By Juan Andrés Guerrero-Saade & Phil Stokes
- SentinelLabs has investigated a supply-chain attack against the Rust development community that we refer to as ‘CrateDepression’.
- On May 10th, 2022, the Rust Security Response Working Group released an advisory announcing the discovery of a malicious crate hosted on the Rust dependency community repository.
- The malicious dependency checks for environment variables that suggest a singular interest in GitLab Continuous Integration (CI) pipelines.
- Infected CI pipelines are served a second-stage payload. We have identified these payloads as Go binaries built on the red-teaming framework, Mythic.
- Given the nature of the victims targeted, this attack would serve as an enabler for subsequent supply-chain attacks at a larger-scale relative to the development pipelines infected.
- We suspect that the campaign includes the impersonation of a known Rust developer to poison the well with source code that relies on the typosquatted malicious dependency and sets off the infection chain.
On May 10th, 2022, the Rust dependency community repository crates.io released an advisory announcing the removal of a malicious crate, ‘rustdecimal’. In an attempt to fool rust developers, the malicious crate typosquats against the well known rust_decimal package used for fractional financial calculations. An infected machine is inspected for the GITLAB_CI environment variable in an attempt to identify Continuous Integration (CI) pipelines for software development.
On those systems, the attacker(s) pull a next-stage payload built on the red-teaming post-exploitation framework Mythic. The payload is written in Go and is a build of the Mythic agent ‘Poseidon’. While the ultimate intent of the attacker(s) is unknown, the intended targeting could lead to subsequent larger scale supply-chain attacks depending on the GitLab CI pipelines infected.
The malicious package was initially spotted by an avid observer and reported to the legitimate rust_decimal github account. A subsequent investigation by the crates.io security team and Rust Security Response working group turned up 15 iterative versions of the malicious ‘rustdecimal’ as the attacker(s) tested different approaches and refinements. Ranging from versions 1.22.0 to 1.23.5, the malicious crate would function identically to the legitimate version except for the addition of a single function,
Decimal::new. This function contains code lightly obfuscated with a five byte XOR key.
Focusing on the obfuscated strings provides a pretty clear picture of the intended effects at this stage of the attack.
The attacker sets a hook on
std::panic so that any unexpected errors throw up the following (deobfuscated) string: “Failed to register this runner. Perhaps you are having network problems”. This is a more familiar error message for developers running GitLab Runner software for CI pipelines.
The theme of the error message betrays the attacker’s targeting. The
bit_parser() function checks that the environment variable GITLAB_CI is set; otherwise, it throws the error “503 Service Unavailable”. If the environment variable is set, meaning that the infected machine is likely a GitLab CI pipeline, the malicious crate checks for the existence of a file at
/tmp/git-updater.bin. If the file is absent, then it calls the
Depending on the host operating system,
check_value() deobfuscates a URL and uses a
curl request to download the payload and save it to
/tmp/git-updater.bin. Two URLs are available:
Once available, rustdecimal issues the appropriate commands to set the binary as executable and spawn it as a fork. In macOS systems, it takes the extra step of clearing the quarantine extended attribute before executing the payload.
If any of these commands fail, an
expect() routine will throw up a custom error: “ERROR 13: Type Mismatch”.
The second-stage payloads come in ELF and Mach-O form, with the latter compiled only for Apple’s Intel Macs. The malware will still run on Apple M1 Macs provided the user has previously installed Rosetta.
Mach-O Technical Details
|Filetype||Mach-O 64-bit executable x86_64|
|Filename||‘README.bin’ dropped as ‘/tmp/git-updater.bin’|
|C&C||api.kakn[.]li resolving to 18.104.22.168|
Both binaries are built against Go 1.17.8 and are unsigned Poseidon payloads, agent installations for the Mythic post-exploitation red-teaming framework. While Mythic has a number of possible agent types, Poseidon is the most suitable for an attacker looking to compromise both Linux and more recent macOS versions. Written in Go, Poseidon avoids the dependency problems that Macs have with Mythic agents written in Python, AppleScript and JXA.
On execution, the second-stage payload performs a number of initial setup procedures, taking advantage of Go’s goroutines feature to execute these concurrently. The function
profile.Start() then initiates communication with the C2.
Both samples reach out to the same C2 for tasking:
At the time of our investigation, the C2 was unresponsive, but analysis of the binary and the Poseidon source shows that the payload contains a switch with a large array of tasking options, including screencapture, keylogging, uploading and downloading files. On macOS, the operator can choose to persist by either or both of a LaunchAgent/Daemon and a LoginItem.
The Linux version is practically an identical cross-compilation of the same codebase–
ELF Technical Details
|Filetype||ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=ce4cf8031487c7afd2df673b9dfb6aa0fd6a680b, stripped|
|Filename||‘READMEv2.bin’ dropped as ‘/tmp/git-updater.bin’|
|C&C||api.kakn[.]li resolving to 22.214.171.124|
There are some notable dependency differences to enable OS specific capabilities. For example, the Linux version does not rely on RDProcess but adds libraries like xgb to communicate with the Linux X protocol.
Ultimately, both variants serve as an all-purpose backdoor, rife with functionality for an attacker to hijack an infected host, persist, log keystrokes, inject further stages, screencapture, or simply remotely administer in a variety of ways.
The campaign itself is a little more opaque to us. We became aware of this supply-chain attack via the crates.io security advisory, but by then the attacker(s) had already staged multiple versions of their malicious crate. In order to do so, the first few versions were submitted by a fake account ‘Paul Masen’, an approximation of the original rust_decimal developer Paul Mason.
That account is in turn linked to a barebones Github account ‘MarcMayzl’. That account is mostly bereft of content except for a single repository with two very suspect files.
The files, named
tmp2 are SVG files for the popular Github Readme Stats. However, these stats are generated in the name of a legitimate, predominantly Rust-focused, developer. This appears to be an attempt to impersonate a trusted Rust developer and is likely our best clue as to what the original infection vector of this campaign may be.
If we think through the campaign cycle, the idea of simply typosquatting a popular dependency isn’t a great way to infect a specific swath of targets running GitLab CI pipelines. We are missing a part of the picture where code is being contributed or suggested to a select population that includes a reference to the malicious typosquatted dependency. This is precisely where impersonating a known Rust developer might allow the attackers to poison the well for a target rich population. We will continue to investigate this avenue and welcome contributions from the Rust developer community in identifying these and further tainted sources.
Software supply-chain attacks have gone from a rare occurrence to a highly desirable approach for attackers to ‘fish with dynamite’ in an attempt to infect entire user populations at once. In the case of CrateDepression, the targeting interest in cloud software build environments suggests that the attackers could attempt to leverage these infections for larger scale supply-chain attacks.
We’d like to acknowledge Carol Nichols, the crates.io team, and the Rust Security Response working group for their help and responsible stewardship. We also extend a sincere thank you to multiple security researchers that enabled us to flesh out and analyze this campaign, including Wes Shields.
Indicators of Compromise
(not to be confused with ‘rust_decimal’)
|README.bin (Mach-O, Intel)||c91b0b85a4e1d3409f7bc5195634b88883367cad|