Test Lab V8: Two System Site
Test Lab is an online hacking virtual penetration testing lab similar to Offensive Security's lab. The contains 12 systems which have a variety of vulnerabilities and misconfigurations. In each system, there is a token which needs to be found and submitted for validation. First you will need to sign up here: https://lab.pentestit.ru/pentestlabs/4 and then you will found there your VPN configuration files and credentials. Before starting we will recommend using Kali Linux because all necessary tools are there, there is a network diagram provided by the labs which will help us to analyze the target.
Earn two pentesting certifications at once!
Enroll in one boot camp to earn both your Certified Ethical Hacker (CEH) and CompTIA PenTest+ certifications — backed with an Exam Pass Guarantee.
As can be seen, above in the network map there are two gateways 192.168.101.6 and 192.168.101.7. From the first gateway, only three system is accessible from the site, cabinet and ssh-dev and the second gateway, the other remaining ones are accessible. In this first part of the article, we are going to root the first two system site and cabinet and other ones we will do in the next parts.
So our primary target is site and cabinet which is accessible from 192.168.101.6. Let us begin the hacking.
Attacking the SITE: Started from the nmap scan by using the following command: nmap -sS -sV -Pn -p1-65535 192.168.101.6
As can be seen, in the above output we found two open ports 80 and 443. We opened the IP and port 80 from the browser, and it shows an SAS bank application which has login functionality.
We browsed the application and viewed the source view of the application for any hints, but nothing found. We ran dirb tool for directory enumeration by using the following command: dirb http://192.168.101.6/ /usr/share/wordlists/dirb/common.txt/ -v
After the running the tool we noticed that the response code for every request is 403, which means forbidden. When we tried to open any non-existent page from the application, it is giving the 404 response code.
It means there is a firewall which is blocking our request. Now we added a small tweak to the dirb tool by adding -a syntax which allows adding a different user agent. In this case we have added the Iceweasel browsers user agent by using the following command: dirb http://192.168.101.6/ /usr/share/wordlists/dirb/common.txt/ -v -a "Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0 Iceweasel/38.5.0"
Now we can see the difference in the results we are getting 404 and 200 responses. Opened the .htaccess file from the browser but nothing interesting was there after that opened the .git/HEAD file the .git directory is accessible it means the other config files will also be accessible and that can b downloaded. There is a tool called DVCS Ripper(https://github.com/kost/dvcs-ripper) which downloads the whole .git repository from the website if .git directory is accessible from the website.
We ran the tool by using the following command: ./rip-get.pl -u http://192.168.101.6/.git/ -o /root/Desktop/app
After running the tool, the whole code is saved in my app folder.
We started browsing all source code of the application and found two credentials from DatabaseSeeder.php, which located under app/database/seeds directory.
We tried to login by using user credentials, and we found our first token.
Attacking the CABINET: This system is also accessible from the same gateway 192.168.101.6 on port 443 which has a login functionality.
We again ran the dirb tool for finding hidden directories and file by using the following command: dirb https://192.168.101.6/ /usr/share/wordlists/dirb/common.txt/ -a "Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0 Iceweasel/38.5.0"
As can be seen, above we found the api directory and we tried to open the directory, and it throws an error that "You can use only /api/auth or /api/balance"
We opened the api/auth directory from the browser, and again it throws an error that email and password field is required.
We added these two parameters in the request with a random value and triggered the URL.
As can be seen, it's showing that email is not valid it means this request is working, and now we need to find out a valid email id.
So we moved to the next directory which is api/balance on triggering this request also it gives an error that api session token and id field is required.
We added these two required parameters with a random value and triggered the URL, after that it again throws a message that api session token value must be 40 characters.
So we added random 40 characters in the parameter value and hit the request. The application responded with the null value. It means that functionality is working.
Let's try SQL injection in token parameter crafted a 40-character-long SQL injection statement for the api_session_token and again triggered the request.
The SQL injection worked and responded back to all emails, after thoroughly reviewing all the email's we picked up RalWestfall's email because its contains the sas-bank.lab domain.
Now we moved back to the /api/auth request which was asking for valid email. We submitted the email in the email parameter, and now it's giving a different error message that password or email is wrong.
In this case, we are 100% sure that email is valid because if we are giving any random email, then it shows a message that the selected mail is invalid. Now we need a password, so we start brute forcing the password parameter by using BurpSuite proxy.
For the password list, we used fuzzdb's password list which can be seen below.
After running the intruder for some time, we found the password which is "freeman".
Tried to login with Ralph Westfall's email and the found password and it worked.
After logging, we browsed the whole application, and we found that there is a file upload functionality in the profile picture.
Tried to upload a PHP backdoor and it throws an error that only image is allowed.
After that, we looked into the view source of the application for finding out the profile picture upload location, and it was under uploads directory.
We browsed the upload directory and tried to access our PHP shell file, and it was there even the application throws the error.
Now we have our shell access we started browsing the whole root directory, and we found a token.txt file under /var/www/ directory.
We opened the text file, and we found the token.
In the next part of the article, we will solve the other machines.
What should you learn next?