The Newest Cisco Vulnerabilities Demonstrate All That’s Wrong with Today’s Patching Processes

Last month’s security advisories published by the Cisco Security reveals several significant vulnerabilities in Cisco IOS and IOS XE software. Overall, there were 28 high impact and 13 medium impact vulnerabilities in these advisories, with a total 46 new CVEs. All Cisco products running IOS were impacted, including IOS XR Software, NX-OS Software, and RV160 VPN Router.

The sheer quantity of vulnerabilities should raise alarms but so should the severity. Based on my own analysis of two sets of advisories — Zone-based firewall feature vulnerabilities (CVE-2020-3421 and CVE-2020-3480 ) and DVMRP feature vulnerabilities (CVE-2020-3566 and CVE-2020-3569) — their impact will be very significant. Both advisories seriously leave enterprises exposed, in ways that never needed to or should have happened.

Zone-based firewall vulnerabilities expose networks to TCP attacks

The multiple vulnerabilities Cisco reported in its Zone-Based Firewall feature of IOS (CVE-2020-3421, CVE-2020-3480) leave enterprises network open to simple L4 attacks.

More specifically, Cisco advisory notes that these vulnerabilities could allow an unauthenticated, remote attacker to cause the device to reload or stop forwarding traffic through the firewall. Cisco reports that “The vulnerabilities are due to incomplete handling of Layer 4 packets through the device.” In such cases, the attacker could craft a sequence of traffic and cause a denial of service.

Organizations will need to patch affected devices as there are no workarounds. As Cisco explains in CVE-2020-342, “Cisco has released software updates that address these vulnerabilities. There are no workarounds that address these vulnerabilities.”

However, patches themselves introduce risks. They involve OS-level changes, which in the rush to publish often contain their own bugs. Network administrators need time to test and stage the new patch. In the meantime, the devices remain open for a simple L4 attack that could potentially take down their networks.

Handling of DVMRP vulnerabilities raises serious questions.

Even worse was how Cisco handled vulnerabilities Cisco IOS XR’s Distance Vector Multicast Routing Protocol (DVMRP) (CVE-2020-3566, CVE-2020-3569). Cisco originally published this Security Advisory on Aug 28, 2020, when Cisco’s response team became aware of exploits leveraging this vulnerability in the wild. But it took a month, yes, a month, before they provided some means for enterprises to address this threat.

According to the Cisco advisory, bugs in DVMRP “could allow an unauthenticated, remote attacker to either immediately crash the Internet Group Management Protocol (IGMP) process or make it consume available memory and eventually crash. The memory consumption may negatively impact other processes that are running on the device.”

In short, an attacker could craft an IGMP traffic to degrade packet handling and other processes in the device. These vulnerabilities affect Cisco devices running any version of the IOS XR Software with multicast routing enabled on any of its interfaces. For a month, Cisco announced to the world that the door was wide open on any network running multicast.

To make matters worse, last month’s security advisory does little to lock that door. There are no patches to fix the vulnerability or even workarounds to temporarily address the problem. Instead, Cisco shared two possible mitigations, but both are limited.

One mitigation suggests rate limiting the IGMP protocol. Such an approach requires customers to first understand the normal rate of IGMP traffic, which would require network analysis of past data that if not done correctly could cause other issues, such as blocking legitimate traffic.

The second mitigation proposed adding an ACL that denies DVMRP traffic for a specific interface. But this mitigation, though, only helps those interfaces that do not use DVMRP traffic, leaving other interfaces exposed.

Enough with the pain of patching appliances

In both cases, enterprise networks were left seriously compromised by vulnerabilities in the very appliances meant to connect or protect them. And this is hardly the first time (check out this post for other examples).

Appliance vendors apologize, rush to provide assistance in the form of an update, but its enterprises who really pay the burden. Security and networking teams need to stop what they’re doing, and work double-time to address vulnerabilities ultimately created by the vendors. It’s pressurized, intense race to fix problems before attackers can exploit them.

At what point will appliance vendors stop penalizing IT and start solving the problems themselves? The sad answer — never.

The problem isn’t Cisco (or any other vendor’s) security group. It’s the nature of appliance. As long as vendors cling to aging appliance architectures, enterprises will suffer the pains of patching. Vendor security teams will invariably have to choose between alerting the public and providing corrective action.

The answer? Make the vendor responsible for your security infrastructure. If they’re not going to fix the problem – and stand behind it — then why should you be the one who has to pay for it? Cloud providers maintains the infrastructure for you and so should appliance vendors. With cloud providers, there are no gaps between vulnerability notification and proactive action for attackers to exploit. If a vulnerability exists, cloud providers can patch infrastructure hood and add mitigations transparently for all users everywhere — instantly.

That’s the power of the cloud and it’s particularly relevant as we start to look at SASE platforms. The advocacy for appliance-based SASE platforms will only continue to lead enterprises down this never-ending patch pain. Moving processing to the cloud resolves that pain for good. Anything else leaves enterprises suffering unprotected in this new age of networking and security.