Hack Like A Jedi | Kenobi | TryHackMe

Hello World and welcome to HaXeZ, in this post we’re going to be channeling our inner Jedi and taking on the TryHackMe Kenobi room. This room requires you to perform some enumeration to identify services. Then, you need to enumerate SAMBA, NFS, and FTP. Next, you need to exploit a vulnerability in FTP to steal Kenobi’s private key and SSH to the server. Once on the server as Kenobi, you can escalate your privileges to root via a SUID file that uses unquoted paths.  

Kenobi Enumeration

First, I ran a Nmap scan with the safe scripts, service version, and operating system detection flags set. This revealed that there were 7 ports listening on the host. As can be seen, the important services found were FTP, SSH, HTTP, NFS, and Samba.

sudo nmap -sC -sV -O 10.10.182.106 -T4
Kenobi Nmap Scan
Kenobi Nmap Scan

Kenobi SAMBA Enumeration

Once the Nmap scan was complete, I enumerated the SAMBA shares. There are several Nmap scripts that can enumerate Samba shares, as seen in the image below. In short, the scripts used were ‘smb-enum-shares’ and ‘smb-enum-users’. As can be seen, it was possible to identify a total of 3 shares on the host. Furthermore, the IPC$ and Anonymous shares had read and write access.

sudo nmap -p 445 --script=smb-enum-shares.nse,smb-enum-users.nse 10.10.182.106
Kenobi SAMBA Enumeration
Kenobi SAMBA Enumeration

Accessing SAMBA Shares

Using a tool called smbclient, it was possible to access the SAMBA shares and view the files. As a result, the Anonymous share (mapped to C:\home\kenobi\share) had a file called log.txt. I downloaded that file using the get command and opened a new tab to read the contents. Notably, the log file mentioned an SSH key being generated as well as the ProftpD service running on port 21.

Kenobi Log.txt
Kenobi Log.txt

Kenobi NFS Enumeration

After reviewing the results of the Nmap scan from earlier, I noticed that NFS was open on ports 111 and 2049. NFS is short for Network File System and is another way to share directories and files on the network. With this in mind, I enumerated the NFS service using a number of Nmap scripts. As can be seen below, the NFS share was exposing the /var directory.

sudo nmap -p 111 --script=nfs-ls,nfs-statfs,nfs-showmount 10.10.182.106
Kenobi NFS Enumeration
Kenobi NFS Enumeration

Finding Vulnerabilities With Searchsploit

It’s time to start looking for a way to gain access to the machine. From our Nmap scan, we know that we have access to the /var NFS share. We also know that FTP is running and that at some point an SSH key was created. I used Searchsploit to look for vulnerabilities in the ProFTPD 1.3.5 service. The results indicate that there is a command execution vulnerability in this version of ProFTPD.

sudo searchsploit ProFTPD 1.3.5
Searchsploit

Exploiting FTP

Ordinarily, FTP will only grant us access to the directories and files in the directory specified in the FTP configuration file. However, as this version of FTP is vulnerable and is running as the Kenobi user, we can leverage that. We can copy the SSH key mentioned in the log file, and move it to a directory that we can access such as the NFS share /var. To do this we use the ‘SITE CPFR’ and ‘SITE CPTO’ commands as shown below.

nc 10.10.182.106 21
SITE CPFR /home/kenobi/.ssh/id_rsa
SITE CPTO /var/tmp/id_rsa
Coping the Kenobi SSH Key
Coping the Kenobi SSH Key

Stealing The SSH Key From NFS

Now that the SSH key is on the /var NFS share, we can mount that share and steal the key. In order to do this, we’re going to use the mount command. First, we need to make a directory to mount the NFS share to. I created a directory in ‘/mnt’ called kenobi2. Next, I mounted the ‘/var’ directory to that newly created directory and stole the SSH key.

sudo mkdir /mnt/kenobi2
sudo mount 10.10.182.106:/var /mnt/kenobi2
sudo cp /mnt/kenobi2/tmp/id_rsa ~/id_rsa
Mounting NFS and Stealing The Key
Mounting NFS and Stealing The Key

Kenobi Foothold

Now that we have Kenobi’s SSH private key we should be able to access the machine. First we need to change the permissions on the key to 600 to please the SSH gods. Once that is done we can SSH to the box using the SSH key which will grant us our foothold into the machine.

SSH To Box
SSH To Box

System Enumeration

Before we elevate our privileges to root and own the entire system, we need to find a way to do so. One common method of privilege escalation on the Linux system is via programs with the sticky bit set. The sticky bit means that the program retains root privileges when run by a normal user. There is more to it but I won’t explain the details in this write-up. So, we need to find all the files with the sticky bit set. The screenshot below shows the results of a find command used to find sticky bits. Essentially, it is looking for all files where the permissions have the sticky bit and then sending errors to ‘/dev/null’.

find / -perm -u=s -type f 2>/dev/null
Finding Sticky Bits on Kenobi
Finding Sticky Bits on Kenobi
Sticky Bit On Menu
Sticky Bit On Menu

Poking The Program

If you run the same command on your local system, you will notice that the ‘/usr/bin/menu’ binary is uncommon. Running this binary shows us that the program is indeed a bespoke program and it gives us three options.

Running /usr/bin/menu Binary
Running /usr/bin/menu Binary

If we run strings against that binary, we can get an idea of what’s going on. Furthermore, we can see how the creator of this binary made a crucial mistake. We can see that the three options correspond to three system binaries (curl, uname, and ifconfig). Unfortunately for the creator, but fortunately for us, they forgot to include the full path to the binary. As this is running with the sticky bit set we can modify our ‘$PATH’ environmental variable and create our own malicious versions of these binaries.

Strings on /usr/bin/menu Binary

Kenobi Privilege Escalation

First, I changed my directory to ‘/tmp’. Then I echoed the contents of the ‘/bin/sh’ binary into a file called curl. This will be our replacement malicious binary. I then gave the newly created curl binary, read, write, and execute privileges. Finally, I exported the ‘/tmp’ path in to our ‘$PATH’ environmental variable. Now, when we run the ‘/usr/bin/menu’ binary, it will look for the binaries in the ‘/tmp’ path first. And what will it find? our malicious curl binary.

cd /tmp
echo /bin/sh > curl
chmod 777 curl
export PATH=/tmp:$PATH
Creating curl binary and change path
Creating curl binary and change path

Now, when we run the ‘/usr/bin/menu’ binary and select the status check options, it runs our malicious curl binary as root and spawns a shell with root privileges.

Unlimited Power
Unlimited Power

Conclusions

This box was a lot of fun, I’m sure there was more to it that I didn’t explore. For example, there was a web server that I didn’t even look at. With the finale of the Kenobi series being released, I thought there was no better time to do a walkthrough of this box. Try and cash in on those delicious keywords. There was nothing out of the ordinary on this box, very typical enumeration and exploitation but it was still a fun box. Anyway, I hope you enjoyed the write-up, feel free to watch the video below.

Hacking The Skynet Mainframe and Preventing Judgement Day

We took technology for granted. Laughed at the suffering of the robots we had enslaved. Dismissed the warnings of the mainstream media. If was over before it began. Skynet, an interconnected neural defense network became self-aware. We didn’t stand a chance.

I was sent back from the future by the leader of the resistance John Connor, my mission is to hack into the Skynet mainframe and destroy it before it becomes self-aware. I have infiltrated a Skynet data center and jacked into their network. If you’re listening to this, you are the resistance.

Hello World and welcome to HaXeZ. Cheesy intros aside, today we’re going to be hacking the Skynet box on TryHackMe.  I came upon this box while going through the Offensive Security Learning path. The Box was a lot of fun so I wanted to make a write-up and create a video about it. The foothold requires some enumeration of Samba and web services. Then exploiting an outdated Content Management System to perform local and remote file inclusion to gain a reverse shell.

Skynet Host Enumeration

I ran a Nmap scan with the safe scripts, service version, and Operating System detection flags set against all ports. The scan came back and revealed that SSH, Apache, Dovecot, and Samba were listening on the server. As a result, we have a large attack surface to go after. We could start by brute forcing SSH. However, as there are plenty of other services to go after let’s start with the web server.

Skynet Nmap Scan
Skynet Nmap Scan

Skynet Web Server Enumeration

The initial landing page of the web server appears to a Skynet search engine. However, submitting search parameters to the submission form didn’t appear to do anything. Therefore, I decided to run DIRB (with a custom wordlist) against the webserver to see if there were any juicy directories. While DIRB was running, I started to enumerate the Samba shares to see if I had access to anything.

Skynet Search Engine
Skynet Search Engine
Dirb Directory Brute Force
Dirb Directory Brute Force

SMB Enumeration

I used the tool smbclient with the list argument to list the shares that were exposed on the host. Notably, there were a number of shares available but the one named anonymous caught my eye. Perhaps this anonymous share would allow me to explore it without authenticating. Success, we were able to access the anonymous share and found a number of files including attention.txt, log1.txt, log2.txt, and log3.txt. The contents of the attention.txt document revealed that the host had recently encountered a misconfiguration and that all users needed to change their passwords. The text document was signed by none other than Miles Dyson. Furthermore, the log1.txt document contained a list of terminator names. Perhaps this was a password list.

smbclient SMB Enumeration
smbclient SMB Enumeration

Squirrelmail

Heading back to my DIRB scan I noticed that it had found a directory called SquirrelMail. Furthermore, upon visiting this directory we were greeted with a login page. With the username milesdyson and the log1.txt wordlist we found on the Samba share, I launched Burp Suite and started a brute force attack.

Squirrel Mail
Squirrel Mail

Comparing the results of the Burp Suite brute force attack revealed that one of the attempts was successful. The response length was different and the HTTP status code showed a 302 redirect instead of a 200 message. In other words, instead of loading a page with an error message saying the credentials were incorrect, it redirected me to the mail portal.

Burp Suite Brute Force
Burp Suite Brute Force

Samba Password

I read through Miles Dyson’s emails and noticed he had received an email from [email protected]. Additionally, this email was informing Mr. Dyson that his Samba password had been changed. The email actually included the new password. Loaded with that new information, I headed back to my terminal and attempted to mount the /milesdyson share with the milesdyson username and the new password. It worked! The share was full of documents about AI neural networks but there was also a text document named important.txt This new text document mentioned a Content Management System under a new directory. This directory was a random combination of letters and numbers so it is unlikely that a directory brute force attack would have found it.

Miles Dyson Samba Directory
Miles Dyson Samba Directory

Deeper Directories

Armed with this new directory, I ran another DIRB against it and found that there was a directory called administrator. Navigating to this directory loaded a new login portal for a Content Management System called Cuppa CMS.

Cuppa CMS
Cuppa CMS

After trying some basic credentials I went back to my terminal and used searchsploit to see if there were any vulnerabilities. Sure enough, there was a local and remote file inclusion vulnerability that would allow a threat actor to load local files on the system such as the passwd file as well as force the server to execute files hosted remotely.

SearchSploit
SearchSploit

Catching A Reverse Shell

After testing out the local file inclusion vulnerability, I headed to Pentestmonkey’s PHP reverse shell on Github.com. I grabbed the raw URL and downloaded it locally and then amended it to include my IP address and desired port of 443. Then I used the Python3 HTTP module to start a webserver on port 80. I created a NetCat listener on port 443 and then appended the link to the reverse shell into the Cuppa CMS URL. After hitting enter I was greeted with that glorious message of Connect to from unknown. The reverse shell had worked and I was now on the system.

Reverse Shell
Reverse Shell

Skynet System Enumeration

I poked around on the system for a bit and was able to capture the user flag from the milesdyson home directory. I also noticed a backup.sh file that appeared to be backing up everything in the /var/www/html directory with Tar. Furthermore, this backup.sh script was owned by root. I decided to cat out /etc/crontab to see whether this was running as a cron job. Sure enough, it was, the job was running as root every hour, minute, and second.

Skynet Enumeration
Skynet Enumeration

Privilege Escalation

The end to Skynet was within reach. I headed over to GTFO bins and searched for Tar. There was an entry for Tar using a feature called checkpoints. These checkpoints allow for the execution of arbitrary actions or commands. By creating a checkpoint I could instruct Tar to execute a command of my choosing. Based on a write-up on https://steflan-security.com I decided to create a bash script that copied /bin/bash to /tmp and then change the permissions to include the setUID bit. This means that when the backup.sh cron job runs, Tar would create a bash binary in /tmp that would elevate me to root. After a bit of trial and error, the exploit worked and by appending the -p argument I was able to get root and capture the root flag.

Privilege Escalation
Privilege Escalation

Conclusions

This was a great box and I loved the theme of it. I don’t know why but I always find boxes with a strong theme more engaging. It’s like the websites on hackthissite.org, if I’m supposed to be hacking some super evil person then I’m more inclined to succeed. Perhaps my imagination is running away with me. Either way, this is a great box, I would personally rank it as a medium difficulty box mainly because I struggled with the last step. I had to terminate (excuse the pun) the existing machine and start again to get it to work. I loved the remote file inclusion vulnerability, that was insanely cool. Anyway, until next time. Kind Regards.