Log4j is a ubiquitous piece of software used in a variety of consumer and enterprise services, websites, and applications—as well as in operational technology products—to log security and performance information. Recently, a very serious remote code execution (RCE) vulnerability in the popular Java logging package, Log4j (CVE-2021-44228) was disclosed, posing a severe risk to millions of consumer products to enterprise software and web applications. This vulnerability is currently being widely exploited by a growing set of attackers.

When vulnerabilities are discovered and exploited, it risks a loss or breach of personal information, financial loss, and other irreversible harms.

Log4j Vulnerability Overview

Until a few days ago, most people would not have had any knowledge of the Log4j software. However, this little-known module is commonly used by other larger software, which means it is found in many products and locations. Some of the early alarm bells were raised by Swedish online game developer, Mojang Studios, after their users’ Minecraft servers were compromised.

Log4j logging library is widely used in enterprise applications from Apple, Twitter, Amazon, Tesla, CloudFlare, and products including Apache Struts2, Apache Solr, Apache Druid, and Apache Flink for its rich feature set and ability to flexibly record log information. Even Ghidra, a popular reverse engineering tool from NSA, is vulnerable to this bug. Attackers can use the feature that is used to write error logs to construct special data request packets through this vulnerability and ultimately trigger the remote code execution.

Threat actors were observed scanning the Internet for servers vulnerable to this unauthenticated RCE after the first POC exploit was published on GitHub. There are also many reports of Log4j vulnerability abuse in the wild, where threat actors are pushing different types of malware, such as Mirai and Tsunami botnets, Cobalt Strike, and Cryptominers.

The vulnerability is simply triggered by sending a specific JNDI string to the Log4j software, which triggers the install of the malicious software as shown below. As we can see, the Log4j vulnerability is easy to exploit and the broad utilization of this software means there are multiple attack vectors.

How Exium Protects Customers From the Log4j Vulnerability

Exium’s customers are protected from attacks exploiting the Apache Log4j remote code execution (RCE) vulnerability as outlined below.

• Zero-Trust Security: In the exploit example (image above), if Zero Trust Security had been in place with least-privilege enforcement, attack risk could be reduced through multiple layers of defense: Initial inbound connectivity would not be allowed as the attacker’s IP would not be in the allowed policy. Because the host that receives the inbound connection is protected by Zero Trust Security, indiscriminate access to the system is not allowed. Outbound communication from the vulnerable server to unknown external entities would not be allowed by policy–again enforced by Zero Trust Security.
• Next Gen Firewall: can automatically block sessions related to this vulnerability. Customers already aligned with our security best practices gain automated protection against these attacks with no manual intervention.
• Content/ Protocol Filtering: Log4j RCE requires access to code hosted externally. Our Advanced URL Filtering security service is constantly monitoring and blocking new, unknown and known malicious domains (websites) to block those unsafe external connections. Also, suitable egress application/ protocol filtering can be used to block the second stage of the attack. Use Known Protocol ID for “LDAP” to block all Lightweight Directory Access Protocol (LDAP) traffic to or from untrusted networks and unexpected sources.
• XDR: Monitors and protects against payloads delivered by exploitation of the vulnerability. Exium’s XDR customers are protected against various observed payloads stemming from Log4j vulnerability. Additionally,  Behavioral Analytics will detect post-exploitation activities related to this vulnerability.
• Secure Private Access: If you are running internal applications that cannot be immediately patched, you can mitigate the risk of exploitation by limiting access to the app. A private access solution, such as Exium Secure Private Access, can be used to make private apps invisible to external attackers who seek to exploit vulnerable services. Furthermore, a private access solution can restrict access to a private app internally, such that only authorized users are able to access the app, reducing the risk that a compromised user or device could be used to exploit vulnerable services.
• IPS: Apply web application firewalling signatures and IPS to detect and prevent the vulnerability from being exploited.

Also, consider heightened security for the newly-registered-domain and high-risk categories.

What comes after Log4j

Log4j could be just the the beginning of a whole new class of bugs. It turns out that the JNDI API is very attractive as a means of compromise as it allows simple unauthenticated remote code execution. A new JNDI-based “Log4j-like” critical vulnerability was disclosed on Jan 7, 2022. Tracked as CVE-2021-42392, this related RCE flaw was discovered in H2 database consoles, an open-source relational database management system written in Java. Although far from as widespread as the Log4j vulnerability, it is estimated to affect almost 7000 assets including popular frameworks like JHipster, Play framework and Spring Boot.

Lessons from the Apache Log4j Vulnerability

Even if you’re not an Apache Log4j user, it’s still likely that one of your partners, customers or suppliers uses software that includes the vulnerable component. The Log4j vulnerability demonstrates the fragility of our large, interdependent technical ecosystem.

Log4j vulnerability requires immediate mitigation, given the popularity and usage of Apache and the ease of exploitation. We strongly recommend anyone using Log4j to update to version 2.15.0, where the fix was released by Apache.

Unfortunately for overworked admins and security teams, a new year doesn’t mean an end to old problems, and exploitation of the Log4j and related JNDI vulnerabilities is going to be haunting many defenders for some time to come.

If there’s any silver lining to this dark cloud it is that in order for threat actors to capitalize on vulnerabilities, they need to engage in malicious behavior, and that’s where AI-powered XDR protection comes into its own. Whether its cryptominers or malware loaders, ransomware or banking trojans, deploying an autonomous detection and mitigation solution like Exium’s XDR is an essential part of defending the modern organization from compromise.

If you would like to see how Exium can help defend your organization, contact us at hello@exium.net