Las versiones de Lightning Development Kit anteriores a v0.2.7 y v0.1.13 expusieron algunas aplicaciones de Bitcoin Lightning a un ataque de reconexión que podía convertir un pago reenviado en una pérdida. Un par de canal malicioso podía acusar recibo de una actualización, reconectarse y afirmar falsamente que nunca la había recibido. Antes del parche, LDK podía firmar una transacción de compromiso en conflicto sin registrarla en el monitor de canal.
Por qué importa
El ataque apuntaba al proceso de gestión de estado detrás de los canales Lightning. Tras la falsa reclamación de reconexión, el par malicioso podía confirmar la transacción en conflicto en la blockchain de Bitcoin y permitir que el pago se liquidara con el siguiente destinatario. Luego podía reclamar el contrato de pago entrante cuando expiraba, dejando a la aplicación de reenvío sin fondos aunque conocía el secreto de pago que normalmente se usa para reclamarlos.
El comportamiento parchado solo permite la retransmisión mientras el acuse de recibo del par siga sin resolverse. Si un par afirma que se perdió una actualización ya acusada, LDK ahora cierra forzosamente el canal.
Los desarrolladores de LDK también parchearon una ruta de robo independiente en v0.2.7 relacionada con los pagos justo a tiempo de LSPS2. Un pago interceptado podía declarar incorrectamente su importe, haciendo que un servicio de liquidez abriera un canal y reenviara más Bitcoin del que financiaba el pago entrante. Los desarrolladores también deben tener en cuenta los contratos de pago pendientes creados por versiones anteriores, ya que sus importes podrían no haber sido validados.
Impacto en el mercado
La exposición inmediata es operativa, no un fallo del protocolo de Bitcoin. LDK se compila en las aplicaciones que lo usan, por lo que los desarrolladores de monederos y pagos deben integrar el código de biblioteca parchado correspondiente en su software desplegado. La versión v0.2.7 aborda el problema de reconexión en la rama 0.2 y la comprobación de importe de LSPS2, mientras que v0.1.13 incluye el arreglo de reconexión compartido para la rama 0.1.
Los equipos que operan infraestructura Lightning deben revisar las versiones de LDK desplegadas, los canales abiertos y los contratos LSPS2 pendientes. Core Lightning es una implementación independiente y no es la biblioteca afectada en este informe.
Preguntas frecuentes
-
¿Qué vulnerabilidad de Lightning abordaron las versiones parchadas de LDK?
Un par de canal malicioso podía reconectarse y afirmar falsamente que se había perdido una actualización ya acusada. Antes del parche, LDK podía firmar una transacción de compromiso en conflicto que el monitor de canal no registraba.
-
¿Qué versiones de LDK corrigen la vulnerabilidad de reconexión?
LDK v0.2.7 corrige el problema en la rama 0.2, mientras que v0.1.13 incluye el arreglo de reconexión compartido para la rama 0.1.
-
¿Cómo podía el ataque de reconexión causar una pérdida de Bitcoin?
El atacante podía confirmar una transacción en conflicto en Bitcoin, dejar que el pago reenviado se liquidara con el siguiente destinatario y luego reclamar el contrato de pago entrante cuando expiraba.
-
¿Qué problema adicional aborda LDK v0.2.7?
La versión 0.2.7 también corrige un problema de pagos justo a tiempo de LSPS2 en el que un importe de pago declarado incorrectamente podía hacer que un servicio de liquidez reenviara más Bitcoin del que recibía.
-
¿Qué deberían hacer a continuación los desarrolladores de aplicaciones Lightning?
Los desarrolladores deben integrar el código de LDK parchado correspondiente en las aplicaciones desplegadas y revisar los contratos de pago LSPS2 pendientes creados por versiones anteriores para detectar importes no validados.