Tag Archive for: CVSS

Greenbone AG

Greenbone Detection Stays Strong Despite NIST NVD Outage

Despite the NVD (National Vulnerability Database) outage of the NIST (National Institute of Standards and Technology), Greenbone’s detection engine remains fully operational, offering reliable, vulnerability scanning without relying on missing CVE enrichment data.

Since 1999 The MITRE Corporation’s Common Vulnerabilities and Exposures (CVE) has provided free public vulnerability intelligence by publishing and managing information about software flaws. NIST has diligently enriched these CVE reports since 2005; adding context to enhance their use for cyber risk assessment. In early 2024, the cybersecurity community was caught off guard as the NIST NVD ground to a halt. Now roughly one year later, the outage had not been fully resolved [1][2]. With an increasing number of CVE submissions each year, NIST’s struggles have left a large percentage without context such as a severity score (CVSS), affected product lists (CPE) and weakness classifications (CWE).

Recent policy shifts pushed by the Trump administration have created further uncertainty about the future of vulnerability information sharing and the many security providers that depend upon it. The FY 2025 budget for CISA includes notable reductions in specific areas such as a 49.8 million Dollar decrease in Procurement, Construction and Improvements and a 4.7 million Dollar cut in Research and Development. In response to the funding challenges, CISA has taken actions to reduce spending, including adjustments to contracts and procurement strategies.

​To be clear, there has been no outage of the CVE program yet. On April 16, the CISA issued a last minute directive to extend its contract with MITRE to ensure the operation of the CVE Program for an additional 11 months just hours before the contract was set to expire. However, nobody can predict how future events will unfold. The potential impact to intelligence sharing is alarming, perhaps signaling a new dimension to a “Cold Cyberwar” of sorts.

This article includes a brief overview of how the CVE program operates, and how Greenbone’s detection capabilities remain strong throughout the NIST NVD outage.

An Overview of the CVE Program Operations

The MITRE Corporation is a non-profit tasked with supporting US homeland security on multiple fronts including defensive research to protect critical infrastructure and cybersecurity. MITRE operates the CVE program, acting as the Primary CNA (CVE Numbering Authority) and maintaining the central infrastructure for CVE ID assignment, record publication, communication workflows among all CNAs and ADPs (Authorized Data Publishers) and program governance. MITRE provides CVE data to the public through its CVE.org website and the cvelistV5 GitHub repository, which contains all CVE Records in structured JSON format. The result has been highly efficient, standardized vulnerability reporting and seamless data sharing across the cybersecurity ecosystem.

After a vulnerability description is submitted to MITRE by a CNA, NIST has historically added:

  • CVSS (Common Vulnerability Scoring System): A severity score and detailed vector string that includes the risk context for Attack Complexity (AC), Impact to Confidentiality (C), Integrity (I), and Availability (A), as well as other factors.
  • CPE (Common Platform Enumeration): A specially formatted string that acts to identify affected products by relaying the product name, vendor, versions, and other architectural specifications.
  • CWE (Common Weakness Enumeration): A root-cause classification according to the type of software flaw involved.

CVSS allows organizations to more easily determine the degree of risk posed by a particular vulnerability and strategically conduct remediation accordingly. Also, because initial CVE reports only require a non-standardized affected product declaration, NIST’s addition of CPE allows vulnerability management platforms to conduct CPE matching as a fast, although somewhat unreliable way to determine whether a CVE exists within an organization’s infrastructure or not.

For a more detailed perspective on how the vulnerability disclosure process works and how CSAF 2.0 offers a decentralized alternative to MITRE’s CVE program, check out our article: How CSAF 2.0 Advances Automated Vulnerability Management. Next, let’s take a closer look at the NIST NVD outage and understand what makes Greenbone’s detection capabilities resilient against the NIST NVD outage.

The NIST NVD Outage: What Happened?

Starting on February 12, 2024, the NVD drastically reduced its enrichment of Common Vulnerabilities and Exposures (CVEs) with critical metadata such as CVSS, CPE and CWE product identifiers. The issue was first identified by Anchore’s VP of Security. As of May 2024, roughly 93% of CVEs added after February 12 were unenriched. By September 2024, NIST had failed to meet its self-imposed deadline; 72.4% of CVEs and 46.7% of new additions to CISA’s Known Exploited Vulnerabilities (KEVs) were still unenriched [3].

The slowdown in NVD’s enrichment process had significant repercussions for the cybersecurity community not only because enriched data is critical for defenders to effectively prioritize security threats, but also because some vulnerability scanners depend on this enriched data to implement their detection techniques.

As a cybersecurity defender, it’s worthwhile asking: was Greenbone affected by the NIST NVD outage? The short answer is no. Read on to find out why Greenbone’s detection capabilities are resilient against the NIST NVD outage.

Greenbone Detection Strong Despite the NVD Outage

Without enriched CVE data, some vulnerability management solutions become ineffective because they rely on CPE matching to determine if a vulnerability exists within an organization’s infrastructure.  However, Greenbone is resilient against the NIST NVD outage because our products do not depend on CPE matching. Greenbone’s OPENVAS vulnerability tests can be built from un-enriched CVE description. In fact, Greenbone can and does include detection for known vulnerabilities and misconfigurations that don’t even have CVEs such as CIS compliance benchmarks [4][5].

To build Vulnerability Tests (VT) Greenbone employs a dedicated team of software engineers who identify the underlying technical aspects of vulnerabilities. Greenbone does include a CVE Scanner feature capable of traditional CPE matching. However, unlike solutions that rely solely on CPE data from NIST NVD to identify vulnerabilities, Greenbone employs detection techniques that extend far beyond basic CPE matching. Therefore, Greenbone’s vulnerability detection capabilities remain robust even in the face of challenges such as the recent outage of the NIST NVD.

To achieve highly resilient, industry leading vulnerability detection, Greenbone’s OPENVAS Scanner component actively interacts with exposed network services to construct a detailed map of a target network’s attack surface. This includes identifying services that are accessible via network connections, probing them to determine products, and executing individual Vulnerability Tests (VT) for each CVE or non-CVE security flaw to actively verify whether they are present. Greenbone’s Enterprise Vulnerability Feed contains over 180,000 VTs, updated daily, to detect the latest disclosed vulnerabilities, ensuring rapid detection of the newest threats.

In addition to its active scanning capabilities, Greenbone supports agentless data collection via authenticated scans. Gathering detailed information from endpoints, Greenbone evaluates installed software packages against issued CVEs. This method provides precise vulnerability detection without depending on enriched CPE data from the NVD.

Key Takeways:

  • Independence from enriched CVE data: Greenbone’s vulnerability detection does not rely on enriched CVE data provided by NIST’s NVD, ensuring uninterrupted performance during outages. A basic description of a vulnerability allows Greenbone’s vulnerability test engineers to develop a detection module.
  • Detection beyond CPE matching: While Greenbone includes a CVE Scanner feature for CPE matching, its detection capabilities extend far beyond this basic approach, utilizing several methods that actively interact with scan targets.
  • Attack surface mapping: The OPENVAS Scanner actively interacts with exposed services to map network attack surface, identifying all network reachable services. Greenbone also performs authenticated scans to gather data directly from endpoint internals. This information is processed to identify vulnerable packages. Enriched CVE data such as CPE is not required.
  • Resilience to NVD enrichment outages: Greenbone’s detection methods remain effective even without NVD enrichment, leveraging CVE descriptions provided by CNAs to create accurate active checks and version-based vulnerability assessments.

Greenbone’s Approach is Practical, Effective and Resilient

Greenbone exemplifies the gold standard of practicality, effectiveness and resilience, achieving a benchmark that IT security teams should be striving to achieve. By leveraging active network mapping, authenticated scans and actively interacting with target infrastructure, Greenbone ensures reliable, resilient detection capabilities in diverse environments.

