The Site Is HTTPS, so I’m Safe, Right?
You might assume you don’t need to worry about man-in-the-middle (MITM) attacks, but what about phone apps or embedded websites?
What is a man-in-the-middle attack?
Public internet connections are inherently unsafe because of the risk of a MITM attack. I’m not saying that you should never use public wifi connections. Still, next time you are at Starbucks or the airport, you should be extra careful to take precautions like VPNs and avoid visiting websites that might expose sensitive personal information. If you regularly travel, consider investing in a portable wifi hotspot.
How does the MITM attack work?
- The attacker performs an ARP poisoning (e.g., ARP spoofing) attack, which maps the wifi router’s IP address to the mac address of the attacker’s machine. Now the traffic of unsuspecting users will be sent to the attacker instead. This attack is straightforward to execute if the attacker is also connected to the same wifi router.
- A user requests a web server but unknowingly is communicating with the attacker’s machine. The attacker can read the request headers and unencrypted requests.
- The attacker forwards the user’s request to the web server. The web server is unaware an attack is taking place.
- The web server processes the user’s request. Again, the attacker can read the response headers and unencrypted traffic.
- The attacker forwards the response from the web server to the user. The web page will load normally for the user as if the attacker did not exist.
At this point, an attacker has successfully inserted themselves in between you and the web server. The most often recommended solution mitigation to the risk of MITM is to avoid websites that don’t use TLS (e.g., websites that don’t use HTTPS). But when you load an HTTPS website, a series of web requests are made to load HTML, CSS JavaScript, images, and other assets, but those are not guaranteed to be HTTPS.
Fortunately, for most modern browsers, including Google Chrome, we don’t need to worry about this since release 81. After this change in 2020, if you visit an HTTPS website, Chrome will automatically upgrade HTTP requests to HTTPS and block them if the upgrade fails. This setting is configurable for each website since some websites might not support automatic upgrading traffic to HTTPS.
Take a look at this example website. Try loading with and without the insecure content setting enabled (if you are on a secure connection, of course). The URL is here:
If you open Chrome dev tools and navigate to the network panel, you can see nine additional requests for content after the initial HTTPS request, and three of those requests (highlighted in red) are not secure.
These are called mixed content websites since loading the entire webpage requires making both HTTP and HTTPS requests. Fortunately, most browsers already prevent loading behind-the-scenes HTTP content.
If these requests weren’t blocked and left unencrypted, your data could be at serious risk because the lack of encryption leaves you vulnerable to a MITM attack. We’ve discussed how a MITM attack works, but what can an attacker do after they nefariously place their system “in the middle”? Here are a couple of exploits:
- Data exposure: the attacker can view unencrypted content, which might contain private information. Even if it does not contain personal information, the nature of the data could expose the user to unwanted scrutiny about their private lives and, in some regimes, be used to censor or limit civil liberties. For example, passive contents like images are not always requested with HTTPS. Still, if the attacker intercepts images from religious, dating, or pornographic websites, then they can learn personal information used to victimize the user.
- Code injection: the attacker replaces benign web content with malicious content. In the example above, since the
simple-example.jswas unencrypted, the attacker could replace the code with arbitrary JavaScript. Injecting malicious JavaScript could be used to exploit other system vulnerabilities, such as simply extracting data or compromising the user’s browser and potentially their entire system.
The Top 4 Most Popular Browsers Are Secure!
Today, Chrome, Safari, Edge, and Firefox, on the most recent versions, are secure against man-in-the-middle attacks when visiting websites secured by HTTPS because they prevent the mixed content MITM exploit described above.
However, if you are in the 8% that use Samsung Internet, Opera, or UC Browser, then I’m sorry — you’ll need to verify for yourselves. The main risk is in the long-tail of browsers categorized below as “Other.” Because they have much lower investment and scrutiny, I wouldn’t assume they have adopted recent security features like this.
For example, the UC Browser downloads JavaScript and runs it immediately without warning if you visit the same active mixed content URL from above. The full title of the app is UC Browser-Safe, Fast, Private. It’s not safe and not private if there is an attacker in your network. The UC Browser accounts for almost 1% of browsers globally and about 12% of users in China.
Are Android and iOS Applications Secure?
Not necessarily! You might not be as secure as you think, whether you pass the time, thumb jamming to some flappy bird or tower defense game, or browsing mind-numbing social media apps. Communication from your iOS or Android applications to their app’s web server is not guaranteed to be secured by TLS.
Both Apple and Google strongly encourage developers to implement security best practices, but they allow developers to opt out of guaranteed HTTPS security. Unlike your Chrome browser in the example above, these settings are controlled by the developers, not the user.
Both Apple and Google allow the developer to configure the application to communicate unencrypted and in the clear. iOS refers to this as an “exception,” implying that this might not be allowed perpetually.
The Android security documentation of this configuration:
Indicates whether the app intends to use cleartext network traffic, such as cleartext HTTP. The default value for apps that target API level 27 or lower is
"true". Apps that target API level 28 or higher default to"false".
Here is a similar article documenting the process for iOS.
Let’s Find an Example on Android!
Inspecting network traffic on Android isn’t as straightforward as Chrome tools on a desktop client. I can’t merely open the network tab in Chrome developer tools to inspect traffic. It requires significant effort to set up, so I won’t go into detail here. Leave a comment if you would be interested in an article on the topic.
First, I downloaded and set up the Burp Suite security testing toolkit by PortSwigger, which has a free commercial edition with slightly limited capabilities. I connected an Android device to my MacBookPro with a USB cable and configured an HTTPS proxy. You can follow this tutorial on proxying Android application traffic for detailed setup instructions.
Essentially, I’m performing a MITM attack on my android phone except by using a USB cable instead of ARP spoofing like in the earlier example.
Without any prior research, I searched for and downloaded several unpopular news apps from the Google Play Store. After three attempts, I got a hit. The application “Russia News | Russia & World News Headlines” almost exclusively communicates over HTTP. Check out the traffic below:
Note that there were no security warnings when downloading or loading content within the application. An attacker running a MITM attack on my network would be capable of intercepting, reading, and modifying any of these requests.
What Can One Do?
Great, apps are not necessarily secure. Excellent, it’s not clear which applications are safe and which ones aren’t. You shouldn’t be expected to perform an in-depth security analysis before putting an app into your regular scrolling rotation. There are two things you should be doing:
- Only use trusted networks. Should you connect to the wifi at your local dive bar? Maybe not. If you need internet on your laptop while traveling, use your phone as a hotspot, or buy a portable wifi hotspot.
- Download a trusted VPN and leave it on… always. ExpressVPN, NordVPN, etc. There are many options. Do some research and pick one that is best for you.
- Avoid in-app browsers. Besides security, if you value your privacy, then you should be avoiding them anyway. See “This site exposes the creepy things in-app browsers from TikTok and Instagram might track.”
Wrap Up
I hope this article somewhat demystifies MITM as an attack, where the attack surface lies, and how you can protect yourself. You might have found it surprising that android and iOS applications are not as secure as browsing in your web browser. I’m looking forward to future security improvements for Android and iOS.
I suspect they are working to eliminate these vulnerabilities and protect users by requiring that all application traffic be HTTPS. However, this might take time since applications often call out third-party services that may not support HTTPS. Until then, use VPNs and stay safe.
And let me know if I missed anything. I guarantee I did.
