AWS Built a Security Tool. It Introduced a Security Risk

I agree this was a security concern and it was reported and addressed appropriately. With that said as things go this is pretty minor; perhaps a medium severity issue. Information disclosures like this may be leveraged by attackers with existing access to the lower environment, in conjunction with other issues, to escalate their privileges. By itself, or without the existing access, it is not usable.

More over, the issue wasn’t that AWS recommended or automatically setup the environment insecurely. Their documentation simply left the commonly known best practice of disallowing trusts from lower to prod environments implicit, rather than explicitly recommending users follow that best practice in using the solution.

I don’t think over-hyping smaller issues, handled appropriately, helps anyone.

This so called “security risk” is a role in a nonprod that can list metadata about things in your production accounts. It can list secret names, list bucket names, list policy names, and similar.

Listing metadata is hardly a security issue. The entire reason these List* APIs are distinct from Get* APIs is that they don’t give you access to the object itself, just metadata. And if you’re storing secret information in your bucket names, you have bigger problems.

Someone invented the two-sentence clickline. Now even blogs do it.

IAM is complex. More so with federation and cross account trust. Not sure every weakness can be considered as a vulnerability.

In this case, I was looking for a threat model within which this is a vulnerability but unable to find so.

This is just incompetence on the part of the person deploying this solution. Just because AWS say “don’t deploy to management account” doesn’t mean you should a deploy something with access to all your accounts into a dev account.

Man, this got me thinking hard about where the line really is for what counts as a real risk versus hype. Everyone draws it different. you ever catch yourself worrying too much about stuff that probably isn't even a threat?

The link is ironically blocked by my companies security suite.

As an AWS-focused practitioner, I started doing Google Cloud training and it blew my mind when I found out that the multiple account sub-account mess that AWS continues to use just doesn’t exist there. GCP sensibly uses a folder and project system that provides a lot of flexibility and IAM control.

It also blew my mind that Google Cloud VPCs and autoscaling groups are global, so that you don’t have to jump through hoops and use the Global Accelerator service to architect a global application.

After learning just those two things I’m downright shocked that Google is still in 3rd place in this market. AWS could really use a refactor at this point.

Depends on your implementation, you should not store sensitive data in metadata

A fundamental problem that plagues many security solutions can be understood by analogy:

Imagine a incredibly secure castle. There are thick unclimbable walls, moats, trap rooms, everything compartmentalized, an attacker that gains control of one section didn't achieve much in terms of the whole castle, the men in each section are carefully vetted and are not allowed to have contact or family relationships with men stationed in other sections, so they cannot be easily bribed or forced to open doors. Everything is fine.

But the king is furious, the attackers shouldn't control any part of the castle! As a matter of principle! The architects reassure the king that everything is fine and there is no need to worry. The king is unconvinced, fires them and searches for architects that do his bidding. So the newlyfound architects scramble together and come up with secret hallways and tunnels, connecting all parts of the castle so the defenders can clear the building in each section. The special guards who are in charge of that get high priviledges, so they could even fight attackers who reach the kings bed room. The guard is also tasked to keep in touch with the attackers so they are extra prepared for when they attack and understand their mindset inside out.

The king is pleased, the castle is safe. One night one of those guards turns against the king and the attackers are sneaked into the castle. The enemy is suddenly everywhere and they kill the king. A battle that should have been fought in stages going inwards is now fought from the inside out and the defenders are suddenly trapped in the places that were meant for the very enemies they are fighting. The kingdom has fallen.

The problem with many security solutions – including AV solutions – is that you give the part of your system that comes into contact with the "enemy" the keys to your kingdom, usually with full unchecked priviledges (how else to read everything that is going on in the system). Actual security is the result of strict compartmentalization and a careful and continous vetting of how each section can be abused and leveraged once it has fallen. Just like in mechanical engineering where each new moving part can add a new failure point, in security adding a new priviledged thing adds a lot of new attack surface that wasn't previously there. And if that attack surface gives you the keys to the kingdom it isn't the security solution, it is the target.

The article is bullshit.

AWS has a pretty simple model: when you split things into multiple accounts those accounts are 100% separate from each other (+/- provisioning capabilities from the root account).

The only way cross account stuff happens is if you explicitly configure resources in one account to allow access from another account.

If you want to create different subsets of accounts under your org with rules that say subset a (prod) shouldn’t be accessed by another subset (dev), then the onus for enforcing those rules are on you.

Those are YOUR abstractions, not AwS abstractions. To them, it’s all prod. Your “prod” accounts and your “dev” account all have the same prod slas and the same prod security requirements.

The article talks about specific text in the AWS instructions:

“Hub stack - Deploy to any member account in your AWS Organization except the Organizations management account."

They label this as a “major security risk” because the instructions didn’t say “make sure that your hub account doesn’t have any security vulnerabilities in it”.

AWS shouldn’t have to tell you that, and calling it a major security risk is dumb.

Finally, the access given is to be able to enumerate the names (and other minor metadata) of various resources and the contents of IAM policies.

None of those things are secret, and every dev should have access to them anyways. If you are using IAC, like terraform, all this data will be checked into GitHub and accessible by all devs.

Making it available from the dev account is not a big deal. Yes, it’s ok for devs to know the names of IAM roles and the names of encryption key aliases, and the contents of IAM policies. This isn’t even an information disclosure vulnerability .

It’s certainly not a “major risk”, and is definitely not a case of “an AWS cross account security tool introducing a cross account security risk”.

This was, at best, a mistake by an engineer that deployed something to “dev” that maybe should have been in “prod” (or even better in a “security tool” environment).

But the actual impact here is tiny.

The set of people with dev access should be limited to your devs, who should have access to source control, which should have all this data in it anyways.

Presumably dev doesn’t require multiple approvals for a human to assume a role, and probably doesn’t require a bastion (and prod might have those controls), so perhaps someone who compromises a dev machine could get some Prod metadata.

However someone who compromises a dev machine also has access to source control, so they could get all this metadata anyways.

The article is just sensationalism.

[dead]