XenMobile New Port Requirement for ADS Connectivity

Overview

Citrix is making security enhancements to XenMobile in the form of certificate pinning. This feature includes a new Citrix Auto Discovery Service (ADS) access requirement that must be enabled in every customer environment whether you choose to use the certificate pinning feature or not.

What is ADS?

Citrix Auto Discovery Service (ADS) is a cloud service owned and maintained completely by Citrix. This service plays a crucial part in every XenMobile environment and serves two main purposes:

  1. As the name suggests, ADS helps with autodiscovery of XenMobile servers. When an email or UPN is used to initiate enrollment through Secure Hub, Secure Hub calls out to ADS to discover the appropriate XenMobile server for the environment.

  2. ADS is also used to pass on environment-specific security settings to Secure Hub. Certificate pinning builds on this security.

We are making security enhancements to the XenMobile ADS that provides an extra layer of security through certificate pinning. Due to the changes we are making, initial enrollment communication must flow through the ADS server.

What is certificate pinning?

Certificate-pinning is a trusted “first-use” security mechanism during the enrollment process that protects servers from impersonation through fraudulent certificates issued by compromised certificate authorities. It is commonly used to prevent “man in the middle” attacks.

What are the prerequisites for certificate pinning?

  1. Customers should open outbound port 443, if not already open, to enable mobile device access for the Citrix ADS service. This port configuration ensures that devices can access ADS when within the corporate network. The ability to access ADS is important when downloading any security updates made available through ADS. These ports must be opened whether you use the certificate pinning feature or not. All customers must complete step 1.

    To enable mobile device connectivity to Citrix ADS, open outbound port 443 from the client (mobile device) to ADS systems in the cloud for the following destination FQDN and IP addresses.

    FQDN IP Address Port IP and Port Usage
    discovery.mdm.zenprise.com 52.5.138.94 443 Secure Hub – ADS

    Communication
    52.1.30.122 443
    ads.xm.cloud.com* 34.194.83.188 443 Secure Hub – ADS

    Communication
    34.193.202.23 443

    * SecureHub version 10.6.15 and later uses ads.xm.cloud.com

    Note: The IP Address and Ports in the chart are required for the communication of devices on the network. The chart is not describing the communication for the internal components within XenMobile. The ADS connection may not work with your proxy server. In this scenario, you should allow the ADS connection to be bypassed at the proxy.

    If interested in enabling the certificate pinning feature continue with steps 2 and 3.

  2. Collect XenMobile server (or Device Manager server for versions earlier than XenMobile 10) and NetScaler Server certificates. These certificates need to be in PEM format. You must acquire the public certificate and not the private key.

    Note: The exported public certificate must not include the certificate chain (i.e. the intermediate and root certificates).

  3. Contact Citrix Support and place a request to enable certificate pinning. During this process, you will be asked for your certificates. A link to Citrix support can be found on the bottom of the page.

I am not interested in certificate pinning. Do I have to do anything?

Yes. ADS access is required from your network by opening the required port. These ports must be opened whether you use the certificate pinning feature or not

Why does certificate pinning require a new port?

The new certificate pinning improvements mandate that any newly enrolling device connect to ADS before the device enrols. This step ensures that the latest security information is available to Secure Hub for the environment in which the device is enrolling. If ADS is not reachable, Secure Hub does not allow enrollment of the device. Therefore, opening up ADS access within the corporate network is critical to enable devices to enroll.

When are these changes occurring and when do I need to act?

For the next release of Secure Hub 10.2 for Android, currently scheduled for early October. Certificate pinning will initially be supported on Secure Hub for Android with XenMobile 10.2 and on a future release of Secure Hub for iOS.

Customers must open firewall ports to the ADS service to ensure new enrollment continuity.

What information do I need to provide to Citrix Support?

Refer to the Certificate Pinning information available at Citrix Documentation for Secure Hub.

How should we engage Citrix for support on this feature?

