Input-Format-Depedent-XSS: Restrictions Are Your Best Friend!

Recently, I had a stubborn form where I attempted XSS in the free text fields, without success. Eventually, I also started looking at other input fields on the form that required stricter input formatting, such as phone number, SSN, address, etc.

Of course, the email field only accepts input containing an email address...! So, I tried an XSS payload containing a valid email, like:

<sCript>alert('burninatorsec@defcon.org')</scRipt>

And it works!

But why?

The validation logic is actually what is reflecting the XSS in the page. Therefore I wouldn't have been able to succeed without the input restriction! It didn't make XSS harder, it made it possible. Furthermore, automated vulnerability scanning tools that don't adjust their behavior to the expected input format based on business context won't find XSS issues like these, they will just dumbly try a bunch of standard payloads. My job is safe for another day.

How do these kind of vulnerabilities happen?

Likely the developer was playing fast and loose with regex, because it's clearly not matching in a way that forces a pattern exclusively (for example, maybe they are missing the "starts with"/"ends with" pattern matching characters). Or maybe they're not using a framework or library with built-in data formatting requirements. Just guessing, but that's the kind of mistake I would have made when I was a dev, and now I get to use it for hacking!

Also, consider that devs will often focus their time and energy on EITHER QA/business logic validation OR security validation, but not usually both. It's counterintuitive, but that's how restrictions can actually help hackers. 

So, at the risk of sounding too Sun-Tzu-Art-of-War: when you use your limitations to your advantage, then you have none.



 

SQL Injection & Manual Data Exfiltration (For When SQLMap Won't Work)

This is a new payload that I'm hoping to incorporate into SQLMap soon (here's the feature request).

Assume a field is vulnerable to error-based SQL injection. SQLMap did a good job mapping out the column names and table names, but couldn't return any data rows. Through some trial and error, it becomes clear I can use a convert error and JOIN to display some data one record at a time (since multiple records will not display). Unfortunately, the WHERE and TOP clauses weren't working, so I had to find another way to integrate through the data rows, so I used LEAD() and LAG(). Hurray, I've got some varchar values coming through!

targetsite.com/vulnerablepage.do?badfield=select LEAD(CoolKeys,0,0) OVER (ORDER BY CoolKeys DESC) from CoolTableName join OtherTable on ArbitraryField=AnotherArbitraryField ...etc.

That was a good start...we get a conversion error on the value, so we get the value displayed, i.e.

Conversion failed when converting the varchar value 's3cretKey' to data type int

However, there was one thing I still needed. I really wanted to chain this with a privilege escalation vulnerability I'd found earlier, and if I could get all the GUID user IDs, including the administrators, then I could become a higher privileged user.

The problem was the SQL injection wasn't returning the GUIDs in my injected SELECT statement. It was a more generic SQL error, which isn't helpful. But I found I could use CONCAT to force the conversion error to show it!

targetsite.com/vulnerablepage.do?badfield=select concat(LEAD(GUIDData,0,0) OVER (ORDER BY GUIDData DESC),'hey') from CoolTableName join OtherTable on ArbitraryField=AnotherArbitraryField

 
Now the error will show: [GUID value]hey! Yay, I'm admin!

TL;DR:

1.) Use LEAD and LAG for situations where one row must be returned (and WHERE or TOP 1 etc. isn't working)

 

2.) Use CONCAT to force conversion errors to display uniqueidentifier-type data values through conversion errors

This all applies to bug bounty programs where SQLMap is not allowed, or if that kind of traffic gets you blocked too often.

Filter Bypass for Open Redirect

Trying to add a redirect payload through a URL parameter (but it's just getting harmlessly tacked to the end of the domain)? Bypass by adding the same parameter twice. When the link is displayed on the page, the browser adds a comma and breaks up the pattern:

So, this fails:

whatever.com/cc?DestPage=/"><a%20href="badsite.com">

 

...because it redirects to whatever.com/badsite.com.

But, this succeeds, redirecting to badsite.com:

whatever.com/cc?DestPage=">&DestPage=<a%20href="badsite.com">

PS This also works for XSS payloads, though in this case, wouldn't require the double-parameter trick. It's probably more common for open redirects, but let me know!

 

 

ctrl + s to Escape Chrome Kiosk

Consider a tablet at a store kiosk where the owner wants to display one particular web page to users. They don't want the user to have access to any other programs or files on the tablet. In this case, they are running Chrome in a restricted mode, using this command:

 chrome.exe --kiosk "keepuseronthispage.com"

In theory, this is a restricted mode doesn't allow right-click context menu, doesn't show the browser address bar or the task bar, and keeps the user out of the system. So... how do we access the rest of the system? Well, if it's a Windows machine, as in this case, kiosk mode can easily be bypassed if the user presses ctrl + s.




Use the "save as" file explorer window that pops up to run cmd.exe. Now you have access to all the local resources.

NOTE: This doesn't seem to work on Mac OS...which is probably for the best.

Bypass Auth Lib

Recently I found a problem with an authentication library. The hyperlink the user clicks to access private content looks something like this:

https://www.authenticateme.com/auth.asp?url=http://www.privatecontent.com/1337

So normally, after the user enters their credentials on the auth.asp page, they are redirected to privatecontent.com/1337 ... or they could just go directly to that page, bypassing any security restrictions. They can then enumerate and access other content based on the formula of the URL.

Additionally, this qualifies as an open redirect, since an attacker could append their own attack server's address to "url=", then send the link to a victim, and then the attacker will receive the credentials passed through the authentication page.

Paywalls and Redirects

It is well known that paywalls can commonly be circumvented by editing the client side code so that the content is no longer hidden. But what about when that code is server side? Here is a quick "no tools" way of getting around certain kinds of paywalls.

Disclaimer: don't get around paywalls. It's rude. Pay content providers for content. Anyway... here is the idea. You are on a site with mixed paywall and non-paywall content. You're looking around trying use the typical methods: to find the element to delete or the flag to set to be able to see the content. You're comparing application logic for displaying the paywall vs non-paywall stuff. No luck. In my case, I am presented with this URL, which has a paywall error on the page:

awesome.com/pants

I wondered if maybe the content had been cached and I could view it that way with an "in site" search (in Google, "site:awesome.com/pants [OPTIONAL_SEARCH_TERM]"). Bingo! There are links like:

awesome.com/pants/pants01
awesome.com/pants/pants02

I am able to navigate to these pages and view the "pants" content. But what if I want to view "socks" content? Even though only the "pants" page was cached on Google, it's all I need, because this page happens to link to other pages behind the paywall. But what about the ones that don't have links? Well, since I have an example of the convention used in the URL page, using the root of the URL as a hint, I can craft any URL needed to access all the others as well. For example:

awesome.com/kneesocks

This probably means it has these behind the paywall:

awesome.com/kneesocks/kneesocks01
awesome.com/kneesocks/kneesocks02

And so it does! Now between the links on these pages and the formulaic predictable URL, I can navigate around the rest of the paywall. Additionally, a mistaken URL will very helpfully redirect if the last directory is correct:

awesome.com/pants/kneesocks03  >  [301 status error]  >  awesome.com/kneesocks/kneesocks03

Suggestion to the site for mitigating this risk: require authorization for the pages that need it, whether they are the redirect page or the old page.