¿Por qué es tan crítica la vulnerabilidad de Log4j ?

16 Diciembre 2021
Crítico

El día jueves 9 de diciembre, se encendieron las alertas de seguridad a nivel mundial por el descubrimiento de una vulnerabilidad crítica identificada como CVE-2021-44228 la cual afecta directamente a una librería de Apache llamada Log4j.

El descubrimiento se volvió más relevante cuando se logró identificar que esta vulnerabilidad no solo afectaba a servidores web dedicados, sino que también a múltiples aplicativos que utilizan esta librería para el manejo de sus logs. Comúnmente es utilizada en “Software basado en Java EE”, “servidores web Apache” y “Aplicaciones compiladas con Spring-Boot”, entre otras.
 

¿Qué es Log4j?

Es un framework de manejo de registros ampliamente utilizado para generar y almacenar mensajes de registros en distintos niveles, como DEBUG, WARN, INFO, ERROR, FATAL. Este framework ayuda a los desarrolladores a automatizar esta funcionalidad de forma confiable, flexible y con un menor consumo de recursos en sus aplicaciones. Está escrito en Java y está licenciado bajo Apache Foundations.


 

La vulnerabilidad CVE-2021-44228 aka Log4Shell

Muchos servicios han sido afectados por esta vulnerabilidad, inclusive servicios basados en la nube. Su criticidad es relevante puesto que de forma remota y a través de configuraciones específicas creadas en el terminal del atacante se podría permitir la ejecución de código remoto en la víctima sin mayores complejidades, poniendo en riesgo a innumerables servidores de todo el mundo. 

Su explotación logra el control total de las máquinas. Lo complejo es que pese a que ya existen parches para la librería log4j, aún existen diversos aplicativos que continúan investigando si sus versiones se encuentran vulnerables y la comunidad aún está en espera de parches específicos para aquellos que sí están afectados. No obstante, afortunadamente gran parte de los aplicativos de seguridad perimetral ya se han pronunciado al respecto y cuentan con nuevas versiones que mitigan esta vulnerabilidad.

Por otra parte, existe evidencia de que distintos actores de amenazas de alta sofisticación han estado explotando activamente esta vulnerabilidad mucho antes de que se difundiera de forma masiva. Lo peor es que durante esta última semana, se han liberado diversas pruebas de concepto por la web generando un nuevo escenario donde la explotación de la vulnerabilidad se ha disparado de forma vertiginosa, logrando evidenciar a distintas botnets intentando tomar control de terminales, instalación de cryptominers e indudablemente: distribución de ransomware. Para más información, referirse a nuestro boletín "Vulnerabilidad crítica en versiones de Log4j permite la explotación de RCE".

Investigadores de Microsoft informaron que los actores del estado-nación de China, Irán, Corea del Norte y Turquía ahora están abusando de  Log4Shell  (CVE-2021-44228) en la biblioteca Log4J en sus campañas. Algunos de los grupos que explotan la vulnerabilidad son:

  • Hafnium vinculado a China: Estaría utilizando la falla para atacar la infraestructura de virtualización.
  • Phosphorus vinculado a Irán  ; Estaría utilizando la falla para implementar ransomware.

Los expertos de Microsoft también afirman que varios ciberactores han comenzado a utilizar la vulnerabilidad Log4Shell para obtener acceso inicial a las redes de destino y luego venderlo a afiliados de ransomware como servicio.
 

Una nueva vulnerabilidad encontrada en Log4J: CVE-2021-45046

El lunes 13 de diciembre, después de que se descubrió que la primera actualización, la versión 2.15.0, estaba "incompleta en algunas configuraciones no predeterminadas y podría permitir que un atacante ejecutase un ataque de denegación de servicios (DoS) ", el proyecto Apache Logging Services lanzó una nueva versión (Log4j 2.16.0) para mitigar esta nueva vulnerabilidad identificada como CVE-2021-45046.

Log4j 2.15.0 hace un gran esfuerzo para restringir las búsquedas JNDI LDAP a localhost de forma predeterminada. Log4j 2.16.0 soluciona este problema eliminando la compatibilidad con los patrones de búsqueda de mensajes y desactivando la funcionalidad JNDI de forma predeterminada. 

Apreciación:

Debido a la identificación de esta nueva vulnerabilidad estimamos que en los próximos días las diversas marcas que ya han liberado actualizaciones de seguridad para mitigar la vulnerabilidad de Log4Shell, estarán validando la factibilidad de liberar nuevas versiones que mitiguen al CVE-2021-45046. De este modo, continuaremos con actualizaciones de estas vulnerabilidades y sus contramedidas.
 

