'Rosetta Flash' Attack Leverages JSONP Callbacks To Steal Credentials 68
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.
haven't we learned from the last 25 exploits? (Score:4, Insightful)
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: (Score:1, Insightful)
Some of us would like the internet to be ... well ... useful.
It was plenty useful before Javascript was even invented. With a few rare exceptions, Javascript has not improved the web. It's made back buttons break, foisted 275 KB pages to do what 4K of HTML would do just fine, made videos break where a direct link would work, given us flashing crap, shit popping up, security vulnerabilities, disabled cut and paste which works again as soon as you disable javascript, and so forth and so on.
If you want the web to be useful, you should be pushing for only the most minim
Re: haven't we learned from the last 25 exploits? (Score:2)
Re: (Score:2, Insightful)
Someone doesn't know shit about the web here...
The introduction of Javascript was when the Internet began to turn to crap. Many of us pointed out at the time just what a security nightmare it would be.
Re: (Score:2)
This. Badly used Javascript, like html frame elements, also break the stateful nature of webpages, and this means breaking the concept of hypertext itself.
If sites were designed with optional javascript and ajax, they would work as well and referring to web content would be much easier. The semantic web was already there.
Of course big sites don't offer you the content as easily. Get logged in, get profiled, don't get out.
Re: (Score:1)
When this crap first started getting pushed, a lot of us saw the potential problems coming and objected. We were assured it was only to be used to 'spice up' webpages, not to replace them.
Such assurances are obviously shit. If it's allowed to use it, then the lowest common denominator of self-proclaimed 'designers' can, will, and must overuse it. This overuse expands steadily and predictably until and unles
Re: (Score:2)
You know, there used to be a time where there were excellent webmasters that could do both HTML and Javascript great. Where you went to a website and without JS, it degraded gracefully.
Apple's website was like that, maybe about 8 years ago or so. Other than being a bit ugly in parts, it worked extremely well without JavaScript. (turning it on made it prettier and things worked a lot better, though). In fact, I only noticed it when I noticed it rendered differently on two different Firefoxes - on one, I had
Re:haven't we learned from the last 25 exploits? (Score:5, Insightful)
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.)
Re: (Score:2)
Amirite... a bluish purple crystal that turns pink in the presence of sarcasm. First described in a Kenny Loggins song:
Amirite. Donut buddy worry 'bout me.
Re: (Score:2)
Nobody minds CSS much, so long as you don't allow embedding JavaScript URLs in it (which, unfortunately, browsers do).
The problem is not JavaScript, per se, so much as the fact that it is massively overused, breaking links, breaking back buttons, etc. Your documentation viewing experience does not demand a web app. It might benefit from some intelligent links that do special stuff if JS is enabled, but if you cannot make your site work with JS disabled, you're abusing JavaScript.
There are exceptions, min
Re: (Score:1)
Re: (Score:2)
Very easily [stackoverflow.com], and because so few people know it is possible, it's a rather nasty vector for cross-site scripting attacks.
I'm well aware of responsive design. I think it's an abomination, because all it does is make it take two page loads to view your site instead of one, by ensuring that I have to first load your broken mobile site, then click the "full versi
Re: (Score:2)
Re: (Score:1)
Re: haven't we learned from the last 25 exploits? (Score:1)
Re: (Score:2)
OK. That really doesnt have anything to do with the web, however. Sure, the web can be used to deliver the project - that doesnt mean it has to actually run inside the browser. There is a HUGE difference.
"We could not have produced this educational game with just HTML."
I get where you are coming from but I still think it's far off the mark. The web is not a game platform, that is not it's purpose, so 'we could not do games thi
Re: (Score:2)
Hear, here!
say wha? (Score:1)
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!
Re: (Score:1, Insightful)
English translation: as usual, Flash is useless except as a vector for malware, viruses, trojans and keyloggers. Remove Flash from your system.
Re:say wha? (Score:4, Insightful)
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.
Re: (Score:2)
As a point, WebM can't replace it fast enough.
A harmful chaining of shitty browser hacks. (Score:5, Insightful)
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: (Score:1, Troll)
Re: (Score:1)
Re:say wha? (Score:5, Informative)
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.
Re: (Score:1)
I'll take a shot at it. (Score:5, Informative)
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
Mitigations (Score:5, Interesting)
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!
Very clever (Score:5, Interesting)
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.
JS (Score:3, Insightful)
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: (Score:1)
Re: (Score:3)
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 (Score:3)
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
Re: JS (Score:2)
(Bah. Touchscreens will be thr death of me)
The other issue is Javascript can do too much. I really only use a small subset of it in my own projects. Basically just simple DOM manipulation, and the odd calculation.
Re: (Score:1)
Re: (Score:2)
Not vulnerable (Score:2)
I don't have flash installed.
Threat mitigated.