'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.

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.

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!