Vulnerabilidades de segurança comuns em bridges
P√°gina Inicial
Artigos
Vulnerabilidades de segurança comuns em bridges

Vulnerabilidades de segurança comuns em bridges

Avançado
Publicado em Mar 22, 2023Atualizado em Jun 15, 2023
9m

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: 

  1. Usu√°rios interagem com o DApp para depositar tokens no contrato inteligente na blockchain de origem.

  2. Em seguida, o DApp envia o hash da transação de depósito para o servidor de backend através de uma API.

  3. 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.

  4. 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

O que s√£o Wrapped Tokens?

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.