Added: Gus Bowers - Date: 03.02.2022 13:39 - Views: 46874 - Clicks: 7709
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. Google apparently cared strongly about the security of this application because they awarded a 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 :. 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. In the case of Hangouts Chat, the desktop application is practically no different from its web version. 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. However, there is no address bar in the desktop application.
So I thought that maybe I could find a way to convince an application to redirect to a location other than chat. In Chat application one would be redirected to a domain controlled by me, where there would be a panel similar to the original one from Google. The user could not verify that the panel is false there is no address barso 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. 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. By the way, I discovered that if a user clicks on a link that answers with e. 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. Therefore, in order to test whether the redirections will actually allow redirecting to any domain:.
Thanks to this, the redirections will be changed to one that le to Sekurak. The values I set are shown in Picture nr 2. I think that already at this point it was possible to talk about vulnerability in this application, i.
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 is a common vulnerability in web applications. It boils down to the fact that we have, e. 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 data. 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. The redirection to s. The URL with this redirect looked like this:. So I prepared on my domain a 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. 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 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. Apparently, they want to provide strong motivation to look for further mistakes.
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. Picture nr 1 Hangouts Chat comparison — web version on the left and desktop version on the right Therefore, it may seem that searching for bugs in the desktop version will be no different from searching for bugs in the web version.
email: [email protected] - phone:(438) 335-3869 x 7039
Google's new messaging app 'Chat' prone to cyber attacks, warns Amnesty