Cisco 0-day Unpatched Switch Telnet Vulnerability CVE-2017-3881

Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.
P

Patrick Kennedy

Guest
Cisco recently released details of CVE-2017-3881 which is extremely serious. The issue is found in Cisco switches using Cisco IOS and Cisco IOS XE software. The exploit targets the Cisco Cluster Management Protocol and (CMP) of switches with Telnet active. It can allow the remote reboot, reload and remote execution of commands allowing for a malformed request to take over a switch. Cisco is accustomed to finding and patching security issues, but this one was disclosed withotu an immediate patch so we suspect it will take engineering to fix. If you run Cisco switches, you need to be aware of this vulnerability.

About Cisco 0-Day CVE-2017-3881

Cisco Logo

Here is an excerpt on the vulnerability:

A vulnerability in the Cisco Cluster Management Protocol (CMP) processing code in Cisco IOS and Cisco IOS XE Software could allow an unauthenticated, remote attacker to cause a reload of an affected device or remotely execute code with elevated privileges.

The Cluster Management Protocol utilizes Telnet internally as a signaling and command protocol between cluster members. The vulnerability is due to the combination of two factors:

The failure to restrict the use of CMP-specific Telnet options only to internal, local communications between cluster members and instead accept and process such options over any Telnet connection to an affected device, and
The incorrect processing of malformed CMP-specific Telnet options.

An attacker could exploit this vulnerability by sending malformed CMP-specific Telnet options while establishing a Telnet session with an affected Cisco device configured to accept Telnet connections. An exploit could allow an attacker to execute arbitrary code and obtain full control of the device or cause a reload of the affected device.

Cisco will release software updates that address this vulnerability. There are no workarounds that address this vulnerability.

(Source: Cisco)

Cisco CVE-2017-3881 Impacted Models

Here is the impacted product list. Warning, it covers hundreds of Cisco switch models.

Cisco Catalyst 2350-48TD-S Switch
Cisco Catalyst 2350-48TD-SD Switch
Cisco Catalyst 2360-48TD-S Switch
Cisco Catalyst 2918-24TC-C Switch
Cisco Catalyst 2918-24TT-C Switch
Cisco Catalyst 2918-48TC-C Switch
Cisco Catalyst 2918-48TT-C Switch
Cisco Catalyst 2928-24TC-C Switch
Cisco Catalyst 2960-24-S Switch
Cisco Catalyst 2960-24LC-S Switch
Cisco Catalyst 2960-24LT-L Switch
Cisco Catalyst 2960-24PC-L Switch
Cisco Catalyst 2960-24PC-S Switch
Cisco Catalyst 2960-24TC-L Switch
Cisco Catalyst 2960-24TC-S Switch
Cisco Catalyst 2960-24TT-L Switch
Cisco Catalyst 2960-48PST-L Switch
Cisco Catalyst 2960-48PST-S Switch
Cisco Catalyst 2960-48TC-L Switch
Cisco Catalyst 2960-48TC-S Switch
Cisco Catalyst 2960-48TT-L Switch
Cisco Catalyst 2960-48TT-S Switch
Cisco Catalyst 2960-8TC-L Compact Switch
Cisco Catalyst 2960-8TC-S Compact Switch
Cisco Catalyst 2960-Plus 24LC-L Switch
Cisco Catalyst 2960-Plus 24LC-S Switch
Cisco Catalyst 2960-Plus 24PC-L Switch
Cisco Catalyst 2960-Plus 24PC-S Switch
Cisco Catalyst 2960-Plus 24TC-L Switch
Cisco Catalyst 2960-Plus 24TC-S Switch
Cisco Catalyst 2960-Plus 48PST-L Switch
Cisco Catalyst 2960-Plus 48PST-S Switch
Cisco Catalyst 2960-Plus 48TC-L Switch
Cisco Catalyst 2960-Plus 48TC-S Switch
Cisco Catalyst 2960C-12PC-L Switch
Cisco Catalyst 2960C-8PC-L Switch
Cisco Catalyst 2960C-8TC-L Switch
Cisco Catalyst 2960C-8TC-S Switch
Cisco Catalyst 2960CG-8TC-L Compact Switch
Cisco Catalyst 2960CPD-8PT-L Switch
Cisco Catalyst 2960CPD-8TT-L Switch
Cisco Catalyst 2960CX-8PC-L Switch
Cisco Catalyst 2960CX-8TC-L Switch
Cisco Catalyst 2960G-24TC-L Switch
Cisco Catalyst 2960G-48TC-L Switch
Cisco Catalyst 2960G-8TC-L Compact Switch
Cisco Catalyst 2960L-16PS-LL Switch
Cisco Catalyst 2960L-16TS-LL Switch
Cisco Catalyst 2960L-24PS-LL Switch
Cisco Catalyst 2960L-24TS-LL Switch
Cisco Catalyst 2960L-48PS-LL Switch
Cisco Catalyst 2960L-48TS-LL Switch
Cisco Catalyst 2960L-8PS-LL Switch
Cisco Catalyst 2960L-8TS-LL Switch
Cisco Catalyst 2960PD-8TT-L Compact Switch
Cisco Catalyst 2960S-24PD-L Switch
Cisco Catalyst 2960S-24PS-L Switch
Cisco Catalyst 2960S-24TD-L Switch
Cisco Catalyst 2960S-24TS-L Switch
Cisco Catalyst 2960S-24TS-S Switch
Cisco Catalyst 2960S-48FPD-L Switch
Cisco Catalyst 2960S-48FPS-L Switch
Cisco Catalyst [...]

The post Cisco 0-day Unpatched Switch Telnet Vulnerability CVE-2017-3881 appeared first on ServeTheHome.

