The Arch Linux user-maintained software repository called AUR has been found to host malware. The discovery was made after a change in one of the package installation instructions was made. This is yet another incident that showcases that Linux users should not explicitly trust user-controlled repositories.
AUR User-Maintained Arch Linux Repository Contaminated with Malware
Linux users of all distributions have received a major warning not to explicitly trust user-run software repositories following the latest incident related to Arch Linux. The project’s user-maintained AUR packages (which stands for “Arch User Repository”) have been found to host malware code in several instances. Fortunately a code analysis was able to discover the modifications in due time.
The security investigation shows that shows that a malicious user with the nick name xeactor modified in June 7 an orphaned package (software without an active maintainer) called acroread. The changes included a curl script that downloads and runs a script from a remote site. This installs a persistent software that reconfigures systemd in order to start periodically. While it appears that they are not a serious threat to the security of the infected hosts, the scripts can be manipulated at any time to include arbitrary code. Two other packages were modified in the same manner.
Following the discovery all dangerous instances were removed and the user account suspended. The investigation reveals that the executed scripts included a data harvesting component that retrieves the following information:
- Machine ID.
- The output of uname -a.
- CPU Information.
- Pacman (package management utility) Information.
- The output of systemctl list-units.
The harvested information was to be transferred to a Pastebin document. The AUR team discovered that the scripts contained the private API key which shows that this was probably done by an inexperienced hacker. The purpose of the system information remains unknown.
Update August 2018 – Malware Packages Analysis
As mentioned before we have updated the article with newer information about the scripts and their effects on the target system. We have been able to obtain detailed information about the scripts’ operation.
The initial deployment script has been found to contain a systemd configuration file that adds a persistent presence on the computer. This makes the init service to automatically start the script every time the computer starts. It is programmed to download the download script which downloads and runs a malicious file.
It is called the upload script which calls several commands that harvest the following data:
- Machine ID
- Data
- System Information
- Package Information
- System Modules Information
This information is then reported to the Pastebin online account.
The confirmed list of affected packages includes the following AUR entries:
- acroread 9.5.5-8
- balz 1.20-3
- minergate 8.1-2
There are several hypotheses that are currently considered as possible. A reddit user (xanaxdroid_) mentioned online that “xeactor” has posted several cryptocurrency miner packages which shows that infection with them was a probable next step. The obtained system information can be used to choose a generic miner instance that would be compatible with most of the infected hosts. The other idea is that the nick name belongs to a hacker group that may target the infected hosts with ransomware or other advanced viruses.
Whether or not Linux users use Arch Linux they should double check if any user-maintained repositories that they use are trustworthy. This incident show once again that security cannot be guaranteed. A comment made by Giancarlo Razzolini (an Arch Linux trusted user) reads that explicitly trusting AUR and using helper applications is not a good security practice. In response to the mailing list announced he posted the following reply:
I’m surprised that
this type of silly package takeover and malware introduction doesn’t happen more often.This is why we insist users always download the PKGBUILD from the AUR, inspect it and
build it themselves. Helpers that do everything automatically and users that don’t pay
attention, *will* have issues. You should use helpers even more so at your risk than
the AUR itself.
Timeline of Arch Linux AUR Incident Response
- Sun Jul 8 05:48:06 UTC 2018 — Initial Report.
- Sun Jul 8 05:54:58 UTC 2018 — Account suspended, commit reverted using Trusted User privileges.
- Sun Jul 8 06:02:08 UTC 2018 — The additional packages were fixed by the AUR team.
Users of all Linux distributions should be well aware of the risks associated with installing software from repositories that are not maintained directly by their direct maintainers. In some cases they do not bear the same commitment and responsibility and it is much more likely that a malware infection can spread and may not be addressed in due time.
Note: The article has been updated with a timeline of the events.
Martin Beltov
Martin graduated with a degree in Publishing from Sofia University. As a cyber security enthusiast he enjoys writing about the latest threats and mechanisms of intrusion.
Follow Me:
So erm the list of packages affected might be nice in include.
Hey somebob,
I followed the incident on the official Arch linux mailing list and the mentioned packages are “libvlc.git” and “acroread.git”. The developers state that two other packages besides “acroread” have been manipulated, a later email mentioned “libvlc”.
Look at the link in the article to access the discussion if you are interested in how the team handled the situation in detail.
Doesn’t “explicit trust” mean the desired behaviour, i.e. a user’s informed decision about a given package, rather than “implicit trust”, i.e. the lack of user’s decision regarding a particular package but a general trust to all of them?
I guess you’re right!
Somebody was just questioning the libvlc source. If you read the later emails it was pointed out that the url is part of pacman-mirrorlist.
Thanks for clarifying this.
Probably every single one AUR helper informs us that we should read PKGBUILDs, so being infected by malware at this layer means that somebody doesn’t treat security seriously…
True, hopefully this incident will help to raise awareness.
6 minutes is a pretty good response time.
My guess would be the output could be used for a more targeted attack against the more powerful machines. If you can tell most of the machines with 32 CPU cores have some package installed, you know which one you should hijack next.
It’s not so much a trust in the AUR system itself. It’s more trusting the maintainer(s). When a package switches maintainer, you should be temporary on guard.
Would be a nice addition to youart.
THE AUR trusted users are awesome IMHO!
Hence why you may want to check the PKGBUILD every now and then before installing or upgrading AUR software. User-maintained repositories can sometimes hold packages that were built by jackasses, no shit Sherlock!
True, but not everyone can understand the variables and code in the PKGBUILD files.
That’s why I can reccomend using “trizen” over “yaourt”: I get all the information first. (Also they did their escaping routines right).
Thanks for the recommendation, I have always used “yaourt” as I am accustomed to it.
True, but it is straightforward bash concentrated almost entirely in a single file (I much prefer it to debian format in that regard), and the only official direction on how to use the AUR has had nice red warnings saying check for potentially malicious code (and if unsure ask on thr forums and/or mailing list) for years
I agree that the Arch Linux user community is very reliable. The AUR repository is awesome as it contains many packages that cannot be included in the main repos.
The wiki gives a detailed overview on how it is managed, I hope that the “acroread case” will set the necessary warning lights to new users in handling the user-maintained packages with greater care.
KEK posted a comment here stating that the “trizen” helper application shows detailed PKGBUILD info by default.