Update: Almost four hours after this article went live, a Tumblr spokeswoman e-mailed Ars to say the site has been patched against the Rosetta Flash attack. Later, a cofounder of Olark said that service had been patched, too.

A serious attack involving a widely used Web communication format is exposing millions of end users' authentication credentials on sites including eBay, Tumblr, and Instagram, a well-respected security researcher said Tuesday.

The exploit—which stems from the ease of embedding malicious commands into Adobe Flash files before they're executed—has been largely mitigated by a Flash security update Adobe released Tuesday morning to coincide with a technical analysis of the threat, including proof-of-concept exploit code. It will take days or weeks for a meaningful percentage of end users to install the fix, so the researcher who wrote the advisory is warning engineers at large websites to make server-side changes that will minimize the damage attackers can inflict on visitors. eBay, Tumblr, Instagram, and Olark are known to be vulnerable to attacks that can intercept authentication cookies or other data they send end users. Until recently, both Twitter and a wide range of Google services were also susceptible to the exploit. The common identifier assigned to the exploit is CVE-2014-4671.

The attack relies on behavior that has existed for years that allows the binary contents of a common shockwave file—a throwback term for Flash files that's better known simply as SWF—to be converted into an equivalent file based solely on alphanumeric characters. The conversion typically happens to compress a SWF file so it works with websites that use a technique known as JSONP—or JSON with padding—to set browser cookies and perform other tasks.

A new proof-of-concept tool dubbed Rosetta Flash uses a creative combination of encoding algorithms to construct character-only representations of SWF files that contain malicious commands. Among other things, malicious SWF files spawned by the tool can use the visitor's Flash application to send Web requests that can access authentication cookies and other files set by other websites that use JSONP. This exfiltration works as a result of Flash being able to bypass the Same Origin Policy, which is in place to stop these kinds of cross domain requests. As a result, a malicious website hosting a booby-trapped SWF file could use authentication cookies that were previously set by eBay and other vulnerable sites to make authenticated data requests on behalf of the person visiting the attack site.

Day of reckoning

"This is a well known issue in the infosec community, but so far no public tools for generating arbitrary ASCII-only valid SWF files have been presented," Michele Spagnuolo, a Google security engineer based in Zurich and the creator of Rosetta Flash, wrote in a blog post. "This led website owners and even big players in the industry to postpone any mitigation until a credible proof of concept was provided. So, that moment has come :)."

One reason many security professionals discounted the real-world threat posed by alphanumeric-represented SWFs was the strict format converted files have to follow. Not only are they required to contain a validating checksum, the finished file must use a set of characters limited to upper- and lower-case letters, numbers, and a small number of punctuation symbols. Rosetta Flash combines the zlib compression library, Huffman encoding algorithm, and ADLER32 checksum-enabled brute forcing techniques to work within these restrictions. The code contains ready-to-be-pasted commands that have been "weaponized," meaning they're designed to make use of browser cookies and other data websites use to grant users access to their account profiles.

Spagnuolo wrote:

Rosetta Flash uses ad-hoc Huffman encoders in order to map non-allowed bytes to allowed ones. Naturally, since we are mapping a wider charset to a more restrictive one, this is not a real compression, but an inflation: we are effectively using Huffman as a Rosetta stone. A Flash file can be either uncompressed (magic bytes FWS ), zlib-compressed (magic bytes CWS ) or LZMA-compressed (magic bytes ZWS ).

Furthermore, Flash parsers are very liberal and tend to ignore invalid fields. This is very good for us, because we can force it to the characters we prefer.

zlib header hacking We need to make sure that the first two bytes of the zlib stream, which is basically a wrapper over DEFLATE, are OK. Here is how I did that:

There aren't many allowed two-bytes sequences for CMF (Compression Method and flags) + CINFO (malleable) + FLG (including a check bit for CMF and FLG that has to match, preset dictionary (not present), compression level (ignored)). 0x68 0x43 = hC is allowed and Rosetta Flash always uses this particular sequence.

Tuesday's security update from Adobe causes Flash to perform additional validation checks to ensure it rejects malicious content from vulnerable JSONP callback interfaces. Like all security updates for Flash, users should install it immediately. Spagnuolo said website operators should avoid using JSONP on sensitive domains and if possible use a dedicated "sandbox" domain. The Google researcher went on to provide the following additional advice for website operators:

A mitigation is to make endpoints return the HTTP header Content-Disposition: attachment; filename=f.txt, forcing a file download. This is enough for instructing Flash Player not to run the SWF starting from Adobe Flash 10.2. To be also protected from content sniffing attacks, prepend the reflected callback with /**/ . This is exactly what Google, Facebook and GitHub are currently doing. Furthermore, to hinder this attack vector in Chrome and Opera you can also return the HTTP header X-Content-Type-Options: nosniff . If the JSONP endpoint returns a Content-Type which is not application/x-shockwave-flash (usually application/javascript or application/json ), Flash Player will refuse to execute the SWF.

Don't blame JSONP or Flash

In an e-mail, Spagnuolo said the threat wasn't the result of weaknesses in JSONP.

"JSONP has been designed to work like this," he wrote. "It is by design. My exploitation technique combines JSONP and the previously unknown ability to craft alphanum only SWF to allow exfiltration of data."

He also said the attack didn't rely on a vulnerability in Flash. Rather, "JSONP allows [attackers] to effectively 'reflect' the SWF making it look like it's hosted on the vulnerable domain. These things combined allow the exploitation."

Listing image by Edwin S. Porter - The Kobal Collection.

The headline and language in the third paragraph have been changed to clarify that authentication cookies aren't actually obtained by the attacker.