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

71–80 of 85 posts

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

#71

Post by voytec »

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…

> And if you’re storing secret information in your bucket names, you have bigger problems.

Yeah but the design should be made on the assumption that some customers will do stupid things, and protect them.

Not an identical case, but I once bought a Cisco router for home lab/learning and it appeared to be a hardware decommissioned by one of European banks, not flashed before being handed over to some asset disposal contractor. It eventually landed on an auctioning portal with bank's configuration. The bank was very meticulous with documenting stuff like the address of the branch where it was installed in device's config and ACL names/descriptions included employees' names and room numbers. You could easily extract the names of people granted extended access to internal systems.

So while I agree with you in principal, even financial institutions do stupid things, lack procedures or their processes don't always follow them. Cloud provider's design should assume their customers not following best practices.

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

#72

Post by lazystar »

liquidpele wrote: post #44
yfiapo wrote: post #35

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

Sounds like typical hyperbole. Worked at a place once where some “security researcher” trashed the product because they could do bad things on the appliance… if logged in as root.

to play devils advocate... why were users able to log in as root?

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

#73

Post by michaelt »

lazystar wrote: post #72
liquidpele wrote: post #44

Earlier quoted context omitted.

Sounds like typical hyperbole. Worked at a place once where some “security researcher” trashed the product because they could do bad things on the appliance… if logged in as root.

to play devils advocate... why were users able to log in as root?

Because the appliance... was not an iphone?

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

#74

Post by jiggawatts »

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…

Azure has Resource Groups and global visibility across all products in all regions in a single pane of glass.

There are “single IP” global load balancers with regional dynamic routing in Azure too.

People just assume AWS is the best in the same way that Cisco was considered the best even though they were a dinosaur selling over-priced products for the last two decades.

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

#75

Post by jiggawatts »

datadrivenangel wrote: post #24
soco wrote: post #19

Earlier quoted context omitted.

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?

Azure Resource Manager provides a “single pane of glass” for both the GUI and CLI tooling so that you’re not jumping between web consoles that appear unrelated but manage a single cohesive deployment of inter-related parts.

It uses human names instead of random gibberish identifiers. Last time I looked at AWS it still refused to turn these into clickable hyperlinks. Do the lookup yourself human! This menial task is beneath the great cloud computer.

Etc…

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

#76

Post by jiggawatts »

atoav wrote: post #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 s…

The difference here is that A/V scanning and security vulnerability scanning can be done from the “outside” using read only privileges.

Many clouds now support scans of snapshots, removing the need for direct access to the read/write internals of a workload.

This is where your analogy falls flat a bit.

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

#77

Post by TheTaytay »

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 agree completely. Every time I need to do Something in AWS I feel like I’m just stumbling over footguns in an infinite sea of footguns. Meanwhile, other providers. (GCP and Azure) have the ability to group resources under projects/folders. They have sensible default isolation primitives that you can understand…

If you forget to tag a resource in AWS, it’s very difficult to find out what it’s being used by. And yeah, infrastructure as code helps with this, but God help you if you created something via the console.

If AWS had a cloud product that had 10% of the surface area, and a simplistic project/RBAC primitive, I would use it in a heartbeat. Hell, it’s essentially what other companies like Heroku are selling (and charging a premium for).

Even if Cloudflare’s R2 cost the same as AWS, I’d use it because the likelihood of one of our engineers doing something wrong permissions is GREATLY diminished.

Anyway, just nodding along to your comment and venting a bit.

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

#78

Post by wrs »

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…

AWS’s account system is nuts. I know it grew historically out of the “just buy S3 storage with your Amazon account” original, but it’s 2025 and they run half the internet now.

Until a few months ago, you couldn’t even be signed in to more than one account at a time in the console. Now you can use…up to five? (If you’re following “best practices” you likely have far more than five.)

For anyone who hasn’t seen GCP’s console, there’s just a simple menu to switch your view to any of the projects you have access to. There’s even a search box in case you have enough to need it.

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

#79

Post by sitharus »

coredog64 wrote: post #57
redserk wrote: post #54

Earlier quoted context omitted.

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.

Yep, an SCP can restrict what S3 buckets you can access via IAM.

If you're using a VPC you can deploy a VPC S3 Gateway Endpoint which has a policy document on it, this will restrict which buckets the whole VPC can access no matter what their IAM policy says. This also has the benefit of blocking access using non-IAM methods, like signed URLs or public buckets.

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

#80

Post by sitharus »

whs wrote: post #69
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.

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

I used to work for an AWS support partner, essentially being tier 3 support. We were also involved in onboarding large customers to AWS and working with their teams to migrate their systems.

We always told them that AWS account IDs are not considered sensitive information by AWS, neither are S3 bucket names. Metadata (tags etc) is generally visible to AWS in a variety of ways if you ask for help, but are not public.

This helped them use the services to the sensitive information was actually hidden and apply the correct security policies.

Post reply on HN