Multiple vulnerabilities in open-source BTS products, attackers or hijacked mobile communication base stations

Objective

In the past few weeks, I have investigated and researched the security of GSM in many aspects, such as the loopholes in GSM communication protocol. In addition, I have a security audit of the most widely used BTS software in the world today. In this article, I'll show you a few of the vulnerabilities I've found in this open source product that will allow an attacker to invade the base station transceiver (BTS) and remotely control its transceiver module.

Background knowledge

A base station transceiver Station (BTS) is comprised of software and radio devices that are essential for smartphones to connect to GSM, UMTS, and LTE networks. BTS is mainly divided into baseband unit, carrier frequency unit and control unit three parts. Baseband unit is mainly used for voice and data rate adaptation and channel coding, etc. the carrier frequency unit is mainly used for the coupling between modulation/demodulation and transmitter/receiver, and the control unit is used for BTS operation and maintenance. The BTS stores the encoding algorithm A5 and the key KC, which is used to decrypt the received ciphertext in the form of user data and signaling data (including decryption).

It is equivalent to a wireless access point in a Wi-Fi network, which manages the communication process for the UM interface. The UM interface is an interface between MS (Mobilestation, Mobile station) and BTS, through which MS completes communication with the network side, completing packet data transfer, mobility management, session management, wireless resource management, and many other functions. The UM interface is the interface between MS and the network in the Gsm/gprs/edge network, also known as the Air Interface (airinterface). The UM interface is used to transmit signaling and business information between MS and the network. The specific one shows:

Figure one: MS-to-BTS connection

BTS's underlying software is actually a signal transceiver, which is a direct interface to wireless hardware devices. It is mainly responsible for frequency tuning and processing Gmsk (Gaussian minimum frequency shift keying) data modulation and demodulation. In short, it is primarily responsible for converting radio waves into digital signals. The communication and synchronization operations of the rest of the BTS's logical units are handled by the three UDP packets shown in Figure two.

Figure two: The Transceiver module and three UDP packets used to communicate with the rest of the BTS's logical units

As shown, the "Clocksocket" packet is primarily responsible for time synchronization; The BTS uses the "Commandsocket" packet to send control commands to the signal transceiver; Finally, "Datasocket" The packet is responsible for broadcasting the GSM packet from the BTS through a radio signal and then receiving the returned response information. Among them, the "Udpsocket" class in the Signal Transceiver module is mainly responsible for processing the communication process of the above three channels.

Our analysis shows that most BTS software currently uses the same (or very similar) transceiver code base. As a result, these BTS software are basically affected by the same vulnerabilities. These vulnerabilities can be exploited by a malicious attacker to remotely control the Signal transceiver module, thereby affecting the normal function of the BTS.

Furthermore, it is possible for an attacker to send a GSM data pulse to the transceiver module and then perform various network attacks on the mobile user, such as IMSI separation, encryption demotion, denial of service attacks, and so on.

In order for the Signal Transceiver module to receive and process the information sent by the attacker, the UDP packet sent to the data channel socket must follow the following format:

When the Signal transceiver module receives these packets, it decodes the packets and then uses the GMSK to signal modulation. Eventually, the signal pulses of different content will be sent to the mobile station (MS) connected to it.

Even if the products labeled in the list below use only GMS or UMTS networks, their signal transceiver modules (which are a standalone component) are essentially the same. So we speculate that the BTS software that handles the LTE connection also uses a similar signal transceiver code.

Affected Products

-yatebts<= 5.0.0

-openbts<= 4.0.0

-openbts-umts<= 1.0.0

-osmo-trx/osmo-bts<= 0.1.10

-and other products that use the same signal transceiver code

Related manufacturers

-legba Co., Ltd. (YATEBTS)

-rangenetworks (Openbts and Openbts-umts)

-osmocom (Osmo-trx and Osmo-bts)

Issue one: Over-exposed service bindings

Overview

This vulnerability exists in the network library of the above product, which causes the udpsockets address of the signal transceiver to be bound to 0.0.0.0, but the address of the three signal transceiver should be bound to the address set by the user (default is 127.0.0.1). This means that attackers can use these addresses to connect to the BTS system and receive (send) packets from the signal transceiver. In addition, access to these services that expose UDP network sockets will not be secure because no authentication mechanism can guarantee the security of these services.

