Hrvatski
EnglishAbstract
Recently, a new vulnerability in a very popular Java logging library has been discovered and has taken the tech world by storm. It has been named Log4Shell by the community and has prompted an immediate response from it's developer, Apache. However, not everything went according to plan as multiple other exploits got discovered by the community not soon after the patches were released. The impact was very severe, as legions of hackers jumped at the opportunity to retrieve sensitive information from a large variety of software companies and providers.
Keywords: Log4J, Log4Shell, vulnerability, exploit, Java
Introduction
Log4j is a Java based logging tool developed by Apache and it is one of the most, if not the most popular logging tool available right now. Despite the careful testing and implementation of most available tools of wide varieties, security vulnerabilities rise up. These vulnerabilities are then logged via CVEs (Common Vulnerabilities and Exploits). Log4j is no such stranger to such vulnerabilities, having 8 vulnerabilities discovered from 2017 to 2021. However, on December 9, 2021, a 0-day exploit was discovered which allowed users to execute arbitrary code by exploiting the vulnerability. The vulnerability was described by some as “the single biggest, most critical vulnerability of the last decade” and recieved a 10 out of 10 on the CVE severity scale labeling it as “critical”. It also recieved a name “Log4Shell”.
The exploit
On December 9, 2021, a researcher from the Alibaba Cloud Security Team discovered an exploit targeting specifically the Log4j2 version of Log4j which could allow for arbitrary code execution and reported it to Apache. By default, Log4j supported a feature called Message Lookup Substitution which allows for specific strings to be replaced by other, dynamically created strings at runtime.
For example, logging the following string:
${java:runtime}
will yield a string similar to Java version 1.7.0_67 where the actual version would vary based on the version of Java the system was running. The researcher discovered that one of the lookup method, the JNDI lookup paired with the LDAP protocol will fetch a specified Java class from a remote source, deserialize it and execute it's code. JNDI stands for Java Naming and Directory Interface which provides naming and directory functionality to applications written using the Java programming language while LDAP stands for Lightweight Directory Access Protocol. This means that if any part of the logged string can be controlled by a remote attacker, the attacked gains remote code execution on the application that logged the string.
The exploit can be visualized via the following diagram:
Other exploits
Soon, a patch from Apache claiming to fix the exploit was released dubbed Log4j 2.15.0. However, not long after a new exploit was discovered against the users who had already downloaded the patch. The fix, as researchers said, was incomplete in certain non-default configurations and made it possible for attackers to perform certain Denial-of-service attacks prompting Apache to push out a third fix. Not long after, researchers at a security firm called Praetorian found an even more serious exploit which allowed data to be downloaded from the affected servers which prompted Apache to push out a third fix.
Praetorian also released a proof of concept(POC) demonstrating the exploit.
However, a fourth exploit arose soon after allowing for remote code execution on the system where a configuration uses a JDBC Appender with a JNDI LDAP data source URI when an attacker has control of the target LDAP server.
Impact
Any software which used Log4j was impacted and many of the world famous companies were members of that list. Well known companies and services affected included Amazon, Attlasian, Minecraft, Jetbrains, Oracle and Microsoft Azure to name a few.
More than 35,000 packages from Maven Central had been affected by the vulnerability which amounts to 8% of all the packages published on the remote repository. For reference, the average impact of advisories affecting Maven Central usually affects around 2% of packages with a median of around 0,1%. Fixing the vulnerability proved to be hard, as 80% of the packages using Log4j used it indirectly, meaning that through dependency injection, the vulnerability was more than one level deep, with majority of the packages being affected 5 or more levels deep.
The depth is visualized on the following diagram:
The exploit also prompted the FTC (Federal Trade Comission, a United States government agency) to put out a press release threatening the companies who fail to take necessary steps to mitigate the exploit with legal reprocussions.
Many hackers have been trying to abuse the exploit. These range from ransomware gangs locking down Minecraft servers to hacker groups trying to mine bitcoin and hackers associated with China and North Korea trying to gain access to sensitive information from their geopolitical rivals. The Belgian ministry of defense reported that its computers were being attacked using Log4Shell.
Conclusion
Log4Shell has been one of the most impactful exploits ever to have been discovered. The sheer scope of software and services using the library makes it difficult to see an end in sight. Due to the aforementioned indirect dependency problem, a significant percentage of software providers possibly does not even know their software has suddenly become vulnerable. Also, there is a significant percentage of useful software that has been abandoned and stopped being maintained. However, due to the nature of such software usually being open source, there is a group of people who have taken it upon themselves to fix such software.
Literature
https://jfrog.com/blog/log4shell-0-day-vulnerability-all-you-need-to-know/
https://en.wikipedia.org/wiki/Log4j
https://docs.oracle.com/javase/tutorial/jndi/overview/index.html
https://security.googleblog.com/2021/12/understanding-impact-of-apache-log4j.html
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44832
