Social Icons

Wednesday, July 09, 2014

“Weaponized” exploit can steal user cookies on eBay, Tumblr, other sites

Google and Twitter already patched against potent "Rosetta Flash" attack.





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 rssult 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 steal
visitors' cookies that were previously set by eBay and other vulnerable
sites.

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 effectively steal 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).



Enlarge SWF header formats.

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.



Flash parsers are liberal.



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:



Enlarge Hacking the first byte of the zlib header.

Enlarge Hacking the second byte of the zlib header.

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

No comments:

Post a Comment

 

Sample text

Sample Text

Sample Text