An analysis of false claims by Venak Security

Since 2014, Proton has operated a public bug bounty program that encourages security researchers to look for vulnerabilities in Proton software and earn cash rewards for what they find and report to us. The more people we have examining our open source code, the faster we can identify potential problems and apply fixes to protect our users.

We’re deeply grateful to the worldwide community of experts who contribute to this program. But unfortunately, every once in a while, we will receive bug bounty claims that don’t stand up to scrutiny, often as a result of insufficient technical understanding.

In response to community questions, today we’re clarifying claims from Venak Security about Proton Pass and Proton VPN. Although we explained to the Venak researchers why their claims were false when we rejected their bug bounty, Venak subsequently published those claims anyway, making it necessary for us to set the record straight.

Let’s start with the bottom line: Venak’s overall claim — “Proton VPN and Proton Pass are suffering from memory protection, user data at risk!”— is false. To see why, let’s break down each claim in more detail.

Proton Pass

Claim 1

“Proton Password Manager Vulnerability: Unsecured Credit Card Data at Risk!”

Reality: In Proton Pass, as in any other password manager, when a user is actively viewing an item (e.g., a credit card number), that data must be stored unencrypted in memory. You can’t encrypt the data in memory, or the application cannot use the data while it is running. There is no way to display data to a user without that data being stored in memory. This is how every password manager works and is not a bug.

In Proton Pass, all sensitive data, including credit card numbers, remains encrypted on disk when not in use. We take additional precautions by obfuscating sensitive data in memory while at rest, only de-obfuscating that data when a user explicitly requests to view an item.

Proton VPN

Claim 2

“Static private keys could potentially expose users’ data to MITM attacks!”

Reality: Despite claiming to have access to private keys, Venak never demonstrates this; rather, the post states, “Here are some screenshots of public keys scraped from memory”. However, public keys are not sensitive, they are meant to be public. As the names imply, public and private keys are not the same. Furthermore, even if private keys were extracted from memory, they are not static, but generated at login per user device. This means even with access to these keys, an attacker would not be able to decrypt user traffic.

Claim 3

“A bad actor could easily extract the data and decrypt the traffic in memory or using a MITM attack.”

Reality: The claim here is that the private keys stored in memory can be used to decrypt user traffic. That is not, however, how the open-source WireGuard® VPN protocol that Proton VPN uses works. WireGuard provides “perfect forward secrecy”(new window), meaning that compromising secrets now in no way compromises previously encrypted traffic or any future traffic.

An attacker who obtains the private keys could potentially authenticate as the user but would not be able to decrypt any traffic. VPN traffic is encrypted by a separate “session key”, which is automatically rotated every two minutes. It is not encrypted by the private key, as claimed by Venak. In short, the claimed vulnerability simply does not exist. Of course, an attacker with admin access to the user’s device could do harm, but that’s not something any VPN can protect against.

Claim 4

“Proton decided to use a static value for each server, which can be easily scraped from memory during key generation.”

Reality: As explained above, the public keys of our VPN servers do not change and are publicly available, because they are public keys. This is not a security issue.

So is your data really at risk?

No, the reported “vulnerabilities” are without merit, and that is why they were rejected by our bug bounty team.

We stand by our products and always keep the privacy and security of our users as a priority. We always welcome comments and engagement with the security community, whether directly through our open-source software projects(new window), or our bug bounty program. We remain committed to our bug bounty program, and look forward to continuing to pay out awards for qualifying vulnerabilities.