ON-DEMAND: Hear from our CISO, Deepen Desai, and Sr. Product Director, Rick Miles, as they discuss Log4Shell and steps your organization should take.
It’s been a long week for IT and security professionals as we’ve peeled back the layers of impact resulting from the Log4j vulnerability CVE-2021-44228, dubbed “Log4Shell.” This vulnerability has the highest possible critical severity (CVSS) score of 10.0, a designation that applies to less than 5% of all CVEs ever discovered. Many are saying it’s the worst vulnerability we’ve seen in a decade.
We’ve offered a ton of guidance this week about the nature of the exploit, the attacks we’ve seen taking advantage of it, how to assess your impact, and how to use layered defenses grounded in zero trust to protect your organization from this and future vulnerabilities.
In this blog, we’ll summarize the latest information and point you to the resources we’ve rolled out as you continue to mitigate the vulnerability and work to improve your risk posture. These resources are also available on zscaler.com.
Why is Log4Shell so bad?
Apache Log4j is an open-source logging library used in millions of JAVA projects, including a substantial percentage of enterprise applications and cloud services. 1,800+ major GitHub repositories have dependencies on the Log4j logging library.
Log4j is used to log all sorts of data about how applications are being used, format it, and push it to various destinations. But, Log4j isn’t just a passive logging tool – it actively interprets the data that is being logged.
The Log4Shell exploit takes advantage of that feature, allowing attackers to use a specially crafted JNDI string to talk to Log4j. Log4j uses JNDI to perform a request to the attacker site, which then executes the attack payload. Our experts show a live demo of how this works, along with a lot of super valuable information about mitigating and stopping it, in this on-demand webinar.
Using this exploit requires very little technical expertise. This was initially discovered in the game Minecraft, in which users were issuing commands simply by using the JNDI string in a chatbox. Security researchers have also shown the ability to issue commands from devices such as iPhones and Tesla vehicles simply by changing the name of the device to the string.
Hopefully by now, many companies have taken action to protect their most critical applications and assets by updating their Log4j libraries and applying mitigations. However, the extreme widespread use of Log4j can make it very difficult to hunt down all of its uses within an enterprise. Any server or application that is not actively being maintained is at risk of being exploited by attackers. And, those who have been exploited may have to handle future attacks associated with fingerprinting performed and/or persistence mechanisms implemented by attackers. This exploit will likely haunt security teams for years to come.
What kinds of attacks have we seen?
We’re only scratching the surface of the attacks that will leverage this exploit. So far, the greatest number of hits are from scanners, as both attackers and security research teams race to identify vulnerable systems.
We’ve seen a high volume of activity associated with botnets, particularly Mirai and Kinsing (cryptomining). Other payloads we’ve observed have included the use of CobaltStrike, and there have been reports of brand new ransomware families that have emerged using this exploit.
In the ThreatLabz exploit analysis blog, we break down the exploits we’ve seen and go in-depth into the attack chains of some of the most prevalent ones. We will continue to update this analysis blog as needed.
ThreatLabz also tapped into our global mesh of decoys to assess exploit activity, and found that testing and development environments are being targeted at the highest rates, presumably as they are lower on the patching priority list.
Am I impacted?
If you are a Zscaler customer, it’s important to note that there has been no impact to Zscaler services as a result of this exploit.
The ThreatLabz security advisory blog includes detailed guidance on identifying any vulnerable versions of Log4j in your environment.
You can also use our complimentary attack surface analysis tool to see if you have any external attack surface using Apache.
What should I do?
As outlined in the ThreatLabz security advisory blog, the first thing to do is ensure that you’ve updated, patched, and/or taken mitigation actions for all vulnerable Log4j servers.
Then, it’s time to think about strengthening your security posture.
Zero day vulnerabilities, by definition, have never been seen before. Do you really want to gamble that your security controls are going to be up to snuff against novel attacks? The best way to protect your organization and its valuable assets is by deploying a true Zero Trust Network Architecture that eliminates the ability for attackers to exploit back doors and limits lateral movement by:
- Minimizing your attack surface and making apps invisible.
- Ensuring only authorized users can access apps.
- Detecting and blocking malicious activity.
- Preventing lateral movement with user-to-app and app-to-app microsegmentation.
Read more about how and why this beats out a legacy VPN approach in this blog.
Deception is a simple and effective approach to threat detection that uses decoy/honeypots to intercept attacks and divert them away from whatever asset they were originally targeting. Deception is particularly effective against zero days as it doesn’t require any prior knowledge of the threats to detect an attack: ANY interaction with a decoy sends a clear signal to security teams that malicious activity is underway. We are seeing more and more security teams recognize how critical a role deception can play within their zero trust deployments. Read how you can use it here.
Many security solutions focus on user-to-app communications, but app-to-app communications are equally as important, particularly in mitigating the impact of supply chain attacks. See how you can use identity-based segmentation to protect your apps and workloads.