Bittensor PyPI Supply Chain

Am 2. Juli 2024 um 19:06 UTC begannen Angreifer, TAO-Tokens aus Bittensor-Wallets im gesamten Netzwerk zu entziehen. Als die Opentensor Foundation das abnormale Transfervolumen 20 Minuten später erkannte und Validatoren hinter eine Firewall stellte, waren etwa 32.000 TAO (~8 Millionen US-Dollar) gestohlen. Der Angriffsvektor lag nicht in Bittensor selbst — er lag in einem bösartigen PyPI-Paket, das zwischen dem 22. und 29. Mai das legitime bittensor-SDK imitiert hatte.

Was geschah

Bittensor-Nutzer — Node-Operatoren, Validatoren, Miner — interagieren mit dem Netzwerk über das offizielle bittensor-Python-SDK, verteilt auf PyPI. Zwischen dem 22. und 29. Mai 2024 lud ein Angreifer eine bösartige Version des Pakets hoch, bittensor==6.12.2, die sich als legitime Release ausgab.

Das bösartige Paket enthielt Code, der bei spezifischen Operationen aktivierte: Wenn ein Nutzer seinen Coldkey entschlüsselte, um zu staken, zu unstaken, zu transferieren, zu delegieren oder zu undelegieren, würde das Paket den entschlüsselten Bytecode an einen vom Angreifer kontrollierten Remote-Server exfiltrieren.

Die Kompromittierung war still und asynchron: Nutzer, die die Trojaner-Version herunterluden, akkumulierten unwissentlich wochenlang Risiko, bis der Angreifer die geernteten Coldkeys am 2. Juli aktivierte und das Netzwerk zu entleeren begann.

Folgen

• Die Opentensor Foundation erkannte das abnormale Transfervolumen um 19:26 UTC.
• Um 19:41 UTC wurden Validatoren in den „Safe Mode" hinter einer Firewall platziert — verhinderten, dass Nodes sich zur Chain verbanden, stoppten Transaktionen und gaben der Foundation Zeit zur Untersuchung.
• Das bösartige Paket wurde innerhalb von Stunden von PyPI entfernt.
• TAO fiel am Tag um etwa 15% auf rund 230 USD.
• Betroffene Nutzer — diejenigen, die die Trojaner-Version heruntergeladen und Schlüsseloperationen durchgeführt hatten — absorbierten reale Verluste; die Foundation kündigte Unterstützung für betroffene Nutzer an, konnte aber die On-Chain-Transfers nicht rückgängig machen.

Warum es wichtig ist

Bittensors Vorfall ist der lehrbuchmäßige Supply-Chain-Angriff auf ein Blockchain-SDK. Die Kompromittierung lag nicht im Protokoll, in den Keys, im Konsens oder in den Smart Contracts — sie lag im vertrauenswürdigen Verteilungskanal, über den Nutzer die Software erhalten, die ihre Keys handhabt. Die Angriffsklasse trifft Open-Source-Software seit Jahren (event-stream, ua-parser-js, mehrere Solana-JS-Pakete), aber Bittensors Vorfall war eine ungewöhnlich klare Demonstration, wie direkt derselbe Angriff auf Blockchain-Custody abbildet.

Die defensiven Antworten sind dokumentiert und ungleichmäßig in der Adoption:

• Pin Paketversionen in Produktions-Deployment-Skripten; niemals pip install bittensor ohne Versionssperre.
• Verwenden Sie kryptografisches Signieren von Releases (Sigstore, GPG-signierte Pakete, npm-Provenance) und verifizieren Sie Signaturen vor der Installation.
• Entschlüsseln Sie Coldkeys in isolierten Umgebungen — Air-Gapped-Signern oder HSMs — sodass selbst ein kompromittiertes SDK sie nicht exfiltrieren kann.

Die 35-minütige Reaktion der Opentensor Foundation — von Erkennung bis Firewall — ist eine der schnelleren öffentlich dokumentierten Vorfallsreaktionen und begrenzte den Verlust bedeutsam. Der Schaden wurde mehr durch die Reflexe der Foundation als durch das Design des Protokolls begrenzt.