Security Advisory Responses

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.

Ubuntu Advisory – https://usn.ubuntu.com/usn/usn-3430-1/


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.

OpenSSL Advisory – https://www.openssl.org/news/secadv/20170828.txt

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/#

3rd party interpretation – http://arstechnica.com/security/2016/10/most-serious-linux-privilege-escalation-bug-ever-is-under-active-exploit/

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.

Libreswan Advisory – https://libreswan.org/security/CVE-2016-3071/CVE-2016-3071.txt

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).

OpenSSL Advisory – https://www.openssl.org/news/secadv/20160503.txt

3rd Party Interpretation – http://arstechnica.com/security/2016/05/aging-and-bloated-openssl-is-purged-of-2-high-severity-bugs/

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.

3rd Party Interpretation – https://ma.ttias.be/openssl-cve-2015-1793-man-middle-attack/

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:

  1. Make sure TCP port 8000 is restricted to only the IPs that are required to admin your VNS3 Manager(s) via the cloud hypervisor firewall rules (Security Groups, Cloud Service, etc.) and reinforced with similar restrictions via the VNS3 Firewall.
  2. Disable SSL 3.0 in your browsers being used to administer the VNS3 Managers. Here is information on how to disable on the most popular browsers:
    – IE – https://technet.microsoft.com/en-us/library/security/3009008.aspx
    – Firefox – https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0/
    – Chrome – http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiting-ssl-30.html

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:
    Region AMI ID
    US-East-1 ami-8876c2e0
    US-West-1 ami-038d8546
    US-West-2 ami-f5db98c5
    EU-West-1, ami-aa9435dd
    AP-Southeast-1 ami-ae496efc
    AP-Southeast-2 ami-a1dbb89b
    AP-Northeast-1 ami-7f9fb67e
    SA-East-1 ami-a918b2b4
    Gov Cloud ami-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):
    Region AMI ID (Instance Store) AMI ID (EBS)
    US-East-1 ami-5a54e032 ami-8071c5e8
    US-West-1 ami-39848c7c ami-f78e86b2
    US-West-2  ami-bde7a48d  ami-5fda996f
    EU-West-1  ami-3e9e3f49  ami-2e963759
    AP-Southeast-1  ami-ae5473fc ami-be486fec
    AP-Southeast-2  ami-4dd8bb77  ami-37dab90d
    AP-Northeast-1  ami-2d7f572c  ami-8f93ba8e
    SA-East-1 ami-a91cb6b4  ami-b919b3a4
    Gov Cloud ami-f72640d4 ami-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).

NIST Notification – http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271

Coverage via The Register – http://www.theregister.co.uk/2014/09/24/bash_shell_vuln/

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:
    Region AMI ID
    US-East-1 ami-c66cd9ae
    US-West-1 ami-cbdcd48e
    US-West-2 ami-938ecda3
    EU-West-1, ami-c4e948b3
    AP-Southeast-1 ami-c06d4a92
    AP-Southeast-2 ami-7bf49741
    AP-Northeast-1 ami-251f3624
    SA-East-1 ami-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):

    Region AMI ID (Instance Store) AMI ID (EBS)
    US-East-1 ami-664df80e ami-1c7bce74
    US-West-1 ami-2fd2da6a ami-a3ddd5e6
    US-West-2 ami-8996d5b9 ami-058dce35
    EU-West-1 ami-9cf253eb ami-66ed4c11
    AP-Southeast-1 ami-766a4d24 ami-546d4a06
    AP-Southeast-2 ami-7ff89b45 ami-4df49777
    AP-Northeast-1 ami-93e9c092 ami-3b1e373a
    SA-East-1 ami-2308a23e ami-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.