HostedDB - Dedicated UNIX Servers

-->
Internet Security Professional Reference:SATAN and the Internet
Previous Table of Contents Next


Service ($service)

This is the name of the tool with the .satan suffix removed. If a tool does more than one scan, such as rpc.satan, this is the name of the service probed.

Status ($status)

This is a one-character field that indicates the status of the target host, as follows:

Field Description

a Indicates that the target was available
u Indicates that it was unavailable
b Indicates that the target name could not be resolved to an IP address and was therefore a bad name
x Is used for other cases (reserved for future use)

Severity ($severity)

This is a two-character field that indicates the estimated severity of the vulnerability:

Field Description

rs Indicates that the vulnerability could lead to root access on the target system
us Indicates that a user shell could be invoked
ns Indicates that a shell owned by the nobody (uid = 2) user could be invoked
uw Indicates that the vulnerability could lead to the writing of a file as a non-root user
nr Indicates that the vulnerability could lead to a file read as the nobody user

The SATAN documentation does not mention three other listings that are used: x, l, and nw. The l severity corresponds to login information gathered from rusers.satan and finger.satan. The x entry indicates an unknown severity, but with potential for access. The nw indicates that the nobody user can write files.

The ns entry corresponds to ITL class 6; the nr entry corresponds to ITL class 4; and the others (except x and l) correspond to ITL class 5. (Note that permissions corresponding to the nobody user directly relate to world access settings on files.) SATAN breaks down the ITL class 5 group into three parts: the ability to execute a program as any non-root user; the ability to execute a program as the nobody user; and the ability to write files as any non-root user.

In general, if a hacker can modify any non-root user file, the hacker can modify executables that the user will run, resulting in the ability of the hacker to gain execution access. The nobody user concept is quite closely linked with the holes of NFS only.

Trusted ($trusted)

This field consists of two tokens separated by an @—the left part being a user and the right part being a host. (If no @ is included, the entire field is interpreted as the user part.) It represents an account or directory that trusts another target. The user part of that account is selected from these four choices: user, root, nobody, or ANY. The host part can be either the target system or ANY, but only the target system makes sense for the Trusted field. The $trusted account trusts users as specified by the $trustee field.

Trustee ($trustee)

This field represents those users and systems that are trusted by the accounts listed in the $trusted field. It uses the same format as the $trusted field.

Canonical Service Output ($canonical)

For non-vulnerability records,this contains a formatted version of the information, either user name, home dir, last login or filesys, clients. For vulnerability records, this contains a description of the problem type.

Text ($text)

This contains messages used for reports. For example, for a TCP scan, this field contains offers <service >, where <service> corresponds to a service name from the /etc/services file, such as shell.

Sample Fact Record

Here is an example of the output of the rpc.satan scan that consists of records in the fact database record format:

% bin/ftp.satan m2.notreal.com
m2/ftp/a/x///ANONYMOUS/offers anon ftp
m2/ftp/a/nw/~ftp/ANY@ANY/writable FTP home directory/~ftp is writable
%

Both facts have a $target of m2, a $service of ftp, and indicate a $status of a (available). The $severity field for the first record is x, indicating an informational record with unknown severity, whereas the second record shows nw to indicate that anyone (even the nobody user) can write a file using this vulnerability. The $trusted and $trustee fields do not apply to the first record, but the second record indicates that the ~ftp directory ($trusted) grants access to anyone on any other system ($trustee = ANY@ANY). The canonical service output for the first record indicates that the problem is ANONYMOUS access to FTP, whereas the second record indicates the problem is a “writable FTP home directory.” Finally, the $text fields for both records describe the problem for reporting purposes.


Note:  The pathnames of most of the .satan tools assume that they are being run with a default directory of the top-level SATAN program, satan-1.1.1. For example, rpc.satan tries to include config/paths.pl, where config is a subdirectory of satan-1.1.1. Either run these tools from that directory, as shown in the example, or modify these tools to include absolute pathnames.

Another way to understand the facts database is to look at the actual satan-1.1.1/results/satan-data/facts file after running a few heavy scans. This file will be filled with records generated by the .satan tools.

Seeing All the Hosts

The all-hosts text file contains host records, which are used to keep track of hosts that SATAN has seen, regardless of whether these hosts have been scanned by SATAN. Each host record consists of six fields, each separated by a pipe (|) character. Newline characters separate entries in this file.

Each SATAN host record consists of the following six fields:

  The name of the host
  The IP address of the host
  The proximity level from the original target
  The level to which this host has been scanned (-1 for hosts that have not been scanned)
  Whether this host was encountered during subnet expansion (0 for no, 1 for yes)
  The time this host was scanned (in time() format) (optional)

By looking at the satan-1.1.1/results/satan-data/all-hosts file, the structure of these records can be seen:

m2.notreal.com/12.34.56.78/0/2/0/817008639
mailhub.notreal.com/12.3.45.67/1/-1/0/

Notice that mailhub.notreal.com has not been scanned (-1) and therefore has no time entry.


Previous Table of Contents Next