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:
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
CVE-2021-45046
¿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:
Comando para archivos comprimidos:
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:
Comando para archivos comprimidos:
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
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.
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:
Detección de Vulnerabilidades
Atlassian
Citrix
Cpanel
Debian
Docker (app)
Docker (dockers)
Oracle
RedHat
Splunk
TrendMicro
Ubuntu
PulseSecure
Microsoft
Se recomienda lo siguiente:
Mantener un trabajo constante de actualizaciones en sus servicios activos.
Producto | Versión |
---|---|
Apache |
Log4j2 anterior a 2.16.0 |