About
On December 9th, 2021, a severe vulnerability (CVE-2021-44228) was released for the widely utilized Apache Log4j logging library. This library is a Java-based logging utility used in vendor applications and hardware appliances. The vulnerability allows an attacker to remotely execute code on versions 2.0 and 2.15.0.
Apache has released a patch and it is advised that the Log4j library is updated to version 2.16.0. Due to Log4j being compiled within various software and hardware applications there are instances where it may only be patched via a vendor specific update(s). This vulnerability is currently being widely scanned for and exploited in the wild. Log4j versions 2.0.0-2.15.0 are the vulnerable.
VENDOR STATEMENTS & AFFECTED APPLICATIONS
RedLegg has been referencing the following resource to track known affected vendors as well as vendor position statements. If you are in need of additional information, RedLegg recommends reaching out to your vendors directly.
https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592
PRE-ExPLOIT Detection
There are three methods to search for vulnerable software: active vulnerability scanning, application scanning, and use of canary tokens. All three are outlined below:
Vulnerability Scanning
Nexpose, NMAP, and Nessus are just a few examples many capable vulnerability scanners that scan your environment to help determine if the vulnerability exists.
Because of the limitations in vulnerability scanners, application scanning and code review are the most thorough methods to determine if the vulnerability exists within your application or appliance.
Application Scanning
RedLegg recommends the below open-source Application scanning tools if a licensed enterprise product is not available:
Canary Tokens
RedLegg recommends utilizing a point & click canary token to attempt to manually verify if applications are vulnerable. Be advised that if the application does not return a response, it may still be vulnerable to CVE-2021-44228.
- Visit https://canarytokens.org
- Choose the Log4shell token
- Enter the email address you wish to be notified at
- Copy the returned string and paste into application input fields or URLs to validate patches or to safely check for the Log4j vulnerability
Mitigation
As of December 14, 2021, the only verified mitigation technique is upgrading Log4j to version 2.16.0. This version patches the vulnerability by removing support for message lookup patterns and disabling JNDI functionality by default. The vulnerability is also mitigated in prior releases (<2.16.0) by removing the “JndiLookup” class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class).
Exploit Detection
The most reliable method of detecting this vulnerability is via Java application logs. RedLegg advises retaining these logs in searchable format to analyze possible exploitation attempts. Be advised that the attack strings can be obfuscated by attackers in attempts to foil alerting and mitigation. Manual searching of logs is also possible but not recommended due to ease of obfuscation.
Endpoint searching is possible, and the below script written by Florian Roth attempts to account for obfuscation while searching:
- Log4Shell-detector https://github.com/Neo23x0/log4shell-detector
RedLegg created a custom LogRhythm rule that detects multiple variations of the expected "jndi" string that is found in logs during exploitation. The presence of the “jndi” string in logs varies widely between all the currently known vulnerable applications. RedLegg focused on detecting the vulnerability within Windows and Linux operational logs due to the wide variety of vulnerable applications not being ingested by the SIEM.
RedLegg has enabled this rule for all clients with a LogRhythm deployment and is in the process of deploying similar rule logic to other supported SIEM technologies.
Additionally, RedLegg is in the process of developing network-based rules to allow for a broader detection scope. We will continue to develop, test, deploy, tune, and redeploy rules for detecting this activity as our research continues and more data is made available.
Additional Resources
- CVE-2021-44228: https://nvd.nist.gov/vuln/detail/CVE-2021-44228
- CVE-2021-45046: https://nvd.nist.gov/vuln/detail/CVE-2021-45046
- Log4j CVE-2021-44228 Advisory: https://github.com/advisories/GHSA-jfh8-c2jp-5v3q
- Log4j Apache Update Site: https://logging.apache.org/log4j/2.x/download.html
- Microsoft Guidance: https://www.microsoft.com/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation/
- Log4j Playbook: https://www.trustedsec.com/blog/log4j-playbook/
- Log4j Exploitation Demonstration: https://www.youtube.com/watch?v=7qoPDq41xhQ
- Complete Overview From CISA: https://www.cisa.gov/uscert/apache-log4j-vulnerability-guidance
- Log4j Tools: https://github.com/MalwareTech/Log4jTools
