O pacote oficial do Node Package Manager (NPM) para o XRP Ledger (XRPL) da Ripple foi comprometido por atacantes que injetaram uma porta dos fundos no código. Esse ataque à cadeia de suprimentos foi detectado pela primeira vez em 21 de abril e visou uma das bibliotecas mais usadas para interagir com o XRP Ledger, colocando em risco aplicativos, desenvolvedores e usuários comuns.
Inserção discreta de código malicioso
O pacote xrpl, que serve como o kit de desenvolvimento de software (SDK) oficial para interagir com o XRP Ledger, possui 140.000 downloads semanais. Ele é usado por inúmeros aplicativos e sites para gerenciar transações, carteiras e outras operações na rede XRP.
No entanto, de acordo com uma investigação da Aikido Intel, empresa de segurança especializada em monitorar ecossistemas de código aberto, atores maliciosos exploraram esse pacote confiável para roubar chaves privadas de criptomoedas e obter acesso não autorizado às carteiras dos usuários.
O ataque foi iniciado quando um usuário desconhecido sob o nome de mukulljangid lançou cinco novas versões do pacote xrpl — as versões 4.2.1 a 4.2.4, juntamente com 2.14.2 — no NPM. O que gerou um alerta imediato foi o fato de essas versões não corresponderem a nenhuma atualização ou marca visível no repositório oficial do projeto no GitHub, onde a versão 4.2.0 ainda era a mais recente na época. Essa discrepância entre o registro do NPM e o GitHub sinalizou uma possível fraude.
Após uma inspeção mais detalhada, a Aikido Intel descobriu atividades suspeitas embutidas nos arquivos-fonte das versões afetadas. Especificamente, o arquivo src/index.ts continha uma função chamada checkValidityOfSeed, que parecia inofensiva, mas servia como um canal para exfiltrar dados sensíveis. A função se comunicava secretamente com um domínio chamado 0x9c[.]xyz, registrado apenas alguns dias antes do ataque — uma característica de comportamento criminoso premeditado.
Como a porta dos fundos operava
A carga maliciosa foi habilmente tecida em componentes-chave da biblioteca, garantindo sua execução sempre que funcionalidades relacionadas a carteiras fossem invocadas. Por exemplo:
- No construtor da classe Wallet, a função checkValidityOfSeed era acionada toda vez que um novo objeto de carteira era instanciado. Isso permitia que os atacantes interceptassem as chaves privadas imediatamente após sua geração.
- Ganchos semelhantes foram colocados em métodos como deriveWallet, fromMnemonic, fromEntropy e outros, garantindo uma cobertura abrangente em vários caminhos de criação de carteiras.
Embora a função em si apenas definisse um método sem chamá-lo de forma explícita, uma investigação mais detalhada apontou que ela era, sim, acionada em diversas partes do código — especialmente durante operações envolvendo seed generation e derivação de chaves.
Evolução do ataque e implicações
As tentativas iniciais do atacante consistem na injeção manual do código malicioso em arquivos JavaScript pré-construídos (build/xrp-latest-min.js e build/xrp-latest.js) a partir da versão 4.2.1. Na versão 4.2.2, o adversário aprimorou sua abordagem, incorporando a porta dos fundos diretamente nos arquivos de código-fonte TypeScript, como src/Wallet/index.ts. Essa mudança foi um esforço deliberado para evitar a detecção, mantendo a furtividade da exploração.
Dada a adoção do pacote xrpl, as possíveis consequências desse vazamento são perigosas. Qualquer aplicação ou serviço que dependa das versões comprometidas pode ter inadvertidamente exposto as chaves privadas dos usuários aos atacantes. Uma vez roubadas, essas chaves concedem acesso irrestrito às carteiras de criptomoedas associadas, possibilitando o roubo dos fundos armazenados nelas.
Medidas tomadas para mitigar a ameaça
Após a descoberta da violação, os mantenedores do pacote xrpl responderam lançando duas versões corrigidas: 4.2.5 e 2.14.3. Essas atualizações neutralizaram a ameaça, removendo o código malicioso e restaurando a integridade da biblioteca. Além disso, a Aikido Intel forneceu indicadores claros de comprometimento (IOCs):
- Versões do pacote: 4.2.1, 4.2.2, 4.2.3, 4.2.4, 2.14.2
- Domínio suspeito: 0x9c[.]xyz
Usuários que suspeitam de exposição devem revisar suas listas de dependências (package.json e package-lock.json) e inspecionar logs de rede para conexões de saída com o domínio mencionado. Se forem encontrados sinais de infecção, as chaves privadas afetadas devem ser consideradas comprometidas e substituídas imediatamente.
Leia mais: Stablecoin da Ripple chega ao Aave V3
