Ghoul

Updated:

Tags: , , , , , , , , , ,

This post is a write-up for the Ghoul box on hackthebox.eu

Ghoul Info

Enumeration

Start enumerating the ports on the victim machine by running Nmap and Masscan:

Running nmap reveals four open ports

Running nmap reveals the following information:

  • Port 22
    • SSH Server
  • Port 2222
    • SSH Server
  • Port 80
    • Apache web server
  • Port 8080
    • Apache Tomcat web server

Poking around the website hosted at port 80 did not result in anything interesting:

Main website

Browsing to secret.php contains a fake user flag:

`secret.php` website

The website at port 8080 contains a login! I always try stupid passwords first, and fortunately admin/admin worked!

Port 8080 Login

A Sierra website is found which immediately presents zip file upload capabilities. After testing a few zip uploads, I realized I had no idea where the files ended up.

Sierra website

The ZipSlip vulnerability allows you to upload files to a location that is under your control. Follow the below steps to pop a shell:

  1. Place a PHP Reverse Shell into /var/www/html on the attacking machine.
  2. Create the zip by running zip abc123.zip ../../../../../../../var/www/html/rev.php.
  3. Upload abc123.zip and call your PHP Reverse Shell:
Creating and calling PHP Reverse Shell

Getting User

Run LinEnum and document the results:

`LinEnum` Output

Run LinPEAS and document a potential password test@aogiri123:

`LinPEAS` Output

/var/tmp contains your uploaded .zip file, a pretty strange python script, and a PDF file. /var/backups/backups on the other hand contains some interesting things:

`/var/backups/backups` directory

The keys directory contains the SSH Private Keys for eto, kaneki and noro:

Backup keyfiles

Try to SSH into the victim machine using the kaneki.backup SSH Private Key from the victim machine:

SSH as user `kaneki`

A SSH Passphrase!? Since the entire box has a theme, use cewl to create a wordlist of the secret.php page. Then run the following commands to convert kaneki’s SSH Private Key to a John readable format, and launch John to bruteforce kaneki’s SSH Private Key:

Bruteforcing the SSH key using John

Use the password found to SSH into the victim machine and grab the user flag:

SSH as user `kaneki` and user flag

Getting Root

After logging in, notice that /home/kaneki/note.txt references a vulnerability in Gogs. Since we are not sure where the Gogs server is, continue to enumerate the victim machine:

`Gogs` reference

During futher enumeration, notice that /var/tmp/rev.php was created as root. This should be an “Ah-Ha!” moment, so create another payload using the ZipSlip vulnerability, this time overwriting /root/.ssh/authorized_keys, allowing you to SSH into the victim machine as root:

ssh-keygen -b 2048 -t rsa -f /root/abc123.key -q -N ""
ssh-keygen -y -f abc123.key > abc123.pub
cat abc123.pub > /root/.ssh/authorized_keys
sudo zip abc1234.zip ../../../../../../../../root/.ssh/authorized_keys
ssh -i abc123.key root@10.10.10.101
Creating `authorized_keys` payload

Unfortunately, it looks like the root flag does not live on this victim machine (very common in real-world scenarios). Try to find some network users that could give us a clue to another target machine. /home/kaneki/.ssh/authorized_keys has a SSH Public Key for the user kaneki_pub:

Kaneki's `authorized_keys` file

Since Nmap is not installed, use the below command to scan for devices that are alive in the 172.20.0.0/24 subnet:

for ip in $(seq 1 255); do ping -c 1 172.20.0.$ip > /dev/null && echo "Online: 172.20.0.$ip";done
`172.20.0.0/24` ICMP scan

SSH into 172.20.0.150 with kaneki_pub’s SSH Public Key found in /home/kaneki/.ssh/authorized_keys (Assume the same SSH Private Key and Passphrase was used):

SSH as user `kaneki_pub`

As always, start enumerating as this user. /home/kaneki_pub/to-do.txt references AogiriTest user that might have access to git. Remember the Gogs server? Document this user for when you get access to Gogs:

Contents of `to-do.txt`

After enumerating this machine and not finding a Gogs Server, run ifconfig to see if this will give us another machine to attack:

`kaneki-pc` ifconfig

172.18.0.0/24 is a target subnet, run the ICMP command again with this new subnet. The only logical choice is 172.18.0.2, so that is the target machine. Run the following command to check for open ports on this victim machine:

for port in $(seq 1 65535); do (echo > /dev/tcp/172.18.0.2/$port) &> /dev/null && echo "Port $port is open"; done
`172.18.0.2` port scan

In the Gogs FAQs, notice that port 3000 is the default port used. Use two SSH forwarders to tunnel from your attacking machine localhost:3002 -> Aogiri:3001 -> kaneki-pc:3000:

SSH forwarders setup

Kick off a quick Nmap scan to make sure the tunnels are working, and that we have the correct target for the Gogs server:

`Nmap` scan of 172.18.0.2:3000

Browse to localhost:3002 and finally find the Gogs login! Unfortunately, any interesting Gogs exploit has to be run as an authenticated user. You know that AogiriTest should have access, so go back to your LinePE results, and grab the potential password test@aogiri123:

LinePE Result

Use these credentials to login to the Gogs server:

Authenticating into `Gogs`

A quick Google search for Gogs vulnerabilities results in gogsownz, which exploits a Gogs administrator user’s Git Hook and provides RCE! Clone the repository and run the exploit against http://172.0.0.1:3002/(Remember the SSH forwarders are still running):

`gogsownz` exploit in action

Check for SUID Bits and Google /usr/bin/gosu. You should come across a pretty nifty sudo tool written in Go. Run gosu -h and notice that it even makes it easy to execute a privesc directly from the application:

Running `gosu` SUID privesc

This frustrating victim machine still does not let you just cat the root flag. At least your enumerating skills are getting sharpened. Document the password in /root/session.sh and transfer aogiri-app.7z to your attacking machine for further analysis:

Copy `aogiri-app.7z`

Extract aogiri-app.7z and notice that it contains a .git repo in /aogiri-chatapp. Firing off some GitHub Dorks to see if there is any sensitive information leakage did not result in much. A quick Google search resulted in a pretty awesome one-liner using gitk and reflog:

git reflog | awk '{ print $1 }' | xargs gitk
Scanning for Git Repo sensitive data

2 Passwords should be found:

  • 7^Grc%C\7xEQ?tb4
  • g_xEN$ZuWD7hJf2G

Recap all that you have found and exploited:

  • Aogiri@172.20.0.10 - rooted
  • Kaneki-PC@172.20.0.150/172.18.0.200 - No root
  • 3713ea5e4353@172.18.0.2 - root

Use 7^Grc%C\7xEQ?tb4 on kaneki-pc to escalate to root:

`kaneki-pc` root escalation

Seriously, a troll at this stage… Use pspy64 to see if there are any unknown cronjobs running that were not previously shown as the kaneki_pub user:

`pspy64` output

Interesting. So every 6 minutes an SSH Agent is created. Looking at the service status, the cron service is not active which means the cron is triggered externally, but it allows the system to ssh root@172.18.0.1 at port 2222. This seems like a really good place for a SSH Session Hijack.

Run the below commands to remove stale agents and hijack the new SSH session, then grab the root flag:

rm -rf /tmp/ssh-*
while true; do export SSH_AUTH_SOCK=/tmp$(find . -name 'agent.*'| cut -d "." -f 2-10);ssh root@172.18.0.1 -p 2222;date;sleep 1;done
SSH Session Hijack and root flag