Most of the today’s cyber attacks are done through the Internet. At many times, web applications are being targeted to launch cyber attacks. With the increasing sophistication of web applications, they are more vulnerable to attacks. Organizations that have launched their web applications online are worried about their security. An adequate security configuration has to be implemented and they should be tested for their effectiveness. Security testing of the web applications is also called as Web Application Penetration Testing (WebApp Pen-Testing).
In this blog, we will have a look on how a typical Web Application Pen-test takes place. As we spoke in one of our previous blog posts, the first ever thing to do in a Pentest is to gather information as much as possible. We’ll have a look at some examples on how the information is gathered.
DISCLAIMER: All the information provided in this blog is for educational purposes only. Not for any malicious activities.
Before we get into how to gather information, we should understand what information could be gathered. There is much information we can gather. Some of them are username formats, passwords, emails, network diagrams, error message contents, etc. How are we going to gather this information? Then comes one of most popular and free information-gathering tool. Google!
As everyone uses Google search engine for everyday usage, it can also be used to gather tons of information about a particular target. Google search operators can be used in a tactful way to gather much information.
site:<target url> type:pdf
The above Google query would list down every PDF file hosted on a particular website. The results would be interesting. There may be publically published PDF contents. We may also find any sensitive information that was supposed to be hidden. Such PDFs may leak confidential information for the attacker. We’ll have another example:
site:<target url> inurl:login
The above search query will find all the URLs that having the word “login”. This may be useful when we need to identify all the login pages associated with a particular website. Likewise, we can gather tons of information through Google search engine. If you are more interested in Google hacking, there is a book named “Google Hacking for Penetration Testers” by Johnny Long. Go grab it.
Can we get the enough information only through Google? Nope. We need to do more work to gather information. We need to gather information about the inner infrastructure of the web application. In other words, we need to find many details about the web server, which is hosting the application. We’ll have a brief look on how it is done.
The approach we are taking to identify the type and version of the web server is simple. We send some specific commands to the web server and analyze the responses of them. Different servers send the different type of responses. Not a single command can identify the full detail about the web server. But several commands and comparison of several responses may give us the details about the underlying web server.
HTTP response header is one of the most common responses used to identify the version of a web server. A tool called Netcat can be used to identify the underlying server of a web application. Have a look on the following command:
nc <ip address of the web site> <port>
By entering the above command, we can simply identify the web server, which is hosting the web application. In the above example, the server is running a Microsoft-IIS/8.5. Finding the web server version may help the attacker in finding publically available exploits. But, Netcat results are not always accurate. We should use some other techniques to make a confirmation of the results. One of the other methods of doing it is by using a tool named Nmap. This tool is considered as one of the highly sophisticated tools in the industry. It is capable of doing awesome things. Let’s have a look on the following command.
Nmap –script http-headers <ip address of the target>
From the above result, we can see that the server is running Microsoft IIS. From both of these results, we can come to a certain level of confidence, that the server is IIS/8.5. Apart from the manual testing, a Pen-tester can use automated and online tools to do the same.
Information gathering does not stop there. We need to gather more details about the application and the configuration. This makes it easy to identify any vulnerability available on the server. One of the other things analyzed in a web application testing is the HTTP method.
A web server allows many HTTP methods to perform actions on a web server. HTTP methods are used by developers to conduct their deployments and stuff. But the same HTTP methods can be used by a malicious person to conduct unintended activities if the server is misconfigured. So, as a Pen-tester, it is important to identify the allowed HTTP methods in a server.
As in the previous example, we can use the Netcat tool to identify the HTTP methods by executing the following command.
nc <target url> <port> with the options
As you can see, the above server allows OPTIONS, TRACE, GET, HEAD and POST methods. The TRACE method is a risky method, which can be leveraged to conduct some malicious activities. The same thing can be tested through Nmap by the following command.
nmap -p <port> –script http-methods <target url>
The same result has been shown in the Nmap output. Nmap has identified the potential risk of the TRACE method as well. The TRACE method can be used to conduct an attack called Cross Site Tracing. This attack may enable an attacker to gather user credentials, which may help him in later stages.
Since we have gained some background information about the server. We can dig further to find any misconfigurations.
I will not be going in detail on such processes. I will give an example. We can try out some default usernames and passwords to a login page. That will let us know whether the deployment team hasn’t changed the default credentials. “Admin” is one of the default usernames found in most cases. We give a try on some other usernames as well. By the time we are testing the default names, we may face failed attempts warnings. Ideally, the login process should be locked in defined failed attempts. If the system didn’t lock the process, that leads us to a clue that, the server may be misconfigured in protecting brute-force attacks. So we may try to fire a brute-force attack in a later stage. We must try to get more details about the login process and authentication mechanism.
We have progressed from information gathering to some vulnerability testing and exploitation attempts. Further, we can test the session management functionality of the web application to find any vulnerability. Session management is the process of managing the user interactions. A misconfigured session management can lead to compromises. There are many aspects we can test. Some of the famous examples are, session bypassing, session fixation, session timeout, cross-site request forgery, etc.
Let’s see what is a session hijack. If an attacker captures the session token of a user (which is given to each user), he may get authenticated to the application using the captured token. In other words, an attacker may steal the session token of an authenticated user and use that token to log in to the application as him. The attacker may not need a valid credential to log in. Likewise, a Pentester may try to exploit the vulnerabilities related to session management.
Now we come to the most popular type of web application attack, which is the input validation attack. These types of attacks are considered as the most successful attacks ever. Input validation is simply, validating any input coming from a user to the server. In most cases, due to the complexity of the applications, the admins fail to enforce validation in all the places. Some of the famous attacks related to input validations are SQL Injection, Cross-Site Scripting, and Buffer overflow, etc.
SQL injection is like a sea. It can be used to compromise so many systems that communicate with the database server. This attack can be done by inserting characters like ( ‘; –, /*, etc.) to the query. Even though we don’t understand those characters. But the databases consider them as valid queries and spit out information that should have been secured. We’ll have a small example.
If we enter the following to the username and password field of a login page and press ENTER,
$username = 1′ or ‘1’ = ‘1
$password = 1′ or ‘1’ = ‘1
If the server is vulnerable, the server will give us the access of the first user in the row of the user table. In many cases, the first user would be an Admin. If this succeeds, we get the access of an Administrator. From there, we can do whatever we want.
Another type of popular attack is the Cross-Site Scripting (XSS). In this scenario, a Pentester would inject browser executable code within the HTTP request. A Pen-tester could simply test the vulnerability by entering some code to the browser URL. We’ll have a look on an example.
http://<target site>/index.php?user=<script>alert(123)</script>
If a Pentester inserts this to the browser URL, and wait for the response, if the response was an ALERT box with the alert saying “123”, the site could be vulnerable to sort of an XSS attack. There are more sophisticated tests to find the XSS related vulnerabilities in a web application. Compromising such vulnerabilities may aid the Pen-tester to conduct further attacks.
Some web servers allow file uploading to the web server. This can be done using several methods. But if a Pentester is succeeded in uploading a file, he may attempt to get a web shell through the uploaded file. In such cases, the damages to the web server may vary from information leakage to high-level compromises.
In a nutshell, a Pentester would try to get access to the web server through various methods. The ultimate goal is to get access to the web server or get a web shell. The access can be obtained through the mentioned methods and using some other methods which weren’t discussed in this blog. A web server compromise may aid a Pentester to hop into other systems and compromise the whole network.