Does just keeping secure and a strong password can really protect you? Today in this article we’ll learn, how an attacker analyzes 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 to Authentication
•  Broken Authentication and Session Management
• Sessions
• Cookies
• Impact of Broken Authentication
• Broken Authentication
  • Credential Stuffing
  • Insecure Web-Applications
    • Insecure Login forms
    • Logout management
  • Bypassing Forget Password Option
• Improper Session Management
  • Administrative Portal Login
  • Session Hijacking
    • Using the Browser’s Plugin
    • Using Burpsuite
  • Mitigation Steps

Introduction to Authentication

Authentication is the process of validating a user who is claiming to be a genuine one. Thus in a web-application, password plays a 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 passes it to the browser in the form of Cookie Session ID.

What is Broken Authentication & Session Management 

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 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.

 A website or application is vulnerable to Broken Authentication when:

• Username and password are easy to guess using fuzzing or brute force.
• Password Does not match Password complexity policy.
• Enumeration of username/password at the of Authentication failure response invalid username or an invalid password.

A website or application is vulnerable to Session Management when:

• Login credentials are not protected when stored and lacking hashing and salt.
• Transmission of username and password over an unencrypted channel such as HTTP
• Session ID exposes in URL.
• User session or authentication tokens are not timeouts after user logout.

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 is 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 die 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 is deleted only when they are on their expiration date or when a user shuts down the browser.

To know more about cookies and session management read from here

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.

Vulnerability Walkthrough to demonstrate Various Attack 

Until 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 login 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 tools 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.

Now it’s time to configure our attack!!

Switch to the Position tab and 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 new 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. Then 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 and at last click on Start Attack.

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.

Here, 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 a bee : bug.

Insecure Login Forms

As mentioned above, when login credential is stored without the proper security majors being used, just like without the addition of hashing or salt value with username and password at the location where it is stored, this could be lead to insecure login that could be considered as vulnerable to session management.

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 vulnerabilities, where the developers simply setup the hyperlinks of the logout page at the logout text without having any concern about the generated session and do not validate the weather the session ID is getting timeout or not once the user logout from the application. 

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 the 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.

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 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 (Attacker) in order to exploit this vulnerability. To install and setup WebGoat click here.

Note: Here at port 8080 the  Webgoat server is enabled for HTTP service and at port 9090 the webwolf is enabled for SMTP.

From the left-hand side, the panel selects 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 [email protected] as the registered email address.

From the above image, you can see that we got the response as “An email has been sending to [email protected]”

Now let’s surf the WebWolf’s webpage and enter the same credentials (Attack’s) 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 set up the new password.

Now it’s time to break and get into the victim’s account i.e.“tom’s account” who is my target and with the help of footprinting, I have identified his email ID. Back to the WebGoat server, we’ll write the tom’s email address as [email protected]. But this time we’ll capture the request in the burpsuite before sending it to the server.

As soon as we capture the “Post Request”, we’ll send it all to the repeater.

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, you can see that “An email has been send to [email protected]”. But this email has actually been sent 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 sends 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 “[email protected]” 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.

Woah!! We are redirected to a new “Reset your password” page, seems like we’re changing 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:

[email protected]
tomandjerry

Great!! We’ve successfully changed 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

Until 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 a 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 does not need to enter his credentials every time for every single page he requests for.

But the attacker sniffs the network and steal up these freshly generated session IDs before they were sent to the user. Now the attacker just needs to send these session ID’s to the web server, the 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 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 copying them into our clipboard, which can further be used in getting an authenticated access. 

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 by pasting the exported cookies into the Cookie Editor console.

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 fail 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 ids 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 favourite 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 and replace the session ID, and further will check its generated response.

From the above image, 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, username, password, session tokens in the most encrypted way where they stored.
2. Validate appropriate session timeout and invalidated during logout for session tokens.
3. The client’s or the Users should use multi-factor authentication and even follow-up with strong password policies in order to increase the password complexities.
4. Session ID’s should not be exposed in the URL.
5. Use the Encrypted channel for transmitting username and password to the server.

Author: Aarti Singh is a Researcher and Technical Writer at Hacking Articles an Information Security Consultant Social Media Lover and Gadgets. Contact here