What is it?
Earlier this month, a vulnerability was announced in an open-source logging utility from Apache called “log4j” that is used extensively in many applications, both web-based and in locally-installed computer software. A patch was immediately available (though two additional fixes have been released since), but needed to be installed by software vendors or web companies in each piece of software before they were again secure. From the first day of the announcement, many companies began updating their software. The vulnerability exists cross-platform because it’s written in Java, a common programming language available on Windows, Mac, Linux, and Android (note that Java and JavaScript are separate languages despite the similar name, and JavaScript does not directly use or contain log4j). The vulnerability was risky and widespread enough that it’s been referred to as “log4shell” within the security community, because the logging system can provide a “shell” or command line interface for an attacker to run anything they want on a vulnerable system.
The most important systems needing updates rapidly are services, applications and websites available directly on the internet that use log4j. Why is this one so serious? A simple one-line piece of text that an attacker can cause to be logged (and many applications log all sorts of things) will let that attacker run whatever of their own custom attack code they want on the server doing the logging, bypassing all security. This is why the very uncommon “CVSS Score” of 10.0, meaning the most serious, easily exploitable vulnerability possible.
What are we doing?
We’ve been keeping a close eye on the log4j vulnerability since it was released and become common knowledge on Wednesday, December 10th, and have confirmed that our customer-facing set of tools (and most of our back-end tools) were either not affected or were fixed by the weekend for the most part, or shortly thereafter. However, there may be some vulnerable code on client systems in a variety of software that will in most cases require updates to be released by vendors to remove or update the vulnerable software. You can also check with specific vendors to see if they are vulnerable; often they will have updates available or are working on them. One of the vendors we use with some clients is Huntress, which has a long track record of proactive security information for IT companies, and they have a more technical article that they have been updating with details since the story was released that we have been following closely, along with several other industry sources.
The vulnerability is significantly more urgent for public-facing services like websites. Static websites may be less likely to be vulnerable and are less likely to contain personal information that could be abused, but if your website contains automation or interactive forms or systems (like a shopping cart), you may want to have your web company confirm your own site is unaffected.
Within most of our clients’ internal networks, we work to wherever possible restrict direct remote access to systems inside corporate networks from being connected to remotely over the internet without an intermediate step required first, such as VPN authentication. This is in large part to help reduce the risk of exactly this type of vulnerability (“reduces attack surface” would be the security industry term), so someone would need to be connected inside network on a subnet with access to a device (server, camera, etc.) that was vulnerable to exploit internal systems. In larger networks, we also segment different types of systems (servers, heating and air conditioning controllers, security cameras, and workstations and laptops) from each other to minimize the damage someone can do when they are connected internally.
Not that staff or a local attacker or someone who managed to get malware running on a company machine inside the network couldn’t cause trouble, but this is an extra step that would slow down random internet strangers from attacking without restriction, which is what started happening shortly after the announcement with public online services (including most major social networks and many online shopping companies)—this is why it was so important for these public-facing vendors to fix their systems quickly.
We have also confirmed that common firewall vendor Fortinet’s FortiGate firewalls were not affected by log4j, although some of their software made for larger companies did have a problem that they worked to fix.
Who else is affected?
This doesn’t mean that your web-hosted vendors (Software as a Service, or SaaS, providers) are safe but they must do their own security fixes, you as a customer can’t do it for them. And there are some computer applications that are affected, that require attack code to be running somehow on a computer first to exploit, so malware might be able to start using vulnerable applications to escalate permissions (become an administrator when the user is not normally) or bypass other security on an office computer, but they would need to first be able to run some code on the system as with most malware.
Some of the big web companies or software that were affected include Apple, Twitter, Minecraft, Steam, Tesla,
We have heard that some attackers are working to try and exploit local applications or local network systems using various methods such as running JavaScript from a web browser using web sockets when you visit a malicious website (which they may trick you into clicking on via phishing emails, malicious ads, or other tricky methods), which is concerning but is a little less of an immediate threat than the web-accessible services, but is a good reason to update applications quickly as updates become available. Scanning tools to scan servers and workstations to determine if they contain the vulnerable code anywhere on the system have been released and can help determine what software is and is not vulnerable and needs updates.
CISA, the Cybersecurity Infrastructure & Security Agency, has released some log4j warnings and guidance, although it’s substantially technical. The news site BleepingCompute released a list of common software and hardware vendors that were affected.
Updates
The other twist is that the first attack was fixed with an updated version of log4j, but since then security issues were found in that first fix, and also in the next fix. Those are not quite as bad, but any systems that were initially updated should be updated again with the very latest fixed version to be the most safe.
Summary
Any given security measure can and will be bypassed, which is why it’s important to have multiple layers of security, from automated scanning and antivirus products to network monitoring and detection systems for local networks and cloud accounts, adding phishing and email impersonation protection, implementing multi-factor authentication (MFA), and should also include training of users on how to be aware of security risks so they don’t fall for scams. Attacks are so prevalent, it’s very likely that all companies will be compromised by an attack at some point that is initially successful. Adding layers of security that help reduce risk that this will happen often, and preparing how to respond to this eventuality, is an important thing to plan for in companies of all sizes! There is no such thing as perfect security (in a complex system that’s actually useful), but there are pragmatic ways to reduce your amount of risk without breaking the bank.
