TrustCall Not Susceptible to Media File Jacking (Telegram, WhatsApp, others Are)

A recent article from Symantec describes a potential vulnerability in WhatsApp and Telegram running on Android:

The security flaw, dubbed “Media File Jacking” … stems from the lapse in time between when media files received through the apps are written to the disk, and when they are loaded in the apps’ chat user interface (UI) for users to consume. This critical time lapse presents an opportunity for malicious actors to intervene and manipulate media files without the user’s knowledge. If the security flaw is exploited, a malicious attacker could misuse and manipulate sensitive information such as personal photos and videos, corporate documents, invoices, and voice memos.

Both WhatsApp and Telegram provide end-to-end encryption; data sent across the network from one user to another is encrypted before it is sent and decrypted on receipt. One of the places where they and others fall short is that once received, the data is not secure. It is stored unencrypted on publicly accessible storage; rogue software detects the incoming attachment as it is written to storage, then manipulates the file before it can be presented to the user.

On Android, there are two types of storage available to an application: internal and external. Files written to internal storage are available only to the application that creates them. External storage is for files that are intended to be shared with other applications. WhatsApp and, in some circumstances, Telegram write their attached files to external storage.

TrustCall, on the other hand, writes all incoming attachment files to internal storage, safe from any malware. TrustCall provides an extra layer of protection. Not only are the attached files inaccessible to outside applications, the files themselves are stored encrypted. So even if third party malware was somehow able to bridge the device’s storage security, it would not be able to access the information stored in the files.

In addition to these measures – internal storage and encryption at rest – the article recommends that the file’s content be validated by the sender providing a hash of the contents which can be checked by the receiver. With TrustCall this validation is not required because the algorithm used for encryption, AES-GCM, provides the same level of integrity checking. If the AES-GCM protected data is found to have been compromised, the decryption fails before attempting to decrypt the payload. This protects against other security vulnerabilities that depend on the recipient attempting to decrypt the payload. By using AES-GCM, we authenticate first, then decrypt only if authentication passed.

Verified by MonsterInsights