Critical Security Flaws in Pure VPN: Code Execution and IP Address Disclosure

Introduction

In this blog post, we shed light on two critical vulnerabilities discovered within PureVPN. One involves an alarming IP leak, a severity comparable to Remote Code Execution (RCE) in the realm of VPN security. The second vulnerability pertains to Code Execution under specific conditions. PureVPN, a well-established player in the VPN industry for over a decade, has recently expanded its presence into other security products.

PureVPN DNS Leak

The first vulnerability found in PureVPN's Linux Desktop client is straightforward. It centers around DNS leaks, a common concern in the VPN landscape. These leaks can unintentionally expose a user's browsing history to their Internet Service Provider (ISP) or other prying entities, even when the user believes they are securely connected through the VPN.
This vulnerability arises because the PureVPN Linux client fails to properly handle DNS queries, allowing them to bypass the VPN tunnel and be sent directly to the ISP or default DNS servers. This flaw was effectively demonstrated using a tool designed to detect IP and DNS leaks.

Code Execution via missing lib file

While conducting a dynamic analysis of the PureVPN Linux client, our observation revealed that upon activating the login button, a system call named 'opennat()' is triggered. This particular system call is designed to load the 'libnssckbi.so' shared library file from a location that permits user-writable access. Dynamic loading, a mechanism enabling an application to load a library into its address space at runtime instead of compile time, is employed in this process. It is crucial to highlight that the specified path does not contain the 'libnssckbi.so' file.

This presents a security vulnerability, potentially enabling malicious actors to execute arbitrary code by placing a file named 'libnssckbi.so' in the designated path. Furthermore, the root cause analysis has unveiled a broader issue affecting applications that rely on the Chromium engine. Any such application, when used on an Ubuntu-based system, becomes susceptible to this issue.

Potential Implications

Malicious Code Execution: By exploiting this vulnerability an attacker can inject, and execute, malicious code. The attacker can use this behavior to bypass the application whitelisting rules.
Denial of Service (DoS) Attack: Substituting the 'libnssckbi.so' file not only exposes users to security risks but also disrupts the functionality of the PureVPN application. This dual impact makes it a serious concern.
Phishing Threats: As an extension of this vulnerability, an attacker could potentially create fake login prompts for PureVPN, tricking users into revealing sensitive information, falling victim to phishing attempts.

Proof of Concept (PoC)

PureVPN’s Response

PureVPN responded by acknowledging the IP leak vulnerability and fixed it in the subsequent release. Whereas, the RCE, PureVPN termed as “Won’t Fix” and responded with the following:

We appreciate your efforts and responsibly sharing your findings. We looked at your report thoroughly to find the root cause of the problem in our code.

Our Linux application is based on Electron which uses Chromium engine. While we have been able to reproduce your finding, we were not able to find the vulnerable code in our repository. Upon initial analysis, we have identified that the lookup for 'libnssckbi.so' from the path '/home/$username/.pki/nssdb/libnssckbi.so' is done by Chromium itself and the same behaviour has been observed in other applications using Chromium such as Google Chrome and Slack (Screenshots / video attached for your reference).

Based on your POC, it appears that the PureVPN app itself does not provide any vector for injection or remote code execution attack unless the system is already breached and running this app. Same goes with Slack and Google Chrome as well. Please see the below snippets and attached screen recording for reference.

Reported issue does not require any action from our side as it has to be fixed in the Chromium project. We would appreciate it if you also may provide any recommendation for the current scenario.

Google’s Response

It is worth noting that this issue was responsibly reported to the Chromium project; however, the response was not entirely satisfactory, as they deemed such vulnerabilities as low impact and local attacks are normally not part of their threat model.

Credits

The vulnerability was discovered by "Rafay Baloch" and "Muhammad Samaak".

Conclusion

In case of PureVPN, the impact of this vulnerability is notably higher due to the potential for a Denial of Service (DoS) attack. A malicious actor could replace the 'libnssckbi.so' file, rendering the PureVPN application unusable. While it is true that each application has its own threat model, and just because a vulnerability exists in one application does not mean it is acceptable in another, especially in a VPN, which users rely on for enhanced privacy and security.