Office of Information Security

December 10, 2021

Apache Log4j: Patch NOW

Latest update and latest info about Log4j patch

Updated 01/07/2022

What’s Log4j?

Log4j is a logging feature embedded in many applications, frequently unbenownst to users and system administrators. It is widely used in a variety of services, websites, and applications to log security and performance information.

  • On 12/29, Apache released a new patch version, 2.17.1, and updated their security advisory to recommend updating Log4j to this version.
  • This is an evolving situation; please check this page frequently for updates.
  • The Office of Information Security received one report of a UW system that was compromised.
  • The OIS Quick Steps section will be continually updated with UW Office of Information Security recommendations.
  • An executive overview, recommendations, and helpful diagram can be found on the Center for Internet Security website.

Additional technical updates about versions, patches, and affected vendors:

  • Vulnerabilities were discovered and mitigated in Log4j version 2.15.0, the first patch attempt, and later. The most severe, CVE-2021-44832, which allows an attacker to execute commands on the system, was disclosed on 12/29/2021 affecting versions 2.0-beta7 through 2.17.0 except for 2.3.2 and 2.12.4.
  • No currently known vulnerabilities exist in versions 2.17.1 for Java 8 and later environments, 2.12.4 for Java 7, and 2.3.2 for Java 6, the latest releases.
  • Log4j version 1.x is not vulnerable to CVE-2021-44228 and subsequent vulnerabilities. However, in certain non-standard configurations it is vulnerable to exploits including CVE-2021-4104. Version 1.x reached end of support in August 2015 and may be vulnerable to other undisclosed exploits. Therefore, it is recommended that you update to the most current version or inquire to your vendors regarding their update plans.
  • The U.S. Cybersecurity and Infrastructure Security Agency maintains an extensive list of roughly 685 vendors and products that indicates whether a product is affected, a link to the vendor advisory, and update status. As of 1/4/2022, 529 of the 2,823 listed products are affected by the vulnerability; 38 are listed as unknown. https://github.com/cisagov/log4j-affected-db/blob/develop/SOFTWARE-LIST.md

Recommendations for everyone in the UW Community

The vulnerabilities described on this page are actively being exploited by cybercriminals and could lead to ransomware, data theft, and other malicious attacks. This is widely considered one of the most serious cyber vulnerability stories in a decade. Because of the ubiquity of Log4j and the fact that it is embedded in so many applications, the vulnerabilities could impact systems for many years to come. There are things you can do to protect UW data and systems from threats associated with Log4j and other vulnerabilities.

UW students, faculty, and staff are encouraged to:

  1. Keep computers, devices, and applications updated and patched.
  2. Stay aware that adversaries will try to exploit the vulnerability through phishing campaigns.
  3. Run antivirus software, keep it updated, and ensure it is running. Sophos antivirus software is free for the UW community, including on personal computers, and may be downloaded here.
  4. Review the summary info on this page, keep it bookmarked, and check back for updates.


Recommendations for specific groups

End users

  • Check affected vendor and product lists, both the vendor security or support webpages and the third party lists.
  • Wherever possible, ensure that automatic updates are turned on for all products.
  • Update affected products as soon as patches are released, or implement any recommended workarounds until a patch is released.

System administrators, resource and service owners

  • Identify services that use any version of Log4j. The CISA scanning tool and the command line tool may be useful, as well as the list of affected products.
  • Prioritize updating or implementing recommended workarounds for apps that use affected versions of 2.x to the latest supported version for a given Java release.
  • For applications that use version 1.x, if a vulnerable configuration isn’t being used then the situation is not urgent, but it is a bad security practice to rely on unmaintained libraries, so it is advisable to check with vendors or developers about their plans to update.

Developers

  • Identify apps that use any version of Log4j. The command line tool may be useful.
  • Prioritize updating apps that use affected versions of 2.x to the latest supported version for a given Java release.
  • For version 1.x:
    •  Known vulnerable configurations make use of any of:
      – SocketServer
      – SocketAppender
      – JMSAppender
      – SMTPAppender
    • If you are making use of any of these components, then prioritize upgrading or migrating your logging library.
    • If these components aren’t being used, then the situation is not urgent, but it is a bad security practice to rely on unmaintained libraries, so do plan to migrate to a supported library in the near future.
    • Information on mitigation for the known vulnerabilities in Log4j 1.x (which are all for non-default configurations) may be found on this blog post: Log4j 1.x Vulnerability Mitigation Guide.

Log4j Vulnerability Summary

In December, the Apache Software Foundation released security advisories about vulnerabilities affecting Apache Log4j. Log4j is not related to the Apache web server product; it is a ubiquitous logging library that records errors and routine system operations and communicates diagnostic messages to system administrators and users.

One reason for the high severity rating is that servers and applications are vulnerable to remote code execution (RCE). RCE is a cyberattack in which an adversary can remotely execute commands on someone else’s computer or device, including complete system take over.

Because Log4j is included in various popular web development frameworks, the vulnerability affects millions of Java applications from many different vendors. One source lists 1,024 affected products from roughly 157 vendors/product lines.

These vulnerabilities are actively being exploited by cybercriminals and could lead to ransomware, data theft, and other malicious attacks. This is widely considered one of the most serious cyber vulnerability stories in a decade. Because of the ubiquity of Log4j and the fact that it is embedded in so many applications, the vulnerabilities could impact systems for many years to come.

Technical details

Apache Log4j is a ubiquitous logging library included in popular web development frameworks including Apache Struts2, Apache Solr, Apache Druid and Apache Flink, as well as just about every application that uses Java. Log4j is used in many third-party apps including Redis, ElasticSearch, LogStash, and vCenter, affecting large internet service providers such as Steam and Apple iCloud. All are now known to be vulnerable to a new remote code execution vulnerability, designated as CVE-2021-44228, that is under active exploitation. The vulnerability is trivial to remotely exploit and requires submitting a string into the victim program that is then parsed and executed by the Log4j logging library, allowing an attacker to execute commands on the system.

Proof-of-concept exploits were released on the same day this vulnerability was disclosed and exploitation attempts have already been observed across the internet. The ubiquity and severity of this vulnerability will make it a high priority for attackers to exploit in the coming days.

Affected Versions and Patches

This is a list of affected versions of Log4j. The list of affected applications which use Log4j is much longer.

  • The vulnerability affects all versions of Log4j from version 2.0-beta9 to 2.17.0.
  • Log4j version 1.x is also vulnerable to this issue when configured to use the JMS Appender class. Note that by default, and in most configurations, that appender is not used.
  • Log4j version 1.x is no longer supported, is subject to multiple other vulnerabilities and it would be advisable to  upgrade to a logging library that is actively maintained.
  • December 7th: Apache released a patch addressing the vulnerability, version 2.15.0.
  • December 13th: Apache released Log4j version 2.16.0, to address an incomplete fix for CVE-2021-44228 in certain non-default configurations.
  • December 17th: Apache released Log4j version 2.17.0 to address a different vulnerability, CVE-2021-45105, that could result in a denial-of-service condition.
  • While applying the latest patch version is recommended, the patch announcement also includes mitigation steps for those unable to upgrade to version 2.17.1 immediately.

OIS Quick Steps

  • Members of the UW community with an active NetID can download Sophos Anti-Virus (AV) from UWare. Currently, Sophos AV scans for at least 19 malicious payloads being delivered via Log4j exploits. Sophos continually updates its malware signature base and its endpoint application can scan devices for signs of malware infection. UW students, faculty, and staff are encouraged to use this free application if they do not currently scan computers and devices for malware.
  • Review Apache’s Log4j Security Vulnerabilities page for additional information.
  • Unless you develop or administer a web application, you probably don’t need to take any action at this time. Some user-facing software may be subject to this vulnerability in which case you should apply software updates as soon as they are available from the developer. The breadth of impact of this vulnerability is not yet fully known; many applications could be impacted and require updates.
  • If you develop or administer a web application that uses Log4j, please update the library or apply mitigations as soon as possible.
  • If you administer a third-party application that relies on Log4j, follow the developer’s recommendations for updating the software or applying mitigations.
  • System administrators may be able to check if an application URL is vulnerable using a proof-of-concept script. System administrators may also search their application logs for strings that indicate exploit attempts. If a system is vulnerable and has received exploit attempts, those attempts must be investigated to determine if they successfully led to compromise.
  • Firewall users should block outbound LDAP on the Internet-facing interface. LDAP is a local network protocol that should not be used over the internet.
  • 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. If you observe signs of compromise on a device or host that contains personally identifiable information (PII) or any other form of UW Confidential, Restricted, or other protected data types, do not try to do your own forensics. Contact our office at ciso@uw.edu. Read more on our Report an Incident  page.

