Last updated at Tue, 22 Aug 2017 15:07:01 GMT

Flash as a Vulnerability Vector

While Adobe has made great progress in releasing both regular and emergency updates to Flash, it's becoming clear that Flash itself is becoming an albatross around the neck of every browser. This week, Adobe released APSB15-14, a fix for CVE-2015-3133. This cross-browser vulnerability was discovered and reported by FireEye, and like all the recent critical Flash vulnerabilities, it can enable an adversary to completely compromise a targeted desktop. Meanwhile, we're shipping two new Flash Metasploit modules written by our own Juan Vazquez: One for CVE-2015-3105, disclosed earlier this month, and CVE-2015-3090, disclosed in May of 2015. I expect we'll be seeing a public exploit for penetration testers for CVE-2015-3113 soon.

This all leads me to believe that the risk introduced by Flash is too big to pretend to ignore. It's enabled by default with pretty much every consumer browser, and very few normal users are aware that it's even possible to disable it. Enterprise IT organizations are also unlikely to disable Flash on a site-wide basis precisely because it's so ubiquitous, and there is a fear that doing so would "break the Internet" for their constituents. It seems to me that Flash is lagging behind every major browser when it comes to security engineering, and because of this, the good security work going into stock browsers is getting undermined by Flash's always-on, always-default de facto status. Today, Flash is a favored vector for both online criminals and Pwn2Own competitors.

Doesn't this all sound a little familiar? Two years ago, Java is was in exactly the same boat. The Internet user base was suffering through a seemingly endless series of critical Java bugs, IT shops felt like it was impossible to disable, and Oracle was not making significant headway against the onslaught of both legitimate and criminal security R&D forces targeting Java.

While Java is still a lingering problem, browsers today have Java locked under a "click-to-play" procedure by default, where user interaction is required for any Java applet to run, and many, if not most, IT organization recommend or require disabling Java on the desktop completely.

Can we do the same with Adobe Flash? According to cybercrime investigator Brian Krebs, it appears absolutely possible. After taking a vow of Flash celibacy for a month, Krebs found that Flash is not nearly as ubiquitous for multimedia content as it used to be, thanks to competing technologies like HTML5's suite of multimedia functions. Major video content sites like YouTube and Netflix generally do not require Flash at all. It is quite possible to default-disable Flash for most sites, enabling it for just one or two trusted sites where there is no alternative, and enable a similar click-to-play requirement for running that Flash content.

Of course, this is all an arms race, and I have no doubt that in two years, we'll all be wringing our hands about the next seemingly ubiquitous Internet technology. But, we have an opportunity today to learn from our own recent history, and I hope we, as a security community, take it.

New Modules

This week brings us five new modules. First, we've two Flash exploits discussed above, a local privilege escalations exploit which was also used in a Flash-based targeted campaign (so says FireEye in their blog from April). Over in auxiliary and post land, there's a new pair of Windows info leak auxiliary modules. One is for remotely dumping memory via the HTTP.SYS vulnerability MS15-034, which is kind of a big deal. The other is a new domain-level hashdump post module that's super handy for quickly snarfing all domain credentials on a compromised domain controller.

As usual, you can peek in on the changes this past week with this compare view on GitHub.

Exploit modules

Auxiliary and post modules