Multiple Critical Vulnerabilities in PureVPN - Remote Code Execution + IP Leak

Introduction

This blog post highlights two vulnerabilities found in PureVPN, one being an IP leak, which is as bad as an RCE in the VPN world, and the other being Remote Code Execution in certain conditions. PureVPN is a very popular VPN that has been in the game for more than a decade and has slowly started entering into other security products.

PureVPN DNS Leak Issue 

The first vulnerability is straight forward in PureVPN’s Desktop client for Linux. DNS leaks, a common concern among VPN’s, which can inadvertently expose a user's browsing history to their Internet Service Provider (ISP) or other prying entities, even when the user is securely connected to a 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 Ipleak.net, a tool designed to detect IP and DNS leaks.

 

Code Execution via missing lib file

During a dynamic analysis of the PureVPN Linux client, we noticed that when the login button is activated, a system call called 'opennat()' is initiated. This system call aims to load the 'libnssckbi.so' shared library file from a location that allows user-writable access. Dynamic loading is a mechanism that allows an application to load a library into its address space during runtime, rather than at compile time. However, it is essential to note that the specified path lacks the existence of 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 behaviour 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.