[German]There is a critical unpatched vulnerability in the log4j Java library used for logging. This software is integrated in many other products. Thousands of services from Apple, Amazon, Twitter, Minecraft, etc. are vulnerable via this vulnerability. Meanwhile, the first attacks on honeypots have already been observed. Here's a brief overview of what's going on.
Advertising
A German reader pointed out this problem in this comment, which is described here, among others. log4j is an Apache library for logging in Java. This library is probably very powerful and flexible and also quite popular. Therefore this library is used in almost every Java application for logging.
Unfortunately, there is an unpatched vulnerability in log4j in the JNDI lookup function. The JNDI lookup function of log4j allows variables to be retrieved via the JNDI – Java Naming and Directory Interface. This is an API that provides naming and directory functions to Java applications. While there are many possibilities, log4j supports (AFAIK) LDAP and RMI (Remote Method Invocation).
Note: I was asked if ports like log4net etc. are also affected. According to this post, rather not.
Vulnerability CVE-2021-44228
A Proof of Concept (PoC) for the remote code execution vulnerability in log4j was published on December 9, 2021. The PoC requires only a few lines of code with which to write a string in the form of a URL to the log file. The directory service JNDI then contacts the LDAP server listed in the log to request data from it. This can also include Java classes, which are then executed. If an attacker succeeds in specifying the URL to a server they control in the log file, they can hijack a server via logging (Log4Shell).
Vulnerability CVE-2021-44228 is rated critical and has received a CVE index of 10 (out of a possible 10 points). Pen testing group 0x0021h, which developed the PoC exploit, states that it works for Apache Struts2, Apache Solr, Apache Druid, Apache Flink and. This GitHub page lists affected services – everything of note is there. Besides Apple iCloud, Amazon, CloudFlare, Steam, Twitter and even the popular Mindcraft is all there. According to Bleeping Computer, Minecraft has already been patched via the emergency patch Minecraft: Java Edition 1.18.1.
Application administrators should look for updates from software vendors and install them promptly. Since exploitation of the vulnerability requires the affected server/client to reach another server on the Internet (which provides the JNDI reference), the following measures can be implemented, according to the SANS institute:
Advertising
- Blocking outbound traffic that is not required. For those who have a server running a Java application that only needs to accept incoming traffic, all outgoing traffic should be prevented.
- Anyone checking traffic should look for LDAP and RMI protocols and filter them..
I think we will still read about incidents from an attack via the log4j vulnerability in the coming days. CERT Telekom reports here about attack attempts they observe in their own honeypots.
Apache patches and a vaccine
Besides Microsoft, which has provided a patch for Minecraft, there is the patch Log4j 2.15.0 from Apache to close the vulnerability. And there is still a universal antidote from the security company Cybereason since 10.12.2021, as I read at the colleagues of Bleeping Computer.
A script Logout4Shell provided on GitHub allows to remotely disable a setting in a vulnerable Log4Shell instance. Logout4Shell walks the user through setting up a Java-based LDAP server and includes a Java payload that disables the 'trustURLCodebase' setting in a remote Log4j server. This allows the CVE-2021-44228 vulnerability to be mitigated.
While the best mitigation against this vulnerability is to patch log4j to 2.15.0 and later, this behavior can be mitigated in Log4j versions (>=2.10) by setting the log4j2.formatMsgNoLookups system property to true or by removing the JndiLookup class from the classpath, the GitHub page states.
Additionally, if the server has a Java runtime version >= 8u121, the com.sun.jndi.rmi.object.trustURLCodebase and com.sun.jndi.cosnaming.object.trustURLCodebase settings are set to false by default, mitigating the risk of exploitation. For more details, see the GitHub description.
Similar articles:
0-day CVE-2021-44228 in Java library log4j puts many projects at risk
log4j vulnerability CVE-2021-44228: Patch your Minecraft
VMware products threatened by log4j vulnerability CVE-2021-44228
