Log4J: 2021 Ends the Same Way It Began

2021 opened with the discovery of the Solar Winds breach, which I wrote about on January 5th in my very first post of the year The Biggest Security Breach Ever. There were various updates as the whole story became clearer. So it seems appropriate, if not desirable, that one of the last posts of the year should be about what is probably an even more severe security breach in a fairly obscure software element Apache Log4J. It is serious, probably affecting hundreds of millions of devices.

Log4J

I read about this when it first became public and one day later Cadence's IT department sent everyone in the company a warning about it. That's how serious it is. It is not just an IT department problem, Log4J is used all over the place.

NIST gives it 10 (out of 10) for its critical vulnerability score (CVS). You can read the details on their page CVE-2021-44228 Detail.

If you want to dig deeper, look at the Wired article The Log4J Vulnerability Will Haunt the Internet for Years. A key paragraph:

The range of impacts is so broad because of the nature of the vulnerability itself. Developers use logging frameworks to keep track of what happens in a given application. To exploit Log4Shell, an attacker only needs to get the system to log a strategically crafted string of code. From there they can load arbitrary code on the targeted server and install malware or launch other attacks. Notably, hackers can introduce the snippet in seemingly benign ways, like by sending the string in an email or setting it as an account username.

Etay Maor

I talked to Etay Maor of Cato Networks. He is the director of security strategy there. I asked him how the attack actually works. He told me that Log4J is a logging utility and you send it a string of characters and it logs those characters. If you send it hello it logs hello. But if you enclose the characters like ${command} then instead of logging the characters, it executes the command. It does no checking on whether this is sensible or not. So you can direct it to your criminal server and do whatever criminal stuff you want. It reminds me of SQL injection attacks where, if the application does no checking of user input, it is possible to do unauthorized things to the database. There always seems to be an XKCD for everything, and I'll put the SQL injection one at the end of this post—it is as clear as anything how SQL injection attacks work.

Log4J is so easy to exploit that anyone can exploit it. In fact, it was a Minecraft player that first found out about it! The early people using vulnerability are doing simple things like trying to take over lots of machines for Bitcoin mining. But Etay thinks that more sophisticated actors will also take advantage of the vulnerability.

So what can you do about it? First, you should install the patched version of Log4J which is 2.16.0. However, there are also reports of a second and even third vulnerability, so this probably won't be the ultimate patch.

But this will not be the last time that something like this occurs. When it does, Etay says you need to operate at two levels. One is immediate. Within 12-24 hours, do something like blocking everything that comes in from unknown websites that have not been seen in the past. That stops bad guys who set up a new server just to exploit this issue, but also blocks some valid users. This approach is very brute force. Better is if you are using some sort of Secure Access Service Edge (SASE) where you can watch for the ${something} in messages and block them. This shuts down the vulnerability in the short term with a much lower false-positive rate. In the longer term, the solution is patching Log4J, as I said above.

But in this particular case, as Etay said:

Good luck finding them all to patch. This is going to be around for a long time, decades.

For a deeper dive, but still approachable to people who are not security professionals, see Cato Networks' blog post Log4J – A Look into Threat Actors Exploitation Attempts.

The Hacker News has a piece on the current situation, Hackers Begin Exploiting Second Log4j Vulnerability as a Third Flaw Emerges: It is bad:

The latest development comes as advanced persistent threat groups from China, Iran, North Korea, and Turkey, counting the likes of Hafnium and Phosphorus, have jumped into the fray to operationalize the vulnerability and discover and continue exploiting as many susceptible systems as possible for follow-on attacks. Over 1.8 million attempts to exploit the Log4j vulnerability have been recorded so far.
...
"This cross-cutting vulnerability, which is vendor-agnostic and affects both proprietary and open-source software, will leave a wide swathe of industries exposed to remote exploitation, including electric power, water, food and beverage, manufacturing, transportation, and more," industrial cybersecurity firm Dragos noted.

SQL Injection Explained by XKCD

As always, if you don't understand an XKCD, you can go the the explainxkcd website. Here's the explanation for this one.

 

Sign up for Sunday Brunch, the weekly Breakfast Bytes email.

.