1. Introduction
The Atlassian JIRA ConfigureReport.jspa ‘reportKey’ Information Disclosure vulnerability allows an unauthenticated attacker to access sensitive information from a JIRA web server by manipulating the ‘reportKey’ parameter. This can expose operating system, database, and build versions, potentially aiding further attacks. Confidentiality is most at risk, but integrity could be affected if attackers use exposed details for targeted exploits.
2. Technical Explanation
The vulnerability stems from insufficient input validation in the ConfigureReport.jspa endpoint of JIRA installations. An attacker can set an invalid ‘reportKey’ parameter to trigger an error page that reveals internal system information. This is a common information leakage issue, often found in web applications with verbose error handling.
- Root cause: Missing input validation on the ‘reportKey’ parameter within ConfigureReport.jspa.
- Exploit mechanism: An attacker sends a crafted HTTP request to ConfigureReport.jspa with an invalid ‘reportKey’ value, causing JIRA to display an error page containing system details. For example:
https://[target]/secure/ConfigureReport.jspa?reportKey=invalid_key - Scope: Affected versions of Atlassian JIRA are reportedly vulnerable; however, specific affected ranges were not provided in the available context.
3. Detection and Assessment
Confirming vulnerability requires checking the JIRA version and testing the ConfigureReport.jspa endpoint for information disclosure.
- Quick checks: Access the JIRA administration interface to determine the installed JIRA version.
- Scanning: Nessus detected this issue, but did not test for related cross-site scripting vulnerabilities. Other vulnerability scanners may have signatures for this issue; check your scanner documentation.
- Logs and evidence: Examine web server logs for requests to ConfigureReport.jspa with unusual parameters. Look for error responses containing system information.
4. Solution / Remediation Steps
The solution involves modifying the JIRA 500 error page to remove sensitive information.
4.1 Preparation
- No services need to be stopped for this remediation.
- Roll back involves restoring the original error page configuration. A change window may be required depending on your organization’s policies.
4.2 Implementation
- Step 1: Access the JIRA knowledge base article at https://id.atlassian.com/login?continue=https%3A%2F%2Fid.atlassian.com%2Fopenid%2Fv2%2Fop%3Fopenid.return_to%3Dhttps%3A%2F%2Fconfluence.atlassian.com%2Fplugins%2Fservlet%2Fauthentication%3Fauth_plugin_original_url%253D%25252Fjirakb%25252Fremove-information-from-the-500-error-page-oops-an-error-has-occurred-282174657.html%26openid.ns%3Dhttp%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0%26openid.ns.sreg%3Dhttp%3A%2F%2Fopenid.net%2Fsreg%2F1.0%26openid.assoc_handle%3D11685648%26openid.identity%3Dhttp%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0%2Fidentifier_select%26openid.realm%3Dhttps%3A%2F%2F*.atlassian.com%26openid.claimed_id%3Dhttp%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0%2Fidentifier_select%26openid.sreg.required%3Dfullname%2Cnickname%2Cemail%26openid.mode%3Dcheckid_setup
- Step 2: Follow the instructions in the article to modify the JIRA 500 error page template. This typically involves removing or commenting out sections that display system information.
4.3 Config or Code Example
Before
After
4.4 Security Practices Relevant to This Vulnerability
Input validation and secure error handling are key practices for preventing this type of vulnerability. Least privilege can limit the impact if exploited.
- Practice 1: Input validation prevents attackers from injecting malicious data that triggers unintended behavior, such as information disclosure.
- Practice 2: Secure error handling avoids revealing sensitive system details in error messages.
4.5 Automation (Optional)
No automation is provided for this vulnerability due to the complexity of modifying JIRA’s configuration files.
5. Verification / Validation
Confirm the fix by attempting to trigger the information disclosure again and verifying that sensitive details are no longer displayed on the error page.
- Post-fix check: Access
https://[target]/secure/ConfigureReport.jspa?reportKey=invalid_key. The resulting error page should display a generic error message without revealing system information.