TunnelVision – Malicious SS7 Data Interception Attack

The topic of telecom signalling (SS7) security has been in the news again, from reports on banking fraud being enabled by having SS7 access, to new reports issued by the US FCC and the US Department of Homeland Security. Recently it seems that both criminals and governments are waking up to the potential threat of malicious SS7 access.

While the attacks do generate concern, there is a potential greater danger from the idea that the world’s telecom networks are inherently unsafe and that the problem is unfixable. This is not the case if operators put in place defences on the SS7 network, and to show the reasons why, we can give an overview of a much more sophisticated attack that we successfully detected.

Soon after going live in one of our customers – a mobile operator in the Middle East – we encountered a very unusual type of attack. A previously unknown attacking ‘platform’ (a malicious system connected to the global SS7 network), based in Central America, had sent a specific command to the operator targeting a particular subscriber, i.e. a mobile phone user. This command – an InsertSubscriberData (ISD) packet – was sent to a SGSN that the subscriber was attached to. It instructed the SGSN to change the settings for the subscriber, basically to inform the attacking node if the subscriber set up a data session, and wait for instructions on how to route it. While this attack was successfully detected by our SS7 Protection firewall, it did open up a very interesting line of inquiry.

From our research, it became apparent that using this method the aim would have been to redirect the user’s data connection, to travel via a specific access point name (APN – a gateway between the mobile network and the internet). In theory, using this method, an attacker could then try to eavesdrop on any (unencrypted) data communications from the device to the internet.

Without going into specific detail, the attack would have executed like the following:

1. Attacker SCP node sends a malicious ISD command, changing the subscriber’s CAMEL settings
2. Targeted subscriber attempts a data session.
3. Via the CAMEL protocol, the SGSN the subscriber is attached to contacts the Attacker node for verification, which returns back the ‘Bad’ APN.
4. SGSN resolves the APN to a corresponding ‘Bad’ Attacker Node GGSN , and establishes a GTP tunnel to the ‘Bad’ Attacker GGSN. All IP traffic from customer handset travels via this path. This traffic would then go on to the internet or any other external point, but the attacker would be able to monitor and (and potentially manipulate) this traffic

One particular important point is the initial malicious ISD (InsertSubscriberData) command was detected, and the subsequent steps (2 to 4) did not occur. However, the particular settings within the ISD command allowed us to determine what the attackers were aiming for if the attack had been successful.

This event was notable in a number of ways:

• First, while methods to intercept SMS and call interception using access to the SS7 network had been known in the past and reported, this particular method of doing data interception was not well-known. While something very like it had been theorized in the past¹ this was a real-life attempted data interception attack that was detected, not an academic possibility. While we did not witness the attack proceed beyond the attempt to change the subscribers settings, the next steps of changing the APN and eavesdropping on the user’s data traffic would have been theoretical possible in the operator’s network. This means that the attackers not only knew this method, but had probably tried it before in this or other operators, with a good chance it may have succeeded.
• Secondly and more importantly this shown the benefits of having SS7 Protection in place. While the dangers are real the fact is that defences in SS7 network – when put in place – combined with intelligence, work. What’s more, previously rare or even unknown attacks can be detected and defeated. In this particular case, an AdaptiveMobile supplied SS7 Protection firewall was in place, monitoring incoming international activity into the operator. This meant the initial ISD attack was successfully triggered on by the Firewall before it could cause any damage.

In this particular attack case the typical operators that would be vulnerable to this particular attack are operators that have a lack of SS7 security controls but also a sophisticated enough CAMEL network to enable this (CAMEL v3 and above), so this would be a smaller list of possible target operators than for other type of SS7 attacks. However as attackers typically aim at the weakest members of any system, then if some mobile operators have protection and others don’t, it means the ‘have-nots’ are even more at risk.

Nonetheless, the fact that we are still learning the total attack possibilities within SS7 means that even the ‘haves’ should not be complacent. Mobile operators should put in place defences to detect and actively block not only attacks that are known today, but also to handle any changes in attack methods or targets. As many attackers know, data is key, and the more intelligence that mobile operators have about the threats affecting their network, the better they can protect their subscribers.

1: Slide 19