NAME

cvechecker - Attempt to identify possible vulnerable software on the system

SYNOPSIS

cvechecker [-i] [-l version.dat] [-b binlist.txt] [-c] [-C] [-r] [-s] [-S] [-d] [-D] [-H] [-w watchlist.txt] [-f filename]

DESCRIPTION

cvechecker is a tool that, simply stated, matches your installed software versus an online database of potential vulnerable software and report the results back to you.

To be able to identify which software is installed on your system, cvechecker asks you to load a list of filenames (such as the output of a find command) into the tool using the -b (or --binlist) argument. It will then try to match the files against an internal list of known softwares. If it finds a known software title, it will attempt to discover the version of this software title. This internal list can be updated using the -l (or --loaddata) arguments.

To identify potential vulnerable software, cvechecker downloads the CVE entries from the Mitre site and stores it in the database. The results of the CVE data and the scanned software on the system then provides us with the means to generate a report, listing software/version sets that have one (or more) CVE entries assigned to them.

cvechecker also supports a watchlist. This is a file that contains the CPEs for which you want to watch for CVEs. The watchlist behaves as if the selected software is indeed installed on your system (so it will be visible in the reports that you pull from cvechecker). Using a watchlist allows administrators to add software that is not detectable by cvechecker (yet).

USAGE

INITIALIZATION

To use cvechecker, you first need to initialize the the databases. If your installation uses a server RDBMS (instead of sqlite) this requires database owner privileges. Please consult the user guide for more information on how to initialize the database using SQL files (instead of database owner) if this is not allowed on your system.

cvechecker -i

Next, download the CVE entries from the Internet as well as the version detection rules and load them in the database.

pullcves pull

LOAD SOFTWARE LIST

Every time your system changes, you need to (re)load the software list in the database. Otherwise, cvechecker will keep on reporting about software and versions that you might not have anymore (or not report about software that you have). A possible method is to use find to identify all executable commands and libraries and load those in cvechecker. I also recommend to add /proc/version as this allows cvechecker to validate Linux kernel vulnerabilities as well.

find / -path /mnt -prune -o -path /media -prune -o -type f -perm -o+x > scanlist.txt 
echo "/proc/version" >> scanlist.txt
cvechecker -b filelist.txt

It is possible to only update a part of the file database when you add the -d (--deltaonly) option. This is useful when you integrate cvechecker with your package management system. It also supports removing a part of the entries in the database (such as when you uninstall software) when you add the -D (--deletedeltaonly) option.

LOAD WATCHLIST

Like the software list, you can have cvechecker load a watchlist. This load can happen concurrently with the filelist and also supports the delta options. Be aware though that, if you do not use the delta option, loading a watchlist will reload the database (clearing your detected software). As such, it is recommended to use the watchlist at the same time with your binary file listing, like so:pr

cvechecker -b filelist.txt -w watchlist.txt

In the reports, watchlist-provided software will have a filename starting with "<<provided>>" and named after the CPE they represent.

LOAD LATEST CVE ENTRIES

Pull in the latest CVE entries from the Internet (see also man pullcves)

pullcves pull

REPORT ON POTENTIAL VULNERABILITIES

To get a report on potential vulnerabilities, run cvechecker with the -r argument.

cvechecker -r

If you want cvechecker to report on vulnerabilities that have been exposed with higher versions of software that you have installed, you can add the -H (--reporthigher) option. However, be warned that this will give lots of false positives. The upside is that you can find potential vulnerabilities in software whose CVE entries doesn't contain all affected software versions (some CVEs only - falsely - contain the highest version where the vulnerability was present).

cvechecker -r -H

If you want to use the output of the command as input for other commands (for instance, to create a nice report), you can add the -C argument which makes the output csv-like:

cvechecker -r -C

REPORT ON DETECTED SOFTWARE

To get a report on the detected software, run cvechecker with the -s (only software) or -S (software with files that lead to the software detection) argument.

cvechecker -s

