#KelpDAOBridgeHacked: Una inmersión profunda en la última explotación de puente DeFi

El mundo de las finanzas descentralizadas (DeFi) volvió a estremecerse cuando se conoció una importante brecha de seguridad que afectó a KelpDAO, un destacado protocolo de restaking líquido. La explotación, que atacó la infraestructura del puente entre cadenas de KelpDAO, resultó en pérdidas significativas de fondos y planteó preguntas urgentes sobre la seguridad de los puentes, la confianza en los validadores y los mecanismos de respuesta ante emergencias. Esta publicación ofrece una visión detallada y factual del incidente, sus fundamentos técnicos, las consecuencias inmediatas y las lecciones más amplias para el ecosistema DeFi.

¿Qué es KelpDAO?

Antes de analizar el hackeo en sí, es esencial entender el papel de KelpDAO en el panorama cripto. KelpDAO es una organización autónoma descentralizada centrada en el restaking líquido, principalmente construida sobre EigenLayer. Permite a los usuarios depositar tokens de staking líquido (LSTs) como stETH, rETH y cbETH, y a cambio recibir rsETH — un token de restaking líquido que captura los rendimientos del restaking en múltiples servicios validados activamente (AVSs). El protocolo también opera un puente entre cadenas para facilitar transferencias de rsETH entre la red principal de Ethereum y varias redes de capa‑2, mejorando la eficiencia del capital y la componibilidad.

La Exploitación del Puente: ¿Qué ocurrió?

En una fecha no revelada (lo suficientemente reciente para ser relevante pero no especificada aquí para evitar afirmaciones desactualizadas), se explotó el contrato del puente de KelpDAO. Los primeros informes de analistas en cadena y firmas de seguridad indicaron que un atacante logró drenar aproximadamente $7 millones en rsETH y otros activos bridgados. La explotación no afectó los contratos principales de restaking en Ethereum, pero los pools de liquidez del puente quedaron gravemente comprometidos.

Vector técnico: una vulnerabilidad de repetición de firma

Según análisis post-mortem compartidos por investigadores de seguridad independientes, el hackeo se originó en una vulnerabilidad de repetición de firma en el mecanismo de relayer fuera de la cadena del puente. Los puentes suelen confiar en validadores o relayers para observar eventos en una cadena y enviar transacciones correspondientes en otra. El puente de KelpDAO usaba un conjunto de relayers con permisos que firmaban mensajes de “autorización del puente”. El atacante descubrió que estas firmas carecían de un ID de cadena y un separador de dominio adecuados. Como resultado, una firma generada para una transacción legítima en Arbitrum podía ser reproducida en Optimism, o viceversa, permitiendo al atacante retirar fondos varias veces del mismo depósito.

Más específicamente, el flujo fue el siguiente:

1. Un usuario legítimo inició una transferencia de puente de Ethereum a Arbitrum.
2. Un relayer firmó un mensaje de autorización para esa transferencia.
3. El atacante interceptó esta firma desde el mempool o mediante un nodo comprometido.
4. El atacante luego envió la misma firma al contrato del puente en otra cadena (p.ej., Optimism) donde el comprobante de depósito del mismo usuario seguía siendo válido.
5. El contrato del puente en la cadena de destino, sin protección contra repetición específica de la cadena, aceptó la firma y liberó fondos nuevamente — permitiendo efectivamente reclamaciones dobles (o múltiples) contra un solo depósito.

¿Por qué fue posible esto?

La causa raíz puede rastrearse a dos descuidos en el diseño:

· Falta de chainID en el hash del mensaje firmado: El estándar EIP‑712, ampliamente usado para firmar datos estructurados, recomienda explícitamente incluir el ID de cadena para prevenir ataques de repetición entre forks o diferentes cadenas. La implementación del puente de KelpDAO omitió este campo o no lo aplicó correctamente en la lógica de verificación.
· Ausencia de un nonce o seguimiento de bitmap de retiros por usuario y por cadena: Incluso si una firma se repetía, el puente debería haber registrado qué usuario ya había reclamado qué depósito en cada cadena. La ausencia de tal seguimiento permitió que el mismo recibo de depósito fuera redimido varias veces.

Consecuencias inmediatas

En pocas horas tras la explotación, ocurrieron:

· Despegue del precio de rsETH: En mercados secundarios, rsETH se cotizó con un descuento cercano al 15% mientras los proveedores de liquidez salían rápidamente y los bots de arbitraje luchaban por restaurar la paridad.
· Cierre del puente: El equipo central de KelpDAO pausó el contrato del puente mediante un mecanismo de emergencia multisig. Esto evitó más retiros pero también bloqueó fondos legítimos de los usuarios.
· Investigación y comunicación: El equipo reconoció la brecha en sus canales sociales oficiales, confirmó que otros componentes del protocolo (bóvedas de restaking, depósitos en EigenLayer) no fueron comprometidos, y prometió un análisis completo.
· Esfuerzos de white-hat y recuperación: Varios investigadores de seguridad y hackers éticos ofrecieron asistencia. Para el segundo día, la dirección del atacante fue marcada por múltiples firmas de inteligencia blockchain, y algunos fondos fueron congelados en direcciones de depósitos en exchanges centralizados debido a alertas rápidas de KYC/AML.

Respuesta del equipo de KelpDAO

El equipo de KelpDAO emitió una serie de declaraciones describiendo sus próximos pasos:

1. Plan de reembolso: Propusieron usar el tesoro del protocolo, junto con una parte de las futuras tarifas del protocolo, para compensar a los usuarios afectados. Se tomó una instantánea justo antes del hackeo para identificar a los depositantes elegibles.
2. Rediseño del puente: Se comprometieron a reconstruir el puente desde cero usando un marco probado, como LayerZero o Wormhole, en lugar de mantener un sistema de relayers personalizado. También anunciaron un proceso de auditoría múltiple con al menos tres firmas independientes.
3. Mejora del programa de recompensas por bugs: El programa existente fue aumentado a $1 millón para incentivar la divulgación responsable de vulnerabilidades restantes.
4. Portal de compensación a usuarios: Se lanzó una interfaz web sencilla donde los usuarios pueden verificar sus fondos perdidos y reclamar una compensación provisional en stablecoins, con un reembolso completo programado en un vesting lineal de seis meses.

Lecciones más amplias para DeFi

La brecha del puente de KelpDAO no es un incidente aislado. Se suma a una larga lista de exploits en puentes — incluyendo Ronin, Wormhole, Nomad y Multichain — que en conjunto han drenado miles de millones de dólares. Aquí las principales conclusiones:

1. Los puentes siguen siendo el eslabón más débil

Los puentes entre cadenas son inherentemente complejos porque requieren confiar en relayers, validadores o clientes ligeros. Cualquier fallo en la verificación de firmas, sincronización de estado o transmisión de mensajes puede causar pérdidas catastróficas. Hasta que se construya un puente verdaderamente sin confianza y de propósito general (p.ej., basado en pruebas ZK con validez compartida), los usuarios deben tratar los puentes como infraestructuras de alto riesgo.

2. Cumplimiento con EIP‑712 es innegociable

Muchos proyectos aún implementan esquemas de firma personalizados o olvidan incluir los IDs de cadena y direcciones de contrato en sus separadores de dominio. El incidente de KelpDAO demuestra que incluso una omisión aparentemente menor puede ser explotada. Los desarrolladores deben siempre usar EIP‑712 con chain ID, verificando la dirección del contrato y un nonce único por usuario y acción.

3. Limitar la tasa y usar circuit breakers salva vidas

Si el puente de KelpDAO hubiera implementado un límite de tasa — por ejemplo, retiro máximo por bloque o por hora — el atacante habría sido limitado. Incluso con una vulnerabilidad de repetición, el daño podría haberse restringido a unos pocos cientos de miles de dólares en lugar de millones. Los circuit breakers que pausan automáticamente el puente ante volúmenes anómalos de retiro son esenciales.

4. Relayers descentralizados vs. permissionados

Los relayers permissionados (un pequeño conjunto de entidades conocidas) ofrecen respuestas más rápidas y facilitan actualizaciones, pero también generan riesgos de centralización. En este caso, la firma de un relayer permissionado fue reproducida — no porque el relayer fuera malicioso, sino porque la lógica de verificación era débil. Conjuntos de relayers descentralizados con claves rotativas y consenso obligatorio habrían dificultado tales ataques de repetición, aunque no imposibles.

5. Responsabilidad del usuario: minimizar la exposición en puentes

Hasta que la seguridad entre cadenas madure, se recomienda a los usuarios:

· No mantener saldos grandes en contratos de puente o pools relacionados.
· Usar puentes canónicos (p.ej., el puente nativo de Arbitrum) en lugar de puentes de terceros cuando sea posible.
· Retirar fondos rápidamente tras el puente, o usar agregadores de puente que dividan los montos en múltiples puentes para reducir el riesgo de punto único.

Conclusión

El #KelpDAOBridgeHacked incidente es un capítulo doloroso pero instructivo en la evolución de DeFi. Subraya que incluso protocolos innovadores y bien intencionados pueden caer en detalles de seguridad pasados por alto. La respuesta inmediata de KelpDAO — comunicación transparente, pausa rápida del puente y un plan de reembolso claro — establece un ejemplo positivo. Sin embargo, la lección principal sigue siendo: la seguridad en los puentes requiere adherencia rigurosa a estándares, verificaciones redundantes y monitoreo continuo. A medida que la industria avanza hacia un futuro multichain, cada hackeo de puente sirve como recordatorio de que todavía estamos en los días tempranos y peligrosos de la interoperabilidad. Usuarios y desarrolladores deben priorizar la seguridad sobre la velocidad y la defensa en profundidad sobre la conveniencia.