The widely used Log4j logging tool is affected by a critical remote code execution vulnerability that has been increasingly exploited by malicious actors, including profit-driven cybercriminals and state-sponsored groups.
The vulnerability is tracked as CVE-2021-44228 and it has been dubbed Log4Shell and LogJam.
SecurityWeek has compiled a list of tools and other resources that can be useful for defenders concerned about the impact of the Log4Shell vulnerability.
Several industry professionals have shared their thoughts on the flaw, its impact, and the steps that organizations should take to reduce risk and detect potential attacks.
Mike Wiacek, Founder and CEO, Stairwell:
“Right now, every IT person in the world is trying to identify if their machines have vulnerable Log4j packages. Attackers are winning because combatting unexpected major vulnerabilities like Log4Shell takes an incredible amount of time—and time-to-patch—particularly in large enterprises. And time is often the determining factor for the amount of damage from a breach.
To guard against Log4j, IT teams need to assess where they need to look for vulnerabilities, what machines need to be patched, and what software needs to be updated to protect against attackers. To minimize further damage while large-scale patching efforts are being made, we advise security organizations to explore platforms that allow them to rapidly search their enterprise assets for software that may include the vulnerable Log4j packages.
One approach could include searching across file metadata such as file paths and file names or hashes. Another approach could include scanning enterprise file content with customized YARA rules to identify files and artifacts associated with log4j components. These types of searches can accelerate otherwise slow and laborious defensive processes and further help organizations assess where related software exists, where it is out of date, where it is vulnerable, and where to look for post-exploit activity should an attacker make a move before patching can occur.”
Sergio Caltagirone, Vice President of Threat Intelligence, Dragos:
“Log4j is used heavily in external/internet-facing and internal applications which manage and control industrial processes leaving many industrial operations like electric power, water, food and beverage, manufacturing, and others exposed to potential remote exploitation and access. Dragos identified active exploitation of vulnerability CVE-2021-44228 and has provided immediate detection support and specific intelligence to industrial customers.
It’s important to prioritize external and internet-facing applications over internal applications due to their internet exposure, although both are vulnerable. Dragos recommends all industrial environments update all affected applications where possible based on vendor guidance immediately and employ monitoring that may catch exploitation and post-exploitation behaviors.”
Michael Assraf, CEO, Vicarius:
“The way modern products are built is using a big hierarchy of dependencies, where developers use libraries written by third-party companies and engineers to speed up the software release process. Log4J is an extremely basic library that allows log writing in Java applications. The way CVE-2021-44228 affects comes in 3 layers – cloud products that directly use the Log4J, web applications that use libraries that use Log4J, and off-the-shelf software which is internally deployed on customer servers and endpoints.
As fixing and deploying cloud applications can be fast, updating libraries that use Log4J can break functionality unless done with caution. As of right now, only 114 of 17170 libraries which use Log4J are actually safe (0.66%). The most problematic fixes are internally deployed software, which will have to wait for a vendor update or a security patch, in that scenario customers are advised to wait on further vendor guidance and as of right now are helpless in reacting.”
Theresa Payton, CEO, Fortalice Solutions:
“Many businesses may not even know if they have used Log4j, which makes knowing the scope of the problem even more difficult. In order for them to find out, they would need a software engineer to go through the various systems to look for the usage and then look at the versions. It can be a time consuming process and time is something that you don’t have when you’re racing against the clock against bad actors seeking to exploit these vulnerabilities.
Typically when a security vulnerability is found the CISO leads the charge to update and patch systems or put in place a manual mitigation. Log4j is more insidious and hidden and not fully in the control of the CISO. Hunting and finding this vulnerability requires everyone that’s a programmer. Where does development happen nowadays – everywhere! Developers can be internal staff, outsourced development, offshore development and 3rd party vendors.”
Dan Piazza, technical product manager, Netwrix:
“It’s safe to say this vulnerability will have, and already is having, a massive effect on the industry. Log4j is used by thousands of applications, libraries, and frameworks, meaning the number of potentially impacted organizations is staggering. And with attackers already scanning the internet to find vulnerable targets, if organizations haven’t already started taking mitigation steps then it may already be too late.
For organizations that still need to mitigate the vulnerability, they must update the log4j package itself and should not just update Java. This was an early misconception, that updating Java could reduce the severity of the vulnerability, which is simply not true. It’s also a good idea to consult with software vendors to see if they use log4j in any way, and if so if they’ve already provided patches for their products.
If an organization uses log4j or software that includes the library, then it’s safest to assume breach and review potentially impacted applications for odd behavior. Furthermore, if an organization feels they’re already breached then they should consult an incident response firm and remove all physical network access to the affected server.”
Paul Laudanski, head of threat intelligence, Tessian:
“The log4j vulnerability has created endless golden opportunities for bad actors – and they know it and are getting creative. What they’re trying to do now is build an arsenal of tools that they can use across the globe for theft and service disruption, especially ahead of the holiday season.
DDoS attacks in particular are a top concern, as exploitation could allow bad actors to download, install and then fully control an army of botnets. DDoS operators can then focus on attacks that bring down critical infrastructure – ranging from utilities to power grid – and especially retailers ahead of the holiday season, a time when people are notoriously distracted, tired and more prone to making security mistakes. Couple that with an increase in moratoriums, when no code is released into production, so emergency patches would require a break of that moratorium.”
Andrew Howard, CEO, Kudelski Security:
“The main problem is not that the Log4j library comes from an open source project run by only one or two programmers as a part-time project. In fact, a similar number of zero-day gaps can be found in commercial software as in open source solutions. The real problem is a lack of security awareness on the part of programmers and companies, which is still prevalent in many cases.
The vulnerability highlights that developers often blindly use libraries without carefully considering all available options. A security-conscious developer would probably have disabled the JNDI query when reading the documentation if the software does not use this feature, thus reducing the attack surface.
I recommend that organizations maintain a repository of libraries that are deemed secure as part of a secure DevOps process and as part of the fundamental IT security strategy of the company. The standard for all development processes then includes programmers continuously checking all libraries used in a software development project for acceptability against this repository.”
Casey Ellis, Founder and CTO, Bugcrowd:
“When a vulnerability is discovered and makes as much noise as Log4Shell, it invariably signals that there are additional vulnerabilities in the same software or fixes for that software and triggers additional research and discovery. In this case, the initial fix provided was developed in a way that mitigated the exploitable symptom, but didn’t properly address the root cause.
This also highlights the dangerous dependency open-source users have on libraries which power large portions of the Internet, but are ultimately written and maintained by unfunded volunteers with limited available time. A huge shoutout to the log4j maintainers, who I’m sure have had an even busier and more stressful week than those in cybersecurity and are working on fixing and improving log4j’s resilience as quickly as they can.”
Reuven Harrison, CTO, Tufin:
“The exploit, like many others, relies on a call-home step to a command-and-control (C2) server.
To prevent these kinds of attacks, organizations should restrict egress (outbound) connectivity. Each subnet, server and workload should be allowed to connect only to the endpoints that are required by business. All other destinations should be blocked.
Blocking egress connections is easy with standard security controls such as firewalls, but defining the policy, which egress connections are allowed, is tough. Doing this properly requires continuous learning of legitimate application connectivity patterns, and enforcement in production environments.”
