Posts

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

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