WSTG - Latest

Home > Latest > 4-Web Application Security Testing > 04-Authentication Testing

Testing for Bypassing Authentication Schema

ID
WSTG-ATHN-04

Summary

In computer security, authentication is the process of attempting to verify the digital identity of the sender of a communication. A common example of such a process is the log on process. Testing the authentication schema means understanding how the authentication process works and using that information to circumvent the authentication mechanism.

While most applications require authentication to gain access to private information or to execute tasks, not every authentication method is able to provide adequate security. Negligence, ignorance, or simple understatement of security threats often result in authentication schemes that can be bypassed by simply skipping the log in page and directly calling an internal page that is supposed to be accessed only after authentication has been performed.

In addition, it is often possible to bypass authentication measures by tampering with requests and tricking the application into thinking that the user is already authenticated. This can be accomplished either by modifying the given URL parameter, by manipulating the form, or by counterfeiting sessions.

Problems related to the authentication schema can be found at different stages of the software development lifecycle (SDLC), like the design, development, and deployment phases:

  • In the design phase errors can include a wrong definition of application sections to be protected, the choice of not applying strong encryption protocols for securing the transmission of credentials, and many more.
  • In the development phase errors can include the incorrect implementation of input validation functionality or not following the security best practices for the specific language.
  • In the application deployment phase, there may be issues during the application setup (installation and configuration activities) due to a lack in required technical skills or due to the lack of good documentation.

Test Objectives

  • Ensure that authentication is applied across all services that require it.

How to Test

There are several methods of bypassing the authentication schema that is used by a web application:

  • Parameter modification
  • Session ID prediction
  • SQL injection

Parameter Modification

Another problem related to authentication design is when the application verifies a successful log in on the basis of a fixed value parameters. A user could modify these parameters to gain access to the protected areas without providing valid credentials. In the example below, the “authenticated” parameter is changed to a value of “yes”, which allows the user to gain access. In this example, the parameter is in the URL, but a proxy could also be used to modify the parameter, especially when the parameters are sent as form elements in a POST request or when the parameters are stored in a cookie.

https://www.site.com/page.asp?authenticated=no

raven@blackbox /home $nc www.site.com 80
GET /page.asp?authenticated=yes HTTP/1.0

HTTP/1.1 200 OK
Date: Sat, 11 Nov 2006 10:22:44 GMT
Server: Apache
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
</HEAD><BODY>
<H1>You Are Authenticated</H1>
</BODY></HTML>

Parameter Modified Request
Figure 4.4.4-1: Parameter Modified Request

Session ID Prediction

Many web applications manage authentication by using session identifiers (session IDs). Therefore, if session ID generation is predictable, a malicious user could be able to find a valid session ID and gain unauthorized access to the application, impersonating a previously authenticated user.

In the following figure, values inside cookies increase linearly, so it could be easy for an attacker to guess a valid session ID.

Cookie Values Over Time
Figure 4.4.4-2: Cookie Values Over Time

In the following figure, values inside cookies change only partially, so it’s possible to restrict a brute force attack to the defined fields shown below.

Partially Changed Cookie Values
Figure 4.4.4-3: Partially Changed Cookie Values

SQL Injection (HTML Form Authentication)

SQL Injection is a widely known attack technique. This section is not going to describe this technique in detail as there are several sections in this guide that explain injection techniques beyond the scope of this section.

SQL Injection
Figure 4.4.4-4: SQL Injection

The following figure shows that with a simple SQL injection attack, it is sometimes possible to bypass the authentication form.

Simple SQL Injection Attack
Figure 4.4.4-5: Simple SQL Injection Attack

PHP Loose Comparison

If an attacker has been able to retrieve the application source code by exploiting a previously discovered vulnerability (e.g., directory traversal), or from a web repository (Open Source Applications), it could be possible to perform refined attacks against the implementation of the authentication process.

In the following example (PHPBB 2.0.12 - Authentication Bypass Vulnerability), at line 2 the unserialize() function parses a user supplied cookie and sets values inside the $sessiondata array. At line 7, the user’s MD5 password hash stored inside the backend database ($auto_login_key) is compared to the one supplied ($sessiondata['autologinid']) by the user.

1. if (isset($HTTP_COOKIE_VARS[$cookiename . '_sid'])) {
2.     $sessiondata = isset($HTTP_COOKIE_VARS[$cookiename . '_data']) ? unserialize(stripslashes($HTTP_COOKIE_VARS[$cookiename . '_data'])) : array();
3.     $sessionmethod = SESSION_METHOD_COOKIE;
4. }
5. $auto_login_key = $userdata['user_password'];
6. // We have to login automagically
7. if( $sessiondata['autologinid'] == $auto_login_key )
8. {
9.     // autologinid matches password
10.     $login = 1;
11.     $enable_autologin = 1;
12. }

In PHP, a comparison between a string value and a true boolean value is always true (because the string contains a value), so by supplying the following string to the unserialize() function, it is possible to bypass the authentication control and log in as administrator, whose userid is 2:

a:2:{s:11:"autologinid";b:1;s:6:"userid";s:1:"2";}  // original value: a:2:{s:11:"autologinid";s:32:"8b8e9715d12e4ca12c4c3eb4865aaf6a";s:6:"userid";s:4:"1337";}

Let’s disassemble what we did in this string:

  1. autologinid is now a boolean set to true: this can be seen by replacing the MD5 value of the password hash (s:32:"8b8e9715d12e4ca12c4c3eb4865aaf6a") with b:1
  2. userid is now set to the admin ID: this can be seen in the last piece of the string, where we replaced our regular user ID (s:4:"1337") with s:1:"2"

PHP Magic Hashes

A similar issue can occur in PHP when hashes are are loosely compared, and end up being evaluated as numbers.

PHP supports the use of scientific notation for numbers, so the number 2e4 is treated as “two times ten to the power of four”, which equals 20,000. Similarly, a number such as 0e4 would be “zero times ten to the power of four”, which equals zero. Because zero times anything is zero, this means that an comparison such as 0e2 == 0e3 would evaluate to true, because both sides equal zero.

This can be exploitable where two password hashes are compared, and both of them are in the form of string of zeros, the letter “e”, and then a string of numbers. Consider the following code:

<?php
{
    if (md5('240610708') == md5('QLTHNDT')) {
        print("Passwords match");
    } else {
        print("Passwords are different");
    }                                                                           
}

The two passwords are clearly different, but since they both hash to strings that equal zero in scientific notation (“0e462097431906509019562988736854” and “0e405967825401955372549139051580” respectively), the comparison will return true and the user will be logged in.

In order to test for this, first you need to identify the type of hashing used by the application. Then you can set a password on a user account that produces this type of hash, and then attempt to login with a different password that would produce a different hashes that would also evaluate to zero. Strings for various password hashes are available in the spaze/hashes GitHub repository.

If this is successful, it not only implies that the application is insecurely comparing password hashes, but also that they’re not salting passwords, and most likely that they’re using a legacy hashing algorithm.

Passwords of the Same Length Working

Occasionally applications will allow users to login by entering any password that is the correct length as the actual password. This is a fairly unusual issue, and suggests significant flaws in how passwords are being stored and processed.

One possible cause for this issue is character encoding problems between different parts of the application, as unknown or invalid characters are often represented with a ? character, which some languages such as SQL treat as a single character wildcard. Thus a comparison of a string like password and ???????? may return true if they wildcards are interpreted, such as in a SQL LIKE comparison.

Note: This also implies that passwords are either being stored in plain text, or using reversible encryption.

Testing is simple: try and login to an account with a password that is incorrect, but is the same length as a valid one.

Tools

References

Watch Star