'Rosetta Flash' Attack Leverages JSONP Callbacks To Steal Credentials

New submitter newfurniturey writes: A new Flash and JSONP attack combination has been revealed to the public today. It has been dubbed the "Rosetta Flash" attack. JSONP callback functions normally return a JSON blob wrapped in a user-specified callback function, which the browser will then execute as JavaScript. Nothing out of the ordinary here. However, the new attack has leveraged a method of crafting a Flash file to contain a restricted character set that's usable within JSONP callbacks (i.e. in a URL). By combining the two, the attack demonstrates it's possible to use a JSONP URL with the contents of the crafted Flash file as the callback function. When set as the data of a standard HTML object tag, the SWF file executes on the targeted site, bypassing all Same-Origin policies in place. Services such as Google, YouTube, Twitter, Tumblr and eBay were found vulnerable to this attack. Several of these services fixed the vulnerability with a patch prior to the public release, and Tumblr patched within hours of the release.

Comments

haven't we learned from the last 25 exploits?

[Anonymous Coward]

Keep javascript and flash disabled.

That is all. Letting random web sites run scripts on your computer has never been a good idea.

Enable it for your bank if you want. Otherwise, keep it disabled, and you'll be a lot happier (it keeps crapsites from foisting their crap on you), more secure from various exploits, and will maintain more of your privacy from all the data harvesters that depend on javascript.

Re:haven't we learned from the last 25 exploits?

[Arker]

Excellent advice.

Expect to be flamed into oblivion by all the 'web devs' that cant be bothered to learn how HTML works and rely on this crap instead, though.

The web - the real web, the HTML web, appears to be shrinking at the moment. New content is often hidden behind some kind of opaque app crap for no apparent reason and with no actual webpage for fallback (thanks google!) and old content occasionally gets removed as well. Each time this happens, it makes it even harder and less likely to revive the healthy web we once built with such love and care.

And naturally the people that are making a profit on this crap will just keep right on cranking it out as long as that is true.

The real victims here are future generations, who should inherit that world-wide web, but are set to inherit something entirely different - and inferior in every way (when judged from the users perspective - from the perspective of big Advertising of course the story will be different, but we built this web for humans, not for marketing.)

A harmful chaining of shitty browser hacks.

[Anonymous Coward]

It's basically a case of one shitty, half-assed browser hack (JSONP) being used in a way that allows another shitty, half-assed browser hack (JavaScript) to abuse yet another shitty, half-assed browser hack (Flash) to violate a shitty, half-assed "security" feature (same-origin policies).

The browser is truly the shittiest platform we've ever had. It may be widespread, but good god, is it ever shitty in so many inherent ways. It's just one smear of shit layered upon another. It really is broken all the way down.

Re:say wha?

[Arker]

"English translation: as usual, Flash is useless except as a vector for malware, viruses, trojans and keyloggers. Remove Flash from your system."

That's actually not quite true. Flash is a great way to develop simple games quickly and cheaply.

The problem isnt Flash itself (which is on the whole a fine product, used correctly) but the idea of using Flash as a substitute for a webpage, the installation of it as a browser plugin, and the auto-execution of it by the browser. None of that should be tolerated.

It's still possible to get a standalone flash interpreter and only feed it local, vetted files, which is really fine (or as close to fine as lots of other things you do every day, at least.)  But Adobe seems to be trying their best to discourage that and force everyone to use it as an auto-enabled browser component instead. The one way to use the program that causes major problems is also the one way they want you to use it.

Everyone who has been infected as a result of this should really get together and sue these arseholes, because money is the only language they understand.

Very clever

[mc6809e]

Reminds me a little of some work done by Terje Mathisen, an expert assembly language programmer. Not exactly that same as the exploit, but probably interesting to a few slashdotters. I'll let him describe it:

"The most complicated code I have ever written is/was a piece of executable text, in order to be able to send binary data over very early text-only email systems:

"Minimum possible amount of self-modification (a single two-byte backwards branch), a first-level bootstrap that fits in two 64-byte lines including a Copyright notice and which survives the most common forms of reformatting, including replacing the CRLF line terminator by any zero, one or two byte sequence. This piece of code picks up the next few lines, combining pairs of characters into arbitrary byte values before flushing the prefetch cache by branching into the newly decoded second-level bootstrap. (Everything uses only the ~70 different ascii codes which are blessed by the MIME standard as never requiring encoding or escape sequences.)

"This second level consists of a _very_ compact BASE64 decode which takes the remainder of the input and re-generates the original binary which it can either execute in place or write to disk.

Re:say wha?

[grcumb]

JSONP callback functions normally return a JSON blob wrapped in a user-specified callback function, which the browser will then execute as JavaScript. Nothing out of the ordinary here. However, the new attack has leveraged a method of crafting a Flash file to contain a restricted character set that's usable within JSONP callbacks (i.e. in a URL). By combining the two, the attack demonstrates it's possible to use a JSONP URL with the contents of the crafted Flash file as the callback function. When set as the data of a standard HTML object tag, the SWF file executes on the targeted site, bypassing all Same-Origin policies in place.

ummmm what? english please!

The code sneaks a Flash file disguised as a URL into some JSON data and cons the browser into treating it as JavaScript, but on the local machine it acts like an HTML <OBJECT>, and because the browser is executing the Flash code locally now (due to the masquerade), it can run with greater privileges than if it were from a remote site.

Or in layman's terms: Flash totally sucks the suckage, dude. Always did. Still does.

JS

[mfh]

This doesn't surprise me. Few developers truly understand how many vectors JS opens up. Just KISS and let's move forward.

JS fanboys are ruining everything.

Re:JS

[mfh]

JS is totally impulsive for a site designer. They just decide to add so many different bells and whistles that they don't have enough time to do penetration tests on any of it. They grab source code from ANYWHERE and tack it on their site. Nobody checks that stuff.

Run NoScript and there are tons of sites calling 10+ different JS blocks.

Moral hazard.

Re: JS

[corychristison]

I agree with you to an extent. The problem lies mostly in that users (developers) don't know what they are actually doing. They are typically young and have no real world experience. As you say, they 'tact peices of code together'.

The other

I'll take a shot at it.

[cbhacking]

I don't know about English, but I can produce an explanation that is understandable by most people with at least some knowledge of how the web works, hopefully... It's not going to be short or simple, but I'll at least try for clear.

JSONP is a web service communication method. The idea is that a client (a web browser) sends a request to a given URL, and in that URL they include a "callback" parameter. The response from the server is a blob of JavaScript starting with the callback parameter (as a function name), and then containing additional data (as a JSON-defined object, usually). Examples:
A target URL that looks like this:
https://vulnerablesite.com/jsonp_service/some_endpoint?callback=jsonp.handle_some_endpoint
Produces a request like this (no body, and some headers omitted for brevity):
GET /jsonp_service/some_endpoint?callback=jsonp.handle_some_endpoint HTTP/1.1
Host: vulnerablesite.com
Cookie: VulnerableSiteSessionCookie=JoeBlowIdentificationValue ...
That produces a response like this (again, header details omitted):
HTTP/1.1 200 OK
Content-Type: application/javascript
Content-Length: 41
...

jsonp.handle_some_endpoint({"foo":"bar"})
The browser would then interpret that response as JavaScript, calling the named function.

Now, this looks risky but normally it's safe enough, because while an attacker could embed a <script src="https://vulnerablesite.com/jsonp_service/some_endpoint?callback=jsonp.handle_some_endpoint" /> script source tag that specifies an arbitrary callback name (which then gets executed as JS), there's nothing really dangerous they can do with that because the server will disallow most sensitive characters in JS (things like ( ) = ' " < >) from the callback name, so you can't actually embed arbitrary javascript in the response. Usually the attacker doesn't control the content of the parameter (the JSON blob) either, or at least can't make it be anything except JSON (which is normally pretty harmless). For example, the attacker could pass "alert" as the callback, in which case the victim gets a message box saying "[object Object]" or similar. Whoop-de-do.

OK, so the attacker can't do much just by invoking a script with an arbitrary callback name. However, Flashplayer can execute applets in a number of formats, including formats that are theoretically compressed. I say "theoretically" because there's actually nothing requiring the data to be "compressed" in any even vaguely efficient manner (which tends to produce dense blobs of seemingly-random binary values). Instead, it's possible to create a "compressed" file that only contains alphanumeric characters (and is therefore valid as a callback name), but when it is "expanded" it produces an arbitrary binary blob (such as a compiled Flash applet).

So, here's what the attacker does. They create a malicious Flash applet. They run it through the special compiler this guy came up with, which converts it into a "compressed" applet format containing only characters that are valid for a callback name. They place an HTML object tag on their own, attacker-controlled website. The object specifies the jsonp service on the vulnerable site as its data source (the way one might specify youtube's flash applet as a data source), and specifies the callback name to be the alphanumeric-format applet. The attacker also specifies that the type of the data is application/x-shockwave-flash.

When a user visits the attacker's site, their browser sees the object tag and tries to retrieve the specified data. The response they get back is *actually* a JSONP script, but the first part of it - the callback function name - is *also* a valid Flash applet. Because the object tag specifies that the data type is Flash, the browser obligingly loads Flashplayer and runs the malicious applet (it ignores the ({"foo":"bar"}) blob at the end).

Now, here's the really mean pa

Mitigations

[cbhacking]

Sorry to self-reply, but I figured I should add some mitigations (for those who don't RTFA...)

First of all, as a user, one can of course disallow Flash by default (or remove it entirely). Mechanisms for doing this vary by browser, but all major browsers have at least one.
You can also update Flash. The latest version, released today (Tuesday the 8th), tightens up the validation of "compressed" applets in such a way that it should catch the output of this "Rosetta Flash" program.

For sitemasters / developers, there are a few options.

• You can host your JSONP service on a different (sub)domain from your sensitive data. This is most effective if the JSONP responses are either static or if there's a CSRF token for accessing the user data.
• You can add the string /**/ to the beginning of the JSONP response body, right before the callback identifier (this is what Google and GitHub are doing, for example). This will be ignored by the browser when it's treating JSONP as JavaScript (a 0-character comment) but will break the reflected-Flash-applet attack because the start of the response body no longer contains the magic number for any kind of Flash applet.
• You can add a HTTP response header like Content-Disposition: attachment; filename=f.txt to the JSONP responses, which will prevent all reasonably recent versions of Flashplayer from executing it the applet.
• You can add the HTTP response header X-Content-Type-Options: nosniff to all vulnerable responses (or just all of them), and then make sure that you specify the correct Content-Type header (it should be Content-Type: application/javascript although application/json, while technically incorrect, will probably work too). This header forces most browsers to pay attention to the server-provided content type, rather than letting the web page specify or guessing from the content itself.

Hope that helps!