05/06/2024
In beginning of May 2024, Blackhat announced an upcoming presentation in August 2024 that incorrectly claims there are zero-day vulnerabilities in OpenVPN2 that allow an attack called OVPNX. The definition of zero-day vulnerabilities is that details are published but no fix available. However the OpenVPN community released a new version in March 2024 with the fixes and the details. Therefore these are simply not zero-day vulnerabilities.
The primary goal of this security advisory is to clarify that these are not zero-day vulnerabilities. It’s important to note that this issue is specific to Windows and is not all that easy to exploit.
Security researcher Vladimir Tokarev reported the issues to the OpenVPN community using a responsible disclosure procedure. They have responded by fixing these issues and releasing OpenVPN 2.6.10 and 2.5.10 and publishing the following relevant vulnerability details:
- https://community.openvpn.net/openvpn/wiki/CVE-2024-27903
- https://community.openvpn.net/openvpn/wiki/CVE-2024-27459
- https://community.openvpn.net/openvpn/wiki/CVE-2024-24974
Impact
In OpenVPN GUI on Windows the OpenVPN2 processes run with least required privileges. But for some actions higher level privileges are necessary, for example for adding routes to the system. For those specific actions the OpenVPN2 process can use the interactive service component which runs at a higher privilege level for this purpose.
If your OpenVPN2 process is compromised, for example by loading a malicious plugin, then it is possible to exploit a vulnerability in the interactive service component to have it perform tasks at its higher privilege level. So this is a privilege escalation issue.
Furthermore the service pipe for the interactive service is reachable over the network, while it does not need to be. If you have valid credentials for a user that is part of the OpenVPN Administrator group, you could access the interactive service, and then exploit the same aforementioned privilege escalation vulnerability.
Exploitability
You could replace the OpenVPN2 binary that comes with OpenVPN GUI with one that performs a malicious attack on the interactive service component. Replacing this binary requires administrator level access. If you run such a binary from another location it will not have access to the interactive service component.
Alternatively you could load a malicious plugin for OpenVPN2 which then does this attack to the interactive service. But you need help from an OpenVPN Administrator to load such a plugin to then exploit the interactive service.
For an over-the-network attack you would need to have valid credentials of a user that is a member of OpenVPN Administrators group.
In short, you would need to have an already significant amount of access to the target system in order to exploit these vulnerabilities. Enough access that you would likely not need to exploit these vulnerabilities.
Resolution
CVE-2024-27903 improves the security of plugin loading on Windows by making it so that plugins can only be loaded from certain trusted locations. So not only do you need the connection profile to be in a trusted location, but the plugin you’re loading must also be in a trusted location. Only OpenVPN Administrator can add to these trusted locations.
CVE-2024-24974 disallows remote access to the service pipe for the interactive service component of OpenVPN GUI for Windows. This solves the remote access vulnerability.
CVE-2024-27459 solves the actual privilege escalation in the interactive service component, so neither methods above can lead to privilege escalation.
If you are on Windows and using OpenVPN GUI, then please update so you get the latest version (2.6.10 or 2.5.10) that includes the fixes for these issues.
11/09/2023
Description:
OpenVPN Access Server uses the OpenVPN 2 codebase at its core for VPN connections. OpenVPN Access Server versions 2.11.0, 2.11.1, 2.11.2, 2.11.3, 2.12.0, and 2.12.1 contain a copy of OpenVPN 2.6 that has two vulnerabilities in it. The first is a division by zero crash, the second a use after free memory security issue.
The division by zero crash is not very easily exploitable on Access Server because the default configuration that it comes with does not include the –fragment option, and control channel security helps to make it harder to exploit. It is however possible that people use the –fragment option, and under certain circumstances it is still possible to trigger this crash. The use after free memory security issue is a more serious one as there is the potential for leaking sensitive information from memory.
We therefore strongly recommend that if you use OpenVPN Access Server 2.11.0, 2.11.1, 2.11.2, 2.11.3, 2.12.0, or 2.12.1, that you upgrade to the latest version of Access Server to address these vulnerabilities. Version 2.12.2 and newer contain the fix for these vulnerabilities.
Resolution:
Update your OpenVPN Access Server to the latest version as soon as possible, which contains the fixes for these vulnerabilities. Version 2.12.2 and newer contain the fix for these vulnerabilities. The procedure on how to upgrade Access Server can be found here: Keeping OpenVPN Access Server Updated. The CVEs we published for this are CVE-2023-46849 and CVE-2023-46850.
10/25/2023
Description
TunnelCrack is the name for a set of 2 vulnerabilities in VPN clients called LocalNet and ServerIP. In simple terms these allow in certain circumstances for traffic that is intended to go through the VPN tunnel to go outside of it. For this attack to be successful the attacker does need to have some control over your local network’s IP addressing and/or DNS servers/records. The way Android implements VPN networking, that particular operating system is not vulnerable to these specific attacks. But other operating systems are.
This affects not only OpenVPN, but other VPN protocols and VPN clients as well, as it is an inherent property of how routing works.
More details are available in this wiki article published by the OpenVPN community, and the linked security report:
Resolution
OpenVPN does support the block-local flag to the –redirect-gateway and –redirect-private options to mitigate the problem by routing the local network IPs into the VPN tunnel. In its current implementation it is however not completely effective in protecting against all possible LocalNet attacks.
We are therefore working together with the OpenVPN community to create solutions on the various operating systems and clients. By necessity these will be different solutions per operating system. In future releases of OpenVPN community edition and OpenVPN Connect these solutions will be introduced to address TunnelCrack.
03/15/2023
Description
For Amazon AWS customers that use the AWS tiered instances licensed and billed directly through Amazon AWS (the ones with xx connected devices in their names), it’s important to ensure your OpenVPN Access Server is up-to-date. The licensing APIs that are used to license these instances will cease supporting TLS 1.0 and TLS 1.1 connections as part of a strategy by Amazon and OpenVPN to meet modern security requirements.
If you have OpenVPN Access Server 2.7.3 or newer, your AWS tiered instance will continue to license properly. Older AWS tiered instances will encounter licensing problems after June 28th, 2023, when the TLS 1.0/1.1 deprecation takes effect. Please note that this affects only AWS tiered instances licensed and billed directly through Amazon AWS. All other licensing forms are unaffected by this change. So this change doesn’t affect those using subscriptions or fixed license keys purchased on our site.
Additionally, on April 30th, 2023, the official standard support ends for the Ubuntu 18.04 LTS operating system that our previous Amazon AWS OpenVPN Access Server releases (prior to 2.11.3) are based on. This covers both the support for newer OpenVPN Access Server releases and security updates of the operating system itself. Therefore, we recommend that our Amazon AWS customers using OpenVPN Access Server upgrade to the latest marketplace offering, which is based on Ubuntu 22.04 LTS and OpenVPN Access Server 2.11.3. The operating system on this offering has updates until April 2027 and will also support new upcoming versions of OpenVPN Access Server.
You must upgrade to the latest Amazon AWS Marketplace image for OpenVPN Access Server to get updates after April 2023.
Resolution
Technically, it’s possible to only resolve the licensing issue on Amazon AWS tiered instances by upgrading the OpenVPN Access Server program to version 2.7.3 or newer on the existing instance, but this won’t solve the issue of the underlying operating system Ubuntu 18.04 LTS going out of support and no longer receiving software and security updates. Our experience with doing an in-place upgrade of the operating system on Amazon AWS has proven that this is risky and can fail with loss of data as a result.
Therefore to resolve both issues, we recommend that you back up settings and migrate them to a new instance of OpenVPN Access Server launched from the AWS Marketplace. Either you can associate the Elastic IP from the old instance with the new instance, or if you’re using a DNS record, you can update the DNS record to point to the new instance’s IP address, to complete the migration.
It may also be acceptable to set up a new instance and configure it from scratch for smaller deployments. But with our migration guide, you can retain your settings from the old instance and restore them to the new one.
We provide documentation that guides you through the migration steps. Our support personnel is standing by to assist you if you encounter any challenges or have any questions.
01/05/2023
Description
Starting 20th of January 2023 we will begin turning off support for TLS 1.0 and TLS 1.1 connections on our website and web download services. TLS 1.2 or higher will be required to make a connection, as that is currently considered secure and supported by almost all software. TLS 1.0 and TLS 1.1 have already been deprecated for a while, but support was kept for some time to allow people the opportunity to upgrade to software that supports TLS 1.2 or higher. To be clear, this change does not affect VPN services, and it does not affect self-hosted solutions like OpenVPN Access Server. It only affects web traffic to the specified sites below.
These are the affected services where TLS 1.0 and TLS 1.1 will be turned off:
- https://openvpn.net (and .com) – the main OpenVPN website
- https://cloud.openvpn.com – the CloudConnexa website
- https://swupdate.openvpn.net (and .org) – file download server for OpenVPN software
- https://as-repository.openvpn.net – the Access Server software repository
Resolution
We don’t anticipate any problems for our customers and visitors that requires any resolution. TLS 1.2 and higher have been supported and standardized for many years now.
Should you however find yourself in the rare position of being unable to visit or access our web services due to this change, it is almost certainly caused by the use of software that is outdated and out of support. In such a case we would strongly recommend to update the software to ensure it can support TLS 1.2 or higher.
12/02/2022
Description
On the 1st of December 2022 an intrusion was detected in one of our systems that contained an encrypted copy of the code signing key used for OpenVPN open source release version 2.5.8 build 603 for Windows. This key was only used to sign that OpenVPN 2.5.8 release build 603 for Windows. It was not used to sign any other software releases or builds. The OpenVPN source code archive files were never at risk, and these were and are safe. We have no evidence or indication that the code signing key was ever obtained by a malicious actor, or that there is anything wrong with the OpenVPN 2.5.8 release build 603. The code signing key was stored encrypted and it is very unlikely it could be abused. However, the mere fact of the intrusion on this system alone has caused us to decide to revoke this code signing key, and re-release OpenVPN 2.5.8 signed with a new code signing key just to be sure, out of an abundance of caution.
Resolution
We have taken steps to increase security, and we have re-released OpenVPN 2.5.8 with a new code signing key, and revoked the old signing key. For you as end-user, there is no remediation steps you need to take. Out of transparency and a firm belief in open communication, we published this security advisory.
11/01/2022
Description
On the 1st of November 2022 the OpenSSL project released security updates marked with high priority for OpenSSL 3 (CVE-2022-3786 and CVE-2022-3602). There is a question and answer document published by the OpenSSL project that provides more detailed information. With this security advisory we aim to provide information on whether your OpenVPN software is affected, and if it is, how to resolve the issue.
OpenVPN Access Server uses the OpenSSL library that comes with the operating system. On most operating systems this is OpenSSL 1.1.1, and that is not affected by this security issue. If however you run Access Server on Ubuntu 22 or Red Hat 9 (or equivalent OS) it will be using the OpenSSL 3 library and you should remediate the situation by upgrading the OpenSSL 3 library in the operating system using the standard apt or yum tools. Guidance on the commands to perform to install updates on these operating systems are in the resolution section below.
CloudConnexa uses OpenSSL 1.1.1 and is therefore not affected.
OpenVPN Connect uses OpenSSL 1.1.1 and is therefore not affected.
OpenVPN GUI uses OpenSSL 1.1.1 and is therefore not affected.
OpenVPN community edition is affected by this issue if you use OpenSSL 3.
OpenVPN for Android is affected, and updating to version 0.7.42 resolves the issue.
Other programs that use OpenVPN may also be affected. We recommend to check with the software maintainer if it is affected and if there is an update available to resolve the issue.
Resolution
To update packages on your operating system (including the OpenSSL 3 library) you can execute the update/upgrade commands as a user with root privileges.
For Ubuntu 22:
apt-get updateapt-get upgrade
For Red Hat 9 (or equivalent OS):
yum check-updateyum update
You can verify the version of OpenSSL now installed with this command:
openssl version
If you see a version like 1.1.1n then you are using OpenSSL 1.1.1 and are not affected by this issue. If you see a version that starts with a 3, check that the particular OpenSSL release for your operating system resolves CVE-2022-3786 and CVE-2022-3602.
It is advisable to restart the system after installing the OpenSSL update, to ensure that all processes will be using the new library. It is also possible to restart services individually, but a system restart will cover all services.
04/21/2021
Description:
OpenVPN Access Server uses OpenVPN 2 codebase at its core for VPN connections. This codebase contains a vulnerability that allows a remote attacker to bypass authentication and access control channel data on servers configured with deferred authentication. It is possible that this control channel data could be used to trigger further information leaks or gain access to protected networks. If the client-side scripting feature is in use, these scripts could be obtained through such an attack. If those scripts contain sensitive information, this information could be compromised. To exploit this vulnerability, the attacker must have a valid, user-locked or auto-login client profile for the vulnerable Access Server, or credentials to obtain such a profile. Although exploiting this vulnerability requires some preparation on the attacker’s side, the severity of a successful attack is high to critical, depending on the gained information. Additionally it was found that it was possible to do a Denial of Service attack using a similar method in the OpenVPN Access Server. We therefore strongly recommend upgrading your Access Server to the latest version to address the vulnerability.
Resolution:
Update your OpenVPN Access Server to version 2.8.8 as soon as possible, which contains the fix for this vulnerability. The procedure on how to upgrade Access Server can be found here: Keeping OpenVPN Access Server Updated. The CVE’s we published for this are CVE-2020-36382 and CVE-2020-15077 and are related to the open source OpenVPN 2 project CVE report CVE-2020-15078.
10/22/2020
Our OpenVPN Connect v2 and v3 client software for macOS is signed using our official digital signature. The signatures of signed installers are also stored on Apple’s servers using their software notarizing solution. Signing and notarizing our software ensures that the program you download from our website or our business products is intact and valid for installation on your system. This is beneficial to the security of our software and your systems.
The digital signature used on our OpenVPN Connect v2 and v3 client software for macOS will expire on October 26, 2020. After this date a particular check on the digital signature might fail. We have updated our client software with a new digital signature that will be valid until September 2025.
Please note that already installed software is not affected by this. That will continue to function normally. It is only new installations that might get a warning message during the installation process about the certificate being invalid because it has expired.
We have updated our client software on our website and on our CloudConnexa product. These versions of OpenVPN Connect have been updated with the new signature:
- OpenVPN Connect v3.2.4.2392 and above
- OpenVPN Connect v2.7.1.111 and above
- OpenVPN Access Server bundled Clients Package v14 and above
On OpenVPN Access Server, the administrator of the server will have to update the Bundled Clients Package (openvpn-as-bundled-clients) to v14 or higher to ensure that the newly signed OpenVPN Connect v2 and v3 software installers can be offered to your users on your Access Server.
Instructions to update the bundled clients package on your Access Server are below. If you have any questions, please contact our support team for more information.
To update on Ubuntu/Debian systems:
sudo apt update && apt upgrade openvpn-as-bundled-clients
To update on CentOS/Red Hat systems:
sudo yum update openvpn-as-bundled-clients
05/30/2020
Description
On May 30th of 2020, a CA root certificate by COMODO/Sectigo Addtrust expired. After that date, any legacy systems that use this CA root certificate will experience an outage or display an error message like “certificate is expired” or “certificate is invalid” when verifying a certificate signed by COMODO/Sectigo Addtrust.
What can happen in certain cases is that you might have a certificate that is valid, but because the CA root certificate it chains to for verification is expired, you will still get a message saying that the certificate is expired or invalid.
More information on the problem and possible solutions can be found here on the official Sectigo website: https://support.sectigo.com/Com_KnowledgeDetailPage?Id=kA03l00000117LT
Resolution
Sectigo has other, older, legacy roots apart from the AddTrust root, and they have generated cross-certificates from one in order to extend backward compatibility. The cross certificate is signed by the root called “AAA Certificate Services”. Customers who have embedded AddTrust External CA Root into their applications or custom legacy devices may need to embed the new USERTrust RSA CA Root replacement.
Older Access Servers can contain CA root information that is outdated. To resolve that, you can update the Access Server to the latest version that contains the most up-to-date information.
If you experience problems with COMODO/Sectigo Addtrust certificates, we recommend that you contact them for support on their certificates.
02/12/2020
Description:
We have identified a possible issue that could lead to LDAP authentication bypass on OpenVPN Access Server 2.8.0. We investigated this and were able to reproduce the problem. It has been discovered that when using an LDAP authentication system in combination with the Access Server version 2.8.0 (other versions are not affected) that there is a security flaw with the login process. Customers that are using two factor authentication, which many fortunately do, are still protected thanks to the extra security factor. Regardless, we recommend that people that are running Access Server 2.8.0 in combination with LDAP to upgrade to the latest version immediately.
Customers that are using Access Server without LDAP are not affected by this issue. Customers using a version of Access Server other than 2.8.0 are also not affected.
Resolution:
If you are running Access Server 2.8.0 and you use LDAP authentication, you should update to the latest version as soon as possible. We released this version within hours after we were able to reproduce this problem. We are also submitting a CVE report for full transparency and to make people aware that they should update. The CVE we published for this is here: CVE-2020-9853.
12/14/2018
Updated licensing system
The licensing system of the OpenVPN Access Server product was updated on January 20th of 2019 to add support for new features and to enhance security. Because of this there were some changes on our end, and this requires a small change in the licensing system to be implemented on OpenVPN Access Server installations from before 2019 as well. This patch ensures that new license keys and renewal license keys can be activated after the mentioned date. The impact of this change is kept as minimal as possible, and we will provide information to answer the most common questions and to make this transition go as smoothly as possible.
Please note that this change does not affect our Amazon AWS tiered instances that are pre-licensed with a predefined amount of connections. These are billed through Amazon AWS directly and use a different licensing system that does not need this update.
Frequently Asked Questions (FAQ)
What do I have to do?
You should upgrade your Access Server to the latest version available on our software packages page, which includes the changes to the licensing system. Alternatively, if you do not wish to upgrade now, you may use our licensing patch to update only the licensing code on an existing Access Server. The patch is designed so it can be applied live without shutting down or cold restarting the Access Server service, so VPN clients don’t need to be disconnected, and it is compatible with Access Server 1.8.3 and above.
What exactly will change?
We are making it possible for new options for licensing in the future, in other words to create a more flexible licensing system. This will make it easier for you to change the amount of connections on an Access Server in a future update of our licensing system, and will allow us to prepare better licensing options for the exciting new clustering feature that we are developing (only available as beta at this time). On top of that we are improving the security of the licensing system while we are at it. This requires that Access Server is updated as well.
What happens if I do nothing?
Actually very little. If you continue using your current OpenVPN Access Server as it is without either upgrading or applying the licensing patch, it will function normally and the license keys that are on it right now will continue working just fine, even after January 20th (assuming your license keys do not expire before then of course). However, when you try to activate new license keys on an old or unpatched Access Server after that date, or renew license keys for this server and try to activate a renewal key on the server, it will produce an error message. To resolve this, either upgrade your Access Server to the latest version, or apply the live licensing patch. You can then activate license keys again normally after that date.
Does this affect the licenses currently on my server?
No. Those are completely unaffected and will continue to function normally.
Do I need to buy new license keys?
No. Your license keys remain completely unchanged.
Can I upgrade my server or apply the licensing patch right now?
Yes, please do. You may upgrade your Access Server at any time before or after January 20th. If you do it before that time, you will not have to worry about any possible licensing problems.
I can’t interrupt my production systems, and I don’t want to upgrade.
That’s alright, we understand that our product is being used in highly critical situations and updates and restarts can be disruptive. So we’ve accounted for that. First of all, if you do nothing, your existing license keys will continue working fine even after January 20th of 2019 (assuming your license keys do not expire before then of course). And if after that date you want to activate a new license key, simply use our live licensing patch. With this patch you can continue using and running your current Access Server version. It will not require your Access Server service to go down and disconnect your VPN clients, but it simply patches the licensing system in memory while Access Server is running. If you have concerns, you may consider setting up a test platform and test the live licensing patch on that to ensure there will be no problems on your production system.
I use a very old version of Access Server, older than 1.8.3.
Unfortunately the new licensing system cannot function properly on an Access Server that old. Version 1.8.3 is from around 2011, so very old. Aside from the security considerations of running severely outdated software, we also just do not support such an old version anymore. We recommend that you upgrade to the latest version. However, if for whatever reason you must continue running such old software, and wish to activate a license key on this, contact our support ticket system and let us know the license key you wish to activate, and we will help you perform an activation procedure for your Access Server.
11/29/2018
In beginning of November of 2017, we released a new version of OpenVPN Connect for Android with many security and functionality improvements. Shortly thereafter we received reports from some users that making a connection was no longer possible. The error messages varied from “certificate verification failed” to “TCP EOF” network errors. We’ve traced this down to certificates being used by older implementations of OpenVPN open source servers that were using MD5 type signature hashes. These signatures are insecure and should not be used anymore.
It is important to note here that OpenVPN Access Server was not affected by this issue. We are talking here about open source implementations of OpenVPN that were using certificates signed with a hashing method called MD5 that has been determined to be broken and which should not be used anymore. Customers of our commercial OpenVPN Access Server offering did not suffer from these problems and do not need to take action. This only really affects people using an open source OpenVPN implementation either set up themselves or part of a third-party embedded product like a router or VPN server product.
We have temporarily added support for MD5 type signature hashes back into the OpenVPN Connect for Android app, which is available on the play store now. If you upgrade to this version then this particular problem should be resolved for you. But the real problem, namely the use of MD5 hash certificates, is not resolved by this. It is strongly encouraged to use secure certificates instead of the flawed MD5 type certificates. It is absolutely not secure to use these older type of certificates and we cannot in good conscience continue to support such a poor level of security in our OpenVPN security product. Therefore support for MD5 will be ending in May of 2018. This gives our users time to migrate to a secure configuration using for example certificates signed with SHA256 type hash or better.
See FAQ item regarding MD5 support on Android app for more technical details on how to detect and resolve this problem.
09/29/2018
Description
Security researcher Ahamed Nafeez has presented a new attack vector which targets VPN tunnels which utilize compression, named VORACLE. The attack vector bears similarities to the CRIME and BREACH attacks, which hit especially HTTPS based connections.
It has been discovered that it is possible to gain information about an encrypted VPN tunnel’s contents in very specific circumstances, if an attacker has the ability to capture the encrypted data packets while a certain type of data is transferred through the VPN tunnel. By that we mean that if a VPN user visits for example an unencrypted HTTP website through an encrypted VPN tunnel, and this information is being compressed and encrypted through the VPN tunnel, certain clues about the contents of this information can still be gathered if the encrypted packets can be captured and analysed, and data can be fed through the VPN tunnel by the attacker. To explain this better, following below is a simplified example. The example mentioned here is not the only possible attack against encryption combined with compression, and it is also very simplified, but it is useful to explain the principle behind attacks like VORACLE, CRIME and BEAST.
Let’s say Alice has setup a login page. To check passwords entered there, Alice sends a message like “tell me if <the password entered> matches <secret password>” to Bob. This information between Alice and Bob is sent through an encrypted VPN tunnel that also uses compression. The more similar the <the password entered> is to <secret password> the better this message compresses. If the attacker Eve can ask Alice to verify passwords and can see the length of the encrypted VPN messages, she gets a pretty good idea how close her guesses are, since the encrypted messages get shorter when her guesses get better.
Without compression the length of the encrypted packets does not change, so Eve cannot gain any information from this. Strictly speaking the length changes if Eve’s password length changes but that gives no additional information. The real world attacks are more complicated and need to take in account the specific circumstances (for example HTTPS or VPN) but they rely on the same principle as demonstrated in this simple example.
Mitigation
Due to the fact that exploiting such an attack is not trivial, we are not treating this situation as an emergency. For now, it is advised that users of the OpenVPN Access Server and the OpenVPN Connect Client software disable the use of compression. This effectively makes exploiting this vulnerability impossible. This can very easily be done on the OpenVPN Access Server by going to the admin web interface, and going to Advanced VPN. There you can disable compression. The client connection profiles may still provide an instruction to enable compression, but it will be disabled if the server denies the use of compression.
For open source OpenVPN users, we direct you to the community wiki article regarding VORACLE.
Resolution
There are still discussions ongoing on how exactly in the open source OpenVPN project compression will be disabled, but for now in our commercial products we will be disabling compression by default in future releases of Access Server. We intend to make it so that when people update their OpenVPN Access Server, or install a fresh Access Server installation, the default setting will be that compression will be disabled. We will also be hiding and disabling the compression feature in later releases of OpenVPN Access Server and work on phasing it out entirely over time, as there is at this time simply no secure method of guaranteeing the security of the data in all situations while compression is enabled.
Our Private Tunnel cloud service had compression switched off already, so is not affected by this issue.
If you wish to disable compression on your own Access Server, go to the admin web interface, go to Advanced VPN, and switch off support for compression.
01/10/2018
Description
For a short while now it’s been known that there are some serious flaws called Meltdown and Spectre that are causing possible security problems for almost all computers. A solution for this, or at least most of the problems, has been created in the form of kernel patches and adjustments in the deepest levels of operating systems like Windows, Macintosh, and Linux, and so on. OpenVPN Access Server itself is only a user-space program and does not run in the kernel and therefore we as creators of the Access Server product do not create these patches. However, we can inform our users on how to get the necessary patches.
Resolution
Our OpenVPN Access Server appliances have for roughly the past 3 years been based on Ubuntu 13, Ubuntu 14 LTS, and Ubuntu 16 LTS. It is important to figure out which operating system your Access Server runs on, and to then take appropriate action to update the operating system software to get the patches and to verify that they have been installed. For Ubuntu specifically there is a page that describes very well how to patch Ubuntu:
For users that run another operating system or an operating system that is no longer supported and updated by their maintainers, it is recommended to plan maintenance to set up a new installation and to migrate data and activation keys (if applicable) to the new server setup, so that you can then enjoy updates for the operating system and get the necessary patches to mitigate the most problematic issues of Meltdown and Spectre. An alternative option is to perform an in-place dist-upgrade of the operating system, but success in this may vary and there is a chance the activation keys may be invalidated in the process, requiring intervention from us to reissue your activation keys for you. The safest course of action when your operating system is no longer supported is to set up a new system with a supported OS and contact us to get activation keys migrated to the new system once things are setup and tested properly.
More information on the Spectre and Meltdown issues can be found here:
More information about a migration process and how to update Access Server itself is here:
11/07/2017
Description
In beginning of November of 2017, we had released a new version of OpenVPN Connect for Android with many security and functionality improvements. Shortly thereafter however we received reports from some users that making a connection was no longer possible. The error messages varied from “certificate verification failed” to “TCP EOF” network errors. We’ve traced this down to certificates being used by older implementations of OpenVPN open source servers that were using MD5 type signature hashes. These signatures are insecure and should not be used anymore.
It is important to note here that OpenVPN Access Server was not affected by this issue. We are talking here about open source implementations of OpenVPN that were using certificates signed with a hashing method called MD5 that has been determined to be broken and which should not be used anymore. Customers of our commercial OpenVPN Access Server offering did not suffer from these problems as we never used such a weak cipher and do not need to take action. This only really affects people using an open source OpenVPN implementation either set up themselves or part of a third-party embedded product like a router or VPN server product with some poor security settings.
Resolution
We had temporarily added support for MD5 type signature hashes back into the OpenVPN Connect for Android app, which is available on the play store now. If you upgrade to this version then this particular problem should be resolved for you if you go into the setting and enable support for weak ciphers. Eventually though, support for this will disappear entirely. But the real problem, namely the use of MD5 hash certificates, is not resolved by this. It is strongly encouraged to use secure certificates instead of the flawed MD5 type certificates. It is absolutely not secure to use these older type of certificates and we cannot in good conscience continue to support such a poor level of security in our OpenVPN security product. Therefore official support for MD5 will be ending in May of 2018, and we may allow this some time more through the use of a special override in the settings of the client program. This gives our users time and motivation to migrate to a secure configuration using for example certificates signed with SHA256 type hash or better.
See FAQ item regarding MD5 support on Android app for more technical details on how to detect and resolve this problem.
07/07/2017
Description
A while ago an issue was discovered in the Network Time Protocol (NTP) daemon that we generally advise people to install on a server running OpenVPN Access Server on Ubuntu. The purpose of the package is to ensure that the time is always correct on the server. This is especially vital when you make use of the Google Authenticator functionality built into the Access Server, as it is time-dependent. On cloud based platforms and other virtualization systems it is not uncommon that time slowly drifts. NTP corrects this automatically.
The vulnerability found has been given designation CVE-2016-9310 and to put it simply, it allows an attacker to use the NTP server to attack other servers with bandwidth. The method is called traffic magnification and basically comes down to make a small request that results in a larger response to a specific target. Enough of these attacks could bring a server down (DoS). Other serious issues have also been found. You can read more about it in the pages linked to below. Fortunately for our users of the OpenVPN Access Server on AWS, our default security groups settings that come with the appliance do not provide access to the NTP daemon at all. So unless these were changed and access was granted to the NTP service port, this flaw cannot be exploited remotely with our Amazon AWS instances.
Resolution
Ubuntu has created their own page regarding this issue and they have issued fixes for the NTP package. Ordinary apt-get update and apt-get upgrade commands should update your packages to the latest versions that contain fixes for this particular issue. We recommend that everyone makes sure their system is regularly updated to ensure these security fixes arrive on your systems as well.
05/15/2017
Description
Minor security vulnerabilities revealed by an audit of OpenVPN, an open source security software providing a safer and more secure internet to millions worldwide, have been fixed. The Open Source Technology Improvement Fund, known as OSTIF, provided funding for the comprehensive security audit. OpenVPN 2.4.0 was audited for security vulnerabilities independently by QuarksLab and Cryptography Engineering between December 2016 and April 2017. The primary findings were two remote denial-of-service vulnerabilities. The issues discovered were minor in terms of security.
Resolution
The denial of service vulnerabilities found have been fixed in OpenVPN 2.4.2 and 2.3.15 released on May 11, 2017. Likewise OpenVPN Access Server, the commercial version, has also been updated to fix those of the vulnerabilities that were found to be present in the OpenVPN Access Server code as well. OpenVPN Access Server version 2.1.6 and above address the issues found completely.
02/27/2017
Description
Google security researcher Tavis Ormandy recently found a bug in the Cloudflare service. You can read more about this on a recent blogpost by Cloudflare. The openvpn.net and privatetunnel.com website both sit behind Cloudflare, a popular content distribution network, for enhanced speed and security. After carefully reviewing the data we feel confident that information was not compromised on our web properties, since the features that are claimed to have been affected were not currently or previously enabled for either of our websites.
Resolution
That aside and in case we missed something, it is always a good idea to change passwords when something like this occurs and it is never a bad practice to change passwords on a recurring basis. In other words, we recommend you change your passwords as a precaution. We do not store any Credit Card information or sensitive user information on either of our web properties, so even if there was in fact a leak, all they would get are passwords.
There were many other websites that you probably visit that sit behind Cloudflare, so we encourage you to please take a look at this list to see if there was a chance any other sites you have accounts on were possibly compromised. If so we advise you replace your passwords there as well just to be safe.
04/07/2014
Description
On April 7th of 2014 we were informed of the vulnerability dubbed Heartbleed (CVE-2014-0160), within one of the Internet’s most significant security libraries (OpenSSL). A great number of services across the internet that use this library, including OpenVPN Access Server, may have been affected by this issue. Since learning of this issue, we have taken immediate necessary steps to ensure the security of OpenVPN and the OpenVPN Access Server product. Within 24 hours we have therefore released patches for specific versions of the Access Server that are affected, and we have released Access Server 2.0.6 with the fix for this issue already incorporated. If you are using an older version that contains the affected OpenSSL library you are advised to update immediately.
The affected versions of Access Server that contain the vulnerable OpenSSL library and are vulnerable to Heartbleed are:
- OpenVPN Access Server 1.8.4 and 1.8.5
- OpenVPN Access Server 2.0.0 / 2.0.1 / 2.0.2 / 2.0.3 / 2.0.4 and 2.0.5
The attack vector that is present on the Access Server with the vulnerable OpenSSL libraries is not present on the Connect Clients, so the risk on the client side is negligible. Only the server that your client connects to could possibly exploit this vulnerability, and even then it is unlikely because we use Perfect Forward Security and TLS-auth on top of the SSL connection which prevents this exploit from being successful. The security of the data channel itself is not particularly at risk, only the web services on the server themselves are. And even then, since we use a privilege separation model, the web services run in a completely different process than the OpenVPN daemons handling the data connections, and therefore the private keys for your OpenVPN connections are not likely to be at any risk. Even so, we did not take chances and have released a fix in OpenVPN Access Server 2.0.7 and newer versions, which incorporate updated clients as well. So update your clients as well.
Resolution
If you have a version other than the aforementioned versions, you are not vulnerable to the Heartbleed vulnerability, but of course we always recommend to keep your system up-to-date. If you are running one of the mentioned versions, we recommend that you upgrade to the latest version available from our website immediately.
The OpenVPN Connect Client for Windows and macOS should also be updated, and you can do so by updating your OpenVPN Access Server first, and then downloading a new and updated copy of the OpenVPN Connect Client from your updated Access Server.
Note that mobile clients like on iPad, iPhone and Android devices, are not affected as they use PolarSSL instead, so no action needs to be taken there.
04/10/2013
Description
The OpenVPN Desktop Client is not receiving maintenance anymore, and has been deprecated for a while. All OpenVPN Access Server customers still using the OpenVPN Desktop Client for Windows should upgrade immediately to the OpenVPN Connect Client that comes bundled with our latest OpenVPN Access Server product. The OpenVPN Desktop Client is obsolete and is no longer maintained or available for download. This client contains a CSRF (Cross Site Request Forgery) vulnerability that can allow remote code execution by a malicious web site, as Stefan Viehböck, SEC Consult, has discovered. The OpenVPN Desktop Client also contains an older version of OpenSSL that has not received recent OpenSSL security updates. This advisory only applies to the OpenVPN Desktop Client app for Windows, and does not affect OpenVPN Connect Client, Private Tunnel, or OpenVPN open source builds for Windows.
Resolution
We still see some users with this program actively in use. We strongly advise these users to switch to the newer client program titled OpenVPN Connect Client or an up-to-date OpenVPN open source alternative. We advise that you always try to use the latest version of the server and client software where possible.