Llegamos a ustedes gracias a:



Alertas de Seguridad

Priorizar y remediar las vulnerabilidades a raíz de Log4J

Y el error del martes de parches de Microsoft

[25/01/2022] Las últimas semanas han dejado a los profesionales de TI abrumados, ya que las organizaciones se apresuraron a evaluar si eran vulnerables a las amenazas planteadas por la vulnerabilidad Log4Shell. Como si eso no fuera suficiente desafío durante, le siguieron más CVEs de Log4j, no todas las cuales merecen la misma atención.

Y las fallas del martes de parches de enero de Microsoft causaron aún más confusión, ya que el primer lote de actualizaciones rompía la funcionalidad, lo que obligó a realizar otra ronda de actualizaciones.

[Reciba lo último de CIO Perú suscribiéndose a nuestro newsletter semanal]

Tal es el predicamento al que a menudo se enfrentan los profesionales de la informática y la ciberseguridad: Averiguar qué vulnerabilidades son las más críticas y merecen atención inmediata, cuáles pueden esperar, y cuándo confiar y aplicar una actualización.

La habilidad requiere una aguda comprensión técnica, planificación y tacto, ya que retrasar parches cruciales, bajo la falsa suposición de que las vulnerabilidades que atienden suponen una amenaza limitada, puede causar consecuencias devastadoras. Por otro lado, dedicar recursos a parchear "vulnerabilidades" endebles que tal vez nunca se exploten sin que los atacantes obtengan acceso administrativo a un sistema, podría convertirse en un esfuerzo inútil.

El modelo de puntuación CVSS no mide el riesgo

Introducido en el 2005 tras una investigación del Consejo Asesor de Infraestructura Nacional (NIAC, por sus siglas en inglés), el estándar del Sistema de Puntuación de Vulnerabilidad Común (CVSS, por sus siglas en inglés) fue diseñado para ayudar a las organizaciones a evaluar la "gravedad" de las fallas. Aunque las puntuaciones CVSS proporcionan una idea decente de la gravedad de una vulnerabilidad, pueden quedarse cortas. Las directrices de puntuación del CVSS 3.1 hacen hincapié en que las puntuaciones del CVSS están diseñadas para medir la gravedad de una vulnerabilidad y no el riesgo que representa.

Cuando se puntúan las vulnerabilidades, se aconseja al analista que "puntúe para el peor escenario de implementación razonable", pero no es raro que dos analistas de ciberseguridad cualificados lleguen a puntuaciones diferentes, lo que hace que el proceso sea subjetivo. Una vulnerabilidad "crítica" podría ser puntuada como "alta" dependiendo de hasta qué punto un analista puede articular la posibilidad realista de que el peor escenario exista en un entorno.

Las puntuaciones CVSS son subjetivas y suelen cambiar

Nos hemos dado cuenta de esto en el caso de las CVE de Log4j. De las cinco CVEs publicadas hasta ahora, incluyendo Log4Shell (CVE-2021-44228), la gravedad de dos vulnerabilidades se ajustó a medida que se descubrió más información.

El CVE-2021-45046, que anteriormente se consideraba una falla de denegación de servicio de gravedad "baja" con una puntuación de 3,7, se elevó posteriormente a una calificación "crítica" (9,0). En cambio, la gravedad de otra falla de denegación de servicio (CVE-2021-45105) descubierta posteriormente se redujo de "alta" a "moderada".

Sin embargo, de todas las CVEs publicadas para Log4j, la revelación de la última falla de ejecución remota de código CVE-2021-44832 suscitó fuertes críticas por parte de la comunidad de infoseguridad, dado que la explotación de la falla requería que el atacante tuviera ya permisos de escritura en el archivo de configuración de registro de Log4j y que hiciera vulnerable la instancia de forma intencionada. Algunos cuestionaron si la asignación de un CVE para este problema estaba justificada en primer lugar, especialmente en un momento en que el equipo de voluntarios y usuarios de Log4j, con poco personal, ya estaba desbordado parcheando fallas legítimas de Log4j.

"Con Log4j, la única vulnerabilidad que importaba era la original: CVE-2021-44228", explica el analista de vulnerabilidades del Centro de Coordinación del CERT, Will Dormann, refiriéndose al hecho de que Log4Shell estaba siendo explotado activamente en la naturaleza.

Sea cauteloso con los informes de seguimiento de las vulnerabilidades

"Entonces llegó el cúmulo de CVE. Otras organizaciones, investigadores, etc., decidieron que sería bueno que encontraran sus propias vulnerabilidades en Log4j. Pero de cada una de las vulnerabilidades de seguimiento (CVE-2021-4104, CVE-2021-45046, CVE-2021-45105, CVE-2021-44832), la explotación exitosa requería que el atacante ya tuviera control sobre el archivo de configuración de Log4j, y/o que el software que utilizara Log4j lo hiciera de una manera artificiosa que ni siquiera fuera vista por ningún software en la naturaleza", explica Dormann.

Tras la revelación de una vulnerabilidad crítica o de una técnica de explotación, no es raro que otros cazadores de bugs se sientan motivados y cambien su enfoque hacia la búsqueda de fallas similares, para enriquecer su cartera de CVE o cobrar premios de recompensas. Una tendencia similar se observó tras la revelación de la técnica de confusión de dependencias y los numerosos paquetes imitadores que surgieron, que siguen infiltrándose en los repositorios de código abierto en la actualidad.

Sin embargo, dado que los proyectos de código abierto suelen estar dirigidos por pequeños equipos de voluntarios que apoyan proyectos críticos en su tiempo libre, las solicitudes de características innecesarias, o los informes de vulnerabilidad para defectos que son pruebas de concepto abstractas y prácticamente inexplotables en circunstancias normales, pueden suponer una carga adicional e indebida para los mantenedores.

El documento de posición de Apache, redactado en enero del 2022, aconseja que "las directivas de seguridad DEBEN evitar imponer cargas adicionales no financiadas a los pocos mantenedores que ya están haciendo el trabajo".

No son solo los mantenedores del proyecto los que se encuentran en desventaja tras la revelación de una serie de vulnerabilidades de alto perfil: los equipos de seguridad y de TI de las organizaciones que utilizan los productos también tendrán que gastar ahora recursos para evaluar el impacto de cada una de las vulnerabilidades y priorizar las actividades de parcheo.

Refiriéndose específicamente a la CVE-2021-45046, tras la revisión de su puntuación CVSS a 9,0, Dormann advierte que, aunque la mayor puntuación de gravedad puede hacer saltar las alarmas desde la revelación de la falla hace más de un mes, "nadie en Internet ha sido capaz de presentar una sola aplicación del mundo real que esté afectada por ella. Sí, algunos vendedores que no hicieron sus deberes probablemente publicaron un aviso diciendo que estaban afectados por él, pero no confirmaron que su software estuviera realmente afectado", continúa.

Dormann argumenta que si no se conoce el contexto en el que se utiliza un componente en su aplicación (por ejemplo, una clase o un método específico vulnerable del componente), declarar una aplicación vulnerable simplemente porque tiene una determinada versión de Log4j podría ser inexacto. "Si una CVE obtiene una puntuación CVSS, esa puntuación puede incluso no reflejar con precisión la gravedad de esa instancia de la biblioteca en un producto determinado".

La falla hace que los administradores desconfíen de las actualizaciones

Mientras la industria comenzaba a recuperarse del episodio de Log4j, el martes de parches de enero dejó a los administradores de sistemas confundidos y disgustados. El 11 de enero, Microsoft publicó una serie de actualizaciones de Windows Server que causaron problemas con las instancias de virtualización Hyper-V y los sistemas de archivos ReFS.

Shawn Waldman, director general de Secure Cyber Defense, tuiteó que estaba "negando estos parches debido a los constantes reinicios".

Adriano Maia, CISO de Proteus Risk Management, tampoco dudó en expresar su preocupación: "¿MS siquiera [probó] esta ola? ¿Alguien más está teniendo problemas? Desde el bloqueo de lsass debido a lsadb.dll hasta los hosts [de Hyper-V] que se vuelven locos".

