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, sigue estando entre las 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. Según el Departamento de Seguridad Nacional de EE. UU., se espera que encontrar y arreglar cada instancia de Log4Shell lleve una década.
Mientras tanto, los equipos de seguridad pueden tomar algunas medidas para acelerar la mitigación y corrección de Log4Shell en sus redes.
Únase a los líderes de seguridad que confían en el boletín Think para obtener noticias seleccionadas sobre IA, ciberseguridad, datos y automatización. Aprende rápido con tutoriales de expertos y documentos explicativos, que se envían directamente a su bandeja de entrada. Consulte la Declaración de privacidad de IBM.
Antes de profundizar en cómo detectar y aplicar parches a 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 grandes de la web, que van desde la infraestructura de red como Amazon Web Services (AWS) y soluciones de Cisco hasta aplicaciones como Twitter y Minecraft.
Algunas versiones de Log4j, específicamente Log4j 2.17.0 e inferiores, sufren vulnerabilidades graves. La más peligrosa es Log4Shell (CVE-2021-44228; calificación CVSS: 10), una vulnerabilidad de día cero de ejecución remota de código (RCE) que se encuentra en las versiones 2.14.1 y anteriores de Log4j.
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 los recursos alojados en servidores externos. Los actores de amenazas pueden tomar el 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, instalar ransomware, desconectar dispositivos y más.
Un ciberataque típico de Log4Shell funciona así:
Mientras Apache trabajaba para parchear Log4Shell, los investigadores de seguridad identificaron unas cuantas fallas relacionadas en algunas versiones de Log4j. Estas incluyen:
Encontrar todas las instancias vulnerables de Log4j en una red puede ser difícil. Log4j aparece en aproximadamente millones de aplicaciones, lo que significa que los equipos de seguridad tienen muchos activos para 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 integración de la que depende el activo. Google informa que las instancias de Log4j más vulnerables tienen 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.
Todas las versiones de Log4j 2 desde la 2.0-beta9 hasta la 2.17 son vulnerables a Log4Shell o a 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 a menudo se empaquetan 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 los archivos JAR, no solo los archivos de nivel superior.
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 las fallas de Log4j. Pueden usar herramientas de desarrollo como Apache Maven para generar árboles de dependencias que mapeen todas las dependencias en una aplicación, o pueden usar inteligencia de amenazas externas para identificar los activos afectados. Por ejemplo, la Cybersecurity and Infrastructure Security Agency (CISA) compiló una lista de software que se sabe que sufre de Log4Shell. La lista está disponible en GitHub.
En los sistemas operativos Linux, Microsoft Windows y macOS, los equipos de seguridad pueden buscar instancias de Log4j en los directorios de archivos mediante la interfaz de línea de comandos.
Herramientas de análisis de vulnerabilidades. Tras el descubrimiento de Log4Shell, algunas organizaciones lanzaron herramientas gratuitas diseñadas para encontrar vulnerabilidades de Log4j. Algunos ejemplos incluyen el Log4j-sniffer 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 vulnerabilidades, las plataformas de gestión de superficies de ataque (ASM) y soluciones de detección y respuesta de endpoints (EDR) ahora pueden detectar vulnerabilidades de Log4j.
Debido a que Log4Shell puede ocultarse en lo profundo de las cadenas de dependencia, los equipos de seguridad pueden complementar los análisis automatizados con métodos más prácticos, como pruebas de inserción.
Caza de amenazas. Según CISA, se sabe que los atacantes utilizan Log4Shell para irrumpir en una red y luego parchear el activo que comprometieron para cubrir sus huellas. Por esa razón, se recomienda que los equipos de seguridad asuman que ya se produjo una violación y busquen activamente signos de explotación de Log4Shell.
Las herramientas de ciberseguridad, como las soluciones de gestión de eventos e información de seguridad(SIEM) y las plataformas de 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 deben poner en marcha procedimientos completos de respuesta e investigación de incidentes para cualquier posible indicio de Log4Shell, dada la gravedad de las consecuencias de un ataque.
Los equipos de seguridad tienen algunas opciones al abordar las vulnerabilidades de Log4j.
Para la corrección completa de Log4Shell y 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 se abusa comúnmente, como LDAP.
No hay un único parche 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.
Los investigadores de seguridad coinciden en que la aplicación de parches es la solución ideal. Si la aplicación de parches no es factible, las organizaciones pueden usar otros pasos de mitigación para minimizar las posibilidades de un ataque.
No permitir búsquedas de mensajes en aplicaciones vulnerables. Los atacantes utilizan una característica 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 "true" o establecer el valor de la variable de entorno "LOG4J_FORMAT_MSG_NO_LOOKUPS" en "true".
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 maliciosos 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 las aplicaciones vulnerables. En Log4j, la clase JNDIlookup rige 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 usar para eliminar la clase JNDIlookup de las aplicaciones vulnerables:
zip -q -d Log4j-core-*.jar org/apache/logging/Log4j/core/lookup/JndiLookup.class
Si bien este método es más eficaz que no permitir las búsquedas de mensajes, no impide que los atacantes realicen otros intentos de explotación, como desencadenar ataques de denegación del servicio a través de búsquedas recursivas.
Bloqueo del tráfico potencial de ataques de Log4Shell. Los equipos de seguridad pueden utilizar cortafuegos de aplicaciones web (WAF), sistemas de detección y prevención de intrusiones (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 usar en solicitudes maliciosas, como "jndi", "ldap" y "rmi".
Sin embargo, los atacantes pueden eludir estas defensas utilizando nuevos protocolos y direcciones IP u ofuscando 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 colocar los 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 una protección adicional.
Una de las cosas difíciles de corregir Log4Shell es que no siempre se mantiene parcheado. En noviembre de 2022, Tenable informó que el 29 % de los activos que aún eran vulnerables a Log4Shell eran "recurrencias", lo que significa que estaban 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 las infraestructuras que utilizan, es fácil pasar por alto las versiones vulnerables de Log4j cuando tienen varios niveles de profundidad en los archivos JAR.
La implementación de programas formales de gestión de vulnerabilidades y gestión de parches puede ofrecer a los equipos de seguridad una forma más eficaz de monitorear los activos para detectar el retorno de las vulnerabilidades de Log4j. El análisis periódico 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 los arreglos.