Scraping off the Rust

On August 20th of this year, the Rust Security Response Team disclosed a supply-chain attack that was affecting several packages hosted on the crates.io repository. Probably the most significant of the affected packages was the arrayref package, which is a long-established utility package with approximately 245 million previous downloads. It's estimated that this package alone is present in about 3/4 of environments where Rust is used.

Attackers were able to compromise the credentials of the legitimate package maintainer, allowing them to publish their own malicious version of the arrayref package, which was listed as arrayref 0.3.10. Shortly thereafter, other packages from the same maintainer were updated, which were internment 0.8.7 and append-only-vac 0.1.9.

Thankfully, all these malicious packages were removed from the repository in under 2 hours. Previous versions were restored and the maintainer account was locked. With that said, the potential reach of this attack was significant because these were not newly created packages, they were established packages already present in project dependency trees.

It may also be the case that this attack was prepared in advance. Several other attacker-controlled packages were found to be associated with the same campaign and were staged days before the arrayref compromise.

Lastly, there appears to be some infrastructure overlapping with earlier software supply-chain attacks from North Korean threat actors, though this connection has not been confirmed.

(Source: The Hacker News)

The overall attack was such that the attackers did not need to inject any malicious code directly into crates, nor did any malicious packages need to be called directly. Instead, the dependency manifest of packages was altered to pull in malicious dependencies as a part of the build process.

In the case of the array-ref crate, the dependency manifest was changed to require a malicious package named proc-macro1. This very closely resembles proc-macro2, which is a legitimate and commonly used package. The attackers also imitated the name of David Tolnay, a very well-known Rust developer, in their account name. The malicious proc-macro1 package was published several hours prior to the changes to array-ref.

The malicious dependency contained a build.rs script, which is a script that is normally executed by Cargo, the Rust package manager, as part of the build process. Thus, the malicious dependency never had to be called directly. Simply starting the build process was enough to execute the attack.

What the build script did was download a second-stage payload and execute it. Payloads were identified for Windows, Linux, and both silicon and Intel-based MacOS. StepSecurity was able to demonstrate that even GitHub Actions jobs could complete successfully with the malicious code executing during the build.

(Source: Aikido)

Rust has had to deal with malicious crate problems before, including typosquatted packages and attacks abusing build scripts. This incident stands out among those previous incidents because the attackers did not have to depend on people choosing unfamiliar packages, they were able to compromise existing packages that people already trusted. With that in mind, we can see this incident as an extension of the recent trend of issues seen in other open-source package ecosystems.

The Arch User Repository (AUR), for example, was the victim of a large malicious package campaign in June of this year. A high volume of malicious packages cause problems throughout the entire repository while administrators were attempting to contain the problem.

Users were advised to inspect changes to PKGBUILD instructions and installation scripts before accepting any updates. Another wave of this incident occurred in July when community researchers reported hundreds of suspicious AUR package updates containing malicious files.

The mechanics of these incidents do differ. With the Rust attack, the process involved compromising a legitimate maintainer and changing dependencies, and with the AUR attack, the process involved taking over or adopting an existing community package and changing its installation process. The underlying strategy would appear to be the same, however, which is to target mechanisms people already use to obtain trusted software.

So, it makes sense that we are seeing a growing pattern across a number of different ecosystems like Rust, Arch, npm, PyPI, and others where attackers will view package repositories, their maintainers, and even their CI/CD systems as a distribution platform for compromise rather than simply a development infrastructure.

This article is shared at no charge for educational and informational purposes only.

Red Sky Alliance is a Cyber Threat Analysis and Intelligence Service organization. We provide indicators of compromise information (CTI) via a notification/Tier I analysis service (RedXray) or an analysis service (CTAC). For questions, comments or assistance, please contact the office directly at 1-844-492-7225, or feedback@redskyalliance.com

Weekly Cyber Intelligence Briefings: