Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Communications Networking Privacy Security

Hundreds of Cisco Switches Vulnerable To Flaw Found in WikiLeaks Files (zdnet.com) 76

Zack Whittaker, writing for ZDNet: Cisco is warning that the software used in hundreds of its products are vulnerable to a "critical"-rated security flaw, which can be easily and remotely exploited with a simple command. The vulnerability can allow an attacker to remotely gain access and take over an affected device. More than 300 switches are affected by the vulnerability, Cisco said in an advisory. According to the advisory, the bug is found in the cluster management protocol code in Cisco's IOS and IOS XE software, which the company installs on the routers and switches it sells. An attacker can exploit the vulnerability by sending a malformed protocol-specific Telnet command while establishing a connection to the affected device, because of a flaw in how the protocol fails to properly process some commands. Cisco said that there are "no workarounds" to address the vulnerability, but it said that disabling Telnet would "eliminate" some risks.
This discussion has been archived. No new comments can be posted.

Hundreds of Cisco Switches Vulnerable To Flaw Found in WikiLeaks Files

Comments Filter:
  • by subk ( 551165 ) on Monday March 20, 2017 @03:04PM (#54076681)
    You deserve to have this happen to you.
    • Where telnet is still a thing, and last I checked was on by default.

      • How about "Welcome to Cisco, Where security was never a thing, and we always insert back doors." I mean, if you want to be accurate.

  • by acoustix ( 123925 ) on Monday March 20, 2017 @03:06PM (#54076693)

    That means someone would have to be dumb enough to
    1) Have the mgmt of the switch be publicly available
    2) Have Telnet enabled.

    Don't get me wrong, it's a bad bug. But a security-minded admin should not have these problems.

    • by HumanWiki ( 4493803 ) on Monday March 20, 2017 @03:14PM (#54076767)

      That means someone would have to be dumb enough to
      1) Have the mgmt of the switch be publicly available
      2) Have Telnet enabled.

      Don't get me wrong, it's a bad bug. But a security-minded admin should not have these problems.

      Err.. yes/no..

      If I was going to attempt to exploit something like this, I'd assume most would be inaccessible from the internet as a general use or would be white listed only..

      What I WOULD do is use this in conjuction with a machine level hack/compromise inside their network and then run amuk from there.. That's much easier to do and less will have full firewall off from within their networks from all PC segments.

      • by skids ( 119237 )

        Most switches support ACLs on all services, and/or on switch SVIs (if you don't have prohibitively many of those), and/or CoPP, so you can tell the switch not to talk to anything but your management stations. You just have to set things up so you can alter those ACLs en-masse when needed. No need for a firewall, really, as long as you aren't using ridiculous utilities that do not belong on a switch in the first place.

        That said, there's pretty much zero reason to use telnet these days, and even the last ve

        • by HumanWiki ( 4493803 ) on Monday March 20, 2017 @03:54PM (#54077081)

          Most switches support ACLs on all services, and/or on switch SVIs (if you don't have prohibitively many of those), and/or CoPP, so you can tell the switch not to talk to anything but your management stations. You just have to set things up so you can alter those ACLs en-masse when needed. No need for a firewall, really, as long as you aren't using ridiculous utilities that do not belong on a switch in the first place.

          That said, there's pretty much zero reason to use telnet these days, and even the last vestiges of FTP and TFTP are starting to become unnecessary as more switch facilities are supporting SCP or (sigh) SFTP. Sigh on the latter because you really are putting a lot of trust in the other end of the connection because SFTP subprotocol code is not production quality code, even in the openSSH tree. But at least someone has to actually own the endpoint to get at it.

          Yes, I understand that, that's great, a lot of that is best practice and in all my years and all the companies I've worked for and systems I've helped migrated, worked on, have managed, etc. I can count on one hand the number of them that were properly configured with ACLs blocking of stuff from user segments, properly configured interconnectivity, complex passwords, clear text protocls being fully off, etc. Not allowing this station etc. And you think your management computers are safe? not really. I've seen plenty of bastion systems being used as source mgmt points for all manner of systems and lazy engineers using web browsers on them to download whatever utility or tool they need. Just because you've locked out your stuff to a bastion server doesn't mean it's protected, it just means your compromise point is now actually pinpointed to a singular or group of devices. Lucky me. Less field work to do.

          That's all great on paper, but it's not as wide-spread in most places as you'd think. I've met many CCIEs that are outright lazy when it comes to locking down switching and routing connections because it makes their job even harder to deal with the ever changing zones, lans, nodes, and whatever wildass hair mgmt gets in their butt that week about which people/persons "need" access to what and when.

          I use firewall generically here and not literally a Firewall as well.

      • That means someone would have to be dumb enough to
        1) Have the mgmt of the switch be publicly available
        2) Have Telnet enabled.

        Don't get me wrong, it's a bad bug. But a security-minded admin should not have these problems.

        Err.. yes/no..

        If I was going to attempt to exploit something like this, I'd assume most would be inaccessible from the internet as a general use or would be white listed only..

        What I WOULD do is use this in conjuction with a machine level hack/compromise inside their network and then run amuk from there.. That's much easier to do and less will have full firewall off from within their networks from all PC segments.

        Which would still require Telnet to be enabled.

    • That means someone would have to be dumb enough to
      1) Have the mgmt of the switch be publicly available
      2) Have Telnet enabled.

      3) Purchase from a vendor that does not understand security well enough to disable telnet.

      • Now that's not fair. Cisco goes to great lengths to make sure the users know to TURN OFF TELNET. It's been in their documentation for decades. It's one of the first things you learn in CCNA training.

        Now, how do you suppose one would configure a cisco switch from bare metal w/o special hardware if they didn't do this?

        • If they bothered to generate a keypair on first boot, then SSH. Problem solved. The F5 LTM does this. Why can't a switch? Besides, its not like a Cisco console cable is "special hardware". Especially in the networking world. If you work with any amount of Cisco gear you probably have 20+ of the things just lying around on desks and stuffed in drawers. Hell, I have crimped my own Cisco compatible console cables on many occasions, its not like the pinout is a secret or anything. There is absolutely no reaso
        • by pnutjam ( 523990 )
          Serial port, even a standard ssh account would be more secure then telnet. Telnet should be disabled.
      • Re: (Score:3, Informative)

        by acoustix ( 123925 )

        That means someone would have to be dumb enough to
        1) Have the mgmt of the switch be publicly available
        2) Have Telnet enabled.

        3) Purchase from a vendor that does not understand security well enough to disable telnet.

        Telnet is not enabled by default on any interface on Cisco switches. I've been using them since 1999 and I can't think of a time when an out-of-the-box switch had Telnet enabled.

    • by Lumpy ( 12016 )

      Exactly. Management VLAN should be very protected.

    • To be fair, the headline said "hundreds". I came in thinking that's not bad at all.

  • 1) You are using proprietary multichassis bonding
    2) You need to make multiple switches look like one for licensing $$ purposes.

    And that is about it. Look at any vendor's release notes and a substantial portion of the bugs are in the clustering regime. Just turn that crap off unless you need it... since inductry-wide it's a proprietary lock-in gambit and doesn't have to survive interop shootouts, there's no way the code is worth running otherwise.

  • You can't treat such "hardware" as hardware anymore: it's a computer, which needs security updates like any other computer that's connected to a network.

    If there is not a realistic way to know about, get, and add security patches to ANY computer that connects to a network, don't buy it.

  • by slashkitty ( 21637 ) on Monday March 20, 2017 @04:03PM (#54077171) Homepage
    So, this leads to many questions: How long did the CIA know about this flaw and not tell Cisco Or, did Cisco know about this flaw and not warm users. How many other unpatched flaws are in the Vault 7 Is Cisco no issuing a REAL fix for this?
    • by guruevi ( 827432 )

      From the synopsis it does seem like Cisco is not providing a fix for this issue, only a "potential" workaround (meaning they baked it in and there are other methods of exploiting the same issue).

      • by Anonymous Coward

        >From the synopsis it does seem like Cisco is not providing a fix for this issue,

        Yeah, that's why commenting on the information gleaned from TFS is stupid.

        https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20170317-cmp

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

    • by AHuxley ( 892839 )
      Re "How long did the CIA know about this flaw"
      The US goes down a list of flaw questions.
      Is the US the only one using the same issue? Will other nations find it soon?
      Are other groups in the wild using it now? Will AV software detect the flaw soon?
      Can it be used against the USA if discovered without been noticed?
      Will the USA be detected in a later code review or from code litter?
      Can the flaw be proved to be the work of another nation when the US uses the same method?
      After all that is worked out, th
  • If your switch has it's administration ports open out to the internet or to anything but a protected LAN, then you need to fire everyone in IT and hire competent people.

  • On the new 2960X's we just bought, it is NOT on by default. You have to go into a second tab during your express setup and purposely enable it.
  • by AHuxley ( 892839 ) on Monday March 20, 2017 @07:46PM (#54078741) Journal
    Keep your brand or company secure by:
    Keep your most advanced work and secrets away from any network.
    Only use advanced US networks, US products for work that is in use and in public.
    When new services, products, contracts are been considered don't store anything on servers, network facing hardware.
    Hold design meetings in secure areas, don't bring in smart phones, devices. Keep vital encrypted notes on paper in that secure room.
    Use a one time pad to send vital messages to distant staff. Use staff to move a message to staff globally, face to face, in person.
    Use a networked company message board as a numbers station to broadcast information globally. Everyone looks at it everyday but the message is only for one person.
    If you have the funding set up bait, a honey pot of digital ideas on US branded hardware that faces the internet as normal.
    Pack it with the most amazing new ideas your competitors had, renamed as your own emerging products. Patents, secret bank accounts, staff lists, work with other nations. Make that server amazing. Use very different code names for emerging products and projects. See if anyone comes looking later for the same junk words or for the staff that are internal security risks on lists that are fake.
    Set up a random safe house with trusted security teams for years based on that staff risk review. See if anyone tries to offer the fake staff member a new job, wants to be "friends", makes a cash offer or poses as your nations security services to do an interview...
    Really simple counterintelligence that any nation or company can create.
    That needs a lot of funding but protects against human and network methods.
    Be aware of any new staff from other nations or your own nations new staff. New "friends" wanting a secure site tour. Physical site access can plant malware thats then collected later by hand.

Truly simple systems... require infinite testing. -- Norman Augustine

Working...