Hey folks, Matt here from Data Center Therapy.
If you’re reading this, you’re probably looking for more information on this log4j vulnerability, and most importantly, if your company is at risk due to it.
Log4What?
For some background, log4j is a java-based logging utility, now part of the apache software foundation. That’s right – the same foundation that provides the apache web server, one of the most popular pieces of software across the internet. Now – despite being under the same umbrella, the two pieces of software aren’t technically related at all.
Now, logging is a huge part of almost everything we do in IT, whether that’s console logs of a switch, your Windows event log, syslogd in Linux, firewall logs – the list goes on and on. Data is everywhere and constantly expanding, and so is the log of, well, what’s happening with all that data. Now if you’ve never worked with Java applications, you may not be familiar with log4j, but a ton of applications use it internally for logging. It’s fast, flexible, and free. And now, barring updating to the latest version or implementing mitigation techniques, easily exploitable – and in the worst way. We’re talking remote code execution.
How’d this happen?
Log4j has a plugin called JNDILookup, which stands for Java Naming and Directory Interface. This plugin allows the log framework to reach out to an LDAP server to retrieve attributes from an object, in-stream while logging an activity or event. This exploit takes advantage of ye olde failure to scrub inputs, and can actually be passed a third-party (and malicious) LDAP server through that request. Log4j will actually reach out and connect to that LDAP server and retrieve the object – and that object could very well be a remote shell. Hence the log4shell moniker.
Should I worry?
So, are you at risk? Check the following list to see if you’re running any of the following types of systems:
-
- Servers and clients running Java that leverage the log4j framework. This is primarily a server-side issue, but the attack surface could include clients as well.
- Dependent software packages: at this point, it’s safe to say that anything that uses log4j is vulnerable. Sure, these packages will eventually (and likely soon) release updates, but this is an ASAP-type situation here. Elasticsearch, VMware products, SonicWall Email Filters; there are countless products that leverage log4j. We’ve linked to a couple frequently-updated lists below.
- Appliances: That old crusty physical (or virtual!) appliance that’s been just there and running forever, potentially out of support but doing something critical? Yeah, don’t forget about those.
Ok. I’m worried. Now what?
What can be done about it, right now? Well, there are two main approaches: patching and mitigation. If you’re able to patch, the latest release (2.152.16) fixes this vulnerability. Doing it yourself might not be supported by your software vendor, so if that fails, mitigation might be your best bet. You can set a property in the java configuration to disable JNDI lookups, or remove the class library entirely from the log4j core. Cloudflare has a really good analysis of the exploit and the after effects of it – we’ll link to that below as well.
Alright so that’s a little bit of a summary on the log4j exploit that’s being branded as log4shell. If you’re a VMware customer, and it’s likely that most of you reading this are, there’s a couple links below that’ll help you get your arms around things. Patches are pending and workarounds are documented, so if you’re running vCenter Server, Horizon, Site Recovery Manager, vRealize Suite, Tanzu, NSX… – yeah, it’s a big list. Check out the links and cover your bases. As always, if you need any guidance, extra hands-on or assistance, please don’t hesitate to reach out to one of our IVOXY Consultants.
Happy patching, everyone!