Auditoría de Common Prefix detecta 7 fallas críticas en las transacciones batch del XRP Ledger

Una auditoría de Common Prefix identificó siete hallazgos en las transacciones batch de XRP Ledger, incluidos problemas críticos de reproducción de firmas y un vector de amplificación DoS que podía generar hasta 40.320 permutaciones de una misma operación. Las correcciones están bajo revisión y no tienen fecha de lanzamiento anunciada.
***

• Las firmas de los batches no estaban vinculadas inicialmente a la cuenta ni al número de secuencia de la transacción externa.
• Un atacante podía crear hasta 40.320 permutaciones de un batch con ocho firmantes y retransmitirlas sin pagar comisiones adicionales.
• XRPL implementó una corrección de reemplazo denominada BatchV1_1, que permanece bajo revisión y todavía no tiene fecha de lanzamiento.

Una auditoría sobre la nueva función batch

El informe de seguridad publicado por Common Prefix revisó la implementación de referencia en C++ de las transacciones batch del XRP Ledger, una función asociada a la propuesta XLS-0056. El trabajo fue realizado por Dejan Cabrilo, Nikolaos Kamarinakis e Ivan Randjelovic, y examinó cuatro pull requests del código base de xrpld: los números 5060, 6176, 6069 y 6446.

Ripple contrató la auditoría para evaluar una herramienta que permite agrupar varias transacciones internas dentro de una sola transacción externa. El diseño busca ofrecer ejecución atómica y distintos comportamientos configurables, de modo que un batch pueda ejecutar todas las operaciones, detenerse ante un fallo o continuar de manera independiente según las flags utilizadas.

La revisión cubrió la firma de batches, el cálculo de comisiones, la serialización, la integración con el consenso, la retransmisión entre pares, la protección contra reproducción y el aislamiento del estado del ledger. En total, los investigadores identificaron siete hallazgos: uno crítico, dos de severidad alta, dos bajos, uno informativo y otro bajo relacionado con las guardas de enmiendas.

El informe clasificó como crítico un problema de reproducción de transacciones batch y como alto un defecto que permitía reutilizar ciertas firmas multi-sign. También consideró de alta severidad un mecanismo para generar múltiples IDs de transacción mediante la permutación de firmantes, aunque posteriormente se aceptó principalmente como un problema de determinismo y no solo como un vector de denegación de servicio.

Firmas sin suficiente vínculo con el contexto externo

El hallazgo más grave, identificado como CP-BATCH-01, surgía porque los datos firmados por los firmantes del batch no incluían la cuenta externa, el número de secuencia ni un identificador único del contenedor. En la práctica, el material construido por serializeBatch incorporaba el prefijo del batch, las flags y los IDs de las transacciones internas, pero no vinculaba esas firmas con un envío externo específico.

Según el análisis, un atacante que observara un batch válido podía extraer el arreglo sfBatchSigners y colocarlo en otro contenedor con credenciales externas diferentes. El riesgo era especialmente serio en el modo tfOnlyOne, que ejecuta únicamente la primera transacción interna exitosa, porque la reproducción repetida bajo condiciones distintas podía permitir que se ejecutaran individualmente todas las operaciones originalmente diseñadas para excluirse entre sí.

El modo tfAllOrNothing también presentaba exposición, aunque bajo una dinámica distinta. Cuando un batch fallaba, por ejemplo por falta de fondos, las secuencias internas no se consumían; si las condiciones cambiaban posteriormente, el mismo conjunto de operaciones podía volver a intentarse porque sus secuencias continuaban siendo válidas.

Los modos tfIndependent y tfUntilFailure resultaban menos afectados debido a que consumen secuencias incluso en determinadas transacciones internas fallidas. La resolución propuesta incorporó la cuenta y la secuencia de la transacción externa a los datos firmados, con el objetivo de que el arreglo de firmantes solo sea válido para un envío concreto y no pueda trasladarse a otro batch.

El segundo problema importante, CP-BATCH-02, afectaba la verificación de firmas multi-sign. En checkBatchMultiSign, los datos incluían la cuenta del multi-signer individual, pero omitían la cuenta del firmante de batch al que pertenecía esa entrada; por ello, si dos firmantes compartían un multi-signer, la firma de una entrada podía copiarse silenciosamente en la otra.

La consecuencia era una ruptura del principio de consentimiento específico, ya que una firma válida para una acción podía presentarse como autorización de otra dentro del mismo batch. La corrección propuesta modifica el flujo para incluir también el sfAccount del firmante de batch, haciendo que el contenido firmado sea diferente para cada entrada.

La auditoría detectó además una omisión de menor severidad en CP-BATCH-03. La función de multi-sign de batches pasaba un valor nulo en lugar de la cuenta de la transacción, lo que desactivaba la comprobación que impide que el propietario aparezca como uno de sus propios multi-signers y cuente para alcanzar el quórum.

La corrección consiste en pasar la cuenta correspondiente a la función de validación, con lo que se restablece la prohibición existente en el multi-sign regular. El informe señala que Ripple confirmó que la auto-firma no constituía una excepción intencional del diseño de batches.

El riesgo de las permutaciones y la carga sobre la red

El hallazgo CP-BATCH-05 combinó dos características de la implementación para crear un mecanismo de amplificación. El campo sfBatchSigners estaba excluido de la firma externa, pero sí se incluía en el cálculo del ID de transacción, mientras que el arreglo STArray conservaba el orden de inserción sin imponer una serialización canónica.

Como no existía una comprobación que exigiera ordenar los firmantes por AccountID, un atacante podía reorganizar los elementos de un batch sin invalidar las firmas. Con ocho firmantes, el número máximo de órdenes posibles alcanzaba 8!, es decir, 40.320 permutaciones de la misma operación válida, cada una con una serialización y un ID de transacción diferentes.

Common Prefix describió el comportamiento en una red privada de pruebas con tres validadores honestos y un nodo malicioso, todos interconectados. El nodo modificado interceptó un batch con ocho firmantes, generó 40.319 permutaciones adicionales y las retransmitió directamente a sus pares, sin realizar el procesamiento local.

La víctima pagó 180 drops una sola vez, mientras que el atacante no tuvo que pagar comisiones por las permutaciones. Aunque solo un batch terminó en el ledger validado, cada variante fue tratada como una transacción nueva por el HashRouter y activó el preflight, incluida la verificación criptográfica de ocho firmas por operación.

La resolución propuesta exige que sfBatchSigners esté ordenado por AccountID en orden estrictamente creciente. Esta regla elimina las distintas serializaciones para un mismo conjunto de firmantes y deja un único ID de transacción canónico, además de absorber la comprobación previa contra duplicados.

El informe también encontró una falta de caché de las firmas de los firmantes de batch, clasificada como CP-BATCH-06 y de severidad baja. Mientras la firma de la cuenta externa puede almacenarse mediante la flag SF_SIGGOOD, las firmas internas se vuelven a verificar en varias etapas del procesamiento, sin un mecanismo equivalente de reutilización.

Con ocho firmantes, las cuatro rondas descritas de verificación podían representar 32 llamadas a verify por transacción batch. En el escenario más exigente, con hasta 32 multi-signers por firmante, una sola operación podía activar hasta 1.024 verificaciones, aunque Ripple no consideró necesario modificar el código debido a los volúmenes actuales y al cobro de comisiones por firmante.

La revisión también observó que un batch con N transacciones internas incrementa en uno el contador txCount usado para escalar las comisiones del ledger abierto. La empresa consideró intencional este comportamiento porque el batch es una sola transacción a nivel de protocolo y sus operaciones internas ya se reflejan en la comisión agregada calculada durante la admisión.

Estado del ledger, consenso y próximos controles

El análisis de la ejecución no encontró errores en los cuatro modos de batch. En tfAllOrNothing, cualquier resultado distinto de tesSUCCESS descarta la vista completa del batch; en tfOnlyOne, el ciclo se detiene después de la primera transacción exitosa; y en tfUntilFailure se conservan las operaciones anteriores hasta encontrar el primer resultado que detiene la ejecución.

El modo tfIndependent intenta todas las transacciones internas sin importar los resultados individuales. En términos generales, los resultados tesSUCCESS y tecCLAIM conservan sus cambios, consumen secuencias y comisiones, mientras que los fallos de tipo tem, tel o tef descartan sus vistas correspondientes.

Cada transacción interna se ejecuta en una OpenView propia, denominada perTxBatchView, que funciona como una primera capa de aislamiento. Cuando la operación puede aplicarse, sus cambios pasan a una vista compartida del batch; esa vista acumulada solo se incorpora al ledger principal cuando la lógica general de aplicación termina correctamente.

Este modelo permite que las transacciones internas posteriores observen los efectos de las anteriores, algo necesario para administrar correctamente las secuencias. En el caso de tfAllOrNothing, una falla descarta todo el estado acumulado; la auditoría concluyó que la fusión de vistas y el orden secuencial producen resultados deterministas para los validadores.

La transacción externa consume siempre su secuencia o ticket antes de ejecutar las operaciones internas, lo que impide reproducir el batch externo mediante el mismo contexto. El preflight también verifica secuencias y tickets, evita duplicados dentro del batch y rechaza transacciones que incluyan simultáneamente sfSequence y sfTicketSequence.

Los investigadores revisaron además las defensas contra la extracción de transacciones internas. Estas deben incluir la flag tfInnerBatchTxn, comisión cero y un campo SigningPubKey vacío; asimismo, los puntos de entrada P2P rechazan esas operaciones y aplican un cargo moderado de recursos a los pares que las envían.

Una inconsistencia menor aparecía en NetworkOPs.cpp, donde el rechazo de tfInnerBatchTxn dependía de que estuviera activa la enmienda featureBatchV1_1. Aunque otras validaciones ya impedían procesar esas transacciones cuando la enmienda estaba inactiva, la corrección hizo que ambos puntos de entrada las rechacen de forma incondicional, en línea con el comportamiento de PeerImp.

Finalmente, la auditoría examinó la integración con LoanSet, que normalmente exige una firma de la contraparte. Para las transacciones internas de batch, ese requisito se omite y la autorización debe llegar mediante un firmante de batch, mientras el campo sfCounterparty sigue siendo obligatorio; los investigadores no identificaron problemas adicionales en esa integración.

Estado de BatchV1_1

El reporte de vulnerabilidad del XRP Ledger señala que la corrección de reemplazo, denominada BatchV1_1, fue implementada y se encuentra actualmente bajo revisión. Hasta el 1 de septiembre de 2026 no se había establecido una fecha de lanzamiento, por lo que los hallazgos y sus correcciones no deben presentarse como una actualización ya activada en la red.

En ese contexto, el movimiento del proyecto hacia BatchV1_1 constituye una respuesta técnica a los problemas identificados en la auditoría. No hay evidencia en el material disponible para atribuir cambios de precio de XRP a este proceso.

El informe concluye que los principales riesgos estaban en el diseño de las firmas y en la serialización de los firmantes, no en la lógica de ejecución ni en la construcción determinista del ledger. Las correcciones reportadas buscan impedir la reproducción contextual, bloquear la reutilización de firmas y establecer una forma canónica de representar los batches, mientras que la optimización del caché queda pendiente de una eventual evaluación de rendimiento.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.

ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín