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.

There’s an interesting link on MSNBC about malware that’s trying to solve CAPTCHAs. Basically it’s using an ruse of a sexy girl who tempts you with nudity if you type in some letters/numbers. The letters/numbers are, of course, to social networking sites, webmail or whatever. Very clever, but also very stupid at the same time.

One thing we’ve seen actually is pretty clever. Malware has the ability to do a lot, including re-writing webpages on the fly. However, the goal isn’t just to re-write some banners (yes, sometimes that is the goal) but sometimes it’s to steal information. And sometimes it makes sense from an attacker’s perspective to ask for an additional piece of information (like a social security number) on a form. What I haven’t seen is adding an additional CAPTCHA to a page, which would be totally invisible to the average user (unlike a stripper on your desktop, which is sort of the opposite of subtle).

When Jeremiah and I did our webinar presentation a while back we ended up with a few minutes to kill before our webinar actually started. So we just sorta started chatting about random webappsec stuff. More of a free for all Q&A session than anything where Jeremiah asked me a lot of questions and I gave my off the cuff feelings on the topic. We weren’t expecting much out of it other than to kill time until the real webinar started, but we got a pretty good response out of that part of it because it was really timely. Okay, so, fine, we’re doing it again.

WhiteHat is sponsoring 150 people to listen in on the webcast (obviously you can download it later, you just won’t be able to listen in live). Here’s the link if you’re interested. I’d tell you what it was about, but I really have no idea. This time we’re bringing in two more people, Chris Paggen, senior manager, application delivery and network security business unit at Cisco, and Jordan Wiens, Security Beat Editor at Network Computing. So who knows if it’ll be good or bad, but it’s an interesting experiment. I for one will be tuning in, er… you know… whatever, you know what I mean.