1. Introduction
The Request Tracker 3.x application, specifically versions prior to 3.8.9, is affected by security bypass and information disclosure vulnerabilities. This means a logged-out user could regain access using the browser’s back button, and sensitive SQL query data may be exposed in logs. These issues pose a medium risk to businesses as they can lead to unauthorised access to customer support tickets and potentially reveal database structure details. Affected systems are typically web servers running Best Practical Solutions Request Tracker (RT). Likely impact is moderate confidentiality loss, low integrity compromise, and low availability disruption.
2. Technical Explanation
- Root cause: The application does not invalidate sessions correctly when a user logs out, allowing access via browser history. SQL queries are logged without sufficient redaction or control.
- Exploit mechanism: A valid RT user logs out but keeps their browser open. An attacker with access to that browser uses the ‘back’ button to return to the previous account page and gain access. Information disclosure occurs when a user transitions, and the application logs unfiltered SQL queries.
- Scope: Request Tracker 3.x versions prior to 3.8.9 are affected. This includes installations on Linux, Windows, and other platforms where RT is supported.
3. Detection and Assessment
Confirming vulnerability requires checking the installed version of Request Tracker. A thorough assessment involves reviewing application logs for exposed SQL queries.
- Quick checks: Check the RT version via the web interface (usually in the ‘About’ section or similar).
- Scanning: Nessus plugin ID 68791 can identify vulnerable versions, but relies on self-reported information.
- Logs and evidence: Examine application logs for SQL queries containing sensitive data during user transitions. Log file locations vary by installation but are often found in /var/log/rt or similar directories.
# Example command placeholder:
# Check RT version via the command line (if available)
# rt --version
4. Solution / Remediation Steps
The primary solution is to upgrade Request Tracker to version 3.8.9 or later. This addresses both the session bypass and information disclosure vulnerabilities.
4.1 Preparation
- Ensure you have a tested rollback plan in case of upgrade issues. A simple rollback involves restoring the pre-upgrade backup.
- A change window may be required depending on your environment and downtime tolerance. Approval from relevant IT stakeholders is recommended.
4.2 Implementation
- Step 1: Download the latest version of Request Tracker (3.8.9 or later) from the official Best Practical Solutions website.
- Step 2: Stop the web server service running RT.
- Step 3: Back up the existing RT installation directory.
- Step 4: Extract the new RT version to a temporary location.
- Step 5: Copy the contents of the new RT directory to your production installation directory, overwriting existing files.
- Step 6: Restore any custom configurations from your backup.
- Step 7: Run any necessary database upgrade scripts provided with the new version.
- Step 8: Start the web server service.
4.3 Config or Code Example
Before
# No specific configuration example available, as the fix is within the application code itself. Prior versions may log full SQL queries without redaction.After
# After upgrading to 3.8.9 or later, verify that SQL query logging is configured appropriately (if enabled) and does not expose sensitive data. Check the RT documentation for details on log configuration options.4.4 Security Practices Relevant to This Vulnerability
Several security practices can help mitigate risks associated with this type of vulnerability.
- Practice 1: Least privilege – limit user access rights to only what is necessary, reducing the impact if an account is compromised.
- Practice 3: Patch cadence – Regularly update applications and systems to address known vulnerabilities promptly.
4.5 Automation (Optional)
# Example Ansible snippet for upgrading RT (requires appropriate modules installed):
# - name: Stop web server service
# service: name={{ web_server_service }} state=stopped
# - name: Backup existing RT installation
# archive: path={{ rt_install_dir }} dest=/tmp/rt_backup.tar.gz
# - name: Extract new RT version
# unarchive: src={{ rt_download_url }} dest={{ rt_install_dir }}
# - name: Start web server service
# service: name={{ web_server_service }} state=started
5. Verification / Validation
Confirm the upgrade was successful and the vulnerabilities are resolved by checking the version number and verifying session management.
- Post-fix check: Check the RT version via the web interface; it should display 3.8.9 or higher.
- Smoke test: Verify that users can log in, create tickets, and perform other core functions without issue.
- Monitoring: Monitor application logs for any unexpected errors or suspicious activity related to session management or SQL queries.
# Post-fix command and expected output (example):
# rt --version
# 3.8.9
6. Preventive Measures and Monitoring
Several measures can help prevent similar vulnerabilities in the future.
- Baselines: Update your security baseline to include a requirement for keeping Request Tracker up-to-date with the latest patches.
- Asset and patch process: Implement a regular patch review cycle, prioritizing critical security updates like those for Request Tracker.
7. Risks, Side Effects, and Roll Back
Upgrading Request Tracker may introduce compatibility issues with custom plugins or configurations.
- Risk or side effect 2: Downtime during the upgrade process – plan for sufficient downtime and communicate it to users.
- Roll back: 1) Stop the web server service. 2) Restore the pre-upgrade backup of the RT installation directory. 3) Restore any custom configurations from your previous backup. 4) Start the web server service.