Como resultado, en dos días Microsoft tuvo que revertir estas actualizaciones debido a los errores críticos y volver a publicarlas. Sin duda, esto provocó una gran confusión con respecto a la priorización y aplicación de las actualizaciones periódicas.

Este percance se vio agravado por el hecho de que el martes de parches de enero corrigió CVE críticos, entre ellos el CVE-2022-21907, una vulnerabilidad de ejecución remota de código en la pila de protocolos HTTP de Windows, que Microsoft instó a todos a parchear lo antes posible. "CVE-2022-21907 es una CVE especialmente peligrosa por su capacidad de permitir a un atacante afectar a toda una intranet una vez que el ataque tiene éxito", explicó Danny Kim, arquitecto principal de Virsec.

"Microsoft ha declarado que esta vulnerabilidad es susceptible de convertirse en gusano y debe ser parcheada inmediatamente. La CVE es el último ejemplo de cómo las capacidades del software pueden ser deformadas y convertidas en armas. La CVE se dirige a la función de soporte de remolque HTTP, que permite a un remitente incluir campos adicionales en un mensaje para suministrar metadatos, proporcionando un mensaje especialmente diseñado que puede conducir a la ejecución remota de código", señaló Kim.

¿Qué pueden hacer las organizaciones?

El reto ya no consiste en limitarse a aplicar las últimas actualizaciones. Si hay algo que nos han enseñado los ataques a la cadena de suministro de alto perfil, como el de SolarWinds, es que no todas las actualizaciones son benignas y pueden causar problemas. Además, las actualizaciones saboteadas de librerías populares "de colores" y "falsas", y una actualización de dependencia legítima que rompió el marco de trabajo Create React App de Facebook para muchos, son otros ejemplos de cómo confiar ciegamente y descargar las últimas actualizaciones puede romper su software en lugar de corregir los errores.

Las organizaciones deben considerar dos aspectos críticos antes de decidirse a actuar:

  • De todas las vulnerabilidades (CVEs) divulgadas, ¿cuáles merecen la máxima atención?
  • En caso de que la reparación de las vulnerabilidades más urgentes requiera la descarga de actualizaciones, ¿son estas legítimas, seguras y garantizan la solución de los problemas?

¿Qué vulnerabilidades hay que priorizar?

A la hora de priorizar las CVE, mirar sus puntuaciones CVSS es un comienzo. Sin embargo, los analistas deben evaluar el peor escenario que plantea la hipotética explotación de una CVE en su entorno. Las fallas que pueden ser explotados de forma remota por actores no autentificados suelen considerarse casi siempre de gravedad "alta" o "crítica", y deben priorizarse especialmente si el componente vulnerable es de acceso público en su implementación.

Para el resto de los defectos -calificados como moderados, por ejemplo- si su explotación depende únicamente de la explotación de otro defecto (por ejemplo, como parte de una cadena de vulnerabilidad) o requiere privilegios elevados por parte del atacante, su parcheado podría esperar un poco, y el enfoque debería ser evaluar y eliminar los vectores de ataque iniciales que pueden ayudar a la explotación de dichos defectos.

Con un marco de registro como Log4j, es mucho más difícil evaluar el impacto de la explotación. Esto se debe a que, por ejemplo, aunque el servidor de registro en el que se ejecuta la versión vulnerable de Log4j no esté directamente orientado a Internet, el servidor web que registra sus actividades, solicitudes y entradas -legítimas y maliciosas- es suficiente para activar la vulnerabilidad incluso en un servidor de registro situado detrás de un perímetro.

Por lo tanto, incluso si a primera vista la vulnerabilidad de Log4Shell no parece explotable en su entorno, una evaluación exhaustiva de los controles del perímetro y de dónde reside el componente vulnerable en su red podría ayudar a obtener una mejor imagen.

El marco de Categorización de Vulnerabilidades Específicas para las Partes Interesadas (SSVC) del CERT/CC tiene como objetivo proporcionar una mejor imagen a los analistas a la hora de evaluar la aplicabilidad de una vulnerabilidad a su entorno, cambiando una talla única por un sistema modular de toma de decisiones, que tiene partes claramente definidas que los gestores de vulnerabilidades pueden elegir y utilizar según sea apropiado para su contexto.

