Lion Cipher Lab

Exploit an unauthenticated MongoDB in your own lab

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

Why it matters

Exposed, unauthenticated databases are one of the most common serious findings on the entire internet, and MongoDB is the case that taught a whole industry the lesson the hard way. MongoDB is a DOCUMENT DATABASE: instead of tables and rows it stores JSON-like documents grouped into collections, and it became enormously popular because that model maps neatly onto the objects a web app already works with. For years its default configuration was a trap waiting to spring — early versions bound to every network interface out of the box, and to this day the server ships with NO authentication…

What you'll learn

• defining what MongoDB is, what a document, collection and database are, and what 'no access control' actually means for a database you can reach over the network
• standing up an isolated two-container lab (a MongoDB server and an 'attacker' client with mongosh on a private Docker network) so the whole exercise touches nothing but your own machine
• confirming unauthenticated access from a second host with mongosh: listing databases, enumerating collections, and reading and writing documents with no credential
• reproducing the real-world data-breach-and-ransom scenario in miniature — reading someone's data, understanding the dropDatabase blast radius, and planting a ransom-note collection — without ever touching a real target
• explaining accurately WHY MongoDB exposure differs from Redis: it is a mass data breach and ransom risk, not a built-in write-to-disk remote-code-execution primitive, and being precise about impact is part of the finding
• naming the two safeguards you had to disable to reproduce the bug — the localhost-only default bind and the no-authentication default — and why disabling them is what makes this a misconfiguration and not a MongoDB vulnerability
• applying the fix: enable access control (--auth), create a user administrator and least-privilege application users with role-based access control, bind to loopback or a specific interface, and add TLS and a firewall
• measuring before and after with the same probe: `show dbs` succeeds unauthenticated before the fix and returns 'requires authentication' after it
• judgment: recognising the finding on sight from an unexpected open 27017, reporting the real (data) impact rather than an inflated one, and preventing recurrence structurally

Steps in this lab

1. What MongoDB is, and what 'no access control' actually means here
2. Build the isolated lab: two containers, one private network, your machine only
3. Confirm unauthenticated access — the finding, from the attacker container
4. The real-world scenario: the MongoDB ransom wave, in miniature
5. Why the default is safe — and why exposed MongoDB still happens anyway
6. The fix, part 1: enable access control and create scoped users (RBAC)
7. The fix, part 2: measure it, then defence in depth (bind, TLS, firewall)
8. Do it better — how to recognise, report, and prevent the exposed database

Open the full interactive lab →