Solving the AWS Roles Mystery

How to track users when identities can assume other Roles

In the AWS environment, permissions to access your organization’s resources are tied to your identity. This makes your identity incredibly valuable, your keys to the kingdom as it were.

But sometimes, it’s good to be someone else. 

In some cases users need extra permissions to perform their work.

Maybe we need to grant different members of our team higher-level entitlements in order to do maintenance on one of our S3 buckets. They might need to create or delete certain buckets, upload bucket objects, or one of a dozen other tasks that require more expansive permissions than we are normally comfortable giving out to a wider base of users.   

Think about how someone can temporarily become a super user in Linux with the sudo command, and you get the general idea.

The question is how can we manage granting more expansive permissions without running the risk leaving too many users with higher-level entitlements? 

If you are using AWS, then the most straight forward answer might be to utilize Roles.

Who are you today?

AWS allows us to create AWS Roles that act as stand in identities with specific permissions but are not tied to any singular identity. 

They can be useful if a group of folks on our team need to occasionally have more powerful entitlements. Instead of granting and revoking said permissions to each individual on an ad hoc basis, we can give the Role the necessary entitlements and allow our users to utilize this Role to get their job done.     

This way, we can simply add or remove users’ access to the Role, minimizing the overall number of actions required to stick to the Principle of Least Privilege.

We can also chain Roles if necessary to help manage their access. For example, the Role  S3SuperUser might not have any permissions by itself, except the ability to assume two other roles:  S3ReadOnly , and S3Writer . 

In this scenario, in order to read an S3 object, a user would have to assume S3SuperUser, and from there, assume S3ReadOnly.

If this explanation already feels like a game of Three-card Monte, then hold on because we are just getting started.

A Real Game of Who’s Who?

One of the big challenges that security teams can run into when dealing with AWS Roles is in understanding who is responsible for actions taken while assuming one of these S3SuperUser Roles. 

Using CloudTrail, let’s see if we can figure out who did what in our example log for ListUsers event, performed by a role called user_lister .

"eventVersion": "1.08",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROATNJFFGSGUAMD4K4VS:listing_users",

"arn": "arn:aws:sts::122334455612:assumed-role/user_lister/listing_users",
"accountId": "343534635624",
"accessKeyId": "ASIATNJFFGSGUFHFD5EO",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROATNJFFGSGUAMD4K4VS",
"arn": "arn:aws:iam::343534635624:role/user_lister",
"accountId": "343534635624",
"userName": "user_lister"
},
"webIdFederationData": {},
"attributes": {
"mfaAuthenticated": "false",
"creationDate": "2021-02-23T09:31:08Z"
}
}
},
"eventTime": "2021-02-23T09:31:22Z",
"eventSource": "iam.amazonaws.com",
"eventName": "ListUsers",
"awsRegion": "us-east-1",
"sourceIPAddress": "143.196.41.228",
"userAgent": "aws-cli/2.0.40 Python/3.7.4 Darwin/19.6.0 exe/x86_64 command/iam.list-users",
"requestParameters": null,
"responseElements": null,
"requestID": "0d123617-b9d3-484f-9944-ea177753f0ca",
"eventID": "ae5ac097-6b9d-405b-8f58-63afb7e125fa",
"readOnly": true,
"eventType": "AwsApiCall",
"managementEvent": true,
"eventCategory": "Management",
"recipientAccountId": "343534635624"
}

Looking at our log, we can see who took the action and when:

“eventName”: “ListUsers”

“eventTime”: “2021-02-23T09:31:22Z”,

However, you may have noticed that the userIdentity is a little weird:

“arn”: “arn:aws:sts::343534635624:assumed-role/user_lister/listing_users”, 

Based on these findings, we can come to two conclusions:

• An unknown user assumed the Role user-lister
• When assuming a role, you can create a name for the specific session. In this case, the session name was listing_users

This all leaves us back at where we started. Namely not knowing which user is hiding behind the user-lister mask.

But now the game is afoot. 

But who is our mystery user?

In order to get to the bottom of this case, play old school detective –– Clue style.

The setting is a dark and stormy night at a mansion in the countryside. Nobody is who they say they are –– and none are to be trusted. 

And for good reason. In the study is Colonel Mustard’s body laid out, dead as a doornail with the candlestick on the floor next to him.

So who’s dunnit?

Thankfully, we have some help on this case from cameras that got it all on tape. Let’s take a look at our murder scene from the security room.

{
"eventVersion": "1.08",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROATNJFFGSG3A4LNSHWH:wearing_a_mask",
"arn": "arn:aws:sts::343534635624:assumed-role/butler/wearing_a_mask",

"accountId": "343534635624",
"accessKeyId": "ASIATNJFFGSGW7VLBWHC",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROATNJFFGSG3A4LNSHWH",
"arn": "arn:aws:iam::343534635624:role/butler",
"accountId": "343534635624",
"userName": "butler"
},
"webIdFederationData": {},
"attributes": {
"mfaAuthenticated": "false",
"creationDate": "2021-02-23T15:35:11Z"
}
}
},
"eventTime": "2021-02-23T16:23:53Z",
"eventSource": "s3.amazonaws.com",
"eventName": "DeleteBucket",
"awsRegion": "us-east-2",
"sourceIPAddress": "143.196.41.228",
"userAgent": "[aws-cli/2.0.40 Python/3.7.4 Darwin/19.6.0 exe/x86_64 command/s3.rb]",
"requestParameters": {
"bucketName": "colonel.mustard",
"Host": "s3.us-east-2.amazonaws.com"
},
"responseElements": null,
"additionalEventData": {
"SignatureVersion": "SigV4",
"CipherSuite": "ECDHE-RSA-AES128-GCM-SHA256",
"bytesTransferredIn": 0,
"AuthenticationMethod": "AuthHeader",
"x-amz-id-2": "vw1Ot/aW60uTGOY0SuvxXeoi2njV3vIHuEye0WU916R+sAWsVb+2YzSxDp
1Cv0paM5GUeUcWbtc=","bytesTransferredOut": 0
},
"requestID": "7YDN9ZYSC5K59HSW",
"eventID": "05568ed0-b012-4a62-b0f1-aaf285b81de8",
"readOnly": false,
"resources": [
{
"accountId": "343534635624",
"type": "AWS::S3::Bucket",
"ARN": "arn:aws:s3:::colonel.mustard"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"eventCategory": "Management",
"recipientAccountId": "343534635624"
}

Based on this footage, we can confirm that this is in fact Colonel Mustard

"resources": [
{
"accountId": "343534635624",
"type": "AWS::S3::Bucket",
"ARN": "arn:aws:s3:::colonel.mustard"
}
],

And he has definitely kicked the bucket

“eventName”: “DeleteBucket”,

But who is his killer?

"userIdentity": {
"type": "AssumedRole",
"principalId": "AROATNJFFGSG3A4LNSHWH:wearing_a_mask",
"arn": "arn:aws:sts::343534635624:assumed-role/butler/wearing_a_mask",
"accountId": "343534635624",

"accessKeyId": "ASIATNJFFGSGW7VLBWHC",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROATNJFFGSG3A4LNSHWH",
"arn": "arn:aws:iam::343534635624:role/butler",
"accountId": "343534635624",
"userName": "butler"
},
"webIdFederationData": {},
"attributes": {
"mfaAuthenticated": "false",
"creationDate": "2021-02-23T15:35:11Z"
}
}
},

Unfortunately for us, this is hardly the evidence we need to lead us to the murderer. However, we now know that our killer is hiding under an assumed role.

“arn”: “arn:aws:sts::343534635624:assumed-role/butler/wearing_a_mask”,

The only clue that they have left behind to help us identify them is this:

“accessKeyId”: “ASIATNJFFGSGW7VLBWHC”

