Introduction to mobile network intrusions from a mobile phone

Sébastien Dudek
Feb 4 · 17 min read

With the introduction of the packet service, mobile user equipment (UE) are able to use the IP communication protocol. Without the right routing and filtering of UE communications, some sensitive assets on the operator’s infrastructure could be exposed, such as core network services.

Mobile operators are generally aware of this kind of attack vector and apply the right mechanisms to avoid any risk from the subscriber context. Nevertheless, those mechanisms are different from an operator to another and their effectiveness varies.

Research aspects in mobile networks are evolving a lot with the development of the SDR (Software-Defined Radio), as well as the SDNs (Software-Defined Networks), that introduce new kinds of architectures. These new architectures are mostly cloud-based systems and include also new features that need time to be fully understood and matured from the deployment perspective. In addition, with the research progress of SDR based 4G and 5G-NR NSA networks, new services also appeared to be used inside organizations like private mobile networks, but all security procedures and mechanisms are only provided by the organization itself.

This post is an overview of previous assessments on private GPRS and LTE mobile network commercial and public solutions, but also 5G-NR NSA setups.

Without the right routing and filtering of UE communications, some sensitive assets on the operator’s infrastructure could be exposed, such as core network services.

Mobile network architectures

In this section, we will focus on the elements that allow data transfer and connection to external IP networks. We will first explain briefly what are the architectures in 2G, 3G, and 4G before giving the new elements and architecture introduced by the move to 5G-NSA.

From 2G to 4G

The following picture illustrates the simplified architectures of 2G to 4G networks:

Starting from 2.5G with packet-switched data to 3G, we see two interesting components that are the SGSN (Serving GPRS Support Node) and the GGSN (Gateway GPRS Support Node).

The GGSN is the router between the mobile network and the external networks, such as the internet. The GGSN communicates using IP to the internet and uses SGSN to bridge communications to the UEs. It is responsible for the IP address assignment for UEs and is the default router for the connected UEs. On the UEs this router is generally identified by an APN (Access Point Name).

The SGSN provides packet-switched service capabilities within GSM, EDGE, EGPRS, and UMTS networks. The SGSN is responsible for mobility management, billing, and the management of data sessions.

In 4G, the architecture (see ETSI TS 13 specification) changes a bit by introducing an EPC (Evolved Packet Core) and is composed of different sub-components such as:

  • an MME (Mobility Management Entity);
  • an S-GW (Serving GateWay);
  • an P-GW (Packet data network GateWay).

The MME is the key control node in LTE, and is responsible for:

  • IDLE mode UE (User Equipment) tracking;
  • paging procedure such as re-transmissions;
  • bearer activation and deactivation process;
  • S-GW selection for a UE at the initial attach;
  • intra-LTE handover with Core Network node relocation;
  • user authentication with HSS.

The lawful interception of signaling is supported by the MME.

The S-GW forwards and routes user data packets and acts as an anchor for the user plane during inter-eNodeB handovers and as the anchor for mobility between LTE and other 3GPP technologies. The S-GW keeps UE contexts such as IP bearers and routing information, and stores contexts during paging. It also performs replication of the user traffic in case of lawful interception.

The P-GW assigns IP addresses and is the entry point of data traffic of UEs. It is used for:

  • policy enforcement;
  • packet filtering;
  • charging support;
  • lawful interception;
  • packet screening.

The transition to 5G

The transition from 4G to 5G network delivers the whole network as a service. 5G and its new core network are more about enabling a large set of services including MIoT (Massive Internet of Things) applications such as traffic sensors, cars with V2X, and other applications for smart cities.

Two kinds of architectures are known for the 5G network as modes:

  • SA (StandAlone);
  • NSA (Non-StandAlone).

At the time of this post, commercial 5G network deployment utilizes primarily the NSA mode and shares the same core network as LTE, known as NSA LTE assisted NR:

The SA mode provides an NGCN (Next-Generation Core Network) that could replace the EPC as shown:

