Introdução
Nos primeiros dias das criptomoedas, você poderia facilmente existir sem saber ou usar mais do que apenas uma única 'cadeia de origem'. Mas hoje, as multi-cadeias se tornaram o paradigma dominante. A Web3 é formada por centenas, senão milhares, de blockchains, cada uma com suas próprias características, objetivos e metas.
Com cada nova adição, o ecossistema da Web3 está se tornando mais complicado. Com a adição de interações entre blockchains emergentes e maduras, a segurança da Web3 se tornou um problema complexo e de multiníveis, especialmente ao lidar com blockchains de Camada 1, Camada 2, Camada 3 e até mesmo Camada 0.
Para que essas blockchains independentes resolvam o problema da interoperabilidade entre blockchains (comunicação entre diferentes blockchains), a comunidade de criptomoedas desenvolveu pontes de cadeia cruzada (Cross-Chain Bridges), que são contratos inteligentes especiais projetados para permitir a transferência de ativos entre blockchains.
Embora os aspectos técnicos de cada ponte sejam diferentes, o conceito principal de como elas funcionam é praticamente o mesmo:
Um usuário envia fundos em uma cadeia, por exemplo, ETH na blockchain Ethereum, e recebe uma versão envelopada do mesmo token, no nosso caso wETH, em outra cadeia.
Quando um ativo é enviado de volta, ele é simplesmente desenvelopado ou trocado de volta para o ativo ETH original na blockchain Ethereum.
Portanto, para garantir uma boa experiência ao usuário, as pontes de cadeia cruzada devem armazenar uma quantidade extremamente alta de valor bloqueado para garantir liquidez o tempo todo. Essa concentração de valor em pontes representa uma oportunidade tentadora para hackers maliciosos, colocando as pontes em risco constante de roubo ou exploração.
Com o interesse em aprender mais sobre a pirataria na Web3, vamos levantar o véu sobre as pontes de cadeia cruzada e revelar como algumas delas foram hackeadas no passado, bem como quais são as vulnerabilidades mais comuns!
Chamada externa insegura – o hack da Poly Network
Liderando as paradas como o segundo maior hack DeFi de todos os tempos, a Poly Network era uma rede de pontes de rede cruzada que conectava com sucesso 35 blockchains diferentes, até que não conectou mais.
Em 10 de agosto de 2021, hackers maliciosos drenaram $611.000.000 (superando o PIB de 191 países) de três contratos inteligentes da Poly Network nas blockchains ETH e BNB. Agora surge a grande pergunta: como eles fizeram isso?
Havia um contrato privilegiado chamado EthCrossChainManager no ecossistema da Poly Network, que era responsável por acionar mensagens de outras blockchains. Ele tinha uma função chamada verifyHeaderAndExecuteTx, que validava a correção do cabeçalho do bloco e também verificava se a transação estava incluída no bloco.
Depois disso, ele chamava outra função, _executeCrossChainTx, que fazia uma chamada externa a uma variável _toContract.
_toContract poderia ser controlado por qualquer usuário(s) arbitrário(s). Não foram implementadas verificações para a execução da função, de modo que os usuários poderiam passar qualquer endereço de contrato como entrada. Além disso, a função aceitava uma variável bytes _method personalizada, que era usada como payload na chamada externa.
(abi.encodePacked(bytes4(keccak256(abi.encodePacked(_method, "(bytes,bytes,uint64)"))), abi.encode(_args, _fromContractAddr, _fromChainId)))
Neste trecho de código, o argumento _method era controlado pelo usuário.
Lembre-se, o EthCrossChainManager é um contrato privilegiado. Então, e se enganarmos este contrato para chamar outro contrato da Poly Network e modificar o calldata de forma que nossa transação chame a função de uma maneira que nos permita drenar todos os fundos e passar pelo modificador onlyOwner?
Bem, é exatamente o que o atacante fez. Eles fizeram um ataque de brute-force a variável _method correta e convenceram o contrato EthCrossChainManager a chamar outro contrato da Poly Network, EthCrossChainData. Nesta chamada, o atacante chamou a função putCurEpochConPubKeyBytes.
O projeto então literalmente se hackeou. E mais de 600 milhões de dólares desapareceram no ar.
2. Acesso não autorizado a chaves privadas – Hacks na Ronin Network e na Harmony Bridge
A maioria das pontes é de propriedade de carteiras multisig (assinaturas múltiplas) especiais. Ao contrário das carteiras regulares, elas utilizam mais de uma assinatura para assinar uma transação e enviá-la para a rede blockchain. Isso as torna mais seguras do que uma carteira de criptomoeda comum para operar infraestruturas críticas, como pontes.
Pelo menos deveria ser assim.
As práticas de gerenciamento de chaves podem ser difíceis de monitorar e aperfeiçoar em organizações de todos os tamanhos. Mesmo que seja difícil obter acesso a apenas uma chave privada, 3 pontes foram hackeadas devido ao acesso não autorizado a várias chaves privadas responsáveis pela operação de multisigs.
Uma vez obtidas as chaves, elas concedem ao hacker acesso privilegiado, permitindo que eles drenem todos os fundos. Vamos dar uma olhada em como isso aconteceu…
Hack 1: Ronin Network, ataque à cadeia de suprimentos
A Ronin Network é uma side-chain da Ethereum lançada em fevereiro de 2021. Seu principal objetivo é permitir que os usuários criem e enviem transações baratas para jogar um jogo muito popular chamado Axie Infinity.
Para reduzir os custos, os desenvolvedores decidiram usar um modelo de Prova de Autoridade para sua cadeia. Usando esse modelo, apenas 9 validadores eram capazes de validar as transações. No momento do hack, 5 deles (mais de 50% - a quantidade exata necessária para um ataque bem-sucedido) eram controlados pela parceira da Ronin Network, a Sky Mavis, a produtora do jogo.
O atacante infiltrou-se na rede da Sky Mavis e obteve as 5 assinaturas usadas para assinar as mensagens. O que se seguiu foi óbvio - o atacante então validou duas transações, retirando 173.000 ETH e mais de 25.000.000 USDC, sendo que este último foi posteriormente trocado por ETH.
Por enquanto, isso detém o primeiro lugar como o maior hack DeFi já perpetrado, totalizando um prejuízo de $624.000.000, ou cerca de 10 das pinturas mais caras de Van Gogh vendidas combinadas.
Hack 2: Harmony Bridge, chaves comprometidas
A Harmony Bridge era protegida por uma multisig que exigia infelizmente 2 de 5 assinaturas para assinar uma transação. Embora o método exato que os hackers usaram para obter o controle sobre os endereços seja desconhecido, algumas pessoas na indústria especularam que tinha a ver com as assinaturas serem operadas como carteiras ativas. Além disso, as chaves privadas eram armazenadas em formato de texto simples, o que não é muito melhor do que ter um lembrete com sua senha escrita.
Após os hackers obterem as chaves privadas, eles as usaram para assinar transações maliciosas. Isso levou a uma perda de $100.000.000 em diferentes tokens e ativos. A maioria deles foi trocada por ETH e depois sacada usando o Tornado Cash.
3. Ataques criptográficos – Hacks nas pontes BNB e Wormhole
Hack 1: Ponte BNB. Forjando uma prova criptográfica
A Ponte BNB estava funcionando como uma ponte entre a antiga Binance Beacon Chain e a nova Binance Smart Chain. Foi explorada por um atacante para criar 2.000.000 de BNB. Este hack é também notável pelo fato único de que a Binance Smart Chain foi interrompida por cerca de 8 horas como resultado do hack. Provavelmente, vários traders tiveram suas posições liquidadas devido a essa paralisação, adicionando aos danos colaterais causados por este hack.
O protocolo criptográfico criado para a Ponte BNB, infelizmente, permitiu que os atacantes forjassem provas necessárias para enviar mensagens arbitrárias. Os hackers conseguiram enviar apenas 2 mensagens, mas isso foi o suficiente para possibilitar a criação de 2 milhões de novos tokens BNB, permitindo o roubo de $586.000.000 em valor. Vamos dar uma olhada mais de perto e entender como o atacante conseguiu causar tanto estrago com o que parece ser um mecanismo simples.
A Ponte BNB usava a árvore AVL imutável (IAVL) para verificar as transações. No entanto, o hacker conseguiu forjar as provas criptográficas para um número de bloco específico, o 110217401.
Se olharmos mais de perto para as transações usadas no hack, veremos que o bloco usado na transação é o mencionado acima, e a prova usada pelo hacker tinha menos da metade do tamanho de uma prova genuína nas transações de outros usuários.
Para fazer isso, o hacker precisava burlar duas operações chamadas iavl:v e multistore. Ambas as operações tinham que ser bem-sucedidas, e a última operação deveria retornar o hash do número de bloco específico. Além disso, a entrada para multistore é, na verdade, a saída de iavl:v!
O hack não parou por aí. O hacker também teve que forjar a variável raiz em avl:v, que é calculada por outra função chamada computehash. Ela leva as assinaturas das folhas e caminhos, e depois calcula os hashes delas. Então, o hacker adicionou um nó folha e um nó interno para combinar, e de alguma forma compelir o nó folha a fornecer o hash de raiz correto.
Isso permitiu que os hackers criassem 2.000.000 de tokens BUSD, que foram então depositados na Venus, um protocolo de empréstimo da Binance, como garantia. O hacker então pegou stablecoins emprestadas e as transferiu para Ethereum, para várias chains de L2 e depois para a Fantom, que recebeu um aumento de 10% no valor total bloqueado em todo o ecossistema como resultado do hack.
Hack 2: Rede Wormhole. Bypass de validação de assinatura
O exploit Wormhole foi outro hack de ponte notável que resultou no roubo de $326.000.000. Vamos dar uma olhada mais de perto em um dos eventos de hack mais discutidos no DeFi e entender como os hackers conseguiram roubar quase 120.000 ETH.
Vamos começar com o problema. O problema estava presente na função verify_Signatures. Ela pegava um conjunto de assinaturas fornecidas pelos "Guardiões", que eram usadas para verificar transferências entre blockchains, e passava essas assinaturas para a função signatureSet.
A signatureSet então delegava a verificação para o programa Secp256k1 solana_program::sysvar::instructions.
No entanto, a versão errada do solana_program que continha a função Secp256k1 estava configurada, e nenhuma verificação real foi realizada. Isso significava que os atacantes podiam criar uma conta com os dados que a função Secp256k1 deveria retornar, contornando completamente a validação de assinatura.
Usando o retorno da função signatureSet, os hackers chamaram a função post_vaa para obter VAAs válidos (Aprovações de Ação Verificadas), para que pudessem gerar com sucesso uma conta VAA que a ponte pudesse aceitar. Depois disso, eles simplesmente chamaram a função complete_wrapped e criaram 120.000 ETH.
4. Exploração de valores zero – Hacks Nomad Bridge, Qubit Finance.
Hack 1: Nomad Bridge, Erro de inicialização
Nomad Bridge é, segundo seu site oficial, “um protocolo de mensagens de cadeia cruzada com segurança em primeiro lugar”. Foi hackeado por blackhats em agosto de 2022, resultando em perdas de $190.000.000. Alguns usuários de criptomoedas na comunidade também exploraram o protocolo, a fim de devolver fundos diretamente ao projeto.
Vamos dar uma olhada em como um dos hacks mais caóticos do DeFi ocorreu.
O problema estava no contrato Replica na rede Moonbeam. Os hackers podiam enviar transações sem qualquer prova – eles simplesmente chamavam a função process diretamente, esvaziando a ponte de tokens wBTC.
Tais transações não foram revertidas devido à inicialização incorreta. Porque, após uma atualização de rotina do contrato, o endereço Zero foi definido como raiz confiável, o que significava que quaisquer provas de transação eram válidas.
A primeira tentativa de hackear a ponte falhou, e o hacker gastou uma quantia enorme de $350.000 em gás. Isso deve ter sido estressante para os atacantes. No entanto, eles conseguiram enviar as próximas transações com sucesso.
Outros usuários perceberam o hack em andamento e conseguiram copiar os mesmos dados da transação e enviá-los por conta própria, então muitos usuários aleatórios também se juntaram ao hack, explorando o protocolo junto com os blackhats. Alguns dos fundos foram hackeados por whitehats e depois devolvidos ao protocolo.
Hack 2: Qubit Finance, safeTransferFrom irreversível
Qubit Finance é um projeto que permite a colateralização em várias cadeias, como bloquear fundos no Ethereum e emprestar na BNB. Para usar essa funcionalidade, você chamaria a função de depósito QBridge.
Essa função então chamará a função IQBridgeHandler(handler).deposit(), que verificará os dados de entrada.
Os hackers chamaram a função de depósito em QBridge sem ETH anexado. No entanto, a transação não falhou como deveria.
O problema aqui estava no contrato ‘IQBridgeHandler’: tokenAddress.safeTransferFrom(depositer, address(this), amount
O endereço do token ETH é um endereço zero e, por causa disso, tais transações não serão revertidas, apesar do fato de que nenhuma transferência real de ETH realmente ocorreu.
Os atacantes fugiram com $80.000.000 em ativos, a maioria dos quais foi convertida em ETH e depositada na Tornado.Cash.
Conclusão
A indústria web3 ainda é jovem e inexperiente, e a tecnologia de pontes de cadeia cruzada é mais jovem ainda. É por isso que alguns erros podem parecer negligentes, especialmente erros no manuseio seguro de chaves privadas ou inicialização. No entanto, é importante observar que a maioria dos ataques descritos no artigo são primeiros históricos, sem precedentes para preparar equipes para uma realidade tão difícil.
A maioria dos projetos mencionados no artigo não foram auditados – o que é um grande sinal de alerta para qualquer grande projeto nos dias de hoje, mas mais comum na era inicial da criptografia. Alguns dos projetos também não tinham nenhum programa Bug Bounty (BBP) na época.
A falta de auditorias e um BBP em funcionamento não revelou fraquezas inerentes ao design e à operação dos contratos inteligentes e mecanismos usados, mesmo depois que as pontes começaram a acumular fundos de usuários na casa das centenas de milhões.
Isso enfatiza a importância da vigilância e das práticas preventivas de segurança, como garantir auditorias antes do lançamento e BBPs depois, ambos trabalhando juntos para impedir os hacks antes que ocorram.
Esse artigo é uma tradução feita por @bananlabs. Você pode encontrar o artigo original aqui
Latest comments (0)