The web root presents a Rick and Morty page with a login portal. No credentials are given. The first move in any web assessment is to read what the server is willing to tell us for free: the page source and well-known files.
Viewing the page source reveals a developer note left in an HTML comment — the username.
Checking /robots.txt surfaces a single suspicious string — the password.
| Source | Value Found | Role |
|---|---|---|
| HTML comment | R1ckRul3s | Username |
| /robots.txt | Wubbalubbadubdub | Password |
Logging in with R1ckRul3s / Wubbalubbadubdub lands on /portal.php, which exposes a command execution panel. This is effectively a web shell running as the web service user — arbitrary Linux commands can be run against the host.
The first ingredient sits in a file in the web directory. cat on some commands is filtered, so a substitute such as less or grep reads it. The second ingredient is elsewhere on the filesystem — find locates it, and a read returns it.
The final ingredient lives in /root, which www-data cannot read. Checking sudo rights reveals the misconfiguration that ends the box.
(ALL) NOPASSWD: ALL means the web user can run any command as root without a password. Reading the root directory becomes trivial.
Developers routinely leave credentials in HTML comments and configuration files like robots.txt during development and forget to remove them before production. Always check source code and standard file locations before attempting anything complex.
Audit HTML source before deployment — use automated secret scanning (git-secrets, TruffleHog). robots.txt is public by design. Never store credentials in it. Apply the principle of least privilege to all sudo rules.