FUD, don't waste your time.
Well, it's just an AWS Account ID
31–36 of 36 posts
Re: Well, it's just an AWS Account ID
#32This seems wrong. Surely you can’t “Enumerate IAM Entities” with just the aAccount ID? So if a company has a user for every dev with username first.last, you could list all devs just by knowing the Account ID? Maybe the author misunderstood what “enumerate” means and meant to say that you can check if a given IAM entity exists under the account? Enumeration and bruteforce are very different things.
In security contexts the term “enumeration” is understood to mean “brute force”. You can Google “enumeration attack” to see a bunch of examples where this is explicitly defined.
More concrete example: Account enumeration because the "forgot password" page tells the user "Unable to find account xyz@example.com" instead of "If your account xyz@example.com exists, then we have now send you an e-mail to recover your account".
If your forgot password page takes longer to respond when an account exists when it does not, it is also a side-channel attack.
Re: Well, it's just an AWS Account ID
#33This seems wrong. Surely you can’t “Enumerate IAM Entities” with just the aAccount ID? So if a company has a user for every dev with username first.last, you could list all devs just by knowing the Account ID? Maybe the author misunderstood what “enumerate” means and meant to say that you can check if a given IAM entity exists under the account? Enumeration and bruteforce are very different things.
In security contexts the term “enumeration” is understood to mean “brute force”. You can Google “enumeration attack” to see a bunch of examples where this is explicitly defined.
While a lot of security people misuse "enumeration" in this way, it's not accurate. They should use the term "oracle", eapecially since it's from the same field.
Re: Well, it's just an AWS Account ID
#34Earlier quoted context omitted.
In security contexts the term “enumeration” is understood to mean “brute force”. You can Google “enumeration attack” to see a bunch of examples where this is explicitly defined.
More concrete example: Account enumeration because the "forgot password" page tells the user "Unable to find account xyz@example.com" instead of "If your account xyz@example.com exists, then we have now send you an e-mail to recover your account". If your forgot password page takes longer to respond when an account exists when it does not, it is also a side-channel attack.
A "workaround" for this is to just try to create a new account, xyz@example.com.
This bypasses what you've mentioned.
Re: Well, it's just an AWS Account ID
#35This briefly mentions something I’ve seen during work and never dared to explore: the various public (RDS) snapshots. Oh boy, some people either use very realistic test datasets or they accidentally made things public that shouldn’t be at all.
I can't think of any use case where one would want an rds snapshot (and many other AWS resources) to be public. Why offering that possibility in the first place?
Re: Well, it's just an AWS Account ID
#36I consider anything that's not public knowledge to be a secret. When possible, try not to come up with anything that's guessable. I randomize even DB usernames in Terraform, not just the passwords. I do the same with schema names, etc. This requires sweat and tears, but it's always worth it. WordPress sucks, but the idea to have a custom table name prefix is not random, but a security consideration. But don't prefix…
Protip: Use random suffixes not prefixes, and you can retain tab completion. The frobnicator service can get a database account name frobnicator_znwxhs1xehhoy. You can use a table name like accounts_c4acou45cbkre if you want.
I guess what beats suffixes is infixes. :D
Fun story: I worked with a DBA who used nearly random table and field names - nonstandard abbreviations, unnatural reordering, weirds prefixes and suffixes. He didn't do it for security purposes though - he wanted us devs to always depend on him to decode those newly-added tables and fields. Although he wasn't busy (you can always see him browse eBay for Oakley sunglasses and investing in expensive Costco wines he would later sell when the price peaks - he wasn't a drinker himself), when we wanted to ask him about a field or table or beg him to write a stored procedure, he would start checking his calendar and schedule a 30-minute or 1-hour meeting at least a week in the future, often 2 or 3, and he managed to discipline us to stop asking why so further in the future by making scenes regarding how busy he is! He also persuaded our CEO to buy the super expensive ERwin (an ERD modeler), and we were getting rejecting on Visio and other products at the same time. The early 2000s were fun times!