El XRP Ledger ha corregido una falla de seguridad crítica que se remonta a 2015 y que podría haber permitido a los atacantes crear aproximadamente 18 billones de XRP mediante una única transacción especialmente diseñada, con más del 80% de los validadores de confianza instalando la actualización de emergencia el 25 de septiembre.
Resumen
- Los desarrolladores de XRPL corrigieron un error crítico de pago que podría crear XRP gastable más allá de su suministro.
- El investigador Cayden Liao demostró que se podrían acuñar aproximadamente 18 billones de XRP mediante una transacción manipulada.
- El equipo de seguridad no encontró evidencia de que la falla de desbordamiento fuera explotada en redes públicas.
- Más del 80% de los validadores predeterminados actualizaron a xrpld 3.4.1 el 25 de septiembre, confirmaron los desarrolladores.
- Una corrección separada de validación por lotes se activó el 9 de octubre después de que los validadores retrasaran su implementación original planificada.
La XRP Ledger Foundation y RippleX confirmaron la vulnerabilidad en una divulgación del 9 de octubre, explicando que un error en el motor de pagos de la red podría haber producido XRP gastable más allá de su suministro previsto de 100 mil millones. Los desarrolladores reprodujeron el problema durante las pruebas y lanzaron la versión 3.4.1 para solucionarlo. Su investigación no encontró evidencia de que la falla hubiera sido explotada en una red pública. El investigador de seguridad Cayden Liao y Veria AI recibieron la recompensa máxima de $250,000 del programa de recompensas por errores después de reportar la vulnerabilidad y demostrar su efecto potencial.
XRP Ledger corrige un error que podría crear billones de XRP
La vulnerabilidad afectó al motor de pagos del XRP Ledger, que procesa transferencias y transacciones relacionadas con el exchange descentralizado integrado de la red.
Según la divulgación oficial, el problema se originó por un desbordamiento de entero en un software escrito en 2015. Un desbordamiento de entero ocurre cuando un cálculo produce un número mayor de lo que el sistema informático puede representar utilizando la cantidad de bits asignada.
En este caso, el motor de pagos sumaba cantidades de XRP asociadas con múltiples ofertas en el libro de órdenes de la red. El software utilizaba un entero de 64 bits para calcular la cantidad total que un comprador debía al completar un pago que involucraba varias ofertas.
Los desarrolladores descubrieron que un atacante podía crear cientos de ofertas con precios especialmente diseñados y lograr que un solo pago las consumiera. Cuando el total calculado superaba el valor máximo del entero, el número podía dar la vuelta a una cantidad mucho menor. El sistema aún acreditaba a los vendedores individuales las cantidades completas de XRP especificadas en sus ofertas, aunque el comprador solo pagara la cantidad reducida producida por el desbordamiento. La diferencia crearía XRP que no existía previamente.
Según la XRPL Foundation, la criptomoneda resultante podría transferirse a otras cuentas, intercambiarse o enviarse a exchanges. El informe describió el resultado potencial: “Un atacante podría haber creado XRP gastable muy por encima del suministro total”.
La vulnerabilidad no podía desencadenarse mediante el comercio ordinario, según los desarrolladores. Un atacante habría necesitado crear varios cientos de cuentas, colocar ofertas con precios inusuales y enviar una transacción cuidadosamente construida para procesarlas juntas. Las verificaciones de seguridad existentes fallaron porque la verificación del suministro del sistema utilizaba el mismo tipo de aritmética que causó el error original.
Mientras tanto, una verificación separada del saldo de la cuenta podía eludirse distribuyendo el XRP recién creado entre múltiples carteras.
Investigador descubre un posible exploit de 18 billones de XRP
La vulnerabilidad llamó la atención de los desarrolladores después de que el investigador de seguridad Cayden Liao y Veria AI probaran el software de código abierto del XRP Ledger.
Veria Labs publicó sus hallazgos el 10 de octubre, describiendo cómo su sistema automatizado de pruebas de seguridad descubrió el problema el 21 de septiembre. Al día siguiente, los investigadores desarrollaron una prueba de concepto funcional en una red de pruebas local.
Según la compañía, la demostración mostró que se podían crear aproximadamente 18 billones de XRP mediante una transacción especialmente diseñada. La cantidad equivalía a aproximadamente 184 veces el suministro total previsto de XRP, según el cálculo de los investigadores. La cifra describe los resultados de pruebas de seguridad controladas, no un aumento real en el suministro circulante de la criptomoneda. Liao envió la vulnerabilidad a través del programa oficial de recompensas por errores de XRPL el 22 de septiembre.
Los ingenieros de RippleX reprodujeron el problema en un servidor independiente y confirmaron que los XRP recién generados podían gastarse en un pago posterior.
El informe inicial clasificó la vulnerabilidad como mayor, pero los desarrolladores elevaron su gravedad a crítica después de confirmar las posibles consecuencias. Veria Labs declaró que la vulnerabilidad podría haber puesto en riesgo todo el valor de mercado de XRP si los atacantes la hubieran explotado con éxito. La estimación de la compañía se basó en una capitalización de mercado de XRP de aproximadamente 94 mil millones de dólares en ese momento.
Sin embargo, la cifra de 94 mil millones de dólares representa la estimación del investigador de la exposición financiera potencial, no pérdidas confirmadas. El equipo de seguridad no encontró evidencia de creación no autorizada de XRP en redes públicas. El 8 de octubre, Veria AI recibió la recompensa máxima de 250,000 dólares por identificar y divulgar responsablemente el problema.
RippleX lanza una solución de emergencia sin el proceso de aprobación normal
Después de confirmar la vulnerabilidad, los ingenieros de RippleX desarrollaron una solución entre el 22 y el 23 de septiembre. El parche se incorporó a la versión 3.4.1 de xrpld, lanzada el 25 de septiembre.
Según la divulgación oficial, los desarrolladores agregaron verificaciones que impiden que el motor de pagos acepte cálculos que excedan el rango de enteros permitido. El software actualizado rechaza los cálculos afectados y devuelve un fallo de pago ordinario en lugar de crear XRP adicional. Los ingenieros reforzaron la verificación de suministro de la red reemplazando la aritmética existente con un contador más amplio diseñado para detectar errores similares. Se revisaron cálculos de saldo adicionales como precaución.
Sin embargo, la decisión de implementar la solución introdujo una situación inusual para la gobernanza del XRP Ledger. Normalmente, los cambios en el procesamiento de transacciones deben pasar por el sistema de enmiendas de la red. Una enmienda requiere el apoyo de más del 80% de los validadores de confianza durante dos semanas consecutivas antes de su activación.
Para la vulnerabilidad de desbordamiento de pagos, los desarrolladores decidieron aplicar la solución inmediatamente cuando los validadores actualizaran su software. La Fundación XRPL explicó que el proceso normal habría expuesto la vulnerabilidad mientras la dejaba explotable durante el período de aprobación.
Debido a que el software del XRP Ledger es de código abierto, publicar un parche puede revelar la ubicación y la naturaleza de una vulnerabilidad.
Los desarrolladores concluyeron que esperar a través del proceso de enmienda habitual podría haber creado riesgos de seguridad adicionales. El enfoque de emergencia conllevaba una preocupación aparte: los validadores que ejecutan diferentes versiones de software podrían discrepar sobre cómo procesar una transacción maliciosa.
En un escenario extremo, el desacuerdo podría impedir temporalmente que la red confirme nuevos ledgers. La fundación dijo que la decisión se tomó en consulta con RippleX, operadores de validadores y otros contribuyentes de XRPL. Para el 25 de septiembre, más del 80% de los validadores en la Lista de Nodos Únicos predeterminada se habían actualizado a la versión 3.4.1.
El código fuente público se publicó posteriormente después de la respuesta de seguridad inmediata. Los registros de lanzamiento de la Fundación XRPL describen la versión 3.4.1 como una actualización de emergencia que aborda problemas de protocolo sensibles a la seguridad.
XRP Ledger resuelve una segunda falla de seguridad antes de la activación de Batch
La divulgación del 9 de octubre cubrió otra vulnerabilidad relacionada con la función de transacciones Batch del XRP Ledger. Batch permite a los desarrolladores combinar hasta ocho transacciones en una sola operación. La función admite diferentes modos de ejecución, incluidos arreglos en los que cada transacción debe tener éxito para que se acepte la operación completa.
Durante las pruebas de seguridad, los investigadores descubrieron un error de validación relacionado con cómo se empaquetaban las transacciones individuales dentro de un Batch. El protocolo requería que cada transacción utilizara un campo específico llamado RawTransaction.
Sin embargo, el software podría aceptar nombres de campos alternativos bajo ciertas condiciones. Los investigadores descubrieron que diferentes versiones del servidor podrían procesar esas transacciones con formato incorrecto de manera diferente.
Según la Fundación XRPL, el desacuerdo resultante podría interrumpir la validación de la red si la función se activara antes de que se corrigiera el problema. El problema se identificó originalmente durante el Sherlock Attackathon y luego fue examinado por el colaborador de la Fundación XRPL, Denis Angell. El ingeniero de RippleX, Mayukha Vadari, determinó que la vulnerabilidad creaba un posible riesgo de consenso entre versiones del servidor.
Los desarrolladores respondieron introduciendo la enmienda fixBatchV1_2. La enmienda requiere que cada transacción Batch utilice el formato de campo aprobado y rechaza las transacciones empaquetadas incorrectamente. Los validadores retiraron temporalmente su apoyo al calendario de activación anterior de BatchV1_1 mientras los desarrolladores completaban la corrección.
Tanto fixBatchV1_2 como BatchV1_1 se activaron en la red principal de XRP Ledger el 9 de octubre. La activación de XRP Ledger Batch recibió el apoyo de 30 validadores, con cinco oponiéndose a la actualización, según las cifras de XRPScan incluidas en el informe de red verificado.
Una investigación anterior sobre la revisión de seguridad de Batch detalló el lanzamiento de emergencia del 25 de septiembre y las salvaguardas necesarias antes de que la función pudiera activarse. La versión inicial había enfrentado previamente preocupaciones de seguridad, incluidos problemas de autorización de transacciones descubiertos durante las revisiones de los desarrolladores.
Una auditoría de seguridad separada de XRP Ledger en agosto documentó 96 vulnerabilidades válidas identificadas durante una competencia de Sherlock que cubría las características propuestas del protocolo.
Para la última vulnerabilidad de Batch, la Fundación XRPL confirmó que las enmiendas afectadas no habían estado activas en la red principal cuando se descubrió el problema. No se perdieron fondos de usuarios, no se comprometieron claves privadas y no ocurrió ninguna falla de consenso debido a ese fallo en particular. La activación del 9 de octubre significa que los servidores que ejecutan versiones de software más antiguas ahora están bloqueados por enmiendas y deben actualizarse a la versión 3.4.1 o posterior para permanecer sincronizados.
La Fundación XRPL dijo que está introduciendo un requisito de verificación adicional para futuras versiones de software: los problemas de seguridad reportados previamente deben probarse nuevamente contra los candidatos de lanzamiento antes de clasificarse como corregidos.
Según la fundación, el procedimiento se aplicará a los hallazgos de auditorías, programas de recompensas por errores, pruebas de seguridad asistidas por IA y otras evaluaciones de vulnerabilidad.
