Os programadores do XRP Ledger corrigiram uma falha crítica no motor de pagamentos que poderia ter permitido a um atacante criar XRP utilizável muito além do limite de oferta de 100 mil milhões da rede numa única transação, segundo um relatório de divulgação da Veria Labs. A vulnerabilidade existia no código do xrpld desde 2015, embora o relatório afirmasse que não havia “qualquer evidência de que este problema tivesse sido explorado em alguma rede pública”.
A falha foi comunicada à RippleX em 22 de setembro e corrigida três dias depois na versão 3.4.1 do xrpld. A Veria Labs afirmou que mais de 80% dos validadores da Lista de Nós Únicos predefinida do XRP Ledger tinham instalado a versão no dia em que foi lançada, limitando a janela prática para um ataque contra a rede.
Cayden Liao, cofundador da Veria Labs, afirmou que um agente de IA identificou a falha e gerou um exploit funcional. Numa publicação no X, Liao estimou que uma única transação maliciosa poderia ter criado cerca de 18 biliões de XRP — aproximadamente 184 vezes a oferta máxima original da rede — se tivesse chegado a uma rede vulnerável.
O cálculo de pagamentos podia sofrer um efeito de overflow
A vulnerabilidade envolvia pagamentos que consumiam várias ofertas do livro de ordens descentralizado do XRP Ledger. Estas transações podem corresponder a muitas ofertas de uma só vez, exigindo que o software some a quantidade de XRP paga em todas elas.
Segundo o relatório da Veria Labs, essa adição não tinha uma verificação de overflow. Em informática, ocorre um overflow quando um número se torna demasiado grande para o tipo de dados atribuído; em vez de produzir o grande valor correto, o cálculo pode dar a volta e resultar num número muito mais pequeno.
Um atacante poderia ter utilizado várias centenas de contas para colocar ofertas de venda de uma fração ínfima de um token por quantidades extraordinariamente elevadas de XRP. Uma única transação de pagamento poderia então consumir essas ofertas. O motor de pagamentos creditaria a cada vendedor o montante de XRP indicado, enquanto o custo calculado para o comprador poderia dar a volta e resultar em “apenas algumas centenas de drops, mais a comissão”, afirmou o relatório. Um drop é a unidade mais pequena de XRP, equivalente a um milionésimo de XRP.
O erro poderia ter aumentado os saldos de XRP sem debitar devidamente a conta do atacante. A Veria Labs afirmou que uma salvaguarda separada, concebida para detetar XRP recém-criado, utilizava outra operação de adição vulnerável a overflow. Como resultado, a verificação interna da oferta do protocolo também poderia não reconhecer o aumento artificial dos saldos.
A dimensão do exploit teórico colocava-o numa categoria diferente da de um compromisso típico de uma exchange ou de um roubo numa bridge. Em vez de roubar fundos existentes de um conjunto definido, o atacante poderia ter introduzido novas unidades gastáveis em circulação, potencialmente minando a confiança nas regras de fornecimento do ledger caso essas unidades chegassem a plataformas de negociação ou a outros participantes da rede.
A correção contornou o calendário normal de alterações
A correção da RippleX entrou em vigor através de atualizações dos servidores, em vez do processo habitual de alterações do XRP Ledger, afirmou a Veria Labs. Normalmente, as alterações modificam as regras da rede apenas depois de receberem mais de 80% de apoio dos validadores de confiança durante duas semanas.
Esse processo foi concebido para dar aos operadores tempo para analisarem e implementarem as atualizações antes de uma regra do protocolo se tornar ativa. Neste caso, o problema de segurança exigia uma resposta mais rápida: cada servidor recebeu a proteção quando o respetivo operador atualizou para xrpld 3.4.1.
A Veria Labs descreveu esta abordagem como a primeira utilização deste método de ativação orientado por atualizações em mais de uma década de alterações do XRP Ledger. A decisão reflete o compromisso prático envolvido na resolução de uma vulnerabilidade com uma janela curta para correção: uma discussão pública alargada antes de uma correção ser amplamente implementada pode dar aos atacantes detalhes técnicos suficientes para reconstruírem o exploit.
Justin Bons, fundador e diretor de investimentos da Cyber Capital, escreveu no X que o xrpld 3.4.1 permaneceu de código fechado durante cerca de duas semanas antes de o código ser publicado. Mayukha Vadari, engenheira de software da RippleX, afirmou que as preocupações com a descoberta rápida e a engenharia reversa influenciaram o processo de publicação.
Essa sequência chamou a atenção porque as redes de código aberto dependem geralmente da revisão pública do código, enquanto uma restrição temporária à disponibilidade do código-fonte limita a análise independente. A abordagem da RippleX deu prioridade à prevenção da exploração enquanto os operadores dos validadores implementavam a correção, publicando depois o código quando o período urgente já tinha terminado.
Uma segunda correção resolveu um problema relacionado com a funcionalidade Batch
A versão 3.4.1 também resolveu um problema separado relacionado com a funcionalidade Batch, que ainda não tinha sido ativada quando os investigadores identificaram a primeira falha. A Veria Labs afirmou que a vulnerabilidade do Batch poderia ter paralisado a rede em determinadas circunstâncias.
O relatório afirmou que um atacante não conseguiria obter ativos na cadeia através do problema do Batch. O seu impacto potencial envolvia a criação de um registo do livro-razão permanentemente malformado, capaz de perturbar serviços fora da cadeia, como indexadores, exploradores de blockchain e kits de desenvolvimento de software. Esses serviços interpretam e organizam os dados do livro-razão para carteiras, aplicações e utilizadores; por isso, os registos malformados podem criar problemas operacionais mesmo quando os saldos do livro-razão permanecem intactos.
A Veria Labs afirmou que o Batch e a sua correção foram ativados na sexta-feira e que os servidores que executam versões antigas do software já não conseguem permanecer sincronizados com a rede. Esse resultado cria um forte incentivo para que os operadores restantes atualizem os seus sistemas, uma vez que os servidores desatualizados não conseguem acompanhar de forma fiável o estado atual do livro-razão.
Liao afirmou que a Veria Labs recebeu a recompensa máxima de 250 000 $ por comunicar as vulnerabilidades. A recompensa reflete a potencial gravidade de uma falha que atingiu a lógica contabilística central de uma blockchain pública, e não uma aplicação periférica.
O incidente também acrescenta evidências de que a análise automatizada de código está a tornar-se uma parte prática da descoberta de vulnerabilidades. O relato de Liao sobre um agente de IA que encontrou e explorou o problema não demonstra que a automatização possa substituir a revisão humana de segurança, mas mostra a rapidez com que erros aritméticos antigos podem ser detetados quando os investigadores combinam a análise automatizada com uma compreensão técnica das regras de transação de um protocolo.
A reparação do XRP Ledger impediu que a vulnerabilidade se transformasse num evento de emissão visível para o mercado. As questões que permanecem centram-se em saber se outras bases de código maduras de blockchain contêm riscos semelhantes de overflow de inteiros em percursos de transação complexos, especialmente quando várias operações são agregadas e os saldos são verificados através de rotinas contabilísticas separadas.
Preocupado com os riscos do protocolo após este erro do XRP Ledger? Explore a dinâmica dos pagamentos entre cadeias em esta análise de pagamentos transfronteiriços.
Aviso: O conteúdo desta página é fornecido apenas para fins informativos gerais e não representa as opiniões nem aconselhamento financeiro da Toobit. Não garantimos a exatidão ou integralidade destas informações e não seremos responsabilizados por quaisquer erros, omissões ou consequências resultantes da sua utilização. O investimento em ativos digitais envolve riscos; os utilizadores devem avaliar de forma independente a sua situação financeira e os riscos envolvidos. Para mais informações, consulte os nossos Termos de Serviço e Divulgação de Riscos.