Moreover, 5G standalone architecture is virtualized, which introduces new ways of developing, deploying, and managing services thanks to SDN (Software-Defined Network). This move will bring many advantages:

  • CUPS (Control and User Plane Separation);
  • reduce network operation costs;
  • provide services with faster data speed;
  • quickly applying patches and replacing vulnerable instances.

Additionally, 5G introduces the concept of network slicing that enables new services through network segmentation. Nevertheless, 5G network slices must be appropriately isolated by the operator to avoid any risks of exposing sensitive assets to unwanted users.

Building a test environment

The following illustration shows a simplified environment we reproduced to illustrate possible attacks, such as those that could be found in a 4G and 5G-NR NSA core network:

This environment includes an EPC manager that is specific to the LTE solution. To complete this environment, we have added a Tomcat service to simulate another non-mobile management service that is also common to find in this type of network too.

As we can see in the figure above, the use of a particular APN will put the UE in a predefined IP range. In some virtual networks, as it’s the case for M2M (Machine-to-Machine) one for urban and IoT systems, the use of the right APN can be a real deal as it allows access to particular backends and resources. As a consequence, the isolation should clearly be done properly (e.g. osmo-ggsn default firewall). Otherwise, an attacker will be able to browse the different subnets as well as exposed services.

In the next section, we will go through general problems that could be found on some private commercial and open-source GPRS/EDGE/EGPRS, and LTE as well as 5G-NR NSA networks solutions.

Intrusion steps

To plan for intrusion test cases, let’s have a look at interfaces exposed. As an attacker, there are three attack vectors that came in mind:

  • a public IP address might be tried to access the target from the internet;
  • USIM card might be used to try attack gateways and exposed backend services;
  • radio fuzzing might be tried to look for 4G, or 5G protocol stack vulnerabilities.

It is to be noted that at the time very few 5G stack implementations exist and even less in open source for security research. The project OpenAirInterface5G, for instance, has to be used in the dev branch to get the 5G-NR implementation. Note that this can be a little bit confusing even for experienced users. So there are still limitations when fuzzing 5G protocol stacks effectively and in a standard-compliant way actually.

Attacks using USIM cards are at times more successful as one might expect. It is sometimes possible to access many core network resources, including the MME, by using the connection provided by the USIM card and the APN.

The steps would be the following:

  1. get an IP address with a provided APN;
  2. scan the IP range given by the P-GW, and those above;
  3. exploit default passwords in exposed services;
  4. find remote command execution vulnerabilities;
  5. upload static tools and look for credentials during intrusions (passwords, private keys) and topologies;
  6. pivot from one machine to another to get access to other networks;
  7. control most of the physical and virtual machines.

If you are familiar with security and penetration testing, these steps look similar to internal intrusion, except it this case it is done using rogue user equipment.

As an example, by intruding the MME to monitor, it could be possible to compromise the traffic:

In the following chapters, we will explain security testing methods to access to these assets by exploiting common configuration mistakes and other weaknesses, which can also be found during an internal or external pentests of mobile networks.

To illustrate these common issues, we will go through the different steps with generated traces reproduced for the purpose of this blog post.

Using the USIM cards

First and foremost, a USIM card of the targeted network is necessary to get the first access. Then there are multiple ways of connecting to the targeted network exist, depending on the radio support:

  • a 4G or 5G cellphone;
  • a 4G or 5G router;
  • but also a Software-Defined Radio UE.

Cellphone or mobile router devices

By putting the USIM card on the phone and tethering the connection of the phone, our computer is able to see the subnet created by the tethering device:

$ ip ad
[...]
22: ens8u1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
pfifo_fast state UNKNOWN group default qlen 1000
link/ether 8e:85:a1:**:**:** brd ff:ff:ff:ff:ff:ff
inet 192.168.42.131/24 brd 192.168.42.255 scope global dynamic ens8u1
valid_lft 3565sec preferred_lft 3565sec

By performing a traceroute we can retrieve the subnets above:

