Red Warning Level – The Log4Shell Vulnerability

The “Log4Shell” zero-day vulnerability in the Java logging library Log4J is currently one of the hottest topics in IT security. In the night of December 11-12, 2021, the German Federal Office for Information Security (BSI) declared a red warning level – and for good reason. The Log4J vulnerability has created, and continues to pose, colossal risks for the security of IT systems.

1. What is Log4J and what is exactly is the problem?

Log4J is a widespread Java logging library developed by the Apache Software Foundation. Log4J is a component of many well-known Java applications and is used in numerous services provided by Apple, Microsoft, Twitter, Amazon and Mozilla, to name only a few. Overviews (non-exhaustive) of some of the software manufacturers and applications affected are already available on GitHub (here and here).

The extremely critical Log4Shell zero-day vulnerability – which should be taken literally and can be understood as “logging for obtaining direct access to the shell”, makes it possible to insert arbitrary code into the Log4J library on vulnerable servers or applications and thus exfiltrate data from the affected system.

The problem can arise whenever an application logs an event in Log4J. This is because, not only does Java log the relevant entry, but it also tries to interpret this entry. Where such an entry contains a link to malicious Java code, the application will embed it and then execute it. In this way, it is possible to inject any type of malware (e.g. backdoor applications, such as Cobalt Strike Beacons) into and exfiltrate data from the system.

As expected, this vulnerability has already been exploited several times (see here for more information).

2. How can you tell if you have been affected?

As this vulnerability can be exploited in a very trivial way, system administrators must deal with the problem urgently.

To obtain an overview of which applications may be affected, they should request information from the manufacturers or providers of their software and devices.

There are also technical ways of determining whether individual applications or devices have been affected.

3. Liability issues

A question that is far less trivial to answer than exploiting the Log4Shell vulnerability is the issue of determining who is liable for any ensuing damages.

Manufacturers and providers of affected software are urgently recommended to inform their customers of the existence of the vulnerability and to provide an indication of how soon the vulnerability is likely to be fixed.

In addition, using a system that has been affected by the Log4Shell vulnerability can be interpreted as a violation of the relevant statutory regulations on IT security.

How long it takes to apply the patch also depends on the contract concluded between the manufacturer/provider and the customer. If the contract does not contain any specific provisions about IT security, the manufacturer/provider is only required to provide IT security of an average type and quality. It could therefore reasonably be argued that it could take longer before patches must be applied in such instances than in the case of explicit contractual regulations on the level of IT security.

Furthermore, the size of the affected company also plays a role in assessing the time available to apply patches and, consequently, in the issue of any claims for compensation.

There is therefore no clear-cut answer to the question on the extent to which a breach of the regulations on the state-of-the-art mentioned above could effectively lead to a claim for compensation; this will depend greatly on the individual case. However, it can generally be assumed that promptly informing the affected customers and promptly fixing the vulnerability will not lead to claims for compensation.

However, if the vulnerability cannot be fixed quickly, this could definitely lead to a violation of statutory IT security regulations, which could in turn be followed by claims for compensation. In this case, urgent thought must be given to ceasing operation of the affected system, at least temporarily, and only starting it again once the vulnerability has been fixed.

Depending on the contractual agreement between the manufacturer or provider and the customer, any damages incurred to the customer or its customers may then be reclaimed from the manufacturer or provider.

This problem is particularly relevant for IoT devices. The inadequacy of manufacturers and providers in this area has recently been criticised by the IoT Security Foundation (here). In this instance, it is advisable to urgently check the contractual regulations on IT security, in order to then establish your own course of action.

4. Exfiltration of personal data

If data leaks have already occurred and have affected personal data, the competent data protection authorities must be informed immediately of the incident. Pursuant to Art. 33 GDPR, this must take place within 72 hours of becoming aware of the incident. Generally, you are not obliged to proactively search for unauthorised access. However, due to the important media presence and the critical nature of the issue, there may be a different standard in this instance. It is therefore currently thoroughly advisable to investigate any unusual access and to assess log files accordingly. If notification is given more than 72 hours after becoming aware of the incident, it must be accompanied by reasons for the delay.

If such personal data leaks are likely to result in a high risk for the rights and freedoms of natural persons, the data subjects must also be notified without undue delay pursuant to Art. 34 GDPR.