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
- 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.