1. Introduction
2. Technical Explanation
The vulnerability arises because RT authenticates users without invalidating their existing session ID. An attacker can exploit this by tricking a user into logging in with a pre-determined, known session ID. This allows the attacker to assume control of the user’s authenticated session. The version of RT running on your server is affected and CVE-2009-4151 details this issue.
- Root cause: Insufficient session management; existing session IDs are not invalidated upon login.
- Exploit mechanism: An attacker provides a user with a link containing a specific session ID. When the user logs in, their session is associated with the attacker’s pre-defined ID.
- Scope: Best Practical Solutions Request Tracker (RT) versions affected have not been specifically identified in this report.
3. Detection and Assessment
Confirming vulnerability requires checking the RT version and reviewing authentication behaviour. A quick check involves identifying the running RT version via the web interface or command line.
- Quick checks: Check the RT version number in the ‘About’ section of the web application, typically found under Administration > About.
- Scanning: Nessus ID 443e08f3 can detect this vulnerability. Other scanners may have similar signatures.
- Logs and evidence: Examine RT logs for unusual session activity or multiple logins from the same IP address with different user accounts. Log file locations vary by installation, but typically reside in /var/log/rt/.
# Example command placeholder:
# Check RT version using Perl (example only)
perl -e 'print $RT_VERSION;'
4. Solution / Remediation Steps
The following steps outline how to address the session fixation vulnerability in Request Tracker.
4.1 Preparation
- Ensure you have access to the RT installation directory and appropriate permissions to modify configuration files. A roll back plan involves restoring the backed-up database and configuration.
4.2 Implementation
- Step 1: Upgrade Request Tracker to the latest available version, which includes security fixes. Check the Best Practical Solutions website for updates.
- Step 2: If upgrading is not immediately possible, review and apply any available patches specifically addressing CVE-2009-4151.
- Step 3: Configure RT to invalidate session IDs on login. This may involve modifying the `rt_session.pm` file or using a configuration option if available in your version.
4.3 Config or Code Example
Before
# In older versions, session IDs might not be invalidated automatically.
# Check rt_session.pm for relevant code sections related to session management.
After
# Ensure the following line is present in your rt_session.pm file or equivalent configuration:
$Session->InvalidateOnLogin(1); # Force session ID invalidation on login
4.4 Security Practices Relevant to This Vulnerability
Several security practices can help prevent this type of issue.
- Practice 1: Least privilege – limit user access rights to reduce the impact if a session is hijacked.
- Practice 2: Input validation – validate all user inputs to prevent malicious data from being processed.
4.5 Automation (Optional)
# Example Ansible snippet to update RT package (example only - adapt for your system)
- name: Update Request Tracker
apt:
name: rt
state: latest
become: true
5. Verification / Validation
Confirm the fix by verifying the updated version and retesting the vulnerability.
- Post-fix check: Verify that RT has been upgraded to a patched version via the ‘About’ section of the web application.
- Smoke test: Log in and verify core functionality, such as ticket creation and assignment, still works correctly.
- Monitoring: Monitor RT logs for unusual session activity or failed login attempts.
# Post-fix command and expected output (example only)
perl -e 'print $RT_VERSION;' # Expected output should show the patched version number
6. Preventive Measures and Monitoring
Regular security assessments and patching are crucial.
- Baselines: Update your security baseline to include a requirement for regularly patching RT with the latest security updates.
- Asset and patch process: Implement a regular patch review cycle, ideally monthly or quarterly, depending on risk tolerance.
7. Risks, Side Effects, and Roll Back
Upgrading RT may introduce compatibility issues with existing plugins or customizations.
- Risk or side effect 1: Upgrading RT could break customisations; test thoroughly in a staging environment first.
- Risk or side effect 2: Service interruption during the upgrade process; plan for downtime if necessary.
- Roll back: Restore the backed-up database and configuration files, then restart the RT web server service.
8. References and Resources
- Vendor advisory or bulletin: http://www.nessus.org/u?443e08f3
- NVD or CVE entry: CVE-2009-4151
- Product or platform documentation relevant to the fix: http://www.securityfocus.com/bid/37162