Check Your Image
ADVISORY: The techniques and tools referenced within this blog post may be outdated and do not apply to current situations. However, there is still potential for this blog entry to be used as an opportunity to learn and to possibly update or integrate into modern tools and techniques.
Today I’ll walk through the process I use to verify ISO images before I install them.
If you downloaded Linux Mint 17.3 Cinnamon on February 20th there’s some chance that you obtained an ISO with malware installed. The Linux Mint team posted notification on their blog on February 21st at around 2:00 am that they’d discovered their website had been compromised and that the official package had been replaced by a malicious version of the operating system. The hacked ISO was being hosted at absentvodka.com and there are a few names related to the Bulgarian based website which the Mint team has said they may launch investigation against.
Following the attack the site was brought down so as to avoid serving malicious ISO files. In comments on the original announcement members of the Mint team identified the site’s WordPress blog as the attacker’s point of entry. Prior to the announcement a dump of the linuxmint.com website was made available on TheRealDeal for $85. At least one individual purchased this and posted the config files on HackerNews.
For the intensely curious the malicious code is available in this gist:https://gist.github.com/Oweoqi/31239851e5b84dbba894 it appears to set up a bot net.
So, how can the user avoid this kind of threat? Well, first off is the recognition that regardless of the technical knowledge, professionalism, and good intentions of those providing a product, we must assume that the product could possibly be compromised. For those reasons it is on the consumers to take whatever steps we can to verify that the product we’re obtaining is the product we think it is. There are a few steps that I typically take to verify operating system images before use. What follows is pretty paranoid, and uses an Arch Linux distro as an example. My goal here is twofold: one, know the system I’m installing and the current issues, and two, get multiple independent verifications that what I’m about to install is legitimate.
Be aware of what vulnerabilities are known for the OS you’re considering installing. Arch Linux lists their CVEs here (https://wiki.archlinux.org/index.php/CVE), most big distros do this, I also use CentOS, for that I check CVEs here (https://access.redhat.com/security/security-updates/#/). Reading through we can see that both have some unpatched (at the time of this writing) namely the glibc vulnerability that has been in the news as of late.
Next is the checksum. We can download our file now, for Arch Linux there’s a huge number of mirrors, usually I select one in the United States and have a look at who the hosting party is. In this case I’ll choose kernel.org. Once over to kernel.org we see that we’re actually in a directory containing the images, and the signatures, and another set of checksums.
In this case I’ll download the x86_64 tarball from kernel.org. Call me paranoid, but what if a malicious entity had obtained access to both kernel.org and Arch Linux (probably unlikely, but not impossible) so rather than downloading the signatures and checksums from kernel.org I’ll go over to aggregate.org, another mirror on the list and download the SHA1 sums there. This is what the sha1sums.txt contains:
Okay. Now let’s check em. I simply grep for the sha1sum from the file, and I can see that they do in fact match.
A similar command can be run to check the md5 sum. Note that before checking the MD5 I went and got that file from yet another download mirror (this time pair.com).
Finally we’ll check the signature. Moving to another site in the mirror list I pick up the signature to check it. This time I selected ocf.berkley.edu and downloaded the signature file to my local machine.
As seen above I first attempted to check the sig with gpg –verify, it assumed the correct file to check, and couldn’t find the key in my gpg keychain. So I imported the key with gpg –recv-keys and the key id. The rerun shows that the signature is in fact verified. You can see a time break between when I first attempt verification and when I pull the key, during that time I was googling the key id to see if there were any fishy results.
So now we can move on with the installation of our ISO. I also recommend that if an integrity check is available for your installation media you run that before install. Arch Linux is a rolling distribution so I go through this kind of verification each time I do an install. With other OSs like CentOS, Ubuntu, etc. which are versioned, I will usually download one image, verify it, and then encrypt it and back it up so that I have a known good image to install from in the future for that particular version.
Bonus section: For work, when I’m super paranoid, and the image is some new hacking tool, or something we’re testing out for another company I’ll actually start the image in an airgap, then plug it into a mirrored switch and pull all of the traffic off of it for a while to see if it attempts to map drives, ping outbound to someone else’s network, or go grab software I didn’t ask for. Beau Bullock has also mentioned to me that he likes to run a vulnerability scan on it after install, which will point out which components of the system may be misconfigured from an outside perspective. This makes a lot of sense, it doesn’t have to mean that the image was intentionally made malicious, just that someone forgot to update package x before signing off on the image.
Ready to learn more?
Level up your skills with affordable classes from Antisyphon!
Available live/virtual and on-demand
