THM - Advent of Cyber [Day 17]
Sometimes users in an enterprise network, in an effort to get their job quicker or get around security implementations in the production network, will use public cloud based services to get their job done quicker. This is obviously not best practice, and even has a name, Shadow IT. This is what today’s task is all about. Specifically we’ll be taking a look at AWS S3 (Simple Storage Solution) and AWS IAM (Identity and Access Management). The neat thing about AWS is that it’s hosted in so many different regions, giving it a lot of redundancy.
Amazon S3
AWS S3 is a hosted object storage. Each space is called a bucket. Inside of that you can think about it kind of like a huge dictionary in Python. The objects are key-value pairs, with the key being a file path, and the value being the file itself. The service is public, meaning that every file is public. The namespace is global, so only one person can own any unique name. S3 is a great tool for anything you don’t mind being public, but enterprise IT employees sometimes accidentally put things in their S3 bucket that they shouldn’t, meaning attackers often have access to things they shouldn’t.
One of the ways we can discover the public location of an S3 object is by inspecting or hovering our mouse over assets on company webpages. If you see something like:
http://BUCKETNAME.s3.amazonaws.com/FILENAME.ext
or
http://s3.amazonaws.com/BUCKETNAME/FILENAME.ext
then we can use that to enumerate the companies S3 bucket.
There are two ways to manage buckets:
- S3 ACLs
- Bucket Policies
You can grab information with curl, but then you’d have to parse xml. If you’re a regular human, you can use the aws command.
aws s3 ls s3://irs-form-990/ --no-sign-request
The --no-sign-request option allows us to download without an AWS account.
Authentication in AWS
As you can see, the --no-sign-requests also allows for no auth if the settings allow it.
IAM Access Keys
IAM access keys are a way that you can authenticate to AWS. Leaked keys are often how AWS accounts are compromised. My understanding of the keys are that they are an asymmetrical pair of keys. You can add keys to profiles with the following command:
aws configure --profile PROFILENAME
You can run commands with the profile by running
aws s3 ls --profile PROFILENAME
The task also gives us some good information if to enumerate AWS.
A few other common AWS reconnaissance techniques are:
- Finding the Account ID belonging to an access key:
aws sts get-access-key-info --access-key-id AKIAEXAMPLE - Determining the Username the access key you’re using belongs to
aws sts get-caller-identity --profile PROFILENAME - Listing all the EC2 instances running in an account
aws ec2 describe-instances --output text --profile PROFILENAME - Listing all the EC2 instances running in an account in a different region
aws ec2 describe-instances --output text --region us-east-1 --profile PROFILENAME
It also tells us if we do decide to use AWS, don’t store keys in default profiles. Yes, this forces you to use --profile after every command, but you won’t run something against the wrong profile by accident.
Tasks
Looks like the Grinch got access to the employee database via AWS S3, and we’ve been tasked with figuring out how. If we inspect the image that we’re given, we can see the URL of the bestfestival’s Amazon S3 Bucket.
We can run the command given to us to see what other files are in the bucket:
As you can see there’s a file called flag.txt, which we can use curl against to get the flag for the second question, just remember to use the full domain name.
As for the key that’s exposed in the interesting file. I first tried to grep the directory for aws, but to no avail, after trying with S3 for the key, we get something interesting.
For the next few questions, I found it easiest to make a profile locally using the info I got and then running another command that gets info based on the profile.
The same goes for the next question. We can get the name of the instance by running:
aws ec2 describe-instances --output text --profile PROFILENAME
The last question was the most difficult for me. Finding the right region was the most difficult part. In the end you can run aws configure and reset the location until you find the right one. You’ll also need to use the list secrets command in secretsmanager in order to see the proper secret to call. The commands will look like this:
aws secretsmanager list-secrets --profile AoC
then:
aws secretsmanager get-secret-value --secret-id SECRET_NAME --profile AoC