Session fixation | Cookie injection leading to ATO Write-Up

There are numerous ways you can handle an authorization on your website. From session-based authentication to token-based authorization, any method you consider to use has to be properly configured or else the whole application might become prone to potential account takeovers.

In my case tho, although the target was horribly configured, it was not exploitable by itself. It had to be chained with other potential stuff to reach impact.

Lets call the main target I performed account takeover on weakauth.main.com .

Quite simply, the target was written in ASP.NET.

Upon first time visiting the website, you are issued a cookie called ASP.NET_SessionId which is totally unauthorized and unprivileged.

Now this cookie has 0 privileges.

This is where vulnerability comes in play: when I authenticate myself in the website, I’m not issued a new session cookie. That previous cookie of mine stays, Its just upgraded now.

This allows me to perform the attack called Session-Fixation, if I find the right follow-up to chain vulnerabilities together.

Session Fixation

Now what this attack is really about, is that I can simply set my cookie session for other users, and if they ever escalate their privileges by authenticating or authorizing, my session also gets upgraded.

Because the cookie session is living on both parties and its never renewed, anything happening to either side is applied to the session, from escalation to logging out.

Now in order to succeed in this attack you need to find some way to inject your session in victims browser. This is precisely called Session Fixation.

Second Vulnerability | Cookie injection

Wonderfully enough, I found an endpoint on optout.main.com which was used to create an opt-out cookie. How ever it took the cookie name from my client parameter and appended !disableClient to it. So a normal response would look like this:

However, since the parameter lacked sanitization, I was able to inject character ; , which precisely means I can evade the context and make my custom cookie in the scope of whole main.com, and turn all of the appended part to a useless attribute.

So a request with this parameter:

would have a response like this:

Notice how !disableClient is left out to a useless cookie attribute? This means we successfully created a custom cookie on whole main.com on victims browser.

Chaining

Now finally chaining the 2 issues which are not vulnerability by themselves, to reach an impact.

I think the walk-through should be pretty straight forward now:

3.[Victim] Opens the malicious URL. They now have a bad session attached to their browser.

4.[Victim] Opens https://weakauth.main.com/Login.aspx , selects “Click here to begin your application” to prompt for login page.

5.[Victim] After entering the user and password, Victim is redirected to their panel in https://weakauth.main.com/Panel.aspx.

6.[Attacker] Now if I visit the panel as the attacker, I can see my session is also upgraded and I have full access: https://weakauth.main.com/Panel.aspx

The website also had very high privilege panels, which also lacked proper cookie generation and were most likely prone to this attack.

This issue was triaged with a CVSS score of 5.9 .

I hope you enjoyed reading this. I’d appreciate if you like and share it.

My twitter: https://twitter.com/rampancist