Cisco Nexus 2000 Series Fabric Extender Software Default Credential Vulnerabilit

[icecream-guy]

Nyaaa

Now every Nexus 2000 fabric extender is vulnerable due to missing password.


https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20160223-nx2000

and even better

Cisco has not released software updates that address this vulnerability. Workarounds that mitigate this vulnerability are not available.


Luckily it's a physical vulnerability

[deanwebb]

I say Cisco, you say Security!

CISCO!

(crickets chirp)

[Otanx]

Sigh, finish patching ASAs, then repatch the ASAs because of bugs. Now patch Nexus. Can we get a IOS vulnerability so I can patch those next?

-Otanx

[mmcgurty]

Sigh, finish patching ASAs, then repatch the ASAs because of bugs. Now patch Nexus. Can we get a IOS vulnerability so I can patch those next?

-Otanx

Be careful what you wish for!


Sent from my iPhone using Tapatalk

[Otanx]

Sigh, finish patching ASAs, then repatch the ASAs because of bugs. Now patch Nexus. Can we get a IOS vulnerability so I can patch those next?

-Otanx

Be careful what you wish for!


Sent from my iPhone using Tapatalk

I am half serious. Our configuration baseline has drifted with different versions running on different switches depending on when and who deployed it. We are too busy to fix it now, but if a major vulnerability comes out then that will be top priority to patch. Then all of our devices will be back to a baseline OS again. We have gotten much more mature with change management so if I can get them all fixed they shouldn't drift again.

-Otanx

[wintermute000]

I'm in two minds about this kind of OS standardisation. Sure it sounds like the sensible thing to do, but in many cases (e.g. simple L2 access switches with no fancy features like dot1x or dhcp snooping etc.) there is practically zero gain. Ditto even with 'normal', non-internet routers that are more or less just L3 forwarding using standard protocols (or even EIGRP lol). And we all have war stores from VSS / ISSU / NX-OS upgrade kabooms. Or 3750X early IOS 15 code bugs. etc.

Then again you don't want to end up with a total mishmash or even worse devices outside of crappy edge switches that are running software half a decade old or the like. And it makes things a lot more predictable (i.e. if you know config X works with hardware Y on software Z, its a nice baseline).

Then again, this is what I see all the frickin time in consultancy, and security/internet edge aside, it hasn't seemed to hurt anybody too much. The only driver for upgrade seems to be for features.

Don't get me wrong, I'm not saying standardisation isn't bad - but I'm just querying the actual cost/benefit in some instances, esp very minor sub-version changes, or pure L2 access switching. I've been there... (racking up ridiculous overtime $$$ upgrading hundreds of L2 edge switches from say 12.2.55SE to 12.2.58SE... LOLOLOL... net result? not a single frickin thing).

If you really did things by the book and did 6 month or annual patch cycles etc. in a large enterprise (say 10k endpoints+) its basically a full time job in itself....

Internet facing/security devices no question keep them as up to date as your outage windows can tolerate.

[Otanx]

Right, my drive for OS standardization is for vulnerability management, and configuration management. If I have seven different versions of OS running on my 3560X switches I have to identify if any of them are impacted by a vulnerability each time. If I have one OS version I can easily identify impact once, and decide if we need to patch or not. Then with multiple OS versions if I do decide to patch I am reading multiple release notes to identify any issues. Also this helps automate the patches. I can patch one or two by hand, and if they are good push the upgrade to all "B" devices, then once they are done push to all "A" side.

Same with configs. A good example is tacacs. We moved most of our gear to the new style of identifying the servers. However, some devices are on older code that does not support the new version. So if I have to update a tacacs key, or modify an IP I have to identify the switches using the new style vs old, and push two different changes. Of course we shouldn't have moved to the new style until they were all ready, but it happened. Same with testing a change. If I want to add a feature I can test once in the lab, and not worry about different versions doing different things. Not a major concern as we don't do anything fancy, but it will probably bite me when I least expect it.

-Otanx

[NetworkGroover]

On a side note, have you heard that Arista runs a single software image on all of its platforms? 

[deanwebb]

On a side note, have you heard that Arista runs a single software image on all of its platforms? 

But... but... how will I complain about code forks and mismatched code paths between product lines?

Does it at least have a management utility written in java?

[NetworkGroover]

I suppose you could complain about early feature trial code.. but that usually works, so....

No luck on the Java piece I'm afraid.

Sorry to disappoint!

[Reggle]

I believe Brocade does that too, one or maybe a few images for all platforms.

[Dieselboy]

Internet facing/security devices no question keep them as up to date as your outage windows can tolerate.

I cannot do this, because our internet router also does SSL VPN. Cisco introduced a feature in the IOS SSL VPN which expect the SSL VPN client to reply to a DTLS message to request DTLS, else it falls back to TCP, which is no good. So as we have VPN Phones, which very much need DTLS, I'm stuck on an older code which does not have this feature implemented because there is no plan to update the VPN client on the Cisco phone handsets to support the feature.