Web Application Penetration Tests - Vulnerability Identification and Details Review

Web Application Pentesting

Vulnerability Identification and Details Review

Vulnerability Identification and Details

In this next section, we will address the following process: • Scope of Engagement

• Information Gathering

• Vulnerability Identification

• Exploitation

• Post Exploitation

• Reporting

2


As a part of the Vulnerability Identification phase, we are going to introduce you to the vulnerabilities identified after the scanning is completed in the information gathering phase.

At the beginning of the course we talked about the types of vulnerabilities Netsparker could identify, in this section, we will look closely at the information provided by Netsparker, but first let’s ensure we complete the last 3 stages of scanning after the crawl and pause scan.

3


The second scanning phase, after the crawl and pause phase, is the attacking mode.

In this mode, Netsparker scanner uses the proof-based scanning technology to validate findings in an effort to eliminate false positives.

4


Once the attacking phase is complete, Netsparker re-crawls the site to ensure that all items discovered are valid and any newly discovered paths are validated. This phase prepares the scanner for a final validation of the vulnerability findings.

Lastly there is an extra confirmation scan, in which the Netsparker scanner further validates the findings by generating exploits at runtime. Just like an actual attacker, Netsparker figures out: how to bypass, how to exploit the vulnerability (SQLi, XSS, LFI etc.) and then exploits it safely.

5


Once finished we can begin examining some of the findings.

We will not go through all the findings but only highlight the most important facts about the more significant results.

6


Netsparker provides a lot of information for every finding.

The rating of this finding is “Important” as depicted in the upper right hand corner.

The CERTAINTY meter shows the level of confidence in the vulnerability

7


Under the CERTAINTY meter, is the reference URL that allows manual verification of the vulnerability, the identified version versus the latest version reference, and the vulnerability database content reference. As you will see for other vulnerabilities, here you will find all the information needed to manually test them. For example, for vulnerabilities such as XSS, SQLi and so on, Netsparker will display the exact payload used.

8


In this specific case we do not have any payload, since this is information that Netsparker is able to retrieve from the web server response.

If we want to investigate it, we can open the HTTP Request / Response tab and inspect its content.

9


Important sections of the vulnerability report include the Vulnerability Details, Impact, Remedy, Remedy References, Known Vulnerabilities in the specified version, and the Classification Section.

10


Here we can see that Netsparker is able to automatically search and link known vulnerabilities against this specific Apache version.

As you can imagine, this will save us a lot of time and effort during the exploitation phase!

If you want to know more, you can open the links provided.

11


Here we can see a Remote File Inclusion (RFI), which has been validated and is rated as Confirmed Critical.

A RFI usually happens when the application allows the path to a remote file, that is not been properly sanitized, to be sent as input.

12


Thanks to RFI, an attacker can include remote files on the web server and execute arbitrary commands on it. This can lead to code execution, edit or viewing content of files and sensitive information, denial of services and much more.

Worst Case Scenario: The attacker gains complete control of the web server.

13


An example of a vulnerable code that expose the web application to RFI is the following:

The location parameter is not properly sanitized. The attacker can inject any valid remote path to file (or local path to file - LFI), and cause the application to include it. Once again, this can be a shell and can lead to execution of code on the web server.

<?phpinclude($_GET['location']);

?>

14


Different from the previous vulnerability, we can see that Netsparker displays not only the vulnerable URL, but it also gives us more information about the vulnerable parameter name and type.

With this information, reproducing the attack will take only few seconds.

15


The Proof of Exploit section shows the output of a whoami command. With this command, Netsparker proves that the vulnerability exists.

Notice that the commands run cause no harm to the application.

16


Before inspecting the information after the Proof of Exploit section, it is important to note that in the top panel of the area the Get Shellbutton is enabled.

Thanks to this button, we will be able to automatically get a shell on the remote system. As we will see later on, this will save us from creating, configuring and uploading a working exploit!

17


The required skills section shows that it would be easily exploited due to freely available resources.

The remedy section shows that this vulnerability can be negated by not allowing file paths to be appended or by doing input validation on certain characters and not allowing characters that would be used for exploitation.

18


Using the previous vulnerability, let’s take a moment to look at the External References section.

In the link provided, we can read very detailed information about the vulnerability. This may be very useful if you want investigate more.

