Depends on your implementation, you should not store sensitive data in metadata
AWS Built a Security Tool. It Introduced a Security Risk
41–50 of 85 posts
Re: AWS Built a Security Tool. It Introduced a Security Risk
#42IAM is complex. More so with federation and cross account trust. Not sure every weakness can be considered as a vulnerability. In this case, I was looking for a threat model within which this is a vulnerability but unable to find so.
The security industry, unfortunately, is awash with best practice violations masquerading as vulnerabilities
Re: AWS Built a Security Tool. It Introduced a Security Risk
#43This 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."
I don't the US government is representative of any kind of advisable behavior. Perhaps if they weren't doing stuff that makes people want to murder them we wouldn't have to light piles of cash on fire to protect the perpetrators.
Re: AWS Built a Security Tool. It Introduced a Security Risk
#44I 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.
Re: AWS Built a Security Tool. It Introduced a Security Risk
#45Earlier 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.
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 and there would be fewer problems if it were treated with the same sensitivity as normal data.
Said another way, some users expect the metadata to be treated sensitively and Amazon’s subversion of this is an Amazon problem not a user problem since this user expectation is rather reasonable.
Re: AWS Built a Security Tool. It Introduced a Security Risk
#46Earlier 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."
I don't the US government is representative of any kind of advisable behavior. Perhaps if they weren't doing stuff that makes people want to murder them we wouldn't have to light piles of cash on fire to protect the perpetrators.
Whether or not it’s advisable doesn’t really change the fact that the if US government is commonly doing something then that it is not correct to describe a security impact to those SOPs as “hardly a security risk”
Re: AWS Built a Security Tool. It Introduced a Security Risk
#47Earlier quoted context omitted.
I’m scared of Google realising that maintaining a given cloud product just isn’t fun anymore and sending it to the Google graveyard.
Like IoT service? I had friends working in that field that scrambled for a year when that happened and they will never touch Google Cloud again.
Ahhhh it wasn't nice, but we at Echo54[0] had a plan/execution (6 months before the due date) to migrate to RabbitMQ (with MQTT Plugin) works way better and cheaper than GCP IoT service. We did all of that in less than 2 months.
Re: AWS Built a Security Tool. It Introduced a Security Risk
#48Earlier 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.
true that too
Re: AWS Built a Security Tool. It Introduced a Security Risk
#49Earlier 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…
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
Re: AWS Built a Security Tool. It Introduced a Security Risk
#50Earlier quoted context omitted.
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.…
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 re…
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.