Another Log4J Update

This week has been full of buzz around Log4j, the most commonly used Java logging module that has a number of recently discovered vulnerabilities. Below is a summary of all the latest news and updates that have come out throughout the week.

CVE-2021-44228

We initially reported on Monday, December 13, 2021 (https://www.connectwise.com/resources/major-vulnerability-in-the-most-common-java-logging-module), about the initial Log4Shell(CVE-2021-44228) vulnerability, which is an untrusted deserialization flaw that can lead to a remote code execution (RCE). This vulnerability can also be used for information disclosure. Since the vulnerability allows an attacker to execute Java on the remote host, we’ve seen attackers embed variables in their payloads (https://blog.cloudflare.com/exploitation-of-cve-2021-44228-before-public-disclosure-and-evolution-of-waf-evasion-patterns/), such as ${env}, ${sys}, ${hostName}, etc. When including these variables in the malicious URI used by JNDI to perform lookups, the values of these local variables are included in the lookup performed, potentially disclosing private information.

The potential attack vectors for this vulnerability are mind-boggling. The most common method we’ve seen so far is targeting exposed web services, but there are countless other attack vectors. For example, Ghidra (https://ghidra-sre.org/) is a Java-based reverse engineering application originally released by the NSA that is commonly used by researchers, such as the CRU, for reverse engineering malware. We were able to confirm with our own testing what others have also discovered that Ghidra can be exploited with a malicious EXE file, for example, https://github.com/zhuowei/GhidraLog4Shell. A bad actor could potentially embed this attack in malware and compromise the system of a security researcher looking into their malware. Yesterday, security researchers at Blumira disclosed that CVE-2021-44228 could also be exploited using JavaScript WebSockets (https://www.blumira.com/analysis-log4shell-local-trigger/). The list of potential attack vectors for this, and other Log4j vulnerabilities could go on and on.

CVE-2021-45046

On Wednesday, December 15, 2021, we shared with you information regarding a new Log4j vulnerability (https://www.connectwise.com/resources/updates-for-log4j-and-december-patch-tuesday), CVE-2021-45046, that affected the initial patch as well as the original mitigation techniques recommended by Apache. At the time, this was disclosed as a potential DoS attack with a CVSS score of 3.7. Since then, we’ve learned that this vulnerability can also be used for RCE and the CVSS score has been upgraded from a 3.7 to a 9.0 (https://www.lunasec.io/docs/blog/log4j-zero-day-severity-of-cve-2021-45046-increased/).

Praetorian also released information this week that CVE-2021-45046 can also be used for the exfiltration of sensitive data. A proof-of-concept video is available in their blog post (https://www.praetorian.com/blog/log4j-2-15-0-stills-allows-for-exfiltration-of-sensitive-data/).

Both CVE-2021-45046 and CVE-2021-44228 are mitigated with the latest versions of Log4j, 2.16.0 and 2.12.2.

CVE-2021-4104

All the initial reports on Log4Shell told us that this vulnerability was specific to Log4J versions 2.x and that 1.x was not affected. Now we know about CVE-2021-4104 (https://nvd.nist.gov/vuln/detail/CVE-2021-4104). This CVE has a CVSS score of 8.1, so not quite as severe as the others, and Log4j 1.x has reached end of life (EOL), so it shouldn’t be as prevalent as 2.x, though we have seen statements from vendors claiming they were not vulnerable because they were using 1.x. Since Log4j 1.x has reached EOL, it is no longer supported and there is not a patched version of 1.x available. At this time, the only way to mitigate any of these attacks is to upgrade to 2.16.o or 2.12.2.

CVE-2021-42550

While this is not a vulnerability in Log4j, it is a similar vulnerability in another Java logging module. Logback (http://logback.qos.ch/) is a Java logging module that claims to be the successor to Log4j. The Logback vulnerability, CVE-2021-42550 (https://nvd.nist.gov/vuln/detail/CVE-2021-42550), is not as severe as the previously discussed Log4Shell vulnerabilities with a CVSS score of 6.6. This vulnerability requires an attacker have permissions to edit configuration files (https://cve.report/CVE-2021-42550) in order to achieve RCE. Logback has released version 1.2.9 (http://logback.qos.ch/news.html) to mitigate this vulnerability.

Ongoing Scans and now Ransomware

There is still massive scanning ongoing. At the beginning of the week, we mostly saw scanning activity and some coin miners being deployed, but now bad actors have also begun using Log4j to deploy ransomware with a new ransomware variant named Khonsari discovered by Bitdefender (https://businessinsights.bitdefender.com/technical-advisory-zero-day-critical-vulnerability-in-log4j2-exploited-in-the-wild) and later confirmed by Microsoft (https://www.microsoft.com/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation/). Then today news has broken that Conti ransomware operators (https://www.advintel.io/post/ransomware-advisory-log4shell-exploitation-for-initial-access-lateral-movement) have begun targeting a Log4Shell vulnerability in VMware VCenter for lateral movement.

Latest ConnectWise Updates

We can’t state this enough. These vulnerabilities are everywhere and are actively being exploited. The initial patch and recommended configuration updates do not mitigate these attacks. The only reliable method of completely mitigating all known Log4j vulnerabilities is to upgrade to Log4j 2.16.0. Unfortunately, for most vulnerable applications, this is not something an end-user can easily do and require an update from your vendor. We strongly recommend a thorough software audit and checking with each vendor to see what is affected and what mitigation paths are available.

For the latest updates regarding ConnectWise products, we recommend you keep an eye on the security advisories in our Trust Center (https://www.connectwise.com/company/trust/advisories). We have signatures on all Perch sensors that detect attempts to exploit the various methods known for remotely attacking Log4j and Logback.