Puntos clave

El ataque movió TAC existente en lugar de crear nueva oferta.

La supervisión del bridge siguió conforme porque cada token espejado estaba respaldado.

El plan de recuperación de TAC propone restaurar los saldos de staking mediante una edición de estado.

Los holders en BNB Chain no deben operar mientras siga sin resolverse su tratamiento.

El bridge estaba respaldado por TAC robado

El informe posterior al incidente de TAC del 2 de septiembre señala que sus controles de monitoreo siguieron funcionando durante todo el ataque. Esos controles estaban diseñados para detectar la falta de colateral del bridge, mientras que el robo ocurrió antes de que los tokens llegaran al bridge. TAC es una blockchain basada en Cosmos con una capa de ejecución compatible con Ethereum, creada para conectar aplicaciones de Ethereum con el ecosistema de TON y Telegram. Cuando TAC se mueve a otra red compatible, los tokens nativos permanecen bloqueados en TAC y se emite una representación equivalente en la cadena de destino.

Un control automatizado comparó el TAC nativo en custodia con la oferta espejada en BNB Chain y Ethereum. El atacante presentó TAC auténtico tomado del staking pool, lo bloqueó y recibió la cantidad correcta de tokens espejados. Ambos lados del bridge siguieron coincidiendo.

Como explicó TAC, “a solvency check cannot detect a theft that preserves solvency.” El bridge permaneció totalmente respaldado aunque los activos que proporcionaban ese respaldo habían sido robados segundos antes.

El staking pool se movió en 95 segundos

El exploit se ejecutó a las 19:46:37 UTC del 22 de agosto y vació la cuenta que contenía todo el TAC delegado a los validadores. La primera transferencia del bridge comenzó 32 segundos después, mientras que una segunda completó el movimiento de aproximadamente 2.986 mil millones de tokens a BNB Chain en 95 segundos. La venta comenzó minutos más tarde. El atacante intercambió 1.208 mil millones de TAC en BNB Chain por 950,293 USDT y vendió otros 49.9 millones de TAC a través de TON por 55,481 USDT. El total de ingresos alcanzó aproximadamente $1.006 millones.

La producción de bloques se detuvo a las 23:58:11 UTC, más de cuatro horas después de que el staking pool hubiera sido vaciado. La red sigue detenida mientras los validadores preparan el software parcheado y el proceso de recuperación.

Las alertas de grandes transferencias estaban activas, pero el primer movimiento del bridge comenzó apenas 32 segundos después del vaciado. Un control que requiriera revisión humana podría ayudar a rastrear los activos después, pero no podía sustituir el código que habría impedido que se creara el saldo inválido.

El exploit ocurrió antes del bridge

La vulnerabilidad subyacente se encontró en el módulo compartido Cosmos EVM, y no en el código del bridge específico de TAC. TAC mantiene un saldo de cuenta en su cadena basada en Cosmos y otro en su capa compatible con Ethereum, y el ataque explotó diferencias entre esos registros.

El software afectado gestionó de forma incorrecta la delegación de tokens con vesting bloqueado, los dedujo de un saldo disponible de cero y permitió que el resultado se desbordara hasta un número extremadamente grande. Luego, la falta de una salvaguarda dejó expuesto a ese saldo inválido el staking pool controlado por el protocolo.

El exploit redujo el pool a cero y acreditó al atacante con su TAC existente. La oferta total no cambió porque la transacción movió tokens entre cuentas sin producir un mint permanente.

El bridge entró en la secuencia solo después de que la red aceptó como válido el saldo del atacante. Luego procesó el TAC robado igual que procesaría tokens adquiridos mediante una transacción ordinaria.

TAC fue una de seis redes afectadas por la vulnerabilidad compartida. La investigación previa de Coindoo sobre cómo Cosmos Labs interpretó mal el error antes del hack de seis cadenas explica por qué la falla siguió siendo peligrosa después de su informe original y cómo las advertencias incompletas dejaron expuestas a redes independientes.

El plan de recuperación preserva las transacciones no relacionadas

TAC planea reparar saldos específicos en el bloque donde la red se detuvo. Esta edición de estado dirigida preserva el resto de la historia de la blockchain en lugar de devolver toda la red a un punto anterior.

Un rollback habría borrado 7,772 transacciones legítimas enviadas por 218 direcciones sin conexión con el ataque. También habría dejado TAC espejado en otras redes sin respaldo nativo correspondiente después de que ya se hubieran producido transferencias entre cadenas.

La edición propuesta restauraría el pool vinculado al staking a su saldo previo al incidente y devolvería a los delegadores sus posiciones de staking registradas. También eliminaría los 65.1 millones de TAC congelados en direcciones vinculadas al atacante cuando la red se detuvo. El déficit de mercado restante se cubriría con aproximadamente 1.258 mil millones de TAC de las reservas de tesorería de la TAC Foundation. Esa cantidad corresponde a la porción vendida a través de BNB Chain y TON, que no puede eliminarse onchain sin revertir los saldos de los compradores del mercado abierto.

Ninguno de estos pasos se ha completado. Primero, los validadores deben adoptar el software parcheado, ejecutar la edición de estado y reanudar la producción de bloques, mientras TAC no ha anunciado una fecha de reinicio.

Los holders de BNB Chain aún no tienen una respuesta final

Otros 1.662 mil millones de TAC permanecen en direcciones asociadas con el atacante en BNB Chain. El puente está deshabilitado en ambas direcciones, lo que significa que el TAC en BNB actualmente no puede canjearse contra los tokens nativos bloqueados en TAC. El saldo pendiente es mayor que la cantidad ya vendida y sigue siendo la principal parte no resuelta de la recuperación. Restaurar el staking pool no decide cómo se tratarán esos tokens espejados cuando las transferencias entre cadenas se reanuden eventualmente.

TAC está trabajando con plataformas de negociación y proveedores de infraestructura, pero no ha publicado el mecanismo, el momento ni la acción requerida para los holders de BNB Chain. Hasta que esos términos se definan, el proyecto indicó a los usuarios que no operen TAC en BNB Chain porque hacerlo implica riesgo de pérdida.

Los stakers no necesitan presentar un reclamo

Los delegadores no están obligados a registrarse, presentar evidencia ni conectar una wallet. El plan de recuperación usaría los registros de staking capturados antes del incidente para restaurar los saldos a nivel de protocolo una vez que la red se reanude.

Los holders en la red TAC detenida deben esperar un anuncio oficial de reinicio. TAC dice que no se requiere ninguna acción de los usuarios que tienen su token en TON o Ethereum, mientras que los activos distintos de TAC en la red nativa no se vieron afectados por el ataque. La recuperación crea una oportunidad para estafas de suplantación. TAC afirma que nunca pedirá a los usuarios visitar un sitio externo de reclamo, conectar una wallet o enviar fondos para recibir tokens restaurados. Cualquier mensaje que haga esa solicitud debe considerarse fraudulento.

El control faltante estaba antes del bridge

Los controles de TAC confirmaron que los saldos de tokens nativos y espejados coincidían. El exploit tuvo éxito porque esa verificación comenzó después de que la red ya había aceptado activos robados como colateral válido.

Los controles de coincidencia de saldos pueden identificar la falta de respaldo, pero no pueden proteger las cuentas que lo suministran. El parche de TAC aborda ese punto anterior al impedir que se cree el saldo inválido antes de que pueda llegar al bridge.

Aviso legal: Este artículo tiene fines informativos únicamente y no constituye asesoramiento financiero ni de inversión.

La publicación Blockchain Hack Drains 28.6% of TAC Supply From Staking Pool apareció primero en Coindoo.