Este artigo é uma contribuição da comunidade. O autor é Minzhi He, auditor da CertiK.
As opiniões 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 essenciais para alcançar a interoperabilidade no espaço blockchain. Portanto, sua segurança é de extrema importância. Algumas das vulnerabilidades de segurança de ponte mais comuns incluem validação fraca dentro e fora da cadeia, manuseio inadequado de tokens nativos e configurações incorretas. Recomenda-se testar a ponte contra todos os vetores de ataque possíveis para garantir uma lógica de verificação robusta.
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 uma atividade DeFi na rede Ethereum, uma ponte blockchain permite que você faça isso sem precisar vender seu Bitcoin.
As pontes Blockchain são essenciais para alcançar a interoperabilidade no espaço blockchain. Eles funcionam por meio de diversas validações on-chain e off-chain, portanto apresentam diferentes vulnerabilidades de segurança.
Por que a segurança da ponte é essencial?
Normalmente, uma ponte conterá o token que um usuário deseja transferir de uma cadeia para outra. As pontes, que muitas vezes são implementadas como contratos inteligentes, 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 porque incluem vários componentes. Com isso em mente, os atores mal-intencionados consideram os aplicativos cross-chain alvos muito bons para roubar grandes quantidades de fundos.
Em 2022, os ataques a pontes geraram perdas de mais de 1,3 mil milhões de dólares, representando 36% das perdas totais do ano, segundo estimativas da CertiK.
Vulnerabilidades comuns de segurança de ponte
Para melhorar a segurança das pontes, é importante compreender as suas vulnerabilidades mais comuns e testá-las antes do seu lançamento. Essas vulnerabilidades podem ser classificadas 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. Nestes casos, quando um usuário deposita on-chain, o contrato inteligente gera uma mensagem assinada e retorna a assinatura na transação. A assinatura serve como comprovante do depósito e é utilizada para verificar a solicitação de saque do usuário na outra rede. Este processo deverá ser capaz de prevenir vários tipos de ataques à segurança, incluindo ataques de repetição e falsificação de registos de depósitos.
Porém, se houver uma vulnerabilidade no processo de validação on-chain, o invasor pode causar grandes danos. Por exemplo, se uma ponte usar a árvore Merkle para validar o log de transações, um invasor poderá gerar recibos falsificados. Isso significa que se o processo de validação for vulnerável, o invasor poderá ignorar a validação do recibo e cunhar novos tokens para sua conta.
Algumas pontes implementam o conceito de "tokens empacotados". Por exemplo, quando um usuário transfere DAI do Ethereum para a Cadeia BNB, o DAI é retirado do contrato Ethereum e uma quantidade equivalente de DAI empacotado é emitida na Cadeia BNB.
No entanto, se a transação não for validada corretamente, um invasor poderá implementar um contrato malicioso para direcionar os tokens empacotados da ponte para um endereço incorreto.
Os invasores também precisam que as vítimas aprovem o contrato-ponte para transferir tokens usando a função “transferFrom” e, assim, drenar os ativos do contrato-ponte.
Infelizmente, isso é pior porque muitas pontes solicitam aprovação infinita de tokens dos usuários de DApps. 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 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, o servidor backend fora da cadeia desempenha um papel crítico na verificação da legitimidade das mensagens enviadas da blockchain. Desta vez vamos nos concentrar na verificação das 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 da cadeia de origem.
O DApp então envia o hash da transação de depósito para o servidor backend por meio de uma API.
O hash da transação passa por diversas validações por parte do servidor. Se for considerado legítimo, um signatário assina a mensagem e envia a assinatura de volta para a IU por meio da API.
Ao receber a assinatura, o DApp a verifica e autoriza o usuário a retirar os tokens da cadeia alvo.
O servidor backend deve garantir que a transação de depósito que ele processa realmente ocorreu e não é uma falsificação. Este servidor back-end determina se o usuário pode retirar tokens da cadeia de destino e, portanto, é um alvo de ataque muito procurado pelos cibercriminosos.
O servidor backend deve 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 falsificar um evento de depósito com a mesma estrutura do evento de depósito legítimo.
Se o servidor backend não verificar qual endereço emitiu o evento, ele poderá considerá-lo uma transação válida e assinar a mensagem. O invasor poderia então enviar o hash da transação para o backend, ignorando a verificação e conseguindo remover 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.
Se um usuário tentar transferir seu ETH para outra rede, ele deverá primeiro depositá-lo no contrato ponte. Para conseguir isso, o usuário simplesmente anexa o ETH à transação, e 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 um token ERC-20, o usuário deve primeiro permitir que o contrato-ponte gaste seus tokens. Após a aprovação e os tokens terem sido depositados 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 com a função "transferFrom()".
Uma maneira de diferenciar isso é usar uma instrução condicional dentro da própria função. Outra maneira é criar duas funções separadas para lidar com cada cenário. A tentativa de depositar ETH usando o recurso de depósito do ERC-20 pode resultar na perda de fundos.
Ao lidar com solicitações de depósito ERC-20, os usuários normalmente fornecem o endereço do token como entrada para a função de depósito. Isto envolve 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 tokens suportados pela ponte é uma prática comum para minimizar esse risco. Somente endereços na lista de permissões podem ser passados como argumento. Isso evita chamadas externas, pois a equipe do projeto já vazou o endereço do token.
No entanto, podem surgir problemas quando as pontes lidam com a transferência de tokens nativos entre cadeias, uma vez que 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 implementado corretamente.
Quando o contrato ponte chama "transferFrom" para transferir os ativos do usuário para o contrato, a chamada externa para o endereço zero retorna falso porque no endereço zero não há nenhuma função "transferFrom" implementada. Porém, a transação ainda pode ocorrer se o contrato não tratar adequadamente o valor devolvido. Isso cria uma oportunidade para os invasores executarem a transação sem transferir nenhum token para o contrato.
Configuração errada
Na maioria das pontes blockchain, a pessoa responsável por colocar tokens e endereços na lista branca ou negra, atribuir ou alterar signatários e outras configurações críticas é uma função privilegiada. Garantir que todas as configurações sejam precisas é fundamental, pois mesmo os descuidos aparentemente mais triviais podem levar a perdas significativas.
Na verdade, houve um incidente em que o invasor contornou com êxito a verificação do log de transferência devido a uma configuração incorreta. A equipe do projeto implementou uma atualização de protocolo alguns dias antes do hack, e essa atualização 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 fez com que todas as mensagens fossem automaticamente classificadas como testadas, permitindo que o 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 mais comuns explicadas até agora 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 não existe uma solução fácil que funcione para todas elas.
Por exemplo, é difícil fornecer diretrizes gerais para garantir um processo de verificação livre de erros porque cada ponte tem requisitos de verificação exclusivos. A abordagem mais eficaz para evitar o desvio de verificação é testar minuciosamente a ponte contra possíveis vetores de ataque e garantir que a lógica de verificação seja robusta.
Em suma, é essencial testar rigorosamente contra potenciais ataques e prestar especial atenção às vulnerabilidades de segurança mais comuns das pontes.
Conclusões
Devido ao seu alto valor, as pontes entre cadeias têm sido alvo de ataques há muito tempo. Os desenvolvedores podem fortalecer a segurança de suas pontes realizando extensos testes de pré-implantação e participando de auditorias de terceiros, reduzindo o risco de recorrência dos hacks devastadores que afetaram as pontes nos últimos anos. As pontes são essenciais para o mundo multichain, mas a segurança deve ser uma prioridade 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 elas funcionam
O que são tokens empacotados?
Aviso Legal e Aviso de Risco: Este conteúdo é apresentado "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 individual de consultores profissionais adequados. Como este artigo foi contribuído por terceiros, observe que as opiniões expressas são do colaborador terceirizado e não refletem necessariamente as da Binance Academy. Para mais informações, leia nosso aviso legal completo aqui. Os preços dos ativos digitais podem ser voláteis. O valor de um investimento pode diminuir ou aumentar e você pode não recuperar o valor investido. Somente você é responsável por suas decisões de investimento. 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.
