Análisis Técnico del Hackeo al Puente Wormhole: Explotación de $326M

El 2 de febrero de 2022, el puente de tokens Wormhole perdió 120,000 wETH — aproximadamente $326 millones en ese momento — en lo que sigue siendo una de las mayores explotaciones de contratos inteligentes en la historia de DeFi. El ataque no requirió llaves robadas, ingeniería social ni control mayoritario de la red de validadores Guardian. Requirió una sola cosa: una API obsoleta del programa de Solana que no verificaba desde qué cuenta estaba leyendo.

Entender esta explotación es esencial para todos los equipos que construyen sobre Solana, para cada protocolo que depende de mensajería cross-chain y para cualquier auditor que revise programas de Solana. La causa raíz fue una falla de verificación en el contrato inteligente del programa puente Wormhole en Solana — no una compromisión de llaves ni una falla en la red Guardian. Las llaves Guardian nunca fueron tocadas. El propio código del puente le otorgó al atacante una autorización que nunca debería haber concedido.

¿Cuál fue la vulnerabilidad técnica principal en el hackeo de Wormhole?

La vulnerabilidad residía en la instrucción verify_signatures del programa puente en Solana de Wormhole (bridge.so). Esta función era responsable de verificar que una cuenta SignatureSet — que contenía firmas Ed25519 o Secp256k1 de nodos Guardian — representaba un consenso genuino antes de autorizar una Verifiable Action Approval (VAA).

La falla: verify_signatures usaba la función obsoleta solana_program::sysvar::instructions::load_instruction_at para comprobar que una instrucción de pre-verificación Secp256k1 había sido llamada antes en la misma transacción. La variante obsoleta no valida que la cuenta pasada sea realmente el sysvar de instrucciones de Solana (Sysvar1nstructions1111111111111111111111111). Lee de cualquier cuenta que esté en el índice nombrado — incluyendo una cuenta controlada totalmente por el atacante.

Por lo tanto, un atacante puede pasar una cuenta fabricada que imite la estructura del sysvar de instrucciones, pre-cargada con datos de firmas controlados por el atacante sobre una carga útil elegida por él. La función lee esos datos falsos, encuentra la llamada Secp256k1 “presente” (en un contexto completamente diferente), marca la VAA como aprobada por Guardian y retorna éxito.

Con una VAA aprobada fraudulentamente, el atacante invocó complete_wrapped, que confía en la aprobación VAA del programa puente para autorizar la acuñación de activos envueltos en Solana. El resultado: 120,000 wETH acuñados sin ningún ETH bloqueado en Ethereum.

Una solución — remplazando load_instruction_at por load_instruction_at_checked, que impone que la cuenta sea realmente el sysvar de instrucciones — ya había sido incorporada en el repositorio GitHub de Wormhole antes del exploit, pero no se había desplegado aún en mainnet.

¿En qué se diferenció la explotación de Wormhole de otros ataques a puentes como Ronin?

El hackeo al puente Ronin (marzo 2022, ~$625M) se menciona frecuentemente junto a Wormhole en discusiones sobre fallas de seguridad en puentes. Son modos de falla fundamentalmente distintos.

Wormhole fue un bug de verificación en contrato inteligente en el programa puente Solana. La red Guardian — un esquema de umbral con 19 nodos — nunca fue comprometida. El atacante la eludió completamente al explotar que verify_signatures nunca verificaba de qué cuenta estaba leyendo. Las llaves Guardian estaban intactas, la red operativa, y todo era irrelevante: el código nunca consultó el verdadero consenso Guardian.

