How to remediate – Nikto (NASL wrapper)

1. Introduction

Nikto (NASL wrapper) is a web server scanner that identifies potential issues on web servers, such as outdated software and dangerous files. This matters to businesses because these issues can allow attackers to compromise websites and the systems they connect to. Systems usually affected are those running web servers like Apache, Nginx, or IIS. A successful exploit could lead to data breaches, website defacement, or denial of service.

2. Technical Explanation

Nikto scans a web server by sending requests and analysing the responses for known vulnerabilities. It doesn’t directly exploit systems but identifies potential weaknesses. The plugin runs Nikto2 as part of a vulnerability assessment process. No specific CVE is associated with running the scan itself, only with the issues it detects on vulnerable servers.

• Root cause: The root cause isn’t in Nikto itself, but in misconfigurations or outdated software on the web server being scanned.
• Exploit mechanism: An attacker would use Nikto to identify a vulnerable component (e.g., an old version of Apache). They could then exploit that specific vulnerability using another tool or technique. For example, if Nikto finds an unpatched version of WordPress, an attacker might try known WordPress exploits.
• Scope: Affected platforms are those running web servers and associated applications like PHP, ASP.NET, or Java servlets. The versions affected depend on the vulnerabilities identified by Nikto.

3. Detection and Assessment

Confirming whether a system is vulnerable requires checking for issues that Nikto might identify. A quick check involves reviewing web server version information. A thorough method uses Nikto itself to perform a full scan.

• Quick checks: Check the web server’s ‘Server’ header using a browser developer tool or command line tools like `curl -I https://example.com`.
• Scanning: Nessus, OpenVAS, and other vulnerability scanners often include Nikto2 as a plugin. Example signature ID 93865 (Nessus).
• Logs and evidence: Web server access logs may show requests from the scanning IP address. Event IDs are not usually specific to Nikto itself.

curl -I https://example.com

4. Solution / Remediation Steps

Fixing issues identified by Nikto requires addressing vulnerabilities on the web server. This involves patching software, updating configurations, and removing dangerous files.

4.1 Preparation

• Call out dependencies or pre-requisites: Ensure you have access to patch repositories and update tools. Roll back plan is to restore from the previous backup.
• Mention change window needs and who should approve: Schedule a maintenance window with appropriate approvals, especially for production systems.

4.2 Implementation

1. Step 1: Update all web server software to the latest stable version (e.g., Apache, Nginx, IIS).
2. Step 2: Apply any relevant security patches for installed applications (e.g., WordPress, Joomla, Drupal).
3. Step 3: Remove or disable any unnecessary files or programs identified as potentially dangerous by Nikto.

4.3 Config or Code Example

Before

# In Apache config: Options Indexes FollowSymLinks
AllowOverride None

After

# In Apache config: Options -Indexes FollowSymLinks
AllowOverride All

4.4 Security Practices Relevant to This Vulnerability

• Practice 1: Patch cadence: Regularly update all software components to address known vulnerabilities.
• Practice 2: Least privilege: Run web server processes with the minimum necessary permissions.

4.5 Automation (Optional)

# Example Bash script to check Apache version
apachectl -v | grep "Server version"

5. Verification / Validation

Confirming the fix involves re-running Nikto to verify that the identified issues are resolved. A service smoke test checks basic website functionality.

• Post-fix check: Re-run `curl -I https://example.com` and confirm the server version has been updated.
• Re-test: Run Nikto2 against the system again to ensure no vulnerabilities are reported.
• Smoke test: Verify that key website pages load correctly and user logins work as expected.

curl -I https://example.com

6. Preventive Measures and Monitoring

Preventing these issues involves establishing security baselines, incorporating checks into CI/CD pipelines, and maintaining a robust asset and patch process.

• Baselines: Implement a security baseline for web servers that includes secure configuration settings (e.g., CIS benchmarks).
• Asset and patch process: Establish a regular schedule for reviewing and applying security patches to all web server components.

7. Risks, Side Effects, and Roll Back

Applying patches or making configuration changes can sometimes cause service disruptions. A roll back plan is essential.

• Risk or side effect 1: Applying a patch may introduce compatibility issues with existing applications. Mitigate by testing in a staging environment first.

8. References and Resources

• Vendor advisory or bulletin: https://cirt.net/nikto2