Multiple Vulnerabilities in Apache HTTP Server Affecting Cisco Products: November 2021

On September 16, 2021, the Apache Software Foundation disclosed five vulnerabilities affecting the Apache HTTP Server (httpd) 2.4.48 and earlier releases.

For a description of these vulnerabilities, see the Apache HTTP Server 2.4.49 section of the Apache HTTP Server 2.4 vulnerabilities webpage.

This advisory will be updated as additional information becomes available.

This advisory is available at the following link:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-apache-httpd-2.4.49-VWL69sWQ

Security Impact Rating: High

CVE: CVE-2021-33193,CVE-2021-34798,CVE-2021-36160,CVE-2021-39275,CVE-2021-40438

Related:

  • No Related Posts

Multiple Cisco Products Server Name Identification Data Exfiltration Vulnerability

A vulnerability in Server Name Identification (SNI) request filtering of Cisco Web Security Appliance (WSA), Cisco Firepower Threat Defense (FTD), and the Snort detection engine could allow an unauthenticated, remote attacker to bypass filtering technology on an affected device and exfiltrate data from a compromised host.

This vulnerability is due to inadequate filtering of the SSL handshake. An attacker could exploit this vulnerability by using data from the SSL client hello packet to communicate with an external server. A successful exploit could allow the attacker to execute a command-and-control attack on a compromised host and perform additional data exfiltration attacks.

There are no workarounds that address this vulnerability.

This advisory is available at the following link:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-sni-data-exfil-mFgzXqLN

Security Impact Rating: Medium

CVE: CVE-2021-34749

Related:

  • No Related Posts

Error: “SSL Error 61: You have not chosen to trust ‘Certificate Authority’…” on Workspace App for Mac

Important! This article is intended for use by System Administrators. If you are experiencing this issue and you are not a System Administrator, contact your organization’s Help Desk for assistance and refer them to this article.

Update to the Latest Receiver Version

  • Upgrade to the latest version of Receiver to verify if this resolves the issue.
  • If you are using SHA2 certificates then the older version of Receiver does not support these certificate. Refer to CTX200114 – Citrix Receiver Support for SHA-2 to view the Receiver versions which supports SHA-2 certificates.

If this does not resolve the issue then proceed to the next section.

For information on Receiver feature updates refer to – Citrix Receiver Feature Matrix.

Missing Root/Intermediate Certificate

This error message suggests that the Mac client device does not have the required root certificate/intermediate certificate to establish trust with the certificate authority who issued the Secure Gateway/NetScaler Gateway server certificate.

Complete the following steps to resolve this issue:

For Big Sur, please refer to Add certificates to a keychain using Keychain Access on macOS Big Sur

For Catalina, please refer to Add certificates to a keychain using Keychain Access on macOS Catalina


The default File Format should be Certificate (.cer).

Note: You might need to rename the certificate to a .CRT extension for the client to properly identify the certificate.

Save the certificate to the ApplicationsCitrix ICA Clientkeystorecacerts folder (create this folder if it does not exist):

User-added image

Related:

  • No Related Posts

ADM and Director Intergration missing Network HDX data: Error “No details are available” or blank page

Running Citrix ADM 13.0 (latest) and attempting to integrated the network function into our Citrix Director 1912.

Attempted to use both HTTP and HTTPS.

WIth HTTP the network tab on director is blank.

With HTTPS it say no details are available.

The following guide was used: https://docs.citrix.com/en-us/xenapp-and-xendesktop/7-15-ltsr/director/hdx-insight.html

Using HTTPS ::

Using HTTPS

Network capture trace shows Director Servers sends a FIN and interrupt TLS Handshake with ADM Server.

TLS flow Request from ADM Server

==========================

Transport Layer Security

TLSv1.2 Record Layer: Handshake Protocol: New Session Ticket

Content Type: Handshake (22)

Version: TLS 1.2 (0x0303)

Length: 170

Handshake Protocol: New Session Ticket

TLSv1.2 Record Layer: Change Cipher Spec Protocol: Change Cipher Spec

Content Type: Change Cipher Spec (20)

Version: TLS 1.2 (0x0303)

Length: 1

Change Cipher Spec Message

TLSv1.2 Record Layer: Handshake Protocol: Encrypted Handshake Message

Content Type: Handshake (22)

Version: TLS 1.2 (0x0303)

Length: 96

Handshake Protocol: Encrypted Handshake Message

Response TLS from Director Server

==========================

Transmission Control Protocol, Src Port: 52282, Dst Port: 443, Seq: 342, Ack: 4300, Len: 0

Source Port: 52282

Destination Port: 443

[Stream index: 0]

[TCP Segment Len: 0]

Sequence Number: 342 (relative sequence number)

Sequence Number (raw): 1163837986

[Next Sequence Number: 343 (relative sequence number)]

Acknowledgment Number: 4300 (relative ack number)

Acknowledgment number (raw): 1444382645

0101 …. = Header Length: 20 bytes (5)

Flags: 0x011 (FIN, ACK)

Window: 512

[Calculated window size: 131072]

[Window size scaling factor: 256]

Checksum: 0xb928 [unverified]

[Checksum Status: Unverified]

Urgent Pointer: 0

[SEQ/ACK analysis]

[Timestamps]

When using HTTP :: Browser shows a blank page, no errors or details.

Related:

  • No Related Posts

ADM and Director Intergration missing Network HDX data :: Error “No details are available” or blank page

Running Citrix ADM 13.0 (latest) and attempting to integrated the network function into our Citrix Director 1912.

Attempted to use both HTTP and HTTPS.

WIth HTTP the network tab on director is blank.

With HTTPS it say no details are available.

The following guide was used: https://docs.citrix.com/en-us/xenapp-and-xendesktop/7-15-ltsr/director/hdx-insight.html

Using HTTPS ::

Using HTTPS

Network capture trace shows Director Servers sends a FIN and interrupt TLS Handshake with ADM Server.

TLS flow Request from ADM Server

==========================

Transport Layer Security

TLSv1.2 Record Layer: Handshake Protocol: New Session Ticket

Content Type: Handshake (22)

Version: TLS 1.2 (0x0303)

Length: 170

Handshake Protocol: New Session Ticket

TLSv1.2 Record Layer: Change Cipher Spec Protocol: Change Cipher Spec

Content Type: Change Cipher Spec (20)

Version: TLS 1.2 (0x0303)

Length: 1

Change Cipher Spec Message

TLSv1.2 Record Layer: Handshake Protocol: Encrypted Handshake Message

Content Type: Handshake (22)

Version: TLS 1.2 (0x0303)

Length: 96

Handshake Protocol: Encrypted Handshake Message

Response TLS from Director Server

==========================

Transmission Control Protocol, Src Port: 52282, Dst Port: 443, Seq: 342, Ack: 4300, Len: 0

Source Port: 52282

Destination Port: 443

[Stream index: 0]

[TCP Segment Len: 0]

Sequence Number: 342 (relative sequence number)

Sequence Number (raw): 1163837986

[Next Sequence Number: 343 (relative sequence number)]

Acknowledgment Number: 4300 (relative ack number)

Acknowledgment number (raw): 1444382645

0101 …. = Header Length: 20 bytes (5)

Flags: 0x011 (FIN, ACK)

Window: 512

[Calculated window size: 131072]

[Window size scaling factor: 256]

Checksum: 0xb928 [unverified]

[Checksum Status: Unverified]

Urgent Pointer: 0

[SEQ/ACK analysis]

[Timestamps]

When using HTTP :: Browser shows a blank page, no errors or details.

Related:

  • No Related Posts

How to Configure SSL on XenDesktop Controllers to Secure XML Traffic

From XenDesktop Controller

IIS Installed on XenDesktop Controller

In this scenario, the XenDesktop controller has IIS installed and functioning to serve Web Interface or other web services. To complete this setup, you must request a Server Certificate and install it on IIS.

There are two ways to generate Server Certificates on IIS 7.x:

  • Create Certificate Request: This generates a CSR file to be submitted to a third party Certification Authority (CA) or to your internal Microsoft CA. For more information, refer to Microsoft TechNet article – Request an Internet Server Certificate (IIS 7)

  • Create Domain Certificate: This generates a CSR file and submits it to your domain registered Microsoft CA server. For more information, refer to the Microsoft TechNet article – Create a Domain Server Certificate on IIS 7.

    User-added image

After the Server Certificate is installed on IIS, ensure to set the Bindings to enable HTTPS on IIS by completing the following procedure:

  1. Select the IIS site that you want to enable HTTPS and select Bindings under Edit Site.

    User-added image

  1. Click Add, select Type as https, port number as 443, select the SSL Certificate that you installed and click OK.

    User-added image

  1. Open Registry Editor on XenDesktop Controller and look for the following key name.

    HKEY_LOCAL_MACHINESOFTWARECitrixDesktopServer.

    Caution! Refer to the Disclaimer at the end of this article before using Registry Editor.

  1. Verify that XmlServicesSslPort registry key exists with the correct value for SSL port. By default, it is set to 443.

    User-added image

  1. Change the XML service port.

    You can do this using PowerShell by running the following command:

    BrokerService –WiSslPort <port number>

    Note
    : If you decide to change the XML service port number on XenDesktop Controller, ensure to update the IIS port number as well under Bindings to match the new value.

IIS is not Installed on XenDesktop Controller

