O XRP Ledger corrigiu uma falha de segurança crítica que remonta a 2015 e que poderia ter permitido a atacantes criar aproximadamente 18 trilhões de XRP por meio de uma única transação especialmente projetada, com mais de 80% dos validadores confiáveis instalando a atualização de emergência em 25 de setembro.
Resumo
- Os desenvolvedores do XRPL corrigiram um bug crítico de pagamento que poderia criar XRP gastável além de sua oferta.
- O pesquisador Cayden Liao demonstrou que aproximadamente 18 trilhões de XRP poderiam ser cunhados por meio de uma transação elaborada.
- A equipe de segurança não encontrou evidências de que a falha de overflow tenha sido explorada em redes públicas.
- Mais de 80% dos validadores padrão atualizaram para o xrpld 3.4.1 em 25 de setembro, confirmaram os desenvolvedores.
- Uma correção separada de validação em lote foi ativada em 9 de outubro após os validadores adiarem sua implantação original planejada.
A XRP Ledger Foundation e a RippleX confirmaram a vulnerabilidade em uma divulgação de 9 de outubro, explicando que um erro no mecanismo de pagamento da rede poderia ter produzido XRP gastável além de sua oferta pretendida de 100 bilhões. Os desenvolvedores reproduziram o problema durante os testes e lançaram a versão 3.4.1 para corrigi-lo. Sua investigação não encontrou evidências de que a falha tenha sido explorada em uma rede pública. O pesquisador de segurança Cayden Liao e a Veria AI receberam a recompensa máxima de US$ 250.000 do programa de bug bounty após relatarem a vulnerabilidade e demonstrarem seu efeito potencial.
XRP Ledger corrige bug que poderia criar trilhões de XRP
A vulnerabilidade afetou o mecanismo de pagamento do XRP Ledger, que processa transferências e transações envolvendo a exchange descentralizada integrada à rede.
De acordo com a divulgação oficial, o problema originou-se de um overflow de inteiro em software escrito em 2015. Um overflow de inteiro ocorre quando um cálculo produz um número maior do que o sistema computacional pode representar usando o número de bits alocado.
Neste caso, o mecanismo de pagamento somava os valores de XRP associados a múltiplas ofertas no livro de ordens da rede. O software usava um inteiro de 64 bits para calcular o valor total que um comprador devia ao concluir um pagamento envolvendo várias ofertas.
Os desenvolvedores descobriram que um atacante poderia criar centenas de ofertas com preços especialmente definidos e organizar para que um único pagamento as consumisse. Quando o total calculado excedia o valor máximo do inteiro, o número poderia dar a volta para um valor muito menor. O sistema ainda creditaria os vendedores individuais com os valores totais de XRP especificados em suas ofertas, mesmo que o comprador pagasse apenas o valor reduzido produzido pelo overflow. A diferença criaria XRP que não existia anteriormente.
De acordo com a XRPL Foundation, a criptomoeda resultante poderia ser transferida para outras contas, negociada ou enviada para exchanges. O relatório descreveu o resultado potencial: “Um atacante poderia ter criado XRP gastável muito além da oferta total.”
A vulnerabilidade não poderia ser acionada por meio de negociação comum, de acordo com os desenvolvedores. Um atacante precisaria criar várias centenas de contas, colocar ofertas com preços incomuns e enviar uma transação cuidadosamente construída para processá-las em conjunto. As verificações de segurança existentes falharam porque a verificação de oferta do sistema usava o mesmo tipo de aritmética que causou o erro original.
Enquanto isso, uma verificação separada de saldo de conta poderia ser contornada distribuindo o XRP recém-criado entre várias carteiras.
Pesquisador descobre potencial exploit de 18 trilhões de XRP
A vulnerabilidade chamou a atenção dos desenvolvedores depois que o pesquisador de segurança Cayden Liao e a Veria AI testaram o software de código aberto do XRP Ledger.
A Veria Labs publicou suas descobertas em 10 de outubro, descrevendo como seu sistema automatizado de testes de segurança descobriu o problema em 21 de setembro. No dia seguinte, os pesquisadores desenvolveram uma prova de conceito funcional em uma rede de testes local.
De acordo com a empresa, a demonstração mostrou que aproximadamente 18 trilhões de XRP poderiam ser criados por meio de uma transação especialmente projetada. O valor era equivalente a cerca de 184 vezes o suprimento total pretendido do XRP, com base no cálculo dos pesquisadores. O número descreve os resultados de testes de segurança controlados, não um aumento real no suprimento circulante da criptomoeda. Liao enviou a vulnerabilidade por meio do programa oficial de recompensas por bugs do XRPL em 22 de setembro.
Engenheiros da RippleX reproduziram o problema em um servidor autônomo e confirmaram que os XRP recém-gerados poderiam ser gastos em um pagamento subsequente.
O relatório inicial classificou a vulnerabilidade como maior, mas os desenvolvedores elevaram sua gravidade para crítica após confirmar as consequências potenciais. A Veria Labs afirmou que a vulnerabilidade poderia ter colocado todo o valor de mercado do XRP em risco se os atacantes a tivessem explorado com sucesso. A estimativa da empresa baseou-se em uma capitalização de mercado do XRP de aproximadamente US$ 94 bilhões na época.
No entanto, o valor de US$ 94 bilhões representa a estimativa do pesquisador de exposição financeira potencial, não perdas confirmadas. A equipe de segurança não encontrou evidências de criação não autorizada de XRP em redes públicas. Em 8 de outubro, a Veria AI recebeu a recompensa máxima de US$ 250.000 por identificar e divulgar responsavelmente o problema.
RippleX lança correção de emergência sem o processo normal de aprovação
Após confirmar a vulnerabilidade, os engenheiros da RippleX desenvolveram uma correção entre 22 e 23 de setembro. O patch foi incorporado à versão 3.4.1 do xrpld, lançada em 25 de setembro.
De acordo com a divulgação oficial, os desenvolvedores adicionaram verificações que impedem o mecanismo de pagamento de aceitar cálculos que excedam o intervalo inteiro permitido. O software atualizado rejeita cálculos afetados e retorna uma falha de pagamento comum em vez de criar XRP adicional. Os engenheiros reforçaram a verificação de suprimento da rede substituindo a aritmética existente por um contador mais amplo projetado para detectar erros semelhantes. Cálculos adicionais de saldo foram revisados como precaução.
No entanto, a decisão de implantar a correção introduziu uma situação incomum para a governança do XRP Ledger. Normalmente, alterações no processamento de transações devem passar pelo sistema de emendas da rede. Uma emenda requer suporte de mais de 80% dos validadores confiáveis por duas semanas consecutivas antes da ativação.
Para a vulnerabilidade de estouro de pagamento, os desenvolvedores decidiram aplicar a correção imediatamente quando os validadores atualizassem seu software. A Fundação XRPL explicou que o processo normal teria exposto a vulnerabilidade, deixando-a explorável durante o período de aprovação.
Como o software do XRP Ledger é de código aberto, publicar um patch pode revelar a localização e a natureza de uma vulnerabilidade.
Os desenvolvedores concluíram que esperar pelo processo usual de emenda poderia ter criado riscos de segurança adicionais. A abordagem emergencial trouxe uma preocupação separada: validadores executando versões diferentes do software poderiam discordar sobre como processar uma transação maliciosa.
Em um cenário extremo, a discordância poderia impedir temporariamente a rede de confirmar novos ledgers. A fundação disse que a decisão foi tomada em consulta com a RippleX, operadores de validadores e outros contribuidores do XRPL. Até 25 de setembro, mais de 80% dos validadores na Lista de Nós Únicos padrão haviam atualizado para a versão 3.4.1.
O código-fonte público foi subsequentemente divulgado após a resposta de segurança imediata. Os registros de lançamento da Fundação XRPL descrevem a versão 3.4.1 como uma atualização de emergência que aborda problemas de protocolo sensíveis à segurança.
XRP Ledger resolve segunda falha de segurança antes da ativação do Batch
A divulgação de 9 de outubro cobriu outra vulnerabilidade envolvendo o recurso de transação Batch do XRP Ledger. O Batch permite que os desenvolvedores combinem até oito transações em uma operação. O recurso suporta diferentes modos de execução, incluindo arranjos nos quais todas as transações devem ser bem-sucedidas para que a operação completa seja aceita.
Durante os testes de segurança, os pesquisadores descobriram um erro de validação envolvendo como transações individuais eram empacotadas dentro de um Batch. O protocolo exigia que cada transação usasse um campo específico chamado RawTransaction.
No entanto, o software poderia aceitar nomes de campos alternativos sob certas condições. Os investigadores descobriram que diferentes versões de servidor podiam processar essas transações formatadas incorretamente de maneiras diferentes.
De acordo com a XRPL Foundation, a divergência resultante poderia interromper a validação da rede se o recurso se tornasse ativo antes que o problema fosse corrigido. O problema foi originalmente identificado durante o Sherlock Attackathon e posteriormente examinado pelo contribuidor da XRPL Foundation Denis Angell. O engenheiro da RippleX Mayukha Vadari determinou que a vulnerabilidade criava um potencial risco de consenso entre versões de servidor.
Os desenvolvedores responderam introduzindo a emenda fixBatchV1_2. A emenda exige que toda transação Batch use o formato de campo aprovado e rejeita transações empacotadas incorretamente. Os validadores retiraram temporariamente o suporte ao cronograma de ativação anterior do BatchV1_1 enquanto os desenvolvedores concluíam a correção.
Tanto fixBatchV1_2 quanto BatchV1_1 foram ativados na mainnet do XRP Ledger em 9 de outubro. A ativação do XRP Ledger Batch recebeu suporte de 30 validadores, com cinco se opondo à atualização, de acordo com números do XRPScan incluídos no relatório verificado da rede.
Pesquisas anteriores sobre a revisão de segurança do Batch detalharam o lançamento de emergência de 25 de setembro e as salvaguardas necessárias antes que o recurso pudesse ser ativado. A versão inicial já havia enfrentado preocupações de segurança, incluindo problemas de autorização de transações descobertos durante revisões de desenvolvedores.
Uma auditoria de segurança separada do XRP Ledger em agosto documentou 96 vulnerabilidades válidas identificadas durante uma competição Sherlock cobrindo recursos propostos do protocolo.
Para a mais recente vulnerabilidade do Batch, a XRPL Foundation confirmou que as emendas afetadas não estavam ativas na mainnet quando o problema foi descoberto. Nenhum fundo de usuário foi perdido, nenhuma chave privada foi comprometida e nenhuma falha de consenso ocorreu por causa dessa falha específica. A ativação de 9 de outubro significa que servidores executando versões mais antigas do software agora estão bloqueados por emenda e devem atualizar para a versão 3.4.1 ou posterior para permanecerem sincronizados.
A XRPL Foundation disse que está introduzindo um requisito adicional de verificação para futuros lançamentos de software: problemas de segurança relatados anteriormente devem ser testados novamente em candidatos a lançamento antes de serem classificados como corrigidos.
De acordo com a fundação, o procedimento se aplicará a descobertas de auditorias, programas de bug bounty, testes de segurança assistidos por IA e outras avaliações de vulnerabilidade.
