WEB3DEV

Cover image for Resumo de vulnerabilidade da ponte de cadeia cruzada
Felipe Gueller
Felipe Gueller

Posted on

Resumo de vulnerabilidade da ponte de cadeia cruzada

0x01 Cenário

Com o crescimento das blockchains e dos programas em cadeia, há uma alta demanda por projetos múltiplas cadeias( multi-chain), e a procura por pontes de cadeia cruzada (cross-chain) irá aumentar de acordo com essa emergente necessidade. Onde existe um negócio, haverá também problemas de segurança. Enquanto as pontes de cadeia cruzada forneçam vantagens para os seus usuários, elas também oferecem vantagens para os invasores, e depois dos ataques de Poly Network, surgirão também os problemas relacionados a segurança das pontes de cadeia cruzada.

0x02 O que é uma ponte de cadeia cruzada?

Uma ponte de blockchain, também conhecida como ponte de cadeia cruzada, conecta duas blockchains permitindo que os usuários enviem criptomoedas de uma cadeia para outra.
As pontes de cadeia cruzada permitem operações de fundos de cadeia cruzada, liberando a transferência de tokens, contratos inteligentes e troca de dados, além de comentários e instruções entre duas plataformas independentes.

Uma ponte de cadeia cruzada comum opera da seguinte maneira:

  • O usuário envia o ativo A para um endereço de depósito na cadeia original e paga a taxa de ponte;
  • O ativo A é bloqueado por um validador selecionado aleatoriamente em um contrato inteligente ou por um custodiante confiável;
  • Emita a mesma quantidade de ativo A1 na cadeia de destino e envie o ativo A1 para o endereço do usuário na cadeia de destino.

0x03 Vulnerabilidades que ocorreram na ponte de cadeia cruzada

Tabela descrevendo os dados de vulnerabilidade coletados na ponte de cadeia cruzada

0x04 Análise de vulnerabilidade comum da ponte de cadeia cruzada

Evento de ataque ChainSwap:

Em julho de 2021, o projeto de ponte de ativos de cadeia cruzada ChainSwap foi atacado. Mais de duas dúzias de projetos de ponte de cadeia cruzada foram atacados, perdendo quase $8 milhões em ativos e fazendo com que mais de dez projetos caíssem 99%.

Esse ataque se deve principalmente ao fato de o protocolo não verificar rigorosamente a validade das assinaturas para que os invasores possam usar suas próprias assinaturas geradas para assinar transações.

Contratos de fábrica

Código da função receive

A principal função do método receive na figura acima é transferir os fundos após a cadeia cruzada do usuário para o endereço do usuário da cadeia de destino, e a assinatura da cadeia de envio precisa ser verificada. O número atual de assinaturas a serem verificadas é 1.

Devido à lógica do método receive e da chamada da função ecrecover, o método decreaseAuthQuota não verifica estritamente as assinaturas chamadas, o atacante passou na assinatura gerada por ele mesmo, e a lógica do contrato seguinte não julgou estritamente o valor do mapeamento das assinaturas e outros cálculos. Isso permite que o invasor execute com sucesso o método receive para assinar os fundos de transferência para si mesmo.

Evento de ataque ao Poly Network

Em agosto de 2021, o protocolo de interoperabilidade de cadeia cruzada Poly Network foi subitamente atacado por hackers. O O3 Swap usando este protocolo sofreu grandes perdas. Os ativos nas três redes da Ethereum, Binance Smart Chain e da Polygon quase foram saqueados. Dentro de 1 hora, 250 milhões, 270 milhões e 85 milhões de dólares americanos de ativos criptografados foram roubados, e a perda total chegou a 610 milhões de dólares americanos.

Esse ataque deve-se principalmente à substituição da chave pública do validador da cadeia de retransmissão. Ou seja, o validador intermediário da cadeia cruzada é substituído pelo atacante e controlado por ele mesmo.

Relação interna do acordo:

A chave pública do validador da cadeia de retransmissão existe no contrato EthCrossChainData;

O proprietário do contrato EthCrossChainData é o contrato EthCrossChainManager.

O método putCurEpochConPubKeyBytes do contrato EthCrossChainData pode modificar a função do validador da cadeia de retransmissão.

Contrato EthCrossChainManager:

Código do contrato EthCrossChainManager

Na figura acima, o método executeCrossChainTxnão impõe restrições estritas aos parâmetros de entrada, o que faz com que o invasor passe para toContract e os parâmetros do método sejam controlados pelo invasor. Devido ao relacionamento interno do protocolo, o invasor passa a mesma assinatura de método presente no método putCurEpochConPubKeyBytes, após a colisão de hash. Chame com sucesso o método putCurEpochConPubKeyBytes do contrato EthCrossChainData para então modificar diretamente a chave pública do verificador da cadeia de retransmissão tornando-a controlável e, em seguida, use o verificador para assinar transferências de fundos maliciosas para obter uma grande quantidade de fundos.

Evento de ataque de múltiplas cadeias (AnySwap)

Em janeiro de 2022, a Multichain declarou oficialmente que há um risco de segurança do protocolo da ponte de cadeia cruzada, e que alguns tokens correm o risco de serem hackeados, e pede aos usuários para cancelar a autorização o mais rápido possível.

O principal motivo do evento: o contrato de token subjacente chamado pelo protocolo não implementa o método de permissão, mas inclui uma função de contingência, portanto, o contrato que chama o método de permissão é executado normalmente.

A esquerda o contrato AnyswapV4Router e a direita o contrato WETH9.

Código dos contratos AnyswapV4Router e WETH9

No método AnySwapOutUnderlyingWithPermit na figura acima, os três primeiros parâmetros são todos passados ​​pelo chamador, to (para), from (de), token e outros parâmetros são todos controláveis ​​pelo invasor. Quando os parâmetros são controláveis, o invasor implanta o contrato de ataque para transferir os tokens afetados. O endereço do contrato é definido como o parâmetro do token subjacente.

O problema principal é que como o WETH9 não possui um método de permissão, mas chamará o método de contingência do WETH9 para a operação de depósito, não haverá erro na chamada (a transação não será revertida), portanto, quando o usuário autorizar os fundos para o protocolo, o invasor transferirá rapidamente os fundos do usuário.

Evento de ataque à ponte Qubit

Em janeiro de 2022, a ponte de cadeia cruzada Qubit Finance, entre Ethereum-Binance, foi invadida, perdendo mais de 80 milhões de dólares.

Problema central: quando o endereço do fundo no método deposit é address(0), o erro safeTransferFrom não ocorre, resultando na execução normal da função de depósito.

O contrato QBridge

Código do contrato QBridge

Na figura acima, deposit é um método de depósito normal. Ao chamar IQBridgeHandler(handler).deposit neste método, quando o endereço tokenAddress de mapeamento do resourceID passado pelo usuário é 0, a tokenAddress.safeTransferFrom(depositer, address(this), amount) subsequente; a transferência será executada normalmente, resultando no funcionamento normal do método e do evento, e o chamador poderá fazer um depósito com sucesso.

O mais importante aqui é que o endereço zero ETH do tokenAddress oficial é o que o oficial faz (o oficial declarou a função de depósito como uma função abandonada ignorada).

Analise dos ataques à ponte Meter.io

Em fevereiro de 2022, o protocolo de cadeia cruzada Meter.io foi atacado e o contrato não impediu a interação direta do token ERC20 encapsulado com o token de gás nativo, resultando em uma perda de aproximadamente 4,3 milhões de dólares.

O problema central do incidente: o método de depósito não verifica a situação do depósito WBNB ao realizar um depósito, o que faz com que o invasor ignore a condição de julgamento e não faça nenhum depósito para obter fundos normalmente.

O contrato da ponte Meter

Código do contrato da ponte Meter

Na figura acima, os métodos deposit e depositETH são métodos de depósito, mas quando o método deposit deposita, não é verificado se o depósito é um token nativo. Quando o invasor usa o deposit para depositar, o endereço WBNB é transmitido. Como esse método não verifica o depósito WBNB, os fundos não são armazenados e transferidos e, então, o método depositHandler.deposit é chamado para contornar com êxito a condição de julgamento. Por fim, o invasor usa essa falha para obter com sucesso um grande número de fundos.

