Tag Archive for: Greenbone

Markus Feilner

Predictive Vulnerability Management with Greenbone

,
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
/by
Markus Feilner

Ransomware as a Service: the Role of Bitcoin and Darknet

Both the cryptocurrency Bitcoin and the darknet have a dubious reputation. The media like to portray both as opaque, criminal parallel worlds. For Ransomware as a Service, Bitcoin and the darknet are welcome tools. Organized crime has been using them for a long time to disguise its business, even if it by no means makes the criminals anonymous and safe from prosecution.

Ransomware became the world’s biggest threat to IT systems in 2021. If you want to successfully protect yourself against it, you also need to understand how the parties involved proceed. Part one of this series of articles focused on the business model of Ransomware as a Service. Part two showed why this “professionalization” also leads to a changed mindset among attackers. Part three now explains why the IT tools that organized crime uses to order and transfer money are far from secure.

Ransomware as a Service: abstract image of Bitcoin logo

Anonymous and Secure?

Bitcoin as a means of payment and the darknet are proving to be practical, helpful and attractive for attackers. Under the cloak of supposed anonymity, they think they are protected from prosecution and shielded from consequences. But this is a common misconception: neither Bitcoin nor the darknet are anonymous in practice.

While cryptocurrency was never designed for anonymity, but explicitly for traceability of transactions even without a reliable central authority, the darknet turns out to be not even remotely as anonymous as its creators would have liked. This is also shown by reports such as the recent ones about KAX17’s “de-anonymization attacks” on the Tor network. Nearly always, classic investigative methods are enough for law enforcement to track down even ransomware actors like the REvil group. This group had collected half a million euros in ransoms in more than 5,000 infections, according to Heise [German only].

Never a Good Idea: Cooperating With Criminals

No matter whether online or offline, anyone who gets involved with blackmailers is abandoned. As in real life, good advice is never to pay a ransom. Regardless of how professional the hotline on the other end seems, trust is not appropriate. The operators of REvils Ransomware as a Service, for example, even stole the extorted ransoms from their clients via a backdoor in the malware.

It all started out so friendly and idealistic. Roger Dingledine and Nick Mathewson laid the foundations for the Tor network in the early 2000s. Based on the idea of onion rings, numerous cryptographically secured layers on top of each other were supposed to ensure reliable anonymity on the web – in their opinion, a fundamental right, analogous to the privacy definition of Eric Hughes “Cypherpunk’s Manifesto”. Then in 2009, Bitcoin saw the light of day, first described by the almost mystical figure of Satoshi Nakamoto.

Darknet and Bitcoin Are Not “Criminal”

Neither the darknet nor Bitcoin were designed to conceal or enable dark schemes. The goal was to create free, independent, supposedly uncontrollable and largely secure structures for information exchange and payment. Like a knife, however, the services can be instrumentalized for both good and evil – and, of course, organized crime knows how to use this to its advantage. The focus is not always on leaving no traces. Most often, the focus is on the simplicity and availability of the means. Bitcoin and the darknet are simply the tools of choice because they are there.

But as in the real world, the easiest way to catch the extortionists is during the money transfer: a blockchain like Bitcoin documents all transactions ever made, including the wallet information (i.e., the Bitcoin owner), and makes it available for viewing at any time. The same applies to the darknet: even if anonymity is technically possible, people regularly fail to meet the simplest requirements. GPS meta-data can be found in photos or UPS codes in the illegal store. The legendary drug store Silkroad was busted because employees made mistakes and confessed.

Digitized, Organized Crime

The darknet and cryptocurrencies are helpful tools for organized crime and thus fire accelerators for the rapidly growing number of serious ransomware attacks. But they are by no means essential, nor are they to blame. Such cyber crime is just the modern IT variant of what we can also experience on the streets of any major city. Ransomware is, so to speak, the modern protection racket, Bitcoin is the garbage can for the handover, and the darknet is the dark bar where deals are made.

