Protecting Mobile Networks from SS7 Attacks. Telesoft White Papers

Transcription

1 Protecting Mobile Networks from SS7 Attacks Telesoft White Papers Christian Feest 23rd June 2015

2 SS7 Networks The Challenge The problem with the current SS7 system is that messages can be altered, injected or deleted into the global SS7 networks in an uncontrolled manner - SS7 Network Security Threat Analysis Report [1] Introduction At the 2014 Chaos Communication Congress security researcher Tobias Engel told mobile network subscribers the only way they could protect themselves from security vulnerabilities in Signalling System No. 7 (SS7) if operators fail to secure their networks: Throw away your phone [2]. Originally designed for use by very large, often statecontrolled, telecoms operators, the practical and financial barriers of gaining access to the SS7 network meant it was essentially a walled garden so no authentication was built in. However, with an increase in the number of network operators, increasing inter-connectivity and a reduction in hardware prices since then, these walls are now significantly lower. As the number of network providers and the number of individuals with access to SS7 increases so does the risk of an attack exploiting these vulnerabilities. With an estimated 83% [3] of network operators not applying any filtering to SS7 traffic flowing through their network subscribers are in danger of having their calls monitored, their location tracked and data held about them being modified or deleted by unauthorised third parties with access to SS7. By not taking sufficient measures to prevent these kinds of attacks operators risk breaching data protection regulations, loss of reputation and loss of customer loyalty. The negative publicity and consequent damage to reputation of such an attack would mean enormous loss of revenue as subscribers switch to alternative providers. Further, the cost of restoring reputation and, if regulations are breached, financial sanctions would mean additional reductions in profit. This whitepaper looks at examples of SS7 attacks and what operators can do to prevent them and protect profit.

3 SS7 Vulnerabilities SS7 is used within mobile networks for features such as call handling, SMS and location update but the lack of authentication required with these messages makes them vulnerable to exploitation. Anyone with access to the SS7 network can send these kinds of requests and will often receive a response without being challenged. An attacker could exploit SS7 s lack of authentication, for example, by sending an anytimeinterrogation (ATI) request to an Home Location Register (HLR) for each Mobile Subscriber ISDN Number (MSISDN) number within a certain range. The HLR will send a response for each genuine MSISDN, allowing the attacker to compile a list of phone numbers that could be utilised by spammers. More worryingly, an attacker could make use of SS7 s vulnerabilities to track a subscriber s location using only their MSISDN. This can be done by querying the subscriber s HLR for their International Mobile Subscriber Identity (IMSI) and current Visitor Location Register (VLR) and then directly querying the returned VLR for the cell ID of the IMSI. A number of products targeted at law enforcement and intelligence agencies use this method to track targets and it is predicted to work in 70% of cases [2]. However, there is nothing to stop an attacker using the same technique to track subscribers regardless of whether or not they have the authority to do so. sendroutinginfoforsm( ) sendroutinginfoforsm (IMSI is in MSC 3) HLR ProvideSubscriberInfo (DST: MSC 3, IMSI: ) GMSC Attacker ProvideSubscriberInfo (IMSI: Cell ID: 1234) VLR VLR VLR MSC 1 MSC 2 MSC 3 Figure 1: Tracking a subscriber in SS7 Further, a report from NKRZI, the Ukrainian Telecom Regulator, found that in April 2014 a number of suspicious SS7 packets were received on operator MTS Ukraine s network that modified control data for subscribers so their calls would be forwarded to a landline in St. Petersburg, Russia. Though not mentioned in the report, it would have been possible for the party in St. Petersburg to bridge these calls to the originally dialled number, allowing them to listen in on or record conversations without either subscriber s knowledge.

4 Countering the attack There is no way to stop unauthorised SS7 Message Signal Units (MSU) from being injected into networks and so a solution must work by recognising and dealing with them before they can reach their intended destination. One way this could be done is by placing a firewall at a network interconnect, for example a Signalling Transfer Point (STP) or International Gateway Exchange, and auditing MSUs as they pass through. Packets flowing through the firewall would be decoded and inspected where configured rules would be applied and traffic flow filtered accordingly. Partner MNO s SS7 Network MNO Footprint SS7 Network Country I Country G Country F Interconnect Partner Country A Roaming Gateway Country B Country D Country H Country J Country C Country E Figure 2: Firewall located in roaming gateway Filtering rules could be applied at multiple levels of the SS7 stack to include the following parameters: Application Context Global Title PLMN ID Operation Code Rules could be applied as blacklists, for MSUs to block, whitelists, which block all MSUs of a certain type except those specified and greylists, for events to log. By fully decoding MSUs at multiple levels the firewall could recognise spoofed messages, for example, by comparing the calling party digits in the Signalling Connection Control Part (SCCP) layer with those in the Mobile Application Part (MAP) layer. By blacklisting MSUs that contain mismatches between these two layers an operator could block spoofed messages on their network. Returning to the example of the spammer compiling a list of phone numbers, a network operator may decide to use a whitelist to block all ATI requests except those originating from a list of trusted sources. When the attacker s ATI requests are received by the firewall they will be rejected when the source address is not found on the list. However, ATI requests from whitelisted sources will still be passed on.

