Tag Archives: Content Spoofing

sIFR3 Cross Site Scripting

 

WhiteHat Security Vulnerability Advisory

Affected Product:   scalable Inman Flash Replacement (sIFR) version 3

Vulnerability:   Cross Site Scripting

CVE ID:   CVE-2011-3641

Affected Versions:   sIFR3 r436 and prior

Vendor Homepage:   http://wiki.novemberborn.net/sifr3/

Description:   sIFR3 allows for the use of non-free fonts within a web application via Adobe Flash plugin. The sIFR3 module interfaces with an external JS file and utilizes the parameter “version” to ensure the two files are compatible. The textField that is displayed upon invalid input in the “version” parameter supports limited HTML rendering and allows for remote code execution Cross Site Scripting. An attacker can render arbitrary images that execute malicious javascript and in Adobe Flash player 10.3 and prior include a large break space to remove the encapsulating error message.

Proof of Concept:

/cochin.swf?version=<a href="javascript:confirm(document.cookie)"><img src="Attacker_Image.jpg"/></a><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/>

Fix:  

Recompile any affected modules with the latest release (r437) which can be obtained from the vendor’s website: http://dev.novemberborn.net/sifr3/nightlies/sifr3-r437-CVE-2011-3641.zip

Editor’s note: Portions of this blog, including the headline, were edited by the author on December 9 after a CVE was assigned and the correct name had been given to the vuln.

Vulnerabilities in a Flash

 

Flash Player-related vulnerabilities currently account for approximately 14% of all Web application vulnerabilities discovered by WhiteHat Security. This statistic is surprisingly high considering that HTTP Archive reports 47% of Web applications are currently using Flash technology.

Flash Media Player is an effective method for delivering stylish vector graphics across multiple platforms to enrich a Web user’s experience. When properly designed, Flash makes a website visit interactive and fun. Unfortunately, Flash can also introduce vulnerabilities to an otherwise safe application. Many Flash developers are primarily designers who may have some programming experience, but little – if any – knowledge about Web security.

Flash Player itself has many security restrictions and policies, but users often misunderstand them – or even purposely disabled them to get a particular feature to “work.” Among many Flash designers, there’s also a common misconception that the Flash framework will provide all the protection their applications need.

One of the most frequent comments I get about Flash vulnerabilities is, “Doesn’t my cross-domain policy file protect me from that problem?” Well, the cross-domain policy file does prevent cross-domain data loading for execution; but it is a unidirectional permission that the server hosting the data file grants. The permission does not come from the Flash file. Some people may find the cross-domain policy file to be “backwards” compared to what they expect, and in many attack scenarios the Flash file will first seek permission from the attacker’s domain before initiating the attack.

Flash Player has an in-depth security sandbox model based on the domain where the Flash file is embedded, and I will discuss the scenarios for when a sandbox policy applies and how that policy can be bridged or bypassed – but in a later blog post. In this post I’m going to focus on the simplest and most prevalent method used today on the Web to exploit Flash files – unsanitized FlashVars.

FlashVars

Flash Player supports several methods to declare variables that are to be used in the resulting content. The two most common techniques are: (1) to declare FlashVars in a related javascript block,  or (2) via the param tag within an embed. A third, and sometimes overlooked, method to declare variables is by directly referencing them in a URL query string. Many Flash designers build their projects based primarily on flexibility in order to allow greater customization and wider distribution, but these “features” often allow attackers to make their own customizations – and then exploit the  application.

Typical banner ad with FlashVars to specify remote image and link:

<object>
<param name="movie" value="swf/banner.swf" />
<param name="img" value="image1.jpg" />
<param name="link" value="http://www.whitehatsec.com" />
<embed src="swf/banner.swf" flashvars="img=image1.jpg&amp;link=http://www.whitehatsec.com" />
</object>

Attackers link to SWF:

http://www.example.com/swf/banner.swf?img=http://web.appsec.ws/images/WH.jpg&link=javascript:confirm('Session%20Information%20Sent%20to%20Hacker');//

 

FlashVars with HTML Support

If a Flash file is compiled for HTML support for a given textbox, then an attacker can inject a limited subset of HTML characters to achieve remote code execution. Flash framework supports two main HTML tags that are of interest to an attacker: ANCHOR and IMAGE. A simple SWF file that reflects user input can be used to execute malicious javascript when a user clicks on the file.

Attackers NameTag:

http://www.example.com/swf/nameTag.swf?name=<a href="javascript:confirm(1)">Haxor</a>

 

Server Filter Bypass

With the exception of Internet Explorer, Flash Player will evaluate a query string behind a hash character in all browsers. When a URL query string is placed behind a hash character the browser will not forward the query string with the request for the Flash file, thus allowing an attacker to bypass any attempt at server filtering.

http://www.example.com/flash/main.swf#?text=WhiteHat+Security,+Inc.

 

Internet Explorer Sandbox Bypass

When directly rendering a Flash file in Internet Explorer the browser will first construct an encapsulating document in the DOM to embed the Flash file. The browser will then put in place a security restriction so that the related content will have no access to the related DOM information of the current domain. As in many Microsoft programs, this was a brilliant concept, but the QA performed was inadequate to ensure that it became an effective security measure. So the fact is, if a Flash file containing malicious javascript is reloaded, it will immediately bridge the security control and give an attacker access to the DOM. The victim clicks once, which initiates the reload; then, thinking nothing has happened, clicks the second time – and gets owned.

 

Redirection

A recent Flash 0-day that allowed an attacker to submit arbitrary HTTP headers to an application was the result of an unhandled 307 redirection from a domain controlled by an attacker. Flash Player has always had limitations handling HTTP responses if it receives anything other than a 200 OK. The problem stems from lack of insight into how a given HTTP request is handled by the Web browser. Firefox 4 contains a new API that hopes to remediate this issue by providing additional insight for browser plugins. If a Flash file utilizes an external configuration file an attacker can bypass any attempt to restrict data loading from a given domain if the domain also contains an open redirection. The Flash file will verify that the initial request is for a trusted domain, but will load the malicious configuration file residing on the attacker’s domain.

 

Proof of Concept

The following video demonstrates the common issue of Flash files targeting external XML configurations via FlashVars without properly validating the XML file that resides on a trusted domain. Camtasia Studio’s popular presentation software was used to produce the video, which shows the vulnerabilities present in Camtasia’s own ExpressShow SWF files. The developer of the files, Techsmith, has addressed this issue with a patch that must be manually applied (available via Techsmith Security Bulletin 5). The patch restricts generated Flash files to loading XML configurations that reside on the same domain as the Flash file.

[youtube]http://www.youtube.com/watch?v=cDAefrArPyo[/youtube]

 

References

HTTP Archive
Guya.net – Flash Bug in Internet Explorer Security Model
OWASP Flash Security Project

 

 

Jason Calvert @mystech7
Application Security Engineer
WhiteHat Security, Inc.