Apache Log4j (Java) Remote Code Execution 0-Day Flaw, Log4Shell (CVE-2021-44228, CVE-2021-45046, CVE-2021-45105, CVE-2021-44832)

Original Publication: December 13, 2021
Update as of: January 4, 2022 
Current Revision: 1.6
Revision History

CMU RELEVANCE:
Commonly Used

PLATFORMS AFFECTED:
Low Complexity Remote Code Execution & Information Leakage (Urgent):
Any Java-based software/service that incorporates Log4j versions starting from 2.0-beta9 through 2.15.0 (excluding security fix releases 2.3.1, 2.3.2, 2.12.2, 2.12.3, and 2.12.4) 

Denial of Service (Significant):
Any Java-based software/service that incorporates Log4j versions starting from 2.0-beta9 through 2.16.0 (excluding security fix releases 2.3.1, 2.3.2, 2.12.3, and 2.12.4) 

High Complexity/Insider Threat Remote Code Execution (Moderate):
Any Java-based software/service that incorporates Log4j versions starting from 2.0-alpha7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4)

PLATFORMS REMEDIATED:
Any Java based software/service that incorporates the following Log4j versions is no longer vulnerable to Low Complexity Remote Code Execution & Information Leakage attacks (Urgent):

• 2.3.1 or greater within the 2.3.x branch for Java 6 platforms
• 2.12.2 or greater within the 2.12.x branch for Java 7 platforms
• 2.16.0 or greater for Java 8 or higher platforms

However, the above versions may STILL be vulnerable to Denial of Service (service crash) attacks (Significant) which have been fixed in:

• 2.3.1 or greater within the 2.3.x branch for Java 6 platforms
• 2.12.3 or greater within the 2.12.x branch for Java 7 platforms
• 2.17.0 or greater for Java 8 or higher platforms

Furthermore, the above versions may STILL be vulnerable to High Complexity/Insider Threat Remote Code Execution attacks (Moderate):

• 2.3.2 or greater within the 2.3.x branch for Java 6 platforms
• 2.12.4 or greater within the 2.12.x branch for Java 7 platforms
• 2.17.1 or greater for Java 8 or higher platforms

BRIEF DESCRIPTION:
There is a critical remote code execution vulnerability in Apache Log4j. Log4j is a popular Java library incorporated into millions of services and products from organizations such as Apple, Amazon, Cisco, Google, IBM, Microsoft, and Tesla. This logic flaw in untrusted input handling allows trivial and reliable exploitation which earns a perfect 10 out of 10 from the Common Vulnerability Scoring System (CVSS) [1]. This is one of the most serious security flaws in the last decade.

The issue was first discovered on Minecraft game servers. Exploit details were published on 2021-12-09. Threat actor mass scanning and exploitation for this flaw started early on 2021-12-10 and has been observed on all campus networks.

An attacker can attempt exploitation, possibly unauthenticated, by sending maliciously-crafted data to a vulnerable service via any protocol that is eventually passed to an application server using Log4j for logging. When Log4j attempts to log the crafted data, a Java Naming and Directory Interface (JNDI) lookup call is triggered to retrieve code from a server controlled by the attacker via Lightweight Directory Access Protocol (LDAP), Remote Method Invocation (RMI), or Internet Inter-Orb Protocol (IIOP). If the lookup is successful, the arbitrary retrieved Java class or shell command is executed and may retrieve additional malware. Further, the crafted data can trigger the lookup call to use any port, so blocking the common LDAP, RMI, and IIOP ports may not prevent exploitation.

Attackers may also reference environment variables in their maliciously-crafted exploit to exfiltrate sensitive information such as database credentials, secret keys, etc., via a Domain Name Service (DNS) request or JNDI lookup address before Java class or shell command execution. [5] This may bypass some network egress filtering controls.

We stress that the initial communication can be over any protocol and may pass through multiple non-vulnerable servers before arriving at a vulnerable one. The initial exploit call out will be performed over either LDAP, RMI, or IIOP. An attacker does not need direct access to a server to compromise it.

The Apache Log4j project issued a second security release (2.12.2 and 2.16.0) [6] on 2021-12-14 to address possible additional paths for abusing the JNDI lookup feature with Low Complexity Remote Code Execution (RCE) and Information Leakage (IL) as well as address an additional Low Complexity RCE, IL, and Denial of Service (DoS, service crash) issue assigned CVE-2021-45046. The original remediation guidance is no longer effective. See the updated guidance below. 

