Adobe Flash (formerly Macromedia
Flash) is a multimedia platform originally acquired by Macromedia and
currently developed and distributed by Adobe Systems. Since its
introduction in 1996, Flash has become a popular method for adding
animation and interactivity to web pages. Flash is commonly used to
create animation, advertisements, and various web page Flash components,
to integrate video into web pages, and more recently, to develop rich
Internet applications. Source: en.wikipedia.org/wiki/Adobe_Flash Conventionally, RIA developed with Adobe
Flash technology consists of a frontend application compiled as an
SWF/AIR object to be executed by the Flash Plugin inside the User’s
Browser or the AIR Platform installed on the User’s System. This
interactive application provides a user Interface to the end-user and in
turn communicates with a backend server for its business logic over
protocols like HTTP/AMF, HTTP/SOAP, HTTP/REST etc.
Similar to any widely used web
application and software, a RIA can also be a victim of most common and
dangerous security Issues. For example, since most Flash based RIAs are
backed by an application for its business logic which in turn uses a
database, a Flash based RIA might also be vulnerable to common
application vulnerabilities like SQL Injection if user input is not
sanitized properly. Quite logical huh?. Attackers can also utilize Flash
to execute mass exploitation, for example backdoors or malware entirely
written in Flash/ActionScript or BOFs against player/plugin or browser.
It is quite general to deduce that
security flaws may also be present in the core environment (which
includes the OS and web browsers) that can be exploited regardless of
the applications (including Flash Player) running in that environment. A recent paper
from Adobe suggests that the approach of Adobe is to implement robust
security within its own products while “doing no harm” to the rest of
the environment (in other words, to introduce no exposures to the rest
of the environment, nor allow any avenues for additional exploitation of
any existing platform security weaknesses).
This provides a consistently high level of security for what Flash applications can do (as managed within Flash Player), regardless of the platform. Because Adobe products are also designed to be backwards-compatible when possible, some environments may be more vulnerable to weaknesses in the browser or operating system, or have weaker cryptography capabilities. Ultimately, users are responsible for their choices of platforms and maintenance of appropriate operational environments.
Vulnerabilities in flash RIA can be broadly classified under two categories: client side vulnerabilities and server side vulnerabilities. Let’s review each one of these very quickly:This provides a consistently high level of security for what Flash applications can do (as managed within Flash Player), regardless of the platform. Because Adobe products are also designed to be backwards-compatible when possible, some environments may be more vulnerable to weaknesses in the browser or operating system, or have weaker cryptography capabilities. Ultimately, users are responsible for their choices of platforms and maintenance of appropriate operational environments.
Client Side Vulnerabilities
Amongst the various vulnerabilities that might affect a Flash Application on the client side, some of the most common ones are:
Flash parameter Injection:
It might be possible for an attacker can inject global Flash parameters
when the movie is embedded in a parent HTML page. These injected
parameters can grant the attacker full control over the page DOM, as
well as control over other objects within the Flash movie. There is nice
detailed paper by the IBM Rational guys on this vulnerability. You can
download it here.
Cross Domain Privilege Escalation:
Cross Domain inter-mixing of content and data is done based on access
policy defined in crossdomain.xml of the serving domain for the SWF
object. If the access policy is too open, then under certain
circumstances, it might be possible for an attacker to supersede the
original SWF object with his own malicious version or access the DOM of
the hosting domain.
Cross Site Scripting: Depending on access policy, a Flash SWF can access its host DOM for various functional use cases. A Flash SWF can in turn modify the DOM of its host and if it does so based on un-sanitized user input, it might be possible to perform a conventional XSS attack on the host DOM.
Cross Site Flashing: Cross Site Flash (XSF) occurs when an SWF objects loads another SWF Object. This attack could result in XSS or in the modification of the GUI in order to fool a user to insert credentials on a fake flash form. XSF could be used in the presence of Flash HTML Injection or external SWF files when loadMovie methods are used. OWASP has a testing guide for XSF. Although not comprehensive, still it is a very good point to start. Read it here.
Server Side Vulnerabilities
Flash Applications seldom makes remote calls to a backend server for various operations like looking up accounts, retrieving additional data and graphics, and performing complex business operations. However, the ability to call remote methods also increases the attack surface exposed by these applications. Flash Applications built with Adobe Flex SDK usually use AMF Objects exchanged over HTTP Protocol as a method of communication.
AMF Remoting calls are essentially RPC like calls where the Flash Application is calling a given method defined on the server on a specific AMF Endpoint. An attacker can intercept and tamper the AMF data to compromise the server.
Testing Flash Applications: Objectives and Approach
A Flash Security Testing exercise for a Flash Based RIA is conducted with the following objectives:
- Identify the application entry points and test for possible vulnerabilities in the SWF Object itself.
- Identify the remote server with which the application might communicate for its business logic requirements.
- Identify the protocol with which the SWF Object is communicating with its back-end server. In most of the cases, the protocol will either be SOAP/REST or AMF.
- Identify and enumerate all the functionalities exposed by the back-end application.
- Penetration Testing of the individual functionalities exposed by the back-end application for standard application security vulnerabilities.
Client Side Testing
Client side primarily relates to static analysis of the flash application. The idea of static analysis of a Flash SWF Object is to decompile the SWF file and attempt to do a white box testing approach by looking into the source code of the Flash SWF File. Basic approach to test client side vulnerabilities is :
- Decompile SWF files into source code (ActionScript) and statically analyzes it to identify security issues such as information disclosure (hard coded).
- Audit third party applications without requiring access to the source code.
- Common vulnerabilities includes hard coded login credentials, internal IP disclosure, etc.
- Apart from analyzing the SWF file, it is also important to analyze the code responsible for generating the HTML file that embeds the SWF object. Under certain circumstances in might be possible to manipulate the FlashVars variable through which SWF inputs can be influenced.
Server Side Testing
The best straightforward way to do a server side testing for flash based RIA applications are as follows:
1. Extract Gateway
- Load the flash e.g http://foo.com/bar.swf in a browser with service capture/burp proxy/charlesproxy running .
- Decompile the SWF using swfdump and grep the gateway patterns. Also get a list of all the urls in SWFdump.
- Try amfphp.DiscoveryService on all gateways using Pinta.
- Use Pinta for AMF calling even if the services and methods are manually entered and hence can be helpful in testing remote methods.
- If it fails try extracting them using regex from SWFDump using the following regular expression.
Services:–"\"([a-zA-Z0-9_]*)\"“ with filter as “service” (conventional)
–"destination id=\"([\\w\\d]*)\"“
- Use Pinta to call remote methods using different test parameters.
- Single quote (SQL injection), neighbor parameters (Direct Object Reference).
Checklist of Vulnerabilities to be tested
- Cross Site Scripting
- Malicious Data Injection
- Insufficient Authorization Restrictions
- Secure Transmission
- SWF Information Leak
- Minimum Stage Size for Anti-ClickJacking
- SWF Control Permission
- Untrusted SWF in Same Domain
- Clickjacking
- Privilege Seperation
- Cross Domain Policy Audit
- Uninitialized Variable Scanning
- Remote Method Enumeration
- Business Logic Testing
http://gcattani.github.io/201303/flash-testing-for-dummies
Tidak ada komentar:
Posting Komentar