O que é um exploit de bridge cross-chain e como surgem estes ataques?

O que é um exploit de bridge cross-chain?

Um exploit de cross-chain bridge é a exploração de uma vulnerabilidade numa bridge: infraestrutura que permite que diferentes blockchains comuniquem entre si. Através de uma vulnerabilidade destas, um atacante pode, por exemplo, libertar tokens sem um depósito válido, fazer minting de tokens sem garantia suficiente ou retirar reservas da bridge.

Uma bridge cross-chain permite mover tokens, mensagens ou outros dados entre blockchains separadas. Isto é necessário porque uma blockchain não consegue verificar automaticamente o que aconteceu noutra blockchain.

Um exploit pode surgir em vários pontos. Pense, por exemplo, num erro na verificação de mensagens, em permissões de acesso demasiado amplas, numa vulnerabilidade em smart contracts ou em private keys roubadas de validators ou administradores. Em algumas bridges, os validators confirmam, por exemplo, que uma mensagem de uma blockchain é verdadeira e válida antes de algo acontecer na outra blockchain.

Importa saber o seguinte: uma bridge acrescenta uma camada extra de segurança por cima das blockchains com que se liga. Em algumas bridges, confia-se, por exemplo, num grupo externo de validators ou num multisig. Outras bridges usam light clients e provas criptográficas, como provas de Merkle, para verificar que uma transação ou evento ocorreu realmente na outra blockchain. O modelo de segurança e, por isso, os riscos podem variar bastante de bridge para bridge.

Uma página de phishing durante o processo de bridging não é automaticamente um exploit da bridge. Essa página pode, no entanto, encaminhá-lo para um contrato malicioso ou levá-lo a assinar uma autorização indesejada, mas isso não significa necessariamente que a bridge subjacente tenha sido comprometida.

Pontos principais

• Uma bridge cross-chain permite a comunicação e a transferência de valor entre blockchains separadas.
• Um exploit de bridge explora uma vulnerabilidade técnica ou operacional numa bridge destas.
• Os atacantes podem, entre outras coisas, provocar pagamentos não autorizados ou fazer minting de tokens sem garantia suficiente.
• A verificação de mensagens cross-chain é um ponto de segurança importante de uma bridge.
• O modelo de segurança varia de bridge para bridge e determina que riscos adicionais os utilizadores enfrentam.

Como funciona uma bridge cross-chain?

Uma bridge cross-chain observa um evento na blockchain de origem e, depois de esse evento ser verificado, executa uma ação correspondente na blockchain de destino.

Imagine que quer enviar um token da blockchain A para a blockchain B. A blockchain B não consegue verificar automaticamente se esse token foi realmente enviado por si na blockchain A. Por isso, a bridge tem de observar e verificar o evento na blockchain A antes de acontecer algo na blockchain B.

Um modelo muito usado chama-se lock-and-mint. Os seus tokens originais são, nesse caso, bloqueados na blockchain de origem. Na blockchain de destino, é então feito minting de um wrapped token: uma representação do token original. Se voltar atrás, o wrapped token é queimado e os tokens originais podem ser novamente libertados.

Exemplo: Bloqueia 1 token na blockchain A. Após a verificação, recebe 1 wrapped token na blockchain B. O seu token original não viaja literalmente para a blockchain B, mas permanece bloqueado como garantia para o token que recebe lá.

Outra abordagem funciona com pools de liquidez. Após uma transação verificada na blockchain de origem, um pool na blockchain de destino pode pagar uma quantidade equivalente de tokens.

A etapa crucial é sempre a verificação. A bridge tem de, por exemplo, verificar se uma mensagem é verdadeira, se vem da blockchain correta, se cumpre as condições certas e se ainda não foi processada antes. A forma como isso acontece varia de bridge para bridge.

Algumas bridges também suportam generalised message passing. Nesse caso, podem não só mover tokens, mas também transmitir e executar outros dados ou instruções entre blockchains. Isto oferece mais possibilidades, mas também pode aumentar a superfície de ataque.

