Cisco Nexus 9500 Series Switches Access Control List Bypass Vulnerability

A vulnerability in the EtherChannel port subscription logic of Cisco Nexus 9500 Series Switches could allow an unauthenticated, remote attacker to bypass access control list (ACL) rules that are configured on an affected device.

This vulnerability is due to oversubscription of resources that occurs when applying ACLs to port channel interfaces. An attacker could exploit this vulnerability by attempting to access network resources that are protected by the ACL. A successful exploit could allow the attacker to access network resources that would be protected by the ACL that was applied on the port channel interface.

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-nexus-acl-vrvQYPVe

This advisory is part of the August 2021 Cisco FXOS and NX-OS Software Security Advisory Bundled Publication. For a complete list of the advisories and links to them, see Cisco Event Response: August 2021 Cisco FXOS and NX-OS Software Security Advisory Bundled Publication.

Security Impact Rating: Medium

CVE: CVE-2021-1591

Related:

  • No Related Posts

Cisco NX-OS Software Unauthenticated Arbitrary File Actions Vulnerability

A vulnerability in the implementation of an internal file management service for Cisco Nexus 3000 Series Switches and Cisco Nexus 9000 Series Switches in standalone NX-OS mode that are running Cisco NX-OS Software could allow an unauthenticated, remote attacker to create, delete, or overwrite arbitrary files with root privileges on the device.  

This vulnerability exists because TCP port 9075 is incorrectly configured to listen and respond to external connection requests. An attacker could exploit this vulnerability by sending crafted TCP packets to an IP address that is configured on a local interface on TCP port 9075. A successful exploit could allow the attacker to create, delete, or overwrite arbitrary files, including sensitive files that are related to the device configuration. For example, the attacker could add a user account without the device administrator knowing.

Cisco has released software updates that address this vulnerability. There are workarounds that address this vulnerability.

This advisory is available at the following link:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-3000-9000-fileaction-QtLzDRy2

This advisory is part of the February 2021 Cisco FXOS and NX-OS Software Security Advisory Bundled Publication. For a complete list of the advisories and links to them, see Cisco Event Response: February 2021 Cisco FXOS and NX-OS Software Security Advisory Bundled Publication.

Security Impact Rating: Critical

CVE: CVE-2021-1361

Related:

  • No Related Posts

Cisco Nexus 3000 and 9000 Series Switches Privilege Escalation Vulnerability

A vulnerability in the Enable Secret feature of Cisco Nexus 3000 Series Switches and Cisco Nexus 9000 Series Switches in standalone NX-OS mode could allow an authenticated, local attacker to issue the enable command and get full administrative privileges. To exploit this vulnerability, the attacker would need to have valid credentials for the affected device.

The vulnerability is due to a logic error in the implementation of the enable command. An attacker could exploit this vulnerability by logging in to the device and issuing the enable command. A successful exploit could allow the attacker to gain full administrative privileges without using the enable password.

Note: The Enable Secret feature is disabled by default.

Cisco has released software updates that address this vulnerability. There are workarounds that address this vulnerability.

This advisory is available at the following link:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-n3n9k-priv-escal-3QhXJBC

This advisory is part of the August 2020 Cisco FXOS and NX-OS Software Security Advisory Bundled Publication, which includes seven Cisco Security Advisories that describe seven vulnerabilities. For a complete list of the advisories and links to them, see Cisco Event Response: August 2020 Cisco FXOS and NX-OS Software Security Advisory Bundled Publication.

Security Impact Rating: High

CVE: CVE-2020-3394

Related:

Cisco Nexus 1000V Switch for VMware vSphere Secure Login Enhancements Denial of Service Vulnerability

A vulnerability in the Secure Login Enhancements capability of Cisco Nexus 1000V Switch for VMware vSphere could allow an unauthenticated, remote attacker to cause an affected Nexus 1000V Virtual Supervisor Module (VSM) to become inaccessible to users through the CLI.

The vulnerability is due to improper resource allocation during failed CLI login attempts when login parameters that are part of the Secure Login Enhancements capability are configured on an affected device. An attacker could exploit this vulnerability by performing a high amount of login attempts against the affected device. A successful exploit could cause the affected device to become inaccessible to other users, resulting in a denial of service (DoS) condition requiring a manual power cycle of the VSM to recover.

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-20200226-nexus-1000v-dos

This advisory is part of the February 2020 Cisco FXOS and NX-OS Software Security Advisory Bundled Publication, which includes six Cisco Security Advisories that describe six vulnerabilities. For a complete list of the advisories and links to them, see Cisco Event Response: February 2020 Cisco FXOS and NX-OS Software Security Advisory Bundled Publication.

