Este artigo é uma postagem da comunidade. O autor é Minzhi He, auditor da CertiK.
As opiniões expressas neste artigo são de responsabilidade do colaborador/autor e não refletem necessariamente as opiniões da Binance Academy.
Resumo
As pontes Blockchain são importantes para alcançar a interoperabilidade no campo blockchain. Portanto, a segurança da ponte é muito importante. Algumas vulnerabilidades de segurança comuns de pontes incluem validação fraca dentro e fora da cadeia, manuseio inadequado de tokens nativos e configuração incorreta. Recomenda-se testar a ponte contra todos os vetores de ataque possíveis para garantir uma lógica de verificação razoável.
Introdução
Bridge blockchain é um protocolo que conecta duas blockchains para permitir a interação entre elas. Se você possui bitcoins, mas deseja participar de atividades DeFi na rede Ethereum, as pontes blockchain permitem que você faça isso sem vender bitcoins.
As pontes Blockchain são essenciais para alcançar a interoperabilidade no campo blockchain. Esta ponte funciona usando várias validações on-chain e off-chain, portanto, possui várias vulnerabilidades de segurança.
Por que a segurança da ponte é importante?
As pontes geralmente armazenam tokens que os usuários desejam transferir de uma cadeia para outra. As pontes são frequentemente implementadas como contratos inteligentes e armazenam grandes quantidades de tokens à medida que as transferências entre cadeias se acumulam, tornando-as alvos tentadores para hackers.
Além disso, as pontes blockchain apresentam uma grande lacuna de ataque porque envolvem muitos componentes. Portanto, os criminosos estão altamente motivados para direcionar aplicações entre cadeias para drenar grandes quantidades de fundos.
Os ataques a pontes causaram perdas de mais de 1,3 mil milhões de dólares em 2022, o que representa 36% das perdas totais desse ano, de acordo com estimativas da CertiK.
Vulnerabilidades comuns de segurança de pontes
Para melhorar a segurança da ponte, é importante compreender as vulnerabilidades de segurança comuns da ponte e testá-la antes do lançamento. Essas vulnerabilidades podem ser categorizadas em quatro áreas.
Validação fraca na cadeia
Para pontes simples, especialmente aquelas projetadas para DApps específicos, a validação on-chain é mínima. A ponte depende de um back-end centralizado para executar operações básicas, como cunhagem, queima e transferência de tokens, enquanto toda a verificação é feita fora da cadeia.
Em contraste, outros tipos de pontes utilizam contratos inteligentes para validar mensagens e realizar verificações em cadeia. Nesta situação, quando um usuário deposita fundos em uma cadeia, o contrato inteligente irá gerar uma mensagem assinada e retornar a assinatura na transação. Esta assinatura serve como prova de depósito e é utilizada para verificar as solicitações dos usuários em outras redes. Este processo deve evitar vários ataques à segurança, incluindo ataques de repetição e registos de depósitos falsos.
No entanto, se existir uma vulnerabilidade durante o processo de validação em cadeia, um invasor poderá causar danos graves. Por exemplo, se uma ponte usar uma árvore Merkle para validar registros de transações, um invasor poderá gerar evidências falsas. Isso significa que eles podem ignorar a validação de prova e criar novos tokens em suas contas se o processo de validação for vulnerável.
Algumas pontes implementam o conceito de “token empacotado”. Por exemplo, quando um usuário transfere DAI do Ethereum para a Cadeia BNB, seu DAI é retirado do contrato Ethereum e uma quantidade equivalente de DAI empacotado é emitida para a Cadeia BNB.
No entanto, se essas transações não forem validadas adequadamente, um invasor poderá implementar um contrato malicioso para rotear tokens empacotados da ponte para o endereço errado, manipulando sua funcionalidade.
O invasor também exige que a vítima concorde com o contrato de ponte para transferir tokens usando a função “transferFrom” para drenar ativos do contrato de ponte.
Infelizmente, isso fica pior porque a maioria das pontes exige aprovação ilimitada de tokens dos usuários DApp. Esta é uma prática comum que reduz as taxas de gás, mas introduz riscos adicionais ao permitir que contratos inteligentes acessem tokens de um número ilimitado de carteiras de usuários. Os invasores podem explorar a falta de validação e aprovação excessiva para transferir tokens de outros usuários para si próprios.
Validação fora da cadeia fraca
Em alguns sistemas de ponte, os servidores backend fora da cadeia desempenham um papel importante na verificação da validade das mensagens enviadas da blockchain. Neste caso, nos concentramos na verificação das transações de depósito.
A forma como uma ponte blockchain funciona com validação fora da cadeia é a seguinte:
Os usuários interagem com o DApp para depositar tokens em contratos inteligentes na cadeia de origem.
Em seguida, o DApp envia o hash da transação de depósito para o servidor backend por meio de uma API.
Hashes de transação requerem alguma validação por parte do servidor. Se for considerado válido, o signatário assina a mensagem e, em seguida, envia a assinatura de volta à interface do usuário por meio da API.
Depois de receber a assinatura, o DApp a verifica e permite que o usuário retire tokens da cadeia de destino.
O servidor backend deve garantir que a transação de depósito processada realmente ocorreu e não foi falsificada. Este servidor back-end determina se os usuários podem retirar tokens da cadeia de destino, tornando-o um alvo de alto valor para os invasores.
O servidor backend deve validar a estrutura do evento resultante da transação, bem como o endereço do contrato que gerou o evento. Se o endereço do contrato for ignorado, um invasor poderá implementar um contrato malicioso para falsificar um evento de depósito usando a mesma estrutura de um evento de depósito legítimo.
Caso não verifique o endereço que gerou o evento, o servidor backend pode assumir que este contrato é válido e assinar a mensagem. Em seguida, o invasor pode enviar o hash da transação para o back-end, ignorando assim a verificação e permitindo retirar tokens da cadeia de destino.
Tratamento inadequado de tokens nativos
O Bridge adota uma variedade de abordagens para lidar com tokens nativos e tokens utilitários. Por exemplo, na rede Ethereum, o token nativo é ETH e a maioria dos tokens utilitários segue o padrão ERC-20.
Quando um usuário pretende transferir seu ETH para outra rede, ele deve primeiro depositá-lo no contrato ponte. Para conseguir isso, os usuários simplesmente anexam ETH a uma transação e então a quantidade de ETH pode ser recuperada lendo o campo “msg.value” da transação.
Depositar tokens ERC-20 é muito diferente de depositar ETH. Para depositar tokens ERC-20, os usuários devem primeiro permitir que o contrato-ponte use seus tokens. Depois que ele concordar e depositar os tokens no contrato ponte, o contrato irá queimar os tokens do usuário usando a função “burnFrom()” ou transferir os tokens do usuário para o contrato usando a função “transferFrom()”.
Uma abordagem para diferenciá-los é usar instruções if-else dentro da mesma função. Outra abordagem é criar duas funções separadas para lidar com cada cenário. A tentativa de depositar ETH usando a função de depósito ERC-20 pode resultar em perda de fundos.
Ao lidar com uma solicitação de depósito ERC-20, os usuários normalmente fornecem um endereço de token como entrada para a função de depósito. Esta ação apresenta riscos significativos, pois podem ocorrer chamadas externas não confiáveis durante as transações. Implementar uma lista de permissões que inclua apenas tokens apoiados por ponte é uma prática comum para minimizar o risco. Somente endereços na lista de permissões podem ser passados como argumentos. Isso evita chamadas externas, porque a equipe do projeto já está filtrando endereços de tokens.
No entanto, também surgem problemas quando a ponte lida com transferências entre cadeias de tokens nativos, porque os tokens nativos não possuem endereços. O endereço zero (0x000...0) representa o token original. Isso pode ser problemático, porque passar um endereço nulo para uma função pode ignorar a verificação da lista de permissões, mesmo se implementado incorretamente.
Quando o contrato de ponte chama “transferFrom” para transferir ativos do usuário para o contrato, a chamada externa para o endereço zero retorna falso porque nenhuma função “transferFrom” é implementada no endereço zero. No entanto, as transações ainda podem ocorrer se o contrato não conseguir lidar corretamente com o valor resultante. Isso cria uma oportunidade para os invasores executarem transações sem transferir tokens para o contrato.
Erro de configuração
Na maioria das pontes blockchain, uma posição privilegiada é responsável por colocar tokens e endereços na lista branca ou na lista negra, atribuir ou alterar signatários e outras configurações importantes. Garantir que todas as configurações sejam precisas é fundamental, pois mesmo erros aparentemente triviais podem causar grandes perdas.
Na verdade, em um incidente, um invasor conseguiu ignorar a verificação do registro de transferência devido a um erro de configuração. A equipe do projeto implementou uma atualização de protocolo vários dias antes do hack, que incluiu a alteração de uma variável. A variável é usada para representar o valor padrão de mensagens confiáveis. Essa mudança faz com que todas as mensagens sejam consideradas comprovadas automaticamente, permitindo que invasores enviem mensagens à vontade e ignorem o processo de verificação.
Como melhorar a segurança da ponte
As quatro vulnerabilidades comuns das pontes descritas acima demonstram os desafios para garantir a segurança em um ecossistema blockchain interconectado. Existem considerações significativas sobre como lidar com cada uma dessas vulnerabilidades. Não existe uma diretriz única que se aplique a tudo.
Por exemplo, é difícil fornecer diretrizes gerais para garantir um processo de verificação livre de erros, pois cada ponte tem requisitos de verificação exclusivos. A abordagem mais eficaz para evitar o desvio de verificação é testar minuciosamente a ponte contra todos os vetores de ataque possíveis e garantir que a lógica de verificação faça sentido.
Em resumo, é importante realizar testes rigorosos para possíveis ataques e prestar especial atenção às vulnerabilidades de segurança comuns nas pontes.
Fechando
Devido ao seu alto valor, as pontes entre cadeias têm sido alvo de ataques há muito tempo. Os construtores podem fortalecer a segurança das pontes realizando testes completos antes da implementação e conduzindo auditorias de terceiros para reduzir o risco de hacks dispendiosos que têm afetado as pontes nos últimos anos. As pontes são essenciais num mundo multi-chain, mas a segurança deve ser uma preocupação primordial ao projetar e construir uma infraestrutura Web3 eficaz.
Leitura adicional
O que é Bridge Blockchain?
O que é interoperabilidade entre cadeias?
Três pontes criptográficas populares e como funcionam
O que são tokens empacotados?
Isenção de responsabilidade e aviso de risco: Este conteúdo é apresentado a você “como está” apenas para informações gerais e para fins educacionais, sem representação ou garantia de qualquer tipo. Este conteúdo não deve ser interpretado como aconselhamento financeiro, jurídico ou outro aconselhamento profissional, nem tem a intenção de recomendar a compra de qualquer produto ou serviço específico. Você deve procurar aconselhamento de consultores profissionais apropriados. Se o artigo for uma contribuição de um colaborador terceirizado, observe que as opiniões expressas são as do colaborador terceirizado e não refletem necessariamente as opiniões da Binance Academy. Por favor, leia nosso aviso completo aqui para obter mais detalhes. Os preços dos ativos digitais podem ser voláteis. O valor do seu investimento pode cair ou subir. Você pode não recuperar o valor investido. Você é totalmente responsável por suas decisões de investimento. A Binance Academy não se responsabiliza por quaisquer perdas que você possa sofrer. Este material não deve ser considerado aconselhamento financeiro, jurídico ou outro aconselhamento profissional. Para mais informações, leia nossos Termos de Uso e Aviso de Risco.