Hackers Exploit AWS Misconfigurations in Massive Data Breach (www.infosecurity-magazine.com)
from kid@sh.itjust.works to cybersecurity@sh.itjust.works on 10 Dec 19:24
https://sh.itjust.works/post/29300559

#cybersecurity

threaded - newest

treadful@lemmy.zip on 10 Dec 22:29 collapse

Fuck this article.

Using publicly available AWS IP ranges, attackers identified potential targets by scanning for application vulnerabilities or misconfigurations. […] The group scanned exposed endpoints for sensitive data, including database access credentials, API keys and other security secrets

That’s the most detailed information about the exploit in the article. And there’s no relevant external links either. Literally nothing actionable in it.

scytale@lemm.ee on 10 Dec 23:28 collapse

Applying Occam’s Razor, I assume this is publicly exposed buckets and lack of (or misconfigured) resource-based policies on those buckets, which is probably like the most common reason for these breaches.

treadful@lemmy.zip on 11 Dec 01:34 collapse

But we’ll never know because people can’t do basic reporting.

Also, you generally don’t magically get things like API keys and database credentials from buckets. Unless your team is completely braindead.

scytale@lemm.ee on 11 Dec 02:21 collapse

you generally don’t magically get things like API keys and database credentials from buckets

Oh you underestimate how clueless some people can be. One of the highest priority checks of cloud SOCs is to just routinely scan for public buckets, because people expose (accidentally or intentionally) stuff on their test or sandbox accounts a lot, and it’s not surprising to find keys and secrets in there. Obviously a simple SCP policy of denying API calls to make a bucket public will easily solve this problem, but then again, even big companies screw that up too.