A quick and CTF from Cybr.com that teaches and demonstrates how to priv esc through changing versions and then exfiltrate data from an S3 bucket. Although simple, it’s quite effective and dangerous; let’s see how a small slip-up turns into a major headache.
After a few minutes of waiting for the lab to load up, we are presented with keys/username. They change every time and as you can see there is a time limit too.
Let’s configure our profile and then check the policies attached to our user:
The 2nd command only tells us which policies are attached to the user, let’s run another command to see which permissions are granted to us through this policy:
Now, we can actually see what permissions are granted to us through this (V1) and let’s check to see if there are any others with higher privileges:
There we go, we have a winner in V4! Definitely higher privs than what we’re working with and if you’re new to AWS, it’s worth checking out what this policy declares and its components such as: Effect, Action, and Resource.
One item to mention in V1:
“iam:SetDefaultPolicyVersion”
Now, let’s see what happens if we change V1 to V4:
The first command is showing our current version, then we run the set-default-policy-version command, effectively changing it to V4, and then re-running the 1st command again to verify our version rollback.
Not quite finished yet, we did see a policy for S3 and with our new privs, we can do a lot with Get*/List* perms on all resources; let’s see how many buckets we’re working with:
Great, let’s take a peep inside and exfiltrate data:
And would you look at that, we have a breach on our hands! Of course this is just a hypothetical/easy example; however, there have been a number of major hacks/leaks due to this and I’m sure there’s another around the corner.
Major S3 Leaks:
https://github.com/nagwww/s3-leaks
Again, it’s easy to quickly setup/forget configurations/policies/permissions when you have so many and have to do deal with so many. That’s why it’s essential for periodic audits/checks to ensure this is found by you, and not someone else.
Mitigations:
Putting this instance inside a private subnet of a VPC that’s inaccessible to the internet. Then you can create a private link, using site-to-site VPN/Transit Gateway/Direct Connect and access your resources.
Deleting other versions of policies.
S3 Bucket: Implementing least priv, with security in mind from the start to end of project lifecycle. Manual/Automated scans for misconfigurations, encrypting everything (transit/rest), mind the contents you’re storing; is it sensitive? Does it really need to be on a S3 bucket? Enabling MFA, object locking (uses a write once/read many model and protects from unwanted changes/removals), and unless you’re really keeping an eagle eye and have good reason, do not freely use “*”
Awesome Resource:
https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/
Had a lot of fun with this and several of other courses from Cybr and looking forward to more.
