While this is painful advice, if you need the security protections of WhatsApp or Signal, don't use those apps on the desktop. The web/desktop versions are only as secure as the OS and browser underneath them. Instead, use them on a late-model iPhone or iPad (with a bluetooth keyboard if screen keyboards drive you nuts).

Don't use Telegram at all.

Care to elaborate on that?

WhatsApp and Signal use the Signal protocol, which has a good reputation among working cryptographers (who I hope we'll hear from in this thread).

1. It's not default.

2. Encrypted chats don't sync between devices.

Telegram doesn't have encryption.

Still waiting for something with native apps for all platforms to be reasonably trustless and have all the goodies that TG has (bots, games, etc).

It would be very big news if that were the case. Major news outlets such as the New York Times[0] have slammed Wikileaks for using "misleading" language to describe the leaks, specifically in reference to WhatsApp.

I hope the author will clarify how they came across this exploit.

From the NYT article:

> In their haste to post articles about the release, almost all the leading news organizations took the WikiLeaks tweets at face value. Their initial accounts mentioned Signal, WhatsApp and other encrypted apps by name, and described them as “bypassed” or otherwise compromised by the C.I.A.’s cyberspying tools.

> Yet on closer inspection, this turned out to be misleading. Neither Signal nor WhatsApp, for example, appears by name in any of the alleged C.I.A. files in the cache.

[0] https://www.nytimes.com/2017/03/09/opinion/the-truth-about-t...

These bugs didn't come from wikileaks.

>Major news outlets such as the New York Times[0] have slammed Wikileaks for using "misleading" language to describe the leaks, specifically in reference to WhatsApp.

Still wouldn't explain their claims about Signal.

> bypass Telegram’s upload policy and upload a malicious HTML document with a mime type of a video file “video/mp4”. Then, they were able to send it to the victim side in an encrypted channel through telegram servers.

It's only missing the words "cyber" and "darknet" to make it complete, but they just upload html with javascript (malicious or not) and it happens to be over https.

So it's a bit obfuscated, but yeah it seems to only affect the web clients.

This is very easy to do 80% of the way, and difficult to do with the remaining 20%. The last mile of file validation is extremely fickle because it requires an understanding of what the uploading library is doing under the hood. You can minimize your risk by carefully choosing files to accept, understanding how they're parsed by your libraries and correctly disallowing everything else.

Practically speaking, you should at a minimum:

1. Whitelist acceptable file types,

2. Perform server-side, not client-side validation,

3. Validate the file types not only by extension, but by contents,

4. Disallow filenames from being set by user input, and ideally hash them before presenting them back,

5. Store the files on a separate host/CDN,

6. Only allow the uploader to retrieve files uploaded by the user, and not from local or remote resources. If you must allow local directories, maintain strict permissions, and do not allow loopback resources.

That's a great start. To go further, you should investigate which library to use carefully and consider how legitimate files you are choosing to whitelist can still be dangerous. For example, you can trigger an XSS with a valid SVG. You can attack system memory with fraudulent JPG sizes. You can trigger server-side request forgery by uploading 127.0.0.1, etc.

Obviously, a trickier problem when those images are encrypted.

WhatsApp is end to end encrypted, so how is server side validation possible?

In this specific scenario, the files should be validated before a user is presented with them and after they are received and decrypted. The client-side validation is only so that the attacker cannot bypass it and leave the server vulnerable; you can instead offload this to the other party, which in this case is client 2 in a client <-> client communication rather than client <-> server communication.

The point is that it happens somewhere out of an attacker's control in a trusted environment. Obviously, the same limitation applies to server-side validation, which is that the file must be validated without triggering a latent exploit within it. That's why it's also important to understand the parsing libraries.

Because both are Web versions, I'd rate Whatsapp one as 6/10 severity and (due to how hard it is to trick the user) Telegram as 3/10.

Don't have stats but given how inconvenient Web versions are, I don't think they are widely used.

How is it that the explanation from companies come only after the researchers writes a blog?

Why can't they disclose the bug themselves (if it had been fixed).

... said the standalone email program developer, ca 2005. Couldn't find any numbers for Telegram, but in 2015 the number of WhatsApp Web users was reported[1] to be 200 million, which seems like a lot of people. Most of them probably aren't aware a desktop version exists, nor would they care.

[1] http://www.ibtimes.com/whatsapp-web-security-bug-puts-200-mi... in articles about a very similar WhatsApp Web bug, also found by Checkpoint. They don't bother to give a verifiable reference for the 200 million, fwiw.

It's correct that the phone does have to be online while you're using it. But at least you don't lose encryption. Somehow, Signal's web-based client manages to do e2e without that requirement; maybe there's a non-technical reason why WhatsApp does it the way they do.

I use Telegram Desktop but this should have showed up in any security test, which they apparently didn't do. As a pen tester, maybe I should take it upon myself to audit stuff that I use now and then...

Apparently, the receiving end just uses the browser to render whatever it's being sent. So apparently there is (or was) effectively no whitelist or verification on the receiving end. Conveniently, the uploader can also control metadata including filename and the thumbnail.

Since the payload is e2e encrypted (for What'sApp, anyway), the server obviously has no idea that any of this is going.

Still I think checkpoint is doing clickbaiting, regarding to their description of the vulnerability and Telegrams reply.

Still I have the feeling, Signal behaves kinda broken and immature. The phone functionality never worked properly for me. Sometimes I'm receiving message/encryption errors. Also sometimes having delay issues.