If you want to use the output of the command as input for other commands (for instance, to create a nice report), you can add the -C argument which makes the output csv-like:

cvechecker -s -C

COMMAND REFERENCE

cvechecker supports the following arguments:

-i, --initdbs: Initialize the databases
-l <datafile>, --loaddata=<datafile>: Load the version detection rules
-b <binlist>, --binlist=<binlist>: Load the list of binaries available on the system. Accepts standard input if "-" is given.
-c <cvelist>, --cvedata=<cvelist>: Load the CSV file with CVE data. The CSV file can be generated with nvd2simple, part of the cvechecker package. Normally you don't need to call this argument as it will be done by pullcves anyway.
-f <binfilepath>, --fileinfo=<binfilepath>: Load a single file path in cvechecker. This allows you to verify if cvechecker can identify the binary or not (as it will display the CPE data if it can)
-r, --runcheck: Match the identified software and versions against the known CVE entries and report it on the screen
-C, --csvoutput: Report using CSV-like output.
Only interesting when used with -r or -s
-s, --showinstalled: Show the detected software/version sets of this system
-S, --showinstalledfiles: Show the detected software/version sets of this system together with the files that are used to detect this software/version set
-d, --deltaonly: The file passed on through the -b (--binlist) option only contains files that need to be added to the file database (and checked for versions) rather than a full file system dump
-D, --deletedeltaonly: The file passed on through the -b (--binlist) option only contains files that have been uninstalled from the system, and thus can be removed from the database
-H, --reporthigher: Do not only report on CVEs that affect software installed on your system, but also on CVEs that affect higher versions of the software that is installed on your system
-w <watchlist>, --watchlist=<watchlist>: Load the watchlist information (a file containing CPE entries - one per line - using the official CPE syntax)

CONFIGURATION FILE

cvechecker will read the configuration file pointed towards by the CVECHECKER_CONFFILE variable. If that variable is not set, ~/.cvechecker.rc, /usr/local/etc/cvechecker.conf or /etc/cvechecker.conf, whichever comes first. This file contains the locations as well as other static parameters for the cvechecker application. An example configuration file is:

#
# Generic settings
#
dbtype = "mysql";
#dbtype = "sqlite3";
cvecache = "/var/lib/cvechecker/cache";
datadir = "/usr/share/cvechecker";
stringcmd = "/usr/bin/strings -n 3 '@file@'";
version_url = "https://raw.github.com/sjvermeu/cvechecker/master/versions.dat";
#userkey = "servertag";
#
# For SQLite3
#
sqlite3: {
  localdb = "/var/lib/cvechecker/local";
  globaldb = "/var/lib/cvechecker/global.db";
}
#
# For MySQL
#
mysql: {
  dbname = "cvechecker";
  dbuser = "cvechecker_rw";
  dbpass = "passwordforcvechecker_rw";
  dbhost = "mysql.company.com";
};

The following options are supported:

•: dbtype tells the cvechecker application which back-end to use. Currently, "sqlite", "sqlite3" and "mysql" are supported (sqlite and sqlite3 result in the same back-end)
•: cvecache is a (cvechecker writeable) directory where pullcves will download all XML files and store the transformed XML2CSV files (containing the CVE entry data). Although it is not used anymore after being imported into the local databases, pullcves relies on the availability of the XML files to find out if it needs to (re)download and import CVE entries. So if you want to clean out the directory, make (empty) files named after the XML files so that pullcves does not redownload and reimport the CVE entry data (not that this will render the application unusable, but it takes a while)
•: datadir is a directory where cvechecker-related files are stored, including the XSLT transformation files used to convert CVE XML files in CSV files as well as the sample reporting files as used in this document
•: stringcmd is the command that cvechecker launches against a file to get the files' content. Currently, this is the only supported method for cvechecker to identify the software/version.
•: version_url is the location where pullcves can find the latest software/version matching rules to identify installed software on the system.
•: servertag is an optional setting that is used in case of server RDBMS backends to differentiate between the cvechecker clients. It is optional, because cvechecker already uses the clients' hostname as a key, but users can define a second one. This can be both because they want to run multiple clients from the same system/hostname, or because they want a more proper key for their identification (such as a server serial id or asset tag). This key is displayed in the reports.
•: sqlite3: combines all sqlite specific settings, which are:

