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.
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.
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.