Log4J, are we done yet?
Cast you mind back to December of 2021, when the cyber security world went into a frantic dash, every sys admin worked until the early hours of the morning ripping out every trace of the Log4J library from there servers, security bloggers, researchers and even end users were all bombarded with the words Log4j. Yes remember now?
Well it is two months on and we are still living with the after shock of the log4js exploit or for the more technical minded CVE-2021-44228. The bug itself, allowed the execution of arbiter code on a server, how and why this was ever allowed to exist is probably for another post, what I wanted to talk about in this post is the after effect, one which according to Jen Easterly, the director of the Cybersecurity and Infrastructure Security Agency (CISA) is the “the most serious vulnerability that [she has] seen in her career.”.
The fall out
Now Easterly is no stranger to this threat landscape, having worked as the executive assistant to the National Security Advisor and then battalion executive officer and brigade operations officer in the United States Army Intelligence and Security Command.
It felt like the vulnerability affected, everything. On top of that, it was very difficult to determine what applications were vulnerable, from what entry point and how badly they were affected. We (the cyber security community) expected carnage, at a global scale. We expected web scans for the vulnerability to go through the roof, and large hacking groups to begin targeting folks right away. But oddly enough this didn't happen, the attack fall out from this vulnerability was actually quite low, that's not to say there wasn't any though.
We saw a fair few VMware Horizon servers targeted (Threatpost.com source) by APT groups, but all in all it could have been a lot worse. After gaining access threat actors did there usual work, compromise services, steal data, lock/destroy systems. At the end of the day this vulnerability was a weakness which allowed hackers to gain access to systems.
What's next
The Log4j vulnerability as mentioned, is everywhere, and it will be the responsibility of vendors all across the world to ensure there products are patched so software engineers and sys admins can continue to use them with confidence.
Considering how deeply embedded the use of the Log4j package is within applications, this vulnerability will continue to rear its head for many years to come. Much like the old Shellshock bug, some vendors or software providers might not even know the issue exists until it is discovered externally somewhere down the road. Which it is so important for vendors and sys admins to start running scans and continue to scan software when ever something new is introduced into there tech stack.
There are countless examples of scripts available to identify the use of Log4j. For example rubo77 provides a decent bash script for Linux machines (github - rubo77 bash script) and there exist other scanning tools out there,
Only time will tell if Log4shell makes a fierce return and disrupts the industry again, but I suspect there is some very important system out there doing something quite critical which is still vulnerable, and when we all least expect it, someone will take advantage of it.
On a side note, there is a very good computerphiles YouTube video which explains why Log4j is so bad if you have time. ComputerPhiles - Log4js