Paid Advertising
web application security lab

Archive for the 'XSS' Category

MitM DNS Rebinding SSL/TLS Wildcards and XSS

Sunday, August 22nd, 2010

27 posts left…

This was one of the more complex issues Josh Sokol and I talked about during our presentation at Blackhat. Let’s say there’s an SSL/TLS protected website ( that an attacker knows that the victim is using. The attacker is a MitM but let’s say that has no security flaws in it whatsoever. Let’s also say that there’s another subdomain called that has the following attributes: It has no important information on it (otherwise the attacker would be content with attacking it instead), it’s vulnerable to XSS, it doesn’t care about host headers and uses a wildcard cert for * How can an attacker use that to their advantage?

The victim requests the IP for for which the attacker modifies the responding DNS TTL to 1 sec (and all subsequent DNS traffic to that domain). The victim logs into (gets cookie). Doing login detection can help determine that the user is authenticated but it’s important that the attack doesn’t start before this, otherwise the attack will fail.

The attacker firewalls off the IP to and forces user to the XSS URL at:’XSS’)%20a (notice that the hostname is wrong as it should be because that is where the XSS lives). Note that this WAS a real XSS in mxr, but has been fixed, and to make it work it would require the user to mouse over it, so you’d have to do some clickjacking or something, but let’s just pretend that all wasn’t a problem, and/or that there was an easier XSS.

The victim requests the IP for again but this time the attacker responds to the DNS request (with 1 second TTL) with the IP address of (not addons). The user connects to the IP address sending the wrong host header - the reason this works is because the wildcard SSL/TLS cert allows for any domain and the website doesn’t care about host headers. The victim runs the XSS in context of even though they’re on the IP. That sounds bad (maybe useful for phishing) but there’s worse the attacker can do.

The attacker can give up if doesnít use HTTPOnly cookies because the attacker can just steal the cookie from JavaScript space. But let’s assume that addons has no flaws in it, including how it sets cookies. In that case the attacker just rebinds again. For lack of a better term we called this “double DNS rebinding.”

The attacker firewalls off IP for and un-firewalls off the IP. The victimís browser re-binds and requests DNS for again. The attacker delivers the IP for The victimís cookie is sent to and the JavaScript is now in context of The victim runs BeEf shell back to attacker, which allows the attacker to see the contents of the user’s account and interact as if they were the user.

We talked with a few people in various places about how likely this is, and although it worked on one of the two sites we checked we think the likelihood that it will work on SSL/TLS enabled sites is pretty low. It has to be wild card, has to have HTTP Response splitting/XSS, etc… and has to ignore the host header. We guesstimate that it’s probably between 2-4% of SSL/TLS protected sites that would be affected by this, although, in reality there’s not a lot of risk here because this has a lot of moving parts - there are certainly easier exploits out there. But the interesting part is this is yet another reason that all sub domains should be considered in scope when you’re talking about something sensitive sitting behind authentication beyond just breaking in and stealing the cert outright.

Incidentally when I told the Mozilla guys about this, they said, “Why would we have checked for XSS in mxr? There’s nothing important on there… It’s all public information.” followed by, “Well, it’ll be fun checking for XSS on all our sub domains now.” That’s a good idea anyway for phishing, but checking for host headers is an easier short-cut in the short term. I wouldn’t worry about this attack, because it’s unlikely, but it was interesting coming up with the use case.

Flash Camera and Mic Remember Function and XSS

Sunday, July 18th, 2010

39 more posts left…

Just a quick post as I head into the ramp up to Blackhat where I won’t be writing posts. Jeremiah and I spent a lot of time trying to break the Flash settings manager a few years back but one thing that I never mentioned was the way in which Flash’s settings are very often scoped to the domain rather than the app. Although currently allowing Flash access to camera and microphone isn’t all that common, if it ever did become common using XSS would be a pretty interesting tactic. Once access is allowed and remembered, an XSS included object could theoretically end up with the same privileges.

Clearly XSS is bad in of itself, but once settings are permanently remembered, even on a site that has no other sensitive information on it (a free video-game site for instance) something like this could allow an attacker to do some nasty spying. In general applications should never allow access to camera and microphone permanently by default. Thankfully, I don’t think there are a lot of apps out there that request mic and/or camera access so the attack surface may be small. But if that were to change I’m sure if an attacker were creative they could combine CSS history hacking + hidden iframe + XSS + camera and microphone app to spy on quite a number of people who had selected the “Remember” option.

The nice thing about this attack is if it fails it doesn’t create a modal dialog alerting the user to the fact that they were under attack (one of the many perils of not using modal dialogs). So the moral of the story is even if your app contains no sensitive data, you need to be extremely careful of XSS. Oh, yeah and Flash may want to allow the web sites in question to remove the “Remember” function from their apps in future versions.

Just Another Day at

