What are Log4Shell and log4j and should you be worried about them?

At the end of November a vulnerability targeting Minecraft servers was uncovered. If you don't play Minecraft you probably didn't pay it much attention.

Since then, however, 'Log4Shell' has surged across the web sending tremors through the security community and prompting the US government to describe it as a 'severe risk'. So, what's going on and is it time to panic?

First of all Log4Shell affects log4j. What's log4j? It's an open-source logging framework in Java that developers use in order to track software activity in cloud and enterprise apps. That means it's used in a vast number of things, Java is on billions of systems including IoT devices, medical kit and more -- it's even used in Ingenuity, the Mars helicopter.

It's also widely incorporated in Apache, the most popular web server software. Even if only a small percentage of devices using log4j are at risk it means this vulnerability has the potential to be massive. The Apache Software Foundation has listed it as critical.

Casey Ellis, CTO and founder of crowdsourced security platform Bugcrowd says, "This is a worst-case scenario -- The combination of log4j's ubiquitous use in software and platforms, the many, many paths available to exploit the vulnerability, the dependencies that will make patching this vulnerability without breaking other things difficult…"

Cybercriminals can use the vulnerability to seize control of a server, allowing them to run any code, access all data on an infected machine, encrypt files and, of course, hold the system to ransom. Indeed it's already being exploited by a growing number of threat actors according to the US government's Department of Homeland Security's Cybersecurity and Infrastructure Security Agency (CISA). The UK's National Cyber Security Centre (NCSC) also says it's aware that scanning and attempted exploitation is being detected globally. Cybersecurity firm ESET has produced a heat map showing where attempted exploits are taking place worldwide.

OK, so this is a big thing and if you weren't worried before you should be now. The next question is, what steps do you need to take to protect your business? Bugcrowd's Ellis says, "The immediate action is to stop what you're doing as a software shop and enumerate where log4j exists and might exist in your environment and products. It's the kind of software that can quite easily be there without making its presence obvious, so we expect the tail of exploitability on this vulnerability to be quite long."

There's a script available on Github to detect the presence of the vulnerability on Linux and Windows systems. The vulnerable versions of log4j 2 are all log4j-core versions from 2.0-beta9 to 2.14.1. The best advice is to update your dependencies to use the latest version, 2.15.0. Earlier 1.x versions of log4j aren't subject to this vulnerability but they have their own issues.

Kudelski Security CEO Andrew Howard says:

The vulnerability highlights that developers often blindly use libraries without carefully considering all available options. A security-conscious developer would probably have disabled the JNDI query when reading the documentation if the software does not use this feature, thus reducing the attack surface.

I recommend that organizations maintain a repository of libraries that are deemed secure as part of a secure DevOps process and as part of the fundamental IT security strategy of the company. The standard for all development processes then includes programmers continuously checking all libraries used in a software development project for acceptability against this repository.

This is likely to be one of those vulnerabilities -- like 2014's Heartbleed -- that will leave a long trail with un-patched systems remaining at risk for years to come.

In the meantime, let's be careful out there.

Image credit: billiondigital/depositphotos.com