Hundreds of AWS root keys, some of which are still active and valid, have been discovered in public GitHub repositories, according to a recent finding by Truffle Security. While AWS Security typically applies a "Quarantine Policy" to leaked credentials, this policy has been criticized for not fully deactivating compromised keys, potentially leaving customer environments vulnerable to significant damage.
AWS's stated rationale for the Quarantine Policy is to limit fraud-related activity and unauthorized charges without disrupting existing customer resources. However, critics argue that this approach is flawed, as a compromised credential, especially a root key, can still be exploited by malicious actors in numerous ways, even if some actions are restricted.
Analysis of the Quarantine Policy reveals several critical permissions that remain active. For instance, an attacker can perform arbitrary actions on Amazon RDS databases, run commands as root on EC2 instances via `ssm:SendCommand` or `ssm:StartSession`, and assume other roles within the account using `sts:AssumeRole`, potentially bypassing many restrictions.
Furthermore, attackers can launch instances through the Auto Scaling service-linked role using `autoscaling:CreateAutoScalingGroup` or `UpdateAutoScalingGroup`, circumventing `ec2:RunInstances` denials. While `cloudtrail:LookupEvents` is denied, `cloudtrail:StopLogging` and `DeleteTrail` are permitted, allowing an attacker to erase audit logs.
Email and SMS services are also at risk. Although `ses:GetSendQuota` and `ListIdentities` are denied, `SendEmail` is not, enabling attackers to send spam. Similarly, `sns:Publish` is allowed, facilitating the sending of fraudulent text messages.
Data manipulation and destruction are also possible. While `s3:DeleteObject` is denied, `s3:PutObject` is allowed, meaning an attacker can fill buckets with petabytes of data. Crucially, `s3:PutBucketVersioning`, `s3:PutObjectLockConfiguration`, `s3:PutObjectRetention`, and `s3:PutObjectLegalHold` are not blocked. This allows an attacker to enable versioning, turn on Object Lock, and set a bucket-default COMPLIANCE-mode retention for up to 100 years, which cannot be shortened or removed by anyone, including the account root or AWS Support, effectively making the data undeletable without deleting the entire AWS account.
Sensitive information stored in Secrets Manager and SSM Parameter Store is also vulnerable, as `secretsmanager:GetSecretValue`, `ssm:GetParameter*` (with decryption), and `kms:Decrypt` are all unencumbered. This means an attacker can access customer secrets.
Backup and recovery mechanisms can also be compromised. `backup:DeleteRecoveryPoint`, `DeleteBackupVault`, and `rds:DeleteDBSnapshot` are permitted, allowing attackers to delete backups. CloudFormation stacks are also at risk, as `cloudformation:DeleteStack` is not explicitly denied, potentially leading to the deletion of all customer stacks.
The continued activity of these root keys and the permissive nature of the Quarantine Policy raise concerns about the potential for widespread damage to customer environments. While AWS is known for its security expertise, the current policy is seen by some as an insufficient response to leaked credentials, potentially requiring a significant customer incident to prompt a change in approach.
