Evaluating VoLTE Security

This blog post discusses the security implications of switching to VoLTE for mobile operators.

Traditionally, the voice traffic elements of mobile telephone networks consisted of very smart core/edge network functions which were accessed by relatively simple end-user terminals (i.e. mobile phones) using a reasonably secure family of protocols designed for circuit-switched mobile networks.  The mobile operators also had very tight guidelines through which they restricted the end user mobile devices that were allowed on their wireless networks. All these characteristics provided a certain degree of security for the end user, the mobile operator and the network as a whole.

volte-hacker.jpg

However, mobile networks began to change drastically when highly programmable and powerful computing devices, such as iPhone and Android phones, were introduced.  Those types of devices offered an opportunity to would-be attackers for exploring potential security gaps in the mobile operators’ networks.  This opportunity has been exacerbated by the switch to more direct IP connectivity from the handsets to the network core, via VoLTE.

Any attacker that can take control of a smartphone can potentially use it to launch attacks towards the operator’s network.  Taking control over the smartphone (or terminal) can be achieved via technical vulnerabilities in the software/firmware of the terminal, but it is usually as simple as having an unsuspecting (or inexperienced) user allowing the attacker in, similarly as an unsuspecting user’s personal computer is infected by a virus or malware.  Attackers can also build their own attack devices using commercially available components.

With this in mind, French consultancy P1 Security recently published a whitepaper of security risks in VoLTE networks.  To summarize, P1 Security claim to have identified several attack vectors, and possibly security gaps, in VoLTE mobile networks, as follows:

  • Mobile terminals (such as smartphones) could be used as the source of a DDOS attack directly aimed at the mobile network.  If a large number of phones can be taken over by the attacker this will form a potent form of botnet.
  • An attacker could discover the phone numbers that are serviced by a particular mobile operator network and use the information for illegal purposes.
  • Attackers could embed arbitrary information in SDP to cause buffer overflows.  This is a special case of more general malformed packet attacks.
  • Attackers could impersonate other users, if authentication procedures are not correctly implemented.
  • The mobile network could be leaking fingerprinting information in messages sent to the attacker, making the topology of the core network easier to deduce, and thereby aiding the attacker with their exploration and exploitation of the network.
  • The terminal equipment identity (IMEI) of a called party could be leaked by the mobile network, and the attacker could use it for nefarious purposes.1
  • Geolocation information of a callee could be leaked by the mobile network to the attacker.

P1 Security is correct that all of the above are possible attack vectors.  So we thought it would be interesting to dive a little deeper into the assessment.  

For the most part, these are attack vectors that have already been addressed by VoLTE standards via the definition of the P-CSCF.2  Those which are not directly addressed by standards are addressed by network-hardened mobile network functions, such as a Session Border Controller (SBC), which often houses the P-CSCF function.

Let’s have a closer look at some of the attacks to focus on each in more detail:

Attack 1: DDOS attack from mobile terminals

Traditionally we think of botnets as being comprised of large numbers of compromised computers.  Not only are modern smartphones pocket-sized computers, they have an always-on direct IP connection to the core telecoms network.  A successful worm might compromise a large number of smartphones without the users even knowing.  They can then be coordinated to launch a wide range of DDOS attacks - including carefully crafted DDOS attacks using SIP registers that require a large amount of processing to handle.

Defense 1: Hardened SBC DDOS handling

This attack highlights the need to protect the telecoms network with an SBC.  These devices are designed to handle DDOS attacks aimed at telecoms networks - discarding the attack traffic efficiently, and blacklisting the devices carrying out the attack.

---

Attack 2: SIP INVITE phone number enumeration

An attacker who has a registered phone on a mobile network can make calls to any number, one at a time.  The response message and/or response code received for each call attempt will let the attacker know whether that specific number is serviced by the operator.  Once the attacker has completed the scan of all the numbers in the attack list, the attacker can move on to using the information for other purposes, such as selling it in the black market or to initiate more severe attacks.

Defense 2: INVITE rate-limiting function

An SBC should be deployed to police a sensible rate of INVITEs per endpoint.  This will ensure that any brute force attempt to gather information in a sensible timeframe will trigger the SBC to identify and blacklist the compromised endpoint.

---

Attack 3: Embed information in SDP 

The attacker can include arbitrary information in SDP without breaking protocol flows.  An example attack using this mechanism is execute a buffer overflow attack on a telecoms target by sending in a large message.  And a carefully-crafted attack might ensure that the payload of the buffer overflow contains executing code that is designed to compromise the target system and gain root access!

Defense 3: Limit the size of SDP

Any attempt to execute a buffer overflow attack would involve sending in very large messages.  The SBC should protect devices in the network from this attack by limiting the size of SDP to a sensible value for valid communications.  

---

Attack 4: Source ID spoofing

The attacker can customize certain SIP header fields (From: and P-Preferred-Identity:) of a SIP INVITE request to impersonate other callers.  This fake information could be received by the callee and trick them into thinking the caller is someone else - e.g. the employee of a bank asking for account details. 

Defense 4: Policing by SBC

The SBC should police the INVITE requests it receives to check their credentials.  It should compare the source IP address to the information in the From: header, and it should check the URIs against those allowed by the S-CSCF at registration time.  In this way the SBC will ensure the integrity of callers trying to initiate calls through it.

---

Attack 5: Topology leak on key SIP headers

Attackers can inspect the SIP messages they receive at the endpoint to see what information is included in the SIP headers.  This information could contain details of the server types and versions of devices in the core network.  The attacker could then use this information to craft attacks that exploit specific vulnerabilities of those devices.

Defense 5: SBC strips out unnecessary headers

The SBC removes non-essential SIP headers as SIP messages traverse core network boundaries.  This means that information defining the topology of the network never reaches the attacker.

---

Attack 6: Leaking IMEI information

RFC 7255 defines the Uniform Resource Name (URN) pattern for GSMA.  This guarantees uniqueness by including the IMEI of the mobile phone user in the ‘+sip.instance’ parameter of the Contact: header.   When the attacker sends an INVITE to initiate a call this information may be included in the responses sent to the attacker, which can be used to build an attack profile for the callee.

Defense 6: Don’t include the information on responses

The network core shouldn’t include this information on responses sent to INVITE requests.   If it does, then the SBC can also be configured to strip this out as the security device at the edge of the network.

---

Attack 7: Geolocation information 

In some IMS implementations the Cell ID of the callee is included in the P-Access-Network-Info header of responses.  This Cell ID could be used by the attacker to narrow down the location of the callee to a specific cell tower.  

Defense 7: SBC strips out unnecessary headers

Same as Defense 5, the SBC removes non-essential SIP headers as SIP responses traverse core network boundaries.

---

So in actuality, the P1 Security paper reinforces the need for a hardened SBC and CSCF to protect against attacks from within the mobile access side of the operator network.  Any operator deploying a P-CSCF implementation that hasn’t been designed with strong security principles in mind from the start could find themselves the victim of a wide range of attacks.  

Metaswitch’s Perimeta SBC is perfectly positioned to help mobile operators deploy a secure network and stymie any of the threats listed. Engineered with an exceptional focus on security, Perimeta has been field proven with more than 400 operators and verified to continue processing calls at rated load whilst been bombarded with line rate of DDOS traffic over a 10Gb link.  

Obviously, providing network security is not a static problem. Beyond the issues raised, Perimeta’s extensible framework for SIP normalization - the Message Manipulation Framework (MMF) can be configured to plug any new network information leaks as they are discovered, all without impacting the industry’s leading virtualized SBC performance.

Click here to learn more about the Perimeta Session Border Controller.

 

1. The IMEI isn’t used for any user authentication within the 3GPP standards, due to the fact it’s not secret. However it has been used by less secure, OTT plays, such as the famous WhatsApp spoofing hack from 2012.

2. The P-CSCF is the SIP function that provides access to the core network.