Found Stored Cross-Site Scripting — What’s Next? — Privilege Escalation like a Boss :D

Harsh Bothra
May 19 · 4 min read

Cross-site scripting is one of the prominent attacks of all time. It is still being exploited in the wild. Cross-site scripting is always not about popping an alert box with some random crazy string or domain or cookies. Cross-site scripting vulnerabilities can be chained with other low hanging issues to make a critical impact. It is an obvious impact people write in their report an attacker can steal session cookies of victim user but the question here is how many people are actually exploiting it? usually with a stored XSS, the priority is “medium to high” but if you can actually steal session cookies, you can take over “Victim Session” and do what not making severity as “critical”.

The objective of writing this post is to explain the importance of cross-site scripting, chaining it with other attacks, and leveraging higher profits with low hanging fruits.

Hello fellow Hacker & Bounty Hunters, in this post, I will talk about how I was able to perform privilege escalation to Admin Account with a simple stored cross-site scripting chained with some low hanging fruits.


In a nutshell, the story talks about -

  • Quick Overview of XSS and Stored XSS

Cross-Site Scripting (XSS) is exploited in the wild, even in present. There are multiple scenarios and types of XSS but to stick with this post, let’s quickly understand what Stored XSS is.

When an application accepts user-supplied input as-is, allowing a user to input malicious javascript code which upon execution may lead to serious issues such as stealing session cookies, redirecting users to the attacker-controlled website and whatnot. In the case of Stored XSS, the javascript code stays in the application and whenever an interaction with code happens, the action of code is performed.

For example: Suppose there is a user profile on a community website. An attacker can inject malicious code in the description which is available for public view. Now, whenever a normal user visits the attacker’s profile, the code in description gets executed.


Recently, I was working on a private program that has the same functionality as above where the application was vulnerable to Stored Cross-Site Scripting in the Description field of user’s profile. Let’s call the application “www.target.com”

The usual flow of the application is:

  1. The Admin User can add multiple users with restricted roles.

I started with performing the stored XSS and reported it via Bugcrowd. The next day, when I was testing the application again, something struck in my mind and I was like, I want to exploit XSS in real-time for more fun.

Now, I wanted to increase the impact even further, so I started looking out some other ways to chain the vulnerability. The XSS was already a non-self XSS (Self XSS is one where a user has to input the code himself in order to gain execution). I checked cookies for the presence of “secure and httpOnly flags”.

The cookies having these flags set are not retrieved from a typical XSS execution and usually, the session cookies are set with these flags as true. Due to this the impact of XSS is not actually taking over session by stealing session cookies.

Cool. So now we have a Stored XSS and Insecure Cookies. So I used a simple Cookie Grabber payload which redirects cookies to a remote server.

So Far we have → A Perfect Session Hijacking Method.

Now, I logged in with Admin Account and navigated to “People’s Directory”. As soon as I visited, I got the session cookies of “Admin User” on my Remote Server.

Further, I used the Session Cookies to gain access to the session of “Admin”. I went to “Users” and changed my attacker user’s role to “Admin”.

Now, the lower privileged user has complete access as Admin. Just for fun (my test accounts only), I went ahead and removed the Original Admin from the Attacker’s account.

Initial Severity when Reported— High (p2)

Updated Severity after Exploitation — Critical (p1) + Bonus (For Report)


Takeaways

  • Always map the functionalities of an application before starting to hunt bugs, it helps to be systematic.

InfoSec Write-ups

A collection of write-ups from the best hackers in the…

Harsh Bothra

Written by

Security Engineer | Bugcrowd Top 200 | Synack Red Teamer | Bug Hunter | Author | Occasional Speaker | Learner | Poet | Twitter — @harshbothra_

InfoSec Write-ups

A collection of write-ups from the best hackers in the world on topics ranging from bug bounties and CTFs to vulnhub machines, hardware challenges and real life encounters. In a nutshell, we are the largest InfoSec publication on Medium. Maintained by Hackrew

Harsh Bothra

Written by

Security Engineer | Bugcrowd Top 200 | Synack Red Teamer | Bug Hunter | Author | Occasional Speaker | Learner | Poet | Twitter — @harshbothra_

InfoSec Write-ups

A collection of write-ups from the best hackers in the world on topics ranging from bug bounties and CTFs to vulnhub machines, hardware challenges and real life encounters. In a nutshell, we are the largest InfoSec publication on Medium. Maintained by Hackrew

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store