"El SSVC trata de convertir de forma fiable las pruebas en decisiones durante la gestión de la vulnerabilidad... y pretende ser un lenguaje compartido entre los responsables de la toma de decisiones y los analistas, de forma que el liderazgo pueda tomar decisiones basadas en el riesgo y los analistas puedan reunir las pruebas de forma coherente y ejecutar esas decisiones", explicó Dormann.

Aunque el SSVC por sí mismo puede no ser suficiente para abordar todas las cuestiones, como la puntuación de las vulnerabilidades en una biblioteca como log4j, el marco ayuda a la toma de decisiones a la hora de priorizar qué vulnerabilidades atender.

Como nota al margen, estar en contacto con una comunidad vetada de profesionales de la infoseguridad puede ser bastante gratificante aquí, y ahorrar tiempo, incluso a través de los medios sociales. Suscribirse a los compendios de infoseguridad y a las listas de correo de los proyectos de código abierto puede proporcionar información oportuna de profesionales cualificados y creíbles que pueden dar un aviso sobre qué vulnerabilidades son críticas entre el ruido. Si bien es cierto que esta correspondencia debe ser examinada por los equipos internos de su organización, al menos puede orientar a sus analistas en una dirección que merezca la pena examinar.

¿Actualizar o no actualizar?

El segundo aspecto de la verificación y el examen de las actualizaciones es un poco más difícil y requiere tanto la intervención manual como la automatización. Aunque la descarga y aplicación del último parche para un componente vulnerable es la orientación recomendada para muchas vulnerabilidades, también se pueden ofrecer soluciones alternativas. Los responsables de la toma de decisiones deben evaluar qué opción ofrece un mejor resultado: aplicar el parche o aplicar manualmente una solución alternativa.

Si los beneficios que aporta la aplicación de la solución son mayores que los costos y los riesgos potenciales que supone la descarga de una actualización posiblemente sospechosa, puede merecer la pena aplicar manualmente una solución. Existe la posibilidad de romper algo al actualizar un archivo de configuración, pero el riesgo es relativamente manejable y controlado, que el riesgo de descargar una actualización no verificada, como en los casos de los ejemplos mencionados de SolarWinds y dependencias dudosas.

Además, el uso de herramientas automatizadas de SCA y escáneres de Log4j, como los publicados por CISA, Google y Microsoft (en Defender 365), puede detectar los fragmentos de código y clases vulnerables específicos que están al acecho en sus aplicaciones. Los enfoques de escaneo binario profundo y de coincidencia de cadenas utilizados por estas herramientas pueden informar con éxito de las clases vulnerables al instante, en lugar de tener que realizar manualmente la ingeniería inversa de los binarios y determinar si están afectados.

Por otro lado, los parches con errores como los del martes de parches de enero de Microsoft son mucho más difíciles de predecir con antelación y, afortunadamente, parecen ser un caso raro. Los problemas causados por estas actualizaciones solo pueden descubrirse a través de los miembros de la comunidad de infoseguridad, las listas de correo y los canales de las redes sociales, después de que alguien ya se haya visto afectado por ellos.

Microsoft lanzó actualizaciones de emergencia fuera de banda (OOB) para arreglar los problemas causados por las actualizaciones de Windows Server con errores, pero eso todavía no resuelve la confusión inicial causada por las actualizaciones rotas en primer lugar, y el dilema: saltar a las actualizaciones del martes de parches de inmediato o probarlas en un entorno de laboratorio. Otro enfoque es confiar en las soluciones de supervisión proactiva que pueden proporcionar cierta protección en ausencia de parches.

"Aunque Microsoft ha proporcionado un parche oficial, [CVE-2022-21907] es otro recordatorio de que las características del software permiten a los atacantes aprovechar las funcionalidades para realizar actos maliciosos", sostuvo Kim de Virsec. "En lugar de intentar parchear e identificar continuamente estas vulnerabilidades, las empresas deberían buscar una solución de monitorización en tiempo real para salvaguardar las aplicaciones y sus funcionalidades de este tipo de ataques".