Um atacante explorou o sistema de mensageria cross-chain baseado em LayerZero para assumir controle da validação de mensagens e manipular o fluxo de execução.

O ataque combinou:

  • alteração de validadores (DVNs)
  • modificação de parâmetros de execução
  • manipulação de ordem de mensagens via skip()

O uso da função skip() não apenas ignora uma mensagem específica, mas avança artificialmente o estado interno (inboundNonce) até o valor informado, fazendo com que todas as mensagens anteriores sejam consideradas como processadas, mesmo sem execução.

A função skip() avança o lazyInboundNonce, que por sua vez atualiza o inboundNonce efetivo, permitindo que o sistema ignore a execução de mensagens pendentes enquanto as considera como processadas.

🧨 NO ATAQUE

Ele usou skip pra:

  • avançar lazyInboundNonce
  • sincronizar com inboundNonce
  • ignorar mensagens

1. inboundNonce

é o nonce real confirmado

  • representa mensagens processadas corretamente
  • estado "oficial"

2. lazyInboundNonce

é o nonce "adiantado" manualmente

  • usado pra skip
  • pode ignorar mensagens
  • não garante execução

💀 DIFERENÇA REAL

inboundNonce = histórico real executado

lazyInboundNonce = estado forçado

🔥 O QUE O ATAQUE FAZ

Quando ele chama skip(n):

👉 ele faz:

lazyInboundNonce = n

👉 e isso força:

inboundNonce ≈ lazyInboundNonce

💀 sem executar nada

🧠 TRADUÇÃO

  • Em termos práticos: - inboundNonce representa o estado canônico realmente executado - lazyInboundNonce representa um estado artificialmente avançado, sem garantia de execução

Isso resultou em:

  • aceitação de mensagens inválidas
  • quebra de consistência de estado
  • potencial movimentação indevida de fundos

A arquitetura analisada envolve:

  • OApp (0x5786…) → aplicação (Aethir OFTAdapter)
  • ReceiveUln302 (0xc02a…) → validação via DVNs
  • EndpointV2 (0x1a44…) → execução e controle de mensagens

🧩1. Execution Parameter Manipulation

Evento:

EnforcedOptionSet(tuple[] _enforcedOptions)

Dados:

  • eid: 30184
  • msgType: 1
  • options: 0x00030100110100000000000000000000000000030d40

As mensagens manipuladas se originaram na Base Mainnet (Chain ID: 8453), identificada no LayerZero pelo Endpoint ID 30184.

Análise:O atacante definiu opções obrigatórias de execução para mensagens dessa chain.

Possível impacto:

  • controle de gas de execução
  • alteração de comportamento da execução
  • ajuste de parâmetros críticos de processamento

Isso representa preparação do ambiente de execução

None

🧩2. Validation Layer Takeover (CRÍTICO)

Evento:

UlnConfigSet(address oapp, uint32 eid, tuple config)

OApp:

0x5786C150609a4eF8957bc614a13e8e29558EaBA4

Configurações observadas:

Primeira configuração:

DVNs:
0x9e059a54699a285714207b43B055483E78FAac25
0xa7b5189bcA84Cd304D8553977c7C614329750d99
None

Segunda:

0x95729Ea44326f8adD8A9b1d987279DBdC1DD3dFf
0xDb979D0A36aF0525AFa60Fc265B1525505c55D79
None

Terceira:

0x380275805876Ff19055EA900CDb2B46a94ecF20D
0x589dEDbD617e0CBcB916A9223F4d1300c294236b
None

Parâmetros:

  • requiredDVNCount: 2
  • optionalDVNCount: 0

🧠 Análise Crítica:

O atacante redefiniu os validadores (DVNs)

Como requiredDVNCount foi definido como 2 e apenas 2 DVNs foram configurados, o sistema passou a depender exclusivamente desses validadores, eliminando redundância e descentralização do processo de verificação.

Isso implica:

  • controle direto sobre validação de mensagens
  • possibilidade de validar mensagens arbitrárias

🚨 Observação importante:

Múltiplas mudanças sequenciais indicam:

  • teste interativo
  • ajuste fino do ataque
  • possível tentativa e erro

👉 comportamento humano / ataque ativo

🧩3. Authorization Context (Root Cause Surface)

Funções críticas associadas à modificação de configuração incluem:

setConfig(address _oapp, address _lib, ...)
setReceiveLibrary(...)
setSendLibrary(...)

Essas funções, conforme o padrão do LayerZero, dependem de mecanismos de autorização, tipicamente baseados em validação do _oapp.

_assertAuthorized(_oapp);

🧠 Insight crítico:

As alterações de configuração observadas (ex: UlnConfigSet) indicam que o atacante conseguiu executar operações privilegiadas relacionadas ao controle de validação de mensagens.

No entanto, a função exata utilizada para realizar essas alterações não pode ser determinada apenas pelos eventos analisados.

💀 Possíveis vetores de comprometimento:

A. Comprometimento do OApp

  • controle do contrato _oapp
  • transferência de ownership
  • upgrade malicioso (proxy)

B. Falha no mecanismo de autorização

  • validação incorreta de msg.sender
  • uso inseguro de tx.origin
  • ausência ou bypass de checagens críticas

C. Acesso privilegiado legítimo utilizado de forma maliciosa

  • uso de permissões administrativas válidas
  • ausência de restrições adicionais (ex: timelock, multisig)

🧨 4. Message Order Manipulation (CORE EXPLOIT)

Evento:

InboundNonceSkipped(srcEid, sender, receiver, nonce)

📍 Sender 1:

0xD5FA8AC45d6A0984D14F3B301b18910948DEb11A

Nonces pulados:

  • 1
None
  • 2
None

📍 Sender 2:

0xB19444E06D7525B15A6638B041D835BEA439C78A

Nonces pulados:

  • 1
None
  • 2
None
  • 3
None

🧠 Análise:

múltiplos caminhos de mensagem foram manipulados

sequência completa ignorada

A presença de múltiplos sender nos eventos de InboundNonceSkipped indica que o atacante manipulou diferentes fluxos de mensagens independentes, sugerindo compreensão aprofundada da arquitetura cross-chain e controle sobre múltiplas rotas de comunicação.

💀 Consequência direta:

  • mensagens legítimas nunca executadas
  • estado interno inconsistente
  • sincronização quebrada

🧠 5. Combined Effect (Exploit Mechanism)

O ataque não foi resultado de uma única vulnerabilidade, mas sim da manipulação coordenada de três camadas independentes de confiança:

🔗 Cadeia de ataque:

  1. Camada de execução → controle de parâmetros (EnforcedOptionSet)
  2. Camada de validação → takeover dos DVNs (UlnConfigSet)
  3. Camada de ordenação → manipulação de nonce (InboundNonceSkipped)

Em conjunto, essas ações permitem contornar completamente as premissas de confiança do sistema cross-chain.

💀 Resultado final:

  • validação comprometida
  • mensagens fora de ordem
  • estado inválido aceito

🧨 Attack Classification

Cross-Chain State Desynchronization Attack via Validation Control

💀 Root Cause Analysis

🎯 Mais provável:

1. Comprometimento de chave administrativa

  • acesso legítimo usado maliciosamente
  • controle de config permitido

2. Falha em _assertAuthorized

  • autenticação insuficiente
  • bypass de autorização

⚠️ Menos provável:

  • bug isolado em lógica de mensagem
  • erro em token/transfer

⚠️ Impacto

  • controle total da validação
  • execução arbitrária de mensagens
  • quebra de garantias cross-chain
  • possível perda total de fundos

🛡️ Recommendations

🔐 Access Control

  • reforçar _assertAuthorized
  • restringir chamadas críticas

⏳ Governance

  • adicionar timelock para config
  • multisig obrigatório

🚫 Restrição de skip

  • limitar uso
  • adicionar validações adicionais

🧠 Monitoring

  • alertas para mudanças de DVN
  • detecção de múltiplas alterações

📌 Final Assessment

O ataque não explorou apenas uma falha isolada, mas sim:

controle de múltiplas camadas críticas do sistema

  • validação
  • execução
  • ordenação

🔥 Conclusão Final

quem controla:

  • DVNs
  • ordem de mensagens

Isso concede ao atacante controle total sobre o pipeline de mensageria cross-chain, incluindo validação, execução e progressão de estado, isso representa uma falha sistêmica nas premissas de confiança do modelo de validação cross-chain.

O ataque demonstra que, em arquiteturas baseadas em validação externa (como DVNs), o controle da camada de verificação equivale ao controle total do sistema.

Nesse contexto, segurança não depende apenas do código, mas da integridade das entidades responsáveis pela validação.