📌 AWS Under the Hood — Day 10 — How to Revoke Temporary IAM Credentials if they are Exposed 📌

No one wants to face this scenario, but unfortunately, it’s common to encounter situations where IAM credentials are accidentally exposed to the Internet. This creates a significant security risk, as unauthorized users could gain access to AWS resources and services. How to fix the issue depends on whether the exposed credentials are permanent user credentials (access and secret keys) or temporary credentials obtained through the Security Token Service (STS) by assuming an IAM role.

Let’s take a look at both of the scenarios.

1. Permanent IAM User Credentials (Access and Secret Key): Some of the immediate actions we can take

• When you detect exposed credentials, the first step is to take immediate action. Deactivate the exposed credentials and issue new ones. This proactive measure prevents unauthorized use of the old credentials, giving you control over the situation.
• Review and Audit: Check AWS CloudTrail and other logging services to review any actions performed using the exposed credentials. This helps understand the extent of the potential breach.
• Implement Policies: If the compromised credentials can’t be immediately rotated, adjust IAM policies to restrict what they can access.

Under the Hood:

• When permanent IAM credentials are used to make a request, AWS authenticates and authorizes the request based on the attached IAM policies. If these credentials are exposed and misused, the unauthorized user can perform any action that the credentials are authorized to do.
• Credential rotation involves issuing new credentials and updating all systems and services that use the old credentials. Once rotated, the old credentials should be deactivated and eventually deleted

2: Temporary Credentials via STS: Some of the immediate actions we can take

• Short Lived by Nature: Since STS credentials are temporary, they expire after a set duration (the expiration time can be as short as 15 minutes and typically does not exceed 12 hours(1-hour default duration)). Knowing this can limit the window of opportunity for misuse.
• Revoke Sessions: If the role session can be identified, it might be possible to revoke the session to invalidate the temporary credentials immediately.
• Review and Audit: Like with permanent credentials, you should review logs to see what actions were performed using the temporary credentials.

Under the Hood:

• Temporary credentials obtained through STS include the access key, secret access key, and a session token. All three must be included in requests to AWS services.
• When a request is made using these credentials, AWS verifies the session token, checks the expiration time of the credentials, and then proceeds with normal access and authorization checks against IAM policies.
• If the credentials are compromised, their expiration naturally limits the damage, but it’s still crucial to act quickly to minimize any potential misuse.

NOTE: It’s not possible to cancel or manually expire a set of temporary credentials. They remain valid until they naturally expire.

Revoking IAM role temporary security credentials

1. Sign in to the AWS Management Console and open the IAM console at https://console.aws.amazon.com/iam/.
2. In the navigation pane, choose Roles, and then choose the name (not the check box) of the role whose permissions you want to revoke.
3. On the Summary page for the selected role, choose the Revoke sessions tab.
4. On the Revoke sessions tab, choose Revoke active sessions.

5: AWS asks you to confirm the action. Select the I acknowledge that I am revoking all active sessions for this role. check box and choose Revoke active sessions on the dialog box.

6: IAM then attaches a policy named AWSRevokeOlderSessions to the role. After you choose Revoke active sessions, the policy denies all access to users who assumed the role in the past as well as approximately 30 seconds into the future. This future time choice takes into account the propagation delay of the policy in order to deal with a new session that was acquired or renewed before the updated policy is in effect in a given region. Any user who assumes the role more than approximately 30 seconds after you choose Revoke active sessions is not affected

Consider a scenario where an EC2 instance assumes a role in accessing an S3 bucket. Now, with the AWSRevokeOlderSessions policy added, we can manually initiate a credential refresh by detaching and then reattaching the instance profile from the EC2 instance. This process will force the EC2 instance to obtain a new set of temporary credentials, enhancing security.

Ref: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html

• Detach the Current Instance Profile (AWS CLI):

aws ec2 disassociate-iam-instance-profile --association-id iip-assoc-1234567890abcdef0

• Reattach the Instance Profile or a New One:

aws ec2 associate-iam-instance-profile --instance-id i-1234567890abcdef0 --iam-instance-profile Name=YourInstanceProfileName

Overall, swift action, thorough auditing, and implementing better security practices to prevent future incidents are key to dealing with exposed IAM credentials.

📚 If you’re interested in more in-depth explanation of these topics, please check out my new book “Cracking the DevOps Interview” https://pratimuniyal.gumroad.com/l/cracking-the-devops-interview

📚 To learn more about AWS, check out my book “AWS for System Administrators” https://www.amazon.com/AWS-System-Administrators-automate-infrastructure/dp/1800201532