A las 2:25 p. m. del 9 de diciembre de 2021, un tuit infame (ahora eliminado) que vinculaba un exploit de prueba de concepto de día cero para el vulnerabilidad que llegó a conocerse como Log4Shell en GitHub (también ahora eliminado) prendió fuego a Internet y envió a las empresas a luchar para mitigar, parchear y luego parchear algunos más a medida que aparecían más y más pruebas de concepto (PoC) en las diferentes iteraciones de esta vulnerabilidad, que estaba presente en bastante mucho todo lo que usaba Log4j.
Conocido como divulgación pública, el acto de decirle al mundo que algo es vulnerable con un PoC que lo acompaña no es nuevo y ocurre con bastante frecuencia para todo tipo de software, desde el más esotérico a lo mundano. Sin embargo, con el tiempo, la investigación y la experiencia nos han demostrado constantemente que el único beneficio de la publicación de PoC de día cero es para los actores de amenazas, ya que las divulgaciones de repente colocan a las empresas en una posición incómoda de tener que mitigar sin tener necesariamente algo con lo que mitigar. (es decir, un parche de proveedor).
¿Cómo funciona normalmente la divulgación?
Hay todo tipo de mecanismos de divulgación que existen hoy en día, ya sea que las empresas tengan un programa de divulgación de vulnerabilidades autorizado oficialmente (piense en Google y Microsoft) o aquellos que se ejecutan a través de plataformas colaborativas que a menudo se denominan bug bounties. Las divulgaciones en estos escenarios a menudo pasan por un proceso específico y tienen plazos adecuados en los que se publica el parche del proveedor y se les da suficiente tiempo para que los usuarios del software en cuestión lo acepten (90 días es el estándar aceptado aquí), así como el PoC se publica públicamente solo con la aprobación del proveedor (también conocido como divulgación coordinada). Las plataformas de recompensas por errores también aplican acuerdos de no divulgación a sus investigadores de seguridad además de esto, por lo que a menudo los PoC permanecen sellados, incluso si la vulnerabilidad se ha solucionado durante mucho tiempo.
Después de haber pasado por muchas divulgaciones, tanto a través del formato de vulnerabilidades y exposiciones comunes (CVE) o directamente a través de procesos de divulgación de vulnerabilidades, por lo general funciona así si todo transcurre sin problemas:
Volviendo a la vulnerabilidad de Log4j, en realidad ya había un proceso de divulgación en marcha, como lo muestra el solicitud de extracción en GitHub que apareció el 30 de noviembre. El cronograma real de la divulgación fue ligeramente diferente, como se muestra en un correo electrónico a BuscarSeguridad:
Si bien los comentarios en el hilo indican frustración con la velocidad de la corrección, esto es normal cuando se trata de corregir vulnerabilidades. Como todos señalan, el parche fue construido por voluntarios.
Razones para publicar PoC de día cero y pruebas en contra
En la superficie, puede parecer que hay razones legítimas para lanzar una prueba de concepto de día cero. Uno de los más comunes es que el proceso de divulgación de vulnerabilidades con el proveedor se haya interrumpido. Esto puede suceder por muchas razones, incluido un proveedor que no responde, que no considera que la vulnerabilidad sea lo suficientemente grave como para solucionarla, que tarda demasiado en solucionarla o alguna combinación. La postura entonces es lanzarlo por el bien común, que la evidencia ha demostrado que rara vez es por el bien de los usuarios del software.
También existen razones periféricas que son menos convincentes para publicar una PoC, a saber, la publicidad, especialmente si está vinculado a un proveedor de seguridad. Nada obtiene cobertura de prensa más rápido que una prueba de concepto para una pieza de software común que todos usan pero que aún no tiene un parche, y esto es, lamentablemente, un pilar de muchas investigaciones de seguridad en la actualidad.
La evidencia contra la publicación de un PoC ahora es sólida y abrumadora. Un estudio realizado por Kenna Security mostró efectivamente que el único beneficio de las vulnerabilidades de PoC era a los atacantes que los aprovecharon. Incluso hace varios años, una presentación en Black Hat, “Cero días y miles de noches”, recorrió el ciclo de vida de los días cero y cómo se lanzaron y explotaron. También mostró que si los exploits de PoC no se divulgaban públicamente, nadie los descubrió, en promedio, durante siete años, incluidos los actores de amenazas. Lamentablemente, esto se dio cuenta demasiado tarde durante la lucha de Log4j. Si bien todas las divulgaciones iniciales se retrocedieron y eliminaron rápidamente, incluso la divulgación más reciente 2.17.1 tuvo el mismo problema, recibió muchas críticas hasta el punto en que el investigador emitió un disculpa pública por el mal momento de la divulgación.
Es bueno ver que las actitudes hacia la divulgación pública de los exploits de PoC han cambiado, y las críticas de los investigadores que deciden apresurarse son merecidas. Pero colectivamente, parece que el trabajo debe centrarse en implementar procesos de divulgación más sólidos para todos, de modo que no caigamos en la trampa de repetir este escenario la próxima vez que surja una vulnerabilidad como esta.
- Coinsmart. El mejor intercambio de Bitcoin y criptografía de Europa.
- Platoblockchain. Inteligencia del Metaverso Web3. Conocimiento amplificado. ACCESO LIBRE.
- CriptoHawk. Radar de altcoins. Prueba gratis.
- Fuente: https://www.darkreading.com/attacks-breaches/log4j-proved-public-disclosure-still-helps-attackers
