A time travel paradox in the title is a good place to start a blog post, don’t you think? You don’t yet know the things you need to know so you can’t wish you didn’t need to know them. There is a solution though – Read this blog post. This all started because Plerion is trying to build a comprehensive risk model for the most severe data breaches occurring in AWS environments. At the top of the list is unauthorized access to S3 buckets. Here are some examples in the media.
As with many things AWS security, the more one digs into the details the more oddities one discovers. None of these oddities are new but they all get regularly rediscovered with great surprise. I thought I’d make a list to maybe lessen the surprise for people in the future, and probably future me as well.
S3 Buckets are the S3 API
Amazon S3 was one of the first services released by AWS so it’s incredibly robust and well tested. It also means it has a history predating standardized design patterns, resulting in a quirky API relative to other services. One of those quirks is that a relatively small part of the API requires HTTP requests to be sent to generic S3 endpoints (such as s3.us-east-2.amazonaws.com), while the vast majority of requests must be sent to the URL of a target bucket.
For example, to list the contents of a bucket, the HTTP request looks something like: `GET /[bucket_name] HTTP/1.1`
To get the tags associated with a bucket: `GET /[bucket_name]/?tagging HTTP/1.1`
Remember, some operations can be performed without authentication, making it critical to properly configure your S3 bucket policies. A poorly set policy can lead to serious security risks such as anonymous deletion of buckets.
AWS S3 Architecture
Unauthorized Access & Security Flaws
Because S3 buckets can be both public and private, it's sometimes tricky to determine which API operations are accessible without authentication. Unauthorized access can lead to anonymous CloudTrail entries, making it difficult to trace back actions like deletion or configuration changes. This means extra precautions are necessary when configuring bucket policies to avoid unintentional data exposure.
Public Example Resources:
https://[bucketname].s3.amazonaws.com/?logging
https://[bucketname].s3.amazonaws.com/?tagging
https://[bucketname].s3.amazonaws.com/?encryption
ListObjects Is Not the Only Way to List Object Keys
There are at least two ways to get object keys without using ListObjects:
`GET /?versions` – Provides metadata about all versions of the objects.
`GET /?uploads` – Lists in-progress multipart uploads.
In the context of significant security issues, these endpoints can be exploited if not correctly configured. Don't rely solely on denying the `s3:ListBucket` operation for securing your buckets.
Edworking is the best and smartest decision for SMEs and startups to be more productive. Edworking is a FREE superapp of productivity that includes all you need for work powered by AI in the same superapp, connecting Task Management, Docs, Chat, Videocall, and File Management. Save money today by not paying for Slack, Trello, Dropbox, Zoom, and Notion.
Incomplete Multipart Uploads - Schrodinger’s Objects
Multipart uploads can be tricky. Parts of an incomplete multipart upload remain in your Amazon S3 account until the upload is either completed or terminated. For full transparency, you'll need to use commands like `ListMultipartUploads` or navigate to the URL directly to see ongoing uploads. Lifecycle rules are recommended to automatically delete unfinished uploads after a set period, to avoid unnecessary storage costs.
A Diagram of Multipart Uploads
Security Insights & Bucket Policies
AWS access control lists can expose bucket access permissions based on email addresses. This feature, although useful, can also leak information about the existence of AWS accounts associated with the given email addresses.
Moreover, each object in Amazon S3 has a storage class defined by the uploader. This choice impacts the performance and storage costs associated with the object. Ensuring proper IAM policies can mitigate the risks of unexpected charges.
Clever Uses and Exploits
Beware of key sensitivity in S3; object keys are case-sensitive, which can cause confusion and security issues if not handled properly. For instance, ‘jeff’ and ‘JEFF’ are two different keys. Storage classes, tagging, and permissions are often controlled by the uploader and not the bucket, leading to potential unforeseen charges and security breaches.
Additionally, some peculiar methods can be used to make a bucket public, like setting up a CloudFront distribution or using AWS Cognito identity pools with self-registration and guest access options. These methods allow broad access to S3 buckets which might not be flagged by security tools.
If you’ve come this far, you now know the ins and outs of misconfigurations within S3 that could lead to substantial security headaches.
Remember these 3 key ideas for your startup:
Meticulously Configure S3 Bucket Policies: Pay extra attention to S3 bucket policies to avoid unauthorized access. Even minor oversight can lead to serious security breaches.
Lifecycle Rules for Multipart Uploads: Implement lifecycle rules to manage incomplete multipart uploads, thus preventing unnecessary storage costs and potential breaches.
Case Sensitivity and Object Control: Understand that S3 keys are case-sensitive and uploader-driven settings (like storage class, tags, permissions) can have significant cost and security implications.
By staying ahead of these quirks, you can protect your startup from potential hazards and focus on what you do best - innovate and grow.
Edworking is the best and smartest decision for SMEs and startups to be more productive. Edworking is a FREE superapp of productivity that includes all you need for work powered by AI in the same superapp, connecting Task Management, Docs, Chat, Videocall, and File Management. Save money today by not paying for Slack, Trello, Dropbox, Zoom, and Notion.
For more details, see the original source.
