Insistently Marketing Persistent XSS | Deadliest Web Attacks

http://deadliestwebattacks.com/2013/03/21/insistently-marketing-persistent-xss/

Insistently Marketing Persistent XSS

Want to make your site secure? Write secure code. Want to make it less secure? Add someone else's code to it. Even better, do it in the "cloud."

The last few HTML injection articles here demonstrated the reflected variant of the attack. The exploit appears within the immediate response to the request that contains the XSS payload. These kinds of attacks are also ephemeral because the exploit disappears once the victim browses away from the infected page. The attack must be re-delivered for every visit to the vulnerable page.

A persistent HTML injection is more insidious. The web site still reflects the payload into a page, but not necessarily in the immediate response to the request that delivered the payload. You have to find the payload, e.g. the friendly alert(), in some other area of the app. In many cases the payload only needs to be delivered once. Any subsequent visit to the page where it's reflected exposes the visitor to the exploit. This is very dangerous when the page has a one-to-many relationship where one attacker infects the page and many users visit the page via normal "safe" links that don't have an XSS payload.

Persistence comes in many guises and durations. Here's one that associates the persistence with a cookie.

Our example of the day decided to track users for marketing and advertising purposes. There's little reason to love user tracking (unless 95% of your revenue comes from it), but you might like it a little more if you could use it for HTML injection.

The hack starts off like any other reflected XSS test. Another day, another alert:

http://web.site/page.aspx?om=alert(9)

But the response contains nothing interesting. It didn't reflect any piece of the payload, not even in an HTML encoded or stripped version. And — spoiler alert — not in the following script block:

<script language="JavaScript" type="text/javascript">//<![CDATA[<!--/* [ads in the cloud] Variables */ s.prop4="quote"; s.events="event2"; s.pageName="quote1"; if(s.products) s.products = s.products.replace(/,$/,''); if(s.events) s.events = s.events.replace(/^,/,''); /****** DO NOT ALTER ANYTHING BELOW THIS LINE ! ******/ var s_code=s.t();if(s_code)document.write(s_code);//-->//]]></script>

But we're not at the point of nothing ventured, nothing gained. We're just at the point of nothing reflected, something might still be wrong.

So we poke around at some more links on the site. Just visiting them as any user might without injecting any new payloads, working under the assumption that the payload could have found a persistent lair to curl up in and wait for an unsuspecting victim.

Sure enough we find a reflection in an (apparently) unrelated link. Note that the payload has already been delivered. This request has no indicators of XSS:

http://web.site/wacky/archives/2012/cute_animal.aspx

We find the alert() nested inside a JavaScript variable where, sadly, it remains innocuous and unexploited. For reasons we don't care about, a comment warns us not to ALTER ANYTHING BELOW THIS LINE!

You don't have to shout. We'll just alter things above the line.

<script language="JavaScript" type="text/javascript">//<![CDATA[<!--/* [ads in the cloud] Variables */ s.prop17="alert(9)"; s.pageName="ar_2012_cute_animal"; if(s.products) s.products = s.products.replace(/,$/,''); if(s.events) s.events = s.events.replace(/^,/,''); /****** DO NOT ALTER ANYTHING BELOW THIS LINE ! ******/ var s_code=s.t();if(s_code)document.write(s_code);//-->//]]></script>

There are plenty of fun ways to inject into JavaScript string concatenation. We'll stick with the most obvious plus (+) operator. To do this we need to return to the original injection point and alter the payload (just don't touch ANYTHING BELOW THIS LINE!).

http://web.site/page.aspx?om="%2balert(9)%2b"

We head back to the cute_animal.aspx page to see how the payload fared. Before we can click to Show Page Source we're greeted with that happy hacker greeting, the friendly alert() window.

<script language="JavaScript" type="text/javascript">//<![CDATA[<!--/* [ads in the cloud] Variables */ s.prop17=""+alert(9)+""; s.pageName="ar_2012_cute_animal"; if(s.products) s.products = s.products.replace(/,$/,''); if(s.events) s.events = s.events.replace(/^,/,''); /****** DO NOT ALTER ANYTHING BELOW THIS LINE ! ******/ var s_code=s.t();if(s_code)document.write(s_code);//-->//]]></script>

After experimenting with a few variations on the request to the reflection point (the cute_animal.aspx page) we narrow the persistent carrier to a cookie value. The cookie is a long string of hexadecimal digits whose length and content does not change between requests. This is a good hint that it's some sort of UUID that points to a record in a data store that contains the XSS payload from the om variable. (The cookie's unchanging nature implies that the payload is not inserted into the cookie, encrypted or otherwise.) Get rid of the cookie and the alert no longer appears.

The cause appears to be string concatenation where the s.prop17 variable is assigned a value associated with the cookie. It's a common, basic, insecure design pattern.

So, we have a persistent HTML injection tied to a user-tracking cookie. A diminishing factor in this vuln's risk is that the effect is limited to individual visitors. It'd be nice it we could recommend getting rid of user tracking as the security solution, but the real issue is applying good software engineering practices when inserting client-side data into HTML. But we're not done with user tracking yet. There's this concept called privacy…

But that's a story for another day.

^ed