It’s a bit cliche, but looks like the butler really did do it. This is a good thread to pull on, but we have to dig a bit deeper. We need to find out where and how they put on their butler suit disguise

assumeRole for the butler Role

{
"eventVersion": "1.08",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROATNJFFGSGVIRMC6D5P:wearing_a_mask",
"arn": "arn:aws:sts::343534635624:assumed-role/Prof.Plum/wearing_a_mask",
"accountId": "343534635624",

"accessKeyId": "ASIATNJFFGSGUQJN7I7I",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROATNJFFGSGVIRMC6D5P",
"arn": "arn:aws:iam::343534635624:role/Prof.Plum",
"accountId": "343534635624",
"userName": "Prof.Plum"
},
"webIdFederationData": {},
"attributes": {
"mfaAuthenticated": "false",
"creationDate": "2021-02-23T15:34:55Z"
}
}
},
"eventTime": "2021-02-23T15:35:11Z",
"eventSource": "sts.amazonaws.com",
"eventName": "AssumeRole",
"awsRegion": "us-east-2",
"sourceIPAddress": "143.196.41.228",
"userAgent": "aws-cli/2.0.40 Python/3.7.4 Darwin/19.6.0 exe/x86_64 command/sts.assume-role",
"requestParameters": {
"roleArn": "arn:aws:iam::343534635624:role/butler",
"roleSessionName": "wearing_a_mask"
},
"responseElements": {
"credentials": {
"accessKeyId": "ASIATNJFFGSGW7VLBWHC",
"expiration": "Feb 23, 2021 4:35:11 PM",
},
"assumedRoleUser": {
"assumedRoleId": "AROATNJFFGSG3A4LNSHWH:wearing_a_mask",
"arn": "arn:aws:sts::343534635624:assumed-role/butler/wearing_a_mask"
}
},
"requestID": "10dac48f-4816-4d9f-a5e4-2f5d21150725",
"eventID": "580b45c2-07b1-4938-bbd1-7814d7392056",
"readOnly": true,
"resources": [
{
"accountId": "343534635624",
"type": "AWS::IAM::Role",
"ARN": "arn:aws:iam::343534635624:role/butler"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"eventCategory": "Management",
"recipientAccountId": "343534635624"
}

Pivoting to our camera footage with a view to the hallway, we can see that someone was putting on the butler suit to carry out their crime.

"responseElements": {
"credentials": {
"accessKeyId": "ASIATNJFFGSGW7VLBWHC",
"expiration": "Feb 23, 2021 4:35:11 PM",
},
"assumedRoleUser": {
"assumedRoleId": "AROATNJFFGSG3A4LNSHWH:wearing_a_mask",
"arn": "arn:aws:sts::343534635624:assumed-role/butler/wearing_a_mask"
}
},

We see that this is the same outfit that the murderer was wearing because it has the same accessKeyId

“accessKeyId”: “ASIATNJFFGSGW7VLBWHC”.

But who is the dastardly character wearing it?

"userIdentity": {
"type": "AssumedRole",
"principalId": "AROATNJFFGSGVIRMC6D5P:wearing_a_mask",
"arn": "arn:aws:sts::343534635624:assumed-role/Prof.Plum/wearing_a_mask",
"accountId": "343534635624",
"accessKeyId": "ASIATNJFFGSGUQJN7I7I",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROATNJFFGSGVIRMC6D5P",
"arn": "arn:aws:iam::343534635624:role/Prof.Plum",
"accountId": "343534635624",
"userName": "Prof.Plum"
},
"webIdFederationData": {},
"attributes": {
"mfaAuthenticated": "false",
"creationDate": "2021-02-23T15:34:55Z"
}
}
},

Aha, Professor Plum is our culprit. It’s hardly a surprise given his shady past and everyone knew that he was jealous of Colonel Mustard’s notoriety. 

But wait, this was a bit of misdirection

“arn”: “arn:aws:sts::343534635624:assumed-role/Prof.Plum/wearing_a_mask”

It looks like our clever killer was pretending to be Professor Plum in order to throw us off their trail. We can see their accessKeyId that they used to carry out their crime.

“accessKeyId”: “ASIATNJFFGSGUQJN7I7I”.

The hunt continues as we trace “Professor Plum’s” steps back on our security camera feed to see where they changed into their current costume.

{
"eventVersion": "1.08",
"userIdentity": {
"type": "IAMUser",
"principalId": "AIDATNJFFGSGXIK6EBUXZ",
"arn": "arn:aws:iam::343534635624:user/Dr.Orchid",
"accountId": "343534635624",
"accessKeyId": "AKIATNJFFGSGYYTI3SCK",
"userName": "Dr.Orchid"

},
"eventTime": "2021-02-23T15:34:55Z",
"eventSource": "sts.amazonaws.com",
"eventName": "AssumeRole",
"awsRegion": "us-east-2",
"sourceIPAddress": "143.196.41.228",
"userAgent": "aws-cli/2.0.40 Python/3.7.4 Darwin/19.6.0 exe/x86_64 command/sts.assume-role",
"requestParameters": {
"roleArn": "arn:aws:iam::343534635624:role/Prof.Plum",
"roleSessionName": "wearing_a_mask"
},
"responseElements": {
"credentials": {
"accessKeyId": "ASIATNJFFGSGUQJN7I7I",
"expiration": "Feb 23, 2021 4:34:55 PM",
},
"assumedRoleUser": {
"assumedRoleId": "AROATNJFFGSGVIRMC6D5P:wearing_a_mask",
"arn": "arn:aws:sts::343534635624:assumed-role/Prof.Plum/wearing_a_mask"
}
},
"requestID": "21ab2865-9777-4bc5-987d-48c17b4df3fa",
"eventID": "ad487799-6e6e-4672-8050-6882b61559b2",
"readOnly": true,
"resources": [
{
"accountId": "343534635624",
"type": "AWS::IAM::Role",
"ARN": "arn:aws:iam::343534635624:role/Prof.Plum"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"eventCategory": "Management",
"recipientAccountId": "343534635624"
}

Here we see the person who assumed the role of Prof.Plum with the same accessKeyId as we saw before.

"responseElements": {
"credentials": {
"accessKeyId": "ASIATNJFFGSGUQJN7I7I",
"expiration": "Feb 23, 2021 4:34:55 PM",
},
"assumedRoleUser": {
"assumedRoleId": "AROATNJFFGSGVIRMC6D5P:wearing_a_mask",
"arn": "arn:aws:sts::343534635624:assumed-role/Prof.Plum/wearing_a_mask"
}

Finally, our murderer is revealed.

"userIdentity": {
"type": "IAMUser",
"principalId": "AIDATNJFFGSGXIK6EBUXZ",
"arn": "arn:aws:iam::343534635624:user/Dr.Orchid",
"accountId": "343534635624",
"accessKeyId": "AKIATNJFFGSGYYTI3SCK",
"userName": "Dr.Orchid"
},

Nobody suspected that it would have been the unassuming Dr. Orchard. He always seemed so nice but anyone can have a dark side , I suppose.

Now all that’s left is to call everyone to the lounge and name our killer. 

When it comes to IAM users, not everything is always as it seems on the surface. But by following the breadcrumbs diligently, we can trace back to understand which identities have done their dirty work, even if they assume a clever disguise to throw us off in the wrong direction.

If keeping track of your team’s roles and access policies feels like murder, then Authomize can help. Our automated platform provides full visibility and intelligent insights into the relationship between identities and assets, making it easy to figure out who dunnit.

Talk to us today to learn more about how Authomize can simplify how you manage your identities, access policies, and authorizations. Start now with a FREE 30-day trial.

The post Solving the AWS Roles Mystery appeared first on Authomize.

*** This is a Security Bloggers Network syndicated blog from Authomize authored by Michael Sheinkman. Read the original post at: https://www.authomize.com/blog/solving-the-aws-roles-mystery/