No dia 14 de agosto, a equipe de desenvolvimento da Besu, o software cliente Ethereum de código aberto, divulgou alertas de segurança detalhando cinco vulnerabilidades descobertas pela empresa de segurança CertiK. As falhas, que variavam de gravidade baixa a alta, já haviam sido corrigidas na versão 26.7.1, lançada em 27 de julho, em uma atualização de segurança urgente recomendada a todos os operadores de nós.
O que a atualização 26.7.1 corrige na Besu
A versão 26.7.1 foi disponibilizada como uma medida preventiva antes da divulgação pública dos detalhes técnicos. A estratégia, comum em projetos de infraestrutura crítica, deu aos operadores de nós uma janela para aplicar o patch e atualizar seus sistemas sem expor as vulnerabilidades a potenciais ataques. As cinco descobertas, todas reportadas pela CertiK por meio de um processo de divulgação responsável, foram classificadas e endereçadas individualmente, com a Besu publicando quatro avisos de segurança no GitHub.
As vulnerabilidades miravam diferentes componentes do cliente, todas com o potencial de comprometer a disponibilidade do nó ou o processamento do consenso, principalmente em configurações específicas. Os problemas incluíam falhas no processamento de anúncios de blocos, no armazenamento em buffer de propostas de consenso para alturas futuras, nos limites de assinaturas via WebSocket e na criação ilimitada de filtros JSON-RPC. Em cenários práticos, um atacante poderia explorar essas brechas para esgotar a memória RAM ou a capacidade de threads de um nó, efetivamente tirando-o do ar ou atrasando a validação de blocos.
Detalhamento técnico das vulnerabilidades corrigidas
A CertiK utilizou sua metodologia proprietária, o Chain Scan, baseada em testes adversariais, para identificar as falhas. Os pesquisadores montaram uma rede de testes Besu privada, composta por múltiplos nós, e introduziram falhas controladas nas interfaces peer-to-peer (P2P), HTTP RPC, WebSocket RPC e nos mecanismos de consenso. O objetivo era simular condições de ataque e avaliar riscos de negação de serviço (DoS).
- Processamento de anúncios de blocos (GHSA-j2j5-x2rr-cv75): Um nó malicioso poderia enviar anúncios de blocos de forma repetitiva e malformada, forçando o nó vítima a alocar recursos de processamento e memória desnecessariamente.
- Buffer de propostas de consenso (GHSA-qhrf-865g-38rh): A falha permitia que um atacante enviasse propostas de consenso para alturas de bloco muito distantes no futuro. O nó, ao tentar armazenar essas propostas em buffer, poderia ter sua memória esgotada.
- Limites de assinaturas via WebSocket (GHSA-ffqr-pj4h-xq37): A ausência de um limite adequado no número de assinaturas de eventos por conexão WebSocket permitia que um único cliente sobrecarregasse o nó, consumindo toda a capacidade de threads disponível.
- Criação ilimitada de filtros JSON-RPC (GHSA-vff7-xxjc-rccp): Similar ao problema do WebSocket, a API JSON-RPC não impunha um teto para a criação de filtros, permitindo que um atacante criasse milhares de filtros simultâneos, levando ao esgotamento de memória.
O que é a Besu e por que essa atualização é importante
A Besu é um cliente Ethereum de código aberto, escrito em Java e licenciado sob a Apache 2.0. Projetado para ser versátil, ele opera tanto em redes públicas, como a mainnet do Ethereum e as testnets Hoodi, Ephemery e Sepolia, quanto em redes privadas corporativas que exigem alta performance e segurança no processamento de transações. O projeto é hospedado pela Linux Foundation Decentralized Trust (LFDT), anteriormente conhecido como Hyperledger Besu.
Para o operador de um nó, especialmente em ambientes corporativos ou em staking pools, a manutenção da disponibilidade é crítica. Uma vulnerabilidade que cause um crash ou um esgotamento de recursos pode resultar em perda de oportunidades de validação, penalidades financeiras (slashing) ou, no mínimo, em uma interrupção no serviço. A atualização 26.7.1, portanto, não é apenas uma correção de bugs, mas uma medida de proteção à estabilidade financeira e operacional da rede.
Como funciona o processo de divulgação de vulnerabilidades
O caso entre a Besu e a CertiK ilustra o fluxo ideal de um processo de divulgação responsável. A CertiK identificou as cinco vulnerabilidades durante uma pesquisa independente, sem envolvimento comercial ou com qualquer cliente específico. As descobertas foram reportadas diretamente à equipe da Besu, que trabalhou de forma coordenada e confidencial para avaliar o impacto e desenvolver as correções.
Apenas após a liberação da versão corrigida (26.7.1) os detalhes técnicos foram tornados públicos. Isso garante que os operadores tenham a chance de se proteger antes que a informação possa ser usada por agentes mal-intencionados. A Besu também reconheceu publicamente a CertiK e a EF Security (Ethereum Foundation Security) por suas contribuições nas notas de versão.
Sobre a CertiK e o impacto no ecossistema Web3
Fundada em 2017 e com sede em Nova York, a CertiK se consolidou como a maior provedora de serviços de segurança para Web3. A empresa utiliza inteligência artificial e auditoria manual para oferecer soluções de gestão de risco que se integram ao ciclo de vida de desenvolvimento de software (SDLC) de clientes institucionais. Até o momento, a CertiK afirma ter identificado mais de 119 mil vulnerabilidades e protegido mais de US$ 600 bilhões em ativos digitais globalmente.
A empresa opera sob padrões rigorosos, incluindo SOC 2 Type II e ISO 27001, e colabora com órgãos reguladores no desenvolvimento de políticas para ativos digitais. Para o mercado brasileiro, que tem visto um crescimento no interesse por blockchain e criptomoedas, a transparência e a segurança proporcionadas por auditorias como essa são um diferencial competitivo para projetos que buscam atrair investidores e usuários sérios.
À medida que o ecossistema Ethereum amadurece, a segurança da camada de execução se torna um pilar fundamental. Atualizações como a 26.7.1 da Besu demonstram que a manutenção proativa e a colaboração entre desenvolvedores e empresas de segurança são a linha de frente na proteção contra ataques e na garantia da resiliência da rede. Para os operadores, a lição é clara: manter o cliente atualizado não é uma opção, mas uma necessidade operacional.
