How to remediate – OpenStack Keystone Default Credentials

1. Introduction

OpenStack Keystone Default Credentials refers to the use of pre-set usernames and passwords within the OpenStack identity service. This allows unauthorised access to the system, potentially giving an attacker full administrative control. Systems running OpenStack Keystone with default credentials are affected. Successful exploitation could compromise confidentiality, integrity, and availability of the entire OpenStack deployment.

2. Technical Explanation

The vulnerability occurs because the Keystone service is shipped with well-known default usernames and passwords. An attacker can use these to log in without needing valid user accounts. This provides a direct route to administrative access. There is no specific CVE associated with this general issue, but it’s often identified during security scans.

• Root cause: Use of insecure default credentials for the Keystone service.
• Exploit mechanism: An attacker attempts login using common default usernames and passwords (e.g., admin/admin). If successful, they gain access to the Keystone web interface and can manage users, tenants, and services. For example, an attacker could use a simple HTTP request with default credentials in the authentication header.
• Scope: OpenStack Keystone installations using default credentials are affected. Specific versions are not typically at fault; it’s configuration dependent.

3. Detection and Assessment

You can confirm if your system is vulnerable by checking for the presence of default accounts or attempting to log in with them. A thorough assessment involves reviewing Keystone’s authentication logs.

• Quick checks: Check the Keystone configuration file (typically /etc/keystone/keystone.conf) for default usernames and passwords.
• Scanning: Nessus ID 350f4002 can identify this vulnerability as an example.
• Logs and evidence: Examine Keystone authentication logs (location varies by distribution, but often in /var/log/keystone/) for successful logins using default credentials. Look for event IDs related to user authentication.

sudo grep -r "admin" /etc/keystone/keystone.conf

4. Solution / Remediation Steps

The solution is to change the default credentials immediately. Follow these steps carefully.

4.1 Preparation

• Ensure you have access to a recovery account or method in case of issues. A roll back plan is to restore the backed-up configuration file.
• This change requires a maintenance window and approval from system owners.

4.2 Implementation

1. Step 1: Edit the /etc/keystone/keystone.conf file.
2. Step 2: Change the ‘admin_password’ setting to a strong, unique password.
3. Step 3: If applicable, change other default usernames and passwords (e.g., service accounts).
4. Step 4: Restart the Keystone service to apply the changes.

4.3 Config or Code Example

Before

[admin]
password = admin

After

[admin]
password = YourStrongPasswordHere

4.4 Security Practices Relevant to This Vulnerability

List only practices that directly address this vulnerability type. Use neutral wording and examples instead of fixed advice. For example: least privilege, input validation, safe defaults, secure headers, patch cadence. If a practice does not apply, do not include it.

• Practice 1: Safe Defaults – Avoid shipping products with default credentials.
• Practice 2: Password Policies – Enforce strong password policies and regular password changes.

4.5 Automation (Optional)

# Example Ansible task to change admin password
- name: Change Keystone Admin Password
  ansible.builtin.lineinfile:
    path: /etc/keystone/keystone.conf
    regexp: '^password = '
    line: "password = {{ keystone_admin_password }}"
  become: true

5. Verification / Validation

Confirm the fix by attempting to log in with the old default credentials and verifying that access is denied. Then, confirm successful login with the new password.

• Post-fix check: Attempt to log in using ‘admin/admin’. Access should be rejected.
• Re-test: Re-run the quick check from Section 3; default credentials should no longer exist in the configuration file.
• Smoke test: Log in with the new admin password and verify you can manage users and tenants.
• Monitoring: Monitor Keystone authentication logs for failed login attempts using default credentials as an example.

sudo keystone-openrc | grep "Authentication failed"

6. Preventive Measures and Monitoring

Suggest only measures that are relevant to the vulnerability type. Use “for example” to keep advice conditional, not prescriptive.

• Baselines: Update your security baseline or policy to include a requirement for changing default credentials on all new systems.
• Asset and patch process: Include regular review of system configurations as part of your asset management process.

7. Risks, Side Effects, and Roll Back

• Risk or side effect 1: Incorrect password configuration could lock out administrative access. Mitigation is to have a recovery account.
• Risk or side effect 2: Service interruption during restart. Mitigation is to schedule changes during off-peak hours.
• Roll back: Restore the backed-up /etc/keystone/keystone.conf file and restart the Keystone service.

8. References and Resources

• Vendor advisory or bulletin: https://launchpad.net/keystone
• NVD or CVE entry: No specific CVE, but see http://www.nessus.org/u?350f4002 for detection information.
• Product or platform documentation relevant to the fix: OpenStack Keystone documentation on configuration options.