All it takes is one old ETL script on an unmaintained server that logs user-submitted records once a week, and their internal networks will be backdoored by script kiddies at some point soon, not to mention sophisticated actors. The companies that downsized technical teams during the pandemic simply don’t have the bandwidth to audit their entire security surface - #hugops to anyone being asked to do this. It’s a perfect storm. And we’re only seeing the beginning.
But it’s not like I’m going to use our corporate credentials to probe our own service providers to see which APIs are vulnerable - I have no desire to be banned and sued. And we’re too small an account to be able to do anything but make ourselves sound paranoid to our account managers. So I’m just waiting for the other shoe to drop. I hope it’s not something that splashes onto our reputation.
I noticed on thursday thanks to HN and mitigated before 2.15.0 released, and have done nothing all weekend.
i want to know who the fuck on earth actually has a use case of loading a class and running it inline from a logging call rather than calling getUserEmailFromLdap(ou, principal).toString() or something
So I'm questioning whether this flaw really does result in remote code execution, or whether the vast majority of companies are using a version of log4j that doesn't have this flaw.