171–180 of 227 posts
Presumably you could use this to find real principals in the other account.
There seems to be a large discussion of whether account IDs are "secret" or "private" or "confidential" or whatever. From my point of view, that entirely misses the point. The problem here is that what's revealed here is the relationship between buckets and account IDs, which allows discovery of shared ownership of buckets (unless you use a micro-account approach). I probably don't care if you can discover that 23432…
Accounts on AWS are pretty cheap (free?) - why would you host everything on the same account?
Earlier quoted context omitted.
... how did I not know this existed. That is exactly how we are setup, the amount of time I just spent going account by account looking for a specific resource. Thank you! I have long wondered why it didn't exist, and apparently it did...
Be aware that AWS Config is not free. https://aws.amazon.com/config/pricing/
Earlier quoted context omitted.
What does this mean? If they're not secret, sensitive, or confidential, then why must they be shared carefully?
Usually, the more information an attacker has about you, the higher the chances of coming up with a successful attack vector.
What value is there in allowing wildcard account id matching? I can't think of a legitimate use case.
Earlier quoted context omitted.
This is because, I assume, the AWS policy execution has a number of “operators” and “operands”, and in this case, you’re using the StringLike operand on the account ID string. Anyway, this discussion is a bit amusing to me, since Devops people are discovering side channels[1] now, although other types of side channels such as speculative execution side channels on CPUs (Meltdown, Spectre) already made waves at the ti…
> the AWS policy execution has a number of “operators” and “operands” That is correct. The IAM condition language is flexible and does not prevent you from doing strange things.
Doing glob matching on account IDs is like doing concatenation with guids, applying a bitshift to a UTF8 string, or running a regex on an integer. It is a nonsensical operation, and - as shown here - results in surprising security properties of the resulting system.
Surprising security properties are an undesirable result in an access control policy language.
Earlier quoted context omitted.
My general assumption is not that they’re random, but at least that they’re not correlated ; in particular that Amazon is not in the habit of handing out, like, account IDs 676363687000 - 676363687999 to a single organization. Even if they did hand out a sequential batch of 1000 account IDs, it would be more likely to be 676363687541 - 676363688540 than a set with a single consistent prefix. Odds are that an account…
I once was involved in creating two (linked) amazon accounts at the "same" time, and ended up with account IDs of which the first 4 digits are identical.
Earlier quoted context omitted.
This is because, I assume, the AWS policy execution has a number of “operators” and “operands”, and in this case, you’re using the StringLike operand on the account ID string. Anyway, this discussion is a bit amusing to me, since Devops people are discovering side channels[1] now, although other types of side channels such as speculative execution side channels on CPUs (Meltdown, Spectre) already made waves at the ti…
> Anyway, this discussion is a bit amusing to me, since Devops people are discovering side channels[1] We, the DevOps people, already knew about side channel attacks, Spectre and the likes, evaluated the performances hit for the fixes (or alleged fixes), patched our kernel boot params etc etc. We are curious people, just like many here.
Well we are, if nothing, consistent.
The next nerd who pinches and inch of the coder/ops divide is going to make a billion.