Chapter 11. Vulnerability Assessment Tools (Scanners)

IN THIS CHAPTER

·        The History of Vulnerability Scanners

·        How Vulnerability Scanners Work

·        What to Look For When Choosing a Scanner

·        Fundamental Shortcomings

·        Top Vulnerability Scanners

·        Other Vulnerability Scanners

With vulnerability announcements being released at a dizzying pace, most organizations face an uphill battle when it comes to hunting down the security holes that reside on their systems. In an attempt to aid organizations in this ongoing quest, a number of commercial and open source efforts have risen to automate the process of vulnerability discovery. These vulnerability assessment tools, or scanners, come in many shapes and sizes, with varying degrees of accuracy. This chapter will outline some of the pros and cons of using these tools, as well as identify where their use can be helpful. We will also shed some light on what's important when selecting such a tool to aid in the never-ending war of keeping your environment secure.

The History of Vulnerability Scanners

Turn back the calendar to the early 1990s. The Internet is off the ground and running rampant in universities. CERT is up and operational. The World Wide Web is more-or-less an experiment that is creeping into Gopher's territory. Vendors are vehemently denying most security bugs, and UNIX administrators are just beginning to feel the wrath of the clever attackers. Internet security practices as we know them today are in their infancy, but the blueprints for modern day tool sets are actively being drawn up.

In 1992, a computer science student named Chris Klaus was experimenting with Internet security concepts. He created a scanning tool, Internet Security Scanner (ISS), that could be used to remotely probe UNIX systems for a set of common vulnerabilities. In Chris'words:

ISS is a project that I started as I became interested in security. As I heard about crackers and hackers breaking into NASA and universities around the world, I wanted to find out the deep secrets of security and how these people were able to gain access to expensive machines that I would think were secure. I searched [the] Internet for relative information, such as Phrack and CERT advisories.

Most information was vague and did not explain how intruders were able to gain access to most systems. At most the information told administrators to make password security tighter and to apply the vendor's security patches. They lacked real information on how an intruder would look at a site to try to gain access. Having talked with security experts and reading CERT advisories, I started trying to look for various security holes within my domain.

To my surprise, I noticed that many of machines were adequately secured, but within a domain there remained enough machines with obvious holes that anyone wanted into any machine could attack the weak 'trusted'machine and from there could gain access to the rest of the domain.

—Chris Klaus. (Found in the ISS version 1.0 readme file, 1993.)

