Hancliffe is a hard rated machine on HackTheBox created by Revolt. For the user part we will abuse a path normalisation vulnerability and a CVE in nuxeo to achieve RCE and a foothold on the machine. On the machine the running Unified Remote 3 version has another know vulnerability which gives us a shell as clara. For the root part we will find credentials for a password manager in clara’s firefox data. This let’s us login via PSRemote as the development user, who has access to a directory with an application running as administrator. This application has a buffer overflow vulnerability which we can abuse to achieve a reverse shell as administrator on the machine.
User
Nmap
As usual we start our enumeration of with a nmap scan against all ports followed by a script and version detection scan against the open ones to get an initial overview of the attack surface.
All ports
1 | |
Scrip and version
1 | |
Nuxeo
From the open ports the web ports seem promising so we start there. Going over to port 80 we see the default nginx hosting page.
On port 8000 there is an installation of a password manager running which doesn’t seem of much use just yet.
Running a gobuster scan on the application on port 80 we can identify a maintenance directory which get’s redirected to /nuxeo/Maintenance/.
1 | |
Looking for recent vulnerabilities in nuxeo we find CVE-2018-16341. Going over to /maintenance it just displays a we'll be back soon page.
The application does howerver perform a dangerous path normalisation which let’s us access the directory one path up leading to access to the login.jsp page mentioned in the PoC exploit of the CVE. This page also displays the running version of nuxeo which seems to be promising for the vulnerability to be present.
Testing for the SSTI with a simple payload we can see that our code gets evaluated, confirming our suspicion.
Following the PoC of the exploit we can build a payload adding an additional parameter in the exec part. This let’s us move our complete payload to the end of the request.
1 | |
We start a python webserver to host our netcat binary and listen on the port we want to recieve the reverse shell.
1 |
|
1 | |
Now we can send the request in burp, url encoding the whole SSTI part of the payload to safely send bad characters.
We get a hit on our web server for the nc64.exe binary and almost instantly after a reverse shell on our listener as svc_account
1 | |
1 | |
Unified Remote 3
Looking for unusual installed programs we find Unified Remote 3.
1 | |
Checking google for known vulnerabilities we find this PoC, which seems promising to achieve RCE. A quick check with netstat shows the port mentioned is indeed listening on the machine.
1 | |
To access it from the outside we upload chisel to the machine and forward the traffic with its socks proxy.
1 | |
1 | |
1 | |
1 | |
We also modify the main function of the PoC specifying arguments to the downloaded executable, which will be netcat in this case.
1 | |
We serve the binary with a python web server again and start a listener on the port we specified.
1 |
|
1 | |
Running the exploit with proxychains we get a hit on our web server and shortly afterwards a reverse shell back on our listener as clara.
1 | |
1 | |
As clara we can now pick up the user flag and continue our way to root.
1 | |
Root
Firefox decrypt
Looking at clara’s firefox profile we see that the key4.db isn’t empty which looks promising.
1 | |
To transfer the files we stand up a smb server with impacket and copy logins.json, key4.db, storage.sqlite and places.sqlite to our machine.
1 | |
1 | |
Now we can use firepwd.py to dump the credentials stored. This reveals what seems to be the master password for the password manager running on port 8000.
1 | |
With this password we can use the app to retrieve the password of the development user.
Testing the credentials against winrm we are able to log into the machine.
1 | |
BOF
We now have access to the C:\DevApp directory on the machine.
1 | |
The powershell script seems to run and restart MyFirstApp.exe. It also maps the port the app is running on to 9999 which we identified earlier in our nmap scan. Since this command needs administrative access to run we can assume that the binary is running in high integrity context on the machine.
1 | |
We transfer the binary over to our machine and open it up in ghidra. We see that it takes input for a username and a password and passes it to the _login function.
In this function we can identify the username to be alfiansyah. For the password it calls two encryption functions on the input, base64 encodes the result and then compares it to YXlYeDtsbD98eDtsWms5SyU=.
Looking at the first encryption function it seems to be atbash.
The other encryption function looks like rot47.
Since both of these encryptions are present in cyberchef we can just use it to decode the base64, decrypt atbash and rot47.
Looking further down the application flow in ghidra we see it also reads a FullName and a code. It then calls the _SaveCreds functions on the values it read.
The interesting part here is that the passed arguments can be both 0x50 bytes long but in the _SaveCreds function it calls strcopy on the code parameter which only has a buffer of 50 bytes resulting in a buffer overflow vulnerability.
To take a close look at the binary we transfer it over to our windows machine and open it in x32dbg. Checking for protections with the ERC plugin using ERC --ProcessInfo we can see that ALSR and NX are disabled.
To exploit this we first need to find the offset we can create a pattern to do this with ERC --pattern c 500. We take this pattern and build a short python script with pwntools to crash the program.
1 | |
After the crash we can find the offset with ERC --FindNrp. This returns an offset of 66 and also reveals that the start of our input ends up in the eax register.
Since space is limited we cannot place a full payload and just point eip to it. The space in eax however is big enough to place an egghunter there and let it search the actual shellcode passed to the initial 0x400 read for the code. For this we first need to find an instruction to jump to eax to execute our egghunter.
We can find a short egghunter on this blogpost. This egghunter has been created by the mona plugin of immunity debugger for wow64 applications on windows 10(32 bit applications running on a 64 bit OS). The only problem we have to deal with is that the stackpointer needs to be decremented to avoid overwriting our own egghunter. We can use defuse.ca to generate the needed shellcode and place it at the start of our egghunter code. Next we also replace the string the egghunter searches for with w00t.
Now we have to generate the shellcode for our reverse shell using msfvenom, specifying our ip and the port we want to recieve the reverse shell on.
1 | |
The finished exploit script looks like this. We open a connection to the application running on port 90. We then send the username and decrypted password. For the fullname we can pass it anything and the code will be our payload. The payload consists of our egghunter padded with nop instructions up to the eip overwrite. eip contains the jump eax instructions and we add a few bytes afterwards to avoid that the search string ends up on the stack. Since there isn’t enough space our payload would be cut off at this point and if the egghunter finds this string the exploit would fail. After those nop’s we can now place our string to search for followed by the shellcode.
exploit.py
1 | |
We set up a ncat listener on the port we specified and run the exploit script.
1 | |
1 | |
After a short delay the egghunter finds the string and moves execution to the shellcode resulting in a reverse shell as the administrator user and the root flag.
1 | |
Unintended
Initially there was also an unintended way that skipped the buffer overflow part of the machine. Looking at the ACL for C:\devapp you could see that authenticated users have modify rights. Since the script restarting the app just looks at the path you could simply move the folder somewhere else, create a new C:\DevApp folder and place an exe inside the folder.
1 | |
First you had to move the current directory out of the way, create a new one and copy the script there.
1 | |
Next you started up a handler inside metasploit and generated a meterpreter executable.
1 | |
1 | |
You placed the meterpreter as MyFirstApp.exe inside the new C:\DevApp folder. After some time the the script restarts the exe sending a meterpreter session as administrator.
1 | |
1 | |
Now you could simply grab the root flag on the administrator’s desktop.
1 | |