Lion Cipher Lab
Exploit an unauthenticated Redis in your own lab
- Penetration Testing / Red Team
- Intermediate
- ~45 min
- Free · no account required
Why it matters
Exposed, unauthenticated data stores are not an exotic finding — they are one of the most common serious findings on the entire internet, and Redis is the poster child. Redis is an in-memory data store: blisteringly fast, beloved for caching, queues and session storage, and for most of its life it shipped with no authentication at all, on the explicit assumption that it would only ever be reachable from trusted machines on a trusted network. That assumption is where the trouble starts. A developer runs Redis on localhost where it is genuinely safe, copies the same configuration onto a server,…
What you'll learn
- defining what Redis is, what 'unauthenticated' means for a data store, and why an exposed one is one of the most common findings on the whole internet
- standing up an isolated two-container lab (a Redis server and an 'attacker' client on a private Docker network) so the whole exercise touches nothing but your own machine
- confirming unauthenticated access from a second host with redis-cli: reading INFO, dumping CONFIG GET *, listing and reading keys, and understanding the FLUSHALL blast radius
- reproducing the classic CONFIG SET dir + dbfilename + SAVE write-primitive on your own lab box, and describing accurately how it becomes remote code execution in the real world
- naming the four modern mitigations that break that primitive — protected-mode, running as a non-root user, rename-command, and Redis 7 protected-configs — and why the lab had to disable them to demonstrate the bug at all
- applying the fix: requirepass and ACL users, protected-mode on, bind to loopback, an unprivileged run user, and rename-command on CONFIG
- measuring before and after with the same probe: unauthenticated INFO succeeds before the fix and returns NOAUTH after it
- judgment: why 'internal only' defaults betray people the moment a service moves to a network, and why a default modern Redis already refuses the attack — so the misconfiguration, not the software, is the finding
Steps in this lab
- What Redis is, and what 'unauthenticated' actually means here
- Build the isolated lab: two containers, one private network, your machine only
- Confirm unauthenticated access — the finding, from the attacker container
- The classic foothold: CONFIG SET dir + SAVE, on your own lab box only
- Why the default is safe — and why exposed stores still happen anyway
- The fix, part 1: require a password (or, better, an ACL user)
- The fix, part 2: defence in depth — mode, bind, user, renamed commands
- Do it better — how to recognise, report, and prevent the exposed store