The perfidy is not in the tools, but in the methods and the long experience in the “business”. Trend Micro, for example, describes the “double extortion ransomware” approach. Here, attackers first make an image of the data and threaten to publish it if payment is not made (i.e., if it is not decrypted). Organized crime has been in the extortion business not just since Bitcoin or the darknet came into existence. Even though the two technologies now enable cyber criminals to extort large sums of money undetected at first, conventional methods are almost always sufficient for detection. The most important prerequisite here is that enough law enforcement personnel are available, not primarily their technical equipment.

Take Precautions

But at this point, in the company, the horse has already bolted. If you are faced with encrypted data and a ransom demand, the darknet, Bitcoin and the detection rate are probably of secondary importance. Much more important is the question of how to get out of the unfortunate situation. And you can only do that if you were prepared. This includes backups, restore tests and the immediate disconnection of all affected machines (network split) – in other words, proactive risk management, disaster recovery tests and constant maintenance of your own systems. Another important component is multi-factor authentication, which prevents attackers from shimmying from one system to the next using acquired passwords alone.

The most important thing, however, is to avoid critical situations in the first place and to identify vulnerabilities in your own systems and close them quickly. Modern vulnerability management like Greenbone’s does just that: it gives you the ability to close gaps in your systems, making the corporate network unattractive, costly, and thus a deterrent to professional cyber criminals, not just from the Ransomware-as-a-Service world.

Greenbone’s products monitor the corporate network or external IT resources for potential vulnerabilities by continuously and fully automatically examining it and, as Greenbone Enterprise Appliances or the Greenbone Cloud Service (software as a service hosted in German data centers), guarantee security by always up-to-date scans and tests.

How this works is described by Elmar Geese, CIO/CMO at Greenbone, also here in the blog with a post around the Log4j vulnerability. In addition, Geese explains how quickly and securely the administration and management are also informed of the latest vulnerabilities and how exactly the scan for vulnerabilities such as Log4Shell is carried out.


Contact Free Trial Buy Here Back to Overview

/by
Elmar Geese

ISO Certification of Our Management Systems

We are proud to have received ISO certification of our management systems for the aspects of quality (ISO 9001) and information security (ISO 27001) at the end of 2021.

Logos of the ISO certification of our management systems

Our success makes us grow, and our growth promotes structure and processes. That is why we actively accompany the creation of structures and processes even more than in the past. In doing so, we are guided by the following goals:

  • Create value for our clientele
  • Provide great products and services
  • Continuously increase the satisfaction of our employees
  • Promote and manage our growth

When we decided to certify information security and quality in our company according to ISO 27001 and ISO 9001 standards, we took the specifics of an agile company into account from the very beginning.

ISO-certified management systems and agile management seem to be a contradiction, but they are not. In this article, we will briefly explain how these two worlds complement each other perfectly and how we combine the respective advantages in one company.

Although agility is not a goal in itself, we were aware that we wanted to run an agile company in an agile way. We understand it like this:

  • We have a common goal.
  • Clarity and explicitness in communication are prerequisites for results-oriented action.
  • Hierarchies are tools, not status functions.
  • Processes are paths to the goal, not goals themselves.

We have recognized that ideally we can use a toolbox that is as universal as possible in the different areas of our organization, which on the one hand helps us to organize our processes in the best possible way, and on the other hand leaves enough room for the different needs of the different teams and areas.

The concepts from worlds as different as “ISO” and “Agile” have helped us and continue to help us. What they have in common is that the concepts require management systems that are more similar in their basic structure than one might think.

It is always about:

  • Focus on sufficiently clearly defined objectives
  • Reliable and appropriate guidelines
  • Comprehensibly defined and helpful processes
  • Measuring points to evaluate, adjust and change as necessary
  • Supportive team members and servant leaders who operate within this structure
  • A continuous improvement process

This is what we call a management system and its inherent agility is defined by the context and purpose when it is applied. It allows us to measure the results and the quality of the processes through a system of objectives and performance indicators.

