The Prevalence of Flash Vulnerabilities on the Web

Transcription

1 TECHNICAL BRIEF FLASH FLOODING The Prevalence of Flash Vulnerabilities on the Web Adobe Flash Player is a cross-platform, browser plugin that provides uncompromised viewing of expressive applications, content, and videos across the Web. According to the HTTP Archive, which is a repository of Web performance information, almost half of current Web applications use Flash Player technology (Figure 1). This number has gradually declined over time, especially with new technologies such as HTML 5, but the HTTP Archive still shows many developers rely on Flash for effective content delivery. With such widespread use of Flash technology specifically for advertising networks, site introductions, and navigation the security implications and the potential risks for vulnerability exploitation are very high. But just what percentage of Flash usage actually results in Web application vulnerabilities? The use of Adobe Flash Player involves significant risks to websites that every user should consider... When looking at Web applications, nearly 22% of websites have at least one Flash vulnerability (Figure 2). No Flash 53% Flash 47% Flash Vulns 22% No Flash Vulnerabilities 78% Source: HTTP Archive - Figure 1. Web Application Flash Utilization Source: WhiteHat Security Statistics Figure 2. Web Applications with Vulnerable Flash TECHNICAL BRIEF: FLASH FLOODING AUGUST

2 This means that 46% of applications with Flash have a potential security flaw that can be directly attributed to the fact that they utilize Flash technology. Further, when comparing Flash vulnerabilities in relation to general Web application vulnerabilities, Flash accounts for almost 12% of application security flaws. FLASH VULNERABILITIES Remediation Rates Over the last decade Flash-related vulnerabilities have consistently maintained a remediation rate of half the rate compared to other Web application vulnerabilities (Figure 3). One contributing factor may be the common practice of outsourcing the media-rich design associated with Flash development to a third-party that generally focuses on dynamic flexibility for redistribution. Another possible factor may be attributed to the fact that Flash Player is a browser plugin and may not fit into the security model of the encompassing application. Due to the client-side rendering of Flash modules, any attempt at filtering input on the server can be trivially bypassed by an attacker directly targeting the module. 100% 0% 21% 41% 34% Within the Last Year The Last Decade 61% All Vulns Remediated Flash Vulns Remediated Not Remediated Figure 3. Remediation Rates External Configurations for Dynamic Content A common use of Flash technology is to display a dynamic slideshow of images with support for featurerich user interaction to replace static content. To provide the dynamic functionality in a reproducible fashion, many modules utilize an external configuration file that details the location and behavior of how the module will be rendered. Unfortunately, it s an extremely common oversight of many developers to forget to include validation when parsing the configuration file, which allows attackers to replace the configuration file with one of their choice and thus exploit the module. Depending on the extent of the functionality of the module, this can usually lead to JavaScript execution within the domain hosting the Flash file. Image and Link Hi-Jacking Many ad networks use flashy ads with variables to specify content or target-location users, who will be redirected when they interact with the Flash module (usually a portal to track link clicks). If the parameters are TECHNICAL BRIEF: FLASH FLOODING AUGUST

3 not validated for acceptable values, an attacker could alter the Flash file and redirect the end user to a site of the attacker s choice. Unsuspecting victims may think they are booking a trip to the Bahamas, when they are really sending an attacker their authentication tokens. Timed Redirection Abuse or Use of ExternalInterface Many Flash vulnerabilities may require a little bit of social engineering or phishing to get a user to interact with vulnerable Flash file. If a Flash module utilizes a timed redirection based on an unvalidated parameter an attacker may achieve an exploit without any interaction required from the intended victim. Another big concern is the use of unvalidated calls to a Flash module s ExternalInterface, which serves as the bridge between a Flash file and the Document Object it s embedded in. If an attacker can influence a call to the ExternalInterface, it s the same as direct JavaScript manipulation. Client-Side Obfuscation or Validation Occasionally, Flash developers will include sensitive information or validation in their modules with the assumption that an attacker couldn t reverse-engineer their software. Passwords or other sensitive data should never be validated client-side with a Flash module. A classic example of validation that should have taken place on the server is a Flash module that validates the quantity and price for purchases. Savvy attackers could proxy the request when the order is submitted to the server and apply their own Hacker discount. EXAMPLES OF FLASH VULNERABILITIES FusionChart Content Spoofing and XSS Many frameworks are available to end users for general use across the Web. FusionChart is one framework used by many applications, providing a variety of graphs and charting functionalities for end-user applications. The issue with frameworks is that many end users inadvertently allow an attacker to directly alter the configurations for these charts. By essentially rendering the content within that application to execute JavaScript, the attacker is then able to redirect a user to an arbitrary domain of the attacker s choice, while having that domain appear to be hosted by the original application. Scalable Inman Flash Replacement (sifr) V3 sifr3 is a Flash module that renders text directly to an application, which then allows the use of non-free fonts that the client s browser may not support. (Source: sifr3 Exploit The Flash module is typically the name of the font, which is then embedded within the Flash. The module then encapsulates an external JavaScript file, which it references to ensure that both the JavaScript file and the Flash font are from the same version. Wherever there s a cool idea, there s always a cool bypass. So, this bypass is CVE , which pertains to the recent version of the sifr3 module release 436 (sifr3 r436). The parameter version is used to validate that the current module is compatible with the related JavaScript library, and, if provided invalid input, renders the content within the module. An attacker can abuse this functionality to render arbitrary HTML within the error message, and to include images or execute malicious JavaScript. TECHNICAL BRIEF: FLASH FLOODING AUGUST

4 Flash Output Encoding When the vendor was contacted concerning this issue, it decided to abandon the project as outdated since the establishment of HTML 5. Because it was an open-source project, a look at the source showed that all it was missing was an encoding method prior to rendering user input to ensure an attacker couldn t execute arbitrary JavaScript : XMLNode(3, _root.version).tostring(); Patch To download the patch for Scalable Inman Flash Replacement (sifr), please visit: (Source: novemberborn.net/sifr3/). If you recompile your current modules, this patch will help resolve the Flash Output Encoding issue. Flowplayer Exploit Flowplayer is a common third-party FLV player that is highly customizable through the use of additional plugins. The problem is that to support plugins on various domains, the module was intentionally designed to break the default security sandbox imposed by Flash Player. An attacker can specify arbitrary Flash modules with the full ability to execute malicious script within the parent domain. Overview of Cross-Domain Policy One of the most common misconceptions among developers is that none of the hacking methods described above is possible due to their cross-domain policy file. That s because many developers view cross-domain policy filing as the end-all solution to every Flash problem they encounter. Unfortunately, that is a very big misconception. In fact, the cross-domain policy will always fail to work the way that people expect it to work. The way Flash policy actually works is to dictate which content can be binarily evaluated within the current domain. So if a policy file is not specified, that file defaults only to the most secure settings of the domain. An overly permissive policy file essentially allows an attacker to remotely view any content within an application. So when an open policy file contains sensitive information within the user s profile, an attacker can view the response from that user s request. A tool was created that demonstrates both the implications of an overly permissive cross-domain policy file and the ways such files can be abused. TOOLBOX A flex module, currently hosted on web.appsec.ws, allows users to examine the policy restrictions imposed by a given domain. The file allows for GET or POST (different HTTP methods), as well as subdirectory policy files. So, if there is a sub-policy file that is authorized by the root, that file can be targeted. The tool also supports the inclusion of custom HTTP headers, if allowed by the target domain. The tool was used to validate the previous 0-day pertaining to Flash redirections on 304 responses that utilized the policy file from the initial domain, but allowed custom HTTP headers to be submitted to an arbitrary domain. TECHNICAL BRIEF: FLASH FLOODING AUGUST

5 CONCLUSION With almost half of today s Web applications using Flash Player in one format or another, it is the Internet s most-used tool for viewing content, watching videos, and performing many other on-site interactions. However, on the downside, the remediation rate for Flash Player vulnerabilities tends to be only about half the rate compared to the remediation rate of other vulnerabilities. This combination of Flash Player s prevalent use and the risks associated with using it requires that Web developers be aware of those risks in order to assure the safety of their websites from attack, as well as the security of every user who visits their sites. Jason Calvert is an Application Security Engineer and senior member of WhiteHat Security s Threat Research Center. He is responsible for the service delivery of WhiteHat Sentinel Source a Static Application Security Testing (SAST) solution and R&D of Web application security testing techniques. Mr. Calvert has been acknowledged several times by Google in their Security Hall of Fame. He is a contributor to the Adobe SWF Investigator project and author of the Flash Exploit Database. Mr. Calvert received a BS in Network Information Security from Saint Cloud State University in Minnesota and currently resides in the San Francisco Bay Area. Founded in 2001, and headquartered in Santa Clara, California, WhiteHat Security provides end-to-end solutions for Web security. The company s cloud technology platform and teams of expert security engineers turn verified security intelligence into actionable insights for customers. Through a combination of core products and strategic partnerships, WhiteHat Security provides complete Web security at a scale unmatched in the industry. WhiteHat Sentinel, the company s flagship product line, currently manages thousands of websites including sites of leading companies in the most regulated industries, such as top e-commerce, finance and healthcare. WhiteHat Security, Inc Freedom Circle Santa Clara, CA Copyright 2012 WhiteHat Security, Inc. Product names or brands used in this publication are for identification purposes only and may be trademarks of their respective companies