{"id":35313,"date":"2020-06-02T12:45:00","date_gmt":"2020-06-02T12:45:00","guid":{"rendered":"http:\/\/f105c1a6-876a-4301-97dc-77fda0d1c0a5"},"modified":"2020-06-02T12:45:00","modified_gmt":"2020-06-02T12:45:00","slug":"cisco-warns-these-nexus-switches-have-been-hit-by-a-serious-security-flaw","status":"publish","type":"post","link":"https:\/\/www.threatshub.org\/blog\/cisco-warns-these-nexus-switches-have-been-hit-by-a-serious-security-flaw\/","title":{"rendered":"Cisco warns: These Nexus switches have been hit by a serious security flaw"},"content":{"rendered":"
<\/div>\n

Cisco has warned customers with Nexus switches running its NX-OS software to install updates to address a serious flaw that allows a remote attacker to bypass network access controls and route malicious internet traffic to internal networks. <\/p>\n

This bug, tracked as CVE-2020-10136, can be used to trigger a denial of service on affected Nexus switches or, more worryingly, route traffic from an attacker’s machine to a target’s internal network after bypassing input Access Control Lists (ACLs) for filtering incoming internet traffic. <\/p>\n

\n

Networking<\/span><\/h3>\n<\/div>\n

Several of Cisco’s widely used Nexus switches harbor a flaw that causes the device to “unexpectedly decapsulate and process IP in IP packets that are destined to a locally configured IP address, even when no tunnel configuration is present”. <\/p>\n

The IETF RFC 2003 specification for the IP-in-IP tunneling protocol<\/a> allows for IP packets to be wrapped or encapsulated inside other IP packets, with the traffic remaining unencrypted at all times. <\/p>\n

Vijay Sarvepalli of the US CERT Coordination Center (CERT\/CC) explains that the protocol unwraps the inner IP packet<\/a> and forwards it through IP routing tables, but a device becomes vulnerable if it accepts these packets from anywhere without restrictions. <\/p>\n

“An IP-in-IP device is considered to be vulnerable if it accepts IP-in-IP packets from any source to any destination without explicit configuration between the specified source and destination IP addresses,” writes Sarvepalli. <\/p>\n

And that’s the problem affecting multiple Cisco Nexus NX-OS devices that support IP-in-IP packet encapsulation and decapsulation: they aren’t meant to decapsulate and process any IP in IP traffic to a device’s tunnel interface unless it’s been manually configured with ACL inbound tunnel controls.<\/p>\n

\n<\/section>\n

“A successful exploit could cause the affected device to unexpectedly decapsulate the IP in IP packet and forward the inner IP packet. This may result in IP packets bypassing input access control lists (ACLs) configured on the affected device or other security boundaries defined elsewhere in the network,” Cisco notes<\/a>. <\/p>\n

“Any input ACL configured on an inbound interface of the affected device is evaluated against the IP fields on the carrier IP packet prior to decapsulation; it would not be evaluated on the passenger IP packet,” Cisco further explains. <\/p>\n

“This may result in the passenger IP packet bypassing the intended ACL filtering. This may also allow the passenger IP packet to bypass other security boundaries that might be defined in the network path to the affected device in the presence of network filtering techniques that only inspect the outer IP header and not the inner IP packet.”<\/p>\n

Beyond this, an attacker who repeatedly exploits the bug can cause the device’s network stack to crash, resulting in a denial of service on the affected switch. <\/p>\n

Cisco has given the bug a severity score of 8.6 out of a possible 10. <\/p>\n

CERT\/CC says the bug could result in a reflective distributed denial-of-service attack, information leakage and network control bypass. <\/p>\n

For those who can’t immediately install updates, CERT\/CC’s Sarvepalli says affected customers can prevent IP-in-IP packets by filtering IP protocol 4 packets at the upstream router or another device. Sarvepalli stresses that this filtering is for IP protocol header value of 4, as opposed to IPv4.<\/p>\n

Cisco also suggests this measure, but first advises customers to use “infrastructure access control lists (iACLs) to allow only strictly required management and control plane traffic that is destined to the affected device”.<\/p>\n

Yannay Livneh, the security researcher who reported the bug to Cisco, has published proof-of-concept exploit code on GitHub<\/a> for admins to use to test whether they have vulnerable Nexus devices on the network. The code lets admins verify whether the device supports IP-in-IP encapsulation from arbitrary sources to arbitrary destinations. <\/p>\n

However, Cisco notes that it has not observed malicious activity exploiting this flaw. <\/p>\n

Affected Nexus switches include:<\/p>\n