Protecting the mobile network from SS7/SRI fraud
An A2P SMS is sent using the mobile number (MSISDN as per E.164), and given the availability of Mobile Number Portability, an MNP lookup must be performed to find the operator belongings of the recipient for routing purposes. Aggregated access to MNP databases globally is not feasible, hence the general modus operandi for SMS providers is to make an Send Routing Information “(“SRI”) look-up via an operator. This is sometimes known as “performing an HLR dip”. Following this query, the SMS provider knows the receiving operators, whereafter a route that allows termination to this network can be selected. The actual SMS will then contain a new SRI and Forward_SM MAP message. Please mind that at the end of the process, a message will be delivered to the operator that has been queried, so there is revenue to be collected for the termination.
There are providers of the SRI service on the market. Mobile operators who resell this function on the market.
It seems like it all works as it should. All SMS providers get the porting information they need and the receiving operator get the termination revenues in the end. Still we see operators objecting to the SRI and blocking them. Why are they doing this?
- Based on the original SRI, a fraudulent provider can send a fake or spoofed Forward_SM
- Information from the original SRI can be used to invade subscriber privacy, as documented and presented by Tobias Engel on 31C3
The key takeaway is that there is a clear collision between the highly commercially relevant provisioning of SRIs and the risks associated with illicit use of the information obtained.
Operators want A2P, as termination of the messages will be a significant source of revenue. But they also want to protect the privacy of their customers. If SRI is blocked, the A2P market is shaking and support for ported numbers is fading, thereby undermining the value of the service for the enterprise that ultimately buy the termination. If SRI is fully accessible, certain fraud scenarios are open and customer privacy it at risk. We need to address both issues. At the same time.
The way operators can defend themselves
- A home routing solution that also return the SRI with a temporary IMSI. Not the real IMSI, but one that is used for mapping the query with the real IMSI. To the best of my understanding, this is regulatory requirement in France. We generally recommend this to operators. This eliminate the fraud scenario and also eliminate all the issues related to SMS and roaming.
- The only other reasonable solution is that operators should allow reselling of the SRI, but ensure that the providers of that service have implemented functions to mask to lower portions of the IMSI. This way the SRI can still be used for routing, but not for any of the illicit purposes. Key is still that a sufficient number of characters are provided so that not only MCC+MNC, but also any additional numbers that is relevant to determine MVNO is provided.
|Issue||How to mitigate|
|“We receive grey SMS traffic”||
Install a filter, sign up with A2P providers and notify your roaming partners that you do not accept A2P via the signalling link. You want to get paid – not get rid of the traffic. Address the real problem!
This issue has nothing to do with the use of SRI’s for routing purposes. If SRI’s cannot be used for a destination the PREFIX and various fall-back solutions are used to achieve the same effect.
|“We receive spoofed messages”||Contact the operator whose Global title is used for the SRI and ensure that they are filtering the lower part of the IMSI.|
|“We receive a large number of SRIs per Forward_SM”||Your problem is that you have connected too few aggregators. Aggregators pass the message around until one has a valid path to you. All intermediate parties will make a query for the same message, Sign up with more aggregators, and the problem will go away.|
|“We receive SRIs and then we receive the Forward_SM from another source”.||Please check if you didn’t also receive an SRI directly associated with the Forward_SM. Normally you would see two SRIs where one is for routing and the second one is for delivery. If this second SRI is not there, it’s likely that it was fetched without the IMSI masking (so it could be used for routing), which is a problem.|