In my downtime one night I decided to fire up an intentionally vulnerable machine, and have a go at trying to test this system with the systematic approach I would with a customer machine. There are a plethora of vulnerable machines available on the website Vulnhub. It should be noted that these machines of course are vulnerable in nature, and should never ever ever be used in a production environment. In fact, I tend to even deploy them to a virtual machine network that does not have accessibility to the Internet. In case someone tried to be clever and gain remote access on my system. In VMware Workstation you can create a custom virtual adapter that has no access to the outside world, and will also setup an environment with DHCP which allows us to connect our testing VM to the same network as the vulnerable machine. As you can see from the screenshot below I used VMnet7 as Host-only, and gave it a subnet range of 10.10.10.0/24.
I will assume at this point you know how to deploy an ISO or OVA to VMware flavor of your choice. For the first step I used the netdiscover tool to find all machines that are on the same subnet. The .1 and the .254 are VMware network addresses that are utilized with the virtual LAN. This means our target device is the 10.10.10.129.
The first step in any pentesting is to find out what is running on the device using a fast nmap scan. This can be accomplished with db_nmap -v -F -Pn -sS 10.10.10.129. To break the nmap command down we will run a verbose Fast scan which will only scan the 100 most popular ports and will ignore if the machine does not respond to Ping. This will force nmap to actually attempt to scan the top most 100 ports. As well we can use the -sS to perform a stealth scan. The stealth scan can provide different results on certain network devices, but since I assume the developer did not put any traps here the stealth scan will return faster results.
The screenshot below shows re-running the command above but this time we will probe each open service with a service scan with the -sV flag. This will use the nmap engine to attempt to determine what service is running on any given port.
It was noted that there was a webserver running on port 80. I will begin with my enumeration with this service. Navigating to the port in a web browser gives me the Apache version and the remote host Operating System, but also returns a 404 error since the index page is not found.
We can try to enumerate more from the webserver by using a popular open source web scanner tool known as Nikto. This can be run by issuing nikto -h http://10.10.10.129 -useproxy http://127.0.0.1:8080. The useproxy flag is optional, but per a previous blog I find it helpful to have full logs of all attacks that are performed against a target. This can be helpful for historical data or if a customer requests certain commands that are performed.
Nikto returns a result that there is a robots.txt file that contains 1 entry. Robots.txt is a text file webmasters create to instruct web robots (typically search engine robots) how to crawl pages on their website. The robots.txt file is part of the the robots exclusion protocol (REP), a group of web standards that regulate how robots crawl the web, access and index content, and serve that content up to users. One of the first places I like to check is the robots.txt file because many times developers or system administrators will put sensitive data in the file so that automated crawlers will not find the sensitive data. However, this is usually a good place to begin our search.
Navigiating to http://10.10.10.129/g0rmint/ presents us with a login.php page as shown by the screenshot below.
Additionally, to make sure there are no other sensitive files that might be exposed we can use a common enumeration tool known as dirb. DIRB is a Web Content Scanner. It looks for existing (and/or hidden) Web Objects. It basically works by launching a dictionary based attack against a web server and analyzing the response. DIRB comes with a set of preconfigured attack wordlists for easy usage but you can use your custom wordlists. Also DIRB sometimes can be used as a classic CGI scanner, but remember is a content scanner not a vulnerability scanner.
Unfortunately, dirb did not provide any additional information that Nikto had not already provided. Many times vulnerable machines will be built with red herrings, or also known as rabbit holes. These are services that look vulnerable, but actually will be setup purely with the intent of distracting the security engineer. Before diving down any rabbit holes I prefer to enumerate all available services. The only other service was an SSH server running on port 22. I can banner grab and attempt to find the version number from the nmap scan earlier or by running nc -nv 10.10.10.129 22. However, the version provided of SSH server does not appear to have any glaring vulnerabilities. There is a centralized repository of security vulnerabilities that have been reported about softwares. We can check the available vulnerabilities by searching for the SSH version number at the following link.
Since the SSH server does not appear to be blatantly vulnerable we can return to the webserver and look more closely at the source of the HTML page. Inside the Header tag there is a meta tag that names a backup-directory at the value of s3cretbackupdirect0ry.
After finding the secret backup directory we need to return to our enumeration phase, and perform our dirb scan again with the additional directories. As you can see from the screenshot below dirb found an additional page at /info.php.
Navigating to the .php page in the web browser we find out there is a single entry of a backup.zip file. By changing the current page to /backup.zip the webserver will allow us to download the file.
After extracting the file we find the full contents of the webserver. Looking for sensitive information that might allow us to login we find out the author's email address.
additionally, we find where the $password is being generated. Which seems to be utilizing the date to hash the password.
We can write a quick little PHP script that will allow us to reverse the date into a hashed password.
This gives us the following password.
Using the author's email address and the password generated from the PHP script we were successful in logging into the g0rmint Admin Portal. This will be the stopping point for tonight.
Hope you found the partial walkthrough enjoyable. Until next time!