Ronin fue un robo operacional de llaves. Sky Mavis operaba cinco de los nueve nodos validadores de Ronin. En noviembre 2021, Axie DAO delegó temporalmente la autoridad de firma a Sky Mavis para manejar la carga de transacciones. La delegación no fue revocada al expirar. Un atacante — atribuido luego al Grupo Lazarus — comprometió sistemas internos de Sky Mavis y obtuvo acceso a cuatro llaves validadoras. Usando la delegación aún activa, adquirieron la quinta firma vía el nodo RPC sin gas de Sky Mavis. Con cinco de nueve firmas válidas, enviaron mensajes legítimos de retiro al contrato puente Ronin. No se explotó ningún bug de contrato inteligente. El puente hizo exactamente lo que debía al recibir cinco firmas válidas: autorizó retiradas.

Paso a paso: cómo se ejecutó el exploit de Wormhole

1. Falsificación de cuenta. El atacante creó una cuenta Solana imitando la estructura esperada en la posición SignatureSet en los datos de instrucción del programa puente Wormhole. Esta cuenta contenía firmas controladas por el atacante — firmas Ed25519/Secp256k1 válidas, pero sobre una carga VAA elegida por el atacante que autorizaba la acuñación de 120,000 wETH a su dirección Solana.

2. Bypass mediante la API sysvar obsoleta. El atacante envió una transacción llamando a verify_signatures del programa puente Solana. El programa invocó load_instruction_at — la variante obsoleta y sin chequeo — para confirmar que una instrucción Secp256k1 había sido llamada antes en la misma transacción. load_instruction_at lee de cualquier cuenta en el índice nombrado sin validar que sea el sysvar real (Sysvar1nstructions1111111111111111111111111).

3. Prueba falsificada aceptada. verify_signatures evaluó las firmas almacenadas en la cuenta controlada por el atacante, las encontró criptográficamente válidas (el atacante las firmó a sí mismo, sobre su propia carga útil), y marcó la VAA como aprobada por Guardian. La red Guardian nunca fue consultada.

4. Acuñación autorizada. El atacante invocó complete_wrapped con la VAA ahora aprobada. El programa puente, confiando en el estado de aprobación de la VAA, acuñó 120,000 wETH en Solana a la dirección del atacante.

5. Extracción cross-chain. El atacante puenteó los wETH acuñados de vuelta a Ethereum mediante el flujo legítimo cross-chain de Wormhole — los wETH existían en la wallet Solana del atacante, así que el puente procesó el retiro como una transferencia normal. Los $326M en wETH sin respaldo aterrizaron en Ethereum, donde el atacante los convirtió a ETH y stablecoins para sacar fondos. Jump Crypto, empresa matriz de Wormhole, repuso los 120,000 ETH robados desde sus propias reservas para resarcir a los usuarios del puente.

Lecciones técnicas críticas para programas Solana y puentes cross-chain

1. Cada AccountInfo pasado a un programa Solana está controlado por el atacante hasta que se demuestre lo contrario.

Esta es la regla fundamental de seguridad en programas Solana. Un programa debe validar owner, key y — donde aplique — executable y is_signer de cada cuenta que recibe. La función obsoleta load_instruction_at aceptaba cualquier cuenta colocada en el índice nombrado. El reemplazo moderno, load_instruction_at_checked, impone que la cuenta sea realmente el sysvar de instrucciones antes de leer de ella. La metodología de auditoría Solana de Soken marca cualquier uso de sysvar no-_checked como hallazgo Crítico, sin importar el contexto.

2. Separación de privilegios entre verificación de firmas y acuñación de activos.

La autoridad de acuñación del puente debe estar detrás de un módulo de verificación que recalcule la prueba desde un estado canónico, propiedad del programa — no desde cuentas suministradas por el llamante. Cuando verify_signatures acepta una cuenta controlada por el atacante como verdad, la separación entre “¿lo aprobó la red?” y “¿podemos acuñar?” colapsa completamente. La instrucción de acuñación debe derivar la autorización desde estado que el programa mismo escribió tras verificar la entrada real de Guardian.

3. La protección contra repetición de VAA debe hacerse on-chain.

