September 30, 2013

Inside Mobile Internet Security

Introduction
The mobile Internet has truly gone global. An estimated 6.8 billion mobile subscriptions were reported globally at the end of 2012 [1]. That’s the equivalent of 96 percent of the world’s population being connected via a mobile device. And it represents a huge increase on the 6.0 billion subscribers reported just 12 months prior [2].

As cellular networks grow, so do the number and frequency of mobile internet connections; posing a new set of challenges for the IT Security community. While many of us are familiar with the architecture of the regular Internet – twisted pairs, Ethernet, TCP/IP – the architecture behind the mobile Internet is less widely understood, leaving users vulnerable to the actions of hackers with only a slightly better level of knowledge.

In this post, Positive Research, the research division of Positive Technologies, will demystify the mobile internet by explaining its general principles, take a deeper look at the General Packet Radio Service (GPRS) Tunneling Protocol, discuss the GPRS Roaming Exchange (GRX) Network and demonstrate some practical issues that arise when attempting to secure a mobile network.

Getting Connected
Let’s start by considering the standard method used to connect devices to the mobile internet. Typically, you need only three parameters to make a connection: an Access Point Name (APN), a login and a password. An APN is a value used by the device to connect to a particular mobile service. A device will have a separate APN for each service such as Wireless Application Protocol (WAP), Multimedia Messaging Service (MMS) or the mobile Internet. . Typically the APN for mobile Internet services will take the format of internet..com. The login and password are often simple, something like: internet-internet.

Once you have the required parameters, connecting to the mobile packet network is a two-stage process:

  1. GPRS Attach
  2. Packet Data Protocol (PDP) Context Activation

GPRS Attach
In the course of the GPRS Attach procedure the phone initiates communication with the operator's packet network. The following elements are then used to authenticate and authorize the user's mobile device:

  • International Mobile Subscriber Identity (IMSI) to identify the user
  • Keys stored on the SIM card to authenticate the user
  • Subscription data to check availability of services (Internet, MMS, WAP) for that user

Additionally, to prevent fraud, a device’s International Mobile Equipment Identity (IMEI) may be checked against a list of stolen devices. If an IMEI matches that of a stolen device then it may be blocked from accessing the network or even reported to authorities.

PDP Context Activation
After successfully negotiating the GPRS Attach procedure, the PDP Context Activation begins. To better understand this procedure, it helps to first clarify the relevant terms:

  • A Serving GPRS Support Node (SGSN) is responsible for authentication and general packet data handling in the mobile network
  • A Gateway GPRS Support Node (GGSN) is responsible for data transfer between the operator's network and external networks (e.g. Internet). It may be a common router with some specific functionality
  • GPRS Tunneling Protocol (GTP) is a stack of protocols used in GPRS, Universal Mobile Telecommunications System (UMTS) and Long Term Evolution (LTE) – an industry standard for wireless communication of high-speed data networks.

The following diagram is a highly simplified representation of the PDP Context Activation process. Further explanation of each step is provided below.

Figure 1 – PDP Context Activation

PDP Context Activation explained:

  1. The phone sends the SGSN an Activate PDP Context request, which (amongst other information) contains the login, password, and APN.
  2. After receiving the APN, the SGSN tries to resolve it on the internal DNS server. The server resolves the received APN and provides a corresponding GGSN address.
  3. The SGSN sends the Create PDP Context request to this GGSN address.
  4. The GGSN authenticates the submitted login and password on the RADIUS server.
  5. The GGSN requests and obtains an IP address for the mobile phone.
  6. The GGSN transmits all data required for PDP context activation back to the SGSN.
  7. The SGSN accomplishes the activation procedure by sending back to the phone all the data required for establishing a connection.

In essence, the PDP Context Activation procedure is the creation of a tunnel between a cell phone and a gateway (GGSN) on the operator’s mobile network. Through this tunnel a user can browse their favorite web sites and check email.

