Man in the middle is easier than you think
I’m often heard saying it’s quite easy to MITM HTTPS (also called SSL/TLS) and decided that maybe I should list all the methods I know of (there are quite a few).
The attacker has many options to try and get in the middle between the user and web server/API
Pure Technical Approaches
The pure technical approaches rely on attacks that don’t require users to make any mistakes and anyone can be vulnerable.
Zero Day Vulnerabilities in browsers
Your web browser is pretty secure, but it’s not perfect there is a continous stream of exploits, known as Zero Day vulnerability being found in browsers. They are called Zero day as the hackers find them before the vendor and the vendor has 0 days to fix them. Take for example the annual pwn2own competition where every year for the last few years security researchers have managed to break all of the major browsers. The browser vendors have definitely made their browsers more secure - but each year they get hacked, fix the hacks but more hacks are found.
The root issue here is software is complicated. As an example Fieox has 14 million lines of code and Chrome has 14.9 million lines. At that volume no one human can understand it all and it gets incredibly hard to ensure there are no weaknesses in it. There are tools that try and solve this but none of them can catch all bugs - as it’s quite hard to define what a bug is, until you see it! There are some approaches using machine learning (also called AI) that may help - but I suspect for the foreseeable future we’ll continue to have 0 day flaws found in browsers at regular intervals.
Zero Days are very relevant for breaking HTTPS as typically once a zero day is found it will be used (often via advertising banners) to install malware on the consumers computer. The malware will do a range of things including breaking HTTPS and logging keystrokes.
TLS/SSL Breaks
TLS/SSL are the cryptographic foundation of security on the internet, however they are definitely not flawless. In the last few years we’ve seen discovered techniques to break them, exploiting flaws in both designs and implementations.
TODO ADD PICTURE HERE
Over the last few years there have been several breaches (all with odd names) on TLS/SSL including
- August 2016 Sweet32
- May 2016 Logjam
- March 2016 Drown
- October 2014 Poodle
- April 2014 Heartbleed
If we extrapolate this would suggest we’re going to get a steady stream of such issues over the next few years. Once you have broken the encryption then it becomes possible to MITM the connection. It can be argued that over time TLS will get more and more secure but so far we don’t seem to have got there!
Incorrectly issued ‘trusted’ certificate
TLS/SSL relies on certificate authorities (CA) to work - those are the companies that certify that when you connect to ‘www.mybank.com’ that you are actually talking to your bank. Each web browser vendor (Microsoft, Apple, Google, Mozilla) have a list of approved certificate authorities they trust by default - and they require them to only issue certificates to legitimate companies. In theory this should mean when you see the green padlock on your browser you know who you are talking to - except this doesn’t work all the time.
The issue is in how the CA verifies the company - there have been repeated issues with legitimate certificate authorities issuing certificates in error to 3rd parties who then impersonate the site. This can happen due to weak verification processes or in some cases it looks delibrate. When this is spotted the CA gets ‘told off’ by the browser vendors but in most cases they are just made to apologise and told not to do it again.
The end result of this is hackers have managed to get certificates that let them MITM legitimate websites and use them for profit. There are a number of upcoming web standards designed to make this stronger (e.g. HSTS) but many sites are not using this yet as it’s hard to configure reliably.
Aquire vendor issued ‘trusted’ certificate
A varient on getting a CA to issue a certificate is to find the private key for a certificate that has been trusted by the user. Most users are not aware of it but many computers have extra certificates installed and trusted by their IT department or 3rd party software. For example if your organization uses Microsoft Active Directory there is a good chance someone has installed a certificate authority for that and your local intranet, another example is Dell who installed for several years such a certificate.
This matters because if that certificates private key is not protected (and unfortunately it often isn’t) and a hacker gets it they can intercept all of your HTTPS traffic.
Social Engineering Approaches
For social engineering approaches we combine technical ‘tricks’ with getting the computer user to do something that makes our lives hacking them easier. It’s surprising easy to convince people to do things that let you hack their computer.
Convince user to install MITM certificate
Many legitimate Wifi hotspots require users to install either software or a certificate to access them. This is especially common in emerging markets (and relatively rare in Europe/North America). The purpose of this is to allow the wifi hotspot owner to inspect all your secure traffic e.g. to prevent misuse. However the same certificate also allows the hotspot owner to MITM all your connections and view any data you see and potentially trigger sites to perform actions as you.
With a ‘legitimate’ Wifi hotspot this probably won’t happen. However there is a device known as a Wifi Pineapple available for $99 that can be used either a security testing tool, or more nefariously, to mimic a legitimate wifi network. The hacker simply has to set up a Wifi pineapple, via it’s easy to use GUI, and you’ll be asked to install a MITM certificate from it, they can then intercept and modify anything you see.
The user has had to do something ‘silly’ for this to happen - namely install the MITM SSL certificate (a simple double click), but it’s generally quite easy to convince people this is legitimate. Relying on consumers IT education being sufficent to not do stuff is a strategy based on ‘hope’, which I’m pretty sure is not going to work!
Convince user to install software
Asking a user to install a MITM certificate is not the only way to ‘break’ HTTPS - another way to achieve this is to ask them to install some software. Typically this software is in the form of a Trojan Horse. For example some wifi hotspots ask you to download a ‘security’ or ‘connection manager’ program. These can be harmless or could also install the tools required to intercept your HTTPS.
Malicious Browser Extensions
Browser extensions have a lot of power - users install them typically from externsion stores and once installed often they can see all the pages you view. This allows them to bypass the protections of HTTPS and gather all the data served on the page.
The main protection against this is the browser vendors who police the extension stores for malicious extensions. However their policing is far from perfect, some malicious extensions do sneak through and they can generally aquire data from consumers for a while before anyone notices.
A varient of this attack is to ‘buy’ an existing popular extension from it’s developer (and remember most are made as hobbies so developers will consider selling for relatively small sums) and then issue an ‘upgrade’ with the malicious code. This allows attackers to quickly distribute their code to many browsers.
Conclusion
So are we all doomed to never having secure websites?
Probably not.
Securing computers from attackers was described by John Oliver as ‘Dancing on the edge of a volcano trying desperately not to fall in’ and to some degrees this is true. Computer systems are now sufficiently complicated there will probably never be a useful and totally secure system again.
However we don’t need totally security - it doesn’t existing in the physical world and we get by just fine. What we need is a assessment of the risks, mitigations and active responses to limit the damage an attacker can do. Techniques are starting to appear to reduce these risks (e.g. shameless plug Cloaked.JS from Irdeto ) which will make it significantly less lucrative for hackers to try this. Combined with a defense in depth approach this can get us to the point where we are controlling the risks and losses to an acceptable level.