Figure three: Socket addresses for three signal transceivers are all bound to address 0.0.0.0

Effect

An attacker could use an IP connection to send UDP packets and get all the functions of the BTS. This also means that attackers can implement remote control, GSM traffic hijacking, access to user communication data, DOS denial of service attacks, and even worse things happen.

Details disclosure

We can find the root cause of this vulnerability in the constructor of the Udpsocket class. In the source file "Commonlibs/sockets.cpp", you can find the "Udpsocket::open" method, and it is the error code in this method that caused the existence of the vulnerability. It is important to note that this source file is included in all affected products. The following code is the vulnerability code:

As we can see from the code snippet above, the system stores the bound address in the member variable of the Mdestination class, but the Udpsocket::open method is implemented as follows:

Although the Udpsocket class provides a construction parameter to specify the IP address that the server is bound to, this part of the data is ignored by the code. As the No. 272 line of code shows, the communication socket is bound to inaddr_any, but the mdestination address variable is not used.

Issue two: stack-based remote buffer overflow

Overview

An attacker could cause a stack buffer overflow by sending a large UDP packet to the control channel of the device.

Effect

An attacker could implement remote code Execution (RCE) or launch a denial-of-service (DoS) attack on the device.

Details disclosure

The control channel is controlled by the transceiver::d Rivecontrol method in the source file Transceiver.cpp. This part of the code looks like this:

Note the cache space for the packet in the code, which is present in the method stack, and its size is defined as 100 bytes (max_packet_length).

Next, we analyzed the Datagramsocket::read method declared in the source file Sockets.cpp (the Datagramsocket class is the parent class of the Udpsocket Class), and we found the following information:

As we can see, the code reads the length represented by max_udp_length, not the value of the max_packet_length variable. The value of max_udp_length is defined in the Sockets.h source file, as shown in:

As a result, an attacker simply sends a UDP packet of more than 100 bytes to the signal transceiver, which can successfully cause a stack overflow on the target device. Figure four shows the error debug information that is caused by the vulnerability:

Figure Four: Packet segmentation errors due to excessive UDP packets

Issue three: Unauthenticated remote control

Overview

The control channel does not introduce any form of authentication mechanism. Plus ' problem one ' makes some of its information exposed to the external network, so a malicious attacker could exploit this vulnerability to remotely control the transceiver module.

Effect

Attackers can:

-A denial of service attack is achieved by shutting down the module.

-Block the signal transmission by modifying the radio signal frequency.

-Remotely hijack BTS via "setbsic" command.

Details disclosure

The control channel uses transceiver in the source file Transceiver.cpp::d Rivecontrol method to process the UDP protocol. Some of the features exposed by this protocol include:

-Turn TRX Module on or off: Cmdpoweron/cmd POWEROFF

-Change the wireless frequency of Trx: Cmdrxtune frequency/cmd Txtune Frequency

-Set up verification information for GSM signal: Cmdsetbsic value

The attacker simply sends a simple UDP packet to the server's 5701 port, which can be executed remotely

Conclusions, mitigation options, and recommendations

Through this article, you must have been aware of how these code vulnerabilities and the lack of authentication mechanisms will affect these BTS products. And more than that, attackers can even exploit these vulnerabilities to launch large-scale cyber attacks.

We strongly recommend that manufacturers quickly take the following mitigation measures to improve the safety of the product:

1. Update your BTS software, if you receive an update patch push, please install the patch as soon as possible.

2. Bind the socket address used to control the operation and data conversion to the local interface (127.0.0.1).

3. Firewall: Block all external network traffic that flows through port 5701 (control port) and port 5702 (data port).

4. Introduce an authentication system to prevent unauthorized attackers from logging on to the server or accessing the network through the BTS control port.

5. Fix the buffer size problem in the code.

6. Perform additional code audits.

* Reference source : Zimperiumzlabs

Multiple vulnerabilities in open-source BTS products, attackers or hijacked mobile communication base stations