Introduction

When I started getting into AWS pentesting, one of the hardest things to fully understand was IAM. AWS documentation is usually great, but can be extensive, and IAM has a lot of similar terms. You have users, roles, groups, managed policies, inline policies, instance roles, etc…

This article will try to shine some light on the subject, as well as some ways to enumerate this information with different tools.

Warning: the post will contain only theory, I’ll publish a write up with practical examples about this next week, but you’ll need the knowledge in this one before the “fun” one.

Later Edit: Heres the link to the practical example writeup which I was talking about

Theory

AWS defines IAM as a way for you to manage access to AWS services and resources securely. It all comes down to permissions. IAM is a way of managing permissions to access your cloud resources. This permissions are assigned to entities. Entities are things to which you can assign permissions to. There are 3 possible entities in IAM:

• Users
• Groups
• Roles.

A user is a representation of the person or service who interacts with AWS.

A group is a collection of IAM users.

Both of these concepts are fairly intuitive, and similar to the ones found in other environments such as Active Directory.

A role similar to a user, in that it’s an identity with permission policies that determine what the identity can and cannot do in AWS. However, a role does not have any credentials (password or access keys) associated with it. Instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it. (source: https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html)

Most of these definitions come from AWS’s official documentation. But here’s where it gets a little more complicated. You assign permissions to entities through policies. Policies come in two flavours:

• Managed policies
• Inline policies (think of them as unmanaged policies)

The difference between them is that Managed policies are stand alone policies, defined on their own. They are not associated with any specific entity, and they can be attached to multiple entities.

Inline policies (or unmanaged policies) are policies that are embedded in an IAM identity (a user, group, or role). The policy is an inherent part of the identity. It cannot be assigned to any other entities. Think of them like a specific attribute of an entity.

Managed policies are recommended over Inline policies because they are easier to manage and audit. You can have a thousand users with the same managed policy, and one change on the policy would affect them all. You would only have to audit that one policy. If you had inline policies for each user, you would have to audit 1000 different policies, and you wouldn’t have a way of modifying all at once.

#pentesting #red-team #infosec #security #devops