How to find the AWS account ID of any S3 bucket
tracebit.com
tracebit.com
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.
Anyway, this discussion is a bit amusing to me, since Devops people are discovering side channels[1] now, although other types of side channels such as speculative execution side channels on CPUs (Meltdown, Spectre) already made waves at the time of discovery, and before that we had power analysis[2] and Magnetostriction detection, and constant time cryptography (this one is a field of its own, so I omit references.)
[1] https://en.m.wikipedia.org/wiki/Side-channel_attack [2] https://en.m.wikipedia.org/wiki/Power_analysis
We, the DevOps people, already knew about side channel attacks, Spectre and the likes, evaluated the performances hit for the fixes (or alleged fixes), patched our kernel boot params etc etc. We are curious people, just like many here.
Well we are, if nothing, consistent.
The next nerd who pinches and inch of the coder/ops divide is going to make a billion.
It's amazing how anything got made considering how disjointed processes used to be.
Not GP, I tried to answer as friendly as possible. Their approach is even more weird given that Security goes really hand in hand with systems infrastructure In any small enough organization, security will be managed by devops/sre. If the org becomes large enough, it will start dedicating people to Security.
It used to be really bad... "works on my machine", bad deploy instructions etc. We paved a lot of these roads with (really fucking bad) strategies like containers. At some point maybe we will learn to write software that is operationalizable. Projects like tigerbeetle give me hope that this is our next evolution.
That is correct.
The IAM condition language is flexible and does not prevent you from doing strange things.
Doing glob matching on account IDs is like doing concatenation with guids, applying a bitshift to a UTF8 string, or running a regex on an integer. It is a nonsensical operation, and - as shown here - results in surprising security properties of the resulting system.
Surprising security properties are an undesirable result in an access control policy language.
You're not a fan of my AWS lottery idea where accounts ending in 666 get access to a free bitcoin miner??
Sharding on account ID might make sense if someone has a large number of them, but that would not necessitate wildcard matching.
filter = property, operand, value
Given the way these IaaSs' distributed KV stores all manage writes (i.e. by having a cluster of transactor nodes that per-key write-linearization responsibility for parts of the keyspace is sharded across — such that writes are fanned out to a particular designated transactor-node given the key's hash-slot), a very large S3 user, generating an extremely high level of metadata-update concurrency against a bucket, could very likely write-contend that bucket's metadata / have a "hot" bucket-metadata key; experience low perf due to that; and solve that by sharding the bucket (swapping one too-hot metadata key for N somewhat-hot metadata keys.)
I want to give an intuition-building example here, of an IaaS feature that wouldn't exist / wouldn't be exposed to the user if not for object-storage buckets being metadata-write-contended at scale. I'm not very familiar with the AWS ecosystem, though, so I'm not sure what the good example is for AWS. What I do know is GCP, so here's a GCP example: Google Cloud Dataflow allows you to set a temporary workspace GCS bucket on a per-job basis (gcsTempLocation). And, IIRC, Google's Cloud Architects advise to not have a bunch of active Dataflow jobs sharing the same gcsTempLocation — regardless of whether they use distinct key prefixes to namespace the temp files. Given that each job would be doing a lot of little serial updates to the temp bucket — and given that Dataflow jobs can each be highly internally concurrent — you're already potentially putting out O(N^2) ~concurrent updates to that bucket. You really don't want to make it O(N^3).
Either you bucket by an internal ID and give the user a hash, or you give the user an ID and bucket by your internal hash.
Users have no business knowing your sharding scheme.
Odds are that an account wildcard match like 676363687* will just match a few hundred entirely random AWS accounts.
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.
As it is my side project’s side project I do what is easy so these operators are always available even in cases where they don’t make sense (I dunno what happens if you try a regex query on a number, I don’t care) I can imagine there is something a bit like this inside AWS but for a security-sensitive system with a lot of users you have a different standard.
But that can be easier said than done for many organizations, especially when you have lots of different teams configuring their own environments.
Illustrative example: I had to deal with a third party that we needed to integrate with because of anti-money laundering procedures a year or two ago. I wanted my team to setup a privatelink with the organization because that's generally more secure than an open sftp port. The company refused citing security reasons to hide their Account Id (it's needed for the role ARN used for reciprocal permissions to PV endpoints). So what did we do?
We ended up whitelisting a range of public IPs they use for inbound port 22...
Moral of the story: you may think you are a genius for obfuscating your IDs, but you can't really run a business unless people have an address back to you
We (as a vendor ourselves) typically integrate as a VPC Endpoint Service, where communication is unidirectional and our service is exposed as a load balancer’s endpoint within the customer’s VPC.
VPC endpoints seem preferable in this situation.
What were you hoping to achieve with this utterly pointless self-censorship?
"Kid Tested. Mother Approved."
Kids tested it but we don't know if they approved it. We don't know if mothers tested it; we only know they approved it.
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.
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 before better practices and buckets all being defined in code. But with a ton of AWS accounts it can be tedious to hunt down a resource in an unknown account and possibly region.
So finding out which account owns a resource can be as simple as, roughly: select accountId where arn = "x"
It might not scale well beyond tens of accounts though, depending in your query…
That is exactly how we are setup, the amount of time I just spent going account by account looking for a specific resource.
Thank you! I have long wondered why it didn't exist, and apparently it did...
https://blog.plerion.com/conditional-love-for-aws-metadata-e...
https://github.com/cloudflare/cloudflare-docs/issues/474
https://community.cloudflare.com/t/api-zone-id/355566
> The Zone ID and Account ID are not sensitive. Sensitive data like account API Key, Secrets etc. can all be revoked, rotated or changed. See the comment 36 below on the Wrangler repo: as per our security team, it’s completely Fine to have your zone_id and account_id public, the Global API key and associated email address should be kept secret.
That said, one thing I could think of that this could be used for is correlation. If you’re running multiple S3 sites from the same AWS account, people would be able to see that they’re hosted by the same account. Whether or not this matters depends on your threat model.
As we are very canary focused, we also think it's interesting to consider the implications of the recent research from Truffle Security w.r.t canary tokens (https://trufflesecurity.com/blog/canaries).
Not necessarily. An AWS account ID + the knowledge of a role name that by mistake has the "allow role assumption" allowlist too wide (say "*") is now enough to take over the account.
One might of course say "well then don't do that", but of course the more complex a system like IAM is the easier it is for unexperienced people to open the floodgates.
In contrast, every half-decent IdP will lock an account automatically after anything from 3-10 wrong attempts.
Knowing an accountId tells you where to focus your efforts. You got through one hoop (of many).
https://medium.com/@TalBeerySec/a-short-note-on-aws-key-id-f...
These key IDs are included in the URL for pre-signed links to S3, so there's a good chance you've already been publishing your account ID.
This will probably be downvoted, but if you read this anyway: this is a good example of why "security by obscurity" is not a good defense. You will overlook something (a determined attacker will not)
Anything non-"security by obscurity" does not depend on you understanding something or not - it will apply, no matter what, as long as the attacker hasn't a genius on payroll which cracks e.g. AES-256 just so (https://www.youtube.com/watch?v=KEkrWRHCDQU)
There is a way to view bananas at
/bananas/:bananaUUID
unsecured endpoint.
I don’t want people to get all my banana data, but as long as there isn’t an easy way to list banana uuids, that endpoint is basically effective security by obscurity.
Security through obscurity means substituting security for a flawed algorithm that is usually trivial to exploit if the attacker is made aware of the algorithm. Think things like no authentication and ROT13ing and Base64ing clientside. If the method leaks or is discovered, the whole system is broken.
You just told me your algorithm and I cannot get to your banana because the UUID key space is insanely large. So that's not security to obscurity.
Hopefully you're using version 4 UUIDs. Those set aside 6 bits to encode UUID details, keeping 122 bits of entropy. Since every banana needs its own identifier, subtract the number of bits needed to uniquely represent bananas. What's left will unavoidably be less guess-resistant than client secrets. Other versions of UUID use many more bits for low-entropy purposes.
You'd have the know the name of the (development) bucket first, right?
https://docs.aws.amazon.com/accounts/latest/reference/manage...
For example, my home address is technically public, but I most certainly wouldn't want it lambasted across the interstate with a picture of my family next to it advertising where I live. It's handed out on a need-to-know basis, and I mostly trust / expect that it's kept mostly confidential, or use-limited.
I really wanted G+ to work, but they were just too stupid to understand that this was a deal-breaker.
If they're not secret, sensitive, or confidential, then why must they be shared carefully?
It's sort of like giving someone your IP address. By itself it's not enough to hack someone. But if your host is insecure, it sure makes it easier knowing exactly where to attack.
https://docs.aws.amazon.com/whitepapers/latest/data-classifi...
The other attack vector is from insiders. Many organizations "shield" identifiable information behind UUIDs or some other scheme. In the event of a breach, the UUID might mean nothing to most (it's not foolproof, though), but opens more doors for an insider.
... by us (it should say).
Users may consider it differently.
They are visible when ever you share something with another AWS account, they're in the ARN. For example, the 12 digit account IDs of all a vendors that vend AMIs, assume roles on AWS accounts (think datadog, for logging / metrics) or otherwise provide services have AWS Account IDs that are well known and easily discoverable. This s3 example is just sort of interesting since its one of the handful of AWS services that don't use account IDs in ARNs.
AWS account ids are not secrets and treating them as secrets or giving the impression that they are anything other than public data is a distraction from real security concerns.
Presumably you could use this to find real principals in the other account.
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.
not free as in: you have to manage it (for example give a CI role access via OIDC, create a role for you to assume to do stuff via the console, etc)
id is static while email can be changed.
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 expose your ID to the world and break your entire security model, because AWS doesn’t think it’s secret. If you do, you’re basing your security off of false assumptions.
Stated another way: you can unintentionally make your account ID sensitive if you're not careful. You have to be careful.
> 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.
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:
It narrows all the possible account IDs to one.
Is that ID already compromised? Can you gain access through someone else that does the work for you?
You can cross reference with other systems you have compromised. Is that account ID in their system? What access does that give you?
Etc, etc. It is not a secret, but it absolutely is valuable.
For example, if you considered it a secret (even though it is not), you might not choose to use third parties that require it, and that can improve your security posture.
You might have a 100% secure system, but you don't want your competitor to know exactly what you are doing. You might also not consider their knowledge of what you're doing to be a vulnerability, nor think that you should spend many resources on preventing them from knowing, you just don't want to make it easy for them.
Cryptography is very black-and-white. Business operational intelligence is not.
https://docs.aws.amazon.com/accounts/latest/reference/manage...
> While account IDs, like any identifying information, should be used and shared carefully, they are not considered secret, sensitive, or confidential information.
If you want protection against that, you need to focus on better home security, hiring bodyguards, going to the police etc, and you’re better off assuming that the assassin will find your address regardless of whether or not you wear a t-shirt with it printed on.
Put another way: there’s a difference between “I don’t do this thing” and “I rely on not doing this thing for my safety”. The second one makes a lot more assumptions than the first one does, and those assumptions can lead to problems if they are false assumptions.
That was my point. The fact that some organizations consider AWS account IDs sensitive is independent of whether they rely on it being sensitive or not.
I might have taken all precautions against an assassin attack, yet I won't make the assassin's job easier by announcing my PII to them. The fact that I won't announce my PII says nothing about whether I took the security precautions.
There’s a difference between “making it easier for an attacker” and using it as a security control, even if it’s not the only security control. The point is that even if you don’t go around wearing a shirt with your address on it, that should never factor in to your designs for security. It should never be considered a security control, even a “defense in depth” one.
In fact, your threat model should ideally ask the question “assume someone does walk around with a shirt with my address on it, will I still be safe?” That doesn’t mean you’re actually going to go do it, but if the answer is yes, that’s how you know you’ve done your job.
Then I don't understand why you object so strongly to the tshirt example unless you're deliberately talking past the person that made it.
Since AWS does not, and has never, treated that information as secret, then there is absolutely no reason to consider it sensitive because there is no security guarantees with how AWS handles those IDs (as this article demonstrates).
Thus, either you're including them into your threat model as sensitive and thus immediately opening up yourself to vulnerabilities (bad security), or you're not including them at all (and thus not treating them as sensitive/secret/whatever). The argument the parent had (and that I agree with) is that you should do the latter unless AWS provides a means to work with those IDs securely (it won't because they're not secrets).
Any time a topic like this comes up, there are people on this forum that try to apply the "security by obscurity does not work" principle to every security topic under the sun, when in reality, that principle really only applies to the world of cryptography. In meat space, where humans operate on plaintext, keeping a secret is a very valid approach to some topics. This is why things like NDAs exist.
There is a lot of data that exists in a space somewhere between "100% secret" and "100% public". This is one of those situations, for many organizations.
> This is one of those situations, for many organizations.
And those organizations are wrong.
> by pretending it’s secret
No, nobody needs to pretend it is secret. You're missing my above point. There is not a dichotomy between secret and public. It is possible for something to be neither secret nor public.
* 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.
This is not the stuff secrets are made of.
Trying to eek some sort of security story out of hiding account ids plays right into security through obscurity. As it’s not treated as a secret the most you’re doing is obscuring the attack surface of your infrastructure. IAM doesn’t allow anyone to use the knowledge of your account ID to grant any privilege not specifically granted within the account itself via two way grants. Holes in your IAM policies aren’t protected by hiding the account ID, they’re protected by closing the holes.
But you might notice that even aws services advertise their own account ids. They’re not secrets and treating them as such doesn’t help you improve security.
If you get an email apparently from AWS that correctly names an S3 bucket and the associated account ID, are you more likely to take it seriously than an email that just names a bucket?
No, the account ID isn’t secret but I don’t think we should be dismissive of this new information either. It’s still important metadata to factor into decision making.
Edge cases, to be sure, but certainly nontrivial.
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.
So sure, maybe pat yourself on the back today that on top of your other measures, no one outside your org and AWS knows your Account ID. But if it gets out at some point, those other measures should be foiling your pentesters on their own. In fact, to better test that this is the case, you should probably give the pentesters your account ID so you can be informed regarding your security in this scenario.
Yes, there are types of data and metadata about your company's infrastructure that can be used against you. But no, you shouldn't hand it to attackers on a silver platter.
> In fact, to better test that this is the case, you should probably give the pentesters your account ID so you can be informed regarding your security in this scenario.
That depends on the scope of the test. Many organizations will do both (and others) to test different layers of security. Remote software exploits are something that many people on this forum are concerned about, but that is hardly the be-all-end-all of security for an organization. There's a lot of security topics entirely outside the scope of computer systems to be cognisant about here.
So if Amazon doesn't keep the account ID a secret how can you as a user of Amazon be expected to keep your account ID secret? There's no way for you to stop Amazon from exposing it.
Amazon says it's not secret, so it's not secret. They make no attempts or guarantees to keep it secret so there's always the threat that Amazon themselves can expose it on your behalf. You can't stop that no matter how wrong you think it is.
so much depends
upon
a regular
expression
"Hi, this is Tom from AWS, I need to speak with you about your account 5923965523" - as a social engineering primer garners significantly different levels of trust from the target depending on whether the target perceives the account ID to be privileged information.
AWS account ID is not sensitive data in any way. Just because you can screw up a config doesnt make a user name or account id “sensitive”.
Its not more sensitive than an email address. What is wrong with you people? Where did you come from, and why are you so dumb?
let's say if apple uses s3, they need to create bucket name "apple.com", and then we can find what aws account which apple is using.
I have dozens of s3 static websites served from a single s3 bucket, all with unique top-level domains, each in its own folder within that single bucket - much easier this way.
Given anyone can create a bucket with any name (if its not already in use), you can't count on getting the bucket name that matches your domain name.
This is outdated information, and not required anymore when using CloudFront.
And even in the past, you could use the S3 API to implement a reverse proxy without matching bucket and domain names.
https://docs.aws.amazon.com/AmazonS3/latest/userguide/websit...
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?
And this still doesn’t let you tie an account ID to an email or human.
No, it's Simple. Simple Storage Service