As you may already know, the business, tech, and cybersecurity industries have been buzzing about Log4Shell (CVE-2021-44228), aka Logjam, the latest software flaw in an earlier version of the Apache Log4j logging utility. As the name suggests, a logger is a piece of software that logs every event that happens in a computer system. The records it produces are useful for IT and security folks to trace errors or check any abnormal behavior within a system.
Understandably, this may be the first time you’ve been told explicitly about the Log4j tool, but what many don’t realize is that hundreds of millions of applications and web services, including those offered by Twitter, Apple, Google, Amazon, Steam, and Microsoft, among others, rely on it. The software and online services you use in your business may be Java-based, too, thus opening you up for possible exploitation.
Exploiting this flaw allows hackers to worm their way into unpatched systems to take control. It’s seriously bad to have this on any endpoint because of its ultra-wide attack surface and the accompanying damage potential that could bring.
Read everything you need to know about Log4Shell in our blog post,
“Log4j zero-day ‘Log4Shell’ arrives just in time to ruin your weekend.”
Because of all of this, there is a great need for businesses, particularly SMBs, to protect themselves against threats that take advantage of the Log4Shell vulnerability. Most certainly now that Microsoft has started seeing underground groups it dubs as “access brokers,” those exploiting Log4Shell to infiltrate and gain initial access from target company networks in the hopes of selling them to ransomware threat actors.
According to the Microsoft Threat Intelligence Center (MSTIC) and the Microsoft 365 Defender Threat Intelligence Team, “We have observed these groups attempting exploitation on both Linux and Windows systems, which may lead to an increase in human-operated ransomware impact on both of these operating system platforms.”
Ransomware is not the only concern here. Threat actors can also install cryptominers, malware that turns devices into bots and making them part of a botnet—which Mirai bot herders have already started doing—and Cobalt Strike, which cybercriminals abuse to perform network surveillance.
How can SMBs protect themselves from Log4j-enabled attacks?
SMBs who use Linux can start off by checking if the version of the platform they are using is affected. TechRepublic published a nifty guide on just how to do that.
SMB Windows users, on the other hand, should expect to be vulnerable as Microsoft uses Java-based apps in its products. The company has provided a lengthy guidance on the matter of Log4j here, which it has regularly updated with observations on criminal movement involving the abuse of the Log4Shell flaw. It is essential to continuously return to that blog post for updates.
Once you have determined that your platform is impacted by Log4Shell, you must upgrade to the latest version of Apache Log4j, which is 2.15.0. If you’re using versions between 2.10 and 2.14.1 but can’t update to the newest version yet, RiskIQ advises organizations to change the following JVM parameter value to “true” and restart the Java process:
-DLog4j2.formatMsgNoLookups=true
“Organizations who are unclear where to include this parameter must check the documentation of the related Java project/product in use for the correct place,” the company further advises. “Alternatively, they may set the LOG4J_FORMAT_MSG_NO_LOOKUPS=”true” environment variable to force this change. Kubernetes deployments may use this environment variable approach to set it across Kubernetes clusters, effectively reflecting on all pods and containers automatically.”
Finally, the Cybersecurity & Infrastructure Security Agency (CISA) encourages users and business administrators to visit the review this Apache Log4j Security Vulnerabilities page to apply other recommended mitigations steps as soon as possible.