19


Based on the Remote File Inclusion in the previous slides, it has connected vulnerabilities such as Cross-Site Scripting via Remote File Inclusion.

Note that it is an Important vulnerability but not confirmed, so this is something that we can slate for manual.

20


In this vulnerability, we see a Cross-site Scripting (XSS) finding which has been validated and is rated as CONFIRMED and IMPORTANT.

An XSS occurs anywhere a web application uses input from a user within the output it generates, without validating or encoding it.

21


XSS flaws allow attackers to send malicious scripts to the vulnerable application's users. This attack is often used to reveal sensitive information retained by the victim's browser, but the possible attacks are numerous.

22


Although we will not go deeper into the details of this vulnerability, let’s briefly explain how it works.

Consider the following PHP code:

The above (silly) code only prints a welcome message to the user whose name is retrieved from the $_GET variable.

23

<?phpecho '<h4>Hello ' . $_GET['name'] . '</h4>';?>


In case you are not a PHP programmer, the $_GET variable stores the <parameter,value> pairs passed through the HTTP GET method.

GET is the method used when clicking links or directly typing the website URL, you want to browse, into your browser location bar.

The user input will be extracted from the query string of the URL browsed (directly or by clicking on a link).

24

http://victim.site/welcome.php?name=MyName


When the above is passed to the server, the $_GET variable will contain a name parameter with the value MyName.

The string ?name=MyName is called querystring. The following HTML code will be returned from the server to the web browser:

So our input is part of the output web page source code.

25

<h4>Hello MyName</h4>


Now let’s see what happens if we are hackers and submit this payload to the same page in the same parameter name:

It injects some JavaScript code into the web page source code.

The JavaScript will be executed in the browser within the website context.

26

http://victim.site/welcome.php?name=</h4><script>alert('This is anXSS');</script>


Why does this happen? Because the user input is returned as output, without any kind of sanitization (either on input or output). Since there isn't any check on the user input, an attacker can exploit this vulnerability to perform a number of different attacks: cookie stealing, control over the victim browser, keylogging and much more.

Cross site scripting attacks are possible when the user input is used somewhere in the web application output. This lets an attacker get control over the content rendered to the application’s users thus attacking the users themselves.

27


Once again, we can see the vulnerable URL and parameter.

Moreover, Netsparker automatically creates the proof URL, which we can use to prove that the vulnerability exists.

In the attack pattern, we can see the payload used to trigger the vulnerability itself.

28


In this vulnerability we see Remote Code Evaluation (PHP) finding which has been validated and is rated as Confirmed Critical.

Remote Code Evaluation or Dynamic Code Evaluation can occur in PHP web applications when the application allows input to a function (eval(), system(), exec(), shell_exec()) without any type of validation.

29


Remote Code Evaluation allows an attacker to send code to the server without it being validated and the server will return the requested information.

This could include system commands that would not normally be allowed through validation.

30


In this vulnerability we see a Blind Based SQL Injection finding which has been validated and is rated as Confirmed Critical.

SQL Injection occurs when developers create dynamic database queries that include user input. If the input is not correctly validated, attackers can inject queries into the URL to extract information from the database.

31


SQL injection is trivial and allows an attacker to take action on the database being queried. This can include reading, writing, and deleting information contained within the database.

In the worst case, an attacker may also be able to execute commands on the underlying operating system.

32


In this vulnerability we see a Command Injection finding which has been validated and is rated as Confirmed Critical.

33


Command injection attacks are possible when an application passes unsafe user supplied data to a system shell, and are generally ran with the authority of the application.

This can leak sensitive information about the host.

34


Command injection is trivial and allows an attackers to take action on the host operating system.

As we can see in the Proof of Exploit section, Netsparker executes some safe commands to prove the impact of this vulnerability.

35

Conclusion

Thanks to the vulnerabilities identified by Netsparker, we now have a better idea of the attacks that we can run on the application. We can then start thinking about our attacking path.

Although Netsparker gave us some proof of concepts of the vulnerabilities found during the exploitation phase, it is a good practice to manually test them in order to confirm they exist.

36

Web Application Penetration Tests - Vulnerability Identification and Details Review

Internet

Transcript of Web Application Penetration Tests - Vulnerability Identification and Details Review