Shulou(Shulou.com)05/31 Report--

What is the vulnerability of sensitive information disclosure caused by path traversal of Jira service workbench? aiming at this problem, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

By testing the permissions of ordinary users and administrator accounts under the JIRA Servcie Desk application, the author finds that some sensitive information under the critical path of the administrator account can be accessed by ordinary users, which will have a serious security impact on collaborative team projects (CVE-2019-14994). The following is the author's simple reproduction and sharing of the vulnerability.

JIRA Servcie Desk introduction

JIRA Servcie Desk is the core product of Atlassian's JIRA applications. It is a help desk management software designed to receive and handle questions or requests from teams or users. It also has other ancillary functions similar to service centers, including handling service agreements, reports, queues, receiving questions and feedback from external sources through website portals or e-mails. JIRA Servcie Desk is specially designed for end users to submit work orders to customer support teams. It is also suitable for development teams and can be used with similar products such as JIRA Software.

JIRA Servcie Desk has two main management portals:

User Portal (Customer portal): access is mainly achieved through the / servicedesk/ directory

Administrator Portal (Administrative portal): access is mainly achieved through the / secure/ directory

Vulnerability situation

The principle of the vulnerability is that if the attacker is an ordinary user with access to the user portal (Customer portal), he can traverse the list of all instance issues submitted by the JIRA project in the administrator portal (Administrative portal), including Jira Service Desk itself, Jira Core projects, Jira Software, and so on.

The conditions under which the vulnerability can be exploited are:

1. The setting option of `anyone can email the service desk or raise a request in the portal` in JIRA Servcie Desk is enabled (anyone can send email to the help desk or make a request on the portal)

2. After the above settings are enabled, the attacker can authenticate and submit a ticket (Support Ticket) to JIRA Servcie Desk normally.

The vulnerability affects the version:

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)

Loophole recurrence

First of all, we want to check whether the target JIRA project instance is running a JIRA Servcie Desk service, which can be verified by the following link:

Https://target.com/servicedesk/

If the target JIRA project does run a JIRA Servcie Desk service, the following administrative login interface is returned:

From the login screen above, click the registration ("Sign up") button to complete the registration. Note that if the registration ("Sign up") button is not displayed here, the vulnerability cannot be exploited unless you have an internal employee account that can log in to the administrative interface. After registration, we can go to the user Portal (Customer portal) page:

Next, as the ordinary user (Customer), we initiate a request for the secure directory / secure/ under the administrator account (Administrator). Combined with other packet capture agents such as Burp (if only browsers are used, the normalization of URL will not lead to successful exploit), we construct the request as follows:

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

Note that depending on the version of JIRA Servcie Desk, the following URL symbol construction is needed to traverse the path:

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

Finally, if there is a vulnerability in the target JIRA Servcie Desk, a project browsing (Browse Projects) page that appears to be a bad page is returned:

That is to say, the Customer of ordinary users can access some page information under the administrator portal. However, because most of the functions in the administrator portal are implemented through APIs, but its APIs handling of URL characters is strange and problematic, which makes normal browsing seem like a bad page.

Further exploitation of this vulnerability is to construct requests that, combined with jqlQuery queries, export all interested organizational data. Try it:

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

If the target JIRA Servcie Desk server returns "not found", you can also try to obtain the relevant data by requesting the following URL. The request will return all the data information related to the query, of course, you can change the jqlQuery query parameters to something else.

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

For example, the following query returns the relevant organization page data information of HTML:

Supplementary explanation

What is strange is that JIRA's own authentication mechanism, under its normal circumstances, if ordinary users or internal employees access the administrator directory / secure/ or / sr/, mentioned above through the browser will be blocked and redirected to the normal user portal page. This simple URL matching redirect jump seems to be a security protection mechanism for the administrator portal by JIRA itself. After that, JIRA gave the following simple fix:

^ / [^?] *.

This fix is a bit ridiculous, it only declares the limited access rules of users, that is, they jump what they access. After the fix is implemented, attackers can also access the relevant functions of the administrator portal through some fuzz or coding techniques.

This is the answer to the question about the vulnerability of sensitive information disclosure caused by traversing the path of the Jira service workbench. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel for more related knowledge.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.