This higher standard enables organizations to confidently address vulnerabilities, even in complex and dynamic threat landscapes. Even in the absence of NVD enrichment, Greenbone’s detection methods remain effective. With only a general description Greenbone’s VT engineers can develop accurate active checks and product version-based vulnerability assessments.

Through a fundamentally resilient approach to vulnerability detection, Greenbone ensures reliable vulnerability management, setting itself apart in the cybersecurity landscape.

NVD / NIST / MITRE Alternatives

The MITRE issue is a wake-up call for digital sovereignty, and the EU has already (and fast) reacted. A long-awaited alternative, the EuVD by the ENISA, the European Union Agency for Cybersecurity, is there, and will be covered in one of our upcoming blog posts.

Contact Test Now Buy Here Back to Overview

/by
Joseph Lee

Apache Camel Case-Sensitive Flaw May Forfeit Remote Command Execution

Two new CVEs in Apache Camel have been disclosed warranting immediate attention from users. On March 9, 2025, Apache disclosed CVE-2025-27636 (CVSS 5.6), a Remote Code Execution (RCE) flaw. Two days later, on March 11th, Akamai’s Security Intelligence Group (SIG) reported a bypass technique for the original patch, resulting in CVE-2025-29891 (CVSS 4.2) being published on March 12th.

Green graphic with stylised camel in a desert landscape. To the right is a button with the inscription ‘RCE in Apache Camel’.

Although the two vulnerabilities have only been assigned moderate CVSS severity scores by CISA-ADP (CISA’s Authorized Data Publisher), they could be severe impact vulnerabilities depending on the targeted Camel instance’s configuration. Both CVEs have the same root cause: improper filtering of HTTP headers or HTTP parameters when communicating to an Apache Camel instance. As the article’s title suggests, parameters were filtered using case-sensitive methods, while the arguments themselves were being applied in a non-case-sensitive manner.

Furthermore, publicly available proof-of-concept (PoC) code and a relatively complete technical description adds to the risk. Greenbone can detect both CVE-2025-27636 and CVE-2025-29891 with vulnerability tests that actively check for exploitable HTTP endpoints. Let’s review the details.

What Is Apache Camel?

Apache Camel is a popular open-source Java library for integrating different components of a distributed enterprise system architecture such as APIs or microservices. In a nutshell, Camel is a versatile platform for routing and mediation based on the Enterprise Integration Patterns (EIPs) concept of enterprise system architecture design. Apache Camel is heavily based on EIPs and provides an implementation of these patterns via its domain-specific languages (DSL) that include Java, XML, Groovy, YAML and others.

As of 2021, Apache Camel held approximately 3.03% of the Enterprise Application Integration market. The software is used by over 5,600 companies, roughly half being US-based. Camel’s market share is predominantly in the Information Technology and Services industry (33%), Computer Software industry (12%) and Financial Services industry (6%).

Two New CVEs in Apache Camel May Allow RCE

When any of Camel’s HTTP-based components handle requests, a default filter is supposed to prevent exposure of sensitive data or execution of internal commands. However, due to a flawed case-sensitive filtering rule, only exactly matched headers were filtered. However, downstream in the program logic, these headers were being applied in a non-case-sensitive manner, allowing filter bypass. Changing the case of the first character of the header name, an attacker could bypass the filter to inject arbitrary headers.

The good news is that either the camel-bean or camel-exec component must be enabled in combination with an http-based component such as such as camel-http, camel-http4, camel-rest, camel-servlet or others. Also, exploitation is limited to internal methods within the scope declared in the HTTP request URI. One final saving grace is that this flaw has not been implicated as an unauthenticated vulnerability. Therefore, unless the system designers have implemented any authentication and authorization for a Camel HTTP API, it is not exploitable.

At the high-end of the risk spectrum, if the Camel Exec component is enabled and targeted, an attacker can achieve arbitrary RCE as the user controlling the Camel process. RCE is achieved by sending the CamelExecCommandExecutable header to specify an arbitrary shell command, overriding the commands configured on the back-end. If exploitable Camel HTTP APIs are Internet accessible, the risk is especially high, however, this flaw could also be used for lateral movement within a network by an insider, or by attackers who have gained initial access to an organization’s internal network.

