~$4M Perdidos: Exploits en Taiko y SecondFi

Durante la semana pasada (2026/06/22 - 2026/06/28), se identificaron 2 incidentes de seguridad notables, con pérdidas confirmadas de aproximadamente $4.1M.

Fecha	Incidente	Tipo	Pérdida estimada
2026/06/22	Taiko	Compromiso de clave y validación incorrecta	~$1.7M
2026/06/23	SecondFi	Fallo en la implementación criptográfica	~$2.4M

Taiko: El atacante combinó una clave de firma de enclave SGX expuesta con una política de atestación incompleta para registrar un prover malicioso como instancia autorizada, demostrando que una atestación válida por sí sola es insuficiente sin una aplicación integral de atributos.
SecondFi: Un fallo en la implementación criptográfica permitió a los atacantes recuperar claves de firma a nivel de dirección usando únicamente datos de transacciones públicas, demostrando cómo una desviación aparentemente menor de la especificación Ed25519 puede llevar al compromiso total de la clave.

Destacado de la semana: Incidente de Taiko

El incidente de Taiko se destaca porque el ataque combinó dos fallos de seguridad independientes (una clave de firma de enclave expuesta y una política de atestación incompleta) para comprometer un sistema de verificación de pruebas basado en SGX. El incidente demuestra que cada capa de una cadena de confianza TEE debe aplicar sus propiedades de seguridad de forma independiente; una cadena de firmas de atestación válida no compensa los atributos de tiempo de ejecución no verificados.

El 22 de junio de 2026, el flujo de verificación de pruebas basado en SGX de Taiko fue explotado en Ethereum, resultando en pérdidas de aproximadamente $1.7M [1]. El atacante utilizó una clave privada de firma de enclave expuesta, que había sido confirmada en un repositorio público de GitHub, para firmar el SIGSTRUCT de un enclave prover lanzado en modo DEBUG. Dado que el contrato de atestación on-chain no rechazaba los enclaves DEBUG, el atacante se registró como una instancia autorizada, envió datos de prueba falsificados y causó que los contratos L1 aceptaran un estado L2 inexistente y liberaran fondos del puente.

Antecedentes

Taiko es un rollup Ethereum Layer-2 con un puente que depende de un sistema de pruebas para decidir si un estado L2 dado o un mensaje cross-chain debe ser aceptado. Como parte de este sistema de pruebas, Taiko utiliza provers SGX: programas off-chain que se ejecutan dentro de enclaves SGX en máquinas físicas que firman los resultados de las pruebas con claves protegidas por el enclave.

Off-chain (máquina física)                  On-chain (Ethereum)
┌─────────────────────────┐                ┌────────────────────────────────────┐
│  SGX Prover Enclave     │                │  SgxVerifier                       │
│  - genera pruebas       │── DCAP quote ─→│  ├─ registerInstance()             │
│  - guarda clave instancia│               │  │  └─ AutomataDcapV3Attestation   │
│                         │── prueba firmada→│  └─ verifyProof()                  │
└─────────────────────────┘                └────────────────────────────────────┘

Descripción general de SGX y DCAP

El concepto central de SGX es el enclave: un entorno de programa aislado por la CPU. MRENCLAVE es la medición del código inicial del enclave, datos, disposición de páginas y metadatos relacionados; puede aproximarse como el hash de la compilación del enclave. MRSIGNER es el hash de la clave pública de firma del enclave y representa la identidad del editor.

La clave privada de firma del enclave firma el SIGSTRUCT de SGX, que contiene metadatos del enclave como MRENCLAVE, ISVPRODID, ISVSVN y ATTRIBUTES. Esta firma no es verificada por el contrato on-chain; es verificada por el hardware SGX durante la fase EINIT cuando el enclave se inicializa. La CPU comprueba que la firma del SIGSTRUCT es válida y que el MRENCLAVE que contiene coincide con la medición del enclave realmente cargado. Solo después de que esta verificación tenga éxito puede inicializarse el enclave y producir informes y quotes posteriores.

Un quote Intel SGX DCAP v3 es un paquete de atestación remota que contiene tres partes:

header: metadatos como la versión del quote, tipo de clave de atestación, QE/PCE SVN y proveedor.
localEnclaveReport: la identidad del enclave de la aplicación atestada, incluyendo MRENCLAVE, MRSIGNER, ATTRIBUTES, ISVPRODID, ISVSVN y reportData. reportData es un valor de 64 bytes escrito por el enclave al generar el informe. Taiko almacena la dirección de la instancia prover en los primeros 20 bytes de reportData.
v3AuthData: prueba de autenticidad para el quote, incluyendo la firma del quote, clave de atestación, informe QE, firma del informe QE y cadena de certificados PCK.

Atestación On-Chain

El contrato de atestación on-chain (AutomataDcapV3Attestation, responsable de la atestación remota) valida la autenticidad del quote a través de la cadena de certificados Intel DCAP. Aunque las claves públicas del emisor en la cadena de certificados se suministran como parte del quote enviado externamente, el contrato verifica la cadena paso a paso y requiere que el hash de la clave pública del emisor final coincida con el hash de la clave pública de la CA raíz de Intel SGX fijado en el contrato [2]. A través de esta cadena, el contrato confirma que el localEnclaveReport cubierto por la firma del quote no fue modificado arbitrariamente en los calldata.

Registro del Prover de Taiko

Una instancia de prover SGX debe registrarse primero a través de SgxVerifier.registerInstance(). Durante el registro, el llamador envía un quote DCAP. SgxVerifier delega la validación del quote a AutomataDcapV3Attestation.verifyParsedQuote(). Si el quote pasa, SgxVerifier lee los primeros 20 bytes de localEnclaveReport.reportData como la dirección de la instancia y la añade al conjunto de instancias autorizadas.

El flujo de verificación de firmas puede simplificarse en tres capas:

La CPU SGX verifica la firma del SIGSTRUCT durante EINIT, confirmando el MRENCLAVE del enclave y la identidad del firmante.
La cadena de certificados DCAP y el informe QE autentican la clave de firma del quote. AutomataDcapV3Attestation utiliza entonces esa clave para verificar la firma del quote y establecer confianza en localEnclaveReport.
El verificador de pruebas de Taiko utiliza la dirección de instancia registrada para verificar firmas de pruebas posteriores y decidir si acepta el estado L2 correspondiente o el mensaje cross-chain.

Análisis de la vulnerabilidad

La causa raíz de este incidente es una combinación de un fallo operativo y una vulnerabilidad a nivel de contrato. Ambos fueron necesarios para que el ataque tuviera éxito.

Fallo operativo: clave de firma de enclave expuesta. La clave privada de firma de enclave utilizada por Taiko/Raiko para firmar el SIGSTRUCT de SGX fue confirmada en un repositorio público de GitHub. MRSIGNER es el hash de la clave pública de firma correspondiente. Cualquiera que obtenga esta clave privada puede firmar el SIGSTRUCT del enclave de un prover, haciendo que el MRSIGNER en el quote resultante coincida con la lista de permitidos de Taiko.

Vulnerabilidad del contrato: verificación de ATTRIBUTES ausente. Con un MRSIGNER coincidente (pasando la lista de permitidos mediante la clave expuesta), el atacante podía lanzar el mismo enclave aprobado en modo DEBUG sin cambiar MRENCLAVE (el indicador DEBUG no forma parte de MRENCLAVE). La política de atestación debería haber detectado esto, pero AutomataDcapV3Attestation (0x5e46...dd72) no verificaba los localEnclaveReport.attributes del enclave de la aplicación. Un enclave DEBUG permite al host o al depurador leer o modificar la memoria del enclave, lo que significa que la clave de firma de instancia que debería haber estado protegida por el enclave SGX ya no es segura.

Juntas, estas dos condiciones significan que cualquier parte puede lanzar el mismo código de enclave prover en modo DEBUG (produciendo el mismo MRENCLAVE que la compilación legítima) y, usando la clave de firma expuesta, firmar un SIGSTRUCT que hace que MRSIGNER coincida con la lista de permitidos de Taiko. El quote resultante satisface tanto las listas de permitidos de MRENCLAVE como de MRSIGNER, mientras lleva el atributo DEBUG no verificado. Dado que AutomataDcapV3Attestation no rechaza el atributo DEBUG, dicho quote supera verifyParsedQuote(), tras lo cual SgxVerifier registra la dirección de instancia en el conjunto de instancias autorizadas.

Un enclave en modo DEBUG no protege su memoria del host o del depurador. La clave privada de instancia generada dentro del enclave puede por tanto extraerse. Con esa clave, el titular puede firmar datos de prueba arbitrarios que los contratos L1 aceptarían, permitiendo transiciones de estado L2 falsificadas y la liberación no autorizada de fondos del puente desde la bóveda (0x9962...15ab).

Análisis del ataque

El atacante envió múltiples transacciones. El siguiente análisis se basa en dos transacciones representativas: la primera registró al atacante como instancia autorizada (0x2f44dc...277260), y la segunda ejecutó la prueba falsificada para robar activos (0x017292...ae35ee).

Paso 1: Usar la clave de firma de enclave expuesta para firmar SIGSTRUCT, haciendo que el MRSIGNER del quote coincida con la lista de permitidos.
Paso 2: Ejecutar el enclave con el atributo DEBUG. DEBUG no cambia MRENCLAVE, pero se refleja en localEnclaveReport.attributes.
Paso 3: Llamar a registerInstance() y enviar un quote SGX real. El quote tenía attributes = 0x07..., que incluye el bit DEBUG (0x02), pero AutomataDcapV3Attestation no verificó este campo, por lo que verifyParsedQuote() devolvió true.

Paso 4: Extraer la clave privada de instancia de la memoria del enclave SGX (posible porque el modo DEBUG deshabilita la protección de memoria) y usarla para firmar datos de prueba maliciosos.
Paso 5: Enviar la prueba manipulada para hacer que los contratos L1 acepten un estado L2 inexistente y robar activos de la bóveda.

Conclusión

Una política de atestación SGX completa debería al menos:

Rechazar SGX_FLAGS_DEBUG en implementaciones de producción.
Verificar MRENCLAVE, MRSIGNER, ISVPRODID e ISVSVN.

Si se aceptan quotes DEBUG, el hardware puede seguir funcionando correctamente, pero ya no proporciona la semántica esperada de protección de memoria. Las claves de firma de enclaves tampoco deben confirmarse nunca en repositorios públicos. Una clave de firma expuesta permite a cualquier parte producir binarios con un MRSIGNER coincidente, reduciendo las barreras restantes de la política de atestación a la aplicación de MRENCLAVE y atributos.

De manera más amplia, para cualquier sistema que dependa de TEEs, la atestación no puede detenerse en confirmar que la cadena de firmas es válida y que la medición está en la lista de permitidos. Cada capa de la cadena de confianza debe aplicar sus propiedades de seguridad de forma independiente.

Referencias

[1] Alerta de Phalcon: Detección del exploit del puente Taiko
[2] Guía del desarrollador de Intel SGX

Más incidentes de esta semana

Incidente de SecondFi

El 23 de junio de 2026, SecondFi (anteriormente Yoroi), una billetera de Cardano desarrollada por EMURGO, reveló una vulnerabilidad crítica en su implementación de firma Ed25519 [1]. La implementación de firma de la billetera calculaba el nonce de firma únicamente a partir del mensaje de transacción público, omitiendo una entrada secreta requerida. Esto redujo la firma digital a un problema de una sola ecuación, permitiendo a los atacantes recuperar claves privadas a nivel de dirección a partir de datos públicos on-chain. Dos atacantes distintos explotaron el fallo, drenando aproximadamente $2.4M (16M ADA) de 374 billeteras [2].

Antecedentes

SecondFi es una billetera de custodia propia para la blockchain de Cardano, rebautizada desde Yoroi en abril de 2026. Desarrollada originalmente por EMURGO, una de las tres entidades fundadoras de Cardano, Yoroi anteriormente atendía a más de un millón de usuarios.

Ed25519 es el esquema de firma digital utilizado por Cardano para la autorización de transacciones. El firmante posee un escalar de firma $k_{L}$ (la clave privada para una dirección específica) y un prefijo de nonce secreto $k_{R}$ asociado al mismo material de clave. Para un mensaje dado $M$ (el payload de la transacción), el nonce de firma se calcula como $r = \operatorname{SHA-512}(k_R \mathbin\Vert M) \bmod L$ . Dado que $k_{R}$ es secreto, $r$ permanece desconocido para los observadores incluso si $M$ es público después de la difusión.

El punto de nonce $R = r \cdot B$ (donde $B$ es el punto base fijo de Ed25519) y el escalar de firma $s \equiv r + H \cdot k_L \pmod{L}$ (donde $H = \operatorname{SHA-512}(R \mathbin\Vert A \mathbin\Vert M) \bmod L$ vincula el nonce, la clave pública y el mensaje) forman la firma final $(R, s)$ . La seguridad del esquema depende de que $r$ sea impredecible: si un observador puede calcular $r$ , la ecuación de firma se convierte en una ecuación lineal de una sola incógnita resoluble para $k_{L}$ .

Análisis de la vulnerabilidad

