VESPER — a tool for managing Vulnerabilities
and Exploits in Software with Portscan-Endorsed
Results

Tanja Hanauer Wolfgang Hommel
Tanja.Hanauer@lrz.de Wolfgang.Hommel@unibw.de

Christoph Wuestner
Christoph.Wuestner@lrz.de

Abstract

1 Motivation

Software can suffer from security vulnerabilities throughout its whole lifecycle: Neglected requirements, design flaws, implementation mistakes, misconfiguration, and careless administration or use may all lead to situations in which an attacker can exploit a vulnerability to his advantage. However, in practice, many attacks still simply exploit outdated software installations: A vulnerability has been identified and made public, and the software vendor already provides a software update (i. e., security patch), but an organization or individual using this software may not yet have installed this update.

In an ideal world, the rigorous use of trustworthy and reliable automated software update mechanisms would solve this problem. Advances over the last decade, especially for desktop operating systems and mobile devices with their default settings and app store concepts, have shown that a large amount of devices can indeed by protected by such a relatively simple technical security measure. However, software installed on server-based systems still suffers from a lack of automated updates, mostly for either of the following two reasons:

1. Professional system administrators are often wary of automated updates as they may disrupt the productive service operation, e. g., due to unwanted configuration modifications or other changes that are not backwards-compatible.
2. Users, especially those renting servers at a hosting company or a virtual machine at a cloud provider, often manually install the most recent version of a software package they want to use if that version is not available through the operation system mechanisms or the web-based management front-end provided to them. However, unless this specific software package includes auto-update mechanisms itself, the automated updates provided by the operating systems mechanisms or the service provider do not cover such manually installed software, while at the same time the users often neglect to manually update the software.

As a consequence, Vulnerability Management (VulnMgmt) has been established as a discipline with the purpose of preventing attackers from exploiting known, and eventually even yet unknown, vulnerabilities. It is typically implemented as a process, i. e., the core activities of identifying, classifying, and either remediating or at least mitigating vulnerabilities are performed on a regular basis [For09]. Given the number of software packages deployed and their vulnerabilities on a long-term and organization-wide scale, VulnMgmt can only be performed efficiently when at least parts of the process are automated through the use of tools [SMH16]. Such tools typically cover the following three aspects:

1. Acquire information about vulnerabilities: This usually combines passive and active activities, such as harvesting databases of known vulnerabilities, mailing lists, and vendor newsletters on the one hand, and performing penetration tests on one's own infrastructure on the other hand.
2. Map vulnerabilities to assets: Affected own systems must be determined, and risk management must be supported by analyzing the probability and impact of attacks, as well as by prioritizing the identified vulnerabilities.
3. Support targeted action: System administrators must receive actionable advice for fixing the found vulnerabilities or at least mitigating their exploitability. For example, configuration workarounds or software updates may be recommended, the progress of implementation has to be tracked, and afterwards the effectiveness of changes must be tested.

Numerous commercial and free software tools offer VulnMgmt functionality and, meanwhile, address anything from single technical aspects up to the whole VulnMgmt process. However, most of the previously existing tools have in common that they handle vulnerabilities in a generic way, i. e., they are not specific for a specific environment or certain software package installations. For their use in practice, this often means that they do not only report true positive results, i. e., only systems that are in fact affected by a vulnerability, but there are also false positive results, which means that a system is claimed to be vulnerable although, in reality, it is not, e. g., due to additional configuration measures that have been taken to prevent a known vulnerability from being exploited.

False positive results have a significant impact on the practical use of VulnMgmt tools: The recipients of VulnMgmt reports, for example system administrators and security team members, get used to the fact that the tool sometimes delivers wrong information and requests actions that are not necessary. During long-term use, they start to ignore more and more reports and finally lose confidence in the usefulness and purpose of the VulnMgmt tool. Similar reactions can be witnessed with false positives in intrusion detection systems (IDS) and security information & event management (SIEM) systems, leading to boy-who-cried-wolf-scenarios in which important alerts are completely ignored because everyone involved assumes that it is just yet another false positive. Various vendors like Advanced Threat Analytics, ESG, or Swimlane also describe the challenge of too many alerts.2

In this paper, we discuss VESPER – Vulnerabilities and Exploits in Software with Portscan-Endorsed Results, our technical approach to identify vulnerabilities in one's own infrastructure, which goes at length to minimize the amount of false positives in its output. Focusing on the true positives was indeed its primary design goal, even though it comes with the cost of having to perform certain steps manually as we detail below. This paper is structured as follows: First, Section 2 analyzes the current state of the art in vulnerability management and related work. In Section 3, we explain the core principles of VESPER and discuss its limitations. Section 4 then outlines the exemplary application of VESPER in a higher education institution data center for a typical use case and compares the achieved results with two other popular VulnMgmt tools. Finally, Section 5 concludes with a summary and an outlook to our ongoing work.

2 The State of the Art in Vulnerability Management
and Related Work

The basic assumption behind any type of VulnMgmt is that the managed vulnerabilities become either publicly known or suitable information is made available through some other channels. We focus our work on the former ones, which, regardless of whether they have been made public through responsible disclosure, full disclosure, or reverse engineering of attacker tools found during security incident investigations, are accessible through public sources. However, the same approach and also our tool may optionally make use of non-public vulnerability information, e. g., regarding software that has specifically been developed for a single customer.

Since more than a decade, the Common Vulnerabilities and Exposures (CVE) database is the de-facto global standard for documenting the core information about each vulnerability. Entries are checked for duplicates and fake reports, assigned a unique identifier (called CVE-ID), and typically include a short description of the identified issue along with links to external, more detailed descriptions. The National Vulnerability Database (NVD) enriches the information provided in the CVE, for example, by also storing each vulnerability's base score according to the Common Vulnerability Scoring System (CVSS); NVD is performing this duty so reliable that other approaches, such as the Open Source Vulnerability Database (OSVDB), have meanwhile shut down.

CVSS, available in version 3 since 2015 but still also used in version 2, is a simple to use scoring system for vulnerabilities: It provides a questionnaire in which answers can be selected for a fixed number of questions, resulting in a score between 0.0 (no severity) and 10.0 (critical severity). The CVSS base score, which is often published, can then be refined by the temporal score and the environmental score, which take...