A technical description of the exploit chain and proof-of-concept (PoC) has been provided by Akamai.

What Is the Appropriate CVSS Score?

Although CVE-2025-27636 (CVSS 5.6) and CVE-2025-29891 (CVSS 4.2) have been assigned moderate severity scores, they could have a critical impact if either the camel-bean or camel-exec components are enabled in combination with http-based components. The situation highlights some limitations of the scoring by CVSS (Common Vulnerability Scoring System).

Akamai researchers report that the flaw is trivial to exploit and have published proof-of-concept (PoC) code, increasing the risk. This implies that the CVSS Attack Complexity (AC) metric should be set to Low (L). However, CISA-ADP has assessed attack complexity as high (AC:H) given these facts. Red Hat has accounted for these factors and increased the CVSS for CVE-2025-27636 to 6.3.

Also, the CISA-ADP assessed no impact to confidentiality for CVE-2025-29891, despite the potential for arbitrary RCE. However, if an Apache Camel instance has a vulnerable configuration, a high impact assessment for Confidentiality (C), Integrity (I) and Availability (A), is justified further increasing the criticality to CVSS 9.8.

On the other hand, the CISA-ADP assigned a Privileges Required (PR) value of None (N). However, although Akamai’s PoC does not use an HTTPS connection or authentication, it would be extremely negligent to operate an unencrypted and unauthenticated API. Apache Camel supports Java Secure Socket Extension (JSSE) API for Transport Layer Security (TLS) or using a KeyCloak Single Sign-On (SSO) authorization server. Camel instances with some form of client authentication enabled would be protected against exploitation. For most cases, the PR value should be adjusted to Low (L) or High (H) resulting in a diminished CVSS of 7.3 or 8.8.

Furthermore, the CVEs were assigned a Scope value Unchanged (UC). According to the CVSS v3.1 specification: “The Scope metric captures whether a vulnerability in one vulnerable component impacts resources in components beyond its security scope.” Execution of arbitrary shell commands on the compromised system is typically assigned the value of Changed (C). If the Camel process is owned by the Linux/Unix root or a Windows administrator user, an attacker would have virtually unlimited control of a compromised system. Accounting for the variety of possible CVSS assessments, CVE-2025-27636 and CVE-2025-29891 should be considered critical severity vulnerabilities if an instance meets the configuration requirements and does not apply authentication.

Mitigating the CVEs in Apache Camel

CVE-2025-27636 and CVE-2025-29891 affect Apache Camel version 4.10 before 4.10.2, version 4.8 before 4.8.5 and version 3 before 3.22.4. Users should upgrade to 4.10.2, 4.8.5 or 3.22.4 or implement custom header filtering using removeHeader or removeHeaders in Camel routes. It should be noted that Camel versions 4.10.0, 4.10.1, 4.8.0 to 4.8.4, and 3.10.0 to 3.22.3 are still vulnerable although they were considered security updates that addressed the flaw.

Also, it is strongly recommended that all HTTP endpoints in a distributed architecture employ strong authentication. For Apache Camel, options include: using Java Secure Socket Extension (JSSE) API for TLS with Camel components or using a KeyCloak OAuth 2.0 SSO authorization server. For legacy systems, a minimum of HTTP Basic Authentication should be configured.

Summary

Apache Camel users should immediately upgrade to versions 4.10.2, 4.8.5 or 3.22.4 to mitigate the newly published CVEs affecting Apache Camel. Alternatively, implement custom header filtering using removeHeader or removeHeaders in Camel routes. Strong authentication on all HTTP endpoints is also highly recommended for security best-practices. Apache Camel supports the JSSE API for TLS or KeyCloak SSO solutions. Greenbone is able to detect both CVE-2025-27636 and CVE-2025-29891 with vulnerability tests that actively check for exploitable HTTP endpoints.

Contact Test Now Buy Here Back to Overview

/by
Joseph Lee

December 2024 Threat Report: Sunsetting a Record Year for IT Risk

In 2024, geopolitical instability, marked by conflicts in Ukraine and the Middle East, emphasized the need for stronger cybersecurity in both the public and private sector. China targeted U.S. defense, utilities, internet providers and transportation, while Russia launched coordinated cyberattacks on U.S. and European nations, seeking to influence public opinion and create discord among Western allies over the Ukrainian war. As 2024 ends, we can look back at a hectic cybersecurity landscape on the edge.

2024 marked another record setting year for CVE (Common Vulnerabilities and Exposures) disclosures. Even if many are so-called “AI Slop” reports [1][2], the sheer volume of published vulnerabilities creates a big haystack. As IT security teams seek to find high-risk needles in a larger haystack, the chance of oversight becomes more prevalent. 2024 was also a record year for ransomware payouts in terms of volume and size, and Denial of Service (DoS) attacks.

It also saw the NIST NVD outage, which affected many organizations around the world including security providers. Greenbone’s CVE scanner is a CPE (Common Platform Enumeration) matching function and has been affected by the NIST NVD outage. However, Greenbone’s primary scanning engine, OpenVAS Scanner, is unaffected. OpenVAS actively interacts directly with services and applications, allowing Greenbone’s engineers to build reliable vulnerability tests using the details from initial CVE reports.

In 2025, fortune will favor organizations that are prepared. Attackers are weaponizing cyber-intelligence faster; average time-to-exploit (TTE) is mere days, even hours. The rise of AI will create new challenges for cybersecurity. Alongside these advancements, traditional threats remain critical for cloud security and software supply chains. Security analysts predict that fundamental networking devices such as VPN gateways, firewalls and other edge devices will continue to be a hot target in 2025.

In this edition of our monthly Threat Report, we review the most pressing vulnerabilities and active exploitation campaigns that emerged in December 2024.

Mitel MiCollab: Zero-Day to Actively Exploited in a Flash

Once vulnerabilities are published, attackers are jumping on them with increased speed. Some vulnerabilities have public proof of concept (PoC) exploit code within hours, leaving defenders with minimal reaction time. In early December, researchers at GreyNoise observed exploitation of Mitel MiCollab the same day that PoC code was published. Mitel MiCollab combines voice, video, messaging, presence and conferencing into one platform. The new vulnerabilities have drawn alerts from the Belgian national Center for Cybersecurity, the Australian Signals Directorate (ASD) and the UK’s National Health Service (NHS) in addition to the American CISA (Cybersecurity and Infrastructure Security Agency). Patching the recent vulnerabilities in MiCollab is considered urgent.

Here are details about the new actively exploited CVEs in Mitel MiCollab:

  • CVE-2024-41713 (CVSS 7.8 High): A path traversal vulnerability in the NuPoint Unified Messaging (NPM) component of Mitel MiCollab allows unauthenticated path traversal by leveraging the “…/” technique in HTTP requests. Exploitation can expose highly sensitive files.
  • CVE-2024-35286 (CVSS 10 Critical): A SQL injection vulnerability has been identified in the NPM component of Mitel MiCollab which could allow a malicious actor to conduct a SQL injection attack.

Since mid-2022, CISA has tracked three additional actively exploited CVEs in Mitel products which are known to be leveraged in ransomware attacks. Greenbone is able to detect endpoints vulnerable to these high severity CVEs with active checks [4][5].

Array Networks SSL VPNs Exploited by Ransomware

CVE-2023-28461 (CVSS 9.8 Critical) is a Remote Code Execution (RCE) vulnerability in Array Networks Array AG Series and vxAG SSL VPN appliances. The devices, touted by the vendor as a preventative measure against ransomware, are now being actively exploited in recent ransomware attacks. Array Networks themselves were breached by the Dark Angels ransomware gang earlier this year [1][2].

