Recently, Marc Ruef @mruef (Computec.ch) has released a new enhanced version of Vulscan, a Nmap script that he already presented in 2010, with basic Vulnerability Scanner capabilities.
Vulscan on the basis of the Nmap option -sV which shows us the versions of the services detected and interacting offline with various vulnerability databases, can alert us if any of those services is potentially vulnerable to any flaw included in any of those databases.
It brings the following pre-installed databases:
Vulnerability Database URL scipvuldb.csv scip.ch/en/?vuldb cve.csv cve.mitre.org osvdb.csv osvdb.org (outdated, 02/03/2011) securityfocus.csv securityfocus.com/bid/ secunia.csv secunia.com/advisories/historic/ securitytracker.csv securitytracker.com
Therefore, a basic example of how this script works would be as follows. After adding the Vulscan folder to the scripts directory where we have our Nmap scripts directory (for testing I’ve used owaspbwa which I knew in advance that provides vulnerable services in port 22 and 80, among others), we run Nmap and this results in the following:
If neither is specified, it will interact with all the pre-installed databases. However, if we want, for example, to cross data with a single database, we’ll add the vulscandb option:
--script-args "vulscandb=basedatos.csv"
specifying the database that we want or even one of our own that we can easily create with the format:
<id>;<title>
One of the enhancements is the support for dynamic report templates using the vulscanoutput option which allows you to enforce your own report structure through the following argument:
--script-args "vulscanoutput='{id} - Title: {title} ({matches})\n'"
where:
A practical case of this script would be, for example, in an scenery where we are conducting a web audit, in which combining this and other NSE scripts for Web scanning of the many that Nmap added on its most significant last update launched one year ago, quickly create a first preliminary report about possible gaps found in that Website such as determining the default Web page title detected during the scanning process (http-title), displaying the directories most widely deployed as network servers or Web applications (http-enum), harvesting the e-mail addresses found during the scanning process (http-email-harvest) and finding the known vulnerabilities in accordance with the Web service service detected using vulscan:
nmap -sV --script=http-title,http-enum,http-email-harvest,vulscan -p80 172.16.94.128
The output report would resemble the following:
Note that, because of space limitations, I have handled the output report in order to avoid showing the full output and only some found vulnerabilities are displayed, not all of them.
Finally, we should take into account that this kind of vulnerability scanning depends to a large extent on Nmap capacity to obtain the version of the detected service, the amount of vulnerabilities documented in the databases and the accuracy of the pattern matching in cross-checking data.
I identified that Vulscan does only pick up the output versions of the nmap -sV option and interacts with them, however, i’d like it to take other outputs from Nse scripts such as html-cms.nse, that detects the scanned CMS version. It would be very useful to use both scripts so one of them detects the concrete CMS version and the other the potential vulnerabilities that could be found for that specific release. I’ve talked to @mruef and he told me that the problem is that it can not access other scripts information unless they provide them in any way such as an output file. The best solution would be that the other nse Scripts enter their identification data at the log output (see the Nmap API http://nmap.org/book/nse-api.html).
According to the Nmap API, the scripts can share information by storing values in a record (a special table available to all scripts). There is a global registry, nmap.registry, shared by all the scripts, whose information prevails during a full Nmap scan, in such a way that scripts can use it, for example, to store the values that later, sequentially, can be used by other script against the same machine within the same scanning, in a way that output of one script brings feedback to the other.
Marc Ruef is already working in a new version that will include new enhancements and features such as e.g. that vulscan 2.0 will support Exploit-DB and IBM X-Force.
References: http://www.scip.ch/?labs.20130625
