A vulnerability discovered by researchers at UC Berkeley enabled attackers to eavesdrop on and modify calls and text messages sent using T-Mobile’s “Wi-Fi Calling” feature, the researchers told SecurityWeek Tuesday.
According to Jethro Beekman and Christopher Thompson, both UC Berkeley graduate students, when an affected Android device connected to a server via T-Mobile’s Wi-Fi Calling feature, it did not correctly validate the server’s security certificate, exposing calls and text messages to a “man-in-the-middle” (MiTM) attack.
“Without this proper verification, hackers could have created a fake certificate and pretend to be the T-Mobile server,” Beekman and Thompson explained. “This would have allowed attackers to listen to and modify traffic between a phone and the server, letting them intercept and decrypt voice calls and text messages sent over Wi-Fi Calling.”
To discover and implement the attack, the researchers said they reverse-engineered the Wi-Fi Calling feature, which uses a standard voice-over-IP (VoIP) protocol over an encrypted connection.
The easiest way to become a man-in-the-middle is for the attacker to be on the same open wireless network as the target victim, they said. Additionally, the paper noted, if the attacker knows the network parameters, they use an ‘Evil Twin’ attack, which imitates a legitimate network and tricks users into connecting to that rogue network instead, by showing up in the list of available Wi-Fi networks.
To analyze the calling process and execute the MiTM attack, Beekman and Thompson used the setup shown in the diagram below.
[P) Phone. (AP) Access point. (M) Man-in-the-middle. (S) Service provider.]
When first turning on Wi-Fi, the DNS conversation requested a chain of information about wifi.msg.pc.t-mobile.com. Next, the researchers said, a TLS connection was established to the host with the port returned as sba.sipgeo.t-mobile.com:5061, which was the port number assigned by IANA for SIP-TLS.
During their analysis, Beekman and Thompson discovered that the certificate chain returned by T-Mobile’s server used a self-signed root certificate that is not included in standard Certificate Authority distributions, and used the common name of the certificate as simply the IP address of the server.
“This can meant that the root certificate was either built-in to T-Mobile’s client software, or they did not implement certificate validation correctly,” the researchers explained in their paper. “In fact, the client does not seem to have any problems with sslsniff intercepting the connection, making us conclude the latter. Analysis of the binaries confirmed that there was no trace of the root certificate.”
The client identifies itself using its phone number, IMEI and IMSI. Further messages followed normal SIP (Session Initiation Protocol) behavior, the researchers explained.
Using the decrypted SIP dialog, an attacker could record all incoming and outgoing calls and text messages, they said.
“[An attacker] could record, block and reroute SIP traffic. The attacker could change it by faking a sender or changing the real-time voice data or message content. He could fake incoming traffic and he can impersonate the client with forged outgoing traffic,” the report said.
“We verified the ability to record outgoing calls and incoming and outgoing text messages. We also verified the ability to change the destination phone number on outgoing calls by modifying sslsniff to change all occurrences of , replacing a single target phone number by a different one.”
After exploring the source code of the (open source) Android IMS stack, Beekman and Thompson said they found two vulnerable components: TlsSocketFactory, which creates a TLS socket and assigns the TestTrustManager to check the validity of certificates.
“The simplest fix we suggested was to simply include the public-key of their certificate in the app and use it to verify the certificate chain of the remote endpoint,” Thompson told SecurityWeek.
According to their report, not all versions of T-Mobile Wi-Fi calling are vulnerable. The researchers noted that according to T-Mobile’s website, the IMS stack is used on the Samsung Galaxy S II, HTC Amaze 4G, myTouch and myTouch Q. The attack was tested the attack on a Samsung Galaxy S Relay 4G and a Samsung Galaxy Note 2, with other modern T-Mobile Samsung Galaxy devices also likely vulnerable. Individuals using T-Mobile Wi-Fi calling for Business may not be vulnerable, as it uses GAN, not IMS technology, the researchers noted.
Beekman and Thompson said they notified T-Mobile of their discoveries in December 2012, and worked with the mobile operator to confirm and fix the problem. As of March 18, all affected T-Mobile customers have received the security update fixing the vulnerability, the researchers said.
This is not the first time TLS/SSL issues have come to the forefront of mobile devices or applications.
Last October, researchers from two universities in Germany published a paper that exposed the state of SSL within Android applications, which revealed that many applications failed to properly implement SSL, leaving millions of users exposed to basic Man-In-The-Middle attacks.
Based on their analysis (PDF) of roughly 13,500 of the most popular free applications on Google Play at the time, eight percent (1,074) contained vulnerable SSL implementations when static testing was performed; with additional issues discovered after manual testing was performed on 100 of them. Additionally, 41 of the manually tested applications collected a substantial amount of personal information, with each one of them vulnerable to a MITM attack that would harvest said data.
“Man-in-the-middle attacks would not be as threatening if not for the proliferation of wireless technologies such as Wireless LAN (802.11)—exactly the technology that Wi-Fi calling advertises in its name,” Beekman and Thompson explained. “In wireless networks, an attacker no longer needs physical access to invade a network. If an attacker can connect to the network they can try ARP spoofing.”
The full technical report by Beekman and Thompson covering the vulnerability and their man-in-the-middle attack is available here.
