Client : ThinkstScapes TrialAugust 2012

ThinkstScapes Ad-hoc Information Update 2012 / AH3

BlueHat Prize

info@thinkst.comresearch@thinkst.comhttp://www.thinkst.com

BlueHat Prize‣ Introduction‣ Overview‣ BlueHat Prize‣ Runtime Focus‣ Competition Targets‣ Entrants‣ Winning Submissions‣ Implications‣ ROPGuard Bypass‣ Conclusions

IntroductionON July 26 2012, Microsoft handed out USD 260,000 in cash to three security researchers. Whereas the typical vendor expects vulnerabilities in exchange, Microsoft instead forked out the money as a prize in a competition designed to attract defensive techniques. That competition was the BlueHat prize, and in this Ad-hoc update we review the prize, examine the entrants and winners and ask how this will make a difference to

organisations both in the short-term as well as into the future.

OverviewWe cover the BlueHat prize by looking at its background, comparing it to other prize and competitions in the industry, and lay out criticisms of the competition. We then examine the prize’s focus on runtime mitigations followed by a brief overview of ROP and address space information disclosures bugs. Thereafter the entrants are examined, the winners described and the implications of the prize enumerated.

Client: ThinkstScapes Trial 2 / 11

The explosion of security events worldwide means that industry participants are increasingly swamped by speakers vying for our attention. Ad-hoc updates are sent out to customers throughout the year as events worthy of notice transpire. Ad-hoc updates are usually brief, bursty and bustled out while events unfold. This Ad-hoc update was created and distributed under the ThinkstScapes subscription service for ThinkstScapes Trial, and is not intended for redistribution. Please contact thinkstscapes@thinkst.com for customer or sales queries.

ThinkstScapes Ad-hoc Information Update2012 / AH3

BlueHat Prize

BackgroundIn 2011 at BlackHat USA, Microsoft announced a search for new ideas in the fight against exploits that rely on memory corruption vulnerabilities, in the form of a public competition with substantial prizes for the winners. The competition was an interesting move by Microsoft as it could be interpreted in a number of ways. With the significant resources available at both Microsoft and Microsoft Research, the solicitation of techniques from the public could be viewed as a tacit admission that new ideas were needed, and that Microsoft’s own ideas engines had run out of fuel. On the other hand, the Linux community has seen the benefit of small teams working on specific exploit mitigation schemes (e.g. PaX1 and grsecurity2), and in that light the engagement of the public research community was a shrewd move by Microsoft as it created a space for small (or even loner) research teams to contribute to Microsoft’s exploit mitigation techniques. Though not without criticism (discussed shortly) the competition appears to be an honest attempt at including public researchers who would typically complain should Microsoft release mitigation tools without seeking public comment. Microsoft has stated3 that the BlueHat prize was inspired by the X-Prize.4

Entrants to the competition had to provide a write-up of their idea to limit memory corruption exploitation at runtime, as well as provide a working prototype that demonstrated the idea. In particular, acceptable entries had to “design a novel runtime mitigation technology solution that is capable of preventing the exploitation of memory safety vulnerabilities.”5 The prototype was subject to technical limitations, such as not introducing more than 5% overhead, absent of third party libraries, little impact on compatibility or usability and reliant on the Windows SDK only.Prizes were to be allocated as follows:

‣ First prize, USD 200,000.‣ Second prize, USD 50,000.‣ Third prize, subscription to MSDN valued at USD 10,000.They were judged by an unnamed panel drawn internally from various Microsoft organisations (Windows, Microsoft Research and MSEC), according to the following criteria: practicality (30%), robustness (30%) and impact (40%).6 Would-be submitters were given eight months to create and submit their ideas, with the competition ending on April 1, 2012. The ideas were then evaluated, and the winners announced at BlackHat USA 2012, in July of this year.

