Authentication issues

Authentication in a web application plays an important role as it verifies the identity of the user and allows the user to view and interact with only those contents that the user is authorized to access. In a web application, authentication is usually done by a combination of username and password.

Authentication protocols and flaws

Authentication is done in web applications using the following methods:

• Basic authentication
• Digest authentication
• Integrated authentication
• Form-based authentication

Basic authentication

In basic authentication, the username and password is transmitted over the network using the Base64 encoding which is very easy to reverse and acquire the clear text password. The credentials can easily be sniffed by an attacker if the transmission is not done over over a secure channel. These drawbacks should be enough to convince a developer to move over to more secure authentication methods.

Digest authentication

The digest mode authentication was introduced to eliminate the drawbacks of basic authentication. It introduced a nonce value that is used as a salt when the client shares the authentication credentials with the server. In addition to the nonce value, the MD5 hash of the password is sent instead of the Base64 encoded value.

Integrated authentication

Microsoft Windows has a single sign-on authentication scheme know as integrated authentication, which leverages a central authentication server called the domain controller. Once a user authenticates successfully to a domain controller, it stores a token. The token comes with a defined life time. When a user access a website that leverages integrated authencation and is part of the same domain as the user, the client passes the token and the user is granted access to the application. LANMAN, NTLMv1, and NTLMv2 are the underlying challenge/response protocols used for the authentication that is seamless.

Form-based authentication

When a login page is used to accept the username and password of the user in a web form, it is called as a form-based authentication. At the server side, the credential is stripped from the form and is validated against an authentication system. Form-based authentication is of great interest to an attacker because it is prone to injection attacks, as the developer is responsible for implementing the security of the form. The authentication information is also shared in clear text when SSL is not implemented.

Using Burp proxy, we can sniff the authentication credentials shared by the client to the server, as shown in the following screenshot. The username and the password are clearly visible in the body of the HTTP message:

Brute forcing credentials

During the assessment of a web application, a test to check the strength of the password should always be included in the plan. The web application developers should implement strict password policies to defeat brute forcing tools. Hydra, a very customizable brute forcing tool included in Kali Linux, provides the option to even brute force the credentials of an application using form-based authentication.

Hydra – a brute force password cracker

Hydra has been tested over several protocols, including HTTP, POP3, SMB, SSHv2, RDP, and many more. It is a password-guessing tool that can try to brute force the password or use a dictionary file to crack it. No points for guessing that your chance of hitting the right password is directly proportional to quality of the dictionary file. With good social engineering skills and knowledge about your target, you can build a good dictionary file. The complete command with its arguments is as follows:

hydra 192.168.1.8 http-form-post "/form_auth/login.php:user=^USER^&pass=^PASS^:Rejected" -L user.txt -P pass.txt -t 10 -w 30 -o hydra.txt

Hydra is a customizable tool and includes multiple options. To successfully brute force a form login page, we require the following information:

• Host: 192.168.1.8

  The host is the target website, such as www.testlab.org.

• Method: http-form-post

  The method when attacking a login page is http-form-post as it uses the post method.

• URL: /form_auth/login.php

  The URL is action page which accepts the credentials, this URL can be determined by using a proxy or by viewing the source of the HTML page.

• Form parameters: user=^USER^&Pass=^PASS^

  These are the variable used to take input which can again be determined by viewing the source by using Ctrl + U in Firefox.

• Failure response: Rejected

  This is an important option; if you don't set it correctly, hydra won't know when it has cracked the password. When you type in the wrong password, the web application will echo back its response mostly likely a login failure notification back to the client. This response is used by hydra to determine if it had cracked the password. When it does not receives a rejected message, which means it possibly got a success message back, it will stop. The response can be viewed using a proxy such as Burp.

• List of username: -L users.txt

  With a text file, you can provide a list of usernames which hydra uses against the target.

• Password dictionary: -P pass.txt

  With the –P option, you can provide a list of passwords that hydra uses along with the username provided earlier. Hydra tries to log in with a combination of each password and username. For example, if you have 10 usernames and 5 passwords, it will make 50 login attempts.

• Threads: -t 10

  Using the –t option, you can specify the number of simultaneous login attempts.

• Timeout period: -w 30

  With the timeout period, you can specify the duration (in seconds) for each login attempt.

• Output file: -o hydra2.txt

  You can redirect the output to a text file using the –o option.

The following screenshot shows the output of the preceding commands:

In the preceding example, 391 login tries were made before hydra got a success message from the server. It also lists the correct username and password values.