Jan 23, 2021 8 min read

Google - Open Redirect

Writeup of Google's Meet Open Redirect vulnerability.

Google - Open Redirect

Open Redirects, in my opinion at least, are a security issue. While not on the level of everything should be dropped and it should be addressed immediately, they do however represent a security risk for your users.

Open Redirect

So, what is an Open Redirect vulnerability? This vulnerability occurs whenever you have input which you then use to redirect the user. Most often this takes the form of a query parameter, which specifies the URL to redirect the user to. This is perhaps the most dangerous form since it is trivial to create an exploit and can help enable attacks such as phishing attacks.

Google's Open Redirect

The vulnerability in Google's Open Redirect is in the fact that Google converts URLs into redirects all over its product suite. The most recent example I found was Google Meet. When a link is posted into the chat messages in a Google Meet session, that link is converted to a Google Meet link in the form of:

https://meet.google.com/linkredirect?dest=<pasted-url>

Where <pasted-url> is the URL which was pasted. There are other parameters, which I will come to in a moment. Clicking on this link will then take the user to the appropriate URL. Now this is a problem since this suddenly becomes a fantastic tool for phishing! Let's look at the following example:

https://meet.google.com/linkredirect?dest=https://accounts-google.phishy.info/

We've emphasised users to look to the beginning of the URL to validate that the link is legitimate. Well, we see that the domain name in the above URL is meet.google.com, a legitimate Google domain. So therefore many will incorrectly assume that this link is legitimate. So what happens when you hit this link? Well you are take to a "Google login" page:

However when you look closer you will realise that it is in fact not an authentic Google login page:

Comparision between an authentic Google login page and a phishing / spoofed login page

The screenshot on the left is the authentic login page. The first give away is the domain name accounts-google.phishy.info, and the other give away (perhaps not so obvious) is the missing content. So we have a link which contains a Google domain, taking you to a "Google login" page. Bear in mind that most will only look to the URL before clicking on it, not after they have clicked on it (I most certainly would be one of these people).

Now you might be thinking, well this link is generated during a Google Meet session so you at least need to be authenticated and have a valid session. Nope! This works without any authentication and is accessible simply by clicking on the link.

Another point is the additional query parameters. There are additional query parameters which do get generated in this link when it is created in Google Meet, however this vulnerability works without those parameters. What is worse you can provide any parameters and they are simply ignored. Now this is an issue because you can use this to help mask the redirect URL:

https://meet.google.com/linkredirect?token=ui2Mk5fz3dzi8zg5oz7K5AkGg3SDDmN2&id=bFSV0DH_IONRBSlW7hSH_nW_PRCYbku3AyNtTq7tJ88&dest=https://accounts-google.phishy.info/

Often this URL could be truncated or more than likely, the user will simply not pay attention to it. Phishers are incredibly creative and they will no doubt make great use of this.

Google's Response

Google response to this is that they don't think that Open Redirects are much of an issue. I did report this to them and it was rejected.

Submission to Google attempting to highlight the issue
Google's reponse to submission

Google have even created a page attempting to explain why they believe Open Redirects are not an issue:

Open redirectors - Bughunter University

Yet when you post the link in something like Twitter and attempt to access the link you are prompted with a warning (kudos to Twitter on this, they've done a great job on this and this is a really great feature):

Twitter's warning message

I do worry, that it is perhaps just myself who views Open Redirects as a security issue. Which is one of the reasons why I put out a poll on Twitter (thank you to all those who took part in it):

Most also share the same view. There were also some interesting comments on the poll, so I would highly recommend that you go and read them for yourself. But ultimately while Open Redirects are not necessarily a significant or critical security issue, they are still a security issue none the less and do represent a risk to your users. Depending on the issue and context, the risk will likely vary. Now the issue with Google's Open Redirect is certainly not something I would lose sleep over, as you have hopefully seen, it does present a risk to Google users. How much of a risk may vary from person to person, depending on who you ask (personally I wouldn't class it as critical). But there is still a concern which would at very least be paid attention to, not simply ignored.

January Update

I've had this blog in draft for over a month, and it was only after Google was contacted for their input that my domain has been flagged:

Google Safe Browsing blocking site

It is in my view that this helps illustrate my point! Why is my domain now flagged if this is not an issue to Google? The fact that this "Deceptive" site was active for a month before it was flagged (likely only because Google was contacted directly, of which I was expecting to happen in any case), illustrates how this issue can be used to help aid phishing. Now I can go ahead and create a new domain and get around this issue temporarily until the new domain is flagged. After which I create a new domain, and then that domain will eventually be flagged. And the cycle continues, and ends up being a game of Whac-A-Mole.

Site on a new domain after Google Safe Browsing flagged the previous domain

Privacy Concerns

Now it turns out that if you follow the traffic flow using the link above, there are in fact 2 redirects:

Redirect 1

The request for the first redirect:

