Un error de una década en XRP Ledger podría haber creado XRP de la nada

¿Qué fallaba realmente?

El problema se encontraba en el código que liquida los pagos a través del intercambio descentralizado (DEX) integrado en el $XRP Ledger. Según el informe oficial de divulgación de la vulnerabilidad publicado ayer, cuando un único pago consumía muchas ofertas, el motor sumaba los importes utilizando aritmética de 64 bits sin verificar.

Al elevar esa suma lo suficiente, se producía un «rebote», que es lo que ocurre con un desbordamiento de enteros. Un número gigantesco se convertía posteriormente en uno pequeño y a los vendedores de la otra parte de la operación se les pagaba el importe íntegro, pero al comprador solo se le cobraba el minúsculo total resultante del rebote. La diferencia era $XRP que nunca había existido antes.

El libro mayor realiza una comprobación de seguridad, conocida como «invariante», que se supone que confirma que nunca se crea $XRP. Esa comprobación utilizaba el mismo cálculo sin verificar, por lo que no detectaba precisamente el fallo que se suponía que debía detectar. El informe remonta el fallo al motor de pagos actual, que se escribió en 2015.

¿Cuánto habría costado un ataque?

El informe indica que el coste consistió en unos pocos cientos de $XRP bloqueados como reservas —que se devuelven una vez retirados los objetos— más las comisiones habituales de transacción. Un atacante habría tenido que realizar cientos de ofertas con precios deliberadamente erróneos y, a continuación, canalizar un pago a través de ellas.

Lo más alarmante era la recompensa: RippleX calificó el fallo de crítico porque se podrían haber creado $XRP gastables por encima del suministro total en una sola transacción validada. Todo el argumento de venta del $XRP se basa en un límite máximo de 100 000 millones de tokens, por lo que una emisión silenciosa habría socavado la promesa fundamental del activo. Por eso, publicaciones como la de Whale Insider lo describieron como un fallo que podría haber generado «miles de millones» de $XRP.

¿Quién lo descubrió y con qué rapidez se solucionó?

El proceso fue bastante breve y se desarrolló de la siguiente manera:

• 22 de septiembre: Cayden Liao y Veria AI enviaron sus hallazgos a través del programa de recompensas por errores de XRPL (XRPL Bug Bounty), calificándolo como «grave».
• 23 de septiembre: RippleX lo reprodujo, lo reclasificó como «crítico» y se incorporó la corrección.
• 25 de septiembre: se lanzó Xrpld 3.4.1, y más del 80 % de los validadores predeterminados de la Lista Única de Nodos (UNL) lo estaban ejecutando ese mismo día.
• 9 de octubre: Divulgación pública.

El parche no se sometió a la votación de enmienda habitual, sino que se lanzó como un cambio directo en el código en la versión 3.4.1 y entró en vigor a medida que cada servidor se actualizaba. El código fuente solo se publicó tras la implementación, una medida habitual para evitar dar pistas a los atacantes. Desde entonces, la cuenta de XRPL Operations ha establecido la versión 3.4.1 como la mínima requerida, añadiendo:

No hemos encontrado pruebas de que este problema se haya aprovechado en ninguna red pública.

En la misma versión se corrigió un segundo error de menor gravedad. Este afectaba a la forma en que se agrupan las transacciones por lotes, y su corrección se incluye en la enmienda fixBatchV1_2, que entró en vigor en Mainnet el 9 de octubre junto con BatchV1_1. El informe indica que tampoco se perdieron fondos a causa de este error.

La revelación se produjo en una semana complicada para la seguridad de las criptomonedas, ya que las pérdidas de dispositivos Ledger, según informó Bitcoin.com News, alcanzaron un valor estimado de 93,4 millones de dólares. Por último, Evernorth, respaldada por Ripple, se prepara para comenzar a cotizar en el Nasdaq bajo el símbolo XRPN el lunes, con aproximadamente 473 millones de $XRP en sus libros. El $XRP también se ha ido expandiendo hacia las finanzas descentralizadas (DeFi), y Firelight ha activado recientemente la protección de bóveda en la red.