Cisco Wireless LAN Controller CAPWAP Denial of Service Vulnerability

A vulnerability in the Control and Provisioning of Wireless Access Points (CAPWAP) protocol handler of Cisco Wireless LAN Controller (WLC) Software could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on an affected device.

The vulnerability is due to insufficient validation of CAPWAP packets. An attacker could exploit this vulnerability by sending a malformed CAPWAP packet to an affected device. A successful exploit could allow the attacker to cause the affected device to restart, resulting in a DoS condition.

Cisco has released software updates that address this vulnerability. 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-wlc-capwap-dos-Y2sD9uEw

This advisory is part of the April 2020 Cisco Aironet AP, Mobility Express, and WLC Software Security Advisory Bundled Publication, which includes four Cisco Security Advisories that describe four vulnerabilities. For a complete list of the advisories and links to them, see Cisco Event Response: April 2020 Cisco Aironet AP, Mobility Express and WLC Software Security Advisory Bundled Publication.

Security Impact Rating: High

CVE: CVE-2020-3262

Related:

  • No Related Posts

Advisory: Sophos UTM – RED Site-to-Site tunnel issues after upgrading to v9.7

Sophos is investigating reports from some customers experiencing RED site-to-site tunnel issues after upgrading from v9.605 to v9.7.

Applies to the following Sophos products and versions

Sophos UTM

A fixed Up2Date package (u2d-sys-9.605004-700005) has been released for the v9.605 to v9.700 update path. For installations already running v9.670 or v9.700, the following are the fixed Up2Date packges:

For installations running 9.7 EAP1 (9.670-4):

  • u2d-sys-9.670004-700004
  • u2d-sys-9.700004-700005

For installations running 9.7 GA (9.700-4):

  • u2d-sys-9.700004-700005

Affected customers can workaround this issue by re-downloading the provisioning file from the Server, and re-creating the client-side RED-interface:

  • On the Server
    1. In the Admin UI, go to: Red Management > [Server] Client Management.
    2. Download all necessary provisioning files.
  • On the Client
    1. In the Admin UI, go to: Red Management > [Client] Tunnel Management.
    2. Open the affected RED-Device and take note of the Tunnel Name and UTM Host.
    3. Delete the Client Tunnel.
    4. Create a new tunnel using the above noted Tunnel Name, UTM-Host, and downloaded provisioning file.
    5. In the Admin UI go to: Interface & Routing > Interfaces.
    6. Open the affected Tunnel Interface and select the newly recreated RED-Interface.

This article will be updated when more information becomes available.

Sign up to the Sophos Support SMS Notification Service to get the latest product release information and critical issues.

If you’ve spotted an error or would like to provide feedback on this article, please use the section below to rate and comment on the article.

This is invaluable to us to ensure that we continually strive to give our customers the best information possible.

Related:

  • No Related Posts

Cisco IOS XE Software ISDN Data Leak Vulnerability

A vulnerability in the Dialer interface feature for ISDN connections in Cisco IOS XE Software for Cisco 4000 Series Integrated Services Routers (ISRs) could allow an unauthenticated, adjacent attacker to
pass IPv4 traffic through an ISDN channel prior to successful PPP authentication.

The vulnerability is due to insufficient validation of the state of the PPP IP Control Protocol (IPCP). An attacker could exploit this vulnerability by making an ISDN call to an affected device and sending traffic through the ISDN channel prior to successful PPP authentication. Alternatively, an unauthenticated, remote attacker could exploit this vulnerability by sending traffic through an affected device that is configured to exit via an ISDN connection for which both the Dialer interface and the Basic Rate Interface (BRI) have been configured, but the Challenge Handshake Authentication Protocol (CHAP) password for PPP does not match the remote end. A successful exploit could allow the attacker to pass IPv4 traffic through an unauthenticated ISDN connection for a few seconds, from initial ISDN call setup until PPP authentication fails.

Cisco has released software updates that address this vulnerability. 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-20190925-isdn-data-leak

Security Impact Rating: Medium

CVE: CVE-2019-12664

Related:

Provisioning Services 7.6.9 – 7.6 LTSR CU8

Console

Attempts to access the farm from the console might fail. The issue occurs when the user is a member of the provisioning administrative group in a domain that is different from the user’s domain.

[#LD1371]

Download Permission

Permissions to download Provisioning Services 7.6.9 are based on valid Citrix Software Maintenance (or the functionally equivalent combination of Legacy Support and Subscription Advantage). For more information on eligibility and access, refer to XenApp and XenDesktop Servicing Options. After you choose your product-edition combination from the list below, if you need help related to permissions, contact Customer Service.

Download URL

Download Provisioning Services 7.6.9

Related:

The Provisioning Server either cannot be found or shows as **down** in the Provisioning Services Console.

To resolve this issue, perform the following tasks:

1. Launch the Provisioning Services Console and verify the Provisioning Server appears as “down.” If so, verify that the Citrix PVS Stream Service is running on the Provisioning Server. For more information, see Starting, stopping, or restarting Provisioning Services

2. From the Provisioning Services Console, verify the Provisioning Server appears when the Servers node is selected. If no Provisioning Server appears, verify the database server’s IP address or FQDN is specified correctly in the Console.

3. Verify the database server is powered on and can be reached from another machine in your environment.

4. Verify that the Provisioning Server’s configuration is complete using the Provisioning Services Configuration Wizard.

Related:

  • No Related Posts

Duplicate McAfee Agent EPO in PVS – EPO Console

Consider the following when using Provisioning Services with the McAfee ePolicy Agent:

Guidelines

A: Delete the Agent GUID for McAfee EPO agent; otherwise all machines deployed came up in EPO server as the same computer. So, if you are going to use the Provisioning Services image in Shared Image mode, Citrix recommends stopping the McAfee framework service and deleting the following registry key, just before your create your Provisioning Services image.

Stop the McAfee Framework service (but leave on Automatic start up) and delete the AgentGUID registry value:

HKEY_LOCAL_MACHINESOFTWARENetwork AssociatesePolicy OrchestratorAgent

Additional registry keys may need to be cleared or deleted before rolling out an image in Standard Image mode. To run McAfee 8.5i and EPO on a vDisk in Standard Image mode, the values for the following registry keys must be deleted before imaging the Master Target Device (this could also be done after building the image by putting the image back into Private Image Mode):

HKLMSOFTWARENetwork AssociatesePolicy OrchestratorAgentAgentGUID

HKLMSOFTWARENetwork AssociatesePolicy OrchestratorAgentMACADDRESS

HKLMSystemCurrentControlSetServicesFireTDIEnum (if using Host Intrusion)

Make sure there is not a policy applied to this PC on EPO that restarts the framework service after X seconds. (Otherwise this key might be recreated before you start the Provisioning Services image creation process).

The problem here is that each time a PC restarts in Shared Image Mode, a different GUID is recreated. It might be necessary to set EPO to delete stale entries from its Asset database. The results might also not provide a true reflection in reports of a particular PCs infection history, as it has a new record in the EPO database each time a reboot occurs. This is preferable over having lots of PCs with only one of them having updated antivirus at a time.

Related:

Re: Dual ESRS/VE Centralized Gateway setup

Hi

We are planning to deploy the ESRS/VE setup. In the same site we have unity & powermax arrays and planning to have 2 different VM dedicated for ESRS centralized setup. So this is called as Dual ESRS HA ?

So my understanding is for ESRS/VE we will be getting a OVA/OVF appliance. On first VM, I will have to import this OVA/OVF file and configure and supply the parameters like IP Addr, DNS, Gateway IP and will need to do the complete ESRS configuration, provisioning etc. Once this is done all the sites and arrays of the customer will be visible in First instance of VM – First ESRS.

For 2nd VM – 2nd ESRS – Do I need to repeat the same entire process that i did or I need to do until ESRS services gets started on the VM and can I skip the ESRS configuration and provisioning part fully ? —> as this is 2nd instance of ESRS.

I read somewhere that while deploying 2nd instance of ESRS, that instance should not be managing any devices at all. In this scenario, how the site id’s and arrays will be pulled or visible in to 2nd instance of ESRS – Will the ESRS Backend infra server that belongs to EMC will do the synchronization of all assets from 1st VM instance to 2nd VM instance ? Please assist

Related:

Dual ESRS/VE Centralized Gateway setup

Hi

We are planning to deploy the ESRS/VE setup. In the same site we have unity & powermax arrays and planning to have 2 different VM dedicated for ESRS centralized setup. So this is called as Dual ESRS HA ?

So my understanding is for ESRS/VE we will be getting a OVA/OVF appliance. On first VM, I will have to import this OVA/OVF file and configure and supply the parameters like IP Addr, DNS, Gateway IP and will need to do the complete ESRS configuration, provisioning etc. Once this is done all the sites and arrays of the customer will be visible in First instance of VM – First ESRS.

For 2nd VM – 2nd ESRS – Do I need to repeat the same entire process that i did or I need to do until ESRS services gets started on the VM and can I skip the ESRS configuration and provisioning part fully ? —> as this is 2nd instance of ESRS.

I read somewhere that while deploying 2nd instance of ESRS, that instance should not be managing any devices at all. In this scenario, how the site id’s and arrays will be pulled or visible in to 2nd instance of ESRS – Will the ESRS Backend infra server that belongs to EMC will do the synchronization of all assets from 1st VM instance to 2nd VM instance ? Please assist

Related:

Cisco Wireless LAN Controller Software Control and Provisioning of Wireless Access Points Protocol Denial of Service Vulnerability

A vulnerability in the Control and Provisioning of Wireless Access Points (CAPWAP) protocol component of Cisco Wireless LAN Controller (WLC) Software could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition.
 
The vulnerability is due to improper input validation on fields within CAPWAP Discovery Request packets by the affected device. An attacker could exploit this vulnerability by sending malicious CAPWAP Discovery Request packets to the Cisco WLC Software. A successful exploit could allow the attacker to cause the Cisco WLC Software to disconnect associated access points (APs). While the APs disconnect and reconnect, service will be unavailable for a brief period of time, resulting in a DoS condition.

Cisco has released software updates that address this vulnerability. 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-20181017-wlc-capwap-dos

Security Impact Rating: High

CVE: CVE-2018-0443

Related:

Cisco Wireless LAN Controller Software Control and Provisioning of Wireless Access Points Protocol Information Disclosure Vulnerability

A vulnerability in the Control and Provisioning of Wireless Access Points (CAPWAP) protocol component of Cisco Wireless LAN Controller (WLC) Software could allow an unauthenticated, remote attacker to retrieve memory contents, which could lead to the disclosure of confidential information.
 
The vulnerability is due to insufficient condition checks in the part of the code that handles CAPWAP keepalive requests. An attacker could exploit this vulnerability by sending a crafted CAPWAP keepalive packet to a vulnerable Cisco WLC device. A successful exploit could allow the attacker to retrieve the contents of device memory, which could lead to the disclosure of confidential information.

Cisco has released software updates that address this vulnerability. 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-20181017-wlc-capwap-memory-leak

Security Impact Rating: High

CVE: CVE-2018-0442

Related: