faulty "role-based access control evaluation"
This is proves the difference between (real) software engineers and run-off-the-mill monkey coders.
Cisco has doled out yet more security updates for its IOS and IOS XE network operating systems, which, we are obliged to remind you, is its scheduled six-monthly patch run and not the usual "oh bugger" state of affairs. In the latest run we have a dozen patches for 13 vulnerabilities rated "high", including ones that cause a …
I did Systems Integration and Test for a Cisco kid once and would like to think I would have caught this or anything else development threw our way. SI&T is always a seriously underrated and underfunded department, the goalkeeper who stops own goals due to an eye for detail and an understanding even real software engineers have bad moments.
For example, you probably meant 'run of the mill' rather than 'run off the mill'.
My reading of this is that on IISR800's/CGR1000's you have the option of installing an add-on server module. The RBAC issue is around a user with access to the router potentially having access to the guest OS without the correct privilege level (from the linked vulnerability notice: "Exploitation of this vulnerability could allow the attacker to successfully log in to the Guest OS using a low-privileged IOS user credentials."). The intended design is to only allow access with level 15 privileges.
While I'm not disputing it is a bug, guest access to the router is likely to mean a user with restricted access rather than an unauthenticated user - knowing how Cisco's AAA system works and the ability to assign roles to privilege levels, the "only priv 15 should be allowed access" looks like an exception.
I would have thought restricting command sets would have been a suitable workaround, but Cisco doesn't list this as an option and I don't have access to any of these devices to test further.
This post has been deleted by its author
Cisco has abysmally bad security for decades now... on different product lines... with completely new implementations. I mean just by chance they should have found some competent programmers starting a new project.
I mean even Microsoft managed to clean up their mess for a while after XP.
"Cisco has abysmally bad security for decades now... on different product lines... with completely new implementations."
Compared to Cisco, Microsoft have significantly less variety across their product lines. Cisco list >820,000 line items in their current pricing spreadsheet. While a significant portion of that is hardware, the associated software may run across multiple product lines with very different intended uses.
Add in regular acquisitions of third party products (particularly management tools) and you have a lot of security issues that have minimal impact to large portions of the customer base.
For this particular vulnerability, I would suggest that the Cisco solution was developed in association with customers (it's basically a small router integrated with 3G/4G connectivity, wifi and an optional server for remote data collection/monitoring purposes) and the method used to provide connectivity between the router and the server didn't consider potential customer requirements to separate management roles.
I've never interviewed at Cisco, but if its anything like the company I interviewed at recently for a C++ system and network dev the problem is with the interviewers. Instead of being asked things like "whats the first thing you do after mapping a structure to network data assuming you received enough data to fill it" *** or "whats a good way to receive signals in a multithreaded process*** they asked crap like "tell us what design patterns you know" and "what features do you like in C++17".
I mean FFS, get a grip on the problem space and ask the correct questions then you'll get people who know what they're doing.
*** (questions I've asked candidates myself when I've been the interviewer)
- Change numeric fields to host byte order
- Use sigwait() in a dedicated thread.
So I switched from HP gear to Cisco a few years ago, but recently discovered that our in-contract hardware, with an EOL of 2022 is no longer receiving security updates, even though that's exactly what the service contract promises.
For now I'm willing to suspend disbelief and assume left hand hasn't quite understood what right hand has done. Waiting to hear back from their legal dept. If they don't start issuing security updates for in-contract hardware, then there is no way I'll ever get permission to buy any cisco kit ever again - and I'm quite sure I'm not the only one.
"After the first year and for Operating System SW -where available- we will provide bug fixes, maintenance releases, workarounds or patches for a period of 4 years for operating system software. Bear in mind that it may be necessary to use software upgrade release to correct a reported problem."
So you buy a hardware platform, and after a bit Cisco says newer software won't be supported on that hardware, and then later still says there are vulnerabilities that are only fixed by newer software. That combination makes your hardware obsolete years before EOL?
Why do people buy Cisco, when their attitude is "fuck you!"?
The ASA 5505 is really odd device support wise. For example the ASA 5510 & 5505 run the exact same ASA OS image file for 126.96.36.199 release but the 5510 was EOL 12 months ago. The 5505 does have 9.2.4 as the latest version available. Wonder if the 9.2.4 will run on a ASA 5510.
The one question I would have is when did you buy the 5505?
While the 5505 was a shipping product until the end of 2017 (it first shipped in 2006), it had been replaced in early 2015 by a newer product that supported later software releases and had hardware that supported modern encryption AND the sales channel was recommending either waiting for the 5506X or purchasing 5512X's in 2014 as the 5505's didn't run newer ASA code. The ASA software for the platform reached end-of-support in September 2018 with the final maintenance release of 9.1(7).
I would suggest that if you purchased the firewalls after ~2014 and your re-seller didn't mention it was a dead platform walking,you have been very unlucky. The 5505 looked dead in 2012 when the first ASA X models were released due to increases in memory/CPU/encryption hardware and Cisco initially didn't plan to replace the 5505, but it proved too popular and they had to rush out the 5506X and the subsequent 5508X.
AC: The one question I would have is when did you buy the 5505?
If you check my link to community.cisco.com in the OP you'll see the answer to your question. You may have made a different decision based on the same criteria, but we purchased way before the end of sale date was even announced.
If I'd known that Cisco wouldn't honour it's contract, and retire the software early (in breach of contract) then the ROI wouldn't have stood up and I'd have proposed an alternative, but we have to go into contracts assuming good faith.
Proprietary vs Open Source? That is the question. Proprietary, you don't have visibility into what vulnerabilities/backdoors exist until it's "discovered" and may never get patched. Open Source, everyone can view the source code, including miscreants, but once "discovered" hopefully gets patched quickly.
So, to keep the spies out and the bugs in which order to I cascade my firewalls?
Outside <--> Linux <--> Cisco <--> Huawei <--> CheckPoint <--> Inside
Outside <--> Linux <--> Huawei <--> Cisco <--> CheckPoint <--> Inside
Outside <--> Linux <--> Cisco <--> Huawei <--> CheckPoint <--> Inside
Outside <--> Cisco <--> Huawei <--> Linux <--> CheckPoint <--> Inside
Outside <--> Huawei <--> Cisco <--> Linux <--> CheckPoint <--> Inside
Outside <--> CheckPoint <--> Huawei <--> Cisco <--> Linux <--> Inside
... ... ... ...
dam... there are just so many combinations! ;-)
Biting the hand that feeds IT © 1998–2019