Ghoul
This post is a write-up for the Ghoul box on hackthebox.eu
Enumeration
Start enumerating the ports on the victim machine by running Nmap and Masscan:
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:
Browsing to secret.php contains a fake user flag:
The website at port 8080 contains a login! I always try stupid passwords first, and fortunately admin/admin worked!
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.
The ZipSlip vulnerability allows you to upload files to a location that is under your control. Follow the below steps to pop a shell:
- Place a PHP Reverse Shell into
/var/www/htmlon the attacking machine. - Create the zip by running
zip abc123.zip ../../../../../../../var/www/html/rev.php. - Upload
abc123.zipand call your PHP Reverse Shell:
Getting User
Run LinEnum and document the results:
Run LinPEAS and document a potential password test@aogiri123:
/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:
The keys directory contains the SSH Private Keys for eto, kaneki and noro:
Try to SSH into the victim machine using the kaneki.backup SSH Private Key from the victim machine:
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:
Use the password found to SSH into the victim machine and grab the 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:
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
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:
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
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):
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:
After enumerating this machine and not finding a Gogs Server, run ifconfig to see if this will give us another machine to attack:
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
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:
Kick off a quick Nmap scan to make sure the tunnels are working, and that we have the correct target for the Gogs server:
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:
Use these credentials to login to the Gogs server:
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):
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:
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:
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
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:
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:
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
