The Log4J vulnerability discovered late last week continues to make lives extremely busy for IT and cybersecurity professionals and software vendors rush to investigate if their products are vulnerable and push patches out to customers while those customers investigate the hundreds of apps their organization uses to determine how exposed they are.
The widely used Apache Log4J 2 Java logging tool contains a remote code execution vulnerability that could impact “millions” of software products, which is making lives very complicated for system administrators and cybersecurity experts alike.
To help you, we asked Paul Ducklin, principal research scientist at cybersecurity firm Sophos, about what this vulnerability means for IT professionals and how to defend against it.
What is Log4j?
Log4J is a common Java logging system maintained by Apache Software Foundation used by developers of web and server applications, and it is used across a huge range of tools. It is the most popular java logging library with over 400,000 downloads from its GitHub project, and “millions” of other products use it.
According to Ducklin, Log4j is an extremely useful Java logging tool that helps keep in compliance with auditing and security requirements.
“It’s very popular, very widely used logging tool, because we all know loggings are important in applications,” Ducklin says. “You want to keep track of which customers have done what, you’ve got auditing requirements, you’ve got security requirements—you want to know who’s using what browser all of this stuff.”
However, there is a feature that allows a message to include “special magic characters” that don’t log what was sent, and instead add extra information.
“For example, say the version of the operating system that’s running on the server—tell me which user is actually running at the moment on the server, all of that stuff. And that sounds a little bit risky, doesn’t it?” Ducklin says. “The idea that you’re logging data, and instead of an actual copy of the data that you’re logging—which you think you’d be making a forensic a precise copy—you can have these magic characters, dollar, squiggly bracket, and then some magic stuff, and then a closing squiggly bracket. And that gets replaced at runtime by the logging system.”
“And somehow, this was considered a fantastic idea.”
The tool also includes a feature that connects to the internet to convert a user ID to an actual name, or a postal code to a town.
“It means a lot of what you log, particularly in the cloud era, is not local data. You’re logging stuff that an untrusted user is sending from the outside,” Ducklin says.
What is Log4Shell?
Log4Shell is the name given to the improper input validation vulnerability in Log4J between versions 2.0 and 2.14.1 that Ducklin says allows a malicious user to send a request to a vulnerable server that includes some data – like an HTTP header – that the server is expected to write to its logfile.
However, that data can be booby trapped to include a crypto miner or other malware.
“What you end up with is something that was supposed to be a super flexible, fantastic, exceptional feature in a widely used logging program that actually turns into an explosively dangerous exploit,” Ducklin says. “You’re taking untrusted data that came from a user, assuming you can do magic things with it. Unfortunately, you’re putting the loggee in charge of the logger. Since the loggee can be anywhere in the world with a traditional server, that’s very bad indeed.”
Since it was discovered, Sophos has detected hundreds of thousands of attempts to exploit the vulnerability and remotely execute code. Log searches suggest it may have been openly exploited for weeks before it was exposed.
How many services and applications use Log4J?
It is unknown how many vendors use the popular logger, but it has been estimated that “millions” of apps do. A security researcher is maintaining a list of vendors on GitHub that have acknowledged using Log4j in their systems.
VMWare, Cisco, IBM, AWS, Google and other big names in tech are responding to the issue by releasing patches for their products and recommending workarounds.
However, the problem may be deeper than that list suggests, Ducklin says. Many web servers are not written in Java, so one would assume they don’t use Log4j. However, it’s not just internet-facing servers that could possibly use this vulnerable code.
“Lots of businesses have some legacy systems where the web server is written in C, but it collects data, and hands it off to some back-end server, and if any of that software is written in Java and it does logging with data that simply has been passed on from the web server that isn’t vulnerable, it still means that something deep inside your network could be tricked into making an outgoing connection and downloading malware,” Ducklin says.
“And the other problem that is significant … where there are lots of applications that might have this buggy library and they didn’t rely on one that was built into the operating system,” Ducklin says. “They carry their own with it, that turns out to be the case with Log4j as well.”
What makes this so difficult to fix?
Apache has fixed the vulnerability, but vendors now also need to patch their products that use Log4j. For IT admins, that means updating and patching anything that uses the impacted version of Log4j.
Most notable vendors have responded with advisories and recommended mitigations, and many have already issued patches.
“You might have lots of patching to do right now in different places across your estate,” Ducklin says.
However, what makes an exploit so easy is because these capabilities were put into the product as a feature, not a bug.
“It actually works really well, it’s just not supposed to load cryptominers,” Ducklin says. “That’s the problem—it’s really easy to exploit, and it’s kind of everywhere.”
Rather than one patch across all systems, this will likely require scanning across an organization’s IT environment to look for where Log4j is being used and starting with the more critical applications first.
Apache has released Log4J 2.15.0 that fixes this flaw, so upgrade now if you’re using any vulnerable version.
Users can also block the Java Naming and Directory Interface (JDNI) from making requests to untrusted servers. If you can’t update, you can set the configuration value “log4j2.formatMsgNoLookups” to “true” to prevent LDAP and similar queries from going out in the first place, according to Sophos.
If you enjoyed this article and want to receive more valuable industry content like this, click here to sign up for our digital newsletters!
Leave a Reply