Related posts:
  1. WD My Net Switch – 8 Port Gigabit Ethernet Unmanaged Network Switch Review
  2. A New PCIe Switch Option: The Microsemi Switchtec PCIe Gen3 Switch
  3. QCT QuantaMesh T1048-LY4A review – our datacenter lab switch
  4. Tripp Lite NSU-G24C2P08 Review – PDU and PoE switch 1U combo



Continue reading...
 
  • Like
Reactions: T_Minus

cheezehead

Active Member
Sep 23, 2012
723
175
43
Midwest, US
Um, the first vulnerability is anyone using telnet. Really surprised they haven't stepped up and just dropped telnet and tell everyone just to use SSH.
 

PigLover

Moderator
Jan 26, 2011
3,184
1,545
113
Apparently this was "discovered" by Cisco after reviewing the CIA/Wikileaks data. Sheesh - you'd figure anybody would know Telnet is vulnerable...
 

Evan

Well-Known Member
Jan 6, 2016
3,346
598
113
Did a double take when I saw telnet, can't imagine why it would be used for anything even something not secure today. Not just from a security aspect but the fact it's hardly the best protocol.
 

Terry Kennedy

Well-Known Member
Jun 25, 2015
1,140
594
113
New York City
www.glaver.org
Um, the first vulnerability is anyone using telnet. Really surprised they haven't stepped up and just dropped telnet and tell everyone just to use SSH.
That would probably go over better if more of the affected products had a decent (modern, secure) SSH implementation. In order to SSH to a lot of the devices on that list, you need to enable the insecure diffie-hellman-group1-sha1 key exchange algorithm.
Emphasis on the ""
Cisco seems well prepared to join the Internet of [Insecure] Things community. Their "smart install" software also has a well-traveled list of vulnerabilities going back to at least 2011. Apparently they've given up trying to fix it, as their most recent advisory (from this month) says:
Cisco mealy-mouth said:
Cisco does not consider this a vulnerability in Cisco IOS, IOS XE, or the Smart Install feature itself but a misuse of the Smart Install protocol, which does not require authentication by design. Customers who are seeking more than zero-touch deployment should consider deploying the Cisco Network Plug and Play solution instead.
So, instead of disabling this insecure feature by default, or only enabling it if there is no configuration already present on the switch, Cisco continues to foist insecure software on unsuspecting users, with a cop-out of "you should have read the manual".
 
Last edited:

whitey

Moderator
Jun 30, 2014
2,766
868
113
41
Yeah ssh PKI key distribution not all folks have cracked/solved yet. It's a major PITA in large HPC environments (other than managing an unruly known_hosts file or thinking abt rsh but that's just as bad as telnet). I can see silly ass Cisco 'thinking' it is still kosher to use telnet for control plane switch traffic as they think it is contained to that transmission plane...until it's NOT! HAHA
 

whitey

Moderator
Jun 30, 2014
2,766
868
113
41
I have this same image but mine reads 'Everytime you deploy a security virtual appliance God kills a kitten' LOL

Plays on the concept/theory that 'bolting on security' after the fact or failing to make it a priority and ensuring it is inherent w/in the product from the get-go is a recipe for disaster/poor code. :-D
 

Evan

Well-Known Member
Jan 6, 2016
3,346
598
113
Yeah ssh PKI key distribution not all folks have cracked/solved yet. It's a major PITA in large HPC environments (other than managing an unruly known_hosts file or thinking abt rsh but that's just as bad as telnet). I can see silly ass Cisco 'thinking' it is still kosher to use telnet for control plane switch traffic as they think it is contained to that transmission plane...until it's NOT! HAHA
Getting a bit off topic sure but known_hosts is not that bad... depends on your scale but we do it on ~500 node systems and just manage, yes not perfect but works for the tightly controlled environment like ours.
Just have your installation routines pass down the initial configuration and key needed so you can run the get keys process and build the file automatic before pushing it back out to all hosts.
 

fractal

Active Member
Jun 7, 2016
309
69
28
33
Telnet, are you ****ing kidding me
Going completely off topic here ... I have had several machines compromised by SSH vulnerabilities. I have had zero, zippo, nada, none compromised by Telnet vulnerabilities. Ok, Ok, go ahead and get on your high horse about my needing to keep my machines patched up to date....

Now, I too recommend keeping an up to date ssh with limited ciphers and all that, but this hatred of Telnet originated back in the days of hubs when everyone listened in on everything. Nowadays, the only people who can listen in on everything have the magic keys for SSH so who's fooling who by saying SSH is better than Telnet ;(

Returning to the OP ... this is a biggie for people who have not segmented their management traffic...
 

whitey

Moderator
Jun 30, 2014
2,766
868
113
41
Nowadays, the only people who can listen in on everything have the magic keys for SSH so who's fooling who by saying SSH is better than Telnet ;(
Or a SPAN port/TAP/inline device :-D then there's always SSH MITM which FAR too many folks blindly and furiously just click through in a 'go away' pissed off manner :-D

Man I work with some SCARY folks, the level of 'all up in your business' is enough to ALWAYS assume our InfoSec team can see EVERYTHING no matter what protocol/patch set you are at damn near! LOL
 

Evan

Well-Known Member
Jan 6, 2016
3,346
598
113
We have a great collection of boxes that isolate different traffic and do all sorts of snooping on it including boxes that have keys for encryption to decrypt that traffic that keys are available for and do some other stuff for traffic we don't have keys for :)

But as somebody pointed out about segmented networks I would assume most people are putting all admin console etc in seperate security zones and access control between and if justified usin jump hosts and buffer zones.

Just the same there is a point here , the telnet service itself is indeed probably more secure than ssh, but telnet traffic and clear text password in all their glory is just saying please hack me if you travel and network that's not in your complete control.