Roaming
The next question that inevitably arises is: How does all this work in a roaming scenario – when a user is away from their home network? There is a special network, the GPRS Roaming Exchange (GRX) which provides packet data exchange for mobile operators worldwide. Something like this:
Figure 2 – Internet connection on another operator’s network

  1. While away from their home country (or using another operator’s network within their own country), a user decides to download a favorite TV show. The user switches on their cell phone and tries to connect to the Internet (sending the login, password and APN).
  2. The overseas SGSN tries to resolve the APN on its own DNS server.
  3. If the DNS server finds no corresponding record, it refers to the root DNS server in the GRX network.
  4. The root DNS server sends a request to the DNS server of the user’s native mobile network operator.
  5. The DNS server responds by providing the address of the user’s GGSN.
  6. The root DNS server forwards this address to the DNS server of the overseas operator.
  7. The overseas operator forwards the address to the overseas SGSN.
  8. The SGSN, knowing the address of GGSN, sends the PDP Context Activation request to it.
  9. If all requirements are satisfied (i.e. the user’s balance is positive, the login and password are verified, etc.), the GGSN sends a response to SGSN which accepts it and forwards to the cell phone confirmation of Internet access.

At this point, the packets of the TV show pass from the home operator to the overseas one. The transfer is done via a special network wrapped into the GTP protocol. All negotiations between the dedicated hardware systems of the two operators are performed via the same GTP.

Lab-based SGSN and GGSN

While a description of the mobile Internet connection process such as the one provided above is informative, Positive Research believes practical investigation is the best way to fully understand the security implications of any system. It was with this hands-on approach in mind that we embarked on a laboratory simulation of the entire mobile Internet ecosystem, configuring our own SGSN and GGSN. In this way we were able to thoroughly investigate the user authentication process and the way data is transferred between the operator and the user’s mobile device. This simulated environment allowed us to test and practically demonstrate the ways in which a hacker might target the various elements within the mobile Internet ecosystem to disrupt or interrupt data traffic.


Figure 3 – The planning process for our lab-based SGSN and GGSN

First, we used a form of Linux script to emulate SGSN functions including GPRS Attach and PDP Context Activation and to provide an interface ready for accessing the Internet - just as if a 3G modem had been connected. To provide the required GGSN functions we used an off-the-shelf Cisco 7200 Series Router.

Once the test equipment was configured, our experts from Positive Research were able to successfully establish simulated communications between the SGSN and GGSN and they were even able to tunnel out to a live mobile internet connection, as illustrated in the following diagram:

Figure 4 – Mobile Internet connection via lab-based SGSN and GGSN

Upon examination of the packets being transferred between our test SGSN and GGSN we found they looked the same as those passed between real-world mobile operator networks. Similar packets may also be transferred across GRX networks, where a malicious hacker can sniff them, as shown in figure 5 below. Now that we could monitor traffic flow, our specialists at Positive Research set out to demonstrate what a hacker might be able to glean from these packets.

Figure 5 – GRX networks provide potential entry point for hackers


Security Implications of GTP

There are several types of GPRS Tunneling Protocol (GTP):

  • GTP-U used for packaging and carrying user data
  • GTP-C used for session management (i.e. for executing PDP Context Activation and other service procedures)
  • GTP' (GTP Prime) used for carrying billing data

GTP does not support peer authentication and encryption, it operates on top of the UDP data transfer protocol. Its mode of operation has important security implications.

The screen shot in Figure 6 below depicts GTP-U and user data tunneling. Tunnels are identified by their Tunnel Endpoint ID (TEID).


Figure 6 – Screen Shot of depicts GTP-U and user data tunneling

Our researchers demonstrated that the TEID field can be spoofed, allowing a malicious hacker to break into a user’s session by sending a packet with a fake tunnel ID.

In the case of GTP-C we also found there is no authentication, nor any sign of encryption of the transmitted data. This means a hacker could not only sniff the data that is being legitimately sent but could also inject data of their own. For example, they could send a fraudulent request to connect or terminate a session.

Possible Attack Vectors - Theory
Based on the results experienced in the lab, Positive Research has defined the following likely attack vectors.

1. DNS Flood Attack

In a DNS Flood Attack, the attacker sends a large number of requests for resolving the operator's APN. All these packets will flood or overload the operator's DNS servers, which will eventually give up and refuse to provide the GGSN address. This will result in a denial of service (DoS) for all of the operator’s mobile users.
Figure 7 – A DNS Flood Attack

2. GTP Flood Attack

In a GTP Flood Attack, the hacker may send a large number of bogus Create PDP Context requests. Under this avalanche of requests, the GGSN may freeze or even hang resulting in yet another form of denial of service for all of the operator’s mobile users.
Figure 8 – A GTP Flood Attack

3. PDP Context Delete

What would happen if the hacker sent a malicious request to terminate a session and not to establish one? Figure 9 below illustrates how a hacker could request to terminate a session using the address of a foreign SGSN. The GGSN decides that a user has finished downloading his TV show and wants to terminate the Internet session. It then deletes the tunnel and terminates the connection. This results in another form of Denial of Service because the user is unable to continue browsing the mobile Internet.

Figure 9 – PDP Context Delete

Real-World GGSN Security Weaknesses Revealed

As we have shown above, mobile operators must provide adequate security measures to protect their GGSNs from hackers if they are to prevent a variety of attacks that will result in denial of service.

However, Positive Research was able to demonstrate that many operators are failing in this regard. Using the basic steps outlined below, our team of mobile experts were able to find listings for many GGSNs on the open Internet; demonstrating that they were not adequately firewalled.

Using the computer search engine SHODAN, our researchers searched for GGSN, obtaining the following results:

Figure 10 – SHODAN search results

Our tests confirmed that these are, in fact, real mobile operators’ GGSNs accessible from the Internet. In keeping with our commitment to ethical hacking, we did not conduct any tests that could have caused harm to any of these systems.

As an alternative approach in our search for real-world GGSNs, we wrote a script sending GTP-echo requests to the Internet and waited for a response. Some responses were received:


And some of those were enabled with Telnet:


The speed with which we were able to access these GGSNs demonstrates that the companies operating them are highly vulnerable to attack and should take added precautions to protect the integrity of their infrastructure...

Conclusion
It is worth noting that a new generation standard with the LTE code name still uses GTP, which is why this particular attack vector is applicable not only today but for the foreseeable future.

This paper has set out the basics of mobile Internet security and has demonstrated how simple it is for a hacker to access private data or cause disruption to the activities of mobile operators. Naturally, the attack vectors demonstrated in this research are of crucial importance to mobile operators who must take steps to protect themselves from the kind of DoS attacks we have illustrated here. The implications for data protection are also clear for all users of the mobile Internet, but in particular to companies who allow their staff to manage sensitive corporate information via mobile devices.

Sources:
1. “ICT Facts and Figures 2013” published by The International Telecommunication Union - http://www.itu.int/en/ITU-D/Statistics/Documents/facts/ICTFactsFigures2013.pdf
2. For more statistics on mobile internet usage see http://mobithinking.com/mobile-marketing-tools/latest-mobile-stats/a#subscribers

Glossary of Terms

APN – Access point Name
DNS – Domain Name System
GGSN – Gateway GPRS Support Node
GPRS – General Packet Radio Service
GTP – GPRS Tunneling Protocol
GTP-U – Protocol for packaging and carrying User Data
GTP-C – Protocol for session management
GTP’ – GTP Prime – Protocol for carrying billing Data
GRX – GPRS Roaming Exchange
IMEI – International Mobile Equipment Identity
IMSI – International Mobile Subscriber Identity
LTE – Long Term Evolution
MMS – Multimedia Messaging Service
PDP – Packet Data Protocol
RADIUS Server - Remote Access Dial In User Service
SGSN – Serving GPRS Support Node
TEID – Tunnel Endpoint ID
UDP – User Datagram Protocol
UMTS – Universal Mobile Telecommunications System
WAP - Wireless Application Protocol

Author: Ilya Safronov, Positive Research.

6 comments:

  1. This comment has been removed by a blog administrator.

    ReplyDelete
  2. This comment has been removed by a blog administrator.

    ReplyDelete
  3. This comment has been removed by a blog administrator.

    ReplyDelete
  4. This comment has been removed by a blog administrator.

    ReplyDelete
  5. This comment has been removed by a blog administrator.

    ReplyDelete
  6. This comment has been removed by a blog administrator.

    ReplyDelete