Another batch of critical bugs in Cisco products raises tough questions.
Cisco product security continues to demand regular urgent patching from users: the company last week pushing out an advisory after multiple critical (CVSS 9.8) vulnerabilities were found in a family of VPN routers. The bugs grant any unauthenticated, remote attacker the ability to execute code as all-powerful root user.
"These vulnerabilities exist because HTTP requests are not properly validated" said Cisco.
"An attacker could exploit these vulnerabilities by sending a crafted HTTP request to the web-based management interface of an affected device [then]... remotely execute arbitrary code on the device".
The bugs affect the following products with a firmware release earlier than 1.0.01.02:
- RV160 VPN Router
- RV160W Wireless-AC VPN Router
- RV260 VPN Router
- RV260P VPN Router with POE
- RV260W Wireless-AC VPN Router
Cisco product security: tackling the issues before the bug bounty programme finds them would save pain...
Cisco's come under regular fire from security professionals for the quality of the software in its products.
A trio of critical bugs in Cisco Data Center Network Manager (DCNM) disclosed in 2020 stand out for rudimental security errors, including hard coded credentials. Once again, they gave a unauthenticated attacker remote code execution as root. That trio of bugs (CVE-2019-15975, CVE-2019-15976, CVE-2019-15977, were among a colossal 120+ vulnerabilities in the product found by just one security researcher.
The Stack meanwhile counted over 220 Cisco CVEs with a 2021 prefix on cve.mitre.org, just 39 days into the year.
What's the company doing to improve product security? A spokesperson told us: "The majority of our disclosures are vulnerabilities that we find internally. We disclose these vulnerabilities with a goal of helping customers understand and manage their risk. Our commitment is to be trustworthy, transparent, and accountable.
They added: "Our goal at Cisco is to always try to reduce the number of vulnerabilities and continuously enhance our products. Unfortunately, despite the best efforts of technology vendors, security vulnerabilities do still occur. We are actively developing new tools and techniques to identify and resolve these issues before they reach our customers, including the use of the Cisco Secure Development Lifecycle."
Start with supply chain security?
Critics argue that better DevSecOps or QA processes should catch some of these issues before a bug bounty programme participant does (by which point customers are already exposed). The Stack holds that regulators should start to hold product vendors responsible for poor out-of-the-box security, particularly on basics like hard-coded credentials -- although implementation of such regulation needs to take into account complex issues around pressure on innovation and cost for smaller vendors. (The US's Solarium Commission report makes some suggestions, while the UK has been pushing forward on requirements for IoT security).
Ilkka Turunen, Field CTO at open source software security and intelligence specialist Sonatype told The Stack: "Most companies procuring devices don't have any standards about the software patch-ability, just a yes/no and update cycle type basic requirements. We need to include basic supply chain questions into that like a SBOM [software bill of materials] requirement and a patching plan for all items for this to take hold.
"To me [such product security/quality issues] are a chicken and egg problem: companies get it wrong because it's not widely understood that today the software component of a hardware device is just as important. So what happens is the software is developed to some basic standard, without the oversight or approval we'd expect from a pure software product, and so it leads down to these obvious glaring things.
"Their customers for the most part being ops teams probably don't know to demand it either, because they see the control software as a necessary evil. If I had my wish, every customer would demand a SBOM for the product and the vendor should be able to justify a plan for keeping them maintained to a certain period. That would force these vendors to change their dev behaviour and start placing controls on how the software is done and making it more upgradeable in the modern sense. We're seeing it in software development standards in some spaces like the PCI Secure Software Standard, so there is precedent that companies could follow."
