Microsoft ha suspendido la cuenta de GitHub del investigador de seguridad Nightmare-Eclipse, quien publicó varios exploits de día cero para Windows. El experto afirma que la empresa ignoró sus reportes y no pagó las recompensas correspondientes, calificando la acción como vindictiva. Ante esto, el investigador ha amenazado con publicar más vulnerabilidades en represalia. 

Ha habido cierto drama desarrollándose últimamente en el mundo de la seguridad de Windows, y el episodio de hoy proviene de otro aparente enfrentamiento del investigador Nightmare-Eclipse (también conocido como Chaotic Eclipse) contra Microsoft. La empresa consideró oportuno banear la cuenta de GitHub de Eclipse por razones aún no especificadas, obligándole a trasladar su actividad a GitLab. Además, se alega que la firma de Redmond ya había eliminado la cuenta de Microsoft que Eclipse utilizaba para informar sobre los errores.

En una publicación de blog en este enlace, Eclipse afirma que esta acción fue vindicativa, declarando una vez más que Microsoft rechazó los intentos de comunicación y que "no recibieron ni un centavo por hacerlo", una probable alusión a recompensas por errores no pagadas del programa MSRC. La iniciativa paga entre 30.000 y 100.000 dólares por cada zero-day de punto final dependiendo de las condiciones, y unos considerables 250.000 dólares si se logra vulnerar Hyper-V. Teniendo ya seis exploits zero-day a su favor, Eclipse afirma que el 14 de julio traerá una especie de ajuste de cuentas para la empresa, hipotéticamente en forma de publicación de más exploits zero-day.

La dramática disputa de Eclipse con Microsoft ha estado activa desde principios de abril, cuando publicaron el zero-day BlueHammer sin previo aviso. El lenguaje en sus publicaciones de blog aquí es confuso y apasionado, dirigiendo una lluvia de vitriolo hacia Microsoft/MSRC. Como resumen general, Eclipse insinúa que Microsoft ignoró o rechazó sus informes de zero-day y/o no pagó las recompensas solicitadas, causando de algún modo un daño financiero en el proceso. Entre otras declaraciones, Eclipse dice que "[le] dijeron personalmente [en Microsoft] que arruinarían su vida y lo hicieron", que existe una especie de interruptor de hombre muerto y que "se asegurará de que los huesos [de Microsoft] queden destrozados".



La saga ha despertado especulaciones de otros expertos, como William Dormann de Tharros, quien dijo en este artículo que "MSRC solía ser excelente para trabajar. Pero para ahorrar dinero, Microsoft despidió a la gente capacitada, dejando a seguidores de diagramas de flujo. No me sorprendería que Microsoft cerrara el caso después de que el informante se negara a enviar un video del exploit, ya que aparentemente eso es ahora un requisito de MSRC".

Microsoft ha guardado silencio sobre los detalles de estos asuntos, por lo que es difícil saber si la situación se trata de un investigador poco cooperativo que no sigue las reglas estándar de divulgación o de una empresa que pone dificultades con los informes de seguridad. Independientemente de ello, la medida de banear la cuenta de GitHub de Eclipse ofrece una mala imagen, ya que está siendo duramente criticada y, en última instancia, no logra nada para la seguridad, ya que el código ya está disponible.

En la era actual, donde la investigación de seguridad impulsada por la IA ha hecho que la ventana estándar de 90 días entre la divulgación y el parche sea completamente obsoleta, y tanto el tiempo hasta el exploit como los exploits no utilizados se acercan a cero, Microsoft y otros actores de software harían bien en ajustar sus políticas.

El historial técnico de Eclipse es impresionante. Publicaron una serie de exploits zero-day para Windows: BlueHammer (enlace) obtiene acceso al usuario SYSTEM vía Defender, y RedSun (enlace) hace lo mismo; UnDefend (enlace) desactiva Defender; GreenPlasma (enlace) obtiene acceso SYSTEM vía el servicio CTFMon, mientras que MiniPlasma (enlace) concede un acceso similar a través de un fallo en el controlador Windows Cloud Filter. Finalmente, está YellowKey, una vulnerabilidad en BitLocker que permite a un atacante abrir unidades cifradas con casi ningún esfuerzo, precisamente la acción que la tecnología debía prevenir.


Fuente:
TomsHardware