Martin's Blog

Security testing flash applications with AMF

Adobe Flash has become a popular platform for implementing rich internet applications (RIA). While the Flash Player itself has been plagued by numerous remote code execution vulnerabilities over the years, the security testing of Flash-based web applications introduces a different set of challenges altogether.

Unlike traditional web applications, Flash applications often communicate with backend services using binary protocols, making interception, inspection, and modification of traffic significantly more difficult.

This post provides an overview of Flash application internals, the ActionScript Message Format (AMF), and describes how we developed a custom AMF plugin for WebScarab can simplify the testing of Flash-based applications.

The Adobe Flash ecosystem

The Adobe Flash ecosystem consists of several components

ActionScript Message Format (AMF)

Most complex Flash applications need to talk to a server. They typically use AMF to exchange data between the client and the server-side component.

AMF is an asynchronous RPC (Remote Procedure Call) mechanism. Native Flash objects are serialized into binary data, sent to the server, and deserialized back into objects.

The Remoting Envelope

When you capture a Flash request, you aren’t just seeing raw data; you are seeing a “Remoting Envelope.” A typical packet consists of:

  1. Preamble: Indicates the version (0 or 3).
  2. Header(s): Contains metadata, names, and serialized AMF objects.
  3. Message(s): The core payload containing the Target URI, the Response URI, and the actual Data (serialized AMF object).

The Raw Request: Here is what the traffic looks like in a standard sniffer—mostly unintelligible binary noise:

The Decoded Request: If we parse the binary structure properly, we can see the object hierarchy:

The Text Representation: The human-readable text values hidden inside:

Lack of Tooling

Testing these applications requires an interception proxy that can parse and modify this binary data. Unfortunately, the current landscape is lacking:

The biggest issue is the lack of write support. Most tools allow you to read AMF, but they do not allow you to easily edit a parameter and re-serialize the packet correctly. Previously, the only workaround was to write a custom “wrapper” Flex application to act as a client, which is time-consuming and inefficient.

WebScarab AMF extension

To solve this, we have developed a custom extension for the WebScarab framework. WebScarab supports a plugin infrastructure, allowing us to override the default behavior.

Our new plugin offers significant improvements over the standard AMF support:

References