As pontes blockchain são críticas 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 fraca validação on-chain e off-chain, 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 sólida.
Introdução
Uma ponte blockchain é um protocolo que conecta dois blockchains para permitir interações entre eles. Se você possui bitcoin, mas deseja participar da atividade 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 dentro do espaço blockchain . Eles funcionam usando várias validações on-chain e off-chain e, portanto, têm 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 mantê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 agentes mal-intencionados são altamente motivados a direcionar aplicativos de cadeia cruzada para drenar grandes somas de fundos.
Os ataques às pontes levaram a perdas de mais de 1,3 bilhão de dólares em 2022, respondendo por 36% das perdas totais do ano, de acordo com estimativas da CertiK.
Vulnerabilidades comuns de segurança de ponte
Para aprimorar a segurança das pontes, é importante entender 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 on-chain é mínima. Essas pontes dependem de um back-end centralizado para executar operações básicas, como cunhagem, gravação e transferências de token, enquanto todas as verificações são realizadas fora da cadeia.
Em contraste, outros tipos de pontes usam contratos inteligentes para validar mensagens e realizar verificações na cadeia. Nesse 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 cadeia. Este processo deve ser capaz de prevenir vários ataques de segurança, incluindo ataques de repetição e registros 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 usa a árvore Merkle para validar o registro da transação, um invasor pode gerar provas forjadas. 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 encapsulados ”. Por exemplo, quando um usuário transfere DAI de Ethereum para BNB Chain, seu DAI é retirado do contrato Ethereum e uma quantidade equivalente de DAI empacotada é emitida na BNB Chain.
No entanto, se esta transação não for devidamente validada, um invasor pode implantar um contrato malicioso para rotear os tokens encapsulados 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 é agravado porque muitas pontes solicitam aprovação de token infinita dos usuários do DApp. Essa é uma prática comum que reduz as taxas de 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 mesmos.
Validação off-chain fraca
Em alguns sistemas de ponte, o servidor de back-end off-chain desempenha um papel crítico na verificação da legitimidade das mensagens enviadas do 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 maneira:
- 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 de back-end por meio 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 cadeia de destino.
O servidor de back-end deve garantir que a transação de depósito que ele processa realmente ocorreu e não foi falsificada. Esse servidor de back-end determina se um usuário pode retirar tokens na cadeia de destino e é, portanto, um alvo de alto valor para os invasores.
O servidor backend precisa validar a estrutura do evento emitido pela transação, bem como o endereço do contrato que emitiu o evento. Se o último for negligenciado, um invasor pode 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 back-end não verificar qual endereço emitiu o evento, ele considerará esta transação válida e assinará a mensagem. O invasor pode enviar o hash da transação para o back-end, ignorando a verificação e permitindo que eles retirem os tokens da cadeia de destino.
Manipulação inadequada de tokens nativos
As pontes adotam abordagens diferentes para lidar com tokens nativos e tokens de utilidade. 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 a quantidade de ETH pode ser recuperada 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 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. Tentar 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. Isso representa um risco significativo, pois chamadas externas não confiáveis podem ocorrer durante a transação. A implementação de uma lista de permissões que inclui apenas os tokens suportados pela ponte é uma prática comum para minimizar o risco. Apenas os endereços da 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 de cadeia cruzada de token nativo, pois o token nativo não possui um endereço. Um endereço zero (0x000…0) é representativo do 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á 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 invasores executarem a transação sem transferir nenhum token para o contrato.
Configuração incorreta
Na maioria das pontes de blockchain, uma função privilegiada é responsável por colocar tokens e endereços na lista branca ou 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.
De fato, houve um incidente em que o invasor ignorou com sucesso 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 alteração resultou em todas as mensagens sendo automaticamente consideradas comprovadas, permitindo assim que um invasor envie uma mensagem arbitrária e passe 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 de blockchain interconectado. Existem considerações importantes para lidar com cada uma dessas vulnerabilidades, e nenhuma cartilha se aplica a todas elas.
Por exemplo, fornecer diretrizes gerais para garantir um processo de verificação sem erros é um desafio, pois cada ponte possui requisitos de verificação exclusivos. A abordagem mais eficaz para evitar o desvio de verificação é testar completamente a ponte contra todos os vetores de ataque possíveis e garantir que a lógica de verificação seja sólida.
Para resumir, é 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 de cadeia cruzada têm sido um alvo para os invasores. 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 hacks devastadores que atormentaram as pontes nos últimos anos. As pontes são essenciais em um mundo com várias cadeias, mas a segurança deve ser a principal preocupação ao projetar e construir uma infra-estrutura Web3 eficaz.