Use the following the link – XenMobile Technical Support to open a support ticket for assistance with ADS configuration. From this link you can locate the support phone number specific to your location.

Questions? Contact your Citrix account manager or authorized Citrix Partner.

Related:

How Do I Block SSLv2 on NetScaler?

This article describes how to block SSLv2 on NetScaler.

Note: According to RFC6176 from Internet Engineering Task Force (ITEF), TLS servers must not support SSLv2. The NetScaler appliance does not support SSLv2 from release 12.1.

Use Case

SSL v2 protocol has many security vulnerabilities which makes it essential for a user to disable it and opt for stronger and more secure protocols such as TLS v1.1 / v1.2.

Introduction to SSL v2

SSL v2 (SSL 2.0) is a protocol created by Netscape in 1994. It was identified with many security vulnerabilities many of which were later resolved in SSL v3, which as well is impacted by security vulnerabilities.

Here is a list of some of the flaws in SSL v2:

  1. SSL v2 has a weak MAC (message authentication code) construction which uses 40 bit of encryption in export mode. It uses the MD5 hash function which makes it vulnerable to length extension attacks wherein an attacker can delete bytes from the end of messages.
  2. It is vulnerable to cipher suite attack as the handshake messages are not protected. In this attack, the attacker edits the list of cipher suite preferences to a lower cipher suite without any detection (in the hello messages). This forces the client and server to agree upon a weaker form of encryption than they otherwise would have chosen.
  3. Message authentication and message encryption use the same key. This can lead to a problem if the client and server negotiate a weak encryption
  4. Session terminated can be forged. A man-in-the-middle attacker can easily insert a TCP FIN to terminate the session. The receiving endpoint is unable to determine whether it is a legitimate end of session request or not thus resulting in an unwanted termination.
  5. SSL v2 does not follow chain certificate and does not support non-RSA algorithm. It only supports RSA key exchange which may not be the preferred option in many cases
  6. SSL v2 only supports one domain certificate with a single service. This is not a preferable option as it would not support virtual hosting for web servers.

Related:

7016877: Configuring eDirectory to mint certificates with a SHA-2 signature

Digital signatures prove ownership. They provide proof that a user is in fact talking to the CA authority who signed a certificate and not some man-in-the-middle.

When encrypting data the public key is used to encrypt the data for the entity holding the private key. However, in this case the roles are reversed. A private key can be used to prove ownership of a public key. The holder of the private key encrypts a small amount of data with the private key then sends that data (in the clear) along with the encrypted data itself. The public key holder uses that key to decrypt the data and compare it to the token (unencrypted) data sent. Only the private key holder can send this type of data to verify its signature on the certificate. This token/encrypted data pair is called a digital signature. Digital signatures cannot effectively sign large amounts of data. Therefore, a hash function is used to take all the certificate variable data and reduce it to a digest containing a small fixed amount of data. This hash is then encrypted with the private key. The verification process afterward is thus:

– The signature is included along with the certificate

– The signature is decrypted with the public key to get the hash

– The certificate is then hashed with the same algorithm

– The two hashed values are then compared

There have been a number of prior hashing algorithms. As computational power increased, the possibility of reversing the hash in an acceptable amount of time has also increased. Prior to SHA-1 MD5 was used until a flaw was found in 2004. Since then SHA-1 has been used. Now the possibility of it also becoming compromised due to increased processing power has spurred the industry to adopt SHA-2.

In support of this major browser manaufacturers are taking steps to begin phasing out SHA-1 signed certificates. Many already are not allowing SHA-1 certificates if they are valid beyond January 2017 (the final cutoff date for support). Some vendors will not accept them past January 1, 2016.

Related:

  • No Related Posts

Citrix XenServer 7.2 Multiple Security Updates

A number of security issues have been identified within Citrix XenServer 7.2 which could, if exploited, allow a malicious man-in-the-middle (MiTM) attacker on the management network to decrypt management traffic. Collectively, this has been rated as a medium severity vulnerability; the following issues have been remediated:

  • CVE-2016-2107
  • CVE-2016-2108

