How did you test for MS08-067?

Microsoft recently released a critical security bulletin, MS08-067 that described a privately reported vulnerability in the Server service and provided a patch for this vulnerability. What was unusual was that this bulletin was released independently of Microsoft’s usual patch notification process and caused quite a bit of concern for many organizations. Tenable used this opportunity to help a number of organizations monitor their networks to determine if this issue had been mitigated. I had the opportunity to speak with many different customers and was surprised at the different priorities, techniques and level of response that varied from organization to organization. In this blog, I will share some of the situations and trends I ran into while working with Tenable Nessus and Security Center customers.

Tenable’s research team released two checks for MS08-067. One of them, plugin #34477, works without any credentials. It verifies the vulnerability by connecting to Windows systems on port 445 or port 139 and performs a check for it. This plugin has the advantage of being fast and not requiring credentials. The other check (plugin #34476) performs a credentialed patch audit for the same vulnerability. This plugin performs file level analysis to ensure that the right system DLLs have been patched. This technique is more accurate than relying on registry checks alone and can also identify systems that have been patched, but perhaps are waiting on a system reboot for them to truly be effective.

I found that the enterprise organizations that tended to rely on un-credentialed scans generally had immature vulnerability and patch management programs. This was by no means a scientific study, but very often, if we were working on an enterprise un-credentialed scan of several thousand hosts for MS08-067, there was no follow up patch audit or configuration audit. The following were typical comments and conversations:

• The organization doing the scanning did not have good communications with IT or the multitude of IT organizations. There was simply too much burden to manage credentials across the organization, and if the IT group(s) had some sort of patch auditing solution, it was not centralized in a way that was accessible to perform a corporate audit.
• There was a perception that MS08-067 was “worm-able” and that the best way to check for it is with an exploit. This is a very dangerous assumption. There are many different scenarios where a network exploit will not work because of a firewall rule or a system configuration. Being un-exploitable and un-patched are two different states. A configuration or firewall filter could eventually change, making the system vulnerable. 
• There were also many organizations that cited the CVSS score of 10 as the main reason for the patching. I would jokingly ask if it would help them politically if we just started putting “10s” on all of the vulnerability audits produced by Nessus so these groups could get the resources they needed. Here was the rub though – I asked about client side issues that had CVSS scores of 10 such as issues with web browsers, email clients and chat clients. The response was often that the organization was not concerned with client-side issues and they ran anti-virus solutions. I have a big issue with this because anti-virus only protects you from common viruses. It does not plug the actual attack vector. For example, anti-virus technology may prevent a malicious site from spreading the latest Trojan to your vulnerable web browser, but at the same time, it will not stop a custom exploit designed to grant access to your network from the outside or any number of scenarios an attacker could attempt.

I did run into organizations that were using the Nessus network checks for MS08-067 very efficiently:

• Some organizations had large patch-management operations and were using network scans to get an independent view of how effectively these patches had been rolled out. Tenable support has often received calls from customers when there was a discrepancy between the patch auditing software and Nessus. We’ve blogged before about the many reasons patch management systems can fail.
• They used Nessus to simulate PCI audits from their ASV and they wanted to get ahead of any potential compliance issues. I would also argue here that patch auditing with Nessus is still quicker and faster than performing a full network scan, but often production PCI systems are extremely locked down and even the auditors do not have direct access to monitor these systems. I find these situations intolerable and see many organizations restricting access to these systems to the point that there are not enough administrators to keep them patched and running. 
• Some organizations had large numbers of Windows XP (not XP Pro) systems that were not part of a domain, and not running some sort of patch auditing agent. Performing a network check on these systems was the only option.

Anytime I had the opportunity to speak with a customer, I urged them to try and take their system monitoring program to the next level:

• If they were just doing scanning, I explained that patch auditing is more comprehensive, quicker, accurate and less intrusive than a network scan. I provided specific examples such as WMI and netstat port scanning as well as Unix and Windows process enumeration. I also pointed a lot of customers to the blog “Knowing When to Patch” which really shows how to move your scanning programming from monitoring for vulnerabilities to monitoring your patch management program.
• If an organization had adopted some sort of patch auditing with Nessus (or even as a complement to an agent-based patch management solution) I suggested that configuration auditing can help minimize variance in operational system settings. This in turn can minimize outages, IT help desk calls and can also increase overall security.  A great example of this occurred when I was chatting with a customer about MS08-067 and I asked if they also could show what the password complexity and lockout polices were for all of their Windows 2003 servers. They could not. However, the point was made and the person I was speaking with is attempting to use MS08-067 to get them to be more proactive. 
• Lastly, if an organization has a good handle on patch and configuration auditing, I ask them how fast they can react to a bad network/system change or a new vulnerability. Detecting non-compliant (insecure or mis-configured) systems early enables it to be corrected quickly and reduces the chance of exploitation. For MS08-067, I asked customers how often they scan their network for new hosts that are un-patched.  Not every security group that does network scanning has access to a log analysis tool or SIM, but for Security Center customers that upgrade to the Log Correlation Engine, I spent some time showing them how they can use logs to look for change in real-time. Similarly, if a group has access to a network span port, running a product like the Passive Vulnerability Scanner allows them to see what is on their network in real-time.

The bottom line here is that although there are many different ways to monitor security, the real question is did you and your staff respond to MS08-067 proactively or reactively?