Wire-desktop: webanalytics.localytics.com

[thatwireguy]

Hello, can anyone explain what these GIFs are used for and their importance to the new Linux desktop app?

[thatwireguy]

I'd also like to point out that while wire.com (and all of its subdomains) use HSTS, these amazon servers do not. Could this damage the integrating of Wire's security or possibly expose users to mitm attacks should the SSL be stripped?

[raphaelrobert]

Do you mean if TLS is stripped from localytics? The wire client still only connects via HTTPS, a fallback to HTTP would fail.

[thatwireguy]

Yes, but localytics still tries to load elements _within_ the application. I was very easily able to degrade the SSL and redirect the localytics request to a random malwaredomainlist.com site. As you can see in the kali terminal the redirection was successful.

It failed in the dev tools console because it was a random domain, not a properly formed .js payload -- which I'm not going to demonstrate. I think my point has been made.

This might be expected of an application that doesn't advertise security and "full end-to-end encryption". I'm not trying to give you guys a hard time, I want Wire to be the best secure messaging application available. Using third-party servers with weak TLS is a bad idea.

Do all version of Wire (iOS, Android, app.wire.com) use localytics?

[raphaelrobert]

Your second screenshot shows that the request failed. If the web server you set up couldn't serve the .js file the result should be a 404 instead. There should be more information in your console as to why the request failed.

[thatwireguy]

@raphaelrobert, hey I'm not trying to be rude but is there anyone else that can chime in on this issue? As I stated in my previous comment, I did not take the time to craft a properly formed js payload. However, I was (with great ease) able to degrade the crypto and redirect the localytics request to a domain of my choosing. The point I'm trying to make is not that I injected js into the application layer, the point is that a motivated attacker with greater knowledge of the application and vulnerability could do more damage. @herrmannplatz

Do all versions of Wire (iOS, Android, app.wire.com) use localytics?

Can anyone explain what these GIFs are used for and their importance to the new Linux desktop app?

[raphaelrobert]

We are always glad when people help to increase the security of Wire.
To answer your questions: yes, localytics is used on all platforms.
The GIFs seem to be part of how localytics works, but it would be best to ask the team behind localytics about it directly. We can only suppose that the Get requests are used to upload data and return a very small GIF (277 bytes).

Regarding the requests to localytics: the initial request to fetch the script is made to https://web.localytics.com/v3/localytics.min.js. HSTS is enabled on that subdomain btw. Subsequent requests are made to https://webanalytics.localytics.com (the GIFs) as you correctly point out. It seems that localytics.min.js will always make HTTPS requests if it was embedded in a secure website (but since we are not the authors of it we can only make assumptions).

However on the screenshot with the MITMf log only DNS requests are visible and there is no indication of an actual downgrade (the log also covers a time span of 11 minutes, so it certainly shows more than just the loading of the web app). And again, the screenshot of the Chrome developer tools shows a failed request to the script (there could be more than one reason).

It is difficult to come to a conclusion without further information. At this stage this still only looks like a claim of a potential downgrade attack without sufficient proof.

[thatwireguy]

Unbelievable.

"HSTS is enabled on that subdomain"

That's false.

"the MITMf log only DNS requests are visible and there is no indication of an actual downgrade"

Do you have any idea how dnsspoofing works? The terminal clearly reads "HSTS bypass". That literally means the SSL was stripped. It also reads "www.localytics.com to 91.195.240.70" -- That means the request to *.localytics.com was modified and changed to a malicious domain of my choosing. I can't believe you don't understand what I'm showing you.

" And again, the screenshot of the Chrome developer tools shows a failed request... without sufficient proof"

For the third time, the dev tool console failed because I pointed the localytics request to a random domain, it was not a proper payload. Unbelievable.

[raphaelrobert]

Agreed, I was looking in the wrong section, web.localytics.com doesn't support HSTS.

The whole point of HSTS is to prevent a browser from accessing the HTTP version of a website if it has visited the HTTPS version at least once before. This is to help users who usually don't type "https://" in the URL bar.

However if the browser explicitly wants to access a URL starting with "https://" it will expect a valid TLS connection (including a valid certificate). There is no way of simply "stripping" the TLS from the connection without terminating it properly (which again requires a valid certificate).
The DNS spoofing and ARP spoofing will only redirect the traffic, but it cannot "strip" or "bypass" TLS.
The "HSTS bypass" mention in the log simply means that the "Strict-Transport-Security" field will be stripped from the response header should SSLstrip encounter a clear text HTTP connection.

To go back to the initial discussion: if the browser makes a request to "https://web.localytics.com/..." it will expect a TLS connection.
If the connection to https://app.wire.com is not somehow compromised (and we need to assume this, otherwise all bets are off anyway) there is also no way for SSLstrip to rewrite the HTTPS request into a HTTP request.

In conclusion: it would make sense for localytics to start sending HSTS responses to cover some edge cases, but probably not solve a fundamental problem.

I hope this clarifies things. If you would like to investigate this matter further, I am happy to help setup a test environment.