Well, it's just an AWS Account ID | Hacker News Reader

Well, it's just an AWS Account ID

mail.cloudsecurity.club

106 pointsbnchandrapal33 comments

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.

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.

And then what?

Send targeted phishing mails.

I can already do that by sending them for root. This seems like trying to make something out of nothing.

Are you stuck in the 70s or something? I can't recall the last time I read email addressed to root.

My friend, the main AWS account is called the root account and its username is root, so your zinger didn't zing.

Our company got hit with this. I guess there's no way to recover from this other than do our best to block these.

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.

A.k.a. .. enumeration.

No, enumeration would be if you can get the entire list of usernames somehow.

> No, enumeration would be if you can get the entire list of usernames somehow.

It's still a form of enumeration.

Once you know the generation scheme, you can always enumerate some form, perfect or otherwise.

If there are rate limits, or if the search space is vast, this is notably more limited (even if arguably still enumeration)

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.

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.

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.

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.

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)

https://github.com/fwdcloudsec/known_aws_accounts

Relevant talk how you can discover the AWS Account ID of any S3 bucket: https://pretalx.com/fwd-cloudsec-2024/talk/9FRYE9/

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

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!

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.

> ...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.

As the author writes: it's not a secret, anymore than your house adresse is, but it allows a burglar to recon and plan an attack

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?

So many words and FUD...with the bottom line being...

> Here's my take: The Account ID is useless and not a direct weakness.

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

I see a tiny scrollbar on an article starting with "Let’s dive into a highly debated topic"...

I figured it must be AI-generated slop, and closed the window.

FUD, don't waste your time.

Reply on news.ycombinator.com