cvechecker(1)cvechecker Manual cvechecker(1)NAMEcvechecker - Attempt to identify possible vulnerable software on the
system
SYNOPSIScvechecker [-i] [-l version.dat] [-b binlist.txt] [-c] [-C] [-r] [-s]
[-S] [-d] [-D] [-H] [-w watchlist.txt] [-f filename]
DESCRIPTIONcvechecker is a tool that, simply stated, matches your installed soft‐
ware versus an online database of potential vulnerable software and re‐
port 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 dis‐
cover the version of this software title. This internal list can be up‐
dated 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 watch‐
list 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 in‐
formation 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 remov‐
ing 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 op‐
tion, loading a watchlist will reload the database (clearing your de‐
tected 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 start‐
ing 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 pull‐
cves)
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 ex‐
posed 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 af‐
fected software versions (some CVEs only - falsely - contain the high‐
est version where the vulnerability was present).
cvechecker-r -H
If you want to use the output of the command as input for other com‐
mands (for instance, to create a nice report), you can add the -C argu‐
ment 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 com‐
mands (for instance, to create a nice report), you can add the -C argu‐
ment which makes the output csv-like:
cvechecker-s -C
COMMAND REFERENCEcvechecker 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 stan‐
dard 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 con‐
tains 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 con‐
tains 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 FILEcvechecker will read the configuration file pointed towards by the
CVECHECKER_CONFFILE variable. If that variable is not set, ~/.cvecheck‐
er.rc, /usr/local/etc/cvechecker.conf or /etc/cvechecker.conf, which‐
ever comes first. This file contains the locations as well as other
static parameters for the cvechecker application. An example configura‐
tion 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. Cur‐
rently, "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 (con‐
taining 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, in‐
cluding 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 soft‐
ware/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 op‐
tional, 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 be‐
cause 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 data‐
base 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 sup‐
ported 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 data‐
base, 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 fu‐
ture, 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, edi‐
tion, ... 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 (hard‐
ware) 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 in‐
stance, 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,,,
AUTHORcvechecker was written by Sven Vermeulen <sven.vermeulen@siphos.be>.
August 17, 2013 17 August 2013 cvechecker(1)