In this scenario, the XenDesktop Controller does not have IIS installed. As a result, there are a few ways to obtain a Server Certificate for the Controller:

  • Export an existing Server Certificate from another server in PFX format. When exporting the Server Certificate, ensure to select the private key as well.

  • You can use the Certreq utility from Microsoft to generate a Certificate Signing Request and submit it to a third party CA or your internal Microsoft CA server. For more information, refer to the Microsoft TechNet article – Certreq.exe Syntax.

    Note: Ensure to always import the PFX server certificates under the XenDesktop controller Local Computer certificate store and not My user account.

    User-added image

After the Server Certificate is installed on XenDesktop Controller, register the SSL certificate for HTTPS on the server. To accomplish this, Windows 2008 has a built-in utility called netsh that allows you to bind SSL certificates to a port configuration. For more information, refer to the Microsoft MSDN article – How to: Configure a Port with an SSL Certificate

The following is the command that you must use:

netsh http add sslcert ipport=0.0.0.0:<port Number> certhash=<hash number> appid={XenDesktop Broker Service GUID}

To obtain the certificate hash of a Server Certificate, open the Registry Editor, and open the following key name location and search for the Server Certificate that you want to use:

HKEY_LOCAL_MACHINESOFTWAREMicrosoftSystemCertificatesMYCertificates

User-added image

An alternative to obtain this certificate hash

  1. Open the Server Certificate and under the Details tab, select Thumprint:

    User-added image

  1. Obtain the GUID of the XenDesktop controller Citrix Broker Service.

  2. Open Registry Editor and select Find.

  3. Search for Broker Service words. By default, the location is in HKEY_CLASSES_ROOTInstallerProducts (see the following example):

    User-added image

  1. Now that you have the certificate hash and Citrix Broker Service GUID, you can run the netsh command to bind the SSL certificate to port 443 and Citrix Broker Service. The following example is based on the GUID and certificate hash values taken from the preceding screenshots:

    Here is command to get the GUID

    Run the below command in Elevated command prompt on the DDC

    wmic product where “Name like ‘Citrix Broker Service'” get Name,identifyingnumber

    IdentifyingNumber

    ​C: >netsh http add sslcert ipport=10.12.37.231:443 certhash=298B8AB50322A5A601A57D4976875191D85A2949 appid={13C9D851-5D94-7C44-4A2B-218F89A28DC7}

    Note
    : For GUID, ensure to include dashes (-). Otherwise, the command cannot run successfully.

A successful bind looks as displayed in the following screen shot:

User-added image

From the Web Interface server

Configure the XenApp Web Site or XenApp Services Site to use HTTPS and 443 as Transport Type and XML Service port respectively under Server Farms.

User-added image

Note: To have a successful SSL connection to the XenDesktop 5 Controller, ensure that Web Interface has installed the Trusted Root certificate (under Local Computer certificate store).

Related:

  • No Related Posts

Process Shows “Starting Application”, Freezes When Launching Applications from Receiver for iOS or From Browser on iOS Devices

In order for this to work you can either disable SSL & TLS or you can disable Session Reliability.

Disable SSL and TLS

  1. Open the AppCenter Management console.

  2. Go to the Published Application Properties for the Application that is experiencing the issue.

  3. Click Advanced > Client Options.

  4. Uncheck the Enable SSL and TLS Protocols.

  5. Click Apply to save the new settings.

User-added image

Disable Session Reliability – To disable Session Reliability you will need to explicitly disable it from StoreFront/Web Interface, as well as the XenApp policies:

  1. From the StoreFront Management console, click NetScaler Gateway > Secure Ticket Authority.

  2. Uncheck enable session reliability.

  3. Click OK to save your new settings.

User-added image
Note: Propagate the changes to the rest of the StoreFront servers if necessary.

Web Interface

  1. From the Web Interface Management console, select the web site you want to change

  2. Click Secure Access

  3. Click next at the Specify Access Methods

  4. Uncheck Enable session reliability

  5. Click Next

  6. Click Finish to save your new settings.

User-added image
XenApp Policies

  1. From within the AppCenter Management console select the Policies node to edit the farm policies.

  2. Ensure that the Computer Policies tab is selected, then select the policy you intend to make the changes in.

  3. Click Edit > Settings tab.

  4. Select Session Reliability > Session reliability connections.

  5. Click add.

  6. Click Prohibited.

  7. Click OK twice to save your new policy settings.

User-added image

Note: To force the policy update right away run gpupdate /force

You can also confirm the policy applied by checking the following key in the registry of the XenApp server: User-added image

HKEY_LOCAL_MACHINESOFTWAREPoliciesCitrixICAPoliciesAcceptSessionReliabilityConnections

Note: This should now be set to a Reg_DWord = 0

Related:

  • No Related Posts