Incluso si el SignatureSet hubiera sido auténtico, complete_wrapped debería rechazar VAAs cuyo hash ya haya sido consumido. Wormhole añadió protección contra repetición en versiones posteriores, pero la ausencia en la versión explotada significaba que una VAA aprobada fraudulentamente podría haberse reutilizado repetidamente. Cada acción de puente debe estar condicionada a un mapeo de VAAs consumidos (processed_vaas: mapping[bytes32, bool]) actualizado atómicamente al inicio de la ejecución.

4. Uso de API obsoletas es un hallazgo Crítico en auditoría.

La vulnerabilidad de Wormhole provenía de una deprecación conocida. El SDK de Solana había marcado a load_instruction_at como obsoleto y proporcionado la versión _checked antes del exploit. La falta de migración de una API obsoleta no es un problema de calidad de código — es una brecha crítica de seguridad que los atacantes buscan activamente leyendo changelogs y comparando commits no desplegados contra código desplegado. Las auditorías en programas Solana deben barrer solana_program::sysvar::instructions::* buscando variantes no-_checked y fallar si encuentran alguna. Esto es práctica estándar en auditorías post-2022 en Ottersec, Halborn y Soken.

5. Las correcciones de seguridad no desplegadas son mapas públicos para ataques.

La corrección que usa load_instruction_at_checked ya estaba comprometida en el repositorio público de Wormhole antes del exploit. Un atacante sofisticado que monitorea repositorios de protocolos objetivo para commits relevantes de seguridad — especialmente los que cambian API obsoletas por sus equivalentes chequeados — puede reconstruir la vulnerabilidad solo con la diferencia. Las pipelines de despliegue para programas críticos de seguridad deben tratar la ventana entre “merge en main” y “despliegue en mainnet” como un período de exposición activa. Los procedimientos de despliegue de emergencia deben cerrar esa ventana en horas, no días.

6. La multisig de umbral no compensa fallas en validación de cuentas.

La red Guardian de Wormhole estaba compuesta por 19 nodos independientes con esquema de firma umbral. Era robusta. Era completamente irrelevante para este ataque. El exploit evitó toda la capa de consenso manipulando qué cuenta leía verify_signatures. Las firmas umbral protegen contra compromisos de llave Guardian; no protegen contra un bug que nunca solicita entrada a los Guardianes. La defensa en profundidad requiere que cada capa del modelo de seguridad sea efectivamente invocada — un control evitado no es control.

Qué significa esto para auditorías de puentes y seguridad de programas Solana

El exploit Wormhole demuestra que la seguridad de puentes cross-chain es un problema de múltiples capas. La red Guardian puede ser criptográficamente sólida, los incentivos económicos correctos y la arquitectura del protocolo bien diseñada — y una sola llamada a una función obsoleta en el programa on-chain puede dejar todo eso nulo.

Para equipos construyendo sobre Solana, la lección sobre validación de cuentas es general: trate cada parámetro pasado a su programa como entrada hostil. Valide propietario, clave, discriminador y longitud de datos antes de operar con cualquier cuenta. Use el envoltorio Account<T> del framework anchor o equivalente para hacer obligatorias estas verificaciones a nivel de tipo en lugar de confiar en aserciones manuales.

Para arquitectos de puentes, la lección es separación de privilegios y anclaje en estado canónico. La autoridad de acuñación debe trazarse a estado propiedad del programa que el propio programa validó — no a pruebas suministradas por llamante que el programa aceptó sin validación.

Soken audita cada programa Solana buscando uso de APIs sysvar obsoletas, falta de chequeo del propietario de la cuenta y brechas en protección de repetición VAA como elementos de prioridad Crítica. El patrón Wormhole — evitar un multisig umbral manipulando la cuenta que lee una función de verificación — es ahora una clase de ataque nombrada en nuestra metodología de auditoría Solana. Si su protocolo usa mensajería cross-chain o acuñación de activos envueltos, contáctenos en soken.dev/services-it.html para discutir una revisión de seguridad antes del despliegue.