Bruteforcing the phone number of any Google user
brutecat.com
brutecat.com
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.
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.
I tried a year or so ago and had to round trip to my Android over mobile data so it was too high latency for what I needed. If there's a way to connect to a phone on the same LAN/WiFi but scrape using its mobile network I would be very interested.
Then you can have basically unlimited IPs.
Android messes with your traffic far more than a bare modem (there's unavoidable NAT for one), and it has tighter thermal limits, so higher latency is expected.
There's several options for storage, as well: - connect an external drive via USB (The /Android/media directory on both the internal and external SD card is generally accessible from both termux and other apps on the phone) - if you're rooted you can mount a network storage in termux (or system-wide, but then you have to figure out sandboxing) - if you're not rooted, mount in reverse (mount your phone storage over the network)
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.
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.
Your isp should really be giving you a /56 or /48.
Ratio of abuse traffic per IPv6 from a /64 might also make a good threshold.
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.
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.
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.)
This RFC has things that may not work properly not to use /64. https://datatracker.ietf.org/doc/html/rfc7421#section-4.2
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.
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 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.
> 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.
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.
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.
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.
I always wonder who's the one maintaining the "poke" feature in Facebook.
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.
Your immediate dismissal of an actual task I've been assigned irks to the point of being given a snarky response.
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!
If something is obvious, sure, but how is the new intern even going to know when to ask?
How are we seriously this obtuse? Is it deliberate?
Clearly $350 billion revenue in 2024 is not enough...
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.
can you elaborate on this?
Perhaps Google should 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.
Indeed, I recently ran into a Google page that served up the old (~2013) Catull logo.
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.
And people say Google abandons products.
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.
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.
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"?
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.
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...
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.
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.
Corporate greed sucks for all
Should probably be https://qbix.com/blog/2021/01/25/no-way-to-prevent-this-says...
Shouldn't the rate limit be set here, related to the display name "John Smith"? You get 5 "John Smiths" for free in the first minute, then 5 more in the first hour, then 5 more in each day going forward. With the same million phone number combos you'd need roughly half a lifetime (10,000 days) to get the hit on average.
It seems like there are probably people out there with JS disabled for whatever reason who still might need to recover their password?
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...
I don't go out of my way to publish my cell or address but a lot of people have them.
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.
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.
yeah the discrepancy is that its harder now. phonebooks were essentially free and had people's addresses in them
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.
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.
If SIM Swap doesn’t work, you can always attack SS7. There’s also nothing you can do about that.
So stop using your phone number as an authentication factor. It’s trivial to pwn for any actor determined-enough.
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.
Even if the issue wasn't abused, it looks like data already leaked.
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.
Your name should also be somewhat private. No need to use your real name on the internet. There was a furor over Google requiring real names on Google+; this kind of outcry needs to continue.
Are we really to the point people don't understand the concept of a phone book anymore?
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 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.
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.
$5000 (after complaining lol) really is a joke.
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.
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.
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.