This is perhaps one of the weirdest vectors I’ve come across. It took me a while to figure out why this was happening, but after some time it became clear. SystemOfAHack sent me this vector a few days ago, but I was unable to get all the peices put together until now. MySpace allows users to enter HTML as we all know. But due to an open ended div tag and overwriting a class with a set id that MySpace uses, SystemOfAHack was able to execute XSS.

The part in bold is what he was able to inject and you can see what it does to the surrounding code:

<div class=x=x"+setTimeout('alert(/xss/)',0)+"; kill="<br>
…
<DIV style="width:80px;height:20px;" ID="UserDataNode0" CLASS="DataPoint=OnlineNow;UserID=71505468;"></div>

After rendering the page the DOM now looks like this:

<div kill="<br>
…
<DIV style=" width:80px;height:20px="" id="UserDataNode0″"class="x=x"+setTimeout('alert(/xss/)',0)+";"\</div>

Then if you look at http://x.myspace.com/js/myspaceJS024.js in the _OnlineNowNodeParser_locateNodes() function you can see that it does an eval on the contents of the class, which now have been overwritten by your vector. Verrrry tricky. I love this kind of thing.

There’s a pretty interesting writeup on Tod Allen’s website about how Hive is vulnerable to XSS. The interesting part to me was how the site actually asked the user to upload code. Ahhh, the information age. Upload whatever you want! The sky is the limit! Of course that policy has risks like credential theft, phishing, cross site request forgeries, etc… Same old story, different site.

Again, there’s that interesting trade off of which sites are useful to people and which sites are secure. If the customers demand to be able to upload JavaScript, we have a big problem. Over the last few days that thread on sla.ckers.org has been brewing on how to allow full HTML with all it’s features without allowing JavaScript. But let’s take that problem one step further and allow JavaScript but no XSS. There’s a real problem for you.

Allowing HTML is the mantra of consumer friendly web applications. The more rich the consumer experience the more engaged they get and the more they can feel like it’s home to them. Over the last few days there has been a really interesting thread evolving stemming from an open source HTML cleanser. SirNotAppearingOnThisForum posted a sample script that he has been working on for the last few days, that attempts to allow HTML but disallow XSS.

After finding some of the more obvious holes, it started getting more and more interesting (especially as it reached the second page of the thread). The latest hole is actually probably one of the best examples of why regex and blacklisting in general is hard. Not just because HTML is flexible but because rendering engines are ultra complex:

<IMG src="http://ha.ckers.org/" style"="style="a
/onerror=alert(String.fromCharCode(88,83,83))//" &gt;`&gt

At first blush this doesn’t look like it should work. Firstly, there is a character immediately before the onerror event handler (although this is ignored). But most importantly the onerror event handler is technically encapsulated by quotes. Yet in Internet Explorer this works. The flexibility of the rendering engines provides a uniquely complex problem that I’ve been talking about for over a year. This is just a particularly good example of why something that should clearly be encapsulated still manages to cause an XSS vector.

Thanks again to our good old friend Turing and his halting problem, stripping XSS out of HTML is hard. Sure you could block everything malicious pretty easily, as others have shown, but that’s a very different problem and much easier solved.

Legislation is probably one of the least sexy parts of what we all work on, but I had a thought a while back that I never managed to circle back on. I used to work for a mega-company doing anti-phishing stuff (among lots of other tasks) and one day I decided to look into anti-phishing from a legal perspective. I never followed through with it, but this is a topic that I think deserves some debate, as I haven’t seen a lot of people talking about this, or sponsoring legislation I think has a snowballs chance in hell of helping.

I was doing an interview with InformationWeek today about anti-phishing (btw, any phishers reading this, if you are interested, they would like to have an interview with you - contact me and I’ll get you in touch with them). One of the questions that was asked (and is always asked every time I talk to high level people about this) is what people can do about it. I started down the same old path I always go down, patch up, use modern browsers with anti-phishing built in, blah blah. I hated the sound of my own voice. If you were to take the average IQ of the internet population, I doubt it would be higher than 90-95 at best. There is no way people reading that article are the target segment of the Internet.

If you take that to the next logical step, the people who need this help the most are also the least likely to know how to fix those issues or keep themselves safe. Taking it the next logical step there is no way for the average consumer to protect themselves. So who is it up to? To me it seems like it should be up to the people who actually do know how to fix these issues.

