Summary
The challenge started with the web page accepting cmd parameter with only env command input. The output of the environment included AWS_ACCOUNT_ID and AWS_ROLE. After obtaining the credentials with assume-role, listing the available S3 buckets and the flag is read. For this challenge, we got the first blood and were the only solvers.
Solving the challenge
Identifying AWS_ACCOUNT_ID and AWS_ROLE, we constructed the arn with the identified information. The reconstructed arn is:
aws:iam::134345785945:role/S3Assumption
Since this information is public and the challenge title is hinting toward assumption, we tried to assume and obtain temporary security credentials that can be used to access AWS resources on the behalf of the role S3Assumption. These temporary credentials included an access key ID, a secret access key, and a security token. More on AWS role Assumptions can be found at docs.aws.amazon.com/cli/latest/reference/st...
The command to obtain the credentials are:
aws sts assume-role --role-arn arn:aws:iam::134345785945:role/S3Assumption --role-session-name dummy
After getting the security credentials, the keys are exported within the environment variables.
Since the role had S3 in its name, we tried to list the available S3 buckets.
Now, the objects within the buckets are listed and after flag.txt is identified, the file is downloaded and submitted.
Remedy
- The trusted policies for IAM roles should never be public. If you have specific reasons to give your AWS access to the client, AWS Cognito is the correct way.
- Role names and AWS Account ID should be managed via instance profile or execution role instead of environment variables