ITP Techblog

Organisations around the world are scrambling to address the Log4J vulnerability, which IT security experts suggest could be the most serious exploit uncovered in the last decade.

This vulnerability is actively being exploited as reported by CERT NZ, so if you have Java applications that depend on Log4J (and if they're Java applications they almost certainly do), you need to get your hands on version 2.15.0 (available to download from here) and ensure the update is applied with the utmost urgency!

This is true even if your application runs behind closed doors - the exploit is triggered when an application logs the exploit string - so if there's a way it can get into your log files (one person exploited it simply by changing their iPhone's name), you're still vulnerable. iCloud, Steam and Microsoft's Minecraft have already been exploited, make sure you don't join them.

Have you patched it yet? No? Go do it now, we'll wait...

Right, with that out of the way, let's take a closer look at what went wrong...

Exploits don't get much worse than this

Log4J has been around for nearly a quarter of a century, and it's the de facto standard for logging in Java applications. It has all the features you could possibly want and makes it easy to manage what gets logged and where. In fact, so successful was this model that it was exported to other languages such as log4net for the .NET runtime and log4cxx targeting C++.

It's this ubiquity that has caused the Internet to "catch fire". The vulnerability (which has been assigned the identifier CVE-2021-44228 and been classed as "Critical" by the Apache Foundation) allows a remote attacker to trivially take control of a server and execute arbitrary code. Exploits don't get much worse than this. If you're still not convinced, there's already a proof of concept exploit tool on Github with easy-to-follow step-by-step instructions. Hackers are believed to have already cobbled together automated tools to exploit servers en masse!

Free Wortley, CEO at LunaSec, who released details on the exploit, said "it's a design failure of catastrophic proportions".

But, you might be thinking, who's using Java these days? Didn't that die off a decade or so ago? Well, although Java isn't as common today as it once was, it has long been hailed as the new COBOL due to the high dependency that enterprises have placed on it. And to be fair, there's a good reason for that. Java frameworks and standards were created to meet industry needs and allowed complex systems to be built with a reasonable chance of not getting too much wrong. Although the world has mostly moved on to more exciting things, there still remains huge amounts of Java code running critical systems, and those are in real danger.

The massive job required to fix Log4J

Even though the vulnerability is already fixed, vulnerable code is in use by so many people in so many places, that this is going to take a long time to get fully resolved, if it ever does. Companies with strong security teams and good security posture would have been able to leap into action and lock things down very quickly, but I'd bet that the majority of people using Log4J aren't on the latest version, and likely other dependencies aren't either.

So even if they know they need to fix this, it won't simply be a case of restarting but possibly a whole lot of emergency work to try and bring their system up to date enough to be able to accept the fixed version. 

What can an attacker do once they've taken over the server? Well, anything that they want really, depending on what access the Java application has. In some cases, an attacker might encrypt data or simply delete it. They might go looking for sensitive information (such as customer records) to either sell or simply release for all to see. Alternatively, they might use the compromised machine as a base for attacking other machines and exploiting them, similar in fashion to a more traditional botnet. Whatever they do though, it's going to be most unpleasant for the server's owner.

Going forward, all we can really do to protect ourselves from these sorts of vulnerabilities is to keep our software up to date (such that updating a library isn't likely to break anything else), and create a list of all of the components used, so that we'll know what to keep a lookout for when security alerts are released.

Elevated risk of supply chain attacks

The really interesting thing here though is not so much that the Internet is on fire, but that it was effectively lit with a single match. Depending on a single library, no matter its pedigree (and Log4J's is excellent), means that we are at risk of supply chain attacks. This time the vulnerability is not believed to have been created maliciously, but what if next time, it is? How would we know? And what would we do if we all depended on it?

With the world of Node-based apps routinely pulling in thousands of packages of dubious quality (and use cases), we have been somewhat numbed to the risk of third party dependencies. It's so convenient to just pull in and use them, that we often don't even think about these sorts of issues (a similar issue "broke the Internet" when a single developer deleted a package that thousands of applications depended on). And even if we do and we audit the library carefully (remember Log4J has countless hours on the clock), are we going to audit everything it depends on? And everything the dependencies depend on?

Whilst we shouldn't shun the wealth of open source libraries and tools available to us, these supply chain attacks are only going to get worse. This problem still remains mostly unsolved, but I think it will become a very serious issue for our industry in the not too distant future.

Peter Membrey is Chief Architect at ExpressVPN, based in Hong Kong. He is responsible for driving engineering excellence within ExpressVPN and has co-authored over a dozen books and a number of research papers on information security issues. He is a member of IT Professionals NZ.