Que diferentes modelos de segurança usam as bridges?

Nem todas as bridges determinam da mesma forma se uma mensagem é válida. Por isso, o modelo de segurança também pode variar bastante.

Uma bridge pode, por exemplo, confiar em:

• Validators externos ou multisigs: um grupo de entidades assina mensagens antes de estas serem executadas noutra blockchain.
• Light clients: uma blockchain verifica informação criptográfica sobre o estado da outra blockchain.
• Provas criptográficas: uma bridge usa, por exemplo, provas de Merkle ou outras construções criptográficas para demonstrar eventos.
• Verificação optimista: as mensagens são aceites primeiro, mas existe um período durante o qual outras partes podem contestar uma mensagem inválida.

Estes modelos têm diferentes compromissos. Um grupo externo de validators pode, por exemplo, ser mais simples, mas acrescenta uma camada extra de confiança. Uma bridge que verifica eventos criptograficamente tem outros riscos técnicos. Por isso, a palavra "bridge" por si só diz pouco sobre quão seguro é o sistema em concreto.

Como pode uma bridge cross-chain ser atacada?

Um atacante tenta, normalmente, contornar a verificação da bridge ou obter a autoridade para aprovar uma mensagem cross-chain inválida na mesma.

A lógica por trás disto é simples: se a blockchain de destino acreditar erradamente que tokens foram depositados ou bloqueados na blockchain de origem, a bridge pode, por exemplo, fazer minting de novos tokens ou libertar reservas sem que exista garantia suficiente em troca.

Isto pode acontecer de várias formas:

• Um erro faz com que uma mensagem não comprovada ou falsificada seja aceite na mesma.
• Um atacante consegue obter private keys suficientes de validators, signatários de multisig ou administradores.
• Um bug num smart contract ignora uma verificação importante ou dá demasiados direitos a uma conta.
• A verificação de uma prova criptográfica, como uma prova de Merkle ou uma prova de light client, contém um erro.
• Uma configuração errada ou uma atualização faz com que mensagens inválidas sejam tratadas como válidas.

Uma prova de Merkle é uma forma criptográfica compacta de demonstrar que determinados dados fazem parte de um conjunto de dados maior, por exemplo, dos dados num bloco. Se uma bridge verificar mal essa prova, um atacante pode, possivelmente, fazer com que seja aceite um evento que nunca ocorreu de forma válida.

Por isso, nem todos os ataques passam por chaves roubadas e nem todas as bridges funcionam da mesma maneira. Para compreender o risco, é preciso olhar para o modelo específico de verificação e de segurança da bridge.

Que vulnerabilidades são frequentes?

Muitos ataques a bridges enquadram-se, de forma geral, em várias categorias: erros em permissões de acesso, erros na lógica, problemas na verificação de mensagens e problemas de segurança operacional.

Permission issues dizem respeito a quem pode executar que ações. Talvez uma conta de administrador tenha direitos em excesso, as contas de validators estejam insuficientemente protegidas ou as permissões possam ser alteradas de forma incorreta. Sobretudo num conjunto pequeno de validators ou de multisig, isto pode representar um risco elevado. Se signatários suficientes colaborarem ou forem comprometidos, podem autorizar pagamentos inválidos.

Logic issues são erros nas regras dos smart contracts. Um contrato, por exemplo, processa uma mensagem sem verificar todas as condições ou o minting e a libertação estão configurados de forma incorreta. Também podem incluir erros durante uma atualização ou na inicialização de um contrato.

Message verification issues surgem quando uma bridge não verifica suficientemente se uma mensagem cross-chain é realmente válida. Uma bridge pode, por exemplo, aceitar a origem errada, verificar mal uma prova criptográfica ou executar uma mensagem que nunca surgiu de forma válida na blockchain de origem.

