flAWS.cloud — A fun interactive way to learn the basics of AWS Security — Part 1 — S3 Shenanigans
flaws.cloud is a fun AWS CTF made by Scott Piper from Summit Route. Scott always has interesting info and projects to share, check him out.
A couple months back I got stuck into another one of his projects called Parliament, an IAM policy linter for CloudFormation. I wrote a wrapper that uses it to lint IAM policies in Terraform. It was a pretty fun exercise, and the code is possibly going to get Checkov, a great tool which I’m also using in our GitHub Actions CI pipeline for our AWS Infra code. It’s working great and I also recommend both of them. But I digress. This post is about flaws.cloud.
This is a review and walkthrough. If you’re the sort of person who enjoys learning by doing (as do I) then I encourage you to just go do flaws.cloud yourself right now — it’s fun, rewarding and educational.
Topics Covered
- AWS CLI Intro — Credential profiles, listing s3 buckets
- S3 bucket configuration
- IAM credential usage intro
- Git secret retrieval (and cleanup)
- EBS snapshot inspection & forensics
- EC2 Instance Profile Metadata Attack (the Capital One incident)
- Recon of API Gateway and Lambda
However if you’re short on time, non-technical, or simply lazy, then welcome to my walkthrough.
Level 1
What can we find out about this site?
Let’s check the DNS
Possibly the owner has set up a reverse DNS / PTR record
And, sure enough visiting the URL tells its s3
So it’s an s3-hosted website. It’s pretty reasonable to guess the bucket is called something like “flaws.cloud”. Let’s try:
Let’s have a look inside that secret file:
And there we have the URL to Level 2
My solution here wasn’t actually the intended one; we were meant to visit http://flaws.cloud.s3.amazonaws.com/ to get a directory listing via the web instead of the CLI. Both methods rely on the same fundamental misconfiguration; the bucket ACL allowed Everyone toRead.
There’s one main technical difference: logging.
Logging for the website access requires the bucket to have “Server access logging” enabled, which writes access logs to another s3 bucket.
The CLI access wouldn’t show up there; that would require “Object-level logging” (using CloudTrail) to be configured for the bucket.
Which one of these is more likely to be enabled depends on who and why the bucket was set up; I’d guess if the owner is using s3 to host the site, they’re more likely to have just Server access logging setup. However if the bucket contains more important material (and likely, the web hosting was unintentional), Object access logging is more likely to be configured.
Either way it’s very likely your IP and access to these items would be recorded, and would in the real world be recommended to be done via TOR (where only the US Navy know what you’ve done :) or a VPN.
Level 2
There’s a good little writeup on what we learnt from the previous Level:
Turns out Level 2 is pretty-much the same as level 1 (actually exactly the same, if you use the CLI again):
Level 3
OK, standard drill, let’s try listing the bucket:
Looks pretty similar to before right? But there’s one important entry there that should make your nerdo-senses tingle: .git
We can pull those files down and inspect that git repo:
Sure enough, in the commit history, we can see that Scott has accidentally committed AWS keys to his repo, before removing them in a later commit:
This is actually a very common mistake, and there are now many good tools to both 1. Prevent and 2. Remediate this situation.
Indeed, GitHub now by-default scans commits for such mistakes.
Let’s do a quick demo of remediating such a mistake.
Bonus Digression: Cleanup with BFG
For remediation — my go-to (and recommended by GitHub) is BFG.
You can install it on OSX using Homebrew: brew install bfg
or on Windows with Chocolatey: choco install bfg-repo-cleaner
We put the strings we want to remove (our secrets) in a text file e.g. “my-soon-to-be-rotated-secrets.txt”:
And run BFG:
Then we just copy and past that reflog command, and sure enough our secrets are removed from the repo:
So, let’s use those keys to list other S3 buckets:
Juicy. It looks like we can skip to the final level — let’s try it:
Aaahhh cheeky.
I’ll put these creds in my ~/.aws/credentials for future use, like so:
Well, the level 4 site we can see in the listing does work. Continued in my next post, flAWS.cloud Walkthrough — Level 4 …
This is part of my 4-part Walkthrough of flaws.cloud:
