Este artigo é um envio da comunidade. O autor é Minzhi He, auditor da CertiK.
As opiniões neste artigo são do colaborador/autor e não refletem necessariamente as da Binance Academy.
DR
As pontes Blockchain são essenciais para alcançar a interoperabilidade no espaço blockchain. Portanto, a segurança da ponte é de suma importância. Algumas vulnerabilidades comuns de segurança de ponte incluem validação fraca dentro e fora da cadeia, manuseio inadequado de tokens nativos e configurações incorretas. É recomendado testar a ponte contra todos os vetores de ataque possíveis para garantir uma lógica de verificação sólida.
Introdução
Uma ponte blockchain é um protocolo que conecta duas blockchains para permitir interações entre elas. Se você possui bitcoin, mas deseja participar de atividades DeFi na rede Ethereum, uma ponte blockchain permite que você faça isso sem vender seu bitcoin.
As pontes Blockchain são fundamentais para alcançar a interoperabilidade no espaço blockchain. Eles funcionam usando várias validações on-chain e off-chain e, portanto, apresentam diferentes vulnerabilidades de segurança.
Por que a segurança da ponte é crítica?
Uma ponte geralmente contém o token que um usuário deseja transferir de uma cadeia para outra. Muitas vezes implantadas como contratos inteligentes, as pontes retêm uma quantidade significativa de tokens à medida que as transferências entre cadeias se acumulam, tornando-as alvos lucrativos para hackers.
Além disso, as pontes blockchain têm uma grande superfície de ataque, pois envolvem muitos componentes. Com isso em mente, os atores mal-intencionados estão altamente motivados para atacar aplicações de cadeia cruzada para drenar grandes somas de fundos.
Os ataques a pontes levaram a perdas de mais de 1,3 mil milhões de dólares em 2022, representando 36% das perdas totais do ano, de acordo com estimativas da CertiK.
Vulnerabilidades comuns de segurança de ponte
Para aumentar a segurança das pontes, é valioso compreender as vulnerabilidades comuns de segurança das pontes e testá-las antes do lançamento. Essas vulnerabilidades podem ser categorizadas nas quatro áreas a seguir.
Validação fraca na cadeia
Para pontes simples, especialmente aquelas projetadas para DApps específicos, a validação na cadeia é reduzida ao mínimo. Essas pontes contam com um back-end centralizado para executar operações básicas como cunhagem, queima e transferência de tokens, enquanto todas as verificações são realizadas fora da cadeia.
Em contraste, outros tipos de pontes utilizam contratos inteligentes para validar mensagens e realizar verificações na cadeia. Neste cenário, quando um usuário deposita fundos em uma cadeia, o contrato inteligente gera uma mensagem assinada e retorna a assinatura na transação. Essa assinatura serve como comprovante do depósito e é utilizada para verificar a solicitação de saque do usuário na outra rede. Este processo deve ser capaz de evitar vários ataques à segurança, incluindo ataques de repetição e registos de depósitos forjados.
No entanto, se houver uma vulnerabilidade durante o processo de validação on-chain, o invasor poderá causar danos graves. Por exemplo, se uma ponte usar a árvore Merkle para validar o registro da transação, um invasor poderá gerar provas 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.
Certas pontes implementam o conceito de “tokens empacotados”. 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 na Cadeia BNB.
No entanto, se esta transação não for devidamente validada, um invasor poderá implantar um contrato malicioso para rotear os tokens empacotados da ponte para um endereço incorreto, manipulando a função.
Os invasores também precisam que as vítimas aprovem o contrato-ponte para transferir tokens usando a função “transferFrom” para drenar ativos do contrato-ponte.
Infelizmente, isso é pior porque muitas pontes solicitam aprovação infinita de tokens dos usuários do DApp. Esta é uma prática comum que reduz as taxas do gás, mas cria riscos adicionais ao permitir que um contrato inteligente acesse um número ilimitado de tokens da carteira do usuário. Os invasores são capazes de 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, o servidor backend fora da cadeia desempenha um papel crítico na verificação da legitimidade das mensagens enviadas da blockchain. Neste caso, estamos nos concentrando na verificação de transações de depósito.
Uma ponte blockchain com validação off-chain funciona da seguinte forma:
Os usuários interagem com o DApp para depositar tokens no contrato inteligente na cadeia de origem.
O DApp então envia o hash da transação de depósito para o servidor back-end por meio de uma API.
O hash da transação está sujeito a diversas validações por parte do servidor. Se for considerado legítimo, um signatário assina uma mensagem e envia a assinatura de volta para a interface do usuário por meio da API.
Ao receber a assinatura, o DApp a verifica e permite ao usuário retirar seus tokens da cadeia de origem.
O servidor backend deve garantir que a transação de depósito que ele processa realmente ocorreu e não foi forjada. Este servidor backend determina se um usuário pode retirar tokens da cadeia de destino e é, portanto, um alvo de alto valor para invasores.
O servidor backend precisa validar a estrutura do evento emitido da transação, bem como o endereço do contrato que emitiu o evento. Se este último for negligenciado, um invasor poderá implantar um contrato malicioso para forjar um evento de depósito com a mesma estrutura de um evento de depósito legítimo.
Se o servidor backend não verificar qual endereço emitiu o evento, ele consideraria isso uma transação válida e assinaria a mensagem. O invasor poderia então enviar o hash da transação para o back-end, ignorando a verificação e permitindo retirar os tokens da cadeia de destino.
Tratamento inadequado de tokens nativos
As pontes adotam abordagens diferentes 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 adere ao 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, o usuário simplesmente anexa o ETH à transação, e o valor do ETH pode ser recuperado lendo o campo “msg.value” da transação.
O depósito de tokens ERC-20 difere significativamente do depósito de ETH. Para depositar um token ERC-20, o usuário deve primeiro permitir que o contrato-ponte gaste seus tokens. Depois de aprovarem isso e depositarem os tokens no contrato ponte, o contrato queimará os tokens do usuário usando a função "burnFrom()" ou transferirá o token do usuário para o contrato usando a função "transferFrom()".
Uma abordagem para diferenciar isso é usar uma instrução 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 na perda desses fundos.
Ao lidar com solicitações de depósito ERC-20, os usuários geralmente fornecem o endereço do token como entrada para a função de depósito. Isto representa um risco significativo, pois podem ocorrer chamadas externas não confiáveis durante a transação. Implementar uma lista de permissões que inclua apenas os tokens suportados pela 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, pois a equipe do projeto já filtrou o endereço do token.
No entanto, também podem surgir problemas quando as pontes lidam com a transferência entre cadeias de tokens nativos, pois o token nativo não possui um endereço. Um endereço zero (0x000...0) representa o token nativo. Isso pode ser problemático, pois passar o endereço zero para a função pode ignorar a verificação da lista de permissões, mesmo se implementada 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, pois não há função “transferFrom” implementada no endereço zero. No entanto, a transação ainda pode ocorrer se o contrato não tratar o valor de retorno de forma adequada. Isso cria uma oportunidade para os invasores executarem a transação sem transferir nenhum token para o contrato.
Configuração incorreta
Na maioria das pontes blockchain, uma funçã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 críticas. Garantir que todas as configurações sejam precisas é crucial, pois mesmo descuidos aparentemente triviais podem levar a perdas significativas.
Na verdade, houve um incidente em que o invasor contornou com êxito a verificação do registro de transferência devido a uma configuração incorreta. A equipe do projeto implementou uma atualização de protocolo alguns dias antes do hack, que envolveu a alteração de uma variável. A variável foi usada para representar o valor padrão da mensagem confiável. Essa mudança resultou em todas as mensagens sendo automaticamente consideradas comprovadas, permitindo assim que um invasor enviasse uma mensagem arbitrária e passasse no processo de verificação.
Como melhorar a segurança da ponte
As quatro vulnerabilidades de ponte comuns explicadas acima demonstram os desafios para garantir a segurança em um ecossistema blockchain interconectado. Existem considerações importantes para lidar com cada uma dessas vulnerabilidades, e nenhum manual se aplica a todas elas.
Por exemplo, fornecer diretrizes gerais para garantir um processo de verificação livre de erros é um desafio, uma vez que cada ponte possui 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 esteja correta.
Resumindo, é essencial realizar testes rigorosos contra possíveis ataques e prestar atenção especial às vulnerabilidades de segurança mais comuns em pontes.
Considerações finais
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 de suas pontes realizando testes completos de pré-implantação e participando de auditorias de terceiros, reduzindo o risco de ataques devastadores que afetaram as pontes nos últimos anos. As pontes são críticas 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 é uma ponte Blockchain?
O que é interoperabilidade entre cadeias?
Três pontes criptográficas populares e como funcionam
What Are Wrapped Tokens?
Isenção de responsabilidade e aviso de risco: Este conteúdo é apresentado a você “como está” apenas para fins informativos gerais e educacionais, sem representação ou garantia de qualquer tipo. 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. Quando o artigo for contribuído por um contribuidor terceirizado, observe que as opiniões expressas pertencem ao contribuidor terceirizado e não refletem necessariamente as 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 diminuir ou aumentar e você pode não recuperar o valor investido. Você é o único responsável por suas decisões de investimento e a Binance Academy não se responsabiliza por quaisquer perdas que você possa incorrer. Este material não deve ser interpretado como aconselhamento financeiro, jurídico ou outro aconselhamento profissional. Para obter mais informações, consulte nossos Termos de Uso e Aviso de Risco.