Building weak credential vulnerability checks

Custom vulnerability check data is not compatible with the Insight Platform

If you are an InsightVM subscriber that leverages the custom vulnerability check capabilities described in this article, be aware that any custom checks you create and any scan data derived from those checks will be contained in and limited to the on-premises Security Console. Custom checks and their scan results do not travel upstream to the Insight Platform. This means they will not exist in InsightVM's cloud-based features and experiences, such as Dashboards, Remediation Projects, and Goals and SLAs.

The Security Console includes a framework for creating complex vulnerability checks using a simple XML format. These vulnerability checks are split across two or more files which are parsed by the Security Console when the scan engine is started.

This article covers a basic example for a vulnerability check that looks for weak credentials, called weak_creds.pl.

This check is not officially supported by Rapid7

This vulnerability check is community-built. This article was migrated from a separate Rapid7 community resource that has since been deprecated. Rapid7 will not be able to provide support or troubleshooting assistance for this example or other custom-built vulnerability checks.

Usage

 
1
Usage: weak_creds.pl [Options]
2


3
Input options:
4
    -s  --services [service(s)]     Service(s) to generate weak creds checks for (comma-seperated)
5
    -u  --usernames [file]          File of usernames (one per line)
6
    -p  --passwords [file]          File of passwords (one per line)
7
    -r  --realms [file]             File of realms (one per line) - (*optional*)
8
    -d  --dir [dir]                 Output directory (default: $service/) - (*optional*)
9
 
10
For databases, the realm represents the database name. If a realm file is not passed, weak_creds.pl uses the default database name.
11
 
12
Supported Services include db2, tds, mysql, postgres, ssh, ftp, telnet, rsh, oracle, cifs, tomcat, and as400

Example

Running weak_creds.pl will generate the new .vck and .xml files within a directory corresponding to the service for the checks.

 
1
$ ./weak_creds.pl  -s ssh -u usernames.txt  -p passwords.txt 
2
$ ls ssh/*
3
ssh/ssh-weak-creds-account-foo-password-bar.vck 
4
ssh/ssh-weak-creds-account-foo-password-bar.xml

Deploy your vulnerability checks

To deploy this vulnerability check into the Security Console, simply copy your .xml and .vck files into the following directory for the Security Console and any paired Scan Engines:

 
1
cp -vf ssh/* /opt/rapid7/nexpose/plugins/java/1/CustomScanner/1/

Next, restart the Security Console. You should see something like the following message in the log:

 
1
NSC  3/13/10 11:10 AM: Imported 1 new and 0 modified vulnerabilities in 22 seconds

How to manually load your check content

Within the the Security Console's and Scan Engine's command line interfaces, new vulnerability checks and descriptions may be loaded without restarting the respective services. The load content command initiates a background reload of vulnerability information.

 
1
> load content
2
2018-01-03T11:29:21 [INFO] > load content
3
2018-01-03T11:29:28 [INFO] Loading vulnerability and solution managers.
4
2018-01-03T11:29:35 [INFO] [Started: 2018-01-03T16:29:28] [Duration: 0:00:07.102] Completed loading vulnerability and solution managers
5
2018-01-03T11:29:35 [INFO] Loading vulnerability check manager.
6
... content trimmed for this article ...
7
2018-01-03T11:35:02 [INFO] Load Content command complete.