[placardloop]

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

[EliavLivneh]

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

[placardloop]

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.

[marcusb]

> “My trust policy has a vulnerability in it but I’m safe because the attacker can’t read my policy to find out”

The goal in preventing enumeration isn't to hide defects in the security policy. The goal is to make it more difficult for attackers to determine what and how they need to attack to move closer to their target. Less information about what privileges a given user/role have = more noise from the attacker, and more dwell time, all other things being equal. Both of which increase the likelihood of detection prior to full compromise.

[zmgsabst]

iam:ListRoles tells you ARNs and policy rules — at least, in their example response.

https://docs.aws.amazon.com/IAM/latest/APIReference/API_List...

I don’t think this is a major or severe issue — but it certainly would provide information for pivots, eg, ARNs to request and information about from where.

[ImPostingOnHN]

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.

[placardloop]

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.

[ImPostingOnHN]

AWS is evidently not using their own tools correctly to build AWS then, because we know that the contents of security policies can easily contain sensitive information.

Just because Amazon tells people not to put sensitive information in a security policy, doesn't mean a security policy can't or shouldn't contain sensitive information. It more likely means Amazon failed to properly implement security policies (since they CAN contain sensitive information), and gives their guidance as an excuse/workaround. The proper move would be to properly implement security policies such that the access is as limited as expected, because again, security policies can contain sensitive information.

An analogy would be a car manufacturer that tells owners to not put anything in the car they don't want exploded. "But they said don't do it!" -- Obviously this is still unreasonable: A reasonable person would expect their car to not explode things inside it, just like a reasonable person would expect their cloud provider to treat customer security policies as sensitive data. Don't believe me here? Call up a sample of randomly-selected companies and ask for a copy of their security policies.

This is key to understand here: What Amazon says is best security given their existing decisions is not the best security for a cloud provider to provide customers. We're discussing the latter: Not security given a tool, but security of the tool itself, and the decisions that went into designing the tool. It's certainly not the case that the tool is perfect and can't be improved, and it's not a given that the tool is even good.