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 opiniões da Binance Academy.
TL;DR
As blockchain bridges são fundamentais para alcançar a interoperabilidade dentro do espaço blockchain. A segurança de blockchain bridges é de suma importância. Algumas vulnerabilidades de segurança comuns de bridges incluem problemas com a validação on-chain e off-chain, gerenciamento inadequado de tokens nativos e configurações incorretas. Recomenda-se testar a bridge contra todos os vetores de ataque possíveis para garantir uma lógica de verificação sólida.
Introdução
Uma blockchain bridge (ou "ponte blockchain") é um protocolo que conecta duas blockchains para permitir interações entre elas. Se você possui bitcoins, mas quer participar da atividade DeFi na rede Ethereum, uma blockchain bridge permite que você faça isso sem precisar vender seus bitcoins.
Blockchain bridges são fundamentais para alcançar a interoperabilidade dentro do espaço blockchain. Elas funcionam usando várias validações on-chain e off-chain e, portanto, apresentam diferentes vulnerabilidades de segurança.
Por que a segurança de bridges é fundamental?
Geralmente, uma bridge detém o token que um usuário deseja transferir de uma blockchain para outra. Bridges são, muitas vezes, implantadas como contratos inteligentes e detêm uma quantidade significativa de tokens à medida que as transferências cross-chain se acumulam, o que as torna alvos potencialmente lucrativos para hackers.
Além disso, as blockchain bridges têm muitos pontos suscetíveis a ataques, pois envolvem muitos componentes. Com isso em mente, usuários mal-intencionados são motivados a alvejar aplicações cross-chain, na tentativa de roubar grandes quantias.
Em 2022, ataques a bridges ocasionaram perdas de mais de 1,3 bilhão de dólares, representando 36% das perdas totais do ano, de acordo com estimativas da CertiK.
Vulnerabilidades de segurança comuns de bridges
Para aumentar a segurança das bridges, é importante entender suas vulnerabilidades comuns e testá-las antes do lançamento. Essas vulnerabilidades podem ser categorizadas nas quatro áreas a seguir.
Validação on-chain fraca
Para bridges simples, especialmente as projetadas para DApps específicos, a validação on-chain é mantida em um nível mínimo. Essas bridges dependem de um backend centralizado para execução de operações básicas como emissão, queima e transferência de tokens, enquanto todas as verificações são realizadas off-chain.
Por outro lado, outros tipos de bridges usam contratos inteligentes para validar mensagens e realizar verificações on-chain. Nesse cenário, quando um usuário deposita fundos em uma blockchain, o contrato inteligente gera uma mensagem assinada e retorna a assinatura na respectiva transação. Essa assinatura serve como comprovante do depósito e é utilizada para verificar a solicitação de saque do usuário na outra blockchain. Este processo deve ser capaz de prevenir vários ataques de segurança, incluindo ataques de repetição (replay attacks) e registros falsificados de depósitos.
No entanto, se houver uma vulnerabilidade durante o processo de validação on-chain, um hacker poderá causar danos graves. Por exemplo, se uma bridge usa Merkle tree para validar o registro da transação, um invasor pode forjar provas falsificadas. Isso significa que, caso o processo de validação seja vulnerável, eles podem ignorar a validação de prova e criar novos tokens em suas contas.
Algumas bridges implementam o conceito de “wrapped tokens.” Por exemplo, quando um usuário transfere DAI da Ethereum para a BNB Chain, seu DAI é retirado do contrato da Ethereum e uma quantidade equivalente de wrapped DAI é emitida na BNB Chain.
No entanto, se esta transação não for devidamente validada, um hacker pode implantar um contrato malicioso e manipular a função para rotear os wrapped tokens da bridge para um endereço incorreto.
Os hackers precisam que as vítimas aprovem o contrato da bridge para transferir os tokens usando a função “transferFrom” e roubar os ativos do contrato.
Infelizmente, esse problema se agrava porque muitas bridges solicitam acesso irrestrito (infinite token approval) aos tokens dos usuários do DApp. Essa é uma prática comum que reduz as taxas de Gas, mas gera riscos adicionais ao permitir que um contrato inteligente acesse um número ilimitado de tokens da carteira do usuário. Alguns hackers são capazes de explorar a falta de validação e o acesso irrestrito para roubar tokens de outros usuários.
Validação off-chain fraca
Em alguns sistemas de bridge, o servidor de backend off-chain desempenha um papel crítico na verificação da legitimidade das mensagens enviadas a partir da blockchain. Neste caso, vamos focar na verificação de transações de depósito.
Uma blockchain bridge com validação off-chain funciona da seguinte maneira:
Usuários interagem com o DApp para depositar tokens no contrato inteligente na blockchain de origem.
Em seguida, o DApp envia o hash da transação de depósito para o servidor de backend através de uma API.
O hash da transação está sujeito a várias validações por parte do servidor. Se 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 que o usuário retire seus tokens da blockchain de origem.
O servidor de backend deve garantir que a transação de depósito processada realmente ocorreu e não foi falsificada. É esse servidor que determina se um usuário pode retirar tokens na blockchain de destino. Por isso, é um alvo valioso para hackers.
O servidor de backend precisa validar a estrutura do evento emitido pela transação, bem como o endereço do contrato que emitiu esse evento. Se o último for negligenciado, um hacker pode implantar um contrato malicioso para forjar um evento de depósito com a mesma estrutura de um evento legítimo.
Se o servidor de backend não verificar qual endereço emitiu o evento, ele considerará esta transação válida e assinará a mensagem. O hacker pode enviar o hash da transação para o backend, ignorando a verificação e permitindo que eles retirem os tokens da blockchain.
Gerenciamento inadequado de tokens nativos
As bridges usam abordagens diferentes para lidar com tokens nativos e tokens de utilidade. Por exemplo, na rede Ethereum, o token nativo é o ETH e a maioria dos tokens de utilidade adere ao padrão ERC-20.
Quando um usuário deseja transferir ETH para outra blockchain, ele deve primeiro depositar os tokens no contrato da bridge. Para isso, o usuário simplesmente anexa o ETH à transação e a quantia pode ser recuperada através da função “msg.value” no campo da transação.
O depósito de tokens ERC-20 difere significativamente do depósito de ETH. Para depositar um token ERC-20, primeiro o usuário deve permitir que o contrato da bridge gaste seus tokens. Após a aprovação e depósito dos tokens no contrato da bridge, o contrato queimará os tokens do usuário usando a função "burnFrom()" ou transferirá os tokens 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. Tentar depositar ETH usando a função de depósito ERC-20 pode resultar na perda dos fundos.
Para 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. Essa operação apresenta riscos, pois podem ocorrer chamadas externas não confiáveis durante a transação. A implementação de uma lista de permissões (whitelist) incluindo apenas os tokens suportados pela bridge é uma prática comum para minimizar os riscos. Apenas endereços da lista de permissões são aceitos 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 bridges lidam com a transferência cross-chain de tokens nativos, já que um token nativo não possui um endereço. Um endereço zero (0x000...0) é representativo do token nativo. Isso pode ser problemático, pois submeter o endereço zero à função pode fazer com que ela ignore a verificação da lista de permissões, mesmo se implementada incorretamente.
Quando o contrato de bridge chama a função “transferFrom” para transferir ativos do usuário para o contrato, a chamada externa para o endereço zero retorna falso, pois não há nenhuma 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 hackers executarem a transação sem transferir nenhum token para o contrato.
Configuração incorreta
Na maioria das blockchain bridges, uma função privilegiada é responsável por colocar tokens e endereços na lista de permitidos e não permitidos, 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 ocasionar perdas significativas.
De fato, houve um incidente em que o hacker conseguiu desviar da verificação do registro de transferência devido a uma configuração incorreta. Alguns dias antes do ataque, a equipe do projeto implementou uma atualização de protocolo que envolvia a alteração de uma variável. A variável foi usada para representar o valor padrão da mensagem confiável. Por conta dessa alteração, todas as mensagens eram automaticamente consideradas comprovadas, permitindo assim que um invasor enviasse uma mensagem arbitrária e conseguisse passar no processo de verificação.
Como melhorar a segurança de bridges
As quatro vulnerabilidades mais comuns de bridges explicadas acima, evidenciam os desafios de garantir a segurança em um ecossistema blockchain interconectado. Existem considerações importantes para lidar com cada uma dessas vulnerabilidades e não há um guia que se aplique a todas elas.
Por exemplo, fornecer diretrizes gerais para garantir um processo de verificação sem erros é um desafio, pois cada bridge possui seus próprios requisitos de verificação. A abordagem mais eficaz para evitar o desvio da verificação é testar minuciosamente a bridge contra todos os vetores de ataque possíveis e garantir que a lógica de verificação seja sólida e consistente.
Em suma, é essencial realizar testes rigorosos contra possíveis ataques e prestar atenção especial às vulnerabilidades de segurança mais comuns em bridges.
Considerações finais
Devido ao seu alto valor, bridges cross-chain têm sido alvo de hackers há um bom tempo. Desenvolvedores podem aprimorar a segurança de suas bridges através de testes de pré-implantação e auditorias de terceiros, reduzindo o risco de ataques hackers devastadores como os dos últimos anos. Bridges são essenciais em um mundo com múltiplas blockchains, mas a segurança deve ser uma prioridade ao projetar e desenvolver uma infra-estrutura Web3 eficaz.
Leituras adicionais
O que é uma Blockchain Bridge?
O que é interoperabilidade cross-chain?
Três bridges cripto populares e como funcionam
Aviso de Risco e Isenção de Responsabilidade: este conteúdo é apresentado a você “no estado em que se encontra“ apenas para fins informativos e educacionais, sem qualquer tipo de garantia. O conteúdo não deve ser interpretado como aconselhamento financeiro, jurídico ou profissional, e não tem o objetivo de recomendar a compra de qualquer produto ou serviço específico. Você deve buscar seu próprio conselho de consultores profissionais. No caso de contribuições e artigos enviados por colaboradores terceirizados, note que as opiniões expressas pertencem ao respectivo autor e não refletem necessariamente as opiniões da Binance Academy. Para mais detalhes, por favor leia nosso aviso aqui. Os preços dos ativos digitais podem ser voláteis. O valor do seu investimento pode aumentar ou diminuir 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 nenhuma de suas possíveis perdas. Este material não deve ser interpretado como aconselhamento financeiro, jurídico ou profissional. Para mais informações, por favor consulte nossos Termos de Uso e Aviso de Risco.