Respuesta de Microsoft a CVE-2021-44228 Apache Log4j 2 – Centro de respuesta de seguridad de Microsoft

Publicado el: 11 dic.2021

RESUMEN

Microsoft está investigando la vulnerabilidad de ejecución remota de código (CVE-2021-44228) relacionado con Apache Log4j (una herramienta de registro utilizada en muchas aplicaciones basadas en Java) divulgada el 9 de diciembre de 2021. A medida que nosotros y la industria en general sigamos obteniendo una comprensión más profunda del impacto de esta amenaza, publicaremos información técnica para ayudar los clientes detectan, investigan y mitigan los ataques, así como orientación para el uso de las soluciones de seguridad de Microsoft para aumentar la resistencia frente a los ataques relacionados. Actualizaremos este blog con información y detalles de protección a medida que estén disponibles.

Además de monitorear el panorama de amenazas en busca de ataques y desarrollar protecciones para el cliente, nuestros equipos de seguridad han estado llevando a cabo una investigación activa de nuestros productos y servicios para comprender dónde se puede usar Apache Log4j y están tomando medidas aceleradas para mitigar cualquier instancia. A través de nuestra investigación, hemos identificado los pasos de mitigación que los clientes podrían tomar en sus entornos, así como en nuestros servicios.

Aplicar las últimas actualizaciones de seguridad

Para abordar esta vulnerabilidad, Microsoft recomienda a los clientes que apliquen las últimas actualizaciones de seguridad para remediar esta vulnerabilidad. Consulte Apache CVE y el aviso de seguridad de Apache para obtener más detalles:

Todos los sistemas, incluidos los que no están orientados al cliente, son potencialmente vulnerables a este exploit, por lo que los sistemas backend y los microservicios también deben actualizarse. La acción recomendada es actualizar Log4j 2 a 2.15.0.

Soluciones alternativas

Para ayudar a mitigar el riesgo de esta vulnerabilidad hasta que se pueda aplicar la actualización de seguridad más completa, los clientes deben considerar los siguientes pasos de mitigación. Estos no deben considerarse una solución completa para resolver esta vulnerabilidad:

  • En caso de que el componente vulnerable de Log4j 2 no se pueda actualizar, las versiones 2.10 a 2.14.1 de Log4J 2 admiten que el parámetro log4j2.formatMsgNoLookups se establezca en ‘true’ para deshabilitar la función vulnerable. Asegúrese de que este parámetro esté configurado en los scripts de inicio de la máquina virtual Java:
    -Dlog4j2.formatMsgNoLookups = verdadero.
  • Alternativamente, los clientes que usan Log4j 2.10 a 2.14.1 pueden configurar la variable de entorno LOG4J_FORMAT_MSG_NO_LOOKUPS = ”true” para forzar este cambio.
  • Los administradores de Kubernetes pueden usar «kubectl set env» para configurar la variable de entorno LOG4J_FORMAT_MSG_NO_LOOKUPS = «true» para aplicar la mitigación en los clústeres de Kubernetes donde las aplicaciones Java ejecutan Log4j 2.10 a 2.14.1, reflejándose efectivamente en todos los pods y contenedores automáticamente.
  • Para las versiones de 2.0-beta9 a 2.10.0, la mitigación es eliminar la clase JndiLookup de la ruta de clases: zip -q -d log4j-core – *. Jar org / apache / logging / log4j / core / lookup / JndiLookup.class

Antecedentes de Log4j

La vulnerabilidad, rastreada como CVE-2021-44228 y denominado «Log4Shell», afecta a las aplicaciones basadas en Java que utilizan Log4j 2 versiones 2.0 a 2.14.1. Log4j 2 es una biblioteca de registro basada en Java que se usa ampliamente en el desarrollo de sistemas comerciales, se incluye en varias bibliotecas de código abierto y se integra directamente en las principales aplicaciones de software. El alcance del impacto se ha expandido a miles de productos y dispositivos, incluidos productos Apache como Struts 2, Solr, Druid, Flink y Swift. Debido a que esta vulnerabilidad se encuentra en una biblioteca de Java, la naturaleza multiplataforma de Java significa que la vulnerabilidad se puede explotar en muchas plataformas, incluidas Windows y Linux. Dado que muchas aplicaciones basadas en Java pueden aprovechar Log4j 2, las organizaciones deben ponerse en contacto con los proveedores de aplicaciones o asegurarse de que sus aplicaciones Java estén ejecutando la última versión actualizada. Los desarrolladores que utilicen Log4j 2 deben asegurarse de incorporar la última versión de Log4j en sus aplicaciones lo antes posible para proteger a los usuarios y las organizaciones.

Análisis de la vulnerabilidad CVE-2021-44228

La vulnerabilidad es una vulnerabilidad de ejecución remota de código que puede permitir que un atacante no autenticado obtenga acceso completo a un sistema de destino. Puede activarse cuando el componente vulnerable Log4j 2 analiza y procesa una cadena especialmente diseñada. Esto podría suceder a través de cualquier entrada proporcionada por el usuario.

La explotación exitosa permite la ejecución de código arbitrario en la aplicación de destino. Los atacantes no necesitan acceso previo al sistema para registrar la cadena y pueden causar de forma remota el evento de registro mediante el uso de comandos como curl contra un sistema de destino para registrar la cadena maliciosa en el registro de la aplicación. Al procesar el registro, el sistema vulnerable lee la cadena y la ejecuta, que en los ataques actuales se utiliza para ejecutar el código del dominio malicioso. Hacerlo puede otorgar al atacante acceso y control total de la aplicación afectada.

Dado que el código de registro y las funcionalidades de las aplicaciones y los servicios suelen estar diseñados para procesar una variedad de datos de entrada externos procedentes de capas superiores y de muchos vectores posibles, el mayor factor de riesgo de esta vulnerabilidad es predecir si una aplicación tiene un vector de ataque viable. ruta que permitirá que la cadena de explotación con formato incorrecto alcance el código Log4j 2 vulnerable y desencadene el ataque.

Un patrón común de riesgo de explotación, por ejemplo, es una aplicación web con código diseñado para procesar nombres de usuario, referencias o cadenas de usuario-agente en registros. Estas cadenas se proporcionan como entrada externa (por ejemplo, una aplicación web construida con Apache Struts). Un atacante puede enviar un nombre de usuario con formato incorrecto o establecer un agente de usuario con la cadena de explotación diseñada con la esperanza de que esta entrada externa sea procesada en algún momento por el código Log4j 2 vulnerable y la ejecución del código de activación.

Figura 1. CVE-2021-44228 vectores de explotación y cadena de ataque

Guía de mitigación para servicios de Microsoft

Después de un análisis más detallado de nuestros servicios y productos, a continuación se muestran algunas estrategias de mitigación proporcionadas por varios servicios de Microsoft.

Microsoft Azure AD

Mientras que la industria está determinando y mitigando la exposición general, los atacantes están investigando todos los puntos finales en busca de vulnerabilidad. La aplicación de políticas rigurosas de acceso con privilegios mínimos a todos los recursos de su entorno es fundamental. Si usa Azure Active Directory para el inicio de sesión único en su entorno, le recomendamos que haga lo siguiente con un enfoque especial en las aplicaciones que implementa o administra directamente (las aplicaciones SaaS, incluidas las implementadas por Microsoft, deben estar protegidas por sus proveedores). Tenga en cuenta que el uso de log4j2 puede ser previo a la autenticación para algunas de sus aplicaciones, pero estos pasos ayudarán a evitar la explotación posterior a la autenticación. Plantillas y ejemplos porque estas políticas están integradas para facilitar la implementación:

Para obtener orientación clave sobre cómo proteger la implementación de su identidad, consulte https://aka.ms/securitysteps.

Azure Application Gateway, Azure Front Door y Azure WAF

