Monday, April 2, 2018

HTTP Basic Authentication bruteforce attack with Burp proxy


- Layout for this exercise:

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

- In this case the goal  is to bruteforce HTTP Basic Authentication using the Burp Suite Proxy.

- First of all, let's enable manually a proxy connection at the Firefox browser of Kali Linux.

- Firefox -> Preferences -> Advanced > Network > Connection Settings:

- Manual proxy configuration: listening on localhost port 8080:

- Launching Burp:

- Options tab: checking that the proxy is listening on the localhost interface at port 8080:

- Connecting the browser to the web page protected with Basic Authentication:

- Burp intercepts the request to the web page:

- Forwarding the request:

- The Apache web server responds with the "Authentication Required" message. Let's introduce some arbitrary credentials, for instance "asdfg:asdfg":

- Burp intercepts the sending credentials:

- Now, Burp will help us to craft those sending credentials. For that purpose, the message is sent to the Intruder:

- The target of the attack is

- The Positions tab helps to specify where to insert the payload for the attack. Decoding with Base64, the fake credentials "asdfg:asdfg" are revealed:

- Putting the username:password space between the section sign §:

- Going to the next tab, Payload sets the type of attack: Brute forcer.

- In this example the character set is simple, just 2 letters (ab), and the minimum and maximum number of characters is 5. 

- Adding a processing rule for the prefix "admin:", corresponding to the username:

- Adding a processing rule for Base64 encoding, used by Basic Authentication:

- The two rules for proccessing the payload:

- It is also very important to remove the character = for encoding, because = is used by Base64 for padding:

- The attack is ready to be started:

- Because the charset is 2 and the number of characters is 5, the total number of tries will be 2^5 = 32.

- The attack starts, and the response status is 401 until a 200 answer is received. Obviously, the 200 message corresponds to a successful try:

- Decoding with Base64:

- The result is the correct credentials "admin:ababa":

- The web server responses, as expected, with the HTML code of the web page:

- Removing the proxy:

- Finally, authenticating the correct credentials the web page is available:

Bypassing HTTP Basic Authentication with Metasploit


- Layout for this exercise:

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

- Creating the files users.txt and passwords.txt:

- Launching Metasploit in quiet (-q) mode:

- Using the auxiliary module http_login:

- Setting some options:

- Running the exploit, there is a successful login corresponding to the correct credentials:

- Authenticating with the correct 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

Capturing HTTP Basic Authentication credentials with Wireshark


- Layout for this exercise:

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

- Launching the sniffer Wireshark, the Kali Linux machine is able to capture all packets crossing its interface eth0:

- Whe the user from Kali tries to access the web page "/basicauth/index.html" the Apache web server responds with the challenge for Authentication requirement. I
ntroducing the credentials:

username = admin
password = ababa

- As expected the access is successful:

- Setting up a filter that limits packets only to those exchanged between Kali ( and Ubuntu Apache server (, we can look into the packets captured by Wireshark.

- Once Kali has sent the correct credentials the server responds with a 200 OK message:

- However, opening the first packet it is clear that Basic authentication has been used, also displaying the string corresponding to the credentials.

- The credentials have been sent without encryption, but encoded with Base64, and the correspondig string can be copied for further study:

- Now, a Python script can be used to decode the Base64 string and reveal the correct credentials: 'admin:ababa'

- Also, Wireshark captures the HTML text response from the server, corresponding to the web page resource:

Tampering HTTP methods to bypass HTTP Basic Authentication


- Layout for this exercise:

- HTTP method tampering is a vulnerability suffered by some misconfigured web servers, what can be used to bypass authentication of a directory.

- HTTP method vulnerabities happen if:

   i) it is possible to list the HTTP methods allowed by an application.
   ii) the security controls fail to block not allowed methods.
   iii) the method GET is executed by default.

- In the example used to illustrate this case it is applied HTTP Basic Authentication on the "test" folder, while the hidden file .htpasswd stores usernames and passwords:

- It is important to notice that the "valid-user" requirement for authentication is limited just to the POST method. 

This is a clear misconfiguration, because it means that any other method different to POST would be allowed to access the web page without any authentication.

- After configurating the former authentication schema for /test, let's restart the web server:

- The Linux tool curl (transfers data from or to a server), used in combination with the HTTP request method OPTIONS (lists the methods supported by the URLhelps to check what are the methods enabled for the directory /test:

- POST responds with the 401 Unauthorized standard answer because for this method it is required authentication (Require valid-user):

- However, the HEAD method responses with the standard 200 OK successful answer:

- Also, the GET method responses with the standard answer 200 OK for successful authentication. In comparison to HEAD, the GET method supplies the whole content of the web resource:

 -  Now, just writing the URL and clicking on the browser simulates the GET method. The consequence is that the authentication defined in the Virtual Host configuration is tampered (GET method does not require "valid-user" authentication), and the resource is available for every user:

- This type of vulnerability is not very usual nowadays. However, some legacy servers in large organizations might be vulnerable in case they are misconfigured according to the described way in this post.

Setting up HTTP Basic Authentication


- Layout for this exercise:

- Web applications may provide their own access control methods, but a web server can also restrict access by using two types of authentications that are part of the HTTP standard: Basic and Digest authentication.

- HTTP Basic Authentication (BA) is the simplest way to enforce access control to web resources. When making a request, the user agent  provides credentials (username and password) to the web server.

- BA uses standard fields in the HTTP header, not providing confidentiality because the credentials are sent just encoded with Base64, but not encrypted or hashed at all. 

- For further information about HTTP Basic Authentication:

- To implement Basic Authentication on an Apache web server, first of all a password file must be created, so that Apache can read it whenever the web page is requested.

- The utility htpasswd (part of the apache2-utils package) manages user files for basic authentication. As an example, let's take:

username: admin (very common as default username in many devices)
password: ababa (simple, for the purpose of ease in this exercise)

- The hidden file .htpasswd has been created and stored encrypted on the server side:

- The default encryption format to store the credentials is "$apr1$" + the result of an Apache-specific algorithm using an iterated (1,000 times) MD5 digest of various combinations of a random 32-bit salt and the password.

See source file apr_md5.c for the details of the algorithm:

- Editing the Ubuntu default virtual host file (000-default.conf):

- Adding the HTTP BA restriction for the directory called "basicauth", where the web page is contained. The <Directory> block specifies that the type of authentication is Basic, the name of the realm (the realm name defines a protection space for a web resource in combination with the canonical root URL of the server being accessed), the path to the .htpasswd file, and the requirement of "valid-user" credentials:

- In this way, we have established a per-directory basis HTTP BA specific for the directory "basicauth" that we are interested in. 

- After editing the virtual host file, let's restart the web server:

- Configtest command checks that the syntax of the configuration file is correct:

- Reviewing the status of the web server:

- Now, a user is prompted to enter credentials when trying to access the web resources contained in the directory "basicauth".

- In case of introducing bad credentials, the server answers with the default "Unauthorized" message:

- Introducing the correct credentials, the web resources are finally available: