Log4j Vulnerability - All that You Must Know About it
About Log4j and How 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 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.
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.
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.
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.
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.