Ataque a la cadena de suministro PyPI de Bittensor

El 2 de julio de 2024 a las 19:06 UTC, los atacantes comenzaron a drenar tokens TAO de wallets de Bittensor en toda la red. Para cuando la Opentensor Foundation detectó el volumen anormal de transferencias 20 minutos después y puso a los validadores tras un firewall, aproximadamente 32.000 TAO (~$8 millones) habían sido robados. El vector de ataque no estaba en el propio Bittensor — estaba en un paquete malicioso de PyPI que se había hecho pasar por el SDK legítimo de bittensor entre el 22 y el 29 de mayo.

Qué ocurrió

Los usuarios de Bittensor — operadores de nodos, validadores, mineros — interactúan con la red a través del SDK oficial de Python bittensor, distribuido en PyPI. Entre el 22 y el 29 de mayo de 2024, un atacante subió una versión maliciosa del paquete, bittensor==6.12.2, que se hacía pasar por una release legítima.

El paquete malicioso contenía código que se activaba durante operaciones específicas: cuando un usuario descifraba su coldkey para hacer staking, unstaking, transferir, delegar o desdelegar, el paquete exfiltraba el bytecode descifrado a un servidor remoto controlado por el atacante.

El compromiso fue silencioso y asíncrono: los usuarios que descargaron la versión troyana acumularon inconscientemente riesgo durante semanas hasta que el atacante activó las coldkeys recolectadas el 2 de julio y comenzó a drenar la red.

Consecuencias

• La Opentensor Foundation detectó el volumen anormal de transferencias a las 19:26 UTC.
• A las 19:41 UTC, los validadores fueron colocados tras un firewall en "modo seguro" — impidiendo que los nodos se conectaran a la cadena, deteniendo las transacciones, y dando a la fundación tiempo para investigar.
• El paquete malicioso fue eliminado de PyPI en cuestión de horas.
• TAO cayó aproximadamente un 15% en el día hasta alrededor de $230.
• Los usuarios afectados — quienes habían descargado la versión troyana y realizado operaciones con claves — absorbieron pérdidas reales; la fundación anunció soporte para los usuarios afectados pero no pudo deshacer las transferencias on-chain.

Por qué importa

El incidente de Bittensor es el ataque a la cadena de suministro de un SDK de blockchain de libro de texto. El compromiso no estaba en el protocolo, las claves, el consenso ni los contratos inteligentes — estaba en el canal de distribución confiable a través del cual los usuarios obtienen el software que maneja sus claves. Esta clase de ataque ha estado golpeando software open-source durante años (event-stream, ua-parser-js, múltiples paquetes JS de Solana) pero el incidente de Bittensor fue una demostración inusualmente clara de cómo el mismo ataque mapea directamente a la custodia blockchain.

Las respuestas defensivas están documentadas y se adoptan de forma desigual:

• Fijar versiones de paquetes en scripts de despliegue de producción; nunca pip install bittensor sin lock de versión.
• Usar firma criptográfica de releases (Sigstore, paquetes firmados con GPG, npm provenance) y verificar firmas antes de la instalación.
• Descifrar coldkeys en entornos aislados — firmantes air-gapped o HSMs — para que incluso un SDK comprometido no pueda exfiltrarlas.

La respuesta de 35 minutos de la Opentensor Foundation — desde detección hasta firewall — es una de las respuestas a incidentes públicas más rápidas registradas, y limitó significativamente la pérdida. El daño se vio limitado más por los reflejos de la fundación que por el diseño del protocolo.