This week, we’ll talk about the evolution of Log4j2 vulnerabilities and some useful mitigation measures you can use to protect against them.
The Evolution of the Vulnerability
“Log4Shell” vulnerabilities started with the discovery of a critical remote code execution vulnerability in the way Log4j2 handled lookups while logging events on the affected systems. This critical vulnerability (CVE-2021-44228) scored a 10 out of 10 on the CVSS. Apache stated that Log4j versions 1.x were less likely to be vulnerable to this finding since JNDI would need to be deliberately enabled. Apache released 2.15.0 to address this vulnerability.
After Apache released mitigation methods for users who couldn’t upgrade Log4j2 to version 2.15.0, another vulnerability was discovered thanks to the attention this open source project got from being in the public’s eye. This vulnerability (CVE-2021-45046) was initially a DOS vulnerability that scored 3.7 out of 10, but later it was also declared a critical code execution vulnerability, and the score was bumped up to 9 out of 10 on CVSS. Apache stated that 1.x versions were not vulnerable and recommended Log4j2 users to update to version 2.16.0 to address this second issue. The JNDI Lookup class removal method was recommended for users who couldn’t upgrade.
Then came the third vulnerability. Although (as of 22nd of December) there is no mention of remote code execution in the security page of Log4j2 version 2.16.0, this vulnerability (CVE-2021-45105) was scored 7.5 out of 10 on CVSS, and it could only cause a denial of service attack on vulnerable systems. Apache released version 2.17.0 and recommended their users upgrade to address the issue. They have also shared new mitigation measures for users who can not upgrade.
It’s important to note that these vulnerabilities were being exploited or attempted to get exploited during the discovery and mitigation phases. According to the 360 Netlab Blog, multiple malware families attempted to propagate using these vulnerabilities. Malicious actors who have successfully exploited the vulnerability were seen implanting coin miners and installing ransomware. These reports underline the importance of mitigating these vulnerabilities as soon as possible.
Official Mitigation Methods
According to the security page of Log4j2, upgrading the component to 2.17 mitigates the three known security issues. For people who can not upgrade their Log4j2, Apache recommended removing the JNDI Lookup class from their vulnerable log4j2-core-*.jar file. However, this is not enough to mitigate the Denial-of-Service vulnerability more recently discovered (CVE-2021-45105). You can mitigate this DOS vulnerability by changing the PatternLayout in the logging configuration. You can read Apache’s Log4j2 security page linked at the beginning of this paragraph to find out about the details of these mitigation methods.
Finding Vulnerable Components
If you’re scanning for vulnerable components, you can use the Log4j-Tools made by jfrog. The tools in this repository are useful when looking for vulnerable Log4j JNDI Lookup calls on a codebase where you are not sure if a piece of code calls Log4j to function. It can also help you determine the vulnerability status of local files. You can also check out Log4j usage and exploitation rules by Cisco CX Security Labs to scan your local files with YARA rules to determine if a file contains the vulnerable Java classes; although this method can provide faster results, it may result in more false positives; however these rules can help you locate Log4j dependent components as well.
The Log4Shell Hashes repository by mubix contains MD5, SHA1, and SHA256 hashes of the log4j2-core files vulnerable to the initial critical RCE vulnerability (CVE-2021-44228). Lastly, you can check out CISA’s database of vulnerable software (only applies to CVE-2021-44228) for a comprehensive list of vulnerable software by vendor.
Protecting Against Attacks
If you can not upgrade your Log4j2 installation and if you’re using Fail2Ban on your server, Fail2Ban regex against Log4Shell by Jay Gooby may aid you in blocking Log4Shell attempts. If you’re using CloudFlare, you can use their WAF rules to protect against these attacks. However, per CISA’s advice, it is encouraged to upgrade to Log4j 2.17.0 or apply the recommended mitigations immediately. It is also important to refer to vendor statements about other software that uses Log4j2, since some software may come bundled with a vulnerable version of Log4j that might need attention.
Finding IOCs & Scanning
If you’re looking for indicators of compromise in your logs, it might be difficult to determine if there were attempts to exploit this vulnerability, mainly because there are many different payloads that can be sent to exploit the known JNDI attack vector. An attacker can encode the strings in the payload, obfuscate them or make it hard to catch when looking for simple payloads. This is where Log4Shell-Rex by back2root might come in handy. Log4Shell-Rex is a regular expression created to match possible malicious payloads encoded with different methods. You can use it on your local log files or use it in your SIEM to match results. However, it should be noted that searching with this regex (with any regex for that matter) may generate false positives or false negatives.
You can also check out the Log4j-scan tool by FullHunt that can aid in discovering and fuzzing for the RCE vulnerability (CVE-2021-44228), you can also use this tool to test for WAF bypasses to get more comprehensive scan results.
We hope to help our customers by sharing useful information in these security digests. As always, feel free to share your thoughts by leaving a comment below.
Comments