Custom Vulnerability Checks

Although SAINT contains thousands of vulnerability checks, there may be reasons to add custom vulnerability checks, such as site-specific security guidelines which define misconfigurations for which there isn't already a check.

SAINT allows you to create custom vulnerability checks without requiring any programming knowledge. All associated information, such as the severity level, CVE, and tutorial, is created along with the check. Once created, a custom check will run at the default vulnerability scan level, and can also be selected when creating custom scan levels.

SAINT also supports basic Microsoft Windows OVAL vulnerability and patch checks. For more information see OVAL checks.

How to Create Custom Checks

To create a custom check, go to the Options icon, and select the Custom Checks link shown in the image below:

Next, click on the New SAINT custom check button.

On the form that appears, enter the following information:

Title – This is the short vulnerability description which will appear on the Data Analysis screens if the vulnerability is detected.
Category – This selection determines where the vulnerability will appear in the vulnerability hierarchy. Top-level categories are indicated by three asterisks (***). Subcategories are indicated by two dashes (--).
Severity – This is the severity level of the vulnerability.
CVE – This is the CVE name for the vulnerability, if any.
Impact, Background, Problem, Resolution, References – These are the paragraphs which are used to create the tutorial for the vulnerability. HTML tags can be used in these fields to create hyperlinks or formatted text.

The next step in creating the check is to create the rule which determines when to report the vulnerability. If the rule is true for a target, then the vulnerability will be reported on that target. There are several rule templates, each of which uses a different check methodology. To create the rule, choose the radio button beside the desired rule template, and fill in the template. The available rule templates follow:

Registry key exists/doesn't exist – Fill in the path to the registry key. Note that the hive HKEY_LOCAL_MACHINE is already there, so start with the top-level key under that, such as SYSTEM or SOFTWARE. Use a backslash to delineate sub-keys.
Registry value equals/not equal/less than/greater than x.y in key – Fill in the registry value, operand, and registry key. Note that a numerical comparison is performed on the operand, which is typically a version number. When entering the key, start with the top-level key under the HKEY_LOCAL_MACHINE hive.
File in folder is dated earlier than date – Fill in the file name, folder name, and date. The folder name should start with the root (either slash or backslash is accepted) and the same character should be used to delineate sub-folders. The date should be in Month/Date/Year format, with a four-digit year.
File in folder is less than version x.y – Fill in the file name, folder name, and version number. The folder name should start with the root (either slash or backslash is accepted) and the same characters should be used to delineate sub-folders. Note that determining the file version requires the file to be downloaded, which could slow down the scan if the file is large.
Received string from port (and version equals/not equal/less than/greater than x.y) – Fill in a string and a port number, or an asterisk or the string <any> to run the check against every port. If the data received from the specified port matches the string, the vulnerability is reported. If the second variation of this template is used, then the %version% substring within the string is a placeholder for a version number to be extracted from the network data, and then a numerical comparison is performed on that version number.
URL contains string (and version equals/not equal/less than/greater than x.y) – Fill in the URL and string. Note that the http://target/ portion of the URL is already there, so specify the URL beginning with the first character beyond the slash following the target, or leave the field blank to specify the home page of the target. The URL will be requested from the server using a GET request, and the vulnerability is reported if the string is found in the resulting page. If the second variation of this template is used, then the %version% substring within the string is a placeholder for a version number to be extracted from the resulting page, and then a numerical comparison is performed on that version number.

After the rule is selected, click on the Create button to create the check.

Running Custom Checks

Custom checks are run the same way as built-in checks. That is, they will be included in scans run at the Vulnerability scan level, and can also be selected when creating custom scan levels. The custom check will appear in the vulnerability hierarchy in the category that was specified when creating the check.

Viewing and Editing Custom Checks

After they have been created, custom checks can be viewed and edited under the Options icon. Click on Custom Checks to see the names of all existing custom checks. Click on the Check ID field beside the desired check to see all of the information that was provided when the check was created. At that point, the check can be modified if desired. After changes have been made, click on the Modify button to save the changes.

To delete a custom check, simply click on the check box beside the name of the custom check on the Custom Checks page and press the Delete Selected button.