PENTEST TALES: Smuggling Blind XSS through an Admin Portal’s front door

“The User-Agent is your best friend!”

Summary:

Highly secure environments can be great, as they can make you work harder when it comes to trying to circumvent one or more obstacles. However, sometimes you reach a wall where you likely have none of the more common paths out in plain sight for you to take advantage of, so you slowly…

start...

to…

lose…

hope…

But… this was an Administrator login portal dashboard thingamajig, and Admin portals are wonderful because they provide all types of juicy treasures and goodies, as long as we can sneak our way in! Furthermore, exploitation vectors pertaining to Admin portals usually end up with a “High,” or “Critical” severity depending on the impact, so in the world of vulnerability disclosures and bug bounties, these types of findings can be top of the line.

But, after a solid amount of time with digging for sensitive information through directory brute-forcing, JavaScript file analysis, etc., I gave the application a thumbs up and went about my way…

Wait a second…

As I was going over and reviewing my target/assessment material the next day, I caught wind of my Gmail account blowing up. Eh, I’ll check that later I thought…

But, I glanced at the title of one of the e-mails, which contained wording related to “…Blind XSS Payload triggered on…”

NOTE: Blind XSS occurs when a web server saves malicious provided input that in turn gets executed in another part of the application, such as back end Administrator areas or something intended for internal only folks.

My Blind XSS payload was executed! And ah, yes, it’s something related to our good friend, the previously discussed Administrator portal. But what triggered this to execute, how was it done, and why did I get an e-mail notification? Let’s get into the juicy stuff…

What, why, who, how, where…huh? Okay, let’s rewind a bit…

Whenever I’m conducting any type of ethical hacking attempts against a target, I have an immediate set of custom “go to” things that I use. This can consist of tools, payloads, and/or specific out of the box approaches that I like to leverage.

With web applications, my trusty friend Burp Suite never leaves my side, and in this case, was instrumental with helping me get into this Admin portal.

Burp Suite has a “Match and Replace” option, which allows you to include a custom set of values that then get replaced automatically during the interception process. This area is very interesting, though I will only be covering what pertains to this finding.

We can add new rules here, or simply alter one of the predefined items. The following shows a similar example of how I set the rule to match a User-Agent value and then replace it with my provided value, in this case being a Blind XSS payload. Whenever this rule is enabled afterwards, any web requests proxied through Burp Suite will now contain a shiny new User-Agent value!

What’s going on in this payload?

The payload consists of the <script> src attribute, and is used to specify an external JavaScript file. The external domain hosting the JavaScript file is a custom domain associated with my own personal instance utilizing the “XSSHunter” tool. Whenever the payload executes, it phones back home to me and basically says, “Hey, here’s where I executed, here’s a screenshot of the page where I executed, and here’s some cookies associated with who executed me.” There’s a few ways in which the notification can be set up, though from the context of this scenario, it was to come directly to my e-mail.

Why did this payload work?

When fuzzing around the Admin Portal earlier on and uncovering a slew of parameters, I noticed errors being thrown whenever something obscure such as illegal characters were included as parameter values. The default errors here in simple terms were basically saying something along the lines of “Hey, there’s been an error. Please check the logs for more details…” etc.

It is not uncommon for User-Agent content to be stored in back end logs, as they can certainly be useful when it comes to teams troubleshooting errors. When this is coupled with lack of proper validation, sanitizing, filters, etc., it can open up a huge door leading to injection issues.

In my case, the payload was smuggled straight through the front door, directly to the off limits Admin area!

Sweet, now what!?

After checking out the details of what my trusty little XSS probe brought back, I located a delicious set of cookies pertaining to whoever executed this payload. In this case, it appeared to have been an Administrator account, judging by certain cookie names and the values they contained. At this point, I did not try any escalation/takeover paths due to having the user’s current cookies, and opted to report it due to the affected area being a back end Admin area.

After reporting this to the specific program owners, they were able to confirm the validity of this loophole, and stamped it with a high severity rating. A fix to the overall issue was rolled out within a few days.