Key management issues surgem quando as private keys de validators, administradores ou signatários de multisig são roubadas ou não estão suficientemente protegidas. Os smart contracts podem funcionar tecnicamente de forma correta, enquanto um atacante consegue, ainda assim, produzir assinaturas válidas com chaves roubadas.

Também os replay attacks são um risco conhecido. Nesses casos, uma mensagem anteriormente válida é usada novamente. Por isso, uma bridge tem de verificar se cada mensagem só pode ser processada uma vez. Um message ID único, nonce ou hash pode ajudar nesse processo.

Uma auditoria pode ajudar a encontrar vulnerabilidades, mas não garante que uma bridge esteja isenta de erros. Sobretudo após atualizações, alterações de definições ou mudanças na infraestrutura off-chain, podem surgir novos riscos.

Como é que as frontends e o phishing entram em jogo?

Nem toda a perda durante a utilização de uma bridge significa que a bridge em si foi explorada. Os atacantes também podem tentar enganar os utilizadores através de um website ou interface falsos.

Uma interface falsa pode, por exemplo, levá-lo a enviar uma transação para um smart contract errado ou a conceder autorização para usar tokens da sua wallet. A infraestrutura técnica da bridge pode, nesse caso, permanecer totalmente intacta.

A distinção é importante: num bridge exploit, é explorado um ponto fraco na bridge ou na infraestrutura à sua volta. No phishing, o utilizador é normalmente enganado para aprovar por si próprio uma ação prejudicial.

Como podem as private keys e os smart contracts desempenhar um papel?

Private keys e smart contracts são componentes importantes de muitas bridges. Um problema num destes elementos pode já ter consequências graves.

Uma private key é uma chave secreta com a qual podem ser feitas transações ou assinaturas criptográficas. Se uma bridge, por exemplo, só executar um pagamento depois de vários validators terem assinado, surge um risco elevado quando um atacante consegue obter um número suficiente dessas chaves. O atacante pode então fazer com que instruções fraudulentas da bridge sejam aprovadas como se fossem legítimas.

Um multisig exige que várias partes assinem antes de uma ação avançar. Isso pode ser mais seguro do que uma única conta de administrador, mas não é automaticamente seguro. O limiar tem de ser bem escolhido, os signatários têm de ser suficientemente independentes e as private keys têm de estar bem protegidas.

No ataque à Ronin Bridge, em março de 2022, chaves de validators suficientes foram comprometidas para aprovar levantamentos não autorizados. No total, foram retirados da bridge 173.600 ETH e 25,5 milhões de USDC. O desenho da bridge foi depois ajustado e foram introduzidas medidas de segurança adicionais.

No incidente da Harmony Horizon Bridge, em junho de 2022, pelo menos duas das quatro private keys dos validators da bridge foram comprometidas. A Harmony comunicou que não havia provas de que os smart contracts da bridge ou o protocolo da blockchain em si tivessem sido afetados. O incidente mostra que uma bridge pode ser comprometida sem que exista necessariamente um erro no contrato on-chain.

Entretanto, os smart contracts constituem as regras on-chain de muitas bridges. Verificam, por exemplo, assinaturas ou provas criptográficas e executam depois ações como fazer minting, queimar, bloquear ou libertar tokens. Se essas verificações forem mal concebidas ou implementadas, um atacante pode, por vezes, criar tokens ou retirar reservas sem uma transação subjacente válida.

Uma boa proteção exige, por isso, tanto smart contracts seguros como uma gestão forte das chaves.

Quais são as consequências de um exploit de bridge cross-chain?

Um exploit de bridge cross-chain pode fazer com que as reservas desapareçam, que os pools de liquidez fiquem vazios ou que os wrapped tokens deixem de estar totalmente cobertos.

