El último análisis de vulnerabilidad de Lightning Network: solo es necesario atacar 85 nodos para robar los fondos del canal de nodos Lightning

Aviv Zohar, profesor asociado de la Escuela de Ingeniería y Ciencias de la Computación de la Universidad Hebrea, la institución más importante de Israel, y Jona Harris, estudiante de posgrado de la Universidad Hebrea, publicaron recientemente un artículo de investigación "Inundaciones y saqueos: un ataque sistemático en la Red Lightning". Se propone un ataque sistemático a Lightning Network. El atacante puede robar los fondos bloqueados en el canal de pago a través de un ataque sistemático a Lightning Network. En este ataque, el atacante obliga a una gran cantidad de víctimas a exigir fondos de la cadena de bloques, y luego puede usar la congestión para robar fondos que no fueron reclamados antes de la fecha límite. El documento demuestra que solo se necesitan 85 canales atacados simultáneamente para garantizar que un atacante pueda robar algunos fondos. Además, el artículo propone varias técnicas de mitigación frente a este ataque. Se sabe que la red de canales de pago de Lightning Network es vulnerable a la congestión de la cadena de bloques, y si la red es atacada, es posible que los participantes no puedan retirar fondos de manera oportuna. En nuestro último artículo, evaluamos uno de esos ataques: un ataque sistemático a Lightning Network que puede robar fondos bloqueados en los canales de pago. En este ataque, el atacante obligó inmediatamente a muchas víctimas a acudir en masa a la cadena de bloques, exigiendo sus fondos. Los atacantes pueden usar la congestión que han creado para robar todos los fondos que no hayan sido reclamados antes de la fecha límite. Las consecuencias de un ataque dependen de la implementación de Lightning Network que elija atacar el atacante. Demostramos que un atacante solo necesita atacar 85 canales simultáneamente para robar fondos dentro de los canales (esto supone que ninguna otra transacción de blockchain compite por espacio de bloque, lo cual es una suposición muy optimista). Además de entender este ataque y sus consecuencias en general, en este artículo proponemos varias técnicas para mitigar este ataque. Nota: El ataque puede permitir que se roben los fondos de usuarios inocentes. No intentes este ataque en casa. Desafortunadamente, actualmente no hay ningún cambio de protocolo que lo elimine por completo. Los hallazgos de este documento se compartieron con los desarrolladores de las tres principales implementaciones de clientes de Lightning Network antes de su publicación. El ataque aprovecha un mecanismo para reenviar pagos a través de múltiples canales Lightning: contratos de bloqueo de tiempo hash (HTLC). En resumen, los HTLC permiten a los participantes enrutar los pagos a través de nodos intermediarios sin confianza, lo que garantiza que ninguno de ellos pueda robar fondos. Si dicho nodo intenta robar fondos, sus pares pueden reclamar los fondos publicando una transacción en la cadena de bloques, pero solo por un tiempo limitado. Como hemos demostrado en nuestro trabajo, es relativamente fácil inundar una cadena de bloques con nodos Lightning inocentes y explotar este límite de tiempo para robar fondos. La idea clave detrás de HTLC es que, después de que se establece un HTLC, el nodo de destino "arranca" un pago del nodo anterior en la ruta al proporcionar un secreto (una preimagen hash). El atacante enrutará el pago entre dos de sus propios nodos y retirará el pago al final de la ruta. Cuando finalmente se retire el pago del nodo de origen, se negará a cooperar, lo que obligará a la víctima a reclamarlo a través de una transacción de cadena de bloques. Este ejemplo de topología muestra el nodo del atacante y el canal que comparte con la víctima. El ataque se divide en cuatro fases principales: El atacante controla dos nodos Lightning, que representan los nodos de origen y de destino. El nodo de origen abre canales a muchas víctimas potenciales, posiblemente múltiples canales para cada víctima. Estos canales son iniciados y financiados por el nodo de origen del atacante (el nodo de destino puede estar lejos de la víctima, pero en el siguiente diagrama simplificamos el proceso y mostramos solo una ruta corta y simple). Fase 1: Establecimiento del canal Después de configurar todos los canales, el nodo de origen comenzará a realizar muchos pagos HTLC al nodo de destino, enrutados a través del canal de cada nodo de origen. El nodo de origen envía la cantidad máxima permitida para ser retransmitida y la distribuye entre tantos pagos como permita la víctima. Como parte del mecanismo HTLC, el nodo de destino debe aceptar el pago devolviendo un conjunto de secretos HTLC. Este ataque evitará hacerlo hasta que el nodo de origen haya terminado de reenviar todos los pagos. Fase 2: carga de canales con pagos HTLC Después de completar con éxito el envío de todos los pagos y agregar HTLC al canal del nodo de destino, el nodo de destino resolverá todos los pagos devolviendo el secreto requerido y reclamará estos fondos para sí mismo. En este punto, el nodo de destino puede cerrar su canal normalmente y quedarse con los fondos enviados por el nodo de origen. Una vez que cada víctima ha adquirido estos secretos, los envía de regreso al nodo de origen, solicitando analizar el HTLC y mover su cantidad al lado de la víctima del canal. El nodo de origen se niega a analizar el pago e ignora cualquier otro mensaje de su víctima. Fase 3: Analizar el pago en el último salto En este punto, cada canal atacado está lleno de HTLC aún por analizar, cuyos secretos conoce la víctima. Dado que el nodo de origen del atacante no coopera, la única forma en que la víctima puede acceder a estos pagos es cerrar su canal y reclamar el HTLC en la cadena de bloques. La víctima tiene un tiempo limitado (en bloques) para reclamar el pago (o un límite de tiempo si el nodo no conoce estos secretos, en cuyo caso los fondos deben ser reclamados por el nodo de origen). Una vez que caducan, el atacante puede gastar la salida del HTLC. Aunque las víctimas aún pueden reclamar los HTLC después del vencimiento, los detalles específicos del protocolo brindan a los atacantes una ventaja significativa: las víctimas no pueden establecer tarifas de transacción cuando publican transacciones. La tarifa se determina cuando se abre el canal. El atacante puede establecer la tarifa para su propia transacción como lo desee, y reemplazar cualquier transacción de la víctima que no haya sido confirmada después del vencimiento (usando la estrategia "Reemplazar por tarifa") por atacando múltiples canales y obligando a todos los canales a cerrarse al mismo tiempo (establecer el mismo tiempo de caducidad para todos los HTLC), las transacciones de propiedad de reclamación de HTLC de algunas víctimas no se confirmarán a tiempo y el atacante las robará. Por lo tanto, el atacante se queda con algunos fondos que deberían haber ido a parar a la víctima (los fondos del siguiente salto de la víctima se enviaron al nodo de destino del atacante). Fase 4: Recopilación de salidas no gastadas después del vencimiento Para mostrar la viabilidad del ataque, realizamos una simulación en Lightning Network local en el registro de red de prueba de Bitcoin. Implementamos un prototipo de un nodo atacante capaz de bloquear la transmisión de secretos de HTLC, ignorar solicitudes para analizar HTLC y emitir transacciones de propiedad de reclamo de HTLC con tarifas más altas. Dado que LND es la implementación Lightning más popular en la actualidad (se informa que más del 90 % de los nodos Lightning en la red ejecutan LND), lo usamos para simular nodos víctimas. Como se muestra en la figura a continuación, atacar 85 canales asegura un ataque exitoso incluso si todo el espacio disponible en el bloque (tamaño máximo del bloque) se asigna a la transacción de la víctima. Cada vez que se agrega un canal, también se robarán todos sus fondos. El número de HTLC robados con éxito para diferentes números de canales atacados y tamaños de bloque. El tamaño de bloque máximo actual de Bitcoin es 4M (correspondiente a la línea verde). De hecho, las Transacciones Lightning tienen menos de todo el espacio disponible. Como se muestra, cuando el espacio disponible en cada bloque disminuye, se necesitan menos víctimas para robar la misma cantidad de HTLC. Demostramos que este puede ser el caso cuando el atacante utiliza la estrategia de "minimización conjunta" (descrita a continuación). El número de HTLC robados con éxito para diferentes números de canales atacados y tamaños de bloque. El peso de bloque máximo actual de Bitcoin es 4M (correspondiente a la línea verde). De hecho, las transacciones Lightning tienen menos espacio libre que todos los gráficos y, a medida que disminuye el espacio libre en cada bloque, se necesitan menos víctimas para robar la misma cantidad de HTLC. Demostramos que este puede ser el caso cuando el atacante utiliza la estrategia de "minimización de feerate" (descrita a continuación). La tarifa pagada por cada transacción de la víctima proviene del parámetro Feerate del canal. Esta tarifa la determina y paga el iniciador del canal (en nuestro caso, el nodo de origen del atacante). Antes de abrir un canal, otro nodo debe aceptar el avance establecido por el canal. Si el nodo cumple con su estimación de la tarifa de blockchain, el nodo acepta establecer una tarifa, determinada por el método de estimación de bitcoind. Como se puede ver en la figura siguiente, el valor estimado de la velocidad de avance puede fluctuar mucho en un período de tiempo relativamente corto. Cuando el canal se cierra unilateralmente, es posible que una tarifa de canal determinada en un momento dado no se aplique en un momento posterior. Tasa de tarifa estimada por Bitcoind para confirmación inmediata (Satoshi/byte) Además de establecer la tasa de tarifa inicial del canal, el iniciador del canal también puede proponer una nueva tarifa de tarifa en cualquier momento después de que se abra el canal para ajustarla al estado actual de la tarifa de cadena del bloque . El protocolo Lightning establece que, en nuestro caso, la otra parte (es decir, la víctima) no puede realizar ninguna solicitud de actualización de la tasa de avance. En la estrategia de "minimización de tasa de tarifa", el atacante utiliza el mecanismo de actualización de tarifas para reducir la tarifa de tarifa del canal cuando sea posible (es decir, cuando la tarifa de blockchain es baja (para que la otra parte acepte el cambio)), pero desde las actualizaciones se realizan cuando las tarifas de blockchain son altas. Una vez que la diferencia entre la tasa de tarifa del canal y la tasa de tarifa real de la cadena de bloques se vuelve grande, un atacante puede comenzar a iniciar todos los pagos de HTLC y lanzar un ataque. En el siguiente gráfico, vemos el espacio de bloque promedio disponible para la víctima cuando el atacante usó la estrategia de minimización de la velocidad de transmisión durante 3 y 7 días. Por ejemplo, cuando el atacante trató de minimizar las tarifas 7 días antes de comenzar el ataque, la víctima tuvo acceso a un promedio de la mitad del espacio del bloque solo el 58% del tiempo o más (durante un período de recopilación de datos de 2 meses) cuando Espacio de bloque promedio disponible para las transacciones de las víctimas cuando se utiliza la estrategia de "minimización de la tarifa". En este trabajo, también mostramos que encontrar víctimas potenciales no es una gran cantidad de trabajo para el atacante. Para que un nodo sea víctima de un ataque, el nodo solo necesita aceptar una solicitud para abrir un canal con el atacante. Como se describe en el protocolo Lightning, un nodo puede indicar su voluntad de abrir un canal respondiendo al mensaje "accept_channel" y no necesita abrir el canal en este momento. Realizamos un experimento en el que se probó la disposición de muchos nodos de la red para abrir un canal con un nodo desconocido. Descubrimos que la gran mayoría de los nodos activos (~95 %) están dispuestos a abrir canales en esta solicitud y, por lo tanto, son víctimas fáciles de este ataque. Respuesta del nodo a la solicitud "open_channel" Para este tipo de ataque, varias técnicas pueden hacer que sea más difícil para el atacante y reducir el daño potencial del ataque. A continuación se presentan algunas de las técnicas de mitigación que proponemos. 1) Reducir la cantidad máxima de HTLC sin resolver: la cantidad máxima de pagos que un atacante puede enrutar a través del canal atacado está determinada por el parámetro del canal "max_accepted_htlcs". Si el valor de este parámetro se mantiene bajo, el atacante tendrá que atacar más canales para robar fondos con éxito. 2) Cierre anticipado del canal: el momento (bloque) en el que la víctima reclama sus fondos está determinado por un parámetro específico de la implementación. La mayoría de las implementaciones de Lightning usan valores mucho más pequeños de los que posiblemente podrían usar (para evitar cerrar canales prematuramente). Este parámetro puede incrementarse en un factor constante o incluso configurarse dinámicamente en función del estado actual del canal, por ejemplo, el número de HTLC sin resolver o el valor total sin resolver. 3) Liberación inmediata de la transacción de reclamo de propiedad de HTLC: algunas implementaciones esperan hasta que se confirme su compromiso publicado antes de liberar la transacción de HTLC para reclamar su salida. Los nodos pueden y deben liberar estas transacciones de inmediato con este compromiso para permitir bloques potenciales en los que pueden ingresar más transacciones. 4) Comportamiento basado en la reputación: los parámetros de un canal pueden afectar en gran medida la probabilidad de un ataque exitoso. Dependiendo de ciertas políticas, los nodos pueden usar más parámetros de permisos para canales con partes a las que se les ha asignado "buena reputación". Aunque existen diferentes mitigaciones que pueden reducir el riesgo de un ataque, eliminar completamente el riesgo parece ser una tarea compleja. Creemos que, en muchos aspectos, la vulnerabilidad explotada es inherente a la forma en que funcionan los HTLC y, por lo tanto, el ataque no se puede evitar por completo sin modificaciones significativas en el mecanismo HTLC

Tags：

DOT