Examining All the Things It Did

The SATAN todo file contains a list of hosts, and probes that have been run against those hosts. Each todo record consists of three fields, separated by a pipe (|) character. The fields are as follows:

•  The hostname

•  The name of the tool that was run against that host

•  Any arguments used by that tool during the run against that host

The best way to understand this database format is to look at the satan-1.1.1/results/satan-data/todo file:

m2.notreal.com/tcpscan.satan/0,80,ftp,telnet,smtp,nntp,uucp,6000/
m2.notreal.com/dns.satan/
m2.notreal.com/rpc.satan/
m2.notreal.com/xhost.satan/-d m2.notreal.com:0

Notice that the system m2.notreal.com had tcpscan.satan scan the system for the listed TCP ports, then a dns scan, an rpc scan, and finally, an xhost test.

Understanding the SATAN Rulesets

When making a scan, SATAN first examines vulnerabilities that are explicitly listed in the scan level of the satan.cf file. The scan level can indicate optional checks for a vulnerability by listing it with a “?”. This means that SATAN will check the rulesets to see whether this specific vulnerability scan should be done, based on information that has already been gathered.

For example, the light scan includes “showmount.satan?” after the rpc.satan entry. This means that the showmount.satan script is run only if the mount service is available on the target system, and this information is available as a result of the rpc.satan output. This conditional execution can speed up the execution of SATAN by avoiding unnecessary tests.

Six files in the rules directory constitute the rulesets for SATAN: drop, facts, hosttype, services, todo, and trust.

drop

The drop file is used to determine which facts should be ignored. It currently ships with only a single rule: ignore NFS-exported /cdrom directories. Note that cdrom directories that are NFS-exported but are not named /cdrom are not dropped from the facts database.

The entries in this file use PERL condition matching against each a SATAN fact. The single rule included in the drop file is

$text =~/exports \/cdrom/i

This rule says that the record should be dropped if the $text field contains “exports /cdrom,” because that is the field between the //. Note that the “i” at the end indicates that the search should be case-insensitive.

facts

The facts file deduces new facts based on existing data. Each entry consists of a condition, which is another PERL search condition that is applied against SATAN facts and a fact that is added to the facts file if that condition evaluates to true.

An example clarifies this structure:

/runs rexd/   $target/assert/a/us/ANY@$target/ANY@ANY/REXD access/rexd is
vulnerable

This entry indicates that if a SATAN record includes the text runs rexd, a new SATAN fact is added (assert) to the facts file: This fact says that the $target that has a runs rexd entry (as a result of the rpc.satan scan) is vulnerable.

The remaining entries in the default SATAN facts file look for old sendmail versions, old ftpd versions, and the existence of a modem on a TCP port.

A recent problem with telnetd programs from various manufacturers permitted remote users to pass environment variables, such as shared library information, to the telnetd. If this problem could be detected by the banner given by a vendor’s telnetd, this vulnerability could be detected by adding an entry into this facts file. Unfortunately, most vendors do not put version information into the telnetd banner, but as an example imagine that vendor XYZ included an RCS string of 1.2.3.4. Then, an entry such as this might be reasonable:

/XYZ m2 V5R4 1.2.3.4/
$target/assert/a/uw/ANY@$target/ANY@ANY/Telnetd access/telnetd is vulnerable

This is making further assumptions about the problem that may or may not be accurate; the example is just for illustration of the process.

hosttype

The hosttype file provides rules that allow SATAN to recognize host types based on the banners returned from telnetd, ftpd, and sendmail.

The file consists of a major section (CLASS class_name) that is just used for reporting, followed by the real rules. Each rule is another PERL condition, which is used to try to match against fact records, and the hosttype, which is the conclusion that results if the PERL condition evaluates to true.

Looking at the Ultrix CLASS of the satan-1.1.1/rules/hosttype, three rules are used to identify various versions of Ultrix:

CLASS Ultrix
/ultrix[\/v ]+([.0-9]+[A-Z]*)/i               “Ultrix $1”
/ultrix version 4/i && length(HOSTTYPE) <= 6  “Ultrix 4”
UNKNOWN && /ultrix/i                          “Ultrix”

Notice that version information can be extracted from the match using the standard PERL matching parameters. In the first case, the $1 corresponds to the information that matches to those parts inside the().