Independent security audit concluded

We’re pleased to announce that an independent security audit of the IVPN service conducted by Cure53 has concluded. The audit was conducted by 6 members of the Cure 53 team over 21 man-days in late November and December.

The purpose of the audit was to evaluate the security of our information systems by measuring how well they conform to a set of security best practices. The audit identifies vulnerabilities that may affect the security or privacy of our customers and provides recommendations on how to resolve them. However, an audit only provides a snapshot of the systems in scope during the period in which it was conducted. We hope that publishing the results of these audits increases our customer’s confidence in the security of our systems and demonstrates our commitment to operating transparently wherever possible.

The scope of the audit was very extensive and included our public VPN service infrastructure, our internal backend servers supporting our VPN service and penetration testing of our public web servers. A white-box approach was used whereby Cure53 was given full access to all our code repositories and a dedicated audit environment created to replicate our exact production environment. No access to production VPN servers or infrastructure was granted to members of the cure53 team.

A total of 9 issues (3 high, 2 medium, 3 low, 1 info) were discovered, all of which were either immediately resolved or have since been resolved. Although the general assessment concludes the audit on the positive note and the vast majority of infrastructure was shown to be designed with high levels of security, the audit identified two vulnerabilities which we’d like to expand on below.

1. Disabled CSRF token

During the audit it was identified that CSRF protection middleware on the IVPN website was commented out.

Although it was re-enabled immediately, it showed that our development process failed to protect us from this code being deployed in the first place. We believe that the code disabling CSRF was pushed to production accidentally by a developer with intention to debug some transient issue on staging and then merged it to production branch.

The attacker would yield no personal data (beyond what would be required to be already known for the attack to succeed) or affect the privacy or security of the customers VPN service in any way. The only possible adverse effect would be locking the user out of their account by modifying their password. Regardless, we take this vulnerability very seriously and have already done the following to ensure this vulnerability can’t be exposed again:

• Created strict rules within our deployment process to peer-review code before deployment (and configured branch permissions to ensure this).
• Added automated tests to ensure this specific vulnerability cannot be deployed.

2. Add-on modules vulnerabilities

We have a legacy system from the early years of our business which contained modules with various security issues. This system has multiple levels of protection and were only accessible to someone

• with access to our internal network
• with valid access credentials to the legacy server
• with 2FA authentication set up on the legacy server

Although only a few people in the company could theoretically exploit these modules, we acknowledge that they should have been removed earlier and it shows that we had a blind spot in the legacy part of our infrastructure. To resolve this issue we immediately deactivated the insecure modules.

Commitments going forward

We believe that extensive regular audits are necessary to ensure our customer’s security and continued trust. We are committed to conducting an annual audit of all our infrastructure. We will initiate another comprehensive audit of similar scope towards the end of this year and every 12 months after that.

We have made available the Cure53 report for those interested in more detail. For transparency we decided to publish the full report with only the details about the vulnerabilities removed to ensure sensitive information about our infrastructure was not exposed (internal hostnames, code snippets etc).

IVPN Team

Featured posts

Related posts

IVPN News

DNS traffic leak outside VPN tunnel on Android

Posted on June 13, 2024 by IVPN Staff

Recently we were made aware of a potential DNS traffic leak outside the VPN tunnel on Android. Even with Android OS “Always-on VPN” and “Block connections without VPN” options enabled, as per the report the plaintext DNS traffic can be observed outside the VPN tunnel.

IVPN News

IVPN web infrastructure security audit concluded

Posted on April 11, 2024 by Nick Pestell

We’re pleased to announce that a sixth annual independent security audit has concluded. The assessment focused on Web UI, backend components, API endpoints, underlying web servers, and web infrastructure. We’d like to share two key excerpts from the report: