The onering Rust Crate Supply Chain Attack

What happened

Version 1.4.1 of onering added a build script that steals source code from the project that uses it. Cargo runs build.rs files during compilation. The code in your program does not need to call the crate for the script to run.

According to Aikido, the script did three things:

1. It found the root of the consuming project. It started at the Cargo OUT_DIR folder and moved up until it found the target folder.
2. It ran git commands to read commit data: hash, author name, author email, date and subject. It also ran git diff HEAD^ HEAD to read the full text of the last change.
3. It sent the data with an HTTP POST. The request looked like a Sentry telemetry event. The commit data sat in event tags and the diff sat in an extra.patch field.

A diff of the last commit can hold new private code, security fixes that are not public yet, and secrets that a developer committed by mistake.

Aikido and GBHackers also report that the maintainer's GitHub repository (cenotelie/onering) appeared to be compromised. A project that pulls the crate from git instead of the registry can be affected too. The sources do not say how the attacker gained access.

Vigilance compares the release you trust with the new one. It reports the file that gained a new capability. Here that file is Cargo.toml in the package. See the scan block below.

Affected versions

• onering 1.4.1 on crates.io.
• The git repository at cenotelie/onering, which the reports describe as also compromised.

The sources do not name the last clean version number. Check the release list on crates.io for the version you trusted before 1.4.1.

Indicators of compromise

• Endpoint: https://o4511539639222272.ingest.de.sentry.io/api/4511539669368912/envelope/
• Sentry public key (DSN): 8197ee42c4f59c83f4cc6d48f5bae821
• Sentry organization ID: o4511539639222272
• Sentry project ID: 4511539669368912
• Request type: HTTP POST with content type application/x-sentry-envelope and a diff in extra.patch.

How to check

Search your lockfile for the crate and its version.

grep -rn -A1 "name = \"onering\"" --include=Cargo.lock .

If the line below it reads version = "1.4.1", your project built with the bad release. Also search proxy and CI logs for the Sentry organization ID above.

grep -rn "o4511539639222272" /var/log 2>/dev/null

What to do now

1. Remove onering 1.4.1 or pin a version that you trusted before it. Regenerate Cargo.lock.
2. List the commits that your project built while 1.4.1 was in the tree. Treat the diff of the last commit of each build as exposed.
3. Rotate any secret that appeared in those diffs.
4. Check the git source in your manifest. Do not pull onering from the compromised repository.
5. Watch for unexpected git commands and outbound HTTP calls during builds.

What Vigilance showed

Vigilance compares the version you trust with the new one and names the file that gained a new capability. The block below is rebuilt from the public reports in the words Vigilance prints. It is not a captured scan, because the malicious release is not redistributed.

files scanned: 36

HEADS UP  1 file can now do things the old version could not. The rest changed and gained nothing.

CHANGED    build.rs
           It now downloads from the internet and runs other programs. It did not before.

Sources

1. aikido.dev/blog/compromised-rust-crate-onering-performs-code-exfiltration
2. gbhackers.com/compromised-rust-crate-with-18000-downloads-steals-source-code/