Related:

How Do I Configure HTTP Strict Transport Security (HSTS) on NetScaler

HSTS stands for HTTP Strict Transport Security. The main objective of HSTS is to protect websites against various attacks like SSL strip, Cookie Hijacking, Downgrade attack etc. RFC 6797 covers the exact IETF standardized functionality of HSTS. HSTS enables servers to declare to other entities (Web browsers, Applications etc) to communicate to the server only via HTTPS connection. This is done by web server by setting Strict-Transport-Security HTTP response header field.

NetScaler 12.0 appliances support HTTP strict transport security (HSTS) as an inbuilt option in SSL profiles and SSL virtual servers. For information on configuring this feature refer to CTX224172 – How to Enable HTTP Strict Transport Security (HSTS) on NetScaler 12.

Use Case

  • Ramesh wishes to interact with various web sites (some arbitrary, some known) in a secure fashion through a web browser.

  • Banking.com wishes to offer their site in an explicitly secure fashion for their own, as well as their users’, benefit.

Ramesh has user account in banking.com and is a regular user transacting through banking.com regularly. As usual Ramesh wants to transfer money to his friend and thus he accesses the website banking.com by typing URL www.banking.com.

User-added image

In this case, browser converts this to http://www.banking.com. Browser detects the name banking.com, communicates with DNS server and gets IP address for host server.

Browser contact the IP address received on port 80. The banking website sends a redirect request to https://www.banking.com. SSL handshake and certificate verification happens leading to SSL connection establishment. The padlock in URL bar will change to green and will be in locked state.

User-added image

User-added image
Ramesh can now enter his credentials safely to make the required transaction.

Well, what can go wrong now? A man in the middle can intercept the resolving request for banking.com and send Ramesh his own server ip address. When request is made to the IP address on port 80 he can redirect Ramesh to his own slightly mispronounced website https://www.blanking.com. Ramesh might not notice the change and enter his credentials thereby giving his details to someone else.

Other possibility is when intruder presents his own certificate for banking.com and this time browser identifies it is not a trusted certificate and sends a pop up asking Ramesh if he wants to override this warning. People , at times ignore warning messages and will end up falling in the trap of intruder.

How HSTS helps?

HSTS sends Strict-Transport-Security flag set in the HTTP response header field. It also sends a value in the header which denotes the time for which the browser can keep the website under STS sites.

HSTS prevents scenarios mentioned above by making sure that they respond only to https request and doesn’t allow Ramesh to override the warning. Also in recent browser versions when the browser receives a HTTP request for a website under STS list, it will automatically makes a HTTPS request to the server thus helping users to be protected from these attacks. This cool feature can be enabled in NetScaler enabling actual backend servers to have this protection through NetScaler path as we do SSL offloading on NetScaler.

Related:

When won’t the SSLV be able to decrypt? Does the client and SSLV have to be integrated into a corporate Certificate Authority as with forward proxy so the SSLV can resign the traffic?¬

I do not need a solution (just sharing information)

Any Man-in-the-Middle (MITM) device that is going to inspect outbound SSL traffic (traffic to SSL servers not under the control of the enterprise) has to be a bump in the wire as it needs to intercept the SSL handshake messages from the server and modify the server certificate before it is sent to the client in order to gain access to the decrypted traffic. This is true for any MITM device providing visibility into outbound SSL traffic and is down to how the protocol works. The term that we use for the method used to inspect outbound traffic is Certificate Re-sign to reflect that SSLV, ProxySG or any other MITM needs to modify the original server certificate before it is sent to the client and this requires the use of a Certificate Authority that is part of the MITM device. In order for the client to not see warnings it needs to trust the Certificate Authority being used by the MITM device.

