This 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.
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.
Yes, you're right. Reading my statement in hindsight shows thats not correct. My intention was to convey that you can check for the existence of common IAM users and roles in the accounts (and even existence of company specific entities like users with first.last pattern, product names, etc)
I've slightly updated the point a bit.
You're correct, it's not enumeration, but it's easier than pure brute force. As the article itself suggests, if the company does use a predictable user name format (and most do), it's pretty trivial to look up their employees on LinkedIn, create a list of likely usernames, and then check if they exist.
Enumeration means a specific thing, that you get a full or paginated list of things and all you need to do is hit it. This isn't enumeration at all. It's like you saying you know the bucket keys to a hashtable so you can enumerate it by hitting them one by one, except in this case you don't even know the keys.
How does knowing the AWS username allow you to send a more effective phishing email? Especially if the username is just the user's... name. That's public info.
Nice article. For those interested here is a project listing companies who's AWS account IDs are known (generally because the IDs have been publicly disclosed by the company itself for product integration purposes)
I 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 field names the same way, please! :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!
Not an expert on AWS, but as this seems something that you may need to share and that cannot be easily changed, considering it a secret is just snake oil.
I'd think of it as more a defence in depth measure. It's not a secret, but taking some common sense steps to not spray it all over the place could slow down an attacker, and a lot of the time just making yourself a slightly harder target than the next guy is enough that an attacker will go in search of softer targets.
This 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?
Agree, obscurity is mostly not good to rely on, it allows you to congratulate yourself about defense in depth and what not but it’s a bit security theatre
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.