Widely Used Logging Library Vulnerability “Log4Shell” Actively Exploited in the Wild
Widely Used Logging Library Vulnerability “Log4Shell” Actively Exploited in the Wild

The Situation

A recently disclosed critical security vulnerability (CVE-2021-44228) in a logging software, Apache log4j2, is one of the most serious cyber security vulnerabilities in recent years. Apache log4j is widely used in many applications across many organisations.  All organisations must act quickly to identify and contain the risks, detect attack attempts and remediate their systems because it is widely used and easily exploitable.

 

Since the disclosure, the vulnerability has been observed to be under active exploitation by cyber attackers. Many organisations across various sectors are vulnerable because the use of log4j is ubiquitous and the vulnerability is easy to exploit. Financially motivated attackers were among the first to exploit targets, and it is highly anticipated that there will be increased exploitation attempts leading to monetisation activities. This includes data theft and ransomware deployment.

Services and products that leverage on the Apache logging framework are working to put up a fix and are communicating the impact to their customers. At the time of writing, some of the services and applications have been patched or had workarounds implemented to mitigate the vulnerability.

 

Hackers are actively scanning the internet for affected systems, and there are developed tools to automatically attempt to exploit the vulnerability. The original exploit targets the Java Naming and Directory Interface (JNDI) and the Lightweight Directory Access Protocol (LDAP), enabling attackers to load arbitrary Java code on a server, allowing them to take control. Increasingly, many organisations already have been targeted in activity seeking to exploit the Log4j flaw. New variations of the original exploit which was first posted on GitHub are being introduced at a rapid pace.

 

Malware strains, botnet malware, crypto-mining malware, email-based attacks leveraging on the Log4j vulnerability are rampant. There are also reports on the increased usage for the attack exploits in ransomware deployment. The first disclosed ransomware, Khonsari, targets Windows systems. TellYouThePass which was a largely inactive ransomware family, has been revived following the log4j vulnerability discovery. TellYouThePass has versions that run in either Linux or Windows. At the time of writing there has been no public disclosure of a successful ransomware breach that exploited the vulnerability in Log4j.  Log4j exploits attempts were observed to make connections to known malicious Cobalt Strike servers – a popular tool used for malicious hacking, enabling activities such as remote reconnaissance and lateral movement. 

 

Apache attempted to address the vulnerability with the release of log4j 2.15.0 on 10 Dec. However, the fix to address the vulnerability was incomplete in certain non-default configurations. Apache urgently released a patch log4j 2.16.0 https://logging.apache.org/log4j/2.x/changes-report.html#a2.16.0) for the vulnerability by removing support for message lookup patterns and disabling the JNDI functionality by default. With this release, a second disclosed vulnerability of lower severity (CVE-2021-45046 Thread Context Message Pattern and Context Lookup Pattern vulnerable to DOS) was also resolved.

 

On 18 Dec, the version log4j 2.17.0 (Java 8 and later) (https://logging.apache.org/log4j/2.x/changes-report.html#a2.17.0) was rolled out. This version resolved a denial-of-service (DOS) vulnerability (CVE-2021-45105) which could be triggered when a non-default Pattern Layout with a Context Lookup was used in the logging configuration.

 

On 27 Dec, the newest release log4j 2.17.1 (Java 8 and later) (https://logging.apache.org/log4j/2.x/changes-report.html#a2.17.1)  was rolled out. This version resolved a remote code execution (RCE) vulnerability (CVE-2021-44832) rated ‘Moderate’ in severity and had a score of 6.6 on the CVSS scale. The patch addressed the vulnerability by limiting JNDI data source names to the java protocol.

 

Ensign Posture & Monitoring

The vulnerability does not affect Ensign’s infrastructure.

Ensign has stepped up monitoring operations as part of ongoing vigilance and will advise clients of any anomalous cyber activities detected.

 

Our Recommendations

While many vulnerable services and products are still working on putting up a fix, there are some proactive steps you can take:

 

[Identify]

  • The vulnerability (CVE-2021-44228) is highly exploited in the wild, with massive reconnaissance activity. Assess the use and impact of Apache log4j2 library services in your environment and infrastructure as soon as possible. Identify affected assets starting with externally facing servers/applications.

  • If third-party applications are impacted, understand the vendor’s recommended short-term mitigation measures, in addition to the timeframe when a patch or update path will be made available.

  • Keep a lookout for the release of scanning templates that will identify this vulnerability, by leveraging on internal and external vulnerability scanning tools. Scan your environment to ascertain if this vulnerability exists.  Additionally, open-source vulnerability toolsets can also be leveraged to identify vulnerable log4j instances.

  • An opensource Log4j scanner to identify potentially vulnerable web services affected by Log4j was announced by CISA. (https://github.com/cisagov/log4j-scanner)

 

[Contain]

  • Prioritise mitigation activities and patch applications as soon as possible when they are released.

  • Patch the vulnerable log4j library with the release of log4j 2.17.1 (Java 8 and later).

  • For servers which are external-facing and vulnerable, restrict all egress (Internet outbound traffic) to the bare minimum to reduce the risk of RCE. However, the risk of data exfiltration of potentially sensitive configuration info via DNS is still present.

  • Reduce the attack surface of impacted applications and servers by limiting access to the application interfaces that could be leveraged for exploitation.

  • If patching is not immediately possible, mitigate the attack vectors by following the three mitigation routes that Apache has listed (https://www.tenable.com/blog/cve-2021-44228-proof-of-concept-for-critical-apache-log4j-remote-code-execution-vulnerability)

  • Due to the large number of evolving evasion tactics being observed, the integrated signatures that come with many web application firewall and SIEM vendors, as well as the list of potential detection strings available online may not be comprehensive. However, they are indicative of the various patterns that could be leveraged for detection.


[Detect]

  • Enhance visibility to identify attackers exploiting the vulnerability. For exploitation detection and rules, check out the post by Neo23x0 (https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b)

  • To prevent attacks on a network level, and to help detect exploitation of this, Cisco has released Snort rules at the following location: (https://www.snort.org/advisories/talos-rules-2021-12-10)

  • For hunting of the “log4Shell” exploitation:

    • Search for requests containing reference to the JNDI in available logs

    • Hunt for known Indicators of Compromise (IOC) (https://gist.github.com/nathanqthai/01808c569903f41a52e7e7b575caa890)

      If you identify any exploitation on the server, verify that the server was vulnerable to the “log4Shell” vulnerability during the timeframes of the suspicious access attempts. Investigate the identified payload for any malicious activity, e.g., dropped files, encoded commands, Java class loading etc.

  • Check if your systems have signs of compromise from 1 Dec 21 before patching (to 2.15.0):

    • For users that deploy or maintain their Java applications, search for alien .class file within CLASSPATH.

    • Search from 1 Dec 21 for JNDI exploit strings like “jndi:” in
      • log4j log files
      • log4j generated logs entries and files

    • For webserver logs, which are usually stored in folders:
      • /var/log
      • /var/log/apache2
      • /var/log/httpd-access.log

    • Search for the following exploit strings with the different protocols:
      • Lightweight Directory Access Protocol                            jndi:ldap 
      • Secure LDAPS                                                                  jndi:ldaps
      • Remote Method Invocation                                              jdni:rmi
      • Domain Name Service                                                      jndi:dns

    • Search for outgoing LDAP connections to destinations which were not seen before 1 Dec 21. If such connections are found, search the host for the presence of log4j. If there were DNS queries logged, review the queries to check for any possible exfiltration via DNS protocol.

    • The presence of the indicators listed above may be indicative of an attack and may not be comprehensive due to the evolving evasion tactics.

 

[Tactical Remediation]

  • If a compromised log4j instance is identified, a forensic investigation should be conducted, and remediation measures such as removal of any potentially malicious artifacts or backdoors (web shells) should be implemented.

  • Environment variables that contain credentials or keys can be leveraged by an attacker to obtain additional infrastructure (on-premises or cloud-based). If a compromised log4j instance is running on a server where credentials are stored within the environment variable, it is important to rotate and change the passwords / keys that could have been exposed.

 

[Related software and vendor bulletins]

 

Ensign will continue to provide updates on this vulnerability, and keep you informed of any additional recommendations. If you require further assistance, please contact us at marketing@ensigninfosecurity.com.

 

References

https://logging.apache.org/log4j/2.x/security.html

https://www.tenable.com/blog/cve-2021-44228-proof-of-concept-for-critical-apache-log4j-remote-code-execution-vulnerability

https://www.msspalert.com/cybersecurity-news/java-vulnerability-log4shell-zero-day-details-patches-and-updates/

https://www.darkreading.com/vulnerabilities-threats/security-experts-sound-alarm-on-zero-day-in-widely-used-log4j-tool

https://threatpost.com/zero-day-in-ubiquitous-apache-log4j-tool-under-active-attack/176937/

https://threatpost.com/log4j-attacks-state-actors-worm/177088/

https://isc.sans.edu/forums/diary/Log4j+2150+and+previously+suggested+mitigations+may+not+be+enough/28134

https://blog.sygnia.co/log4shell-remote-code-execution-advisory

https://arstechnica.com/information-technology/2021/12/patch-fixing-critical-log4j-0-day-has-its-own-vulnerability-thats-under-exploit

https://www.linkedin.com/posts/invictus-incident-response_cve-2021-44228-activity-6875096631977607168-DT23/

https://www.mandiant.com/resources/log4shell-recommendations

    Contact Us
Copyright © 2024 Ensign InfoSecurity Pte. Ltd.