Benchmarks for Corporate Security

The CIS Benchmarks map corporate and government guidelines that serve as benchmarks for compliance. The benchmarks describe configurations, conditions, audits and tests for various setups and systems in detail. After a successful scan, IT admins receive a comprehensive report with a percentage figure that provides information about the compliance of the systems, but also immediate recommendations for further hardening measures.

Compared to the requirements of IT-Grundschutz, CIS Benchmarks often prove to be significantly more detailed, but therefore also more comprehensive. Unlike the many tests in the Greenbone Enterprise Feed, which look for security gaps and vulnerabilities to help defend against attacks, the CIS Benchmarks serve to prove that a company or an authority complies with the applicable compliance regulations at all times and has always done so.

CIS Benchmarks at Greenbone

Already since 2021, Greenbone integrates numerous compliance policies for CIS Benchmarks. These policies are sets of tests that a Greenbone product runs on a target system. In simple terms, for each individual requirement or recommendation from a CIS Benchmark, a vulnerability test is developed to verify compliance with that requirement or recommendation. All tests are combined by Greenbone into scan configurations and added to the Greenbone Enterprise Feed. Since the scan configurations in this case map enterprise or government policies, they are referred to as “compliance policies”.

In 2022, Greenbone is significantly expanding the set of CIS compliance policies included in the Greenbone Enterprise Feed. 18 additional compliance policies for CIS Benchmarks for diverse product families have been added. In addition to a compliance policy for Docker containers, tests are now available for Windows 10 Enterprise, Windows 2019 Server, Centos and distribution-independent Linux benchmarks. In addition, web masters running servers such as Apache (2.2 and 2.4), NGINX, Tomcat, and Microsoft IIS 10, as well as database administrations (MongoDB 3.2 and 3.6, Oracle Community Server 5.6 and 5.7, and PostgreSQL 9.6, 10, 11, and 12) can now access compliance policies for CIS Benchmarks.

CIS Benchmarks: Level 1, 2 and STIG

The CIS Benchmarks are divided into several levels (Level 1, 2 and STIG) and usually include several configuration profiles to be tested. Level 1 provides basic recommendations for reducing an organization’s attack surface, while Level 2 addresses users with special security needs. STIG – the former Level 3 – on the other hand is mainly used in military or government environments. STIG stands for Security Technical Implementation Guide. The US Department of Defense maintains a web page with all the details. The DISA STIGs (Defense Information Systems Agency Security Technical Implementation Guides) described there are a requirement of the US Department of Defense.

Certified by CIS

Greenbone is a member of the CIS consortium and is continuously expanding its CIS Benchmark scan configurations. Like all compliance policies developed by Greenbone on the basis of CIS Benchmarks, the latest ones are certified by CIS – this means maximum security when it comes to auditing a system according to CIS hardening recommendations. This not only simplifies the preparation of audits, important criteria can be checked in advance with a scan by a Greenbone product and, if necessary, any weaknesses found can be remedied before problems arise.

Since Log4j is included in numerous software products, the manufacturers of the products had to and still have to provide updates as well. This is still ongoing, and more Log4j vulnerabilities may emerge in the future.

As a moving target, Log4j still gets a lot of attention, under various aspects:

• New (and luckily still less severe) vulnerabilities are found.
• New initiatives are emerging proactively to check log4 sources, such as Google’s initiative: Improving OSS-Fuzz and Jazzer to catch Log4Shell
• At Greenbone, we are creating even more vulnerability tests to get better test coverage, and deploy them to our products on a daily basis.

We have already received a pretty good CVE coverage for the additional Log4j vulnerabilities that have been published in the last few days, including:

• CVE-2021-44228
• CVE-2021-4104
• CVE-2021-45046
• CVE-2021-45105

As mentioned earlier, we do not stop here. More local security checks will follow today and tomorrow, once Linux distributions have published their advisories.

We already published some facts about Log4j and how to deal with it in our recent posts:

• log4j Vulnerability Detection Available in Greenbone Feeds
• In-Depth Information About Greenbone’s log4j Vulnerability Test Coverage

Update from 2021-12-20: vulnerability tests for products running on Microsoft Windows are now available.

Note: The tests check the existence of Log4j and its version. A separate vulnerability test may not be available for each affected application, but all Log4j files are found and reported (/path-to-log4j-file/).

The issued installation paths must be checked and, if necessary, the vendor must be contacted. It must be checked whether updates are already available for the respective application and whether the find is relevant.

PowerShell execution privileges on a target system are required for the account used in an authenticated scan. Some vulnerability tests execute PowerShell commands to increase the accuracy of the results, which require permissions for the duration of a scan.

Update from 2021-12-15: an additional attack vector was identified and reported in CVE-2021-45046. We are working on vulnerability tests for this vector, although our tests are working for this additional case too. We recommend to update to the latest Log4j version. The attack is more complicated and a protection requires a different configuration. But as this is a very new vector, we advise to better be save than sorry. For more information see https://www.lunasec.io/docs/blog/log4j-zero-day-update-on-cve-2021-45046/.

This article collects answers to the most frequently asked questions regarding Greenbone’s Log4j vulnerability test coverage.

What Is this Vulnerability About?

The “Log4Shell” vulnerability affects a software library responsible for recording events (so called “logging”) in software written in the Java programming language. A malicious attacker can use this vulnerability to execute code on the affected systems.

Since this vulnerability can be exploited through the Internet and without any authentication, this can be very critical for affected systems and companies. As the software is also included in a lot of software and services accessible through the Internet, many companies and services are likely to be affected.

More information about this vulnerability can be found here:

• heise online (German only): https://www.heise.de/news/Kritische-Zero-Day-Luecke-in-log4j-gefaehrdet-zahlreiche-Server-und-Apps-6291653.html
• Federal Office for Information Security (German only): https://www.bsi.bund.de/DE/Service-Navi/Presse/Pressemitteilungen/Presse2021/211211_log4Shell_WarnstufeRot.html
• LunaSec: https://www.lunasec.io/docs/blog/log4j-zero-day/
• National Vulnerability Database (NVD): https://nvd.nist.gov/vuln/detail/CVE-2021-44228

Are any Greenbone Products and Services Affected?

We checked the status of potentially affected systems with the highest priority. None of our products or internally and externally provided services are affected.

Can Greenbone Products Detect this Vulnerability?

Yes, detection routines have been integrated into the Greenbone Community Feed and into the Greenbone Enterprise Feed starting with feed version 202112130808. This means that both our appliances and our cloud product are able to detect this vulnerability.

While detection routines are available, the complex nature of this vulnerability means that a detection cannot be guaranteed to find every single affected system or products. This especially applies to unauthenticated “remote” checks, for the following reasons:

• The product or service may only be vulnerable under very specific circumstances. As the Log4j library is very complex and highly configurable and it is used differently in many products, it is not possible to find all vulnerable instances through a remote check.
• Security configurations in the customer’s network may prevent a successful verification of the vulnerability.
• Products and services may also be affected indirectly.

A custom scan configuration for directly detecting this vulnerability as quickly as possible is also available through both feeds. Please note that the current scan configuration only contains active checks (remote and local). Package-version checks are not included to keep the scan configuration, and thus the scan time, minimal.

Is the Detection Included in the Greenbone Community Feed?

Yes. A basic detection for the vulnerability is included in both feeds. Additional vulnerability tests for potentially affected enterprise products are available through the Greenbone Enterprise Feed.

Which Detection Is Included in Which Feed?

Greenbone Enterprise Feed

We are continuously deploying vulnerability tests into the Greenbone Enterprise Feed, so the following list may be incomplete, but reports the status of 2021-12-14, 12:00 p.m.

Important: To get the most current information regarding your installation, you can search for ~CVE-2021-44228 in the “CVE” and “NVTs” section of the “SecInfo” menu on the web interface of your installation.

• Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (Log4Shell)
• Apache Log4j Detection (Linux/Unix SSH Login)
• Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (HTTP, Log4Shell) – Active Check
• Apache Struts 2.5.x Log4j RCE Vulnerability (Log4Shell)
• Apache Druid < 0.22.1 Multiple Vulnerabilities (Log4Shell)
• Apache Flink < 1.13.4, 1.14.x < 1.14.1 Log4j RCE Vulnerability (Log4Shell)
• Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (TCP, Log4Shell) – Active Check
• Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (UDP, Log4Shell) – Active Check
• Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (SIP, Log4Shell) – Active Check
• Apache Solr 7.x, 8.x Log4j RCE Vulnerability (Log4Shell) – Version Check
• Debian: Security Advisory for apache-log4j2 (DSA-5020-1)
• Debian LTS: Security Advisory for apache-log4j2 (DLA-2842-1)
• Elastic Logstash Log4j RCE Vulnerability (Log4Shell)
• Openfire < 4.6.5 Log4j RCE Vulnerability (Log4Shell)
• VMware vCenter Server 6.5, 6.7, 7.0 Log4j RCE Vulnerability (VMSA-2021-0028, Log4Shell) – Version Check
• VMware Workspace ONE Access Log4j RCE Vulnerability (VMSA-2021-0028, Log4Shell)
• VMware vRealize Operations Log4j RCE Vulnerability (VMSA-2021-0028, Log4Shell)
• VMware vRealize Log Insight Log4j RCE Vulnerability (VMSA-2021-0028, Log4Shell)
• VMware vRealize Automation Log4j RCE Vulnerability (VMSA-2021-0028, Log4Shell)
• VMware vRealize Orchestrator Log4j RCE Vulnerability (VMSA-2021-0028, Log4Shell)
• VMware vCenter Server 6.5, 6.7, 7.0 Log4j RCE Vulnerability (VMSA-2021-0028, Log4Shell) – Active Check
• ArcGIS Server <= 10.7.1 Log4j RCE Vulnerability (Log4Shell)
• Metabase < 0.41.4 Log4j RCE Vulnerability (Log4Shell)
• Splunk 8.1.x, 8.2.x Log4j RCE Vulnerability (Log4Shell)
• Wowza Streaming Engine <= 4.8.16 Log4j RCE Vulnerability (Log4Shell)
• SonicWall Email Security 10.x Log4j RCE Vulnerability (SNWLID-2021-0032, Log4Shell)
• IBM WebSphere Application Server Log4j RCE Vulnerability (6525706, Log4Shell)

Greenbone Community Feed

We are continuously deploying vulnerability tests into the Greenbone Community Feed, so the following list may be incomplete, but reports the status of 2021-12-14, 12:00 p.m.

Important: To get the most current information regarding your installation, you can search for ~CVE-2021-44228 in the “CVE” and “NVTs” section of the “SecInfo” menu on the web interface of your installation.

• Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (Log4Shell)
• Consolidation of Apache Log4j detections
• Apache Log4j Detection (Linux/Unix SSH Login)
• Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (HTTP, Log4Shell) – Active Check
• Debian: Security Advisory for apache-log4j2 (DSA-5020-1)
• Elastic Logstash Log4j RCE Vulnerability (Log4Shell)
• Debian LTS: Security Advisory for apache-log4j2 (DLA-2842-1)
• Openfire < 4.6.5 Log4j RCE Vulnerability (Log4Shell)
• Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (TCP, Log4Shell) – Active Check
• Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (UDP, Log4Shell) – Active Check
• Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (SIP, Log4Shell) – Active Check

About Authenticated/Unauthenticated Tests

Some version checks require authentication, others do not. Additionally, some could have both.

The respective information is available through the links returned by the search for ~CVE-2021-44228 in the “CVE” and “NVTs” section of the “SecInfo” menu on the web interface of your installation.

The “Quality of Detection” contains information on the detection method. A value of “package (97 %)” indicates an authenticated check, other values like “remote_banner (80 %)” happen unauthenticated.

For more technical information about this see https://docs.greenbone.net/GSM-Manual/gos-21.04/en/reports.html#quality-of-detection-concept.

About Active Tests/Test Checking Version, QoD

You can see if it is an active check based on the QoD and the “Detection Method” on the web interface when viewing the vulnerability test details.

Note: Only systems which are actually logging input which can be modified by an attacker (e.g., specific HTTP request headers, URLs, …) are vulnerable.

The detection method, Quality of Detection, mitigation and lots of further details are available through the links returned by the search for ~CVE-2021-44228 in the “CVE” and “NVTs” section of the “SecInfo” menu on the web interface of your installation.

Scanning for Nodes on Separate VRFs & VLANs

• Out-of-band (OOB) scanning is currently not possible. Please scan in each segment.
• We think of such an Out-of-band (OOB) communication/external interaction possibility to be integrated in the future.

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.

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.

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.

Let’s take a look at the history of the feed.

In 2005, the development of the Nessus vulnerability scanner decided to stop working under open source licenses and switch to a proprietary business model. By that time, members from Intevation and DN-Systems – the two companies that would later found Greenbone Networks – were already contributing developments to Nessus. In 2006, several forks of Nessus were created in response to the discontinuation of the open source solution. Of these forks, only one remains active: OpenVAS, the Open Vulnerability Assessment System.

In late 2008, Greenbone was formed to push OpenVAS. In the same year, two other companies became active: Secpod from India and Security Space from Canada. Both focused on providing vulnerability testing and partnered with Greenbone to create a reliable and up-to-date feed of vulnerability tests.

This started with the removal of source code and vulnerability tests where the license was unclear or incompatible. Several thousand vulnerability tests were eliminated to get a clean baseline with just under 3000 vulnerability tests at the time.

Shortly after, the content of the feed grew rapidly and steadily to over 10,000 vulnerability tests. 50,000 tests were then contained in the feed after about 8 years of development in 2016. The next 50,000 followed after only 5 more years and represent the current state with more than 100,000 vulnerability tests.

Number of VTs over time

How Is the Feed Composed Anyway?

It is also interesting to see how these 100,000 vulnerability tests in the feed are put together. In our SecInfo Portal, you can easily take a look at all the included tests yourself.

About half of the tests detect vulnerabilities with a high severity class – i.e., with a severity between 7.0 and 10.0. Another 40,000 tests such with the severity class “Medium” (severity 4.0 to 6.9).

Distribution of VTs by severity class

Vulnerabilities for the same area are grouped into families. Among the largest families of vulnerability tests are mainly those for local security checks, i.e., authenticated scans. In these, the target is scanned both from the outside via the network and from the inside using a valid usage login. Thus, more details about vulnerabilities can be found on the scanned system. Vulnerability tests for such authenticated scans already account for over 60,000 tests. The largest VT families with a total of almost 30,000 vulnerability tests are “Fedora Local Security Checks” and “SuSE Local Security Checks”.

Number of VTs in the top 10 VT Families

Globally Known Vulnerabilities Are also Covered

The general public is unaware of many vulnerabilities. But every now and then, particularly significant and spectacular cyber attacks make it into the media – especially when many large companies or governments are affected.

Greenbone reacts immediately when such incidents become known and starts developing a corresponding vulnerability test. Such notable vulnerabilities in recent years include Heartbleed (2014), POODLE (2014), DROWN (2016), Meltdown (2018), Spectre (2018), BlueKeep (2019) and PrintNightmare (2021). Most people probably also particularly remember the Solarwinds attack in 2019 and 2020. The attackers had exploited a previously unknown vulnerability to inject the malicious webshell “SUPERNOVA”.
All of these vulnerabilities can be detected via tests in the Greenbone Security Feed.

In the future, we will continue to work on expanding the scope of our feed to provide users with the opportunity to detect vulnerabilities at an early stage and not give attacks a chance. So with our solutions constantly updated to cover the latest and most critical vulnerabilities, you can relax. The next 100,000 vulnerability tests will follow – stay tuned!