According to recent reports, Array Networks holds a significant market share in the Application Delivery Controller (ADC) market. According to the ​​IDC’s WW Quarterly Ethernet Switch Tracker, they are the market leader in India, with a market share of 34.2%. Array Networks has released patches for affected products running ArrayOS AG 9.4.0.481 and earlier versions. The Greenbone Enterprise Feed has included a detection test for CVE-2023-28461 since it was disclosed in late March 2023.

CVE-2024-11667 in Zyxel Firewalls

CVE-2024-11667 (CVSS 9.8 Critical) in Zyxel firewall appliances are being actively exploited in ongoing ransomware attacks. A directory traversal vulnerability in the web management interface could allow an attacker to download or upload files via a maliciously crafted URL. Zyxel Communications is a Taiwanese company specializing in designing and manufacturing networking devices for businesses, service providers and consumers. Reports put Zyxel’s market share at roughly 4.2% of the ICT industry with a diverse global footprint including large Fortune 500 companies.

A defense in depth approach to cybersecurity is especially important in cases such as this. When attackers compromise a networking device such as a firewall, typically they are not immediately granted access to highly sensitive data. However, initial access allows attackers to monitor network traffic and enumerate the victim’s network in search of high value targets.

Zyxel advises updating your device to the latest firmware, temporarily disabling remote access if updates cannot be applied immediately and applying their best practices for securing distributed networks. CVE-2024-11667 affects Zyxel ATP series firmware versions V5.00 through V5.38, USG FLEX series firmware versions V5.00 through V5.38, USG FLEX 50(W) series firmware versions V5.10 through V5.38 and USG20(W)-VPN series firmware versions V5.10 through V5.38. Greenbone can detect the vulnerability CVE-2024-11667 across all affected products.

Critical Flaws in Apache Struts 2

CVE-2024-53677 (CVSS 9.8 Critical), an unrestricted file upload [CWE-434] flaw affecting Apache Struts 2 allows attackers to upload executable files into web-root directories. If a web-shell is uploaded, the flaw may lead to unauthorized Remote Code Execution. Apache Struts is an open-source Java-based web-application framework widely used by the public and private sectors including government agencies, financial institutions and other large organizations [1]. Proof of concept (PoC) exploit code is publicly available, and CVE-2024-53677 is being actively exploited increasing its risk.

The vulnerability was originally tracked as CVE-2023-50164, published in December 2023 [2][3]. However, similarly to a recent flaw in VMware vCenter, the original patch was ineffective resulting in the re-emergence of vulnerability. CVE-2024-53677 affects the FileUploadInterceptor component and thus, applications not using this module are unaffected. Users should update their Struts2 instance to version 6.4.0 or higher and migrate to the new file upload mechanism. Other new critical CVEs in popular open-source software (OSS) from Apache:

The Apache Software Foundation (ASF) follows a structured process across its projects that encourages private reporting and releasing patches prior to public disclosure so patches are available for all CVEs mentioned above. Greenbone is able to detect systems vulnerable to CVE-2024-53677 and other recently disclosed vulnerabilities in ASF Foundation products.

Palo Alto’s Secure DNS Actively Exploited for DoS

CVE-2024-3393 (CVSS 8.7 High) is a DoS (Denial of Service) vulnerability in the DNS Security feature of PAN-OS. The flaw allows an unauthenticated attacker to reboot PA-Series firewalls, VM-Series firewalls, CN-Series firewalls and Prisma Access devices via malicious packets sent through the data plane. By repeatedly triggering this condition, attackers can cause the firewall to enter maintenance mode. CISA has identified CVE-2024-3393 vulnerability as actively exploited and it’s among five other actively exploited vulnerabilities in Palo Alto’s products over only the past two months.

According to the advisory posted by Palo Alto, only devices with a DNS Security License or Advanced DNS Security License and logging enabled are affected. It would be an easy assumption to say that these conditions mean that top-tier enterprise customers are affected. Greenbone is able to detect the presence of devices affected by CVE-2024-3393 with a version detection test.

