Whitelist

Form HTTP based authentication - Brute force attack with Burp

FORM HTTP BASED AUTHENTICATION - BRUTE FORCE ATTACK WITH BURP

- Layout for this exercise:

- The goal of this exercise is to bypass a form based authentication, trying to gain access to the resources located into www.whitelist.com/formauth.

- The attack method used in this case will consist of brute forcing the username and password challenges prompted to the user, taking advantage of some tools provided by the proxy Burpsuite:

- First of all, the browser used by the attacker is set to connect the web page through a manual proxy, so that the connection can be intercepted and crafted:

- Starting the proxy Burp:

- Now, when the user tries to connect to www.whitelist.com/formauth, the connection is intercepted and refused by Burp:

- Analyzing into Burp, the request has been intercepted:

- Then, the request is forwarded:

- Now, the attacker enters some fake credentials (username=asdfg, password=xxxxxxxx):

- Burp detects the fake credentials:

- Right clicking and sending to the Intruder:

- Setting the target (Host and Port) for the attack:

- The attack consists of brute forcing 2 payloads: the 1st payload is inserted into the username position and the 2nd payload is for the password:

- The first payload is defined with a simple list of two possible usernames:

- It is interesting to notice that the Pro version of Burpsuite allows to introduce a complex password list previously crafted or generated by the attacker:

- About the second payload, referred to the password, Burp prompts the user with a charset of lowercase letters, numbers, and a length of 5.

- However, because of the huge amount of requests that Burp would generate (60466176, it would take hours to check all of them), I have simplified the process using a very easy charset with the letters "ab" and a length of 5.

- In this way, the number of request counts would be VR(2,5) = 2^5=32, multiplied by 2 because the first payload list is composed of 2 possible usernames. To sum it up, 64 requests:

- Starting the attack:

- Once the attack is developed, it can be noticed that all the results have a length of 411, with the exception of the 22nd one, whose length is 383:

- For instance, checking the rendered response for the 33rd request, the answer is that the user is not authorized to access the web page, so the corresponding combination (daniel:aaaab) is not correct:

- However, doing the same for the 22nd response (the one with different length) the answer is positive. We find that the user is authorized and welcome to the web page:

- Looking at the response in a raw format:

- We can deduce that the combination used for that request is correct (admin:ababa) and the attack has been successful.

Cracking HTTP Digest Authentication with Hydra

CRACKING HTTP DIGEST AUTHENTICATION WITH HYDRA

- Layout for this exercise:

- Creating a list for users:

- Creating a list for passwords, 5 characters with the limited charset of "ab":

- Launching Hydra, and passing as parameters the lists of users and passwords:

- A successful password has been found. Checking the credentials, the web resource is available:

- Note: in this exercise a very simple combination of username:password has been used, because the purpose was just to illustrate the usage of the attacking tools. However, in real world there are available complex lists of combinations of username:password that can be used for performing dictionary and brute force attacks. The Kali command #locate wordlists provides many available wordlists, for instance into the folder /usr/share/wordlists

HTTP Basic Authentication bruteforce attack with NSE (Nmap Scripting Engine)

HTTP BASIC AUTHENTICATION BRUTEFORCE ATTACK WITH NSE (NMAP SCRIPTING ENGINE)

- Layout for this exercise:

- This exercise is based in the previous post Setting up HTTP Basic Authentication.

- The Nmap http-brute script is part of the NSE (Nmap Scripting Engine) and performs brute force password auditing against http basic, digest and ntlm authentication.

- Some of the possible arguments are:

http-brute.hostname = sets the host header in case of virtual hosting
http-brute.method = sets the HTTP method to use (GET by default)
http-brute.path = points to the path protected by authentication

- For more information about this NSE script:

https://nmap.org/nsedoc/scripts/http-brute.html

- In this example we are pointing at the resources identified by the URL www.whitelist.com/basicauth/

- Let's suppose simple credentials, for the ease of this exercise:

username = admin
password = ababa

- Creating users.txt and passwords.txt, both stored into the root(/) folder:

- Launching the http-brute script with the right options, the brute force is successful in just 0.08 seconds:

- Checking that the credentials are correct:

Calculating HTTP Digest Authentication parameters with Wireshark and Python

CALCULATING HTTP DIGEST AUTHENTICATION PARAMETERS WITH WIRESHARK AND PYTHON

- Layout for this exercise:

- This exercise is based in the previous post Setting up HTTP Digest Authentication.

- HTTP Digest Authentication (DA) applies a hash function to the username and password before sending the credentials over the network.

- DA was originally specified by RFC 2069, although it was later replaced by the more secure RFC 2617. For instance, the new standard protects against the chosen-plaintext attack cryptanalysis.

- The process consists of 3 steps:

1) H1 = MD5 (username:realm:password)

2) H2 = MD5(method:URI)

3) response = MD5(H1:Nonce:NonceCount:ClientNonce:qop:H2)

- Nonce is randomly generated by the server and helps preventing reply attacks due to the presence of timestamp; NonceCount prevents reuse of nonces (the value increments each time a new request is done); ClientNonce is created by the user and prevents collision attacks from rainbow tables; and qop ("auth" for authentication) is the quality of protection.

- Since client and server share same information, both parties perform their own calculation for the "response".

- Once the server receives the "response" from the client, it verifies whether there is a match with its own calculation. Only in case of matching then the server allows authorization to the resources.

- The goal of this exercise is to illustrate how HTTP DA (RFC 2617) calculates the "response" using repeatedly the algorithm MD5.

- First of all, let's launch the sniffer Wireshark at the Kali machine, filtering packets for just the HTTP protocol:

- The client Kali tries to access the web resource and the server responds with an authentication requirement:

- Once the client enters the correct credentials, the server allows access to the web page:

- Now, let's examine the packets captured by Wireshark, limiting to those exchanged by the client (192.168.1.13) and the server (192.168.1.15).

- The third packet corresponds to the client sending the correct credentials, because the next one (the fourth) corresponds to the 200 OK successful answer from the server:

- Opening the third packet, all the parameters used in the DA transaction are displayed:

- Copying the parameters to a text file for further study:

- Now, all parameters are available so that we can reproduce the calculations performed by server and client:

- Using a Python script with the previous parameters:

- The "response" is finally calculated:

- We can check that our "response" is equal to the "response" calculated by server and client in the previous example:

Setting up HTTP Digest Authentication

SETTING UP HTTP DIGEST AUTHENTICATION

- Layout for this exercise:

- While HTTP Basic Authentication exchanges "username:password" in plain text, just encoded with Base64, however HTTP Digest Authentication sends the credentials encrypted with a MD5 Hash.

- In future posts we'll see how the MD5 is crafted by the Apache server. For now, more information about HTTP Digest Authentication is available here:

https://en.wikipedia.org/wiki/Digest_access_authentication

- Let's set up HTTP Digest Authentication at the Apache web server on the folder "digestauth", located in the web root folder "/var/www/html/":

- First of all, the mod_auth_digest must be installed:

- The utility htdigest creates a file (in this case it is a hidden file named .htdigest) used by Apache to establish the credentials. Three parameters are provided by the user:

realm: withelist_authority

username: admin
password: ababa

- Checking the content of the hidden file .htdigest:

- Adding some directives to the virtual host configuration file, located at "/etc/apache2/sites-enabled/000-default.conf":

- Note that the directives are specified for the folder "/digestauth", providing its whole path. Also, AuthName must match the realm provided for .htdigest, in this case "whitelist_authority":