Scenario đź§Ş
Difficulty: Beginner
Objective: ⛳️ You’ve successfully completed this challenge once you’ve accessed and decoded a secret API key stored in Secrets Manager.
Description: You work for a cloud pentesting consulting firm, and you’ve been hired by Serious Corp to find vulnerabilities in their IAM configurations.
This is a grey box operation, and you’ve been given credentials to a lower-privileged IAM user named Adam, but you do not have any architectural diagrams of how the environment is configured or laid out.
In reviewing internal documentation that you were granted access to, you notice that there is an employee named Emma who is in charge of running the infrastructure within this particular AWS environment used to host internal apps and resources. You also noticed that Emma uses a role named AppManagement to perform most of her job functions in that AWS environment. She does that by assuming this role and using that role’s permissions to access resources in AWS. Finally, you learn that the organization uses Amazon Secrets Manager to store secret values, including secret keys for access to internal and sensitive APIs.
Given the provided credentials, look for IAM Privilege Escalation paths that will give you permissions to access secrets within this environment’s Secrets Manager storage.
Hints
Hint #1: Unlike the labs throughout this course that focused on a single exploit at a time, this challenge will require chaining two or more exploits together. All of the exploits and techniques that you need have been covered in this course — there isn’t anything new. For convenience, here’s a checklist of exploits we learned about that could potentially be useful for this challenge (you only technically need two and some in this list will not work):
- AddUserToGroup
- AttachUserPolicy
- AttachGroupPolicy
- AttachRolePolicy
- PutRolePolicy
Hint #2: Remember to start with enumeration. You need to get a lay of the land to understand what’s going on in that specific AWS environment and what you have access to.
As you enumerate, ask questions like:
- Am I part of a group? If so, what permissions does that group give me? (Remember that groups can have both inline and attached policies which are retrieved with different commands)
- Do I have any inline policies that give me additional permissions?
- Is there a boundary policy applied to the user? Even if you can’t see that policy, it could explain why you don’t have access that you think you should have
- Are there other groups in this AWS account? Do those groups have different permissions?
- Can I change my permissions with something like SetDefaultPolicyVersion, AddUserToGroup, PutUserPolicy, etc…?
- Knowing the role’s name from the scenario, and knowing that Emma uses that role to do her job, how can I use that to my advantage?
Hint #3: The secret value is encoded and needs to be decoded, but this will be easily done with online tools 🙂
A great challenge, one thing that i like about this one is that we can check our PermissionsBoundary policies details and they will come handy in a sense that later on, you can see which given policies overlaps with the ones that are whitelisted for us that helps us narrow down our approach.
HINTS:
[challenge: Secrets Unleashed]
[LIST-USER-INLINE-POLICIES]
[LIST-GROUP]
[LIST-GROUPS-FOR-USERS]
[LIST_INLINE_GROUP_POLICIES]
[LIST_ATTACHED_GROUP_POLICIES]
[LIST-ROLES]
[GET-GROUP-INLINE-POLICY (INFRA)]
EXPLOIT STARTS HERE>>>
(with elevated privilidge u can list roles now)
[ATTACH-ROLE-POLICY]
[ASSUME-ROLE]
[AWS-CONFIGURE PROFILE]
[LIST-SECRETS]
[GET-SECRET-VALUE]
[DECODE]
I’ve been banging my head off a wall for the past 2 days trying to solve this while on nightshift. First day off, solve it in 10 minutes. Great challenge!!
Love this! Great job persevering. Hope others seeing this who don’t get it the first time get motivated to keep trying!