El incidente de Nightmare Eclipse muestra que es posible que las peleas entre investigadores y proveedores nunca desaparezcan por completo
Microsoft reabrió algunas heridas y ha reavivado el debate durante las últimas dos semanas sobre la divulgación de vulnerabilidades y la dinámica a veces conflictiva que crea entre investigadores y proveedores de seguridad.
La última controversia se produjo cuando Microsoft amenazó con emprender acciones legales penales contra un investigador de seguridad que reveló públicamente una serie de vulnerabilidades de día cero con exploits de prueba de concepto. microsoft insistió en que no recibió detalles sobre las vulnerabilidades antes del lanzamiento, y agregó que los defectos no fueron divulgados de manera responsable y pusieron a sus clientes en riesgos innecesarios.
La disputa pública entre Microsoft y el investigador conocido como “Eclipse de pesadilla«, que no pudo ser identificado ni contactado para hacer comentarios, provocó consternación entre algunos profesionales de la seguridad. La contundente respuesta de Microsoft y la reacción resultante revivieron un punto de fricción entre proveedores e investigadores que encuentran e informan fallas en el software que venden.
«La pelea se argumenta como una divulgación coordinada, pero la queja subyacente es personal y específica de una manera que la divulgación no debería serlo, especialmente con un proveedor que ha estado en esto durante tanto tiempo», dijo a CyberScoop Katie Moussouris, fundadora y directora ejecutiva de Luta Security.
«Microsoft pareció emocionarse y no debería haber dicho nada públicamente, pero de alguna manera se sintió justificado al llamar a un investigador e involucrar a las autoridades al mismo tiempo», dijo. «Eso los devuelve a las primeras etapas del duelo por la revelación de la vulnerabilidad: la negación y la ira».
El antiguo empleado de Microsoft que trabajó en contacto con la comunidad de seguridad, creó el primer programa de recompensas de la empresa y ha otorgado charlas en conferencias sobre el tema Ya en 2013, dijo que la compañía redobló su falta de responsabilidad en toda la saga.
Microsoft se negó a responder preguntas a raíz de las consecuencias.
Nightmare Eclipse insinuó una falla y una batalla inminente con el proveedor en una serie de publicaciones de blog previas a la misiva de Microsoft sobre las vulnerabilidades. rojosol, Desdefender, Martillo azul, llave amarillaGreenPlasma y MiniPlasma.
Los atacantes explotaron tres de las seis vulnerabilidades que Nightmare Eclipse lanzó antes de que Microsoft las parcheara.
El investigador afirmó que Microsoft se negó a comunicarse, no les pagó ni les dio crédito por descubrir e informar algunas de las vulnerabilidades, eliminó la cuenta del Centro de Respuesta de Seguridad de Microsoft que usaron para revelar las vulnerabilidades y marcó su cuenta de GitHub para su eliminación.
«Están demostrando a todos que están intensificando activamente este conflicto», escribieron, antes de amenazar a Microsoft con un comunicado a mediados de julio que «asegurará que sus huesos queden destrozados ese día».
La divulgación de vulnerabilidades es una vía de doble sentido
Las características de los procesos adecuados de divulgación de vulnerabilidades tienen matices y, a menudo, se enmarcan en los ojos del espectador.
Cualquier baile exitoso entre cazadores de insectos y vendedores se reduce a encontrarse a mitad de camino, dijo Andrew Morris, fundador y arquitecto jefe de GreyNoise.
Si bien los proveedores deben corregir los defectos del software y priorizar la seguridad, Morris señaló que la divulgación irresponsable de vulnerabilidades perjudica tanto a los respondedores de incidentes como a las víctimas potenciales.
«Personalmente, siento que este investigador está siendo extremadamente mezquino. Parece que tienen un interés especial», dijo.
«No puedes darle algo a alguien y decir que es por la bondad de tu corazón, y luego enojarte cuando no te pagan por ello».
Pero Morris también dejó claro que los proveedores tienen la responsabilidad de generar confianza entre los investigadores.
«Si realmente le importa ser el primero en enterarse de los errores en su software, no enterarse una vez que se ha producido un daño o una vez que alguien ha sido descubierto, entonces desea cultivar esa confianza con la comunidad de seguridad», dijo Morris.
Microsoft dijo que reconoce que la relación entre los investigadores de seguridad y los proveedores es crítica y, en ocasiones, frágil.
«Valoramos profundamente a la comunidad de seguridad y continuaremos tomando en serio sus comentarios», dijo la compañía en su publicación. en X.
Sin embargo, la compañía se mantiene firme en oponerse a las circunstancias de las revelaciones de Nightmare Eclipse, describiendo sus acciones como ilegales, injustificables e irresponsables.
«Cuando un individuo infringe la ley y participa en actividades maliciosas que causan un daño real a nuestros clientes, trabajaremos con las autoridades según corresponda», dijo Microsoft sin nombrar al investigador por su apodo. «Seguimos creyendo firmemente en la divulgación coordinada de vulnerabilidades como base para proteger a los clientes y mejorar nuestros productos. Sabemos que, dada la naturaleza de este trabajo, en ocasiones habrá malentendidos. Seguimos comprometidos a participar de buena fe y a brindar una experiencia respetuosa y profesional para todos los investigadores, independientemente de interacciones pasadas».
El costo del retroceso
Los investigadores de seguridad buscan defectos por varias razones: pagos de recompensas, reconocimiento, credibilidad de la industria o simplemente la emoción de la búsqueda que conlleva encontrar vulnerabilidades y solucionarlas.
En el mejor de los casos, este proceso ocurre entre bastidores, con parches publicados y advertidos a los clientes antes de que ocurra la explotación.
Este enfoque colaborativo ha arraigado y mejorado considerablemente, pero todavía hay casos en los que los investigadores se sienten despreciados.
“El público no tiene idea de lo que sucedió detrás de escena para juzgar por qué un investigador que previamente coordinaba finalmente se cansó y decidió abandonar un día cero. [vulnerability]», dijo Moussouris. Como tal, está menos inclinada a criticar las acciones de Nightmare Eclipse, y agrega que «parecen ser alguien que necesita ayuda».
Sin embargo, la confianza entre los investigadores y los proveedores de vulnerabilidades se rompe a menudo. A principios de esta semana, el investigador de seguridad Ammar Askar afirmó que su última interacción con el equipo de seguridad de Microsoft fue tan pobre que decidió revelar públicamente cualquier error que encuentre en VS Code en el futuro. Cumplió esa amenaza al dejando caer una vulnerabilidad y explotar el código para un defecto que permite a los atacantes robar tokens de GitHub.
Si bien acciones como esta pueden sabotear la confianza y abrir una brecha entre los proveedores y los investigadores de vulnerabilidades, el recurso es en gran medida limitado. Moussouris dijo que la mayoría de las veces los límites legales y éticos son claros para los involucrados. Los investigadores pueden informar errores, retenerlos, venderlos o publicarlos. «La única línea roja es el crimen: usar un defecto para extorsionar o atacar a la gente», dijo Moussouris.
«Amenazar con publicar en una fecha determinada es una amenaza con divulgar, y la divulgación es legal. El tono puede resultar feo. [Nightmare Eclipse] todavía no violó ninguna regla ni violó ningún deber”.
El momento no podría ser peor
Ambas partes son en parte responsables de lo sucedido, pero Microsoft empeoró las cosas, afirmó Morris. Amenazar con acciones legales y adoptar un enfoque agresivo nunca ha funcionado. Construir una buena relación entre investigadores y proveedores requiere comunicación abierta y confianza.
«Pensé que ya habíamos superado esto. Resulta que no», dijo.
El incidente de Nightmare Eclipse llega en un momento tenso en este espacio. Los proveedores y sus clientes se enfrentan a una avalancha de más vulnerabilidades, y el aumento de modelos de inteligencia artificial que las descubren está exacerbando este desafío, dejando a los expertos en seguridad alarmados por lo que se avecina.
Las perspectivas sobre dónde se descubrirán y explotarán las vulnerabilidades a continuación, y con qué impacto, son desconocidas y tremendamente inquietantes.
Estas señales implican que el sistema clásico basado en CVE con procesos divulgados responsablemente probablemente esté roto, dijo Morris. «Hay tantos CVE. Es como si esto ¿ya funciona?».
Por ahora, y a pesar de todos sus defectos, los programas coordinados de divulgación de vulnerabilidades se consideran ampliamente como el enfoque más sensato y escalable para este dilema.
«La divulgación coordinada es lo que sucede cuando un proveedor tiene suerte. Alguien a quien no contrató le entrega un error real en lugar de usarlo o venderlo. Eso pone toda la carga de mantener viva la coordinación en el proveedor», dijo Moussouris. «La aplicación de parches silenciosos sin CVE y la llamada a los investigadores que no siguen su cronograma de divulgación desperdician la suerte del proveedor».
Hizo hincapié en lo que está en juego: «Espero que Microsoft y todos los proveedores aprendan que la divulgación coordinada de vulnerabilidades es un regalo y una gracia de la comunidad de investigadores de seguridad para ellos, y la divulgación pública sigue siendo mejor que la no divulgación o el delito».
Las alternativas a una relación en deterioro podrían causar estragos y dejar a todos los proveedores y clientes más susceptibles a los ataques.
«Si los proveedores desaprenden cómo recibir propiedad intelectual y mano de obra gratuita de la comunidad de seguridad en forma de informes de vulnerabilidad con gratitud, nos dirigimos a un mundo donde nadie se molesta en avisar a los proveedores, o se mueven hacia un modelo de divulgación cronometrada que no da ninguna gracia», dijo Moussouris.
Concluyó con un mensaje directo: «Los proveedores de productos escribieron el código vulnerable, son dueños del riesgo y deben hacer todo lo que esté a su alcance para con sus usuarios para reducir ese riesgo». Eso incluye “guardar sus quejas para sí mismos y aprender de la introspección sobre la divulgación coordinada de vulnerabilidades que salieron mal”.