Although the cynic in me is inclined to ask what has changed since then (many of Chris'observations still ring true today), ISS was one of the early, if not the first, remote vulnerability assessment scanners to be deployed en masse on the Internet. ISS looked for a few dozen common security holes and flagged them as issues to be resolved. Although a few people were nervous about the tool's obvious power in the wrong hands, most administrators welcomed it with open arms.

A few years later, Dan Farmer (of COPS fame) and Wietse Venema (of TCP_Wrapper fame) authored a similar tool called SATAN (Security Administrator Tool for Analyzing Networks). SATAN essentially did the same thing as ISS, but had some advancements: a more mature scanning engine, a Web-based interface, and a wider assortment of checks. Unlike ISS, however, the pending release of SATAN became a media-crazed event. So hyped was its release that in April 1995 (the month it was officially released), TIME magazine wrote an article on it and Dan Farmer. CERT even issued an advisory on its abilities (CA-1995-06). Many people feared that the release of SATAN would bring about total chaos on the Internet.

Obviously this was not the case, as SATAN's release did little more then cause traffic for a few days while people downloaded it.

Note

Oddly enough, although Farmer lost his job at SGI over SATAN, Klaus managed to use ISS to build a multimillion dollar security products juggernaut—Internet Security Systems (ISS).

Since then, the vulnerability assessment scene has continued to grow and mature. Today, there are more than a dozen scanners in circulation, each with its own set of strengths and weaknesses. The fundamental concepts, however, have not changed much since the early days of ISS and SATAN.

How Vulnerability Scanners Work

As you will see in both the Microsoft and UNIX chapters, vulnerabilities come in many flavors. However, there are primarily two classifications for operating system vulnerabilities: ones that are local exposure points (host-level), and ones that are remote exposure points (remote-level).

In addressing remote exposure points, there are a number of methods one can use to approach the task of automated vulnerability scanning. For example, one approach might involve using a port-scanning tool such as nmap, identifying the operating system, and then logging all the listening ports. The user would then be given a list of ports (that is, 21, 25, 53, 80, and so on) and an OS type (that is, Linux Kernel 2.2). This approach has a few problems, however, as the user is left with a ton of data (that is, port information) and no details as to what services are actually vulnerable. The user is simply given a blueprint of their system. Identifying what those listening services are, and whether they are vulnerable or not, is an exercise left to the user. For example, if my data set tells me that machine X is running the Linux 2.2 Kernel and has a service listening at port 21, I still have very little idea as to whether I am vulnerable to any of the wu-ftpd buffer-overflow bugs. In fact, I don't even know whether this particular system is running wu-ftpd—it might be running ProFTPd or glftpd, instead. So even when hunting down a single port, I still need to

a.        Identify what is listening at that port

b.       Identify what version that service is

c.        Research whether there are any known vulnerabilities associated with that service and version number

Although this approach might be feasible for a dozen machines or so, it obviously won't scale in mid- to large-sized organizations where thousands of machines are present. The task at hand then moves from difficult to impossible.

A more practical approach would be to build on the previous model of port-scanning and OS identification, and then add some mechanism to identify the listening service types and versions. You would then have another piece of the puzzle completed. Going back to the wu-ftpd buffer overflow example, by identifying the service version, you would now know

a.        That the server is Linux Kernel 2.2-based

b.       That port 21 is listening

c.        What the service type and version is

Let's say that your service query process informs you that you are using wu-ftpd version 2.4.2. This gets you even closer, as now you simply need to research whether wu-ftpd version 2.4.2 has any known vulnerabilities.

Note

You should note the difference between port scanning and vulnerability scanning. Although most vulnerability scanners do indeed scan for open TCP and UDP ports, this is only one of their many features. In contrast, although port scanners like nmap are capable of performing some interesting feats (such as OS fingerprinting), they rarely contain any sort of vulnerability database. In short, most vulnerability scanners take port scanning a few steps farther.

The last remaining component to this process is research—knowing what versions of what services are vulnerable. In many ways, this ties into what attackers do: scan, query, research, and exploit. In this case, it turns out that wu-ftpd version 2.4.2 is, indeed, vulnerable to a known attack type.

Based on the sheer number of known product vulnerabilities (estimated between 2,000–3,000 to date), creating a thorough system to properly identify and track all these product vulnerabilities is a fairly daunting task. The mining and managing of this vulnerability data presents the biggest challenge and the biggest argument for using an automated tool.

Although implementation details vary, based on these examples, you can deduce that there are a number of common components throughout most scanning approaches:

·        The vulnerability data. Vulnerability assessment scanners have internal databases of vulnerability information that help them to accurately identify remote system exposure points.

·        The scanning mechanism. The technical guts of the scanner lie in its capability to properly identify services, subsystems, and vulnerabilities. Depending on how the scanner was written, it might not be efficient at scanning large ranges of machines.

·        The reporting mechanism. Finding a problem is one thing; adequately reporting on it is something entirely different. Some products are stronger than others when it comes to clearly stating what they've discovered.

Some scanners will break this mold, but they are more often the exception than the rule.

Note

A more thorough—and definitely more dangerous—approach is to create a tool that looks for vulnerabilities and actually attempts to exploit them. SNI started going down this path with their original Ballista product. In theory, this would definitively end the problems associated with misdiagnosed vulnerabilities (also referred to as false positives). However, it could also bring about some serious chaos. For example, exploiting vulnerabilities such as the BIND NXT bug crashes the DNS server. If this particular exploit were implemented, all DNS servers running vulnerable versions of BIND would be disabled during every scan!

What to Look For When Choosing a Scanner

Like any product-purchasing decision, before answering the question of which product is right, you first need to decide your specific requirements. For example, if plotting vulnerability- remediation progress over time is something you want automated, then a product's capability to log and plot multiple scan sets is a feature you need to look for. If you have a large NetWare environment, you might want to make sure that the scanner has NetWare-specific checks. If you have to scan 50–100 hosts, efficiency might not be an issue. However, if you need to scan thousands at a time, you'll want to make sure the scanner can scale to that range. Again, many of these issues are specific to what you'll need your vulnerability scanner to do.

There are also some common areas of concern that all products need to address. A few of the issues that you will come into contact with in choosing a vulnerability scanner include

·        Completeness of the vulnerability checks. I don't recommend falling into the trap of playing the numbers game when picking a scanner. However, the number of vulnerabilities a scanner looks for is still important. At a bare minimum, a scanner should look for the known critical vulnerabilities that allow for root/administrator-level compromises.

·        Accuracy of the vulnerability checks. It's important that scanners have a good set of vulnerability checks. However, a scanner's capability to accurately identify those vulnerabilities is also important. Missing a bunch of holes is as equally undesirable as being forced to sift through a report identifying hundreds of non-existent vulnerabilities. Like intrusion detection systems, some scanning products still have problems with false positives.

·        Scope of the vulnerability checks. It should be noted that most of the vulnerability scanners are designed to discover remote vulnerabilities, not local (host-level) ones. However, a few products like ISS and Webtrends have system-level agents that will also look for local vulnerabilities—vulnerabilities that would otherwise be undetectable by remote scans. While these system agents often address a greater range of vulnerabilities, they also require installation, making them a management nightmare for large environments.

·        Timely updates. Although scanners will always be one step behind the vulnerability announcements, they should be updated at a fairly regular (once per month or more) interval. You'll want to look for a scanner that has a significant R&D team behind it that is consistently updating the product.

·        Reporting capabilities. Finding vulnerabilities is important, but properly describing the problems and their subsequent fixes is also important. So is the accurate ranking of the vulnerabilities. This is of particular concern for larger organizations because they usually rely on system administrators to remediate the discovered problem.

·        Licensing and pricing issues. Some of these products are licensed per node, some per server scanned, and some are free. Some of them have an easy licensing system (like NAI); others (like ISS) require a convoluted key-cutting system. Attempting to provide accurate prices and licensing information in this book would be an exercise in futility, as the vendors are constantly changing the terms. However, it should be noted that licensing issues should be thoroughly investigated before purchasing decisions are made, as some of these pricing schemes are just downright obnoxious. When in doubt, however, there is always Nessus, which is free.

No scanner that I know of has addressed all these issues well, but Nessus and ISS Internet Security Scanner come pretty close.

In January 2001, Neohapsis labs released a fairly comprehensive analysis of these tools for Network Computing magazine. Based on the given requirements, Nessus and ISS Internet Security Scanner came out on top of the scanner shoot-out. You can find the story here: http://www.nwc.com/1201/1201f1b1.html.

Fundamental Shortcomings

Just about every security tool discussed in this book has had a set of fundamental problems, and vulnerability scanners are no different. Knowing their limitations is as important as knowing their strengths.

The major shortcomings of these products can be grouped into three categories: completeness, timeliness, and accuracy. First, reviews of these products have shown that many of them catch a fairly high number of known vulnerabilities, but none of them are equipped to identify all of them. As of the fourth quarter of 2000, there were a still a number of the SANS Top Ten that went unnoticed by these products.

You can view the SANS Top Ten list of common vulnerabilities here: http://www.sans.org/topten.htm. While not a definitive list by a long shot, it does list some of the more common holes found on machines today.

Second, most of these products are updated once a quarter, if that often. If a vulnerability is announced in January, your scanner might not be equipped to detect that vulnerability until March. That leaves you with two months to fend for yourself when it comes to scanning. Now, your internal threat identification effort should be on top of this problem anyway, but the point is that these scanners should not be your primary method of defense when it comes to hunting down remotely exploitable exposures.

Another problem is that most modern-day scanners are simply implementing "banner- grabbing" techniques to identify service versions. This technique is arguably sufficient for most environments; however, it can create some interesting scenarios. For example, by simply telnetting to port 25 (SMTP mail) and 21 (FTP), one can identify versions of these two services.

Note that these two machines appear to be running Microsoft Exchange 5.5 and version 4.0 of the Microsoft FTP server. However, many services such as Bind, sendmail, and wu-ftpd are now allowing administrators to change these banners in their configuration files. Although this is not a security threat, changing a default wu-ftpd banner to "Fabio's favorite FTP Server version 1.0" will completely confuse most vulnerability scanning tools. The strange and disturbing moral of this story is that if you want your scanners to be effective, don't change your default banners.

Finally, these products still struggle with false positives. Frequently on large and diverse networks, vulnerability scanners will misfire and report on vulnerabilities that simply do not exist. Although it's better to be safe then sorry, this does create some overhead as personnel then have to run around trying to hunt down phantom vulnerabilities.

Top Vulnerability Scanners

In an ideal world, technology-purchasing decisions would be backed by proper requirement gathering, proper testing, and realistic budgeting. However, I've grown to realize that people rarely have the luxury of doing things the right way. It is for this very reason that I've picked what I consider to be the top vulnerability scanners on the market today, and listed them here. This is not to say that the other products won't do a sufficient job—these are just my personal favorites based on my field experiences and testing. I still encourage the reader to perform some level of investigation when choosing a product to adopt, but the list of products in the following sections should get you started.

Axent NetRecon

Axent's NetRecon complements Axent's existing security product line of firewall and intrusion detection suites. NetRecon's strengths lie in its interface, strong reporting abilities, its moderately sized vulnerability database, and its capability to perform what is often referred to as secondary exploitation—using knowledge gained from one server to assess another. Although it's rare that I've found this final feature useful, it is something not seen in many other products.

NetRecon has traditionally not been as thorough as Nessus, Cybercop Scanner, or ISS, but it is still a fairly comprehensive scanning tool that can be quite useful. It can also report into Axent's Enterprise Security Manager (ESM), which can be used for more general risk assessment efforts.

Vendor: Axent/Symantec

Headquarters: Rockville, MA (USA)

Platform: Windows

Product: NetRecon

URL: http://www.axent.com

ISS Internet Scanner

ISS initially built its company on Internet Scanner, and it has long been regarded as the de facto standard in the industry for vulnerability scanning. Internet Scanner has a strong reporting back-end, a comprehensive set of vulnerability checks, and a very usable GUI. ISS has obviously spent as much time polishing the product as they have on the back-end scanning engine itself. For example, the scanner provides a significant amount of background data on each vulnerability check.

Internet Scanner uses a Microsoft ODBC–based back-end to store its scan data, which can be used later for doing long-term trending. As in NetRecon's integration with ESM, Internet Scanner integrates with the ISS Decisions product. Combined with scanner data, ISS Decisions can be used in conjunction with other security products (firewalls, intrusion detection systems, and so on) to paint a more global picture of vulnerability and threat points.

Although Internet Scanner traditionally hasn't had as many problems with false positives as other products, it does still lag behind on the update front. The other negative point worth mentioning is the fact that in my experience Internet Scanner appears to have become less stable in the 6.x series of releases. I've had numerous problems with it crashing during large scans, and occasionally I'll have to clear out its internal database and start again clean before it will cooperate. It has always been recoverable, however.

It should be noted that ISS also makes two other scanning products, System Scanner and Database Scanner, although both are agent-based and incapable of scanning remote systems.

Vendor: Internet Security Systems, Inc.

Headquarters: Atlanta, GA (USA)

Platform: Windows NT Workstation version 4.0

Product: Internet Scanner

URL: http://www.iss.net

Network Associates Cybercop Scanner

Cybercop Scanner's roots come from NAI's (Network Associates, Inc.) acquisition of SNI (Secure Networks, Inc.) and their Ballista product. Although Cybercop Scanner has an impressive number of vulnerability checks and moderate reporting abilities, it also comes with a number of surprisingly useful tools. Two of the tools that are of particular interest are CASL, and the SMB grinder. CASL enables the GUI-based construction of IP packets, whereas the SMB grinder is similar to the password cracking capabilities of L0phtCrack.

Cybercop's primary downsides revolve around it lacking some fundamentally important vul nerability checks, and its bizarre licensing scheme. NAI usually tries to sell Cybercop on a pernode basis, as opposed to a per-number-of-servers-scanned basis. This can create some horrendously high pricing schemes, depending on the alignment of the stars and the salesperson's current commission plan.

Vendor: Network Associate, Inc.

Headquarters: Santa Clara, CA (USA)

Platform: Windows NT and UNIX

Product: Cybercop Scanner

URL: http://www.nai.com

The Open Source Nessus Project

Nessus was written by Renaud Deraison, an open source author living in Paris, France. Renaud discovered Linux at age 16 and has been hacking it ever since. In 1996, Renaud began attending 2600 meetings and subsequently developed a strong interest in security. This spawned a partnership between Renaud and two other programmers, and together they wrote their first auditing tool in 1997. After tackling that project, Renaud conceived Nessus in early 1998.

Nessus is quickly becoming the Linux of the vulnerability-scanning field. Driven by the open source movement, Nessus wasn't much to speak of a few years ago but is now gaining ground on—and sometimes surpassing—its commercial counterparts. Nessus employs an extensible plug-in model that enables the security community to add scanning modules at will. This gives Nessus a development edge because any check that it does not have can be created by anyone with some time and coding abilities on their hands.

Nessus uses a console-engine model, in which the console might or might not reside on the same computer as the scanning engine. This distributed architecture allows for some interesting flexibility, as you don't need to be anywhere close to the scanning engine in order to control it.

At the time of this writing, Nessus had more than 500 vulnerability checks, some of which still aren't available in the commercial scanning tools. Depending on how the development efforts continue to progress, Nessus could surpass commercial scanners in overall thoroughness in the coming year.

Vendor: NONE (open source)

Headquarters: NONE (Released out of France, however)

Platform: UNIX (Windows console available)

Product: Nessus

URL: http://www.nessus.org

Whisker

Whisker was written by a hacker by the name of "rain forest puppy" (rfp), who has carved out a niche for himself in regards to discovering Web-based vulnerabilities. Whisker doesn't fit the general definition of a vulnerability scanner as it is specifically focussed on scanning for known vulnerable CGI scripts. In fact, the only things it looks for are vulnerable CGI scripts. However, its list of CGI checks is more comprehensive than all the commercial scanners combined. Because of this, I highly recommend you use Whisker in addition to a mainstream scanner.

Vendor: NONE (open source—rfp labs)

Headquarters: Chicago, IL (USA)

Platform: Windows and UNIX

Product: Whisker

URL: http://www.wiretrip.net/rfp/

Other Vulnerability Scanners

The following is a list of scanners that are up-and-coming (although this is not as comprehensive a list as the previous one). I do encourage the reader to continue to monitor the progress of these products, and test them whenever possible.

BindView HackerShield

Vendor: BindView

Headquarters: Houston, TX (USA)

Platform: Windows

Product: HackerShield

URL: http://www.bindview.com

Cisco NetSonar

Vendor: Cisco Systems

Headquarters: San Jose, CA (USA)

Platform: Windows

Product: NetSonar

URL: http://www.cisco.com

SAINT

Vendor: World Wide Digital Security, Inc.

Headquarters: Bethesda, MD (USA)

Platform: UNIX

Product: SAINT

URL: http://www.wwdsi.com

SARA

Vendor: NONE (Open Source)

Headquarters: NONE

Platform: UNIX

Product: SARA

URL: http://www-arc.com

Webtrends Security Analyzer

Vendor: Webtrends

Headquarters: Portland, OR (USA)

Platform: Windows and UNIX

Product: Security Analyzer

URL: http://www.webtrends.com

Summary

Although vulnerability scanners are by no means an all-encompassing solution to identifying vulnerabilities and locking down systems, they can still be extremely valuable tools. As with any security tool, however, one should be aware of the weaknesses these tools exhibit. They are consistently behind when it comes to vulnerability announcements, they do not always report information accurately, and they are not exhaustive when it comes to the depth of their vulnerability data. Using a scanner in conjunction with a solid vulnerability identification effort and a solid set of system lock-down procedures, however, will result in a strong strategy for combating the overall problem.