Durante la semana pasada (2026/05/18 - 2026/05/24), BlockSec identificó múltiples incidentes de ataques en varios ecosistemas blockchain. La tabla a continuación lista 5 incidentes notables con pérdidas totales estimadas de aproximadamente $104.6M.
| Fecha | Incidente | Tipo | Pérdida Estimada |
|---|---|---|---|
| 2026/05/18 | Incidente Verus | Fallo en la Lógica de Negocio | ~$11.7M |
| 2026/05/18 | Incidente EchoProtocol | Clave Privada Comprometida | ~$76.7M |
| 2026/05/20 | Incidente RetoSwap | Fallo en la Lógica de Negocio | ~$2.7M |
| 2026/05/22 | Incidente Polymarket | Clave Privada Comprometida | ~$700K |
| 2026/05/24 | Incidente StablR | Clave Privada Comprometida | ~$12.8M |
Se seleccionan dos incidentes para un análisis en profundidad:
- Verus: el atacante explotó un fallo de validación de tipo en el Puente Verus-Ethereum al enviar una salida de exportación suplementaria artesanal que el puente clasificó erróneamente como una exportación primaria válida. La semántica de los mensajes entre cadenas forma parte de la superficie de ataque.
- RetoSwap: un fallo de autenticación a nivel de protocolo en el flujo de comercio P2P permitió a un atacante secuestrar el rol de árbitro enviando un mensaje ACK falsificado. El atacante comprometió la creación de la billetera multisig completamente fuera de la cadena.
El Mejor Auditor de Seguridad para Web3
Valide el diseño, el código y la lógica de negocio antes del lanzamiento
Destacado de la Semana: Verus
Este incidente se destaca porque el atacante abusó deliberadamente de un tipo de exportación entre cadenas especializado, lo que indica un profundo conocimiento del diseño interno de la cadena Verus. El exploit demuestra que los formatos de mensajes entre cadenas, incluidos los campos de datos suplementarios y los límites de codificación, forman parte de la superficie de ataque y requieren el mismo rigor que la verificación de pruebas criptográficas.
El 18 de mayo de 2026, el Puente Verus-Ethereum, un puente entre cadenas que conecta la cadena Verus L1 y Ethereum, fue explotado por aproximadamente $11.7M en ETH, tBTC y USDC [1][2]. La causa raíz fue un fallo de validación de tipo en la ruta de importación del lado de Ethereum: el contrato del puente aceptó una salida de exportación suplementaria artesanal y la clasificó erróneamente como una exportación primaria válida, lo que permitió al atacante suministrar datos de transferencia coincidentes y vaciar los fondos. Al 23 de mayo, aproximadamente el 75% de los fondos robados habían sido devueltos.
Antecedentes
El Puente Verus-Ethereum libera activos en Ethereum después de que alguien demuestre que existe una exportación calificada del lado de Verus bajo un estado Verus notarizado. Ethereum no observa directamente las transacciones de Verus; depende de los datos de prueba enviados más una notarización que ancla el estado de Verus en el que se confía.
Tres objetos del puente son relevantes para este incidente: una exportación primaria, que es el objeto que Ethereum importa y utiliza para los pagos; una salida de exportación suplementaria, que son datos adicionales adjuntos a la exportación primaria y no están destinados a ser tratados como una exportación activa independiente para fines de pago; y una notarización, que permite a Ethereum demostrar que un objeto específico del lado de Verus existió en el estado finalizado del puente.
Análisis de Vulnerabilidad
Los contratos de puente del lado de Ethereum con errores están desplegados en 0xa045...6fc87f y 0x08f0...d0107d.
La causa raíz fue un fallo de validación de tipo en la ruta de importación de Ethereum. El puente demostró que existía un objeto real del lado de Verus, pero no verificó que el objeto demostrado fuera una exportación primaria válida antes de usarlo para liberar fondos. En cambio, aceptó una salida suplementaria artesanal y la analizó como si fuera una exportación activa normal.
A alto nivel, el flujo vulnerable es:
proveImports(...)
-> verificar prueba
-> verificar keccak256(serializedTransfers) == hash de transferencia comprometido
processTransactions(...)
-> ejecutar pagos en EthereumNinguna verificación en este flujo rechaza objetos con FLAG_SUPPLEMENTAL establecido. La corrección verifica explícitamente este indicador y revierte cuando el objeto demostrado es suplementario:
Análisis del Ataque
El siguiente análisis se basa en la transacción de Ethereum 0x6990f0...87eb321 y la transacción de Verus f899e698...b9f5a733.
-
Paso 1: El 17 de mayo, el atacante financió la dirección de Ethereum
0x5aBb...9D5777con 1ETHa través de Tornado Cash. El 18 de mayo, el atacante obtuvo 0.02VRSCdel faucet de Verus para la direcciónRW9vEW...B3g6zd. -
Paso 2: El atacante envió cuatro transacciones de exportación con destino a Ethereum en Verus que contenían salidas de exportación suplementarias artesanales. Estas salidas suplementarias fueron codificadas para ser analizables sin errores y contenían un compromiso
hashReserveTransfersque coincidía con los pagos fraudulentos que el atacante pretendía ejecutar más adelante. -
Paso 3: Después de que una notarización entre cadenas avanzara lo suficiente en Ethereum, el atacante envió una transacción de importación falsificada en Ethereum. El objeto del lado de Verus demostrado fue la salida suplementaria de la transacción de Verus mencionada anteriormente.
-
Paso 4: El puente de Ethereum aceptó la prueba pero no rechazó el objeto demostrado como datos suplementarios. En cambio, analizó la salida artesanal como si fuera una exportación activa válida. Dado que el atacante también suministró
serializedTransferscuyo hash coincidía con el valorhashReserveTransferscomprometido, el puente continuó a través del flujo de importación. -
Paso 5: Con la salida suplementaria malinterpretada como una exportación válida, las transferencias fraudulentas pasaron las verificaciones del lado de Ethereum. El atacante vació aproximadamente $11.7M en
ETH,tBTCyUSDC. -
Paso 6: Poco después de que la importación maliciosa tuviera éxito, los nodos de Verus encontraron una aserción de estado inválido causada por la coexistencia del hilo de exportación fraudulento y un hilo de exportación real, lo que detuvo la progresión posterior del puente y limitó la explotación subsiguiente.
Conclusión
El incidente fue causado por un fallo de validación de tipo en el Puente Verus-Ethereum: el contrato de Ethereum aceptó una prueba criptográfica real, pero el objeto demostrado era una salida de exportación suplementaria, no una exportación primaria válida para pagos.
Los formatos de mensajes entre cadenas forman parte de la superficie de ataque. Los datos suplementarios, los campos opcionales, las codificaciones compactas y los desplazamientos del analizador deben tratarse con el mismo rigor que las verificaciones de firmas o pruebas de Merkle. Cuando un objeto no coincide con el tipo esperado para la acción que se está ejecutando, el puente debe rechazarlo directamente en lugar de intentar analizarlo.
Referencias
Más Incidentes de Esta Semana
RetoSwap
El 20 de mayo de 2026, RetoSwap, un exchange P2P descentralizado en Monero bifurcado del Protocolo Haveno, fue explotado por aproximadamente $2.7M (7,000 XMR) [1]. La causa raíz fue un fallo de autenticación a nivel de protocolo: el cliente aceptó un mensaje ACK falsificado y fuera de orden, y sobreescribió la dirección Tor almacenada del árbitro con una controlada por el atacante sin verificar al remitente contra la clave pública conocida del árbitro. Esto permitió al atacante secuestrar la creación de la billetera multisig y robar los fondos en cuanto fueron depositados.
Antecedentes
RetoSwap es un exchange P2P descentralizado en Monero, bifurcado del Protocolo Haveno. Su protocolo de comercio se basa en un modelo multisig de árbitro 2 de 3 para asegurar las operaciones y coordina las transacciones fuera de la cadena a través de Tor.
Una operación normal se desarrolla en tres fases: primero, el comprador, el vendedor y el árbitro completan intercambios de mensajes fuera de la cadena para establecer una billetera multisig; segundo, los fondos se bloquean en la billetera multisig solo después de que haya sido completamente creada; tercero, el comprador y el vendedor cofirman una transacción de pago para liquidar, o el árbitro interviene para resolver disputas. Toda la comunicación se realiza a través de Tor, y cada nodo se identifica únicamente por su dirección .onion.
Análisis de Vulnerabilidad
El 20 de mayo, el proyecto Haveno abrió una solicitud de extracción titulada "core: refuse to update node address before multisig created" [2]. Para entonces, RetoSwap ya estaba siendo explotado.
El parche reveló una vulnerabilidad en TradeProtocol.java:onAckMessageAux(...). El cliente identificaba a los pares usando un senderNodeAddress suministrado por el mensaje sin verificar criptográficamente que el remitente coincidiera con la clave pública del árbitro esperado. Un atacante podía enviar un mensaje ACK falsificado que llevara una dirección .onion controlada por el atacante, y el cliente sobreescribiría la dirección del árbitro almacenada con ella.
Dado que esto ocurrió durante la Fase 1 (antes de la creación de la billetera multisig), la dirección del atacante reemplazó la dirección del árbitro real. Por lo tanto, el atacante poseía tanto la clave del comerciante como la clave del árbitro de la billetera multisig, lo que permitía el robo del saldo completo una vez que se depositaran los fondos.
La corrección aborda esto de dos maneras: verifica al remitente contra la clave pública conocida del par, rechazando mensajes de pares no verificados; y condiciona las actualizaciones de dirección a trade.isDepositRequested(), impidiendo sobreescrituras antes de que se cree la billetera multisig.
Análisis del Ataque
No se ha identificado ninguna transacción de ataque en cadena para este incidente. RetoSwap opera completamente a través de Tor con manejo de mensajes fuera de la cadena, por lo que las acciones críticas ocurren fuera de cualquier libro mayor público. La siguiente reconstrucción se basa en el parche disponible públicamente y las comunicaciones oficiales.
-
Paso 1: El atacante se unió a una operación existente como comprador o vendedor.
-
Paso 2: El atacante envió un mensaje ACK falsificado y fuera de orden que parecía provenir del árbitro, llevando una dirección
.onioncontrolada por el atacante comosenderNodeAddress. -
Paso 3: El cliente de la víctima aceptó el mensaje y sobreescribió la dirección almacenada del árbitro sin verificar al remitente contra la clave pública conocida del árbitro.
-
Paso 4: Toda la comunicación posterior destinada al árbitro, incluida la creación de la billetera multisig, fue enrutada al atacante, quien obtuvo la tercera clave multisig.
-
Paso 5: Una vez que el comprador y el vendedor depositaron fondos en la billetera multisig comprometida, el atacante robó el contenido completo de la billetera. El beneficio total ascendió a aproximadamente 7,000
XMR(~$2.7M).
Conclusión
El incidente no fue un fallo criptográfico sino un fallo de autenticación a nivel de protocolo: los mensajes fueron validados como bien formados, pero el remitente no estaba criptográficamente vinculado a una clave pública conocida antes de que se aplicaran las actualizaciones de dirección. Como resultado, el cliente trató un senderNodeAddress no verificado de un mensaje ACK falsificado como el nuevo punto de contacto del árbitro antes de que se creara la billetera multisig, lo que permitió al atacante secuestrar el rol de árbitro.
Las lecciones clave son: (1) cualquier mensaje que actualice la identidad de un par debe ser verificado criptográficamente contra la clave pública conocida del par antes de que se aplique la actualización, y (2) el estado crítico de identidad, como las direcciones de las contrapartes, debe ser inmutable una vez que ha comenzado la fase sensible a la seguridad (p. ej., la creación de la billetera multisig).
Referencias
Acerca de BlockSec
BlockSec es un proveedor integral de seguridad blockchain y cumplimiento de criptomonedas. Desarrollamos productos y servicios que ayudan a los clientes a realizar auditorías de código (incluidos contratos inteligentes, blockchain y billeteras), interceptar ataques en tiempo real, analizar incidentes, rastrear fondos ilícitos y cumplir con las obligaciones AML/CFT, a lo largo del ciclo de vida completo de protocolos y plataformas.
BlockSec ha publicado múltiples artículos de seguridad blockchain en conferencias de prestigio, ha reportado varios ataques de día cero en aplicaciones DeFi, ha bloqueado múltiples hackeos para rescatar más de 20 millones de dólares y ha asegurado miles de millones en criptomonedas.
-
Sitio web oficial: https://blocksec.com/
-
Cuenta oficial de Twitter: https://twitter.com/BlockSecTeam