GET /linkredirect?dest=https://accounts-google.phishy.info/ HTTP/1.1
Host: meet.google.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:82.0) Gecko/20100101 Firefox/82.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: close
Cookie: NID=204=N6m7GUJA19XWA2iv0emAGB3dtu3azZzwE6EfJKSGzSWCoOSNnIjlNVd8hfcZe904hIyY9NHN87NzROyCZ9KVYjaTVA2jtTs62d00_iGYcI6IsO1unWFZxkFnPgUbqOXRn1SM5Za70lqCWudsCaSk1JS5Il_XSqTq6BdosvTSVZk; S=talkgadget=ctSyYf_8K1G8Zclh4zj4hh1gDYEGhi2r; CONSENT=WP.28e24e
Upgrade-Insecure-Requests: 1

And the response for the first redirect:

HTTP/1.1 302 Moved Temporarily
Content-Type: text/html; charset=UTF-8
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: Mon, 01 Jan 1990 00:00:00 GMT
Date: Thu, 10 Dec 2020 18:26:42 GMT
Location: https://www.google.com/url?hl=en-GB&q=https://accounts-google.phishy.info/&sa=D&ust=1607711202666000&usg=AFQjCNHUdDPDfHuKlLF-aw7UEheQtYMARg
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Content-Security-Policy: base-uri 'self';object-src 'self';report-uri /talkgadget/_/cspreport;script-src 'nonce-3B8WM8SGZsjmzjBnkCuzFA' 'unsafe-inline' 'strict-dynamic' https: http: 'unsafe-eval'
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Server: GSE
Alt-Svc: h3-29=":443"; ma=2592000,h3-T051=":443"; ma=2592000,h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"
Connection: close
Content-Length: 337

<HTML>
<HEAD>
<TITLE>Moved Temporarily</TITLE>
</HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000">
<H1>Moved Temporarily</H1>
The document has moved <A HREF="https://www.google.com/url?hl=en-GB&amp;q=https://accounts-google.phishy.info/&amp;sa=D&amp;ust=1607711202666000&amp;usg=AFQjCNHUdDPDfHuKlLF-aw7UEheQtYMARg">here</A>.
</BODY>
</HTML>

Redirect 2

The request for the second redirect:

GET /url?hl=en-GB&q=https://accounts-google.phishy.info/&sa=D&ust=1607711202666000&usg=AFQjCNHUdDPDfHuKlLF-aw7UEheQtYMARg HTTP/1.1
Host: www.google.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:82.0) Gecko/20100101 Firefox/82.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: close
Cookie: NID=204=N6m7GUJA19XWA2iv0emAGB3dtu3azZzwE6EfJKSGzSWCoOSNnIjlNVd8hfcZe904hIyY9NHN87NzROyCZ9KVYjaTVA2jtTs62d00_iGYcI6IsO1unWFZxkFnPgUbqOXRn1SM5Za70lqCWudsCaSk1JS5Il_XSqTq6BdosvTSVZk; CONSENT=WP.28e24e
Upgrade-Insecure-Requests: 1

The response for the second redirect:

HTTP/1.1 200 OK
Location: https://accounts-google.phishy.info/
Cache-Control: private
Content-Type: text/html; charset=UTF-8
Strict-Transport-Security: max-age=31536000
Date: Thu, 10 Dec 2020 18:26:42 GMT
Server: gws
Content-Length: 364
X-XSS-Protection: 0
Alt-Svc: h3-29=":443"; ma=2592000,h3-T051=":443"; ma=2592000,h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"
Connection: close

<HTML><HEAD>
<meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>Redirecting</TITLE>
<META HTTP-EQUIV="refresh" content="1; url=https://accounts-google.phishy.info/">
</HEAD>
<BODY onLoad="location.replace('https://accounts-google.phishy.info/'+document.location.hash)">
Redirecting you to https://accounts-google.phishy.info/</BODY></HTML>

Now there may be a legitimate reason why it was done in such as way. However the sceptic in me does wonder why they have chosen to do this in such as manner. This is a company which let's face it, doesn't have the best reputation when it comes to personal data an privacy. The sceptic in me does wonder if they have perhaps done in this manner to try obtain more personal data? However, I'll leave it up to the reader to draw their own conclusions.

Conclusion

Google appears to use redirects in numerous places, and do not seem too concerned about the potential risks this poses. My advice is be vigilant (which you should in any case, but perhaps a bit more when it comes to Google links), when clicking on or accessing Google links. Tools such as password managers can certainly help, I created a video illustrating how password managers can help prevent phishing attempts. Also make sure that you enable multi-factor authentication wherever possible.

Also as part of this exercise I've created a phishing tool, which takes has a fake Google login page. While there is an input for an email, nothing is actually done with this input, and when the user clicks on the Next button or "submits" their email address it takes the user to a page with further information on phishing. This is designed to be an awareness tool to hopefully help alert users to the dangers of phishing and just how easy it is to fall victim to them. It often just takes the slightest slipup.

Sean Wright
Sean Wright
Experienced application security engineer with an origin as a software developer. Primarily focused on web-based application security with a special interest in TLS and supply chain related subjects.
Great! You’ve successfully signed up.
Welcome back! You've successfully signed in.
You've successfully subscribed to Sean Wright.
Your link has expired.
Success! Check your email for magic link to sign-in.
Success! Your billing info has been updated.
Your billing was not updated.