AWS
AWS accounts can be accessed programmatically by using an Access Key ID and a Secret Access Key.
Amazon Security Token Service (STS) allows us to utilise the credentials of a user that we have saved during our AWS CLI configuration. We can use the get-caller-identity call to retrieve information about the user we have configured for the AWS CLI. Let's run the following command:
aws sts get-caller-identity
IAM: Users, Roles, Groups and Policies
Amazon Web Services utilises the Identity and Access Management (IAM) service to manage users and their access to various resources, including the actions that can be performed against those resources. Therefore, it is crucial to ensure that the correct access is assigned to each user according to the requirements. Misconfiguring IAM has led to several high-profile security incidents in the past, giving attackers access to resources they were not supposed to access. Companies like Toyota, Accenture and Verizon have been victims of such attacks in the past, often exposing customer data or sensitive documents. Below, we will discuss the different aspects of IAM that can lead to sensitive data exposure if misconfigured.
IAM Users
A user represents a single identity in AWS. Each user has a set of credentials, such as passwords or access keys, that can be used to access resources. Furthermore, permissions can be granted at a user level, defining the level of access a user might have.
IAM Groups
Multiple users can be combined into a group. This can be done to ease the access management for multiple users. For example, in an organisation employing hundreds of thousands of people, there might be a handful of people who need write access to a certain database. Instead of granting access to each user individually, the admin can grant access to a group and add all users who require write access to that group. When a user no longer needs access, they can be removed from the group.
IAM Roles
An IAM Role is a temporary identity that can be assumed by a user, as well as by services or external accounts, to get certain permissions.
IAM Policies
Access provided to any user, group or role is controlled through IAM policies. A policy is a JSON document that defines the following:
What action is allowed (Action)
On which resources (Resource)
Under which conditions (Condition)
For whom (Principal)
Consider the following hypothetical policy
This policy grants access to the AWS user Alice (Principal) to get an object from an S3 bucket (Action) for the S3 bucket named my-private-bucket (Resource).
Enumerating Users
Alright, let's see what we can do with the credentials we got from Sir Carrotbane's office, since we have already configured them in our environment. We can start interacting with the AWS CLI to find more information. Let's begin by enumerating users. We can do so by running the following command in the terminal:
Enumerating User Policies
Policies can be inline or attached. Inline policies are assigned directly in the user (or group/role) profile and hence will be deleted if the identity is deleted. These can be considered as hard-coded policies as they are hard-coded in the identity definitions. Attached policies, also called managed policies, can be considered reusable. An attached policy requires only one change in the policy, and every identity that policy is attached to will inherit that change automatically.
Let's see what inline policies are assigned to Sir Carrotbane by running the following command.
Great! We can see an inline policy in the results. Let's take note of its name for later.
Maybe, Sir Carrotbane has some policies attached to their account. We can find out by running the following command.
Hmmm, not much here. Perhaps we can check if Sir Carrotbane is part of a group. Let's run this command to do that.
Looks like sir.carrotbane is not a part of any group.
Let's get back to the inline policy we found for Sir Carrotbane's account. Let's see what permissions this policy grants by running the following command (replace POLICYNAME with the actual policy name you found):
So, it looks like Sir Carrotbane has access to enumerate all the different kinds of users, groups, roles and policies (IAM entities), but that is about it. That is not a lot of help getting TBFC's access back. We might need to try something different to do that. If you look carefully, you'll notice sir.carrotbane can perform the sts:AssumeRole action. Maybe there's still hope!
Enumerating and Assuming Roles
The sts:AssumeRole action we previously found allows sir.carrotbane to assume roles. Perhaps we can try to see if there's any interesting ones available. Let's start by listing the existing roles in the account
Bingo! There's a role named bucketmaster, and it can be assumed by sir.carrotbane. Let's find out what policies are assigned to this role. Just as users, roles can have inline policies and attached policies. To check the inline policies, we can run the following command.
There is one policy assigned to this role. Before checking that policy, let's see if there are any attached policies assigned to the role as well.
Looks like we only have the inline policy assigned. Let's see what permissions we can get from the policy.
Well, what do we have here? We can see that the bucketmaster role can perform three different actions (ListAllBuckets, ListBucket and GetObject) on some resources of a service named S3. This might just be the breakthrough we were looking for. More on this service later.
Assuming Role
To gain privileges assigned by the bucketmaster role, we need to assume it. We can use AWS STS to obtain the temporary credentials that enable us to assume this role.
This command will ask STS, the service in charge of AWS security tokens, to generate a temporary set of credentials to assume the bucketmaster role. The temporary credentials will be referenced by the session-name "TBFC" (you can set any name you want for the session). Let's run the command:
The output will provide us the credentials we need to assume this role, specifically the AccessKeyID, SecretAccessKey and SessionToken. To be able to use these, run the following commands in the terminal, replacing with the exact credentials that you received on running the assume-role command.
Setting the Temporary Credentials to Assume Role
Once we have done that, we can officially use the permissions granted by the bucketmaster role. To check if you have correctly assumed the role, you can once again run:
aws sts get-caller-identity
This time, it should show you are now using the bucketmaster role.
S3 Enumeration
Amazon S3 stands for Simple Storage Service. It is an object storage service provided by Amazon Web Services that can store any type of object such as images, documents, logs and backup files. Companies often use S3 to store data for various reasons, such as reference images for their website, documents to be shared with clients, or files used by internal services for internal processing. Any object you store in S3 will be put into a "Bucket". You can think of a bucket as a directory where you can store files, but in the cloud.
Now, let's see what our newly gained access to Sir Carrotbane's S3 bucket provides us.
Listing Contents From a Bucket
Since our profile has permission to ListAllBuckets, we can list the available S3 buckets by running the following command:
There is one interesting bucket in there that references easter. Let's check out the contents of this directory.
Hmmm, let's copy the file in this directory to our local machine. This might have a secret message.
Last updated