“Secure” E2E Messaging Apps: More Than Meets the Eye

[This was originally published on RiskBasedSecurity.com.]

Secure messaging apps, often touted as having end-to-end (E2E) encryption, have become extremely popular in recent years. This popularity has increased even more in the last two months, likely influenced by increased anxiety over the power wielded by “big tech” and endorsement by celebrated tech business leaders like Elon Musk.

Some of the most popular apps have also seen millions of users flee their platform in favor of greener pasture for a variety of reasons, including WhatsApp changing their privacy policy despite assurances, Signal being blocked by a government, or inner turmoil within the company. As many users flock to these “secure, E2E” messaging apps, some are learning that many privacy “features” have been slightly dressed up by marketing, as key functionalities are not enabled by default, or can be extremely cumbersome to use.

In addition to the “usual” means for gaining access to encrypted chat, such as nation-state level access to communication networks, machines to attack cryptography, as well as physical access to the phone, the other major way is via classic vulnerabilities. For those familiar with our reports, you may appreciate that before we dive into the numbers, we give disclaimers first. As is often the case when we’re looking at software vulnerabilities, doing a 1:1 comparison is not straightforward, because we need to consider the factors that may influence these numbers. These include technical implementations, age of the app, number of platforms it can deploy on, the user-base, and the presence or lack of a bug bounty program. Here is a quick breakdown of messaging app disclosed vulnerabilities:

Not a Vulnerability

Before you start making assumptions about which is the most or least secure, let’s cover a few things that may influence your perspective. First, press and claims over “hacking” these secure apps may be wildly inflated. One of the best examples can be seen in December, when controversial company Cellebrite said they “cracked” Signal’s encryption. Signal promptly responded, explaining that the claim was exaggerated by the news and mocking Cellebrite’s claims as “amateur hour”. The claim, according to Signal, was false and misleadingly reported.

This illustrates why it’s important to be clear whether a disclosure is valid, represents a lower risk than advertised, has other qualifying aspects, or is invalid. If a report is not valid, Risk Based Security labels it as “Not a Vulnerability” or NAV for short. In the table above we point out how many of the total disclosures weren’t actually vulnerabilities to reach an accurate count while illustrating how pervasive the NAV problem can be.

Other Caveats

It is also important to consider when the app was founded, since the older the app is, the more vulnerabilities are likely to have been found. Newer apps that have a smaller install base typically have fewer disclosed vulnerabilities, just as you would expect. The install base may not immediately seem relevant, but one hidden factor in this is that we don’t know the distribution by platform. If 90% of users have it on a mobile device, then a bunch of vulnerabilities in the desktop client may not be as serious. On the other hand, if the vulnerability is in a mobile client, it may be worth paying more attention to it when forming an opinion of the potential risk.

Risk Based Security strongly encourages secure communications, even for casual chat between you and friends or family. Helping ensure the security and privacy of your chat should be an important factor in deciding on how to communicate. While many will “go where their friends are,” it may be more important to convince your friends and colleagues to adopt safer technology.

Leave a Reply