Posts tagged "Pwn2Own"

Reflections on Pwn2Own

Returning from CanSecWest left me reflecting on how the Pwn2Own competition has evolved over time. A lot has changed in the Pwn2Own competition over the years. The event has grown in attendance, competitors, and complexity, just as the industry has grown.

For the first contest in 2007, no one competed on the first day. Shane McCauley called fellow security researcher Dino Dai Zovi in NYC that night and urged him to compete. Dino was able to write the exploit over night and win the contest on the second day. Visually, the attacks seem no different from year to year. The contestant sits down at the machine, and “seconds” later the calculator (or notepad in this year’s case), pops up on the screen.  However, the preparation for the attacks from 2007 to 2016 are now drastically different, with contestants preparing attacks weeks in advance.

Media coverage around security advisories is often just a run down of how many CVEs a vendor released that month. People often imply from these articles that all the CVEs are easily exploitable and trivially weaponizable. This can lead to false perceptions that exploiting the software is a simple task. In reality, a CVE from a vendor is not a guarantee of exploitability. Even if the CVE can give the attacker the ability to overwrite memory, that is not a guarantee that it can be weaponized. Technologies such as ASLR (Address Space Layout Randomization) weren’t even released for Mac OS X when Dai Zovi competed in 2007. Today’s attackers have to work around defenses such as CFG (Control Flow Guard), Isolated Heaps, and a number of other technologies designed to prevent a crash from becoming an exploit.

In addition, competitors have to deal with the fact that the contest frequently occurs after Patch Tuesday where a vendor’s security improvements could interfere with their attack. Adobe has been aggressively adding mitigations to Flash Player over the last few months. In our release the week before the contest, we added changes to zero memory more often and leveraged the Windows’ low fragmentation heap. Both Adobe and Google found that some of the contestant’s entries overlapped with recent security reports. Part of the reason for the increasing payouts for the winners comes from the fact that the targets for the competition all have active security teams and external communities that are constantly working to improve the platform. As the community and vendors continue to mature their software, bug or mitigation collisions become more of a material risk for competitors. While it may not seem like it on the surface, the attackers are trying to hit moving targets.

The Flash Player updates prior to the contest led to some failed attempts at the competition. The failed attempts were by teams who had already won under different categories. Therefore, the competitors were clearly highly skilled and had already proven themselves to be capable of weaponizing exploits for the target platform. The reality is that what they are attempting to do is not easy and the failures serve to remind us how hard it is to get those wins. When any competition gets to a certain level, even the most skilled players are going to experience some losses.

That said, the contest always has its share of winners. Those wins demonstrate that there is always more that vendors can do in order to improve security. While the individual bugs help, Pwn2Own is truly valuable because it shows how different researchers will try to bypass the existing mitigations to create the fully weaponized exploit. That insight into different attack approaches inspires us as vendors to come up with the next generation of defenses.

Like many pros, the winning contestants always make it look easy. Although, as an industry we are often too quick to lump everything in the same “it is easy because it is completely vulnerable” bucket. Companies like Adobe, Microsoft, and Google are in a constant sprint with attackers. The security industry has progressed from the days of just trying to write clean, well validated code. Today, we are adding in large platform features that serve no other purpose than trying to thwart attackers. These types of features are added at an increasingly frequent basis. The companies who are on the front line of this battle will change and grow over time. It is important for those vying to one day be on the defender’s side of Pwn2Own to understand the current table stakes.

Overall, Pwn2Own is a fun contest to interact with security researchers and to push the industry forward. Beneath the high level pageantry of smoking jackets and large prizes, is a low-level escalation between offensive and defensive strategists. While the visual results from watching in the room seem similar from year to year, the innovation and challenge required to achieve those results increases every year.

Peleus Uhley
Principal Scientist

Adobe @ CanSecWest 2015

Along with other members of the ASSET team, I recently attended CanSecWest 2015, an annual security conference held in Vancouver, Canada.  Pwn2Own is also co-located in the same venue as CanSecWest (a summary of this year’s results can be found here).  This was my first time attending CanSecWest and I found that I enjoyed the single-track style of the conference (it reminded me of the IEEE Symposium on Security and Privacy, which is also a small, single-track conference, though more academic in content).

Overall, there were some great presentations.  “I see, therefore I am… You” presented by Jan “starbug” Krissler of T-Labs/CCC (abstract listed here) detailed methods of using high resolution images to create techniques for authenticating to biometric systems, such as fingerprint readers, iris scanners, and facial recognition systems.  Given the advancements in high resolution cameras, the necessary base images can even be taken from a distance.  One can also use high resolution still images, such as from political campaign posters, or high resolution video.  Using such images, in some cases one can directly authenticate to the biometric system.  In one example, the face recognition software required the user to blink or move before unlocking the system (presumably to avoid unlocking simply for still images); however, Jan found that if you hold a printed image of the user’s face in front of the camera and simply swipe a pencil down and up across the face, then the system will unlock.  Overall, this presentation was insightful, engaging, and generally amusing.  It highlights how more effort needs to be placed on improving the security of biometric systems and that they are not yet ready to be solely relied upon for authentication. I recommend that those interested in biometric security watch this presentation once the recording is available (NOTE: there is one slide that some may find objectionable).

The last day of the conference had multiple talks about BIOS and UEFI security.  The day was kicked off with the presentation entitled “How many million BIOSes would you like to infect?” presented by Corey Kallenberg and Xeno Kovah of LegbaCore (abstract listed here, slides available here).  They showed how their “LightEater” System Management Mode (SMM) malware implant could operate with very high privilege and read everything from memory in a manner undetectable to the OS.  They demonstrated this live on multiple laptops, including a “military grade” MSI system that was running Tails via live boot.  This could be used to steal GPG keys, passwords, or decrypted messages.  They also showed how Serial-over-LAN could be used to exfiltrate data, including the ability to encrypt the data so as to bypass intrusion detection systems that are looking for certain signatures to identify this type of exploit.  Their analysis showed that UEFI systems share similar code, meaning that many BIOSes are vulnerable to being hooked and implanted with LightEater.  The aim of their presentation was to show that more attention should be put forth towards BIOS security.

When conducting application security reviews, threat modeling is used to understand the overall system and identify potential weakness in the security posture of the system.  The security techniques used to address those weakness, also rely on some root of trust, be that a CA or the underlying local host/OS.  This presentation highlights that when your root of trust is the local host and you are the victim of a targeted attack, then the security measures you defined may be inadequate.  Using defense in depth techniques along with other standard security best practices when designing your system can help minimize the impact of such techniques (for instance, using service-to-service authentication mechanisms that have an expiry, are least privileged, and limit server-side the source location of the client, so that if this exploit happens to the host, the service authentication token is not useful from an external network).

Todd Baumeister
Web Security Researcher

The Evolution of Exploit Sophistication

When we look at the exploits that Adobe patched from February and March of this year, it is clear that today’s zero-day exploits are increasingly more sophisticated. This increase in sophistication is not limited to the skills needed to find and exploit the vulnerability. The code used to exploit the environment is also more robust in terms of code quality and testing. In short, exploit creation today requires the same level of rigor as professional software engineering projects.

Today’s advanced exploits need to be written to work in any target environment. For instance, February’s Reader 0-day supported 10 different versions of Reader with 2 sub-versions dependent on the end-user’s language. In addition, Flash Player CVE-2013-0634 had shell code for Windows XP, Vista, Windows 7, Server 2003, Server 2003 R2, Server 2008 and Server 2008 R2 as well as supporting six versions of Flash Player. Variants of CVE-2013-0634 also supported Firefox and Safari on Mac OS X. An exploit developer would need a robust testing environment to ensure that the exploit would work in that many different environments for each version of Flash Player. The exploit writers even took into account different CPU architectures by including a signed 32-bit payload and a 64-bit payload. This reflects the fact that these exploits are written with professional code quality and stability requirements for distribution across a dynamic target base.

As vendors are increasing software defenses through techniques such as sandboxing, attackers are now combining multiple vulnerabilities from different vendors to achieve their goals.When I look at the reports from Pwn2Own and some of the recent zero-day reports such as CVE-2013-0643, attacks are moving toward combining vulnerabilities from multiple products, some of which are from different vendors. We are moving away from the model of single vulnerability exploits.

This is all a part of the natural evolution of the threat landscape and the commercialization of exploits. This will require an equal evolution on the part of vendors in their software defences. Karthik Raman and I will be discussing this topic, “Security Response in the Age of Mass Customized Attacks,” in more detail at the upcoming Hack in the Box Conference (HITB) Amsterdam next week. Please stop by our talk if you would like to discuss this further.

Peleus Uhley
Platform Security Strategist