30% of Apache Log4j Security Holes Remain Unpatched
It sounds like a bad joke. I mean we all knew that the open source Java logging library Apache Log4j was nasty with a capital N. The National Vulnerability Database (NVD), rated it a 10.0 CVSSv3 which is the worst possible. Last, but not least, Log4j is also used all over the place. So months later how many instances of this security hole have been fixed? All of them? Far from it! According to cloud security company Qualys, only 70% has been patched. “30% of Log4j instances remain vulnerable to exploitation.”
This is crazy! Even if you didn’t care about protecting yourself or your customers — or, as more likely, are too clueless to patch your software — the U.S. The Federal Trade Commission (FTC) will fine you for not fixing the problem. Oh, and did you know that Travis Smith, Qualys director of malware threat research reported that Qualsys has seen “attempted ransomware attacks, some of which have been successful — by Conti, Khonsari, and some nation-state-backed adversaries?”
Do you really want to lose your business?
The CISA and NCSC have reported 1,495 products vulnerable to Log4Shell. Of those, Qualys has spotted 1,065 programs across 52 publishers still in use!
Where the Problems Are
So, where are these problems? Well, the vast majority of them, over 80%, are on Linux. As I like to say Linux is more secure than its alternatives, that doesn’t mean that it’s secure. And, if you’re still running insecure versions of Log4j, it doesn’t matter a darn how secure the rest of your system is. If the window is wide open, no one cares about the locks on your doors.
More than half of programs with Log4j within them are also out of support. The odds of your software supplier patching these are somewhere between slim and none. If you’re still running out-of-date programs, stop. You’re just asking for trouble.
Put the Fix in
Not sure if you’re open to attack? Use Qualys’s new open source Log4j scanning utility to see if your defenses are down. I mean, you should have been running Log4j trouble scanners long ago, but better late than never.
If you don’t find trouble, Qualys claims the average time to remediation after detection was 17 days. You can do it faster though. Systems, which could be exploited remotely were patched quicker, in only 12 days. It’s really a matter of how important you think patching or mitigating this problem really is.
I’ll make it simple for you. Fixing Lof4j vulnerabilities is a mission-critical problem for your company. Yes, it’s a pain. Trust me, cleaning up after a ransomware attack or explaining to a customer why their data went bye-bye is even more of a pain. Fix it already!
