background image

36

Chapter 4

Vulnerability scanners generally create a lot of traffic on a network and 

are therefore not typically used in a penetration test when one of the objec-
tives is to remain undetected. If, however, you are running a penetration test 
and stealth is not an issue, a vulnerability scanner can save you from having 
to probe systems manually to determine their patch levels and vulnerabilities.

Whether you use an automated scanner or do it manually, scanning is 

one of the most important steps in the penetration testing process; if done 
thoroughly, it will provide the best value to your client. In this chapter, we 
will discuss a number of vulnerability scanners and how they can be integrated 
within Metasploit. We’ll highlight some auxiliary modules in the Metasploit 
Framework that can locate specific vulnerabilities in remote systems.

The Basic Vulnerability Scan

Let’s look at how a scan works at the most basic level. In the following listing, 
we use 

netcat

 to grab a banner from the target 192.168.1.203. 

Banner grabbing

 

is the act of connecting to a remote network service and reading the service 
identification (banner) that is returned. Many network services such as web, 
file transfer, and mail servers return their banner either immediately upon 
connecting to them or in response to a specific command. Here we connect 
to a web server on TCP port 80 and issue a 

GET HTTP

 request that allows us to 

look at the header information that the remote server returns in response to 
our request.

root@bt:/opt/framework3/msf3# 

nc 192.168.1.203 80

GET HTTP 1/1

HTTP/1.1 400 Bad Request

 Server: 

Microsoft-IIS/5.1

The information returned at   tells us that the system running on port 80 

is a Microsoft IIS 5.1–based web server. Armed with this information, we could 
use a vulnerability scanner, as shown in Figure 4-1, to determine whether this 
version of IIS has any vulnerabilities associated with it and whether this par-
ticular server has been patched.

Of course, in practice, it’s not that simple. Vulnerability scans often con-

tain many 

false positives

 (reported vulnerability where none exists) and 

false 

negatives

 (failure to log a vulnerability where one exists) due to subtle differ-

ences in system and application configurations. In addition, the creators of vul-
nerability scanners have an incentive to report positives: The more “hits” a 
vulnerability scanner finds, the better it looks to a potential buyer. Vulnera-
bility scanners are only as good as their vulnerabilities database, and they can 
easily be fooled by misleading banners or inconsistent configurations.

Let’s take a look at some of the more useful vulnerability scanners, 

including NeXpose, Nessus, and some specialized scanners.