Live data from Hacker News

AWS Built a Security Tool. It Introduced a Security Risk

token.security

51–60 of 85 posts

Re: AWS Built a Security Tool. It Introduced a Security Risk

#51
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.

Re: AWS Built a Security Tool. It Introduced a Security Risk

#52
post #49

Earlier quoted context omitted.

I invite you to consider the possibility that even though that’s the case, it’s Amazon’s fault for this design choice and one that can be critiqued especially since metadata disclosure can be paired with other exploits. For example, if I know a bucket name then I know the bucket’s domain name since buckets are by default created open to the public. There’s no inherent reason for treating metadata as less sensitive an…

s3 buckets being public by default was stopped 2 or 3 years ago: https://aws.amazon.com/about-aws/whats-new/2022/12/amazon-s3... longer if using the console

I know because it was one of the key decisions we made with R2 and pushed this point in the community.

The majority of S3 buckets, especially valuable ones, remain created back when it was the default and thus the metadata sensitivity with bucket names remains (and that isn’t the only metadata issue).

Re: AWS Built a Security Tool. It Introduced a Security Risk

#53

Earlier quoted context omitted.

AWS does not treat metadata with the same level of sensitivity as other data. The docs explicitly say that sensitive information should not be stored in eg tags or policies. If you are attempting to do so, you’re fighting against the very tool you’re using.

I invite you to consider the possibility that even though that’s the case, it’s Amazon’s fault for this design choice and one that can be critiqued especially since metadata disclosure can be paired with other exploits. For example, if I know a bucket name then I know the bucket’s domain name since buckets are by default created open to the public. There’s no inherent reason for treating metadata as less sensitive an…

AWS S3 buckets have always been default private since forever.

Re: AWS Built a Security Tool. It Introduced a Security Risk

#54
post #49

Earlier quoted context omitted.

I invite you to consider the possibility that even though that’s the case, it’s Amazon’s fault for this design choice and one that can be critiqued especially since metadata disclosure can be paired with other exploits. For example, if I know a bucket name then I know the bucket’s domain name since buckets are by default created open to the public. There’s no inherent reason for treating metadata as less sensitive an…

s3 buckets being public by default was stopped 2 or 3 years ago: https://aws.amazon.com/about-aws/whats-new/2022/12/amazon-s3... longer if using the console

The globally unique names of S3 could be problematic with just the metadata of name.

You could figure out how a company names their S3 buckets. It's subtle, but you could create a bunch of typo'd variants of the buckets and sit around waiting for s3 server logs/cloudtrail to tell you when someone hits one of the objects.

When that happens, you could get the accessing AWS Account # (which isn't inherently private, but something that you wouldn't want to tell the world about), IAM user accessing object, and which object was attempted to be accessed.

Say the IAM user is a role with terribly insecure assume role policy... Or one could put an object where the misconfigured service was looking and it'd maybe get processed.

This kind of attack is preventable but I doubt most people are configuring SCPs to the level of detail you'd need to completely prevent this.

Re: AWS Built a Security Tool. It Introduced a Security Risk

#55

Earlier quoted context omitted.

AWS does not treat metadata with the same level of sensitivity as other data. The docs explicitly say that sensitive information should not be stored in eg tags or policies. If you are attempting to do so, you’re fighting against the very tool you’re using.

I invite you to consider the possibility that even though that’s the case, it’s Amazon’s fault for this design choice and one that can be critiqued especially since metadata disclosure can be paired with other exploits. For example, if I know a bucket name then I know the bucket’s domain name since buckets are by default created open to the public. There’s no inherent reason for treating metadata as less sensitive an…

> Said another way, some users expect the metadata to be treated sensitively and Amazon’s subversion of this is an Amazon problem not a user problem since this user expectation is rather reasonable.

It's an Amazon problem to the extent that they lose business over it. But if people choose to use AWS, despite having different requirements for data security than AWS provides, that is a user problem. At some point the onus is on the user to understand what a tool does and doesn't do, and not choose a tool that doesn't meet their requirements.

Re: AWS Built a Security Tool. It Introduced a Security Risk

#56

Earlier quoted context omitted.

I think Google scares a lot of people away with their approach of not being able to talk to any human whatsoever unless you spend a lot of money on a monthly basis. I read a lot of horror stories of people getting in troubles with GCP and not being able to talk to a human person, whereas you would get access to some human presence with AWS. Things might have been changed, but I guess a lot of people have still this i…

I’m scared of Google realising that maintaining a given cloud product just isn’t fun anymore and sending it to the Google graveyard.

Yeah I think anyone who chooses to do business with Google at this point is taking a needless risk. I wouldn't trust them to continue to provide anything except perhaps the ad business.

Re: AWS Built a Security Tool. It Introduced a Security Risk

#57
post #54
post #49

Earlier quoted context omitted.

s3 buckets being public by default was stopped 2 or 3 years ago: https://aws.amazon.com/about-aws/whats-new/2022/12/amazon-s3... longer if using the console

The globally unique names of S3 could be problematic with just the metadata of name. You could figure out how a company names their S3 buckets. It's subtle, but you could create a bunch of typo'd variants of the buckets and sit around waiting for s3 server logs/cloudtrail to tell you when someone hits one of the objects. When that happens, you could get the accessing AWS Account # (which isn't inherently private, but…

That’s why Amazon recommends the use of the expected owner parameter for S3 operations.

ISTR it’s also possible to apply an SCP that limits S3 reads and writes outside your organization. If not via an SCP then via a permission boundary at the least.

Re: AWS Built a Security Tool. It Introduced a Security Risk

#58
post #29
post #13

Earlier quoted context omitted.

Depending on what the metadata is, it can be a huge security risk. For example, some US government agencies consider computer names sensitive, because the computer name can identify who works in what government role, which is very sensitive information. Yet, depending on context, the computer name can be considered "metadata."

That sounds more like the government’s fault for putting a secret in the name. Make the computer name a random string or random set of words, no relation to the person or department who uses it. Problem solved.

And more problems created.

Now you have to have another system that decodes the random words to human usable words. Is that information going to be stored all in one system? Is each team going to be responsible for the translation? How is that going to be protected from information loss?

I work with systems like this so, yea, it can be done. But it cannot be done trivially.

Re: AWS Built a Security Tool. It Introduced a Security Risk

#59
post #26

Earlier quoted context omitted.

AWS IAM terrible, GCP's is much better

In AWS, everything is in one place and uses a fairly expressive policy syntax. For GCP, you have " global IAM" in one place, contextual IAM in another (VPC-SC), per-resource IAM under the resource (GCS buckets), roles in another spot that require using the most sluggish docs website in the world to decode, and user/group management in an entirely separate app (cloud identity/workspace). How is GCP much better? FWIW I…

It's not as clean in AWS as you make it out to be. Service control policies, resources policies in services like S3 and SNS...

Re: AWS Built a Security Tool. It Introduced a Security Risk

#60
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.

Post reply on HN