News
Yet Another Misconfigured AWS S3 Bucket Exposes Sensitive Customer Data
The years-long problem of misconfigured S3 storage buckets on the Amazon Web Services (AWS) cloud computing platform has surfaced again, exposing sensitive data from customers despite tons of warnings, guidance, documentation and advice from AWS and other providers.
“We have identified a significant operation that scanned millions of websites, exploiting vulnerabilities in improperly configured public sites,” reads a Dec. 9 post on the vpnMentor site. “This incident resulted in the exposure of sensitive keys and secrets, granting unauthorized access to customer data.”
The incident was uncovered and reported to vpnMentor by independent cybersecurity experts Noam Rotem and Ran Locar.
The stolen data was stored in an S3 bucket left open due to a misconfiguration by its owner, ultimately being used as a “shared drive” between the attackers.
The researchers discovered the operation in August 2024, after which AWS Security was notified because many victims were AWS customers. AWS Security reportedly handled the issue as of Nov. 9, 2024.
The AWS Security team clarified that the security incident was not an AWS infrastructure issue but a customer-side responsibility under the shared responsibility model. The attackers exploited application-level errors, not AWS infrastructure, to access customer-managed data.
The post came with the mandatory guidance to avoid such breaches:
- The first thing any system operator should do is make sure they NEVER have hard-coded credentials in their code or even in their filesystem. AWS provides excellent services (such as the “AWS Secrets Manager”) to store sensitive credentials, and with proper CI/CD processes in place, there is absolutely no need to have passwords and keys in places that might be accessed by unauthorized parties.
- It is also advisable to run simple web-scans using open source tools like “dirsearch” or even “nikto”, which are often used by lazy attackers to identify common vulnerabilities — that way, if something was left exposed, you have a chance at finding it before malicious actors do.
- In addition, using a WAF (Web Application Firewall) is a relatively low-cost solution that can filter out malicious attempts to get sensitive information.
- As a precaution against leakage of keys, passwords, or other secrets, it is advisable to roll them periodically. That way, even if a malicious actor has obtained access to your keys, they will be rendered useless after the roll period (See AWS documentation).
- CanaryTokens are tripwires for your secrets. They are easily created and can be sprinkled around your code in places nobody should access. If a canary gets triggered, it means someone is attempting to access secrets they shouldn’t.
That guidance joins official documentation from AWS including Security best practices for Amazon S3 that’s full of configuration advice.
All of that advice and guidance doesn’t seem to be having much effect, though, judging from a smattering of articles throughout the years:
Though the issue seems to have peaked in 2017, the fact that it keeps happening some seven years later is a testament to the difficulty of securing cloud-based resources, especially when they’re misconfigured by customers.
The researchers acknowledged as much.
“Unfortunately, though, there is no silver bullet,” they said. “Security is a process that requires continuous effort. However, by implementing even the minimum measures mentioned above, you can avoid being the lowest hanging fruit and getting caught in the dragnet of these operations.
“Attackers are often lazy and will focus on the easier targets. Unless they have incentives to focus on a specific target, they will pick on the easiest one. As a wise man once said: when running away from a bear, you don’t need to be the fastest. You just need to make sure you aren’t the slowest.”
