Application Security

Researcher Finds Whitelist Bypass on Google Login Page

Google’s login page is plagued by a whitelist bypass vulnerability that could allow an attacker to redirect users to arbitrary pages or trick them into downloading malicious code, security researcher Aidan Woods claims.

<p class="MsoNormal"><span><span style="color: #000000;"><span style="font-family: &quot;trebuchet ms&quot;, geneva;"><strong><span>Google’s login page is plagued by a whitelist bypass vulnerability that could allow an attacker to redirect users to arbitrary pages or trick them into downloading malicious code, security researcher Aidan Woods claims.</span></strong></span></span></span></p>

Google’s login page is plagued by a whitelist bypass vulnerability that could allow an attacker to redirect users to arbitrary pages or trick them into downloading malicious code, security researcher Aidan Woods claims.

According to the researcher, Google’s login page accepts a vulnerable GET parameter ‘continue’ that undergoes a basic check, and which has to point to a Google service, but which does not verify the type of service that has been specified. Thus, an attacker could insert any desired service at the end of the login process, the researcher says.

Because of that, the vulnerability can be exploited for arbitrary file upload via Google Drive, but also to open redirects via various services. To point the user to an arbitrary file, however, the public link sharing must be enabled after the file has been uploaded to Google Drive.

To exploit the vulnerability for open redirects, an attacker would have to set the value of the vulnerable parameter to “continue=https://www.google.com/amp/example.com#identifier,” which would allow them to send the user to an arbitrary page after login, the researcher explains. Thus, Google’s legitimate login page can be leveraged for phishing attacks.

For example, Woods notes, the user might be told that the password they just introduced is incorrect and asked to reintroduce it. However, the user has been already “unknowingly and seamlessly redirected to an attacker’s website while in the process of logging in to the legitimate google.com,” and they would serve the password to the attacker instead.

The researcher also explains that the ‘continue’ parameter accepts the domain docs.google.com as a value, meaning that an attacker could link to an almost arbitrary file hosted in Google Drive, as long as public link sharing has been enabled for it. What’s more, an attacker can specify the direct download path, thus encouraging the browser to download the file without leaving the legitimate login page, which could determine the user to believe that Google sent the file.

The researcher says that he was able to successfully specify both .html and .exe files and have the browser download them without leaving the login page. Because of that, he says, Google’s login page is plagued with a URL whitelist bypass vulnerability, where the whitelist is the one in place on the ‘continue’ parameter (it would accept only *.google.com/* domains).

Woods also notes that users can prevent this vulnerability from being exploited by always checking the URL (at each stage of the login process), to avoid logging in after clicking links that don’t come directly from Google, and to never run files that appear to come from Google during sign-in.

Advertisement. Scroll to continue reading.

The researcher also reveals that he sent three different reports to Google to point out the issue. Apparently, only the third report was forwarded to a Google employee, who dismissed it in the end, saying that the issue won’t be tracked as a security bug.

“Only first reports of technical security vulnerabilities that substantially affect the confidentiality or integrity of our users’ data are in scope, and we feel the issue you mentioned does not meet that bar,” Google told the researcher. However, Woods believes that the security vulnerability is as real as it can be and that the public disclosure might determine Google to change its position on the matter. He even published a video detailing the vulnerability.

Related Content

Copyright © 2024 SecurityWeek ®, a Wired Business Media Publication. All Rights Reserved.

Exit mobile version