JANUARY 7, 2022 17:44 GMT
Update 1/12/2022 Added info on newly discovered PowerShell backdoor exploit.
The last 2 weeks of 2021 were a frenzy of patching and hyper-analysis for Apache’s open source Log4j Java logging library. The biggest security headline in months rapidly saturated even mainstream news with alerts and analysis pieces, making it even harder to find clear guidance. But one week into January 2022, things seem to have stabilized in terms of the code, while reports of exploit attempts from across the sector continue.
The wake of the Log4j vulnerabilities is significant. While the situation is by no means resolved, this wrap-up article will summarize the situation thus far. Innovate also published three previous advisories at the outset of the situation in mid-December:
- Apache Log4j Zero-Day Exposes Java Applications to RCE 12/10/2021
- Log4j/Log4Shell Updates and Recommended Guidance 12/13/2021
- Apache Releases Log4j 2.16.0 to Patch Lingering DoS Vulnerability 12/14/2021
CVEs and Versions at Present Time
The latest version of Log4j is 2.17.1, which fixes the latest of the three big CVEs:
- CVE-2021-44832 – fixed by 2.17.1
- CVE-2021-45046 – fixed by 2.16.0
- CVE-2021-44228 – fixed by 2.15.0
CVE-2021-44228 (Dec 10, 2021)
The initial Log4shell vulnerability broke news on December 9, 2021. It allows an unauthenticated attacker to exploit a flaw in Log4j version < 2.15.0 to make log injections with specially crafted code that can leverage the JNDI service to execute code in other applications. This jfrog article is an excellent technical explanation of the exploit that uses actual code examples.
CVSSv3 Score: 10.0
Fixed by: Log4j 2.15.0
CVE-2021-45046 (Dec 14, 2021)
On the heels of the initial vulnerability, CVE-2021-45046 was discovered and Log4j 2.16.0 was released. The nature of the flaw was slightly different as the focus on Log4j had revealed further opportunities that allowed specially-crafted JNDI lookups to DoS the host. Initially rated as lower severity, it was upgraded to a CVSSv3 9.0.
CVSSv3 Score: 9.0
Fixed by: Log4j 2.16.0
CVE-2021-44832 (Dec 28, 2021)
The most recent vulnerability discovered in Log4j is a bug allowing RCE when JDBC Appender is used with a JNDI LDAP data source URI. However, it requires a specific scenario in order to exploit: the attacker must be in control of the remote LDAP server. The issue can be fixed by limiting JNDI data source names to the Java protocol in Log4j 2 versions 2.17.1, 2.12.4, and 2.3.2.
CVSSv3 Score: 6.6
Fixed by: Log4j 2.17.1 w/security patches available for 2.12.4 (Java 7) and 2.3.2 (Java 6)
Exploits in the Wild
With an unauthenticated remote code execution vulnerability, the sky is the limit for how systems running vulnerable Log4j can be abused. So it’s an interesting research project to find examples of actual Log4Shell exploits occurring in the wild.
Aqua Security compiled a great blog post 5 days post-disclosure detailing the types of attacks they’re seeing against their honeypots:
https://blog.aquasec.com/real-world-log4j-attacks-analysis
At that time, they recorded “multiple malicious techniques to exploit our environment, including known malware, file-less execution, files downloaded from a remote resource and executed straight from memory, and reverse shell executions.” Their data shows roughly 67% reverse shell attempts with the remaining third split between Mirai and Muhstik, two Linux botnets used for cryptomining and DDoS attacks.
Microsoft’s 365 Defender Threat Intelligence Team and Threat Intelligence Center (MSTIC) issued some guidance and insight in a blog post on January 3 detailing the types of exploit attempt activity they have observed. The 365 Defender product is well-positioned as a frontline defense for the masses of Windows hosts out there, and as a result provides good representative data for a cross-section of attacks.
“The bulk of attacks that Microsoft has observed at this time have been related to mass scanning by attackers attempting to thumbprint vulnerable systems…”
The detailed post goes on to detail multiple types of exploitation from across the globe, including “nation-state activity groups originating from China, Iran, North Korea, and Turkey.” Groups known to operate as access brokers, often employing ransomware techniques, have operationalized the exploit.
Essentially, all the bad actors out there got a huge Christmas gift in the form of a new tool for exploit, and they are making use of it.
Update Check Point published an article Jan 11 detailing a new development in tooling for Log4j exploits dubbed “CharmPower.” The new PowerShell-based modular backdoor has been observed in use by APT35, suspected to be an Iranian nation-state actor. This is an improvement on the original open-source exploit kit that is more easily detected. Someone spent their holidays hard at work.
Consequences of Failure to Mitigate
Aside from the obvious risk of sitting on an exploitable vulnerability with tools widely available for attackers to use, regulators have jumped into the fray to pressure businesses to act. The US Federal Trade Commission issued a warning earlier this week that it “intends to use its full legal authority to pursue companies that fail to take reasonable steps to protect consumer data from exposure as a result of Log4j.”
Software vendors can also expect higher scrutiny from their customers as downstream consumers demand greater governance in remediation of high profile critical vulnerabilities.
What Should I Be Doing Now?
The type of action to take in regard to Log4j vulnerabilities depends on which side of the table you’re on. Are you a developer/maintainer of software? Or an IT operations director trying to flush out all occurrences of Log4j in your enterprise application inventory?
For IT Operations or CISOs:
- Take inventory of all instances of Log4j being utilized in your business applications. Scanning tools have been made available from several vendors, including Tanium, Qualys, and SOC as a Service tools like novaSOC. These tools are effective at scanning a network and identifying hosts with vulnerable Log4j versions using either local agents in EDR fashion or by “fuzzing hosts” with erroneous parameters for HTTP headers and POST data to root out vulnerable responses.
- Vendor updates and patching should be tracked to full resolution and confirmation of Log4j version 2.17.1
- Start requesting a software bill of materials (BOM) from vendors in order to review all components of their software stack. This is useful in both tracking vulnerabilities but also for licensing concerns. It’s useful to have full visibility into layers of the stack down to the base open-source libraries included with nearly all software. At the very least it will save time during audits when the next big vulnerability comes down the pike.
For Software Developers:
Software developers and devOps engineers who manage products using Log4j should be upgrading their imported libraries to use the latest version. These are security fixes and don’t affect syntax or instantiation, so upgrades should be relatively painless.
It is likely that repackaging and rolling out upgraded versions of your products is the larger effort, as well as working with or convincing customers who may be reluctant to rock their own boat. But documenting that the vulnerability was patched and made available is a prudent act of due diligence.
A Strategy For Living with Log4j
Log4Shell is here with us to stay, not unlike an endemic virus. Even after patches and mitigations are applied, the best strategy for living with it, or any other prolific vulnerability, is to develop tools and practices for granular visibility into all software in your organization.
One of the biggest pain points of this particular vulnerability is that organizations were blindsided and their inability to determine their versions of Log4j, or if it was even present, was laid bare.
Log4j has been and probably always will be the most popular Java logging library. Version 2 (the vulnerable version) is utilized in thousands of Java applications and is wrapped or embedded in software you’d never expect it to be.
While developers of high-profile commercial software have been responsive with upgrading their included versions of Log4j and shipping out updates to customers, there are organizations who may struggle with quick patching or even determining the existence of the vulnerable versions.
It’s likely that Log4Shell will be in the attacker’s or pen tester’s bag of tricks for years to come, so a strategy for living with it involves good visibility into inventory and preparing defenses that can detect and block exploit attempts.
Resources
- Apache Log4j Zero-Day Exposes Java Applications to RCE
- Log4j/Log4Shell Updates and Recommended Guidance
- Apache Releases Log4j 2.16.0 to Patch Lingering DoS Vulnerability
- Innovate Log4j / Log4Shell center
- Aqua Security writeup on Log4Shell reverse shell attacks
- Microsoft 365 Defender Threat Intelligence Team blog post
- FTC warning for companies who fail to mitigate Log4Shell
- cve.org: CVE-2021-44832
- cve.org: CVE-2021-45046
- cve.org: CVE-2021-44228