$ traceroute penthertz.com
traceroute to penthertz.com (37.187.1.112), 30 hops max, 60 byte packets
1 192.168.42.129 (192.168.42.129) 1.455 ms 1.631 ms 1.686 ms
2 192.168.3.1 (192.168.3.1) 26.892 ms 38.573 ms 38.535 ms
3 extrouter (192.168.0.1) 44.764 ms 44.774 ms 44.887 ms
4 10.125.28.236 (10.125.28.236) 56.978 ms 57.085 ms 62.695 ms
5 10.125.15.164 (10.125.15.164) 68.422 ms 68.472 ms 68.438 ms
6 10.125.15.154 (10.125.15.154) 74.166 ms 49.972 ms 50.171 ms
7 212.194.172.148 (212.194.172.148) 61.643 ms 68.226 ms 68.230 ms
8 62.34.2.20 (62.34.2.20) 73.729 ms 73.776 ms 73.761 ms
9 62.34.2.0 (62.34.2.0) 79.935 ms 79.967 ms 79.850 ms
10 * * *
11 * * *
...

Alternatively, other types of UE such as an SDR-based UE can also be used, but this generally does not change the final results.

Software-Defined Radio UE

Within some LTE implementation such as srsLTE and other commercial solutions like Amarisoft, an SDR UE is used to test the radio and the connectivity to the core network.

As for the LTE, people behind the OpenAirInterface5G project developed a nrUE, but it is not yet complete and only includes very few features.

For this section, we talk about the use of srsUE of srsLTE to connect to the targeted eNodeB, which is connected to the same EPC as the targeted gNB.

After compiling srsUE with PCSC support, we can configure the UE by editing the ue.conf file as follows:

[rf]
dl_earfcn = 3350
freq_offset = 0
tx_gain = 80
#rx_gain = 40
...
[nas]
apn = internet
apn_protocol = ipv4

If we do not know the eARFCN in use, we can use different tools:

  • Modmobmap;
  • OpenLTE scanners;
  • srsUE scanning library;
  • cellphones DIAG interface thanks to tools like SCAT.

After plugging the USIM card in a PCSC reader, srsUE can be run as follows:

$ sudo srsue --usim.mode=pcsc

This will result in the following lines showing that everything worked as expected if the setup was correct:

Found Cell:  Mode=FDD, PCI=1, PRB=25, Ports=1, CFO=3.6 KHz
Set RX sampling rate 5.76 Mhz, filter BW: 5.00 Mhz
Found PLMN: Id=00101, TAC=1
[...]
RRC Connected
Network attach successful. IP: 192.168.3.2
Victim Network (Victim) 27/12/2019 15:21:38 TZ:64

As we can see, with the right APN we are directly connected to the dedicated network that has been set previously in the IMS, through the tun_srs:

$ ip ad
[...]
28: tun_srsue: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc
pfifo_fast state UNKNOWN group default qlen 500
link/none
inet 192.168.4.2/24 scope global tun_srsue
valid_lft forever preferred_lft forever

This setup is a bit more complex, but here it is even more obvious we are connected as 192.168.4.2, unlike with the tethering feature of a router, or any smartphone that shows 192.168.42.129. We are also sure that no filtering is applied between us and the P-GW.

Public IP address

Exposed service directly as the external interface is generally filtered. But if some services are reachable from the internet, it is likely that these services are also listed in services such as Shodan or Censys, allowing an attacker to probe a list of open services without port scanning.

Missing network segmentation and isolation

Beginning our attack

Getting connectivity on the UE dedicated network, the first move that comes in mind is to trace the route of a connection to get a list of gateways and IP ranges we can try to get access to. To illustrate this scenario, we reproduced a small setup also inspired by a private LTE network based on Amarisoft.

Here is an example of the path we can get with a private LTE network solution:

$ traceroute penthertz.com
traceroute to penthertz.com (37.187.1.112), 30 hops max, 60 byte packets
1 192.168.42.129 (192.168.42.129) 1.455 ms 1.631 ms 1.686 ms
2 192.168.3.1 (192.168.3.1) 26.892 ms 38.573 ms 38.535 ms
3 extrouter (192.168.0.1) 44.764 ms 44.774 ms 44.887 ms
4 10.125.28.236 (10.125.28.236) 56.978 ms 57.085 ms 62.695 ms
5 10.125.15.164 (10.125.15.164) 68.422 ms 68.472 ms 68.438 ms
6 10.125.15.154 (10.125.15.154) 74.166 ms 49.972 ms 50.171 ms
7 212.194.172.148 (212.194.172.148) 61.643 ms 68.226 ms 68.230 ms
8 62.34.2.20 (62.34.2.20) 73.729 ms 73.776 ms 73.761 ms
9 62.34.2.0 (62.34.2.0) 79.935 ms 79.967 ms 79.850 ms
10 * * *
11 * * *
...

Using a different APN like ims, gives us access to another subnet as follows:

$ traceroute penthertz.com         
traceroute to penthertz.com (37.187.1.112), 30 hops max, 60 byte packets
1 192.168.42.129 (192.168.42.129) 1.881 ms 2.272 ms 2.352 ms
2 192.168.4.1 (192.168.4.1) 28.282 ms 40.591 ms 40.604 ms
....

By scanning subnetworks above ours, we are able to reach other devices:

Nmap scan report for devtest.lan (192.168.0.26)
Host is up (0.062s latency).
Nmap scan report for 192.168.0.27 [host down]
Nmap scan report for 192.168.0.28
Host is up (0.18s latency).

Even the gateway which is used for internet access and its management interface:

$ sudo nmap -v -A 192.168.0.1
[...]
80/tcp open http
| fingerprint-strings:
| FourOhFourRequest:
| HTTP/1.0 404 Not Found
| Content-type: text/html
| Date: Fri, 27 Dec 2019 21:46:41 GMT
| Connection: close
| Pragma: no-cache
| Cache-Control: no-cache, no-store, max-age=0
| Expires: 0
| <HTML><HEAD><TITLE>404 Not Found</TITLE></HEAD>
| <BODY><H1>404 Not Found</H1>
| requested URL was not found
| </BODY></HTML>
[...]

In the UE subnet we are able also to get exposed services of the P-GW, that is also used as the MME, MBMS, and other purposes:

nmap -v -A 192.168.3.1      
[...]
Scanning 192.168.3.1 [1000 ports]
Discovered open port 80/tcp on 192.168.3.1
Discovered open port 8080/tcp on 192.168.3.1
Discovered open port 22/tcp on 192.168.3.1
Discovered open port 9000/tcp on 192.168.3.1
Discovered open port 9003/tcp on 192.168.3.1
Discovered open port 9001/tcp on 192.168.3.1
Discovered open port 8009/tcp on 192.168.3.1
[...]
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
80/tcp open http Apache httpd 2.4.29 ((Ubuntu))
| http-methods:
|_ Supported Methods: GET POST OPTIONS HEAD
|_http-server-header: Apache/2.4.29 (Ubuntu)
|_http-title: Apache2 Ubuntu Default Page: It works
8009/tcp open ajp13 Apache Jserv (Protocol v1.3)
|_ajp-methods: Failed to get a valid response for the OPTION request
8080/tcp open http Apache Tomcat 8.5.50
| http-methods:
|_ Supported Methods: GET HEAD POST
|_http-title: Apache Tomcat/8.5.50
9000/tcp open cslistener?
9001/tcp open tor-orport?
9003/tcp open unknown
[...]

We can also conclude that the network is flat as we are able to reach the other interfaces of the gateway using other subnet addresses:

$ sudo nmap -v -A 192.168.4.1    
Starting Nmap 7.70SVN ( https://nmap.org ) at 2019-12-27 14:06 CET
Scanning 192.168.4.1 [1000 ports]
Discovered open port 80/tcp on 192.168.4.1
Discovered open port 8080/tcp on 192.168.4.1
Discovered open port 22/tcp on 192.168.4.1
Discovered open port 8009/tcp on 192.168.4.1
Discovered open port 9003/tcp on 192.168.4.1
Discovered open port 5060/tcp on 192.168.4.1
Discovered open port 9000/tcp on 192.168.4.1
Discovered open port 9001/tcp on 192.168.4.1
[...]

Similar attacks on real operators

It is important to note that this type of vulnerability has also been seen before on real operator networks. The American Sprint operator had a case where they did not isolate UE properly, allowing an attacker with a provided USIM card to perform scans (see the following picture) and contact exposed services. As a result of this vulnerability, Chris Valasek and Dr. Charlie Miller were able to remotely exploit an exposed D-Bus service called Uconnect, and to control every car connected to the M2M network dedicated to cars.

Critical services exposed

As an example of service exposure, looking at TCP port 80 of a private LTE solution, we are able to access a management interface after a directory fuzzing as shown here:

This manager allows to capture packets in the EPC at different points (MME, MBMS, etc.) but also to execute commands:

(mme) uectx
MME_UE_ID eNB_ID eNB_UE_ID M_TMSI
104 0x1a2d0 5 0xd53a880a
(mme) ue
IMSI IMEISV M_TMSI REG TAC #ERAB IP_ADDR
901700000029550 3596780********* 0xd53a880a Y 00101. 0x1 1 192.168.3.2

Looking at port TCP 8080 we also discover an Apache Tomcat service that is exposed:

But when trying to access the manager with default credentials, we are not allowed to access this page as we do not have local access to the machine:

Weak SSH passphrase

To brute-force SSH logins, one can make use of many tools like Metasploit (or Patator) and its SSH module as follows:

msf5 > use auxiliary/scanner/ssh/ssh_login

If the SSH configuration allows brute-force without being banned, and if any weak login and password are found vulnerable, we can retrieve a session as follows:

msf5 auxiliary(scanner/ssh/ssh_login) > set USER_FILE /tmp/user.list
USER_FILE => /tmp/user.list
msf5 auxiliary(scanner/ssh/ssh_login) > set PASS_FILE /tmp/passwords.list
...
msf5 auxiliary(scanner/ssh/ssh_login) > run
[+] 192.168.3.1:22 - Success: 'user:tiger' ''
[*] Command shell session 1 opened (192.168.42.131:32801 -> 192.168.3.1:22)
at 2019-12-27 14:28:45 +0100
...
msf5 auxiliary(scanner/ssh/ssh_login) > sessions -l
Active sessions
===============
Id Name Type Information Connection
-- ---- ---- ----------- ----------
1 shell unknown SSH user:tiger (192.168.3.1:22) 192.168.42.131:32801 ->
192.168.3.1:22 (192.168.3.1)
...
msf5 auxiliary(server/socks5) > sessions -i 3
[*] Starting interaction with 3...
uname -a
Linux devtest 5.0.0-37-generic #40~18.04.1-Ubuntu SMP Thu Nov 14
[...]

Default passwords

In certain cases, web management interfaces can run with default, or weak credentials allowing an attacker to access these interfaces.

Default and most used passwords can be found in many accessible resources, including software documentation but also public databases. But it happens that some GitHub repositories also store sensitive information such as passwords by mistake.

Command injections

Web managers may contain features, or plugins, that execute commands on the system or may allow installing plugins.

As a result, it is possible to execute arbitrary commands on targeted systems. In addition, those managers are often launched with the root privileges, so the whole targeted system could be compromised directly and then used as a pivot.

Among those web managers, unauthenticated remote command execution vulnerabilities can also be discovered.

Privileges escalation with SUDO

On some servers it is possible to find that compromised users could also escalate their privileges just by calling sudo directly:

****@*****epc:~$ sudo -l
[...]
User user may run the following commands on devtest:
(root) NOPASSWD: ALL

This vulnerability is common on servers that are not directly exposed externally, especially in internal/core networks.

Unprotected private keys

This is a common mistake that could be found on servers, as well as on personal computers, by looking to files containing the following strings:

-----BEGIN RSA PRIVATE KEY-----
MIIEo[STRIPPED]
-----END RSA PRIVATE KEY-----

By using those keys, it is possible to pivot from one server to another and to gain access to other ranges. Although a firewall could be used for preventing unauthorized access from certain IP ranges, the firewall’s restrictions can be circumvented by compromising the intermediate nodes which are allowed to access the restricted machine and reachable from the attacker.

Pivoting

SOCKS tunneling

Having a foot on a machine through SSH, we are able to perform SOCKS connections and perform web pentesting thanks to SOCKS proxy clients like proxychains, tsocks, and many others:

$ proxychains firefox
...
|S-chain|-<>-127.0.0.1:8888-<><>-127.0.0.1:8080-<><>-OK
|S-chain|-<>-127.0.0.1:8888-<><>-127.0.0.1:8080-<><>-OK
<><>-OK
|S-chain|-<>-127.0.0.1:8888-<><>-127.0.0.1:8080-<><>-OK
|S-chain|-<>-127.0.0.1:8888-<><>-127.0.0.1:8080-<><>-OK
...

This allows us to access to the Tomcat manager page we could not access in the beginning for example:

After that, we are able to upload a WAR file and escalate our privileges as the Tomcat service is run with root privileges.

Moreover, we are also able to tunnel Nmap scans, but that technic comes at the price of performance issues.

Conclusion

There has been a lot of security research into exposure with roaming operations via SS7, GTP and Diameter. This post explains how there can be ways to attack mobile networks from the subscriber context when the traffic from user equipment is not isolated in a secure manner. In this post, we talked about possible ways to attack web servers and other assets similarly to any internal mobile network. This allows us to realize how the mobile core network can be similar to any other network with similar issues:

  • lack of isolation;
  • misconfiguration issues;
  • missing software updates leading to RCE;
  • default passwords on exposed services.

Nevertheless, all the attacks could be avoided by strictly following GSMA best practices, especially concerning Virtualized Mobile Networks:

  • Legal and Regulatory Compliance failure: Core risks are about geographic deployment and security of solutions, particularly in heterogeneous environments;
  • Isolation Failure: Core risk is around functions “escaping” from allocated resources, enabling prejudicial data access to extensive areas of information (at rest, in motion or in memory);
  • Denial of Service: Risks include flooding of public interface or resource exhaustion (e.g. on internal network or memory);
  • Topology Validation and Enforcement: Risk is around malicious configuration (e.g. VM layer misconfiguration);
  • Security Logging and Incident Management: Risks arise from failures to log or manage issues from complex interactions across domains.

Implementing these recommendations are at the responsibility of individual operators, and the results may therefore vary.

To go further, the presentation “Taking Over Telecom Networks” at HITB 2018, by Hardik Mehta and Loay Abdelrazek, also illustrates additional vectors and risks from a subscriber context perspective.

Further work on 5G NGC

Compared to the 4G network where everything is structured in nodes with different physical and logical interfaces defined by a stack of several protocols, functions provided by the different nodes in 5G NGC are virtualized in the form of VNF (Virtual Network Functions) functions exposing a RESTfull APIs:

Various methods can be used on REST APIs as it is mostly web. Thus, VNF shares the same types of vulnerabilities than any other web applications exposing a REST API:

  • server DoS;
  • unauthenticated methods and/or actions;
  • logical vulnerability, leading to fraud or data leak;
  • Remote Code Execution through objects serialization/deserialization;
  • etc.

As security researchers, a lot of interesting aspects will come when 5G NGC will be ready.

For those who are interested, a public implementation of the 5G NGC APIs has been released on GitHub. There is also a Swagger that allows us to browse the APIs, like the VAE V2X Message Delivery Service:

Authors

This post is a collaboration of Guillaume Bour (SINTEF), Sébastien Dudek (PentHertz), Shinjo Park (TU Berlin), as well as Marko Buuri, Henri Lindberg, and Tuomo Makkonen (all three from Fraktal, on Medium).

Mobile stacks and networks security

GSM/GPRS, UMTS, LTE, 5G-NR and core network security

Thanks to Marko Buuri

Sébastien Dudek

Written by

Security researcher, and founder of the PentHertz company that focuses on radiocommunications and hardware security.

Mobile stacks and networks security

GSM/GPRS, UMTS, LTE, 5G-NR and core network security

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade