Google has fixed a security vulnerability in its page for recovering account details that allowed anyone to access the page and brute-force the private phone number of any user. The flaw posed a significant risk to Google users by exposing them to risk of phishing and other attacks.
A security researcher who goes by the online name of Brutecat detailed on their website how the page for recovering one’s password worked without JavaScript. This meant that it also lacked protection from BotGuard, a cloud-based cybersecurity offering designed to protect websites and Web applications from malicious bots, automated attacks, crawlers, and scrapers.
“This surprised me, as I used to think these account recovery forms required JavaScript since 2018 as they relied on BotGuard solutions generated from heavily obfuscated, proof-of-work JavaScript code for anti-abuse,” Brutecat wrote in a post detailing the discovery.
BotGuard won’t work on websites without JavaScript because many of its advanced detection techniques rely on executing JavaScript in the visitor’s browser to gather client-side data, researcher Pieter Arntz from Malwarebytes explained in a post analyzing the flaw.
“If a website does not serve JavaScript, or if a user or bot disables JavaScript, BotGuard cannot collect the necessary information for fingerprinting or behavioral analysis,” he wrote.
Brutecat informed Google of the flaw, and it has since been fixed; the researcher was awarded $5,000 through Google’s bug-bounty program for the discovery.
How the Brute-Force Google Flaw Worked
Since BotGuard was not in effect on the password-recovery page, Brutecat was able to craft two HTTP POST requests to check if a recovery email or phone number was associated with a specific display name. The first provided an “ess” value tied to the recovery phone number that could be used for the next HTTP request.
The second request allowed Brutecat to check if a Google account exists with that phone number as well as the display name, with the response coming back that an account was found. The researcher then tried to brute-force entry into the account using the phone number on the recovery page but came up empty due to a rate limit on their IP address and the arrival of CAPTCHAs after a few requests.
The researcher then had the idea to use a proxy as well as IPv6, rotating the IP address used for every request to bypass the rate limit, and developed a proof-of-concept (PoC); however, they always ran into CAPTCHAs as a roadblock to brute-forcing the person’s account details.
Eventually, Brutecat developed a way around the roadblocks by replacing js_disabled with the BotGuard token from the JavaScript-enabled password-request form. “The Botguard token seemed to have no request limit on the No-JS form,” Brutecat explained.
Final Tweaks Led to Success
This paved the way for the PoC work, but the researcher had to make a few more tweaks to address issues such as finding country codes for a victim’s phone number and discovering the victim’s Google account display name.
“Brutecat also had to use rotating IP addresses and a trick to bypass the occasional CAPTCHAs but was able to manage 40K requests per second,” Artnz explained in the Malwarebytes post. “At that rate, if the attacker knew the country code of the phone number, it would take about 20 minutes in the US to find out the recovery phone number. In the UK that would come down to 4 minutes because they have shorter phone numbers.”
To acquire the full display name of the account, Brutecat discovered a method to leak Google account display names by exploiting a feature in Looker Studio, formerly Google Data Studio, Artnz went on to explain. The researcher did this by making a report/document in Google’s Looker Studio tool, then changing the document’s owner to the victim’s Google account, using the victim’s email address.
“After transferring ownership, the victim’s full name automatically appeared on the Looker Studio home page’s ‘Recent documents’ list even if the victim never opened the document, interacted with it, or knew about it,” Artnz explained. “The key to this was finding that Looker Studio’s interface still displayed names for document transfers without requiring any action from the victim, unlike other Google services that now require prior interaction.”
Mitigation & Potential Impact
Brutecat sent a report about the flaw to Google on April 14 and received an immediate response, with Google acknowledging by April 25 that it was a good catch and the flaw did indeed exist. By June 6, the flaw was completely mitigated. Google fixed the flaw by fully deprecating the No-JS username recovery form to endpoints worldwide, according to Brutecat.
“We’ve always stressed the importance of working with the security research community through our vulnerability rewards program and we want to thank the researcher for flagging this issue,” Google said in an emailed statement. “Researcher submissions like this are one of the many ways we’re able to quickly find and fix issues for the safety of our users.”
At this time, the company does not believe that the flaw has ever been exploited. However, such a weakness in Google’s password-recovery form would have posed a significant threat to users if it had been exploited, exposing them to various phishing and other attacks, according to Malwarebytes. Indeed, having someone’s personal number and other private details about them is especially helpful for socially engineered vishing attacks that initiate with phone calls.
“Allowing an attacker to trace phone numbers to Google accounts like this creates a massive risk for phishing and SIM-swapping attacks — especially since the majority of users will have their primary phone number as their account recovery number,” Artnz wrote.
