0% found this document useful (0 votes)
128 views73 pages

Flash Security and Attacks

Uploaded by

beckbeck20177
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
128 views73 pages

Flash Security and Attacks

Uploaded by

beckbeck20177
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 73

8.

1 Introduction

8.2 Flash Security Model

8.3 Flash Vulnerabilities

8.4 Pentesting Flash Application

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
Adobe Flash is a technology used to create video, animations
and other rich content. Flash files can be used as standalone
applications or be embedded in HTML pages.
The contents can be developed using several tools: Adobe
Flash Professional (the most popular), Flash Develop, Ajax
Animator, Flash Minibuilder, etc.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


To build the logic of the application, Adobe provides a
scripting language called ActionScript. This language is based
on ECMA-262 specs and is very similar to JavaScript.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


As opposed to other scripting languages, Flash ActionScript
needs to be compiled before execution. The compiled object
is in SWF format (Shockwave Flash).
Once compiled, it is very difficult to obtain the exact source
code of the application. Many commercial tools known as
Flash decompilers have been built for this purpose.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Examples of commercial decompiler:
• Sothink Flash decompiler
• Trillix Flash decompiler

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


To embed a Flash animation within a web page, you can use
an object element with type application/x-shockwave-
Flash. Here is an example:

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


The HTML page can embed the Flash animation and specify a
param element with the attribute allowScriptAccess to
describe the policy for communication between the
animation and the parent HTML page.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


allowScriptAccess can have three values:
• Always
• The SWF file can always communicate with the HTML page regardless of the
domain(SWF can be on a domain A and communicate with domain B).
• sameDomain
• The SWF file can communicate with the HTML page only if they share the
same domain.
• Never
• The SWF file can never communicate with the HTML page

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


There are three methods by which you can pass arguments to
Flash files.
Let us have a look in the coming slides.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Method 1 – Direct reference

Flash is not embedded in an HTML page and arguments are


provided directly through the URI. When the browser directly
loads the URI, a dummy HTML page is created.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Method 2 – Flash Embedded in HTML page

Flash is embedded in an HTML page and arguments are


passed through the attribute data of the object element.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Method 3 – FlashArgs attribute

Flash is embedded in the HTML page and arguments are


passed through the attribute FlashArgs of the object element.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
Sandbox and stakeholder are two important concepts in the
Flash security paradigm.
In this chapter, we will go through them while trying to both
depict the Flash security model and, how it impacts overall
web application security.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


By default, SWF files hosted on the subdomain
a.example.com can only access resources (SWF files, images,
sounds, text files, etc.) on a.example.com.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


The set of accessible resources comprises the Flash sandbox.
Access control is performed by stakeholders that can restrict
or retract the default policies.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


When a Flash animation is started by a player, different
security controls are performed at different levels.
Stakeholders describe different roles (human or not) involved
in the control of security settings.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


There are four stakeholders:
administrator, user, website, and
author. They make up a chain where
the administrator role is the first link
and the author is the last.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Flash security checks are performed, starting from the first
stakeholder (Administrator) and working to the last. An
operation fails when the first stakeholder in the chain blocks
it.
Each stakeholder can enforce security controls using different
means. In the following chapters, we will have a look at each
stakeholder role more closely.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Who:
The Administration role is represented by the system
administrator responsible for the Flash player installation.
They can configure Flash security settings that will affect all
operating system users.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


How:
mms.cfg

• This text configuration file is read when Flash player starts. It allows administrators
to grant or restrict access to a variety of features. In Microsoft systems, it is
generally located in the directory system32\Macromed\Flash.

The Global Flash Player Trust directory

• Administrators can register SWF files as trusted for all operating system users. This
means that SWF files can interact with other SWF files and can load data from local
and remote locations.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Who:
The user role is represented by the operating system user
running a Flash animation through the player.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


How:
Settings manager, Settings UI

• The Settings Manager and Settings UI provide security-related options such as:
camera and microphone settings, shared object storage settings, settings
related to legacy content, and so on.

User Flash Player Trust directory

• Users can register SWF files as trusted. This means that SWF files can interact
with other SWF files and can load data from local and remote locations.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Who:
The website role is represented by the web server component
responsible for the delivery of the Flash animation and/or
Flash resources to the client. This role can decide if an
external SWF animation can interact (through ActionScript)
with data available on the web server.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


How: Policy File
A policy file is a file placed in a specific location on the web
server. This file is read by the Flash player; SWF files residing
on third party domains will use this to derive their access
rules, which they must adhere to.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Note that this policy file can grant or deny access to resources
stored on the current server enforcing the policy. The
resources that pertain to this access are: SWF (images, text
files, or other SWF files).

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Example 1

A SWF animation (on domain: A.com) tries to access external


resources (images and audio files) available on a different
domain (B.com).
The policy file (crossdomain.xml) on domain B.com will
determine if the operation is allowed or not.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
Example 2

A SWF animation (on domain: A.com) tries to access external


resources (text files and xml files) available on a different
domain (B.com).

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
Depending on the requested resource, ActionScript can
initiate two different types of connection:
• Document-based server connection for ActionScript objects
• Loader (to load SWF files or images JPG,PNG,GIF)
• Sound
• URLLoader (to load text or binary data)
• URLStream
• Socket connection for ActionScript objects
• Actionscript socket
• XMLSocket

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


This policy file is checked by the Flash player if it is a
document-based server connection. By default, when the
Flash file accesses external resources like images, text,
sounds, etc., Flash player looks for a file named
crossdomain.xml in the root directory of the server.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


This policy file is also known as the Master policy file. An
example of a URL policy file:

A SWF file can check for policy files in different locations by


calling the Security.loadPolicyFile() method.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Socket policy file

This policy file is checked by the Flash player whether or not it


is a socket connection. By default, the Flash player looks for a
socket policy file on port 843; we refer to this policy file as the
Master policy file.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Who:
The author role is represented by the developer of the Flash
animation. This role can affect the interaction between SWF
files available on different domains.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


How:
The API Security.allowDomain(<allowedDomain>)
grants permissions to the following features:
• Interaction between different SWF files (Flash Cross-Scripting)
• Display list access
• Event detection
• Full access to properties and methods of the Stage object

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


By default, an SWF file cannot access the ActionScript
properties and methods of another SWF file available on a
different domain.
Access is granted only if the accessed SWF allows the domain
of the calling SWF. To achieve this goal, the API call
Security.allowDomain() can be used by the accessed SWF
ActionScript.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Example 3

An external SWF animation (domain: A.com) accesses


properties and methods of another SWF file available on a
different domain (B.com).

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
When Flash animations are embedded in HTML pages,
ActionScript code (available in the SWF file) can call the
parent page’s JavaScript code by using the
ExternalInterface class.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


An example of JavaScript code execution launched by a Flash
animation (Flash.SWF):

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


When Flash animations are embedded in HTML pages,
JavaScript code can call Actionscript code included in the
embedded Flash file.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


In the following code, the Flash animation exposes the
sayHelloToJavascript method and the JavaScript function
getFlashMovie is used to obtain a reference to the
embedded Flash object (for the sake of simplicity, we are not
including their definitions).

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


The method has the following definition -
navigateToURL(URLRequest, [target]).
This ActionScript method is used to open a URL in the
window embedding the Flash file. It is similar to the
JavaScript function window.open. The function has an
optional second parameter - target. This parameter can be
used to specify where the URL should be opened (a given
frame, current window or a new window).

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


The parameter URLRequest can contain JavaScript code, such
as javascript: alert('Hello from Actionscript.'); in
this case, the JavaScript code will be run only if one of the
following conditions is true:
• the SWF file is a locally trusted file
• the target is the HTML page in which the SWF file is
embedded and the allowScriptAccess rules described
above apply
• the target and the SWF file are part of the same sandbox (they
are located in the same subdomain)
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
If input sanitization does not occur, this method can be
exploited by malicious users, allowing attacks on other users
through Flash applications.
You can see the entire set of documentation here.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Flash features an internal storage mechanism based on Local
Shared Objects. Conceptually, Local Shared Objects are
similar to browser cookies:
• They can be used to track user activity or to store preferences.
• They are read only by subdomains that have set them.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


However, there are also some significant differences:
• They are not sent back and forth over HTTP connections.
• They do not expire.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


• They are stored in a dedicated Flash directory, and are shared
by all browsers on a system.
• Example: a local shared object set through the Mozilla browser by a domain
example.com can be read by a Chrome browser (installed on the same
machine) visiting the same domain. (Cross-browser access.)
• Path in Windows 7: C:\Users\<user>\AppData\Roaming\Macromedia\Flash
Player\#SharedObjects\
• They can contain complex (and large amounts of) data, so
they offer the advanced features of local storage.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


To create or retrieve a local shared object with ActionScript:
var myCookie:SharedObject = SharedObject.getLocal("information");

If the shared object information exists, its properties are


retrieved and saved into the object myCookie; otherwise, an
empty sharedObject will be created.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
A Flash Parameter injection vulnerability occurs when:
• The attacker can insert malicious code into the web
application.
• The web application passes the input provided by the attacker
to the Flash animation without any significant sanitization.
• The Flash animation, embedded in the HTML page, does not
sanitize input parameters.
• The SWF source code allows HTML injections or XSS.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Attack in action

The following example shows a simple web application


vulnerable to this type of attack. index.php and flash.SWF
are two web application files involved in the attack.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Index.php

This is the container page. This file processes an input


argument named site (taking it from the URL of the received
request).
User input in this case is passed to the embedded Flash
without sanitization.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Flash.SWF

This file contains ActionScript code which processes the input


argument without any sanitization. Flash code uses the site
input argument to replace the current window. But if the site
argument contains JavaScript code, it will be run as if it was
executed from the container page (index.php).

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


How do you exploit this vulnerability?
If you want to read cookies set by the current domain (where
index.php is located), you should use the following payload:

site=javascript:alert(document.cookie);

This is a simple XSS attack run through Flash.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


SWFinvestigator is an interesting tool which allows
researchers use to analyze the quality and the security
aspects of SWF files.
It contains a fuzzer that searches for XSS vulnerabilities.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Features:
• Actionscript 2/3 disassembling
• SWF tag viewing
• Local Shared Object (LSO) analyzing
• Dynamic function calling

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
As we said earlier, Flash contents need to be compiled before
they can be run. Many Flash developers believe that it is
impossible to obtain the source code of the Flash application
once compiled. They are often misled by this idea, and may,
in turn, hardcode information:
• URLs of hidden resources
• Resources that should be hidden to regular users
• Credentials of services

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


An attacker could use a decompiler to decompile the SWF
files, obtain the source code and find credentials and other
useful information.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
The following is a brief walkthrough of the security checks to
perform when you encounter a Flash component on a
website.
Main areas to check are:
• Client side components (SWF files and container page)
• Communication protocol between the client side player and
the server side components
• Server side components

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Static analysis of the SWF source code
• Obtain the source code of the SWF files and search for
interesting hard-coded information (URL, credentials info,
etc.).
• Check if input parameters are sanitized.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Analysis of the container page (generally the HTML page
containing the Flash SWF file):
• Check the allowScriptAccess parameter.
• Check if input arguments that will be passed to the Flash are
sanitized.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Analysis of the website hosting the Flash application
• Check if the policy file (crossdomain.xml) is configured
properly.
Search for common vulnerabilities
• If input is not sanitized, you must check whether an attacker
can take advantage of it. Check for common vulnerabilities
(HTML injections, XSS). You could use the SWFinvestigator’s
XSS fuzzer.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


A complex Flash application may make use of web services.
So, each request could be sent according to a given protocol:
• SOAP
• AMF
This step is fundamental because it allows you to define the
structure of the requests (including your payloads) that you
need to use to check server-side components.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


In order to enumerate all backend functions (services) we
have to test each of them against common server-side
vulnerabilities (SQL injections, RFI, etc.).

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Display List Access Event Detection

Full access to properties Controlling outbound


and methods URL access

OWASP Flash Security


Project

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Flash

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015


Flash
In these Flash labs, the student
can practice tool and techniques
against a flash web application.

Powered by TCPDF (www.tcpdf.org)


Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

You might also like