Friday, April 16th, 2010

I don’t think I need to introduce this email, I think it speaks for itself:

Valued Road Runner Business Class Customer,

This email is in regards to the Time Warner (Road Runner) account for the following location


The Road Runner Abuse Control Department has received a complaint of network abuse originating from a computer connected to your cable modem. We recognize that most Internet abuse complaints are the result of computers infected with viruses/worms or compromised by a trojan horse( a.k.a. “trojan” for short). Trojans allow malicious third parties to gain access to your system(s) for the purpose of using your Internet connection to intentionally commit the abuse in question. The abuse commonly comes in the form of either unsolicited email ( a.k.a. “spam”) or port scanning (connection attempts to other systems across the Internet for the purpose of finding vulnerable systems to infect or exploit). However, if not addressed in a timely manner, your machine(s) potentially may be used for other more illegal activities

A portion of the complaint we have received is copied below for your review:

|date |id |virusname |ip
|domain |Url|
|2010-04-14 02:20:04 CEST |514019 |unknown_html_RFI
| | |


If your recognize this activity and it was intentionally sent, you may be in violation of our Acceptable Use Policy (AUP) and it’s important that you contact us immediately to discuss. If you do not recognize this, you likely have a compromised or infected system connected to your cable modem and will need to take action to clean and secure all Internet connected-computers as soon as possible. We take these complaints very seriously and further substantiated complaints could, at some point, require us to disable your cable modem in an effort to protect the integrity of our network. We obviously have no desire to interfere with your ability to conduct business and would prefer to not take such action, so please pursue whatever measures are necessary (up to and including the formatting of hard drives and/or assistance from a third party IT professional) to correct the problem with due urgency.

If it would be helpful, Road Runner does offer free anti-virus and firewall software for commercial use. You will need your Road Runner account information to register the software, so you may need to contact your local Time Warner office for assistance. For more information, please visit the following link:

Additionally, we have a suggested course of action on our Website, but please be aware that it is intended for use by residential customers to clean a single computer and may not be feasible for use in a commercial environment. Moreover, some of the suggested software is licensed for personal use only. We cannot accept responsibility for compliance with software licenses, so please be aware of rules and restrictions related to the installation and use of any applications suggested. If interested in this course of action, please visit the following link:

http://www.rrsecurity-abuse .com

If you have a network connected via a router, you may be able to view the router logs, looking for either a large amount of email activity or the port scanning activity specified above. This may indicate which computer is the offending system and thus help you simplify the solution.

The corrective action taken is entirely your responsibility. We are merely making contact to alert you to the problem in an effort to both protect our network and enforce our policies. But we ask that you do take corrective action as soon as possible and contact us to advise, preferably by simply replying to this email. Also feel free to contact us with any questions you have regarding this issue.

Thank You,
Time Warner Cable (Road Runner) Abuse Control, Regional Office

I didn’t realize 2 lines of completely benign JavaScript that can be included on websites is now considered abusive. I can’t wait until someone ads Google Adsense as unknown_html_RFI. If you know who submitted this, please smack them upside the head for me and then sit them down and help them find a job that doesn’t require a keyboard. kthanksbye.

MalaRIA Malicious RIA Proxy

Tuesday, April 6th, 2010

I got an email from Erlend Oftedal about a new tool he’s created called MalaRIA. The tool uses weak crossdomain.xml and clientaccesspolicy.xml (so both Flash and Silverlight) to allow a piece of code that resides on his server to use the client’s machine as a proxy to read information off of other websites that are protected in other ways. So think of it like an RIA version of BeEF.

You can read his blog post here or if you’re the visual type you can check out his movie here. We often talk about why poorly written crossdomain.xml files are dangerous, but I think this puts the last nail in that coffin. Yes, it’s dangerous. For real. Incidentally there is no reason you couldn’t deliver a MalaRIA payload over BeEF as well, if you wanted the best of both worlds. Nice job by Erlend!

Update: code available here.

Facebook Patents Social Feeds and I Patent XSS

Friday, February 26th, 2010

In honor of the USPO’s decision to allow Facebook’s patent for social feeds I decided to patent XSS. Please pay up. You know who you are. Thank you.

Google Buzz Security Flaw

Tuesday, February 16th, 2010

Speaking of Google, I got an email from TrainReq (the same fellow who allegedly hacked Miley Cyrus for those who don’t keep up to date on your tween idols). The email was regarding an exploit against Google Buzz. It’s yet another example of bad input validation/output encoding by your favorite advertising overlords at Google. As you can see, nothing up my sleeves:

