hackademix.net

Rich Cannings recently documented Flash-based XSS, clarifying with some examples the quite fuzzy coverage this issue received so far.
Its “The Fix / Users” section says:

Update to the latest version of Flash Player plugin. This will protect users from attacks using the “asfunction” protocol handler

Unfortunately, the majority of the examples listed right there do not use the “asfunction” protocol handler at all!

More realistically, Jeremiah Grossman writes:

- Users update their Flash player – Based on the nature of the issue, I’m not certain of how much benefit to this there is, but might as well patch anyway if there is one available.

- Disable or block Flash content – I think most people reading this probably already do some form of Flash blocking, but for everyone else, there are simply not going to.

Now, the “some form of Flash blocking” Jeremiah’s talking about is most likely NoScript, which:

1. Blocks Flash (and other plugins) by default when the content comes from an untrusted web site
2. Blocks Flash (and other plugins) by default when content from a trusted website is embedded in an untrusted page - this prevents embedded Flash XSS
3. Checks cross sites requests for script injection and sanitizes them as needed - this prevents reflected XSS, included the Flash variants

The best thing, making this approach much more viable than “disabling Flash content” tout-court, is that you can allow individual blocked content pieces with a click, having a chance to examine their types and full addresses before running them: this is what may save you from being owned in a Flash ;)

Looks like 2007 improved XSS awareness in the “mainstream” media outlets too.
The Register recently published a report about the Orkut XSS worm. It’s not the first time, here’s a list of XSS worms and some already hit The Register’s columns, but the level of understanding is visibly getting better. This is clearly good, because XSS worms are becoming more and more common. While at this moment we can mainly see goliardic demonstrations, like this nice hi5.com Xmas gift by my friend Sirdarckcat, we should all be worried of how easy and quick to find and exploit this kind of web application flaws is, and ready for the real scams that are unavoidably coming (like this), thanks to the growing importance of so called “Web 2.0 social networks” and other web services in our private and business lives.

The Register has also “discovered” Flash-based XSS, something that is surely old news in our circles: as you may remember, Sirdarkcat’s attack on RSnake was based on that.

The good news is that you, dear NoScript user, are already immune from both the aforementioned XSS worms, which are based on cross-site XBL (something which is also mitigated by Firefox 3) and more generally on 3rd party script inclusion.
Even better, you’re also protected against Flash-based XSS, included RSnake’s kind, now in NoScript default configuration: latest NoScript, in facts, won’t run Flash applets (and other plugins) even if hosted on trusted sites, when they’re embedded or linked from an untrusted site. In other words, it prevents browser plugins from being exploited for XSS in its very definition.

java&
#x73;cript:
\u0061\u006c\u0065\u0072\u0074\u0028\u0022
\u0048\u0061\u0070\u0070\u0079 " + 0×07D8)

The recent disclosure by pdp of the jar: protocol bug originally discovered and responsibly reported by Jesse Ruderman in February, and its redirect variant discovered and popularized by Beford with a nice Google-targeted proof of concept, spawned some interesting 3rd party coverage.
Interesting, because very few 3rd party reporters and commenters seem to truly understand how this vulnerability works, and — worse — because of the quite nonsensical advices given to protect users.

How the Vulnerability Works

The jar: protocol is used internally by Mozilla browsers to resolve and address resources stuffed inside optionally compressed archives in Zip format called JARs (Java ARchives).

A JAR URL looks like this:
jar:http://someserver.com/some/path/somearchive.jar!/some/internal/path/resource.jpg
As you can see, after the jar: scheme we’ve got a regular http: URL (http://someserver.com/some/path/somearchive.jar), followed by an exclamation mark separator and the internal path to find the actual resource inside the archive.

When a Mozilla browser is asked to open a jar: URL, it first downloads the whole JAR file from the server using a regular HTTP GET request (for http://someserver.com/some/path/somearchive.jar, in our example), then extracts the required resource (resource.jpg, in our example) from the archive on the client side.

All good and handy, but here’s the problem: the jar: protocol currently assumes any nested URL following the jar: scheme actually points to a JAR, no matter what the actual content-type header or any other file type hint (e.g. the file extension) suggests.
This means that I can stuff a malicious HTML page of mine inside a Zip file, rename it as “ma1.jpg” and upload it as my avatar on a message board.
Then trick some user to open my malicious page directly through a jar: URL like
jar:http://someforum.com/images/avatars/ma1.jpg!my_evil_page.html
Worse, my page’s JavaScript code will run in the same domain as the hosting site, i.e. someforum.com, hence I’m cross-site scripting the message board.
To make it even more nightmarish, I don’t actually need the target website to be a message board allowing file uploads: I just need an open redirect, which can be found on Google and many other “safe” places, because my disguised JAR file will inherit the security context of my victim’s redirector even if it’s hosted on a website of mine. That’s how Beford’s proof of concept works.
Did you say “Universal XSS”?

What Firefox Users Can Do

At least until a Firefox patch is released, Firefox users should install latest NoScript stable release, or even better help us testing latest development version.
NoScript will prevent remote JAR resources from being loaded as documents, neutralizing the XSS dangers of the jar: protocol while keeping its functionality. See this FAQ for more details.
It should be noted that this specific protection is completely independent from JavaScript blocking: this means that you’re protected on every site, no matter if there you’ve set NoScript to allow JavaScript or not.
Strangely enough, even if this is the only advice which works (other than switching to a different browser), it has been give only by the US Cert advisory (together with another less effective one, see below).

Bogus Advices

Firefox users should avoid follow untrusted “jar:” links on suspicious Web sites.
(Ryan Naraine’s Zero Day)

There are several ways for a browser to open an URL automatically without your consent: JavaScript, an IFrame, a Meta Refresh, a redirect…
If this vulnerability is exploited in the wild, you won’t see any “jar: link” coming.

Poor Ryan has probably been misled by reading the following:

Do not follow untrusted “jar:” links or browse untrusted websites.
(Secunia Advisory)

Admittedly, the “don’t browse untrusted websites” clause adds some correctness to this advice, but also makes it practically useless.
Furthermore, Ryan quotes the US Cert advisory as well, hence he’s got no excuses for omitting the NoScript work-around.
As we said, US Cert correctly referenced NoScript’s JAR protection, but also gave a bogus advice of its own:

Using proxy servers or application firewalls to block URIs that contain jar: may mitigate this vulnerability.

If you read how this issue works carefully, you should have noticed that all the jar: protocol resolution happens inside the browser: the only request which is sent, possibly hitting proxy servers or application firewalls, is the regular nested HTTP request. Are you going to block every image together with my innocent looking http://someforum.com/images/avatars/ma1.jpg? At any rate, your network devices are very unlikely to ever see mythological beasts like “URIs that contain jar:”…

No matter how nonsensical the advices above are, someone decided to endorse them all:

No patch is available through there are a number of workarounds (such as blocking URIs that contain “jar:” using a reverse proxy or application firewall). For home users, Secunia advises users to avoid following untrusted “jar:” links or visiting untrusted websites.
(The Register)

What a pity they left out the only one which does work ;)

Update:

PC World and ComputerWorld finally joined the fun:

application firewalls and proxy servers can be used to block Windows Universal Resource Identifiers (URIs) that contain the JAR protocol

They actually reference NoScript, but in a quite misleading way:

Users can download a NoScript add-on for Firefox to block JavaScript and executable content from untrusted Web sites, and can secure their Google accounts by remaining signed out whenever possible.
IBRS security consultant James Turner, who has used the NoScript add-on, said protection against these vulnerabilities can be a trade-off between security and a rich online experience.
“The add-on works fine but it is a trade-off between reducing your online experience by blocking JavaScript and protecting yourself against the exploit,” Turner said.

As I said, NoScript’s JAR protection has nothing to do with JavaScript blocking and it works no matter what the content of your whitelist is: in other words, there’s no trade-off at all because you keep JavaScript enabled where you need it! Oh, “security expertize”…
In the meanwhile, Ryan Naraine wrote a follow-up honestly reporting my criticism (notice that I had privately emailed both him and The Register’s John Layden with no answer, before deciding to write this post of mine).
Thanks Ryan.

So I just come back from my honeymoon journey (Greece, Turkey and Croatia) right in time to find that Sirdarckcat and Kuza55 teamed together to throw a friendly defacement at our beloved RSnake!

The kids miserably failed, nevertheless RSnake did not like it a bit.
Their payload was playful rather than venomous in my opinion, but you can judge by yourself:

0wning RSnake For Fun and PageRank

So, you’re sitting on the sla.ckers.org irc channel one day and someone is poking around with one of RSnake’s tools, and finds that its not working, or at least that’s what it seems like untill they realise that its not just broken, its broken in a fun XSS way :) - what do you do? Do you: a) Urge the person to report the problem to the vendor (RSnake), and get mad props for being awesome? b) Scream about how the vendor is a security “expert” and needs to “secure their shit!!!1111″? c) 0wn the vendor for Fun and PageRank Well, to me, the answer seemed fairly obvious. Since the “Evil Advertising Empire” (Google), cue ominous music….now, had done a little dance and increased the PageRank of our blogs, we had gotten a taste of the power which we could amass, muahahaha, and we wanted more! Or at least I did….. So anyway, Hey RSnake :) Thanks for the free advertising space. Anyway, credit goes to: sirdarckcat for not only being generally awesome, but finding the actual exploit. thornmaker for (inadvertently) providing us with a method to get our payload through NoScript (Javascript variable setter’s and window.name FTW!), so umm, hey thornmaker :) Gareth Heyes for doing that awesome research on selective payloads using CSS, which where implemened in the exploit. kuza55 for not really doing anything, but being in the right place at the right time but being able to get some free Googlejuice from things anyway :p Oh, and, of course: XSS! We now return you to your regularly unscheduled posting ;) - kuza55 & sirdarckcat P.S. Thanks for directing carja.ckers.org to 127.0.0.1 :) P.S.2. Sorry .mario, NoScript is the new attack playground :P, we’ll be back to php-ids ASAP.

At any rate, from my NoScript standpoint, nice setter+name bypass combo — just you send me a mail next time, thanks ;)
Latest release already defeats it, but for those who disabled automatic updates, it’s time to get it…

If the GoogHOle wasn’t wide enough, yesterday Petko D. Petkov AKA pdp posted another “semi-disclosure” about how you can redirect someone else’s GMail incoming messages to your account.
Petko declared “I am not planning to release this vulnerability for now”, but this counts as a full disclosure in my book, since the details he gives away are far more than enough to put up a proof of concept in 10 minutes, if the reader knowns the very basics of Cross Site Request Forgery (CSRF).

1. Victim must be logged in GMail.
2. Victim must visit a malicious web page: most likely scenarios are clicking an external link from an incoming message or surfing porn while checking email from time to time.
3. The malicious web site forges a POST request to GMail’s “Create Filter” wizard, possibly using an autosubmit invisible form to build a filter which forwards incoming messages to a mail recipient owned by the attacker.
4. Since user is already authenticated, her session cookie is passed along with the forged request and the GMail filter gets silently implanted, with all the output hidden inside an IFRAME.
5. The new GMail filter now acts as a persistent backdoor stealing incoming messages, and it will go unnoticed forever unless the victim is a power GMail user who creates or edits from time to time her own filters, which are deep buried in the “Settings” user interface: I, for instance, never saw them until yesterday!

Very clever and very dangerous.
As I said, this surely counts as a 0day public full disclosure: no matter if pdp omitted an explicit PoC. How many of us, having minimal web coding experience, wouldn’t be able to build a working exploit using the info above?

CSRF Countermeasures

As usual, now that’s been publicly disclosed, this vulnerability is being patched very quickly by the great Google development crew.
Nonetheless, many other holes of this kind are still around. That’s why CSRF is called “The Sleeping Giant”: some web coders may still need to learn how to fix or prevent them, and users surely want to know how to protect themselves.

1. Web Developers

Please use form keys!

1. Generate a random identifier (form key) every time you display a form meant to be submitted by authenticated users only.
2. Echo your key as an hidden field of the form and bind its value to the user session data kept on the server side.
3. As soon the form is submitted, compare the returned key with the one stored in session data: if they don’t match, throw away the request because it is probably forged.

The above is a simple yet effective anti-CSRF technique. It will work fine unless a further Cross Site Scripting (XSS) vulnerability is present too, allowing attacker to read your form key on the fly and forge a seemingly valid requests.

2. Web Users

This GMail incident proves how even the best trained web developer in the world can fail at implementing CSRF countermeasures.
Most of the existing literature about XSS and CSRF will tell you that poor users can do nothing to protect themselves from these attacks, but this is blatantly false.
A quite radical, not very usable but effective approach would be using different browsers (or different profiles, if you use Mozilla derivatives) for each “sensitive” web site you access, and force yourself not to follow any external link nor browse any other site while logged in.

Anyway, if you prefer not to make your life miserable by spawning multiple browsers and scanning every single link with a magnifying lens, your answer is, once again, Firefox + NoScript (sorry to sound repetitive, but that’s it).

First of all, automating a POST request is trivial if JavaScript is enabled on the attacker site — form.submit() — but just impossible if malicious scripts are blocked by NoScript.
The obvious objection, raised for instance by both pdp and Adrian Pastor at GNUCITIZEN, sounds like:

The attacker could simply build an invisible POST form and disguise its “submit” button as a regular link or an image, then social-engineer his victim into clicking it and so have the exploit launched no matter if JavaScript is disabled.

True, but NoScript effectively defeats this attack as well!

A common misconception about NoScript is that it just blocks JavaScript on untrusted sites.
It certainly does, but NoScript actually enhances browser security in several other ways.
A very incomplete list:

1. It blocks Java, Flash, Silverlight and other plugins on untrusted sites, and optionally also on trusted pages, while letting you activate the plugin content on demand, with a click.
2. It prevents malformed URIs to exploit buggy URI handlers, i.e. the foundation for many cross-application exploits discovered by Billy Rios, Nate McFeters and Thor Larholm.
3. It implements the most advanced and effective anti-XSS protection available on the client side.

NoScript’s anti-XSS protection deploys various specific countermeasures, e.g. HTML/JavaScript injection detection, URL sanitization on suspicious cross-site requests, UTF-7 encoding neutralization and many others.
One of them also provides an effective defense from CSRFs of the kind affecting GMail: in facts, NoScript intercepts POST requests sent from untrusted origins to trusted sites and strips out their payloads.
This means that, even if the attacker exploits a scriptless vector to launch his POST CSRF through social engineering, NoScript users are still safe as long as the malicious site is not explicitly whitelisted.

When he learned this, pdp commented:

Giorgio, sounds good, but doesn’t that break things?
I mean, CSRF is one of the most fundamental Web characteristic.
Disabling it might be OK for people like us, but for the general population, that is a no go!

Petko, my friend,

1. The very foundation of the Web is CSR (Cross Site Requests, AKA Hyperlinking), not CSRF (Cross Site Request Forgery) which is an unwanted side effect of bad coding practices.
2. RFC 2616 defining HTTP (hence, in a certain sense, the Web itself), clearly states that while GET requests (the ones we generate by following hyperlinks or submitting a search form) are idempotent, i.e. should not modify the receiving system, POST is reserved to requests which cause a permanent change. NoScript just prevents untrusted sites from modifying data held by trusted sites, and this looks Pure Good™: why could you want the contrary?
3. Even if you actually wanted the contrary, you can either use the “Unsafe reload” command, available whenever a request is filtered by NoScript, or permanently configure some sites of your choice as unfiltered recipients of unsafe requests by listing them in NoScript Options/Advanced/XSS/Exceptions

The NoScript feature we’re talking about has been in place for more than six month now.
I guess it’s transparent enough if security researchers like you, Adrian or .mario — people “like us”, much more attentive to what happens inside their browsers than “the general population” — did not even notice it… ;)