Cross-Site Flashing

Description

Cross-Site Flashing is a vulnerability caused by the flash content embedded inside a Web application trying to load flash content from another domain based on user’s input without any validation. This SmartAttack injects the flashvars of flash content and tries to detect whether it embeds malicious flash content without any validation.

Impact

If an attacker succeeds in embedding his flash content inside a Web application, he would be able to perform attacks like Cross-Site Scripting and also steal sensitive information. He may be able to change the user interface of a Web application to trick the user into providing his sensitive details.

When the Web application is vulnerable to the Cross-Site Flashing, the attacker could leverage the fact that his flash content would run with similar privilege as that of the legitimate flash content on the vulnerable Web application. Attacker could further exploit this fact to bypass access controls and perform harmful actions like stealing confidential data, installing malware etc.

How It Works 

Cross-Site Flashing is a vulnerability exploited by an attacker by hosting his malicious flash content on the Web application and then launching further attacks. This may also be used as an ‘enabler’ vulnerability to execute Cross-Site Scripting or Clickjacking attacks on the Web application.

Flash content can accept parameters from ‘flashvars’. If these flashvars are referred while embedding any external flash content, an attacker could exploit this by crafting a link pointing to the vulnerable flash content which will then embed his malicious flash content. One example of such link could be http://host.com/vulenrable_flash_content.swf?flashToEmbed=<path to malicious flash content>. If a user clicks on such a link, the vulnerable flash content would load the attacker’s flash content which could be used by the attacker for malicious purposes.

Exploit

A frequent tactic used by malicious Websites is to provide a link or popup containing an offsite link to vulnerable flash content which then embeds some malicious flash content. When the user clicks on this link, a request is sent to flash content that will embed the malicious flash content which can be programmed to launch further attacks like Session Hijacking or Cross-Site Scripting.

Flash contents can take user defined inputs from HTTP URL query strings like

http://host.com/vulenrable_flash_content.swf?flashToEmbed=<path to malicious flash content

In the above example, if the target flash content is not validating any input from “flashToEmbed” and loading the flash content given there, an attacker can point this parameter to his flash content which will get loaded eventually. This content would have access with similar privileges as the target flash sandbox. The attacker could pre-program his flash content to run javascript such as document.cookie to steal session information stored in cookies and send a request with this data to himself.

Technical Description

Tests with this SmartAttack inject a URL which makes vulnerable flash content load custom flash content hosted on Cenzic’s server. This SmartAttack identifies a failure when it detects evidence of an alert generated by the Cenzic owned flash file.

This SmartAttack can fault inject flashvars which are used while embedding flash content. Because it injects all such fields, it may cause problems with the application or database bloat. Hence, it is not safe to be used for applications that are live.

This SmartAttack works with all kinds of traversals. The SmartAttack walks the traversal and identifies flash files which are candidates for fault injection. For each candidate flash file, the SmartAttack sends a series of fault-injected requests, trying to load malicious flash content inside it.

The SmartAttack can also be configured to vary the timeout before checking whether the malicious flash content was successfully embedded or not.

To Use

1.        Create a traversal that represents the target application, or a subset of specific pages in the application.

2.        Create a new assessment or open an existing assessment.

3.        Add the traversal created above to the assessment.

4.        Add this SmartAttack to the assessment.

5.        Set the parameters or accept the defaults in the assessment. (See below.)

6.        Run the assessment.

To Verify

Here are the steps to be followed to manually verify a vulnerability reported by this SmartAttack:

1.        First observe the “Item details” tab of the report item and note the “Injectable field”.

2.        Double click the report item and click on the URL shown in the upper part of the window, or click on ‘Render Response’.

3.        If an alert is observed, the vulnerability is verified. This alert is generated by a flash file hosted on Cenzic’s server. “Injectable field” mentioned above is the vulnerable field.

Parameters

Optional

Timeout Duration (integer)

Specifies the number of milli seconds to wait and see if a target application is embedding injected flash content.
The default value is “5000”

Advanced

Max Traversal Restarts (integer)

This parameter controls whether and how many times a fault injector will attempt to restart a traversal if fault injection interferes with replaying the traversal. The parameter can be set to “0” to prevent the traversal from being restarted.
The default value is “0”.

Start SmartAttack After Traversal (Boolean)

This is an advanced parameter that controls whether the SmartAttack processing (concurrent browsing, in this case) begins during the traversal or after the traversal has completed. The default is false, meaning that the processing will start during the traversal. In cases where traversals are unable to complete due to the effects of SmartAttack processes during concurrent browsing, setting this parameter to true will postpone concurrent browsing until after the traversal has completed, which allows all of the injectable requests in the traversal to be collected and injected after the traversal is over. While this allows all of the concurrent browsing to occur, it might not occur in the same context or state that it would have during the traversal.
Default = “false”

 

Report Messages

Pass: “No Cross-Site Flashing vulnerabilities were found”.

Vulnerability: “Cross-Ste Flashing vulnerabilities were found”.

Remediation

The following recommendations will help to mitigate the risk of Cross-Site Flashing:

·         Avoid loading external flash content based on user input given in “flashvars”. But if it is unavoidable, employ strict checks of input validation in the flash content code.

·         If loading external flash content is unavoidable, your flash content should maintain a white list of domains, content from which is allowed to be loaded.

·         Object tag embedding a flash movie should not have AllowScriptAccess set to ‘always’. Value of AllowScriptAccess should be either ‘sameDomain’ or ‘never’. Also, value of AllowScriptAccess should be explicitly set. Default value should not be used.

 

References

Secure SWF Applications:
http://www.adobe.com/devnet/flashplayer/articles/secure_swf_apps.html

How to restrict SWF content from HTML:
http://blogs.adobe.com/stateofsecurity/2007/07/how_to_restrict_swf_content_fr_1.html