Este artigo é uma contribuição 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.
Em resumo
As pontes Blockchain são a base para alcançar a interoperabilidade no setor blockchain. Portanto, proteger as pontes é muito importante. Algumas vulnerabilidades comuns de segurança de ponte incluem autenticação fraca dentro e fora da cadeia, manuseio inadequado de tokens nativos e configurações incorretas. A ponte deve ser testada para garantir que possa suportar todos os vetores de ataque e garantir uma lógica de verificação adequada.
Introduzir
Uma ponte blockchain é um protocolo que conecta duas blockchains para permitir a interação entre elas. Se você possui bitcoin, mas deseja participar de atividades DeFi na rede Ethereum, a ponte blockchain permitirá que você faça isso sem vender seu bitcoin.
As pontes Blockchain são fundamentais para alcançar a interoperabilidade no setor blockchain. Eles operam usando diferentes autenticações on-chain e off-chain e, portanto, apresentam diferentes vulnerabilidades de segurança.
Por que a segurança da ponte é importante?
As pontes normalmente contêm tokens que os usuários desejam 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 porque envolvem muitos componentes. Dada essa natureza, os atores mal-intencionados estão altamente motivados para visar aplicações entre cadeias para retirar grandes somas de fundos.
Os ataques a pontes levaram a perdas de mais de US$ 1,3 bilhão em 2022, representando 36% das perdas totais do ano, de acordo com estimativas da CertiK.
Vulnerabilidades de ponte comuns
Para melhorar a segurança da ponte, é valioso compreender as vulnerabilidades comuns da ponte e testá-la antes de lançá-la. Essas vulnerabilidades podem ser classificadas em quatro tipos, como segue.
Autenticação on-chain fraca
Para pontes simples, especialmente aquelas projetadas para DApps específicos, a validação on-chain costuma ser mínima. Essas pontes contam com um back-end centralizado para realizar 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ção em cadeia. Nesse caso, quando um usuário deposita dinheiro em uma cadeia, o contrato inteligente gera uma mensagem assinada e retorna a assinatura na transação. Essa assinatura serve como comprovante de depósito, utilizada para verificar a solicitação de saque de um usuário em outra rede. Este processo será capaz de evitar vários ataques à segurança, incluindo ataques de repetição e registros de depósitos falsos.
No entanto, se houver vulnerabilidades no processo de autenticação on-chain, um invasor poderá causar sérios danos. Por exemplo, se uma ponte usar uma árvore Merkle para autenticar registros de transações, um invasor poderá criar provas adulteradas. Isso significa que eles podem ignorar a autenticação de prova e criar novos tokens em suas contas se o processo de autenticação for vulnerável.
Algumas 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 é liberada na Cadeia BNB.
No entanto, se esta transação não for devidamente autenticada, um invasor poderá implantar um contrato malicioso para rotear tokens empacotados da ponte para um endereço incorreto, manipulando a funcionalidade.
Os invasores também precisam que a vítima aprove o contrato-ponte para transferir os tokens usando a função “transferFrom” para retirar ativos do contrato-ponte.
Infelizmente, isso fica pior porque muitas pontes exigem aprovação ilimitada de tokens dos usuários do DApp. Este é um método popular que reduz as taxas de gás, mas cria riscos adicionais ao permitir que o contrato inteligente acesse um número ilimitado de tokens da carteira do usuário. Os invasores podem explorar a falta de autenticação e aprovações excessivas para transferir tokens de outros usuários para eles.
Autenticação fora da cadeia fraca
Em alguns sistemas de ponte, os servidores backend fora da cadeia desempenham um papel importante na verificação da legitimidade das mensagens enviadas da blockchain. Neste caso, estamos nos concentrando na verificação das transações de depósito.
Uma ponte blockchain com autenticação fora da cadeia funciona da seguinte forma:
Os usuários interagem com o DApp para depositar tokens em um contrato inteligente na cadeia de origem.
Este DApp então envia a string hash da transação de depósito para o servidor backend via API.
A string hash da transação está sujeita a alguma validação do servidor. Se for considerado legítimo, o signatário assina uma mensagem e envia a assinatura de volta à interface do usuário por meio da API.
Ao receber uma assinatura, o DApp irá verificá-la e permitir que os usuários retirem seus tokens da cadeia alvo.
O servidor backend deve garantir que a transação de depósito que ele processa realmente ocorreu e não foi adulterada. Este servidor back-end determina se os usuários podem retirar tokens da cadeia de destino e, portanto, é um alvo de alto valor para os 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 ignorado, um invasor poderá implantar um contrato malicioso para falsificar 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 considera esta uma transação válida e assina a mensagem. O invasor pode então enviar o hash da transação para o backend, ignorando a verificação e permitindo retirar tokens da cadeia de destino.
Tratamento inadequado de tokens nativos
As pontes têm abordagens diferentes para lidar com tokens nativos e tokens utilitários. Por exemplo, na rede Ethereum, os tokens nativos são ETH e a maioria dos tokens utilitários está em conformidade com o padrão ERC-20.
Quando os usuários pretendem transferir seu ETH para outra rede, eles devem primeiro depositá-lo no contrato ponte. Para isso, basta o usuário anexar ETH à transação e o valor de ETH pode ser obtido lendo o campo “msg.value” da transação.
O envio de tokens ERC-20 é significativamente diferente do envio de ETH. Para depositar um token ERC-20, os usuários devem primeiro autorizar o contrato-ponte para gastar seus tokens. Depois de aprovar isso e depositar os tokens no contrato de ponte, o contrato 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 diferenciar isso é usar uma instrução if-else dentro da mesma função. Outra abordagem é criar duas funções separadas para lidar com cada situação. A tentativa de depositar ETH usando a função de depósito ERC-20 pode resultar na perda desses fundos.
Ao processar solicitações de depósito ERC-20, os usuários normalmente fornecem endereços de 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 tokens com suporte de ponte é uma forma popular de mitigar riscos. Somente endereços na lista de permissões podem ser passados como argumentos. Isso evita chamadas externas porque a equipe do projeto filtrou endereços de token.
No entanto, também podem surgir problemas quando as pontes lidam com transferências entre cadeias de tokens nativos, uma vez que os tokens nativos não possuem um endereço. O endereço número 0 (0x000...0) representa o token original. Isso pode ser problemático porque passar o endereço 0 para uma 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 os ativos do usuário para o contrato, a chamada externa para o endereço zero retorna falso porque 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 fazerem transações sem transferir nenhum token para o contrato.
Configuração errada
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 importantes. Garantir que todas as configurações estejam corretas é crucial, pois mesmo erros aparentemente pequenos podem levar a perdas significativas.
Na verdade, houve um problema em que um invasor contornou com êxito a verificação do registro de transferência devido a uma configuração incorreta. A equipe do projeto realizou uma atualização de protocolo alguns dias antes do hack, que envolveu a alteração de uma variável. Variável usada para representar o valor padrão de uma mensagem confiável. Esta alteração faz com que todas as mensagens sejam automaticamente consideradas comprovadas, permitindo assim que um invasor envie uma mensagem arbitrária e ignore o processo de verificação.
Como melhorar a segurança da ponte
As quatro vulnerabilidades comuns explicadas acima demonstram os desafios de garantir a segurança em um ecossistema blockchain interconectado. Existem considerações importantes para abordar cada uma dessas vulnerabilidades, e nenhum manual único se aplica a todas elas.
Por exemplo, fornecer diretrizes gerais para garantir um processo de verificação livre de erros é um desafio porque cada ponte tem seus próprios requisitos de verificação. 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 uma lógica de verificação adequada.
Em resumo, é essencial realizar testes rigorosos contra potenciais ataques e prestar especial atenção às vulnerabilidades de segurança mais comuns em pontes.
resumo
Devido ao seu alto valor, as pontes entre cadeias têm sido alvo de ataques há muito tempo. Os desenvolvedores podem aumentar a segurança de suas pontes realizando testes completos antes da implantação e usando terceiros para participar da auditoria, para reduzir o risco de ataques devastadores – que têm atormentado as pontes nos últimos anos. As pontes são componentes muito importantes em um mundo multicadeia, mas a segurança deve ser uma preocupação importante para projetar e construir uma infraestrutura Web3 eficaz.
Consulte Mais informação:
O que é uma ponte Blockchain?
O que é interoperabilidade entre cadeias?
Três pontes populares de criptomoeda e como elas funcionam
O que são tokens embrulhados?
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 pretende ser uma recomendação de compra de qualquer produto ou serviço específico. Você deve procurar aconselhamento de consultores profissionais apropriados. Nos casos em que os artigos são contribuídos por colaboradores terceiros, observe que as opiniões expressas pertencem ao colaborador terceirizado e não refletem necessariamente as opiniões da Binance Academy. Leia nosso aviso completo aqui para obter mais detalhes. Os preços dos ativos digitais podem flutuar. 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.