Hemos determinado que estos servicios en sí mismos no son vulnerables a este exploit. La aplicación del cliente que se ejecuta detrás de estos servicios puede ser vulnerable a esta vulnerabilidad. Recomendamos a los clientes que sigan las mitigaciones y soluciones mencionadas en este blog para proteger sus aplicaciones. Paralelamente, también estamos trabajando para mejorar los RuleSets administrados por WAF para ayudar a proteger contra esta vulnerabilidad.

Servicio de aplicaciones de Azure (Windows y Linux)

Azure App Service and Functions no distribuye Log4J en los tiempos de ejecución administrados como Tomcat, Java SE, JBoss EAP o Functions Runtime. Sin embargo, sus aplicaciones pueden usar Log4J y ser susceptibles a esta vulnerabilidad.

Si es posible, los clientes deben actualizar Log4j a la versión v2.15.0 y volver a implementar las aplicaciones. Esta es la mitigación principal recomendada. Si no puede volver a implementar su aplicación, en Log4j versiones 2.10 y posteriores, puede mitigar este comportamiento estableciendo la propiedad del sistema “-Dlog4j2.formatMsgNoLookups = true”. En App Service, puede establecer esta propiedad mediante creando una configuración de aplicación llamado JAVA_OPTS con un valor de “-Dlog4j2.formatMsgNoLookups = true”. La configuración de la aplicación JAVA_OPTS se pasa a su aplicación Java cuando se inicia. Si ya tiene configurada la configuración de la aplicación JAVA_OPTS, simplemente agregue “-Dlog4j2.formatMsgNoLookups = true” al valor existente. Si está utilizando Log4J versión 2.9 o inferior, esta mitigación de propiedades del sistema no funcionará y debe actualizar a v2.15.0.

Hay algunos casos en App Service en los que deberá configurar esta propiedad del sistema de manera diferente:

Si está utilizando una secuencia de comandos de inicio personalizada para iniciar sus aplicaciones, deberá agregar esta propiedad del sistema a la secuencia de comandos de inicio.

En Windows App Service, si usa HttpPlatformHandler para iniciar sus aplicaciones Java, deberá agregar esta configuración en su archivo web.config. Si no está familiarizado con estos términos, es probable que no se apliquen a su aplicación.

Servicio de aplicaciones de Azure para contenedores

Si está implementando contenedores de Linux o Windows en App Service, deberá establecer la propiedad del sistema en la imagen de su contenedor. Lo más probable es que esté en el punto de entrada de su Dockerfile.

Funciones de Azure

La configuración de la propiedad del sistema dependerá de la opción de alojamiento que elija: dedicado, premium o consumo. Como recordatorio, la principal mitigación recomendada es actualizar Log4J a 2.15.0 y volver a implementar su aplicación. Si no puede hacer eso por cualquier motivo, puede aplicar la propiedad del sistema.

  • Funciones dedicadas y premium: Cree una configuración de aplicación denominada JAVA_OPTS con un valor de «-Dlog4j2.formatMsgNoLookups = true». Si ya tiene configurada la configuración de la aplicación JAVA_OPTS, simplemente agregue “-Dlog4j2.formatMsgNoLookups = true” al valor existente.
  • Funciones de consumo:
    • Linux: Cree una configuración de aplicación llamada «languageWorkers__java__arguments» con un valor de «-Dlog4j2.formatMsgNoLookups = true».
    • Ventanas: Cree una configuración de aplicación denominada «languageWorkers: java: argumentos» con un valor de «-Dlog4j2.formatMsgNoLookups = true».

Tenga en cuenta que la actualización de la configuración de la aplicación reiniciará sus aplicaciones web y de funciones, lo que podría afectar el rendimiento del arranque en frío. Si está utilizando Log4J versión 2.9 o inferior, esta mitigación de propiedades del sistema no funcionará y debe actualizar a v2.15.0.

Información para operaciones de seguridad y cazadores

Los equipos de seguridad de Microsoft han reunido la siguiente guía y recursos para ayudar a los clientes a comprender esta vulnerabilidad y para ayudar a detectar y buscar vulnerabilidades:

Actualizaremos más esta guía a medida que sigamos aprendiendo de nuestra investigación.

El equipo de MSRC



Fuente del articulo