Other competitions and prizesThe lure of prize money to extract ideas from researchers is not new; bug bounties are a staple of many software projects and have been used by software vendors (e.g. Mozilla and Google for bugs in Firefox and Chrome respectively) as well as by security firms. The ZDI has purchased the details of many exploits over the years,7 including for 5-digit amounts in USD, and the short-lived WabiSabiLabi auction website tried to create a 0day marketplace.8 These all tried to match a value to an exploit or vulnerability.

ThinkstScapes Ad-hoc Information Update 2012 / AH3 IDIDID

Client: ThinkstScapes Trial 3 / 11

1 http://pax.grsecurity.net/

2 http://grsecurity.net/

3 http://risky.biz/RB249

4 http://www.xprize.org/

5 http://www.microsoft.com/security/bluehatprize/contest.aspx

6 http://blogs.technet.com/b/srd/archive/2012/07/26/technical-analysis-of-the-top-bluehat-prize-submissions.aspx

7 http://www.zerodayinitiative.com/

8 http://www.wslabi.com/

PaX  is  a  leading  defense  

technology  for  Linux

$260,000  is  about  a  foot  of  stacked  $100  bills

Pwn2Own9, while not the first hacker competition by a long shot, captured the imagination of the wider world; hack a laptop and keep it. The competition has evolved, and competitors now get both hardware as well as cash for their submissions.However, all these rewards discussed so far focus on the attacker side of the equation, without any recompense for introducing new defensive techniques, and Microsoft is known for never having paid for vulnerabilities. The reasons for the lack of rewards for defense researchers are not clear, but one obvious issue with defensive advancements is that they generally take longer to develop; where an exploit can be banged out in a number of hours or days, a defensive technology must take into account a wide variety of operational environments which makes testing long and tedious, and this does not augur well for the part-time or casual researcher. Combined with the fact that defensive researchers are often employed vendors with a vested interest in keeping new ideas in-house where they can be turned into products and sold, the landscape for defense competitions is barren. The counteraction to this tendency is to make the prize lucrative enough that entrants choose to submit their idea, rather than turn it into a product, or entice part-timers to spend their free time on their entry.One significant recent addition to the landscape has been DARPA’s Cyber Fast Track (CFT) program,10 managed by former member of the L0pht Peter Zatko (“Mudge”). CFT functions as an incubator, providing small amounts of funding to research projects in the information security space. Multiple awards are made on a regular basis for work in both offensive as well as defensive spheres. While proposers aim to be accepted, they do not directly compete against one another as the number of awards is not fixed.Takeaway: Microsoft’s BlueHat prize is a unique attempt to garner new ideas for improving their security, by rewarding innovation in defense rather than trying to purchase vulnerabilities that have already been found.

CriticismNegative comments appeared soon after the competition was announced. They primarily covered three separate concerns:11

1. All submissions were subject to the terms of the competition, not just the winning entries.

2. As a condition of entry, Microsoft was granted a royalty-free license to the ideas, regardless of whether the entry was a prize-winner (this follows from the condition above). Ownership of the idea remained with the author.

3. The prize money was too low considering the potential impact a successful entry would have on Microsoft’s eco-system.

All of these were valid. Microsoft received 20 submissions which averaged out to USD 13,000 per entry12 and the total prize constituted about 0,002% of Microsoft’s USD 9,8 billion R&D budget in 2012.13

Takeaway: In spite of the objections, 20 entrants were received which indicates that the terms were acceptable to numerous parties. However, as will be seen, the entrants did not include many notable industry veterans.

ThinkstScapes Ad-hoc Information Update 2012 / AH3 IDIDID

Client: ThinkstScapes Trial 4 / 11

9 http://en.wikipedia.org/wiki/Pwn2Own

10 http://www.cft.usma.edu/

11 http://www.subreption.com/blog/the-blue-hat-prize-a-late-april-fools-joke/

12 http://www.microsoft.com/security/bluehatprize/

13 http://www.microsoft.com/Investor/EarningsAndFinancials/Earnings/FinancialStatements/FY12/Q4/IncomeStatements.aspx

Pwn2Own  winner  celebra@ng

Complaints  emerged

Runtime FocusThis inaugural edition of the BlueHat prize specifically targeted runtime mitigations for memory corruption defense. Previous exploit mitigations focused on static checks and additions, including:

‣ Data Execution Prevention‣ Stack cookies with /GS‣ ASLR‣ Exception handler checking with /SafeSEHThese must generally be enabled at compile time (except for DEP, though DEP makes assumptions about what an application does with its stack). By switching focus to runtime mitigations, Microsoft is providing a clear indication of the diminishing returns in the arena of static analysis and defense. If one looks at the lead taken by the PaX/grsecurity projects (who have both consistently innovated in the field of exploit mitigation), their techniques generally rely on code changes to the runtime environment, though typically through a compiled code change (e.g. additional randomisation for all memory allocation, removal of commonly used information sources and additional permission checks). It is thus unsurprising that the BlueHat prize sought to stimulate similar research on the Windows side, by introducing mitigations that could be rolled out without significant changes to Windows internals.Takeaway: Attention is turning to runtime mitigations.

Competition TargetsIn the competition description, two possible examples of open problems were provided, though entrants were not required to address either one. The two examples were return-oriented-programming (ROP) and address space information disclosures. Both provide strong hints as to where Microsoft sees a dearth of innovative ideas, and where mitigations will have a strong impact against current exploits.Note that this section contains technical details, and can be skipped if one is more interested in understanding the the impact of the competition.

ROPReturn-oriented-programming (ROP) is a recent term for a set of techniques that emerged following a long gestation period that was seeded by Solar Designer’s 1997 ret2libc attack.14 In a classic stack-based buffer overflow, attacker-controlled machine instructions (or shellcode) are loaded into the stack memory region and then executed. In response to this, stacks were designated as non-executable areas (enforced in either hardware or software), and this meant that even if attackers could load instructions onto the stack, any attempt to execute the instructions would produce a fatal error. The neat trick that Solar Designer pioneered was based on the insight that a stack is used to pass data between functions; if an attacker can write arbitrary information to the stack then instead of placing instructions there, he can create stack entries that would cause functions to be executed, without having to write executable code. Thus a non-executable stack (also known as DEP on Windows) is bypassed by using ret2libc techniques.15

ROP extends this massaging of the stack to build even smaller chunks of code, by allowing an attacker to piece together small blocks of instructions rather than larger functions. Instead of working with a function whose purpose is, say, “execute this shell script”, a ROP exploit uses smaller pieces called ‘gadgets’, which perform fundamental tasks such as “increment the EAX register”, or “load data from the top of the stack into the address pointed to by the ECX register”. These gadgets are basic enough that it is possible to build a compiler that will convert a high-level exploit into a series of gadgets that are specific to the targeted

ThinkstScapes Ad-hoc Information Update 2012 / AH3 IDIDID

Client: ThinkstScapes Trial 5 / 11

14 http://seclists.org/bugtraq/1997/Aug/63

15 An attacker could also perform a stack-pivot, and create a completely new stack elsewhere in memory.

ROP Exploits are made from gadgets

application.16 ROP also showed that control of registers other than the instruction pointer could lead to exploitation in a generic manner (in this case, the stack register).The actual instructions in ROP gadgets are typically found in libraries loaded into the execution environment at fixed locations. When an application does not use ASLR, its libraries are loaded at predictable locations, and the offsets for the ROP gadgets thus become predictable. ROP exploits rely on knowing the location of gadgets, through pre-computation in almost all cases. An analogy sometimes used for a ROP exploit is the archetypical ransom note cut from different letters in a magazine, where the text is carefully sifted for the right characters which are then chopped out and pasted onto the note to form a completely different message. A ROP exploit uses bits of a program in a sequence completely unintended by the developer, to perform their malicious actions.From this, it should be apparent that by randomising the location of all code at execution, ROP exploits would fail as the location of gadgets would be unknowable. Where ASLR is implemented fully, ROP exploits are not possible. However, ASLR support in libraries and executables is subject to a compiler flag and, should the flag not be present, then the code would be loaded at a predictable location. Even if an application uses ASLR, a third-party library it relies upon may not and that library would be a source of ROP gadgets.Thus runtime mitigation of ROP was a significant target for the BlueHat prize, as it would instantly make legacy applications invulnerable to ROP exploits, without the need to recompilation.

Address space information disclosureIn certain classes of applications, ASLR may be enabled but DEP may be disabled, meaning that executable instructions can be loaded onto the stack. While not a common use-case for consumer applications, this technique is heavily used by programs that perform Just In Time (JIT) compilation. Browser plugins such as Adobe Shockwave or Oracle’s Java will convert applet byte-code into machine instructions in order to execute them, and rely on the stack to hold the newly created executable instruction sequences. DEP is disabled in the browser, to enable the plugins to correctly function. Assuming DEP is disabled, then an exploit could execute instructions directly from the stack if the address of the stack is known, as the very first exploit step would be to jump to the start of the shellcode. ASLR may well be enabled though, which eliminates the pre-loading of the stack address in the exploit.Instead, the attacker relies on two bugs. The first bug is simply an information leak which reveals the address of the stack. When stack’s address is recovered, the actual exploitable vulnerability can be attacked as the shellcode will be loaded with the stack’s current address. (Information leaks can also affect the heap, but we omit their description.) In the manner, an application that has DEP disabled but ASLR enabled can still be exploited, if an initial bug is found that reveals actual memory addresses.

Entrants

ProfilesOf the 20 entries received, 14 (70%) aimed at ROP mitigation, 2 at generic buffer overflows, 2 were unclear from their description and 1 focused on preventing heap sprays. None attacked the address space information disclosure problem, suggesting that this problem is still wide open.The sources of the entries made for an interesting read. While some of the names were recognisable as regular speakers or publishers in industry (Jared DeMott, Piotr Bania, Didier Stevens), a significant portion were young or up-and-coming researchers or students, and were not based in the US.17 This validates to a degree the criticisms that the prize money would not attract notable entrants; however, it also shows that

ThinkstScapes Ad-hoc Information Update 2012 / AH3 IDIDID

Client: ThinkstScapes Trial 6 / 11

16 http://media.blackhat.com/bh-us-10/presentations/Iozzo,Weinmann_Kornau/BlackHat-USA-2010-Iozzo-Weinmann-Kornau-Everybody-be-cool-this-is-a-roppery-slides.pdf

17 http://www.microsoft.com/security/bluehatprize/entries.aspx

there is as section of the industry for whom the rewards were attractive enough. That the competition produced new ideas was seen as a sign of success by Microsoft.18

Curiously, only one submission was entered by a group and all the remaining entrants were individuals.Takeaway: Researcher attention was focused primarily at ROP.

SynopsesMicrosoft released abstracts for each idea, and a fuller description for the three winners.17

The various ROP mitigations included relying on hardware features to implement ROP protections, software shims inserted to validate the call stack, compiler extensions to include anti-ROP checks, interception of stack-pivots to prevent exploits from relying on the heap and lastly by obfuscating API addresses. One particularly interesting technique suggests including a secret or token with each API call, to ensure that the API is called by an authorised call chain, with the assumption being that a typical ROP exploit would not have knowledge of the token and therefore would not be able to call the APIs. While the abstract does not address how the token is composed, generated and protected, it hints at the notion of separate trust zones inside an application.The Heap Spray protection involved a long-lived monitor process that attempted to detect when another process was being targeted by a heap spray and then write “safe” shellcode into that processes’ memory space that would hopefully be run by the exploit instead of the attacker’s shellcode.The buffer overflow protection abstract did not provide enough concrete details to summarise their approaches.

Winning submissions19

First Place: kBouncerAwarded to Vasilis Pappas for kBouncer. This solution exploits a hardware feature on Intel processes that provides a record of the last 16 code branches. The idea is that whenever a system call occurs, the kernel includes logic that verifies whether the branch record to that point indicates that a ROP exploit is underway by checking whether the branch was preceded by a CALL instruction.

The reliance on hardware meant that the technique would have limited performance impact, though not applicable on older hardware.

 

LeD:  Legi@mate  instruc@on  sequence.  Right:  Instruc@on  sequence  typical  of  a  ROP  exploit.

ThinkstScapes Ad-hoc Information Update 2012 / AH3 IDIDID

Client: ThinkstScapes Trial 7 / 11

18 http://risky.biz/RB249

19 http://blogs.technet.com/b/srd/archive/2012/07/26/technical-analysis-of-the-top-bluehat-prize-submissions.aspx

Microsoft does not expect the technique to remain robust in the face of attackers as the hardware record is limited, and attackers would likely be able to craft exploits that are not exposed within the last saved 16 branches. It is believed that the technique It will increase the difficulty level of writing current ROP exploits.

Second Place: ROPGuardIvan Fractic submitted ROPGuard, a series of additional checks inserted at runtime into critical functions such as VirtualProtect that test whether the environment appears to be safe. The tests include verifying the stack pointer value, status of the return address, partial execution simulation and function specific contract changes. Microsoft’s analysis of the entry holds that, while the techniques are not all new and some are shared with other submissions, this entry contains unique elements and is a superset of other submissions.What makes ROPGuard worthy of mention is that it was included in version 3.5 of EMET, Microsoft’s Enhanced Mitigation Experience Toolkit.20 released on the same day as the announcement of the winners. In other words, in 12 months Microsoft has sourced additional novel defensive techniques and rolled them out to customers, at the cost of a few senior developers.Similarly to the first place winner, this technique is not considered to be a comprehensive longterm solution to ROP.

Third Place: /ROPJared DeMott entered an proposed extension to the Visual Studio compile suite he named /ROP. This extension would add a whitelist of address which a return statement could jump to; at compile time the whitelist would be generated and inserted in the executable metadata, and at runtime a software interrupt would be triggered by each return statement and the address verified against the whitelist. This would mitigate ROP exploits that rely on return statements that jump to non-whitelisted addresses, but there are ROP exploits that would not be affected by /ROP. While ultimately introducing too much overhead, the approach hints that a hybrid defense in which runtime activity is based on compile-time annotations might be an additional research field.Winners Takeaway: All winners focused on ROP, with approaches that varied from hardware-feature reliant to compiler extensions.

Implications

The rise of the bountyRunning a defensive technology competition really only makes sense for vendors who sell customer-side platforms, which puts the approach out of reach for virtually all software vendors. However, the option of a bounty program remains and should not be quickly dismissed. We will discuss this in more detail, in an upcoming ThinkstScapes.

Is ROP Solved?No. This competition fostered additional research into ROP defenses, but none of the entries was a comprehensive permanent solution to ROP, and all suffer from one or more weaknesses. Microsoft have stated that they expect the cat-and-mouse game between attacker and defender to continue,21 and that these mitigations will not protect applications in the longterm. However, the mitigations will provide immediate coverage against typical current and past ROP exploits.

ThinkstScapes Ad-hoc Information Update 2012 / AH3 IDIDID

Client: ThinkstScapes Trial 8 / 11

20 http://support.microsoft.com/kb/2458544

21 http://risky.biz/RB249

It certainly is a datapoint worth noting; Microsoft spent USD 250,000 for partial protection but has not yet uncovered a full defense against ROP.Takeaway: None of the techniques completely solve ROP and they are not future-proof; however, they should provide protection against most current and past ROP exploits.

EMETThe extension of EMET shows that Microsoft will continue to support this tool, and we think it has great applicability not just for ROP mitigation but for locking down enterprise systems in general. EMET provides a range of protective measures that are individually configurable. While the default for many is disabled, it is easy for administrators to roll out protections across an enterprise, on a per-application basis.This gives administrators a tool to aid in defending their systems that is not dependent on exploit signatures and does not require daily updates. Administrators can perform an analysis and determine which applications expose their users to potentially harmful inputs (e.g. web browsers, email clients, document editing and viewing suites), and enable EMET protections on these. While EMET will not protect all applications equally, it is a big step in terms of extending an administrator’s defensive toolset.The integration of the ROPGuard features into EMET 3.5 signaled Microsoft’s intent at putting to use the license it paid for. Why the runner-up entry was used in place of the winner is subject to speculation; changes reliant on hardware features rely on a wider test sample and could have influenced the decision, as might the maturity of the proof-of-concept prototype supplied to Microsoft.Takeaway: EMET provides a powerful tool for limiting the effectiveness of unknown exploits, in contrast to signature-based detection tools. Important applications that broaden an organisation’s attack surface should be subjected to EMET restrictions where possible.

BlueHat prize futureAt this stage Microsoft has said they plan to repeat the competition. The prize structure is yet to be decided, and whether they will still target memory corruption mitigations remains to be seen, but they are confident of the value in the competition.22

ROPGuard bypassWithin two weeks of the release of EMET 3.5, a researcher had posted an exploit that was explicitly designed to evade the checks contained within EMET 3.5, and successfully performed a ROP exploit on an EMET-protected application.23 In a nutshell, the bypass was based on the fact that ROPGuard protected important APIs, but did not prevent an exploit from directly issuing system calls. Comments and articles24 (more sardonic than not) swiftly followed, highlighting with relish the apparent ease with which the trumpeted protection was circumvented.The point to keep in mind is that EMET’s ROPGuard does not completely prevent ROP, in the same way that DEP and ASLR did not prevent exploits in their time. Each refinement of a defensive technique makes exploitation a

ThinkstScapes Ad-hoc Information Update 2012 / AH3 IDIDID

Client: ThinkstScapes Trial 9 / 11

22 http://risky.biz/RB249

23 http://repret.wordpress.com/2012/08/08/bypassing-emet-3-5s-rop-mitigations/

24 http://arstechnica.com/security/2012/08/microsoft-defense-bypassed-in-2-weeks/

Bypass  blog  post

ROP  Tab  on  EMET  3.5  Tech  Preview

little more difficult, and decreases the number of potential attackers as the bar for exploitation is raised. EMET will be updated to include the bypass, and no doubt a follow-up bypass will be released after that. While at first glance this may appear to suffer from the same failing as signature-based AV, there is a difference: signature-based AV can be bypassed automatically and algorithmically. Bypasses for ROPGuard

involved human effort, which does not scale nearly as well. In addition, where malware can be permuted infinitely to bypass signatures, this particular bypass technique does not have infinite possibilities (though whether the performance hit that will occur by instrumenting all syscalls or APIs is acceptable, is another matter).Takeaway: EMET with ROPGuard will not prevent all ROP exploits and the bypass was to be expected. EMET will be updated, and a bypass to that update will appear, but that is not a valid reason to avoid EMET.

ThinkstScapes Ad-hoc Information Update 2012 / AH3 IDIDID

Client: ThinkstScapes Trial 10 / 11

The  TwiQers  were  amused

ConclusionMicrosoft’s BlueHat prize has introduced a new form of security bounty, that of a reward for defensive thinking. In the inaugural competition that targeted runtime mitigations of memory corruption vulnerabilities, which led to the majority of entrants focusing on ROP mitigations. All three of the winners presented various ROP reduction techniques which, while not ending ROP exploits, will make exploitation by means of ROP more difficult. A subset of the techniques was incorporated into Microsoft’s EMET tool.

This update was written by marco@thinkst.com and haroon@thinkst.com. Please contact us if you have queries or comments relating either to this report, or the ThinkstScapes service.

The explosion of security events worldwide means that industry participants are increasingly swamped by speakers vying for our attention. Ad-hoc updates are sent out to customers throughout the year as events worthy of notice transpire. Ad-hoc updates are usually brief, bursty and bustled out while events unfold. This Ad-hoc update was created and distributed under the ThinkstScapes subscription service for ThinkstScapes Trial, and is not intended for redistribution. Please contact thinkstscapes@thinkst.com for customer or sales queries.

ThinkstScapes Ad-hoc Information Update 2012 / AH3 IDIDID

Client: ThinkstScapes Trial 11 / 11