The information security experts said that in many cases what separates administrators from normal users is nothing more but the knowledge of a password. It does not sound glamorous and indeed it is as noisy as it gets but in the majority of the cases bruteforce attacks are the most practical and easy way to break into systems by taking advantage of bad password management practices.
Web Applications and Web Services are particularly vulnerable to password bruteforce attacks. This type of software is relatively easy to access, it is abundant, it is available remotely by default and most of all it is custom and subject to constant change to keep up with the latest developments in Web technologies.
Basic Authentication
Since the early days of the World Wide Web, Basic Authentication and some of its variations, such as Digest Authentication, NTLM and so on, is the defacto standard for authentication. It is no secret that Basic Authentication is sufficiently insecure to be used for any practical purposes but this does not stop developers utilising this authentication scheme to password-protect router management interfaces, web services, administrative interfaces and much more. One of the reasons why it is so wide-spread is because Basic Authentication is relatively straightforward to implement as the whole authentication scheme relays on a specially constructed header, which contains both the username and the password encoded in base64 format.
The information security experts set up a brutforce attack against a basic authentication prompt. Open AppBandit’s Fuzzer or the Fuzzer from the online suite and configure a few parameters. First of all, we need to set the Authorization header and then we need to add the Basic Authentication item, which was purposefully build for this specific task.
For the username, professionals will use a list of known accounts. They can also use a common dictionary from some well-known databases.
For the password, professionals will use an actual dictionary. AppBandit nor Fuzzer come with their own dictionaries. Instead, both tools can download and include dictionary files provided from the community. Add a dictionary item from the drop-down and simply search for “password” and you will find the list of various collections from many kinds of most common password lists and actual password list extracted from well-known past data breaches.
Ensure that you increase the maximum parallel requests to 60 or more and reduce the timeout to something like 5 seconds in order to increase the performance of the attack. Sure enough, soon on later professionals find the right password by simply monitoring the response codes as illustrated by the screenshot below.
Pin-Based Authentication
Many applications, particularly mobile apps, utilise what is known as PIN-based authentication, i.e. authenticating with 4 to 6 digit code. Two-factor authentication based on token-generation sent over email or SMS also falls under this category because it is often incorrectly implemented. Needless to say, PINs provide low entropy to be considered secure. Bruteforcing pins, whether you decide to bruteforce them sequentially or at random is straightforward.
The information security researchers set up the attack against a fictitious JSON service. Configure the request so that it is considered valid by the service. In the body, we will use a chain of items to correctly encode the generator for the pin. First, experts need JSON encoder to quote the value. Professionals also need a Format item to pad the value to the correct pin length.
The pad item contains a simple counter, i.e. for loop. The counter goes from 0 to 9999 with step 1. The reason we use the pad is that only 4 digit numbers are considered valid pins. We need to add extra zeros in front of the number to cover all pins starting with zero to make a four-digit pin. We can use the same technique for 6 and 8 digit pins as well.
Setup the attack options as desired – i.e. increased number of concurrent request and reduced timeout. Execute the attack. Unlike the Basic Authentication bruteforce example, we saw earlier, which provides a straightforward mechanism based on status code to differentiate valid from invalid attempts, this type of attack entirely depends on the application so you need to come up with your own heuristics. It is also possible to sort the responses based on how much time it took to come back.
This same attack can be configured for form-based authentication and even Basic Authentication. You just need to move the generator to the desired place.
Form-Based Authentication
Needless to say, form-based authentication is the most common type of authentication scheme on the web. Practically any PHP application implements one – most of the time badly. If correctly implemented the form-based authentication should be resilient to automated password guessing attempts but although it may sound simple, this is by no means easy in real-world scenarios as there are many corner cases that require specific type of handling.
To set up a form-based authentication bruteforce attack we need to follow the same steps with the Basic Authentication example. This time we will not use the Authorization header but we will have to follow set up the parameters that are expected by the application. We can capture that information first by the AppBandit Proxy or tools such as HTTPView which work straight from your own browser without additional setup.
Information security researchers can get pretty clever as especially if the username is an email and we want to cover more ground.
So let’s set up a generator for our user list. First, we will define some variables to make the attack a lot more configurable.
The information security professionals dynamically generate the email address.
Now let’s add the top 100 more common passwords from the same list.
Once the attack is running you need to keep an eye on the running task for clues that will indicate a valid login attempt. For the majority of the responses, professionals will get the same result. Those requests which contain valid credentials will differentiate in a number of ways as we discussed earlier. You need to come up with your own heuristics. Most of these scenarios are covered by the built-in filters.
Authentication Caveats
Web authentication systems are funny in a sense that they can never be perfect. If they are too secure then they will be inaccessible. If they are too accessible they are they are most likely insecure. As a result, of this, there are a number of things to keep in mind when cracking passwords with any of the techniques covered above.
Account lockout is a common defence mechanism against brute-force attacks but it can be converted to denial of service depending on the situation. Since we can generate valid usernames with high degree of success this means that we can also lock everyone out of the system – i.e. denial of service.
Converting between horizontal and vertical bruteforce attacks is also a common technique. In other words, instead of testing many passwords against a single account, we can test for one password against many accounts given that we can either enumerate the accounts or generate them somehow with high degree of success.
Some authentication systems naively lock out valid authentication attempts if they come from the same IP address. Later, these systems are refactored to have a number of exceptions because it is discovered that IPv4 address space is relatively small and many customers are likely going to have the same IP. An attacker might be able to utilise one of these networks or trick the application to believe they originate from networks in the exception list to bypass the account lockout restrictions.
Similarly, if the authentication system blocks IPs or NETBLOCKs based on the attacker’s IP address, a bruteforce attack can be converted into denial of service as the users in the same network will not be able to log in. Information security researchers said, this is particularly important for mobile networks as it is unlikely for the mobile user to have a dedicated public IP address.
Finally, just because there is reCAPTCHA on the page it does not mean it is used. Many times it is there for show.
Deauthentication may not actually work – i.e. although it will appear that the user is logged off, the actual session is not destroyed. Previously used sessions can be reused by the attacker.
Working as a cyber security solutions architect, Alisa focuses on application and network security. Before joining us she held a cyber security researcher positions within a variety of cyber security start-ups. She also experience in different industry domains like finance, healthcare and consumer products.
