How Accurate is Your Software Vulnerability Scanner?

Tuesday, April 05, 2011

Jamie Adams

4085079c6fe0be2fd371ddbac0c3e7db

When it comes to determining if the version of software present on your system is vulnerable, it isn't always as straight forward as you might think.

First, you must identify all of the software on your system and then determine if it is a vulnerable version. At this point, you must decide if the risk is worth mitigating by applying a patch.

My job at Raytheon Trusted Computer Solutions is to architect and develop software which focuses on securely configuring operating systems and software components. Patch management tools and software version scanners are only concerned with the version of software present on your system.

For example, our Security Blanket product would ensure that the Samba file sharing software is configured to disallow anonymous guest connections while a software version scanner is only concerned with the version of Samba.

We've been asked by some of our customers if we'd consider including software version checking in Security Blanket. I thought about the myriad of scanners and their methods and I've come to a realization... there really isn't a complete, accurate solution available.

Before everyone jumps to the defense of their favorite product or tool, let me explain. First and foremost, you must be able to determine what software is on your system. Generally, the two most widely used methods are:

  • Query the package database to see what has been “installed.”
  • Remotely scan open network ports. Many of these tools have proprietary algorithms which utilize service signatures to aid in the determination of which versions of software are running.

These both seem straightforward. However, what about all of the software which has been copied onto systems in non-package form, such as Apache Tomcat servers and the numerous JAR files used? This information isn't in the package database because it wasn't “installed” — just copied.

Maybe the port scan will detect and identify the Tomcat instances — provided they are running and are accessible via the network being scanned. Many of these port scanners first check to see if the service is advertising its version but these days most system administrators suppress the version information. The port scanner must then resort to its service signatures which isn't 100% accurate.

Additionally, what about all of those plug-ins and components Tomcat may be using? What about software in non-package form and  not exposed via the network? Let's say a sysadmin decided they need multiple Java Runtime Environments (JRE) and Java Development Kits (JDK) so, they copy them onto the system in non-package form. 

Some scanners might inventory all “notable” executable files on the file systems such as locating all files named “java” or “javac”. If you do locate any, how do you determine their version? You certainly don't want to simply execute it with “java -version” because it may be a Trojan horse!

This is what got the DISA FSO in trouble in September 2009 (see CVE-2009-4211). This is a time consuming and ineffective technique, and not to mention, possibly dangerous.

Once you've identified which software is present on your system, you need to determine if it is in fact a vulnerable version. This has frustrated many of my customers in the past. Let's consider CVE-2010-4180 which identifies a vulnerability in “OpenSSL before 0.9.8q, and 1.0.x before 1.0.0c.”

The diligent sysadmin checks their installed package version and then verifies the command file (/usr/bin/openssl) before executing it to discover that 0.9.8h is present.

# /bin/rpm -q openssl
openssl-0.9.8h-28.20.1

# /bin/rpm -qf /usr/bin/openssl
openssl-0.9.8h-28.20.1

# /bin/rpm -Vv openssl |/bin/egrep /usr/bin/openssl
........ /usr/bin/openssl

# /usr/bin/openssl version
OpenSSL 0.9.8h 28 May 2008

At this point the logical conclusion is that this software must be patched. It is deceiving because the package version is actually 0.9.8h and vendor release 28.20.1.

If you examine the package's change log, you'll see that the package has been patched to fix the CVE-2010-4180 even though the vendor didn't change the major version number (0.9.8h).

# /bin/rpm -q openssl --changelog
* Tue Dec 07 2010 gjhe@novell.com
- fix bug [bnc#657663] CVE-2010-4180
for CVE-2010-4252,no patch is added(for the J-PAKE
implementaion is not compiled in by default).

Scanners which use vendor-maintained OVAL patch definitions would know that this package is okay. Unfortunately, not all vendors or open-source projects provide this level of detail.

The bottom line is that system administrators must take into account all methods in which software may get copied (or installed) onto their systems. A strong change management program and strict access to systems is required.

System administrators must be aware of any and all changes to their systems. Software patching is inevitable. Unfortunately, I have yet to experience an all-encompassing software version scanner and patch management tool.

Cross-Posted from Security Blanket Technical Blog

Possibly Related Articles:
16092
Viruses & Malware
Software
Java SSL Software Vulnerabilities Scanners Administration Servers
Post Rating I Like this!
Default-avatar
James Product plug drivel
1302187916
4085079c6fe0be2fd371ddbac0c3e7db
Jamie Adams James.. thanks for the comment. However, I will tell you.. we DON'T have any plans to pursue software version scanning. There are plenty of good tools out there. My point was that, unfortunately, you might need to use multiple tools to get a more accurate picture of your environment.
1302188261
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.