A recently disclosed vulnerability in the Log4j logging library (CVE-2021-44228) is forcing administrators to take immediate action. The Log4Shell vulnerability allows the execution of Java code in the affected library. Attackers could exploit this to plant their own malware, including ransomware, which can provide extensive data encryption, and cryptominer, which harnesses the resources of compromised devices for targeted mining of cryptocurrencies. Attackers can also integrate compromised systems into a botnet from which cyberattacks can be carried out.
The vulnerability affects Log4j up to version 2.14. A new version of the library 2.15, which fixes the gap, has already been released. However, the problem is more profound. Even determining whether systems are affected by the vulnerability is not trivial. Due to the wide distribution of the Log4j library, a large number of possible products come into consideration, which should be examined for the presence of the vulnerability.
To make matters worse, software in use often relies on its own instances of the library, so that patching the system library is not sufficient in case of doubt, but each application must be updated separately to close the security gap.
A list of eligible products with references to manufacturers’ comments has been published on GitHub website. This includes applications from manufacturers such as Apache or VMWare that are widely used in the corporate context. In its report, the German Federal Office for Information Security recommends repeatedly comparing the list with products in use, as it is continuously updated.
If patching is not currently possible, it should be checked in any case to what extent hardening of the affected systems, especially with regard to possible outgoing connections, can provide a remedy. Temporary deactivation of affected systems or components should also be considered until a secure way to close the gap is available.
If companies are affected by the vulnerability, it is important to take into account not only the need for rapid technical action but also a possible obligation to report a potential data breach in accordance with Article 33 of the GDPR. This obligation emerges as a result of the possible impairment of personal data that is processed on the compromised systems. Attackers can, for example, ensure a data outflow through a compromise and thus ensure a breach of confidentiality.
Even if there are thus far no indications of this vulnerability, investigations should be initiated and documented in order to be able to subsequently disclose all necessary information to potential affected parties and the supervisory authorities.