Vulnerability Hierarchy

At the root of SAINT's scan level configuration model is a vulnerability check hierarchy consisting of categories, sub-categories, and individual vulnerability checks. The vulnerability check hierarchy is defined in the config/vulns.dat file.

Vulnerability Categories

At the top of the vulnerability hierarchy are 12 top-level categories. These correspond to the 12 vulnerability classes defined in SAINTwriter reports. Specifically, they are as follows:
 
  1. web – Vulnerabilities in web servers, CGI programs, and any other software offering an HTTP interface
     
  2. mail – Vulnerabilities in SMTP, IMAP, POP, or web-based mail services
     
  3. ftp – Vulnerabilities in FTP and TFTP services
     
  4. shell – Vulnerabilities in ssh, telnet, rlogin, rsh, or rexec services
     
  5. print – Vulnerabilities in lpd and other print daemons
     
  6. rpc – Vulnerabilities in Remote Procedure Call services
     
  7. dns – Vulnerabilities in Domain Name Services
     
  8. database – Vulnerabilities in database services
     
  9. net – Vulnerabilities in routers, switches, firewalls, or any SNMP service
     
  10. win – Missing Windows hotfixes or vulnerabilities in the registry or SMB shares
     
  11. pass – Missing or easily guessed user passwords
     
  12. misc – Any vulnerability which does not fit into one of the above classes

 

Many of these top-level categories contain sub-categories. For example, mail vulnerabilities are further subdivided into IMAP, POP, and SMTP vulnerabilities. Some sub-categories themselves contain sub-categories. The result is a logical hierarchy of vulnerability categories into which individual checks are placed, making it easy to find any desired check by drilling down from the top-level categories to the more specific categories.
 

Each vulnerability check is assigned a unique identifier. The identifier always starts with the top-level category, followed by the progression of sub-categories if any, followed by a string which identifies the check itself, separated by underscores. For example, the check for vulnerable Apache web server versions is identified by web_server_apache_version. web is the top-level category. server is the sub-category of web which contains vulnerabilities in web server software. apache is the sub-category of server which contains vulnerabilities in the Apache web server. version uniquely distinguishes the check from any other checks in the apache sub-category.

The vulns.dat file

The vulns.dat file, found in the config directory, contains the vulnerability hierarchy and all associated information. Similar to the SAINT database format, vulns.dat consists of records, one on each line, separated by pipe characters (|). There is also a vulns_custom.dat file which contains information on custom checks, if any have been created.

 

There are two types of records. Category records define a category or sub-category and consist of three fields: the category identifier, the category description, and the word "category", in that order.

 

The second type of record is for vulnerability checks. Vulnerability check records consist of eight fields:

 

  1. The vulnerability identifier
     
  2. The vulnerability description – This should be the same as or similar to the text (eighth) field of the fact corresponding to the vulnerability.
     
  3. The vulnerability tutorial – This should be the same as the seventh field of the fact.
     
  4. Maximum severity (red, yellow, or brown)
     
  5. CVEs – A space-separated list of CVE numbers. An asterisk indicates CVEs which are explicitly included as examples in the SANS Top 20. A question mark indicates related entries which may be specific cases of the vulnerability, but which are not generally applicable. "r", "y", and "b" indicate severity levels specific to that CVE entry which differ from that specified in the preceding field. "x" indicates a dangerous check is available.
     
  6. SANS Top 20 – This field is 1 if the vulnerability falls into the SANS Top 20, and 0 otherwise.
     
  7. Authentication – This field is 0 if no authentication is required, 1 if authentication is required, 2 if an SNMP read community string is required, and 3 if both unauthenticated and authenticated checks exist.
     
  8. SAINT probe dependencies – This field lists all probes which need to run for the vulnerability to be detected, without the .saint extensions, and separated by semi-colons. Question marks indicate conditional probes, which are only run if one of the rules in the todo rule set is matched. tcpscan and udpscan should be followed by a port number, list, range, or an asterisk which indicates that all ports included at the heavy scan level should be scanned. An asterisk would be used, for example, if the vulnerable application runs on a random port.

 

Returning to our previous example of the Apache web server version check, the record would appear as (with line breaks added for readability): 
web_server_apache_version|vulnerable Apache version|
Apache vulnerabilities|red|CVE-2002-0392* CVE-2002-0661|
1|0|tcpscan 80;http?
This indicates that the maximum possible severity for this vulnerability is red; there are two CVE entries, the first of which is explicitly listed as an example on the SANS Top 20 list; the vulnerability is in the SANS Top 20; the check does not require any special authentication; and the vulnerability is detected by running tcpscan.saint against port 80, and if appropriate, http.saint.