We are proud and happy that we could now certify our management systems very successfully for the aspects “Quality” (ISO 9001) and “Information Security” (ISO 27001). It helps us and it also helps you as our clientele. It measurably documents two very important characteristics that you expect from us and our products and services and that you ultimately want to ensure by using our products in your own organization, namely:

  • Security, and
  • Quality of information technology systems.

It’s our mission at Greenbone to ensure this through one of the leading vulnerability management products. We do it every day, in over 100,000 organizations around the world.


Contact Free Trial Buy Here Back to Overview

/by
Elmar Geese

Additional Log4j Vulnerabilities Published

Log4j was affected by a vulnerability that allowed Remote Code Execution (RCE) attacks. In short, user inputs into a software could lead to a code execution on a remote server. This represents a severe security risk. It was named “Log4Shell” (CVE-2021-44228) and immediately addressed by the Log4j team, who provided a fix. In the following days, additional Log4j vulnerabilities were found. While these do not have the same impact as the first one, they can also cause severe damage. For this reason, it is very important to check systems and always update to the latest versions.

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:


Contact Free Trial Buy Here Back to Overview

/by
Elmar Geese

Scanning for Vulnerabilities like Log4Shell – How Does It Work?

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

/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
Elmar Geese

Log4j Vulnerability Detection Available in Greenbone Feeds

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

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

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

log4j detection in Greenbone feeds

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

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

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

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

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

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


Contact Free Trial Buy Here Back to Overview

/by
Markus Feilner

New Vulnerability Scanner “Notus”

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

Scanner architecture of the new vulnerability scanner

 

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

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

Performance Shortcomings of Classic Scanners

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

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

JSON Data Helps Speed up the Scanner

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

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

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

About Greenbone and OpenVAS

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

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

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

Full CVSSv3x Coverage in the Greenbone Feeds

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

Helpful Severity Metrics

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

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

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

How Severity Ratings Are Created

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

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

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

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

How is the Severity of a Vulnerability Calculated?

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

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

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

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

CVSSv3.0/v3.1 Support Since GOS 21.04

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

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

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

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

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

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

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

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

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

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

Contact Free Trial Buy Here Back to overview
/by
Patricia Meibert

Greenbone appoints Elmar Geese as Chief Operating Officer – Greenbone expands management team to support continued growth

Osnabrück, March 13, 2020 – Vulnerability management specialist, Greenbone, today announced it has appointed Elmar Geese to the newly created role of Chief Operating Officer (COO). Geese, who joins the company’s senior management team, will play a key role in Greenbone’s future growth, overseeing the company’s expanding operations.

Portrait of Elmar Geese, Chief Operating Officer at Greenbone, responsible for corporate strategy and operational growth.Geese will take responsibility for Greenbone’s overall corporate strategy as well as process optimisation within the company. He will also focus on adding value to Greenbone’s range of products by, for example, making its vulnerability management solution available as a managed service, so it is more accessible to companies that do not have the in-house capabilities or resources to deploy and manage their own hardware.

“With its solutions for intelligent vulnerability management, Greenbone has the potential to develop from a European market leader to a global player,” said Geese. “The security of information systems is fundamental for companies and our modern society, demonstrated by the many security incidents we now witness every day. Greenbone plays a decisive role in making our world safer and I look forward to taking a major part in this.”

Geese has over three decades of experience within the IT sector, working as founder, manager and consultant. Most recently, he was CIO at the Berlin health start-up machtfit, where he was responsible for the company’s SaaS platform for occupational health management. As head of product development and operations, he also contributed to the long-term acquisition of customers such as Bayer AG, Deutsche Bahn, Lufthansa, Edeka and Lanxess.

“We are thrilled to welcome Elmar onto the Greenbone team,” said Jan-Oliver Wagner, Greenbone founder and CEO. “As we continue to grow, it’s essential that we have someone to support us at management level with a capable head for business and a strong entrepreneurial background. Elmar offers just that, and we are very much looking forward to working with him and are confident that with him on board, we will easily master the tasks that accompany rapid company growth.”

 

Contact Free Trial Buy Here Back to overview
/by