~$4M Perdidos: Explorações Taiko e SecondFi

Durante a semana passada (2026/06/22 - 2026/06/28), 2 incidentes de segurança notáveis foram identificados, resultando em aproximadamente $4,1M em perdas confirmadas.

Data	Incidente	Tipo	Perda Estimada
2026/06/22	Taiko	Comprometimento de Chave & Validação Inadequada	~$1,7M
2026/06/23	SecondFi	Falha na Implementação Criptográfica	~$2,4M

Taiko: O atacante combinou uma chave de assinatura de enclave SGX exposta com uma política de atestação incompleta para registrar um prover malicioso como uma instância autorizada, demonstrando que uma atestação válida por si só é insuficiente sem uma aplicação abrangente de atributos.
SecondFi: Uma falha na implementação criptográfica permitiu que atacantes recuperassem chaves de assinatura no nível de endereço usando apenas dados públicos de transações, demonstrando como um desvio aparentemente menor da especificação Ed25519 pode levar ao comprometimento completo da chave.

Destaque da Semana: Incidente Taiko

O incidente Taiko é destacado porque o ataque combinou duas falhas de segurança independentes (uma chave de assinatura de enclave exposta e uma política de atestação incompleta) para comprometer um sistema de verificação de provas baseado em SGX. O incidente demonstra que cada camada de uma cadeia de confiança TEE deve aplicar suas propriedades de segurança de forma independente; uma cadeia de assinaturas de atestação válida não compensa atributos de tempo de execução não verificados.

Em 22 de junho de 2026, o fluxo de verificação de provas baseado em SGX da Taiko foi explorado na Ethereum, resultando em aproximadamente $1,7M em perdas [1]. O atacante utilizou uma chave privada de assinatura de enclave exposta, que havia sido enviada para um repositório público no GitHub, para assinar o SIGSTRUCT de um enclave prover lançado em modo DEBUG. Como o contrato de atestação on-chain não rejeitava enclaves DEBUG, o atacante se registrou como uma instância autorizada, enviou dados de prova forjados e fez com que os contratos L1 aceitassem um estado L2 inexistente e liberassem fundos da bridge.

Contexto

Taiko é um rollup Ethereum Layer-2 com uma bridge que depende de um sistema de provas para decidir se um determinado estado L2 ou mensagem cross-chain deve ser aceito. Como parte desse sistema de provas, a Taiko utiliza SGX provers: programas off-chain executados dentro de enclaves SGX em máquinas físicas que assinam resultados de provas com chaves protegidas pelo enclave.

Off-chain (máquina física)                  On-chain (Ethereum)
┌─────────────────────────┐                ┌────────────────────────────────────┐
│  SGX Prover Enclave     │                │  SgxVerifier                       │
│  - gera provas          │── DCAP quote ─→│  ├─ registerInstance()             │
│  - mantém chave         │                │  │  └─ AutomataDcapV3Attestation   │
│    da instância         │── prova assin→ │  └─ verifyProof()                  │
└─────────────────────────┘                └────────────────────────────────────┘

Visão Geral do SGX & DCAP

O conceito central do SGX é o enclave: um ambiente de programa isolado pela CPU. MRENCLAVE é a medição do código inicial do enclave, dados, layout de páginas e metadados relacionados; pode ser aproximado como o hash da build do enclave. MRSIGNER é o hash da chave pública de assinatura do enclave e representa a identidade do publicador.

A chave privada de assinatura do enclave assina o SIGSTRUCT do SGX, que contém metadados do enclave como MRENCLAVE, ISVPRODID, ISVSVN e ATTRIBUTES. Essa assinatura não é verificada pelo contrato on-chain; ela é verificada pelo hardware SGX durante a fase EINIT quando o enclave é inicializado. A CPU verifica se a assinatura do SIGSTRUCT é válida e se o MRENCLAVE contido nele corresponde à medição do enclave realmente carregado. Somente após essa verificação ser bem-sucedida o enclave pode ser inicializado e produzir relatórios e quotes subsequentes.

Um quote Intel SGX DCAP v3 é um pacote de atestação remota contendo três partes:

header: metadados como versão do quote, tipo de chave de atestação, QE/PCE SVN e fornecedor.
localEnclaveReport: a identidade do enclave da aplicação atestada, incluindo MRENCLAVE, MRSIGNER, ATTRIBUTES, ISVPRODID, ISVSVN e reportData. reportData é um valor de 64 bytes escrito pelo enclave ao gerar o relatório. A Taiko armazena o endereço da instância do prover nos primeiros 20 bytes de reportData.
v3AuthData: prova de autenticidade do quote, incluindo a assinatura do quote, chave de atestação, relatório QE, assinatura do relatório QE e cadeia de certificados PCK.

Atestação On-Chain

O contrato de atestação on-chain (AutomataDcapV3Attestation, responsável pela atestação remota) valida a autenticidade do quote através da cadeia de certificados Intel DCAP. Embora as chaves públicas dos emissores na cadeia de certificados sejam fornecidas como parte do quote submetido externamente, o contrato verifica a cadeia passo a passo e exige que o hash da chave pública do emissor final corresponda ao hash da chave pública do Intel SGX Root CA fixado no contrato [2]. Por meio dessa cadeia, o contrato confirma que o localEnclaveReport coberto pela assinatura do quote não foi modificado arbitrariamente no calldata.

Registro do Prover Taiko

Uma instância de SGX prover deve primeiro ser registrada por meio de SgxVerifier.registerInstance(). Durante o registro, o chamador submete um quote DCAP. O SgxVerifier delega a validação do quote para AutomataDcapV3Attestation.verifyParsedQuote(). Se o quote for aprovado, o SgxVerifier lê os primeiros 20 bytes de localEnclaveReport.reportData como o endereço da instância e o adiciona ao conjunto de instâncias autorizadas.

O fluxo de verificação de assinatura pode ser simplificado em três camadas:

A CPU SGX verifica a assinatura do SIGSTRUCT durante o EINIT, confirmando o MRENCLAVE do enclave e a identidade do assinante.
A cadeia de certificados DCAP e o relatório QE autenticam a chave de assinatura do quote. O AutomataDcapV3Attestation então usa essa chave para verificar a assinatura do quote e estabelecer confiança no localEnclaveReport.
O verificador de provas da Taiko usa o endereço de instância registrado para verificar assinaturas de provas posteriores e decidir se aceita o estado L2 correspondente ou a mensagem cross-chain.

Análise da Vulnerabilidade

A causa raiz deste incidente é uma combinação de uma falha operacional e uma vulnerabilidade no contrato. Ambas foram necessárias para o sucesso do ataque.

Falha operacional: chave de assinatura de enclave exposta. A chave privada de assinatura de enclave usada pela Taiko/Raiko para assinar o SIGSTRUCT do SGX foi enviada para um repositório público no GitHub. MRSIGNER é o hash da chave pública de assinatura correspondente. Qualquer pessoa que obtenha essa chave privada pode assinar o SIGSTRUCT de um enclave prover, fazendo com que o MRSIGNER no quote resultante corresponda à lista de permissões da Taiko.

Vulnerabilidade no contrato: verificação de ATTRIBUTES ausente. Com um MRSIGNER correspondente (passando pela lista de permissões via chave exposta), o atacante poderia lançar o mesmo enclave aprovado em modo DEBUG sem alterar o MRENCLAVE (o flag DEBUG não faz parte do MRENCLAVE). A política de atestação deveria ter detectado isso, mas o AutomataDcapV3Attestation (0x5e46...dd72) não verificava os localEnclaveReport.attributes do enclave da aplicação. Um enclave DEBUG permite que o host ou depurador leia ou modifique a memória do enclave, o que significa que a chave de assinatura da instância que deveria ter sido protegida pelo enclave SGX não está mais segura.

Juntas, essas duas condições significam que qualquer parte pode lançar o mesmo código de enclave prover em modo DEBUG (produzindo o mesmo MRENCLAVE que a build legítima) e, usando a chave de assinatura exposta, assinar um SIGSTRUCT que faz o MRSIGNER corresponder à lista de permissões da Taiko. O quote resultante satisfaz tanto as listas de permissões de MRENCLAVE quanto de MRSIGNER, enquanto carrega o atributo DEBUG não verificado. Como o AutomataDcapV3Attestation não rejeita o atributo DEBUG, tal quote passa pelo verifyParsedQuote(), após o qual o SgxVerifier registra o endereço da instância no conjunto de instâncias autorizadas.

Um enclave em modo DEBUG não protege sua memória do host ou depurador. A chave privada da instância gerada dentro do enclave pode, portanto, ser extraída. Com essa chave, o detentor pode assinar dados de prova arbitrários que os contratos L1 aceitariam, possibilitando transições de estado L2 forjadas e liberação não autorizada de fundos da bridge a partir do vault (0x9962...15ab).

Análise do Ataque

O atacante submeteu múltiplas transações. A análise a seguir é baseada em duas transações representativas: a primeira registrou o atacante como uma instância autorizada (0x2f44dc...277260), e a segunda executou a prova forjada para roubar ativos (0x017292...ae35ee).

Passo 1: Usar a chave de assinatura de enclave exposta para assinar o SIGSTRUCT, fazendo com que o MRSIGNER do quote corresponda à lista de permissões.
Passo 2: Executar o enclave com o atributo DEBUG. O DEBUG não altera o MRENCLAVE, mas é refletido em localEnclaveReport.attributes.
Passo 3: Chamar registerInstance() e submeter um quote SGX real. O quote tinha attributes = 0x07..., que inclui o bit DEBUG (0x02), mas o AutomataDcapV3Attestation não verificava esse campo, então verifyParsedQuote() retornou true.

Passo 4: Extrair a chave privada da instância da memória do enclave SGX (possível porque o modo DEBUG desativa a proteção de memória) e usá-la para assinar dados de prova maliciosos.
Passo 5: Submeter a prova forjada para fazer os contratos L1 aceitarem um estado L2 inexistente e roubar ativos do vault.

Conclusão

Uma política de atestação SGX completa deve pelo menos:

Rejeitar SGX_FLAGS_DEBUG em implantações de produção.
Verificar MRENCLAVE, MRSIGNER, ISVPRODID e ISVSVN.

Se quotes DEBUG forem aceitos, o hardware pode ainda estar funcionando corretamente, mas não fornece mais a semântica esperada de proteção de memória. Chaves de assinatura de enclave também nunca devem ser enviadas para repositórios públicos. Uma chave de assinatura exposta permite que qualquer parte produza binários com um MRSIGNER correspondente, reduzindo as barreiras restantes da política de atestação à aplicação de MRENCLAVE e atributos.

De forma mais ampla, para qualquer sistema que dependa de TEEs, a atestação não pode parar em confirmar que a cadeia de assinaturas é válida e que a medição está na lista de permissões. Cada camada da cadeia de confiança deve aplicar suas propriedades de segurança de forma independente.

Referências

[1] Alerta Phalcon: Detecção de Exploit na Bridge Taiko
[2] Guia do Desenvolvedor Intel SGX

Mais Incidentes desta Semana

Incidente SecondFi

Em 23 de junho de 2026, a SecondFi (anteriormente Yoroi), uma carteira Cardano desenvolvida pela EMURGO, divulgou uma vulnerabilidade crítica em sua implementação de assinatura Ed25519 [1]. A implementação de assinatura da carteira calculava o nonce de assinatura apenas a partir da mensagem pública da transação, omitindo uma entrada secreta obrigatória. Isso reduziu a assinatura digital a um problema de equação única, permitindo que atacantes recuperassem chaves privadas no nível de endereço a partir de dados públicos on-chain. Dois atacantes distintos exploraram a falha, drenando aproximadamente $2,4M (16M ADA) de 374 carteiras [2].

Contexto

SecondFi é uma carteira self-custody para o blockchain Cardano, renomeada a partir de Yoroi em abril de 2026. Originalmente desenvolvida pela EMURGO, uma das três entidades fundadoras do Cardano, a Yoroi já serviu mais de um milhão de usuários.

Ed25519 é o esquema de assinatura digital usado pelo Cardano para autorização de transações. O assinante possui um escalar de assinatura $k_{L}$ (a chave privada para um endereço específico) e um prefixo de nonce secreto $k_{R}$ associado ao mesmo material de chave. Para uma dada mensagem $M$ (o payload da transação), o nonce de assinatura é calculado como $r = \operatorname{SHA-512}(k_R \mathbin\Vert M) \bmod L$ . Como $k_{R}$ é secreto, $r$ permanece desconhecido para observadores mesmo que $M$ seja público após a transmissão.

O ponto de nonce $R = r \cdot B$ (onde $B$ é o ponto base fixo do Ed25519) e o escalar de assinatura $s \equiv r + H \cdot k_L \pmod{L}$ (onde $H = \operatorname{SHA-512}(R \mathbin\Vert A \mathbin\Vert M) \bmod L$ vincula o nonce, a chave pública e a mensagem) formam a assinatura final $(R, s)$ . A segurança do esquema depende de $r$ ser imprevisível: se um observador puder calcular $r$ , a equação de assinatura torna-se uma equação linear de incógnita única, solucionável para $k_{L}$ .

Análise da Vulnerabilidade

Esta vulnerabilidade está no software de assinatura da carteira SecondFi, não em um contrato inteligente.

Combinando a análise existente [2] com nossa própria investigação, descobrimos que as versões v10.0.3 a v10.0.6 (em produção desde 8 de junho de 2026; corrigidas na v10.0.6.2) são afetadas. A implementação vulnerável calculava o nonce de assinatura como:

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

em vez do correto:

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

Isso removeu a única entrada secreta ( $k_{R}$ ) da derivação do nonce. Como $M$ é público, qualquer pessoa pode recalcular $r$ para qualquer transação assinada por um endereço afetado.

Com $r$ conhecido, a equação de assinatura $s \equiv r + H \cdot k_L \pmod{L}$ torna-se solúvel:

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

Todos os valores no lado direito são públicos ou calculáveis a partir da assinatura on-chain e dos dados da transação. Isso não é reverter um hash ou resolver o logaritmo discreto a partir de $A = k_L \cdot B$ ; a implementação falha expôs diretamente $r$ , reduzindo a recuperação da chave a uma aritmética modular direta.

O impacto é o comprometimento de chave com escopo de endereço. Qualquer endereço que produziu uma assinatura por meio da implementação vulnerável deve ser tratado como comprometido.

Importar o mesmo mnemônico em uma carteira corrigida não protege o endereço já exposto; os fundos devem ser movidos para uma chave recém-gerada que nunca tenha assinado por meio da implementação de assinatura vulnerável.

Análise do Ataque

Este ataque não segue uma sequência típica de exploit on-chain com interações rastreáveis em contratos inteligentes. Como a vulnerabilidade expõe uma relação determinística entre dados públicos e a chave de assinatura, a recuperação da chave é realizada offline.

Passo 1: Identificar endereços alvo que assinaram transações usando SecondFi v10.0.3 a v10.0.6.
Passo 2: Para cada alvo, recuperar os componentes públicos de assinatura da transação ( $R$ , $s$ ) e reconstruir a mensagem $M$ a partir do payload da transação on-chain.
Passo 3: Calcular o nonce de assinatura $r = \operatorname{SHA-512}(M) \bmod L$ , explorando o fato de que a implementação de assinatura vulnerável omitiu o prefixo de nonce secreto $k_{R}$ .
Passo 4: Calcular o escalar de desafio $H = \operatorname{SHA-512}(R \mathbin\Vert A \mathbin\Vert M) \bmod L$ .
Passo 5: Resolver o escalar de assinatura: $k_L \equiv (s - r) \cdot H^{-1} \pmod{L}$ .
Passo 6: Usar o $k_{L}$ recuperado para assinar transações arbitrárias a partir do endereço comprometido e transferir fundos para carteiras controladas pelo atacante.

Dois atacantes distintos exploraram essa vulnerabilidade de forma independente. Um comprometeu 171 carteiras em duas ondas, enquanto o segundo drenou 203 carteiras em uma varredura separada, extraindo coletivamente aproximadamente 16M ADA (~$2,4M) [2]. A EMURGO posteriormente resgatou outros 129M ADA antes que os atacantes pudessem alcançar esses fundos.

Conclusão

A causa raiz foi uma falha na implementação criptográfica que removeu o prefixo de nonce secreto da derivação do nonce Ed25519, reduzindo o nonce de assinatura a uma função determinística de dados públicos. Cada assinatura afetada tornou-se um problema de recuperação de chave de equação única.

Este incidente reforça que desenvolvedores de carteiras devem usar bibliotecas Ed25519 padrão e bem auditadas em vez de implementações de assinatura personalizadas. Qualquer desvio da especificação, mesmo aquele que pareça menor, como omitir uma única entrada de hash, pode comprometer a chave inteira. O software de assinatura em produção deve passar por auditoria criptográfica independente antes da implantação, particularmente ao lidar com derivação de chaves e operações de assinatura.

Referências

[1] Divulgação Pós-Incidente da SecondFi
[2] Tibane Labs: Análise Forense SecondFi Cardano

Sobre a BlockSec

A BlockSec é um provedor completo de segurança blockchain e conformidade cripto. Desenvolvemos produtos e serviços que ajudam nossos clientes a realizar auditorias de código (incluindo contratos inteligentes, blockchain e carteiras), interceptar ataques em tempo real, analisar incidentes, rastrear fundos ilícitos e cumprir obrigações de AML/CFT, ao longo de todo o ciclo de vida de protocolos e plataformas.

A BlockSec publicou múltiplos artigos de segurança blockchain em conferências de prestígio, reportou vários ataques zero-day em aplicações DeFi, bloqueou múltiplos hacks para resgatar mais de 20 milhões de dólares e protegeu bilhões em criptomoedas.