Welcome back, my novice hackers!
In this third installment of my Hacking Web Apps series, we will look at the authentication of web applications. Remember, there are many ways to hack web applications (as I pointed out in my first article), and cracking authentication is just one method.
To be able to crack authentication of web applications, we first need to understand a bit about how web applications manage authentication. In order to do this, we will be using the Damn Vulnerable Web Application and Burp Suite to practice our attack methods.
I hope it goes without saying that you should always do reconnaissance first before attempting any authentication attack. Know you enemy!
For the rest of this series, we will be working with the Damn Vulnerable Web Application (DVWA). Although most of the vulnerabilities in this application are rather old and patched in modern applications, we need to start with this application to do the following.
- Demonstrate the principles of web app hacking
- Have a safe environment to practice in
Once we have demonstrated web app hacking principles here on the DVWA, we will progress to show how those principles can be applied to more modern and less vulnerable web applications in later tutorials.
If we are using Metasploitable, simply browse to the IP address of your Metasploitable OS with the Iceweasel web browser in Kali. Here, mine is 192.168.181.128 on my internal network, but if you have Metasplotable on a public IP, it will work just as well. You should see a webpage like this below. Click on the DVWA link.
Once we have clicked on the DVWA link, it will open a login screen like that below. Do not try to log in just yet. Be patient.
We will be using Burp Suite in many of these web-based attacks. It is built into Kali, so no need to install anything. Simply open Burp Suite by going to Applications -> Kali Linux -> Web Applications -> Web Application Proxies -> burpsuite.
When you do so, you should be greeted with Burp Suite opening a GUI, as seen below.
You must configure Burp Suite as your proxy. If you need more information on setting up a proxy, see this article on THC-Hydra where we also used Burp Suite as a proxy.
Before we begin to attack authentication, let's pause a minute to examine the types of web-based authentication.
Basic authentication, as the name implies, is the simplest and most basic form of authentication for a web application. It uses Base64 encoding, which is a weak encoding scheme and easily broken. The Base64 encoding (not encrypting) scheme translates binary data to textual data. Although the underlying plaintext is obfuscated, it is easily decoded.
Basic authentication is often used to authenticate against routers, webcams, etc. If we can intercept the credentials by sniffing or using a proxy like Burp Suite, there are a number of tools available that can decode this simple Base64 encoding.
A step up in security is digest authentication which was described by RFC 2617. Digest authentication relies upon a challenge-response authentication model. The user is usually expected to prove they have some secret without sharing it across an insecure communication channel.
Digest authentication is a bit more secure, but it vulnerable to replay attack. It creates a one-way hash (MD5) that is sent to the server for authentication. To prevent the use of rainbow tables to break this form of authentication, the server sends a nonce which acts like a salt. This MD5 hash cannot be decrypted, but can be captured and replayed by the attacker.
Digest authentication is stronger than basic authentication because the credentials are not sent over the insecure channel, just the MD5 hash of the credentials. Even though it is difficult to crack this MD5 hash, the hash can be captured enroute to the server. Once captured, it will provide anyone access to the account when it is replayed.
Form-based authentication is the more common form of authentication in HTTP. Unlike basic and digest authentication, form-based authentication does not rely upon basic web protocols. It is a highly customizable format that usually has HTML FORM and INPUT tags.
Generally, the form has both username and password fields where the user enters this information which is included in a GET or POST request over either HTTP or HTTPS. This is the form we often see on modern web applications. When the server receives the username and password and they are correct, the user is allowed entry to the application.
Form -based authentication uses a variety of encrypting and coding schemes. As a result, no one type of attack will work in all cases. We need to decipher the type of encoding or encryption before we select an attack method. If TLS or SSL is not enabled, though, the credential will be sent in plaintext.
Let's begin by logging in to DVWA with a username and password combination of admin/password. Now, near the bottom of the left hand buttons, you will see a "DVWA Security" option.
Let's make it a bit more challenging by setting the Security to "high."
Next, Let's go back to the login screen and look at the source code.
As you can see in the source code below, the PHP GETs the username and then validates the input by stripping out special characters that might be used in an SQL injection (' -- ;). Next, it GETs the password and does the same validation on it to remove the possibility of an easy SQL injection. Then, it takes the two strings and puts them into an SQL query string to run against the authentication database. (For more on the basics of SQL, check out this article.)
$qry = "SELECT * FROM 'users' WHERE user = '$user' AND password = '$pass';"
If both of the conditions in the WHERE clause evaluate to true, then the user is authenticated to the web application.
Now that we have the basics of web application down, in my next tutorial in this series, we will examine ways to crack this authentication process. So keep coming back, my novice hackers!