Comprehensive Guide to Broken Authentication

Does just keeping a secure and a strong password can really protect you? Today in this article we’ll learn, how an attacker analyze and take over the user’s account that have been logged in inside some weakly authenticated web-application with an immune password.

Table of Content

·         Introduction

·         Sessions

·         Cookies

·         Impact of Broken Authentication

·         Broken Authentication

o   Credential Stuffing

o   Insecure Web-Applications

§  Insecure Login forms

§  Logout management

o   Bypassing Forget Password Option

·         Improper Session Management

o   Administrative Portal Login

o   Session Hijacking

§  Using Browser’s Plugin

§  Using Burpsuite

·         Mitigation Steps

Introduction

Authentication is the process of validating a user who is claiming to be a genuine one. Thus in a web-application, password plays the major role in the authentication phase. In order to get the desired access, the user have to enter his username and password, further these credentials are sent to the server for the authentication process. However the server checks them into its database and if found valid, it generates a session and pass it to the browser in the form of Cookie Session ID.

But what if an intruder bypasses this authentication process either by guessing up the username and passwords or even by capturing up an active session of any particular user. Thus this scenario is considered as Broken Authentication where the authentication and session management of the web-applications are often not implemented correctly, leading the attacker to gain an unauthorized access to the user’s data.

Form the above picture you can see that the attacker is trying to get into the web-application by the credential stuffing method, where he is having a bunch of breached passwords which thus in-turn helps him to gain an authenticated session.

In order to explore more, let’s take a deep dive and learn about the sessions and the cookies concepts.

Sessions

When a user made any changes in a web application like a sign in or sign out, the server does not know who that person is. In order to solve this issue, sessions were introduced, which holds the information of a single user that can be reused across several web pages over a particular web-application.

Example: login ID user name and password.

Therefore some code are generated with a unique identification number in the form of hash for that specific session which is a random string of 32 hexadecimal numbers such as 5f7dok65iif989fwrmn88er47gk834 and thus it is known as sessionID.

Cookies

A cookie is a small piece of data similar to the sessions, they are sent by the server to the browser. Thus this data is stored on the user’s computer while he/she is browsing. Cookies have a short time period due to their preset expiry date and time.

Cookies are classified into major categories but the most common one is –

Session Cookie:

These cookies dies when the browser is closed because they are stored in the browser’s temporary memory. They’re majorly used for the e-commerce websites so the user can continue browsing without losing what he put in his cart and finally able to checkout. The session cookie are deleted only when they are on their expiration date or when a user shuts down the bowser.

Impact of Broken Authentication

Broken Authentication is the vulnerability which allows the attacker to gain the user data without proper authentication. This vulnerability arises in the web application where the sessions are not properly sanitized. Therefore it stood as the second most critical vulnerability in the OWASP top10 having “a CVSS Score of 8.8”.

However the Broken Authentication vulnerability has been majorly reported under

1.       CWE- 287 Improper Authentication

2.       CWE-345 Insufficient Verification of Data Authenticity

3.       CWE-522 Insufficiently Protected Credentials

To learn more about the other CWE categories for Broken Authentication and Session Management click here.

Uptill now you might be clear with the concept of authentication and aware with the fact that how crucial the sessions are. So now it’s time to exploit and analyze these vulnerabilities over the most vulnerable platforms i.e. bWapp and WebGoat.

Credential Stuffing

During the major data breaches, it is easy for the attackers to grab a list of commonly used usernames and passwords. Thus using these different pairs, they are able to gain the actual user’s credential of a particular web-application. Credential stuffing somewhere also known as bruteforcing or fuzzing.

Therefore we’ll try to bypass this high security captcha login using one of the best web-fuzzing tool i.e. Burpsuite.

Boot in your burpsuite in order to capture the ongoing HTTP request, by setting up the proxy server at the localhost and enabling the intercept option in the proxy tab. 

As soon as you grab the request just send it directly to the intruder by a simple right click on the proxy tab or either by pressing Ctrl +I.

Now it’s time to configure our attack!!

As soon as you get the confirmation with the Host and the Port, just switch to the Position tab there right at the target tab.

Choose the Attack type to Cluster Bomb, further add up the attack position by simple clearing all the preset positions with the Clear $ button and adding the news positions with the Add $ button.

From the above image you can see that, I’ve set the attack position over the login and the password fields, where my dictionaries would work.

Here in the Payload section, we’ll be adding up our dictionaries.

Choose the Payload Set 1 and 2 simultaneously one after the other and include our lists in both of them by simply clicking on the Load button.

We’re almost done, now just click on the Attack button and wait for the response.

From the below image you can see that our attack has been started and there is a fluctuation in the length section and our lists are working in the way we want.

I’ve double clicked over the length section in order to check the lowest value first.

As soon as I choose the 48^th Request due to the only fluctuated value, I was able to see that the payload 1 and 2 with bee and bug inputs respectively are giving a successful login in the Response section.

Therefore I was able to get into the web-application by entering the credentials as bee : bug.

Insecure Login Forms

Many web developers tries to trick their clients by setting up the username and password into the html code with the font color as “white” at the username and password field only.

Let’s check whether this login form is having the same issue or not.

Simply right click anywhere on the form screen and choose View Page Source option.

As we analyze the HTML form code, I was able to determine the username and the password values as tonystark and I am Iron Man hidden with the white font.

Insecure Logout Management

This is one of the most common vulnerability, where the developers simply setup the hyperlinks of the logout page at the logout text without having any concern about the generated session.

I’ve set the “Choose your bug” option at “Broken Authentication –Logout Management”. From the below image you can see that as I’ve clicked on the OK option in the popped up confirmation field. Thus further I had been redirected to logout page.

Now let’s try to simply click on the back button.

Great!! We are back into the account again. That means we were just redirected to the new page but our session cookies were not expired yet.

Let’s check it out, how this all happens at the backend.

From the above image we can see that the developer had simply set ”ba_logout_1.php” as the Hypertext Reference to the “here” text.

Bypassing Forget Password Option

Forget Password is the most common feature of every web-application. The majority of applications use it, in order to send a security question or a reset password link to their users at their registered email addresses. But what, if we exploit this feature and change the credentials of the users without their concern or even without capturing anything from their browsers?

Let’s try how we can exploit it!!

I’ve logged in into the WebGoat’s platform by creating a new user account as hackingarticles in order to exploit this vulnerability. To install and setup WebGoat click here.

From the left-hand side panel select Broken Authentication following with Password Reset field.

Thus selecting the 6^th option from the top, we’ll be redirected to our desired task.

Dragging to the bottom we’ll find the Account Access form, below there we can find a “forgot password” option.

As soon as we click on it we’ll be redirected to the “Forgot Your Password” page.

Now, it’s time to start our attack.

I’ve entered hackingarticles@webgoat-cloud.org as the desired email address.

Note:

You can enter any domain rather than webgoat-cloud.org, but the name should be the one you set as the username for your account.

From the above image you can see that we got the response as “An email has been send to hackingarticles@webgoat-cloud.org”

Now let’s surf the WebWolf’s webpage and enter the same credentials that you have used while logging into WebGoat

http://192.168.0.11:9090/login

From the below image, you can see that I’ve received an email with a reset link in order to setup the new password.

Now it’s time to break and get into the victim’s account i.e.“tom’s account”.

Back to the WebGoat server we’ll write the tom’s email address as tom@webgoat-cloud.org. But this time we’ll capture the request before sending it to the server i.e. tune in you burpsuite by enabling up the proxy and the intercept option.

As soon as we capture the “Post Request”, we’ll send it all to the repeater, by clicking on the right hand side and selecting the Send to Repeater option.

Now we’ll manipulate the request and send it to our server i.e. the server we set at 192.168.0.11:9090.

From the above image over the right hand side in the window you can see that, “An email has been send to tom@webgoat-cloud.org”. But this email has actually been send over our WebWolf server.

Let’s get back to our “WebWolf” application and check what we have received as in our Incoming Request.

From the above image you can see that I’ve successfully manipulated the WebGoat server, which send the request over my account.

Copy the unique Id as highlighted, which we will use in our future case.

We’re now almost done, go back to the inbox of “hackingarticles@webgoat-cloud.org” and open that reset link that we got earlier.

From the above image you can see that, in the URL section, we’re having a unique ID here too.

Let’s change this unique ID with the one we copied earlier.

Wooahh!! We are redirected to a new “Reset your password” page, seems like we’re changing the Tom’s credentials.

I’ve now set the password here as “tomandjerry”. And fired the “SAVE” button.

Let’s check whether we’re able to change the tom’s credentials or not.

Go back to the WebGoat web-application and select the option to “Account Access” and enter the following credentials:

tom@webgoat-cloud.org

tomandjerry

Great!! We’ve successfully changed the Tom’s password just with his email account, without knowing who is tom.

Improper Administrative Login

Administrative logins are considered as one of the most important and the most crucial vulnerability, it occurs due to unsanitized session generated from the server’s end.

Let’s try to exploit this vulnerability and get into the web-application with the administrative privileges.

Boot back into your bWapp server and select “Session Management – Administrative Portals” in the “Choose Your Bug” option keeping the security at low.

From the above image you can see that after the “.php?” we’ve got “admin=0”, let’s manipulate this but “admin=1” and check out the grabbed result.

Simple!! We’ve unlocked this page with the administrative rights.

Let’s try to increase up the level and set it to “medium”, now checking the same in the URL, we won’t be able to find anything. So is this vulnerability patched?

Wait, let’s try to capture its cookies and analyze them.

Look there it is, the flaw is still the same, but this time it is in the cookies. So now let’s check whether our manipulation will work or not?

I’ve again manipulated the “admin=0” to “admin=1”

From the below image you can see that we’ve successfully unlocked the webpage again with some simple manipulations.

Session Hijacking

Uptill now we all are aware with the fact that for every different user there is a unique session ID generated, thus when an attacker sniffs the network traffic via man-in-the-middle attack or via Cross Site Scripting and thereby steals up the session ID or the session tokens of the legitimate user’s authenticated session in order to get an unauthorized login. This methodology is known as Session Hijacking.

The idea about session hijacking would be more clear from this image.

Here the user enters his credentials into the web-application, thus application sends them to the server for authentication. Therefore as soon as the credentials were found valid, the server generates a session and shares it to the browser, such that the user do not need to enter his credentials everytime for every single page he requests for.

But the attacker sniffs the network and steal up these freshly generated session IDs before they were send to the user. Now the attacker just need to send these session ID’s to the web server, server tries to match them with its database stored session ID. If they both are matched thus the server servers the attacker will HTTP 200 OK reply and the attacker will get a successful access without submitting proper Identification.

So it’s time to play with these sessions and hijack some accounts.

Session Hijacking using Browser’s extensions

Isn’t it great if you could simply get into other’s account without bruteforcing or resetting the password or by not finding any flaws in the web-application?

In order to perform all this, we’ll be using a simple browser extension i.e. “Cookie Editor”, which enable us to import and export the browser generated cookies by simply coping them into our clipboard, which can further be used in getting an authenticated access. You can install this extension from here.

Let’s Start!!

From the below image you can see that I’m having this Cookie Editor enabled in my browser and I’ve logged in inside bWapp as “Hackingarticles : 123”, now from the options provided I’ll click on the “Export” button in order to export all the cookies of this particular session.

Since I’ve successfully exported the user’s cookies now it’s time to import them into the attacker’s machine.

From the below image you can see that, the user “bee” is active with an enabled cookie editor extension.

Now let’s try to import these cookies into the attacker’s browser.

As I hit the “enter” button the exported cookies of the user hackingarticles will be imported directly into the browser where the user bee  resides.

So everything is up now, just simply refresh the browser and there it goes. From the below image you can see that we’ve successfully captured the hackingarticles session with just 3 clicks.

Session ID exposure in URL

Many times the developers fails to manage the privacy of the web-applications by leaving some basic flaws such as disclosing the session ID in the URLs, which allows the attacker to steal these session id’s by simply monitoring up the network and manipulate them in order to exploit the authenticated user to compromise his account.

For this exploitation, we’ll be using the bWAPP, selecting up the “Choose your bug” option to “Session Management – Session ID in URL” and setting the security level to “low”.

From the above image you can see that the “PHPSESSID=” of the user “Hackingarticles” is displayed into the browser’s URL, just copy the same into a text file.

Similarly we’ll copy the “PHPSESSID=” from the user “Bee” and paste it into the same text file.

Form the above image you can see that both these session ID’s are different.

Thus, it’s time to exploit this vulnerability.

In the Bee’s account we’ll go to the “Change Password” option, and will try to change the password.

But before hitting up the “change” button, we’ll run our favorite tool “burpsuite” and capture the ongoing HTTP Request.

From the below image you can see that we’ve successfully captured the HTTP request, and there we are again presented with the “PHPSESSID”.

Now we’ll be sharing this captured request to the repeater by simply doing a right click and choosing the option as “Send to repeater”, and further will check its generated response.

Time to manipulate this session ID with the one we have captured form the “Hackingarticles” user

From the above image, in the response tab over the right hand side of the window you can see that the user have been changed from bee to Hackingarticles as we hit the Send button.

We’re almost there, just change the “PHPSESSID=” with the one that we’ve used in our previous step, in the Proxy tab.

As soon as I hit the Forward button, I will be redirected to a new web page.

Great!! We are back into Hackingarticles account by simply manipulating up the SessionID.

Mitigation Steps

1.       Developers should setup the Session ID’s in the most encrypted way they can and even with an appropriate session timeout.

2.       The client’s or the Users should use multi-factor authentication and even follow-up with the strong password policies in order to increase the password complexities.

3.       Session ID’s should not be stored in URL’s.

4.       The user’s should change their passwords on a regular basis.