AWS Identity and Access Management

Introduction

AWS IAM is one of the foundational services in the cloud, responsible to control access to AWS resources in a particular AWS account across the Internet.

During sign up process on AWS, Root user is created automatically and hence they have unrestricted access to all AWS services in that account. Therefore it is vital to have MFA on root account. In addition to this, following are the best practices:

• Disable Root access key for cli usage

• Rotate credentials

• Don't share root user credentials

Hence, for day to day activities, it is not at all recommended to use root account. So what's the solution? AWS provides IAM (Identity and Access Management) service to create users, groups, roles and policies to provide privileges to the AWS cloud account as required, following the principle of least privilege.

As the name suggests, IAM is responsible for Identity and Access which is cooler way of redefining Authentication and Authorization. Under Authentication, Creation and management of identities happens and under authorization, permissions to identities happens.

• When the word "Identities" is written, it represents any of the following:

  • IAM User - Can be a User or an Application

  • IAM Group - can be a collection of IAM Users

  • IAM Role - Used to assign temporary credentials that has privileges to perform and access certain AWS resources; so IAM Users, application or external identities can assume the role.

• When the word "permissions" is used, it usually refers to permissions inside a policy, which is used to do access control (a way for authorization mechanism) for the above identities.

IAM user with Administrative privileges is the 2nd most powerful account that can be used safely instead of root account for day to day privileged operations in the AWS cloud.

Note by default, AWS IAM Identities don't have access to billing console. It needs to be explicitly permitted.

AWS IAM can provide secure access, provide granular control over that access and also ensure that access is temporary. This is all facilitated to AWS IAM Identities, which can be a IAM user or IAM Group or even IAM role.

Account ID and Account Alias

Account ID (which is 12 digit numerical id) is created on its own when one sign-up for AWS. Now, one can simply create account alias which will be bound to account id. Its similar to why DNS is being used. Humans cannot remember numbers, so they need simple names and that is where this comes up.

Once created, the new URL for login for IAM Users can be as follows:

ARN

All resources have unique Amazon Resource Name (ARN)

It is of the following format

arn:partitition:service:region:account-id:resourcetype/resource/qualifier

Note that partition in arn can also be "aws-us-gov" or "aws-cn", if not, it is usually "aws" for most case

Example:

arn:aws:s3::::images-of-football

The reason region and account id are not mentioned in this 
is because s3 is a global service, so no region is required and 
also when region and account is not give, it is assumed that default account
and default region is selected
resource type is also set to default to bucket
resource is images-of-football as this is a bucket arn

arn:aws:ec2:us-east-1:112233445566:instance/i-054dsfg34gdsfg38

Here, one can can see that for ec2, resource type is given as instance
and resource is instance id (i-054dsfg34gdsfg38)

If it ever requires that all instances would have ARN of
arn:aws:ec2:us-east-1:112233445566:instance/*

AWS STS

One of the foundational service for IAM is AWS STS. AWS Security Token Service (AWS STS) is a web service that enables to request temporary, limited-privilege credentials for trusted users in form of tokens that can control access to AWS resources.

The duration of the validity of the token or lifetime of the token can range from 15 mins and go upto 36 hours.

The working of AWS STS can be explained as follows:

Source: https://cloudpatterns.org/wp-content/uploads/2023/03/aws-sts-chart-2.png

Each IAM entity (user, group, or role) has a defined aws:userid variable.

Note that a Session ARN is a unique identifier for a session when a user assumes an IAM role. This session is created when an IAM user or another role assumes a role using the AssumeRole API call.

The Session ARN typically looks like this:

arn:aws:sts::ACCOUNT_ID:assumed-role/ROLE_NAME/SESSION_NAME

AWS Requests

To access a resource, the principal sends a request to AWS with the help of following components:

• Name of the principal that can be IAM User or IAM Role

• Actions or operations to perform

• Resource over which the operation has to be performed

• Resource specific data

• Environment in which the request has to be performed (Specific conditions such as IP if implemented)

A sample of Request and Response made using AWS CLI can look like this:

For those who are interested to know how to intercept AWS CLI Requests in Windows/Linux, here are the steps:

1. Download Burp Certificate and head over to Linux machine or ubuntu wsl and issue the command: openssl x509 -inform der -in path/to/Burp-certificate.der -out /path/to/Burp-certificate.pem

2. copy the contents of .pem file generated in above step.

3. Append the above certificate in "C:\Program Files\Amazon\AWSCLIV2\awscli\botocore\cacert.pem" at the end. Note for linux, the path is "/usr/local/aws-cli/v2/current/dist/awscli/botocore/cacert.pem"

4. Download the AWS-Sig4 Burpsuite extension from Portswigger.

5. Import the keys into the extension.

6. In Windows CMD prompt, use the following commands for Windows/Linux (for particular session):

   • HTTP Proxy

   set HTTP_PROXY=http://127.0.0.1:8080 ORexport HTTP_PROXY=http://127.0.0.1:8080

   • HTTPS Proxy

   set HTTP_PROXY=http://127.0.0.1:8080 ORexport HTTP_PROXY=http://127.0.0.1:8080

7. Finally use awscli commands and it would be intercepted.

8. One can also use this to change User Agent if required