Esta vulnerabilidad se encuentra en el software de firma de la billetera de SecondFi, no en un contrato inteligente.

Combinando el análisis existente [2] con nuestra propia investigación, encontramos que las versiones v10.0.3 a v10.0.6 (activas desde el 8 de junio de 2026; corregidas en v10.0.6.2) están afectadas. La implementación vulnerable calculaba el nonce de firma como:

r = \operatorname{SHA-512}(M) \bmod L

en lugar del correcto:

r = \operatorname{SHA-512}(k_R \mathbin\Vert M) \bmod L

Esto eliminó la única entrada secreta ( $k_{R}$ ) de la derivación del nonce. Dado que $M$ es público, cualquiera puede recalcular $r$ para cualquier transacción firmada por una dirección afectada.

Con $r$ conocido, la ecuación de firma $s \equiv r + H \cdot k_L \pmod{L}$ se vuelve resoluble:

k_L \equiv (s - r) \cdot H^{-1} \pmod{L}

Todos los valores del lado derecho son públicos o calculables a partir de la firma on-chain y los datos de la transacción. Esto no implica invertir un hash ni resolver el logaritmo discreto a partir de $A = k_L \cdot B$ ; la implementación defectuosa expuso directamente $r$ , reduciendo la recuperación de la clave a aritmética modular sencilla.

El impacto es el compromiso de la clave a nivel de dirección. Cualquier dirección que haya producido una firma a través de la implementación vulnerable debe considerarse comprometida.

Importar el mismo mnemónico en una billetera corregida no protege la dirección ya expuesta; los fondos deben trasladarse a una clave recién generada que nunca haya firmado a través de la implementación de firma vulnerable.

Análisis del ataque

Este ataque no sigue una secuencia típica de exploit on-chain con interacciones de contratos inteligentes rastreables. Dado que la vulnerabilidad expone una relación determinista entre datos públicos y la clave de firma, la recuperación de la clave se realiza fuera de línea.

Paso 1: Identificar las direcciones objetivo que firmaron transacciones usando SecondFi v10.0.3 a v10.0.6.
Paso 2: Para cada objetivo, recuperar los componentes de firma pública de la transacción ( $R$ , $s$ ) y reconstruir el mensaje $M$ a partir del payload de la transacción on-chain.
Paso 3: Calcular el nonce de firma $r = \operatorname{SHA-512}(M) \bmod L$ , aprovechando que la implementación de firma vulnerable omitió el prefijo de nonce secreto $k_{R}$ .
Paso 4: Calcular el escalar de desafío $H = \operatorname{SHA-512}(R \mathbin\Vert A \mathbin\Vert M) \bmod L$ .
Paso 5: Resolver el escalar de firma: $k_L \equiv (s - r) \cdot H^{-1} \pmod{L}$ .
Paso 6: Usar el $k_{L}$ recuperado para firmar transacciones arbitrarias desde la dirección comprometida y transferir fondos a billeteras controladas por el atacante.

Dos atacantes distintos explotaron esta vulnerabilidad de forma independiente. Uno comprometió 171 billeteras en dos oleadas, mientras que un segundo drenó 203 billeteras en un barrido separado, extrayendo colectivamente aproximadamente 16M ADA (~$2.4M) [2]. EMURGO posteriormente rescató otros 129M ADA antes de que los atacantes pudieran acceder a esos fondos.

Conclusión

La causa raíz fue un fallo en la implementación criptográfica que eliminó el prefijo de nonce secreto de la derivación del nonce Ed25519, reduciendo el nonce de firma a una función determinista de datos públicos. Cada firma afectada se convirtió en un problema de recuperación de clave de una sola ecuación.

Este incidente subraya que los desarrolladores de billeteras deben utilizar bibliotecas Ed25519 estándar y bien auditadas en lugar de implementaciones de firma personalizadas. Cualquier desviación de la especificación, incluso una que parezca menor como omitir una sola entrada de hash, puede comprometer la clave completa. El software de firma de producción debe someterse a una auditoría criptográfica independiente antes del despliegue, particularmente cuando se manejan operaciones de derivación de claves y firma.

Referencias

[1] Divulgación post-incidente de SecondFi
[2] Tibane Labs: Análisis forense de SecondFi en Cardano

Acerca de BlockSec

BlockSec es un proveedor integral de seguridad blockchain y cumplimiento cripto. Desarrollamos productos y servicios que ayudan a los clientes a realizar auditorías de código (incluyendo 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 de todo el ciclo de vida 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.