31–40 of 227 posts
Earlier quoted context omitted.
And those organizations are building their security model off of false assumptions, and are wrong.
Defense in depth, always assume that anything can get used as an attack vector including AWS itself .
For sure an interesting find, but was kinda hoping based on the title that there was a more straightforward way to do this. I really wish that AWS had a simple way from an admin account to ask "where is X resource" within an organization to quickly tell me which account has a specific S3 bucket (and other things, but s3 buckets is the big one). Admittedly this is mostly an issue with legacy buckets that existed befor…
So finding out which account owns a resource can be as simple as, roughly: select accountId where arn = "x"
For those interested, we put the code online here: https://github.com/tracebit-com/find-s3-account
TIL: AWS Account IDs are considered secrets. IMO, if a given value cannot be cycled, it is sensitive but not secret.
Earlier quoted context omitted.
No, this is wrong. The fact that AWS does not consider the ID a secret means that your company never should either. If your company “cares” about its ID being secret, then your company is designing its systems in an insecure way. The fact that AWS does not treat the ID as secret means you have no guarantees that anyone within AWS cannot see or find your ID. You also have no guarantee that AWS at some point won’t expo…
You've said "this is wrong" and then repeated exactly my point back to me. I suspect some misunderstanding has occurred here. We are agreeing on this--you need to follow AWS's lead and design your cloud deployment such that the account ID doesn't leak anything interesting about your business. That's a direct quote from my original post. I further gave an example--if you're a design firm using a single account for dif…
> you can treat your account ID as non-secret because AWS does. That doesn't directly follow;
It does follow, and not only that, but not only “can” you treat them as non-secret, you _must_ treat them as non-secret.
> the difference between AWS's point of view and your company's point of view means there are things you might care about that AWS does not
The point here is that if you want to have good security, you _cannot_ “care” about this if your service provider does not also care about it. If you “care” about your ID being public, but your provider does not, then if you want to have good security you must either find a way to not care, or find another provider.
So are S3 Crawler bots inbound that will be used to exploit and blackmail S3 bucket owners... via doxxing? EDIT: isnt one of the S's "secure".... Isnt it like THE FIRST S?!?!?!? EDIT I get it! - I forgot the three Ss'! Shove it.
… in Simple Storage Service?
Earlier quoted context omitted.
Defense in depth, always assume that anything can get used as an attack vector including AWS itself .
It’s not defense in depth to build your security model off of false assumptions, it’s just bad security.
Earlier quoted context omitted.
While I agree, the way you wrote this might mislead people into thinking that you meant you can treat your account ID as non-secret because AWS does. That doesn't directly follow; the difference between AWS's point of view and your company's point of view means there are things you might care about that AWS does not. Rather, you need to follow AWS's lead and design your cloud deployment such that the account ID doesn…
No, this is wrong. The fact that AWS does not consider the ID a secret means that your company never should either. If your company “cares” about its ID being secret, then your company is designing its systems in an insecure way. The fact that AWS does not treat the ID as secret means you have no guarantees that anyone within AWS cannot see or find your ID. You also have no guarantee that AWS at some point won’t expo…
You and gp are talking past each other.
Your focus is on Account ID being public should not be a security vulnerability.
Instead, the gp's focus is on metadata leakage of identity.
Same type of conversation that differentiates concepts of "public key" vs "published key" of SSH keys: