Shulou(Shulou.com)06/01 Report--

In this issue, Xiaobian will bring you about how to realize LTE air interface user plane data arbitrary tampering vulnerability analysis. The article is rich in content and analyzes and narrates from a professional perspective. After reading this article, I hope you can gain something.

0x00 Vulnerability Background

June 27, 2020 The GSMA CVD Vulnerability Publishing Platform has published a new vulnerability. The Unicorn team first analyzed the vulnerability.

The vulnerability is introduced by a flaw in the LTE standard because mandatory integrity protection of user plane data is not used, allowing data on the LTE link to be tampered with. DNS requests and responses can be tampered with, for example. Since the attack occurs at the data link layer, any upper layer protocol available defenses against DNS will fail. The only solution is to modify the LTE standard, and 3GPP is currently working on how to fix the vulnerability.

Figure 1 GSMA CVD Disclosure

The vulnerability is a vulnerability in the LTE protocol standard. The reason is that when the LTE standard was formulated, in order to improve the bandwidth utilization rate of short packets, encryption was only enabled at the air interface level for user plane data, and integrity protection was not enforced like control plane data.

This allows remote exploitation of this vulnerability to tamper with a user's IP data messages by attacking the wireless link between the eNodeB and the terminal (mobile phone, etc.) in the operator's LTE network, which the authors named ALTER attack. Even more threatening is that DNS spoof attacks can be carried out on LTE users at the radio wave level.

User plane and control plane of LTE air interface

The control plane of LTE is used to transmit signaling, while the data plane is used to transmit user service data, such as IP packet data carrying voice calls and web browsing.

In LTE, ciphering and integrity protection are implemented at PDCP layer. The following two diagrams are functional diagrams of PDCP layer of LTE air interface (uu interface) control plane and user plane respectively.

Fig. 2 Functional diagram of PDCP layer of LTE control plane

Figure 3 Functional diagram of PDCP layer of LTE user plane

Comparing these two figures, it can be seen that there is encryption and integrity protection in the control plane of the LTE air interface, while there is only encryption in the user plane. In fact, this user-plane encryption is optional in the LTE standard. Of course, operators usually enable encryption when deploying, but the vulnerability has nothing to do with encryption. The problem is that integrity protection is not used.

0x01 Attack process and principle

hardware platform

Figure 4 Schematic diagram of LTE malicious relay

The core component of this attack is LTE Relay, which inserts an LTE malicious relay between the operator eNodeB and the mobile phone. The malicious relay consists of a fake eNodeB and a fake UE (terminal, similar to mobile phone). In the downlink, data sent by the operator eNodeB to the real UE (user mobile phone) is received by the pseudo-UE and sent to the real UE through the pseudo-eNodeB. In the uplink, data sent by the real UE to the operator eNodeB is received by the pseudo-eNodeB and sent to the operator eNodeB through the pseudo-UE. In this way, all data between the real UE and the operator will be relayed.

realization principle

When LTE network enables user plane encryption, to launch an attack, the first thing to solve is to bypass the encryption algorithm on the air interface and modify the IP packet data.

LTE encryption principle

From the conventional thinking, as long as the ciphertext of the block symmetric encryption algorithm is modified by one bit, it will cause at least half of the bits in the packet to change when decrypting, which is a standard for evaluating the quality of the encryption algorithm. From this point of view, when encryption is enabled on the LTE user plane, it seems that modification of the ciphertext will not bring any harm. At most, the data will pass transparently through malicious relay, and malicious relay cannot decrypt it. It is also impossible to modify the plaintext by tampering with the ciphertext under control. However, this idea does not apply to streaming encryption, which happens to be used for LTE user plane data.

Figure 5 LTE user plane data encryption/decryption schematic diagram

As shown in the figure, in the LTE stream encryption process, the key stream generator generates a key stream by using a series of parameters such as AS key, and obtains ciphertext c after exclusive OR of the key stream and plaintext stream. When decrypting, the plaintext m is obtained by exclusive OR of the secret key stream and the cipher text stream c.

encryption

Keystream XOR m = c;

decryption

Keystream XOR c= m;

The sender and receiver use the same AES key, i.e. the same algorithm, to generate keystreams.

2. Bypass encryption and tamper with packets arbitrarily

Figure 6 LTE User Plane Data Encryption/Decryption Diagram after Attacker Insertion

The above figure is a schematic diagram of LTE user plane data encryption and decryption after inserting an attacker. It is assumed that the ciphertext stream c'is obtained by exclusive OR of a specific mask and ciphertext stream c, and the plaintext stream obtained when decrypting is m'.

This process can be described as

mask XOR c = c';

Keystream XOR c' = m';

A simple deduction

Keystream XOR c' XOR m = m' XOR m;

Keystream XOR c' XOR ( Keystream XOR c) = m' XOR m;

Keystream XOR (Mask XOR c) XOR ( Keystream XOR c) = m' XOR m;

available

Mask = m' XOR m;

If you know the original plaintext of the data message, you can get the tamper mask.

For mobile data networks, the DNS of the same operator and the same region is generally fixed and easy to obtain, so the plaintext of the DNS packet can be roughly guessed. However, to do DNS spoof attacks, only the IP address in the DNS request sent by the UE needs to be modified, and the offset of the IP address in the PDCP packet is also fixed, which makes the modification operation easier. The remaining problem now becomes how to locate DNS packets among the many PDCP frames.

3 Locating DNS packets

DNS request data is generally short, you can try to distinguish by length, but it should be noted that how to distinguish the same short TCP SYN request from DNS request, the author through the way of large data, statistics of the mobile network DNS request length distribution, distribution chart is as follows:

It can be seen from this figure that the length of the downlink DNS request response is very distinct from the length of other PDCP frames, and can be distinguished effortlessly. For the uplink DNS request, you can guess, that is, modify the target IP address of the suspected DNS request message to the malicious DNS server controlled by yourself, and observe whether the DNS request response is detected. If a response is received, it means that a DNS packet is modified. This method has a high accuracy.

4 IP header verification and processing

After modifying IP, it will cause the checksum of IP packet to change, and here we have to deal with checksum. Here, the author uses the method of modifying TTL to compensate for IP change to ensure that the checksum of the whole IP header remains unchanged. We know that TTL decreases hop-by-hop as IP packets travel. For IP packets intercepted by the uplink air interface, obviously, no route has been passed since they come out of the UE, so TTL is still a default value, which can be obtained from the default setting of TCP/IP protocol stack of the UE operating system. For the downlink, we don't know how many routes IP packets have traveled since they were sent from our malicious DNS server. Modifying the TTL compensation checksum doesn't work. Here, the author compensates by modifying the identification area in the IP header.

5 UDP checksum processing

For the uplink, since the program that ultimately calculates the UDP checksum is obviously on a malicious DNS server controlled by the attacker, it can be ignored by modifying the protocol stack source code.

For the downlink, modify the DNS server stack to set the UDP checksum directly to 0 and the DNS response remains valid.

This checksum problem is resolved. The holes for tampering with LTE user plane data had been filled in, and the principle of the entire attack had been explained.

0x02 Threat Range

Since the vulnerability was introduced by the LTE standard, it affects all other networks that have evolved from LTE, such as NB-IoT,LTE-V, and future 5G (which still does not have mandatory user plane integrity protection enabled).

Compared with DNS spoof phishing attacks under WIFI, LTE air interface DNS spoof implementation is much more difficult, but the attack range is larger than WIFI. LTE attacks do not need to crack the pre-shared secret key like WIFI attacks. Therefore, regardless of the difficulty of implementation, the success rate and coverage are stronger than phishing attacks under WIFI, and the threat is also greater.

Since the attack occurs at the data link layer, any upper layer protocol available protection against DNS, such as DNSSEC, DTLS, etc., will fail here. The only solution is to modify the LTE standard. At present, some operators and equipment manufacturers have indicated that they want to push LTE standards to fix this vulnerability.

The above is how to achieve LTE air interface user plane data arbitrary tampering vulnerability analysis shared by everyone. If there is a similar doubt, please refer to the above analysis for understanding. If you want to know more about it, please pay attention to the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.