Quantum of Malice

Modern mobile networks rely heavily on data both from consumer and corporate perspectives. At the same time, we are moving towards a landscape where not only MNOs (Mobile Network Operators) maintain critical infrastructure, but also more traditional business entities like international corporations, sports teams and even schools, colleges and universities begin to setup and use their own private mobile networks. 

While this offers interesting possibilities for end users and especially private interests, it also comes with its own share of security challenges. In CT (Communication Technology) security, the focus, especially on the telecom side, has for a long time been the quest for the next signalling network interconnect type of attack. Even more impactful would be something that translates to 3G, 4G, 5G and beyond. However, it seems for firewall vendors, network infrastructure developers and security researchers that we have yet to find this elusive tele-sasquatch. Not for a lack of trying, but it’s getting harder and harder to deny that some problems of the telecom interconnect protocols have actually been resolved and the industry may deserve at least a small gold star for that. 

Armed with the assumption that no new sendRoutingInfoForSm is hiding in the bushes, we at Enea set out to find some new ways an attacker could disrupt mobile network services. Instead of chasing ghosts of the interconnect we decided to look for answers in the clouds. After all, when chasing a dream where else would you look? And why not mix dreams with reality and generate some novel threats based on tried and tested demons from the past. 

Man–In–The–Middle (also sometimes known as machine-in-the-middle, manipulator-in-the-middle or other variations) is a fairly well–known concept, often used when explaining why Diffie Hellman key exchange works. But as much as the term is thrown around it’s not a wheel that is popular to reinvent. Although it should be – it’s a healthy exercise for any aspiring researcher and there’s no harm in trying it over new protocols. It turns out that these attacks are still viable on telecom protocols as these are heavily reliant on SCTP.

As the reader may be aware, the network stack usually consists of a layered stack where each layer represents a specific functionality. At the top of the stack we usually find the protocol spoken by applications. Using the Web as an example, we could find HTTP code here, one of the languages spoken by web browsers and web servers. This HTTP code would be encapsulated in the HTTP protocol. The HTTP protocol is in turn encapsulated in what is called a Transport protocol, and on the web it’s either TLS on top of TCP or simply TCP (Transmission Control Protocol).  

TCP sits on top of the IP protocol and the IP protocol usually sits on top of Ethernet or some type of tunnelling protocol. But for discussion we are mostly interested in the Transport Protocol. In telecommunications specifically a non–TCP protocol called SCTP (Stream Control Transmission Protocol) was selected to carry the telecom protocol payloads. This was a decision made long ago and it sets the telecom networks aside from the web communication. The SCTP protocol has a few features that makes it different from the more popular TCP protocol, but in many ways they are also similar. They both keep track of communications using sequence numbers where each transaction is acknowledged by the recipient. They are both cleartext protocols and they both have some type of handshake to initiate the connection. 

But there are also some key differences. The SCTP is, despite its name (stream control transmission protocol) is not a stream protocol but a message–based protocol, more similar to UDP datagrams in this way. The streams are actually different “channels” in the connection that could provide some isolation within a single connection, or “association” as they are called in SCTP-speak. The TCP protocol on the other hand doesn‘t have streams but is a streaming protocol. This means it can keep on streaming data on and on and it‘s up to the application to interpret when transmission is complete. But let‘s not dwell on this, we shared our research on the SCTP protocol and we did this because there are hardly any sophisticated attacks published on this protocol. So we felt it was our responsibility to demonstrate some of the possible attacks and vulnerabilities within existing implementations of the SCTP protocol. Even in 5G where TLS is introduced there are still plenty of SCTP associations and even a few UDP connections that can be freely exploited and played with. Our research however quickly led us to a wonderland of MOTS (Man–On–The–Side) attacks and how these could be implemented on 5G protocols. Using this MOTS research we were able to: 

1. Redirect UPF Connections.

The implication here is obvious: if you redirect the UPF connection you can intercept traffic from the network here and manipulate, steer it away, block or disrupt. 

2. Create Transparent Service Degradation.

Here the use case is perhaps less obvious – nobody in their right mind would attempt to hijack critical infrastructure just to slow down their neighbours Netflix streaming. A more practical use case would be a network where some third–party devices are already compromised, but their QoS settings prevents efficient data exfiltration or creates obstacles for the attacker when attempting to use the devices in other subsequent attacks in a more elaborate kill chain. In such cases the modification of QoS may serve as a means of improving the attacker’s capabilities or obstructing certain devices that may interfere with the attacker’s plan. 

3. Crash 5GC Protocol Parsers.

We were also able to identify and exploit a fair amount of poorly written protocol parsers both on the AMF and NG-RAN side. These are of course vendor and implementation specific but still illustrate that there is work to be done when it comes to developing secure telecom protocols. It also highlights that some of the maturity we have come to expect in webservers is still lacking in core network elements. 

Early in 2023 we presented our findings to the industry within GSMA working groups, and have received very positive feedback on our work. We have since continued our research. In this blog we reveal how we performed these MOTS attacks. 

Our attacks were made using a technique known as Quantum Inserts, it has been demonstrated on TCP, most notably as part of the Snowden NSA leaks but so far there have been no previous publications on doing this on using the SCTP protocol. This is hardly surprising since SCTP is mainly used in telecom protocols and not as widely attacked as TCP. Of course, it should come as no surprise that these SCTP based attacks work not only on NGAP in 5G but translates into any protocol using SCTP as transport. 

The attacks exploit the retransmission feature of the SCTP protocol and the fact that the kernel implementation of the SCTP protocol relies on transmission sequence numbers to determine the retransmit. This makes sense since a retransmission can occur for several reasons. Our attacker node is set up on the same switch as the target or any relay device or node along the path of the transmission.  

Screenshot from demo MOTS attack

To execute the attack our purpose–built tool will create a raw socket and monitor the eth0 interface for any SCTP traffic between our gNodeB and AMF. Before the attacker can actually interact with the traffic he must collect some information. This can’t be done by only monitoring SCTP heart beats, the information must be gathered from true data chunks. So we will monitor specifically for this. 

First we intercept transaction sequence number and the verification tag of the connection. Together with the Stream ID and payload identifier we now have enough information to mimic and exchange between the two entities. We are free to modify NGAP or S1AP packets as long as we don’t interfere with the NAS portion of the packets. This is because the NAS portion has integrity protection built into the protocol. The NGAP and S1AP however does not… 

Now the attacker simply has to wait for the packet it should target. In our case the DownlinkNASTransport AuthenticationRequest – strictly for demo purposes we will modify the Authentication values, more specifically the: 

• Authentication management field
• The sequence number
• And the message authentication code.

When the target packet comes along, our attacker node generates an instant response, preceding the actual response and thus allowing us to respond on behalf of the NG-RAN or AMF with false information, for example the wrong IP of the UPF.  

Attack flow of MOTS attack. Malicious response is inserted prior to real responses being received. This real response is treated as a retransmit 

The original response arrives milliseconds after our attack, but at that time it is too late, the recipient has already received our attack response and classified it as the response based on transmission sequence number. The actual response is discarded as a superfluous retransmit and disappears into oblivion, dropped between nodes never to be seen again.

Anatomy of an attack: Wireshark flows showing 2 responses to InitialUE Message in packet #9. The malicious response is packet#10, while the actual response is in packet #11, but is seen as a retransmission and is dropped. 

Using this method multiple types of attacks can be performed.  

The simplest first type of attack is to inject a response where the bit rate is set to zero, i.e. perform a type of Denial of Service, as below, where the uEaggregateMaximum BitRateDL is set to zero.

Attack Example 1: Service degradation by adjusting bitrate in a NGAP message 

The next type of attack is to return a specific non-zero value. For example, below we have changed the AUTN value in the 5G authentication challenge to be our own specific string.  

Attack Example 2a: Original packet with the AUTN data is unmodified. 

Attack Example 2b: Attacker packet where the AUTN data has been replaced with “banana splits!” 

Like the previous attack, the end result of this is Denial of Service, but it is accomplished via a different means.

The next type of attack is to perform data interception. Here we change the IP address of the UPF reported to the gNodeB in the attacker response in order to trick it to redirect the IP flows.  

The normal traffic flow is as follows:

However, our malicious response to the gNodeB (over the N2) interface tells the gNodeB that the UPF is a different IP address, in this case 10.0.0.6 

Attack Example 2: UPF redirection by modifying the IP Address of the UPF 

As a result, the N3 IP flow is redirected to a UPF that the attacker controls: 

The successful attack re-routes the traffic from NG-RAN to the attacker UPF where it can be intercepted and/or monitored.

Since our focus was NGAP we couldn’t help but also look at S1AP, the 4G counterpart of NGAP. Like NGAP is for 5G, S1AP is the 4G control plane , that is active between the eNodeB and MME. The S1AP works just like NGAP in that it is carried by the SCTP Transport Protocol. This means that the exact same attacks work just as well in 4G. An example of a 4G MOTS data redirection attack is shown below. In fact, you should also be able to translate similar attacks to SS7, as SCTP is also used extensively here. The foundation for this new class of attacks is using transport layer attacks and they will translate everywhere. More importantly, all major SCTP implementations are vulnerable to these attacks and we have not seen any indication that updates are even considered by other telecom vendors or operating system developers. 

Above is a table that generally describes some of the more common telecom protocols and as you can see a fair number of them do rely on SCTP for transport. 

To show the effectiveness of the principle of these attacks on the 4G S1AP protocol, below we have the S1AP version of the DoS and Redirection attacks that we performed on the NGAP protocol.

S1AP Attack Example1:  Service degradation by adjusting bitrate 

S1AP Attack example 2: Redirection attack sent to a eNB, forcing it to use a malicious UPF SGWredirection by modifying the IP Address of the GTP-U Tunnel

 As seen above, the S1AP attacks are nearly identical to the DoS and Data Redirection attack we were able to do on 5G NGAP, and the effects are the same. 

When a new class or style of attacks, or in this case, a whole new dimension is added to the mobile network battlefield, the first reaction among some is to point out that attackers need more access than just interconnect, and they are correct. But in a cloudified landscape where anyone and his hamster will be running their own 5G core, you will see more access. During our investigation of actual 5G network nodes we have also noticed that even if IPSec is recommended, it’s often neglected, poorly implemented and more importantly not always a viable way of mitigating these attacks. Since the attacker is sitting alongside the connection, next to the source or destination, or anywhere along the path where a cleartext is visible, the IPSec is rarely a guaranteed protection against this type of attack. 

Since our presentation, we have continued to refine countermeasures against these types of attacks and also generated some unique and cutting edge tools to deal with threats that go beyond what we have presented here. The industry is moving into containerized, self-healing, auto-configuring and re-generating networks. Enea realizes that we need to test this new network structure with an attacker mindset, and this requires us to think about mobile operator security further than just the stale rehashed edge attacks. For a true self-healing network we require defences against attackers capable of image compromise, hypervisor control, orchestration manipulation and dynamic re-infection. A single choke-point model is not going to be able to deal with these attacks effectively – what is needed is a defence in-depth mindset for protection.

Enea’s latest security innovation is designed to extend the visibility of signaling firewalls and ensure robust protection against dynamic and emerging threats. Discover more about Enea’s world-first, next generation signaling technology here>.