There’s four things of note here. Firstly it’s on Google’s domain, not some other domain like Google Gadgets or something. So yes, it’s bad for phishing and for cookies. Secondly, it’s over SSL/TLS (so no one should be able to see what’s going on, right?). Third, it could be used to hijack Google Buzz - as if anyone is using that product (or at least you shouldn’t be). And lastly isn’t it ironic that Google is asking to know where I am on the very same page that’s being compromised? Why on earth does Google think its systems are secure enough to trust them with that kind of sensitive information? Yes, bad guys can figure out where you’re located if you allow that function. Chinese dissidents beware! But if you have something to hide, you must be a bad guy, right, Eric?

Live Labs Web Sandbox

Tuesday, November 3rd, 2009

This post has been sitting in my to-post-about file for ages. I don’t know why it took me this long since thankfully, it’s one of the few things that I don’t actually have to research to post about (which is rare for me, actually). Anyway, almost exactly a year ago the Microsoft Live Labs group came to me and asked me to check out their web sandbox. Unlike Content Restrictions which is browser specific and still not available publicly, Live Labs tries to solve the problem of allowing rich user content by way of an API that blocks all known bad inputs.

It was written, in large part, by Scott Isaacs, who was one of the original guys who worked on the JavaScript engine within IE - so he knows what’s he’s talking about. The upside is that I wasn’t able (in the admittedly small amount of time I looked at it) to get around the filter. It may be possible to do, especially as technology changes, but it certainly wasn’t straight forward. I’m sure the Live Labs team would love feedback if someone was able to. The down side is that this is an API that you must send your data through. So it’s not on-page entirely, as it must go through a filter that they’ve developed server-side. If you can get around that one barrier, it’s a pretty slick little tool. I’m sure they’d appreciate feedback.

Porn, CSS History Hacking, User Recon and Blackmail

Wednesday, October 21st, 2009

Every once in a while it becomes clear that there is a nice convergence of technologies and of the ecosystem itself where it may be possible to divine the future through the tea leaves. I stumbled across a page that shows how you can measure how many of your visitors look at porn using the CSS History hack. Now let’s take a step back. This is the second time I’ve seen the CSS history hack used in a production environment in just a few weeks, and never before. Two completely different applications (one for blocking Torrent users and this one, presumably just for fun). Two in a few weeks… statistically irrelevant possibly, but maybe it’s also pointing towards a new convergence of interest in this relatively old technique.

Now let’s take some of the stuff that Jabra and I (and others throughout the last several years) have been working on to actually get usernames and even people’s full real names from computers (here and here). Now what if you knew that Mr. Conservative Republican Congressman from a bible belt constituency was visiting a gay porn site? Suddenly something as simple as a few de-cloaking hacks turns into a perfect way to blackmail someone. I’m not saying it absolutely will happen, I’m just saying that we now have enough tools at our disposal and there is enough interest converging towards anti-privacy that it wouldn’t take much to turn it into a viable weapon against prominent individuals. The only trick is surfacing the JavaScript payload to the right demographic. XSS anyone?

Call for Input on Content Security Policy

Wednesday, October 14th, 2009

For those of you who have been following the much anticipated Content Security Policy - you’ll be excited to know it’s currently available for early preview. The guys at Mozilla have a blog post explaining the details of where Content Security Policy is and asking for input. As you’d expect it’s not as full featured as it will probably end up being when it finally gets released, but if you want a chance to tell Mozilla what you think, this is the place to go.

They also include a demo page so that you don’t have to do your own development, you can just try it out right on their site. The demo page can be found here. For anyone interested in solving XSS issues on sites that need to allow it by policy (because of user demand), this is something you should definitely look into. Come to think of it, user generated HTML kind of reminds me of this picture. If it seems like a bad idea, it probably is - but maybe we can make a bad idea worth it after all:

JavaScript Protocol Comment Newline Injection

Wednesday, October 14th, 2009

I got an email from MaXe describing a way to inject JavaScript protocol directives in such a way, that they got around a rather stupid filter that looks for :// (naturally limiting you to things like http:// https:// ftp:// and the like:

Basically when researching this vulnerability I found out a “new” way: (at least in my little world)

Basically some forum applications and such checks url inputs for ://, just like vBulletin did before the patch so after some time I came up with javascript:// ..

Which wouldn’t really do anything, but if you apply “new line” or “carriage return” (%0a or %0d) to the url then you have all the power in the world.

So basically javascript://%0A is “cancelling” the comment (actually the browser interprets it as a new line just as described in my blog) and there by making f.ex. alert(0) possible.

javascript://alert(0) wouldn’t work of course since alert(0) is commented out.

javascript://%0Aalert(0) works because alert(0) is placed on a new line!

Pseudo example:
// %0A ( \n aka new line )

I know it looks so simple and anyone could have come up with that, but I haven’t seen it yet anywhere on the net and it made my day.

Pretty clever filter evasion there. Easy enough to patch, of course, but just another great example of how people’s mis-understanding of the protocol and languages they are attempting to thwart works against them. Chalk this up to another blacklist that shouldn’t exist.