Resumen de vulnerabilidades

CVE-2021-44228

  • CVSS: 10/10 (CRÍTICO)
  • Impacto: Control total del servidor (RCE)
  • Mitigación: Actualizar a Log4j "2.15.0", privilegiando llegar a la última versión disponible “2.16.0”
  • Mitigación temporal: Agregar "log4j.format.msg.nolookups=true" a la configuración global de su servidor o aplicación web.

CVE-2021-45046

  • CVSS: 9.0/10 (CRÍTICO)
  • Impacto: Ataque DOS
  • Mitigación: Actualizar a Log4j "2.16.0"
     

¿Cómo funciona el ataque?

1. El atacante debe crear una instancia JAVA, que al ser consultada a través de JNDI, logre entregar el comando o archivo malicioso a la máquina de la víctima. Para ello puede utilizar cualquier posibilidad de implementación de JNDI, tales como: LDAP, HTTP, DNS, RMI, entre otras.


 

2. El atacante genera una solicitud a la víctima para insertar una cabecera especial con una implementación de búsqueda JNDI que será guardado como un registro por la librería log4j de la víctima.


 

3. La víctima recibe dicha solicitud, la almacena gracias a log4j quien interpola este registro siempre y cuando “message lookup substitution” esté habilitado
.

4. La víctima se comunica directamente con el servidor del atacante a través de la implementación JNDI definida (para este caso LDAP)
 

5. El terminal del atacante, que ejecutó la instancia de JAVA con el script “log4jexplotation.jar” está configurado para entregar el comando definido directamente en el terminal de la víctima. Esto tiene diversas variantes que otorgan la posibilidad de descargar archivos maliciosos, ejecutar comandos específicos, etc.

 

¿Qué es JNDI?

La interfaz de nombres y directorios de Java (JNDI) es una interfaz de programación de aplicaciones (API) que proporciona funcionalidad de nombres y directorios a las aplicaciones escritas utilizando el  lenguaje de programación JAVA. 

Se define como independiente de cualquier implementación de servicio de directorio específica. Por lo tanto, se puede acceder a una variedad de directorios (nuevos, emergentes y ya implementados) de una manera común. En términos sencillos es básicamente una interfaz para poder obtener instancias de recursos internos/externos. Sin JNDI, la ubicación o la información de acceso de los recursos remotos tendrían que estar codificados en las aplicaciones o estar disponibles en una configuración.
 

¿Qué podemos hacer ante esta vulnerabilidad?

Estas vulnerabilidades afectan tanto a sistemas de ciberseguridad perimetrales como también a aplicaciones y servicios web que pueden brindar servicios tanto a nivel perimetral como en la red interna.
 

PERÍMETRO

1. Actualización de sistemas perimetrales (si existe parche)

Identificar si los aplicativos expuestos a Internet utilizan la librería afectada. Para ello proveedores de ciberseguridad como TrendMicro, han liberado escaneadores públicos:

Del mismo modo, objeto poder tener conocimiento si los proveedores han liberado alguna actualización de seguridad contra esta vulnerabilidad, ponemos a disposición un listado del estado de afección de distintas marcas, elaborado por la Agencia de estadounidense "Cybersecurity and Infrastructure Security Agency" (CISA): https://github.com/cisagov/log4j-affected-db

2. Indicadores de compromiso

Investigadores han puesto a disposición una gran cantidad de indicadores de compromiso, principalmente direcciones IP maliciosas asociadas a servidores que están explotando log4shell:

https://github.com/hackinghippo/log4shell_ioc_ips/blob/main/ips.txt

Este repositorio se actualiza aproximadamente cada 1 hora.

3. Reglas SNORT

Si bien existen reglas SNORT que pueden ser cargadas a través de sistemas de prevención de intrusos, es importante destacar que el tráfico cifrado solo se podría observar a través de complementos especializados para ello. Es por esto que este tipo de contramedida no es una solución definitiva y se debería privilegiar la protección a través de un Web Application Firewall.

4. Protección en capa de aplicación a través de WAF

Tal como lo demuestra la imagen que referenciada el cómo funciona el ataque, el primer acercamiento para detenerlo es a través de un Web Application Firewall que es capaz de observar las solicitudes a través de los métodos de petición HTTP. 

Debido a que este tipo de soluciones posee la capacidad de identificar a través de firmas los patrones de ataque, existen algunos Regex que ayudan a la detección y bloqueo de éstos.


 

