42 ms·

How to find the AWS account ID of any S3 bucket

583 points by tracebit 3y ago

mise_en_place 3y ago
This is kind of a big deal, but also not really? UUIDs are not IDs. And IDs are not always indices. This is a common design flaw in many distributed systems.
static_void_ 3y ago
Account IDs are 12 digit random numbers. They are used to identify an AWS account, that's all. Knowledge of the full 12 digits doesn't grant access to anything, prove you own the account, or enable you to authenticate to any systems (or individuals like in customer service for example) in AWS. 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.
ianhawes 3y ago
TIL: AWS Account IDs are considered secrets. IMO, if a given value cannot be cycled, it is sensitive but not secret.
- tracebit 3y ago
  AWS do not define account IDs as a secret (https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-identifiers.html https://docs.aws.amazon.com/accounts/latest/reference/manage...) but until now it's not been possible to do this look up.
- abadpoli 3y ago
  AWS Account IDs are not secret and don’t need to be. AWS doesn’t design anything that assumes your account ID is secret, and you shouldn’t either.
  - dekhn 3y ago
    I've gotten in long arguments with senior IT people who refuse to believe this even when they talk to AWS directly about it.
    - dylan604 3y ago
      I guess anything that looks like random letters/numbers is going to be considered a secret to some people. If it wasn't meant to be secret, it would be human readable. Or some such nonsense.
  - electroly 3y ago
    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't leak anything interesting about your business that you'd prefer to keep private. Correlated ownership of buckets (e.g. different clients of the same design firm) in particular is something AWS doesn't care about, but you might. If you don't want people to know that the buckets have the same owner, better split it up into separate accounts to preserve the non-secretness of the account ID.
    - abadpoli 3y ago
      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 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.
- jameshart 3y ago
  AWS account IDs aren’t secret, but the identity of who owns particular S3 bucket names is meant to be. 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?
  - afavour 3y ago
    Not to mention it also means you can establish relationships between buckets by finding common ownership. 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.
  - btown 3y ago
    More generally, this opens up all sorts of threat models for espionage and alternative data. A private bucket called project-foobar-logs-staging might have its existence known in an index but never have been known to be associated with Baz Corp's publicly-known image buckets - but with this disclosure, a database will become available making that association possible. And it will be possible to monitor if and when project-foobar-logs-prod gets provisioned. Not to mention that state-level actors would love to see an enumerable list of projects their rivals are working on, and if any of them happen to have been secured only by obscurity in the past. Edge cases, to be sure, but certainly nontrivial.
- INTPenis 3y ago
  It's valuable info to any pentester. Security by obscurity is still one layer of security.
  - Uehreka 3y ago
    But there’s a reason people advise against security by obscurity: the obscurity can go away at any time and once it does it’s unrecoverable. 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.
    - corytheboyd 3y ago
      When obscurity is the only option, like opting not to expose AWS account ID, why not do it? Don’t think this should be conflated with replacing proper security with obscurity, which is obviously wrong. The less you expose about your operation, the better. Not exposing details of your infrastructure to the public is another commonly suggested best practice that is obscurity, not security, that nobody challenges. For example, cleaning up common default response headers for things like cloud front.
      - evandale 3y ago
        You can't keep it secret because Amazon doesn't keep it secret. 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.
        corytheboyd 3y ago
        You as a user of Amazon can do whatever you want though, including being careful about which pieces of information you elect to expose publicly. If it’s up to you, why choose to expose it, when you can choose NOT to? Just because this reverse search of bucket to account id exists doesn’t mean you should begin to expose your account id on your own.
- fnordpiglet 3y ago
  They’re not a secret, in fact it’s what you use to share the identity of one account with another, possibly third party’s account. It’s a secret in the way your personal email address is. You may not advertise it on 4chan, but you definitely share it to limited audiences. Once you’ve shared it it’s no longer an actual secret. Indeed, as has been noted, aws itself doesn’t treat your account id as a secret and freely shares it within aws, logs it in plain text, uses it for operations with human operators, internal reporting, etc. It’s an identifier, it’s discoverable, shareable, and leaks all over the place. 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.
  - sroussey 3y ago
    Yes, but I do use random email addresses (that look like passwords) to stop correlation, concerted credential stuffing (that might lock me out for a time), etc. And if it pops up in a compromised server no one will know that email address is mine.
    - fnordpiglet 3y ago
      And aws also offers ideas like external IDs and similar concepts to do something like this. 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.
- corytheboyd 3y ago
  Everyone here throwing down the “technically not a secret” card but I don’t think that was your point. I guess “sensitive, but not secret” is the right way to say it. They’re obviously not secret like credentials, but it’s a damn good piece of info for an attacker to hold against you, because, like you said, it’s impossible to rotate, but is tangentially related to every single part of your AWS infrastructure (per-account of course).
  - evandale 3y ago
    It's not even sensitive or confidential though, Amazon says that themselves in their docs.
    - corytheboyd 3y ago
      I guess I disagree with the AWS documentation then. It should be treated as a sensitive piece of information that should not be exposed to the public. It’s not going to bring you down if it’s leaked, but it could be used along with other leaked info over years in more sophisticated attacks. Why risk it is more the point.
- paulddraper 3y ago
  Not at all. 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.
samstave 3y ago
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.
- deleted 3y ago
  [deleted]
- JohnMakin 3y ago
  Exploiting incorrect/weak IAM permissions I would assume.
- upheaval7276 3y ago
  No. Simple Storage Service
- PodgieTar 3y ago
  Of S3? No, it's Simple. Simple Storage Service
- akerl_ 3y ago
  No. None of the Ss in S3 stand for Secure. And this still doesn’t let you tie an account ID to an email or human.
- beepboopboop 3y ago
  > Shove it … in Simple Storage Service?
busymom0 3y ago
Slightly related - CloudFlare account_id and zone_id are safe to be public https://github.com/cloudflare/cloudflare-docs/issues/474 https://github.com/cloudflare/cloudflare-docs/issues/474 https://community.cloudflare.com/t/api-zone-id/355566 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.
- abadpoli 3y ago
  AWS account ID is also safe to be public. 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.
  - tracebit 3y ago
    Exactly - this isn't going to open the door for someone but could add a ton of value to enumeration. 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 https://trufflesecurity.com/blog/canaries).
  - mschuster91 3y ago
    > AWS account ID is also safe to be public. 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.
    - anamexis 3y ago
      Well sure, but your account email isn't safe to be public if your password is "password".
tracebit 3y ago
For those interested, we put the code online here: https://github.com/tracebit-com/find-s3-account https://github.com/tracebit-com/find-s3-account
- belter 3y ago
  I am not sure this would be in agreement with these policies, or at least the spirit of them: https://aws.amazon.com/security/penetration-testing/ https://aws.amazon.com/security/penetration-testing/
  - jkaplowitz 3y ago
    OP's article said they consulted with Amazon's security team before publishing, so I imagine they know what's allowed in this case.
    - belter 3y ago
      It says he consulted but does not say what was their answer. I can't imagine it was a thumbs up, probably an embarrassed silence?
      - willcipriano 3y ago
        They can fix the bug if they don't like it.
        Breza 3y ago
        This is my attitude towards security disclosures. In this case, Amazon approved the disclosure. But even if they hadn't, it's better for the good guys and bad guys to know about problems when the alternative is only the bad guys knowing (or the bad guys and a few good guys at the affected company).
      - chriscjcj 3y ago
        Reminds me of the old slogan for Kix cereal. "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.
nerdjon 3y ago
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 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.
- emilburzo 3y ago
  If you use AWS config setup for the organization (aggregator), you'll get a athena-sql-queryable inventory of all your resources from all organization accounts. So finding out which account owns a resource can be as simple as, roughly: select accountId where arn = "x"
  - nerdjon 3y ago
    ... how did I not know this existed. 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...
    - mfenniak 3y ago
      Be aware that AWS Config is not free. https://aws.amazon.com/config/pricing/ https://aws.amazon.com/config/pricing/
      - nijave 3y ago
        Yeah it's pretty nice feature wise but surprisingly expensive given all it really does is run API calls in a loop and export to S3
  - baby_souffle 3y ago
    You can also do this with steam pipe. It might not scale well beyond tens of accounts though, depending in your query…
phendrenad2 3y ago
Can we go further, and find the email associated with an account ID?
- tuananh 3y ago
  i dont think we can. id is static while email can be changed.
  - ikbear 3y ago
    [dead]
  - eax-eip 3y ago
    How about the other way: email -> account ID?
jameshart 3y ago
> The ability to apply a wildcard match on the s3:ResourceAccount condition key 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.
- efitz 3y ago
  That's the part that surprised me as well; it doesn't seem like a field that should be eligible for anything other than an exact match. I am unable to conceive of a use case for pattern matching account IDs.
  - sroussey 3y ago
    Well, that assumes that the ID is cryptographically random. Perhaps that is a bad assumption.
    - pc86 3y ago
      Even if it's not that doesn't mean pattern matching IDs is good.
      - sroussey 3y ago
        Oh god, no. Seems like a bad idea indeed! But might give some insight into their system.
    - dclowd9901 3y ago
      If it's sequential, that somehow seems worse?
    - jameshart 3y ago
      My general assumption is not that they’re random, but at least that they’re not correlated; in particular that Amazon is not in the habit of handing out, like, account IDs 676363687000 - 676363687999 to a single organization. Even if they did hand out a sequential batch of 1000 account IDs, it would be more likely to be 676363687541 - 676363688540 than a set with a single consistent prefix. Odds are that an account wildcard match like 676363687* will just match a few hundred entirely random AWS accounts.
RajT88 3y ago
Will it make it easier to identify the operators of malvertising campaigns hosted on AWS?
- victorbjorklund 3y ago
  Doubt they use their real information on their AWS accounts.
  - dotancohen 3y ago
    Just need enough information to send to either Amazon or the FBI.
    - 8organicbits 3y ago
      Shouldn't the bucket name / URL be enough?
      - dotancohen 3y ago
        The answer to these types of questions is, depends upon who gets the case. Generally, the further along you've gotten within legal limits, the better the chance that the case will be given serious consideration and time.
    - victorbjorklund 3y ago
      Pretty sure AWS always could look up the info of an account if a bucket was used for crimes. Adding the name of a fake account probably doesnt add anything for them.
sylens 3y ago
While I wouldn't publicly hand out my account IDs as a general practice, I think you have to expect that some of them will be disclosed at some point. As more third party vendors and SaaS platforms move away from IAM users and access keys to using role assumption as the preferred method of integration (as they should!), the account ID of at least the account you use as their integration point is now known by another party, who have their own dependencies, vulnerabilities, etc.
- SamuelAdams 3y ago
  This is what I’m curious to learn. What can an attacker do with an AWS account ID? How is that any different from knowing someone’s email address?
  - sylens 3y ago
    If the account and its resources are properly configured - not much. But that can be easier said than done for many organizations, especially when you have lots of different teams configuring their own environments.
  - deleted 3y ago
    [deleted]
  - quickthrower2 3y ago
    Useful social engineering datapoint
  - coredog64 3y ago
    Once I have an AWS account ID, my next trick is to grant cross-account bucket policies to discover role names in the account.
    - baby_souffle 3y ago
      How does this work?
      - 3y ago
jokoon 3y ago
Maybe their logic is to let authorities track people who misuses it?
tuananh 3y ago
aws s3 bucket needs to match the domain for website hosting. 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.
- ejb999 3y ago
  Not exactly - they Can do that, but they don't need to match - using cloudfront in front of your s3 website and then the site can be served from any bucket or folder within a bucket. 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.
  - tuananh 3y ago
    ah thanks. iirc it used to be like that ( when use without cloudfront).
- mayank 3y ago
  > aws s3 bucket needs to match the domain for website hosting. 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.
- hacker_newz 3y ago
  That is not how s3 buckets work.
  - tuananh 3y ago
    it used to be like that (without cloudfront) https://docs.aws.amazon.com/AmazonS3/latest/userguide/website-hosting-custom-domain-walkthrough.html https://docs.aws.amazon.com/AmazonS3/latest/userguide/websit...
ed 3y ago
How might this matter? A obvious one: Given a production bucket, it’s now possible to find development buckets for that same org, which is not expected behavior IMO.
- catlifeonmars 3y ago
  Unlikely, unless dev buckets are somehow in the same account.
  - booi 3y ago
    it's bad practice but it's more common than you think especially with older accounts (pre-organization)
- drjasonharrison 3y ago
  Only true if they use the same accounts for both production and development. This would be another reason not to use the same accounts.
- corytheboyd 3y ago
  You only need the bucket name to do that. You should include a randomly generated prefix/suffix in bucket names to prevent against such enumeration attempts. Another good idea (as well as, not instead of) is to expose objects in buckets publicly with a non-default host name, such that the bucket name isn’t leaked at all.
  - gusmd 3y ago
    Or, for read scenarios, putting a CloudFront distribution in front of the bucket!
- paulddraper 3y ago
  How so? You'd have the know the name of the (development) bucket first, right?
  - 3y ago
dheera 3y ago
Perhaps this can make s3fs and similar mounting tools easier to use; just plug in the bucket, enter password, and it mounts.
cj 3y ago
> While account IDs, like any identifying information, should be used and shared carefully, they are not considered secret, sensitive, or confidential information. https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-identifiers.html https://docs.aws.amazon.com/accounts/latest/reference/manage...
- dimitrios1 3y ago
  Seems like at least in the digital world, there is either public or private information, and that's it. We don't really have a good concept of privilege or protected information. 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.
  - greiskul 3y ago
    One huge mistake that Google did when they were integrating youtube with Google+, was the idea of sharing people's youtube comments with their G+ friends. Youtube comments have always been public, but there was huge customer pushback, forcing them to revert them for this idea, since there is in people's mind a huge difference between public and publicized comments.
    - styfle 3y ago
      Also G+ made your email address public to your friends/circles/etc and I don’t think there was a way to disable it.
    - mellutussa 3y ago
      Yep, that and other things like reviews wm you did went straight to your Google+ page. I really wanted G+ to work, but they were just too stupid to understand that this was a deal-breaker.
- panarky 3y ago
  What does this mean? If they're not secret, sensitive, or confidential, then why must they be shared carefully?
hassli 3y ago
[flagged]
bjw4 3y ago
Any tips on how to do the same for EC2 instances? Am aware of one that’s allegedly joined to our domain but can’t find it in any owned accounts
- vegardx 3y ago
  If you're lucky and it has a instance profile attached with appropriate role/policy attached you can use get caller identity to see what account it's running in: https://docs.aws.amazon.com/cli/latest/reference/sts/get-caller-identity.html https://docs.aws.amazon.com/cli/latest/reference/sts/get-cal...
bagels 3y ago
What value is there in allowing wildcard account id matching? I can't think of a legitimate use case.
- denysvitali 3y ago
  This is probably the rule engine of the policies being used for something less useful
- syncsynchalt 3y ago
  It's likely only allowed because someone didn't think to explicitly disallow it.
thenickdude 3y ago
Related: AWS key IDs (not the secret key part) include your account ID within them, bitshifted by one position: https://medium.com/@TalBeerySec/a-short-note-on-aws-key-id-f88cc4317489 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.
- firebaze 3y ago
  Quite a few people in this thread assume that the AWS key id is part of a "security by obscurity" "protection in depth". 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 https://www.youtube.com/watch?v=KEkrWRHCDQU)
  - ralusek 3y ago
    To me security by obscurity is limited to things like this: 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.
    - disruptiveink 3y ago
      That's an unfortunately common misconception. Your example is not security though obscurity any more than password authentication is, though. 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.
orf 3y ago
Interesting post. I wonder if you can further combine it by using a PrincipalTag in some way? You can assume a number of roles with different tag values, and these can be interpolated into the condition. This lets you do things without a huge statement?
NovemberWhiskey 3y ago
There seems to be a large discussion of whether account IDs are "secret" or "private" or "confidential" or whatever. 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.
- denysvitali 3y ago
  Accounts on AWS are pretty cheap (free?) - why would you host everything on the same account?
  - gaudystead 3y ago
    You may be underestimating human laziness...
  - whs 3y ago
    In my company we use reseller billing as AWS do not have a local billing entity. The reseller owns the organization's root account and we do not have access to it. Every subaccount creation require a support email to the reseller.
  - Garlef 3y ago
    free as in: AWS does not charge you 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)
    - NovemberWhiskey 3y ago
      My favorite factoid about AWS accounts is that there's a global, hard rate limit for their deletion. It's actually a pain point for us.
huslage 3y ago
I have always likened AWS Account IDs to be similar to public keys. But even less useful. There is nothing useful that you can do with them without other information.
master_crab 3y ago
AWS account ID == Your IP address. It may be sensitive, but someone needs to know it to get s*$t done. 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
- stingraycharles 3y ago
  AWS PrivateLink has another property that generally makes it undesirable for these types of integrations: communication is bidirectional, and IP subnets should not overlap. 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.
  - EE84M3i 3y ago
    I thought PrivateLink was branding for vpc interface endpoints? There's no ip subject restriction for that because it's basically a proxy. Are you thinking of vpc peering? VPC endpoints seem preferable in this situation.
    - stingraycharles 3y ago
      Oh I apologize, you’re completely correct and I am confusing PrivateLink with VPC peering. Thank you for correcting me.
- executesorder66 3y ago
  > get s*$t done What were you hoping to achieve with this utterly pointless self-censorship?
sam0x17 3y ago
Any scenario where the actual hack results in the time-honored trope/misunderstanding of "hacking" the password one character at a time is awesome
lijok 3y ago
ITT lots of debate on whether AWS Account IDs are sensitive or not. To chime in my 2c; we've had this debate in multiple orgs with different security teams and the outcome has always been the same; they're not and it's counterproductive to your security posture to treat it as privileged information. Humans have a nasty habit of placing trust in people who have access to privileged information. "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.
- deleted 3y ago
  [deleted]
