Description

Weak authentication-cookie signing secrets combined with insecure random generation enable token forgery and authentication bypass in Apache Druid’s Kerberos authenticator.

When druid.auth.authenticator.kerberos.cookieSignatureSecret is not explicitly configured, Apache Druid generates a fallback secret using ThreadLocalRandom, which is not a cryptographically secure RNG. This results in low-entropy, predictable secrets used to sign Kerberos authentication cookies.
An attacker who can observe or brute-force the fallback secret may forge valid authentication cookies, achieving unauthenticated → authenticated escalation.

Additionally, each Druid process generates its own fallback secret. In distributed or multi-broker clusters, this leads to inconsistent signing keys, causing inter-node authentication failures and broken deployments.

The issue affects Apache Druid ≤ 34.0.0.

Vulnerability Details

• Insecure fallback secret generation:
  When cookieSignatureSecret is absent, Druid derives the signing secret from ThreadLocalRandom, which is not cryptographically secure, making the resulting secret predictable or brute-forceable.

• Per-process secret divergence:
  Each Druid node uses its own insecurely generated secret, so cookies signed by one node may not validate on another—breaking Kerberos authentication in clustered setups.

• Potential impact:

  • Authentication bypass: attacker forges Kerberos authentication cookies.
  • Privilege escalation: attacker impersonates legitimate Druid users.
  • Cluster instability: multi-node deployments fail authentication between brokers.

• Root cause:
  Missing or optional configuration of druid.auth.authenticator.kerberos.cookieSignatureSecret combined with insecure RNG fallback.

This leads to a compromise of the authentication boundary with network-only access and no user interaction.

Steps to Reproduce

1. Deploy Apache Druid ≤ 34.0.0 with the Kerberos authenticator enabled but without setting:

   druid.auth.authenticator.kerberos.cookieSignatureSecret
   

2. Observe cookie signing behavior:
   On startup, each Druid component generates a fallback secret using ThreadLocalRandom.

3. Capture a Kerberos authentication cookie (e.g., via proxy or local testing).

4. Attempt to brute-force or predict the fallback secret:
   Due to the low entropy introduced by ThreadLocalRandom, determining the secret (or a collision) is computationally feasible.

5. Forge a valid authentication cookie:
   Once the attacker acquires or predicts the secret, they can construct arbitrary signed cookies and impersonate any user.

6. Validate cross-node inconsistencies:
   In a multi-node cluster, cookies signed by one node fail on another, demonstrating the per-process secret mismatch.

Recommendation

• Upgrade to Apache Druid 35.0.0+:
  This release requires an explicit, strong cookieSignatureSecret for Kerberos authentication. Startup fails if the secret is missing, preventing insecure fallback behavior.

• Set a cryptographically strong secret in all environments:

  druid.auth.authenticator.kerberos.cookieSignatureSecret=<128-bit or stronger random key>
  

• Ensure consistent configuration across all nodes in a cluster (brokers, coordinators, routers, etc.).

• Use a secure RNG for any future secret generation and avoid fallbacks that reduce entropy.

• Audit deployments to ensure no nodes are relying on the weak fallback secret from previous upgrades.