Hey Folks, In this tutorial, we are going to discussing the types, mitigation and exploitation of Broken Authentication and Session Management vulnerabilities. We are usually discussing the OWASP TOP 10 web application vulnerability and of which this vulnerability comes second in the OWASP TOP 10. Both vulnerabilities are very important and through this article you will learn how attackers can take over accounts if these vulnerabilities are found in web application even how we can prevent these vulnerabilities and protect ourselves.
Lets take a look 🙂 !!
First we’ll talk about broken certification and their practicals, likewise session management and their practice. Finally we will discuss the mitigation of both vulnerabilities.
A Short Intro About the Authentication
Authentication is the process of recognizing or identity of a computer system user. For Instance : each and every time we need to enter user and password when we try to access particular resources and then the process starts and the server tries to locate the credentials in the database, If the credentials are found then it authenticates the user.
What is Broken Authentication?
Broken Authentication is types of vulnerability that allow an attacker to
bypass the authentication through various types of techniques such as :
- Through Bypasses the Captcha Securities
- Bypassing Two Fatcor Authentication
- Credential Stuffing – A list of Valid Username and Password List
- Brute force or other automated attacks.
- Exposes Session IDs in the URL
- Session ID does not expire after successful logout.
There are some more technologies left that can help us bypass authentication. But the question is how these vulnerabilities arise ?
- Due to disable Two Factor Authentication
- If applications, software, and OS are not up-to-date.
- Due to disable the limit login attempt security’s.
- If the server only accepts the password and not the passphrase.
Similarly, there are many things that we must do for sure. But how can we prevent this vulnerability ?
- To patch all vulnerabilities and keep all up-to-date.
- Set secure and strong authentication policy.
- Make sure server accept only the passphrase.
- It is suggested to not expose authentication protocol.
- Ensuring that session IDs and cookies are encrypted.
- Validate all user input on the server side.
Captcha Bypassing with Credential Stuffing
The captcha security specially designed to prevent against the bot, malware and attacks such as : brute force, fuzzing etc. If you want to get deep knowledge on this then you can visit here. In order to prevents these kind of attacks, we implement the captcha security on web application but sometimes the attackers bypass it and take over the account using brute force technique. But we will take a live example using the bWAPP vulnerable web application.
From the given image we can analyze that captcha is required to login in web application, even we cannot login by giving wrong captcha.
After analysis the back we observed that in the low and medium setting does not have any kind of restriction. As we know that isset function is always returns true if the variable exists which means if the input has value then it will be true print. YEEEE 🙂 !!
Got it 🙂 Now we will enter any username and password but we have to enter the correct captcha details.
In this situation we will uses our burpsuite tool and intercept the request. After doing this we click on action button and send the request into the intruder mode to perform brute force attack.
Here we will select the payload and also the place where we will add a valid username and password list.
in the first list we add a valid username as you can see in the image below.
In the second list we add a valid passwords and click on attacks.
Amazing 🙂 As you know we initially added the correct captcha details and the result of which you can see here and we have successfully bypassed CAPTCHA security and got the correct credentials.
As you can see that we have successfully login into the web application with “bee” and “bug” credentials.
Two-factor authentication is a additional security process in which users provide two different authentication factors to verify themselves. There are multiple types of two factor authentication security such as : one-time passwords, verification codes, QR codes, hardware tokens and questions ❔.
A scenario is mentioned below in which we are trying to reset our account password but we do not have an answer to the security question. Hmmmm 🙂 What will do !! Now we will tampering some things and try to reset the password.
After enter any username and password we intercept the request through the burpsuite and analysis the code.
We did not get any idea after analyzing the request but we will maneuver. We have only two options, first is to remove all query parameters and second to add some additional parameters like null characters etc to defeat the security. But we just add the number zero before the number in question as you can see below. Let’s see what will happen.
Nice 🙂 We cannot believe it, you can see below that we have successfully defeated security and we went ahead without answering questions.
Insecure Login Forms
The vulnerabilities that can be exploited on an insecure login landing page that called as “broken authentication vulnerability”. Sometimes login or landing pages are vulnerable due to sensitive information leaking into the source page. We will take the same example through the bWAPP application. We do not know the username and password, lets try to bypass the authentication.
After intercept the request we did not get an idea, but after go to source code of the login page we get username and password. As you can see below there is no sense of giving user and password in source code and this mistake causes the attacker to bypass authentication.
Done 🙂 After entering the above credentials we are able to bypass authentication.
This is another vulnerability that can lead to broken authentication vulnerabilities. Let’s take an instance : Suppose we use a public computer to access important documents and for this we login to any website, after complete we selecting “logout” and simply closes the browser tab and walks away. but attacker uses the same browser after half an hour, the user is still authenticated which means the web application is vulnerable to the logout management vulnerability. Lets take a live example using a bWAAP web application. The application is vulnerable to this vulnerability so we will click the “here” button and logout from the web application.
Now we can come back or enter the URL of the home page.
WOW 🙂 Here you can see that we have successfully login to the web application again without any credentials.
brute Force Attack
As we know about brute forcing in which attackers use a large number of valid username and password lists and try to break the authentication. There are many tools available that will be found on GitHub from which you can choose once to break the authentication, but in our case we will choose our compatible burpsuite tool. Below you can see that we are unable to access the web application.
Open the burpsuite tool and intercept the request. After doing all this we will go to the Intruder tab via the action button.
Now we will select the payload and also their position. After doing this we have to add a valid username and password list and click on the attack option.
HAHA 🙂 What a great credentials !! Below you can confirm that the length of the correct credentials has changed. Similarly we can perform brute force attack on any web application.
Now we can login to the web application successfully.
Cookie is a small piece of data which stored on the user’s computer by the web browser while user browsing a website. As we know cookies travel in headers but sometime it becomes a vulnerability for web applications. Below given example we can understand better and we are using penterlab.com for which you can go here. Below we are given a task in which we have already logged in user1 but through this user we have to login to the admin account. Lets see how its possible.
After intercept the request we have observed that cookies are traveling with in md5 hash encrypted value.
Now we will decode it through the third party web application. After decode it you can see that the md5 value is targeted to user1. Got it 🙂 !!
Now we need to get the encoded value of the admin user.
We will reverse this process and change the MD5 hash value of user1 to admin.
Boom 🙂 Here you can see below that the server has accepted the request without knowing the value of cookies and we have successfully logged in without obtaining the admin password.
Session is a temporary and interactive information which interchange between client and server. Session management is the process of keeping track of a user’s activity across sessions of interaction with the computer system such as : login, logout, signin etc. Session management might involve requiring the user to re-login if the session has expired. If vulnerabilities are found in these activities such as :
- Session not expired
- Weak session ID
Then attacker can lead the broken authentication vulnerability and take over the account.
Insecure Administrative Portals
It is type of session management vulnerability where server improperly verifies the identity of a session ID or user both. Look like we have to give an example of this vulnerability. Below given image we can observed that it shows “the page is blocked” but in the URL we obtain some different thing such as ” admin=0“. Lets see what happen after change the value to “admin=1“.
Wow 🙂 Here you can see that we have successfully obtain the admin rights after change the value.
HEHE 🙂 Through the given image you can analyze the code and see that there are no restrictions.
Vulnerability in WordPress
The same vulnerability appears in WordPress but there are some changes. Here you can see that we are already logged into WordPress.
Now we will put “reauth=1” in URL and find out what will happen.
Nice 🙂 We do not need to click on the login button as well as we have successfully logout in WordPress, with adding “reauth = 1” to the URL.
Session ID in URL
This vulnerability may allow the normal user to do anything by the attacker because if the session ID is traveling in the URL, then anyone can change the PHPSESSID and get the other to enter someone else’s account. For example you can see below that we are currently logged in with Shubham user in which PHPSESSID is appearing in the URL as the server uses GET request. Lets try to fix it.
But as soon as we change the security level in medium, we see that PHPSESSID is no longer visible in the URL because the server uses a POST request.
Session ID not Expire
Whenever the client sends a request to access any website, then most of the time session based cookies are transit between the client and the server. As we know that when we access a website, the session ID is generated by the server which depends on the client because the session ID will expire automatically as soon as the client closes the browser. But sometimes the session ID is not terminated by the server and attackers take advantage of this vulnerability. Lets take a scenario.
First – The PHPSESSID is created when we log into the web application and the PHPSESSID expires after logout, which should also happen.
Second – Now the PHPSESSID should expire after logout, but as soon as we login again with the previous PHPSESSID through the burpsuite tool, then we are successfully logged into the web application which means the web application is vulnerable to session management vulnerability.
In this tutorial, we have covered all the topics from which you can get deeper information about broken authentication.