131–140 of 227 posts
> The ability to apply a wildcard match on the s3:ResourceAccount condition key That’s the crazy part. No good can ever come from this - there is no legitimate reason why you would grant or deny permission based on a partial account id match.
You're not a fan of my AWS lottery idea where accounts ending in 666 get access to a free bitcoin miner??
How might this matter? A obvious one: Given a production bucket, it’s now possible to find development buckets for that same org, which is not expected behavior IMO.
Unlikely, unless dev buckets are somehow in the same account.
How might this matter? A obvious one: Given a production bucket, it’s now possible to find development buckets for that same org, which is not expected behavior IMO.
You'd have the know the name of the (development) bucket first, right?
Earlier quoted context omitted.
It says he consulted but does not say what was their answer. I can't imagine it was a thumbs up, probably an embarrassed silence?
Why all the doubt? "not sure" "can't imagine" When the source says they already did their due diligence...
I agree that the account number just by itself is not a secret, but there is a reason why all AWS demo videos mask the account number.
TIL: AWS Account IDs are considered secrets. IMO, if a given value cannot be cycled, it is sensitive but not secret.
In fact, when delegating IAM access (where security is top of mind), account IDs are shared liberally.
Account IDs are as secret as phone numbers. That bit of info could be tangentially useful to an attack, but really shouldn't be assumed to be secret in any meaningful way.
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 2343242365 is the account number associated with "coolbuttplugs.com" but I probably do care if the same account hosts a bucket for "michaeljfoobar.name" and my buttplug thing is a sideshow from my white shoe law practice.
Earlier quoted context omitted.
That's the part that surprised me as well; it doesn't seem like a field that should be eligible for anything other than an exact match. I am unable to conceive of a use case for pattern matching account IDs.
If for some reason you’re dealing with thousands of accounts that are architecturally indistinguishable, bucketing them by ID prefix isn’t a particularly wild thing to want to do.
Sharding on account ID might make sense if someone has a large number of them, but that would not necessitate wildcard matching.
TIL: AWS Account IDs are considered secrets. IMO, if a given value cannot be cycled, it is sensitive but not secret.
AWS Account IDs are not secret and don’t need to be. AWS doesn’t design anything that assumes your account ID is secret, and you shouldn’t either.
* Security through obscurity provides secondary security only, so it doesn't add to defense-in-depth significantly. If it can be added, then it is slightly safer to prefer to do so. Elimination of unprivileged enumeration and internal primary key predictability are relatively more important to reduce the attack surface.
How might this matter? A obvious one: Given a production bucket, it’s now possible to find development buckets for that same org, which is not expected behavior IMO.
How so? You'd have the know the name of the (development) bucket first, right?
Earlier quoted context omitted.
Well, that assumes that the ID is cryptographically random. Perhaps that is a bad assumption.
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…
Honestly, wouldn't surprise me that much if they were willing to accommodate this if for sufficiently large accounts. It'd still pretty sketchy to design your access control around, but it wouldn't be unrealistic.