Recent months have seen a number of high profile breaches such as the OneLogin breach that resulted from compromised access keys. In these instances, the affected organizations failed to meet their obligations to prevent unauthorized access as required by the shared responsibility model. While deactivating or deleting a compromised access key seems like the most appropriate response, it is insufficient to contain a breach.
In this blog post, the RedLock Cloud Security Intelligence (CSI) team will demonstrate a scenario where a malicious actor can continue to access an environment and raise his/her privileges, even after the compromised access key has been deleted. In addition, AWS access key security best practices are provided to prevention circumvention upon key deletion.
Consider an IAMUser aws-victim whose access key has been compromised by an attacker.
- The attacker proceeds to configure his AWS CLI to use these credentials. This can be verified by running ''aws sts get-caller-identity'' command.
- Let’s assume that he creates an EC2 instance which assumes a high privileged role with production permissions.
- Then he proceeds to create temporary security credentials using the AWS Security Token Service. These credentials are valid for a period of time ranging from 15 mins to 36 hours based on the parameters used when requesting the tokens. In this example, the attacker uses 36 hours.
- Now let’s assume that an administrator discovers that the access key has been compromised and proceeds to delete the access key.
- The attacker is now unable to access the account using the compromised access keys.
- In response, the attacker changes the aws credentials to the temporary one that he had obtained earlier. He can once again perform certain actions as aws-victim user such as starting/stopping EC2 (Amazon Elastic Compute Cloud) instances, accessing data in Amazon S3 (Simple Storage Service) buckets, etc.
- However, there are some actions that the attacker cannot perform directly. Example: he cannot get the list of AWS users associated with the account.
- Now the attacker could start the production EC2 instance that he had created earlier and SSH into it to perform privileged activities.
Note: For security reasons, the IAMUser aws-victim has been deleted and the keys used in this example are no longer valid.
Security Best Practices
One of the following security best practices are recommended to address the issue:
- The ideal solution is to delete the IAMUser, if possible.
- If the above is not possible, add a policy for the IAMUser that denies access using temporary security credentials created before a specific time such as current date and time.
- If neither of the above are possible, attach a "deny all" policy to the IAMUser for 36 hours which is the maximum amount of time that temporary security credentials can be valid for.
To get 14 other tips to fortify your AWS environment, download the RedLock CSI research report.