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

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

#81

Post by donavanm » Tue, May 06, 2025, 4:20 AM UTC

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…

Most of the access youre describing is based on AWSServiceRoleForSupport https://docs.aws.amazon.com/awssupport/latest/user/using-ser.... You can see both the IAM policy and the cloudtrail access logs in your account. There are internal tools which use IdP + business justification (ex open support ticket for a specific service) before giving a human limited, predefined, access to that role.

Some services will have an internal “admin” tool that is limited to a smaller group with similar limited access + review mechanisms. IME those tools are generally built in to the service implementation and dont expose access via a similar service principal/role. The reduced customer visibility is mitigated by very restrictive access, like “team primary oncall + manager approval + high severity ticket”.

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

#82

Post by atoav » Tue, May 06, 2025, 5:23 AM UTC

jiggawatts wrote: post #76

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.

So you give another kingdoms access to your castle, but they are not allowed to touch things? Or they get details like your blueprints and who is stationed where?

Just kidding, I know there are ways to do this in a more complex and secure way, e.g. with self hosting services etc., but that is why I tried to not make it about all AV products.

The fact remains that this kind of layer can (and repeatedly does) introduce weak points that will be attacked. I am not saying there aren't ways to implement this well, with trade offs that are worth it. What I say is that: "Just add AV-product X" is likely a doomed approach.

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

#83

Post by arccy » Tue, May 06, 2025, 12:27 PM UTC

candiddevmike wrote: post #40

arccy wrote: 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…

GCP's resource based hierarchy means it's much easier to locate where a permission comes from, it's either global, or attached to the resource in question. Most people probably shouldn't ever need to know about VPC-SC.

AWS IAM is a ball of mud, attach any policy at any one of the possible attachment points, good luck figuring out where you managed to gain permission to do X. And the constant emails for "ACTION REQUIRED: we changed some managed IAM permission and your workflows will break", whether you actually use that role, they can't even tell, so all you can do is complain to your emotional support TAM in the weekly call.

AWS's IAM conditions are also annoying dynamically typed, sure it's more powerful, but imo that's just more string to hang yourself with. the use of "*" in so many rules is just a recipe for disaster.

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

#84

Post by dangus » Wed, May 07, 2025, 3:04 PM UTC

pixl97 wrote: post #58

dangus wrote: post #29

Earlier quoted context omitted.

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.

As someone who has been in the IT department for a company, this is a basic and trivial function of an asset tracking system. It’s literally just matching the serial number or computer name of the asset to the employee.

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

#85

Post by ben-dh-kim » Thu, May 08, 2025, 3:40 AM UTC

This can be a sensitive issue for organisations of a certain size. Depending on how widespread and complex the trust relationship is, it may or may not be a threat. But I think one of the points that everyone is questioning is how the first attack vector can be initiated. I agree with what you're saying about the complexity of IAM and trust relationships in general.