Tag Archive for: Schwachstellenmanagement

Vulnerabilities in IT environments appear in different forms. The most common ones are likely software vulnerabilities that have not been patched. Then there are weak passwords, misconfigurations or network switches that have been EOL for five years. However, another type of security gap sometimes causes significant confusion during the scans: hardware vulnerabilities.

We have become accustomed to the continuous emergence of software vulnerabilities, and hopefully, it is now standard practice for every company to regularly scan its network for vulnerabilities and apply patches. Unfortunately, mistakes are not limited to software developers – CPU developers are not immune either. CPU vulnerabilities often arise from design flaws, allowing malicious actors to exploit unintended side effects to access sensitive data. Unlike software vulnerabilities, which can often be resolved through patches or updates, hardware vulnerabilities require either microcode updates or fundamental architectural changes in future processor designs.

Microcode Updates

The only way to mitigate CPU vulnerabilities is by applying microcode updates, which are typically distributed through the operating system or sometimes even through firmware (UEFI/BIOS). Microcode is a low-level software layer within the processor that translates higher-level machine instructions into specific internal operations.

While end users do not traditionally update microcode themselves, manufacturers like Intel provide relevant updates to patch certain vulnerabilities without requiring a full hardware replacement. However, these updates often introduce performance loss, as they disable or modify certain CPU optimizations to prevent exploitation. In some cases, this can even lead to performance reductions of up to 50%.

Flaws on different levels

Since these vulnerabilities exist at the CPU level, tools like the Greenbone Enterprise Appliance detect and report them. However, this can lead to misconceptions, as users might mistakenly believe that the reported vulnerabilities originate from the operating system. It is crucial to understand that these are not OS vulnerabilities; rather, they are architectural flaws in the processor itself. The vulnerabilities are detected by checking for the absence of appropriate microcode patches when an affected CPU is identified. For example, if a scan detects a system that lacks Intel’s microcode update for Downfall, it will be reported as vulnerable. However, this does not mean that the OS itself is insecure or compromised.

Performance or safety?

In the end, mitigating CPU vulnerabilities always involves trade-offs, and users must decide which approach best suits their needs. In principle, there are three options to choose from:

  • Apply microcode updates and accept significant performance degradation in compute-heavy workloads.
  • Forego certain microcode updates and accept the risks if the probability of exploitation is low in their environment.
  • Replace the affected hardware with CPUs that are not vulnerable to these issues.

Ultimately, the decision depends on the specific use case and risk tolerance of the organization or individual responsibles.

Trimble Cityworks, an enterprise asset management (EAM) and public works management software is actively under attack. The campaign began as an unknown (zero-day) vulnerability, but is now tracked as ​​CVE-2025-0994 with a CVSS of 8.6. The vulnerability is a deserialization flaw [CWE-502] that could allow an authenticated attacker to execute arbitrary code remotely (Remote Code Execution; RCE). Greenbone includes detection for CVE-2025-0994 in the Enterprise Feed.

Active exploitation of CVE-2025-0994 is a real and present danger. Trimble has released a statement acknowledging the attacks against their product. Thanks to the vendor’s transparency, CISA (Cybersecurity and Infrastructure Security Agency) has added CVE-2025-0994 to their catalog of Known Exploited Vulnerabilities (KEV), published an ICS advisory as well as a CSAF 2.0 document. CSAF 2.0 advisories are machine readable advisory documents for decentralized sharing of cybersecurity intelligence.

Although many media reports and some threat platforms indicate that a public proof-of-concept (PoC) exists, the only search result for GitHub is simply a version detection test. This means it is less likely that low-skilled hackers will easily participate in attacks. The misinformation is likely due to poorly designed algorithms combined with lack of human oversight before publishing threat intelligence.

Who Is at Risk due to CVE-2025-0994?

Trimble Cityworks is designed for and used primarily by local governments and critical infrastructure providers including water and wastewater systems, energy, transportation systems, government industrial facilities and communications agencies. Cityworks enhances Geographic Information Systems (GIS) by integrating asset management and public works solutions directly with Esri ArcGIS. The software is meant to help organizations manage infrastructure, schedule maintenance and improve operational efficiency. In addition to CISA, several other government agencies have issued alerts regarding this vulnerability including the US Environment Protection Agency (EPA), the Canadian Centre for Cyber Security and New York State.

Trimble Cityworks has reported serving over 700 customers across North America, Europe, Australia and the Middle East in 2019. While specific numbers for municipal governments in the U.S., Canada and the EU are not publicly disclosed, a Shodan search and Censys map both reveal only about 100 publicly exposed instances of Cityworks. However, the application is considered to have a high adoption rate by local governments and utilities. If publicly exposed, CVE-2025-0994 could offer an attacker initial access [T1190]. For attackers who already have a foothold, the flaw is an opportunity for lateral movement [TA0008] and presents an easy mark for insider attacks.

A Technical Description of CVE-2025-0994

CVE-2025-0994 is a deserialization vulnerability [CWE-502] found in versions of Trimble Cityworks prior to 15.8.9 and Cityworks with Office Companion versions prior to 23.10. The vulnerability arises from the improper deserialization of untrusted serialized data, allowing an authenticated attacker to execute arbitrary code remotely on a target’s Microsoft Internet Information Services (IIS) web server.

Serialization is a process whereby the software code or objects are encoded to be transferred between applications and then reconstructed into the original format used by a programming language. When Trimble Cityworks processes serialized objects, it does not properly validate or sanitize untrusted input. This flaw allows an attacker with authenticated access to send specially crafted serialized objects, which can trigger arbitrary code execution on the underlying IIS server. Deserializing data from unauthenticated sources seems like a significant design flaw in itself, but failing to properly sanitize serialized data is especially poor security.

Exploitation CVE-2025-0994 could lead to:

  • Unauthorized access to sensitive data
  • Service disruption of critical infrastructure systems
  • Potential full system compromise of the affected IIS web server

Mitigating CVE-2025-0994 in Trimble Cityworks

Trimble has released patched versions of Cityworks that address the deserialization vulnerability. These patches include Cityworks 15.8.9 and Cityworks 23.10. On-premise users must immediately upgrade to the patched version, while Cityworks Online (CWOL) customers will receive these updates automatically.

Trimble noted that some on-premise deployments are running IIS with overprivileged identity permissions, which increases the attack surface. IIS should not have local or domain-level administrative privileges. Follow Trimble’s guidance in the latest Cityworks release notes to adjust IIS identity configurations properly.

Users of on-premises Trimble Cityworks should:

  • Update Cityworks 15.x versions to 15.8.9 and 23.x versions to 23.10.
  • Audit IIS identity permissions to ensure that they align with the principle of least privilege.
  • Limit attachment directory root configuration to only folders which only contain attachments.
  • Use a firewall to restrict IIS server access to trusted internal systems only.
  • Use a VPN to allow remote access to Cityworks rather than publicly exposing the service.

Summary

CVE-2025-0994 represents a serious security risk to Trimble Cityworks users, which largely comprise government and critical infrastructure environments. With active exploitation already observed, organizations must prioritize immediate patching and implement security hardening measures to mitigate the risk. Greenbone has added detection for CVE-2025-0994 to the Enterprise Feed, allowing customers to gain visibility into their exposure.

An actively exploited RCE (Remote Code Execution) with system privileges vulnerability that does not require user-interaction is as bad as it gets from a technical standpoint. When that CVE impacts software widely used by Fortune 500 companies, it is a ticking time bomb. And when advanced persistent threat actors jump on a software vulnerability such as this, remediation needs to become an emergency response effort. Most recently, CVE-2024-50623 (also now tracked as CVE-2024-55956) affecting more than 4,200 users of Cleo’s MFT (Managed File Transfer) software met all these prerequisites for disaster. It has been implicated in active ransomware campaigns affecting several Fortune 500 companies taking center stage in cybersecurity news.

In this cybersecurity alert, we provide a timeline of events related to CVE-2024-50623 and CVE-2024-55956 and associated ransomware campaigns. Even if you are not using an affected product, this will give you valuable insight into the vulnerability lifecycle and the risks of third-party software supply chains. 

CVE-2024-50623 and CVE-2024-55956: a Timeline of Events

The vulnerability lifecycle is complex. You can review our previous article about next-gen vulnerability management for an in depth explanation on how this process happens. In this report, we will provide a timeline for the disclosure and resolution of CVE-2024-50623 and subsequently CVE-2024-55956 as a failed patch attempt from the software vendor Cleo was uncovered and exploited by ransomware operators. Our Greenbone Enterprise Feed includes detection modules for both CVEs [1][2], allowing organizations to identify vulnerable systems and apply emergency remediation. Here is a timeline of events so far:

  • October 28, 2024: CVE-2024-50623 (CVSS 10 Critical) affecting several Cleo MFT products was published by the vendor and a patched version 5.8.0.21 was
  • November 2024: CVE-2024-50623 was exploited for data exfiltration impacting at least 10 organizations globally including Blue Yonder, a supply chain management service used by Fortune 500 companies.
  • December 3, 2024: Security researchers at Huntress identified active exploitation of CVE-2024-50623 capable of bypassing the original patch (version 5.8.0.21).
  • December 8, 2024: Huntress observed a significant uptick in the rate of exploitation. This could be explained by the exploit code being sold in a Malware as a Service cyber crime business model or simply that the attackers had finished reconnaissance and launched a widespread campaign for maximum impact.
  • December 9, 2024: Active exploitation and proof-of-concept (PoC) exploit code was reported to the software vendor Cleo.
  • December 10, 2024: Cleo released a statement acknowledging the exploitability of their products despite security patches and issued additional mitigation guidance.
  • December 11, 2024: Wachtowr Labs released a detailed technical report describing how CVE-2024-50623 allows RCE via Arbitrary File Write [CWE-434]. Cleo updated their mitigation guidance and released a subsequent patch (version 5.8.0.24).
  • December 13, 2024: A new name, CVE-2024-55956 (CVSS 10 Critical), was issued for tracking this ongoing vulnerability, and CISA added the flaw to its Known Exploited Vulnerabilities (KEV) catalog, flagged for use in ransomware attacks.

Cleo Products Leveraged in Ransomware Attacks

The risk to global business posed by CVE-2024-50623 and CVE-2024-55956 is high. These two CVEs potentially impact more than 4,200 customers of Cleo LexiCom, a desktop-based client for communication with major trading networks, Cleo VLTrader, a server-level solution tailored for mid-enterprise organizations, and Cleo Harmony for large enterprises.

The CVEs have been used as initial access vectors in a recent ransomware campaign. The Termite ransomware operation [1][2] has been implicated in the exploitation of Blue Yonder, a Panasonic subsidiary in November 2024. Blue Yonder is a supply chain management platform used by large tech companies including Microsoft, Lenovo, and Western Digital, and roughly 3,000 other global enterprises across many industries; Bayer, DHL, and 7-Eleven to name a few. Downtime of Blue Yonder’s hosted service caused payroll disruptions for StarBucks. The Clop ransomware group has also claimed responsibility for recent successful ransomware attacks.

In the second stage of some breaches, attackers conducted Active Directory domain enumeration [DS0026], installed web-shells [T1505.003] for persistence [TA0003], and attempted to exfiltrate data [TA0010] from the victim’s network after gaining initial access via RCE. An in-depth technical description of the Termite ransomware’s architecture is also available.

Mitigating CVE-2024-50623 and CVE-2024-55956

Instances of Cleo products version 5.8.0.21 are still vulnerable to cyber attacks. The most recent patch, version 5.8.0.24 is required to mitigate exploitation. All users are urged to apply updates with urgency. Additional mitigation and best practices include disabling the autorun functionality in Cleo products, removing access from the Internet or using firewall rules to restrict access to only authorized IP addresses, and blocking the IP addresses of endpoints implicated in the attacks.

Summary

Cleo Harmony, VLTrader, and LexiCom prior to version 5.8.0.24 are under active exploitation due to critical RCE vulnerabilities (CVE-2024-50623 and CVE-2024-55956). These flaws have been the entry point for successful ransomware attacks against at least 10 organizations and impacting Fortune 500 companies. Greenbone provides detection for affected products and affected users are urged to apply patches and implement mitigation strategies, as attackers will certainly continue to leverage these exploits.

While the German government has yet to implement the necessary adjustments for the NIS2 directive, organizations shouldn’t lose momentum. Although the enforcement is now expected in Spring 2025 instead of October 2024, the core requirements remain unchanged. While there remains a lot of work for companies, especially operators of critical infrastructure, most of it is clear and well-defined. Organizations must still focus on robust vulnerability management, such as that offered by Greenbone.

Missed Deadlines and the Need for Action

Initially, Germany was supposed to introduce the NIS2 compliance law by October 17, 2024, but the latest drafts failed to gain approval, and even the Ministry of the Interior does not anticipate a timely implementation. If the parliamentary process proceeds swiftly, the law could take effect by Q1 2025, the Ministry announced.

A recent study by techconsult (only in German), commissioned by Plusnet, reveals that while 67% of companies expect cyberattacks to increase, many of them still lack full compliance. NIS2 mandates robust security measures, regular risk assessments and rapid response to incidents. Organizations must report security breaches within 24 hours and deploy advanced detection systems, especially those already covered under the previous NIS1 framework.

Increased Security Budgets and Challenges

84% of organizations plan to increase their security spending, with larger enterprises projecting up to a 12% rise. Yet only 29% have fully implemented the necessary measures, citing workforce shortages and lack of awareness as key obstacles. The upcoming NIS2 directive presents not only a compliance challenge but also an opportunity to strengthen cyber resilience and gain customer trust. Therefore, 34% of organizations will invest in vulnerability management in the future.

Despite clear directives from the EU, political delays are undermining the urgency. The Bundesrechnungshof and other institutions have criticized the proposed exemptions for government agencies, which could weaken overall cybersecurity efforts. Meanwhile, the healthcare sector faces its own set of challenges, with some facilities granted extended transition periods until 2030.

Invest now to Stay Ahead

Latest since the NIS2 regulations impend, businesses are aware of the risks and are willing to invest in their security infrastructure. As government action lags, companies must take proactive measures. Effective vulnerability management solutions, like those provided by Greenbone, are critical to maintaining compliance and security.

OpenVAS began in 2005 when Nessus transitioned from open source to a proprietary license. Two companies, Intevation and DN Systems adopted the existing project and began evolving and maintaining it under a GPL v2.0 license. Since then, OpenVAS has evolved into Greenbone, the most widely-used and applauded open-source vulnerability scanner and vulnerability management solution in the world. We are proud to offer Greenbone as both a free Community Edition for developers and also as a range of enterprise products featuring our Greenbone Enterprise Feed to serve the public sector and private enterprises alike.

As the “old-dog” on the block, Greenbone is hip to the marketing games that cybersecurity vendors like to play. However, our own goals remain steadfast – to share the truth about our product and industry leading vulnerability test coverage. So, when we reviewed a recent 2024 network vulnerability scanner benchmark report published by a competitor, we were a little shocked to say the least.

As the most recognized open-source vulnerability scanner, it makes sense that Greenbone was included in the competition for top dog. However, while we are honored to be part of the test, some facts made us scratch our heads. You might say we have a “bone to pick” about the results. Let’s jump into the details.

What the 2024 Benchmark Results Found

The 2024 benchmark test conducted by Pentest-Tools ranked leading vulnerability scanners according to two factors: Detection Availability (the CVEs each scanner has detection tests for) and Detection Accuracy (how effective their detection tests are).

The benchmark pitted our free Community Edition of Greenbone and the Greenbone Community Feed against the enterprise products of other vendors: Qualys, Rapid7, Tenable, Nuclei, Nmap, and Pentest-Tools’ own product. The report ranked Greenbone 5th in Detection Availability and roughly tied for 4th place in Detection Accuracy. Not bad for going up against titans of the cybersecurity industry.

The only problem is, as mentioned above, Greenbone has an enterprise product too, and when the results are recalculated using our Greenbone Enterprise Feed, the findings are starkly different – Greenbone wins hands down.

Here is What we Found

 Bar chart from the 2024 benchmark for network vulnerability scanners: Greenbone Enterprise achieves the highest values with 78% availability and 61% accuracy

 

Our Enterprise Feed Detection Availability Leads the Pack

According to our own internal findings, which can be verified using our SecInfo Portal, the Greenbone Enterprise Feed has detection tests for 129 of the 164 CVEs included in the test. This means our Enterprise product’s Detection Availability is a staggering 70.5% higher than reported, placing us heads and tails above the rest.