Puede obtener mayor información de la protección que ofrece IMPERVA, en el siguiente enlace:
https://www.imperva.com/blog/how-were-protecting-customers-staying-ahead-of-cve-2021-44228


Bloqueo efectuado por solución Cloud WAF de IMPERVA


RED INTERNA

1. Detectar la vulnerabilidad con script específicos

Para detectar esta vulnerabilidad de forma interna existen diferentes opciones de realizarlo, una de las más sencillas resulta en conocer la versión de Log4j instalada en sus activos. (vulnerable desde 2.0-beta9 hasta 2.14.1

Existen además diferentes escaneadores compartidos en Github para detectar los activos vulnerables dentro de su organización abarcados en la vulnerabilidad CVE-2021-44228. Se detallan los siguientes:

Comandos Grep/Zgrep para detección de explotación

También es posible detectar la explotación de esta vulnerabilidad a través de los siguientes comandos:

Comando para archivos no comprimidos:

  • # sudo egrep -I -i -r ' \ $ (\ {|% 7B) jndi: (ldap [s]? | rmi | dns | nis | iiop | corba | nds | http): / [^ \ n] + ' /var/log
  • Este comando permite la detección, a través de la búsqueda de intentos de explotación en archivos ubicados en la carpeta /var/log y en sus subcarpetas.

Comando para archivos comprimidos:

  • # sudo find /var/log -name \ * .gz -print0 | xargs -0 zgrep -E -i ' \ $ (\ {|% 7B) jndi: (ldap [s]? | rmi | dns | nis | iiop | corba | nds | http): / [^ \ n] + '
  • Este comando permite la detección de la explotación de esta vulnerabilidad, en archivos ubicados en la carpeta /var/log y en sus subcarpetas.
     

Comandos Grep/Zgrep en variantes ofuscadas

Estos comandos buscan la explotación de la vulnerabilidad en variantes ofuscadas, en la carpeta /var/log y sus subcarpetas

Comando para archivos no comprimidos:

  • # sudo find / var / log / -type f -exec sh -c " cat {} | sed -e 's / \ $ {lower: //' g | tr -d '}' | egrep -I -i 'jndi : (ldap [s]? | rmi | dns | nis | iiop | corba | nds | http): ' "  \;

Comando para archivos comprimidos:

  • # sudo find / var / log / -name ' * .gz ' -type f -exec sh -c " zcat {} | sed -e 's / \ $ {lower: //' g | tr -d '}' | egrep -i 'jndi: (ldap [s]? | rmi | dns | nis | iiop | corba | nds | http):' "  \;
     

2. Reglas YARA

Las siguientes reglas fueron compartidas en la comunidad de Github por el usuario Neo23x0, las cuales buscan detectar la explotación de esta vulnerabilidad:
https://github.com/Neo23x0/signature-base/blob/master/yara/expl_log4j_cve_2021_44228.yar
 

3. Ejecutar escaneos de vulnerabilidades con software especializado como Tenable

Tenable ha informado que ya posee plugins para la detección de las vulnerabilidades, incluyendo evaluaciones remotas y locales (credenciales). Para ello posee dashboards de seguimiento tanto en Tenable.sc como en Tenable.io

 

 

Respuesta de importantes proveedores de seguridad contra la vulnerabilidad de ejecución remota de código Apache Log4j (CVE-2021-44228)

Los  diferentes Vendors han continuado efectuando los correspondientes estudios en sus productos y objeto determinar que productos estarían afectados y realizar la correspondiente mitigación cuando este disponible, por lo que se estima que este proceso tomará un largo periodo de tiempo.
 

Palo Alto: Impacto de la vulnerabilidad de Log4j CVE-2021-44228

  • Hemos determinado que este problema afecta a las versiones PAN-OS 9.0, PAN-OS 9.1 y PAN-OS 10.0 para Panorama. Se están desarrollando revisiones para abordar la vulnerabilidad en las versiones de PAN-OS afectadas.
  • Nota: Las versiones de PAN-OS 8.1 y PAN-OS 10.1 para Panorama no se ven afectadas por este problema. Todas las versiones de PAN-OS para firewalls y dispositivos WildFire no se ven afectadas.
  • https://security.paloaltonetworks.com/CVE-2021-44228
     

F5 : K19026212: Apache Log4j2 Remote Code Execution vulnerability CVE-2021-44228

Cisco: Vulnerability in Apache Log4j Library Affecting Cisco Products: December 2021

Cisco está evaluando el impacto de todos los productos y servicios de CVE-2021-44228 y CVE-2021-45046.

  • Software fijo
    • Para obtener información sobre las versiones de software corregidas, consulte los productos identificados en la sección Productos vulnerables del aviso de Cisco. 
  • Detección de Vulnerabilidades
    • Para ayudar a detectar la explotación de estas vulnerabilidades, Cisco ha publicado reglas de Snort en la siguiente ubicación: Reglas de Talos 2021-12-15  
       

VMware: VMware Response to Apache Log4j Remote Code Execution Vulnerability (CVE-2021-44228, CVE-2021-45046)

Forti: Apache log4j2 log messages substitution (CVE-2021-44228)

Los siguientes productos se ven afectados y se están trabajando en soluciones actualizandose tan pronto como ETA  esté disponible:

  • FortiAIOps - Corregido en la versión 1.0.2
  • FortiCASB - Corregido en 2021-12-10
  • FortiConverter Portal - Corregido en 2021-12-10
  • FortiCWP - Corregido en 2021-12-10
  • FortiEDR Cloud - No explotable. Mitigaciones precautorias adicionales implementadas el 2021-12-10
  • FortiInsight - No explotable. Se están investigando mitigaciones precautorias adicionales.
  • FortiIsolator - Arreglo programado para la versión 2.3.4
  • FortiMonitor - Mitigaciones para NCM y Elastiflow disponibles FortiPortal - Arreglado en 6.0.8 y 5.3.8 FortiSIEM - Mitigación disponible
  • ShieldX - Corrección programada para las versiones 2.1 y 3.0 - ETA 2021/12/17

Detección de Vulnerabilidades

  • Protección de firma IPS (FortiOS)
    • Fortinet ha lanzado la firma IPS Apache.Log4j.Error.Log.Remote.Code.Execution, con VID 51006 para abordar esta amenaza.
  • Protección de firma IPS (FortiADC y FortiProxy)
    • FortiADC admite la firma IPS para mitigar log4j (versión 19.215).
    • FortiProxy admite la firma IPS para mitigar log4j (versión 19.215).
  • Cortafuegos de aplicaciones web (FortiWeb y FortiWeb Cloud)
    • Las firmas de aplicaciones web para prevenir esta vulnerabilidad se agregaron por primera vez en la base de datos 0.00305 y se actualizaron en versiones recientes.
       

Atlassian

Citrix

  • Se encuentra afectado, aún evaluando impacto final, sin embargo para productos ya identificados se presentan parches para ambas vulnerabilidades.
  • Si dispone de Citrix WAF se recomienda hacer uso de él para la detección temprana de la amenaza.
  • Mayores detalles en: 

Cpanel

Debian

Docker (app)

Docker (dockers)

Oracle

RedHat

Splunk

TrendMicro

Ubuntu

  • Se encuentra afectado,impacto final ya evaluado por lo que se presentan parches para ambas vulnerabilidades, necesitando solo actualizar los paquetes vulnerables y no todo el sistema.
  • Mayores detalles en: 

PulseSecure

Microsoft

Se recomienda lo siguiente:

Mantener un trabajo constante de actualizaciones en sus servicios activos.

  • Se debe actualizar a Log4j 2.16.0 para obtener una protección completa ya que en esta versión se soluciona este problema eliminando la compatibilidad con los patrones de búsqueda de mensajes y desactivando la funcionalidad JNDI de forma predeterminada.
  • Link de actualización: (https://logging.apache.org/log4j/2.x/download.html)
  • Mantener seguimiento de posibles actualizaciones de seguridad de los vendors de los que su organización posea.
  • Ejecutar comando de búsqueda/grep en todos los servidores para detectar cualquier archivo con nombre "log4j2", y luego comprobar si es una versión vulnerable o no (Comando Linux: [find . -name *log4j2*]
  • Añadir “log4j.format.msg.nolookups=true" a la configuración global de su servidor/web .
  • Las reglas y los filtros proporcionados por proveedores brindan una protección LIMITADA contra este exploit, por lo que NO debe asumirse como sustituto al parchado.

Tags: #Apache #Parche #Log4j #Día cero #explotación #biblioteca #Log4shell #CVE-2021-44228 #CVE-2021-45046
  • Productos Afectados
  • Producto Versión
    Apache Log4j2 anterior a 2.16.0


© 2019 Entel CyberSecure
Protege tus activos críticos, datos e infraestructura TI y minimiza tus riesgos de fuga de información,
fraude electrónico, espionaje industrial, suplantación de identidades y amenazas Zero Day, con las soluciones y servicios del Centro de Ciberinteligencia de Entel.