Slashdot Mirror
'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.
"Several of these services fixed the vulnerability with a patch prior to the public release, and Tumblr patched within hours of the release." Who hasn't?
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.
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!
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.
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.
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.
The dangers of knowledge trigger emotional distress in human beings.
In Mozilla's stupidity, they decided to remove a very useful feature.
Sigh. I shouldn't have to run noscript.
What do you mean?
javascript.enabled. Set it to false, and voila, disabled javascript.
Surely noscript is handier for its while/blacklisting abilities, but disabling javascript is something you can do with no extensions, out of the box.
That's way too much effort for something that was really easy to do before. Mozilla introduced a bug into Firefox by removing the ability to easily disable JavaScript without having to fuck with its about:config values, even if they're too fucking stupid and/or ignorant to acknowledge this.
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: /jsonp_service/some_endpoint?callback=jsonp.handle_some_endpoint HTTP/1.1 ...
...
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
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
There's no place I could be, since I've found Serenity...
Gopher and UUCP are good enough for me! Really nobody should be using anything more than ASCII text files. I was about to suggest EBCDIC, but I then realized that we are living the year 2014.
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.
Hope that helps!
There's no place I could be, since I've found Serenity...
I don't have flash installed.
Threat mitigated.
I use PrefBar to solve this problem. http://prefbar.tuxfamily.org/. Single bar across top of browser to toggle Javashit, Flash, Cookies, proxies, referrer-ID, and moar.
PrefBar has lots of unanticipated uses. When Google Image Search changed its default behavior to "Javashit on, get infinite scrolling crap" and "Javashit off, click on thumbnail, go to the webpage that hosted the image (often the wrong page, or some long forum thread with a thousand posts in it)", you can tell it you're using Lynx. With Javashit disabled and a User-Agent of lynx, it reverts to two-pane view of a big frame that you can ignore, and a thumbnail, beneath which is the URL of the image you're actually looking for. You can pop that open in a new tab and have the desired image before the the irrelevant website even loads in the two-page tab.
And as long as I'm ranting here, I'll also chip in with a hearty fuck beta, fuck webdevs, and most of all, fuck Asa Dotzler and all his UX clones.
The EICAR test virus does something similar. DOS executable with assembler instruction values only from the printable ASCII character set. Nowhere near as sophisticated as the above reference piece.
http://www.rexswain.com/eicar.html
That misses the point of this vuln entirely which requires NO JavaScript whatsoever on the user's part. The site is written to use JavaScript and set up a JSONP service. This trick fools the JSONP service into returning a "callback name" that just so happens to be valid .swf data. The attacker then uses the URL that triggers that response in a context that expects flash (e.g. an or tag). As far as Flash is concerned the .swf came from that site so it's allowed to make any further requests to that site it wants.
[I, too, am sad the UI for disabling JS is gone, but honestly for myself I've always used the Web Developer Toolbar when I wanted to disable JS because it's faster to get to that option.]