Upon accessing the URL of the provided lambda function in the challenge, we obtain an aws_access_key_id, an aws_secret_access_key, and an aws_session_token. These can serve as temporary credentials, enabling the execution of diverse actions on AWS via the AWS CLI. To preserve these credentials, they can be stored within the ~/.aws/credentials file, subsequently establishing a default profile for accessing various stuff in the corresponding AWS account.
1 2 3 4 5 6 7
[default] aws_access_key_id = redacted
aws_secret_access_key = redacted
aws_session_token=redacted
Let’s get started by fetching details about the IAM entity corresponding to these credentials.
1
aws sts get-caller-identity
This gives us the role name role_for-lambda-to-assume-role. Let’s proceed by retrieving some information about this role.
1
aws iam get-role --role-name role_for-lambda-to-assume-role
Here, we quickly spot that there’s a permission boundary attached to this role.
According to AWS docs, a permission boundary uses an AWS or customer managed policy to restrict access to resources that can be accessed by an IAM entity. It is nothing but a policy. We can view information about this policy through its ARN by running the following command.
1
aws iam get-policy --policy-arn arn:aws:iam::743296330440:policy/permission-boundary_restrict-assumptions
The version id holds paramount significance in this response. This version id can be utilized in conjunction with the policy arn to extract the policy document.
In this context, it is evident that the policy grants permission for sts:AssumeRole on the specified resource arn:aws:iam::*:role/role_to_secretsmanager_read_flag, contingent upon the condition that the external id is set to nullcon-external-id. Now, let’s carry out this operation within the account provided in the challenge description, namely 562778112707.