In today’s time, the use of the authentication system is increasing because of the increase in the number of services that are coming up on the internet. But not everyone knows how to either make proper authentication software or how to properly set up one.
The very obvious method of attacking any login form is just to brute force the credentials. But in this kind of brute force, we don’t simply try numbers or simple alphabets. What we do is take an existing dictionary of commonly used username/passwords and use those to see if we can find the right combination. This is known as Dictionary Attack.
To perform a dictionary attack we can use a lot of tools like Hydra or Medusa but the issue with these CLI tools is that we need to provide a lot of arguments to them started and that could be confusing. That is why when trying a dictionary attack on a web application/form it’s better to use Burp Suite. In Burp we can capture the login request and then use the intruder to perform the attack.
Re-registration
We saw that it is possible to just simply guess/brute force the password with the help of a password dictionary. In this task, we are going to focus on a vulnerability that is unique in its own way.
A lot of times what happens is that developer forgets to sanitize the input(username & password) given by the user in the code of their application which can make them vulnerable to things like SQL injection but SQLi could be a bit difficult to exploit. So we are going to focus on a vulnerability that happens because of a developer’s mistake but is very easy to exploit i.e re-registration of an existing user.
Let’s understand this with the help of an example, say there is an existing user with the name admin and now we want to get access to their account so what we can do is try to re-register that username but with slight modification. We are going to enter “ admin”(notice the space in the starting). Now when you enter that in the username field and enter other required information like email id or password and submit that data. It will actually register a new user but that user will have the same right as normal admin. And that new user will also be able to see all the content present under the user admin.
JSON Web Token
JSON Web Token(JWT) is one of the commonly used methods for authorization. This is a kind of cookie that is generated using HMAC hashing or public/private keys. So unlike any other kind of cookie, it lets the website know what kind of access the currently logged-in user has. The only special thing about JWT is that they are in JSON format(after decoding).
JWT can be divided into 3 parts separated by a dot(.)
1) Header: This consists of the algorithm used and the type of the token.
{ "alg": "HS256", "typ": "JWT"}
alg could be HMAC, RSA, SHA256 or can even contain None value.
2) Payload: This is part that contains the access given to the certain user etc. This can vary from website to website, some can just have a simple username and some ID and others could have a lot of other details.
3) Signature: This is the part that is used to make sure that the integrity of the data was maintained while transferring it from a user’s computer to the server and back. This is encrypted with whatever algorithm or alg that was passed in the header’s value. And this can only be decrypted with a predefined secret(which should be difficult to)
Now to put all the 3 part together we base64 encode all of them separated by a dot(.) so it would look something like:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Note: This example was taken from jwt.io and you should check that website out if you want to learn more about JWT.
Exploitation
If used properly this is a very secure way of authorization but the problem is with using is “properly”. A lot of developers misconfigure their system leaving it open to exploitation.
Now one of the methods to exploit this is to perform a brute force/dictionary attack and find the secret used for encrypting the JWT token and then used that to generate new tokens. But here we are not going to do that, we are going to see a very amazing way of exploiting this.
If you remember, in the Header section I said that the alg can be whatever the algorithm is used, and also it can be None if no encryption is to be used. Now, this should not be used when the application is in production but again the problem of misconfiguration comes in and make the application vulnerable to this kind of attack. The attack is that an attacker can log in as low privilege user says guest and then get the JWT token for that user and then decode the token and edit the headers to use set alg value to None. This would mean that no encryption has to be used therefore the attacker wouldn’t need to the secret used for encryption.
A lot of time on websites we see that when we register a user and login with our credentials we are given a certain id which either is completely a number or ends with a number. Most of the time developers secures their application but sometime in some places, it could happen that just by changing that number we are able to see some hidden or private data.