VNS3 Security Responses

Cohesive Networks LLC has never received a National Security Letter, FISA order, or any other classified request for user information.

Open Management Infrastructure Remote Code Execution Vulnerability [12 Sept 2021] – CVE-2021-38647

Recent Azure “OMI” agent vulnerability does NOT affect Cohesive VNS3 Platform.

*NO ACTION REQUIRED*

A recently discovered exploit allows unauthenticated remote code execution on servers (including Azure virtual machines) using the Azure OMI agent. Cohesive builds the VNS3 platform on top of a hardened Ubuntu Linux base. In order to be allowed in the Azure Marketplace we are required to run the “Azure Waagent” but do not install any other Microsoft software.

Cohesive has reviewed build logs and images confirming the agent is not present in any of our Azure releases.

The OMI agent uses tcp ports: 5986/5985/1270
VNS3 Platform users can easily confirm these ports are not in use using the Network Sniffer functionality in VNS3.

CVE-2021-38647 – https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-38647
Microsoft Response – https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-38647
3rd party interpretation – https://arstechnica.com/information-technology/2021/09/security-researchers-at-wiz-discover-another-major-azure-vulnerability/

Vulnerable VNS3 versions: NONE

 

VNS3 Vulnerability [7 Aug 2020] – CVE-2020-15467

The vulnerability allows an AUTHENTICATED administrator to gain access to the VNS3 host operating system.  This vulnerability was discovered by researchers at Fireeye/Mandiant.  It is applicable to all VNS3 4.x versions prior to 4.11.1.

*NO IMMEDIATE ACTION REQUIRED FOR MOST USE CASES*

The authenticated user has complete control of the VNS3 device.  They can reboot it, halt it, use the firewall to coerce, change, inspect or even redistribute traffic – as VNS3 is a network device for those very purposes.   Some network device providers provide shell access to their devices – something Cohesive does not do – as we believe VNS3 being a sealed appliance ensures consistency and integrity of performance.  Through our plugin system and customer controlled plugins we allow many of the capabilities of host access – with reduced risk of an improper change to the VNS3 appliance. 

CVE-2020-15467 – https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15467

Vulnerable VNS3 versions: 4.0 to 4.9.2

REMEDIATION and PREVENTION:

  • Upgrade to VNS3 4.11.1 which has been fixed for this vulnerability (as well as attempts at similar exploits both in Cohesive code and underlying library code).
  • Contact Cohesive to patch in-place VNS3 appliances via remote support operation.  Customers with 24×7 support contracts will be given priority.
  • Use VNS3 Administrator sign-on controls in VNS3 4.9.2+.   One of the feature areas we have focused on in the last several releases is Administrator login and logging.  VNS3 appliances can now be pointed at an LDAP directory, Active Directory or Google Gsuite account for authentication of its Administrators, with that information also captured in internal logging as Administrators take actions.   This can certainly provide insight into the actions and behaviors of your VNS3 Administrators.


While this does represent a vulnerability, the attack vectors for VNS3 deployments are limited if at all present. Vulnerabilities of any kind can be controlled by implementing a layered/defense in depth security approach as defined below.

  • When possible use cloud VLANs like those available in AWS VPC, Azure, Google Compute, and others.
  • Use network ACLs and Hypervisor Port Filtering (like AWS Security Groups)
  • Ideally a VNS3 Manager should only have the following port assignments:
    • TCP Port 8000 open to only your operations center and as needed to Cohesive Networks’ support address
    • TCP 22 only open as needed to Cohesive Networks’ support address
    • UDP 500 only open to specific partner IPsec endpoints for IKE/Phase1 connectivity
    • ESP/Protocol 50 only open to a specific partners IPsec endpoint address when using native IPsec
    • UDP 4500 only open to specific partner’s IPsec endpoint address when using encapsulated (NAT-T) IPsec
    • UDP 1195-1202 only open as documented to other VNS3 managers in a topology.
    • UDP 1194 only open to VNS3 clients IP addresses or subnet masks as required.
    • UDP SNMP port only open to your operational system making SNMP polling requests.
  • To further secure your topologies we recommend using the VNS3 Network Firewall as well as host filtering on your cloud servers.
This has been patched in the latest 4.11.1 release available in cloud marketplaces and via private AMI permissions.

 

Libreswan Security Advisory [11 May 2020] – CVE-2020-1763

The Libreswan project has published information about a recently patched vulnerability that can allow a denial of service attack (CVE-2020-1763). No remote code execution is possible via this attack, the vulnerability could allow an external third party to crash the VNS3 IPsec subsystem by sending repeated malformed IKEv1 packets on UDP 500.

*NO IMMEDIATE ACTION REQUIRED FOR MOST USE CASES*

CVE-2020-1763 – https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-1763

Vulnerable VNS3 versions: 4.4.0 to 4.9.1
Not Vulnerable: 4.3.11 and earlier & 4.9.2 and later

REMEDIATION and PREVENTION:
Limiting UDP 500 and UDP 4500/ESP protocol 50 inbound access to the VNS3 controller instance from only those remote addresses needed for the IPsec VPN connections eliminates exposure to this vulnerability. Use the VNS3 firewall, cloud hypervisor firewall (e.g. Security Group) and/or cloud ACL to prevent exposure.

While the potential denial of service does represent a vulnerability, the attack vectors for VNS3 deployments are limited if at all present. Vulnerabilities of any kind can be controlled by implementing a layered/defense in depth security approach as defined below.

  • When possible use cloud VLANs like those available in AWS VPC, Azure, Google Compute, and others.
  • Use network ACLs and Hypervisor Port Filtering (like AWS Security Groups)
  • Ideally a VNS3 Manager should only have the following port assignments:
    • TCP Port 8000 open to only your operations center and as needed to Cohesive Networks’ support address
    • TCP 22 only open as needed to Cohesive Networks’ support address
    • UDP 500 only open to specific partner IPsec endpoints for IKE/Phase1 connectivity
    • ESP/Protocol 50 only open to a specific partners IPsec endpoint address when using native IPsec
    • UDP 4500 only open to specific partner’s IPsec endpoint address when using encapsulated (NAT-T) IPsec
    • UDP 1195-1202 only open as documented to other VNS3 managers in a topology.
    • UDP 1194 only open to VNS3 clients IP addresses or subnet masks as required.
    • UDP SNMP port only open to your operational system making SNMP polling requests.
  • To further secure your topologies we recommend using the VNS3 Network Firewall as well as host filtering on your cloud servers.
This has been patched in the latest 4.9.2 release available in cloud marketplaces and via private AMI permissions.
Sad SACK [June 20 2019]:
CVE-2019-11477 for a remote denial of service (system crash) 
CVE-2019-11478 for a remote denial of service (resource exhaustion)
CVE-2019-11479 for a remote denial of service (resource exhaustion)
 
Several flaws in the way that the Linux kernel’s TCP implementation processes Selective Acknowledgement (SACK) options and handles low Maximum Segment Size (MSS) values. A remote attacker could use these issues to perform denial of service attacks on a server.
 
*NO IMMEDIATE ACTION REQUIRED FOR MOST USE CASES*
 
The vulnerability requires access to open TCP ports on a device. In a sealed appliance like VNS3, no user has access by design and no malware is included via our strict build controls and there is no path/mechanism for malware to be installed when deployed following best practices.
 
Some use-cases use VNS3 as a Proxy Server facing the Internet via a TCP port like 80 or 443. In that case if that access is via the open Internet then we recommend customers contacting Cohesive Networks for an update cloud image or for patches via remote support access.
 
 
 
PREVENTION:
VNS3 appliances by design are mostly not susceptible to this attack. Following best practices for deployment ensure VNS3 controllers are safe from exploit.
 
Limit remote inbound access to the VNS3 controller instance via VNS3 Remote Support mechanism (multi-party/multi-factor authentication), VNS3 Firewall, and cloud hypervisor firewall cloud hypervisor firewall (e.g. Security Group) and/or cloud ACL to prevent exposure.
 
As usual, vulnerabilities of any kind can be controlled by implementing a layered/defense in depth security approach as defined below.
 
  • When possible use cloud VLANs like those available in AWS VPC, Azure, Google Compute, and others.
  • Use network ACLs and Hypervisor Port Filtering (like AWS Security Groups)
  • Ideally a VNS3 Manager should only have the following port assignments:
    • TCP Port 8000 open to only your operations center and as needed to Cohesive Networks’ support address
    • TCP 22 only open as needed to Cohesive Networks’ support address
    • UDP 500 only open to specific partner IPsec endpoints for IKE/Phase1 connectivity
    • ESP/Protocol 50 only open to a specific partners IPsec endpoint address when using native IPsec
    • UDP 4500 only open to specific partner’s IPsec endpoint address when using encapsulated (NAT-T) IPsec
    • UDP 1195-1202 only open as documented to other VNS3 managers in a topology.
    • UDP 1194 only open to VNS3 clients IP addresses or subnet masks as required.
    • UDP SNMP port only open to your operational system making SNMP polling requests.
  • To further secure your topologies we recommend using the VNS3 Network Firewall as well as host filtering on your cloud servers.
Cohesive Networks will provide updated Images with the OS vendor provided patches when available.
CVE-2018-3639 – Meltdown-Spectre Variant 4 [22 May 2018]
*NO IMMEDIATE ACTION REQUIRED*
 
The vulnerability requires an authenticated local attacker and malware to be running on the VNS3 controller. In a sealed appliance like VNS3, no user has access by design and no malware is included via our strict build controls and there is no path/mechanism for malware to be installed when deployed following best practices.
 
 
 
PREVENTION:
VNS3 appliances by design are not susceptible to this attack. Following best practices for deployment ensure VNS3 controllers are safe from exploit.
 
Limit remote inbound access to the VNS3 controller instance via VNS3 Remote Support mechanism (multi-party/multi-factor authentication), VNS3 Firewall, and cloud hypervisor firewall cloud hypervisor firewall (e.g. Security Group) and/or cloud ACL to prevent exposure.
 
As usual, vulnerabilities of any kind can be controlled by implementing a layered/defense in depth security approach as defined below.
 
  • When possible use cloud VLANs like those available in AWS VPC, Azure, Google Compute, and others.
  • Use network ACLs and Hypervisor Port Filtering (like AWS Security Groups)
  • Ideally a VNS3 Manager should only have the following port assignments:
    • TCP Port 8000 open to only your operations center and as needed to Cohesive Networks’ support address
    • TCP 22 only open as needed to Cohesive Networks’ support address
    • UDP 500 only open to specific partner IPsec endpoints for IKE/Phase1 connectivity
    • ESP/Protocol 50 only open to a specific partners IPsec endpoint address when using native IPsec
    • UDP 4500 only open to specific partner’s IPsec endpoint address when using encapsulated (NAT-T) IPsec
    • UDP 1195-1202 only open as documented to other VNS3 managers in a topology.
    • UDP 1194 only open to VNS3 clients IP addresses or subnet masks as required.
    • UDP SNMP port only open to your operational system making SNMP polling requests.
  • To further secure your topologies we recommend using the VNS3 Network Firewall as well as host filtering on your cloud servers.
Cohesive Networks will provide updated Images with the OS vendor provided patches when available.
CVE-2018-8897 – MOV SS and POP SS Mistake Allows Privilege Escalation [10 May 2018]
*NO IMMEDIATE ACTION REQUIRED*
 
The vulnerability requires an authenticated local attacker that can then escalate privileges to read data in kernel memory and control operating system functions. In a sealed appliance like VNS3, no user has access by design.
 
 
 
Relevant VNS3 versions: Spectre/Meltdown patched VNS3 versions (4.3.6 and later)
 
PREVENTION:
VNS3 appliances by design are not susceptible to this attack. Following best practices for deployment ensure VNS3 controllers are safe from exploit.
 
Limit remote inbound access to the VNS3 controller instance via VNS3 Remote Support mechanism (multi-party/multi-factor authentication), VNS3 Firewall, and cloud hypervisor firewall cloud hypervisor firewall (e.g. Security Group) and/or cloud ACL to prevent exposure.
 
As usual, vulnerabilities of any kind can be controlled by implementing a layered/defense in depth security approach as defined below.
 
  • When possible use cloud VLANs like those available in AWS VPC, Azure, Google Compute, and others.
  • Use network ACLs and Hypervisor Port Filtering (like AWS Security Groups)
  • Ideally a VNS3 Manager should only have the following port assignments:
    • TCP Port 8000 open to only your operations center and as needed to Cohesive Networks’ support address
    • TCP 22 only open as needed to Cohesive Networks’ support address
    • UDP 500 only open to specific partner IPsec endpoints for IKE/Phase1 connectivity
    • ESP/Protocol 50 only open to a specific partners IPsec endpoint address when using native IPsec
    • UDP 4500 only open to specific partner’s IPsec endpoint address when using encapsulated (NAT-T) IPsec
    • UDP 1195-1202 only open as documented to other VNS3 managers in a topology.
    • UDP 1194 only open to VNS3 clients IP addresses or subnet masks as required.
    • UDP SNMP port only open to your operational system making SNMP polling requests.
  • To further secure your topologies we recommend using the VNS3 Network Firewall as well as host filtering on your cloud servers.
Cohesive Networks will provide updated Images with the OS vendor provided patches when available.
Meltdown and Spectre Vulnerabilities [1 Jan 2018]
Timeline
1/2/18 – Meldown and Spectre architecture flaws made public by Google Project Zero researchers John Horn, plus Werner Haas and Thomas Prescer from Cyberus Technology; Daniel Gruss, Moritz Lipp, Stefan Mangard and Michael Schwarz from Graz University of Technology.
1/4/18 – Cohesive Networks sends administration email to customers and users detailing the flaw, providing alerts about potential cloud instance reboots (as cloud providers patch their infrastructure), and providing information about the low probability of attach due to VNS3 network device architecture and deployment best practices.
1/10/18 – Cohesive Networks sends administration email to customers and users providing updates on OS vendor Meltdown and Spectre patches.
1/30/18 – Cohesive Networks sends administration email to customers and users notifying about availability of final Meltdown and Spectre patches from the OS vendor and the beginning of patched VNS3 version testing.
2/21/18 – Cohesive Networks sends administration email to customers and users that includes the final patched VNS3 version 4.3.6 that includes fixes for Meltdown and Spector.
Meltdown and Spectre vulnerabilities exploit a design flaw in modern processors that allow Kernel-memory-leaking potentially giving normal programs access to protected kernel memory which could include sensitive data like passwords.
 
Spectre and Meltdown Project Page – https://spectreattack.com/
 
 
Vulnerable VNS3 versions: All VNS3 versions to 4.3.5
Not Vulnerable: 4.3.6 and later
 
REMEDIATION and PREVENTION:
Limit remote inbound access to the VNS3 controller instance via VNS3 Remote Support mechanism (multi-party/multi-factor authentication), VNS3 Firewall, and cloud hypervisor firewall cloud hypervisor firewall (e.g. Security Group) and/or cloud ACL to prevent exposure.
 
While the potential potential access exploit does represent a vulnerability, the attack vectors for VNS3 deployments are limited if at all present. Vulnerabilities of any kind can be controlled by implementing a layered/defense in depth security approach as defined below.
 
  • When possible use cloud VLANs like those available in AWS VPC, Azure, Google Compute, and others.
  • Use network ACLs and Hypervisor Port Filtering (like AWS Security Groups)
  • Ideally a VNS3 Manager should only have the following port assignments:
    • TCP Port 8000 open to only your operations center and as needed to Cohesive Networks’ support address
    • TCP 22 only open as needed to Cohesive Networks’ support address
    • UDP 500 only open to specific partner IPsec endpoints for IKE/Phase1 connectivity
    • ESP/Protocol 50 only open to a specific partners IPsec endpoint address when using native IPsec
    • UDP 4500 only open to specific partner’s IPsec endpoint address when using encapsulated (NAT-T) IPsec
    • UDP 1195-1202 only open as documented to other VNS3 managers in a topology.
    • UDP 1194 only open to VNS3 clients IP addresses or subnet masks as required.
    • UDP SNMP port only open to your operational system making SNMP polling requests.
  • To further secure your topologies we recommend using the VNS3 Network Firewall as well as host filtering on your cloud servers.
Cohesive Networks released VNS3 4.3.6 which included Meltdown and Spectre patches from our OS vendor.
DNSMASQ Vulnerabilities [2 Oct 2017]
There are six issues discovered with the dnsmasq package (CVE-2017-14491, CVE-2017-14492, CVE-2017-14493, CVE-2017-14494, CVE-2017-14495, and CVE-2017-14496). The potential dnsmasq vulnerabilities result from how the package incorrectly handles DNS requests, IPv6 router advertisements, and DHCPv6 requests. These issues could be used to remotely cause dnsmasq to crash, resulting in a denial of service, or possibly execute arbitrary code.
 
Vulnerable VNS3 versions: NONE
 
The package is included in VNS3 version 3.5.x images as a build dependency (Docker which is used for the Network Security Plugin System) but the process that is exploitable is not running or available so no vulnerability exists.
 
Cohesive Networks will release a new VNS3 version 3.5.3 with a build date of 20171012 where we explicitly remove the unused dnsmasq package.
 
OpenSSL: Malformed X.509 IPAddressFamily could cause OOB read [28 Aug 2017]
The potential OpenSSL vulnerability (CVE-2017-3735) could allow a one-byte buffer overread when an X.509 certificate has a malformed IPAddressFamily extension. OpenSSL reports the most likely result would be an erroneous display of the certificate in text format. The vulnerability is being listed as low severity and no OpenSSL release is being made.
 
 
Vulnerable VNS3 version: 3.5 LTS and 4.x
 
REMEDIATION and PREVENTION:
 
While the potential access exploit does represent a vulnerability, the attack vectors for VNS3 deployments requires a bad actor to have a clientpack credential. As a result there is no exposure when following clientpack best practices defined below:
  • Clientpack credentials should only be distributed known and trusted devices.
  • Any unused clientpack credentials should be disabled via UI or API to prevent unauthorized use.
  • Clientpacks credentials should be regenerated when a device that was using that credentials is deprovisioned.
Because this threat can be prevented with proper clientpack lifecycle management, a fix will be incorporated into future VNS3 versions.
Kernel Local Privilege Escalation “Dirty COW” [19 Oct 2016]
Dirty COW (CVE-2016-5195) is a privilege escalation vulnerability in the Linux Kernel It has been discovered that a race condition exists in the memory manager of the Linux kernel that can allow an unprivileged local user to gain write access to read-only memory mappings. With this access vulnerability, an attacker with a local system account can modify on-disk binaries to gain administrative privileges.
 
Dirty Cow Project Page – https://dirtycow.ninja/#
 
 
Vulnerable VNS3 version: all 3.x and 4.x
 
REMEDIATION and PREVENTION:
Limit remote inbound access to the VNS3 controller instance via VNS3 Remote Support mechanism (multi-party/multi-factor authentication), VNS3 Firewall, and cloud hypervisor firewall cloud hypervisor firewall (e.g. Security Group) and/or cloud ACL to prevent exposure.
 
While the potential potential access exploit does represent a vulnerability, the attack vectors for VNS3 deployments are limited if at all present. Vulnerabilities of any kind can be controlled by implementing a layered/defense in depth security approach as defined below.
 
  • When possible use cloud VLANs like those available in AWS VPC, Azure, Google Compute, and others.
  • Use network ACLs and Hypervisor Port Filtering (like AWS Security Groups)
  • Ideally a VNS3 Manager should only have the following port assignments:
    • TCP Port 8000 open to only your operations center and as needed to Cohesive Networks’ support address
    • TCP 22 only open as needed to Cohesive Networks’ support address
    • UDP 500 only open to specific partner IPsec endpoints for IKE/Phase1 connectivity
    • ESP/Protocol 50 only open to a specific partners IPsec endpoint address when using native IPsec
    • UDP 4500 only open to specific partner’s IPsec endpoint address when using encapsulated (NAT-T) IPsec
    • UDP 1195-1202 only open as documented to other VNS3 managers in a topology.
    • UDP 1194 only open to VNS3 clients IP addresses or subnet masks as required.
    • UDP SNMP port only open to your operational system making SNMP polling requests.
  • To further secure your topologies we recommend using the VNS3 Network Firewall as well as host filtering on your cloud servers.
Because this threat can be managed with proper cloud ACL settings or VNS3 Firewall rules, the fix will be incorporated into a new 3.5.3 LTS release and our 4.x releases in future.
libreswan Security Advisory [10 Jun 2016]
The Libresawn project has published information about a recently patched vulnerability that can allow a denial of service attack called IKEv2 aes_xcbc transform causes restart of IKE daemon (CVE-2016-3071). No remote code execution is possible via this attack, the vulnerability could allow an external third party to trigger restarts of Libreswan.
 
 
Vulnerable VNS3 version: 3.5.1.14
Not Vulnerable: 3.5.1.13 and earlier
 
REMEDIATION and PREVENTION:
Limiting UDP 500 and UDP 4500/ESP protocol 50 inbound access to the VNS3 controller instance from only those remote addresses needed for the IPsec VPN connections eliminates exposure to this vulnerability. Use the VNS3 firewall, cloud hypervisor firewall (e.g. Security Group) and/or cloud ACL to prevent exposure.
 
While the potential denial of service does represent a vulnerability, the attack vectors for VNS3 deployments are limited if at all present. Vulnerabilities of any kind can be controlled by implementing a layered/defense in depth security approach as defined below.
 
  • When possible use cloud VLANs like those available in AWS VPC, Azure, Google Compute, and others.
  • Use network ACLs and Hypervisor Port Filtering (like AWS Security Groups)
  • Ideally a VNS3 Manager should only have the following port assignments:
    • TCP Port 8000 open to only your operations center and as needed to Cohesive Networks’ support address
    • TCP 22 only open as needed to Cohesive Networks’ support address
    • UDP 500 only open to specific partner IPsec endpoints for IKE/Phase1 connectivity
    • ESP/Protocol 50 only open to a specific partners IPsec endpoint address when using native IPsec
    • UDP 4500 only open to specific partner’s IPsec endpoint address when using encapsulated (NAT-T) IPsec
    • UDP 1195-1202 only open as documented to other VNS3 managers in a topology.
    • UDP 1194 only open to VNS3 clients IP addresses or subnet masks as required.
    • UDP SNMP port only open to your operational system making SNMP polling requests.
  •  To further secure your topologies we recommend using the VNS3 Network Firewall as well as host filtering on your cloud servers.
Because this threat can be managed with proper cloud ACL settings or VNS3 Firewall rules, the fix will be incorporated into a new 3.5.1.X release and our 4.0 release in future.
OpenSSL Security Advisory [3rd May 2016]
The OpenSSL project has published information about some recently patched vulnerabilities, two of which are labeled as high severity: Memory corruption in the ASN.1 encoder (CVE-2016-2108) and Padding oracle in AES-NI CBC MAC check (CVE-2016-2107).
 
 
 
While OpenSSL lables the vulnerabilities as “high” severity, the attack vectors for VNS3 deployments are limited if at all present. Vulnerabilities of any kind can be controlled by implementing a layered/defense in depth security approach as defined below.
 
  • When possible use cloud VLANs like those available in AWS VPC, Azure, Google Compute, and others.
  • Use network ACLs and Hypervisor Port Filtering (like AWS Security Groups)
  • Ideally a VNS3 Manager should only have the following port assignments:
    • TCP Port 8000 open to only your operations center and as needed to Cohesive Networks’ support address
    • TCP 22 only open as needed to Cohesive Networks’ support address
    • UDP 500 only open to specific partner IPsec endpoints for IKE/Phase1 connectivity
    • ESP/Protocol 50 only open to a specific partners IPsec endpoint address when using native IPsec
    • UDP 4500 only open to specific partner’s IPsec endpoint address when using encapsulted (NAT-T) IPsec
    • UDP 1195-1202 only open as documented to other VNS3 managers in a topology.
    • UDP 1194 only open to VNS3 clients IP addresses or subnet masks as required.
    • UDP SNMP port only open to your operational system making SNMP polling requests.
  • To further secure your topologies we recommend using the VNS3 Network Firewall as well as host filtering on your cloud servers.
Cohesive Networks will make a patched AMI available or will provide a patch to running VNS3 controller instances by request. The patch will require Cohesive Networks to access your VNS3 instance(s) via Remote Support, patch the openssl libraries, and reboot the VNS3 instance. As a result a short operational window will be required.
OpenSSL Security Advisory [9 Jul 2015]
Alternative chains certificate forgery (CVE-2015-1793) – https://www.openssl.org/news/secadv_20150709.txt
 
The OpenSSL project has published information about a vulnerability (CVE-2015-1793) affecting openssl versions 1.0.1n, 1.0.1o, 1.0.2b, and 1.0.2c.
 
 
These openssl versions have only been available since June 2015 and this functionality is not in any version of the VNS3 product line – VNS3, VNS3:ms, and VNS3:ha (alpha).
 
No Cohesive Networks products are affected by this flaw (CVE-2015-1793). No actions are required to fix or mitigate this issue.
glibc gethostbyname buffer overflow “GHOST Vulnerability” [27 January 2015]
Qualys Security Advisory CVE-2015-0235 – http://www.openwall.com/lists/oss-security/2015/01/27/9
 
Qualys researchers have found a vulnerability in the Linux GNU C Library (glibc) that can allow access to a system in specific scenarios. Attack vectors are theoretically possible – standard VNS3 deployment best practices do not allow for such attacks.
 
Access to TCP port 8000 (API/GUI) should only be available to your cloud hosts, and/or your operation center. Access to TCP port 22 should never be available via your cloud environment’s hypervisor firewall rules other than when explicitly enabled for a remote support event. Additionally TCP port 22 is controlled by the VNS3 Remote Support multi-factor/multi-party authentication system that is disabled by default on all VNS3 instances.
 
Vulnerabilities of any kind can be controlled by implementing a layered/defense in depth security approach as defined below.
 
  • When possible use cloud VLANs like those available in AWS VPC, Azure, Google Compute, and others.
  • Use network ACLs and Hypervisor Port Filtering (like AWS Security Groups)
  •  Ideally a VNS3 Manager should only have the following port assignments:
    • TCP Port 8000 open to only your operations center and as needed to Cohesive Networks’ support address
    • TCP 22 only open as needed to Cohesive Networks’ support address
    • UDP 500 only open to specific partner IPsec endpoints for IKE/Phase1 connectivity
    •  ESP/Protocol 50 only open to a specific partners IPsec endpoint address when using native IPsec
    •  UDP 4500 only open to specific partner’s IPsec endpoint address when using encapsulted (NAT-T) IPsec
    • UDP 1195-1202 only open as documented to other VNS3 managers in a topology.
    • UDP 1194 only open to VNS3 clients IP addresses or subnet masks as required.
    • UDP SNMP port only open to your operational system making SNMP polling requests.
  • To further secure your topologies we recommend using the VNS3 Network Firewall as well as host filtering on your cloud servers.
If you have any questions or would like Cohesive Networks Support to patch your running VNS3 instances, please contact us. The patch will require Cohesive Networks to access your VNS3 instance(s) via Remote Support, patch the glibc package, and reboot the VNS3 instance. As a result a short operational window will be required.
 
NOTE: A new point release of VNS3 3.5 is imminent and will include the patch. Images will be available to customers early the week of February 2nd.
OpenVPN DoS Vulnerability [3 December 2014]
The OpenVPN denial of service vulnerability (CVE-2014-8104) does not warrant an emergency patch. The next release of VNS3 will include a fix. If you have any additional questions please don’t hesitate to contact us.
POODLE SSL 3.0 Vulnerability [15 October 2014]
Google researchers have found a flaw in SSL 3.0 (CVE-2014-3566) that allows the POODLE attack (Padding Oracle On Downgraded Legacy Encryption).
 
SSL 3.0 Exploit Paper – https://www.openssl.org/~bodo/ssl-poodle.pdf
 
Register – http://www.theregister.co.uk/2014/10/14/google_drops_ssl_30_poodle_vulnerability/
 
All versions of the VNS3 (and older VPN3) UI does issue a session cookie but it is not associated with authentication. Thus in the event of a successful POODLE exploit, the attacker would not be able to get information to log into the VNS3 Manager’s UI.
 
Looking at the data that can be exploited there is no reason for patches or new VNS3 AMI builds. This is a client vulnerability, not a server vulnerability. Regardless in upcoming releases we will disable SSL 3.0 on the server side to ensure we deliver the highest quality product possible.
 
Our best practice recommendations are below:
 
If you have any additional questions please don’t hesitate to contact us.
Shellshock Bug [26 September 2014]
Updated Patches for Bash Command Interface Vulnerability (CVE-2014-7169). Our OS provider has updated patches for the Shellshock bug affecting Linux and Unix. VNS3 supported versions 2.7, 3.0, 3.01, 3.03, 3.04, and 3.5 are potentially affected.
 
  • For those of you operating in AWS, new AMIs have been built, deployed and shared with your accounts. Updated AMIs are listed below. Customer using and licensed for 2.x-3.0x use the following AMIs:
RegionAMI ID
US-East-1ami-8876c2e0
US-West-1ami-038d8546
US-West-2ami-f5db98c5
EU-West-1,ami-aa9435dd
AP-Southeast-1ami-ae496efc
AP-Southeast-2ami-a1dbb89b
AP-Northeast-1ami-7f9fb67e
SA-East-1ami-a918b2b4
Gov Cloudami-8d2640ae
  • Customers using and licensed for 3.5x use the following AMIs (Note: only EBS-backed Images if you have previously received and agreed to the EBS Disclosure and Agreement):
RegionAMI ID (Instance Store)AMI ID (EBS)
US-East-1ami-5a54e032ami-8071c5e8
US-West-1ami-39848c7cami-f78e86b2
US-West-2ami-bde7a48dami-5fda996f
EU-West-1ami-3e9e3f49ami-2e963759
AP-Southeast-1ami-ae5473fcami-be486fec
AP-Southeast-2ami-4dd8bb77ami-37dab90d
AP-Northeast-1ami-2d7f572cami-8f93ba8e
SA-East-1ami-a91cb6b4ami-b919b3a4
Gov Cloudami-f72640d4ami-b919b3a4
We are available to live patch running Manager instances. Please send a message to our support team (support AT cohesive DOT net) to receive instructions on providing access via our multi-factor/multi-party remote support authentication system. The live patch takes less than a minute to apply but requires our involvement.
 
If you have any additional questions please don’t hesitate to contact us.
Shellshock Bug [24 September 2014]
Bash Command Interface Vulnerability (CVE-2014-6271) VNS3 supported versions 2.7, 3.0, 3.01, 3.03, 3.04, and 3.5 are potentially affected by the Bash command interpreter bug being labeled the “shellshock” bug (CVE-2014-6271).
While attacks on VNS3 instances are theoretically possible – the standard VNS3 deployment practices do not make such attacks likely. Access to TCP port 8000 should only be available to your cloud hosts, and/or your operation center. Access to TCP Port 22 should never be available other than when explicitly enabled for a remote support event. Additionally assuming access for potential attackers, they would still need a working credential to access either the VNS3 UI/API (UI doesn’t use cgi scripts) or ssh (one-time, unique key, controlled by you the customer). Regardless of this limited attack vector, we are still making new VNS3 images available for all supported cloud environments.
  • For those of you operating in AWS, new AMIs have been built, deployed and shared with your accounts. Updated AMIs are listed below. Customer using and licensed for 2.x-3.0x use the following AMIs:
RegionAMI ID
US-East-1ami-c66cd9ae
US-West-1ami-cbdcd48e
US-West-2ami-938ecda3
EU-West-1,ami-c4e948b3
AP-Southeast-1ami-c06d4a92
AP-Southeast-2ami-7bf49741
AP-Northeast-1ami-251f3624
SA-East-1ami-6b0aa076
  • Customers using and licensed for 3.5x use the following AMIs (Note: only EBS-backed Images if you have previously received and agreed to the EBS Disclosure and Agreement):
RegionAMI ID (Instance Store)AMI ID (EBS)
US-East-1ami-664df80eami-1c7bce74
US-West-1ami-2fd2da6aami-a3ddd5e6
US-West-2ami-8996d5b9ami-058dce35
EU-West-1ami-9cf253ebami-66ed4c11
AP-Southeast-1ami-766a4d24ami-546d4a06
AP-Southeast-2ami-7ff89b45ami-4df49777
AP-Northeast-1ami-93e9c092ami-3b1e373a
SA-East-1ami-2308a23eami-f10aa0ec
For other clouds where our images are listed in the public catalog, new images are delivered or being delivered to those catalogs.
If you operate in a cloud that does not have a Partner Image directory or Public catalog where an image has been built for you (e.g. Dimension Data, Azure, Google GCE ), we will contact you directly to deliver an updated VNS3 image.
LZO Security Advisory [30 June 2014]
Multiple Memory Corruption Vulnerabilities (CVE-2014-4607) Media outlets are reporting a 20 year old vulnerability to the LZO compression libraries used by the Linux Kernel and OpenVPN. Both OpenVPN and LZO home represent this as media hype as no current systems (including VNS3 deployments) are affected. The vulnerability requires decompression of 16MB of untrusted compressed bytes. VNS3 and OpenVPN use UDP which makes the exploitation impossible as UDP has a maximum packet size of 65,507 bytes.
OpenSSL Security Advisory [05 June 2014]
SSL/TLS MITM vulnerability (CVE-2014-0224) NOTE FOR AWS USERS: As a result of the following Security Advisory, new VNS3 version 3.04 AMIs have been built. Launch permissions have been transferred from the old 3.04 AMIs to the new 3.04 AMIs. If you have any questions feel free to contact our support team. Immediately after the DTLS discovery source code review showed another potential vulnerability where a man-in-the-middle exploit is possible. Review showed that this exploit has existed in all versions of OpenSSL. Most usage profiles of VNS3 or VPN3 do not lend themselves to this type of attack being practicable although it does have a theoretical possibility. Is there a way that the risk of these exploits, and in fact any code exploit can me minimized in my cloud deployments? Yes, following best practices for cloud deployment of VNS3 Managers and VNS3 clients will in most cases prevent these types of exploits from being practicable from outside your network. When deploying VNS3 we recommend using cloud computing’s built in capability for a “defense in depth” approach. VNS3 uses OpenSSL in multiple ways, with the primary use being within OpenVPN as part of in-band overlay networking, which is largely unaffected by any of these vulnerabilities. The other use is as part of the web UI and API services of VNS3 for HTTPS support, which is where the attacks can come into play if a layered security model isn’t being deployed.
 
  • When possible use cloud VLANs like those available in AWS VPC, Azure, Google Compute, and others.
  • Use network ACLs and Hypervisor Port Filtering (like AWS Security Groups)
  •  Ideally a VNS3 Manager should only have the following port assignments:
    • TCP Port 8000 open to only your operations center and as needed to Cohesive Networks’ support address
    • TCP 22 only open as needed to Cohesive Networks’ support address
    • UDP 500 only open to specific partner IPsec endpoints for IKE/Phase1 connectivity
    •  ESP/Protocol 50 only open to a specific partners IPsec endpoint address when using native IPsec
    •  UDP 4500 only open to specific partner’s IPsec endpoint address when using encapsulted (NAT-T) IPsec
    • UDP 1195-1202 only open as documented to other VNS3 managers in a topology.
    • UDP 1194 only open to VNS3 clients IP addresses or subnet masks as required.
    • UDP SNMP port only open to your operational system making SNMP polling requests.
  • To further secure your topologies we recommend using the VNS3 Network Firewall as well as host filtering on your cloud servers.
OpenSSL Security Advisory [05 Jun 2014]
DTLS recursion flaw (CVE-2014-0221) VNS3 deployments are not impacted by the DTLS recursion flaw (CVE-2014-0221). The exploit involves using OpenSSL as a DTLS client. OpenVPN client does not do this.
OpenSSL Security Advisory [07 Apr 2014]
TLS heartbeat read overrun (CVE-2014-0160) VNS3 supported versions 2.7, 3.0, 3.01, 3.03, and 3.04 are NOT affected by the OpenSSL TLS heartbeat read overrun (CVE-2014-0160).
VNS3 does take advantage of open source software for use as underlying components of the complete enterprise-grade cloud network appliance. Cohesive Networks extensively tests and vets all aspects of the VNS3 system before making a new version generally available. We are committed to your cloud success. If you have any additional questions please don’t hesitate to contact us.