Hope of Delivery: Extracting User Locations From Mobile Instant Messengers
September 19, 2023 by Katharina
Did you ever see one of the delivery status notifications in a mobile messenger? For example, WhatsApp uses a double-check to indicate that a message is sent out (one check) and arrived at the destination (second check). This is a handy little notification that shows you whether a message was delivered (or not if there are connectivity issues) and it provides some feedback about an otherwise asynchronous connection. Unfortunately, this little status message leaks important information about your connection! How does that happen? Well, to explain this we have to explain some basics first.
Whenever sending information through the Internet, it takes some time until the packet arrives at the destination. This is due to the fact that, although it travels very fast, information still has to be transmitted. The fastest connection you can get nowadays is a transmission through a fiber cable that operates at the speed of light. The speed of light is approximately 300,000km per second and we can use it as an upper bound. No matter how advanced your Internet connection is, you won’t transmit information faster than that. We can use this speed to translate a transmission time into a distance. Let’s say you send a message and it travels for 0.02s, then it can reach anything within the reach of 6000km when traveling at the speed of light. For comparison, that’s the distance between Bochum and New York. We can make use of this! By measuring how long it takes to receive the delivery status notification, we get an estimate of where the destination of our connection is. Following our Bochum-New York example it would take 0.04s to send the message (one way from Bochum to New York) and receive the delivery status (second way from New York to Bochum). To be fair, 0.04s could be anything in reach of 6000km but still, it’s a starting point!
We made use of this starting point and looked at different messengers, their infrastructures, and attacker models. The good news first: An attacker can’t just use this information and localize any person at any place. But it’s possible to learn where one of your contacts is, just from measuring the status notification. And this becomes possible by just sending a message to the target, which is nothing too conspicuous if it appears to be someone from the contact list: “While making use of this side channel is mostly limited to people who are in each others’ contact lists and have already started a conversation before, it yet comprises an unexpected and privacy-infringing act with very low technical requirements that is equally hard to detect and hard to mitigate for a potential victim.”
Source: [Link to orignal PDF]
Leaky Blinders: Information Leakage in Mobile VPNs
September 07, 2023 by Katharina
“A VPN tunnels traffic through a TCP or UDP connection between the user’s system and a remote network, which allows access to services and devices in the remote network. Optional encryption through IPSec, TLS, or Wireguard provides an additional level of confidentiality.” What does this mean? Instead of directly connecting to the desired service, all traffic goes through the network of the VPN service. Additional encryption protects the content of the connection, and requests reach the destination through the VPN instead of coming directly from the user. This is convenient for accessing services within a network (for example in a company or a university), or for borrowing the whereabouts of the VPN service (instead of using your own).
Now why are we interested in VPNs for mobile traffic? And why is this relevant for the security of the connection? Because most often a VPN is designed to run on a computer but not on a phone. A computer isn’t optimized for mobility, it doesn’t have to prioritize battery usage so strictly. A mobile phone on the other side puts constant effort into preventing battery drain. This is only possible when prioritizing how many resources an application is assigned. Limiting resources means less computational power to perform additional encryption and constant tunneling of traffic, just like a VPN app would do. And because of these limitations (and other characteristics) in mobile phones we have to assume that there is a slight chance that some packets in a mobile VPN leak. Now comes the security part: Leakage is always a problem! Traffic that is supposed to be tunneled and encrypted must not be transmitted outside the tunnel. Especially when users rely on the added security of the VPN.
We investigate this assumption and look at Android VPN apps in different usage scenarios. The bad news is: “Our results indicate that in all combinations of devices, apps, and scenarios, a certain amount of traffic remains unprotected by the tunnel. In some cases, the combination of influencing factors leads to thousands of leaked packets.” However, it does make a difference which app you rely on: “Less reliable VPN apps lead to more downlink traffic, which indicates that incoming traffic is less likely to be protected by the tunnel.”
What can we conclude from these findings? You cannot fully rely on a mobile VPN app, there will be some amount of leakage in any situation. There are more reliable solutions that limit this leakage and, consequently, reduce the information that is shared unintentionally. We can also conclude that we have to learn a lot more about the technical environment of a mobile phone, or about the expectations of users when opting for the additional protection of a VPN app.
Source: [Link to orignal PDF]
5G with Mandatory Full-Rate Integrity Protection (to support)!
July 8, 2020 by David
Good news regarding my favorite topic: 5G devices shall support full-rate integrity protection. As state in my previous blog post, the 3GPP SA plenary meeting took place last week and has decided that “The UE shall support integrity protection of user data at any data rate, up to and including, the highest data rate supported by the UE.” starting release-16 on [1]. This decision is a big step towards more secure 5G networks, as user plane integrity protection is the only valid countermeasure against the aLTEr and IMP4GT attack [1,2].
Still, user plane integrity protection remains optional to use [1]. As the phones must support full-rate integrity protection, the deployment of integrity protection will not run into any legacy problems. Which is great for the operators, but also take them under obligation to enable it. The statement of the GSMA plenary meeting let me hope that providers will enable it despite any performance impairments (“it was unanimously agreed, that support of full-rate UPIP should be mandatory and made available as soon as possible in devices and networks regardless of the potential performance drawbacks.”) [3]
Decision on Mandatory Full-Rate Integrity Protection
June 26, 2020 by David
The plenary meeting of the 3GPP Security Group is held from 30. June to 3. July 2020. In preparation for the meeting, the Deutsche Telekom AG released a discussion paper with the title “Way forward on User Plane Integrity Protection.” [1] In this document, they identified seven observations regarding mandatory full-rate integrity protection, which I will partly comment on in the following. Based on this document, 3GPP will decide on the security of future 5G networks.
First of all, this document is backed by the support of many powerful providers, e.g., AT&T, Telefonica, and Vodafone, but also by import equipment manufacturers, e.g., Broadcom, Huawei, and HiSilicon. The providers’ support shows that they have understood the need for mandatory full-rate integrity protection for 5G. Further, the backing of some network equipment vendors let me hope that full-rate protection is technically feasible.
The document demands mandatory full-rate integrity protection of user plane traffic to the 5G specification (release 16). As observation #1 states: “requirement for a mandatory and full-rate user plane integrity protection Researchers [2] and GSMA [1] documented the need for changes in the 5G specifications to mandate full rate user plane integrity protection to address the known and prevent from potential future attacks and secure 5GS.”
Observation #2 and #3 demand to support of full-rate protection of the network side and the UE. Stated as follows: “Supporting User Plane Integrity Protection is mandatory for the network. Full rate is implicit because there is no speed limit defined. If vendors declared ‘full compliance’ with 3GPP TS 33.501, it shall be supported.” Interestingly, the observation #2 explicitly mention the network side, until I have assumed that the UE side in the main problem of implementing full-rate protection. However, it is equally essential that the network side supports full-rate protection. Observation #3, which demands the UE side to support full-rate protection, reads as follows: “UEs are already now able to use full rate UPIP up to the maximum speed. The requirement for mandating full rate UPIP is technically correct and only needs to be implemented.”
Together with other 3GPP members, the Deutsche Telekom AG has already tried to specify mandatory integrity protection. However, the attempts got reject (3GPP term “noted”) with the argument of performance impairments. Observation #4 comments on this issue “Statements were received that mandating full rate UPIP will consume significant processing power and will therefore deteriorate the potential throughput of the UE. Currently although requested several times, no figure has been provided by vendors on the calculated impact.” I agree with this observation and demand the vendors to discuss the performance impairments openly. Only if we know the issues can we solve the problems and implement full-rate algorithm, e.g., with a more performant algorithm design. Further, the support of other vendors (Broadcom, Huawei, and HiSilicon) shows that it is only a question of implementation and not infeasible. This puts blocking 3GPP vendors in the position of providing figures regarding their performance impairments.
Further interesting is observation #7. To circumvent a discussion of full-rate integrity protection, Qualcomm and Samsung focused on adding security measures for ICMP and DNS to the specification at a meeting in April 2020. Observation #7 comments on this attempt as follows: “However, changes have been agreed on proposals for Security Aspects of DNS and ICMP [8]. These are captured in an informative Annex. It is common understanding that such informative Annexes will hardly lead to implementation and are not relevant for standards compliance.” This demonstrates that those suggestions not lead to any implementation and, therefore, render an ineffective mitigation. Further, the attack remains feasible even if those suggestions are in place, which I will outline in a future blog post.
Conclusion
Again: Adding mandatory full-rate integrity protection is the essential security measure for our future 5G networks! Not specifying it in the next release (16) make our upcoming 5G networks vulnerable to substantial attacks. The members standing behind this document have understood the need, but blocking vendors prevent secure 5G networks. The next SA plenary meeting aims to decide on this issue, and I hope that we can trust our future 5G networks.
5G Release-16 Without Mandatory Full-Rate Integrity Protection?
May 16, 2020 by David
Responsible for adding mandatory full-rate integrity protection to 5G networks is the 3GPP, a consortium that specifies the 5G standard in the form of releases. In particular, release 16, frozen in June, is the last chance to add mandatory integrity protection to the 5G specification. This is because release 16 is the first feature freeze release for the 5G NR Standalone radio layer. Adding security in a later release is an inadequate option, as backward compatibility weakens even newer releases. Thus, if mandatory full rate UP IP is not specified for release 16, we face 5G networks that are prone to sustainable attacks. There is a lot of back and forth on this topic. Integrity protection causes an additional overhead and that is always expensive. Let's have a look at the discussions.
Discussions
- The issue of missing integrity protection is known since March 2018 [1]. Some 3GPP documents even date back to 2006, stating that missing integrity protection can be a security problem [12].
- March 2020: To mitigate the threat of attacks in 5G networks, a large group of providers and some vendors have attempted to mandate integrity protection in the 5G specification [3,4].
- This attempt was postponed due to some vendors’ objection, mainly baseband vendors, e.g., Qualcomm, OPPO, and Samsung [5,6]. They argue that it is challenging to integrate full-rate integrity protection due to the performance requirements and need more technical discussion on a working group level [7].
- May: Another attempt tried to add mandatory full rate integrity protection [8,8a]. Again this was postponed (3GPP term “noted”) by the vendors [9,10,11].
What do we learn from this? Things are never easy! One the one side who would complain about better security? On the other side, who wants to invest additional resources for something that could be exploited through some very advanced attacks? I'm curious what we will end up with.
The importance of integrity protection
May 15, 2020 by David
Integrity protection assures that an attacker cannot mess with packets in transit. While this is a standard feature for control plane data, we don't have the same protection for the user plane in 4G. When we look at attacks like aLTEr or IMP4GT, it becomes clear how severe the consequences of a user data manipulation could be. Let's have a look at both attacks.
DNS Spoofing with aLTEr
When opening a website, a user types a domain name into the browser and then waits for the page to load. What happens in the background is a DNS request, in which the browser asks at which address it can find the requested website. Such requests belong to the user plane and as we all know by now, it doesn't have any integrity protection when it comes to 4G. Because of that, an attacker can pick up the DNS request and manipulate the response. Let's assume we want to log in to a social media platform. But instead of the accurate response, we receive something that was changed by the adversary. The bogus response points to a phishing site that looks legitimate. We enter our login credentials and nothing happens. Maybe bad Internet connection? Don't know, let's try something else... The page didn't load and that's not too much of a problem, right? But the attacker now knows our username and password. That's bad!
Impersonation
The impersonation attack is even worse. Now the attacker goes crazy and brings a lot of equipment including a remote server that does the heavy lifting for all the computations we are going to need. Let's not go into detail with the attack, it's very complicated and would need its own blog. You can always refer to the paper for this! What's important to know: IMP4GT allows an attacker to fully impersonate a legitimate base station, in both directions. This means it's possible to intercept and decrypt packets meant for the victim, and to manipulate and change the packets that are sent towards the network. Although this is not trivial to implement, it shows how far an attacker can get just because the user plane of 4G lacks integrity protection.
Where are the good news?
I guess we all agree that this is not the end of the world, but it's also not an acceptable state for something as important as mobile communication. So the good news is that help might be on its way. With 5G we have the opportunity to improve things and make them better.