datadeft 3y ago
Sometimes I am having trouble finding my own AWS account id...
myroon5 3y ago
Other public AWS resources with global namespaces also reveal AWS account IDs: https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/ https://blog.plerion.com/conditional-love-for-aws-metadata-e...
d0gsg0w00f 3y ago
I think the more worrying attack vector is when you now use the account number to try and Allowlist a principal from that account in some policy in your account. If the principal doesn't exist in the other account you'll get a role/user not found error! Presumably you could use this to find real principals in the other account.
jimmalongading 3y ago
I apologize in advance for what Im going to say here. 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?
rosa4151 3y ago
[flagged]
daveevad 3y ago
> the ability to use StringLike conditions so much depends upon a regular expression

583 points by tracebit 3y ago

This is kind of a big deal, but also not really? UUIDs are not IDs. And IDs are not always indices. This is a common design flaw in many distributed systems.

static_void_ 3y ago

Account IDs are 12 digit random numbers. They are used to identify an AWS account, that's all. Knowledge of the full 12 digits doesn't grant access to anything, prove you own the account, or enable you to authenticate to any systems (or individuals like in customer service for example) in AWS. 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.

ianhawes 3y ago

TIL: AWS Account IDs are considered secrets. IMO, if a given value cannot be cycled, it is sensitive but not secret.

tracebit 3y ago
AWS do not define account IDs as a secret (https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-identifiers.html https://docs.aws.amazon.com/accounts/latest/reference/manage...) but until now it's not been possible to do this look up.
abadpoli 3y ago
AWS Account IDs are not secret and don’t need to be. AWS doesn’t design anything that assumes your account ID is secret, and you shouldn’t either.
- dekhn 3y ago
  I've gotten in long arguments with senior IT people who refuse to believe this even when they talk to AWS directly about it.
  - dylan604 3y ago
    I guess anything that looks like random letters/numbers is going to be considered a secret to some people. If it wasn't meant to be secret, it would be human readable. Or some such nonsense.
- electroly 3y ago
  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't leak anything interesting about your business that you'd prefer to keep private. Correlated ownership of buckets (e.g. different clients of the same design firm) in particular is something AWS doesn't care about, but you might. If you don't want people to know that the buckets have the same owner, better split it up into separate accounts to preserve the non-secretness of the account ID.
  - abadpoli 3y ago
    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 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.
jameshart 3y ago
AWS account IDs aren’t secret, but the identity of who owns particular S3 bucket names is meant to be. 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?
- afavour 3y ago
  Not to mention it also means you can establish relationships between buckets by finding common ownership. 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.
- btown 3y ago
  More generally, this opens up all sorts of threat models for espionage and alternative data. A private bucket called project-foobar-logs-staging might have its existence known in an index but never have been known to be associated with Baz Corp's publicly-known image buckets - but with this disclosure, a database will become available making that association possible. And it will be possible to monitor if and when project-foobar-logs-prod gets provisioned. Not to mention that state-level actors would love to see an enumerable list of projects their rivals are working on, and if any of them happen to have been secured only by obscurity in the past. Edge cases, to be sure, but certainly nontrivial.
INTPenis 3y ago
It's valuable info to any pentester. Security by obscurity is still one layer of security.
- Uehreka 3y ago
  But there’s a reason people advise against security by obscurity: the obscurity can go away at any time and once it does it’s unrecoverable. 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.
  - corytheboyd 3y ago
    When obscurity is the only option, like opting not to expose AWS account ID, why not do it? Don’t think this should be conflated with replacing proper security with obscurity, which is obviously wrong. The less you expose about your operation, the better. Not exposing details of your infrastructure to the public is another commonly suggested best practice that is obscurity, not security, that nobody challenges. For example, cleaning up common default response headers for things like cloud front.
    - evandale 3y ago
      You can't keep it secret because Amazon doesn't keep it secret. 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.
      - corytheboyd 3y ago
        You as a user of Amazon can do whatever you want though, including being careful about which pieces of information you elect to expose publicly. If it’s up to you, why choose to expose it, when you can choose NOT to? Just because this reverse search of bucket to account id exists doesn’t mean you should begin to expose your account id on your own.
fnordpiglet 3y ago
They’re not a secret, in fact it’s what you use to share the identity of one account with another, possibly third party’s account. It’s a secret in the way your personal email address is. You may not advertise it on 4chan, but you definitely share it to limited audiences. Once you’ve shared it it’s no longer an actual secret. Indeed, as has been noted, aws itself doesn’t treat your account id as a secret and freely shares it within aws, logs it in plain text, uses it for operations with human operators, internal reporting, etc. It’s an identifier, it’s discoverable, shareable, and leaks all over the place. 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.
- sroussey 3y ago
  Yes, but I do use random email addresses (that look like passwords) to stop correlation, concerted credential stuffing (that might lock me out for a time), etc. And if it pops up in a compromised server no one will know that email address is mine.
  - fnordpiglet 3y ago
    And aws also offers ideas like external IDs and similar concepts to do something like this. 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.
corytheboyd 3y ago
Everyone here throwing down the “technically not a secret” card but I don’t think that was your point. I guess “sensitive, but not secret” is the right way to say it. They’re obviously not secret like credentials, but it’s a damn good piece of info for an attacker to hold against you, because, like you said, it’s impossible to rotate, but is tangentially related to every single part of your AWS infrastructure (per-account of course).
- evandale 3y ago
  It's not even sensitive or confidential though, Amazon says that themselves in their docs.
  - corytheboyd 3y ago
    I guess I disagree with the AWS documentation then. It should be treated as a sensitive piece of information that should not be exposed to the public. It’s not going to bring you down if it’s leaked, but it could be used along with other leaked info over years in more sophisticated attacks. Why risk it is more the point.
paulddraper 3y ago
Not at all. 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.

samstave 3y ago

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.

deleted 3y ago
[deleted]
JohnMakin 3y ago
Exploiting incorrect/weak IAM permissions I would assume.
upheaval7276 3y ago
No. Simple Storage Service
PodgieTar 3y ago
Of S3? No, it's Simple. Simple Storage Service
akerl_ 3y ago
No. None of the Ss in S3 stand for Secure. And this still doesn’t let you tie an account ID to an email or human.
beepboopboop 3y ago
> Shove it … in Simple Storage Service?

busymom0 3y ago

Slightly related - CloudFlare account_id and zone_id are safe to be public https://github.com/cloudflare/cloudflare-docs/issues/474 https://github.com/cloudflare/cloudflare-docs/issues/474 https://community.cloudflare.com/t/api-zone-id/355566 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.

abadpoli 3y ago
AWS account ID is also safe to be public. 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.
- tracebit 3y ago
  Exactly - this isn't going to open the door for someone but could add a ton of value to enumeration. 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 https://trufflesecurity.com/blog/canaries).
- mschuster91 3y ago
  > AWS account ID is also safe to be public. 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.
  - anamexis 3y ago
    Well sure, but your account email isn't safe to be public if your password is "password".

tracebit 3y ago

For those interested, we put the code online here: https://github.com/tracebit-com/find-s3-account https://github.com/tracebit-com/find-s3-account

belter 3y ago
I am not sure this would be in agreement with these policies, or at least the spirit of them: https://aws.amazon.com/security/penetration-testing/ https://aws.amazon.com/security/penetration-testing/
- jkaplowitz 3y ago
  OP's article said they consulted with Amazon's security team before publishing, so I imagine they know what's allowed in this case.
  - belter 3y ago
    It says he consulted but does not say what was their answer. I can't imagine it was a thumbs up, probably an embarrassed silence?
    - willcipriano 3y ago
      They can fix the bug if they don't like it.
      - Breza 3y ago
        This is my attitude towards security disclosures. In this case, Amazon approved the disclosure. But even if they hadn't, it's better for the good guys and bad guys to know about problems when the alternative is only the bad guys knowing (or the bad guys and a few good guys at the affected company).
    - chriscjcj 3y ago
      Reminds me of the old slogan for Kix cereal. "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.

nerdjon 3y ago

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

emilburzo 3y ago
If you use AWS config setup for the organization (aggregator), you'll get a athena-sql-queryable inventory of all your resources from all organization accounts. So finding out which account owns a resource can be as simple as, roughly: select accountId where arn = "x"
- nerdjon 3y ago
  ... how did I not know this existed. 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...
  - mfenniak 3y ago
    Be aware that AWS Config is not free. https://aws.amazon.com/config/pricing/ https://aws.amazon.com/config/pricing/
    - nijave 3y ago
      Yeah it's pretty nice feature wise but surprisingly expensive given all it really does is run API calls in a loop and export to S3
- baby_souffle 3y ago
  You can also do this with steam pipe. It might not scale well beyond tens of accounts though, depending in your query…

phendrenad2 3y ago

Can we go further, and find the email associated with an account ID?

tuananh 3y ago
i dont think we can. id is static while email can be changed.
- ikbear 3y ago
  [dead]
- eax-eip 3y ago
  How about the other way: email -> account ID?

jameshart 3y ago

> The ability to apply a wildcard match on the s3:ResourceAccount condition key 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.

efitz 3y ago
That's the part that surprised me as well; it doesn't seem like a field that should be eligible for anything other than an exact match. I am unable to conceive of a use case for pattern matching account IDs.
- sroussey 3y ago
  Well, that assumes that the ID is cryptographically random. Perhaps that is a bad assumption.
  - pc86 3y ago
    Even if it's not that doesn't mean pattern matching IDs is good.
    - sroussey 3y ago
      Oh god, no. Seems like a bad idea indeed! But might give some insight into their system.
  - dclowd9901 3y ago
    If it's sequential, that somehow seems worse?
  - jameshart 3y ago
    My general assumption is not that they’re random, but at least that they’re not correlated; in particular that Amazon is not in the habit of handing out, like, account IDs 676363687000 - 676363687999 to a single organization. Even if they did hand out a sequential batch of 1000 account IDs, it would be more likely to be 676363687541 - 676363688540 than a set with a single consistent prefix. Odds are that an account wildcard match like 676363687* will just match a few hundred entirely random AWS accounts.

RajT88 3y ago

Will it make it easier to identify the operators of malvertising campaigns hosted on AWS?

victorbjorklund 3y ago
Doubt they use their real information on their AWS accounts.
- dotancohen 3y ago
  Just need enough information to send to either Amazon or the FBI.
  - 8organicbits 3y ago
    Shouldn't the bucket name / URL be enough?
    - dotancohen 3y ago
      The answer to these types of questions is, depends upon who gets the case. Generally, the further along you've gotten within legal limits, the better the chance that the case will be given serious consideration and time.
  - victorbjorklund 3y ago
    Pretty sure AWS always could look up the info of an account if a bucket was used for crimes. Adding the name of a fake account probably doesnt add anything for them.

sylens 3y ago

While I wouldn't publicly hand out my account IDs as a general practice, I think you have to expect that some of them will be disclosed at some point. As more third party vendors and SaaS platforms move away from IAM users and access keys to using role assumption as the preferred method of integration (as they should!), the account ID of at least the account you use as their integration point is now known by another party, who have their own dependencies, vulnerabilities, etc.

SamuelAdams 3y ago
This is what I’m curious to learn. What can an attacker do with an AWS account ID? How is that any different from knowing someone’s email address?
- sylens 3y ago
  If the account and its resources are properly configured - not much. But that can be easier said than done for many organizations, especially when you have lots of different teams configuring their own environments.
- deleted 3y ago
  [deleted]
- quickthrower2 3y ago
  Useful social engineering datapoint
- coredog64 3y ago
  Once I have an AWS account ID, my next trick is to grant cross-account bucket policies to discover role names in the account.
  - baby_souffle 3y ago
    How does this work?
    - 3y ago

jokoon 3y ago

Maybe their logic is to let authorities track people who misuses it?

tuananh 3y ago

aws s3 bucket needs to match the domain for website hosting. 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.

ejb999 3y ago
Not exactly - they Can do that, but they don't need to match - using cloudfront in front of your s3 website and then the site can be served from any bucket or folder within a bucket. 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.
- tuananh 3y ago
  ah thanks. iirc it used to be like that ( when use without cloudfront).
mayank 3y ago
> aws s3 bucket needs to match the domain for website hosting. 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.
hacker_newz 3y ago
That is not how s3 buckets work.
- tuananh 3y ago
  it used to be like that (without cloudfront) https://docs.aws.amazon.com/AmazonS3/latest/userguide/website-hosting-custom-domain-walkthrough.html https://docs.aws.amazon.com/AmazonS3/latest/userguide/websit...

ed 3y ago

How might this matter? A obvious one: Given a production bucket, it’s now possible to find development buckets for that same org, which is not expected behavior IMO.

catlifeonmars 3y ago
Unlikely, unless dev buckets are somehow in the same account.
- booi 3y ago
  it's bad practice but it's more common than you think especially with older accounts (pre-organization)
drjasonharrison 3y ago
Only true if they use the same accounts for both production and development. This would be another reason not to use the same accounts.
corytheboyd 3y ago
You only need the bucket name to do that. You should include a randomly generated prefix/suffix in bucket names to prevent against such enumeration attempts. Another good idea (as well as, not instead of) is to expose objects in buckets publicly with a non-default host name, such that the bucket name isn’t leaked at all.
- gusmd 3y ago
  Or, for read scenarios, putting a CloudFront distribution in front of the bucket!
paulddraper 3y ago
How so? You'd have the know the name of the (development) bucket first, right?
- 3y ago

dheera 3y ago

Perhaps this can make s3fs and similar mounting tools easier to use; just plug in the bucket, enter password, and it mounts.

cj 3y ago

> While account IDs, like any identifying information, should be used and shared carefully, they are not considered secret, sensitive, or confidential information. https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-identifiers.html https://docs.aws.amazon.com/accounts/latest/reference/manage...

dimitrios1 3y ago
Seems like at least in the digital world, there is either public or private information, and that's it. We don't really have a good concept of privilege or protected information. 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.
- greiskul 3y ago
  One huge mistake that Google did when they were integrating youtube with Google+, was the idea of sharing people's youtube comments with their G+ friends. Youtube comments have always been public, but there was huge customer pushback, forcing them to revert them for this idea, since there is in people's mind a huge difference between public and publicized comments.
  - styfle 3y ago
    Also G+ made your email address public to your friends/circles/etc and I don’t think there was a way to disable it.
  - mellutussa 3y ago
    Yep, that and other things like reviews wm you did went straight to your Google+ page. I really wanted G+ to work, but they were just too stupid to understand that this was a deal-breaker.
panarky 3y ago
What does this mean? If they're not secret, sensitive, or confidential, then why must they be shared carefully?

hassli 3y ago

[flagged]

bjw4 3y ago

Any tips on how to do the same for EC2 instances? Am aware of one that’s allegedly joined to our domain but can’t find it in any owned accounts

vegardx 3y ago
If you're lucky and it has a instance profile attached with appropriate role/policy attached you can use get caller identity to see what account it's running in: https://docs.aws.amazon.com/cli/latest/reference/sts/get-caller-identity.html https://docs.aws.amazon.com/cli/latest/reference/sts/get-cal...

bagels 3y ago

What value is there in allowing wildcard account id matching? I can't think of a legitimate use case.

denysvitali 3y ago
This is probably the rule engine of the policies being used for something less useful
syncsynchalt 3y ago
It's likely only allowed because someone didn't think to explicitly disallow it.

thenickdude 3y ago

Related: AWS key IDs (not the secret key part) include your account ID within them, bitshifted by one position: https://medium.com/@TalBeerySec/a-short-note-on-aws-key-id-f88cc4317489 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.

firebaze 3y ago
Quite a few people in this thread assume that the AWS key id is part of a "security by obscurity" "protection in depth". 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 https://www.youtube.com/watch?v=KEkrWRHCDQU)
- ralusek 3y ago
  To me security by obscurity is limited to things like this: 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.
  - disruptiveink 3y ago
    That's an unfortunately common misconception. Your example is not security though obscurity any more than password authentication is, though. 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.

orf 3y ago

Interesting post. I wonder if you can further combine it by using a PrincipalTag in some way? You can assume a number of roles with different tag values, and these can be interpolated into the condition. This lets you do things without a huge statement?

NovemberWhiskey 3y ago

There seems to be a large discussion of whether account IDs are "secret" or "private" or "confidential" or whatever. 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.

denysvitali 3y ago
Accounts on AWS are pretty cheap (free?) - why would you host everything on the same account?
- gaudystead 3y ago
  You may be underestimating human laziness...
- whs 3y ago
  In my company we use reseller billing as AWS do not have a local billing entity. The reseller owns the organization's root account and we do not have access to it. Every subaccount creation require a support email to the reseller.
- Garlef 3y ago
  free as in: AWS does not charge you 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)
  - NovemberWhiskey 3y ago
    My favorite factoid about AWS accounts is that there's a global, hard rate limit for their deletion. It's actually a pain point for us.

