La vulnerabilidad Log4j, o "Log4Shell”, se considera una de las fallas de software más catastróficas de la historia. Apache solucionó la falla en diciembre de 2021, pero sigue siendo una preocupación para los equipos de seguridad. De hecho, todavía se encuentra entre los vulnerabilidades de seguridad más explotadas.

Log4Shell persiste porque el paquete de software Apache Log4j 2 al que afecta es una de las bibliotecas de registro más utilizadas del mundo. Se espera que encontrar y reparar cada instancia de Log4Shell lleve una década, según el Departamento de Seguridad Nacional de los Estados Unidos.

Mientras tanto, los equipos de seguridad pueden tomar algunas medidas para acelerar la mitigación y corrección de Log4Shell en sus redes. 

Comprender las vulnerabilidades de Log4j  

Antes de profundizar en cómo detectar y parchear Log4Shell, es importante comprender la naturaleza de la vulnerabilidad.

log4j es un registrador de código abierto (mantenido por Apache Software Foundation) que registra información y eventos en un programa. Log4j no es un software independiente sino un paquete de código que los desarrolladores pueden conectar a sus propias aplicaciones Java. El marco Apache Log4j se utiliza en algunos de los servicios más importantes de la web, desde infraestructura de red como Amazon Web Services (AWS) y soluciones de Cisco hasta aplicaciones populares como Twitter y Minecraft.

Algunas versiones de Log4j (específicamente, Log4j 2.17.0 y anteriores) sufren vulnerabilidades graves. El más peligroso de ellos es Log4Shell (CVE-2021-44228; clasificación CVSS: 10), una ejecución remota de código (RCE) vulnerabilidad de día cero encontrado en las versiones 4 y anteriores de Log2.14.1j. 

Log4Shell es el resultado de cómo las versiones vulnerables de Log4j manejan Java Naming and Directory Interface (JNDI), una API que las aplicaciones Java utilizan para acceder a recursos alojados en servidores externos. Los actores de amenazas pueden tomar un control casi total de los sistemas vulnerables enviando comandos de búsqueda JNDI maliciosos a través de Log4j. Estos comandos engañan a la aplicación para que ejecute código arbitrario que puede hacer casi cualquier cosa: robar datos, instale ransomware, desconectar dispositivos y más.

Ataques Log4Shell

Un Log4Shell típico ciberataque funciona así: 

1. Un pirata informático configura un servidor utilizando un protocolo común, como el Protocolo ligero de acceso a directorios (LDAP) o el Sistema de nombres de dominio (DNS). 
2. El pirata informático almacena malware o alguna otra carga maliciosa en el servidor.
3. El hacker envía una búsqueda JNDI a una aplicación que ejecuta Log4j, dirigiendo la aplicación al servidor del hacker. 
4. La búsqueda JNDI hace que la aplicación se conecte al servidor del hacker, descargue la carga útil maliciosa y ejecute el código malicioso. 

Vulnerabilidades relacionadas de Log4j y cómo se explotan

Mientras Apache trabajaba para parchar Log4Shell, los investigadores de seguridad identificaron un puñado de fallas relacionadas en algunas versiones de Log4j. Éstas incluyen: 

• CVE-2021-45046 permite a los piratas informáticos enviar búsquedas JNDI maliciosas a sistemas que utilizan ciertas configuraciones no predeterminadas, incluso si esos sistemas han reparado Log4Shell. Presente en las versiones 4 y anteriores de Log2.15j.  
• CVE-2021-45105 permite a los piratas informáticos iniciar Ataques de denegación de servicio enviando mensajes maliciosos a Log4j. Presente en las versiones 4 y anteriores de Log2.16j. 
• CVE-2021-44832 es una vulnerabilidad de ejecución remota de código. Esta falla es menos crítica que Log4Shell porque los piratas informáticos necesitan obtener permisos elevados antes de poder explotarla. Presente en las versiones 4 y anteriores de Log2.17j.  

Cómo detectar vulnerabilidades de Log4j   

Encontrar todas las instancias vulnerables de Log4j en una red puede resultar complicado. Log4j aparece en un estimado millones de aplicaciones, lo que significa que los equipos de seguridad tienen muchos activos que inspeccionar. 

Además, Log4j suele estar presente como una dependencia indirecta. Eso significa que no está contenido directamente en el código fuente de un activo, sino que aparece como una dependencia de un paquete de software o una integración de la que depende el activo. Informes de Google que las instancias de Log4j más vulnerables se encuentran a más de un nivel de profundidad en la cadena de dependencias, y algunas tienen hasta nueve niveles de profundidad.

Dicho esto, los equipos de seguridad pueden detectar vulnerabilidades de Log4j con las tácticas y herramientas adecuadas.  

Qué buscar

Todas las versiones de Log4j 2 desde la 2.0-beta9 hasta la 2.17 son vulnerables a Log4Shell o una falla relacionada. Dicho de otra manera, los equipos de seguridad deben encontrar y abordar cualquier versión de Log4j anterior a la 2.17.1.

Log4Shell y sus fallas relacionadas solo están presentes en los archivos “Log4j-core”, que proporcionan la funcionalidad principal de Log4j. Las fallas no están presentes en los archivos “Log4j-api”, que controlan la interfaz entre las aplicaciones y los registradores Log4j.

Log4j puede aparecer en activos que controla la empresa, activos de terceros que utiliza la empresa (por ejemplo, servicios en la nube) y activos utilizados por proveedores de servicios con acceso a la red de la empresa. Si bien es más probable que Log4j aparezca en aplicaciones basadas en Java, también puede estar presente en aplicaciones que no son Java a través de dependencias e integraciones.

Dentro de las aplicaciones Java, las bibliotecas como Log4j suelen estar empaquetadas en archivos Java Archive o "archivos JAR". Los archivos JAR pueden contener otros archivos JAR, que a su vez pueden contener sus propios archivos JAR, y así sucesivamente. Para encontrar todas las versiones vulnerables de Log4j, los equipos de seguridad deben inspeccionar todos los niveles de archivos JAR, no solo los archivos de nivel superior.

como encontrarlo 

Los expertos recomiendan utilizar una combinación de técnicas para encontrar vulnerabilidades de Log4j.

Búsquedas manuales. Los equipos de seguridad pueden buscar manualmente fallas de Log4j. Pueden usar herramientas de desarrollo como Apache Maven para generar árboles de dependencia que mapeen todas las dependencias en una aplicación, o pueden usar herramientas externas. inteligencia de amenazas para identificar los activos afectados. Por ejemplo, la Agencia de Seguridad de Infraestructura y Ciberseguridad (CISA) compiló una lista de software que se sabe que sufre Log4Shell. La lista esta disponible en GitHub.

En los sistemas operativos Linux, Microsoft Windows y macOS, los equipos de seguridad pueden buscar en directorios de archivos instancias de Log4j utilizando la interfaz de línea de comandos.

Herramientas de escaneo de vulnerabilidades. Tras el descubrimiento de Log4Shell, algunas organizaciones lanzaron herramientas gratuitas diseñadas para encontrar vulnerabilidades de Log4j. Ejemplos incluyen Rastreador Log4j de Palantir y el escáner del Centro de Coordinación CERT, Entre muchos otros.

Si bien todavía hay escáneres especializados disponibles, muchas soluciones de seguridad estándar como escáneres de vulnerabilidad, gestión de superficie de ataque (ASM) plataformas y detección y respuesta de endpoints (EDR) ahora pueden detectar vulnerabilidades de Log4j.

Debido a que Log4Shell puede esconderse profundamente en las cadenas de dependencia, los equipos de seguridad pueden complementar los análisis automatizados con métodos más prácticos, como pruebas de penetración.

Caza de amenazas. Según CISA, se sabe que los atacantes utilizan Log4Shell para ingresar a una red y luego parchear el activo que comprometieron para cubrir sus huellas. Por ese motivo, se recomienda que los equipos de seguridad asuman que ya se ha producido una infracción y cazar activamente en busca de signos de explotación de Log4Shell.

Herramientas de ciberseguridad como información de seguridad y gestión de eventost (SIEM) soluciones y detección y respuesta extendidas (XDR) pueden ayudar a detectar actividades anormales asociadas con Log4Shell, como entradas de registro extrañas o patrones de tráfico sospechosos. Los equipos de seguridad deberían lanzarse por completo. respuesta al incidente y procedimientos de investigación para cualquier posible indicio de Log4Shell, dada la gravedad de las consecuencias de un ataque.

Cómo reparar las vulnerabilidades de Log4j

Los equipos de seguridad tienen algunas opciones al abordar las vulnerabilidades de Log4j.

El mejor caso: parchear sistemas vulnerables  

Para una corrección completa de Log4Shell y las fallas relacionadas, las organizaciones deben actualizar todas las instancias de Log4j en sus redes a la última versión (o al menos a la versión 2.17.1). Las últimas versiones de Log4j eliminan las funciones que los atacantes pueden explotar y eliminan la compatibilidad con protocolos de los que comúnmente se abusa, como LDAP.

No existe un parche único disponible para todo el sistema y la actualización de Java en sí no soluciona el problema. Los equipos de seguridad deben actualizar cada instancia de Log4j en cada activo afectado. 

Otras medidas de mitigación

Los investigadores de seguridad coinciden en que parcheo es la solución ideal. Si no es posible aplicar parches, las organizaciones pueden utilizar otras medidas de mitigación para minimizar las posibilidades de un ataque.

