Amazon S3 (Simple Storage Service) has once again been in the news this year. S3-based security incidents are not new - with examples of misconfigured public buckets dating back to 2017 and before. We've seen a renewed focus on supply-chain attacks with S3, cloud ransomware, and even cryptocurrency attacks leveraging compromised S3 static website hosting.
While not all of the news above directly relates to what we built as an S3 security tool, it prompted us to re-examine the market today for available security tooling.
We found issues with current tooling (and even some recent releases) including false positives, false negatives, and even misleading results due to incomplete understanding of the complex nature of S3 configuration. We cover these example issues in the issue section below.
Thus, we built and open-sourced YES3 Scanner (Yet Another S3 Scanner) to help you with securing your data in S3 including preventing unintended public access, preventing against ransomware, and ensuring additional security settings and safeguards are in place to make it difficult for attackers and for accidental misconfiguration.
GitHub Repository: https://github.com/FogSecurity/yes3-scanner
YES3 scans for 10+ settings on your S3 buckets and AWS account to determine any risks to your S3 infrastructure. For more detail on our reasoning and how we think through S3 and data security, reach out to us at info@fogsecurity.io.
Access Issues such as Public Access
S3 Buckets and Data in S3 can be made public via multiple different mechanisms including access control lists, bucket policies, and bucket website hosting.
YES3 Scanner will alert both on settings and report which buckets are actually public. While each of these settings contribute to "public" settings, the following are the combinations we see as effectively public (and we see as missing in other security tools):
Preventative S3 Security Settings
Certain S3 security settings do not by themselves expose data. However, these controls function as additional layers of security and can prevent a misconfigured ACL or misconfigured bucket policy from exposing data.
Additional Security Settings such as Encryption
Encryption is seen as an additional layer for security. Bucket encryption sets default encryption when encryption is not specified. This does not analyze current encryption of objects in the bucket. For more insights on object encryption, we plan on offering object-level analysis. To sign-up for a private beta, email us at info@fogsecurity.io.
YES3 will report on SSE-S3 bucket encryption as this is transparent encryption. When a principal makes a request to S3 and has permissions on the S3 object, it will also be able to transparently decrypt the object. When an AWS Managed or Customer Managed CMK is used, the principal must also have access to the KMS Key (for example, via the KMS Key policy) as an additional layer of security.
Ransomware Protection, Data Protection, & Recovery
Part of ransomware protection includes the ability to recover from data corruption or data deletion. Bucket Versioning and Object Lock as well as an active backup strategy are S3 provided features that assist with backing up data or preventing data deletion.
S3's bucket lifecycle configuration permits for users to automate data deletion in S3. This has been observed in recent ransomware attacks where malicious actors used bucket lifecycle settings to set files for automatic deletion in 7 days along with their ransomware demands.
YES3 will report on:
Note: Your use cases may require different settings, we recommend using this as guidance and checking what the best settings are for your specific architecture. If you have a different backup strategy defined with data, that can also be a strategy for protecting against ransomware and assisting with a recovery strategy.
We found issues with current tooling (and even some recent releases) including false positives, false negatives, and even misleading results due to incomplete understanding of the complex nature of S3 configuration.
While we won't go into all of the details of the current market, here's a few examples that demonstrate how current tooling can lead to potentially disastrous representations of your data security in AWS - when you may think your data is secure when reality is different.
False Negatives
False negatives where security posture is reported as ok when it is potentially insecure was found in one tool with the following:
False Positives
False positives where security posture is reported as insecure but in reality are ok was found in a tool with the following:
False positives can lead to wasted time and inefficiency with security teams. Additionally, they can lead to loss of trust within an organization both for tooling and for security teams.
Misleading or Incomplete Results
Some of the tools and security frameworks we found were limited in the approach and reporting of security posture. These included issues such as:
yes3.py --profile <your_profile_here> --region <region_specifier>Note: YES3 will use sts get-caller-identity to check the AWS Account. This API call does not require any additional IAM Permissions.
Sample Output:
YES3 SCANNER RESULTS
----------------------------
AWS Account: 123412341234
Account Settings
Account Block Public Access Overall Status: OK
----------------------------
Bucket Summary
Total Buckets: 14
----------------------------
Buckets potentially public: 3
fog-pub-sample-bucket | Public Method: ['acl']
fog-pub-sample | Public Method: ['policy', 'acl]
fog-pub-policy-sample | Public Method: ['policy']
----------------------------
Buckets with Access Issues: 1
sample-locked-bucket
----------------------------
Buckets with default S3-Owned Encryption: 6
Buckets with a Block Public Access setting disabled: 3
Buckets with Bucket ACLs Enabled: 2
Buckets with ACLs set to public: 0
Buckets with Bucket Policy set to public: 1
Buckets with Object Lock disabled: 5
Buckets with Versioning disabled: 4
Buckets with Lifecycle Config Set to Expiration: 1
Buckets with Public Access from Website Setting: 0
----------------------------
Additional Bucket Details
Buckets with default S3-Owned Encryption: sample-bucket-1, sample-bucket-2, sample-bucket-3, sample-bucket-4, sample-bucket-5, sample-bucket-6
Buckets with a Block Public Access setting disabled: sample-bucket-1, sample-bucket-2, sample-bucket-3
Buckets with Bucket ACLs Enabled: sample-bucket-1, sample-bucket-2
Buckets with ACLs set to public:
Buckets with Bucket Policy set to public: sample-bucket-1
Buckets with Object Lock disabled: sample-bucket-1, sample-bucket-2, sample-bucket-3, sample-bucket-4, sample-bucket-5
Buckets with Versioning disabled: sample-bucket-1, sample-bucket-2, sample-bucket-3, sample-bucket-4
Buckets with Lifecycle Config Set to Expiration: sample-bucket-7
Buckets with Public Access from Website Setting:
With YES3 Scanner, we hope that you can say YES to feeling good about your S3 security posture and data security. We're continuing to build in this space with more to come on object-level data security in S3, different services, and ransomware protection. Reach out to us at info@fogsecurity.io if you want more information on what we're building in this space and if we can help you solve any problems with cloud ransomware protection and data security!
Fog Security: Ransomware in Amazon S3: SSE-C
Fog Security: The Complete Guide to Cloud Native Ransomware Protection in Amazon S3 and KMS
Fog Security: Amazon S3 Block Public Access Bypass
Amazon S3: The Meaning of Public
Plerion Blog: S3 Encryption doesn't work the way you think it works
