How to remediate – Web Common Credentials

1. Introduction

The Web Common Credentials vulnerability means protected web pages could be accessed using widely known usernames and passwords. This is a serious risk as it allows unauthorised access to sensitive data and systems. Websites, extranets, and any web application handling user accounts are usually affected. A successful attack could compromise confidentiality, integrity, and availability of the web service.

2. Technical Explanation

This vulnerability occurs when web applications permit login with default or easily guessable credentials. Attackers use automated tools to test common username/password combinations against a website’s login page. The precondition for exploitation is an accessible login form and the application’s acceptance of weak credentials.

• Exploit mechanism: An attacker uses a list of common usernames and passwords to attempt logins via HTTP requests. A successful login grants access to the web application as the compromised user. For example, using ‘admin’ with password ‘password’.
• Scope: Web servers running any platform (Apache, Nginx, IIS) are affected if they host vulnerable applications. Common examples include default accounts on content management systems or network devices accessible via a web interface.

3. Detection and Assessment

Confirming vulnerability involves checking for the presence of default accounts and testing login attempts with common credentials. A quick check is to attempt login using ‘admin’/’password’. Thorough assessment requires a password spraying attack against the login page.

• Quick checks: Attempt login with username ‘admin’ and password ‘password’. Check for any error messages indicating account existence or failed attempts.
• Scanning: Nessus plugin ID 10384 can identify this vulnerability, but results should be verified manually.
• Logs and evidence: Web server access logs may show repeated login attempts from the same source IP address with various usernames. Look for successful logins using common credentials.

curl -u 'admin:password' http://targetwebsite/login

4. Solution / Remediation Steps

Fixing this issue requires changing default passwords and enforcing strong password policies. These steps should be performed carefully to avoid service disruption.

4.1 Preparation

• Ensure you have access credentials for administrative tasks. A roll back plan is to restore the original configuration from the backup.
• Changes should be approved by the security team and a change window booked.

4.2 Implementation

1. Step 1: Change default passwords on all accounts, including those for content management systems or network devices accessible via web interfaces.
2. Step 2: Implement a strong password policy requiring minimum length, complexity, and regular changes.

4.3 Config or Code Example

Before

# Insecure configuration example (Apache .htpasswd)
admin:$1$salt$hashedpassword

After

# Secure configuration example (Apache .htpasswd)
admin:$6$salt$strongerhashedpassword

4.4 Security Practices Relevant to This Vulnerability

Practices that directly address this vulnerability include least privilege, strong password policies and regular security reviews. Least privilege reduces the impact if an account is compromised. Strong passwords make brute-force attacks harder.

• Practice 1: Implement the principle of least privilege to limit user access rights.
• Practice 2: Enforce a robust password policy with minimum length, complexity requirements and regular changes.

4.5 Automation (Optional)

# Example PowerShell script to check for default accounts in Active Directory
Get-ADUser -Filter 'Name -like "*admin*" -or SamAccountName -like "*administrator*"' | Where-Object {$_.Enabled -eq $true}
#This is a sample and requires modification for your environment. Review output carefully before making changes.

5. Verification / Validation

• Post-fix check: Attempt login with username ‘admin’ and password ‘password’. Expected output should be a failed login attempt.
• Re-test: Re-run the Nessus scan (plugin ID 10384) to confirm that the vulnerability is no longer detected.
• Smoke test: Verify users can still log in with their valid credentials and access key web application features.
• Monitoring: Monitor web server logs for failed login attempts, particularly those targeting common usernames.

curl -u 'admin:password' http://targetwebsite/login # Expected output: 401 Unauthorized or similar error message

6. Preventive Measures and Monitoring

Update security baselines to include strong password policies, regular account reviews, and vulnerability scanning. Implement checks in CI/CD pipelines to prevent deployment of applications with default credentials. For example, use CIS benchmarks for web server configuration.

• Baselines: Update your security baseline or policy to enforce strong passwords and account lockout rules.
• Pipelines: Add static code analysis (SAST) tools to CI/CD pipelines to identify hardcoded credentials in application code.
• Asset and patch process: Review web application configurations regularly for default accounts and weak passwords. A monthly review cycle is recommended.

7. Risks, Side Effects, and Roll Back

Changing passwords may disrupt users if not communicated properly. Incorrect configuration could lock out legitimate users. To roll back, restore the original web application configuration from the backup taken during preparation.

• Roll back: Restore the web application configuration from the backup taken prior to making changes. Restart the web server.

8. References and Resources

• Vendor advisory or bulletin: Check your web application vendor’s security advisories for specific guidance.
• NVD or CVE entry: https://nvd.nist.gov/vuln/detail/CVE-2017-9805
• Product or platform documentation relevant to the fix: Refer to your web server’s documentation for configuring password policies and account lockout rules.