HTTP Basic Authentication bruteforce attack with Burp proxy

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 www.whitelist.com:




- 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

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

 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. Introducing 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 (192.168.1.13) and Ubuntu Apache server (192.168.1.15), 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

TAMPERING HTTP METHODS TO BYPASS 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 URL) helps 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.