Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bruteforcing the phone number of any Google user

brutecat.com

Post reply on HN
Print view View original

81–90 of 204 posts

Re: Bruteforcing the phone number of any Google user

#81

Post by qingcharles »

rvnx wrote: post #15
dkdcio wrote: post #10

Earlier quoted context omitted.

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.

Re: Bruteforcing the phone number of any Google user

#82

Post by kevindamm »

VladVladikoff wrote: post #80

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.

Re: Bruteforcing the phone number of any Google user

#83

Post by hayleox »

okanat wrote: post #53
paxys wrote: post #21

Earlier quoted context omitted.

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 somet…

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.

Re: Bruteforcing the phone number of any Google user

#84

Post by VladVladikoff »

atum47 wrote: post #49

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.

Re: Bruteforcing the phone number of any Google user

#85

Post by jeffbee »

0xbadcafebee wrote: post #70
belter wrote: post #5

Earlier quoted context omitted.

> It must be a daunting chore to maintain all the legacy pages. Clearly $350 billion revenue in 2024 is not enough...

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 pag…

There is something wrong with your computer.

Re: Bruteforcing the phone number of any Google user

#86

Post by valicord »

dylan604 wrote: post #59
bornfreddy wrote: post #46

Earlier quoted context omitted.

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.

How does a new hire know "what it is supposed to be"?

Re: Bruteforcing the phone number of any Google user

#87

Post by hayleox »

xnx wrote: post #68
jeffbee wrote: post #4

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 fe…

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

Re: Bruteforcing the phone number of any Google user

#88

Post by stackskipton »

zerof1l wrote: post #62

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.

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.

Re: Bruteforcing the phone number of any Google user

#89

Post by AtomicByte »

zerof1l wrote: post #62

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.

Yes that does happen to be what is commonly done

Re: Bruteforcing the phone number of any Google user

#90

Post by dheera »

atum47 wrote: post #49

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.

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.
Post reply on HN