ld-preload

ldpreload: Stealing Solana Validator Keys in Plain Sight

This tool was just thrown together, it isn't indented for production, if you run into issues, please debug.

Overview

A tool that demonstrates LD_PRELOAD injection attacks against containerized applications. This was built to understand how malicious shared libraries can intercept system calls in isolated environments.

Important: THIS IS NOT A SOLANA BUG OR VULNERABILITY. We chose Solana validators specifically because they handle real money and the stakes are high. When credentials get stolen from a validator, actual financial loss happens. This makes it a compelling example to raise awareness about the severity of this attack. The technique works against any application (containerized or not) that loads credentials from files.

What it does

The tool spins up a Solana validator inside a Docker container and injects a malicious shared library using LD_PRELOAD. The library hooks the close() system call to exfiltrate validator keypair files when they're accessed.

When files in the solana ledger directory are closed, the hook copies them to /tmp/stolen-validator-data on the host. This simulates a supply chain attack where compromised dependencies could steal credentials from production systems.

Running the Attack

Run make to build the Go binary. You need Docker installed and running to actually use it.

When you run the demo, which is a Go application, here's what happens:

Default mode (LD_PRELOAD environment variable):

./ldpreload

1. Build the malicious library inside a container.
2. Mount the malicious library into the validator container.
3. Launch the compromised Solana validator with LD_PRELOAD set to the malicious library.
4. The malicious library hooks the close() system call and exfiltrates the private keys.
5. The stolen data is analyzed.

Persistent mode (/etc/ld.so.preload):

./ldpreload --persistent

1. Mount the malicious.c source file into the validator container.
2. Launch the compromised Solana validator with a command that compiles the library and writes to /etc/ld.so.preload.
3. The malicious library is loaded automatically for all processes.
4. Same interception and exfiltration process.
5. The stolen data is analyzed.

Here's what the output looks like when the attack succeeds:

Step 1: Building malicious library...
✓ Building malicious library complete

Step 2: Preparing clean environment...
✓ Preparing clean environment complete

Step 3: Launching compromised validator...
✓ Launching compromised validator complete

Step 4: Analyzing stolen data...
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
STOLEN FILES:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  • validator-identity.json (232 bytes)
  • validator-stake-account.json (229 bytes)
  • validator-vote-account.json (233 bytes)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
ATTACK SUMMARY:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  Keys stolen:              3
  Method:                   LD_PRELOAD injection
  Detection by victim:      None
  Validator operation:      Continues normally

  Result: COMPLETE COMPROMISE

Those JSON files contain Ed25519 private keys stored as byte arrays. With these keys, an attacker has complete control over the validator:

• Sign transactions
• Withdraw stake
• Manipulate consensus votes
• Drain associated wallets

The validator keeps running normally, no crashes, alerts, or suspicious behavior. The EDR agent sees the validator process legitimately accessing its own files, which is exactly what it's supposed to do. File permissions are respected and the audit logs show normal operation.

The attack is entirely invisible.