IAM Credentials

Every call to AWS is authenticated in some form. For the API, this is typically done through Request Signing (opens in new tab). However, when using the AWS console you log in using a more traditional username/password combination. In this room, we'll dive into the various ways you authenticate to AWS and best practices for securing your AWS account and passwords.

Select the Cloud details button at the top of the room:

Where needed generate the environment required for the room. The "Generate Environment" button will appear if the room contains an environment that needs to be generated. 

For any issues with the environment, select the "Reset Environment" button. Review this article for more information.

To view the credentials required for the environment, select the credentials tab. You can use these credentials to access the environment in various ways. More information can be found here:

Please note: This task is informational only. The email address is not provided for the Root Account.

The first set of credentials we will discuss is the most powerful - the login password for the Root Account (opens in new tab). This is the password you create when signing up as an AWS Customer for the first time. There are very few limits on what the root user can do, so this password should be secured. If your AWS account was created before 2017, this password is also your Amazon Retail password, so be careful when sharing your Amazon Retail password with family and friends.

If you use AWS Organizations and created the AWS account via the CreateAccount (opens in new tab) API call, then the root password is a randomly generated string. AWS doesn’t return that password when an account is created via AWS Organizations. To log in as root, you will need to do a password reset.

To login as root or reset the password, you must use the main AWS Sign In page: https://signin.aws.amazon.com/signin (opens in new tab). There you will be prompted to log in as an IAM User or the Root User:

The AWS Console uses the term "Console Password" while the AWS CLI and APIs use LoginProfile.

To grant an IAM User access via the AWS console, you can do it from the user's Security Credentials tab (opens in new tab) or via the AWS CLI.

           user@machine$ aws iam create-login-profile --user TryHackMe-IAM-User --password 'SolarWinds321!'
{
    "LoginProfile": {
        "UserName": "TryHackMe-IAM-User",
        "CreateDate": "2022-06-20T18:27:13+00:00",
        "PasswordResetRequired": false
    }
}
        

aws iam update-login-profile --user TryHackMe-IAM-User --password 'SolarWinds123!'

AWS allows an account administrator to set a rudimentary password complexity policy. You'll find this setting in IAM under "Account Settings (opens in new tab)" or via the CLI with

aws iam get-account-password-policy

AWS Access Keys are the primary method of interacting with the AWS API. Even the AWS Console uses access keys on the back end. You’ll be able to see this when we dive into our room on CloudTrail.

There are two types of access keys: Long Term and Temporary Session keys.

Long-term access keys begin with the string AKIA. They do not expire but it’s best practice to rotate them regularly. Long-term keys consist of an Access Key Id and a Secret Access Key. Only IAM Users or the Root User can have long-term access keys; however, best practice is to never generate access keys for the Root User. The Root User or an IAM User can only have two Access Keys at one time. You cannot set the access key id or secret, they are always generated by AWS.

Long-term access keys can be active or inactive. You can disable an AWS Access Key via this command:

aws iam update-access-key --access-key-id AKIA... --status Inactive

aws iam update-access-key --access-key-id AKIA... --status Active

aws iam delete-access-key --access-key-id AKIA...

Session keys have an expiration date, after which they are no longer valid. Session keys also have an Access Key Id and a Secret Access Key, but they also have a long Session Token. The Session Key ID begins with ASIA. As they are temporary, AWS Session keys cannot be deleted or disabled like the long-term keys.

Trivia: IAM has many different Identifiers, which are documented here: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-unique-ids (opens in new tab)

Long-term credentials can be created via the AWS Console or the AWS CLI:

           user@machine$ aws iam create-access-key --user-name student
{
    "AccessKey": {
        "UserName": "student",
        "AccessKeyId": "AKIAZOHYLBQBCGG27LF5",
        "Status": "Active",
        "SecretAccessKey": "akSn+o2+CwfnREDACTED6C/0",
        "CreateDate": "2021-10-26T11:02:05+00:00"
    }
}
        

Short-term keys are only provided when requested, and there are numerous ways AWS can provide those. They are generated by the AWS Security Token Service, abbreviated “sts”

