Adobe Flash vulnerabilities and exploits have worried users and security professionals for many years. The situation today remains serious. A quick search of the National Vulnerability Database shows 277 vulnerabilities reported in Flash Player since 2011. For Flash zero-day attacks (which means that there was no patch from Adobe when the vulnerability was exploited), researcher Chris Evans provided a useful spreadsheet tracking all of them in recent years (except for the recent CVE-2014-9163). Since 2011, 21 Flash zero-day attacks have been disclosed, and that doesn’t count those exploited in the wild soon after Adobe’s patch. On average, there are about six Flash vulnerabilities per month, and every two to three months we have seen a Flash zero-day attack. Flash threats are not only Flash exploits; because Flash works as a plug-in to browsers, vulnerabilities in browsers can sometimes be exploited with the aid of Flash. This usually happens with Microsoft Internet Explorer. Previously, we have seen IE zero-day attacks involving Flash, such as the IE CVE-2014-1776 zero-day attack in April 2014, and the IE CVE-2013-3163 zero-day attack in July 2013.
At McAfee Labs we have performed leading research on Flash for quite a long time. During the last couple of years, we have analyzed every Flash-related threat. We were the first security vendor to successfully identify the modern exploitation technology on Flash Player, which we named Flash Vector Spraying, in February 2013. This advanced technology soon became the leading exploitation method used in many Flash and IE zero-day attacks to defeat address space layout randomization and data execution prevention on Windows 7 and later operation systems. You may have read about the technology talking about zero-day or watering-hole attacks.
Flash is a complex application. From a research point of view, the Flash Player binary Flash32_xx_xx_xx.ocx is about 16MB without any symbols, which makes it really hard for researchers to reverse-engineer the application. Thus it’s not easy to analyze and debug Flash exploits. The core script engine on Flash–the ActionScript language–is extremely flexible, but this flexibility makes it almost impossible to deliver meaningful signatures against malicious Flash contents.
What about sandbox-based detection, you ask? Yes, sandboxing is cool and has attracted a lot of attention in the industry. However, once you understand how the bad guys make Flash exploits, you won’t think sandboxing is such a good idea. First, a Flash exploit–especially for targeted or advanced attacks–may work on only one or some versions of Flash Player that are vulnerable. Flash Player has frequent updates; there are many Flash Player versions. Thus it would be really hard for a sandboxing solution to set up the vulnerable version for any potential Flash exploit. A sandboxing solution that can’t trigger the exploit code is ineffective. Second, due to their nature, sandboxing systems are offline solutions, and cannot prevent malicious Flash exploits by blocking these attacks inline, in real-time. Third, Flash content is so common on the Internet that running all the Flash content in a sandbox would likely introduce performance problems and thus harm the usability of a sandbox solution as well as the user experience.
Considering these challenges, we find the best way to fight Flash exploits is with the traditional “static” approach, aided by some innovative ideas based on our in-depth understanding of how Flash exploits work, as well as the nature of Flash compilers. From a product perspective, the static approach is useful because it’s the fastest solution and users expect the highest performance. In addition, it’s quite easy to integrate our detection engine with many of our security products. Our approach is to detect malicious exploitation operations not based on signatures or patterns, and our engine effectively detects and stops zero-day (or any unknown) attacks related to Flash content. We tested our in-the-Labs engine with all samples involved in all previous Flash and IE zero-day attacks when they came out, and none of them could evade our detection engine. Here is a short list of the zero-day attacks and their typical in-the-wild Flash samples, and we detected all of them at the time they appeared.
Concerned about our customers’ experiences, we have performed quite a lot of large-scale tests against real-world Flash samples from both our internal and external VirusTotal sample databases. Based on the results, we are confident that our solution will balance the effectiveness, performance, and false-positive rate very well.
During the past 18 months, our research and engineering team has been busy implementing the engine and integrating it into our Network Security Platform (NSP). With the release of NSP Version 8.2, we are excited to announce the availability of this feature. Our NSP customers may refer to this page for information regarding this release.
We are excited about this advanced and innovative feature for combating Flash exploits, and we hope our customers will share that excitement, too. We strongly suggest our NSP customers try this feature and give us feedback regarding your experience. Because the feature can recognize zero-day attacks, we also encourage our customers to share the intelligence when they detect unknown samples.
Protecting our customers from threats–advanced or otherwise–is our mission. The McAfee Labs IPS team, part of Intel Security, continues to work hard to maintain its leadership in this field.
Thanks to Chang Liu and Winny Thomas, who made special efforts for this product feature.
The post An Advance You Won’t Want to Miss: McAfee Adds Flash Exploit Detection to NSP 8.2 appeared first on McAfee.