How to remediate – Web Common Credentials (HTML form)

1. Introduction

The Web Common Credentials vulnerability refers to the possibility of logging into a web application using widely known username and password combinations. This poses a significant risk as attackers can gain unauthorised access to sensitive data and systems. Systems with HTML form-based logins are typically affected, particularly those lacking robust account protection measures. A successful exploit could compromise confidentiality, integrity, and availability of the service.

2. Technical Explanation

This vulnerability occurs when web applications do not enforce strong password policies or allow default credentials to remain active. Attackers attempt login using common usernames like ‘admin’, ‘user’, or passwords such as ‘password’ or ‘123456’. The Nessus scanner identified successful logins with these combinations, indicating a weak security posture. There is no specific CVE associated with this general issue but it relates to CWE-798: Use of Hardcoded Credentials. An attacker could simply attempt login via the web interface using common credentials until a successful authentication occurs.

• Root cause: The server accepts logins with easily guessable username and password combinations.
• Exploit mechanism: An attacker uses a list of common credentials to brute-force access through the HTML form login page. For example, attempting ‘admin’ with the password ‘password’.
• Scope: Any web application or service using an HTML form for authentication is potentially affected, especially those running default configurations or lacking strong password policies.

3. Detection and Assessment

Confirming vulnerability involves checking login success with common credentials. A quick check can be performed directly through the web interface. Thorough assessment requires automated scanning tools.

• Quick checks: Attempt to log in using ‘admin’ / ‘password’, ‘user’ / ‘123456’, and similar combinations via the application’s login page.
• Scanning: Nessus vulnerability ID 8937 is an example of a scan that detects this issue. Other scanners may have similar checks.
• Logs and evidence: Examine web server access logs for successful logins from unexpected sources or with common usernames. Look for event IDs related to authentication success, particularly those following failed attempts.

curl -u "admin:password" http://target-server/login

4. Solution / Remediation Steps

The primary solution is to enforce stronger password policies and disable or change default credentials. Follow these steps carefully to avoid service disruption.

4.1 Preparation

• No services need to be stopped for this remediation, but plan during off-peak hours to minimise user impact.
• Roll back involves restoring the previous configuration from the backup. A change window should be booked with appropriate approval.

4.2 Implementation

1. Step 1: Change the default administrator password to a strong, unique value.
2. Step 2: Enforce a minimum password length of at least 12 characters.
3. Step 3: Implement complexity requirements (uppercase, lowercase, numbers, symbols).
4. Step 4: Consider implementing multi-factor authentication for administrator accounts.
5. Step 5: Review and remove any unnecessary default user accounts.

4.3 Config or Code Example

Before

#Example Apache config - weak password policy
AllowOverride None
AuthType Basic
AuthName "Restricted Area"
AuthUserFile /etc/htpasswd
Require valid-user

After

#Example Apache config - stronger password policy and htpasswd file update
AllowOverride None
AuthType Basic
AuthName "Restricted Area"
AuthUserFile /etc/htpasswd
Require valid-user
PasswordEncryption bcrypt

4.4 Security Practices Relevant to This Vulnerability

Several security practices directly address this vulnerability type. Implementing these will improve overall account security.

• Practice 1: Least privilege – limit user access rights to the minimum necessary for their role, reducing impact if an account is compromised.
• Practice 2: Strong password policies – enforce complexity, length, and regular changes to make passwords harder to crack.
• Practice 3: Input validation – prevent common usernames or passwords from being submitted during registration or login.

4.5 Automation (Optional)

If using configuration management tools, automate password policy enforcement.

#Example Ansible task to enforce password complexity
- name: Ensure strong password policies are in place
  lineinfile:
    path: /etc/security/pwquality.conf
    regexp: '^minlen='
    line: 'minlen = 12'
  become: true

5. Verification / Validation

• Post-fix check: Attempt to log in using ‘admin’ / ‘password’. The login attempt should be rejected.
• Re-test: Re-run the Nessus scan (ID 8937). It should no longer report the vulnerability.
• Smoke test: Verify that legitimate users can still log in with their correct credentials and access key application features.
• Monitoring: Monitor web server logs for failed login attempts using common usernames, which could indicate ongoing brute-force attacks.

curl -u "admin:password" http://target-server/login #Should return 401 or similar error

6. Preventive Measures and Monitoring

Regular security baselines, pipeline checks, and a robust patch process can prevent recurrence of this issue.

• Baselines: Update your security baseline to include strong password policies (for example, CIS control 1.2).
• Pipelines: Add static code analysis (SAST) tools to your CI/CD pipeline to identify hardcoded credentials or weak password validation logic.
• Asset and patch process: Review web application configurations regularly as part of a scheduled security assessment cycle.

7. Risks, Side Effects, and Roll Back

Changing password policies may cause temporary inconvenience for users. Ensure clear communication and support are available during the change.

• Risk or side effect 1: Users may forget their new passwords, requiring assistance from helpdesk.
• Risk or side effect 2: Complex password requirements could lead to users writing down passwords insecurely.
• Roll back: Restore the previous web application configuration file from backup.

8. References and Resources

• Vendor advisory or bulletin: Check your web server/application vendor’s security pages for specific guidance.
• NVD or CVE entry: While there is no single CVE, search the NVD database for related password-related vulnerabilities.
• Product or platform documentation relevant to the fix: Refer to your web server’s documentation on configuring authentication and password policies.