El indexador Kasplex KRC-20, con su función «Signature Bypass», agota dos reservas de tokens

Cinco transacciones, sin clave privada

Se supone que una clave privada es la línea divisoria entre ser propietario de 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 en absoluto la cadena base de Kaspa.

El atacante transfirió 186 425 259 ZEAL y 54 397 983 246 NACHO desde una dirección de custodia del puente, a pesar de que no controlaba su clave privada. A continuación, esos tokens se reenviaron a la misma dirección de custodia como depósitos normales del puente, se acuñaron en la capa EVM de Igra Labs y en Kasplex L2, y se vertieron en los fondos de liquidez de Zealous Swap.

Cuando todo se calmó, los saldos de ZEAL y NACHO en L2 del atacante estaban vacíos, mientras que los fondos afectados habían perdido entre el 94 % y el 99,6 % de su valor en KAS. Aquí está el quid de la cuestión: la capa uno (L1) de Kaspa hizo exactamente lo que se suponía que debía hacer.

Una firma vacía que, aun así, fue aceptada

La propiedad de los tokens KRC-20 no viene impuesta directamente por el consenso de Kaspa. Las instrucciones de los tokens se incluyen en las transacciones de Kaspa, mientras que un indexador de Kasplex fuera de cadena lee dichas instrucciones y determina quién es el propietario de qué. Normalmente, una transferencia KRC-20 contiene una clave pública, instrucciones de los tokens y una firma válida. El atacante mantuvo esa estructura habitual, pero proporcionó una firma vacía y añadió un OP_NOT después de OP_ENDIF.

Una firma vacía hace que OP_CHECKSIG devuelva «false» en lugar de rechazar la transacción de inmediato. El OP_NOT adicional invirtió ese resultado a «true», lo que dejó a Kaspa con una transacción válida. En la capa de consenso no se produjo ningún fallo. El indexador fue otra historia. Reconoció el sobre KRC-20, pero no exigió que el script se ajustara exactamente al formato canónico. En consecuencia, consideró legítima la transferencia falsificada. La propia API de Kasplex incluso devolvió «opAccept: 1» en la primera transacción ZEAL falsificada.

Cualquiera podía crear la falsificación

El giro más perverso 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. Eso significa que trasladar los tokens a otra dirección no resuelve el problema subyacente. Hasta que se corrija el indexador y se reindexe su historial, el mismo fallo puede utilizarse, en teoría, contra saldos KRC-20 en otros lugares.

Cinco transacciones falsificaron las transferencias de ZEAL y NACHO. En cambio, nueve pequeñas retiradas de una unidad fueron firmadas genuinamente por el servicio de custodia y parecen haber sido pruebas para comprobar si la vía de salida funcionaba. Curiosamente, las transacciones legítimas fueron las de menor cuantía. El monedero de custodia contenía aproximadamente otros 50 tokens KRC-20. El atacante eligió dos.

Los tokens siguen ahí, pero no así su respaldo

El domingo por la mañana, Igra afirmó que se habían sustraído todas las tenencias de ZEAL y NACHO de la cartera de custodia, dejando 97 651 212 ZEAL y 42 570 879 908 NACHO en las redes de Capa 2 sin respaldo completo de la Capa 1. Otros 4 500 millones de NACHO quedaron en manos del atacante en L1.

Igra suspendió las salidas de iKAS hacia Kaspa L1 y las transferencias a Hyperlane, al tiempo que se advirtió a los usuarios que no realizaran puentes con tokens KRC-20, no compraran ZEAL o NACHO en los intercambios descentralizados (DEX) de la capa 2 ni añadieran liquidez a los fondos comunes afectados. Se indicó que los activos nativos de KAS, el consenso de Kaspa y los activos de Igra que no fueran tokens KRC-20 puenteados no se vieron afectados. Corregir el software por sí solo no bastará para solucionar el problema. Zealous Swap afirma que los operadores deben aplicar un parche al indexador y reindexar su historial, rechazando las firmas vacías, las etiquetas malformadas y los scripts que continúan más allá de OP_ENDIF. Nacho the Kat, por su parte, afirma que la comunidad tiene la intención de avanzar hacia el estándar KCC-20, diseñado para incorporar las reglas de los tokens en scripts que la propia red se encarga de hacer cumplir.

Este problema se suma a una serie de vulnerabilidades, errores, ataques y filtraciones de datos ocurridos en las últimas semanas. El sábado, Blink Wallet, proveedor de infraestructura custodial y no custodial de Lightning Network, reveló que se habían vaciado «unas pocas docenas» de cuentas custodiales. La empresa de ciberseguridad DCENT también ha sufrido esta semana el vaciado de las carteras de la aplicación DCENT App Wallets. Esto ocurre en un momento en el que los ataques de ciberseguridad se han intensificado, y hay quien sospecha que la IA está contribuyendo a esta oleada de atacantes.