Usage of the Log4J Library
Logging helps developers to see all the activities an application is performing and nearly, every software application (even cloud-based) creates logs for its errors. Developers, usually, do not create their application’s logging system (to not reinvent the wheel) but prefer to use an already established logging library (a common norm in coding and development) and one of the most popular logging libraries of Java is Log4J. So, nearly every application (including applications by governments, agencies, enterprises, Microsoft, Apple, Google, etc.) that is written in Java may have this library and a vulnerability in a such library could be a cyber security worst nightmare and dream come true for hackers. Moreover, this library is open-source, so there are no official figures on how many devices/ applications are using this library. The Log4J is used by many popular applications (like Twitter, Apple iCloud), games (like Minecraft, Steam), websites, etc. Along with these, this library is also part of many other frameworks like Kafka, Elasticsearch, Flink. The list of applications, products, plug-ins vulnerable to the Log4J exploit is increasing continuously.
Detection of a Vulnerability in Log4J
The first report of a vulnerability in Log4J was initially surfaced on 1st December 2021 by Chen Zhaojun from the Alibaba Cloud Security team, who, as a standard bug hunting practice and as a responsible I.T. person, informed the Apache Foundation about the flaw (although, some bug hunters sell such vulnerabilities to hackers and such vulnerabilities go undetected for months or years). The detection has occurred in Minecraft. Minecraft’s chat feature is the source of identification of the Log4J exploit. The game’s chat algorithms are based on the Java API that uses the Log4J library and this library allowed the bad guys to freeze Minecraft servers, remove all players, etc. In a favorable environment, this vulnerability was easily manipulated by Remote Code Execution (RCE), which enhances the threat level of the vulnerability. The presence of a vulnerability in the Log4J library was publicly accepted on 9th December 2021 by Apache. The vulnerability was named as Log4Shell and was officially labeled as CVE-2021-44228. The CVE (Common Vulnerabilities and Exposures) numbering system is a nomenclature to uniquely identify each vulnerability/exploit detected all across the world. The Log4J is categorized as a zero-day (or 0 day) vulnerability. The zero-day vulnerability means that the vulnerability is already targeted by hackers, even before the developers knew about the flaw and have zero-day to implement a patch for the exploit.
Affected Versions of the Log4J Library and Released Patches
The Log4J versions 2.0 to 2.14.1 are reported to be affected by the vulnerability. The Log4J version 2.15.0 was the original patch released for the CVE-2021-44228 but later on, another vulnerability was found in Log4J (mostly, in non-default configurations) labeled as CVE-2021-45046. This vulnerability had a security impact of 3.7 (quite low as compared to the original vulnerability). The Apache Foundation then released the Log4j version 2.16 to patch the exploit in the original fix. As we were working on this article, another patch Log4J version 2.17 for the Log4J vulnerability labeled as CVE-2021-45105 (the Denial-of-Service/DoS attack) is released from Apache. The information about patches is available on the official Log4J security page of the Apache website. Many readers might think that as the patch is already applied to the Log4J, then why this fuzz? Although the latest version of the Log4J library is patched, the applications, products, plug-ins, etc. that are still using the older versions of Log4J are still unpatched. Also, there is the case of applications that have become abandonware and are using a vulnerable version of Log4J. Abandonware is a software product that is ignored/ not further developed by its owners/ manufacturers and is without any official support.
The Magnitude of the Log4J Exploit
On a security impact rating, the Log4J exploit can easily be categorized as 10/10 (the highest possible risk level). The magnitude of this vulnerability is so large that all the major players (Microsoft, Google, Cisco, etc.) along with governments and Apache (the developers of Log4J) are working day and night to patch the vulnerability. The concern and response of these companies can be seen on their official web pages or social media accounts. The severity of the vulnerability can be noted when Jen Easterly director of CISA (US Cybersecurity and Infrastructure Agency) mentioned the Log4J exploit as One of the most serious that I’ve seen in my entire career, if not the most serious. And due to this severity, the IT industry leaders think that the Log4J vulnerability will keep haunting the industry for years to come.
Why was the Log4J Vulnerability not Detected Earlier?
A question comes into many users’ minds that why a vulnerability of such magnitude was not detected early as the Log4J library is available since 2013. Although in the USA 2016 BlackHatEvents a vulnerability of Log4J was presented, that discussed JNDI as an attack vector, whereas, the current vulnerability is a type of template injection which allows for the use of JNDI. But in software applications, exploits are hard to detect as new technologies emerge, the horizon of I.T. industry changes (e.g., software applications before the invention of the Internet and after the Internet are a different story). Also, as discussed earlier, the Log4J library versions below 2.0 are not affected (they have their shares of issues), so, advancement in technology was the reason this exploit could be detected.
Attacks by Using the Log4J Vulnerability
With the new exploit in town, hackers are targeting their tools to use the exploit. First noticed malware targeting the exploit was CryptoMiners (that mines crypto-currency from the affected machine). That was followed by Cobalt Strike (penetration testing) to steal the username/passwords from the infected system. Then the ship was joined by ransomware-based malware like Khonsari and the list is going on. And last but not least, the state-backed hacking groups by various countries are targeting the rivals by exploiting this vulnerability. Here is a map from ESET about the reported attacks carried out (highest volumes of attacks in the US, the UK, Germany, Turkey, and the Netherlands.). Until now, there are 1800000 plus reported incidents (and counting) of attempts to use this Log4J exploit by hackers. Also, nearly over 40 percent of corporate networks are attacked by using this vulnerability. The availability of the exploit code on various sites has made matters worst. Moreover, things got complicated as the exploit can be targeted by HTTP and HTTPS protocols. But that is just the starting point as if a malware worm targeting the vulnerability is developed, then its impact might be way more than the original vulnerability. Because, a computer worm is a standalone piece of software that quietly replicated itself and spreads through the network (e.g., the Code Red worm in the 2000s or WannaCry in 2017).
How it Works
The Log4J library (along with the logging framework) keeps a track of what an application is doing and to use the exploit, an attacker only needs to force a log entry in Log4J by a simple task e.g., setting a username of an account or sending the code string in an email. Creating an application’s log entry by an attacker in the logging framework may vary from application to application (e.g., in Minecraft, chat feature was used) or computer to computer. Once such a log entry with malicious code is created, then the attacker can load malicious code to the machine, take full control of the system, spread through the network, install malware, launch another form of attack or whatnot. The most dangerous part of this vulnerability is that it is “pre-authenticated,” which means a hacker does not have to sign into a vulnerable system to take control of it. The exploit can be simply described in the following steps: The process is explained in the following chart:
Are You Safe?
So, after going through the above, a question comes into a users’ mind is that am I safe? It depends. If a user is a part of an organization that uses the Java Log4J library, then he and his organization are at risk. If a user or his organization are not using anything Java-based (most unlikely) but if the enterprise application dependencies, 3rd party vendor utilities or application are Java-based, then the user or his organization might be at a risk. You can search the Internet for the applications that you are using if those are vulnerable.
What to Do?
Now, the ultimate question, what to do if a Log4J vulnerability is present in your system or organization.
For a User
A common end-user cannot do anything substantial about this vulnerability except to keep his applications (especially antivirus/anti-malware applications), devices, or OS up to date. If the user is using a form of abandonware, then uninstalling it may keep his system safe. Also, if you are using an online service (like Stream), then making sure they have applied the patches (check their official pages or social media handles) is the way forward for a common user.
For an Organization
The milage to safeguard an organization from the Log4J exploit may vary from organization to organization. The first step should be to do an audit of the entire infrastructure, application dependencies, 3rd party vendor utilities, or remote employees to find out if the vulnerability exists. The audit should look for application logs for the following patterns or their derivations: The organization can also use automated threat hunting and investigation tools (like Log4J Vulnerability Tester by TrendMicro) to find out any such applications that have the Log4J vulnerability. The organization’s developer should be put on the task to check their code for any reference to the Log4J vulnerability. Also, the Internet-facing devices of an organization should be patched at the earliest possible time to avoid a catastrophe. An organization should act as fast as possible as the organization has to compete with the bad guys who are at least 7 days ahead of others to target the vulnerability.
Technical Aspects of the Vulnerability
Till now, we tried to cover the Log4J vulnerability in layman terms but in this section, we will discuss the Log4J vulnerability in developers’ technical terms. This vulnerability is exploited by using the JNDI (Java Naming and Directory Interface) Lookup. This can result in a denial-of-service (DoS) attack. Whenever JNDI finds an expression like ${a_Java_expression}, it finds the value of that expression and replaces it. Some of the Log4J supported lookups are sys, JNDI, env, java, lower, and upper. Some of the supported protocols by Log4J lookup are LDAP, DNS, RMI, and IIOP. To inject an entry in the application log, the attacker may use HTTP requests to a server and upon receiving the request, the Log4J lookup will download and execute the malicious.class (hosted on the hacker-controlled LDAP server), if the ObjectClass attribute in LDAP object is defined as javaNamingReference and has the following attributes: Then the LDAP object loader will extract the contents of the malicious URL as defined in the javaCodebase and will create a corresponding object in the memory. Once the initialization method or more formally, the constructor of the mentioned class is executed, an untrusted code from an untrusted source will be running on the infected machine. The most basic expression that an attacker can inject in the Log4J is This will execute the malicious code hosted on: Once the malicious code is executed successfully, the server interprets the string leading to shell commands in various formats like JavaScript, Java Class, Unix shell, etc. Another factor increasing the severity of the vulnerability is the nesting ability of the Java ${} block which will make detection of the suspicious strings a lot more difficult. For example, instead of using ${ jndi:}, hackers can use ${${lower:jn}${lower:di}} which will allow hackers to extract information/data from a remote server. An interesting question that might come into a reader’s mind is where to put the code that can land into the Log4J library? Many applications log everything happening to them including the incoming requests like HTTP headers (like User-Agent or X-Forwarded-For), URI, the request body, etc. The worst part is that an attacker can send such a request to an application’s logger from all the Internet and then can give commands to control the infected machine. The process is made clear in the following diagram: Following are the few examples of the URLs identified so far to initiate different types of attacks by using the Log4J library: The following is a piece of the HTTP server logs showing a Log4J exploit attempt: The base64 string in the above log decodes to: This will fetch a malicious code from 45.155.xxx.xxx and subsequently run the script by using Bash. In the end, we will want our readers to be vigilant against this threat and should not take it lightly because there is a reason Internet is on fire due to this vulnerability.
Open Source Vulnerability Index Containing 140,000 Vulnerabilities Launched by…Google Introduces Android Partner Vulnerability Initiative To Track Security…Dirty Pipe: The Latest Serious Linux Kernel Vulnerability is Being PatchedWindows 7 Receives Its First Ever Third-party Security Patch For IE 11…
