Lion Cipher Lab

Exploit a weakly-configured PostgreSQL in your own lab, then lock it down

• Penetration Testing / Red Team
• Intermediate
• ~50 min
• Free · no account required

Why it matters

PostgreSQL is one of the most widely deployed databases in the world — it sits behind web apps, analytics stacks, and internal tools everywhere — and unlike a cache it holds the crown jewels: customer records, credentials, business data. It is also, unlike Memcached or a stock Redis, a database that authenticates by default: the official container will not even start without a password unless you deliberately tell it not to. That is exactly why the way it gets breached is instructive. Nobody ships Postgres with 'no authentication' as a documented default; instead, a real team under deadline…

What you'll learn

• defining what PostgreSQL is, what a database 'role', a 'superuser' and pg_hba.conf are, and why an exposed database superuser is one of the most damaging findings on an internal network
• stating precisely how Postgres differs from Redis/MongoDB/Memcached: it DOES authenticate by default, so the finding is a MISCONFIGURATION (trust auth or a weak superuser password) plus a wide listen_addresses — not 'no auth at all'
• standing up an isolated two-container lab (a deliberately-weakened postgres server and a psql client 'attacker' on a private Docker network) so the whole exercise touches nothing but your own machine
• connecting from the 'attacker' with psql and confirming the exposure — a superuser session obtained with no or a trivial password
• reading server-side files an application never meant a client to see with pg_read_file(), and understanding this needs superuser / pg_read_server_files
• demonstrating the COPY ... FROM PROGRAM command-execution primitive (running a harmless shell command as the database's OS user) in your own container, and understanding exactly why it works and when it does NOT
• naming the honest severity split: superuser reachable = server file read + RCE + full data; a least-privilege app role reachable = at most that role's data, and NO file read or RCE
• applying and MEASURING the fix — a strong scram-sha-256 password, listen_addresses locked down, pg_hba.conf tightened, and a least-privilege role that is denied COPY FROM PROGRAM — then re-running the same probes and watching them be refused
• judgment: how to write this up so the owner acts (the fix is 'the reachable account must never be a superuser', not just 'add a firewall rule')

Steps in this lab

1. What PostgreSQL is, and why an exposed superuser is worse than an exposed cache
2. Build the isolated lab: two containers, one private network, your machine only
3. Confirm the exposure — a superuser session with no password
4. Read server-side files with pg_read_file() — and see why it needs superuser
5. The headline: command execution with COPY ... FROM PROGRAM (in your own container)
6. The fix, and the measurement: real auth, a locked-down listener, and a least-privilege role
7. Do it better — recognise, report, and prevent the exposed database

Open the full interactive lab →