How to remediate – Request Tracker 3.8.x < 3.8.17 / 4.x < 4.0.13 Multiple Vulnera...

1. Introduction

The Request Tracker 3.8.x prior to 3.8.17 and 4.x prior to 4.0.13 application is affected by multiple vulnerabilities. This Perl-based issue management system can be exploited remotely, potentially allowing attackers to gain elevated privileges or inject malicious code. Systems running these versions of Request Tracker are at risk of data breaches, service disruption, and unauthorized access. The likely impact on confidentiality, integrity, and availability is medium.

2. Technical Explanation

The vulnerabilities stem from flaws in the application’s handling of authentication, file management, input validation, and session security. A remote attacker with ‘ModifyTicket’ privileges can gain ‘DeleteTicket’ access without proper authorisation (CVE-2012-4733). The ‘rt’ command line tool uses predictable temporary files which a local attacker could overwrite using symlinks (CVE-2013-3368). Other flaws allow calling arbitrary Mason components, direct requests to private callback components, cross-site scripting via attachment filenames and MIME headers in email templates. An information disclosure vulnerability exists due to Apache::Session::File session store reuse. Finally, improper URL validation when the ‘MakeClicky’ component is enabled can lead to XSS attacks (CVE-2013-5587).

• Root cause: flaws in authentication checks, insecure temporary file handling, insufficient input validation, and session management issues.
• Exploit mechanism: An authenticated attacker with ‘ModifyTicket’ privileges could delete tickets they should not have access to. A local user can overwrite arbitrary files using symlinks when running the ‘rt’ command line tool. Remote attackers can inject scripts or HTML via various vectors.
• Scope: Request Tracker versions 3.8.x prior to 3.8.17 and 4.x prior to 4.0.13 are affected.

3. Detection and Assessment

Confirming vulnerability requires checking the application’s version number. A thorough assessment involves reviewing logs for suspicious activity and testing input fields for potential XSS vulnerabilities.

• Quick checks: Check the Request Tracker version via its web interface (usually in the ‘About’ section or similar).
• Scanning: Nessus has not tested these issues, but relies on self-reported version numbers. Consider using vulnerability scanners that can identify Request Tracker and report versions.
• Logs and evidence: Examine application logs for unusual activity related to ticket modification, file access, or Mason component calls. Look for error messages indicating input validation failures.

# Example command placeholder:
# No specific command available without knowing the RT installation path. Check version via web interface.

4. Solution / Remediation Steps

4.1 Preparation

• Call out dependencies or pre-requisites: Ensure you have access to the latest version of Request Tracker and understand the upgrade process outlined in its documentation. A roll back plan is to restore from the earlier backup.

4.2 Implementation

1. Step 1: Download the latest version of Request Tracker (3.8.17 or 4.0.13 or later) from the official Best Practical Solutions website.
2. Step 2: Stop the web server hosting Request Tracker.
3. Step 3: Back up the existing Request Tracker installation directory.
4. Step 4: Extract the new version of Request Tracker to a temporary location.
5. Step 5: Copy the contents of the extracted directory to the original installation directory, overwriting existing files.
6. Step 6: Verify file permissions are correct for the web server user.
7. Step 7: Start the web server hosting Request Tracker.

4.3 Config or Code Example

Before

# No specific config example as this requires an upgrade of the entire application.
# Check version via web interface to confirm pre-upgrade status.

After

# No specific config example as this requires an upgrade of the entire application.
# Check version via web interface to confirm post-upgrade status (3.8.17 or 4.0.13 or later).

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help mitigate risks associated with this type of vulnerability. Least privilege reduces the impact if an account is compromised. Input validation prevents malicious code injection. A regular patch cadence ensures timely application of security updates.

• Practice 1: Implement least privilege principles, limiting user access to only necessary functions and data.
• Practice 2: Enforce strict input validation on all user-supplied data to prevent cross-site scripting and other injection attacks.

4.5 Automation (Optional)

Automation is not recommended for this vulnerability due to the complexity of the upgrade process. Manual verification is essential.

# No automation script provided as it's too risky without detailed knowledge of the environment.

5. Verification / Validation

• Post-fix check: Check the Request Tracker version via its web interface; it should display 3.8.17 or 4.0.13 or later.
• Re-test: Attempt to exploit the vulnerabilities described earlier (e.g., try deleting tickets with limited privileges). The actions should be blocked.
• Smoke test: Verify that core functionality, such as ticket creation and modification, still works as expected.
• Monitoring: Monitor application logs for any errors or suspicious activity related to authentication, authorization, or input validation.

# Post-fix command and expected output:
# Check version via web interface - Expected Output: Request Tracker 3.8.17 or later (or 4.0.13 or later)

6. Preventive Measures and Monitoring

Regularly update security baselines to include the latest versions of Request Tracker. Implement automated checks in CI/CD pipelines to prevent deployment of vulnerable code. Establish a patch review cycle that aligns with the risk profile of your organization. For example, scan for vulnerabilities weekly and apply critical patches within 72 hours.

• Baselines: Update security baselines or policies to require Request Tracker versions 3.8.17 or later (or 4.0.13 or later).
• Asset and patch process: Implement a regular patch review cycle, prioritizing critical security updates.

7. Risks, Side Effects, and Roll Back

• Risk or side effect 2: Service interruption during the upgrade process. Mitigation: Schedule the upgrade during a maintenance window.
• Roll back: