AWS Quarantine Policy Criticized for Insufficient Protection Against Leaked Root Keys
Hundreds of leaked AWS root keys remain active, with a critical security researcher arguing AWS's quarantine policy is insufficient to prevent destructive actions.
A recent finding by Truffle Security has revealed that hundreds of leaked AWS root keys are still active and valid, despite AWS's automated systems detecting their exposure. This situation has drawn sharp criticism from security experts who argue that AWS's implemented 'Quarantine Policy' for leaked credentials falls short of adequately protecting customers from malicious actors.
AWS Security employs automated means to detect leaked credentials, typically from public repositories like GitHub, and applies a quarantine policy to limit potential damage. The stated aim of this policy is to "limit the potential damage that may be caused by fraud-related activity leading to unauthorized charges, while not impacting the existing resources." However, security researcher Corey Quinn argues this approach is fundamentally flawed, as deactivating credentials, even with a quarantine policy, can break legitimate customer workloads until they are rotated.
Quinn highlights that while the quarantine policy restricts certain actions such as buying savings plans or modifying Lambda functions, it leaves a significant number of dangerous capabilities unchecked. Attackers can still perform highly destructive actions, including running arbitrary commands on EC2 instances via ssm:SendCommand, assuming other roles within the account using sts:AssumeRole which can render the entire restriction list moot, and launching new instances via autoscaling services to bypass ec2:RunInstances denials.
Furthermore, the policy fails to prevent attackers from disabling critical security logging and auditing functions. While cloudtrail:LookupEvents is denied, cloudtrail:StopLogging and DeleteTrail are permitted, meaning attackers can effectively erase audit logs. Similarly, while ses:GetSendQuota is blocked, SendEmail remains available, allowing for the dispatch of spam to customer lists. The policy also permits sns:Publish, enabling the sending of fraudulent text messages.
Perhaps most concerning is the policy's inability to prevent attackers from permanently locking data in S3 buckets. While s3:DeleteObject is denied, s3:PutObject is allowed, enabling attackers to fill buckets with data. Crucially, the policy does not block actions like s3:PutBucketVersioning, s3:PutObjectLockConfiguration, s3:PutObjectRetention, and s3:PutObjectLegalHold. This allows attackers to enable versioning, turn on compliance-mode Object Lock with retention periods extending to 2126, or apply it per object, making data irremovable by anyone, including account root and AWS Support, without deleting the entire AWS account.
Other unhindered actions include accessing secrets manager values and SSM parameters with decryption, deleting backup recovery points and database snapshots, and deleting CloudFormation stacks. Quinn suggests that this list is not exhaustive and that a more robust approach is needed, questioning AWS's commitment to customer security until a major incident forces their hand.
The implications of these findings are significant for any organization utilizing AWS. The continued viability of leaked root keys, coupled with a quarantine policy that permits extensive destructive capabilities, presents a clear and present danger. Organizations must remain vigilant in credential management, implement robust rotation policies, and critically evaluate the security measures provided by cloud providers.