Skynet - TryHackMe Room Writeup
The link for this lab is located here: https://tryhackme.com/room/skynet
In this room, we will cover using Gobuster on a website, using SMBclient and SMBMap to enumerate shares and exploiting a CMS RFI vulnerability as well as wildcard privilege escalation.
Full Walkthrough
The first step is to scan the machine to find any potential open ports. For this scan, I scan all ports to get an idea of what is open.
This reveals some things are open such as SSH, HTTP and SMB. With these ports, we can run a more detailed scan to get some version information and possible OS detection.
We get some information including OpenSSH version 7.2p2, Apache 2.4.18 and possible email server called “Dovecot pop3d” as well as some Samba information indicating this is a Linux machine possibly running Ubuntu.
With this information, we can first check out the website.
This reveals what looks like a Google search clone with a simple search bar. Seeing that there is nothing else here, we can check the source code to see if anything is being hidden or any hidden comments - unfortunately there are none.
Next, we can try running gobuster to find hidden directories. After a short while, we get a return for a “/admin” page which seems interesting.
We can leave gobuster running for a little while. Before delving further into the website, we can first check out the SMB ports which could reveal some information. First, we use smbclient to list all the shares available - when asked for a password, don’t enter anything.
As we can see there is an anonymous share and a milesdyson share. Going off the names, we probably don’t have access to the milesdyson share but we can more than likely access the anonymous share without credentials.
To connect to the SMB share, we can use smbclient once again.
Once in the share, we can list all the files with the “ls” command. This reveals an “attention.txt” file. To download it, we can use the “get” command.
There is also a “logs” directory. Navigating inside, we see three logs which we can also download.
First, looking at the attention.txt file, we see a message saying that various passwords have been changed and everyone needs to change their password.
Next, looking through each of the log files, 2 are empty. However, the log1.txt file has what seems to be a list of potential passwords or old passwords.
Going back to the dirbuster scan, we see some interesting results. The most interesting of which is the /admin panel (probably need credentials) and a directory called squirrelmail.
Going to the /squirrelmail directory reveals a mail service login page indicating the version - version 1.4.23
Searching around for this version for exploits reveals a Github page with a script for a Remote Code Execution exploit (CVE-2017-7692).
However, looking at the source code for this exploit reveals that we need some user credentials. Dammit! Maybe we can utilize that potential list of passwords we found earlier to try and bruteforce credentials?
First, we can intercept a login request to SquirrelMail with any password and try using the username of “milesdyson” which was the name of the share we saw earlier.
Once intercepted, we can send it to Intruder and add our parameter we want to bruteforce - in this case the secretkey field i.e. the password.
Next, we can load that log.txt password list into Burp Suite as our payload.
As an extra, we can also look for the error message that appears with false credentials by entering some fake credentials and looking at the message that appears. In this case, “Unknown user or password incorrect”.
Using this, we can add a Grep - Match string to our results which will flag any results with a certain string - in this case, the error message.
Letting Intruder run for a while, we can see that one entry does NOT match that grep string possibly indicating it was able to login successfully or something else happened.
Looking at the response of that particular request, we see that it returned a status code of 302 Found while also setting some cookies and indicating another location of webmail.php - this confirms it was able to login.
Using these valid credentials we just found, we can login to the mail application.
Looking through the various emails, we come across one that indicates that our (milesdyson) SMB password was changed revealing the password.
Aha! Now we have the password to possible access the milesdyson share. To do this, we can once again use smbclient with the “-U” parameter to specify we want to use the milesdyson user.
Listing the contents of this directory, we find various PDF documents and a directory called “notes”.
Navigating inside “notes”, we see a tone of markdown files but a file stands out - important.txt.
Downloading this file using “get” and looking inside, there is a note that tells us we need to add features to beta CMS /45kra23zxs28vy3d. This sounds like a new directory we can navigate to on the website.
Going to this directory does indeed reveal a new webpage for Miles Dyson.
Knowing this new webpage exists and that it is running some beta CMS, we can run another gobuster scan to reveal any new subdirectories. After a while, a /administrator page is found.
Navigating to this new page reveals a login form.
Password re-use is very common so we can try using the same credentials we did for both SquirrelMail and the SMB share.
Unfortunately, this doesn’t work. The next step we can try is looking at the source code - maybe there is some hidden default credentials.
There are no credentials but there is a forgot password option that has been commented out. This comment gets returned via the server when we refresh the page. We can try intercepting the response via Burp Suite by first checking the option to allow us to capture server responses.
After refreshing the page, we can get to the server response. Once we have the response, we can try uncommenting the forgot password option and forwarding it on.
This, in turn, should reveal a forgot password option on the web page.
Clicking on this new link shows that we can enter an email and reset our password.
Remember we have access to SquirrelMail? Unfortunately however, we don’t have the specific email address - only the username so it seems out of question.
Instead, we can try googling for the Cuppa CMS and see if any exploits exist. After a bit of researching, we find a Local/Remote File Inclusion vulnerability.
Reading the exploit, we first can see that using this, we can include local or remote PHP files - also giving us a URL.
Moreover, we get the actual URL we can use. In the example provided, we could possibly read the /etc/passwd file using the urlConfig parameter.
Knowing that this vulnerability possibility exists, we can read some files. One method would be to host a malicious reverse PHP shell via Python and execute it using this method. However, another more interesting idea I had was “What if we can read the configuration files? Maybe they include some credentials or useful information?”
With this idea, I did a bit of researching and found this particular post:
This says we can steal secrets from a config file by using a PHP filter command to convert the config file to Base64 and then outputting it instead of executing it.
Using this, we can possible read the Configuration.php file via the vulnerable path found earlier (urlConfig=).
Taking this massive string and decoding it from Base64, we get some possible credentials - it tells us the database name is cuppa, the user is root and the password is password123.
These might be useful later so keep them. Instead of reading the config file, we can also try reading the /etc/passwd file as described already.
With this vulnerability now confirmed to be working, we can use a PHP reverse shell. First, we have to change the IP and port in the source code - I changed it to port 8888.
Next, we simply host this PHP file using Python.
Once again use that vulnerable path but this time indicate the path to our reverse shell being hosted.
Before hitting Enter, we start a netcat listener.
After hitting enter, we should receive a reverse shell.
Before going any further, I always like to stabilize the shell using various methods. In this case, I used python to spawn a BASH shell.
With this shell, we can simply navigate to the /home/milesdyson directory and grab the user.txt flag.
As seen in the previous file listing, there is a backups folder in milesdyson home directory. Looking inside, we see a backup.sh script which simply moves into /var/www/html and creates a tar archive. More importantly, it is being executed as root and using a wildcard!
Seeing this script, it is possible it is being executed by crontab to be scheduled at certain times. Looking at the /etc/crontab file, we can see that it is being executed every minute and, once again, as the root user.
Using GTFOBins, we can see there is a way to use tar to get root privileges. First, we simply echo the echo command into a script file which then adds www-data user to the sudoers file with all permissions. Next, we simply echo “/var/www/html” into a file called “--checkpoint-action=exec=sh privesc.sh”.
Finally, we echo “/var/www/html” into another file called --checkpoint=1. This article explains it.
After about a minute, using “sudo -l” we see that the user we are running as (www-data) now has full sudo permissions with no password required.
Seeing this, we can simply execute “sudo /bin/bash” to gain a root BASH shell.
Then, finally, we can navigate to /root to grab the root.txt flag.
