Part 2: How I Owned Your OS Before You Installed It
9 10 11 months – I though I’d free up some time to write part 2 of this story.
This is not fully without reason though…. Reason #1: I’m quite a lazy person. Reason #2: Good – and easy(ish) to use – MitM attacking tools are hard to come by. But more on that later.
Just a quick recap from part 1.
I wrote about how you can backdoor an OS and package it back up into an ISO that (once installed) will grant you access to a cleanly installed system within minutes of booting.
But an ISO file is rather useless if it’s only available on our own machine. Someone needs to start using it. That is why in this post we’ll look into methods of delivering our backdoored ISO file to our target(s).
Methods of delivery
There are a several ways we can deliver our ISO. The most obvious one is by simply swapping a CD/DVD; or replace a file in a directory. This might sound unlikely, but how many companies have you seen where network shares are easily accessable to all employees? And the same counts for places where the CDs are kept (If people still use these…)
An other method would be a ‘man in the middle’ (MitM) attack.
Man in the Middle attack using ARP spoofing
In this post I’ll be focusing on a MitM attack that used ARP spoofing. Mainly because the amount of tools availible to perform this attack is quite significant. And the amount of documentation about it is also widely available.
As Wikipedia explains: “ARP spoofing is a technique whereby an attacker sends fake (“spoofed”) Address Resolution Protocol” to the target.
ARP is used to convert an IP address to a physical address such as an Ethernet address (also known as a MAC address)
During an ARP spoofing attack the attacker aims to associate his/here own MAC address with the IP of an other host. This allows the attacker to intercept any traffic that is send to this IP.
This attack is limited to Local Area Networks (LANs) but can be very effective when performed on a gateway (I.e router).
The ARP spoofing attack is nothing new and has been around for quite a while. Yet, it can still be extremely effective. Only recently @byt3bl33d3r released a MitM framework called MITMf allowing you to easily perform MitM attacks from your command line.
MITMf + HTTP = ?
Now that we have our attack method and the right tool it’s time to start our attack.
As you might remember – or you just read part 1 – from my previous post that I used Linux Mint. The reason I choose Mint is because their website doesn’t use a HTTPS connection when providing download links to their ISO files.
Since HTTP is used – this means the connection is not encrypted – we have the opportunity to modify traffic without our target being aware this is happening.
In our case we want to replace URLs and a checksum (hash) values on the page. To do this we need a plugin for MITMf that allows us to replace data on the page. Luckily I already wrote this module for you. Simply place it in the plugins directory and you should be fine. Or simply do a pull/clone since it’s been merged into MITMf.
There are two things on the page we want to change:
- The download link to the ISO file; We want to change this to a URL so that it points to our backdoored ISO file.
- The MD5 checksum; Because we don’t want our victim to know that they are downloading a modified version of their OS right?
We can do this by running the following command:
1 2 3 4
The content of our replace.regex file is (please note the regexes are seprarated by a tab):
By putting the ISO on a server outside the LAN you’re providing the ISO via WAN download speeds. If you need to host it internally you probably want to look into throtteling the connection to prevent your target form suspecting something fishy.
Once our victim visits the Mint website the following output is generated (trucated for readability):
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
What just happend was that all the URLs that point to a
linuxmint-17-cinnamon-64bit-v2.iso file where rewriten to point to an ISO file on my domain. This will of course result in the user downloading our backdoored ISO file. Additionally the hash provided on the page will match the hash of the ISO the user is downloading.
So how do you defend agains this? Well, the project providing you with the ISO could just spend the $50 to get a SSL cert…..
It is true that you still have mirror servers that are providing you with ISO files that could be backdoored but at least the likelyhood that your checksums are trustworthy is higher.
But, if no HTTPS is availible you (as a user) can always use PGP (Pretty Good Privacy) to verify your ISO.
ISO verification using PGP
Apart from offering you a great way to encrypt your email, PGP surves many purposes. One of them is file verification.
Unfortunately PGP can be quite tricky, and sadly most projects don’t advertise the thorough guide they wrote on their download pages. Instead you have to know about PGP and find the guide (often) yourself.
A good example of one of these PGP guides can be found here.
I was unable to find a similar guide (or even the PGP keys) for Linux Mint. Please let me know if they have one so I can update this post.
One of the most important factors here is that (and I’m pretty sure about this) most people don’t verify their ISO files. It is complicated and for most users probably something they don’t understand.
I still don’t fully understand why some projects don’t run their site via HTTPS. There are probably many reason on why not. But my main concern with the distribution of ISO files over HTTP are:
- The PGP verification process is too complicated – and I’m pretty sure even some IT professionals won’t go through the trouble.
- The provided checksums on the download pages are very misleading and give you a false sense of security when delivered over HTTP.
- The projects assume the users are going to verify their ISO file.
When discussing this on IRC (sorry forgot your handle) the only reason I could understand is that it is possible HTTPS is avoided to minimize the attack surface on the server hosting the ISOs. If you have more insight into other possible reasons please leave a comment or contact me directly via something from the list on the left
It is probably very easy to say the user is to blame here – “The user should know better”. But I believe security should be invisible unless user interaction is required. And if user interaction is required security aspects of your project should be accessable and understandable for all users of all technical levels. I don’t think that is the case with PGP verification.