Arthur T Knackerbracket has processed the following story:
A researcher has exposed a flaw in Google's authentication systems, opening it to a brute-force attack that left users' mobile numbers up for grabs.
The security hole, discovered by a white-hat hacker operating under the handle Brutecat, left the phone numbers of any Google user who'd logged in open to exposure. The issue was a code slip that allowed brute-force attacks against accounts, potentially enabling SIM-swapping attacks.
"This Google exploit I disclosed just requires the email address of the victim and you can get the phone number tied to the account," Brutecat told The Register.
Brutecat found that Google's account recovery process provided partial phone number hints, which could be exploited. By using cloud services and a Google Looker Studio account, the attacker was able to bypass security systems and launch a brute-force attack.
They explained in the post that "after looking through random Google products, I found out that I could create a Looker Studio document, transfer ownership of it to the victim, and the victim's display name would leak on the home page, with 0 interaction required from the victim."
The researcher also found an old-school username recovery form that worked without Javascript, which allowed them to check if a recovery email or phone number was associated with a specific display name using 2 HTTP requests.
After this, they could go "through forgot password flow for that email and get the masked phone."
Finally, a brute-forcing tool they developed as gpb would run with the display name and masked phone to unmask the phone number, using real-time libphonenumber validation to filter out invalid number queries made to Google's API.
[...] Surprisingly, Google didn't consider this a serious flaw, awarding Brutecat $5,000 under its bug bounty scheme.
"Google was pretty receptive and promptly patched the bug," the researcher said. "By depreciating the whole form compared to my other disclosures, this was done much more quickly. That being said, the bounty is pretty low when taking into account the impact of this bug."
(Score: 3, Funny) by JoeMerchant on Friday June 13, @11:33AM
Originally they paid $1337 bounty but the author negotiated that up to $5000, I wonder if he telephoned someone to discuss it?
🌻🌻🌻 [google.com]
(Score: 3, Insightful) by VLM on Friday June 13, @02:51PM (3 children)
Because there's not much.
I read the entire report because I thought it would be something interesting along the lines of SSSS protocol but to crack google account phone numbers. It was not and I was mildly disappointed but whatever.
The report is kind of "in between" the perspective of the attacker and the defender which is OK but also not what I expected, but it's OK, not bad.
From the point of view of Google which was not discussed in the article (assumed the reader knows?) the problem is they have a workflow of if you know someones (presumably your) full account name, then the password reset protocol involves them asking your recovery phone number to text you an unlock code and if you get the phone number right or wrong google will immediately in a HTTP response let you know. As the article explains, you can in theory test all phone numbers in an international code in varying lengths of time (depending on country phone numbering system) but always under an hour. Googles strategy is to require a captcha be solved. The mistake they made was you're required to solve "a recent captcha" not "this specific captcha", whoops a daisy. So solve one captcha once by hand, give it to your brute forcer system(s) they can test all 1 million phone numbers in the Netherlands at a rate of about 40K numbers/sec using the same solved captcha, which will take about 25 seconds, and one will match...
So to defend against that, google can do two things: tie the captcha request to a specific password reset request so you can't use my captcha solve to test a million of your combo of phone# and accountname, and/or stop telling people if they had a match or not. If you toss up a message such as "if you provided the correct phone number, you will get a text to reset your password; if not, try again later." and that will not leak success or failure destroying the entire "exploit".
The impact is vaguely around zero. Its 2025, we can assume every government, corporation, criminal, and spammer has a database with my email addrs and phone number linked. Its hard to imagine how in 2025 they would not. It would be like trying to report a security leak that someone can "crack" SN to determining that VLM's account number is 445 (I was aiming to get 443 back in the day as a protocol humor joke, LOL). Any process or belief that assumes privacy of that kind of public data in 2025 in inherently flawed, so a "yellow pages book" exists for Google accounts is not really a risk given that everyone you should worry about already has one delivered to them via a mix of purchasing from Google and various nefarious activities.
My guess, to be blunt, is they built this "hole" into the system so the bad guys can run this at their leisure on purpose. "We're not cooperating with law enforcement to release the phone number of any account, we're just... writing shitty security code which is totally not cooperating". I'd also guess that whatever IDS/monitoring system google has, if they see 1E6 reset requests in the logs, they just wildcard ignore everything if the reverse DNS is *.nsa.gov or *.fbi.gov or *.ice.gov or whatever.
I wouldn't say its a complete nothing-burger, but its definitely the lite-est of lite beers.
(Score: 3, Insightful) by JoeMerchant on Friday June 13, @09:10PM
As the headline says: it's a brute force attack.
The point is: by using clever this and thats (like rotating IP6 addresses) he was able to execute the brute force attack successfully, reliably, repeatedly - that is impressive, because hack throttling is supposed to make brute force attacks take years or decades to succeed even once.
🌻🌻🌻 [google.com]
(Score: 3, Insightful) by JoeMerchant on Saturday June 14, @01:26AM
Put another way: what is the value of every phone number of every Google user on the planet?
Even if the vuln was a backdoor password of "12345678" that's still a vuln and reporting it should be rewarded somewhat in proportion to the value of the asset now better protected.
🌻🌻🌻 [google.com]
(Score: 2) by VLM on Saturday June 14, @02:24PM
I came up with a third idea.
I think Google is storing a list of captchas solved in the last hour and for every webserver in the cluster if it gets a solve from that list, let it thru.
Well... this is almost too obvious... after you process a request, either delete the captcha solve from the list of valid captchas or mark it as having been used, and don't let it be used 1e6 times maybe to handle race conditions and weird processing let it only be used "ten times".
(Score: 2) by Undefined on Saturday June 14, @11:21AM (1 child)
How many of us actually answer their phone when it's a random caller at this point?
I haven't answered a phone call in quite a few years, as spammers have made the phone into a constant tool of abuse (while the government does little to nothing about it.)
I use a silent ringtone as the default, and have another (audible) ringtone for those callers I actually want to hear from. My only interaction with other calls is a few minutes spent deleting them from my phone's call log every few days.
I'm not saying this vulnerability isn't a problem, of course it is as it's yet another bit of our personal data lost to corporate incompetence / malfeasance and government complicity, but at least for me, the actual random calling of my phone is only a source of amusement.
--
I use a dedicated preprocessor to elaborate abbreviations.
Hover your mouse over any abbreviation to see any you are unfamiliar with.
(Score: 2) by bzipitidoo on Saturday June 14, @01:23PM
How many of us let our voicemail fill up, so that random callers can't leave spam? I'd disable voicemail altogether, but that's not an option cell phone service providers provide.