No permitir búsquedas de mensajes en aplicaciones vulnerables. Los atacantes utilizan una función de Log4j llamada "sustituciones de búsqueda de mensajes" para enviar comandos maliciosos a aplicaciones vulnerables. Los equipos de seguridad pueden desactivar manualmente esta función cambiando la propiedad del sistema "Log4j2.formatMsgNoLookups" a "verdadero" o estableciendo el valor de la variable de entorno "LOG4J_FORMAT_MSG_NO_LOOKUPS" en "verdadero".  

Si bien eliminar la función de sustitución de búsqueda de mensajes dificulta el ataque de los atacantes, no es infalible. Los actores malintencionados aún pueden usar CVE-2021-45046 para enviar búsquedas JNDI maliciosas a aplicaciones con configuraciones no predeterminadas.

Eliminación de la clase JNDIlookup de aplicaciones vulnerables. En Log4j, la clase JNDIlookup gobierna cómo el registrador maneja las búsquedas JNDI. Si esta clase se elimina del directorio de clases de Log4j, ya no se podrán realizar búsquedas JNDI.

APACHE señala que el siguiente comando se puede utilizar para eliminar la clase JNDIlookup de aplicaciones vulnerables:   

zip -q -d Log4j-core-*.jar org/apache/logging/Log4j/core/lookup/JndiLookup.class

Si bien este método es más efectivo que no permitir búsquedas de mensajes, no impide que los atacantes realicen otros intentos de explotación, como desencadenar ataques de denegación de servicio mediante búsquedas recursivas.

Bloquear el tráfico potencial de ataques Log4Shell. Los equipos de seguridad pueden utilizar firewalls de aplicaciones web (WAF), sistemas de detección y prevención de intrusos (IDPS), EDR y otras herramientas de ciberseguridad para interceptar el tráfico hacia y desde servidores controlados por atacantes mediante el bloqueo de protocolos de uso común como LDAP o RMI. Los equipos de seguridad también pueden bloquear Direcciones IP asociadas con ataques o las cadenas que los atacantes suelen utilizar en solicitudes maliciosas, como "jndi", "ldap" y "rmi".

Sin embargo, los atacantes pueden sortear estas defensas utilizando nuevos protocolos y direcciones IP u ocultando cadenas maliciosas.

Poner en cuarentena los activos afectados. Si todo lo demás falla, los equipos de seguridad pueden poner en cuarentena los activos afectados mientras esperan un parche. Una forma de hacerlo es colocando activos vulnerables en un segmento de red aislado al que no se puede acceder directamente desde Internet. Se puede colocar un WAF alrededor de este segmento de red para mayor protección.

Manteniendo Log4Shell a raya

Una de las cosas complicadas de remediar Log4Shell es que no siempre permanece parcheado. En noviembre de 2022, reportado sostenible que el 29% de los activos aún vulnerables a Log4Shell eran "recurrencias", lo que significa que fueron parcheados, pero la falla reapareció. Las recurrencias ocurren cuando los desarrolladores usan accidentalmente bibliotecas de software que contienen versiones sin parches de Log4j para crear o actualizar aplicaciones.

Si bien los desarrolladores pueden examinar más de cerca los marcos que utilizan, es fácil pasar por alto las versiones vulnerables de Log4j cuando tienen varios niveles de archivos JAR.

Implementación formal gestión de vulnerabilidades y manejo de parches Los programas pueden ofrecer a los equipos de seguridad una forma más eficaz de monitorear los activos para detectar el regreso de las vulnerabilidades de Log4j. El escaneo regular de vulnerabilidades y las pruebas de penetración pueden ayudar a detectar rápidamente nuevas vulnerabilidades, Log4Shell o de otro tipo. La gestión de parches garantiza que las nuevas vulnerabilidades se cierren tan pronto como los proveedores publiquen las correcciones.   

Más ayuda para combatir Log4Shell y otras vulnerabilidades de día cero

Cada vez más, los piratas informáticos utilizan herramientas automatizadas para explotar vulnerabilidades de día cero como Log4Shell con facilidad y lanzar una avalancha de ataques de ransomware y otras ciberamenazas. Los equipos de seguridad que trabajan con enfoques tradicionales de seguridad de endpoints enfrentan fatiga de alertas, herramientas complejas e investigaciones prolongadas, y luchan por mantenerse al día.

IBM Security® QRadar® EDR, anteriormente ReaQta, soluciona amenazas de endpoints conocidas y desconocidas casi en tiempo real con una automatización inteligente fácil de usar que requiere poca o ninguna interacción humana. Con QRadar EDR, los analistas pueden tomar decisiones rápidas e informadas y utilizar la gestión de alertas automatizada para centrarse en las amenazas más importantes. Las capacidades avanzadas de inteligencia artificial de aprendizaje continuo y una interfaz fácil de usar devuelven el control al personal de seguridad y ayudan a salvaguardar la continuidad del negocio.

Explorar IBM Security QRadar EDR