As the awareness around SS7 vulnerabilities in mobile networks increases, thanks in good part to the work of the GSMA’s Fraud and Security Group (FASG), we find in the last few SS7 vulnerability tests that we conducted, that more operators are blocking Category 1 SS7 vulnerabilities, while not blocking anything else.

Category 1 vulnerabilities cover, among other things, the ability for an attacker to resolve a subscriber’s IMSI knowing only the subscriber’s phone number. The IMSI is in turn required to conduct most subsequent attacks such as call interception or SMS interception.
Category 1 vulnerabilities are usually easy to block with the most popular STPs, and while this is a step in the right direction, some operators falsly believe that their networks are safe from further attacks, because IMSIs cannot be resolved by attackers.

Attackers, including foreign intelligence agencies, have long been known to acquire IMSIs by using some of the following non-SS7 based method:
– following the target with a passive or active IMSI catcher
– getting physical access to the target’s phone for a short time, for example at a bar, nightclub or restaurant
– snooping on SCCP roaming signaling traffic, for example through leaks or attacks at SCCP carriers. An interesting story on the subject can be found here.

But in light of several recent massive leaks of MSISDN <-> IMSI lists in various countries, which are later found and brokered on the dark web, we would like to attract operators’ attention to a lesser known SS7 based method for building a MSISDN <-> IMSI list for an entire subscriber base.

The method relies on the MAP message RestoreData, which is used when an MSC has lost the profile for a subscriber that is still actively attached to the MSC, and the MSC must request a new copy of the subscriber profile from the HLR. This message can only be filtered with stateful, Category 3 type SS7 firewalls and often receives little attention in vulnerability assessments and remediation efforts. We have not seen any HLRs of any major vendors that are currently filtering this threat appropriately, even when expensive additional SS7 security packages are deployed.

A typical operator has a 6 digit MCCMNC, leaving 9 random digits in an IMSI for assignment to subscribers. By inspecting a sample of the operator’s SIM cards (from retail purchase at a few different outlets, including any MVNOs or sub-brands), this number range can often be reduced to 8 or less digits, particularly in smaller countries.
This gives us a maximum number of unique IMSIs of 100 million, possibly less.

Using the RestoreData message, an attacker can now sequentially request the profile for each possible IMSI from the HLR via SS7, starting with XXXXXXX00000000 all the way to XXXXXXX99999999. The first MSU sent by the HLR in answer to a RestoreData message generally contains the MSISDN, so that the operation can then be silently aborted to minimize the number of MSUs sent.
“Scanning” in this manner an 8 digit range of IMSIs would therefore only require 100 million MSUs to be sent in each direction.
If we assume that 10 MSUs per second is a “safe” packet rate for an attacker to stay under the radar, it would take 116 days of continuous scanning to build a full list of all subscribers’ IMSIs.
If the rate can be increased to 100 MSUs per second, the “scanning” of the entire subscriber base would only take 12 days. Less is the variable IMSI range can be narrowed to something smaller than 8 digits long.

Would an operator whose only SS7 security is STP based filtering of Category 1 messages notice such an attack, even at a speed of 100 MSUs per second? That would be a question for each operator’s security team to answer…