- Blockchain Besu corrigiu cinco vulnerabilidades que poderiam esgotar recursos e interromper nós validadores.
- A versão 24.1.1 usada na primeira fase do Drex aparece entre as afetadas.
- Não há evidência pública de exploração nem confirmação da versão atualmente usada pelo BC.
O Besu, blockchain escolhido pelo Banco Central do Brasil para operar a rede de testes do Piloto Drex, continha cinco vulnerabilidades que poderiam comprometer a disponibilidade de nós e, em determinadas condições, interromper o processamento do consenso.
A CertiK compartilhou com o Bitnotícias que identificou as falhas durante uma pesquisa independente e comunicou os problemas de forma privada aos mantenedores do projeto. Duas descobertas receberam a classificação “Major” da empresa de segurança. O Besu agrupou os cinco problemas em quatro alertas: um de gravidade alta e três moderados.
As vulnerabilidades afetavam todas as versões anteriores à 26.7.1, disponibilizada em 27 de julho. O projeto recomendou que os operadores instalassem a atualização com urgência, mas somente publicou os detalhes técnicos em 14 de agosto, depois de conceder tempo para a aplicação das correções.
- Leia também: Quem vendeu Bitcoin na alta de 20% desta semana?
Quando realizou os testes no piloto do Drex, o Banco Central usou a versão 24.1.1 do Besu, que também continha as vulnerabilidades deste alerta. No caso do Drex, após a primeira e segunda fase do Piloto o Banco Central abandonou o uso de blockchain e prometeu novos testes sem DLT para 2026 ainda não divulgados.
Falhas poderiam consumir recursos e interromper nós
As descobertas não permitiam criar alterar ou roubar diretamente ativos. O risco estava relacionado principalmente a ataques de negação de serviço por esgotamento de recursos. Em uma rede distribuída, a indisponibilidade de um servidor assume uma dimensão adicional. Um nó validador não apenas deixa de responder às aplicações como também para de participar das votações necessárias para confirmar blocos e transações.
A vulnerabilidade considerada mais grave pelo Besu reunia duas descobertas da CertiK, identificadas como HYB-01 e HYB-04. O projeto publicou ambas no alerta GHSA-j2j5-x2rr-cv75, classificado como de gravidade alta.
O problema permitia que um único participante conectado à interface peer-to-peer anunciasse diferentes identificadores para o mesmo número de bloco. O Besu poderia, então, agendar repetidamente a busca desses blocos e consumir uma quantidade crescente de memória e threads.
O ataque não dependia das interfaces JSON-RPC ou WebSocket. Bastava que o participante concluísse o procedimento de conexão ao protocolo eth/68 para começar a enviar os anúncios maliciosos. A correção passou a organizar as solicitações por número de bloco.
Depois que o nó pede determinado bloco, um segundo anúncio somente será aceito se vier de um participante com reputação superior. A mudança limita o volume de tarefas que podem ficar pendentes simultaneamente.
O segundo alerta com maior potencial de impacto envolvia diretamente os mecanismos de consenso QBFT e IBFT usados em redes privadas. A CertiK classificou a descoberta HYB-02 como “Major”, enquanto o Besu atribuiu gravidade moderada devido à baixa probabilidade de exploração.
Segundo o alerta oficial, um participante conectado ao subprotocolo istanbul/100 poderia enviar propostas de blocos referentes a alturas futuras antes que o sistema verificasse se ele tinha autorização para propor aquele conteúdo.
O Besu já limitava o armazenamento a mil mensagens, mas considerava apenas a quantidade, não o tamanho de cada proposta. Um conjunto de mensagens com blocos de vários megabytes poderia preencher a memória do processador de eventos BFT e interromper o consenso no validador afetado.
O próprio alerta descreve o possível impacto como crítico, embora considere remota a probabilidade. A correção adicionou um limite em bytes ao armazenamento temporário, impedindo que mensagens excessivamente grandes ocupem toda a memória disponível.
O relatório da primeira fase do piloto confirma que na época a CBDC brasileira a adotou o QBFT como protocolo de consenso e, portanto, estaria vulnerável a esta falha.
WebSocket e JSON-RPC também apresentavam riscos
As duas descobertas restantes envolviam interfaces utilizadas por aplicações para consultar informações ou acompanhar eventos processados pelos nós.
Na falha HYB-03, um cliente poderia abrir um número ilimitado de assinaturas por meio da função eth_subscribe na interface WebSocket. Cada assinatura permanecia registrada na memória do servidor, permitindo que o consumo de recursos crescesse continuamente.
O Besu classificou o problema como moderado. A interface WebSocket fica desativada por padrão, o que reduz a superfície de exposição, mas redes que habilitaram o recurso poderiam ser afetadas.
A versão 26.7.1 passou a limitar o número global de assinaturas ativas a 100 mil por padrão. O software também começou a remover assinaturas quando uma conexão é encerrada durante o procedimento de criação.
A HYB-08 atingia os filtros usados por clientes HTTP JSON-RPC. O software armazenava filtros de logs, blocos e transações pendentes em uma estrutura sem limite global, por usuário ou por conexão.
De acordo com o alerta do Besu, um único cliente HTTP sem autenticação poderia criar filtros continuamente e aumentar o consumo de memória do servidor. Os filtros permaneciam ativos mesmo quando o cliente não retornava para consultá-los.
A CertiK considerou essa descoberta de menor gravidade, mas o Besu manteve sua própria avaliação como moderada. A correção estabeleceu um limite padrão de mil filtros ativos e um prazo de 120 segundos para excluir aqueles que não recebem consultas.
A exposição prática das interfaces depende da configuração de cada rede. Um nó que não habilita WebSocket, restringe o JSON-RPC a aplicações internas e controla quais participantes podem se conectar apresenta uma superfície de ataque menor do que um servidor aberto à internet.
Besu corrigiu falhas antes de publicar detalhes
A CertiK encontrou os problemas durante uma pesquisa independente, sem contrato comercial ou participação de um cliente. Os pesquisadores construíram uma rede privada com vários nós Besu e introduziram falhas controladas nas interfaces peer-to-peer, HTTP RPC, WebSocket RPC e de consenso.
A metodologia buscou identificar situações em que mensagens ou solicitações poderiam consumir recursos sem limites. A empresa forneceu à equipe do Besu estruturas de teste reproduzíveis para demonstrar os comportamentos observados.
As partes mantiveram os detalhes em sigilo enquanto os desenvolvedores analisavam e corrigiam o código. A versão 26.7.1, lançada em 27 de julho, informou apenas que solucionava vulnerabilidades de segurança e recomendou a atualização imediata.
Os quatro alertas técnicos apareceram em 14 de agosto, 18 dias depois da disponibilização da correção. Essa ordem reduziu o risco de que potenciais atacantes recebessem instruções detalhadas antes que os operadores tivessem acesso ao patch.
As notas da versão reconheceram publicamente a CertiK e a equipe de segurança da Ethereum Foundation pelas respectivas divulgações responsáveis. As cinco descobertas da CertiK não receberam identificadores CVE, mas constam no banco de alertas de segurança do GitHub.
