Log4Shell - Thoughts from the Truework Security Team

CVE-2021-44228 and CVE-2021-45065: Gaining Certainty In Uncertain Times

The internet is ablaze with talk of wide-reaching critical vulnerabilities, the likes of which have rarely been seen before. These critical vulnerabilities (a perfect 10 on the CVSS scales) are formally known as CVE-2021-44228 and CVE-2021-45046, and more commonly known as “log4shell”. The flaws reside in a popular, nearly ubiquitous Java logging library called Apache log4j, maintained by the Apache Software Foundation.

Your security team is probably working over time to understand the risks of this vulnerability, and with good reason. While ensuring widespread patching of any particular vulnerability is already a difficult task as an organization grows, the ubiquity of the log4j package combined with the nature of this particular flaw means that overlooking even one or two assets could still result in compromise across the board - including services not utilizing the log4j library, but residing in the same networks as the affected systems.

A Brief Timeline

The following is a non-comprehensive timeline of the mentioned log4j vulnerabilities:

1. November 29th, 2021 - log4j maintainers submit a pull request titled “Restrict LDAP access via JNDI”
2. December 1st, 2021 - The oldest identified exploit of this vulnerability, retroactively identified by Cloudflare
3. December 4th, 2021 - log4j maintainers merge the aforementioned pull request
4. December 9th, 2021 - Truework Trust and Safety is notified of the issue and sets out to better understand it’s impact on Truework
5. December 10th, 2021 - log4j maintainers release 2.15.0, addressing CVE-2021-44228
6. December 13th, 2021 - log4j maintainers release 2.16.0, addressing CVE-2021-45046

What is CVE-2021-44228 a.k.a. Log4shell?

CVE-2021-4428 is a software vulnerability that makes use of a combination of features in the log4j library to achieve unauthenticated remote code execution on affected services. The log4j library supports a feature called Lookups, which provides a way to add values to your logs in arbitrary places via substitution. In particular one of these Lookups is called “Java Naming and Directory Interface” or JNDI, which was created as a way to interact with a remote directory service, such as “Lightweight Directory Access Protocol” commonly referred to as LDAP, in order to add specific values into your logs.

Attackers discovered that by using this JNDI lookup, they were able to inject values into logging streams that would then cause log4j to connect to the host referenced in the JNDI lookup. Since this functionality allows for the retrieval of remotely hosted code, attackers were able to host malicious Java classes on their LDAP server that would then be loaded by the vulnerable application and subsequently executed during the log substitution.

This meant attackers only had to find fields that were being passed to a logger using log4j in order to achieve code execution.

The Impact Thus Far

Once attackers figured out how to reliably achieve code execution on affected services, they quickly began to migrate towards standard cybercrime behaviors – deploying cryptominers, building self-propagating worms, and leveraging access in order to pivot internally on networks and exploit companies further.

Attackers have also begun to exfiltrate environment variables via combining the JNDI lookup with another log4j lookup called ENV, which allows for substitution of environment variables, into your logs. Combining these makes it possible to leak sensitive data, such as AWS keys or other third party API keys from production services, which can then be leveraged to further access, abuse cloud resources, steal source code, and more.

So Now What?

A Security Program coupled with an engaged Engineering Team is instrumental in driving the core foundations that can help to detect, respond to and mitigate the active threats spawning from this vulnerability. While there is no silver bullet for most organizations in this situation, solid security and engineering foundations are still the key to an effective response that delivers the required visibility and execution capabilities to address these threats.

Focusing on Observability and Detection Capabilities, Software and Asset Inventory, Patch Management and Communication to Key Stakeholders is a great place to start. That, coupled with remaining vigilant and methodical in times of crisis, tends to pay off in dividends.

A few tips that may be useful for the defenders hard at work right now:

• Watch for suspicious JNDI calls in logs and traces
• If possible disable lookups in properties, or remove the log4j lookup capability
• Patch any vulnerable log4j libraries in use to at least version 2.15.0 or 2.16.0
• Upgrade your JDK
• Add WAF rules to block malicious inbound requests
• Restrict egress to the internet from environments and systems impacted
• Be curious, be calm

Truework and CVE-2021-44228 A.K.A. Log4shell

Currently, Truework’s platform does not leverage Java or interface with Java based systems - except in extremely limited, downstream use cases. Despite the unlikeliness of being directly impacted by 1st-party code, Truework’s Trust & Safety and Engineering teams have responded quickly to investigate, triage and update any packages or services that we rely on which could even remotely be susceptible to this issue. We will continue to diligently monitor the impact that this vulnerability may have on our vendors, our partners, and our customers.

While we are making every effort to ensure the safety and security of the systems we use and the data we work with, Truework welcomes Security Researchers who believe that they have found impact to Trueworks systems to get in touch with us, as outlined in our Vulnerability Disclosure Policy.