Los agentes de inteligencia artificial de Alpen Labs reprodujeron en aproximadamente una hora el fallo que permitió extraer unos 3.996 BTC de Liquid, una cantidad valorada entonces en cerca de 320 millones de dólares. La demostración, sin embargo, fue posterior al ataque y no demuestra que un sistema de vigilancia basado en IA hubiera detectado el problema antes de que el dinero saliera de la sidechain.
Una prueba de rango que podía recibir la respuesta equivocada
Liquid es una sidechain de Bitcoin en la que los L-BTC representan bitcoins depositados en una reserva controlada por una federación. El 6 de septiembre, la red aceptó L-BTC que no tenían respaldo en bitcoin. Una retirada autorizada convirtió ese estado inválido en un pago real desde la reserva: los firmantes de la federación liberaron aproximadamente 3.996 BTC.
Según el análisis publicado el 22 de septiembre por Simanta Gautam, consejero delegado de Alpen Labs, el origen del fallo estaba en la forma en que Elements, el software sobre el que funciona Liquid, almacenaba en caché las comprobaciones criptográficas de las transacciones confidenciales.
Un cambio introducido el 1 de septiembre pretendía que cada resultado almacenado dependiera de todo el contexto relevante para la verificación, incluido el generador del activo y el script de salida. Alpen sostiene que esos campos se concatenaron como bytes sin codificar sus límites. Como resultado, una prueba válida utilizada para rellenar la caché y otra prueba distinta e inválida podían generar exactamente la misma entrada.
En la reproducción local de Alpen, una verificación nueva rechazaba el objetivo defectuoso. Sin embargo, una vez que la prueba válida había introducido su resultado en la caché, el mecanismo afectado lo aceptaba. La consulta exitosa a la caché evitaba la comprobación de la prueba de rango que debía haber bloqueado la operación.
La compañía describe el resultado como una reproducción local del fallo de consenso sospechado. También introduce cautelas: no tuvo acceso a los binarios exactos de los validadores en producción ni al contenido histórico de las cachés. La ruta concreta por la que se preparó la caché en la red se infirió a partir del código y de las evidencias de la cadena.
El límite de pago habría actuado en otra fase
La secuencia posterior muestra por qué una clave válida no bastaba como barrera de seguridad. Según SideSwap, el atacante envió 4.000 L-BTC a su servicio de retirada a las 14:05 UTC del 6 de septiembre. Un minuto después, SideSwap quemó los tokens con una autorización válida. La orden superaba los fondos disponibles en su propia cartera, por lo que dos intentos de pago fallaron. A las 14:28, los firmantes de la federación liberaron 3.996 BTC.
SideSwap afirma que remitió 3.995,99999857 BTC a la dirección del cliente dentro del mismo bloque de Bitcoin. Su sistema utilizaba una clave de autorización conectada, los pagos eran automáticos y no contaba con controles por tamaño, velocidad, relación con el suministro, historial de la cartera o revisión humana. La federación también firmó una solicitud excepcional después de los dos intentos fallidos.
Un límite de pago, una retención independiente o una aprobación fuera de línea, aplicados antes de la autorización o de la firma de la federación, podrían haber detenido esta ruta concreta incluso después de que Liquid hubiera aceptado el estado inválido. El punto exacto de intervención es relevante: un control previo a la firma podría haber evitado la salida de fondos de la reserva, mientras que una revisión manual posterior habría dejado los bitcoins bajo control de SideSwap para una eventual devolución, pero no habría impedido la transferencia inicial de la federación.
Correcciones y una cuestión aún abierta
El 8 de septiembre, Elements modificó las claves de la caché para codificar la longitud de los campos, añadió pruebas centradas en colisiones e incorporó una opción para desactivar la caché de las pruebas de rango. La versión 23.3.4 llegó al día siguiente. Estos cambios actúan sobre la validación que debe impedir que unos L-BTC inválidos se conviertan en un estado aceptado por la sidechain.
SideSwap señaló que una compilación privada de seguridad instalada en uno de sus nodos en agosto aceptaba la transacción del ataque, aunque ese dato no permite determinar qué versión utilizaba cada miembro de la federación.
Liquid comunicó el 17 de septiembre que las transacciones ordinarias habían reanudado su actividad, mientras las retiradas seguían suspendidas. El reinicio de los retiros quedaba condicionado a confirmar una cobertura íntegra de bitcoin, completar las actualizaciones de software, realizar pruebas y someter el sistema a revisiones independientes. La cuestión operativa pendiente es si, al reabrir esa función, existirá un control independiente capaz de detener una solicitud autorizada de tamaño excepcional antes de que los bitcoins abandonen la custodia de la federación.