Análise do ataque à Wormhole

Em fevereiro de 2022, a importante ponte (Wormhole) das duas principais blockchains da Ethereum e Solana foi hackeada, com uma perda de mais de 320 milhões de dólares.

O principal motivo da vulnerabilidade: a validade da instrução não é verificada no método load_instruction_at chamado por verify_signatures, o que permite que invasores forjem e usem a assinatura de verificação para obter fundos.

O contrato de interface verify_signature.rs

O código do contrato verify_signatures

O método verify_signatures na figura acima é o método de assinatura chamado durante a verificação de cadeia cruzada. Como o método verify_signatures chama o método load_instruction_at, o método load_instruction_at é um método abandonado depois que o protocolo é atualizado. A instrução recebida não é rigorosamente verificada neste método, o que leva a invasores. Depois de passar em um valor controlável, o invasor usa este método de assinatura para assinar sua própria solicitação de cadeia cruzada e obter uma grande quantia de fundos.

Análise do ataque à Li Finance

Em março de 2022, o Li.Finance, um protocolo de cadeia cruzada distribuído na Ethereum, foi atacado. O invasor realizou 37 injeções de chamadas e obteve cerca de 600.000 dólares em ativos (204 ETH) em várias carteiras.

O problema central desse ataque é que os dados externos recebidos não são estritamente restritos, o que leva o invasor a passar por sua própria lógica de chamada controlável.

O contrato CBridgeFacet

Código do contrato CBridgeFacet

Na figura acima, no método swapAndStartBridgeTokensViaCBridge_, o parâmetro _swapData de entrada não é estritamente restrito. Na mesma chamada LibSwap.swap, o valor não é estritamente restrito. Como resultado, no método de troca, _swapData pode chamar com êxito o método call para executar operações maliciosas. Os invasores exploram essa falha para fazer várias chamadas para obter fundos.

Análise do ataque à Ronin Network

Em março de 2022, o nó validador da cadeia lateral (sidechain) Ronin da Axie Infinity e o nó validator da Axie DAO foram comprometidos, resultando em 173.600 ETH e $ 25,5 milhões USDC em ponte de Ronin em duas transações.

Razões para o ataque

Atualmente, a cadeia Ronin da Sky Mavis consiste em 9 validadores. Para identificar um evento de depósito ou um evento de saque, são necessárias cinco das nove assinaturas do validador. Os invasores assumiram o controle de quatro validadores Ronin da Sky Mavis e um validador terceirizado executado pela Axie DAO. (novembro-dezembro de 2021, o Axie DAO permitiu que a Sky Mavis assinasse várias transações em seu nome, depois que o incidente foi interrompido sem revogar o acesso à lista de permissões, o invasor obteve acesso ao sistema Sky Mavis e usou RPCs sem gás do validador Axie DAO para obter a assinatura).

0x05 Resumo e recomendações

A partir dos incidentes de ataque de ponte de cadeia cruzada acima, pode-se descobrir que, desde os dois importantes ataques de ponte de cadeia cruzada do ano passado até este ano, houve vários ataques de ponte de cadeia cruzada. O número de ataques de ponte de cadeia cruzada aumentou significativamente e os fundos roubados também são bastante grandes. Hackers já visavam a parte mais vulnerável da ponte que permite a transferência de dados entre blockchains. Pelo resumo da tabela, os ataques ocorrem principalmente antes da cadeia cruzada e na assinatura, que geralmente são brechas contratuais, e também há furtos causados ​​por descuido oficial. Para mais e mais projetos de cadeia cruzada e segurança de contrato de projeto, aqui estão os conselhos:

  • Auditorias de segurança concluídas em contratos antes do projeto entrar em operação
  • A interface de chamada do contrato precisa verificar rigorosamente sua adaptabilidade
  • Quando a versão é atualizada, as interfaces relevantes e a segurança da assinatura precisam ser reexaminadas
  • É necessário um exame minucioso dos assinantes de cadeia cruzada para garantir que as assinaturas não sejam controladas por pessoas mal-intencionadas

Este artigo é uma tradução de lunaray feita por Felipe Gueller. Você pode encontrar o artigo original aqui.

Top comments (0)