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:
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.
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:
https://en.wikipedia.org/wiki/Basic_access_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.
https://httpd.apache.org/docs/2.4/misc/password_encryptions.html
-
See source file apr_md5.c for the details of the algorithm:
http://svn.apache.org/viewvc/apr/apr/trunk/crypto/apr_md5.c?view=markup
- 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:
