Another Tuesday, another round of security bulletins from Microsoft. Are you patched? Nessus contains credentialed local checks for all Microsoft security bulletins.
I have always wondered what the term "specially crafted" really means. What is "special"? Merriam-Webster defines it as "distinguished by some unusual quality". "Unusual" is relative, and means that someone has defined what "usual" means. This is where we start to enter a grey area. How do we determine what is "special" if the "usual" is not clearly defined? In this case, I'm talking about RFCs, the documents used to define what "usual" means with respect to Internet protocols. One of the vulnerabilities this month has to do with IPSec and specifically ISAKMP, the key management protocol. Apparently a "specially crafted" packet will cause this service to eat up CPU cycles and cause a DoS condition. These flaws are common, but my concern is that this condition may not always be caused by a malicious attacker using a tool such as Scapy. For example, a VPN client might send "specially crafted" packets because the programmer, who wrote the client software, misinterpreted the RFC. I wish that Microsoft would be a little more forthcoming regarding the details of the flaw, particularly how difficult it is to exploit.
I am also somewhat puzzled by the term "could allow". When using it in the context of remote exploits, it’s even more confusing. A vulnerability either allows or does not allow remote code to be executed. Sure, there are mitigating factors, but if the vulnerability does allow for remote code execution, then Microsoft should just come out and say it. When you are reading security bulletins from Microsoft, keep in mind that "could allow" really means "allows under certain circumstances".
A Vulnerability is Convenient, but not a Requirement
The ability to exploit a Microsoft Office application by enticing someone to download and open a document does not necessarily require a vulnerability to exist. This month, there are two vulnerabilities that require a user to open a document with a vulnerable version of an application. However, research from earlier this year proves that by using Visual Basic macros, an attacker can embed code in a document that will compromise a machine even when opened with a fully patched version of an application. A video tutorial can be found on Mark Bagget's web site. The moral of the story is that you need to have defense in depth and expand your countermeasures to include attacks that are not prevented just by applying a patch. For example, a comprehensive user education program can be effective to mitigate threats that are manipulating the end user.
Patch Tuesday Breakdown and Thoughts
What follows is a breakdown of the patches that have been released by Microsoft in the latest "Patch Tuesday" set and their associated Nessus plugins:
- MS09-069 - Nessus Plugin ID 43061 (Credentialed Check) - A DoS vulnerability in IPSec due to the "specially crafted" packet discussed earlier in this article.
- MS09-070 - Nessus Plugin ID 43062 (Credentialed Check) - Remote code execution for ADFS enabled web servers that requires authentication to exploit.
- MS09-071 - Nessus Plugin ID 43063 (Credentialed Check) - Wireless networks beware: if you are using IAS for authentication, attackers can send PEAP requests that can trigger remote code execution. This can be dangerous, as the authentication server in a PEAP wireless network has to be exposed to wireless clients, which could be attackers lurking (even ones from miles away with the right antenna).
- MS09-072 - Nessus Plugin ID 43064 (Credentialed Check) - There is a public exploit available for one of the five vulnerabilities that this patch affects. However, figuring out which vulnerability is exploitable and which software is affected can cause dizziness. OSVDB to the rescue! The Open Source Vulnerability Database is a web site that allows you to search and sort thousands of vulnerabilities, including the Microsoft security bulletins. I ran a search for "MS09-072" and limited it to "Microsoft Advisories". I got exactly the results I was looking for:
OSVDB Rules! (Click for larger image)
The results show all five of the vulnerabilities contained within this bulletin, when they were disclosed and their descriptions. The disclosure date is especially useful, as we can now see which vulnerability was most likely the one to have a public exploit. OSVDB 60490 was disclosed on 11-20-2009. Clicking on this OSVDB entry showed me all of the currently known information about it, including links to information about the public exploit.
- MS09-073 - Nessus Plugin ID 43065 (Credentialed Check) - This one appears to be low in severity, as exploiting it would be difficult because it relies on opening a Word document in WordPad. In reality, most people who open Word documents use Microsoft Office and will not be affected by this vulnerability because the default application for opening Word documents is Word, not WordPad.
- MS09-074 - Nessus Plugin ID 43066 (Credentialed Check) - This one may have some impact for email filtering rules. For example, how many of us are blocking Microsoft Project files attached to emails? How many of us know for certain the answer to this question? It may be time to find out.
I'd venture to say, "Happy Patching", but in my experience happiness only comes once the patches are all applied – and didn’t break anything in the process!