huslage 3y ago

I have always likened AWS Account IDs to be similar to public keys. But even less useful. There is nothing useful that you can do with them without other information.

master_crab 3y ago

AWS account ID == Your IP address. It may be sensitive, but someone needs to know it to get s*$t done. 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

stingraycharles 3y ago
AWS PrivateLink has another property that generally makes it undesirable for these types of integrations: communication is bidirectional, and IP subnets should not overlap. 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.
- EE84M3i 3y ago
  I thought PrivateLink was branding for vpc interface endpoints? There's no ip subject restriction for that because it's basically a proxy. Are you thinking of vpc peering? VPC endpoints seem preferable in this situation.
  - stingraycharles 3y ago
    Oh I apologize, you’re completely correct and I am confusing PrivateLink with VPC peering. Thank you for correcting me.
executesorder66 3y ago
> get s*$t done What were you hoping to achieve with this utterly pointless self-censorship?

sam0x17 3y ago

Any scenario where the actual hack results in the time-honored trope/misunderstanding of "hacking" the password one character at a time is awesome

lijok 3y ago

ITT lots of debate on whether AWS Account IDs are sensitive or not. To chime in my 2c; we've had this debate in multiple orgs with different security teams and the outcome has always been the same; they're not and it's counterproductive to your security posture to treat it as privileged information. Humans have a nasty habit of placing trust in people who have access to privileged information. "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.

deleted 3y ago
[deleted]

datadeft 3y ago

Sometimes I am having trouble finding my own AWS account id...

myroon5 3y ago

Other public AWS resources with global namespaces also reveal AWS account IDs: https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/ https://blog.plerion.com/conditional-love-for-aws-metadata-e...

d0gsg0w00f 3y ago

I think the more worrying attack vector is when you now use the account number to try and Allowlist a principal from that account in some policy in your account. If the principal doesn't exist in the other account you'll get a role/user not found error! Presumably you could use this to find real principals in the other account.

jimmalongading 3y ago

I apologize in advance for what Im going to say here. 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?

rosa4151 3y ago

[flagged]

daveevad 3y ago

> the ability to use StringLike conditions so much depends upon a regular expression