Llevo ya algunos meses inspecionando este producto llamado JIRA desarrollado por Atlassian y me sorprenden 2 aspectos concretos: la cantidad de vulnerabilidades y falencias de configuración con la que cuentan en sus distintas versiones la herramienta y lo popular que parece en la red (Internet).
La idea de esta entrada es poder describir una serie de vulnerabilidades conocidas en JIRA de distinta tipología y presentar algunas PoC (pruebas de concepto) que he desarrollado para automatizar la explotación de algunas de esta vulnerabilidades descritas. Espero que sea de utilidad.
Recopilación de datos de usuarios a través del log activity
Arrancamos con este registro de datos temporal (log) llamado activity, que en alguna ocasión ya lo hemos descrito en el blog, sin embargo quiero aprovechar esta entrada para actualizar la versión del script que automatiza la extracción de los datos de usuarios hallados en el log. Pero antes veamos un poco de que se trata esta divulgación de información.
Un gran número de aplicativos JIRA cuenta con este fichero expuesto y accesible, si el mismo no se encuentra especialmente tratado, suele exponer una serie de información referente a movimientos y actividades (de ahí el nombre) realizados recientemente por los usuarios de la plataforma. Aquí un ejemplo de lo que veremos:
Como se evidencia en la imagen aquí tendremos identificar al menos 3 datos relevantes enmarcados bajo determinadas etiquetas:
- <name></name> Contiene el nombre completo registrado del usuario.
- <email></email> Contiene la cuenta de correo electrónico del usuario.
- <uri></uri> Esta etiqueta contiene la ruta de acceso (URL) al perfil del usuario, de la parte final se logra obtener el nombre de usuario (username).
Adicionalmente se observa en el recuadro superior el dato referente a la fecha de registro de la actividad acontecida. En la etiqueta <updated></updated>.
Para aprovechar esta condición he generado el script en bash llamado UserEnumJira.sh que automatiza esta recopilación que lo presentaría de la siguiente manera:
Para su ejecución basta con definir la URL del aplicativo JIRA:
En caso de no contar con acceso al recurso activity o en su defecto en caso de que dicho recurso se encuentre vacío o sin la información necesaria el resultado de la ejecución del script será el siguiente:
Finalmente a modo de guía para el usuario que utilice el script, se me ocurrió generar un par de validaciones en la inserción del objetivo de análisis, para “instar” al usuario que introduzca el activo adecuadamente (o al menos como se espera que lo haga).
Vulnerabilidad CVE-2020-14181 – Enumeración de usuarios
Esta vulnerabilidad fue detectada por la gente de Positive Technologies, en concreto por el investigador de seguridad Mikhail Klyuchnikov (@mn1), yo la vi publicada el pasado octubre a través del siguiente Tweet:
Bastante curiosa la vulnerabilidad identificada para nuestros días e incluso alguno no tardo en indicar que se trata de una referencia antigua, sin embargo y como fuese, el proveedor lo gestionó recientemente a través del ticket JRASERVER-71560.
La vulnerabilidad se presenta en el recurso (endpoint) /ViewUserHover.jspa y es dada debido a que la plataforma resuelve de distinta manera al enviar una petición GET a la siguiente URL:
https://OBJETIVO/secure/ViewUserHover.jspa?username=USUARIO
La plataforma validará el valor del parámetro username y nos indicará cuando el usuario es inválido, a través del siguiente mensaje: “User does not exist / El usuario no existe”, por tanto, todo lo que no devuelva este resultado, se considerará un usuario válido.
El automatismo que preparé para este caso trabaja con esta condición y a partir de un diccionario proporcionado nos listará los usuarios existente en la plataforma JIRA objetivo. A continuación os dejo una demo del funcionamiento:
Podéis obtener el script desde el siguiente repositorio de GitHub: PoC_CVE-2020-14181.sh
Vulnerabilidad CVE-2019-3403 – Enumeración de usuarios
Esta vulnerabilidad es muy similar a la CVE-2020-14181, descrita anteriormente. En este caso la divulgación se produce en el recurso /rest/api/2/user/picker y es dada debido a una verificación de autorización incorrecta, es decir, basta con acceder a la siguiente URL:
https://OBJETIVO/rest/api/2/user/picker?query=USUARIO
En donde el valor del parámetro query puede ser “randomizado”.
En este caso, si el valor del parámetro query coincide con un usuario válido en la plataforma JIRA obtendremos un resultado similar al siguiente:
Por lo contrario, si el valor del parámetro query no coincide con un usuario existente, la respuesta es distinta.
Mas información de la vulnerabilidad en el ticket del proveedor: JRASERVER-69242
A continuación la correspondiente demo del funcionamiento del script que he preparado para aprovechar esta vulnerabilidad:
Podéis obtener el script desde el siguiente repositorio de GitHub: PoC_CVE-2019-3403.sh
Vulnerabilidad CVE-2019-8449 – Enumeración de usuarios
Otro recurso web que nos permite conseguir la enumeración de usuarios a través de consultas directas al servidor dado los mensajes de respuesta. En este caso la revelación de información se produce en el recurso: /rest/api/latest/groupuserpicker, que permite generar peticiones GET similares a la siguiente:
https://OBJETIVO/rest/api/latest/groupuserpicker?query=USUARIO
En donde el valor del parámetro query puede ser “randomizado” una vez más.
Mas información de la vulnerabilidad en el ticket del proveedor: JRASERVER-69796
Para este caso he generado el siguiente script funcional que basta con definir la URL del objetivo y el diccionario de palabras para aprovechar la vulnerabilidad:
Podéis obtener el script desde el siguiente repositorio de GitHub: PoC_CVE-2019-8449.sh
Vulnerabilidad CVE-2018-5230 – Cross Site Scripting (XSS)
Esta vulnerabilidad está bastante entretenida en su modo de explotación. La primera vez que la vi fue a través del siguiente reporte de HackerOne: https://hackerone.com/reports/380354, que básicamente se trata de un problema en el llamado “issue collector” el cual cuenta con algunos campos que no sanitizan las entradas de los usuarios y en las respuesta de error que da el aplicativo interpreta la inserción, permitiendo ejecutar código arbitrario (HTML o JavaScript).
Los pasos básicos para reproducir esta vulnerabilidad normalmente son los siguientes:
- Vaya al enlace tipo:
https://OBJETIVO/issues/?filter=-8
- Haga clic en el apartado «Fecha de Actualización«
- Escriba un número en la opción «Hace más de X minutos» e intercepte la petición con Burp
- Haga clic en «Actualizar«
- En la petición interceptada, localiza el parámetro updated%3Anext y reemplace el valor o añada al final un payload. Por ejemplo:
<script>alert('XSS')</script>
- Vuelve al navegador y visualice la explotación del XSS (PoC)
Mas información de la vulnerabilidad en el ticket del proveedor: JRASERVER-67289
Vulnerabilidad CVE-2018-20824 – Cross Site Scripting (XSS)
A través de esta vulnerabilidad conseguiremos un “bonito” XSS reflejado. Se produce en el plugin Wallboard, más concretamente en el parámetro cyclePeriod el cual permite insertar código arbitrario (HTML o JavaScript) que será reproducido por el aplicativo JIRA. Para reproducir esta vulnerabilidad basta con enviar la siguiente petición GET al servidor:
https://OBJETIVO/plugins/servlet/Wallboard/?dashboardId=10000&dashboardId=10000&cyclePeriod=alert(/XSS/)
Mas información de la vulnerabilidad en el ticket del proveedor: JRASERVER-69238
Vulnerabilidad CVE-2017-9506 – Server Side Request Forgery (SSRF)
Esta vulnerabilidad se produce en el complemento IconUriServlet, en principio está reportada como SSRF (Server Side Request Forgery), lo cual será bastante interesante (de darse las condiciones idóneas) si lo que pretendemos es indagar algo más en la infraestructura interna del objetivo. Asimismo aprovecharemos sus condiciones para exponer otras vulnerabilidades derivadas como por ejemplo Cross Site Scripting (XSS), pero vamos primero con la PoC del SSRF.
Lo primero será tener claro a que nos referimos cuando hablamos de una vulnerabilidad de SSRF y dado que existen cientos de recursos que nos lo explican mejor de lo que yo podría hacerlo en 2 líneas, te invito a visitar por ejemplo la documentación de PortSwigger: https://portswigger.net/web-security/ssrf (en donde ya de paso cuentas con laboratorios donde poder poner en práctica la teoría).
Bien, volviendo a la vulnerabilidad de JIRA, para poder demostrar la vulnerabilidad podremos apoyarnos en 2 simples técnicas, una es a través de una llamada al buscador de Google, para ello haremos la siguiente petición GET al servidor:
https://OBJETIVO/plugins/servlet/oauth/users/icon-uri?consumerUri=https://google.com
La otra demostración será una petición GET al recurso ipinfo.io, el cual nos presentará una serie de datos referente a la dirección IP desde donde se produce la llamada. Entre los datos obtendremos: dirección IP pública, nombre del host, origen de la dirección IP, ubicación y otros datos del proveedor. A continuación un ejemplo de la petición GET generada:
https://OBJETIVO/plugins/servlet/oauth/users/icon-uri?consumerUri=https://ipinfo.io/json
Finalmente y volviendo a lo comentado anteriormente, podremos demostrar otro XSS reflejado, también de simple identificación y reproducción, a través de un recurso que tengamos preparado, yo en este caso puedo llegar a subir a un servidor externo un fichero que me refleje vía JavaScript un alert con el dominio (document.domain) del host. A continuación las muestras de los ficheros preparados:
- poc.html
<script>alert(document.domain)</script>
- poc.svg
<svg xmlns="http://www.w3.org/2000/svg" onload="alert(document.domain)"/>
Quedando la vulnerabilidad evidenciada a través de la siguiente URL:
https://OBJETIVO/plugins/servlet/oauth/users/icon-uri?consumerUri=http://xss-site.orgfree.com/poc.html
Mas información de la vulnerabilidad en el ticket del proveedor: OAUTH-344
La idea de esta entrada principalmente es recopilar y reagrupar todas aquellas validaciones posibles que podemos hacer cuando tengamos un activo en donde evidenciemos que se ejecuta un JIRA. Este producto nos dará mucho juego como ha quedado demostrado y obviamente todo estará sujeto a las versiones y los controles de capas adicionales. Espero que resulte de provecho. Happy Hacking!
Referencias
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14181
- https://jira.atlassian.com/browse/JRASERVER-71560
- https://twitter.com/ptswarm/status/1318914772918767619
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-3403
- https://jira.atlassian.com/browse/JRASERVER-69242
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-8449
- https://jira.atlassian.com/browse/JRASERVER-69796
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-5230
- https://jira.atlassian.com/browse/JRASERVER-67289
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20824
- https://jira.atlassian.com/browse/JRASERVER-69238
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9506
- https://ecosystem.atlassian.net/browse/OAUTH-344
- https://dontpanic.42.nl/2017/12/there-is-proxy-in-your-atlassian.html