La vulnerabilidad Log4j, o "Log4Shell", está considerada como uno de los fallos de software más catastróficos de la historia. Aunque Apache parcheó el fallo en diciembre de 2021, sigue siendo una fuente de preocupación para los equipos de seguridad. De hecho, es uno de los fallos de seguridad más explotados.
Log4Shell persiste porque el paquete de software Apache Log4j 2 al que afecta es una de las bibliotecas de información de registro más utilizadas del mundo. Según el Departamento de Seguridad Nacional de EE. UU., se espera que encontrar y corregir 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.
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 mayores servicios de la web, desde infraestructuras de red como Amazon Web Services (AWS) y soluciones Cisco hasta aplicaciones populares como Twitter y Minecraft.
Algunas versiones de Log4j, en concreto, Log4j 2.17.0 e inferiores, sufren graves vulnerabilidades. La más peligrosa de ellas es Log4Shell (CVE-2021-44228; calificación CVSS: 10), una vulnerabilidad de día cero de ejecución remota de código (RCE) encontrada en las versiones 2.14.1 y anteriores de Log4j.
Log4Shell es el resultado de cómo las versiones vulnerables de Log4j manejan la interfaz de nombres y directorios de Java (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 maliciosos de búsqueda JNDI 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 mucho más.
Un ciberataque típico de Log4Shell funciona así:
Mientras Apache trabajaba para solucionar la vulnerabilidad Log4Shell, los investigadores de seguridad identificaron una serie de fallos relacionados con algunas versiones de Log4j. Entre ellos figuran:
Encontrar todas las instancias vulnerables de Log4j en una red puede ser difícil. Log4j aparece en 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 integración en la que se basa el activo. Google informa de 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 las 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 vulnerabilidad relacionada. En otras palabras, los equipos de seguridad deben identificar y abordar cualquier versión de Log4j anterior a la 2.17.1.
Log4Shell y sus defectos relacionados solo están presentes en los archivos "Log4j-core", que proporcionan la funcionalidad principal de Log4j. Los defectos 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 cloud) y activos utilizados por proveedores de servicios con acceso a la red de la empresa. Aunque 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 empaquetarse 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 los fallos de Log4j. Pueden utilizar herramientas de desarrollo como Apache Maven para generar árboles de dependencias que mapeen todas las dependencias de una aplicación, o pueden utilizar inteligencia de amenazas externas para identificar los activos afectados. Por ejemplo, la Agencia de Seguridad de Ciberseguridad e Infraestructura (CISA) compiló una lista de software conocido por sufrir 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 escaneo de vulnerabilidades. Tras el descubrimiento de Log4Shell, algunas organizaciones lanzaron herramientas gratuitas diseñadas para encontrar vulnerabilidades de Log4J. Los ejemplos incluyen el rastreador Log4j de Palantir y el escáner del Centro de Coordinación CERT, entre muchos otros.
Aunque todavía hay escáneres especializados disponibles, muchas soluciones de seguridad estándar, como escáneres de vulnerabilidades, 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.
Dado que Log4Shell puede ocultarse en lo profundo de las cadenas de dependencia, los equipos de seguridad pueden complementar los escaneos automatizados con métodos más prácticos, como las pruebas de penetración.
Búsqueda 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 ha producido una vulneració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 ampliadas (XDR), pueden ayudar a detectar actividades anómalas asociadas a 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 ante cualquier posible indicio de Log4Shell, dada la gravedad de las consecuencias de un ataque.
Los equipos de seguridad tienen varias opciones a la hora de abordar las vulnerabilidades de Log4j.
Para la corrección completa de Log4Shell y los fallos relacionados, 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 habitualmente, como LDAP.
No hay 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.
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 utilizar 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 estableciendo el valor de la variable de entorno "LOG4J_FORMAT_MSG_NO_LOOKUPS" en "true".
Aunque 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 controla cómo el registrador gestiona 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 las aplicaciones vulnerables:
zip -q -d Log4j-core-*.jar org/apache/logging/Log4j/core/lookup/JndiLookup.class
Aunque este método es más eficaz que deshabilitar las búsquedas de mensajes, no impide que los atacantes realicen otros intentos de explotación, como desencadenar ataques de denegación de servicio a través de búsquedas recursivas.
Bloqueo del tráfico potencial de ataques de Log4Shell. Los equipos de seguridad pueden utilizar firewalls 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 a los ataques o las cadenas que los atacantes suelen utilizar 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 remediar Log4Shell es que no siempre permanece parcheado. En noviembre de 2022, Tenable informó de que el 29 % de los activos que seguían siendo vulnerables a Log4Shell eran "recurrencias", lo que significa que estaban parcheados, pero el fallo reapareció. Las recurrencias se producen cuando los desarrolladores utilizan accidentalmente bibliotecas de software que contienen versiones sin parches de Log4j para crear o actualizar aplicaciones.
Aunque los desarrolladores pueden examinar con más detenimiento los marcos que utilizan, es fácil pasar por alto las versiones vulnerables de Log4j cuando se encuentran en varios niveles de profundidad dentro de 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 monitorizar los activos para detectar el retorno 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.