Microsoft’s Security Bounty Program

Microsoft has revealed details on its new bounty program for security research. Unlike a typical bounty program that just pays a researcher for finding a specific vulnerability, Microsoft is offering rewards for a broader range of attacks on mitigation techniques.

  1. Mitigation Bypass Bounty. Microsoft will pay up to $100,000 USD for truly novel exploitation techniques against protections built into the latest version of our operating system (Windows 8.1 Preview). Learning about new exploitation techniques earlier helps Microsoft improve security by leaps, instead of capturing one vulnerability at a time as a traditional bug bounty alone would. TIMEFRAME: ONGOING
  2. BlueHat Bonus for Defense. Additionally, Microsoft will pay up to $50,000 USD for defensive ideas that accompany a qualifying Mitigation Bypass submission. Doing so highlights our continued support of defensive technologies and provides a way for the research community to help protect more than a billion computer systems worldwide.TIMEFRAME: ONGOING (in conjunction with the Mitigation Bypass Bounty).

As you can see the focus isn’t about specific vulnerabilities, it’s about hardening mitigation techniques to prevent entire classes of vulnerabilities. A mitigation technique, such as DEP, prevents direct code execution. Another technique, ASLR, makes bypassing DEP more difficult by preventing Return Oriented Programming.

Flaws in these techniques can lead to bypasses, and these bypasses can be used across vulnerabilities, and therefor have a much larger impact.

Microsoft has done this before. In the past their rewards program has led to a series of new “Anti-ROP” techniques in the EMET program. Improving and adding to these techniques drives up the cost of every exploit.

Microsoft is also paying out for Internet Explorer 11 vulnerabilities:

  1. Internet Explorer 11 Preview Bug Bounty. 
    Microsoft will pay up to $11,000 USD for critical vulnerabilities that affect Internet Explorer 11 Preview on the latest version of Windows (Windows 8.1 Preview). The entry period for this program will be the first 30 days of the Internet Explorer 11 beta period (June 26 to July 26, 2013). Learning about critical vulnerabilities in Internet Explorer as early as possible during the public preview will help Microsoft make the newest version of the browser more secure. TIMEFRAME: 30 DAYS

IE11 is available on the Windows 8.1 Preview, and Microsoft is hoping that researchers can help break into it so they can gauge security. While solving individual vulnerabilities does not exactly add much to security, it does help developers behind IE11 see where attackers will go. If I were an IE11 developer, and I got a response from a dozen developers showing that they could break into my program through the Javascript Renderer, I’d know that I needed to really focus on securing that component, because it’s likely the easiest spot to attack. So while those patches themselves may not be making the program much more secure, the knowledge I gain from viewing trends will.

I’d like to see more bounty programs like this, but Microsoft is in the best position for it – a browser can’t always do much about mitigation techniques, as they have more to do with the operating system and compilers. I think a lot of good will come from this program.

New Anti-ROP From Microsoft

Microsoft held a contest for computer scientists to come up with new ways to stop Return Oriented Programming (ROP) – a  technique used by hackers that allows them to easily bypass Data Execution Prevention (DEP.) Currently the most common anti-ROP technology is ASLR, headed by PaX. ASLR attempts to randomize as much of the address space as possible, which makes it difficult for hackers to find code that they can use for ROP. ASLR leaves much to be desired as if any part of the address space is not randomized it’s enough for an attacker to craft a ROP attack. There will always be static areas of address space.

Other techniques like EAF aren’t great, better for legacy exploits. And I’ve written before about techniques for defeating ROP.

Microsoft’s competition yielded three ‘top’ contributions and while the details aren’t entirely revealed I’m gonna comment on each based on the very tiny amount of information provided.

First is Jared DeMott’s /ROP.

To understand it you should know that ROP basically works by taking the compiled library and controlling the order that it executes… sorta. It means that absolutely no new code needs to be added to exploit the system.

The idea of /ROP is to check return instructions. This seems like a great idea, after all, return oriented programming without the return… just doesn’t work.

Without details it’s hard to criticize except that you don’t need return instructions for ROP. You can use ‘return-like’ instructions, which can do the same thing and create exploits just as well. What about jmp?

It’s also a detection system and only works on *known* areas of ROP. That doesn’t sound like such a big deal but it really is. It doesn’t stop anything fundamental, not really, and it’s reactive.

 Ivan Fratric

Ivan’s works by labeling specific functions as critical for ROP. And when those functions are called a check is made.

This reminds me a lot of EAF. We’ll see how it works and if it works in the real world.

Again, detection.

Vasilis Pappas

No clue how this one will work out, not enough detail given at all to make any kind of statement.

If one could simple remove the ability to ROP with magic or some such thing it would force attackers to come up with entirely new methods of exploitation. ROP is the way to get into a system right now. Hopefully one of these really does the trick. Personally I don’t quite understand why specific libraries aren’t compiled without gadgets – there are a few universally static areas of the Windows OS, why not just remove the gadgets? I really don’t know, probably some patenting bullshit.

Hopefully one of these actually drives up the cost. There just isn’t a ton of information out there right now.

I’d love to see more of these types of bounties in the future. Not patches, actual new techniques.

Ubuntu Developer Responds To SecureBoot

I’ll preface by saying that this is not an official statement on behalf of Canonical as far as I know, simply a post on /r/ubuntu. The user is the Ubuntu Community Manager and his post about SecureBoot pretty much sums up my own opinions.

His post in its entirety: 

I think we would all agree that this is terrible that Microsoft are putting other Operating Systems in a position where either (1) they have to sign keys to boot, or (2) we have to ask users to switch off something in their BIOS that has “secure” in the title.

While mal-ware is indeed a threat, and quite nasty, I would have preferred to have seen a means in which a solution can be found that is not controlled by a large corporation who themselves has an Operating System product.

From an Ubuntu perspective, we are going to do everything that we can to ensure our OS boots on the widest range of hardware possible, and the story that Matthew Garrett tells is similar to our experiences in the Ubuntu world. Matthew’s story, and the challenges he has explored are not specific to Fedora, but to all Linux distributions.

I think the problem Microsoft is trying to solve is admirable…mal-ware at that lower level is dangerous, but I think the solution is putting companies like Canonical and Red Hat in a tough spot. [1]

This hits the nail on the head, really. Microsoft is trying to solve a problem and that’s great but in doing so they are putting distros and Linux users in a difficult place. As he says, it’s now a matter of supporting SecureBoot and paying VeriSign or asking users to disable a security feature.

One Final Post About SecureBoot?

I did a post highlighting the positive side of things and then a very negative M$$$-bashy type post. I want something I can point to that at least makes an attempt at fair and balanced with enough information for the reader to make a decision so here it is.

What Is SecureBoot?

SecureBoot is a UEFI protocol that blocks anything that isn’t digitally signed from running before the operating system starts. Essentially, untrusted code can not start before trusted code. This directly addresses an entire class of malware and attacks that we already see on systems in the real world. On a SecureBoot system the malware could not start up because it is not digitally signed.

Windows 8 (currently in Release Preview) uses SecureBoot by default on systems that have “Windows 8 Approved” hardware. This means that, by default, these systems will only boot code that’s been digitally signed.

You can disable SecureBoot on x86 devices but not ARM.

So How Does Linux Fit Into This?

Linux, in a SecureBoot environment, is considered untrusted code. It isn’t signed, therefor it can’t boot. Thankfully Microsoft has ordained that all x86 devices must allow the user to disable SecureBoot and users will also be able to sign software with their own keys. You can also purchase a Microsoft signature.

The problem is that, while Linux is not entirely locked out, it’s still discouraging. As a user you have two options:

1) Disable a security feature (potentially difficult to do)

2) Go through the procedure to sign your software with your own key (almost definitely very difficult to do)

And as a developer your options are:

1) Tell anyone who wants to use your OS to disable a major security feature (discouraging)

2) Pay 99 dollars to VeriSign for a Microsoft signature.

These options aren’t good. Microsoft has not locked Linux out but it’s now more difficult for small Linux distros to gain members and it’s more difficult for users to make choices about which distro to use.

And, to reiterate, Linux is entirely locked out of Windows 8 ARM devices.

It’s worth noting that other distros can not simply use Fedora’s bootloader. The entire chain of trusted software must be signed including kernels and modules. This is what complicates things for distros. I personally run my own kernel so this complicates things a ton for me as I now have to go through the process of signing my own kernel and modules and blah blah blah every damn time (well, not really, I don’t have EFI, but I would.)

So Is There A Bright Side?

There is, and in the spirit of fair and balanced I will delve into it.

SecureBoot is actually a really awesome feature. It prevents cold boot attacks* on disk encryption, it seriously restricts malware, and it’s actually implemented in an not totally horrible way (we can sign things! Way better than patchguard!)

*by preventing immediate loading of a livecd/usb for it. It also prevents bootkits, which bypass encryption.

Microsoft is actually subsidizing VeriSign keys so that they’re only 99 dollars (SSL certs can be 200-300 dollars and only last 1-3 years) so that’s pretty nice I guess…

And Linux distros are in fact already working on implementing SecureBoot, which will make transitioning to Linux (well, to some distros of Linux) as smooth as ever while still providing a really fantastic security feature. Fedora has already confirmed it’s working on it and Canonical is likely to announce the same soon.

SecureBoot is actually one of the better security protocols to come about. It’s not some silly little thing to block out mere theoretical attacks, it’s legitimately a strong layer of security.

How Should I Be Feeling?

I can’t really tell you how to feel about this situation. Some people are just happy for the security and are fine with using a big name distro and others are outright pissed at Microsoft and calling for their heads on a plate. But it’s my blog so I’m going to tell you how I feel…

Honestly, I’m really into security so part of me is happy to see it happen… but it feels very forced. I would have preferred to see this come about naturally. If SSL had come about naturally we probably wouldn’t have all of the problems we see today with CA’s just ‘tacked on’ as a last resort “couldn’t think of anything better, had to rush it” type deal. If the community had openly discussed how to do this in a way where everyone benefits I think things could have not only gone smoother but we would also end up with a more secure product. SecureBoot as an idea is amazing, one of the best ideas for security in the last few years really, but this is not the proper process for implementing it.

My 2 cents, I think this covers everything.

Do Not Track On By Default In IE10

Internet Explorer 10 is the browser shipping with Windows 8 (currently in Release Preview) and it’s got an interesting feature. Do Not Track is a new would-be standard for telling advertisers not to track you online. Microsoft has stated that it will be enabled DNT for IE10 by default.

The Importance Of Privacy

Every single user should have complete and final control over their data. No one should be able to track you if you don’t want to be tracked – not the government and not corporations. I hold this to be fundamentally true.

Do Not Track does not actually stop anyone from tracking you. It “asks nicely” for them to stop tracking you and they have no legal obligation to care. Still, as DNT is incorporated into modern browsers it will hopefully become the standard and it could be enforced both by browsers (blacklisting ads that don’t comply) and the law.

The Big Problem

I’m new to blogging, and while I don’t own this domain or use Google Analytics I can see a lot of information. I see where people come from (the majority of users who visit this blog are from Google), which articles are popular, which tags are popular etc. If I were so inclined it would be very easy to make my blog more targeted to take advantage of the information provided to me. Even with a few days of information I can see a ton about how to increase my blogs popularity.

The same is true for advertisers. This tracking isn’t just about being creepy – it really does help. If I’m getting ads for makeup products I’m not going to click them, if I get an ad for some new book about computer or whatever I’m way more inclined to click that ad.

The sad truth of it all is that ads are what make the internet possible. Everyone has to pay for hosting or come up with some other business model, which means selling you something else. That or you’re paying out of pocket.

So while I commend Microsoft for implementing Do Not Track I’m going to outright say that this is a bad decision for the internet as a whole. It should be a choice but it should be off by default. Put a little box asking users to enable it at first run if you want, explain to them what it means. But turning off tracking for 50% of the internet is not ‘healthy’ for it.

If the entire world turned on DNT and Adblock the internet would have no way to maintain revenue. It’s not that every site would shut down overnight but tons of sites would have to start paying monthly fees and a lot would shut down.  I’m not saying to turn DNT off, just think about that.

Personally, I run Adblock Plus (which sends a DNT header) and I whitelist any website that I want to support. Adblock Plus already whitelists ads that it considers to be unobtrusive and that is a policy that I wholeheartedly support.

I think this is a really weighted subject and there’s a lot to talk about here but for now this will do.


Universal ASLR Bypasses And How To Solve Them

Address Space Layout Randomization is an exploit mitigation technique that focuses on preventing Return Oriented Programming attacks. It’s become one of the “must have” tools for a secure program (like DEP) and it’s preset in all modern user-oriented operating systems.

Mitigating ROP is pretty important as most modern exploits take advantage of it. And ASLR would be entirely effective in an ideal world where every single part of address space is randomized and 64bit address space is impossible to bruteforce and heapspray doesn’t exist. We don’t live in that world and there are universal ASLR bypasses for Windows and Linux, heapspray does exist, and the majority of users are stuck in a 32bit address space (and 64bit vanilla ASLR isn’t necessarily impossible to bruteforce).

Windows is actually pretty on top of things with ASLR (as of Windows 8) and /FORCEASLR but there’s always going to be a way around it (unless some things seriously change.)

So what’s the answer?

Well, for non-performance critical applications perhaps a solution like Gadgetless Binaries would be a viable option. Gadgetless binaries would compile code in such a way that an attacker would be unable to make use of static address space instructions to form their attack.

There is a performance hit here so I’m not saying to compile everything with it, but for security critical applications why not? There are specific areas of Windows address space that are loaded in the same exact place every time – why not compile that area with gadgetless binaries and avoid situations like this?

There’s also a somewhat less effective In-Place Code  Randomization technique and even less effective (though still welcome) EAF, which is what Microsoft has implemented.

Perhaps I’m just missing something. Maybe this would require paying out or some such thing but it seems like a great idea to me as ASLR isn’t going to solve every problem. At least not with current implementations (outside of PaX ASLR, which makes use of many other features via Grsecurity to prevent attacks against ASLR).


Microsoft Gives Advice To IT Professionals About Social Engineering

In a new security article on social engineering Microsoft highlights what measures can be taken to both prevent and remediate  socially engineered attacks.

Some key highlights are:

  •  Limit attack surface
  •  Limit user accounts and strictly monitor high privilege accounts
  •  Maintain a proper incidence response team
  •  Risk analysis and weighting
  •  Proper training

You can read the full article for details but I think those are the tips that stand out. The go-to policy for many companies is “enforce periodic password changes, don’t hand out smartphones to just anyone, tell users to be secure.” That’s my (limited) experience at least. This article should prove useful to anyone willing to put the work into maintaining a secure environment.

EMET – A Windows Security Tool That Everyone Should Use

Techniques like ASLR and DEP have made exploitation of modern software more difficult. And yet many programs still don’t make use of them. Why? Well, sometimes it’s a matter of compatibility but very often it’s simply a matter of the developer not knowing or not caring enough to implement them.

EMET sets out to fix this.

There are very few programs that I think belong on every single computer. EMET is one of those few.

What is it?

EMET is the Enhanced Mitigation Experience Toolkit and it’s pretty damn cool. The goal of EMET is to prevent programs from being exploited by forcing them to make use of modern mitigation techniques (EAF, SEHOP, ASLR, DEP, HeapSpray, Bottom Up Randomization.)

The Good

EMET attempts to bring insecure programs like Java (which is the most exploited piece of software for Windows users) up to speed in terms of security. By running Java with EMET you can prevent a ton of exploits that would have otherwise led to infection. You can also run your browser with EMET to prevent Flash/ browser exploits.

EMET also uses virtually no resources. EMET.dll is something like 44kb and that’s all that’s loaded into programs. The mitigation techniques should have a negligible effect on performance as well.

Compatibility is easy to maintain as EMET can be used on a per-program basis. I suggest that you run your PDF viewer and Java with EMET and consider running your browser as well.

Windows XP users should be downloading EMET as soon as possible. XP doesn’t have any form of ASLR but EMET will provide EAF, which is another ROP mitigation (though less effective.)

The Bad

EMET is not a replacement for an antivirus. It offers absolutely no detection of malware or malicious activity – its only goal is to prevent exploitation.

Even with all of those mitigation techniques there are ways around them; DEP and ASLR just don’t apply to every situation ie: JIT Spraying, which needs a whole separate class of mitigation. EMET drives up the cost of exploit, it doesn’t eliminate the threat.

Some of the techniques like EAF and HeapSpray are also easily bypassed, they’re more for defeating automated attacks, which is still valuable since that’s what the average user will come across.

There are potential compatibility issues with EMET. Very old programs can’t handle DEP and they’ll potentially break even if you just install EMET. It sucks. I suggest you contact the developer and remove EMET in the meantime.

It should be plain to see why EMET is such a significant security tool. Forcing horribly insecure programs like Java to start acting like modern software is probably the most important first step in securing Windows. EMET is a must have, whether you’re on XP, Vista, or 7.

I’ll be posting a guide with screenshots on how to set up EMET very soon.

Grab EMET Here: