How to remediate – HTTP Server Authentication Detected

1. Introduction

HTTP Server Authentication Detected is an informational notice indicating that pages on your web server are protected by HTTP authentication. This means users must provide a username and password to access these pages. While not directly exploitable, it can indicate weak security practices if credentials aren’t managed properly or if sensitive data is exposed. Affected systems typically include web servers running Apache, Nginx, IIS, or similar software. A successful attack could lead to unauthorized access to protected resources, impacting confidentiality, integrity and availability of those resources.

2. Technical Explanation

The vulnerability occurs when a web server is configured to use HTTP Basic Authentication (or Digest Authentication) without proper security measures like HTTPS encryption. This means usernames and passwords are sent in plain text over the network, making them vulnerable to interception. An attacker can capture these credentials using tools like Wireshark or by performing a Man-in-the-Middle attack. The precondition for exploitation is that the server uses HTTP authentication without TLS/SSL protection.

• Root cause: Use of unencrypted HTTP connections for authentication.
• Exploit mechanism: An attacker intercepts network traffic to capture usernames and passwords sent during the authentication process. For example, an attacker could use a packet sniffer on the same network segment as the server or client.
• Scope: Web servers (Apache, Nginx, IIS) configured with HTTP Basic or Digest Authentication without HTTPS.

3. Detection and Assessment

You can confirm if a system is vulnerable by checking its web server configuration and testing authentication access.

• Quick checks: Use `curl -v ` to check the HTTP headers for authentication prompts. If you see “WWW-Authenticate”, it indicates HTTP Authentication is enabled.
• Scanning: Nessus plugin ID 30481 can detect HTTP server authentication. This is an example only, and results should be verified manually.
• Logs and evidence: Web server access logs may show authentication attempts. Check for entries related to authentication failures or successful logins. Exact paths vary by web server (e.g., Apache’s `access.log`, Nginx’s `access.log`).

curl -v https://example.com/protected-page

4. Solution / Remediation Steps

The primary solution is to enable HTTPS for all pages protected by HTTP authentication.

4.1 Preparation

• Ensure you have a valid SSL/TLS certificate installed and configured. A roll back plan is to restore the original configuration files and restart the web server.
• A change window may be required, depending on your environment. Approval from the security team might be needed.

4.2 Implementation

1. Step 1: Obtain a valid SSL/TLS certificate for your domain.
2. Step 2: Configure your web server to use HTTPS instead of HTTP. This typically involves updating the virtual host configuration file.
3. Step 3: Restart the web server service to apply the changes.
4. Step 4: Test access to the protected pages using HTTPS.

4.3 Config or Code Example

Before

# Apache VirtualHost configuration (HTTP)
<VirtualHost *:80>
    ServerName example.com
    DocumentRoot /var/www/example.com
    <Directory /var/www/example.com>
        AuthType Basic
        AuthName "Restricted Area"
        AuthUserFile /etc/httpd/.htpasswd
        Require valid-user
    </Directory>
</VirtualHost>

After

# Apache VirtualHost configuration (HTTPS)
<VirtualHost *:443>
    ServerName example.com
    DocumentRoot /var/www/example.com
    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/example.com.crt
    SSLCertificateKeyFile /etc/ssl/private/example.com.key
    <Directory /var/www/example.com>
        AuthType Basic
        AuthName "Restricted Area"
        AuthUserFile /etc/httpd/.htpasswd
        Require valid-user
    </Directory>
</VirtualHost>

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this issue.

• Least privilege: Limit the number of users with access to protected resources.
• Secure defaults: Configure web servers with HTTPS enabled by default.
• Patch cadence: Keep your web server software up-to-date with the latest security patches.

4.5 Automation (Optional)

# Example Ansible task to ensure HTTPS redirection
- name: Ensure HTTPS redirection is enabled
  apache2_module:
    name: redirect
    state: present
    enable: yes
  become: true

5. Verification / Validation

Confirm the fix by checking that HTTP authentication is no longer accessible over unencrypted connections and that HTTPS is working correctly.

• Post-fix check: Use `curl -v ` again. You should receive an error when attempting to access the page via HTTP, or be automatically redirected to HTTPS.
• Re-test: Re-run the Nessus scan (plugin ID 30481) and verify that it no longer reports the vulnerability.
• Smoke test: Verify that users can still log in to the protected pages using HTTPS.
• Monitoring: Monitor web server logs for any failed login attempts or errors related to SSL/TLS configuration.

curl -v http://example.com/protected-page # Should return an error or redirect

6. Preventive Measures and Monitoring

Update security baselines and implement checks in your CI/CD pipeline to prevent similar issues.

• Baselines: Update your web server security baseline to require HTTPS for all sensitive pages.
• Pipelines: Add static code analysis (SAST) or dynamic application security testing (DAST) tools to your CI/CD pipeline to identify insecure configurations.
• Asset and patch process: Implement a regular patch review cycle for your web server software.

7. Risks, Side Effects, and Roll Back

Potential risks include SSL/TLS configuration errors or compatibility issues with older browsers.

• Risk or side effect 2: Older browsers may not support the latest TLS versions. Mitigation: Consider supporting older TLS versions if necessary, but prioritize security best practices.
• Roll back: Restore the original web server configuration files and restart the service.

8. References and Resources

• Vendor advisory or bulletin: Check your web server vendor’s documentation for best practices on securing HTTP authentication with HTTPS (e.g., Apache, Nginx, IIS).
• NVD or CVE entry: There is