Slashdot Mirror


SDN Switches Not Hard To Compromise, Researcher Says

alphadogg writes: Software-defined switches hold a lot of promise for network operators, but new research due to be presented at Black Hat will show that security measures haven't quite caught up yet. Gregory Pickett, founder of the Chicago-based security firm Hellfire Security, has developed several attacks against network switches that use Onie, the Linux-based Open Network Install Environment that competes with OpenDaylight. Being able to exploit the vulnerability to put malware on SDN switches would have full visibility into all of the traffic running through the switch, enabling large-scale spying.

39 of 105 comments (clear)

  1. Not Supprising by Anonymous Coward · · Score: 1

    I recall thinking "Oh, no" when I saw the first HP presentation on the subject...

    1. Re:Not Supprising by Mikkeles · · Score: 4, Insightful

      So long as "features" count for more than security, this will continue.

      --
      Great minds think alike; fools seldom differ.
    2. Re:Not Supprising by WaffleMonster · · Score: 1, Interesting

      So long as "features" count for more than security, this will continue.

      So long as people waste their time and resources guarding wires rather than systems this will continue. Most of the need for SDN in the first place originates with fools continuing to pursuit castle defense during the space age.

      --
      "Finally, we will access, disclose and preserve personal data, including your content (such as the content of your emails, other private communications or files in private folders), when we have a good faith belief that doing so is necessary."

  2. SDN is not a smart idea at this time... by gweihir · · Score: 3, Insightful

    If and when the human race learns to code software that is very hard or impossible to compromise, SDN may have a place, but before that, it is an exceptionally bad idea. It is also not a new bad idea, but an old one that has been renamed. For example, "Active Networking" did try this thing before.

    --
    Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    1. Re:SDN is not a smart idea at this time... by sociocapitalist · · Score: 1

      If and when the human race learns to code software that is very hard or impossible to compromise, SDN may have a place, but before that, it is an exceptionally bad idea. It is also not a new bad idea, but an old one that has been renamed. For example, "Active Networking" did try this thing before.

      No system or network is perfectly secure and a SDN can be protected just like any other sensitive and imperfect infra can be protected.

      --
      blindly antisocialist = antisocial
    2. Re:SDN is not a smart idea at this time... by gweihir · · Score: 2

      Who let the insane one in here again?

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    3. Re:SDN is not a smart idea at this time... by Luthe_Faydwire · · Score: 2

      You do understand that all networks are running software today right? More importantly big networks are incredibly hard to upgrade in a timely fashion; primarily due to the problem that in most cases you have to take part of the network offline. Even in fully redundant networks the politics slow the whole upgrade process down. I look forward to the time when we can run a cluster of controllers and upgrade them in service.

    4. Re:SDN is not a smart idea at this time... by K.+S.+Kyosuke · · Score: 1

      after you gave apk crap on his program

      Talking about yourself in the third person makes many a psychiatric warning light go off...

      --
      Ezekiel 23:20
    5. Re:SDN is not a smart idea at this time... by K.+S.+Kyosuke · · Score: 1

      You might still be able to follow Hoare's maxim and make a system so that there are obviously no deficiencies in it.

      --
      Ezekiel 23:20
    6. Re:SDN is not a smart idea at this time... by sociocapitalist · · Score: 1

      No, it cannot. It does require a complete lack of understanding how networks can and cannot be protected to make such a claim however.

      Is that so?

      Since you are confident enough to make such a statement, I invite you to explain why it is not possible.

      --
      blindly antisocialist = antisocial
    7. Re:SDN is not a smart idea at this time... by sociocapitalist · · Score: 1

      Incidentally, lack of any detailed and coherent response from you will only confirm that you are just another overly arrogant and obnoxious person on this website whose mouth spits out comments that they make out of ignorance and cannot actually back up with anything substantial.

      --
      blindly antisocialist = antisocial
    8. Re:SDN is not a smart idea at this time... by sociocapitalist · · Score: 1

      Nice, self-serving BS. There is absolutely no point in explaining anything to you as you are convinced you already have the absolute truth, while you clearly do not even understand the basics. I encourage you to look up the Dunning-Kruger effect though, and try to understand what it means to be on the left side of the graph.

      I am not convinced that I know the absolute truth (should such a thing even exist). Hell I could even be wrong and I'd love to learn from whatever you could teach me. I invited you to explain your point to me.

      As I suspected from reading your other posts, you were unable to actually put forth anything to substantiate your casually obnoxious statement.

      Maybe you're right and I have a complete lack of understanding here.

      Maybe,

      Personally I think you opened your mouth and said something that you are incompetent to deliver on.

      My qualifications include the CCIE and the JNCIE, both very low number and neither of them paper, though you probably don't know what I mean by that. Look it up.

      I've spent more than twenty years in securing networks and supporting infrastructure for customers including but not limited to ISPs, banks and phone companies.

      Have a nice day :-)

      --
      blindly antisocialist = antisocial
  3. Onie =! OpenDayLigth by Anonymous Coward · · Score: 2, Interesting

    As far as I'm concerned, OpenDayLight is not a bare-metal OS installed on the network assets running the Data Plane... ODL is an SDN controller running on the Management Plane. "SDN Ready" switches in general are just regular switches compatible with OpenFlow... the article doesn't make much sense. Let see...

  4. Security updates by manu0601 · · Score: 1

    Given the amount of security updates we had on Linux servers those days, it is not surprising a lot of vulnerabilities exists in embedded Linux systems.

    It would require a lot of work from distribution maintainers and system administrators to keep that stuff ahead of the vulnerability curve?

  5. This is what happens when you move the control... by Zondar · · Score: 4, Insightful

    ... plane outside the confines of the device and make it communicate over a common (not hardened and not separate) channel/network.

  6. I recall thinking "Oh, no" when I saw the first HP presentation on the subject...

    Yep.

    If you can software define the entire switch (or other network device), you can software design an invisible-to-the-rest-of-it tap component for it. B-b

    --
    Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
    1. Re:Yep by Anonymous Coward · · Score: 2, Insightful

      You can do this as well for current 'hardware defined' network components. All switch fabric ICs that I know of can transfer packet data to the host cpu, this is normally used to implement the high end L3 features (and of course to allow access to the management CLI/GUI). If you can update the host CPU firmware with a tap component it will be as invisible as this SDN hack. I even know of one ASIC where you could in theory make it capture all data, put ETH/IP/UDP header before it and then send it out. The host cpu would not need to be involved except for setting the initial configuration,

      There is quite some information on the internet about the internals of Cisco and other firmware. Adding 'execute magic packet payload' functionality to most devices would not require much skills.

      The trick is preventing access, rather than using an obscure invisible firmware.

      BTW: Did you know that some Realtek switch chips allow you to update their register values via ethernet? Normally this is used (on 1 port) so you can connect multiple switches to a single managed switch controller. Many unmanaged switches have it enabled by default on all ports.
      https://en.wikipedia.org/wiki/Realtek_Remote_Control_Protocol

  7. The trick is only permiting access... by Karmashock · · Score: 2

    ... to the control interface from a specific port. And then you plug that port into one of your servers that is deep in your security bubble by default... and then you VNC or RDP into that when you want to access the SDN.

    Its when you allow access through any port that things become stupid.

    --
    I've decided to stop wasting my time responding to AC trolls/sockpuppets... so if you want a response from me... login.
    1. Re:The trick is only permiting access... by Antique+Geekmeister · · Score: 1

      And then you leave the root keys, and the details on how to access and configure the server, on a trivially accessable wiki, especially with root keys stored unencrypted by developers and admins by policy "because we trust the people we work with" and "because we have a firewall".

    2. Re:The trick is only permiting access... by Karmashock · · Score: 2

      No... The only people that can touch the server are people that are hand picked and trusted. Can they do bad things? Sure. You have to trust someone. But a senior admin betraying you is not the same thing as a shithead hacker walking into your operation and writing "I WAS HERE" with his urine.

      The trick is to backstop exposed systems to the security of secured systems. Where in the security is not actually breached unless the secure systems are breached. And then you make breaching those a matter of certain people needing to be compromised or certain physical machines being physically touched by people or hardware of ill intent. Then you control those people and that hardware. And then breaching THAT security is uncommon. Examples of it failing would be Snowden or the Iran Stuxnet situation. Snowden was given access, downloaded files, and walked off with them. I can think of ways to make that harder. And the Stuxnet thing happened because people were taking thumb drives from unsecured systems to secured systems and not running it through a protocol shift that would filter out rootkits or other nonsense designed to compromise windows or linux systems.

      --
      I've decided to stop wasting my time responding to AC trolls/sockpuppets... so if you want a response from me... login.
    3. Re:The trick is only permiting access... by Antique+Geekmeister · · Score: 1

      > No... The only people that can touch the server are people that are hand picked and trusted.

      You seem to be _extremely_ optimistic about most security enviromments. I don't deny that your guidelines are sensible and appropriate, or that they are rigorous and thoughtful. But they're violated, in practice and in policy even in most so-called "secure" environments. As most networks grow and mature, there are extremely frequent holes drilled and policies violated for the ease and convenience of the administrators and developers, for access by those who pay salaries, Even when technologies exist to provide access more safely and rigorously, the attempt to turn off the favorite access tool of a critical developer is the sort of thing that gets people fired.

      Edward Snowden is actually a good example of where policy was being ignored, namely the policy for the NSA not to commit criminal acts against US citizens. He _repeatedly_ reported criminal abuse by the NSA to his own superiors, and tried to use the chain of command to address ongoing criminal activity. He was stonewalled, and repaid the trust placed in him by very correctly whistleblowing. The man deserves a pardon, a medal, and to be on the staff of the US representative to the UN Security Council. His was precisely the kind of case where human involvement in security paid enormous dividends over blind technological obedience.

      Stuxnet was a different situation. It's well known that in a large group of employees, some of them will be security careless, and that a significant number of them will violate the security principles you advocate. They're good principles, but there are going to be violations of them. It's why the most effective security I've worked with is multi-layer: it includes robust backups, regular upgrades, security scans, changes in access credentials, access auditing, sensible password policy, and other tools.

    4. Re:The trick is only permiting access... by Karmashock · · Score: 1

      Depends on the implementation, no?

      Many of them are encrypted, proprietary, and sufficiently uncommon that there isn't an off the shelf hack for it.

      That said, I take your point. I'm just trying to point out that you can shield one thing with another. Ideally for the deep deep stuff you need to walk up and touch it to get access. But most people aren't willing to deal with that.

      --
      I've decided to stop wasting my time responding to AC trolls/sockpuppets... so if you want a response from me... login.
  8. What exactly is a SDN, anyway? by swb · · Score: 2

    It kind of seems cloud-ish in its specifics.

    Is it a generic switching backplane that allows arbitrary software loads and more elaborate centralized configuration, perhaps enabling more exotic topologies?

    How far are we away from this now? Most switches anymore seem like specialist PCs with a zillion NICs that boot some variant of linux or bsd and allow for pretty exotic topologies as it is, limited only by the interconnect hardware they have.

    Or is it something tied to virtualization where its meant to describe networks that only exist in hypervisor clusters?

    1. Re:What exactly is a SDN, anyway? by Anonymous Coward · · Score: 1

      You know how something like a Cisco 6k L2/L3 switch/router can route and switch, and when it routes the first packet in a flow it can then store the decision out on the blades so that subsequent packets simply get switched, and that routing decision is done using routing logic on a generalized processor in the supervisor module while the switching is done by ASICs? Now imagine that the same thing happens but where the control-plane decision happens using some off-board service that controls all the switches (including perhaps virtual ones in compute hypervisors). Now add in not just ACLs but also firewalls and other networking esoterica.

      That's SDN.

    2. Re:What exactly is a SDN, anyway? by Anonymous Coward · · Score: 1

      As I understood it, just a few months ago, only a few SDNs actually were switching on the ASICS, and they were not the freebies.

      Have things changed, and is it now possible to use the ASICs from most SDN projects ?

    3. Re:What exactly is a SDN, anyway? by Anonymous Coward · · Score: 1

      Depends what you want to do. Most current not extremely-high-end switch fabric ASICs can do approximately what an expensive L2/L3 managed switch can do. This gets you there for 99.9% of traffic. Some exotic configuration can probably not be handled by the ASIC, but these few packets then go through the CPU. As long as you are switching streams (eg, wait for trigger packet, update asic config) the performance loss is minimal. If you are doing heavy per packet things then they all have to go through the CPU. Even then, the performance is not that bad for what you get.

    4. Re:What exactly is a SDN, anyway? by Crazy+Taco · · Score: 1

      How far are we away from this now? Most switches anymore seem like specialist PCs with a zillion NICs that boot some variant of linux or bsd and allow for pretty exotic topologies as it is, limited only by the interconnect hardware they have.

      And that's just the switches. Have a look at a really advanced network device, like the F5 Big-IP load balancer. That loads Linux plus a proprietary real time OS called TMOS, is a full proxy for most common traffic types like TCP, and as a full proxy it can intercept and edit anything that comes through it. And if you don't like the gazillion options it gives you, you can write iRules in the TCL language and apply them to any listener. The iRule is basically just a TCL program, and it can edit the packets and their payload in any way you want as they come through. And all these BigIPs can be remotely controlled by BigIQ, which is F5s centralized controller.

      So in theory, if you compromised the F5 you already had pretty much the same kind of control over traffic the blackhat people are highlighting. But, not everything in your network would run through an F5. I think the big difference today is that everything DOES run through a switch somewhere.

      --
      Beware of bugs in the above code; I have only proved it correct, not tried it.
  9. Re: LMAO - I know the feeling... apk by Anonymous Coward · · Score: 1

    Why did you downvote the guy? This is his first post that makes sense

    because he's a known spammer and generally a douche. in his own eyes he is always right and anybody who disagrees with him has some sort of personal grudge or jealousy against him. that's the way he is - no dissent is ever legitimate. everything is somehow personal, even things like system configuration and web browsers. you can't argue with people like him, and if you sincerely try, he just convinces himself he's being "persecuted" and pats himself on the back for his unquestioning dedication.

    if you've ever met a religious fanatic, it's not exactly the same thing but it's similar. apk wants to prove to everyone how clever and correct he is, how much smarter he is than anyone who disagrees with him in the slightest. when that doesn't work it's like some kind of bitter defeat, a societal failure to recognize how special he is and how flawless his solutions are. he's known to throw temper tantrums in the form of personal attacks and massive spamming sprees. his hostfile program is his favorite thing to spam us with, sometimes dozens of posts in a single discussion, each one several pages long. he must have a lot of proxies to get around the posting limits as easily as he does.

    in short he's a nuisance and a pest, the kind of person who resists learning and, in all likelihood, has nothing better to do.

  10. ah yes - the new Corporate Buzzword by ruebarb · · Score: 1

    word came down a few months ago from on high - we need to learn how to do SDN and become experts at it - we have none of it in our environment and no one knows how to support it or what our use for it would be - and we're the network guys but Cisco must be trying to sell us something

    or Somewhere...someone...got their hands on a Network Week magazine - one of our dumbass Level 1 phone dorks musta left it in the john.

    --

    ----------
    ah honey, we're all resplendent - Bill Mallonee
  11. Software-defined switches .. by nickweller · · Score: 1

    Software-defined switches .. a solution in search of a problem .. discuss ...

    1. Re:Software-defined switches .. by coofercat · · Score: 1

      I don't get it either. I can understand wanting to dynamically open firewall ports here and there (which is also dangerous, and another subject), but I don't get why you'd need to mess with vlans and such like dynamically. When I worked on massive scale, the architects talked about "data centre holes" where you had space available but couldn't use it because of limitations in the network. I assume SDNs solve that problem, but then so does HAProxy instead of using hardware load balancers.

      Either way, I could really use a good explanation of why SDNs are required in a "few hundred" server setup (which lets face it, most of the world works with). Surely you just put a bunch of VM hypervisors on each of your vlans and then start up the VMs on the right hypervisors. If you've got spare hypervisors on one VLAN and none on another, you physically move them (or manually alter the switch vlans). Why you *need* that to be dynamic is still a mystery to me. Anyone know?

    2. Re:Software-defined switches .. by Antique+Geekmeister · · Score: 1

      There are actually uses. a robust virtualization server can support an SDN to set up a completely internal testing network. This can be far faster, and far cheaper, than bringing in new switches and new cabling and new configuration environments.

    3. Re:Software-defined switches .. by swb · · Score: 1

      You can do this now with VMware, create a vSwitch with no NICs attached and connect machines that can only talk to each other. I think distributed vSwitches can carry this further and extend these across nodes, although as a more expensive licensed feature people usually map these internal test networks to an isolated VLAN so they can span nodes.

  12. Re: LMAO - I know the feeling... apk by K.+S.+Kyosuke · · Score: 1

    Because even when the thought makes sense, the presentation is worse than the work of a brain-damaged third-grader?

    --
    Ezekiel 23:20
  13. Re:K.S. Kyosuke = "Run, Forrest: RUN!!!" by K.+S.+Kyosuke · · Score: 1

    I have absolutely no idea what "ab+" is, nor do I care, nor do I understand how it could possibly fix your incomprehensible and borderline psychotic diction if it hasn't done so yet.

    --
    Ezekiel 23:20
  14. Re:K.S. Kyosuke = "Run, Forrest: RUN!!!" by K.+S.+Kyosuke · · Score: 1

    Third person again...

    --
    Ezekiel 23:20
  15. Re:You sure ran from my "flawed solution" by K.+S.+Kyosuke · · Score: 1

    I haven't written that comment, despite being in agreement with it. But I guess that this public statement is kind of redundant, because 1) you will never get it into your thick skull and 2) everyone else already understood that anyway.

    --
    Ezekiel 23:20
  16. virtualization by Chirs · · Score: 1

    Cloud computing tied to networking leads to the need to reconfigure the network very flexibly and potentially frequently. This is where SDN comes in.

    Suppose you have a big beefy virtualization host. You run a bunch of VMs on it, some of which might themselves be acting as full-fledged routers pushing gigabits/sec of packets. (Yes, this is possible right now.) You want to have strict control over which VMs can talk to which other VMs, you want to control which virtual networks can connect to which physical networks (or possibly which vlans/vxlans on which physical networks). Now combine this with SR-IOV or PCI passthrough where a given physical ethernet device can be logically switched between different customers depending on which VM it's attached to at any given time.

    1. Re: virtualization by nickweller · · Score: 1

      Thanks all, I learned something new today, slashdot can still deliver the knowledge ...