Microsoft Security in 2024: Who Left the Windows Open?

While it would be unfair to single out Microsoft for providing vulnerable software in 2024, the Redmond BigTech certainly didn’t beat security expectations. A total of 1,119 CVEs were disclosed in Microsoft products in 2024; 53 achieved critical severity (CVSS > 9.0), 43 were added to CISA’s Known Exploited Vulnerabilities (KEV) catalog, and at least four were known vectors for ransomware attacks. Although the comparison is rough, the Linux kernel saw more (3,148) new CVEs but only three were rated critical severity and only three were added to CISA KEV. Here are the details of the new actively exploited CVEs in Microsoft Windows:

  • CVE-2024-35250 (CVSS 7.8 High): A privilege escalation flaw allowing an attacker with local access to a system to gain system-level privileges. The vulnerability was discovered in April 2024, and PoC exploit code appeared online in October.
  • CVE-2024-49138 (CVSS 7.8 High): A heap-based buffer overflow [CWE-122] privilege escalation vulnerability; this time in the Microsoft Windows Common Log File System (CLFS) driver. Although no publicly available exploit exists, security researchers have evidence that this vulnerability can be exploited by crafting a malicious CLFS log to execute privileged commands at the system privilege level.

Detection and mitigation of these new Windows CVEs is critical since they are actively under attack. Both were patched in Microsoft’s December patch release. Greenbone is able to detect CVE-2024-35250 and CVE-2024-49138 as well as all other Microsoft vulnerabilities published as CVEs.

Summary

2024 highlighted the continuously challenging cybersecurity landscape with record-setting vulnerability disclosures, ransomware payouts, DoS attacks and an alarming rise in active exploitations. The rapid weaponization of vulnerabilities emphasizes the need for a continuous vulnerability management strategy and a defense-in-depth approach.

December saw new critical flaws in Mitel, Apache and Microsoft products. More network products: Array Networks VPNs and Zyxel firewalls are now being exploited by ransomware threat actors underscoring the urgency for proactive patching and robust detection measures. As we enter 2025, fortune will favor those prepared; organizations must stay vigilant to mitigate risks in an increasingly hostile cyber landscape.

Contact Test Now Buy Here Back to Overview

/by
Elmar Geese

In-Depth Information About Greenbone’s Log4j Vulnerability Test Coverage

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

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:

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 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 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.


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
Greenbone AG

Greenbone OS 21.04 – All New Features at a Glance

Since 2021-04-30, the latest GOS version – version 21.04 – is available and, as always, it brings a lot of new features and improvements! What exactly? Get an overview of all important changes with GOS 21.04 here!

New Hardware Models for Our Midrange Class Available

A new hardware generation has been introduced for the Midrange Class hardware appliances, which are used for medium-sized companies or for branch offices of large, distributed companies.

The new hardware now uses SSD-type hard disks instead of HDD, which are 10 times faster, quieter and lighter. There is also more hard disk space available. The RAM has also been improved. It is now DDR4 instead of DDR3, which makes it significantly faster with a higher clock rate (3200 MHz). Furthermore, twice to four times as much main memory is available than before. In addition, a new, faster CPU of the latest generation has been installed. The ports of the appliances also change: instead of 6 ports GbE-Base-TX and 2 ports 1 GbE SFP, there are now 8 ports GbE-Base-TX and 2 ports 10 GbE SFP+.

The model names remain unchanged.

Boreas Alive Scanner now as Standard

The Boreas Alive Scanner is a host alive scanner that identifies the active hosts in a target network. It was introduced with GOS 20.08, but was previously optional. With GOS 21.04, the Boreas Alive Scanner became standard.

Compared to the Nmap port scanner, which was previously used by default, the Boreas Alive Scanner is not limited in terms of the maximum number of alive scans performed simultaneously and is therefore faster.

The Boreas Alive Scanner significantly reduces scanning time for large networks with a small percentage of reachable hosts. This also makes it possible to get the first scan results faster, regardless of the percentage of alive hosts in the network.

Clearer Results Thanks to New Report Formats

Two additional report formats are now available for exporting reports, replacing the previous standard report formats: Vulnerability Report PDF and Vulnerability Report HTML. The report formats are clearly structured and easy to understand. Specific information relevant to the target group can be quickly identified and understood.

The report formats provide a basis for user-defined reports, which are planned for future GOS versions.

Example of a Greenbone vulnerability report in HTML format, featuring a risk matrix and detailed scan results of IT infrastructure vulnerabilities.

 

New Network Backend for a more Stable Connection

With GOS 21.04, the network configuration backend in GOS has been improved by introducing the gnm networking mode. This prevents connection losses in certain network configurations as well as connection problems with SSH sessions. In addition, the GSM no longer needs to be restarted after certain network settings have been changed.

New Hypervisors for Our Virtual Appliances

The officially supported hypervisors for the virtual appliances have been changed with GOS 21.04. The GSM EXA/PETA/TERA/DECA and 25V can be used with Microsoft Hyper-V, VMware vSphere Hypervisor (ESXi), and Huawei FusionCompute; the GSM CENO can be used with Microsoft Hyper-V and VMware vSphere Hypervisor (ESXi); and the GSM ONE can be used with Oracle VirtualBox, VMware Workstation Pro, and VMware Workstation Player. Additionally, GOS 21.04 supports the ARM instruction set on Huawei FusionCompute.

Improvement of the Web Server, Ciphers and Web Certificates

With GOS 21.04, the nginx web server is used in addition to the Greenbone Security Assistant Daemon (gsad). This web server uses OpenSSL instead of GnuTLS to define the available ciphers and protocols of the server. There is now a new menu in the GOS administration menu for configuring the TLS version. In addition, the menu for configuring the ciphers has been adapted.

Another change can be found in the generation of HTTPS certificates. Here it is now possible to define one or more Subject Alternative Name(s) (SAN). These are used to cover multiple domain names and IP addresses with one certificate.

CVSS v3.0/v3.1 Support for Severity Calculation

CVSS version 3.0 and 3.1 are now supported for calculating the severity of CVEs (Common Vulnerability Enumeration).

VTs and CVEs can contain version 2 and/or version 3.0/3.1 CVSS data. If a VT/CVE contains both CVSS v2 data and CVSS v3.0/v3.1 data, the CVSS v3.0/v3.1 data is always used and displayed.

The page CVSS Calculator now contains both a calculator for CVSS v2 and a calculator for CVSS v3.0/v3.1.

Screenshot comparing CVSSv2 and CVSSv3.1 score calculation in GOS 21.04, showing severity levels, vectors, and risk ratings for a sample vulnerability.

Open Scanner Protocol Makes all Sensor GSMs Lightweighted

Already with GOS 20.08 it was optionally possible for all sensors to be controlled via the Open Scanner Protocol (OSP). This results in the sensors becoming lightweighted and avoids the need for additional credentials on the sensor.

With GOS 21.04, only OSP is now used as the protocol to control a sensor GSM via a master GSM. The Greenbone Management Protocol (GMP) is no longer used.

Simplified and More Intuitive Functions on the Web Interface

With GOS 21.04, some minor changes have also been made to GOS and the web interface to make GSM operation and scanning clearer and more intuitive.

For example, the Auto-FP function and the alternative severity class schemes – BSI Vulnerability Traffic Light and PCI-DSS – have been removed.

Some devices – especially IoT devices – can crash when scanned across multiple IP addresses simultaneously. This can happen, for example, if the device is connected over IPv4 and IPv6. With GOS 21.04, it is possible to avoid scanning over multiple IP addresses at the same time by using the new setting Allow simultaneous scanning via multiple IPs when creating a target.

See for Yourself!

Check out our new features and changes for yourself! New appliances with GOS 21.04 are now available and existing appliances can also be upgraded to the latest version. Also our free trial version can be used with GOS 21.04.

Contact Free Trial Buy Here Back to overview
/by