Este último ponto pode ter consequências importantes. Num modelo lock-and-mint, um wrapped token deve, normalmente, estar coberto por reservas noutra blockchain. Se essa garantia desaparecer, a possibilidade de trocar o wrapped token pelo ativo original pode ficar sob pressão. Isto também pode afetar protocolos em que o token é usado como garantia, ativo de negociação ou liquidez.

As equipas de projeto podem, por vezes, suspender temporariamente uma bridge para limitar danos adicionais. Após o exploit da Nomad, em agosto de 2022, por exemplo, o processamento adicional foi interrompido depois de um erro na inicialização ter permitido que mensagens inválidas fossem tratadas como válidas. Nesse incidente, foram retirados da bridge cerca de 190 milhões de dólares em ativos.

No exploit do BSC Token Hub, em outubro de 2022, foi usada uma prova criptográfica falsificada, o que permitiu criar cerca de 2 milhões de BNB adicionais. A BNB Chain coordenou-se com validators para parar temporariamente a blockchain e limitar danos adicionais. Assim, uma grande parte dos BNB envolvidos permaneceu sob controlo.

As transações em blockchain não podem, em regra, ser simplesmente revertidas por uma entidade central, como acontece, por exemplo, com uma transferência bancária tradicional. Ainda assim, isso não significa que nunca possa haver intervenção. Dependendo da rede, validators, equipas de projeto, emissores de tokens ou a governação podem, por vezes, tomar medidas para parar transações adicionais, bloquear ativos ou aplicar outras medidas de recuperação.

Uma pausa temporária pode limitar danos adicionais, mas também tem desvantagens. Os utilizadores podem, por exemplo, ficar temporariamente impossibilitados de fazer bridging ou de recuperar os seus tokens. Além disso, uma paragem de emergência significa que determinados administradores, validators ou guardians têm influência para atrasar ou suspender partes do sistema.

Se os utilizadores são ou não compensados após um exploit não está garantido. Isso depende, entre outros fatores, das reservas disponíveis, de seguros, de decisões do projeto, da governação e da possibilidade de recuperar os fundos roubados.

Um grande exploit de bridge pode, além disso, afetar a confiança num projeto ou num ativo bridged. Isso pode influenciar a liquidez e, possivelmente, também o preço de mercado, mas o efeito varia consoante o incidente e as condições de mercado.

Para além da perda financeira direta, uma bridge pode, por isso, tornar-se menos útil durante muito tempo. A liquidez pode diminuir, os wrapped tokens podem tornar-se mais difíceis de trocar e os utilizadores podem ficar mais relutantes em voltar a usar a bridge.

Que exploits conhecidos de bridges cross-chain existem?

Já ocorreram vários exploits de bridge de grande dimensão. A causa técnica variou de incidente para incidente.

• Poly Network: em agosto de 2021, foram movimentados mais de 600 milhões de dólares em criptoativos na Poly Network após a exploração da infraestrutura cross-chain. Uma grande parte dos fundos foi devolvida mais tarde.
• Wormhole: em fevereiro de 2022, uma vulnerabilidade na Wormhole em Solana foi explorada para criar wrapped ETH sem a cobertura subjacente exigida. O atacante transferiu depois parte dos ativos para Ethereum.
• Ronin Bridge: em março de 2022, as validator keys foram comprometidas, permitindo ao atacante aprovar levantamentos não autorizados. No total, foram retirados da bridge 173.600 ETH e 25,5 milhões de USDC.
• Harmony Horizon Bridge: em junho de 2022, pelo menos duas private keys dos validators da bridge foram comprometidas. No incidente, foram roubados cerca de 100 milhões de dólares em criptomoeda.
• Nomad: em agosto de 2022, um erro relacionado com a inicialização do contrato Replica fez com que mensagens não comprovadas pudessem ser tratadas como válidas. Assim, vários endereços puderam copiar transações e retirar ativos da bridge. A perda total foi de cerca de 190 milhões de dólares.
• BNB Chain Token Hub: em outubro de 2022, a bridge nativa entre a BNB Beacon Chain e BNB Smart Chain foi afetada. Através da falsificação de uma low-level proof, puderam ser criados cerca de 2 milhões de BNB adicionais.

