So, let's pretend you are Rob, Mr. Head of IT, and that you are sitting in your office on March 9th, working on your fantasy baseball (I hear Albert Pujols is the way to go...) when one of your staff walks in and says that Microsoft has another 0-day running around. Internet Explorer 6 & 7 are vulnerable to a condition where invalid pointer that is accessed after an object is deleted. Putting on your best manager hat, you ask the hard question: "OK, what do we know?"

She tells you that because you bought into the anti-Vista hype (in her head, she's calling you moron but she doesn't say it out loud, she isn’t crazy, just proud), there isn't much that can be done currently. There were some mitigations provided, but they mainly involved Vista and Server 2003 and 2008. Now you know that your boss is going to be calling any moment and here is what you know: Something about an invalid pointer, the fact that it is "in the wild", a CVE number and "Microsoft is working on it", you probably shouldn't tell him that Vista part. The phone rings.

Let's switch to the view of the attacker. Something that was incredibly valuable has suddenly moved to a very short timeline. The moment that exploit that you paid fifty large for gets patched you're toast. You can't even trade it at this point, because that code is out there, and no one is going to pay you anything for released code that they can find themselves and easily rework. All you can do now is broaden your attacks and drop as many bots as possible so in the future you have some pivot points to launch your attacks. Maybe you'll get lucky and hit somewhere that has some interesting information. Time to bust out the mass mailer. You love irony, so your subject line is "Information on Microsoft IE 0-day, please read".

Security researchers everywhere are scrambling and the ones that understand this process are starting to share information about the attack. The race is on to get enough information out so that organizations can protect themselves. Many of these researchers are working for "free", knowing that getting their name out there on an issue like this is a great way to increase their employability going forward. Others are working for well known research organizations, Sourcefire and in this case, importantly, a little firm named McAfee. In a blog post on this on the evening of March 9th they named a site that was associated with the attack: https://notes.topix21century.com.

Now this information, for those paying attention is really important. I'm all for giving credit where good work is done, so kudos to McAfee for putting this information out. First, it provides researchers with a location where they can find the exploit. Secondly, it gives Rob something he can do. Now he can check the IP addresses associated with topix21century.com and block them at his firewall. Then he can watch his firewall logs and DNS logs for evidence that one of his hosts are trying to get to this site. Now he knows which hosts are owned and he can begin the remediation process. He still doesn't understand the attack, but he can take care of the first wave.

By the time Rob gets into work the next day someone named Moshe Ben Abu is suddenly really important. Overnight he had created a Metasploit module that generated the attack and less than 24 hours had passed from the point that the Microsoft announcement was up. (Note and additional kudos to Moshe Ben Abu: He has contributed 10 exploits to the Metasploit package in the last 3 years). Now Rob had two new things to work with. One, he had a known attack that he could use to test this detection strategy and more importantly, his hot-shot security staff could look at the Metasploit module and figure out what this detection strategy is going to be. Metasploit modules typically are very clean and even a moderately talented security person can pull the stings that are important to look for. In this case, "setAttribute('s',window)" and "#{j_object}.addBehavior('#default#userData');" look interesting. Now they have all the information they need to configure their detection systems, whatever they are, to detect the attack. This time, when the phone rings, Rob is ready.
For many, many security shops, who don't have commercial data feeds, haven't had the opportunity to find their way to numerous "back channel" IRC channels and mailing lists and don't have the budget for a multitude of "APT-KILLING" solutions this is the way (hopefully) that these two days played out. This isn't the only time this timeline occurred either. Metasploit had exploits for Microsoft's Aurora and Adobe's JBIG2, media_newplayer and utilprintf before there was a patch. Yet there was some degree of backlash against McAfee because initial reports had Mr. Abu gleaning technical details from McAfee's site to generate his exploit. As it turns out, he did the research himself based on the link above. There is also (always) grumbling when Metasploit puts out a module, even when it affects things that have long had a patch.

Unfortunately, this situation led to McAfee making the following declaration:

"McAfee Labs does not support the release of exploit code, particularly in advance of a security patch being made available. We regularly sanitize blog content to prevent providing information that might assist attackers, while at the same time providing a service to customers and the security community to help improve protection levels...Future blog posts will be subject to additional sanitization."

So here is the new debate...shops like Sourcefire and McAfee have the resources to hire some very intelligent, very talented people to do their work for them. Yet McAfee has made the decision that it will further limit information from their blog so that exploits cannot be developed. This is, unfortunately, purely a PR move. The people who use these exploits have no need for the Metasploit module. This isn't to say they wouldn't use that code if they had it available, using widely published code instead of custom built code obfuscates who created the exploit. But if it weren't available they would still have access to the code either through back channel sharing or their own reverse engineering. Let's not pretend these guys don't have talent. This decision does nothing but save face for McAfee and reduce the information that security shops have to work with. I guess that's a business decision; hopefully they just said that to make people go away and they'll do what they want going forward.

But research shops aren't the only people who have to make this decision. The software vendor also has to figure out what information to share as they go forward. While in Mattland the vendor would share any exploit code they had so that mitigations can be developed and tested, I think we can all agree that this will never happen. So what are their options? Brace yourself, because I'm going to say something nice about Microsoft AND Adobe.

Microsoft is the gold standard in vendor response. First, there is the MAPP program, where security vendors receive information on upcoming patches and 0-day threats directly from Microsoft with technical details of the attack so vendors can publish protection as quickly as possible. Now, this has the unfortunate cost of being bound by an NDA from sharing that information or publishing detection in an easily parseable manner, but it gets protection out quickly and accurately. Then there are the tools that Microsoft has developed. Sometime on the 10th they released sufficient information that registry changes could be made (and forced out to end users) that would eliminate the exploit path in the software. This essentially acted as a patch that had to be manually applied and, while a vast majority of home users really don't get any use out of this, IT shops got a solution they could push down through their management system. Also, Microsoft has built the "Fix it" tool, an easy one-button click for end users to apply the mitigation to their boxes. IT shops love this because they can send an email out to those folks who are travelling or working from home to go and push this button. As a bonus, there is a button to back out this fix, if it is found that the fix impacts business critical systems. This system also is MUCH easier for home users, so those who know that this is available have an easy, safe and verified way to apply the fix. Finally, Microsoft has an automated patch system to push patches by default to customers who are Internet connected. This one step may be the most important change Microsoft has made to their response capability.

Are they perfect? No, as in: Where the hell is my patch?

Adobe is still recovering from suddenly coming into the spotlight of the research world. To be fair, that came in a flurry after the JBIG mess, but Adobe has made vast improvements in their response capability. Brad Arkin and his team should be proud of their efforts, and I'm looking forward to more of the same. First, they've improved their working relationship with the people who want to help them: security vendors and vulnerability reporters. They put mitigation information into their advisories so that customers can build detection and response systems in advance of a patch. Their discovery-to-patch time is significantly reduced from earlier in 2009. They've also added the JavaScript Blocklisting which, for functions that aren't part of the core of JavaScript, is an excellent addition on par with Microsoft's registry configuration capability. They also have an improving reputation among security researcher as a shop that is responsive and organized in handling inbound disclosures. Finally they are currently beta testing an auto-update feature that will push updates to their clients automatically.

These two companies have demonstrated they are willing to face the security issue head on. They have dedicated teams, they get information to their customers and they have or will put into place an auto-patching system. They both have a good reputation amongst researchers that chose to disclose vulnerabilities they discover directly to vendors. Microsoft is clearly best-of-breed and Adobe is catching up rapidly. It may be because they have no choice, or maybe they are just responsible corporate citizens. Both are getting a ton of attention from researchers. This isn't due to their code is any worse than anyone else's, but because they are nearly ubiquitous on business systems.

In comparison to those two companies, if you want to see someone who is working hard at doing it completely wrong, lets look at Apple. Now, on the good side, they do have an automated patch system. But they haven't exactly kept up in the secure architecture realm. While Vista introduced default ASLR to improve the effectiveness of their DEP stack protection mechanisms, Apple’s address stack is still not fully randomized. This, and other 'features', led Charlie Miller, uber apple hacker, to say "Safari on the Mac is easier to exploit. The things that Windows does to make it harder (for an exploit to work), Macs don’t do. Hacking into Macs is so much easier. You don’t have to jump through hoops and deal with all the anti-exploit mitigations you’d find in Windows."

They also have a horrible reputation amongst security researchers. On more than one occasion I've heard "**** them, I ain't giving them ****". This attitude apparently got the attention of Apple to the point that they had some guy running around last year's Black Hat/DEFCON conferences trying to convince people that Apple wanted to work with vulnerability researchers. When he caught up to me in the bar he said "I just need you to know that we really care about researchers". My response: "Well, that message isn't exactly coming across loud and clear". Then he tried to hook me up with a free copy of iLife. Um, thanks.

They do patch regularly (and somewhat randomly) but there are some concerns with some lag time on important security bugs. During the Kaminsky frenzy of '08, for example, they patched well after Microsoft delivered their update. Microsoft published July 8th and Apple didn't patch until August 1st. When they did patch, they failed to make any indication about the criticality of the patch, and left it to end users to figure out if it was important that "BIND is susceptible to DNS cache poisoning and may return forged information". In doing a quick check, they still do not provide any information about mitigating factors or guidance to IT shops to evaluate the severity of the vulnerability. This is fine for home users, but not particularly useful to corporate security shops.

Apple is coasting on the fact that their install base isn't broad enough to bring the sort of attention that Microsoft and Adobe face. This is both good for Apple, because they typically don't have to directly face a vulnerability (although they do have a substantial open-source code base they have to monitor, WebKit can be pretty hairy, apparently) and bad for their customers. Customers are given a false sense of security, particularly those who would face a targeted attack. With Apple lagging behind in underlying security architecture and Charlie Miller heading to CanSec with "a few Safari zero-day flaws in his back pocket.” there is a threat there. And because Apple has isolated much of the security community they aren't benefitting from the free work that researchers provide for Adobe and Microsoft and many discovered bugs go unreported.

OK, so vendors don't quite give enough information during that critical time between disclosure and patching. That leaves the Evil Mr. Moore, head of the Metasploit project, loved by penetration testers and hated by pure white hats. But from an ops point of view, he is the equivalent of the Director of the Internet Intelligence Agency. He reports to us, the users of the Internet with the most accurate information possible: Exploit code. There is no other way to look at it; the best way to build and test mitigations is by directly looking at what the threat is. Not guessing at what "iepeers.dll" does or what a "JBIG2" is. It is sitting right in front of you, all the information you could want. For many organizations, he is the best data feed they have. So to Evil Mr. Moore, and all of the secret agents working for the IIA, thank you for your service.

And a parting message to McAfee -- Don't stop, your customers, and the research community as a whole, need your expertise beyond just your rule set.