neat new and ridiculous flash hacks
Skip this Video
Download Presentation
Neat, New and Ridiculous Flash Hacks

Loading in 2 Seconds...

play fullscreen
1 / 60

Neat, New and Ridiculous Flash Hacks - PowerPoint PPT Presentation

  • Uploaded on

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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
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

Penetration Tester

Security Consultant

Senior Security Researcher: MAD Security

Instructor: The Hacker Academy


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 *” directives in crossdomain.xml
  • …But people do anyways

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 *


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

the livejournal worm
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
crossdomain xml csrf
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:[email protected] will force the browser to request http://foo:[email protected]/crossdomain.xml
  • No alerts will be triggered and the browser can be forced to log into
xss in flash objects
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


My approach: XSS through RFI bugs in Flash objects

Many objects load a secondary XML configuration file, which can be poisoned

the point
The Point:

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

client side hpp
Client-Side HPP
  • A bad name for a simple attack
  • Passing multiple copies of the same parameter

  • Flash will interpret “input” as “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
  • 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?
  • 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
  • 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
  • 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
case 3 upload an object
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
how the upload attack works
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
how is this different from uploading a javascript file
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.
remember gifar
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.
but wait there s more
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)

how to hack a gmail account
How To Hack A Gmail Account
  • The webmail application lives on
  • Attachments are served from
  • Seems simple enough
plan a
Plan A
  • Send an email to victim with attachment
  • Load the object out of the victim’s account, embedding it in my web page


  • I need to know the messageID of the attachment
  • I don’t know your messageIDs
  • I do know my messageIDs
plan b
Plan B
  • 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
  • Token-based CSRF protection on login

Solution: Cross-Subdomain cookie manipulation to forge CSRF tokens

  • Finding an XSS hole in *

Solution: Google gadgets can be poisoned with arbitrary XML files, injecting Javascript into

other problems1
Other Problems
  • 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
  • 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
  • Detecting when the user has logged in

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

the final exploit
The Final Exploit
  • 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
  • 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 *
  • 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