A few months ago Google released a new product – Hangouts Chat application, which was surely the answer of the American giant to the ubiquitous Slack. In short, it is a communication platform for teams, where you can simply chat, as well as exchange files, presentations, etc.
You can use the Chat both in your browser (at https://chat.google.com/ , but it is necessary to have a G Suite account), as well as in the form of a desktop and mobile application – which in turn, can be downloaded from https://get.google.com/chat/. Google apparently cared strongly about the security of this application because they awarded a number of research grants at the time. I also decided to use it – and I took a desktop application for the workshop because it is not web applications alone that humans live for :).
Hangouts Chat – what a desktop application looks like
It turned out that the desktop application is written with the use of Electron, a framework that allows the writing of applications for desktop systems (Windows, Linux, macOS) with the use of web technologies, such as HTML, CSS, or JavaScript. From the technical point of view it was realized in such a way that the window with the view of the application is, in fact, an instance of Chromium browser, and underneath there is also Node.js running.
In the case of Hangouts Chat, the desktop application is practically no different from its web version. In fact, the Electron window simply displays the same website that is hosted at https://chat.google.com. This is shown in Picture nr 1.
Therefore, it may seem that searching for bugs in the desktop version will be no different from searching for bugs in the web version. This is true, but with one important reservation. The web version, displayed in a traditional browser, of course, has an address bar. The address bar is, in fact, the only place where you can determine whether or not you can trust the domain. Below is a quotation from the book Tangled Web by Michał Zalewski, which confirms this opinion:
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, there is no address bar in the desktop application. This means that the user must trust the application itself, that it serves content from the domain https://chat.google.com, but there is no reliable method, no reliable indicator to confirm it.
So I thought that maybe I could find a way to convince an application to redirect to a location other than chat.google.com, which would result in a very reliable phishing, extracting user login data. In Chat application one would be redirected to a domain controlled by me, where there would be a login panel similar to the original one from Google. The user could not verify that the panel is false (there is no address bar), so he would give his data there, which could then go to my server.
Search for redirection So I started to think about possible ways of redirecting the user to another domain. The simplest idea… is to add a link to an external chat domain. The user clicks the link and then switches to the external domain.
Reality? Links to external domains are opened in the default system browser.
As you can see in the video above, the link to Sekurak site does not open in the Chat application itself, but in an external browser. So it is difficult to convince the user to provide us with data to Google, if he will be able to see which domain he is working on.
Testing the topic further, I noticed that links leading to the domain chat.google.com, are being opened in the application. By the way, I discovered that if a user clicks on a link that answers with e.g. code 400 or 404 (e.g. this one: https://chat.google.com/webchannel/events), he has to restart the application in order to be able to continue using it because there is no “Back” button in it.
From the experience of working with various applications, it was often noticed that a good way to circumvent the rules related to URLs (in the example above, meaning, only links to a specific domain are allowed) is to use HTTP redirections, in other words HTTP responses with 3xx codes.
By default, chat.google.com responds with redirection if we refer to a non-existent URL in it, e.g. https://chat.google.com/test123. This redirection leads to: https://chat.google.com/u/0/?hasBeenRedirected=true.
Therefore, in order to test whether the redirections will actually allow redirecting to any domain:
- I will run Burp in the background (this is a webproxy tool),
- Set Chat to work with a proxy,
- I will set up a rule in Burp so that the header of the answer
“https://chat.google.com/u/0/?hasBeenRedirected=true” is replaced by “https://sekurak.pl”. Thanks to this, the redirections will be changed to one that leads to Sekurak.
The appropriate option in Burp can be found in the menu Proxy->Options->Match and replace->Add. The values I set are shown in Picture nr 2.
Let’s see below how the application reacted to such changed redirection:
Fantastic! I think that already at this point it was possible to talk about vulnerability in this application, i.e., not checking where the redirections lead. However, I missed one more stone. For the time being, the attack is practically impossible to use because it is hard to count that we will be able to attach a proxy to the user, who will change the content of the redirections.
You will need a vulnerability that allows you to redirect the user to any other site. And open redirect is such a susceptibility.
Open redirect
Open redirect is a common vulnerability in web applications. It boils down to the fact that we have, e.g., a URL of the following type: https://sekurak.pl/?redir=https:// attacker-domain after visiting which the user will be redirected to https:// attacker-domain.pl. The theory (as is also mentioned on the OWASP) is that if a user has been redirected to this domain from a domain he trusts, he will also trust this target domain more strongly. This is to facilitate phishing attacks. In my opinion, this is a rather stretched interpretation, and the Google security team has a similar opinion. In a traditional web model, the user can still rely on the address bar as a place to tell if the domain is trusted.
However, in the case of Chat desktop application, the situation is quite different. Here open redirect is indeed a serious vulnerability because the user of the address bar does not see it; he does not know on which domain he is entering login data.
So I decided to look for such vulnerability in the domain https://chat.google.com. It turned out to be much simpler than I thought at first; all you had to do was browse through the requests generated by the application itself.
It generates a request to the inside of the catalogue https://chat.google.com/accounts. It turns out that all such URLs redirect to https://accounts.google.com. Check it out for yourselves: https://chat.google.com/accounts/any-url: after clicking you should be at https://accounts.google.com/anny-url. The redirection to accounts. google. com is only the first element of the puzzle but the most important because it turned out that there is a publicly known open redirect in this domain!
So I didn’t have to look any further but to use the solution described on the blog Vag Mour {Labs}. For a detailed description of the error I invite you to the link from the previous sentence, but the attack boils down to the fact that I can redirect to my domain; I just have to host something under the URL:/_ah/conflogin in it. The URL with this redirect looked like this:
|
1 |
https://chat.google.com/accounts/ServiceLogin?continue=https://appengine.google.com/_ah/conflogin?continue=http://bentkowski.info/&service=ah |
So I prepared on my domain a login panel resembling the one from Google – and this time we have a fully reliable phishing :).
The same attack will not work with a web browser because the address bar will clearly indicate that the domain should not be trusted (Picture nr 3).
Summary
I think that the first conclusion to be drawn from the description above is that you should always look at what you see in the address bar, in particular, if in a moment we have to enter your credentials or any other confidential data on the website.
Second conclusion: Applications written in Electron make open redirect a much more serious vulnerability than in the traditional web model, due to the fact that the user cannot confirm the authenticity of the site. So he must trust that the application itself verifies where it is redirected.
The last conclusion: If you use Hangouts Chat – update! Google released the proper patch a few days ago.
In response to a frequently asked question under the posts about bug bounty finds: Google was surprisingly generous when it comes to the bounty for this error because they paid $7500. Apparently, they want to provide strong motivation to look for further mistakes.
Update: this tweet by Eduardo Vela Navy that the bounty amount was related to the ability to execute the operating system code on the user’s side. Before I reported this vulnerability, I also tried to escalate it in this way, although I did not manage to do so. It is hard to say whether Google knows the specific way in which such vulnerabilities are exploited, or simply assume that this is possible (many other electron applications show that it is often possible).