VoLTE Security Analysis, part 2

In our talk IMSEcure – Attacking VoLTE Brian and me presented some theoretical and practical attacks against IP Multimedia Subsystems (IMS). Some of the attacks already have been introduced in a former blogpost and Ahmad continued with a deeper analysis of the Flooding and targeted DoS scenario. But still, there are some open topics I’d like to continue with now. The methods I am demonstrating here also help to get a better understanding of VoLTE/IMS and how it is implemented on modern smartphones.

Eavesdropping
Performing eavesdropping can have multiple reasons: this could be due to bad reasons but also if you want to understand a technology in more detail. In general, classic eavesdropping of VoLTE communication is not easy. Taking a look to the network communication we have to split it up between the interfaces the voice data is transmitted to the IMS. This results in

• the logical IMS interface (Gm) – which represents the IP-Layer
• the radio interface (LTE) between UE and antenna
• the transport interface (S1-U) from antenna to the IMS

The security architecture of the logical connection (Gm) heavily depends on the configuration of the UE (what is supported by the phone?) and the IMS (what is offered to the phone?). In reference to the specifications, the support of confidentiality protection is required, but it must not be used. This applies as well to the signaling traffic (defined in 3GPP TS 133.203) as to the media traffic (defined in 3GPP TS 133.328). For the whole architecture this does not mean that no encryption is in place at all because the LTE radio layer should be encrypted by using AES or Snow3G anyhow. We can assume that at least the radio communication will use encryption – leading into the fact that “passive sniffing” on radio layer will not be easy.
Another important interface is the transport interface from the antenna (in 4G known as eNodeB) to the core network called S1. Some theoretical attacks we already have shown in our previous talk LTE vs. Darwin we don’t want to focus on here. In summary, the security of this interface is based on IPSec; if IPSec is enabled eavesdropping will not be possible. If IPSec is disabled, it will be possible.

Anyhow, doing eavesdropping on network/transport layer heavily depends on the configuration of the provider. Another option is to do eavesdropping locally on the phone. Remember, VoLTE is based on normal IP communication which is much easier to access than GSM communication. In the rest of the blogpost, I’d like to demonstrate how this is working. The proceeding is also very useful for pentesters to analyze the VoLTE communication and it’s configuration, as we have done in our talk.
But keep in mind, in theory this method can also be by mobile malware/malicious apps.

For our test we need:

1. A SIM supporting VoLTE (not all contracts and SIM are)
2. A Rooted Android phone supporting VoLTE
3. Android-Tools installed on your laptop

After starting the phone, the VoLTE interface must be identified. To do so, connect your rooted Android phone to your laptop and start a terminal in via adb shell. The big advantage of LTE is, that common IP communication is used and that there is a dedicated interface available we can see on the phone. You can list available interfaces via the command ip addr. Your output will be something like this:

There are two interfaces for LTE radio, called rmnet0 and rmnet1. One will be for normal data traffic, the other one for VoLTE. Having tcpdump installed, you now can take a capture on the interface itself and access the voice traffic. More comfortable is to forward the traffic via Wifi/USB to your laptop and see directly in wireshark:

adb shell tcpdump -i rmnet1 -n -s 0 -w - | nc -l 127.0.0.1 -p 11233
adb forward tcp:11233 tcp:11233 && nc 127.0.0.1 11233 | wireshark -k -S -i -

Another possibility to access the traffic is rerouting, you simply can do this via iptables. This can also be used for MitM tests by forwarding to attack proxys (e.g. burp) or modify the requests manually. To make iptables MitM more easy, we created a little shell script which must be executed on the Android phone:

##IPTABLES SCRIPT FOR ANDROID TO ROUTE TRAFFIC TO LAPTOP AND BACK
iptables -F
iptables -t nat -F

IMS="10.0.0.1" #IP Address of the IMS
MITM="192.168.0.2" #IP Address of the Laptop to be used for MitM

echo 1 > /proc/sys/net/ipv4/ip_forward
RMNET=`ip addr show dev rmnet1 | grep -oE "([0-9]{1,3}\.){3}[0-9]{1,3}"`
WLAN=`ip addr show dev wlan0 | grep inet | grep -oE "([0-9]{1,3}\.){3}[0-9]{1,3}" | grep -v 255`

iptables -t nat -A OUTPUT -d $IMS -j DNAT --to-destination $MITM
iptables -t nat -A POSTROUTING -o wlan0 -d $MITM -j SNAT --to-source $WLAN
iptables -t nat -A POSTROUTING -o rmnet1 -s $MITM -d $IMS -j SNAT --to-source $RMNET
iptables -t nat -L -vn

Information Disclosure
Having access to the traffic you can start with a first analysis. This for instance can be information disclosures like demonstrated in our talk. This includes

• Vendor Names of IMS
• Version Information of IMS
• Internal IP Addresses
• Customer Information
• Location Data (we are using mobile phones, right?)

Some of the information disclosures are similar to the ones you see in normal web applications. The vendor names and version numbers could help an attacker to abuse known vulnerabilities; but talking about mobile communication, the IP address of other participants could be more interesting due to privacy reasons. Such addresses can also be abused to perform side-channel attacks as already demonstrated.

But in our talk we described some more attacks, such as Injection and Impersonation/Identity Spoofing. For obvious reasons, we will not show in detail how this is working but I’d like to point out that this is a real danger the provider must be aware of. Most of the providers think that they are safe because they are using IPSec but that’s not true! We should keep in mind: the attacker is coming from the mobile phone itself – which is, and always will be, an untrusted device. More on this later 🙂

Best,
Hendrik