Vulnerability in Hangouts Chat: from open redirect to code execution

Aug 4 · 5 min read

Hangouts Chat — desktop app

After installing, it turned out that the desktop app is actually an Electron app. In fact, the desktop app just displays the web application hosted at

It may therefore seem that looking for security issues in the Electron app will not differ from the web version. This is mostly true, with one important caveat. The web version, when displayed in a browser, contains an address bar. The address bar is in fact the only place where the user can tell if (s)he trusts the domain or not. Here’s what Michał Zalewski writes about it in Tangled Web:

In essence, the domain name in the URL shown in the browser’s address bar is one of the most important security indicators on the Web, as it allows users to quickly differentiate sites they trust and have done business with from the rest of the Internet.

However, in the Electron app, the address bar is missing. This means the the user must trust that the application itself serves content from but there is no reliable indicator that confirms it does.

So at this point I thought that maybe I’d be able to find a way to redirect the application to an external domain (other than, which in turn would allow a very reliable phishing. The user would be redirected to an external domain controlled by the attacker, with a login panel very similar to the original one from Googe. The user would not be able to tell that the panel is fake as the address bar is missing.

Looking for redirection

So I started with the simplest possible idea to redirect user to another domain. I will… just add a link to the external domain in the chat. And when the user clicks it, (s)he’ll get redirected.

This obviously didn’t work as external links were opened in the default browser.

Let’s not give up, though.

After further research, I noticed that links to were opened directly in the Electron app. It turned out, by the way, that when a user clicks a link that returns code other than 200 (like:, the user must restart the application as there is no “Back” button ;)

A quite common way to bypass URL access rules is to abuse redirections (responses with code 3xx). I noticed that redirects to when navigating to a non-existent URL, like So I defined a match/replace rule in Burp to rewrite the “hasBeenRedirected=true” URL-s to to see what happens.

And this is how the application reacted:

This is amazing! It actually confirms that a 302 redirect might be abused to display arbitrary websites within Hangouts Chat window.

The only missing piece now is an actual redirect in

Open redirect

Open redirect is a vulnerability which, in my opinion, tends to be overvalued. To cite Google from their Bug Hunter University page:

Open redirectors take you from a Google URL to another website chosen by whoever constructed the link. Some members of the security community argue that the redirectors aid phishing, because users may be inclined to trust the mouse hover tooltip on a link and then fail to examine the address bar once the navigation takes place.

I agree with the sentiment. In general users should trust the address bar as the only reliable security indicator. The thing is that it is no longer true in case of Electron. In Electron app we don’t have the address bar, hence the user is unable to confirm to identity of the website. So in this case, it is clearly a severe vulnerability.

The search for open redirect in turned out to be much easier than I had initially thought. Any URL under is redirected to For example, check this out: You should end up on after clicking.

The redirect to is just a first step in the riddle. But in fact the most important one as there exists a well-known, publicly disclosed open redirect on (credit: @teh_h3ck). Please refer to the original blog post to find out details but the idea is that basically I can redirect to my own domain, I just need to host stuff on /_ah/conflogin URL.

So the final open redirect from is as follows:

I then prepared a logon page resembling the one from Google — and now we can have a very credible phishing page :)

The user, as shown in the gif above, cannot know that (s)he is on a fake page because the address bar is missing.

The same attack would not work in the web app:


As you can see, Electron applications, because of missing address bar, actually make open redirect great again. If you write an Electron app, make sure that the main window cannot be redirected to an external domain.

If you use Google Hangouts Chat, make sure to update. Google released a patch a few days ago.

Interestingly, Google was quite generous with the bounty for the bug and paid 7,500 USD. The bounty actually corresponds to code execution.

Thank you, Google, for the research grant, by the way! Otherwise, I would have probably never looked at the application.

Update: The original title of the post was: “Vulnerability in Hangouts Chat a.k.a. how Electron makes open redirect great again”. It sparked some backlash in social media and seemed click-baity hence I decided to change it to something more neutral.

Discord Community ::


Written by

Contact :

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade