S3 Bucket Security Hardening Using SCP policy
Hi, everyone
My name is Santosh Kumar Sha, I’m a Security researcher/ Security Engineer from India(Assam). In this article, I will be Demonstrating How I was able Hardened the S3 Bucket Security Using SCP policy to reduced the impact and Blast Radius during an Security event or During any Hacked happened.
SPECIAL Note:
This write is note about AWS Best practice for S3 bucket. As Cloud Expert and Security expert, we have already implemented or aware of all the AWS best Practices of s3 bucket like Bucket Versioning, KMS encryption, S3 access log, Bucket policy with list access, Enable Event Notifications, CloudTrail API notification, Cross-Region Replication , Lifecycle policy, MFA delete, Object lock etc.
TOOLS used for the exploitation
- AWS CLI
- Prowler(https://github.com/prowler-cloud/prowler)
Story Behind the Blog:
The Story Behind this writeup was working for Client whose AWS production account hacked and all there s3 bucket containing Data containing critical data was deleted if s3 versioning object data also.
As Client was less technical and don’t want any overload configuration and also want control over all the account while dealing with s3 bucket configuration and s3 bucket changed.
Here it goes:
As initial Setup we have implemented all AWS best practice for s3 bucket in Production account like Bucket Versioning, KMS encryption, S3 access log, Bucket policy with list access, Enable Event Notifications, CloudTrail API notification, Cross-Region Replication , Lifecycle policy, MFA delete, Object lock etc.
But after implement all this, we are still under radar of any security because if prod account attacker/hacker can changed and update all the configuration. So, to prevent attacker/hacker from making any changes to s3 bucket configuration we came up with a Plan use AWS SCP policy to restrict any s3 configuration to prevent the hacker and also to reduce the blast radius of attack and also give control over The client to make any changes to bucket.
SCP overview:
AWS SCP (Service Control Policy) is an AWS Organizations feature that allows you to define fine-grained permissions and limits for your entire organization or individual organizational units (OUs). SCPs let you to manage and regulate permissions for numerous AWS accounts inside your organization from a single location.
First : In-order to restrict disabling/Suspending s3 versioning setting and S3 version object deletion.
S3 versioning is a feature of Amazon S3 that allows you to store several versions of an object in a bucket. Each object in a versioned bucket is assigned a distinct version ID, allowing you to track numerous versions of the same object. This feature enhances data security by storing version history and offering complete version control capabilities. So, in-order to secure s3 version and s3 version object deleting and to prevent any hacker/attacker for hacking changes to bucket we have implemented the below SCP policy and Attached to that AWS production account.(This SCP policy Can be attached to any OU which all implement for All accounts in that OU)
SCP policy for all S3 bucket:
{
“Version”: “2012–10–17”,
“Statement”: [
{
“Sid”: “s3-versioning-and-s3-object-delete-restriction”,
“Effect”: “Deny”,
“Action”: [
“s3:DeleteObjectVersion”,
“s3:PutBucketVersioning”,
“s3:PutObjectVersionAcl”
],
“Resource”: [“*”]}
]
}
The above SCP policy will restrict any user from deleting object versions, changing bucket versioning settings, or changing version ACLs throughout the AWS Account or organizational units (OUs) to which the SCP is applied for any S3 buckets. You can also apply the SCP policy to any specific S3 bucket instead of all bucket by Just providing the ARN of that bucket in Resource field like below.
SCP policy for all S3 bucket:
{
“Version”: “2012–10–17”,
“Statement”: [
{
“Sid”: “s3-versioning-and-s3-object-delete-restriction”,
“Effect”: “Deny”,
“Action”: [
“s3:DeleteObjectVersion”,
“s3:PutBucketVersioning”,
“s3:PutObjectVersionAcl”
],
“Resource”: [“arn:aws:s3:::scpolicyfors3bucket”]
}
]
}
How it work:
After the SCP policy is attached to few AWS account or AWS Organizational Unit. If Any Hacker/attacker tries to delete version object and suspend S3 version using console or AWS CLI command, it will restrict the request/api call from executing.
AWS console View: Trying to delete version object and suspend S3 version.:
Disabling and Deleting:
AWS CLI Command View: Trying to delete version object and suspend S3 version.
Note: Now if Client and developer who want to making any changes in s3 bucket and any s3 bucket configuration changed He/she have to detach the SCP policy from that account using AWS management/Root Account through AWS organization with relevant permission for the Management/root Account.
Lastly: In-order to Hardened S3 Bucket Security you can use the below SCP policy
The SCP policy listed below prohibits many S3 actions for all resources (*) within the AWS organization or organizational units (OUs) to whom the policy applies. The policy specifies the following actions:
- `s3:DeleteObjectVersion`: Denies the deletion of S3 object versions.
- `s3:PutBucketVersioning`: Denies modifying S3 bucket versioning settings.
- `s3:PutObjectVersionAcl`: Denies modifying S3 object version ACLs.
- `s3:PutEncryptionConfiguration`: Denies modifying S3 bucket encryption configuration.
- `s3:DeleteBucketPolicy`: Denies deleting the bucket policy.
- `s3:PutAccessPointPolicy`: Denies modifying access point policies.
- `s3:PutBucketPolicy`: Denies modifying bucket policies.
- `s3:DeleteAccessPointPolicy`: Denies deleting access point policies.
- `s3:DeleteAccessPointPolicyForObjectLambda`: Denies deleting access point policies for Object Lambda.
- `s3:DeleteBucket`: Denies deleting S3 buckets.
- `s3:DeleteObject`: Denies deleting S3 objects.
- `s3:ReplicateDelete`: Denies replicating deletions for S3 replication.
- `s3:PutLifecycleConfiguration`: Denies modifying S3 bucket lifecycle configurations.
- `s3:PutReplicationConfiguration`: Denies modifying S3 bucket replication configurations.
- `s3:PutBucketLogging`: Denies modifying S3 bucket logging configurations.
- `s3:PutBucketObjectLockConfiguration`: Denies modifying S3 bucket object lock configurations.
- `s3:PutBucketNotification`: Denies modifying S3 bucket notification configurations.
- `s3:PutObjectAcl`: Denies modifying S3 object ACLs.
- `s3:PutBucketAcl`: Denies modifying S3 bucket ACLs.
- `s3:DeleteMultiRegionAccessPoint`: Denies deleting multi-region access points.
- `s3:DeleteAccessPoint`: Denies deleting access points.
- `s3:DeleteAccessPointForObjectLambda`: Denies deleting access points for Object Lambda.
This policy effectively prevents these activities from being performed on all S3 resources within the impacted AWS accounts or OUs. Before implementing this policy in your production environment, make sure you thoroughly test and validate it.
Hardened S3 Bucket Security SCP policy:
{
“Version”: “2012–10–17”,
“Statement”: [
{
“Sid”: “”,
“Effect”: “Deny”,
“Action”: [
“s3:DeleteObjectVersion”,
“s3:PutBucketVersioning”,
“s3:PutObjectVersionAcl”,
“s3:PutEncryptionConfiguration”,
“s3:DeleteBucketPolicy”,
“s3:PutAccessPointPolicy”,
“s3:PutBucketPolicy”,
“s3:DeleteAccessPointPolicy”,
“s3:DeleteAccessPointPolicyForObjectLambda”,
“s3:DeleteBucket”,
“s3:DeleteObject”,
“s3:ReplicateDelete”,
“s3:PutLifecycleConfiguration”,
“s3:PutReplicationConfiguration”,
“s3:PutBucketLogging”,
“s3:PutBucketObjectLockConfiguration”,
“s3:PutBucketNotification”,
“s3:PutObjectAcl”,
“s3:PutBucketAcl”,
“s3:DeleteMultiRegionAccessPoint”,
“s3:DeleteAccessPoint”,
“s3:DeleteAccessPointForObjectLambda”
],
“Resource”: [
“*”
]
}
]
}
Takeaway:
The policy effectively prevents the ability to delete S3 object versions, change bucket versioning settings, change object ACLs, change encryption configuration, delete bucket policies, and other activities.
The major lesson from this SCP policy is that it imposes stringent restrictions and limitations on S3 actions to safeguard the organization’s S3 resources’ security, integrity, and compliance. By prohibiting these acts, the policy reduces the risk of data loss, unauthorized access, or policy misconfiguration by preventing unauthorized or inadvertent updates, deletions, or policy changes.
Before deploying the policy in a production environment, it is critical to properly evaluate, test, and validate it to ensure it corresponds with your specific security requirements and organizational goals.
Support me if you like my work! Buy me a coffee and Follow me on Twitter.
LinkedIn Profile: https://www.linkedin.com/in/santoshlegend12tech/
