I often tell Nessus users that patch auditing is more efficient and accurate than network scanning. And for the most part, this is absolutely true. However, there are several cases when patch auditing, or a lack of understanding of how patch auditing works, can actually give you bad data. This blog will describe the many subtle nuances to conducting patch audits.
Where do patches come from?
When I have the opportunity to interview potential new employees for Tenable, I often ask many questions about the differences between un-credentialed network scanning and credentialed patch auditing. I’m usually looking for a good grasp on the vulnerability disclosure process as well as operating system internals. A typical exchange goes like this:
Candidate: Access to port 445 & 139.
Ron: At a higher level?
Candidate: You need administrator rights.
Ron: An even higher level …
Candidate: Not sure.
Ron: It depends on the patch being available from the vendor or project.
Of course this is obvious, but it's not something people say right away. Having a patch to test against in the first place is the ultimate point in performing a patch audit. I’ve found a lot of people who understand this basic concept, but don’t apply it to their auditing process or overall security assessments.
End Of Life = No More Patches!!!
At Tenable, we often get requests to write a “patch audit” on a security issue for a platform that no longer has new patches available. Companies such as Apple (OS X), Novell (SuSE) and RedHat stop producing patches for older releases of certain operating systems and declare them “End Of Life” (EOL). This creates a situation where an OS is indeed vulnerable to security issues, yet no patch will be available for it.
This can manifest itself in many different ways. If you had a vulnerability that was recently disclosed for an application such as Secure Shell or the Apache web server, you will likely be able to determine this vulnerability from an un-credentialed network scan. However, when you perform the patch audit on the same system, you don’t find any missing patches because there aren’t any available to address this problem. If you were only performing patch auditing in this situation, you might not ever know you had vulnerabilities!
Tenable’s research group has produced a Nessus check for older versions of Windows operating systems that are no longer supported as well as one (plugin #33850) that checks for a wide variety of
Unix OS that are no longer supported.
The Patch is Not Applied
If you work with a large enough sampling of computers, you will run into situations where patches seem to have been applied, but in actuality they are not. There are lots of reasons for this. We’ve blogged about this in the past. Lack of disk space, buggy patches, too much security preventing the patch form installing, loss of power during patch application, incorrect backup methods, systems not being rebooted and many other reasons can contribute to a patch that seemed to get installed, but did not complete.
On Windows computers this really become evident if you compare what has been recorded in the registry and what files are actually on the disk. Most software installations will mark some sort of setting in the Windows registry during installation. If this occurs before the installation is fully complete, and the patch fails, you will have a situation where a patch looks like it has installed when reading the registry, but it really hasn’t.
With Nessus, all Windows patch audits look at the file system directly to read exactly what has been installed on the computer. This sometimes puts Tenable in a defensive position when we have a Nessus user claim that they are receiving a false positive for a patch audit when “they know” the patch has been applied.
In product evaluations, this functionality can also show through. We once had an evaluation where
Nessus was the only product that “missed” a patch. All other scanning vendors “correctly” identified the patch being applied. That was until the system in question was successfully penetration tested with Core Impact. At that point they found there had been an error delivering the patch and the other scanning vendors were in fact “incorrect”.
A common reason that patches have not been fully applied on Windows systems is that the system requires a reboot. Tenable’s research group recently added a check (plugin #35453) in Nessus that checks if the Windows computer is in a state that requires a reboot.
Only doing an OS Patch Audit
Consider this conversation ….
Admin: Yes, all patches have been applied.
Conversations like this likely occur each day in many different IT organizations. When someone says they have applied “all of the patches” do they include:
- Third party browsers and email clients like Opera, Thunderbird and Mozilla?
- Software updates for your Anti Virus and Anti Malware agents?
- Library updates for Java, Quicktime and Flash?
- Software updates for your network management agent from CA, Tivoli or HP?
- Firmware security updates for your wireless card, network card, motherboard or CPU?
- Popular desktop applications such as iTunes, Blackberry and Skype?
- Non-critical / non-security patches from Microsoft that fix reliability issues and other bugs?
The list could go on. The point is that if you audit a Windows computer for Microsoft patches you will likely miss a lot of software that is installed and potentially vulnerable. The same is true for OS X, Solaris, Red Hat Linux, etc, etc.
At Tenable, we try to help detect as many of these issues as possible. Users who perform full credentialed scans with Nessus on Windows and other systems usually see all of the missing Flash, iTunes, Java and other “third party” security issues that don't come directly from the operating system vendor. If these products have listening network ports, we also make an effort to scan for these issues from the network, so that you don’t have to rely on credentials. Some anti-virus agents and applications such as Skype and iTunes fall into this category.
What about manually compiled services?
Last, if you are in an IT environment where you are auditing patches and not systems, you can run the risk of missing manually-compiled software installations.
Consider a scenario where you are working with a flavor of Unix where the choice has been made to design a service offering based on a hand-compiled distribution of a server such as Apache, MySQL, Sendmail, .etc. This can create a situation where you have two versions of an application installed except that one application was compiled by your IT staff and the other came with your operating system distribution.
We’ve blogged about this situation before. Nessus credentialed checks (plugin #33851) have the ability to audit all running processes against the list of installed packages and see if there is a difference that may indicate that a manually-compiled service is running.
The core issue is one of false confidence. If you have an audit technology that looks at Linux RPMs or some other type of Unix packaging for system updates, it does not know to look in other non-standard places and won’t report on your manually-compiled services. This can provide you a false sense of security.
This problem is stereotypically one concerning Unix networks, but I’ve seen people run into this problem running Apache and MySQL, built from source and on Windows platforms as well.
For more Information
We’ve blogged several times in the past few years on the topic of performing patch and security auditing for networks. The following previous blog posts touch on similar issues:
- Testing the Effectiveness of your Patch Auditing System
- Knowing When to Patch (a.k.a. don’t let your vulnerability scanner dictate your patch policy!)
- How did you test for MS08-067? (compares credentialed and un-credentialed methods)
- “But I patched our DNS servers …” (when network issues trump system patches)
If you are new to network scanning, Tenable has many free videos to watch that that show how easy it is to perform comprehensive Windows and Unix audits with Nessus. We also offer many free white papers that show how different types of network auditing can be unified for easy enterprise security and compliance monitoring.