1. Introduction
Web Tests Session Expiration Errors occur when Nessus terminates web attacks due to session issues. This can lead to incomplete scan results, potentially missing vulnerabilities on affected web servers. Businesses may be exposed to risk if vulnerabilities are undetected. Web applications and servers using session-based authentication are typically affected. Impact is likely to affect confidentiality, integrity, and availability of data depending on the nature of the application.
2. Technical Explanation
The vulnerability arises from Nessus losing its authenticated session while performing web tests. This can happen if the server has a short session timeout or if there’s network instability during the scan. An attacker cannot directly exploit this, but it prevents accurate security assessments. There is no known CVE associated with this specific issue as it relates to the scanning tool itself rather than an application vulnerability.
- Exploit mechanism: An attacker cannot exploit this directly, but a lack of complete scan results could allow real vulnerabilities to remain undetected and unpatched.
- Scope: Affects web servers scanned by Nessus using HTTP authentication.
3. Detection and Assessment
Confirming the vulnerability involves checking Nessus scan logs for session termination errors. A thorough method is to review the full scan report for incomplete test results.
- Quick checks: Review Nessus scan history for scans that ended prematurely or with warnings about session issues.
- Logs and evidence: Check the Nessus scanner logs (usually located in /var/nessus/logs) for entries indicating session errors or authentication failures.
# No command available as this is a scanning tool issue, not a system vulnerability. Review scan results within the Nessus UI.4. Solution / Remediation Steps
Fixing this involves adjusting Nessus scan settings to handle session timeouts more effectively. These steps aim to maintain an active session during longer scans.
4.1 Preparation
- Dependencies: None. Roll back plan: Restore the original scan policy from backup.
- Change window: Standard maintenance window is sufficient, approval not usually required for informational issues.
4.2 Implementation
- Step 1: Increase the re-authenticate delay in Nessus preferences. Navigate to Preferences -> HTTP login page and increase the “re-authenticate delay (seconds)” value. Start with a small increment, such as from 30 seconds to 60 seconds.
- Step 2: Reduce scan parallelism. Go to Options and decrease the “Number of hosts in parallel (max_hosts)” setting. A lower number will reduce load on the server.
- Step 3: Further reduce test parallelism. Also in Options, decrease the “Number of checks in parallel (max_checks)” setting. This reduces the frequency of requests during a scan.
4.3 Config or Code Example
Before
# Preferences -> HTTP login page -> re-authenticate delay (seconds) = 30
# Options -> Number of hosts in parallel (max_hosts) = 10
# Options -> Number of checks in parallel (max_checks) = 50After
# Preferences -> HTTP login page -> re-authenticate delay (seconds) = 60
# Options -> Number of hosts in parallel (max_hosts) = 5
# Options -> Number of checks in parallel (max_checks) = 254.4 Security Practices Relevant to This Vulnerability
While this is a scanning tool issue, robust web application security practices can indirectly help. For example, secure session management and appropriate timeout values reduce the likelihood of premature session termination.
- Practice 1: Secure Session Management – Implement strong session IDs and enforce reasonable session timeouts to minimise exposure windows.
- Practice 2: Input Validation – Validate all user inputs to prevent attacks that could disrupt sessions or cause unexpected behaviour.
4.5 Automation (Optional)
No automation is available as this requires changes within the Nessus UI.
# No script provided, configuration must be done manually in the Nessus web interface.5. Verification / Validation
Confirming the fix involves re-running the scan and verifying that it completes without session errors. Check for complete test results in the Nessus report.
- Post-fix check: Run a new scan against the target web server. Verify that the scan completes successfully with no warnings about session issues.
- Re-test: Review the scan history and reports to confirm the absence of previous session errors.
- Monitoring: Monitor Nessus logs for any recurring session errors or authentication failures.
# No command available as this is a scanning tool issue, not a system vulnerability. Review scan results within the Nessus UI.6. Preventive Measures and Monitoring
For example, regularly review web application session configurations to ensure appropriate timeout values are set. Update security baselines to include recommended Nessus settings for reliable scanning.
- Baselines: Update your security baseline or policy to reflect the adjusted Nessus scan settings (re-authenticate delay, max_hosts, max_checks).
- Pipelines: Implement regular vulnerability scans with Nessus as part of your CI/CD pipeline.
- Asset and patch process: Review Nessus configuration periodically to ensure optimal performance and reliability.
7. Risks, Side Effects, and Roll Back
Increasing the re-authenticate delay may slightly increase scan duration. Reducing parallelism can also extend scan times. Roll back by restoring the original Nessus scan policy settings.
- Risk or side effect 1: Increased scan time due to higher re-authentication delays and reduced parallelism.
- Risk or side effect 2: No known service impacts, but monitor resource usage during scans.
- Roll back: Restore the original Nessus scan policy from backup. Navigate to Policies -> Import Policy and select the backed up file.
8. References and Resources
- Vendor advisory or bulletin: Tenable Nessus Documentation
- NVD or CVE entry: Not applicable as this is a scanning tool issue, not an application vulnerability.
- Product or platform documentation relevant to the fix: Nessus Scan Configuration Options