AWS Built a Security Tool. It Introduced a Security Risk • Hacker News Board

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

#21

Post by b112 » Mon, May 05, 2025, 12:54 PM UTC

dangus wrote: post #5

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 ho…

Sort of the same with anything Amazon. Look at their retail website! It used to be the most ground breaking, impressive product search engine out there.

Now it's weird in a dozen different ways, and it endlessly spews ridiculous results at you. It's like a gorgeous mansion from the 1900s, which received no upkeep. It's junk now.

For example, if I want to find new books by an author I've bought from before, I have to go to: returns & orders, digital orders, find book and click, then author's name, all books, language->english, format->kindle, sort by->publication date.

There's no way to set defaults. No way to abridge the process. You mysteriously you cannot click on the author name in "returns & orders". It's simply quite lame.

Every aspect of Amazon is like this now. It was weird workflows throughout the site. It's living on inertia.

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

#22

Post by sumitkumar » Mon, May 05, 2025, 12:54 PM UTC

dangus wrote: post #5

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 ho…

So this is about customer support. Google supports by the customer by a better product but minimal manual support for issues later.

AWS has an organically evolved bad product which has been designed by long line of six page memos but a manual support in case things get too confusing or the customer just need emotional support.

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

#23

Post by y-curious » Mon, May 05, 2025, 12:57 PM UTC

bulatb wrote: post #3

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

Hackers Hate Him: The Weird Trick that Keeps Users Clicking in 2025

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

#24

Post by datadrivenangel » Mon, May 05, 2025, 1:04 PM UTC

soco wrote: post #19

dangus wrote: post #5

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 ho…

I don't know GCP but my experiences with Azure were also way smoother than AWS. It's like the Amazon folks are not even trying to work on less friction...

Which parts of Azure have you used that have less friction than AWS?

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

#25

Post by EliavLivneh » Mon, May 05, 2025, 1:04 PM UTC

placardloop wrote: post #16

philipwhiuk wrote: post #11

Earlier quoted context omitted.

At the end of the day if you deploy a tool that can access production data, you need to treat it like production. That's the reality here.

No, that’s not the reality. “Production data” isn’t as black and white as that. Metadata about your account, regardless of if you call it “production” or not, is not guaranteed to be treated with the same level of sensitivity as other data. Your threat model should assume that things like bucket names, role names, and other metadata are already known by attackers (and in fact, most are, since many role names managed…

Hey, author of the blog here :)

Just wanted to point out that it is not just names of objects in sensitive accounts exposed here - as I wrote, the spoke roles also have iam:ListRoles and iam:ListPolicies, which is IMO much more sensitive than just object names. These contain a whole lot of information about who is allowed to do what, and can point at serious misconfigurations that can then be exploited onwards (e.g. misconfigured role trust policies, or knowing about over-privileged roles to target).

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

#26

Post by arccy » Mon, May 05, 2025, 1:08 PM UTC

candiddevmike wrote: post #17

dangus wrote: post #5

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 ho…

Google's resource management + AWS's IAM + Azure's... nah == best of everything.

AWS IAM terrible, GCP's is much better

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

#27

Post by placardloop » Mon, May 05, 2025, 1:08 PM UTC

EliavLivneh wrote: post #25

placardloop wrote: post #16

Earlier quoted context omitted.

No, that’s not the reality. “Production data” isn’t as black and white as that. Metadata about your account, regardless of if you call it “production” or not, is not guaranteed to be treated with the same level of sensitivity as other data. Your threat model should assume that things like bucket names, role names, and other metadata are already known by attackers (and in fact, most are, since many role names managed…

Hey, author of the blog here :) Just wanted to point out that it is not just names of objects in sensitive accounts exposed here - as I wrote, the spoke roles also have iam:ListRoles and iam:ListPolicies, which is IMO much more sensitive than just object names . These contain a whole lot of information about who is allowed to do what, and can point at serious misconfigurations that can then be exploited onwards (e.g.…

ListPolicies does not show the contents of policies, so the information you mentioned isn’t possible to obtain from there.

Things like GetKeyPolicy do, but as I mentioned in my comments already, the contents of policies are not sensitive information, and your security model should assume they are already known by would-be attackers.

“My trust policy has a vulnerability in it but I’m safe because the attacker can’t read my policy to find out” is security by obscurity. And chances are, they do know about it, because you need to account for default policies or internal actors who have access to your code base anyway (and you are using IaC, right?)

You’re right to raise awareness about this because it is good to know about, but your blog hyperbolizes the severity of this. This world of “every blog post is a MAJOR security vulnerability” is causing the industry to think of security researchers as the boy who cried wolf.

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

#28

Post by ImPostingOnHN » Mon, May 05, 2025, 1:13 PM UTC

placardloop wrote: post #27

EliavLivneh wrote: post #25

Earlier quoted context omitted.

Hey, author of the blog here :) Just wanted to point out that it is not just names of objects in sensitive accounts exposed here - as I wrote, the spoke roles also have iam:ListRoles and iam:ListPolicies, which is IMO much more sensitive than just object names . These contain a whole lot of information about who is allowed to do what, and can point at serious misconfigurations that can then be exploited onwards (e.g.…

ListPolicies does not show the contents of policies, so the information you mentioned isn’t possible to obtain from there. Things like GetKeyPolicy do, but as I mentioned in my comments already, the contents of policies are not sensitive information, and your security model should assume they are already known by would-be attackers. “My trust policy has a vulnerability in it but I’m safe because the attacker can’t re…

I disagree with your opinion here: The contents of security policies can easily be sensitive information.

I think what you mean to say is, "Amazon has decided not to treat the contents of security policies as sensitive information, and told its customers to act accordingly", which is a totally orthogonal claim.

It's extremely unlikely that every decision Amazon makes is the best one for security. This is an example of where it likely is not.

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

#29

Post by dangus » Mon, May 05, 2025, 1:14 PM UTC

gwbas1c wrote: post #13

placardloop wrote: post #7

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…

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.

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

#30

Post by placardloop » Mon, May 05, 2025, 1:15 PM UTC

ImPostingOnHN wrote: post #28

placardloop wrote: post #27

Earlier quoted context omitted.

ListPolicies does not show the contents of policies, so the information you mentioned isn’t possible to obtain from there. Things like GetKeyPolicy do, but as I mentioned in my comments already, the contents of policies are not sensitive information, and your security model should assume they are already known by would-be attackers. “My trust policy has a vulnerability in it but I’m safe because the attacker can’t re…

I disagree with your opinion here: The contents of security policies can easily be sensitive information. I think what you mean to say is, "Amazon has decided not to treat the contents of security policies as sensitive information, and told its customers to act accordingly" , which is a totally orthogonal claim. It's extremely unlikely that every decision Amazon makes is the best one for security. This is an example…

It’s not orthogonal. The foundation of good security is using your tools correctly. AWS explicitly tells users to not store sensitive information in policies. If you’re doing so, it’s not AWS making the mistake.