Saturday, April 7, 2018

Local / Remote File Inclusion attack


1 - File Inclusion

- A File Inclusion vulnerability is a type of vulnerability that is most commonly found to affect web applications that rely on a scripting runtime.

- This issue is caused when an application builds a path to executable code using an attacker controlled variable in a way that allows the attacker to control which file is executed at run time. 

- Successful exploitation of a File Inclusion vulnerability will result in remote code execution on the web server that runs the affected web application.

- A File Inclusion vulnerability is distinct from a generic Directory Traversal attack, in that directory traversal is a way of gaining unauthorized file system access, and a file inclusion vulnerability subverts how an application loads code for execution.

- Depending on how the File Inclusion is performed we can difference between Local and Remote File Inclusion.

2 - Local File Inclusion (LFI)

- Layout for this exercise:

- LFI vulnerabilities allow an attacker to read and even sometimes execute files on the victim machine. 

- This can be very dangerous because if the web server is misconfigured and running with high privileges, the attacker may gain access to sensitive information. 

- If the attacker is able to place code on the web server through other means, then they may be able to execute arbitrary commands.

- Let's see a couple of LFI examples using DVWA.

- First, right clicking on Upload tab and going to Inspect Element:

- Changing the allowed maximum file sizes to be uploaded:

2.1) Example 1: uploading a file

- Uploading a picture:

- The file uploading is successful, providing us with the path:

- Now, going to the browser and crafting the URL in this way the picture can be accessed:

2.2) Example: uploading and executing a wbshell PHP script

- web shells are small programs or scripts that can be uploaded to a vulnerable server and then opened from the browser to provide a web based interface to run system commands, so they are basically backdoors that run from the browser.

- For a given web server, the web shell script must be in the same language that the web server supports or is running (php, asp, jsp etc). 

- In this example the well-know webshell c99.php will be used (DVWA is PHP web server), what can be downloaded from here:

- Uploading to DVWA the webshell c99.php:

- The uploading is successful:

- Now, crafting an URL in this way:

- The result is that c99.php is executed, giving access to control the machine:

- For instance, running cat command the /etc/passwd is displayed:

3 - Remote File Inclusion

- Remote File Inclusion (RFI) occurs when the web application executes a remote file. 

- The layout of this part of the exercise would be different because two devices are needed:

- To perform this attack we must take into consideration that t
he PHP language (DVWA runs on PHP) has a directive which, if enabled, allows filesystem functions to use a URL to retrieve data from remote locations.

- The directives is allow_url_fopen in PHP versions <= 4.3.4 and allow_url_include since PHP 5.2.0. In PHP 5.x this directive is disabled by default, in prior versions it was enabled by default.

- Let's notice that our DVWA web application have enabled both directives, located at the php.ini file:

- In this case the URL must be crafted in a different way than when LFI.

- The include.php section is replaced with the remote URL where the webshell script is stored:

- Entering the crafted URL the webshell c99.php is again executed:

4 - PHP include() function vulnerability

- Now that we have performed some examples of File Inclusion attacks, let's examine what are the reasons of these vulnerabilities at the DVWA web application.

- As said before DVWA is a PHP/MySQL web application.

- In PHP the main cause of vulnerabilities are due to the use of unvalidated user input with a filesystem function that includes a file for execution. 

- For instance, functions prone to be vulnerable are include() and require()

- include() statement includes and evaluates a file that is passed to as a parameter by the input user.

- To exploit the include() vulnerability an attacker will alter a variable that is passed to one of these functions to cause it to include malicious code from a remote resource. 

- To mitigate this vulnerability all user input needs to be validated before being used.

- Going to the DVWA web application, on the File Inclusion page, clicking on the View Source button the following source code is available:

- This code is not vulnerable by itself, it just take the input $file and prepends http/https.

- However, going to the index.php file of the DVWA application, at line 35 we find that the include() PHP function takes $file as parameter without further sanitization:

- This code is vulnerable because there is no sanitization of the user-supplied input. 

- Specifically, the $file variable is not being sanitized before being called by the include() function.

Directory / Path Traversal attack


1 - Directory/Path Traversal attack

- Directory traversal or Path Traversal is an HTTP attack which allows attackers to access restricted directories and even execute commands outside of the web server’s root directory:

- This vulnerability can exist either in the web server software itself or in the web application code.

- In order to perform a directory traversal attack, all an attacker needs is a web browser and some knowledge on where to blindly find any default files and directories on the system.

- With a system vulnerable to directory traversal, an attacker can make use of this vulnerability to step out of the root directory and access other parts of the file system. 

- This might give the attacker the ability to view restricted files, which could provide the attacker with more information required to further compromise the system.

- The "../" characters are used by most Operating System to refer the previous folder or directory.

- The "../" characters represent a directory traversal, and the number of “../” sequences depends on the configuration and location of the target web server on the victim machine. 

2 - Example 1: DVWA running at an Ubuntu Linux machine

- Layout for this exercise:

- Let's perform one example with the DVWA vulnerable machine running at an Ubuntu Linux machine:

- In this example 3 strings of "../" are used to display on the screen the contents of /etc/passwd:

- In the next example let's suppose that the server stores a text file at the Desktop:

- Entering the string /../../../ and the corresponding path the content of the text file is revealed:

3 - Example 2: DVWA running at a Windows machine

- Layout for this exercise:

- In this case we are looking for the win.ini file, what is a Windows system file used with Microsoft Windows that loads settings from the C:\Windows directory each time Windows boots:

- Now, going even to something more confidential, let's suppose that there is a file at the Desktop containing usernames and passwords:

- Traversing the path up to the Desktop and entering into the URL, the content of the file can be revealed:

Friday, April 6, 2018

Spoofing an Authentication Cookie


- Layout for this exercise:

1 - Authentication cookies

- Authentication cookies are the most common method used by web servers to know whether the user is logged in or not, and which account they are logged in with.

- Without such a mechanism, the site would not know whether to send a page containing sensitive information, or require the user to authenticate themselves by logging in. 

- The security of an authentication cookie generally depends on the security of the issuing website and the user's web browser, and on whether the cookie data is encrypted. 

- Security vulnerabilities may allow a cookie's data to be read by a hacker, used to gain access to user data, or used to gain access (with the user's credentials) to the website to which the cookie belongs.

- In this exercise the OWASP WebGoat v5.4 will be used for the purpose of exemplifying the spoofing of an authentication cookie: 

2 - Session Management Flaws

- Going to Session Management Flaws -> Spoof an Authentication Cookie:

- The scenario consists of a login web form that works correctly for two different username/password cases, for instance signing in with webgoat/webgoat and aspect/aspect the authentication is ok:

- However, the challenge is to achieve a successful authentication bypass for the user alice, what at first is rejected by the login process:

3 - Tampering the authentication process

- With the purpose of retrieving authentication cookies for webgoat/webgoat and aspect/aspect let's use the Tamper Data add-on of the browser Firefox:

- Starting the tamper:

- Now, let's sign in with webgoat/webgoat:

- Tampering:

- Copying the cookie:

- Storing the authentication cookie for further study:

- Same thing for aspect/aspect:

- As a result of the tampering, now we have two authentication cookies, one for webgoat/webgoat and the other one for aspect/aspect:

- Comparing the two cookies it is clear that both start by 65432 and end up with two different strings: ubphcfx and udfqtb

4 - Decoding/encoding the cookies

- Going to:

- Entering the string ubphcfx and reversing:

- Decoding with Char-- (shifting down one character):

- The result is the expected webgoat:

- Same process with the authentication cookie udfqtb obtained for aspect/aspect:

- So now what we can do is to follow the reverse method with alice in order to achieve a similar string to build a new authentication cookie:

- Reversing and encoding with Char++ (shifting up one character):

- The result is:

-  Actually the encoding process is very simple, consisting of just reversing plus shifting one character:

wegboat ->  taogbew -> ubphcfx 
aspect    ->  tcepsa    -> udfqtb
alice       ->  ecila        -> fdjmb

- To build alice's cookie the string fdjmb is prepended to 65432 in this way:

5  - Launching the cookie spoofing attack

- Now, let's tamper again an authentication session for webgoat/webgoat:

- At this moment, let's copy alice's crafted cookie and paste it into the cookie field:

- Clicking OK:

- Finally the attack is successful and the spoofed user alice becomes authenticated: