Of all the security issues that have surfaced in the past few years, none has had as significant an impact as the Log4j exploit. Nicknamed Log4Shell, it was reported to the developers, the Apache Software Foundation, on November 24th 2021 by Chinese tech company Alibaba and a fix was released two weeks later.

The existence of the Log4j exploit was first publicly announced by Chen Zhaojun, a cyber security researcher with the Alibaba Cloud Security team on December 9. 2021 and formally announced by the U.S. Some vulnerabilities are more important and serious than others which is why we have developed a system to rank them. The latest vulnerability has been assigned the highest CVSS score and has been found in Apache Software Foundation. The CVE-2021-44832 identifier, allocated in December 2021, will be followed up with a more detailed distribution of CVE-2021 later on.

A new vulnerability found in Apache Log4j would allow cyber attackers to execute their own code during remote RCE attacks. An RCE is a vulnerability that could enable an attacker to control a computer remotely and give them full access. It usually only takes one step for this to happen. The Log4Shell vulnerability was particularly easy for attackers, because it required very little work.

What is Log4j?

Log4j is a great utility tool to have, especially for modern applications. It can track and log important events such as errors and alerts with detailed information. The Apache Software Foundation, a leading member of the Open Source Movement, has developed Log4j as part of its contribution to the greater software community. This FOSS is written in Java and is free to use. After launching on 8 January 2001, this type of software quickly grew in popularity due to its light-weight and easy to use features.

How Does the Log4j Vulnerability Work?

The Log4j vulnerability has been caused by the Java Naming and Directory Interface (JNDI) which allows additional Java objects from remote naming services during runtime execution. Security vulnerabilities were identified in Apache Log4j2 in versions 2.0-beta9 through 2.15.0, but not in the latest stable release (2.17.0)

Cyber-threat actors use specially crafted HTTP/HTTPS requests to log an event to create a user-agent string for the attack, for example: GET /subdir HTTP/1.1 Host: company.com

Some luck can help attackers. In this case, the server passed the user’s agent string to Log4j, which interpreted it and queried a LDAP server. One of the major problems with vulnerable versions of Log4j system response is a lack of verification and ‘cleaning’ process on input received. An LDAP server controlled by an attacker, sends back directory info containing the malicious java object to update the config files followed by execution in admin mode. The data is sent to the server and executed, which compromises the system.

How Bad is the Log4j Exploit?

One of the most serious security flaws found on the internet has just been discovered. If you are using any Cloudflare, iCloud, or Minecraft: Java Edition products, it is advisable to change your password and be mindful of any security breaches.

Cloudflare’s CEO, Matthew Prince, tweeted on December 11th, “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.” He also reports that a lean evidence of malware exists in Cloudflare logs for more than.

After we made the Log4Shell issue public, cyber criminals swung into action. To my knowledge, there were no recorded threats or exploits before the public disclosure. Nine days after disclosing the vulnerability, we published an article on our blog to clarify that, as of 19th December there were 17,000 packages affected, that is 4% of the entire ecosystem. 25% of these packages have already been fixed. As pointed out in the Google article, this was just the start with 25% and that “more will undoubtedly come as we continue to examine our dependency tree” As you can see in the graph below, a popular Java package called struts2 was vulnerable since hundreds of other packages depended on it.

XKCD – Courtesy of Randall Munroe Licensed under a Creative Commons Attribution-NonCommercial 2.5 License

In the recent blog post, Google explained that “Over 80% of vulnerabilities are more than one level deep.” Up to 40-50% of these vulnerabilities can affect all applications up to 9 levels below. Major bugs are fixed with support packages and they tend to be released in order from lowest impact to the highest.

The popularity of Log4j grew enormously over a short period of time and there are many reasons for this. For one, it’s a good library with a clean & well-maintained codebase. Another reason is that many products use Log4j and it has indeed affected hundreds of millions of users. A recent article in The Guardian details that this vulnerability is a major threat to organizations around the world and noted it may be the worst computer vulnerability discovered in years. They were correct.

In December 2021, Tenable’s Deputy CTO said of the Log4Shell security vulnerability, “It is among the most significant vulnerabilities in decades.” Ransomware is quickly becoming an issue that many people are concerned about. It is one of the fastest growing types of malware out there and it has the capability to damage every type of device in your home. From heavy industrial equipment, to network servers, down to just plain old printers, and even your kid’s Raspberry Pi…it can affect them all. Some systems may be on-premises while others may be hosted in the cloud. It doesn’t matter where they’re located, the flaw is going to affect them and cybercriminals are already looking forward to getting their hands on them. There’s been some ransomware activity popping up, but we’re not even close to seeing any major disruptions. It wouldn’t surprise me if you end up running into it within the next few weeks, as there’s already been some instances within the last few days.

All Log4Shell libraries should be checked for vulnerabilities and other implementations should never be based on it. The complexity of it makes maintenance 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 made public, other cyber-criminals immediately began exploiting it. For example, state-sponsored Iranian hacking group Charming Kitten (better known as APT35) launched multiple attacks against Israeli government and business sites after exploiting the Log4j bug on December 15, 2021.

Attacks targeting the Log4Shell vulnerability can be used to make a specific website go down, but the most dangerous way it’s being used is for botnets to automatically scan for other vulnerable websites. With millions of outdated websites still using Log4j, it is rife for hackers.

As of December 2021, security researchers found Mirai botnets – groups of malware-infected computers often used in denial-of-service attacks – gaining control over IoT devices by exploiting the Log4j vulnerability. Devices include cameras, TVs, switches and routers. As soon as the flaws were found, hackers created two new exploits for it. Elknot and Gafgyt are also taking advantage of the Log4j exploit.

“B1txor20” is a new vulnerability in the Log4j framework that was uncovered by Qihoo Security Labs and could exploit the security flaws. Malware- which deploys backdoors, SOCKS5 proxy, malware downloading, data theft, arbitrary command execution and rootkit installing functionality- has been identified as targeting Linux ARM and X64 CPU architecture devices from as early as March 2022. The Log4j exploit is being used by the malware to spread and connect back to servers in order to exfiltrate data. B1txor20 is a relatively new software that has some design flaws, which the cyber threat actors are likely to fix in future versions.

How to Prevent Log4j Exploits

Here are four ways to prevent a Log4j exploit that is targeting highly vulnerable systems.

• A possible solution is to upgrade or disable Log4j libraries. As noted earlier, this can cause a lot of time and has the risk of downtime for your enterprise-scale application.
• Ensure your business is protected with a web application firewall (WAF) to prevent unauthorized access. JNDI requests from unknown IP addresses can be blocked by a WAF and will keep your business safe.
• Disable Jakarta’s lookup service.
• Disable remote Java objects loading