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

61–70 of 85 posts

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

#61

Post by shermantanktop »

b112 wrote: post #21
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…

We all say “Microsoft” “Google” “Amazon” as though each is a single monolithic entity with a consistency of culture, mission, and behavior. And yet I bet the company you work does things in marketing which don’t reflect how engineering thinks.

Your observations imply a root cause. But public information about Amazon’s corporate structure shows that AWS is almost a separate company from the website. Same is true for Google’s search vs YouTube or Apple hardware design vs their iMessages group.

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

#62

Post by belter »

dastbe wrote: post #49
vlovich123 wrote: post #45

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

S3 buckets were never public by default. From the link you posted:

"...Amazon S3 buckets are and always have been private by default. Only the bucket owner can access the bucket or choose to grant access to other users..."

The feature and announcement you linked was about making active an additional safety feature that would block them becoming public. Even if you intentionally ( or accidentally ) configured them with public access.

The well known accidents in the past, of Facebook or the Pentagon having private data in public S3 buckets, I can only attribute to the modern practices of self-paced learning, skipping videos on Udemy courses or deciding formal training is no longer necessary because I can Google it...

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

#63

Post by gitremote »

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

"We kill people based on metadata."

- Ex-NSA chief Michael Hayden

Metadata is data. In a large corporation, metadata can also reveal projects under NDA that only a select few employees are supposed to know about about.

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

#65

Post by belter »

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…

What is the "account sub-account" you are referring to? Does it blow your mind Google Availability Zones are firewalls across the SAME data center?

https://youtu.be/mDNHK-SzXEM?t=560

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

#67

Post by sieabahlpark »

vlovich123 wrote: post #45
placardloop wrote: post #15

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…

[dead]

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

#68

Post by stogot »

vlovich123 wrote: post #45
placardloop wrote: post #15

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…

> since buckets are by default created open to the public.

This is false

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

#69

Post by whs »

placardloop wrote: post #15
gwbas1c wrote: 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."

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.

To add on this point, in my interaction with AWS employees it seems that

- The account manager and the enterprise support TAM can view a list of all resources on the account, including metadata like resource name, instance type and cost explorer tags. Enterprise support routinely present a monthly cost review with us, so it is clear that they can always access this information without our explicit consent. They do not have the ability to view detailed internal information about it though, such as internal logs.

- When opening support case, the ticketing system ask for resource ARN which may contains the name. It seems that the support team can view some data about that object including monitoring data and internal logs, but potentially accessing "customer data" (such as ssh-ing into an RDS instance) requires explicit, one off consent.

- I never opened any issues about IAM policy, so I don't know if they see IAM role policy document

- It seems that the account ID and account name is also often used by both AWS' sales side and reseller's side. I think I read somewhere that it is possible to retrieve the AWS account ID if you know S3 bucket or something, and when exchanging data with external partner via AWS (eg. S3, VPC peering) you're required to exchange account ID to the partner.

Post reply on HN