Hechos clave:
-
Una tarifa baja puede evitar que una transacciĆ³n de compromiso se confirme antes a tiempo.
-
Los desarrolladores reevalĆŗan la propuesta de canales de anclaje para combatir el problema.
La red de canales de pago en Bitcoin, Lightning Network (LN), ha estado en desarrollo durante varios aƱos y como parte de ello, se siguen encontrando ciertas debilidades que exponen la seguridad de sus usuarios y sus fondos. Una reciente discusiĆ³n entre desarrolladores alerta sobre una nueva vulnerabilidad que le permitirĆa a un atacante robar fondos aprovechando la funciĆ³n āreemplazo por comisiĆ³nā (RBF), con la cual es posible sustituir una transacciĆ³n no confirmada por una versiĆ³n diferente con una tarifa mĆ”s elevada.
Los canales de anclaje que se encuentran en fase experimental, es un mecanismo de seguridad para confirmar transacciones de compromiso. Cada vez que el saldo cambia en un canal LN, los participantes crean y firman una transacciĆ³n de compromiso. La transacciĆ³n solo se transmite si una de las partes decide cerrar el canal unilateralmente āpor ejemplo, porque la otra parte no respondeā.
Debido a que la transmisiĆ³n de la transacciĆ³n por compromiso puede ocurrir mucho tiempo despuĆ©s de su creaciĆ³n, los usuarios pueden pagar demasiado o muy poco en tarifas de transacciĆ³n. Pagar una tarifa demasiado baja puede evitar que la transacciĆ³n de compromiso se confirme antes de que caduquen los bloqueos de tiempo contenidos en ella, lo que permite el robo de fondos.
El desarrollador Jimmy Song, publicĆ³ un artĆculo el 27 de abril, en el cual comenta sobre la importancia de defenderse de todos los ataques posibles. Entre las vulnerabilidades que estĆ”n consumiendo las neuronas de los desarrolladores, Song destaca la deĀ Lightning y RBF Pinning que ya ha exigido una extensa discusiĆ³n en la lista de correo de desarrolladores de bitcoin.
Ā«Esencialmente, es poco probable que se explote la vulnerabilidad a travĆ©s del Reemplazo por comisiĆ³n que permite a cualquiera de las partes usar Ā«El NiƱo Paga por el PadreĀ» (CPFP). El Ā«RBF carveoutĀ», o la transacciĆ³n CPFP, puede ser usada en conjunto con un minero para potencialmente robar algunos fondosĀ», agrega el desarrollador, quien tambiĆ©n seƱala que cuando se trata de seguridad nada puede parecer paranoico, porque quien ha trabajado con la seguridad sabe que todos estamos a una vulnerabilidad de que ocurran cosas realmente malas.
ĀæCĆ³mo sucede el ataque?
En su publicaciĆ³n, Song expone una serie de mejoras en las que trabajan los desarrolladores con el objetivo de mejorar aĆŗn mĆ”s el sistema. Para comprender mejor en quĆ© consiste la vulnerabilidadĀ Lightning – RBF Pinning, CriptoNoticias consultĆ³ la opiniĆ³n de un experto, se trata del desarrollador Sergi Delgado, quien explicĆ³: āSupongamos un escenario de Lightning Network con 3 nodos: A, B, y C, y un contrato de tiempo de hash bloqueado (HTLC), el cual ha sido ofrecido por A a C a travĆ©s de Bā.
Un contrato de tiempo de hash bloqueado o HTLC es un mĆ©todo de pago que bloquea los fondos a la espera que el receptor reconozca haber recibido la transferencia antes de la fecha lĆmite. El concepto es bastante simple y sirve como una forma de extender los canales de pago mĆ”s allĆ” de un estado bidireccional.
Todo comienza de manera normal cuando Alice ā el remitenteā decide enviar un pago a Carlos ābeneficiarioā a travĆ©s de Bob āintermediarioā. Para evitar que sus fondos se vean comprometidos, Alice asegura su transacciĆ³n utilizando un contrato HTLC. Carlos, con mala intenciĆ³n entre manos, gastarĆa el pago HTLC utilizando la preimagen; creando una nueva versiĆ³n de la transacciĆ³n (RBF) con baja comisiĆ³n, pero lo suficientemente alta como para que entre en la mempool sin que sea confirmada. Bob, no se da cuenta que el HTLC ya ha sido gastado, por lo que intentarĆ” reclamarlo cuando este expire, pero su transacciĆ³n no serĆ” aceptada porque se encuentra en conflicto con la nueva versiĆ³n que Carlos introdujo previamente.
Debido a que los nodos LN no monitorizan la mempool, Bob no se entera de que su transacciĆ³n estĆ” en conflicto con la transacciĆ³n enviada por Carlos, por lo que no podrĆ” utilizar la preimagen para invalidarla. DespuĆ©s de unos bloques, Alice podrĆ” reclamar su HTLC por expiraciĆ³n, haciendo que Bob pierda el dinero ofrecido por ese pago.
Monitorizar la mempool no tiene por quĆ© ayudar a solucionar el problema. A diferencia de la blockchain, la mempool no estĆ” consensuada por los nodos de la red, lo que hace que pueda haber diferentes versiones de una misma transacciĆ³n. Esto hace que el atacante pueda enviar versiones diferentes de las transacciones a la mempool del nodo atacado, y al resto de la red, haciendo que la soluciĆ³n no sea efectiva.
Sergi Delgado, desarrollador.
El desarrollador agrega que la vulnerabilidad de Lightning Network tiene su origen en la nueva propuesta de canales de anclaje, ya que permite reemplazar una transacciĆ³n por comisiĆ³n, lo cual posibilita que las transacciones no confirmadas permanezcan mĆ”s tiempo en la mempool.
āEsto hace que, por ejemplo, un nodo malicioso pueda aƱadir una segunda transacciĆ³n gastando de la primera, asegurĆ”ndose de que esta no serĆ” confirmada āde nuevo dado que la segunda transacciĆ³n tiene fees aceptables, pero el paquete de la transacciĆ³n A + B, no las tieneā, ademĆ”s que reemplazar estas transacciones para evitar el ataque, puede costar mĆ”s que el valor que se gana con ellasā, explicĆ³ Delgado.
No es una falla fƔcil de explotar
Sergi Delgado coincide con Jimmy Song cuando comenta que este tipo de ataques es poco probable, pero tambiĆ©n estĆ” de acuerdo en que ello no significa que hay que bajar la guardia. Ā«Con el estado actual de LN, la probabilidad de que se explote esta vulnerabilidad es baja, porque implicarĆa hacer una predicciĆ³n muy exacta de las comisiones de la transacciĆ³n para conseguir que esta sea propagada, pero no confirmada y tampoco eliminada de la mempool por tener tarifas muy bajasĀ», apunta.
Con respecto a las soluciones que se estĆ”n planteando para mitigar la vulnerabilidad, Delgado agrega: Ā«Respecto al modelo actual, no hay ninguna soluciĆ³n fĆ”cil de aplicar, de lo contrario ya se habrĆa aplicado anteriormente. Con respecto a anchor outputs, se estĆ” considerando reestudiar la propuesta para intentar prevenir este tipo de ataquesĀ».
TambiĆ©n es conveniente tener presente que Lightning Network tiene otra vulnerabilidad, la cual estĆ” vinculada a ataques de sobrecarga de transacciones o congestiĆ³n de canales. En marzo, CriptoNoticias informĆ³ que dos investigadores de la Universidad de JerusalĆ©n publicaron un reporte sobre la capacidad que tienen estos ataques de detener el funcionamiento de ambas redes.
