Integrity of HTTPS
Recently there has been a significant push from some of the big names of the web domain such as Google and Firefox to make HTTPS the default. A push for a secure by default scenario is a good thing right? Well there appear to be some out there who disagree.
So Dave is going to UA sniff (I guess) and refuse to serve content to Chrome... Because spending time on that is far more productive than deploying HTTPS I guess 🤦♂️ pic.twitter.com/Jpd7bYtrJ0
— Scott Helme (@Scott_Helme) June 22, 2018
The common trait amongst many of these people is that they seem to think that HTTPS in only important for protecting sensitive information. I have already spoken to this on a previous post. Well this is true, HTTPS is more than this. I have seen the same thinking come about multiple times, so much so that I decided to create a presentation about it. During the course of this year I have given my talk "The Need for HTTPS" on several occasions. The primary focus of this talk is to highlight the need for HTTPS from an integrity perspective. One of the elements of my talk is that I use a WiFi Pineapple to gain a Man-in-The-Middle (MiTM) scenario and connect to a plain HTTP site. I then proceed to inject a BeEF hook to basically take ownership of the victim's browser. In this post I will attempt to show this in practice to highlight why HTTPs is so important, regardless of the fact that there is no sensitive information being sent from the victim or server.
Gaining MiTM
This is the most difficult bit. But there are many tools at an attacker's disposal. One of my favourite mehtods is to setup a rogues wireless Access Point (AP) using a WiFi Pineapple. Let me just say this tool is just awesome! The idea behind it is that I will get victims to connect to a AP which I control with my WiFi Pineapple. I even wrote a tutorial on how to do this and have the victim's web based traffic routed via Burp Suite. Then all traffic to and from the connected victim, is routed via my system (and hence I then have MiTM).
How hard is this? Well as I sit at the airport there are several wireless Access Points available:
If I throw in one called Free High Speed Internet? I'm quite confident people would connect to it. In fact I've in the past setup an AP called Free WiFi and had about 3-4 devices connecting to it within a 5 minute time span.
Besides utilizing the wireless approach, there are other methods such as ARP spoofing or DNS spoofing.
Exploiting HTTP
So you now have the victim's traffic routing through your system, the next bit is to modify the data. Examples could include changing the location of a login link, or even completely changing the text within the returned page (fake news anyone?). Or alternatively one could inject malicious content into the response. Such examples could include a cryptominer or BeEF hook.
Below is a benign example which I created, however it shows the basic principle behind the attack. In the videos I did 2 things:
- Modified the content to change the wording of the page.
- Injected a "malicious" JavaScript which redirects the victim to a "malicious" site.
I broke the illustration into 3 parts, to make it easier to consume as well as illustrate.
Part 1
In this video I show the victim connecting to the rogue AP, and show how it appears no different from any other AP. I then show the victim navigating to the target site. I did not make any alterations since I wanted to show what the original site and text looked like as well as how it behaved.
Part 2
In the second part, I showed how an attacker could manipluate the content of the page to alter the contents displayed back to the user.
Part 3
In this final part I showed how an attacker could inject malicious JavaScript to alter the behaviour of the page to carry out their malicious actions.
Integrity of HTTPS
So how does HTTPS help? If connecting over HTTPS, the server has to present a trusted and valid certificate to the client. This means the certificate needs to be signed by a trusted Certificate Authority (CA) and the certificate needs to be issued for the server (a DNS entry in the Subject Alternative Name field of the cetificate). If the attacker tried the same above the user would be presented with an error page similar to the one below.
Or the one below if they were using a valid CA.
This also illustrates why it is so important to do the appropriate certificate verification checks on the client. In addition why it's so important that CAs are held accountable and ensure that they only issue certificates to valid requests. Using the above MiTM examples, the victim would have been shown an error in their browser, preventing both scenarios from occurring. Namely being able to detect when someone is tampering with the data as well as preventing any malicious behaviour from happening (for example being redirected to a malicious site).