The most basic way is via GetSessionToken:

           user@machine$ aws sts get-session-token
{
    "Credentials": {
        "AccessKeyId": "ASIAZOHREDACTEDOJ",
        "SecretAccessKey": "mcvRgtwn1REDACTEDREDACTEDREDACTEDyDfznWA",
        "SessionToken": "IQoJb3JpZ2luX2VjENz//////////wEaCXVzLWVhc3QtMSJIMEYCIQCZS9B06rbR/
        t6re+MkJs6f4cDK0acByMniyQDNRpVFtAIhANdebzglsesOZsXDRE/
        wLLzD3OKChXGFGgT5zt42jtIiKusBCHQQABoMNyAG8b8kAOGzGHPW1XNzjUgc8Sa94neKMHC578wOwg0KaY0FEOpTFTI1/
        dL7DYfXiK65GoY6Km7/QQfGHpbua3YFcS0P90d39o0WEm3v0SrF5IfCINcp060sT16vuXCS3bMwgeDcfk9PEGErC0cE+gktoX/
        NQjhtLmPrfh7KZO+T7Lo1WfzT584FQR34XV0ZoZjBNL/QruFWdk=",
        "Expiration": "2021-10-26T23:12:49+00:00"
    }
}
        

AWS supports using a Virtual MFA (opens in new tab) (TOTP (opens in new tab)), Hardware token (opens in new tab), or U2F Security Key (opens in new tab) (the last two links are the Amazon Retail pages for the products). MFA can be applied to either an IAM User or the Root User. When using an identity federation to assume an IAM Role, implementing MFA is the responsibility of the identity provider.

When MFA is applied to an IAM User or the Root User, AWS will require the second factor when performing a console login. MFA is not required by default when making an AWS API call using access keys. However, IAM Policies can implement conditions to require MFA. To do this, the user must first request temporary credentials and pass the MFA token as part of the request. The new temporary credentials will have a flag that says MFA was present when they were created, and the IAM Policy Condition will be satisfied.

Mishandling of AWS Credentials is the primary way an AWS Account is compromised. There are several best practices for handling AWS Access Keys that you should follow:

1. Avoid using IAM Users where ever possible. Many cloud providers offer the ability to use SAML or OIDC to get session credentials for AWS API access. 
2. NEVER commit an access key to a source code repository (GitHub, GitLab, etc.). GitHub will scan all commits (opens in new tab) to public repositories for any AKIA and notify AWS, who will promptly disable the key. But even private repositories can be compromised, and attackers know to look for the AKIAs in source code and configuration files.
3. Rotate Access Keys often. When creating an access key, you have the option to download the credentials as a CSV file. These CSV files collect in Download folders. If machines are not properly cleansed when decommissioned or a laptop is left in a taxi cab, these credentials can find themselves for sale on the dark web.
4. Use MultiFactor Authentication for access to the Root and IAM Users.

Many of the IAM Identifiers (opens in new tab) can be useful from a reconnaissance perspective. For example, AKIA strings, while not sensitive, can be used to identify an AWS Account with the following command:

aws sts get-access-key-info --access-key-id AKIAEXAMPLE

As we noted in the section on IAM Roles, AWS Services can also leverage temporary credentials to access resources in your account. The Role’s Assume Role Trust document must specify the service as a Principal allowed to assume the role.

The mechanics for getting those credentials vary depending on the service. But when you’re attacking or defending cloud infrastructure, knowing how to get these credentials is vital.

The Primary way to get credentials for a role is with the AWS STS AssumeRole API Call (opens in new tab) or the aws sts assume-role (opens in new tab) AWS CLI command.

If you’re using an EC2 Instance, there is a special network address in the hypervisor you can use to request temporary credentials for the EC2 Instance Profile. It was through this Instance MetaData Service (IMDS) that the Capital One breach was executed. In a future room, we will show you how a curl to 169.254.169.254 will present temporary AWS Access Keys. As a response to the Capital One incident and outcry from the cloud security community, AWS released the IDMSv2 (opens in new tab) which requires a two-step session based method.

If your code is running in AWS Lambda (opens in new tab), the Access Key ID, Secret Access Key, and Session Token are available as environment variables (opens in new tab).

For ECS Containers (opens in new tab), there is another IP address you can curl for the container’s credentials:

curl 169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI

The $AWS_CONTAINER_CREDENTIALS_RELATIVE_URI environment variable is populated if IAM Roles for Tasks is configured.

Finally, you can get temporary credentials from your CloudShell (opens in new tab) with this simple command:

curl $AWS_CONTAINER_CREDENTIALS_FULL_URI -H "X-aws-ec2-metadata-token: $AWS_CONTAINER_AUTHORIZATION_TOKEN"