5 Network operators own data could also be utilised by the firewall to enable it to make more sophisticated judgements regarding MSU routing. If, for instance, the firewall had access to a subscriber s HLR velocity checks could be performed to detect unauthorised MSUs. A location update from Australia for a subscriber who two minutes previously reported he was in France would clearly be illegitimate. A firewall with access to the relevant database could be programmed to recognise this and act accordingly. MAP MAP TCAP TCAP SCCP SCCP MTP 3 MTP 3 MTP 2 MTP 2 A MTP 1 MTP 1 B Figure 3: Full decode of MSU for multi-layer filtering To further improve the efficiency of the firewall data could be collected in order to build a picture of statistically normal network behaviour. A node that regularly receives large numbers of updatelocation requests, for example, is likely to be an HLR. If all of a sudden mt-forwardsm MSUs are detected as coming from this node it s likely they would be unauthorised as an HLR would not ordinarily send such a message. Building a picture of normal network behaviour in this way could be used to detect International Revenue Share Fraud attacks (IRSF). IRSF attacks work by attaining a premium rate phone number or range of phone numbers from an international revenue share provider, who shares a percentage of the income generated from calls made to these numbers, and fraudulently initiating calls to them. Calls can be fraudulently initiated in a number of ways SIM theft, international call forwarding, hacking Private Branch Exchanges (PBX) but will often have a distinct signature when made for the purpose of IRSF. Known IRSF number ranges could be added to black or grey lists and suspicious activity, particularly long bulk calls to a single number, could be flagged as potentially fraudulent. By recognising suspicious activity like this as quickly as possible the firewall would enable the network operator to take action to block the fraudulent calls, saving money that would otherwise go to fraudsters. MILBORNE SS7 Firewall The MILBORNE SS7 Firewall (IPS) works at line rate in conjunction with existing network infrastructure to fully decode, inspect and block harmful SS7 MSUs. To find out more, call us today, or visit our website

6 Conclusion SS7 was not designed with today s increasingly interconnected environment in mind and the new threats this presents. Network operators who do not evolve to anticipate these threats leave themselves exposed to a wide range of highly damaging attacks against their networks and subscribers and as access to SS7 increases these attacks are only going to become more likely. One way to protect against these kinds of attacks is by using a firewall to filter SS7 traffic at network interconnects. MSU filtering could be applied at multiple layers of the SS7 stack and use data from operators as well as statistics gathered by observing previous traffic to ensure maximum optimisation. A firewall properly configured using these tools would be sufficiently sophisticated to block unauthorised MSUs without blocking legitimate ones and harming valued services. Sources 1. ETSI/TC/SMG#30 P99-744: SS7 Network Security Threat Analysis Report. 4th August Retrieved 2nd June 2015 from: 2. Engel, Tobias: SS7: Locate. Track. Manipulate. Chaos Communication Congress Retrieved 2nd June 2015 from: ss7-locate-track-manipulate.pdf 3. Langlois, Philippe and Gadaix, Emmmanuel: 6000 Ways and More: A 15 Years Perspective on why Telcos Keep Getting Hacked. Hack in the Box Retrieved 2nd June 2015 from: hitb.org/hitbsecconf2012kul/materials/d1t1%20-%20philippe%20langlois%20and%20emmanuel%20 Gadaix%20-%206000%20Ways%20and%20More.pdf 4. National Commission for the State Regulation of Communications and Information Verification of Telecommunications Compliance (Національна комісія, що здійснює державне регулювання у сфері зв`язку та інформатизації). 16th May Retrieved 6th June 2015 from

7 Headquarters Telesoft Technologies Ltd, Observatory House, Stour Park Blandford DT11 9LQ UK t. +44 (0) f. +44 (0) e. Americas Telesoft Technologies Inc 125 Townpark Drive, Suite 300 Kennesaw, Georgia, GA USA t India Telesoft Technologies Ltd (Branch Office) Building FC-24 Sector-16A, Noida Uttar Pradesh, INDIA t f e. e. Copyright 2015 by Telesoft Technologies. All rights reserved. Commercial in Confidence.