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.
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