In the case of inbound SSL traffic from clients the enterprise does not control to SSL servers that the enterprise does control a different mechanism is used. This is what we call Known Server Key and it requires that SSLV (or any other MITM) has a copy of the SSL servers certificate and private key. Using KSK does not require that the client be modified or configured to trust any special Certificate Authorities. As long as the server certificate is for a publicly trusted server the client will not generate any warnings when SSLV carries out KSK to provide visibility.

0

Related:

  • No Related Posts

When won’t the SSLV be able to decrypt? Does the client and SSLV have to be integrated into a corporate Certificate Authority as with forward proxy so the SSLV can resign the traffic?

I do not need a solution (just sharing information)

Any Man-in-the-Middle (MITM) device that is going to inspect outbound SSL traffic (traffic to SSL servers not under the control of the enterprise) has to be a bump in the wire as it needs to intercept the SSL handshake messages from the server and modify the server certificate before it is sent to the client in order to gain access to the decrypted traffic. This is true for any MITM device providing visibility into outbound SSL traffic and is down to how the protocol works. The term that we use for the method used to inspect outbound traffic is Certificate Re-sign to reflect that SSLV, ProxySG or any other MITM needs to modify the original server certificate before it is sent to the client and this requires the use of a Certificate Authority that is part of the MITM device. In order for the client to not see warnings it needs to trust the Certificate Authority being used by the MITM device.

In the case of inbound SSL traffic from clients the enterprise does not control to SSL servers that the enterprise does control a different mechanism is used. This is what we call Known Server Key and it requires that SSLV (or any other MITM) has a copy of the SSL servers certificate and private key. Using KSK does not require that the client be modified or configured to trust any special Certificate Authorities. As long as the server certificate is for a publicly trusted server the client will not generate any warnings when SSLV carries out KSK to provide visibility.

0

Related:

  • No Related Posts

VU#767208: ThreatMetrix SDK for iOS fails to validate SSL certificates

Vulnerability Note VU#767208

ThreatMetrix SDK for iOS fails to validate SSL certificates

Original Release date: 10 Jan 2017 | Last revised: 11 Jan 2017

Overview

On the iOS platform, the ThreatMetrix SDK versions prior to 3.2 fail to validate SSL certificates provided by HTTPS connections, which may allow an attacker to perform a man-in-the-middle (MITM) attack.

Description

ThreatMetrix is a security library for mobile applications, which aims to provide fraud prevention and device identity capabilities. The ThreatMetrix SDK versions prior to 3.2 do not validate SSL certificates on the iOS platform. An affected application will communicate with https://h-sdk.online-metrix.net, regardless of whether the connection is secure or not.

Impact

An attacker on the same network as or upstream from the iOS device may be able to view or modify ThreatMetrix network traffic that should have been protected by HTTPS.

Solution

Apply an update

This issue has been addressed in ThreatMetrix SDK versions 3.2 and later. Any iOS application that uses a vulnerable version of the ThreatMetrix SDK will need to be regenerated with an updated version of the library.

Avoid untrusted networks

Avoid using untrusted networks, including public WiFi. Using your device on an untrusted network increases the chance of falling victim to a MITM attack.

Vendor Information (Learn More)

Vendor Status Date Notified Date Updated
ThreatMetrix Affected 04 Jan 2017 10 Jan 2017

If you are a vendor and your product is affected, let
us know
.

CVSS Metrics (Learn More)

Group Score Vector
Base 4.8 AV:A/AC:L/Au:N/C:P/I:P/A:N
Temporal 4.0 E:F/RL:OF/RC:C
Environmental 3.9 CDP:ND/TD:ND/CR:ND/IR:ND/AR:ND

References

Credit

This vulnerability was reported by Will Dormann of the CERT/CC.

This document was written by Will Dormann.

Other Information

  • CVE IDs:
    CVE-2017-3182
  • Date Public:
    10 Jan 2017
  • Date First Published:
    10 Jan 2017
  • Date Last Updated:
    11 Jan 2017
  • Document Revision:
    11

Feedback

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Related: