Api Key Exposure in Redis

API keys are often stored as string values in Redis for fast lookup by microservices. When a Redis instance is exposed without authentication or with weak access controls, an attacker can enumerate keys and extract those values. Common manifestations include:

• Unauthenticated TCP access to the default port 6379 (or a TLS‑wrapped port) allowing the use of redis-cli or any client to run KEYS * or SCAN 0 to list all keys.
• Abuse of administrative commands such as CONFIG GET *, INFO, or DEBUG OBJECT that return server configuration or internal metadata, which can reveal key names or indirectly aid in key discovery.
• Lua sandbox escapes (e.g., CVE‑2021‑32761) that let an attacker execute arbitrary Lua scripts, enabling them to iterate over the key space and exfiltrate values stored as API keys.
• ACL bypass flaws like CVE‑2022‑24834, where a malformed username can bypass +@all restrictions and grant execution of normally prohibited commands, again leading to key disclosure.

Once the attacker has a list of keys, they can issue GET, MGET, or hash‑specific commands (HGETALL, HMGET) to harvest the API key values. Because Redis is an in‑memory store, the exposure is immediate and does not rely on logs or backups.

Detecting exposed API keys in Redis requires probing the unauthenticated surface and inspecting returned values for patterns that resemble secrets. middleBrick performs the following checks when pointed at a Redis host:

• Connection attempt without credentials; if the server responds with a +PONG to PING, the instance is considered unauthenticated.
• Execution of INFO to collect server version, mode, and enabled modules, which helps correlate findings with known CVEs (e.g., checking for versions vulnerable to CVE‑2021‑32761).
• Running CONFIG GET * (if not blocked) to see whether dangerous settings like protected-mode no or bind 0.0.0.0 are present.
• Scanning the key space with SCAN 0 COUNT 1000 (or KEYS * if permitted) to gather up to a few thousand keys, then sampling their values with GET or MGET.
• Applying entropy‑based and regex heuristics to sampled values to detect strings that match common API key formats (e.g., AWS Access Key IDs, Stripe live keys, GitHub personal tokens, Azure SAS tokens). When a match is found, middleBrick flags the finding as an API key exposure with severity high.

The scanner does not attempt to modify data; it only reads what is openly accessible. Findings are reported with the exact key name, the masked value (showing only the first and last two characters), and remediation guidance.

Securing Redis against API key leakage involves a combination of authentication, network hardening, command restriction, and secret‑management best practices.

# redis.conf
requirepass v3ry$tr0ngP@ssw0rd!

# redis.conf
rename-command CONFIG ""
rename-command KEYS ""
rename-command DEBUG ""

# redis.conf
bind 10.0.0.5 127.0.0.1
protected-mode yes

# redis.conf
tls-port 6379
tls-cert-file /etc/redis/tls.crt
tls-key-file /etc/redis/tls.key
tls-ca-cert-file /etc/redis/ca.crt
tls-auth-clients yes

127.0.0.1:6379> ACL SETUSER appuser on +get +set ~api_keys:* nopass

Example of a secure client connection in Python (redis‑py):

import redis
r = redis.Redis(
    host='redis.internal.example.com',
    port=6379,
    username='appuser',
    password='v3ry$tr0ngP@ssw0rd!',
    ssl=True,
    ssl_cert_reqs='required'
)
# Safe operation – only allowed keys
value = r.get('api_keys:payment_gateway')

Using the middleBrick CLI to verify the fix:

middlebrick scan redis://redis.internal.example.com:6379

The scan will now return an authentication failure and no API key findings, confirming that the exposure has been mitigated.