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.
So long as "features" count for more than security, this will continue.
Great minds think alike; fools seldom differ.
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.
... plane outside the confines of the device and make it communicate over a common (not hardened and not separate) channel/network.
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