How to remediate – Apache Cassandra Default Credentials

1. Introduction

Apache Cassandra Default Credentials vulnerability refers to systems running Apache Cassandra with its default administrative login credentials still in place. This allows unauthenticated remote attackers to gain privileged access to the database, potentially compromising sensitive data and system integrity. This impacts confidentiality, integrity, and availability of the Cassandra database and any applications relying on it.

2. Technical Explanation

The vulnerability stems from Apache Cassandra’s insecure default configuration which ships with a pre-defined username (‘cassandra’) and password (‘cassandra’). An attacker can exploit this by directly attempting to log in using these credentials, bypassing normal authentication mechanisms. This is typically exploitable remotely via the CQL native protocol.

• Root cause: Use of weak or default administrative login credentials.
• Exploit mechanism: An attacker attempts a connection to Cassandra using the default username and password. Successful authentication grants full administrator access. For example, an attacker could use `cqlsh` with the default credentials to connect and execute commands.
• Scope: Apache Cassandra versions prior to those where default credentials were changed or removed are affected.

3. Detection and Assessment

Confirming whether a system is vulnerable involves checking if the default credentials are still active. A quick check can be performed using `cqlsh`, while thorough assessment requires examining configuration files.

• Quick checks: Attempt to connect to Cassandra using the default username and password via `cqlsh`.
• Scanning: Nessus plugin 16374 or OpenVAS scanner ID 92580 can identify this vulnerability. These are examples only.
• Logs and evidence: Examine Cassandra logs for successful authentication attempts with the ‘cassandra’ user. Log files are typically located in `/var/log/cassandra`.

cqlsh  -u cassandra -p cassandra

4. Solution / Remediation Steps

The solution involves changing the default administrative login credentials for Apache Cassandra.

4.1 Preparation

• Ensure you have access to the server’s command line and appropriate permissions to modify configuration files. A roll back plan involves restoring from the pre-change backup.
• A planned maintenance window is recommended, requiring approval from system owners.

4.2 Implementation

1. Step 1: Stop the Cassandra service using `systemctl stop cassandra`.
2. Step 2: Edit the `cassandra.yaml` file located in `/etc/cassandra/`.
3. Step 3: Change the value of the `authenticator` property to `PasswordAuthenticator`. If it is already set, skip this step.
4. Step 4: Start Cassandra using `systemctl start cassandra`.
5. Step 5: Connect to Cassandra using `cqlsh`.
6. Step 6: Change the password for the ‘cassandra’ user using the command `ALTER USER cassandra WITH PASSWORD ‘‘;`. Replace `` with a strong, unique password.

4.3 Config or Code Example

Before

# In cassandra.yaml
authenticator: DummyAuthenticator

After

# In cassandra.yaml
authenticator: PasswordAuthenticator

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.

• Practice 1: Implement strong password policies to enforce complex and unique passwords.
• Practice 2: Follow the principle of least privilege, granting users only the necessary permissions.

4.5 Automation (Optional)

If suitable, provide a small script or infrastructure code that applies the fix at scale. Only include if safe and directly relevant.

# Example Ansible task to change Cassandra password (requires appropriate credentials)
- name: Change Cassandra Password
  command: cqlsh -u cassandra -p  -e "ALTER USER cassandra WITH PASSWORD '';"
  become: true

5. Verification / Validation

• Post-fix check: Attempt to connect using `cqlsh -u cassandra -p cassandra`. This should fail.
• Re-test: Re-run the quick check from Section 3; it should no longer succeed with default credentials.
• Monitoring: Monitor Cassandra logs for failed authentication attempts using the ‘cassandra’ user, which could indicate brute-force attacks.

cqlsh  -u cassandra -p cassandra # Should fail

6. Preventive Measures and Monitoring

Suggest only measures that are relevant to the vulnerability type.

• Baselines: Update security baselines or policies to require changing default credentials on all new installations of Apache Cassandra.
• Asset and patch process: Establish a regular review cycle for system configurations, including password audits.

7. Risks, Side Effects, and Roll Back

List known risks or service impacts from the change.

• Risk or side effect 1: Incorrectly changing the password can lock out administrative access. Ensure you have a recovery mechanism in place.
• Risk or side effect 2: Service interruption during Cassandra restart. Minimize downtime by performing changes during off-peak hours.
• Roll back: Restore from the pre-change database backup if necessary. Revert `cassandra.yaml` to its original state and restart Cassandra.

8. References and Resources

Link only to sources that match this exact vulnerability.

• Vendor advisory or bulletin: Apache Cassandra Security Documentation
• NVD or CVE entry: No specific CVE is associated with default credentials, but related vulnerabilities exist.
• Product or platform documentation relevant to the fix: Cassandra Authenticator Configuration