https://pentestmag.com/making-remote-working-safer-through-securing-the-router/

#pentest #magazine #pentestmag #pentestblog #PTblog #remote #work #router #security #cybersecurity #infosecurity #infosec

Amazon S3, one of the leading cloud storage solutions, is used by companies all over the world for a variety of use cases to power their IT operations. Over four years, UpGuard has detected thousands of S3-related data breaches caused by the misconfiguration of S3 security settings. Jeff Barr, Chief Evangelist for Amazon Web Services recently announced public access settings for S3 buckets, a new feature designed to help AWS customers stop the epidemic of data breaches caused by incorrect S3 security settings.

The ongoing cloud security problem for this simple storage service has resulted in tens of millions of breached records. So this is welcome news and a step in the right direction for AWS services, but we don’t think it’s enough.

Bad S3 security is a common target for corporate spies.

The S3 Security Problem
Security researchers, including UpGuard, are constantly discovering open, unprotected S3 buckets containing sensitive data.

Who is responsible for the S3 security problem?
It’s tempting to blame you, the users, for being too lazy or stupid to use S3 properly. We’ve all read about “solutions” to the S3 security problem, including (but not limited to):

Monitoring your S3 buckets using products like AWS Config or UpGuard Core
Building your own S3 monitoring solution using AWS Cloudtrail and Lambda
Command-line testing with tools like S3 Inspector
Using AWS Identity and Access Management (IAM) user policies that specify the users that can access specific buckets and objects
These solutions do work, and we recommend using them to monitor your S3 security posture. To tell you the truth though, it feels a bit unfair. Why should S3 users be forced to spend more money on alternative solutions to resolve a fundamental issue? IAM policies are complicated even for the experienced user.

Our opinion is that the security problem with S3 is one of product design.

Yes, AWS ensures that S3 servers are private by default. Yet we continue to see thousands of open buckets, and regular breaches.

Our view is that AWS has made it far too easy for S3 users to misconfigure buckets to make them totally publicly accessible over the Internet. It’s up to AWS to create better security solutions by default. There are two key product features we’ve highlighted below that can easily trip you up if you’re not careful.

#1: Any Authenticated Users
The concept of “any authenticated AWS users” is a poorly understood feature of S3 and an extremely common misconfiguration. This level of security allows anybody with an AWS account to see inside your buckets.

#2: Inconsistent ACLs and Bucket Policies
Another easily misconfigured feature of S3’s security model is the interplay between ACLs and policies governing buckets and the objects inside them.

Some of the most catastrophic breaches we’ve found caused by people misunderstanding how these settings work together. You can lock down ACLs to an Amazon S3 bucket, but if the bucket policy is misconfigured, then you can still leave your data wide open to the Internet.

What has AWS done to secure S3?
So if you agree that features of the S3 security model are at least partially responsible for leaky buckets, what has AWS been doing to resolve the problem?

Through 2017, AWS announced multiple changes that promised to help:

Providing a “public” flag for open buckets, and an email outreach campaign to owners of those buckets.
The launch of Amazon Macie, which “is a security service that uses machine learning to automatically discover, classify, and protect sensitive data in AWS”.
After the launch of these features, we saw many exposed buckets disappear. But we also saw many more buckets with sensitive information persist, and new ones created since then with sensitive, publicly accessible data.