Hack The Box - Love
In this post, I walk you through Love from Hack the Box, an easy Windows box where good enumeration is the key to success. The box contains a bunch of open ports, the main interesting ones serving HTTP are 80, 443 and 5000. This last one gives access denied, but on ports 80 and 443 you will find a voting system secured by a login prompt. Via the certificate on port 443 you can leak some extra domains that give access to a tool that contains a CSRF that allows you to access services on localhost. This way, you get access to the service running on port 5000, which has admin credentials that grant access to the voting system. Once in the voting system, we can leverage a known CVE to upload a malicious payload and get a reverse shell on the box. On the box, you then execute an msi
to get root. With all that said, let’s dive right in and start our port scan enumeration.
Enumeration
We are starting our investigation with a nmap scan. This allows getting a better overview of what is exposed on the target machine. We’ll use -sV
to enumerate versions, -sC
to run all default scripts, and store the output in a file named nmap.txt
. This way, we can always refer back to it later. This machine contains a fair few of open ports, hence why the scan might take some time. Add -v
as a parameter if you want nmap to show open ports while it finds them.
There is lots of good stuff in this output. A few things to note are the open ports 80, 443 and 5000 serving some HTTP applications. Digging a bit deeper into the result for these ports, we can see the certificate and service info leaking the following domains for us:
- www.love.htb
- staging.love.htb
Let’s add them to our hosts file and see what we get:
On www.love.htb
we find a Voting System application protected by a login page:
On staging.love.htb
, we find some file scanner.
Going to 10.10.10.239:80
we get presented with the Voting app again. But trying to open 443
or 5000
we get presented with a forbidden page:
Given the Voting System
app is protected by a login, let’s focus on the file scanner tool first. But before we do that, let’s kick run a gobuster
scan against this app and see if we can maybe find some hidden paths that can leak some interesting information:
In the file scanner tool, let’s try and upload a file and see what happens. From the nmap output, we can see an apache running PHP so let’s try and upload a couple of files and see what happens. Maybe we get lucky and get easy code execution. We can spin up a local webserver with with python -m http.server
and serve a few simple files:
With this in place we have a couple of files that we can upload from our local machine. A plain text file and a very barebones php file to test if we can get any form of code execution.
We can see that the file uploader calls our local service, downloads the file, and then just echos the file’s contents right back to us. Let’s open Burp suite and make the same request again to intercept the request and send it over to the repeater. This way, we can more easily play around with this upload tool.
We can start tweaking this request in the repeater and upload the different payloads that we prepared earlier. But whatever we upload just get’s send back to us. So other than maybe XSS, this seems to be a dead-end:
But we can see that this tool is actually sending out HTTP requests. We could see the request come into our python webserver. So let’s think about this for a second: we have access to a piece of code that can make outbound requests from the target machine. This means that we can start making requests to the localhost of this target machine via this service. Often services running on localhost don’t have the same set of access checks in place. This is because requests are not going through whatever reverse proxy is enforcing these checks but rather directly to the web app. Earlier, we noticed that when going to http://10.10.10.239:5000
, we got presented with a forbidden page. Let’s try accessing this service directly from localhost through this tool:
Foothold
We got a set of credentials that we can use to log into the Voting System application. If you look at the results from the gobuster
scan we kicked off earlier. You will see a /admin
path. Let’s open that page and see if these credentials work:
- Username: admin
- Password: @LoveIsInTheAir!!!!
Let’s use searchploit
and see if we can find a known exploit that we can use to get a foothold on the box:
The last one looks interesting: Voting System 1.0 - File Upload RCE
and get a copy of the script into a local folder:
As is, the script doesn’t work, so we’ll need to make a couple of changes. First, we’ll need to add the correct URL, username, and password in the settings area. Besides that, we’ll also need to change the hardcoded URL’s. The script assumes that the whole app is running behind /votesystem
, but in our case everything is hosted behind /
:
With those changes in place, all we have to do now is prepare our reverse listener and kick of the script:
And we got a shell on the box that gives access to the user flag:
Lateral Movement
To fingerprint the system and get an idea of our next steps lets run WinPEAS. After cloning the repo to your local machine navigate to the directory containing winPEASany.exe
and start a Python web server with python m http.server
. This way we can with PowerShell
easily download and directly execute this binary:
I removed any noice from the very long output that WinPEAS
generates. The interesting part is that AlwaysInstallElevetad
is set to 1. These registry keys tell windows tha a user of any privilage can install an msi
file as NT AUTHORITY\SYSTEM
. All we need to do here is craft a malicious installer and run it to get access as the system user.
To generate this installer we can use a tool called msfvenom
and have it execute a reverse shell payload that we can point to an nc
listener running on our local machine. On our local machine execute the following command to generate the payload:
You can see it generated a 32-bit payload. On this machine, the payload type isn’t all too important. Windows has a thing called WoW
or Windows on Windows, allowing us to easily execute 32-bit binaries on a 64-bit system. If you ever bumped into Windows Core or Windows IOT, then WoW
will most likely not be present.. In that scenario, it will be important you create the correct payload.
From the directory where you created the msi
installer, launch another web server with python so can easily drop the installer on the box:
And we are in! As you can see we have access as NT AUTHORITY\SYSTEM
and are able to read the root flag: