Introduction to mobile network intrusions from a mobile phone

Sébastien Dudek
Feb 4, 2020 · 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:

By performing a traceroute we can retrieve the subnets above:

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:

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:

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

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:

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:

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

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

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

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:

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:

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:

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:

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:

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:

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:

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:

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

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store