Beyond the basics: techniques every pentester should know to exploit AWS Infrastructure — Part 1/X

Published in

Decathlon Digital

10 min readNov 27, 2023

Introduction

Amazon Web Services (AWS) is a leading cloud computing platform used by millions of organizations worldwide, including Decathlon. It is crucial for security teams to have a deep understanding of the different AWS services, vulnerabilities, how to exploit them, as well as how to fix them.

This article aims to provide a comprehensive overview of the techniques that every pentester and security team should know to exploit AWS infrastructure beyond the basics. We will cover reconnaissance, exploitation, and post-exploitation techniques, as well as mitigation strategies to help AWS users protect against attacks. By understanding these techniques, pentesters can better assess the security of AWS infrastructure, and security teams can take steps to secure their systems and protect against potential attacks.

Thank you Romain Ego, Daniel Polombo and the whole CyberSecurity Team at Decathlon :)

Initial access aka what a pentester needs to understand

1) AWS IAM: THE topic

Well … The extent of AWS is such that it takes several years to master the authentification management …. However, we will try to give you a summary.

As a pentester, it’s important to have a deep understanding of AWS IAM and its capabilities. We need to be familiar with how to identify and exploit IAM-related vulnerabilities, such as weak access control policies, misconfigured roles, and over-permissive permissions … but before identifying vulnerabilities or misconfiguration, we have to understand IAM associated concepts.

Let’s start with identities and principals

a) Identities and Principals

An identity refers to an entity that can be authenticated and authorized to access AWS resources. Examples of identities include IAM users, roles, groups, and AWS accounts root users themselves.

Principals, on the other hand, are the entities that can be authenticated and authorized to perform actions on AWS resources. A principal can be an AWS account or an identity within an account, such as an IAM user, role, or group. When a principal attempts to access an AWS resource, AWS checks the permissions associated with the principal to determine whether the requested action is allowed.

We will give real world misconfiguration examples in the next section

b) Policies

In AWS, policies are documents that define permissions for identities and resources. Policies can be identity-based, resource-based, SCPs, Permission Boundaries, … More info here. It’s important to note that policies are used to grant permissions, but also to limit them (with SCPs, Permissions Boundaries or Deny statement for example)

Identity-based policies are attached to an IAM identity (such as an IAM user, group, or role) and specify what actions the identity can perform on AWS resources. Identity-based policies are used to grant permissions to specific users or roles.

For example, an identity-based policy might be used to grant an IAM user the ability to create and delete objects in an S3 bucket.

Here’s an example of an identity-based policy that grants an IAM user permission to read objects from an S3 bucket:

Resource-based policies, on the other hand, are attached directly to an AWS resource (such as an S3 bucket or an SNS topic) and specify what actions are allowed on that resource.

Resource-based policies are used to grant permissions to entities that need access to a specific resource.

For example, a resource-based policy might be used to grant access to an S3 bucket to an AWS Lambda function.

Here’s an example of a resource-based policy that allows a specific AWS Lambda function to access an S3 bucket:

One example of AWS identity misconfiguration is granting excessive permissions to a user or role within an AWS account.

Here is an example of a misconfigured IAM policy that could lead to unintended access to AWS resources:

This policy grants the Allow effect for all S3 and EC2 actions on all resources within the AWS account. This means that any user or role associated with this policy will have full access to all S3 buckets, EC2 instances, and most of the network components in the account. The policy is too broad and violates the principle of least privilege, as it grants excessive permissions that may not be necessary for the user or role to perform their intended job functions.

A better approach would be to limit the Action and Resource statements in the policy to only what is necessary for the user or role to perform their specific tasks. For example, if the user only needs to manage a single S3 bucket, the policy could be modified as follows:

This policy grants the Allow effect for the GetObject and PutObject actions on the my-bucket S3 bucket, but implicitly denies access to all other S3 buckets and EC2 instances in the account. By limiting the scope of the policy to only what is necessary, it reduces the risk of unintended access to sensitive resources in the account.

In summary,

Identity based policies are like: What does this entity has access to
Resource based policies are like: Who has access to this resource

But in all cases, it’s important to note that both can be combined. For the same user, a S3 bucket can be accessed through an identity-based policy when another S3 bucket through its resource-based policy at the same time.

Also, AWS documentation provides a flow of how IAM permissions are evaluated. It is one of the key concept of AWS and demonstrates its power

c) Roles, Trust relationships and permissions

Now, let’s discuss about roles, trust relationships, and permissions.

In AWS, a role is a way to delegate permissions to access AWS resources to entities that are not associated with an AWS account, such as an IAM user or an AWS service. A policy defines a set of permissions that determine what actions the role can perform and what resources the role can access. Roles are similar to IAM users in that they can be granted permissions to access AWS resources. However, roles are not associated with a specific user or group, and instead can be assumed by any entity that has been granted permission to do so. The entity can be internal (another role, or a user) or external (another entity from another AWS account, or even a Github repository through and AWS OIDC provider)

From https://d2908q01vomqb2.cloudfront.net/22d200f8670dbdb3e253a90eee5098477c95c23d/2017/09/06/RM1-0917-diagram-b.png

The trust relationship defines which principals (accounts or users for example) are allowed to assume the role.

Permissions are the actions that a principal is allowed to perform on AWS resources.

d) AWS Access key

An AWS access key is a set of credentials that allow a user or application to access and use the services provided by AWS. It consists of an access key ID and a secret access key, and are used to authenticate and authorize API requests to AWS services.

IAM uses the following prefixes to indicate what type of resource each unique ID applies to.

When possible, using temporary credentials (STS, ASIA**** keys) is better than using long-term credentials (AKIA****).

It is important to never share or store access keys in unencrypted files, as this could lead to unauthorized access and compromise of sensitive data. Additionally, access keys should be rotated regularly to reduce the risk of compromise. Overall, the proper use and management of AWS access keys is crucial for maintaining the security of AWS resources and data.

e) Assuming a role

Assuming a role on AWS means temporarily taking on the permissions and access rights assigned to a specific AWS IAM role. When an IAM user or application assumes a role, it gains access to the AWS resources and services that are associated with that role, based on the permissions and policies assigned to it.

For example, an application running on an EC2 instance may need to access data stored in an S3 bucket. Rather than providing the application with direct access to the S3 bucket using its own security credentials, a role can be created with the necessary permissions to access the S3 bucket. The application can then assume the role to gain temporary access to the S3 bucket, without needing to manage its own security credentials.

2) How do I mix all this up and connect to the CLI?

AWS provides an official CLI command, and it requires an AWS credential to login. You can use either an access key/secret key or use saml2aws to generate AWS temporary credentials using a SAML IDP.

Anyway, if you already have an access key/secret key, open your terminal, install the CLI, then type aws configure

Enter the access key and secret key

Once you have entered your Access Key ID, Secret Access Key, region, and output format, aws configure will store this information in a configuration file on your local machine (~/.aws/credentials). You can then use the AWS CLI to run commands against your AWS resources.

You can also use “aws configure sso and “aws configure sso-session” commands to configure your profile

The challenge for a pentester (or OPS) is to be able to connect to several accounts easily without having to reconfigure. The key is to set up profiles for each AWS account that you want to connect to.

Let’s assume first you are using saml2aws.

You can check the ~/.aws/config and create manually/programmatically all the profiles.

To test the profile, you can use the AWS CLI with the — profile option, like this:

This will authenticate you with the “pentest-account1” profile and list the contents of the S3 bucket in that account.

If you are using AWS Access Key, specify the AWS access key and secret access key to each profile

Environment variable provide another way to use a profile.

Just use in your terminal:

3) Bonus: AWS Security Token Service (STS)

The AWS Security Token Service (STS) is a web service that enables you to request temporary security credentials for accessing AWS resources.

As a pentester, there are several important aws sts commands that you should be familiar with, but the two more important one are below

aws sts get-caller-identity: This command returns information about the IAM user or role that is making the request. Image if you find an AWS Access Key in the wild and would like to test it. It’s like a “whoami” in Linux (thanks Daniel for the ref ;) )

Then run tools to enumerate permissions … but we will deep dive this topic later on

aws sts assume-role: This command enables you to assume a role and obtain temporary security credentials that are associated with the role. This can be useful for testing and verifying role-based access controls (RBAC) in AWS environments.

Below more commands

aws sts get-session-token: This command enables you to obtain temporary security credentials for an IAM user or role, without requiring long-term access keys. This can be useful for testing and verifying multi-factor authentication (MFA) and temporary access controls.
aws sts decode-authorization-message: This command enables you to decode and view authorization messages that are included in AWS requests. This can be useful for understanding how AWS policies are evaluated and how access decisions are made.
aws sts get-federation-token: This command enables you to obtain temporary security credentials for federated users who are authenticated using SAML or OpenID Connect (OIDC). This can be useful for testing and verifying federated identity controls.

Do not forget to add the — profile behind your command ;)

Here the end regarding AWS IAM. It’s a very important topic that you need to master. We’ve only scratched the surface of what IAM is at AWS, so feel free to take a look at the AWS documentation, which is really exhaustive.

More to come like reconnaisance technique or exploitation on AWS ;).

Practice labs

Feel free to test your knowledge with these different labs:

We already (and will continue) to use these practices labs during our TechSecurity events.

It is a good way to educate our users (Security Champions and even our OPS team) without requiring time-consuming preparation.

Stay tuned

How about you?

Do you have experience using AWS? Do you have some additional recommendations? Let us know in the comments below!

🙏🏼 If you enjoy reading this article, please consider giving it a few 👏👏👏

If you are interested in joining Decathlon Tech Team, check out our carriers portal to see the different exciting opportunities ! 👩‍💻👨‍💻