Prevent Bad Signals From Harming Network Availability

A recent Palo Alto Networks blog post described GTP protocol attacks on both the control and user planes, highlighting the importance of full visibility on higher layer protocols to prevent delivery of malware to mobile devices. But another harmful effect of malware is not as well-known: attacks on mobile network signaling protocols. Signaling attacks can be devastating to network availability and invisible to the end user.

In the mobile network industry, we see a huge variety of signaling protocols; the most commonly used include SS7 (2G and 3G networks) and Diameter (4G networks) running over SCTP. In the initial phase of globalization of mobile networks, security of these and other signaling protocols was not an issue – there were few service providers; they were interconnected via purpose-built network GRX (later IPX); and smartphones and Android malware did not yet exist. Now, we know signaling protocols have a lot of vulnerabilities as they were not designed to today’s standards of security.

For example, today the IPX network comprises over 40,000 nodes, and this figure is growing fast. Even this network itself has vulnerabilities. Engineers from BICS, one of the biggest GRX/IPX operator worldwide, conducted research that revealed 5500 nodes accessible from the internet in a global interconnect network. This means that bad guys can get access to those nodes, and that can become dangerous.

Similar to application-based attacks (e.g., a Mirai botnet attack), the disrupted service of several service provider networks in Europe and the Middle East, signaling-level attacks can be targeted against either an end-user or service provider infrastructure. And this is really happening today.

One of the big cases illustrating signaling infrastructure vulnerabilities happened in Europe against one of the largest mobile carriers, which also owns more than 10 mobile networks in Europe and Asia. In this case the network was down, due to receiving the malformed message via SS7 network. In another example, an attack was launched against end users, where SS7 vulnerabilities were used to “drain” bank accounts.

As the problem has grown, GSM Association started to put in place SS7 and Diameter security recommendations[1] in order to help service providers protect their networks and customers. (Official documents are published on GSMA website and accessible for the members.)

Let’s briefly look at a signaling network’s protocol stack and name a couple of the main attack types. The image below shows protocol stacks for SS7 over IP (SIGTRAN) and Diameter.

SS7 Vulnerabilities: A major issue regarding SS7 is that it can allow access to end-user SMS, location and even call by getting certain MAP messages from another node in the SS7 network (which can have a legitimate use case). And, as this protocol is not using authentication methods to authorize a neighboring node, it becomes vulnerable while allowing impersonation of network nodes and/or network partners in roaming interconnect. Based on this vulnerability many attacks against end users can be executed, including fraud, credential theft, eavesdropping, location tracking, SMS and call spoofing, etc. (A good overview of attack types is provided in this SANS Institute white paper.)

SCTP DoS Attacks: Main attacks against infrastructure are denial-of-service attacks that are trying to exploit (the underlying for Diameter and SS7) specific messages on Diameter and SS7 protocols. This attack cannot be stopped by L3/L4 firewalls, as they are not able to see and block messages of higher layer protocols. And with more roaming traffic, it is expected there will be more and more threats as a result of difficulties in identifying what should be blocked, and what should be allowed.

So, what is needed to solve these issues?

Improve visibility: The security platform should be able to see much higher in the protocol stack than L3/L4. It should be able to understand which applications SS7 and Diameter traffic are delivering (i.e., MAP for SS7 or S6a for Diameter protocols.) An important pre-requisite here is to execute SCTP stateful inspection and protocol validation, which also helps to protect against SCTP DOS attacks.

Reduce the attack surface: The security platform should be able to allow only legitimate applications. If the connection is between HSS and MME, it should only be allowed to run S6a applications. On the SCTP level, it should be possible to determine which higher layer protocols are running on it and apply filtering based on so-called PPID (payload protocol identifier).

Allow communication only with connected network nodes: There could be several nodes standing behind the same IP address in an SS7 network, so it’s important to implement filtering based on the real identifier of node in the SS7 infrastructure – also known as “global title.”

With these requirements satisfied, a service provider can apply message filtering to prevent DoS on SS7 and Diameter nodes as well as attacks against end users. An example of this is Category 1 messages in SS7. These are messages that should normally only be received from within the same network, and not on interconnect links from other networks. Additionally, security functions become an integral part of signaling nodes themselves: Signaling Transfer Points and Diameter Signaling Controllers.

A next-generation security platform that takes the measures listed above can stop the majority of real-world attacks and protect signaling elements and network service availability.

Palo Alto Networks recently released additional enhancements to its Signaling Protection capabilities. Palo Alto Networks Next-Generation Security Platform for service providers provides comprehensive and consistent signaling protection, including GTP and SCTP security functions. The next-generation security platform provides deep application layer visibility, consistent policy enforcement and identification of already-infected devices.

For more information, please download our solution brief: Extended Application Layer Visibility across Multiple Mobile Network Peering Points.

[1] FS.11 “SS7 Interconnect Security Monitoring and Firewall Guidelines”; FS.19 “Diameter Interconnect Security”; IR.82 “SS7 Security Network Implementation Guidelines”