The Apache Log4j project issued a third security release (2.3.1, 2.12.3, and 2.17.0) [6] on 2021-12-17 to address a new DoS issue involving uncontrolled recursion from self-referential lookups (CVE-2021-45105). Applying the patch for this additional issue is not as urgent since the workarounds and second security release remain effective against Low Complexity RCE and IL. However, if you run a service where uptime is critical, please consult your vendor guidance (again) or consider updating (again) to Log4j 2.17.0 as soon as possible. Note: Security release 2.3.1 was added for this issue on 2021-12-28 to add protection for services relying on Java 6. See the updated guidance below.

The Apache Log4j project has issued a fourth security release (2.3.2, 2.12.4, and 2.17.1) [6] on 2021-12-28 to address a new High Complexity/Insider Threat RCE issue involving modifying logging configurations to use the Java Database Connectivity (JDBC) Appender with a data source referencing a malicious JNDI Uniform Resource Indicator (URI) to load remote code (CVE-2021-44832). Applying the patch for this additional issue is not as urgent considering only trusted individuals would be able to modify logging configurations. See the updated guidance below.

ASSESSING VULNERABILITY: 

We recommend that you:

• Review vendor advisories for services and software you directly manage.
• Perform self-service computer file scans on the systems you manage.

Do your part to keep Carnegie Mellon University safe. If you are notified by a vendor of a breach involving CMU data or suspect your system has been compromised, contact the Information Security Office (ISO) immediately for further instructions. DO NOT take any remediation action. REPORT A BREACH

Reviewing Vendor Advisories
Make an inventory of all the services and software that you directly manage. Review vendor specific advisories for each item to learn which product versions are affected and follow their provided workaround and/or patch guidance. See the Cybersecurity & Infrastructure Security Agency (CISA) [10] and CERT Coordination Center (CERT/CC) [11] maintained lists as well as [3], [7], and [8] for volunteer maintained lists of advisories from popular vendors. Ensure the vendor has incorporated the latest recommendation from Apache Log4j [6].

Self-Service Computer File Scan 
The CERT/CC has released tools [9] to scan computer files for copies of the vulnerable Log4j library jar files. This should help identify what software on the computer may be vulnerable to attack and needs remediation.

They offer a PowerShell script, Python3 script, and a Bash script (more rudimentary) to do the scanning. While they are portable across multiple operating systems with the right supporting script engine installed, PowerShell is native to Windows and Python3/Bash are either native or easier to set up on Linux/Mac. 

Review the GitHub tool site for instructions and downloads [9].

REMEDIATION:

If a patch is not yet available for your particular Java based software, consider applying these mitigations:

1. Locate the vulnerable Log4j jar file(s) and run the following to remove the JndiLookup class from each affected file:

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

This will protect from unauthenticated RCE and IL attacks, but your service/software may still be vulnerable to the latest service crash (DoS) issue. Your software vendor may have further guidance on how to do the above and protect against the latest DoS issue, but please ensure they have at least incorporated the recommendation from Apache Log4j [6] published on 2021-12-14 to remove the JndiLookup class file(s). See the CISA [10] and CERT/CC [11] maintained lists as well as [3], [7], and [8] for volunteer maintained lists of advisories from popular vendors.

2. Apply egress filtering via a network or host firewall to prevent your server from connecting out to untrusted networks or hosts. Only allow outbound connections to your operating system vendor, your software vendors, and any systems for which you have a business need to integrate. If in doubt, start by restricting access to campus networks only and then add and subtract specific trusted networks and hosts based on vendor and integration partner recommendations as needed. The network IP ranges for the Pittsburgh campus are:

• 128.2.0.0/16
• 128.237.0.0/16
• 172.16.0.0/12
  

Although newer versions of the Java Development Kit (JDK) and Java Runtime Environment (JRE) include the “com.sun.jndi.ldap.object.trustURLCodebase” to protect from certain types of JNDI abuse, these protections can be bypassed in exploits related to this issue. Please DO NOT rely only on upgrading your JDK/JRE for remediation.

If a patch is available for your Java-based software, test and patch as soon as possible.

1. See the CISA [10] and CERT/CC [11] maintained lists as well as [3], [7], and [8] for volunteer maintained lists of advisories from popular vendors. Please ensure they have incorporated the latest information from the Apache Log4j [6] project.

2. Consider egress filtering as a best practice to mitigate similar issues in the future.

If you developed your own application:

1. Apply the mitigations above to protect against RCE and IL attacks.

2. Apply one of the following mitigations to protect against DoS attacks per [6]:

• In PatternLayout in the logging configuration, replace Context Lookups like ${ctx:loginId} or $${ctx:loginId} with Thread Context Map patterns (%X, %mdc, or %MDC).
• Otherwise, in the configuration, remove references to Context Lookups like ${ctx:loginId} or $${ctx:loginId} where they originate from sources external to the application such as HTTP headers or user input.

3. Confirm that if the JDBC Appender is being used it is not configured to use any protocol other than Java.

4. Plan to upgrade to Log4j 2.17.1 (Java 8 or higher) or higher in future iterations of your software as it will fully protect from RCE, IL, and the latest DoS issue without requiring the mitigations above. The latest version can be found on the Log4j download page at [4].

INFORMATION SECURITY OFFICE & COMPUTING SERVICES RESPONSE:
1. Computing Services is assessing risks to the services we run and applying mitigations and patches where needed. The majority of our Campus Data Center hosted infrastructure is heavily network egress filtered and resistant to compromise even if the underlying software may be vulnerable. Individual service notifications will be issued should maintenance be required for updating

2. The ISO, with help from multiple Computing Services teams, has developed, received, and implemented partial network detections for attack attempts in HTTP cleartext coming into the campus network and correlated indicators of compromise. We have enabled automated blocking of external attacker IPs relying on passive observation of received attacks (meaning there is a chance that some attacks may leak through and be successful before the IPs are blocked). If we detect a potential compromise due to this issue, we will notify the system owners and/or suspend the compromised system.

3. The ISO is developing network vulnerability scanning for this issue. We will send updated communications when our scanning and notification process begins. NOTE: Given the myriad of protocols that may be used to trigger this flaw, we may not be able to cover them all. Lack of notification from the ISO does NOT mean your server/service is not vulnerable. You should assume your Java-based software is vulnerable until you verify with your vendor that it either doesn't use Log4j OR you’ve applied the vendor-recommended mitigation or patches.

4. The ISO has sent targeted email communications for this vulnerability to those who have obtained an active SSL certificate from the Carnegie Mellon University Certificate Authority and those who have network registrations for systems that ISO's vulnerability scanners fingerprinted as running web services. You may review those messages at [12].

5. The ISO continues to monitor developments and will update our blocking and tackling and send communication updates as necessary.

VENDOR ADVISORY:
https://logging.apache.org/log4j/2.x/index.html (Details under “News” near the bottom)

REFERENCED INFORMATION:
[1] https://nvd.nist.gov/vuln-metrics/cvss 
[2] Removed obsolete reference (see revision 1.1)
[3] https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592 
[4] https://logging.apache.org/log4j/2.x/download.html 
[5] https://github.com/apache/logging-log4j2/pull/608#issuecomment-991354707 
[6] https://logging.apache.org/log4j/2.x/security.html 
[7] https://www.techsolvency.com/story-so-far/cve-2021-44228-log4j-log4shell/#affected-products 
[8] https://github.com/NCSC-NL/log4shell/tree/main/software 
[9] https://github.com/CERTCC/CVE-2021-44228_scanner
[10] https://github.com/cisagov/log4j-affected-db#software-list
[11] https://kb.cert.org/vuls/id/930724#vendor-information
[12] https://www.cmu.edu/iso/news/email-verification/index.html

ADDITIONAL INFORMATION:
https://kb.cert.org/vuls/id/930724
https://nvd.nist.gov/vuln/detail/CVE-2021-44228
https://nvd.nist.gov/vuln/detail/CVE-2021-45046
https://nvd.nist.gov/vuln/detail/CVE-2021-45105
https://nvd.nist.gov/vuln/detail/CVE-2021-44832
https://www.lunasec.io/docs/blog/log4j-zero-day/
https://blog.cloudflare.com/cve-2021-44228-log4j-rce-0-day-mitigation
https://www.theguardian.com/technology/2021/dec/10/software-flaw-most-critical-vulnerability-log-4-shell

SEVERITY RATINGS KEY:
*Urgent:  Requires Immediate Intervention from the ISO. Exploitation is underway and threatens disruption of essential services and/or exposure of non-public data.  The ISO will take necessary actions to mitigate risk while campus custodians remediate locally.

*Significant:  Requires Immediate Custodian Attention. Easy to exploit (i.e. little skill required, little prior knowledge of the target required, readily available and/or automated tools can conduct attack, no user interaction required).  It is likely to be exploited which will disrupt essential services and/or expose non-public data.

*Moderate:  Deserves custodian attention.  Some harm is possible. May cause noticeable disruption of essential services and/or release of non-public data but requires sophisticated skill and knowledge.  It is less likely to be exploited (at this time).

*Minor: Can wait for routine updates.  Little to no harm possible. Would not cause disruption of essential services or expose non-public data if exploited, and/or requires significant skill, time, and access by the malicious actor. Should still be patched at the next opportunity.

Revision History