Litecoin afirma que la reorganización de 13 bloques no fue un ataque de 'día cero', pero el historial de commits en GitHub muestra lo contrario

La fundación de Litecoin calificó la explotación del fin de semana como un zero-day. El repositorio de litecoin-project en GitHub muestra que la vulnerabilidad en el consenso fue parcheada de manera privada entre el 19 y el 26 de marzo, más de cuatro semanas antes del ataque.

Physical representation of Litecoin tokens.
Resumen
  • Los atacantes explotaron una vulnerabilidad previamente corregida pero no completamente desplegada en el protocolo Mimblewimble Extension Block de Litecoin, provocando una reorganización de la cadena de 13 bloques que retrocedió aproximadamente 32 minutos de actividad.
  • Los commits públicos en GitHub muestran que el error principal del consenso fue corregido de forma privada semanas antes del exploit, creando una ventana en la cual algunos pools de minería ejecutaron código actualizado mientras otros permanecían vulnerables, una brecha que, según los investigadores, los atacantes parecían aprovechar.
  • La red de Litecoin finalmente se reorganizó de nuevo a la cadena válida una vez que cesaron los ataques de denegación de servicio a los mineros parcheados, pero la fundación aún no ha explicado el cronograma del parche ni ha revelado cuánto LTC se vio afectado durante la ventana de bloques inválidos.

Una reorganización de cadena de 13 bloques en Litecoin el viernes por la noche y el sábado retrocedió aproximadamente 32 minutos de actividad en la red después de que atacantes aprovecharan una vulnerabilidad en su protocolo Mimblewimble Extension Block (MWEB).

El error había permitido un ataque de denegación de servicio contra las principales piscinas de minería, permitiendo que las transacciones MWEB inválidas pasaran inadvertidas por nodos que no se habían actualizado, antes de que la cadena válida más larga de la red las corrigiera.

La Fundación informó en las horas de la mañana asiática del domingo que el error fue completamente corregido y la red está operando con normalidad.

Sin embargo, destacados investigadores afirman que el repositorio de GitHub del proyecto litecoin cuenta una historia diferente. El investigador de seguridad bbsz, quien trabaja con el grupo de respuesta ante emergencias SEAL911 para exploitaciones en criptomonedas, publicó la línea de tiempo de los parches extraída del registro público de commits.

La vulnerabilidad de consenso que permitió la desvinculación inválida de MWEB fue corregida de manera privada entre el 19 y el 26 de marzo, aproximadamente cuatro semanas antes del ataque. Una vulnerabilidad separada de denegación de servicio fue corregida en la mañana del 25 de abril.

Ambas correcciones se incorporaron en la versión 0.21.5.4 esa misma tarde, después de que el ataque ya había comenzado.

El análisis post-mortem indica que una vulnerabilidad zero-day provocó un DoS que permitió que una transacción MWEB inválida se filtrara," escribió bbsz. "El registro de git narra una historia ligeramente diferente.

Una vulnerabilidad de día cero se refiere a una falla desconocida para los defensores en el momento de un ataque.

El historial de commits de Litecoin muestra que la vulnerabilidad de consenso era conocida y fue parchada de forma privada un mes antes del exploit, pero la solución no había sido difundida públicamente ni requerida para todos los pools de minería.

Eso creó una ventana en la que algunos mineros ejecutaban el código corregido mientras que otros utilizaban la versión aún vulnerable, y parece que los atacantes sabían cuál era cuál.

Alex Shevchenko, CTO del proyecto Aurora de la Fundación NEAR, recaudó preocupaciones paralelas en un hilo.

Los datos de la blockchain mostraron que el atacante prefinanció una cartera 38 horas antes de la explotación mediante un retiro de Binance, con la dirección de destino ya configurada para intercambiar LTC por ETH en un exchange descentralizado.

El ataque de denegación de servicio y el error MWEB fueron componentes separados, argumentó Shevchenko, siendo el DoS diseñado para desconectar los nodos mineros parcheados, de modo que los no parcheados formaran la cadena que incluía las transacciones inválidas.

El hecho de que la red haya gestionado automáticamente la reorganización de 13 bloques una vez que el ataque DoS cesó sugiere que una cantidad suficiente de hashrate estaba usando código actualizado para eventualmente superar el ataque, pero solo después de que la bifurcación sin parche estuviera operativa durante 32 minutos.

Un ataque a Litecoin muestra cómo difieren los ataques en diversas redes en la forma en que los mantenedores del código y los desarrolladores reaccionan ante las explotaciones. Las cadenas más recientes, con conjuntos de validadores más pequeños y centralizados, coordinan las actualizaciones a través de grupos de chat y pueden implementar parches en toda la red en cuestión de horas.

Las redes de prueba de trabajo más antiguas, como Litecoin y bitcoin, dependen de que los grupos de minería independientes decidan cuándo actualizarse, lo cual funciona para cambios no urgentes pero crea una ventana de vulnerabilidad cuando un parche de seguridad necesita llegar a todos antes de que un atacante explote la brecha.

La Fundación Litecoin no ha abordado públicamente la línea de tiempo de GitHub hasta la mañana del domingo.

No se ha divulgado la cantidad de LTC liberada durante la ventana de bloques inválidos ni el valor de cualquier intercambio completado antes de que la reorganización los revirtiera.

Activos relacionados