To be clear, the Greenbone Enterprise Feed tests aren’t something we added on after the fact. Greenbone updates both our Community and Enterprise Feeds on a daily basis and we are often the first to release vulnerability tests when a CVE is published. A review of our vulnerability test coverage shows they have been available from day one.

Our Detection Accuracy was far Underrated

And another thing. Greenbone isn’t like those other scanners. The way Greenbone is designed gives it strong industry leading advantages. For example, our scanner can be controlled via API allowing users to develop their own custom tools and control all the features of Greenbone in any way they like. Secondly, our Quality of Detection (QoD) ranking doesn’t even exist on most other vulnerability scanners.

The report author made it clear they simply used the default configuration for each scanner. However, without applying Greenbone’s QoD filter properly, the benchmark test failed to fairly assess Greenbone’s true CVE detection rate. Applying these findings Greenbone again comes out ahead of the pack, detecting an estimated 112 out of the 164 CVEs.

Summary

While we were honored that our Greenbone Community Edition ranked 5th in Detection Availability and tied for 4th in Detection Accuracy in a recently published network vulnerability scanner benchmark, these results fail to consider the true power of the Greenbone Enterprise Feed. It stands to reason that our Enterprise product should be in the running. Afterall, the benchmark included enterprise offerings from other vendors.

When recalculated using the Enterprise Feed, Greenbone’s Detection Availability leaps to 129 of the 164 CVEs on the test, 70.5% above what was reported. Also, using the default settings fails to account for Greenbone’s Quality of Detection (QoD) feature. When adjusted for these oversights, Greenbone ranks at the forefront of the competition. As the most used open-source vulnerability scanner in the world, Greenbone continues to lead in vulnerability coverage, timely publication of vulnerability tests, and truly enterprise grade features such as a flexible API architecture, advanced filtering, and Quality of Detection scores.

Ransomware, phishing, denial of service attacks: according to a recent study, 84 per cent of the companies surveyed are concerned about the security of their IT systems and see a further increase in the threat situation. For good reason, as companies are also concerned about outdated code, data theft by employees, inadequate protection of company […]

Why is Greenbone not a security provider like any other? How did Greenbone come about and what impact does Greenbone’s long history have on the quality of its vulnerability scanners and the security of its customers? The new video “Demystify Greenbone” provides answers to these questions in an twelve-minute overview. It shows why experts need […]

Earth quakes and cyber attacks have much in common. First: The forces are outside of our control and we can not prevent them to happen.

Second: We are not helplessly at the mercy. We can install early warning, minimize destructive effect and recover quickly. But only if we act BEFORE it happens.

Sure, earth quakes are about human live and cyber attacks are so far usually not. Yet I think this comparison is important in order to make it easier to understand the significance of cyber attacks the the options for action.

Of course there are also differences and the most striking one to me is the average frequency of occurence. This vivid direct comparison shows the parallels:

We have no technology to prevent them to happen, but… Earth quake Cyber Attack
We have prognosis models where they happen most likely Tectonic models Vulnerability intelligence

We have sensors that provide early warnings shortly before it happens

(sometimes they fail though with false positive and false negatives)

Seismographs Vulnerability scanning and threat intelligence
We have a scale to compare events about potential damage

Richter magnitude scale: Ranges from 1.0 to 9.9

  • Sometimes the effect is just shaking indoor objects and sometimes it is collapse of buildings

Severity Score: Ranges from 0.1 to 10.0

  • Sometimes you have some extra network load and sometimes a remote administrative exploit.
…you can do something to minimize negative impact:
Make you infrastructure stable against this type of force

Obligatory architecture designs

  • Overview and controlling of compliance

Obligatory security policies

  • detection and limitation of attack surface:
  • Vulnerability testing and remediation
  • Vulnerability management and compliance
Have trained teams ready to help recover quickly when it happens
  • Central command center and
  • distributed on-site medical and repair teams
  • Processes and and regular trainings thereof
  • Security operation center and distributed system administrator
  • Dev-ops or suppliers for operational support
  • Processes and and regular trainings thereof
Make all people aware on how to save their lives best when it happens
  • Understandable training materials and
  • regular awareness trainings
  • Understandable training materials and
  • regular awareness trainings