Os montantes nestes incidentes devem, no entanto, ser vistos em contexto. Um valor mencionado pode referir-se ao valor de mercado dos tokens criados, às reservas efetivamente retiradas, a ativos temporariamente bloqueados ou a montantes que foram recuperados mais tarde. Como os preços das criptomoedas variam, o valor em dólares reportado também pode diferir consoante o momento da medição.

Como podem os exploits de bridges cross-chain ser evitados?

Os exploits de bridges cross-chain não podem ser totalmente evitados, mas várias camadas independentes de segurança podem reduzir a probabilidade de um ataque bem-sucedido e limitar os danos máximos.

A base é uma verificação rigorosa. Uma bridge tem de, entre outros aspetos, verificar de onde vem uma mensagem, se é válida, para que ação se destina e se ainda não foi usada antes. Só depois disso é que um contrato pode, por exemplo, fazer minting de tokens ou libertar reservas.

O modelo de confiança também conta. Uma bridge que dependa de um pequeno conjunto externo de validators ou de multisig tem um perfil de risco diferente de uma bridge que verifique informação cross-chain através, por exemplo, de light clients. Nenhum desenho está totalmente isento de risco.

Além disso, algumas medidas podem ajudar a limitar os danos máximos:

• Rate limits limitam quanta valor pode ser movido num determinado período.
• Limites de levantamento estabelecem um máximo para os pagamentos.
• Circuit breakers podem abrandar ou parar automaticamente atividade anómala.
• Funções de pausa podem suspender temporariamente determinadas atividades da bridge durante um incidente.
• Monitorização pode sinalizar mais rapidamente mensagens de bridge invulgarmente grandes ou anómalas.

Esse travão de emergência não resolve a vulnerabilidade subjacente. Pode, no entanto, impedir que um atacante retire todas as reservas disponíveis num curto espaço de tempo.

Auditorias, bug bounties, code reviews e testes extensivos também são importantes. Funcionam melhor em combinação com monitorização contínua, gestão segura de chaves e um plano de resposta a incidentes preparado antecipadamente.

Que medidas de segurança podem os desenvolvedores tomar?

Os desenvolvedores podem reduzir o risco ao estruturar de forma rigorosa, desde o início, a verificação, as permissões de acesso, a gestão de chaves e as medidas de emergência.

1. Verifique cada mensagem na totalidade. Verifique, entre outros aspetos, a blockchain de origem, o remetente, o nonce ou message ID único, o destino e a função permitida. Assim evita que uma mensagem venha da origem errada ou seja reutilizada para outra ação.

2. Implemente proteção contra replay. Marque uma mensagem processada como usada e não a aceite novamente. Isto ajuda contra replay attacks, nos quais a mesma instrução é executada várias vezes.

3. Conceda o mínimo de direitos possível. Use o princípio do least privilege. Nem todas as contas precisam de poder atualizar contratos, alterar validators, fazer minting de tokens ou ativar uma paragem de emergência. Quanto menos permissões tiver uma conta, menor será o dano potencial se for comprometida.

4. Proteja as contas de administração com um multisig. Para ações administrativas sensíveis, use, quando adequado, vários signatários independentes em vez de uma única externally owned account com uma única private key. Um multisig só é útil, no entanto, se os signatários e as suas chaves forem realmente suficientemente independentes.

5. Use um timelock para alterações de risco elevado. Um timelock introduz um período de espera antes de uma atualização ou decisão de governação ser executada. Assim, as alterações podem ser verificadas antecipadamente e a atividade suspeita pode ser detetada mais cedo.

6. Teste mais do que apenas o percurso normal. Faça auditorias independentes, mas teste também atualizações, inicialização, entradas incorretas, casos-limite e verificação de provas. O exploit da Nomad mostra quão grave pode ser um erro numa atualização ou inicialização.

