Pricing Network
IP Address
34.204.168.209
Internet provider
Amazoncom
NOT CONNECTED
Your Internet provider can possibly track your Internet activity.
Help & Support Contact
IP Address
34.204.168.209
Internet provider
Amazoncom
NOT CONNECTED
Your Internet provider can possibly track your Internet activity.

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

Comments icon
We invite you to discuss this post in our Reddit community or on Twitter. You can also send your feedback to blog@ivpn.net.
Tags: Audit Transparency

Comments

John Ivpnuser

29.01.2020

I can’t seem to access the report!?

John Doe

31.01.2020

Thank you to everyone involved in the audit and being transparent about it. I understand that not every minor detail cannot be covered, but it’s good to at least know that you guys are making an effort to show things are being done. Again thank you, I don’t see much activity in regards to promotion of your services but I hope I prosperous new year to you all and that you keep this transparency up in the future.

Viktor Vecsei

05.02.2020

The link is working on our end. Please contact our customer service team here if you still can’t access it: /contactus - they are ready to send it to you directly through other channels.

cure69

04.03.2020

great to see, thanks for doing this =)

Jorge

14.03.2020

I am not that IT literate; So how if at all does this audit correlate to logging” either network or user related?

spinon

15.03.2020

The total number of issues found in the Cure53 audit (9) does not tally with the sum of the numbers in parentheses. Why the glaring discrepancy?

Viktor Vecsei

14.04.2020

No-logs claim specifically was scrutinized in an earlier audit: https://www.ivpn.net/blog/ivpn-no-logging-claim-verified-by-independent-audit

Viktor Vecsei

14.04.2020

The number of low errors indicated in the original blog post (1) was incorrect. It is actually 3 - as visible in the full audit PDF linked. So the total issue count was shown correctly, while we made a basic addition error on that specific type. This is now fixed. Sorry.

Updating the IVPN Certificate Authority

Posted on May 18, 2020 by Iain Douglas

This is an advanced warning that you may need to take action to continue using our service beyond 20th July 10:56 2020 UTC. The IVPN Certificate Authority (CA) is used to sign certificates we issue for our servers.

IVPN applications are now open source

Posted on February 10, 2020 by Viktor Vecsei

Today we are excited to announce the open sourcing of all IVPN applications (Android, macOS, iOS and Windows) under GPLv3 license. This is a first step in a multi-year plan to open source many parts of our service.

Protect yourself today and get peace of mind

Shut out hackers, identity thieves and the global government surveillance apparatus — every time you go online.