Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Security The Internet

'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.
This discussion has been archived. No new comments can be posted.

'Rosetta Flash' Attack Leverages JSONP Callbacks To Steal Credentials

Comments Filter:
  • Re:say wha? (Score:5, Informative)

    by grcumb ( 781340 ) on Tuesday July 08, 2014 @11:02PM (#47412419) Homepage Journal

    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.

  • 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

Those who can, do; those who can't, write. Those who can't write work for the Bell Labs Record.

Working...