7. Prepare antecipadamente a resposta a incidentes. Use monitorização, deteção de anomalias, rate limits e, quando adequado, uma paragem de emergência controlada. Defina antecipadamente quem pode intervir, que ações são possíveis e como a comunicação decorre durante um incidente.

8. Faça uma gestão cuidadosa das private keys. Mantenha as chaves de validators e administradores separadas e bem protegidas. Além disso, assegure procedimentos que permitam adicionar, remover e substituir signatários de forma controlada.

Uma auditoria ou um bug bounty não é, por si só, um selo de segurança. Novas atualizações, relayers off-chain, alterações de configuração e a segurança diária das private keys continuam a ser riscos separados.

Como podem os utilizadores limitar os riscos?

Como utilizador, não pode definir a segurança de uma bridge, mas pode limitar o risco que assume através dela.

1. Veja o modelo de confiança. Verifique que bridge está a usar e como as mensagens cross-chain são verificadas. Veja, por exemplo, se é usado um grupo externo de validators, multisig, light client ou outro modelo de verificação.

2. Use a interface correta. Abra a bridge através de um canal de projeto fiável e controlado. Antes de assinar uma transação, verifique, entre outros aspetos, o URL, a blockchain, o endereço de receção e o token que está a enviar.

3. Não assine às cegas. Verifique o que uma transação ou mensagem faz antes de a assinar. A assinatura cega pode expô-lo a phishing, a um contrato malicioso ou a autorizações indesejadas.

4. Limite as token approvals. Sempre que possível, conceda apenas autorização para o montante necessário. Uma token approval pode permanecer ativa on-chain até ser alterada ou revogada.

5. Revogue approvals não utilizados. Verifique limites de spending antigos e revogue-os se já não precisar deles. Apenas desligar a sua crypto wallet de uma dApp não remove approvals de tokens já existentes.

6. Limite a sua exposição. Uma pequena transação de teste pode ajudar a verificar, por exemplo, o endereço, a interface e o percurso escolhido. No entanto, esse teste não prova que a bridge em si seja segura.

7. Tenha em conta o risco dos tokens bridged. Após um exploit, os wrapped tokens podem tornar-se temporariamente difíceis de trocar ou menos líquidos. Quanto mais tempo e mais valor dependerem de uma única bridge e das reservas subjacentes, maior será a exposição a esse risco específico da bridge.

Além disso, verifique as comunicações oficiais de incidentes e os avisos de segurança atuais antes de usar uma bridge.

Conclusão

Uma bridge cross-chain permite trocar tokens, mensagens e outros dados entre blockchains, mas acrescenta também uma camada extra de segurança. As vulnerabilidades podem surgir, entre outros pontos, na verificação de mensagens cross-chain, nas permissões de acesso, nas private keys, na configuração e nos smart contracts.

As consequências podem ser grandes, porque as bridges gerem frequentemente quantidades significativas de criptomoeda ou são responsáveis pela cobertura de wrapped tokens. Incidentes em projetos como Poly Network, Wormhole, Ronin, Harmony, Nomad e BNB Chain mostram, além disso, que os exploits de bridges podem surgir de formas muito diferentes.

Para os desenvolvedores, uma boa segurança depende, por isso, de várias camadas independentes: verificação rigorosa, proteção contra replay, administração limitada, gestão segura de chaves, monitorização e um plano de resposta a incidentes preparado. Para os utilizadores, o mais importante é compreender que modelo de confiança uma bridge usa, verificar a interface correta e ter em conta os riscos adicionais dos ativos bridged.

As bridges desempenham um papel importante num ecossistema com várias blockchains, mas não estão isentas de risco. Quanto melhor compreender como uma bridge verifica eventos noutra blockchain e de que partes ou sistemas essa verificação depende, melhor poderá avaliar o respetivo modelo de segurança.