TryHackMe — Skynet

Disclaimer : All my post are intended for my personal notes, any methodologies, tools or ways that can be suggested are most welcome! :)

Now let’s try to crack another fun box from tryhackme. A linux box named Skynet. I already hacked into the box with my friend (follow his cybersecurity journey on his youtube channel).

Let’s deploy the machine and scan all ports using nmap.

nmap -Pn -p- -oA nmap/portScan 10.10.41.153 -vv

Let’s also try to using masscan to scan all possible ports. You can find a great write-up and methodology about masscan, autorecon and other tools here. Let’s try to get some methods and tools that we can use against our target.

masscan -e tun0 -p1–65535 — interactive 10.10.41.153

Run autorecon by Tib3rius in parallel with port scans.

autorecon 10.10.41.153

We can see how great Autorecon tool is, it does most of the work for us to get our initial shell.

1st Checkpoint

Let’s try to recollect after those scans.

• We got 6 open ports available. 22,80,110,139,143 445.
• Port 22 is for SSH
• Port 80 is for http (website?)
• Ports 110,143 are for pop3 and imap. Services needed for sending and retrieving emails.
• Ports 139,445 are for smb.

Enumeration

Ports 110,143

Reading the result of nmap ran by autorecon agains those ports.

port 110

port 143

So far, nothing really caught our attention here.

Ports 139,445

Let’s try to check the result against smb ports.

Results are the same for ports 139 and 445.

So, we got a user : milesdyson

We got anonymous login shares except for milesdyson’s.

And we got some interesting files inside the anonymous folder.

Let’s try to download them using smbget command.

smbget -Rv smb://10.10.13.123/anonymous

Let’s try to look around the files we’ve downloaded and check for interesting information.

According to attention.txt, all employees are required to change their password and inside the log1.txt file, bunch of words that seem to be passwords.

So, we got milesdyson as username and password file, seems we can use it for brute forcing the password.

Note: We can actually try each password to the first question on skynet so we can get the correct one instead of brute forcing the application.

Port 80

Port 80 seems to be a dead-end, we got a search engine that doesn’t really function. However, according to the room we need to find a hidden directory so that gives us a nudge on what to do, maybe we can do a go buster against port80. Reviewing the result of gobuster from autorecon tool.

checking all the hidden directories, we end up to ‘/sruirrelmail’ folder.

So we got a ‘webmail’ perhaps we take note of the squirrel mail version 1.4.23 it will come handy, then we can try to use the username and password file we have found. Let’s try to use hydra.

First we intercept the login request and copy the request parameters.

Then we supply it as the body of the http-post-form flag on hydra. It should look somethine like the screenshot below.

hydra -l milesdyson -P ../../logs/log1.txt 10.10.147.12 http-post-form “/squirrelmail/src/redirect.php:login_username=^USER^&secretkey=^PASS^&js_autodetect_results=1&just_logged_in=1:user or password incorrect” -vvv

Nice! we got the password for logging inside the squirrelmail. Let’s try to login.

We got 3 emails from 2 users, skynet@skynet and serenakogan@skynet. Looking around the emails.

It says in this email that the samba password reset for milesdyson was reset to )s{A&2Z=F^n_E.B`. Gold! Let’s try that to login to smb shared folder that doesn’t allow anonymous login, but let’s try to stick our nose to other emails.

Converting the binaries.

So, I don’t want to overthink about those last 2 emails. Let’s try to login to SMB using the password we found.

Use smbclient and supply the username and the password we found.

The file that stands out the most is the that important.txt file. Let’s download it and read the contents.

It says about the beta CMS or content management system, we did not scan it earlier, so maybe it was the answer on the second question.

And it is.

Let’s now check the hidden directory.

It’s another dead end. The third questions ask something about remote file inclusion, so maybe there’s a more interactive page here we can discover, now let’s run gobuster.

gobuster dir -u 10.10.161.65/45kra24zxs28v3yd/ -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -t50 -x txt,bak,config -s 200,204,301,302,307

We found another hidden directory ‘/administrator’ let’s try to visit url.

We were welcomed by a login page that says about ‘cuppa cms’.

Tried using credentials we got and tried using SQLi bypass — no go. It also says on the code to enter email to reset the password but the forgot password facility was commented out.

Let’s now try to search for possible public exploit for cuppa. Run ‘searchsploit cuppa’ and we got 1 result with a text file.

searchsploit cuppa

let’s copy the file to our working directory and read the content.

It says here that the cuppa CMS has RFI and LFI vulnerability. Let’s check if the version of cuppa we have is vulnerable. Let’s try to dump the etc/passwd file.

It seems to be working. We can also dump the user flag user.txt

There goes our user flag. How about the root flag root.txt?

But for some reason (perhaps cms was not installed as root) I cannot read the root flag. It seems this is as far as we can go using LFI.

Let’s now try to gain access to server by using RFI vulnerability of the CMS.

Copy the php-reverse-shell.php (default in kali) to our working folder.

Let’s change the target IP and port number.

For the RFI to work, we need to set up our local http server (we can do so using python) and set up a listener using netcat, so once our attack machine served the reverse-shell file using RFI vulnerability, the target machine will execute it and will throw a reverse shell back to us, catching it with a netcat listener.

We have successfully gained our initial low-privileged shell.

Let’s now upgrade the shell using the classic python pty command below.

Let’s upload linpeas for faster privilege escalation enumeration, run it and review the results.

Note: My friend has successfully rooted the machine using kernel exploit. He pointed out that lipeas has given him the CVE details of the exploit. Will update my notes/write-up once I have reviewed how it works.

One of the possible exploit is the file inside our user’s directory.

Linpeas flagged it as ‘high’ possibility for exploit.

Note to self: Try other scripts and compare the results. Don’t forget your manual scripts.

backup.sh is owned by root. Let’s try to figure out what it does.

So, it goes to /var/www/html folder and run ‘tar’ command to backup the all the files in directory to user’s directory. Let’s check the crontab.

Cron job run the file every minute, let’s check if it really does.

As we can see, the time was updated from 16:59–17:00 confirming our initials findings.

Now let’s find out how we can exploit the file without write access to it and being run by cron job every minute.

Search the go-to GTFOBins for tar and found that we can actually spawn a shell with tar command. How about gaining higher level of permission? It says here that we can use sudo command and though our access is not in sudoers file, the file was being executed by root.

I search for more information about privilege escalation using tar, and found a very great article. So, the wildcard * (asterisk) in the backup.sh was there on purpose, to elevate our privileges, or it wants to show us that carelessness of system admin can lead to unimaginable problem.

So, according to the article, we will going to create a script that will put our user (www-data) into sudoers file with no password. We also need to create some files that will make tar command execute our malicious script.

Let’s begin, first we go to the directory where tar grabs files for backup > /var/www>html.

we create a malicious .sh file that will add our users to sudoers file. In order to do that, we will need to issue 2 echo commands in between the ‘ and “ (clever!) then send it to an sh file.

echo ‘echo “www-data ALL=(root) NOPASSWD: ALL” > /etc/sudoers’ > privesc.sh

Then we need to create 2 files.

1. — checkpoint-action=exec=sh privesc.sh
2. — checkpoint=1

Then that’s it! We need to wait for a minute so we can call bash with sudo command.

And we got root!

Takeaways:

1. Always check if the application you were using has public exploit, patch and update if there are resolutions
2. Be mindful of the file permissions.
3. Be careful when creating scripts, we know that we want to make our life as easy as possible by create scripts for repetitive tasks, however, be mindful on commands, parameter and script, as we might putting our machine at risk unknowingly.

I have really enjoyed pawning the machine with my friend, we actually created a live feed while rooting the box. I have to re-do the box as I was not able to take note and add the techniques on my list.