Supply chain PyPI de Bittensor

Le 2 juillet 2024 à 19:06 UTC, des attaquants ont commencé à drainer des tokens TAO depuis des wallets Bittensor à travers le réseau. Au moment où l'Opentensor Foundation a détecté le volume de transfert anormal 20 minutes plus tard et a placé les validateurs derrière un firewall, environ 32 000 TAO (~8 millions de dollars) avaient été volés. Le vecteur d'attaque n'était pas sur Bittensor lui-même — il était dans un package PyPI malveillant qui avait usurpé l'identité du SDK officiel bittensor entre le 22 et le 29 mai.

Ce qui s'est passé

Les utilisateurs Bittensor — opérateurs de nœuds, validateurs, mineurs — interagissent avec le réseau via le SDK Python officiel bittensor, distribué sur PyPI. Entre le 22 et le 29 mai 2024, un attaquant a téléversé une version malveillante du package, bittensor==6.12.2, qui se faisait passer pour une release légitime.

Le package malveillant contenait du code qui s'activait pendant des opérations spécifiques : quand un utilisateur déchiffrait sa coldkey pour staker, unstaker, transférer, déléguer ou annuler une délégation, le package exfiltrait le bytecode déchiffré vers un serveur distant contrôlé par l'attaquant.

La compromission était silencieuse et asynchrone : les utilisateurs ayant téléchargé la version trojan accumulaient sans le savoir du risque pendant des semaines jusqu'à ce que l'attaquant active les coldkeys récoltées le 2 juillet et commence à drainer le réseau.

Conséquences

• L'Opentensor Foundation a détecté le volume de transfert anormal à 19:26 UTC.
• À 19:41 UTC, les validateurs ont été placés derrière un firewall en « mode sûr » — empêchant les nœuds de se connecter à la chaîne, arrêtant les transactions, et donnant à la fondation le temps d'enquêter.
• Le package malveillant a été retiré de PyPI en quelques heures.
• TAO a chuté d'environ 15 % sur la journée à environ 230 $.
• Les utilisateurs affectés — ceux qui avaient téléchargé la version trojan et effectué des opérations de clé — ont absorbé de vraies pertes ; la fondation a annoncé un soutien aux utilisateurs affectés mais ne pouvait pas annuler les transferts on-chain.

Pourquoi c'est important

L'incident Bittensor est l'attaque de chaîne d'approvisionnement sur un SDK blockchain classique. La compromission n'était pas dans le protocole, les clés, le consensus ou les smart contracts — elle était dans le canal de distribution de confiance par lequel les utilisateurs obtiennent le logiciel qui gère leurs clés. La classe d'attaque frappe les logiciels open-source depuis des années (event-stream, ua-parser-js, plusieurs packages JS Solana) mais l'incident Bittensor était une démonstration inhabituellement claire de la façon dont la même attaque se transpose directement sur la garde blockchain.

Les réponses défensives sont documentées et inégalement adoptées :

• Épingler les versions de package dans les scripts de déploiement de production ; jamais pip install bittensor sans verrouillage de version.
• Utiliser la signature cryptographique des releases (Sigstore, packages signés GPG, npm provenance) et vérifier les signatures avant installation.
• Déchiffrer les coldkeys dans des environnements isolés — signataires air-gapped ou HSMs — pour que même un SDK compromis ne puisse pas les exfiltrer.

La réponse en 35 minutes de l'Opentensor Foundation — de la détection au firewall — est l'une des réponses d'incident publiques les plus rapides enregistrées, et a significativement limité la perte. Les dommages ont été contraints davantage par les réflexes de la fondation que par la conception du protocole.