I’m not one of those people who is super into having laws dictate our lives, but this seems like an interesting idea. Current anti-phishing laws only apply to countries that have extradition treaties with us, and since when do phishers care about that anyway? What if we turned the law around and pointed it at the people who actually do know how to fix these issues for consumers - the ISPs? What if we made a law that said that ISPs must make a reasonable effort to subscribe to anti-phishing lists and they must shut down access to websites that have known phishing holes in them. Failure to do so could result in fines, and further, if a consumer is actually phished, the ISP is liable.

I’ve already talked to large ISPs who are using OpenDNS, but that’s not cutting it. OpenDNS only applies to sites that are linked to using a hostname, and many phishing sites use only IP addresses. So yes, it would painful for ISPs. Yes, it would extra cost. Yes, it would be annoying for researchers (maybe they have to call to get sites turned back on for them). Yes, it could cause DoS for websites that are caught as false positives, or virtual hosts on the same IP. All valid points, but none of them seem worth it to spend another billion dollars this year of Internet consumer’s money to finance the phishing market. Comments?

This morning Legionnaire sent me an email to a post that I thought was worth posting in case anyone else hadn’t seen it. Google is indexing blacklists for it’s anti-phishing technology, but in doing so is stealing usernames and passwords. Bummer! As if it isn’t hard enough to get people to adopt security now people can claim that Google’s built in security is spyware too (not that web accelerator isn’t spyware, but you get my drift).

There is a picture of this issue over on Finjan’s website that shows the accidental logging of the user’s credentials. You can see how Google is doing it, and it’s kinda scary. And the worst part is there really is no good way to insure that they aren’t in there other than either not allowing anything with a username/password pair in the blacklist (which could be used against them) or by trying to strip them out (which again, could be used against them). In these cases I doubt the phishers did anything special with those sites, but that’s not to say they couldn’t. Thanks for the link Legionnaire!

Jeremiah and I have been talking the last few days about some code he was developing to attempt to stop large scale XSS worms. As a result of his research he came up with a few experimental code snippets for Firefox. Very interesting stuff. It shows how JavaScript can be used to protect itself as sort of a defense in depth strategy for when your inline XSS filters fail you, or when your website (like MySpace) is eternally riddled with XSS holes due to having to use HTML

Jeremiah lists a few words of caution when using this code, and I’d like to add one to the list. The mhtml vulnerability is still out there and using it can easily circumvent this, by including an iframe to a remote site with this malicious code. In Jeremiah’s words, “everything breaks down completely with [browser vulnerabilities]”. He’s exactly right. So experimental, yes, neato, yes. I’m sure there is lots more research to be done, and I’d be curious to hear of anyone able to undefine his __defineGetter__ functions.

ntp published an interesting conversation today on sla.ckers.org discussing IP trust relationships that web applications often have. It might sound crazy that one site should trust anything at all, but I’ve seen countless examples where certain IPs are simply ignored by security systems, purely because they are believed to be secure. First of all, insiders represent a majority of corporate hacks. Secondly, every day, on this website and on sla.ckers.org we are finding IPs that are untrustworthy, regardless of the brand associated with them.

To elaborate on ntp’s thoughts, let me give you a 95% real world scenario that I’ve actually seen. There is an online credit card processor that actually uses IP based authentication for adding user accounts to your database. Not only is that scary, but it’s highly probable that the usernames could include SQL injection. Not because the credit card processor would allow that through, but because the scripts that run on your server trust whatever is sent through the credit card processor. Now let’s assume for a second that the credit card processor’s machine is a windows box, and runs a remote desktop.

Someone at that company could easily be subverted into clicking a link (I tell them that for some reason I can’t get a connection between their server and my own so they must log in to verify it). When they click the link, it performs actions on their behalf (beyond connecting to my machine). Normally that wouldn’t be a big deal. They aren’t authenticated to anything, and they may have never used that account before. However, because of IP trust relationships between their IP and every one of the merchants that they service, I now can add user accounts to as many accounts as I can reasonably do in the time the browser is left open. Not only that, but I can do SQL injection and pull other user accounts, delete databases or whatever I choose to the database.

Suddenly the trust relationship has allowed major security issues, due to the privileged nature of the credit card processor. Nasty. There are all sorts of these IP based trust relationships on the Internet, because there is really no other good way to know who a user is before they have authenticated. Nasty, and a very overlooked attack vector.

Hallelujah! It’s been a great past few days, and I couldn’t even tell you all until now. I’ve been exchanging emails from David Ross from Microsoft for a few days regarding some anti-XSS stuff he’s working on. That MS is reading and listening gives me a great deal of hope! Further, David forwarded me an excerpt from an internal paper he had written (the snippet comes from a paper that expresses David’s own individual views as a security researcher and not necessarily the overall views of Microsoft). Take a look at the snippets:

RSnake’s “XSS Cheat Sheet” provides a long list of techniques such as the STYLE/expression trick described above. This is a great resource that can be leveraged by web application penetration testers looking for ways to circumvent potential fixes. But the cheat sheet effectively also provides a great reference of obscure techniques that enable XSS where it might not otherwise be possible.

and…

The one significant XSS-focused attack surface reduction measure implemented for Internet Explorer 7 was actually not intended to block XSS. In an effort to reduce non-XSS vulnerabilities involving the use of “javascript:” URLs, a mitigation was put in place that disables these URLs for navigation. The use of javascript: URLs in unusual places (such as IMG or EMBED tags) often enables XSS where it would not otherwise be possible. The mitigation effectively disabled these usage scenarios and has proven to be an effective XSS-focused attack surface reduction measure, albeit inadvertently.

As a side note, that jives with what other Microsoft higher ups have told me about the reason for that change (although it was pretty unofficial and at first they told me it might be a bug, so it’s nice to get some clarity on that change). I’m glad to see it recognized as to how that change came to be. It’s nice to see that internally it is realized how it impacted the number of vectors that affected Microsoft Internet Explorer from version 6.0 to 7.0.

Incidentally, RSnake took note. In an October 14 posting to his blog,

RSnake states:

“I’m glad the JavaScript directive has been relegated to IFRAMEs and HREFs rather than being possible anywhere a location was - thereby definitely reducing the attack surface for the newest browser from Microsoft.”

Until a few days ago I had had very little hopes for the browser companies stepping up to the plate and coming up with the solutions for the problem. It appears that we are developing new security issues at a rate much faster than the browser companies are fixing them. They have the most to gain by fixing these issues too It’s really nice to be talking to people who can make a difference and are committed to it. David and I are now working on some concepts for more browser security. Obviously all of this would be a ways away or may never happen, but at least I now have some hope. What a great story - browser company teams up with independent security researchers to come up with cutting edge solutions. “Teams” might be a strong word, but it’s as close as I’ve seen the browser companies come to walking hand in hand with the security community and I’m glad to be a part of it. I just can’t wait to get started.

Don’t worry, I’m still going to be as dispassionate about browser religion as I’ve ever been (as you may or may not remember, I’m the one who came up with the concept of content-restrictions in Firefox). I like to stay objective. I’m just eager to get the percentage of effective browser exploitation down to where it can be mitigated through whatever means are available, and right now Microsoft is really listening.

And no, telneting to port 80 just isn’t an option.

A recent thread on sla.ckers.org discussing a vulnerability in neopets actually got me thinking. Spikeman posted that you could detect once the page had completed loading in an iframe using an onload event handler. More timing attacks anyone? Well that’s not all. In Firefox it actually has a peculiar behavior. In IE (as it should) the onload event handler works all the time, because the page has finished loading. In Firefox it doesn’t fire if the browser encounters an error. An error could be something as simple as the server is not up (I have not tested with other server errors).

This proof of concept shows the difference (try in IE and Firefox to see the difference). You can see that in Firefox a series of iframes can be chained together to do port scanning (including Intranet port scanning). This is obviously a known issue when talking about JavaScript includes, but this is the first time I’ve heard of anyone discussing using an iframe for this purpose.  Yet another way to do cross domain leakage (and cross firewall leakage at that). Thanks to Spikeman for alerting me to the onload event handler in iframes.

Am I going to have to eat my words? I was thumbing through some AV reports over the last few days and one report stuck out at me. Granted, I don’t follow each worm (not enough hours in the day for all the things I’d like to explore) but I was surprised to see a worm that had to do with Pharming. For those of you who are unfamiliar with the term, unlike phishing, pharming takes a more proactive approach by forcing people’s DNS entries to point to a different/malicious server. Frankly, I thought it was mostly the stuff of science fiction since no one could point to a single example of any instance of pharming greater than 100 people (a single ISP that got it’s DNS compromised). Granted, the trojan doesn’t mention pharming but that is the obvious next step if it isn’t already doing it (rather than just trying to get some click-through traffic on some websites).

Trojan.Flush.K also known as Trojan.Dnschanger modifies DNS entries on your Windows box and attempts to forward you to a malicious website. The obvious synergies with phishing attacks make this particular one stand out at me. Symantec rated this one very low (probably to do both with the lack of virulence and the ease of cleaning the system), but it’s interesting to note how potentially dangerous this could be if it were more widespread and written with more malice.