Penetration Testing #3 - Dirbsuter lab from INE free course - finding hidden resources

Introduction

Hello guys!

Today it's time for another lab from the INE free course about penetration testing. This challenge is based on the Dirbuster tool that I'm gonna learn. As far as I know, this program is capable of finding hidden resources that reside on a web server. From a penetration tester point of view, such findings are interesting because they can have serious security holes. Imagine that a programmer decided not to publish a testing part of its web application. It means that he or she hid some resource and it's not available through any browser. In that case, the Dirbuster is probably the best choice for finding this resource. It can do it in two ways - using brute-force or dictionary attack. There are pros and cons to each of these approaches. For example, when we are using a brute-force type of attack we can be sure that the tool will not avoid any set of characters and it will try to find exactly each option. But on the other side, this approach is very time-consuming. Dictionary attack relies on the fact that we don't want to test every possible set of characters, but only those that are common in naming resources. Obviously, this type of attack is significantly less time-consuming than brute-force, but we can't be sure that every hidden resource was found at the end of the process. This is because we have a finite number of words in a dictionary.

From now on it's clear that hiding resources by not indexing them is a mistake. Every attacker with knowledge of how to use the Dirbuster can easily find these resources and potentially compromise the whole network. And now after the introduction to the topic, I invite you to check my write-up about the lab.

Dirbsuter lab - finding hidden resources

Here is the description of the lab:

And here is the goal that I will try to achieve:

Obviously, if we want to find machines responsible for some services we have to map the whole network for example with the help of the Nmap. But before launching this tool it's crucial to know the IP of the network.

IP of the client's network

There is a 24-bit netmask configured in the client's network, therefore the network's IP address is 10.104.11.0. Now if we are armed with this address we are able to map the network and find the web application. First, let's see which hosts are alive without checking open ports and running services.

Hosts that are alive in the client's network

As you can see there are two hosts alive in the client's network with these IP addresses: 10.104.11.96 and 10.104.11.198. Now we can scan them for open ports and running services.

Mapped machines on the client's network

The SSH connection is available to these two machines, so if we know credentials we can connect to them remotely. The machine with a 10.104.11.96 IP address is the web-server that is running the client's web application. This web-server is based on the Apache HTTPd software. The second host with a 10.104.11.198 IP address is the MySQL database most likely it's a database of the application.

The view of the web application

The goal of this lab is to access some restricted area of the web application. We can use the Dirbuster to check for hidden resources and try to access them. Most likely we will find something interesting that will be restricted from public use.

The above picture shows the Dirbuster interface. To tell this tool that we want to find hidden resources on the web-server we need to give the tool a target URL. The second option in the configuration of the Dirbuster is Work Method. We can tell the Dirbuster that we want to Use GET requests only and in this case, the Dirbuster will query the web-server using only GET requests. If we check Auto Switch the Dirbuster will be switching between HEAD and GET requests.

The Number Of Threads option is here because it affects the speed of the program. The more processor threads are in use the faster the Dirbuster works.

Scanning type is probably the most important option to set in the whole configuration. List based brute force has to be checked if we want to launch a dictionary attack. Pure brute force as the name suggests means that we want to test every possible set of characters in case of finding resources, in other words, launch a brute force attack. A dictionary attack is dependent on the dictionary file which is most likely a big text file with the most common names of resources. These dictionaries can be found in /usr/share/dirbuster/wordlists/. If you choose brute force attack then you need to point Minimum length and Maximum length of the character set and the content of the character set itself.

Starting option tells the Dirbuster where to start the searching process. In this field of configuration, we can indicate for example in which file extensions we are interested in.

I set the Dirbuster exactly like this:

I set the file extension field to php, bak, and old because I want to find some hidden php scripts that are a part of the web application but also backup files that can store sensitive data.

I would say that these three marked resources are interesting. Let's see what we've got here.

As you can see there is something shady here because we are not allowed to visit a login page. Let's read the content of /staff/readme.txt file.

Readme file is simply a note made by the developer team that should not be kept on the server. Important information is that the file extensions of backup files are most likely old, bak and xxx. Now let's check the /include/config.old backup file.

And here is the jackpot! The config.old file is the backup file that is kept on the server with database credentials written inside. Obviously, it's a very big security mistake from the developer team since any attacker could read these credentials and get unauthorized access to the database of the application. So if we are keeping such sensitive data in our hands let's use it and try to get access to the application.

Unfortunately, there isn't a jackpot. :/ It appears that these credentials are not correct anymore so we need to continue digging. After some clicking on the main page, this Sing Up part caught my attention:

It seems that this Sign Up part of the whole application is tested by the developer team and it isn't public by any means. Therefore it can be our new target since there is a chance that we can sign up to the web application in silence.

Luckily the page that we are looking for was most likely found by the Dirbuster and it's name is simply signup.php. Let's see if our supposition is correct.

This kind of sensitive information is a great award! Dev team thought that the sign up page is protected because it's not available via web browser, but it's not safe at all. Let's test those credentials and see if we can finally break into the application.

Using obtained credentials we could log in to the MySQL server in the client's network. The next thing to do in this situation is to check what databases are available and look into tables of those databases. In our case, we have one database called awdmgmt_accounts and one table inside this DB named accounts. This table consists of credentials to the Admin's account saved in plaintext. It appears that we can break into the client's web application. Let's see if this is possible.

Yeeeeeeessssssssss!! It worked. We are now inside the web application of the client with the privileges of the administrator. The whole action taken to break into the application need to be written step by step in the summary report. After this, we can come back home from the client's firm and enjoy the feeling of being unstoppable. :D

That was a great lab. I'm always happy if I can break into something legally and take the lesson from this operation. Thanks for reading this post.

Cheers!