Rosetta Flash uses ad-hoc Huffman encoders in order to map non-allowed bytes to allowed ones.
#Block rosetta stone host file full#
In the Rosetta Flash GitHub repository I provide ready-to-be-pasted, universal, weaponized full featured proofs of concept with ActionScript sources.īut how does Rosetta Flash really work? Details on Rosetta Flash Rosetta Flash takes in input an ordinary binary SWF and returns an equivalent one compressed with zlib such that it is composed of alphanumeric characters only
Rosetta Flash leverages zlib, Huffman encoding and ADLER32 checksum bruteforcing to convert any SWF file to another one composed of only alphanumeric characters, so that it can be passed as a JSONP callback and then reflected by the endpoint, effectively hosting the Flash file on the vulnerable domain. SWF files can be embedded on an attacker-controlled domain using a Content-Type forcing tag, and will be executed as Flash as long as the content looks like a valid Flash file. , my tool focuses on this very restrictive charset, but it is general enough to work with different user-specified allowed charsets. Since most JSONP callbacks restrict the allowed charset to, _ and. JSONP, by design, allows an attacker to control the first bytes of the output of an endpoint by specifying the callback parameter in the request URL. This is why allowing users to upload a SWF file on a sensitive domain is dangerous: by uploading a carefully crafted SWF, an attacker can make the victim perform requests that have side effects and exfiltrate sensitive data to an external, attacker-controlled, domain. With Flash, a SWF file can perform cookie-carrying GET and POST requests to the domain that hosts it, with no crossdomain.xml check. To better understand the attack scenario it is important to take into account the combination of three factors:
If you prefer, you can discover the beauty of Rosetta by reading the paper or with a set of comprehensive slides. I will present this vulnerability at Hack In The Box: Malaysia this October, and the Rosetta Flash technology will be featured in the next PoC||GTFO release.Ī CVE identifier has been assigned: CVE-2014-4671 (NIST). This led websites owners and even big players in the industry to postpone any mitigation until a credible proof of concept was provided. This is a well known issue in the infosec community, but so far no public tools for generating arbitrary ASCII-only, or, even better, alphanum only, valid SWF files have been presented. After a month, Adobe released a better fix for Rosetta Flash.
#Block rosetta stone host file update#
Update : The original fix by Adobe was not enough ( CVE-2014-5333 (NIST)). Twitter, LinkedIn, Yahoo!, eBay,, Flickr, Baidu, Instagram, Tumblr and Olark still have vulnerable JSONP endpoints at the time of writing this blog post (but Adobe pushed a fix in the latest Flash Player, see Mitigations and fix). High profile Google domains (, maps., etc.) and YouTube were vulnerable and have been recently fixed. This is a XSRF bypassing Same Origin Policy. In this blog post I present Rosetta Flash, a tool for converting any SWF file to one composed of only alphanumeric characters in order to abuse JSONP endpoints, making a victim perform arbitrary requests to the domain with the vulnerable endpoint and exfiltrate potentially sensitive data, not limited to JSONP responses, to an attacker-controlled site.
0 kommentar(er)