Tools for detection

  • A command line tool scans projects to find vulnerable Log4j versions containing the vulnerabilities identified in the CVEs. The tool works with three package managers: gradle, maven, bundler; searchers .jar and .gem files. Supports Linux, macOS and Windows.

https://github.com/whitesource/log4j-detect-distribution/

  • CISA released a tool to scan for CVE-2021-44228 and CVE-2021-45046 that includes support for lists of URLs, fuzzing for more than 60 HTTP request headers, fuzzing POST parameters, and fuzzing for JSON data parameters.

https://github.com/cisagov/log4j-scanner

https://github.com/cisagov/log4j-scanner/tree/master/log4-scanner#features

Joint Cyber Security Advisory Guidance

Detailed steps from the Joint Cybersecurity Advisory on Log4j:

The following highlighted steps are from a joint advisory published by leading information security government agencies around the world. System owners can follow these steps in order to mitigate vulnerabilities and exploitation to Log4j.

  1. Inventory all assets that make use of the Log4j Java library
    • According to public reporting, adversaries are patching and mitigating assets they compromise to retain control of asset.
    • Assume all versions of Java and Log4j are vulnerable and include them in the inventory, including cloud assets.
    • Identify the inventoried assets that are likely vulnerable.
    • Use CISA’s GitHub repository and CERT/CC’s CVE-2021-44228_scanner to identify assets vulnerable to Log4Shell.
  2. Mitigate known and suspected vulnerable assets in your environment.
    • Treat known and suspected vulnerable assets as compromised. These assets should be isolated until they are mitigated and verified.
  3. Patch Log4j and other affected products to the latest version immediately. See CISA’s GitHub repository for known affected products and patch information.
    • Prioritize patching, starting with mission critical systems, internet-facing systems, and networked servers. Then prioritize 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. Note: this may impact the behavior 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.
      • Remove the Jndilookup.class from the class path.
      • Delete or rename Jndilookup.class. Note: removal of the JndiManager will cause the JndiContextSelector and JMSAppender to no longer function.
  4. Keep an inventory of known and suspected vulnerable assets and what is done with them throughout this process.
    • It is important to track patching because malicious cyber actors may compromise an asset and then patch it to protect their operations. System owners should perceive that systems patched without their consent require security reviews for a potential compromise.
  5. Evaluate and apply other mitigations.
    • Remain alert to changes from vendors for the software on the asset, and immediately apply updates to assets.
    • Continue to monitor Log4J assets closely, especially for processes, ports, or activity that were not authored by a system owner.
    • If you manage your own firewall, Block specific outbound Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) network traffic.
      • Outbound LDAP (at a minimum, use allowlist for outbound LDAP to known good destinations)
      • Remote Method Invocation (RMI) (at a minimum, use an allowlist for outbound RMI to known good destinations)
      • Outbound DNS (at a minimum, blocking direct outbound DNS from web application servers configured to use enterprise DNS)
  6. Conduct a security review.

Relevant News

techcrunch: FTC warns of legal action against organizations that fail to patch Log4j flaw

arstechnica: Zero-day in ubiquitous Log4j tool poses a grave threat to the Internet

References

Center for Internet Security: Log4j Zero-Day Vulnerability Response

Microsoft: Guidance for preventing, detecting, and hunting for CVE-2021-44228 Log4j 2 exploitation


CISA and Joint Cybersecurity Advisory:


Sophos:

Randori: CVE-2021-44228 – Log4j 2 Vulnerability Analysis

Apache Logging Services: Apache Log4j 2

 

More Articles