Bruteforcing the phone number of any Google user
brutecat.com577 points by brutecat a day ago
577 points by brutecat a day ago
This article highlights something interesting... it is quite common to get at least one /64 IPv6 block from a hosting provider or ISP. Yet most of the rate-limiting and IP blocking is done for a single IP. Sounds like when dealing with IPv6, an entire block of /64 should be rate-limited or blocked.
Even companies which not only should know better, but are actually paid to handle things like this get it hilariously wrong.
The company I work for is a client of a big-ass CDN you've heard of (not the one whose ceo hangs around these parts). Yet, they somehow think it's fine to notify me of "new connections from an unusual IP" when I connect from the same /64 block of ipv6.
It's easier to reuse existing code and simply bump the number of digits required to store the IP address.
I'd be rather surprised if IPv6 hasn't done some damage to the idea of IP blocking on the whole. It's possible, even as a residential Internet user, to request a /56 or /48 automatically with DHCPv6 Prefix Delegation. I have a /56 with Comcast. That's potentially up to 65536 /64 blocks, just from a residential user, so if you're going to attempt IP filtering for IPv6, it's got to be a lot smarter than swapping out your single-IP blocking for /64 blocking.
It is already pretty common to start with IP blocking but upgrade to blocks when the bad behavior continues.
Assuming a /64 as a starting point is an easy win and bumping it up with repeat offenders seems pretty easy in the grand scheme of things.
Doesnt CGNAT make these methods obselete though? All my webscraping is proxied through my phone and I rarely get IP blocked and im very aggressive even on CF protected sites.
It actually makes things a easier for both blocking and allocating (e.g. VPS hoster) side.
Once the "oh no, we can't afford that many unique allocations" excuse is away, algorithms that enforce quotas for every prefix size at the same time (with no excuses for CGNAT weirdness) stop being too ruthless.
You can distribute your addresses as needed, and I can track successful and failing attempts - at whatever distribution scheme you use. E.g. group your "unverified" or "trial" accounts at a larger prefix size, so they get each other blocked - but not your paying customers.
How are you getting a /56 from Comcast? I can only request up to a /60 from them, any larger and I get a /60 rather than whatever I requested.
Good question, I checked just now and I am indeed getting only a /60. At some point in the past they gave me a /56 but no longer. I didn't notice the change because I have fewer than 16 networks, and networkd handled delegating /64s to them automatically.
Shame, I was hoping I could get on the /56 train too lol. Thanks for checking!
I'm on a relatively large Indian ISP, and my home network gets an IPv6 network assigned, which is directly routable. Didn't think about it until tailscale told me it was connecting over a direct IPv6 connection and I wondered how that was possible. Sounds like 90s network rampage may be back here.
Blocking inbound connections using connection tracking is orthogonal to NAT. It's just that NAT implies the former by default due to its nature.
Direct connections are a good thing and how the Internet is supposed to work. NAT is the only reason IPv4 has lasted this long.
Rate limiting on /64 for IPv6 is well known and I know Google does it for other services. Sounds like this was not properly updated when they put IPv6 into play.
Effectively a /64 is the new /32.
Your isp should really be giving you a /56 or /48.
Even that isn’t sufficient, as it’s very easy to get ahold of /48 blocks. To do a good job of this, you need to actually break things down by ASN and look at their policies for handing out IP addresses to figure out what granularity to use.
I had assumed that most people would block by /64. Probably safest to count distinct abusive/noisy IPv6s per /64 and block/throttle when it hits a threshold.
Ratio of abuse traffic per IPv6 from a /64 might also make a good threshold.
[BuyVM](https://my.frantech.ca/cart.php?gid=37), a popular host for shady operators, gives a /48 even with their cheapest plans ($2/month, though only $7/month is in stock right now)
A bit more context: BuyVM is a legitimate business, popular with hobbyists, and has features that are hard to get elsewhere (e.g., BGP sessions). They do take a pro-free speech stance but they are a far cry from bulletproof hosting ("shady operators"). An imperfect comparison at a massively bigger scale would be Cloudflare's prominence in certain contexts.
they are pretty well-known as a "DMCA ignored" hosting site. Search "dmca ignored buyvm lowendtalk" and you'll find lots of forum threads of people recommending buyvm for hosting pirated content. They were also once mentioned by the RIAA for ignoring copyright law https://www.musicbusinessworldwide.com/files/2025/01/USTR-20... There's also at least one mention I can find of them hosting a CSAM website.
What if the user only get one address, how to separate the two? Seems like a need to share if a larger block (providor) is handing out based on blocks or single addresses…
Say what? IPv6 was designed that first 64 bits are network, last 64 bit are host.
Since /64 is smallest network in IPv6 and because of that most providers hand out /64 when you ask for IPv6 public address because A) Most Rate Limiting uses /64 and B) IPv6 has so many IPs, no one cares.
Vultr has at least one /32 I was able to find (2001:19F0::/32) which if you cut that into /64 comes out ~4.2 Billion different networks or same amount of IPv4 address that exist.
ARIN will hand anyone who asks a /48 IPv6 subnet which 65,536 unique networks and getting larger prefix is not hard.
> Since /64 is smallest network in IPv6
A /64 is not the smallest network in IPv6. Nothing stops you having a /112 or a /126 or whatever you like.
It is the only network size on which SLAAC works however, so it's a good choice for lan sizes.
I'm talking practical. I know you can reduce networks further BUT there is plenty of stuff that could break.
GCP for example hands out /96s to each VM, so this isn’t a theoretical or niche usecase.
Yes, but for GCP all the VMs with a /96 in the same /64 will be closely related: in the same project, same VPC network, same cloud region.
So from the point of abuse logic it's appropriate to treat the whole /64 as a single unit. (That was the starting point of the thread, even though I realize that due to thread drift that's probably not what your comment was about.)
What stuff?
Crappy network devices may not handle it properly, SLAAC obviously, I'm sure there are IPv6 tools that expect /64 for host, almost all blacklist setups for IPv6 assume /64.
This RFC has things that may not work properly not to use /64. https://datatracker.ietf.org/doc/html/rfc7421#section-4.2
The RFC only mentions issues with a shorter prefix, not a longer one. There should be no issues whatsoever with longer prefixes.
The problem here is, that also larger networks (eg. student wifi at some university) uses a /64 for maybe even hundreds of students connected at the same time. Hold a lecture, tell the students to go to github to download some tool, and the first 10 will succeed, and the rest will get rate limited.
The same is true now with NAT (where they're all behind a single ip or a very small pool of IPs), but IPv6 should make these things better.
IP rate limiting hasn't been a serious misuse prevention tool for 15-20 years
Can you elaborate? As one tool among many it seems to me to be a perfectly serviceable tool in the toolbox, with a sufficiently high rate limit to account for shared IPs.
I did something similar way back when I was trying to find the phone number for a person, using Facebook.
When recovering a password Facebook would give you most of the digits of the phone number, so I wrote them down in a vcard file and imported it on my phone to just look at the pictures. It worked surprisingly good.
There is also a similar hole with Google profile photos and other Google apps. For example if you see a review by John Smith on Google maps, you add emails on Google Hangouts, guess a bunch of variations like johnsmith@gmail.com, smithjohn@gmail.com etc and see the profile photos to compare the match.
This is why I don't use a real phone number with any of these services. They don't need my phone number to operate either.
g has been demanding a valid phone for years, as have most other major providers. if you lose the number you sign up with, you can potentially get locked out of the account. whats your mo?
Their own policies place a limit on how "demanding" they can be.
Initializing a new (or power-washed) android/ChromeOS device _requires_ a Google account, so if you don't have one (or claim not to) they device initialization process will generate a new Google account for you. Even if there's no phone number or SIM card in the device.
I've had a number of Android/ChromeOS devices over the years, and I've had each one generate a new Google account. None of these accounts have phone numbers associated with them.
I generally don't use these accounts for much more than downloading free apps from the Google Play store -- maybe more extensive use would trigger a "You must add a phone number to this account to proceed"?
Initializing a new (or power-washed) android/ChromeOS device _requires_ a Google account
It's been a while since I've had to look at Android in any detail, but I remember that not being necessary, and a quick search online suggests that to still be the case today.
Are you saying it's as simple as clicking the "proceed without a google account" button and I've just failed to notice the option each of those times?
If there's a non-obvious workaround, why not post a link to it?
"Just Google it" isn't as easy as it used to be...
They can just take your number anyway if you ever insert a SIM, since they control "your" phone.
Interestingly, your phone number is actually not stored on the SIM card. It instead holds a globally unique ICCID number which your operator links to your account (phone number) on their systems.
This actually makes it possible to transfer your phone number between SIM cards or even operators, and means your cell phone is blissfully unaware of its own phone number.
While interesting, it's irrelevant. Google can take your number the moment you enter your SIM into the phone. They even have it as a feature.
Not sure how it looks in USA, but in EU you can get a prepaid SIM card for $2 and use it forever for cases like this. You'll probably have to top it up with another $1-2 if used sparingly, but that's the price of such separation.
Where in the EU? The best I've found in Ireland requires adding €5 of prepaid credit at least every six months to prevent the number from being deactivated. As of yet, I have not managed to automate it.
Can't definitely find it, but in Orange Poland prepaid offer it costs ~$7 (29 PLN) to prolong the account for 365 days (regardless whether it is topped up or not), but it has to be activated manually, it is not the "normal" way to use a prepaid plan tbh.
If you didn't sign up with a number in the first place, they like to request that you add one, but you can just skip it.
I lost my hotmail account I had for years due to losing my phone number. My boss at one point said he would pay for me to have a cell phone, not for work purposes or to contact me just as a perk of working there hey here is a personal cell phone on me so you don't have to pay for one. All good and he let me get the first iphone that came to Canada the 3g and it was awesome. Left that job years later and didn't think far ahead enough that I needed that phone number to get into my account should I have an issue. Well I did and tried all the recovery methods with no luck. Sad thing is I still get occasional emails forwarded from that account, haven't seen one in a long while but was still getting them for years. Hurts a lot to have lost it. The screw up that compounded my loss was I guess I was paranoid about giving my personal information online back in the day. So my name I used was John Fokendoe. And some made up birthday. So I could not remember all the info I entered and years and years lost. For my google I downloaded the backup codes in Case I lose access to my phone. They sit in a folder safe and there if I ever need to recover the account.
I currently have three actively used gmail accounts that all date from the initial "word of mouth" referral from another user days. I once had many gmail accounts that I spun up for a project mapping spam to disposable accounts, etc.
Not one of these emails ever had a phone number attached. The current gmail accounts I use also have no phone number associated, whenever I'm asked to attach a phone number for recovery or security I decline.
As none of these were ever signed up from a phone number there's no phone number to lose, in the event of a security challenge I verify from an associated gmail account.
There's little to no trace of my birth certificate name, phone number, actual address of my house, etc. on the internet .. the few people who do push through on that kind of back tracking invariably end up with a relative or a different but similar West Australian.
I’m mostly impressed that he can throw 40k requests per second at a server for a prolonged period and not somehow spike the resources enough to set off some alarms.
it is possible that it did throw an alarm but the behavior ceased soon enough afterwards that it didn't escalate to alert-level paging, or that -- even if it did -- those resources were back to normal within a few minutes that it took to open laptop, password password OTP, link-following and graph-referencing annnd oh it's already coming back down before the status update is drafted.
And 40kqps isn't really much at the scale of Focus (or most of Google's APIs) so I could easily see it going under the radar, especially each using different IP addrs and with IPv6 across /64.
The gap worth noticing here isn't monitoring, though, it's the zero rate limiting on js_disabled flow using a token borrowed from an earlier js enabled flow.
For comparison, Google apparently processes about 160k search queries per second.
These bug bounties pay peanuts. Sad.
It seems that these services forget what happens when white hats stop reporting this because of that :/
Corporate greed sucks for all
I’ve used plenty of forgot password forms before and entered my phone number to recover accounts, but I never really thought about how much information they could actually leak. It reminds me of those recovery flows from back in the day, where even just the last couple of digits of a phone number could end up being a real vulnerability for attackers. It’s surprising how something that seems harmless, like a simple recovery page, can actually hide some pretty serious security risks.
> It’s surprising how something that seems harmless, like a simple recovery page, can actually hide some pretty serious security risks.
This is something you should include in any personal security checkup. Attempt account recovery using every allowed mechanism. The rules for recovery change over time in a way that classical login doesn't.
It must be a daunting chore to maintain all the legacy pages. The amount of now-years-old stuff that long-standing sites have to maintain, or choose to maintain, is shockingly high, and testing the combination of all that stuff is impossible.
If you want an example of how diverse in age these apps are, dig around in the Gmail settings panel. Eventually you will land on a popup that uses the original Gmail look and feel, from 2004.
Bug bounty program appears to be an efficient spend. For a few thousand dollars they mobilize unpaid people looking for extreme edge cases and then surface these issues. It would’ve cost way more to pay an employee to search for this.
The main cost of running a bug bounty program is developer time spent triaging submissions from all the people who just run an automated scanner against your website and submit everything it outputs.
Which is exactly why companies are aggressive about deprecating old products and services. "But why can't they just leave them running and not touch it?" Because every such service eventually becomes a security hole. The only secure code is no code.
While your argument seems to make sense on the surface, it fails in deeper inspection.
What security implications did Google Reader have? I do understand keeping older APIs and endpoints for authentication and authorization are indeed dangerous. However, if your architecture causes the mere clients of those authorization infra to be exploited, I think the problem isn't keeping the products running. You designed something inherently insecure.
Google Reader used Google accounts for authentication, so an exploit in Reader could potentially be compromising to your entire Google account. This very article gives an example of that; Looker Studio was used to reveal the name on any account, even though most accounts have likely never used Looker Studio.
Google could mitigate this by not having universally shared accounts across all services, but they're not going to do that because most users would find that inconvenient.
Since you're the person that didn't answered with "hah you say: don't code bugs", I'll take some time to answer you.
> Google Reader used Google accounts for authentication, so an exploit in Reader could potentially be compromising to your entire Google account. This very article gives an example of that; Looker Studio was used to reveal the name on any account, even though most accounts have likely never used Looker Studio.
Guess what else uses Google Accounts? Everything that Google needs authentication for. When designing software, so much effort is put into its design, possible user stories and architecture. We put so much effort into unit tests, integration tests, regression tests whatnot.Security is no different. When designing services, considering the data flow is critical for security. An engineering organization should take into account of data that needs authentication. Those should be separate isolated services.
They can crate security islands for critical parts. Why Looker needs to get the full name from an e-mail that this person hasn't initiated a two-way contact? Or even, why it can in the first place? There is a service that does this resolution (Contacts?). Google failed to consider that limiting this kind of queries when creating this service. It has nothing to do with the functionality of Looker Studio. Now anything touches this service has problems. The old and the new products. You'll not be able to resolve these problems by deprecating Looker Studio nor deprecating Reader solved these issues.
> Google could mitigate this by not having universally shared accounts across all services, but they're not going to do that because most users would find that inconvenient.
It is not the sharing of the authentication provider but the authorization of the kinds of queries is the problem here. It is not the problem with the age of the service Looker provides either. Yes you may be able to extract some data if the pod running Looker Studio got compromised, maybe even PII data. The dependencies can get old or can have critical bugs. However, they shouldn't be able to be exploited to extract large swaths of data due to layering and consideration of security architecture. That's why creating those security narrow-waist points are so important. They need to be given the same care of the correctness of the software and other UX goals.
Even a smaller company needs to consider these architectural details when designing integrated services. With GDPR, you should be able to delete every piece of PII. It gently forces you to do the right thing already. It is totally unacceptable that bigger companies like Google skipping this.
> You designed something inherently insecure.
That describes most/all software older than a decade with no updates applied. How many libraries was Google Reader using that now have known vulns? I'm guessing it's more than zero.
This is the same logic as "just don't write bugs", if it was that easy everybody would already be doing it.
Google Reader was the last major user of the old social sharing stack at Google designed for Buzz, a product mostly remembered to these days for United States v. Google and the 2011 FTC consent decree. When people redesigned Google's social stack for G+ (e.g. all the infrastructure like Zanzibar underlying Circles, which to this day is close to state of the art!) the choice was between migrating Reader to the new tech - which nobody could justify the cost of - or keeping the old tech around for Reader when that tech was known to have had serious privacy issues leading to a major lawsuit.
If “what security implications does xyz have” was easy to answer then there would never be another hack or data breach. The simple answer is that we don’t know. And it is very expensive to find out.
I'm indicating that "it isn't easy to answer" is the root of problem there.
It means that the engineering teams were incompetent in designing a system with a "narrow waist" security infrastructure. Then the solution isn't deprecating xyz but fixing the security infrastructure. Otherwise the same issues will surface again and again in the newer products.
There still is a standard password recovery flow with mail/capability URL that is reasonably safe and hasn't changed too much in a decade.
It is the bullshit some security advisories brought us that introduced new dangers. By sharing telephone numbers for example...
These threats are also worse than losing an account in many cases, because now the data can easily be correlated, which has proliferated through a lot of 2FA bullshit.
> Eventually you will land on a popup that uses the original Gmail look and feel, from 2004.
Indeed, I recently ran into a Google page that served up the old (~2013) Catull logo.
I was recently editing the Wikipedia page for Google Bookmarks (2005-2021). I wanted to add a logo to the page, but I was having a lot of trouble finding a high-quality copy of the logo anywhere. Eventually I figured out that Google's old URL scheme for product logos was very guessable, and they had never taken it down: https://www.google.com/intl/en-US/images/logos/bookmarks_log...
They'll probably never stop serving those old URLs because who KNOWS where they might still be in use. One of surely a million examples of weird little legacy things Google is stuck with.
I tried to guess what it might be ... I went to check moon.google.com, one of the older apps/jokes that I can recall still running. It seems that they got someone to update moon.google.com with a more recent look and feel, and dozens of moons instead of just the one.
And people say Google abandons products.
There are major things at some large enterprises that are given the same level of support. Friend works on an internal link shortener app that is heavily used at their mega corporation and it gets maybe one ticket every other sprint just for upgrading node versions etc even though its monitoring is down.
> It must be a daunting chore to maintain all the legacy pages.
Clearly $350 billion revenue in 2024 is not enough...
Something that can be hard to appreciate if you haven't managed this sort of project is that it can be surprisingly hard to throw money at the problem.
If you try to hire at your regular "bar" for skill for boring work like this - people will often quit. This is one of the reasons many company's integrations are lacking despite it being a strategic interest - integration work is miserable and doesn't help your career.
Hiring below the skillbar at the same pay, is dangerous and often doesn't actually work out - if it was that easy someone more skilled probably would have fixed this a while ago.
So you try to pay more for the miserable work - but hold on, now you have to pay out of band salaries, and legal tells you that opens you to massive liabilities.
Ok - maybe you can just level them differently? No, HR will tell you that will mess with all your internal level processes - which are key to running the company. They're going to add a lot of additional overhead tracking these "fake" leveling bands and dealing with the consequences.
None of this means the problem is literally unsolvable, but it now requires a huge amount of time and effort from people near the top of the company who everyone would much rather spend their time on making the company better.
All of this to say - sure you could solve this problem, but it's actually much more complex than adding some line items to a budget.
Source: have watched many big companies try and fail for years to staff unsexy work like this.
You can give people time to go fix things that bug them. Two systems that you use don't work together and it bothers you? Have a day a week to fix it.
> pay out of band salaries, and legal tells you that opens you to massive liabilities
can you elaborate on this?
In my country, there is already a (little known and not really enforced) law, that says, that for similar work there has to be a similar pay (simplifying massively). There is possibly a bunch of workarounds for this (as usual), but a good HR will not like the idea of hiring another SWE, with the same title as other SWEs, but with 2x pay.
In addition to having the money, Google also needs the incentive to spend that money on such projects. If the perceived return on capital is low (or negative!), the incentive is simply not there.
In addition to having the money, Google also needs the incentive to spend that money on such projects. If the perceived return on capital is low (or negative!), the incentive is simply not there.
Perhaps Google should Google the concepts of "customer service," "standing behind your product," and "brand reputation."
> Google the concepts of "customer service," "standing behind your product," and "brand reputation."
They're probably satisfied with their reputation with their customers, who are advertisers. The corporate IT folks who buy their G Suite products are also their customers, but overall the majority of the users of Google's software are not their customers, and Google cares about them the same way I care about how the gasoline in my car feels.
Google's main search page is the slowest page & UI I have found on the internet today (not accounting for bandwidth limits). Even on modern devices it lags at text entry and even rearranges characters in the text box so you have to wait 10+ seconds for it to finish loading or it will go haywire. The shopping and other pages are actually worse. So it appears you're right, $350B isn't enough money to maintain a web page in 2025.
There is something wrong with your computer.
1) it happens on both an Android smartphone and a Linux computer 2) it only happens with Google 3) it is consistent and reproducible
It must be a daunting chore to maintain all the legacy pages. The amount of now-years-old stuff that long-standing sites have to maintain, or choose to maintain, is shockingly high, and testing the combination of all that stuff is impossible.
One company I worked for used interns and new hires for that. One of the early tasks assigned to the intern pool was to comb the web sites for outdated information, or things that no longer conformed to the current brand book. The list then went somewhere else so the pages could be updated or deleted.
The major benefit of this was giving the new people an overview of what we do, why we do it, and a slice of the history of the products.
On the other hand they had no idea if the information was valid or wildly outdated. But better something than nothing I guess. :-)
This is where modern "learning" falls down. You load a page, read its contents, compare with what it is supposed to be, update if outdated, move on. I know I know, that sounds like, egad, work, but that's called a job.
Your immediate dismissal of an actual task I've been assigned irks to the point of being given a snarky response.
Sorry if it irks you, that was not my intention.
My point was not that this job doesn't deserve attention (it does!), but that it would deserve attention from the senior personnel, not (just) the interns. I've seen too many times how important tasks, which are difficult to achieve for someone who wasn't there, are given to newcomers with little oversight and guidance. Maybe that's not how it is here, in which case - good for you!
How does a new hire know "what it is supposed to be"?
The information is transferred through a method called "communication" by another human.
OP originally pitched the website clean up work providing a way to learn about the company, its products, history, etc.
If something is obvious, sure, but how is the new intern even going to know when to ask?
Being able to do this is a marketable skill. It’s one thing to write it but quite another to correct it
What is the point of assigning something to a new hire, if they can't do it without another person watching the whole thing over their shoulder AND they are unlikely to benefit from this knowledge in the future (since it's a legacy page that is supposed to be deleted)?
I often assign things to new hires because I expect them to approach the question without the biases of long-time team members who have learned to overlook and normalize some bullshit. Either the new person is wrong, and I explain why, and they learned something, or they're right and the existing stuff can't be defended or justified, and I learned something.
I am sure some governments including mine would gladly pay more than $5 000 for this.
Off topic, it was very interesting to peek into libphonenumbers metadata. I find it curious that we have so many ways to write down an already standardized identifier.
> 2025-05-15 - Panel awards $1,337 + swag. Rationale: Exploitation likelihood is low. (lol)
Yeah, no, the exploitation likelihood of this is very high. The number of users who might have their phone numbers revealed might be low, but I guarantee you that private investigators, detectives, criminals, etc. would all use this if they needed it and it was there.
> This time can also be significantly reduced through phone number hints from password reset flows in other services such as PayPal, which provide several more digits (ex. +14•••••1779)
I've never thought about this but it's extra scary. If you have the same phone number and email address with enough services and they all mask in a different order for reset hints...
If it makes you feel better (it probably won't) hundreds/thousands of services have collected your phone number over the years (for 2FA or any other reason), with or without consent, and a large chunk of them have had data breaches. So your name-email-phone number combo is 100% already available in public data dumps.
not so long ago practically everyone's name and phone number was available publicly for free in any phone box
Not to mention that these "phone books" also included everyone's address, and married couples were usually listed together.
Yeah, you could get an unlisted number but you were charged for it and almost no one did because it was also how people you wanted to get in touch with you found you a lot of the time. Not that data breaches aren't bad but a lot of the breached info has been pretty routinely available for a very long time. (And, as you say, cell phone numbers are probably less routinely available than landlines were.)
I don't go out of my way to publish my cell or address but a lot of people have them.
My old man was a doctor and the local phone company at the time (GTE) automatically made our home number unlisted. Presumably this was done for other “critical” professions who might receive many home calls that should be directed at their place of work.
Being unlisted was sometimes devastating to a 1980s kid’s social life… I missed out on multiple birthday parties and other invitations. My sisters probably lost out on some dating opportunities.
people always trot this out, but it was very possible to have your information unlisted so it was not printed in the book. you could also use a different name. an old coworker selected to have his name listed as David King so that when found in the book it would show up as King David.
having an unlisted number wasn't uncommon. for privacy minded people, it was a simple phone call to make it unlisted, and most just did it at time of getting the number.
nonetheless, pre-opting, your information was there, so anyone with a phonebook from before you made that decision would have your information. if an organisation had an interest in invading people's privacy it would not be complex to simply keep a copy of every edition of the phonebook
There were a few stories in the past about people social engineering their way past support by asking one companies support for the last 4 of a card and then using that last 4 for a different company.
Here's the one I'm thinking of (time flies, doesn't it?)
https://www.wired.com/2012/08/apple-amazon-mat-honan-hacking...
> Those security lapses are my fault, and I deeply, deeply regret them.
> But what happened to me exposes vital security flaws in several customer service systems, most notably Apple's and Amazon’s. Apple tech support gave the hackers access to my iCloud account. Amazon tech support gave them the ability to see a piece of information – a partial credit card number – that Apple used to release information. In short, the very four digits that Amazon considers unimportant enough to display in the clear on the web are precisely the same ones that Apple considers secure enough to perform identity verification. The disconnect exposes flaws in data management policies endemic to the entire technology industry, and points to a looming nightmare as we enter the era of cloud computing and connected devices.
There's services that do this automatically for a price, and they've been around for a while, for e-mail, phone numbers, and much more. Any bits (literally, bits) of information given without authorization (or plausible belief it's the intended user on the other side) will be efficiently put together from a variety of sources, as there's no shortage of incentive, and many all over the world prodding services used by billions of people worldwide. And then eventually leaked..
There used to be deep web services that provided a lot of this stuff for free back in the early 2000s or so. I think everything like that is behind at least some level of paywall now but it's not hard to get a fairly complete dossier on someone given a bit of background information and a pretty small expenditure.
When I was at university, I went to a talk from a security researcher who found this was the case with credit cards.
what’s the risk? your email being made public? your phone number?
Get personal info, then call carrier for a SIM swap, access crypto from there. Bonus: no KYC, since it's the other person's identity + you can login from 4G internet, so a trusted IP range.
Where can I get this though?
I haven't been able to get into my main Google account for years because they enabled 2FA without warning and it had a phone number I no longer have. I have the username and password and I get all the emails because I also have the recovery email address. I just need to get the recovery code by SMS.
VERY discouraging to anyone considering being a white hacker. "Likelihood low" and only 5k bounty for this is pathetic.
If you didn't change your phone number in the last two years or so, it is most probably in one of the data leaks that could be downloaded by anyone.
2025: https://qbix.com/blog/2025/06/06/%e2%80%9cno-way-to-prevent-...
2023: https://qbix.com/blog/2023/06/12/no-way-to-prevent-this-says...
2021: https://qbix.com/blog/2023/06/12/no-way-to-prevent-this-says...
Which is funnier?
You used the same link for 2023 and 2021.
Should probably be https://qbix.com/blog/2021/01/25/no-way-to-prevent-this-says...
Btb. Thank you !
This is super creative and cool. Brutecat back at it again heh
Wow, if I needed any more proof Google is a ghost ship then this is it. The $5K bounty is an insult, and the fact that they low-balled it in the first place makes them look like absolute clowns. Good on you for calling out how little of a shit Google gives about actually protecting user data.
Nobody is forced to participate in a bug bounty. If you don't like the rewards, don't do it. There's a limit to the financial viability of these programs.
Who's talking about participation? We can be appalled by their business practices as their customers (actual or potential). These are the same companies that tell us that our privacy and security is their #1 concern, and use that justification to take away our rights "for our own good", but when there's a real threat they address it with with a business-casual equivalent of "fuck off".
Neat find, though it's funny to me that a phone number is something people (including everyone on this thread I bet) have been handing out like candy their entire adult lives - to friends, stores, banks, employers, government agencies, random websites – but still expect it to remain some critical secret that no one should ever find out. A phone number is about as private as your name, and you should consider it as such.
No it isn't. You give it to people you trust mostly you don't expect them to make it available publicly on the Internet.
You really trust that not a single friend of yours has ever clicked the "share contacts" button after downloading Facebook/Instagram/Snapchat/LinkedIn/TikTok...? You trust that your auto dealer or bank has not shared your details with Experian (even though you signed a piece of paper explicitly authorizing that)? You trust that your mobile operator itself isn't sharing your contact data with advertisers (go back and read your carrier agreement)? You trust that your grocery store's membership system has fool-proof IT security? Look up "recent data breaches" on Google and see how many of those companies/hospitals/government agencies you had a relationship with. I can guarantee that despite your best efforts and "trust" your phone number is accessible in a few clicks to anyone who cares to look.
I feel like both sides are right here:
1. Google shouldn't make it trivial to find out my phone number from my email. Given that even Google itself, despite having better technology available, still allows the dumpster that is SMS verification to be used as an auth "factor," they should not be enabling SIM-swapping so directly. Just knowing someone's number makes it trivial to social engineer a SIM-swap, and that can likely unlock every account most people have, and a lot of important accounts (like banks) even for security-minded people, since banks love SMS and hate everything else.
2. I shouldn't act like my phone number is a well-protected secret, or trust that anyone who calls or texts me has gotten it from a trusted source.
This is why I use things like Firefox Relay's email/phone masking for sites and services I don't trust. Would be interested if people know of free alternatives, as the phone mask requires their premium plan, and that can be a no-go for friends and family.
It helps somewhat, but unless you give a unique number to every single friend, business, bank, store, your real number will find its way into data breaches sooner or later. Heck AT&T and T-Mobile have themselves had large scale hacks in the last few years.
I mean it's better than nothing :/ Firefox's mobile mask is only one number, but I haven't seen any better alternatives. I do think I get significantly less spam/scam calls and texts than everyone else I know. But even if you had a unique number per service, I don't think that'll stop them entirely. If you've ever had to get a new number, as you say, it's probably already leaked somewhere whether or not you share it anywhere.
Uhh . . . this is not an earth-shattering take, considering they used to publish entire books with everyone's phone numbers and addresses in them, and you had to pay a fee not to have your number listed.
Are we really to the point people don't understand the concept of a phone book anymore?
Back when phone books were a thing, you couldn't take over a phone number from the other side of the country in the middle of the night and use it to transfer funds to a foreign bank account before you even wake up.
Social security numbers were also never supposed to be secret but as their use changed over the years, so did the way people treat them.
Yes, phone numbers are leaked everywhere. So are social security numbers and home addresses. That doesn't mean your website should be leaking that information.
Do I give it out? Not so much.
Do I expect it to be private? No.
You can for a small fee on some websites get my number.
Heck if you find a phone book from ~2000 where I use to live then you could just look it up in the phone book. Number portability saw to that.
Considering the number of data breaches and past history of phone numbers. To expect any sort of privacy is 'nice to have' but not going to happen. At this point it is basically security thru obscurity to expect it to be private.
Even when they had 'unlisted' numbers you could buy a book from the phone company that had it in there anyway. They even had reverse phone books you could buy. I even remember CD's from ~1998 that had the whole country. You didn't even need to keep the books.
Things have changed in the last decades. With all the unsolicited calls (and especially scams) one would prefer to keep their phone number as private as possible. Doesn't mean that delivery can't get it, just that it shouldn't be on the net.
[flagged]
TIL about another google product I knew nothing about. https://lookerstudio.google.com
Not a homegrown product. Looker was a pretty popular tool for data analysis and visualization and was acquired by Google a while ago.
Lookerstudio was formerly google data studio, which was homegrown at google!
You are blessed to have not been harassed by your GCP rep to attend a demo of this software.
Maybe this specific exploit was already known for a long time to an illegitimate actor, because legit actors saw past rewards and simply gave up too early.
$5000 (after complaining lol) really is a joke.
> 2025-05-15 - Panel awards $1,337 + swag. Rationale: Exploitation likelihood is low. (lol)
Oh, so this is how vendors are going to start playing it to minimize bug bounty costs, huh? Good luck with that- the whole point of the award being a decent chunk of change is to make responsible disclosure more appealing to researchers who might otherwise go the other direction.
I run the BBP at work and we have gotten great reports from it that I'm really glad we didn't find out the "bad" way.
But I kind of think that, instead of any person or group of people choosing between "submit to a BBP" or "sell a 0-day to evil state actors or dark web clients" a BBP is better seen as allowing you to employ stunningly smart and ethical researchers in India (where a $2k bounty goes pretty far) to find all your vulns ASAP so that you have way fewer vulns for the actual bad guys to find. A pretty good "High" vuln is so valuable to people like CIA, FSB, Mossad, etc, not to mention terrorists, money launderers, etc. that it would be hard to compete with those guys financially if we were dealing with strictly economically rational but amoral researchers.
We've paid thousands to a couple of the same researchers, and it's money well spent.
To anyone whose number hasn't already leaked to the B2B SaaS outbound databases: do everything you can to protect your privacy there is still hope for you, the rest of us are already lost
I think it's hard to top Equifax's breach/leak
Indeed, I think if our government weren't absurdly corrupt and incompetent that breach should have triggered two things:
1. Announce a timeline to publish SSNs publicly for all people (forcing function for businesses who might drag their feet)
2. Before #1 comes to pass, issuance of actual credentials to replace SSNs for multiple purposes, credentials that
A. can be validated in an online process
B. you can get multiple credentials that all tie back to a secure identity for credit reporting purposes, and you can be notified when new credentials are generated
C. and (*crucially*) can be invalidated for future use when compromised
#2 is not easy! It would be a massive project. But it's hard to argue that keeping the absurd "secret 9 digit number" joke going isn't even less viable than taking that project on would be.
[dead]
[flagged]
There are problems which are difficult to solve even with immense computing power, which will confuse even powerful LLMs, but which humans can easily solve. That won't require JS, yet be a big obstacle to attackers. IMHO the biggest reason why such solutions aren't more widely deployed is because the incumbent wants to keep its effective browser monopoly.
can be easily exploited by script kiddies using large proxy networks
Such a scheme would need a large amount of LLMs or actual (intelligent) humans too.
Google clearly wanted to make account recovery accessible even without JS
Unfortunately, they made authentication require JS.