Rainbow Table Attack in Elasticsearch

Rainbow table attacks exploit precomputed hash chains to reverse password hashes, bypassing the need for brute-force computation. In Elasticsearch, this vulnerability manifests when the security realm stores user passwords using fast, unsalted hash algorithms (e.g., MD5, SHA-1) or when the REST API inadvertently leaks password hashes via error messages or debug endpoints.

Elasticsearch's authentication is managed via realms (e.g., native, ldap, active_directory). The native realm, if misconfigured, may accept weak password hashes. For example, an administrator might manually create a user via the _security/api/user API with a pre-hashed password using MD5:

PUT /_security/api/user/weak_user
{
  "password" : "5f4dcc3b5aa765d61d8327deb882cf99", // MD5 hash of "password"
  "roles" : ["admin"]
}

Here, the password hash is stored verbatim. An attacker who compromises the Elasticsearch cluster (e.g., via an unauthenticated API endpoint like /_security/_authenticate that returns user details) can extract this hash and use a rainbow table to recover the plaintext password in seconds. This is particularly dangerous if the same password is reused across systems.

Additionally, Elasticsearch's debug logs or verbose error responses (e.g., when authentication fails) might include password hashes if logging levels are set too high (DEBUG). An attacker probing the API could trigger such responses to collect hashes.

The attack is amplified by Elasticsearch's distributed nature. If multiple nodes share the same weak password hash (synchronized via the cluster state), a single breach yields multiple credentials. Furthermore, Elasticsearch's REST API is often exposed directly to the internet without a WAF, making it an easy target for unauthenticated scanning.

Detecting rainbow table vulnerabilities in Elasticsearch involves identifying weak password hashes in storage and auditing API endpoints that leak credential data. Manual detection requires accessing the _security API (which typically requires admin privileges) or analyzing cluster state snapshots. This is where automated API scanning becomes essential.

middleBrick's scanner tests Elasticsearch endpoints by:

• Probing user management APIs: It attempts to retrieve user details (e.g., GET /_security/_authenticate or GET /_security/api/user/_all) if unauthenticated access is possible. A finding is triggered if password hashes are returned in the response (e.g., "password_hash" field) using weak algorithms.
• Testing hash strength: The scanner checks if the stored hash format matches known patterns for fast hashes (e.g., MD5's 32-character hex, SHA-1's 40-character hex). It cross-references with Elasticsearch's native realm documentation, which expects bcrypt hashes (starting with $2a$ or $2b$).
• Identifying misconfiguration: It flags if the xpack.security.authc.realms.native.native1 settings allow weak hashing (though Elasticsearch 7.x+ defaults to bcrypt, custom realms or legacy upgrades might not).

Example middleBrick finding for an Elasticsearch endpoint:

Note: middleBrick operates as a black-box scanner—it does not require credentials but may miss hashes if the API is properly locked down. However, it excels at finding unauthenticated leaks or misconfigured endpoints that expose hash data.

Remediation focuses on enforcing strong, salted password hashing and eliminating hash leakage. Elasticsearch provides native mechanisms that must be configured correctly.

1. Enforce bcrypt in the native realm
Elasticsearch's native realm uses bcrypt by default (since 6.8/7.1). Ensure no legacy settings override this. In elasticsearch.yml:

xpack.security.authc.realms.native.native1:
  enabled: true
  # No 'hash' setting—defaults to bcrypt

When creating users via the API, do not provide pre-hashed passwords. Let Elasticsearch hash them:

POST /_security/api/user/secure_user
{
  "password" : "StrongRandomPassword!123",
  "roles" : ["read"]
}

Elasticsearch will store a bcrypt hash (e.g., $2a$10$N9qo8uLOickgx2ZMRZoMy.Mr...>). To verify, retrieve the user:

GET /_security/api/user/secure_user

The response should include "password_hash" starting with $2a$.

2. Disable debug logging in production
In elasticsearch.yml, set:

xpack.security.logger.level: INFO
# or WARN, never DEBUG in prod

This prevents password hashes from appearing in logs that might be exposed via log aggregation APIs.

3. Implement rate limiting on authentication endpoints
Configure xpack.security.authc.rate_limiter to throttle repeated login attempts, hindering online brute-force attacks that could complement rainbow tables:

xpack.security.authc.rate_limiter:
  enabled: true
  limits:
    - credentials: true
      max_concurrent_requests: 10
      max_login_attempts_per_interval: 100
      interval: 1m

4. Rotate compromised passwords
If weak hashes are found, force password resets for all users. Use the API to update passwords en masse (with proper privileges):

POST /_security/api/user/_all/_password
{
  "password" : "NewStrongPassword!456"
}

5. Enforce TLS
Always use HTTPS (xpack.security.transport.ssl.enabled: true) to prevent man-in-the-middle attacks that could capture password hashes in transit. While rainbow tables target stored hashes, network interception could yield plaintext passwords.

Finally, audit your Elasticsearch version. Older versions (pre-6.8) may lack bcrypt defaults. Upgrade to a supported version and review the official security API documentation for realm-specific hash settings.