•: localdb is a (cvechecker writeable) directory where cvechecker will store its sqlite3 databases containing the CPE data (identification information of software/versions) as well as the local systems' matching file/software pairs and all downloaded CVE entries
•: globaldb is a (cvechecker writeable) sqlite3 database containing the software/version matching rules and CPEs associated with these rules

•: mysql: combines all mysql specific settings, which are:

•: dbname is the name of the cvechecker database
•: dbuser is the user that cvechecker uses to connect to the database
•: dbpass is the password that cvechecker uses to connect to the database and authenticate itself
•: dbhost is the hostname where the database resides

CVECHECKER IS NOT COMPLETE

The strength of cvechecker can only be fully used if the list of supported software is huge. Currently, the list is too small to cover most systems. However, if you want to help us out in creating a larger database, please read on.

The format used to import software detection rules is as follows:

,[filepart],1,[fileregexp],[contentregexp],a,[vendor],[product],[version],[update],[edition],[language]

The first comma tells cvechecker what the field separator is, so if you need to use the comma in a regular expression, you can use a different field separator. Just start the line with the separator.

•: filepart is a string which cvechecker will match against the filename (not fully qualified). If it matches, cvechecker will continue with this file's investigation. This is merely for performance reasons
•: 1 is the type of check that cvechecker will execute to find out about the software's version. Currently, only 1 is supported. In the future, more methods will be added.

•: The "1" method uses the output of strings <file>. The output is then matched against a regular expression (with grouping) and the results of the matches are then used to identify the version, edition, ... of the software

•: fileregexp is a regular expression statement that cvechecker will run against the filename (not fully qualified). If it matches, cvechecker will continue with this file's investigation.
•: contextregexp is a regular expression statement that cvechecker will run against the output of the strings <file> command. If it matches, the same regular expressions' grouping output will be used to fill up the metadata about the software
•: a means that this is an application match. Other values are h (hardware) or o (operating system). From this point onwards, all next fields are part of the CPE specification
•: vendor is the vendor name of the software. You can deduce the vendor name by surfing to the software's homepage/vendor's homepage. The vendor name is the domainname, without any prefix or suffix. For instance, www.redhat.com yields "redhat". If no vendor exists, then the vendor is the name of the author. For instance, Sven Vermeulen yields "sven_vermeulen".
•: product is the name of the software title itself
•: version is the version of the software. It will most likely use grouping references (\1, \2, ...) from the regular expression
•: update is the update of the software. It will either be empty, or use the grouping references (\1, \2, ...) from the regular expression
•: edition is the edition of the software. It will either be empty, or use the grouping references (\1, \2, ...) from the regular expression
•: language is the language of the software. It will either be empty, or use the grouping references (\1, \2, ...) from the regular expression

I have mentioned CPE. CPE stands for Common Platform Enumeration and is a standard for identifying a product with version. More information on CPE can be found at http://nvd.nist.gov/cpe.cfm and http://cpe.mitre.org/specification/index.html.

A few examples of these detection rules:

,ncftp,1,ncftp,^.*NcFTP ([0-9\.]+)/([0-9]+) .*,a,ncftp_software,ncftp,\1,\2,,
,libflashplayer.so,1,libflashplayer.so,FlashPlayer_([0-9]+)_([0-9]+)_([0-9]+)_([0-9]+)_FlashPlayer,a,adobe,flash_player,\1.\2.\3.\4,,,
,perl,1,perl.*,/usr/lib/perl5/site_perl/([^/]+)/,a,perl,perl,\1,,,

AUTHOR

cvechecker was written by Sven Vermeulen <sven.vermeulen@siphos.be>.