Contact Free Trial Buy Here Back to Overview

Jennifer Außendorf, project lead of the project for Predictive Vulnerability Management

Project lead Jennifer Außendorf

Identifying tomorrow’s vulnerabilities today with Predictive Vulnerability Management: Together with international partners from across Europe, Greenbone’s cyber security experts are developing a novel cyber resilience platform that uses artificial intelligence and machine learning to detect vulnerabilities before they can be exploited, helping to prevent attacks.

Greenbone is strengthening its internal research in the field of “Predictive Vulnerability Management” and will additionally participate in publicly funded research and development projects in 2022. Currently, the security experts are working on a funding application for a European Union project. Until the first phase of the application submission is completed, Greenbone is involved within an international consortium and is working on a joint cyber resilience platform. The focus here is on preventing attacks in advance so that remedial action can be taken more quickly in an acute emergency. Methods for detecting anomalies by combining and analyzing a wide variety of sources from network monitoring and network analysis data will help to achieve this. The research area focuses on active defense against cyber attacks and includes penetration tests and their automation and improvement through machine learning.

In an interview, project manager Jennifer Außendorf explains what the term “Predictive Vulnerability Management” means.

Jennifer, what is cyber resilience all about? Predictive Vulnerability Management sounds so much like Minority Report, where the police unit “Precrime” hunted down criminals who would only commit crimes in the future.

Jennifer Außendorf: Predicting attacks is the only overlap, I think. The linchpin here is our Greenbone Cloud Service. It allows us to access very large amounts of data. We analyze it to enable prediction and remediation, providing both warnings for imminent threats and effective measures to address the vulnerabilities.

For example, we can also identify future threats earlier because we are constantly improving Predictive Vulnerability Management with machine learning. In the area of “Remediation”, we create a “reasoned action” capability for users: they are often overwhelmed by the number of vulnerabilities and find it difficult to assess which threats are acute and urgent based purely on CVSS scores.

One solution would be to provide a short list of the most critical current vulnerabilities – based on the results of artificial intelligence. This should consider even more influencing variables than the CVSS value, which tends to assess the technical severity. Such a solution should be user-friendly and accessible on a platform – of course strictly anonymized and GDPR-compliant.

Why is Greenbone going public with this now?

Jennifer Außendorf: On the one hand, this is an incredibly exciting topic for research, for which we provide the appropriate real-life data. The large amounts of data generated by the scans can be used in a variety of ways to protect customers. Figuring out what is possible with the data and how we can use that to add value for users and customers is a big challenge.

On the other hand, Greenbone wants to use the project to strengthen cyber security in the EU. For one thing, this is a hot topic right now: customers often end up with American companies when looking for cyber defenses, which usually doesn’t sit well with the GDPR. Greenbone has decided to launch a project consortium and will seek project funding in parallel.

Who will or should participate in the consortium?

Jennifer Außendorf: The consortium will consist of a handful of companies as the core of the group and will be complemented by research partners, technical partners for development and a user group of other partners and testers.

Because the project will take place at EU level, it is important for us to involve as many different member states as possible. We hope that the different backgrounds of the partners will generate creative ideas and approaches to solutions, from which the project can only benefit. This applies equally to the phase of building up the consortium.

Are there other players in the field of Predictive Vulnerability Management so far or has no one tried this yet?

Jennifer Außendorf: At the moment, we don’t see any competitors – Greenbone also deliberately wants to be an innovation driver here. Yes, the buzzwords “thought leadership”, “cloud repurpose” and “cyber resilience” are certainly floating around, but there is one thing that only we (and our customers) have: the anonymized data, which is essential for the research results, and above all the large amount of data that makes it possible to apply machine learning and other methods in connection with artificial intelligence in the first place – only we have that.

What is the current status there, what is on the roadmap?

Jennifer Außendorf: We are currently in the process of specifying the individual topics in more detail with the first research partners. They have many years of experience in cyber security and machine learning and provide very valuable input. We are also currently working on expanding the consortium and recruiting additional partners. Work on the actual application should start soon.

Our goal is to incorporate the results of the project directly into our products and thus make them available to our customers and users. Ultimately, they should benefit from the results and thus increase cyber resilience in their companies. That is the ultimate goal.

Contact Free Trial Buy Here Back to Overview

Greenbone’s vulnerability management finds applications with Log4j vulnerabilities in systems that definitely need to be patched or otherwise protected. Depending on the type of systems and vulnerability, these can be found better or worse. Detection is also constantly improving and being updated. New breaches are found. Therefore, there may always be more systems with Log4Shell vulnerabilities in the network. For this reason, it is worthwhile to regularly update and scan all systems. The Greenbone vulnerability management offers appropriate automation functions for this purpose. But how are vulnerabilities found, and where can they be hidden? Why are vulnerabilities not always directly detectable? The following article will give you a brief insight into how scanning for vulnerabilities like Log4Shell works.

A vulnerability scanner makes specific queries to systems and services and can read from the responses what kind of systems and services they are, but also what products are behind them. This also includes information such as their versions or even settings and other properties. In many cases, this makes it possible to determine whether a vulnerability exists and whether it has already been eliminated. In practice, these are sometimes highly complicated and nested queries, but above all they are also very, very many. Entire networks are scanned for thousands of different vulnerabilities.

The Log4j vulnerability “Log4Shell” (CVE-2021-44228) is a flawed program library used in many web services products. Therefore, partly it is directly visible through a vulnerability scan, but partly it is hidden behind other elements. That is why there is not only one vulnerability test for Log4j, but several. More are added all the time because the manufacturers of the respective products share relevant information and also provide updates to close the gaps. The list of systems affected by Log4Shell is constantly updated at https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592.

Some of the vulnerability tests require an authenticated scan. This means that the scanner must first log into a system and then detect the vulnerability in the system. An authenticated scan can provide more details about vulnerabilities on the scanned system.

The vulnerability tests that are suitable to find the Log4j vulnerability are provided collectively in a scan configuration. Greenbone keeps this “Log4j” scan configuration continuously up-to-date in order to keep adding new tests. As a result, a scan may report a Log4j vulnerability tomorrow that was not found today. It is therefore advisable to configure the Log4j scan to run automatically on a regular basis. This is especially important in the next weeks, when many software vendors are gathering more findings. Greenbone continuously integrates these findings into the tests and the scan configuration.

scanning for vulnerabilities like Log4Shell
Does a Vulnerability Have to Be Exploited to Find It?

Exploiting a vulnerability to find it is not advisable. And fortunately, it is not necessary either. Doing so could cause the very damage that should be avoided at all costs. Moreover, a product vendor that provides vulnerability exploitation as a feature would potentially strongly encourage misuse of that feature, which raises further – not only legal – issues. Therefore, Greenbone’s vulnerability management does not include such features.

Exploitation of the Log4j vulnerability as attackers would do is also not required to prove the existence of the vulnerability. Greenbone has developed several tests to prove Log4Shell, each of which looks at systems in different depths. Several tests can detect the Log4j vulnerability with 100 % certainty, most with 80 % to 97 % certainty. Some tests also collect indicators of 30 % where they do not get close enough to the vulnerability. Each test at Greenbone makes a statement about detection certainty, which is stated as “Quality of Detection.”

What Is the Role of Software Product Vendors?

Manufacturers of a wide variety of products can use Log4j libraries, which are now vulnerable with it. Product manufacturers have included Log4j in different ways. Usually, a deep scan can find Log4j without the vendor’s help. However, most manufacturers also support the process through public vulnerability reports. These can then be used to write vulnerability tests that can provide a reliable vulnerability statement even with less deep scans. The reason for this is that the scans can use simpler configurations through vendor information. In addition, they also run faster.

In principle, however, a vulnerability scanner can also check and find vulnerabilities without the manufacturer publishing a vulnerability report.

Conclusion

Vulnerability management is an indispensable part of IT security. It can find risks and provides valuable information on how to fix them. However, no single measure provides 100 % security, not even vulnerability management. To make a system secure, many elements are used, which in their entirety should provide the best possible security.

This is comparable to a vehicle, where the passenger compartment, seat belts, airbags, brake support, assistance systems and much more increase safety, but can never guarantee it. Vulnerability management makes risks controllable.


Contact Free Trial Buy Here Back to Overview