Table of Contents[Hide][Show]
Log4Shell, an internet vulnerability, recently affected millions of machines. Log4j, an obscure yet almost ubiquitous piece of software, causes it.
Log4j is used to log all of the actions that occur behind the scenes in a variety of computer systems.
It is based on an open-source logging library that is used by businesses and even government organizations in most applications.
Being one of the worst cyber security holes ever uncovered, it is critical to protect your systems from this vulnerability. But, how?
Let’s explore Log4j vulnerability in detail and all possible fix solutions for it.
What is Log4j?
Log4j is an open-source logging framework that enables software developers to record different data within their applications. It is a component of the Apache Logging Services project, which is run by the Apache Software Foundation.
Hundreds of websites and apps use Log4j to perform critical operations such as logging data for debugging and other uses.
When you input or click on a poor online link and get a 404 error notice, this is a frequent example of Log4j at work. The web server that runs the domain of the web link you tried to access informs you that no such webpage exists. It also logs the event in Log4j for the server’s system administrators.
Throughout software programs, similar diagnostic signals are employed. In the online game Minecraft, for example, the server uses Log4j to log activity such as total RAM used and user instructions sent into the console.
How does the vulnerability occur?
Lookups are a new feature introduced in Log4j 2.0, which helps to incorporate additional information in log entries. One of these lookups is the JNDI (Java Naming and Directory Interface) lookup, which is a Java API for communicating with a directory service.
Using this approach, internal user IDs can be mapped to actual user names. This query exposes the newly discovered RCE vulnerability, since one of the data types supplied by the LDAP server is a URI pointing to a Java class, which is then loaded into memory and run by the Log4j instance.
Due to a weakness in the Log4j library’s input validation, it is possible to inject an arbitrary LDAP server from an untrusted source. Because developers assume that data sent to logs will be handled as plain text, no extra input validation is undertaken, and dangerous user input enters the logs.
A log statement might look like this:
A malicious user would now insert a JNDI lookup referring to a rogue LDAP server in a URL parameter. The JNDI lookup would be as follows:
The Log4j library then talks with this LDAP server at attacker.com to get directory information, including values for the Java Factory and Java Codebase.
These two values include the attacker’s Java class, which is then loaded into memory and executed by the Log4j instance, completing the code execution.
Who is at risk?
The Log4j vulnerability is incredibly broad, affecting business applications, embedded devices, and their subsystems. Affected apps include Cisco Webex, Minecraft, and FileZilla FTP.
However, this is by no means an entire list. The flaw even impacts the Ingenuity Mars 2020 chopper mission, which uses Apache Log4j for event recording.
The security community has compiled a list of vulnerable systems. It’s crucial to note that these lists are continuously updating, so if a certain program or system isn’t featured, don’t assume it’s not affected.
Exposure to this vulnerability is quite likely, and even if a specific tech stack does not apply Java, security executives should expect critical supplier systems, SaaS suppliers, cloud hosting providers, and web server providers to do so.
How to check for Log4j vulnerability?
The first step is to determine whether an assault has already occurred. You can do so by checking the system logs for RCE payload fragments.
If a search for terms like “jndi”, “ldap”, or “$::” yields any logs, security researchers should explore further to see if it was a legitimate attack or merely fingerprinting.
Many assaults in the wild were discovered that did not deliver any harmful payloads. Nonetheless, they were carried out by security experts to determine how many apps were vulnerable to this attack.
The next step is to use the Log4j library to identify all projects. If versions between 2.0-beta9 and 2.14.1 are used, the project can be susceptible.
Given the difficulty in determining where this vulnerability exists, it can be preferable to presume the project is susceptible and that updating the library is the best course of action to remove the danger of code execution.
The project is not vulnerable if the used version is less than 2.0-beta 9, although the Log4j library should still be upgraded because versions in the 1.x range are old and no longer get updates.
Whether a susceptible project is discovered, it is advised that it be checked to see if any information logged using Log4j contains information that the user can change. URLs, request parameters, headers, and cookies are examples of this data. If one of these is logged, the project is in jeopardy.
This knowledge can help you in delving further into the system logs and determining whether your web application has already been attacked.
There are free online tools that can detect if a web application is vulnerable. One of these programs is Log4Shell huntress. It is open-source and available on GitHub.
If a vulnerable area of code in the online application is discovered, the payload provided by the disclosed tool can be used to inject it into the web application. The testing tool would reveal the connections made between your web application and their LDAP server if the vulnerability was exploited.
Solutions to fix Log4j vulnerability
The first step is to update Log4j, which you can do by using the normal package managers or by downloading it directly from this page.
It is also possible to decrease the vulnerability’s exploitability by setting the environment variable FORMAT MSG NO LOOKUPS to true. This countermeasure, however, is only applicable to Log4j versions greater than or equal to 2.10.
Let us now consider alternative options.
1. Workarounds for Log4j version 2.17.0
It is definitely strongly advised to use Log4j version 2.15.0 to protect against Log4Shell, however, if this is not possible, other solutions are available.
Versions 2.7.0 and later of Log4j: It is feasible to protect against any attack by changing the format of the events to be logged using the percent m nolookups syntax for the data supplied by the user. This update requires editing the Log4j configuration file to generate a new version of the program. As a result, before deploying this new version, the technical and functional validation stages must be repeated.
Log4j versions 2.10.0 and later: It is also possible to protect against any attack by setting the log4j2.formatMsgNoLookups configuration parameter to true, for example, when starting the Java virtual machine with the -Dlog4j2 option.” formatMsgNoLookups = true, Another option is to remove the JndiLookup class from the classpath argument, which will remove the main attack vector (the researchers do not rule out the possibility of another attack vector).
Amazon Web Services provides a hotpatch that is “should be utilized at your own risk.” Other “techniques,” such as Logout4Shell, which “uses this vulnerability against itself,” have been published. The security expert questions the legality of this move, which involves “hacking a machine to fix it.”
2. The problem has been resolved in Log4j v2.17.0.
For versions greater than 2.10: Log4j2.formatMsgNoLookups should be set to true.
For versions 2.0 through 2.10.0: Run the following command to remove the LDAP class from Log4j.
Log4j2.formatMsgNoLookups should be set to true in the system settings.
Mitigation in JVM
Mitigation with JVM parameters is no longer an option. Other mitigating methods continue to be successful. Upgrade to Log4j version 2.17.0 if possible. There is a migration guide available for Log4j v1.
If an update is not possible, make sure that the client-side and server-side components have the -Dlog4j2.formatMsgNoLookups = true system property set.
Please note that Log4j v1 has reached its end of life (EOL) and will no longer receive bug fixes. Other RCE vectors are also susceptible to Log4j v1. Hence, we urge that you upgrade to Log4j 2.17.0 as soon as possible.
3. Mitigation measures
Current exploits can not work even if Log4j is susceptible in some instances, such as if the host machine is running a Java version higher than 6u212, 7u202, 8u192, or 11.0.2.
This is due to better Java Naming and Directory Interface (JNDI) remote class loading protection in current versions, which is necessary for the attack to operate.
Furthermore, with Log4j versions larger than 2.10, the issue can be avoided by setting the formatMsgNoLookups system value to true, providing the JVM argument -Dlog4j2.formatMsgNoLookups = true, or deleting the JndiLookup class from the classpath.
In the meantime, until the vulnerable instances are fixed, the vulnerability can be addressed using the techniques below:
- Set the system property log4j2.formatMsgNoLookups to true for >=2.10.
- Set the environment option LOG4J FORMAT MSG NO LOOKUPS to true for >=2.10.
- Remove JndiLookup.class from the classpath for 2.0-beta9 to 2.10.0: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
One recommended best practice is to limit egress traffic to the internet to only the appropriate ports.
Though most attacks in the field are delivered over HTTP, the vulnerability might be exploited via any protocol that logs user input data using Log4j.
However, updating to log4j 2.17.0 is the best remedy because someone can discover an additional approach to the issue. Furthermore, a lot of publishers and manufacturers have announced improvements to their services or apps.
4. Log4Shell vulnerability patch
Log4j is omnipresent, especially now that the vulnerability is being exploited. To summarize, all you need to do is include the following characters in the logs inspected by Log4j.
And this will download and execute the Java file located at the end of the URL. It’s as straightforward as it is dramatic.
As you are aware, it is critical to upgrade log4j to version >= 2.17.0 to remedy this Log4Shell vulnerability (CVE-2021-44228).
If this isn’t possible:
For applications that use Log4j library versions 2.10.0 and later, it is also possible to protect against any attack by setting the configuration parameter log4j2.formatMsgNoLookups to true, for example, while starting the Java virtual machine with the -Dlog4j2.formatMsgNoLookups = true option.
Another option is to delete the JndiLookup class from the classpath argument, which will remove the primary attack vector (the researchers do not rule out the existence of another attack vector).
Note
Organizations who are hesitant or unwilling to make adjustments to susceptible systems (or who are but wish to install extra safeguards) should think about:
- Make sure that all traffic is routed through an iSensor/WAF/IPS. This can keep the assault from gaining access to the system.
- Limiting the amount of traffic that can reach the susceptible system If the system does not need to be connected to the internet, restrict access to just essential and trustworthy IPS and ranges.
- Reducing the host’s authorized outgoing traffic. Because this attack operates by connecting to a rogue server, all superfluous IP addresses and ports should be blocked on a firewall.
- If the service is no longer required, it should be disabled until a fix is ready.
Conclusion
The Log4j flaws shocked our community and reminded us all how reliant we are on open-source software.
Log4j is unique. It is neither an operating system, nor is it a browser, nor is it a software. Rather, it’s what programmers refer to as a library, a package, or a code module. It just serves one purpose, that is, keeping a record of what happens on a server.
People who write code prefer to concentrate on what makes their software distinctive. They are not interested in reinventing the wheel. As a result, they rely on a plethora of existing code libraries, such as Log4j.
The Log4j module is derived from Apache, the most extensively used web server software. That is why it can be discovered on millions of servers. Hence, increasing the security threats.
I hope the above solutions help you keep your devices safe.
Stay tuned to HashDork for more helpful information from the tech world.
Leave a Reply