One of the best ways to lower your AWS bill by 99 percent or more is by not checking your keys into public GitHub repositories. Many of us have done this inadvertently over the years, and the defenses against it have improved dramatically (my personal favorite being "using non-ephemeral credentials derived from OIDC or SSO is an anti-pattern"), but it still happens.

On Friday, BleepingComputer reported on a Truffle Security finding that hundreds of leaked AWS keys are root keys and are somehow still active and valid.

AWS Security is full of very smart people who care deeply about a number of things, including "not abetting crime." If they detect (usually via automated means) that a credential has been leaked, they're quick to apply a Quarantine Policy to it. Trouble is, that policy enumerates a bunch of bad behaviors in an ever-expanding graph of principals and associated behaviors.

AWS' considered position on this is that they don't want to break customer environments: "The policy aims to limit the potential damage that may be caused by fraud-related activity leading to unauthorized charges, while not impacting the existing resources."

AWS' considered position on this is wrong.

If I get access to your credentials (much less a root credential, good god), deactivating them may very well break your workload because anything that relies on those credentials will start failing. Until you rotate them, those workloads will continue to fail. That's not good!

But I promise you, as a bad actor, I can do far worse to you.

Hold my tea

Go ahead and apply a quarantine policy to a credential set and toss it my way. I won't be able to buy savings plans, read your S3 data, modify Lambda functions, and do a host of other things.

But here's what I can do.

• Anything I damn well feel like on RDS. You don't have anything important in databases, right?

• ssm:SendCommand / ssm:StartSession are permitted, which means I can run commands as root on EC2 instances, which will in turn invoke with that instance role’s permissions.

• sts:AssumeRole means that I can assume any other role in the account and get its permissions, rendering the entire restriction list potentially moot.

• I can use autoscaling:CreateAutoScalingGroup / UpdateAutoScalingGroup to launch instances via the Auto Scaling service-linked role, so the ec2:RunInstances deny never applies.

• cloudtrail:LookupEvents gets denied (that'll stop you from... reading the audit log), but I can call both cloudtrail:StopLogging and DeleteTrail which do exactly what you expect; you don't have an audit log anymore.

• SES denies ses:GetSendQuota / ListIdentities actions, but y'know what's missing? SendEmail, so I can blast my spam out to your entire list.

• sns:GetSMSAttributes means I can't get your SMS configuration, but I can absolutely sns:Publish to send fraudulent text messages wherever I'd like.

• s3:DeleteObject gets denied, but s3:PutObject is allowed. I can't delete your data, but I can fill a bucket to petabytes.

• Next, they fail to block s3:PutBucketVersioning, s3:PutObjectLockConfiguration, s3:PutObjectRetention, and s3:PutObjectLegalHold. So on any existing bucket, like that one I just stuffed petabytes into, I can enable versioning, turn on Object Lock, and set a bucket-default COMPLIANCE-mode retention out to 2126, or alternatively slap it on per object. COMPLIANCE retention can't be shortened or removed by anyone, including the account root and AWS Support. The only way to remove it is to delete the entire AWS account.

• secretsmanager:GetSecretValue, ssm:GetParameter* (WithDecryption), and kms:Decrypt are all unencumbered, so your secrets are now my secrets. Sharing is good! 

• Backups are important, so it's a shame you don't have any. Well, not after I kick off backup:DeleteRecoveryPoint / DeleteBackupVault, and rds:DeleteDBSnapshot. 

• If you're using CloudFormation, and for some things you almost certainly are, cloudformation:DeleteStack going unmentioned means you're not using it anymore and all of your stacks are gone.

I would make different choices

This isn't a comprehensive list - just a few things that occurred to me over the course of about an hour. I'm not a bad actor; I'm almost positive that I'm missing a whole bunch.

AWS is almost certainly going to change this. My question for them is simply, "how big of a customer incident needs to happen before you do?" ®