The Linux Mint Backdoor: How Bad Was It?
It was worse than was thought, but a lot better than it could have been.
This past Saturday, February the 20th, it was discovered that one of the most popular Linux desktop distributions had its installation image backdoored. The links on Linux Mint’s homepage, that pointed to installation disk images, had been replaced by links to a malicious site. This new site hosted copies of the installation disk that contained a backdoor for a simple, but effective DoS bot. Linux users looking to install a new operating system were installing this malicious code in to their new machines.
Stories and links flooded in through social media about the backdoor, but the first notice appears to be from a user on the Linux Mint user forums at 6:40 p.m. UTC on the February 20th (http://webcache.googleusercontent.com/search?q=cache:forums.linuxmint.com/viewtopic.php?f=90&t=217178&p=1135353). By 1:44 a.m. UTC on the 21st the Linux Mint team had confirmed the attack (http://blog.linuxmint.com/?p=2994) and was working to resolve the issue. The comments on the Mint blog show that the Mint team struggled to remove the attacker and ultimately shut down the entire Mint website to remove the risk of further infection.
While the transparency provided by Linux Mint is great to see, it doesn’t answer the question of exactly when traffic began redirecting to the malicious site. A backdoored operating system can pose an extremely large risk by giving complete control of the impacted system to an attacker. This makes establishing an accurate timeline of events an important aspect when understanding and evaluating the risk. It provides a clear time window for users to assess if their machines may be compromised.
Through the data collected by Level 3 Threat Research Labs we can confirm that the impact was actually worse than what has been reported by other sources to date. The traffic shifted to multiple different malicious hosts three separate times between February 19th and 21st:
The final end time on the 21st is an estimate since many security researchers were attempting to access the malicious URLs directly during this time period, causing a less clear cut off in traffic. However, it coincides with the discussion occurring on the Linux Mint blog where Clement Lefebvre of the Linux Mint team stated he had disabled the website entirely in response to a comment from a user after 3:02 a.m. GMT. (http://blog.linuxmint.com/?p=2994#comment-124896).
The entire trend of traffic for each malicious IP can seen in the following time series graph:
During the impacted time period, hundreds of downloads took place, successfully delivering the attacker’s backdoored installation image to Mint users globally.
The Linux Mint team’s statement indicates that only a single edition of its software was believed to be backdoored: Linux Mint 17.3 Cinnamon. Level 3 Threat Research Labs obtained and analyzed the backdoored disk image, including comparing it to a known good image in order to understand what malicious items had been placed on the installation image. Fortunately the backdoor was not very sophisticated and very little was done to mask its existence or functionality. This is a much better outcome than could have occurred with a more sophisticated attacker.
The attacker began work on building the image on February 17th 2016 and completed it on February 19th 2016. The malicious installation image contained over 1500 additional items compared with the known good image, largely due to the installation of non-backdoored development and build packages. These packages were installed by the attacker to compile an IRC based DoS bot. The bot code used was functionally an exact copy of the Kaiten bot code (https://packetstormsecurity.com/files/25575/kaiten.c.html), a very old and well-documented bot dating back to 2001 (https://resources.sei.cmu.edu/asset_files/WhitePaper/2001_019_001_52491.pdf).
The bot source code was left on the backdoored disk image in /var/lib/man.cy and the compiled bot binary was installed in /var/lib/apt-cache. These indicators, along with others listed at the end of the article, provide an indication that a system has installed this compromised disk image.
In order to persist the bot through reboots two different cron jobs were installed in /etc/cron.hourly/man.sh and /var/spool/cron/crontabs/root.
Each cron entry runs /var/lib/man, a simple perl script which executes the bot if it is not currently running on the system:
These few files work together to ensure the bot is always running and ready to participate in DoS attacks against new victims.
The bot code installed is known as Kaiten, which contains a small number of settings that are expected to be customized by the installer. Our attacker modified the code accordingly, and set the botnet to operate with the following attributes:
The five servers specified include a duplicate of updates.absentvodka.com along with three other hostnames: updates.mintylinux.com, eggstrawdinarry.mylittlerepo.com, and linuxmint.kernel-org.org.
Level 3’s passive DNS data for the time period of the attack includes DNS lookups for the updates.absentvodka.com host, pointing to 188.8.131.52 which was one of the same hosts serving the backdoored installer. The other hostnames saw no DNS activity because the other domains were not registered at the time of the traffic rerouting. The other domains have since been registered, most likely by security researchers or malicious actors.
IRC botnets such as Kaiten have waned in popularity over the last 15 years, but despite their age and being surpassed by more advanced botnet designs, they still function today. This particular botnet is focused on DoS attacks, which can be seen by the command structure including methods for a variety of basic volumetric TCP and UDP attack types.
As with many bots, this code includes the ability to download arbitrary files and execute shell commands on the infected host. In the case of this bot, the User Agent is hardcoded to the very old 4.75 release of Mozilla released in September of 2000.
Recommendations and Conclusions
Most open source operating system images take care to provide their users with hashes representing the file being downloaded. This is primarily done to check for file corruption, however validation for security purposes is clearly a useful step to take as well.
In the case of this image, MD5 hashes were also included inside the disk image, which would have alerted users to the image being modified if verified. The attacker was aware of this and took the time to create a new version of this file, but did not complete the task by overwriting the original.
The Linux Mint project should consider not only including hashes, but also cryptographically signing images, a method which could not be easily modified by an attacker. Since the attacker in this instance had access to the image and the website, the hash could have been changed. As long as private keys used for signing were stored off this webserver, a cryptographic method would not have been vulnerable to such manipulation.
This compromise should remind security professionals that knowledge of a bot, exploit, or attack vector does not mean that it is eradicated. Just like a human disease, when weaknesses present themselves the well-known can return and still be dangerous. So even with these basic recommendations in place, every network should be monitoring its outbound traffic to look for anomalies and interactions with unknown hosts. These best practices used together would have caught and allowed for appropriate response to the risk outlined in this article.
User-Agent: Mozilla/4.75 [en] (X11; U; Linux 2.2.16-3 i686)