Cassandra Pentesting Skill

This skill helps you enumerate and assess Apache Cassandra databases for security vulnerabilities. Cassandra is a distributed NoSQL database that often accepts unauthenticated connections, making it a valuable target for enumeration.

When to Use This Skill

• You discover open ports 9042 (native protocol) or 9160 (thrift) during port scanning
• You need to enumerate a Cassandra database for a security assessment
• You want to extract system information, keyspace data, or credential hashes
• You're performing authorized penetration testing on infrastructure containing Cassandra

Quick Start

# Install cqlsh if not available
pip install cqlsh

# Connect to Cassandra instance
cqlsh <TARGET_IP> 9042

Enumeration Procedures

1. Initial Connection

Cassandra often accepts any credentials or no credentials at all. Try connecting without authentication first:

cqlsh <TARGET_IP>
cqlsh <TARGET_IP> 9042

If authentication is required, you may need to brute force or use default credentials.

2. Gather System Information

Once connected, run these queries to understand the cluster configuration:

-- Get cluster metadata
SELECT cluster_name, thrift_version, data_center, partitioner, 
       native_protocol_version, rack, release_version 
FROM system.local;

-- List all available keyspaces
SELECT keyspace_name FROM system.schema_keyspaces;

3. Enumerate Keyspaces

For each keyspace discovered, describe its structure:

-- Describe a specific keyspace
desc <keyspace_name>;

-- Describe system authentication tables
desc system_auth;

4. Extract Sensitive Data

Query authentication and configuration tables for credentials and hashes:

-- System authentication roles (may contain credential hashes)
SELECT * FROM system_auth.roles;

-- Application-specific auth tables (common patterns)
SELECT * FROM logdb.user_auth;
SELECT * FROM logdb.user;

-- Configuration data
SELECT * FROM configuration."config";

5. Automated Enumeration

Use NMAP for initial reconnaissance:

# Cassandra info script
nmap -sV --script cassandra-info -p 9042,9160 <TARGET_IP>

# Full version detection
nmap -sV -p 9042,9160 <TARGET_IP>

Common Findings

Finding	Risk	Description
Unauthenticated access	High	Database accepts any/no credentials
Credential hashes exposed	Medium	system_auth.roles contains password hashes
Configuration data leaked	Medium	Application configs in custom keyspaces
Outdated version	Medium	Older versions may have known vulnerabilities

Shodan Queries

For reconnaissance, use these Shodan queries to find Cassandra instances:

port:9160 Cluster
port:9042 "Invalid or unsupported protocol version"

Example Workflow

Scenario: You found port 9042 open on 192.168.1.100

1. Initial scan:

   nmap -sV --script cassandra-info -p 9042 192.168.1.100
   

2. Connect and enumerate:

   cqlsh 192.168.1.100
   

3. Run enumeration queries:

   SELECT cluster_name, release_version FROM system.local;
   SELECT keyspace_name FROM system.schema_keyspaces;
   SELECT * FROM system_auth.roles;
   

4. Document findings:

   • Cluster name and version
   • All keyspaces discovered
   • Any credential hashes or sensitive data
   • Authentication status (open/protected)

Security Considerations

• Authorization: Only test Cassandra instances you have explicit permission to assess
• Data handling: Credential hashes and configuration data are sensitive - handle appropriately
• Impact: Enumeration queries are read-only and generally safe, but be cautious with write operations
• Logging: Your connection and queries may be logged by the database administrator

Troubleshooting

Issue	Solution
Connection refused	Verify port is open and Cassandra is running
Authentication required	Try default credentials or brute force (if authorized)
Protocol version error	Ensure cqlsh version matches Cassandra version
Timeout	Check network connectivity and firewall rules

Next Steps After Enumeration

1. If credential hashes are found, attempt offline cracking
2. If application data is accessible, assess data sensitivity
3. Document all findings for the security report
4. Consider testing for known Cassandra CVEs based on version
5. Check for misconfigured permissions on discovered keyspaces