O protocolo NEAR da plataforma de contrato inteligente continha uma vulnerabilidade que poderia permitir que um invasor derrubasse todos os nós da rede, efetivamente desligando-a.
De acordo com um relatório de 26 de setembro da empresa de segurança de blockchain Zellic, que a descobriu, a vulnerabilidade foi eliminada discretamente por meio de um patch em janeiro, mas algumas redes ainda podem conter falhas semelhantes.
No relatório, Zellic se referiu à falha como um “Web3 Ping of Death”, devido à sua capacidade de derrubar uma rede inteira “em um instante”.
Pesquisadores descobriram isso enquanto investigavam o protocolo de rede peer-to-peer da NEAR para nós validadores, que permite que seus validadores se comuniquem efetivamente entre si. A NEAR usa um “mecanismo de handshake” para estabelecer conexões entre nós e garantir que os nós não estejam agindo de forma maliciosa.
O “peer remoto”, ou o peer que quer se conectar, envia uma mensagem de handshake para o peer local. Em resposta, o peer local envia de volta uma confirmação da mensagem.
Processo de conexão ponto a ponto NEAR. Fonte: Zellic.
Durante esse processo, o peer remoto é obrigado a provar sua identidade fornecendo uma chave pública e assinando uma mensagem provando que ele é o dono dessa chave pública. Esse processo de verificação de identidade tem como objetivo impedir que nós maliciosos conhecidos se conectem à rede.
Quando os pesquisadores analisaram a função de verificação de assinatura, eles descobriram um fato alarmante. Os nós permitiam que dois tipos de assinaturas criptográficas fossem aceitas.
O primeiro tipo, baseado no Algoritmo de Assinatura Digital em Curvas de Edwards Torcidas 25519 (Ed25519), pode ser verificado com segurança pelos nós.
Entretanto, tentar verificar o segundo tipo, com base na curva Standards for Efficient Cryptography Prime Field 256K1 (SECP256K1), resultaria em uma resposta de “pânico” que travaria o nó.
A função de verificação para esse tipo de assinatura criptográfica continha duas vulnerabilidades diferentes. Primeiro, ela chamava uma função “expect” e exigia que a resposta contivesse no máximo 32 bytes de dados.
No entanto, a resposta dada por essa função nunca teve 32 bytes de comprimento. Isso significava que o nó travaria sempre que tentasse verificar uma assinatura SECP256K1.
Seção de código NEAR contendo vulnerabilidade “.expect()”. Fonte: Zellic.
Em segundo lugar, se o último byte da assinatura não estivesse entre zero e três, a função “from_i32()”, que foi chamada como parte do processo de verificação, produziria um erro.
Esse erro faria com que a função final “unwrap()” chamada no final do processo parasse, travando o nó. Isso significava que, mesmo que a primeira vulnerabilidade fosse corrigida, um invasor poderia criar deliberadamente uma assinatura maliciosa que poderia travar o nó usando a segunda vulnerabilidade.
Vulnerabilidade de função de lançamento de erro em NEAR. Fonte: Zellic.
Ao descobrir essa falha, os pesquisadores ficaram surpresos ao descobrir que ela não havia sido detectada anteriormente em testes ou que já havia causado a queda da rede.
No entanto, eles descobriram que o software do nó NEAR não tem “nenhum caminho de código que permita que um nó NEAR gere chaves do tipo SECP256K1”. Em outras palavras, embora o software permitisse que os nós aceitassem assinaturas SECP256K, ele não permitia que eles produzissem tais assinaturas.
Como resultado, nenhum nó jamais derrubou acidentalmente a rede ao criar chaves SECP256K e tentar se conectar a outro nó.
Mesmo assim, um nó malicioso poderia alterar o software para permitir que chaves SECP256K fossem geradas. E uma vez que o fizessem, eles teriam o poder de derrubar qualquer nó NEAR simplesmente tentando se conectar a ele. O resultado poderia derrubar toda a rede, constituindo um “Web3 Ping of Death”.
Para provar que a vulnerabilidade era real, os pesquisadores primeiro criaram uma versão do software NEAR contendo um patch malicioso que permitia a geração de chaves SECP256K.
Eles então lançaram dois nós em uma versão de testnet privada do NEAR. O primeiro nó executou o software legítimo fornecido pelos desenvolvedores, enquanto o segundo executou a versão maliciosa.
Depois que o primeiro nó começou a produzir blocos, o segundo nó tentou derrubar o primeiro explorando as duas vulnerabilidades. Eles descobriram que o nó malicioso conseguiu derrubar o legítimo todas as vezes.
Revista: Prisão suspeita de repórter de golpe de criptomoedas, primeiro-ministro pró-cripto do Japão: Asia Express
A Zellic revelou secretamente a vulnerabilidade para a equipe da NEAR em dezembro, usando a plataforma de recompensa por bugs da HackenProof para facilitar a divulgação. Em resposta, a equipe pagou à Zellic uma recompensa de US$ 150.000 e corrigiu o software do nó em janeiro.
Durante esse período entre a descoberta e o patch, nenhum invasor descobriu a falha, e a rede permaneceu online.
A descoberta da vulnerabilidade proporcionou um final feliz para o que poderia ter sido uma história de crise.
Outros blockchains não tiveram sorte o suficiente para evitar falhas que resultaram em quedas. Em dezembro, a rede Arbitrum caiu por mais de 78 minutos, impedindo que os usuários fizessem qualquer transação.
Mais tarde, os desenvolvedores revelaram que esse tempo de inatividade foi causado por um aumento na cunhagem de inscrições, para o qual a rede não estava adequadamente preparada.
De acordo com os desenvolvedores, em janeiro, cerca de 50% dos nós Cardano caíram devido a uma “anomalia”. A interrupção fez com que a produção de blocos diminuísse, dando origem a tempos de confirmação de transações mais longos. No entanto, não fez com que toda a rede caísse.
Em fevereiro, a rede Solana falhou em produzir um bloco por mais de 25 minutos. Esta foi a mais recente de várias quedas de Solana, que alguns usuários criticaram duramente.
