Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AWS Built a Security Tool. It Introduced a Security Risk

token.security

Post reply on HN
Print view View original

11–20 of 85 posts

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

#11

Post by philipwhiuk »

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…

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.

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

#12

Post by phinnaeus »

thinkindie wrote: post #8
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 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.

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

#13

Post by gwbas1c »

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."

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

#14

Post by gwbas1c »

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…

My experience with GCP was that the support staff was rude.

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

#15

Post by placardloop »

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."

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.

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

#16

Post by placardloop »

philipwhiuk wrote: post #11
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…

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 by AWS have default names common across accounts).

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

#17

Post by candiddevmike »

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.

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

#19

Post by soco »

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

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

#20

Post by MortyWaves »

phinnaeus wrote: post #12
thinkindie wrote: post #8

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.

Or sell it off to nefarious companies like SquareSpace
Post reply on HN