A Researcher Figured Out How to Reveal Any Phone Number Linked to a Google Account
Technology
54
Beiträge
40
Kommentatoren
0
Aufrufe
-
Casually rotating 18,446,744,073,709,551,616 IP addresses to bypass rate limits.
I am not in IT security, but find it fascinating what clever tricks people use to break (into) stuff.
In a better world, we might use this energy for advancing humanity instead of looking how we can hurt each other. (Not saying the author is doing that, just lamenting that ITS is necessary due to hostile actors in this world. )
This doesn't really work in real life since IPv6 rate limiting is done per /64 block, not per individual IP address. This is because /64 is the smallest subnet allowed by the IPv6 spec, especially if you want to use features like SLAAC and privacy extensions (which most home users would be using)
SLAAC means that devices on the network can assign their own IPv6. It's like DHCP but is stateless and doesn't need a server.
Privacy extensions means that the IPv6 address is periodically changed to avoid any individual device from being tracked. All devices on an IPv6 network usually have their own public IP, which fixes some things (NAT and port forwarding aren't needed any more) but has potential privacy issues if one device has the same IP for a long time.
-
Ipv6 catching strays
Usually is. Still common among network admins to hear dumb shit like IPv6 being less secure because no NAT.
️ -
Phone books from outside my region were available at the library; that place where they store a consolidated collection of books for just anyone to sign out and use.
I don't remember that, however it doesn't surprise me at least for a radius around your area. I'd be surprised if they had all of them from all the states
-
F. This will be moved to an OSINT tool within a week, and scraped into a darkweb database by next Friday.
I think you missed the part at the very end of the page that showed the timeline of them reporting the vulnerability back in April, being rewarded for finding the vulnerability, the vulnerability being patched in May, and being allowed to publicize the vulnerability as of today.
-
F. This will be moved to an OSINT tool within a week, and scraped into a darkweb database by next Friday.
Well at the bottom of the article he shows the bug report timeline has been complete, so it's likely already fixed.
-
Usually is. Still common among network admins to hear dumb shit like IPv6 being less secure because no NAT.
️If NAT is your “firewall”, you have bigger problems!
-
Bruteforcing the phone number of any Google user
From rate limits to no limits: How IPv6's massive address space and a crafty botguard bypass left every Google user's phone number vulnerable
brutecat.com (brutecat.com)
$5,000
This is like 1/10th of what a good blackhat hacker would have gotten out of it.
-
Bruteforcing the phone number of any Google user
From rate limits to no limits: How IPv6's massive address space and a crafty botguard bypass left every Google user's phone number vulnerable
brutecat.com (brutecat.com)
I keep telling people, it's a matter of when, not if.
Do not trust corporations.
-
Google, Apple, and rest of big tech are pregnable despite their access to vast amounts of capital, and labor resources.
I used to be a big supporter of using their "social sign on" (or more generally speaking, single sign on) as a federated authentication mechanism. They have access to brilliant engineers thus naively thought - "well these companies are well funded, and security focused. What could go wrong having them handle a critical entry point for services?”
Well as this position continues to age poorly, many fucking aspects can go wrong!
- These authentication services owned by big tech are much more attractive to attack. Finding that one vulnerability in their massive attack vector is difficult but not impossible.
- If you use big tech to authenticate to services, you are now subject to the vague terms of service of big tech. Oh you forgot to pay Google store bill because card on file expired? Now your Google account is locked out and now lose access to hundreds of services that have no direct relation to Google/Apple
- Using third party auth mechanisms like Google often complicate the relationship between service provider and consumer. Support costs increase because when a 80 yr old forgot password or 2FA method to Google account. They will go to the service provider instead of Google to fix it. Then you spend inordinate amounts of time/resources trying to fix issue. These costs eventually passed on to customer in some form or another
Which is why my new position is for federated authentication protocols. Similar to how Lemmy and the fediverse work but for authentication and authorization.
Having your own IdP won’t fix the 3rd issue, but at least it will alleviate 1st and 2nd concerns
They have access to brilliant engineers
Not really.
-
Bruteforcing the phone number of any Google user
From rate limits to no limits: How IPv6's massive address space and a crafty botguard bypass left every Google user's phone number vulnerable
brutecat.com (brutecat.com)
Damn that's interesting. I like how they walked through step by step how they got the exploit to work. This is what actual real hacking is like, but much less glamorous than what you see in the movies.
-
I don't remember that, however it doesn't surprise me at least for a radius around your area. I'd be surprised if they had all of them from all the states
You could just have them borrow one from whatever other library had it. Hell, you could just call the phone company and order the one you want yourself. Fuck, you could just call 411 and have them look it up for you right then.
-
Phone books from outside my region were available at the library; that place where they store a consolidated collection of books for just anyone to sign out and use.
I once used one to look up my friend from summer camp. He lived in New York City and I didn't live anywhere close
Library had a bunch of NYC phonebooks
-
Without researchers like that, someone else would figure it out and use it maliciously without telling anyone. This researcher got Google to close the loophole that the exploit requires before publicly disclosing it.
That's the fallacy I'm alluding to when I mention stuxnet. We have really well funded, well intentioned, intelligent people creating tools, techniques and overall knowledge in a field. Generally speaking, some of these findings are more makings then findings.
-
I think the method of researching and then informing the affected companies confidentially is a good way to do it but companies often ignore these findings. It has to be publicized somehow to pressure them into fixing the problem.
Indeed, then it becomes a market and it incentivises more research on that area. Which I don't think is helpful for anyone. It's like your job description being "professional pessimist". We could be putting that amount of effort into building more secure software to begin with.
-
I think it's important for users to know how vulnerable they really are and for providers to have a fire lit under their ass to patch holes. I think it's standard practice to alert providers to these finds early, but I'm guessing a lot of them already knew about the vulnerabilities and often don't give a shit.
Compared to airing this dirty laundry I think the alternatives are potentially worse.
Hmm I don't know... Users usually don't pay much attention to security. And the disclosure method actively hides it from the user until it no longer matters.
For providers, I understand, but can't fully agree. I think it's a misguided culture that creates busy-work at all levels.
-
$5,000
This is like 1/10th of what a good blackhat hacker would have gotten out of it.
I always wonder what's stopping security researchers from selling these exploits to Blackhat marketplaces, getting the money, waiting a bit, then telling the original company, so they end up patching it.
Probably break some contractual agreements, but if you're doing this as a career surely you'd know how to hide your identity properly.
-
Damn that's interesting. I like how they walked through step by step how they got the exploit to work. This is what actual real hacking is like, but much less glamorous than what you see in the movies.
When do we get to the part where a bunch of UNIX logs get projected, backward, on someone's face
-
I always wonder what's stopping security researchers from selling these exploits to Blackhat marketplaces, getting the money, waiting a bit, then telling the original company, so they end up patching it.
Probably break some contractual agreements, but if you're doing this as a career surely you'd know how to hide your identity properly.
Chances that such an old exploit get found at the same time by a whitehat and a blackhat are very small. It would be hard not to be suspicious.
-
Chances that such an old exploit get found at the same time by a whitehat and a blackhat are very small. It would be hard not to be suspicious.
Yes, but I was saying the Blackhat marketplaces wouldn't really have much recourse if the person selling the exploit knew how to cover their tracks. i.e. they wouldn't have anyone to sue or go after.
-
Google, Apple, and rest of big tech are pregnable despite their access to vast amounts of capital, and labor resources.
I used to be a big supporter of using their "social sign on" (or more generally speaking, single sign on) as a federated authentication mechanism. They have access to brilliant engineers thus naively thought - "well these companies are well funded, and security focused. What could go wrong having them handle a critical entry point for services?”
Well as this position continues to age poorly, many fucking aspects can go wrong!
- These authentication services owned by big tech are much more attractive to attack. Finding that one vulnerability in their massive attack vector is difficult but not impossible.
- If you use big tech to authenticate to services, you are now subject to the vague terms of service of big tech. Oh you forgot to pay Google store bill because card on file expired? Now your Google account is locked out and now lose access to hundreds of services that have no direct relation to Google/Apple
- Using third party auth mechanisms like Google often complicate the relationship between service provider and consumer. Support costs increase because when a 80 yr old forgot password or 2FA method to Google account. They will go to the service provider instead of Google to fix it. Then you spend inordinate amounts of time/resources trying to fix issue. These costs eventually passed on to customer in some form or another
Which is why my new position is for federated authentication protocols. Similar to how Lemmy and the fediverse work but for authentication and authorization.
Having your own IdP won’t fix the 3rd issue, but at least it will alleviate 1st and 2nd concerns
The sad thing is, we had federated auth before social sign on. OpenID was a thing before oauth
