Incidente de Seguridad en Kaspa KRC-20
Este fin de semana, un atacante logró extraer 186.4 millones de ZEAL y 54.4 mil millones de NACHO de una billetera puente de Kaspa KRC-20 sin poseer la clave privada correspondiente. Posteriormente, recicló los tokens a través de redes de capa dos (L2) y los vendió en grupos de liquidez.
Lo curioso es que la red de Kaspa en sí no fue hackeada.
Cinco transacciones válidas engañaron a un indexador fuera de la cadena para que reconociera transferencias que en realidad no habían sido firmadas, dejando tokens puenteados sin respaldo y algunos grupos despojados de hasta el 99.6% de su valor en el lado de KAS.
El Método del Atacante
Se supone que una clave privada es la línea divisoria entre poseer criptomonedas y simplemente saber dónde se encuentran. El 20 de septiembre, alguien encontró una forma de eludir esa suposición para los tokens KRC-20 sin romper la cadena base de Kaspa. El atacante movió 186,425,259 ZEAL y 54,397,983,246 NACHO desde una dirección de custodia de puente, a pesar de no controlar su clave privada.
Estos tokens fueron enviados de vuelta a la misma dirección de custodia como depósitos de puente ordinarios, acuñados en la capa EVM de Igra Labs y Kasplex L2, y luego vertidos en grupos de liquidez de Zealous Swap. Al final, los saldos de ZEAL y NACHO del atacante en L2 estaban vacíos, mientras que los grupos afectados habían perdido entre el 94% y el 99.6% de su valor en el lado de KAS.
Detalles Técnicos del Ataque
Aquí está el truco: la capa uno (L1) de Kaspa hizo exactamente lo que se suponía que debía hacer. La propiedad de los tokens KRC-20 no se hace cumplir directamente por el consenso de Kaspa. Las instrucciones del token se encuentran dentro de las transacciones de Kaspa, mientras que un indexador de Kasplex fuera de la cadena lee esas instrucciones y determina quién posee qué.
Normalmente, una transferencia KRC-20 contiene una clave pública, instrucciones del token y una firma válida. El atacante mantuvo esa estructura familiar, pero proporcionó una firma vacía y agregó un OP_NOT después de OP_ENDIF. Una firma vacía hace que OP_CHECKSIG devuelva falso en lugar de anular la transacción de inmediato. El OP_NOT adicional invirtió ese resultado de nuevo a verdadero, dejando a Kaspa con una transacción válida.
No hubo errores en la capa de consenso.
El indexador, en cambio, era otra historia. Reconoció el sobre KRC-20, pero no requería que el script coincidiera exactamente con el formato canónico. Como resultado, acreditó la transferencia falsificada como legítima. La propia API de Kasplex incluso devolvió opAccept: 1 en la primera transacción falsificada de ZEAL.
Consecuencias y Respuesta
El giro más desagradable fue que el atacante no necesitaba descubrir ninguna credencial oculta. Una dirección estándar de Kaspa expone la clave pública necesaria para construir la operación KRC-20 falsificada. Esto significa que mover los tokens a otra dirección no resuelve el problema subyacente. Hasta que el indexador sea corregido y su historia reindexada, la misma falla puede teóricamente ser utilizada contra los saldos KRC-20 en otros lugares.
El domingo por la mañana, Igra anunció que se habían tomado todas las tenencias de ZEAL y NACHO de la billetera de custodia, dejando 97,651,212 ZEAL y 42,570,879,908 NACHO en las redes de Capa 2 sin respaldo completo de L1. Otros 4.5 mil millones de NACHO permanecieron con el atacante en L1.
Igra pausó las salidas de iKAS a Kaspa L1 y las transferencias de Hyperlane, mientras se advertía a los usuarios que no realizaran puentes de tokens KRC-20, compraran ZEAL o NACHO en intercambios descentralizados (DEX) de L2, o añadieran liquidez a los grupos afectados.
Reflexiones Finales
El KAS nativo, el consenso de Kaspa y los activos de Igra que no eran tokens KRC-20 puenteados fueron descritos como no afectados. Arreglar el software por sí solo no limpiará el desorden. Zealous Swap afirma que los operadores necesitan corregir el indexador y reindexar su historia, rechazando firmas vacías, etiquetas mal formadas y scripts que continúan más allá de OP_ENDIF.
Nacho the Kat, mientras tanto, ha indicado que la comunidad tiene la intención de avanzar hacia KCC-20, un estándar diseñado para establecer las reglas de los tokens en scripts aplicados por la propia red. Este problema se suma a una serie de exploits, errores, hacks y filtraciones de datos ocurridos en las últimas semanas.
El sábado, el proveedor de infraestructura custodial y no custodial de Lightning Network, Blink Wallet, reveló que «unas pocas docenas» de cuentas de custodia fueron drenadas. La empresa de ciberseguridad DCENT también vio cómo las billeteras de DCENT App fueron drenadas esta semana. Este contexto se produce en un momento en que los ataques cibernéticos se han intensificado, y algunos sospechan que la inteligencia artificial está asistiendo en esta ola de explotadores.
