Web App Pentesting: Vulnerability ID and Details

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.
<?php
include($_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 Shell
button 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
<?php
echo '<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 an
XSS');</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 App Pentesting: Vulnerability ID and Details

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Web App Pentesting: Vulnerability ID and Details

Semelhante a Web App Pentesting: Vulnerability ID and Details (20)

Último

Último (20)

Web App Pentesting: Vulnerability ID and Details