The Need for Security Intelligence: MS07-046
eEye Research routinely finds vulnerabilities in many different applications from many different vendors. Throughout its tenure, eEye Research has become the leading security intelligence team and has only recently started publicly offering a service to utilize this industry leading expertise. In this brief case study, we will walk you through a recent event dealing with a Microsoft vulnerability to help identify the need to have a deeper level of intelligence than what is offered by vendors and public mailing lists, only the tip of the iceberg of what is the main security threat against networks.
MS07-046 represented the most critical vulnerability from the Patch Tuesday cycle this August. The vulnerability within GDI was discovered by eEye Research and was disclosed privately to Microsoft so that a patch could be prepared to fix this vulnerability. This vulnerability has a very high impact since metafiles have the potential to be included in nearly every Office document, displayed on websites, or transferred via IM, thereby making this vulnerability potentially very mobile. Since targeted attacks are constantly on the rise, it is never safe to assume that the person who reports a vulnerability to a vendor is the first or only researcher to know of the vulnerability. A zero-day exploit is a very dangerous and expensive weapon that many cybercriminals use in targeted attacks to infiltrate targets without the targets being able to protect themselves. Unfortunately, because of the numerous attack vectors with this specific vulnerability, there was no way for administrators to proactively mitigate this threat except by using a non-signature host-based IPS.
One day after this report, a zero-day vulnerability was found in circulation on many sites that was quickly dubbed the .ANI Processing zero-day. This vulnerability resembled a very similar vulnerability to another eEye Research-discovered vulnerability within GDI’s .ANI processing. Attacker toolkits were quickly updated with fully-functional exploits for this vulnerability, and Microsoft was forced to release an official patch for this vulnerability a short 6-days later in the form of MS07-017. Unfortunately, because of the incredibly quick turnaround necessary for the MS07-017 patch, the vulnerability that we reported just a week earlier would not be included within this patch. This was expected since Microsoft had been privately notified of the vulnerability and there was no active exploitation occurring.
At that point in time, MS07-017 patch looked to have no impact upon our vulnerability except for requiring very minor modifications to our exploit proof-of-concepts. So, if anyone other than eEye Research knew of this vulnerability, they would only have to make a minor modification to their exploit to continue using it in attacks against targeted networks without those networks being able to have a good mitigation in place. However, as part of the Preview service, eEye Research reverse engineers every critical patch from Microsoft to give a deeper analysis regarding the vulnerability and the existence of any silently fixed vulnerabilities or enhancements. Within MS07-017, we came upon a very useful find: HKLM\Software\Microsoft\Windows NT\CurrentVersion\GRE_Initialize\DisableMetaFiles(DWORD). This key did not exist on any machine that we were able to review, and when reverse engineering the changes between pre-/post-MS07-017 GDI32.dll’s, this registry seemed to have the full effect of what its name would imply: after installing MS07-017, our exploit had become useless if this registry key was created and set to 1 because all metafiles were effectively disabled from being processed by GDI. Of course, this was immediately reported to our Preview customers and many of them immediately rolled out this registry key to their mission-critical machines.
To our surprise, when we scoured the Microsoft advisory for MS07-017, as well as all KB articles and Patch Tuesday documents, we could find no information related to this newly introduced mitigation technique. Many times silently fixed vulnerabilities are the payoff of reverse engineering, but we had just effectively identified a silently fixed mitigation tactic. While at Blackhat this year in Las Vegas, we brought up this registry key to a Microsoft employee that definitely should have been informed of this mitigation tool, but all we got was an inquiring look and a shoulder shrug. Granted, maybe it was because we were still wearing Blackhat 2006 eEye Research t-shirts, but we were pretty sure that this mitigation was never even known beyond a small group of GDI developers that decided not to inform MSRC. Until the patch for our GDI vulnerability was released, the only people that would be protected from exploitation were our Preview and Blink customers.
This month, MS07-046 was released, thereby patching our GDI vulnerability. Of course, since we had dropped the hint at Blackhat, we were hoping the DisableMetaFiles registry key would have been included with the bulletin as a form of mitigation for customers with MS07-017 applied. However, to our surprise, their response was a bit more dismal: “Microsoft has not identified any workarounds for this vulnerability.” MSRC either still did not know of the mitigation, or did not find it necessary to inform many of their customers of this simple workaround. Furthermore, this key was never seen on any public mailing lists or reverse engineering forums, so there was no form of mitigation possible for one of the most serious client-side bugs of the year.
Unfortunately, unless you are a Preview customer, a regular attendee to the eEye Research VEF, or are spending your Patch Tuesday cycles reverse engineering patches instead of patching your systems, vendor advisories and mailing lists are usually trusted as the best source of information. But, in similar light to “Quis Custodiet Ipses Custodies”, how are you to trust the software vendor that has a vested interest in making their software seem as secure as possible? Granted, Microsoft as well as some other vendors does offer many tools to enhance the security of your network, but should this be relied upon as the main and only information source for security issues? Unfortunately, this is what many networks rely on as their main source for security intelligence.
A successful security team needs more information than what is released publicly since this information is typically only the tip of the iceberg for what is actively occurring in the world of security. At times, there may be silent mitigations being introduced as we’ve outlined above. At others, there might be a more serious targeted zero-day attack against client-side applications that cannot be detected at the network level. A mission-critical network needs to know about these threats to the lowest level possible in order to protect themselves. This is not a technical necessity so much as a business decision to help threat assessment teams become more efficient by utilizing security intelligence services and leaning on the leaders of the industry instead of performing all research internally.
Source: Andre Derek Protas, Director of Research and Preview Services, eEye Digital Security |
News & Articles
Reader Q&A
Announcements
Tech Talk
Etcetera