Slashdot Mirror
Hackers Can Spoof Phone Numbers, Track Users Via 4G VoLTE Mobile Technology (bleepingcomputer.com)
An anonymous reader writes: "A team of researchers from French company P1 Security has detailed a long list of issues with the 4G VoLTE telephony, a protocol that has become quite popular all over the world in recent years and is currently in use in the US, Asia, and most European countries," reports Bleeping Computer. Researchers say they identified several flaws in the VoLTE protocol (a mixture of LTE and VoIP) that allow an attacker to spoof anyone's phone number and place phone calls under new identities, and extract IMSI and geo-location data from pre-call message exchanges. These issues can be exploited by both altering some VoLTE packets and actively interacting with targets, but also by passively listening to VoLTE traffic on an Android device. Some of these flaws don't even need a full call/connection to be established between the victim and the target for the data harvesting operation to take place. Additionally, another flaw allows users to make calls and use mobile data without being billed. The team's research paper, entitled "Subscribers remote geolocation and tracking using 4G VoLTE enabled Android phone" was presented last week at SSTIC (Symposium sur la Securite des Technologies de l'Information et des Communications), a security conference held each year in Rennes, France.
In the US you can just walk into a store and get a SIM without "registering". You mean in the EU you have to register it with a national ID? How backward!
LTE uses Diameter, but most SS7 attacks are also viable since they underlying messages and commands have identical functions (they have to, otherwise you can't interact with large parts of the telephone network).
This paper describes something else. When you do a call over VoLTE you normally get a dedicated bearer (sort of like a VLAN over LTE) assigned to you to guarantee QoS. On many android phones (same holds for USB LTE modems) this interface becomes visible as a virtual IP based network interface. The VoLTE stack will then setup IPSec on this interface if requested by the network, and finally initiate a SIP/RTP session through it for handling the actual call. They say that a use with root access can run for example run tcpdump on this inferface and eavesdrop on the call. This in itself is not surprising and cause for concern, with root access to the phone you can record directly from the microhpone after all.
More surprising is that they tested some of the SIP servers and that they were poorly secured, being vulnerable to well known SIP attacks: user enumeration, source spoofing and data tunneling (clever...). They also discovered a lot of data leakage in optional headers and protocol ids, including the IMEI and serving cell of the remote party.
I have heard, but have no direct information, that many of these IP bearer based services are almost directly connected to the operators IP core network (firewalling is not supported by many access network components, you would need to add it externally), and thus that traditional software exploitation may work.
so basically VoLTE spec don't see the point in protecting the SIP call correctly and allow anyone on their network to place SIP calls
"Depending on the network operator’s architecture, IPsec tunnels between the UE and the IMS core network will be set up. In this case, we
need to inject data directly into this existing IPsec tunnel, typically, when we want to test active vulnerabilities and replay traffic. The easiest way
to achieve this is to reuse an existing socket used by a legitimate IMS service on Android. Reusing this socket will permit to inject traffic inside
the IPsec tunnel, as the association already was established by the Linux Kernel IPsec stack (Netkey)."
At least they use IPSec but honestly they do not check the keys... deploying all the keys is going to be a major headache, and you have to trust a CA not to screw up...
The solution is to deploy your keys using DANE and DNSsec, most operators are using IPv6 and DNSsec so its not much of a deployment stretch
they also complain that the " utran-cell-id-3gpp value of UE-victim received in SIP 183 Session Progress response" honestly yes if you secured the tunnel then it would not matter
So in conclusion what they are saying is they can do MITM attacks because the operator does not authenticate correctly the IPsec tunnel and trusts all data sent...
the old Russian Proverb "trust but verify" no problem with the SIP just the verification plus tunnel and keys...
I wonder how much money consulting these guys make for setting up a MITM attack... good luck to them
regards
John Jones