Test Lab V8: Two System Site
In this article we will learn about Test Lab V8: Two System Site.
Information about Two System Site:
Test Lab is an online virtual penetration testing lab similar to Offensive Security Lab. It contains 12 systems that have various vulnerabilities and misconfigurations. In each system there is a token that needs to be found and submitted for verification. First you will need to register here: https://lab.pentestit.ru/pentestlabs/4 and then you will find your VPN configuration files and login information. Before we start, we recommend using Kali Linux because all the necessary tools are available, there is a network diagram provided by the labs to help us analyze the target.

As you can see above in the network map there are two gateways 192.168.101.6 and 192.168.101.7. Only three systems, the cabinet and ssh-dev and the second gateway are accessible from the site from the first gateway, the rest are accessible. In this first part of the article we will root the first two system pages and the cabinet and the others 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 went through the app and looked at the app’s source view for any hints, but we couldn’t find anything. We started the dirb tool to enumerate the directories using the following command: dirb http://192.168.101.6/ /usr/share/wordlists/dirb/common.txt/ -v

After running the tool, we noticed that the response code for each request is 403, which means Forbidden. When we tried to open any non-existent page from the app, it gives 404 response code.

It means that our request is blocked by the firewall. We have now added a small improvement to the dirb tool by adding -a syntax to allow adding another user agent. In this case, we added the Iceweasel browser user agent 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 get 404 and 200 responses. I opened the .htaccess file from the browser, but after opening the .git/HEAD file there was nothing interesting, the .git directory is accessible, that means the other configuration files will also be accessible and can be downloaded. There is a tool called DVCS Ripper (https://github.com/kost/dvcs-ripper) that will download the entire .git repository from the web if the .git directory is accessible from the web.
We ran the tool 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.
Related article:Everything you need to know about Ethical Hacking as a Career by Blackhat Pakistan 2023
Reference Links:
https://lab.pentestit.ru/pentestlabs/4
https://github.com/fuzzdb-project/fuzzdb