Pwn2Own - The Root of Research

Over the last decade of Pwn2Own™ competitions, different people harbored different emotions towards the contest. It’s been referred to as a blood bath for browsers, although no actual blood has ever been spilt over the years. It has helped launch people’s careers, or at the very least, it has helped increase their notoriety. It’s been accused of crushing souls of fanbois and haters alike. Again, no fanbois or haters were harmed throughout the contest’s history, although we make no claims on their souls. There are also more serious claims that Pwn2Own represents nothing more than “security theater” – they call it a good show, but claim it doesn’t really show anything. If anything, the exact opposite is true. Over the last 10 years, Pwn2Own has become the root of security research.

It’s not just that exploits used during Pwn2Own are complex. They certainly are. Several of the bugs disclosed through program received accolades from the community, such as Pwnie awards. More than that, the bugs that appear during Pwn2Own drive the research of others and ultimately provide mitigations from vendors. For example, several years ago, use-after-free (UAF) vulnerabilities were used to exploit browsers – especially Internet Explorer. This led to many other researchers finding UAF and reporting them to the ZDI program. The flood of UAF cases resulted in Microsoft introducing mitigations like Isolated Heap and MemoryProtection to prevent many of these UAFs from working. This lead ZDI researchers to study the mitigations in depth where they found a few issues. These findings became a submission to the Microsoft Mitigation Bypass Bounty and an award of $125,000 (all given to charity).  Would UAFs have been as popular without Pwn2Own? Perhaps, but their inclusion in the contest certainly drove research in that area, with the end result being a more secure browser. Of course, we haven’t just seen UAFs. Various types of bugs have been used throughout the years, all of which became commonplace (or at least more prevalent) after appearing in the contest. Bugs like sandbox escapes, junction point manipulation, control flow guard (CFG) bypasses, and font abuse have all taken their turns.

The vendors are responding though. If nothing else, additional defensive measures likethe suppression of win32k system calls has made exploitation more difficult. In the first Pwn2Own, a single bug was needed to exploit QuickTime. This past year, a winning submission from 360Vulcan Team started off with a bug in the Google Chrome renderer. From there, they pivoted to use two Flash UAFs. After that, they targeted the Windows kernel with a kernel object UAF. In other words, it took four bugs in three different products from three different vendors to successfully attack Google Chrome and elevate their permission to the SYSTEM level. That’s progress.

Another thing setting Pwn2Own apart is the need for a complete exploit chain. Researchers don’t need full, working exploits when submitting bugs to vendors. Even when submitting bugs to the ZDI program, a full proof-of-concept isn’t always required to get paid (although we highly encourage it). The contest is different. Pwn2Own requires researchers to develop exploits from start to finish. And let’s clear something up – despite what you may have read, it takes significantly longer than 30 seconds to exploit these pieces of software. The exploit itself may only take 30 seconds to execute, but significant time – often hundreds of hours – has been spent developing the exploits used during the contest. It just happens quickly during the public phase, which is what everyone sees. Don’t discount the substantial amount of time it takes to get to that table at CanSecWest ready to run code.

This year, we’re incorporating targets we haven’t included before in previous Pwn2Owns: Linux, enterprise applications, and server-side exploits. Will these lead to a new category of attack similar to UAF? Probably not. It usually takes about a year for researchers to catch up to new targets. In 2014, systems with EMET installed were considered “exploit unicorns.” In 2015, every successful exploit had to – and did – evade EMET. In 2016, we introduced a category for VMWare escapes. Will we see exploits this year that traverse from guest to host? We certainly hope so, and we look forward to seeing everything else that shows up too. Follow us here and on Twitter for the latest information and results from the contest. Better yet, join us in person at CanSecWest to see the contest for yourself. You never know what new research will be unveiled.

©2017 Trend Micro Incorporated. All rights reserved. PWN2OWN, ZERO DAY INITIATIVE, ZDI and Trend Micro are trademarks or registered trademarks of Trend Micro Incorporated. All other trademarks and trade names are the property of their respective owners.