2 ms·
We have avoided Java internally, but I am mainly worried that our ecosystem of SaaS tools, service providers, even payment processors might be bleeding data bre
by btown 5y ago
We have avoided Java internally, but I am mainly worried that our ecosystem of SaaS tools, service providers, even payment processors might be bleeding data breaches and nobody knows yet.
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.
- burntoutfire 5y agoIf I understood the vuln correctly, the injected malicious payload makes Log4J download and execute code from attacker's LDAP. I'm thinking that, in serious organizations, the call to the LDAP just won't make it through the firewall.
- btown 5y agoEven if we assume serious and dedicated security ops at these organizations, the attacker can specify the port to connect to. So any firewall would need to deeply inspect outbound traffic. And plenty of ETL jobs can mix in offsite data e.g. pulling from S3, or even from a hosted LDAP solution, so they wouldn’t prevent outbound traffic. The attacker could even use AWS IPs! As I said, a perfect storm.