Devel Writeup w/o Metasploit
Last updated
Last updated
First thing first, we run a quick initial nmap scan to see which ports are open and which services are running on those ports.
-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.
We get back the same results as above.
Similarly, we run an nmap scan with the -sU flag enabled to run a UDP scan.
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.
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 the 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.
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.
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.
We’ll go with the general reverse shell since Meterpreter is not allowed in the OSCP.
Run the following MSFvenom command to generate the aspx payload.
-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 a netcat listener on the attack machine to receive the reverse shell when it’s executed.
In the web browser load the reverse-shell.aspx file we uploaded in the FTP server.
Go back to your listener to see if the shell connected back.
Perfect! We have a shell and it’s running as iis apppool\web.
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 learn more about the operating system to see if we can escalate privileges.
The above command returns information about the system.
We’re on a Microsoft Windows 7 build 7600 system. It’s fairly old and does not seem to have been updated, so it’s probably vulnerable to a bunch of exploits.
Let’s use google to look for exploits.
The first two exploits displayed allow us to escalate privileges. The second exploit (MS11–046), has documentation on how to compile the source code, so we’ll go with that one.
Get the EDB-ID from the web page, so that we can use it to find the exploit in searchsploit.
Update searchsploit to ensure you have all the latest vulnerabilities.
Use the -m flag to look for the exploit 40564 and copy it to the current directory.
Now, we need to compile the exploit. The compilation instructions are in the exploitdb webpage.
If you don’t have mingw-w64 installed, install it.
Compile it using the listed command.
Alright, we have a compiled exploit. Now what is left is to transfer the exploit to the target (Devel) machine.
Start up a server on the attack (Kali) machine.
Netcat doesn’t seem to be installed on Windows, but powershell is. So, we’ll use it to transfer the file from our server to a directory we can write to.
The file is now in the Downloads directory. Execute it and check if the exploit worked and escalated our privileges.
We have system! Navigate to the user.txt file and output its content to get the user flag.
Do the same thing for the root flag.
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:
Disabled anonymous access to the FTP server.
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.
