Arun ShankarA vulnerability impacting Log4j versions 2.0 through 2.14.1 was disclosed on the project’s GitHub on December 9, 2021. The flaw has been dubbed Log4Shell and has the highest possible severity rating of 10. Log4j is an open-source Java logging library that is widely used in a range of software applications and services around the world. The vulnerability can allow threat actors to take control of any Java-based, internet-facing server and engage in remote code execution attacks.
Most login screens in the world typically audit failed login attempts, meaning that virtually every authenticated page using Log4j is vulnerable. Browser search bars are also often logged and expose systems to this flaw. Exploiting the flaw is fairly trivial. An attacker can exploit the vulnerability by simply sending a malicious code string that gets logged by Log4j. At that point, the exploit will allow the attacker to load arbitrary Java code and take control of the server.
Log4j is an open-source Java logging library that is widely used in a range of software applications
This is the single biggest vulnerability in the history of modern computing
The Log4j Remote Code Execution Vulnerability is the single biggest, most critical vulnerability of the last decade. When all of the research is done, we may in fact learn that it is the single biggest vulnerability in the history of modern computing.
This kind of vulnerability is a reminder that organisations must develop mature cybersecurity programmes to understand cyber risk in a dynamic world. We encourage organisations to update their security controls, assume they have been compromised and activate existing incident response plans. The number one priority now is to work with your in-house information security and engineering teams or partner with an organisation that conducts incident response to identify the impact to your organisation.
CISA’s vulnerability guidance on Apache Log4j
US based Cybersecurity and Infrastructure Security Agency, CISA and its partners, through the Joint Cyber Défense Collaborative, are responding to active, widespread exploitation of a critical remote code execution vulnerability in Apache’s Log4j software library, versions 2.0-beta9 to 2.14.1, known as Log4Shell and Logjam.
Log4j is very broadly used in a variety of consumer and enterprise services, websites, and applications—as well as in operational technology products—to log security and performance information. An unauthenticated remote actor could exploit this vulnerability to take control of an affected system.
Apache released Log4j version 2.15.0 in a security update to address this vulnerability. However, in order for the vulnerability to be remediated in products and services that use affected versions of Log4j, the maintainers of those products and services must implement this security update.
Users of such products and services should refer to the vendors of these products, services for security updates. Given the severity of the vulnerability and the likelihood of an increase in exploitation by sophisticated cyber threat actors, CISA urges vendors and users to take the following actions.
This RCE vulnerability—affecting Apache’s Log4j library, exists in the action the Java Naming and Directory Interface takes to resolve variables. Affected versions of Log4j contain JNDI features—such as message lookup substitution—that do not protect against adversary-controlled Lightweight Directory Access Protocol, LDAP and other JNDI related endpoints.
An adversary can exploit this vulnerability by submitting a specially crafted request to a vulnerable system that causes that system to execute arbitrary code. The request allows the adversary to take full control over the system. The adversary can then steal information, launch ransomware, or conduct other malicious activity.
Call to action
- For vendors, immediately identify, mitigate, and patch affected products using Log4j.
- Inform your end users of products that contain this vulnerability and strongly urge them to prioritise software updates.
In addition to the immediate actions, enterprises need to action the following:
- Enumerate external-facing devices that have Log4j.
- Ensure your SOC actions alerts on these devices.
- Install a WAF with rules that automatically update
- Review CISA’s upcoming GitHub repository for a list of affected vendor information and apply software updates as soon as they are available
- Review Apache’s Log4j Security Vulnerabilities page for additional information.
- Apply available patches immediately. Prioritise patching, starting with mission critical systems, internet-facing systems, and networked servers. Then prioritise patching other affected information technology and operational technology assets.
- Until patches are applied, set log4j2.formatMsgNoLookups to true by adding -Dlog4j2.formatMsgNoLookups=True to the Java Virtual Machine command for starting your application. This may impact the behaviour of a system’s logging if it relies on Lookups for message formatting. Additionally, this mitigation will only work for versions 2.10 and above.
- Conduct a security review to determine if there is a security concern or compromise. The log files for any services using affected Log4j versions will contain user-controlled strings. Consider reporting compromises immediately to CISA and the FBI.
Checking for vulnerability and risks from unsuccessful remediation
The first thing to check is whether any version of log4j prior to 2.15.0 is being used, including from dependencies. Maven and Gradle both have ways to print the entire dependency tree for a project, which will allow for determining whether or not a vulnerable version of log4j is being used. Even with version 2.15.0 or greater, it should also be verified that the format MsgNoLookups system property is not set to true since this version is only not vulnerable because it set the default value of this from true to false.
In some versions of log4j, this property can simply be set to false manually to mitigate the vulnerability. If the application does not require LDAP as part of its legitimate usage, it is also possible to block all LDAP traffic with a Firewall or Web Application Filter to prevent remote code from being reached should the vulnerability be exploited.
These, however, only check whether or not log4j is capable of utilising this RCE vulnerability. Whether or not a system is truly vulnerable to an attack is a much more complicated issue without a single test the likes of which vulnerabilities like HeartBleed had. In order to exploit this vulnerability, an attacker would need to perform a log injection attack.
Finding these is a much more complex process, but essentially anywhere that input from a user or potential attacker is logged may be vulnerable to this exploit. Thus, testing for an actual RCE would require trying to find a way to make a JNDI LDAP request within the logs from the user context itself, example through the web site or API if the potentially affected application is a web application.
Since this vulnerability allows for Remote Code Execution, the risks are pretty high in the event that a vulnerability exists. An attacker could potentially gain a foothold into the network and from there try to access critical resources and data.
Being a very popular open-source library, the occurrences of vulnerable applications was certainly higher as a result. In general, any software can be vulnerable to attacks and often popular open-source software will have a large ecosystem looking for and patching security threats. Thus, while open-source software gains the majority of the headlines when major security flaws are found, this does not mean that it is proportionately less secure and in fact is more likely much more secure than propriety code or less popular libraries.
Widespread use simply increases the likelihood that vulnerabilities will be found, not necessarily the likelihood that they will exist.
When looking for open-source libraries, organisations should seek out large, reputable, well-maintained projects like log4j for the reasons listed above. Obviously, vulnerabilities may still exist, but the community is more likely to find and patch these vulnerabilities, as well as check that code seems free of bugs that could create vulnerabilities in the first place, than with smaller projects.
Even for those with applications not vulnerable to CVE-2021-44228 or not even using log4j for logging, this vulnerability is definitely a wake-up call that log injection is a potential method that attackers might use. It would be worthwhile to check that any user input being logged is properly sanitised in any application, regardless of what logging system or even programming language is being used.
While other forms of injection are much more prevalent and focused on, log injection is still a form of injection attack and thus falls under the OWASP Top 10 vulnerabilities.
Cybereason releases vaccine to prevent exploitation of Apache Log4Shell vulnerability
Cybereason researchers have developed and released a vaccine for the Log4Shell vulnerability. The vaccine is now freely available on GitHub. It is a relatively simple fix that requires only basic Java skills to implement and is freely available to any organisation. Cybereason previously announced that none of the company’s products or services were impacted by the vulnerability.
We recommend patching affected systems as soon as possible. For systems that cannot be updated or at least not updated immediately, Cybereason researchers have discovered a way to disable the vulnerability. Logout4Shell is a vaccine to protect against exploits targeting the Log4Shell flaw.
You can permanently close the vulnerability by causing the server to save a configuration file, but that is a more difficult proposition. The simplest solution is to set up a server that will download and then run a class that changes the server’s configuration to not load things anymore.
Organisations and security professionals are scrambling to update Log4j to patch the bug, while attackers are actively scanning the Internet for affected systems. There are already tools developed to automatically attempt to exploit the bug.
You should still update your Apache systems to permanently remediate the vulnerability, but patching takes time, and some systems may not be able to be updated immediately—or at all. The recommended guidance is to upgrade as soon as possible to Apache log4j-2.1.50.rc2. All prior 2.x versions are vulnerable.
This fix will disable the vulnerability and allow you to remain protected while you assess and update your servers.
Applications and downstream behaviours must be monitored at all times
On the heels of the log4j vulnerability, security practitioners were reminded how severely a RCE vulnerability can devastate an enterprise. Even more so, a vulnerability found in third-party software that an enterprise does not control leaves their security practitioners unable to properly secure their environments.
A recent CVE from Microsoft regarding their iSNS server is another example of a RCE vulnerability found in third-party software. This vulnerability allows a user with a specially crafted input to execute arbitrary code on the host. The seemingly endless number of vulnerabilities found is a tell-tale sign that software will never be perfect, but with adequate runtime protection and application controls can be safeguarded against itself to ensure it never behaves outside of its intended limits.
Successful RCE vulnerabilities rely not only on the vulnerability to gain access, but also on available downstream actions to carry out an attack – the log4j and iSNS vulnerability are the exact same way. Applications and their downstream behaviours must be monitored at all times to ensure it does not break from its expected execution.
The impact ranges from very bad to slightly less bad
Nicholas Luedtke, Principal Analyst, Mandiant.
Log4j is a library that is built into the logging functionality of a very large part of the Internet. It is embedded and used by a ton of software that run websites, clouds, security services, games. Because logs are important for security, debugging, and audit trails, it is very common for some part of user-controlled data to go directly into log files.
Those two aspects coupled by the trivial nature of exploitation of this vulnerability make it very serious.
Attackers only need to find a vector by which they can cause a crafted string to be inserted into a logfile of a vulnerable system. Once they have achieved that, the impacts to an enterprise can be wide. Obviously, they could gain a foothold on the victim’s network; that foothold may be privileged if the product that was compromised was an administrative or security component.
They can also leak environment variables from the compromised systems which can lead credentials being leaked if they are stored in an environment variable. Additionally, because of the embedded nature of this library into other software, as a consumer, it is very difficult to tell what products you have in your environment that might be using it. If you cannot do that first task quickly or completely, mitigation becomes very difficult.
The impacts from this one varies on what system is doing the logging and what permissions that system has, but they range from very bad to slightly less bad.
We have seen Chinese and Iranian state actors leveraging this vulnerability, and we anticipate other state actors are doing so as well or preparing to. We believe these actors will work quickly to create footholds in desirable networks for follow on activity which may last for some time. In some cases, they will work from a wish list of targets that existed long before this vulnerability was public knowledge. In other cases, desirable targets may be selected after broad targeting.
The Iranian actors who we have associated with this vulnerability are particularly aggressive, having taken part in ransomware operations that may be primarily carried out for disruptive purposes rather than financial gain. They are also tied to more traditional cyber espionage.
This is not a problem with Apache, the Apache Software Foundation maintains log4j2
On December 9th, LunaSec published a blog post with details regarding a vulnerability in the log4j2 library. This vulnerability became quickly known as log4shell, and CVE-2021-44228 was assigned to it.
Let us start with a couple of FAQs:
- This is not a problem with Apache. The Apache Software Foundation maintains log4j2. They do a lot of great stuff, not just the webserver. Log4j is not part of the Apache webserver.
- Not all software using Java is vulnerable. Only software that includes the log4j2 library is vulnerable.
- Any string that is logged via log4j2 could potentially be used to exploit this vulnerability.
The most immediate priority for defenders is to reduce exposure by patching and mitigating all corners of their infrastructure
With the exception of crypto mining, there is a lull before the storm in terms of more nefarious activity from the Log4Shell vulnerability. We expect adversaries are likely grabbing as much access to whatever they can get right now with the view to monetize and capitalize on it later on.
The most immediate priority for defenders is to reduce exposure by patching and mitigating all corners of their infrastructure and investigate exposed and potentially compromised systems. This vulnerability can be everywhere.
Where systems have been identified as vulnerable, defenders should run an incident response process and monitor for signs of remote access trojans such as C2 call-backs. Secrets stored on exposed systems should also be rotated, particularly if they are exposed in environment variables. Lastly, consider critical third-party vendors who may also be at risk.
- Sophos is seeing a rapid uptick in attacks exploiting or attempting to exploit this vulnerability, with hundreds of thousands of attempts detected so far.
- Crypto mining botnets are among the earliest attack adopters; botnets focus on Linux server platforms, which are particularly exposed to this vulnerability.
- Sophos has also seen attempts to extract information from services, including Amazon Web Services keys and other private data.
- Sophos observed that attempts to exploit network services start by probing for different types. Around 90% of the probes Sophos detected were focused on the Lightweight Directory Access Protocol.
- A smaller number of probes targeted Java’s Remote Interface, but Sophos researchers noted that there seem to be a larger variety of unique RMI-related attempts.
- Sophos expects adversaries to intensify and diversify their attack methods and motivations in the coming days and weeks, including the possibility of leveraging for ransomware.
