Revisé otra vez la reexplicación del incidente de puente “@Dusk ” que se hizo público; lo más impactante no es que el atacante haya usado una vulnerabilidad tan compleja, sino que en realidad no necesitaba romper el consenso.
El 16 de enero, una wallet de firma utilizada para el servicio de puente Dusk a EVM fue accedida sin autorización. Las cuatro sustracciones listadas oficialmente sumaron 10,910,010 DUSK, y parte de esos fondos volvió a ir a BSC; luego hubo otro intento de puente de 8,910,000 DUSK que falló porque el servicio fue desactivado. La clasificación oficial es muy clara: no es que el consenso de Dusk haya fallado, ni que hubiera una vulnerabilidad en el protocolo subyacente; es que se comprometió la ruta de la clave de la wallet del puente.
Esta frase es correcta técnicamente, pero los activos del usuario no pierden valor solo porque el accidente se considere “capa de aplicación”.
La arquitectura antigua comprimía la wallet de firma, el procesamiento de eventos y la conexión de red en una misma ruta operativa. Por fuera parecía liviano, rápido y fácil de mantener; pero una vez que se obtiene el control del permiso de firma, el atacante también consigue una capacidad de liberación de fondos demasiado grande al mismo tiempo. #dusk La “matrícula” que se pagó realmente en esta ocasión es que, si el puente solo tiene que conectarse a liquidez real, ya entra en el límite de seguridad de activos; no puede esconderse tras el argumento de que “el propio protocolo funciona normalmente”.
La conversión posterior, por cierto, es bastante concreta: se separan la firma y el procesamiento de eventos; primero se confirma el evento EVM, se ingresa a la base de datos y se pone en cola, y luego un worker independiente lo procesa según una máquina de estados. Las transacciones se marcan como seen, submitted, completed, failed o stuck. Antes de difundir la transacción original, se persiste; al reintentar, se reenvía la misma, en vez de reconstruirla. En el extremo de firma en caliente solo se deja el saldo necesario para la operación reciente; si falta, se pausa, y la wallet en frío se completa manualmente.
Dicho en simple: antes era como si una sola persona tuviera al mismo tiempo la tarjeta de acceso, el libro contable y el sello de pago; ahora finalmente se separa la aceptación, el registro y el desembolso en ventanillas distintas, y a cada ventanilla se le pone un límite.
Pero no voy a eliminar el riesgo solo porque “se complete la reconstrucción”. $DUSK A partir de ahora, hay que demostrarlo con datos públicos: ¿cuán bajo es el tope de la wallet caliente?, ¿cuánto tiempo tarda en detenerse ante una anomalía?, ¿cómo se concilia el cúmulo de transacciones?, ¿si los permisos de firma tienen auditoría independiente?, ¿si los usuarios pueden verificar por su cuenta el estado de cada transacción.
Lo que más teme el puente no es que el código no sea lo suficientemente elegante, sino que una filtración de credenciales permita tocar todo el dinero del pool. La reparación verdaderamente confiable no es la explicación por niveles después del incidente, sino diseñar de modo que el próximo fallo de un solo punto solo cause daños limitados, rastreables y con capacidad de cerrarse rápidamente.
$DOLO $AIO
El 16 de enero, una wallet de firma utilizada para el servicio de puente Dusk a EVM fue accedida sin autorización. Las cuatro sustracciones listadas oficialmente sumaron 10,910,010 DUSK, y parte de esos fondos volvió a ir a BSC; luego hubo otro intento de puente de 8,910,000 DUSK que falló porque el servicio fue desactivado. La clasificación oficial es muy clara: no es que el consenso de Dusk haya fallado, ni que hubiera una vulnerabilidad en el protocolo subyacente; es que se comprometió la ruta de la clave de la wallet del puente.
Esta frase es correcta técnicamente, pero los activos del usuario no pierden valor solo porque el accidente se considere “capa de aplicación”.
La arquitectura antigua comprimía la wallet de firma, el procesamiento de eventos y la conexión de red en una misma ruta operativa. Por fuera parecía liviano, rápido y fácil de mantener; pero una vez que se obtiene el control del permiso de firma, el atacante también consigue una capacidad de liberación de fondos demasiado grande al mismo tiempo. #dusk La “matrícula” que se pagó realmente en esta ocasión es que, si el puente solo tiene que conectarse a liquidez real, ya entra en el límite de seguridad de activos; no puede esconderse tras el argumento de que “el propio protocolo funciona normalmente”.
La conversión posterior, por cierto, es bastante concreta: se separan la firma y el procesamiento de eventos; primero se confirma el evento EVM, se ingresa a la base de datos y se pone en cola, y luego un worker independiente lo procesa según una máquina de estados. Las transacciones se marcan como seen, submitted, completed, failed o stuck. Antes de difundir la transacción original, se persiste; al reintentar, se reenvía la misma, en vez de reconstruirla. En el extremo de firma en caliente solo se deja el saldo necesario para la operación reciente; si falta, se pausa, y la wallet en frío se completa manualmente.
Dicho en simple: antes era como si una sola persona tuviera al mismo tiempo la tarjeta de acceso, el libro contable y el sello de pago; ahora finalmente se separa la aceptación, el registro y el desembolso en ventanillas distintas, y a cada ventanilla se le pone un límite.
Pero no voy a eliminar el riesgo solo porque “se complete la reconstrucción”. $DUSK A partir de ahora, hay que demostrarlo con datos públicos: ¿cuán bajo es el tope de la wallet caliente?, ¿cuánto tiempo tarda en detenerse ante una anomalía?, ¿cómo se concilia el cúmulo de transacciones?, ¿si los permisos de firma tienen auditoría independiente?, ¿si los usuarios pueden verificar por su cuenta el estado de cada transacción.
Lo que más teme el puente no es que el código no sea lo suficientemente elegante, sino que una filtración de credenciales permita tocar todo el dinero del pool. La reparación verdaderamente confiable no es la explicación por niveles después del incidente, sino diseñar de modo que el próximo fallo de un solo punto solo cause daños limitados, rastreables y con capacidad de cerrarse rápidamente.
$DOLO $AIO