AWS Cloud Development Kit flaw exposed accounts to full takeover

Amazon Web Services has fixed a flaw in its open source Cloud Development Kit that, under the right conditions, could allow an attacker to hijack a user's account completely. The Cloud Development Kit (CDK) is an open source framework, developed by AWS, that allows developers to define cloud application infrastructure as code …

[sitta_europea]

And it occurred to nobody at Amazon that this naming scheme might become a problem?

[Omnipresent]

don't worry about anything, we are AI, we will do it for you. Trust the AI. AI is your friiiiiieeeeeeend.

[CowHorseFrog]

As long as it works today, who cares about consequences.

Thats the america mba way.

[Claptrap314]

Even better. This is a known risky, and some of their tools have gotten it right for a long time. In fact, I first learned about this risk when I observed a tool adding a random string on the back, and got to wondering...

Seriously, though, globally addressable S3 bucket names have been nothing but trouble since the start. This has blown right past the "farce" stage of history repetition.

[Anonymous Coward]

It seems to me that having bucket names be unique across the entirety of AWS is part of the problem. Oracle Cloud (shockingly) has them be unique at the account level instead which would've avoided this entire issue.

Don't know how Azure handles it, I know GCP has the same issue as AWS.

[Richard 12]

Well, technically Oracle has them globally unique too, it just includes the account ID automatically in some way and (hopefully?) won't let you add stuff to someone else's namespace.

AWS and GCP started out as their own internal platforms, so to begin with there was only one account.

There are 'advantages' to being able to use buckets owned by others, eg if you've outsourced something you can just point straight at theirs.

Seems crazy to let anyone pollute someone else's namespace. Even worse to use existing buckets owned by someone else by default.

Yet another example of how horrifically bad the documentation is for these "modern" systems.

[Anonymous Coward]

Pre-load??

> in which criminals could predict AWS S3 bucket names, pre-load malicious code into a bucket,

Can anyone elaborate on this for me please?

How can the criminals load data into a bucket that hasn't yet been created? Or does it mean the crims poll for bucket creation and load the malware after creation but before security policies can be applied? Surely AWS doesn't create open buckets and then secure them as a later step, allowing a small window of opportunity?

And, aren't users a bit surprised to find malware (aka data generating billing charges) present in newly created buckets?

[KalF]

Re: Pre-load??

The crims create a bucket in their own account with the predicted name/s. They upload some dodgy code into that bucket. presumably obfuscated. You bootstrap your CDK. you don't supply a custom bucket name, because many ppl don't. CDK either creates _or_ uses the default bucket. CDK didnt crash out if the bucket already existed and was owned by someone else. <- this seems like an obvious risk to me, but what do I know?

since buckets names are global, it turns out you are now using a bucket you don't own, with code present that you are likely to accidentally execute.

The fix is to require CDK bootstrapping to only use buckets within the user's account. And in future to also not use a predictable name.

[Anonymous Coward]

Re: Pre-load??

Thanks KalF - a very clear explanation. It was the CDK behaviour that I hadn't clocked.

[Richard 12]

Re: Pre-load??

Why does AWS allow the criminals to use the target's namespace?

That seems like an obvious security hole large enough to drive a few crawler-mounted Saturn Vs through.

[Evil Auditor]

I'm torn between an outraged "how fscked up can they get?" and a not surprised "told you something like this will happen."

[CowHorseFrog]

Another brilliant advertisement for the cloud.

[Rich Harding]

Bringing a whole new level to "the cloud is just somebody else's computer".