Security Impact Rating: High

CVE: CVE-2020-3168

Related:

Cisco Nexus 9000 Series Fabric Switches ACI Mode Border Leaf Endpoint Learning Vulnerability

A vulnerability within the Endpoint Learning feature of Cisco Nexus 9000 Series Switches running in Application Centric Infrastructure (ACI) mode could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on an endpoint device in certain circumstances.

The vulnerability is due to improper endpoint learning when packets are received on a specific port from outside the ACI fabric and destined to an endpoint located on a border leaf when Disable Remote Endpoint Learning has been enabled. This can result in a Remote (XR) entry being created for the impacted endpoint that will become stale if the endpoint migrates to a different port or leaf switch. This results in traffic not reaching the impacted endpoint until the Remote entry can be relearned by another mechanism.

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-20190828-nexus-aci-dos

Security Impact Rating: Medium

CVE: CVE-2019-1977

Related:

  • No Related Posts

Cisco Nexus 9000 Series Fabric Switches ACI Mode Fabric Infrastructure VLAN Unauthorized Access Vulnerability

A vulnerability in the fabric infrastructure VLAN connection establishment of the Cisco Nexus 9000 Series Application Centric Infrastructure (ACI) Mode Switch Software could allow an unauthenticated, adjacent attacker to bypass security validations and connect an unauthorized server to the infrastructure VLAN.

The vulnerability is due to insufficient security requirements during the Link Layer Discovery Protocol (LLDP) setup phase of the infrastructure VLAN. An attacker could exploit this vulnerability by sending a malicious LLDP packet on the adjacent subnet to the Cisco Nexus 9000 Series Switch in ACI mode. A successful exploit could allow the attacker to connect an unauthorized server to the infrastructure VLAN, which is highly privileged. With a connection to the infrastructure VLAN, the attacker can make unauthorized connections to Cisco Application Policy Infrastructure Controller (APIC) services or join other host endpoints.

Cisco has released software updates that address this vulnerability. There are workarounds that address this vulnerability.

This advisory is available at the following link:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190703-n9kaci-bypass

Security Impact Rating: High

CVE: CVE-2019-1890

Related:

Cisco Nexus 9000 Series Fabric Switches Application Centric Infrastructure Mode Symbolic Link Path Traversal Vulnerability

A vulnerability in the system shell for Cisco Nexus 9000 Series Fabric Switches in Application Centric Infrastructure (ACI) mode could allow an authenticated, local attacker to use symbolic links to overwrite system files. These system files may be sensitive and should not be overwritable by non-root users. The attacker would need valid device credentials.

The vulnerability is due to incorrect symbolic link verification of directory paths when they are used in the system shell. An attacker could exploit this vulnerability by authenticating to the device and providing crafted user input to specific symbolic link CLI commands. Successful exploitation could allow the attacker to overwrite system files that should be restricted.

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-20190501-fabric-traversal

Security Impact Rating: Medium

CVE: CVE-2019-1836

Related:

  • No Related Posts

Smarts NCM: Cisco Nexus 5k series devices pull-all or pull hardware job shows complete, but there is no configuration information on the GUI

Article Number: 513339Article Version: 5 Article Type: Break Fix



Smarts Network Configuration Manager

The Cisco Nexus 5k devices does discover and appears to complete a pull-all or pull hardware, but does not load any configuration information in the GUI. In reviewing the commmgr and session logs it appears that all communication completed successfully and no indication of a problem. Then NCM tries to parse the data and insert it into the master PostgreSLQ Control Database (controldb), but it fails when the parser encounters the following error in the $VOYENCE_HOME/ncmcore/logs/powerup.log file:

Powerup.log:

DEBUG [com.powerup.configmgr.server.services.repository.impl.DeviceStateXMLMarshaller] (http-apr-8881-exec-5) Unmarshalling config unit of type – PhysicalHardware

ERROR [com.powerup.service.marshal.castor.CastorObjectMarshaller] (http-apr-8881-exec-5) CastorObjectMarshaller.fromXML

org.exolab.castor.xml.MarshalException: element “HardwareElement” occurs more than once. (parent class: com.powerup.configmgr.common.domain.PhysicalHardware)

Caused by: ValidationException: element “HardwareElement” occurs more than once. (parent class: com.powerup.configmgr.common.domain.PhysicalHardware)

location: /PhysicalHardware/HardwareElement


Daemon.log doesn’t show any xml parsing error:

<Message>

<![CDATA[

System Properties pull complete

]]>

</Message></Result><Result config-unit-type=”Identity” status=”1″ error-code=”0″ action-id=”abc000“><Name>Identity</Name>

<Message>

<![CDATA[

Identity pull for <device name> complete

]]>

</Message></Result><Result config-unit-type=”PhysicalHardware” status=”1″ error-code=”0″ action-id=”abc000“><Name>PhysicalHardware</Name>

<Message>

<![CDATA[

PhysicalHardware data changed!!!

]]>

Device has extra hardware details causing NCM DB to fail to parse it.

File hwinvfuncs.inc modified to deflect the extra hardware details pulled from the Nexus devices.

Follow the below steps to implement the workaround:

1) Log into the Device Server or Combination Server with root privileges.

2) Run: source /etc/voyence.conf

3) Navigate to $VOYENCE_HOME/custompackage directory, check if you have cisco/nexus sub directories.

If it doesn’t exist, create the folders, so that you have directory structure as $VOYENCE_HOME/custompackage/cisco/nexus/

4) Copy the attached hwinvfuncs.inc file and place it in the $VOYENCE_HOME/custompackage/cisco/nexus/ directory.

5) Restart the services by running: service voyence restart.

6) Clear the device cache with steps from KB 304993, https://support.emc.com/kb/304993

7) Execute Pull All on the device.

.p

Related:

Re: Principal Switch

I have 2 switch that is trunked each other (edge and core).The core switch have the lowest firmware compared to the edge switch.Is there anything wrong with the “principal” and “local” switch setting from the edge switch?Why the principal and the local switch is a different switch from the edge switch?

HELP ME!!!

EDGE switch

CNBJSSW102# sh wwn switch

Switch WWN is 20:00:00:05:73:be:36:00

CNBJSSW102# sh ver | inc Software next 4

Cisco Nexus Operating System (NX-OS) Software

Software

BIOS: version 1.0.19

loader: version N/A

kickstart: version 5.0(4)

system: version 5.0(4)

CNBJSSW102# sh fcdomain domain-list

VSAN 1

Number of domains: 4

Domain ID WWN

——— ———————–

0xe3(227) 20:01:00:0d:ec:63:ee:81 [Principal]

0x62(98) 20:01:00:0d:ec:8d:39:41

0x0c(12) 20:01:00:0d:ec:a7:2b:c1

0x0e(14) 20:01:00:05:73:be:36:01 [Local]

VSAN 3

Number of domains: 4

Domain ID WWN

——— ———————–

0x03(3) 20:03:00:0d:ec:63:ee:81 [Principal]

0x0a(10) 20:03:00:0d:ec:8d:39:41

0x0c(12) 20:03:00:0d:ec:a7:2b:c1

0x0e(14) 20:03:00:05:73:be:36:01 [Local]

———————————————————————————————————————————————————

CORE switch

CNBJSSW01# sh wwn switch

Switch WWN is 20:00:00:0d:ec:63:ee:80

CNBJSSW01# sh ver | inc Software next 4

Cisco Storage Area Networking Operating System (SAN-OS) Software

Software

BIOS: version 1.0.16

kickstart: version 3.3(4)

system: version 3.3(4)

CNBJSSW01# sh fcdomain domain-list

VSAN 1

Number of domains: 4

Domain ID WWN

——— ———————–

0xe3(227) 20:01:00:0d:ec:63:ee:81 [Local] [Principal]

0x62(98) 20:01:00:0d:ec:8d:39:41

0x0c(12) 20:01:00:0d:ec:a7:2b:c1

0x0e(14) 20:01:00:05:73:be:36:01

VSAN 3

Number of domains: 4

Domain ID WWN

——— ———————–

0x03(3) 20:03:00:0d:ec:63:ee:81 [Local] [Principal]

0x0a(10) 20:03:00:0d:ec:8d:39:41

0x0c(12) 20:03:00:0d:ec:a7:2b:c1

0x0e(14) 20:03:00:05:73:be:36:01

Related:

Re: VxRail – 10Gb + 1GbE

Hi Folks,

I’m using VxRail P470F Full-Flash using onboard network NIC (2x10Gb SFP+ + 2x1GbE).

I’m using the two 10Gb SFP+ onboard ports for the entire traffic (mgmt + data). I would need to know if I can use the 2x1GbE and configure a vSwitch on it for VM data traffic ?

According to the documentation, nothing states that the 2x1GbE should not be used, and technically, nothing prevent me to use these interfaces from vCenter (they are marked as “down” as nothing is connected right now).

Thanks in advance for your answers !

Related: