This article is more than 1 year old
Software-defined networking is dangerously sniffable
'Know Your Enemy' scheme uses switch flow tables to design attacks
Software-defined networking (SDN) controllers respond to network conditions by pushing new flow rules to switches. And that, say Italian researchers, creates an unexpected security problem.
The researchers were able to persuade their SDN environment to leak information that sysadmins probably don't want out in public, including network virtualisation setups, quality of service policies, and more importantly, security tool configuration information such as “attack detection thresholds for network scanning”.
Even a single switch's flow table, they write, can provide this kind of information, as well as serving as a side-channel for an attacker to exploit.
The three network boffins – Mauro Conti of the University of Padova, and Sapienza University's Fabio De Gaspari and Luigi Mancini – are particularly concerned about SDN being exploited to help an attacker build a profile of the target network, in what they call a Know Your Enemy (KYE) attack.
For example, they write, an attacker could potentially:
- Connect to the passive listening ports most SDN switches include for remote debugging, to retrieve the flow table (they offer HP Procurve's
dpctlutility as an example);
- Infer information about the flow table from jitter (that is, round trip time (RTT) – variance);
- Sniff control traffic, because of inadequate protection (not using TLS, or not using certificates for authentication;
- Exploit vulnerabilities that might exist in switch operating systems, such as backdoors; or
- Copy the flow table or memory content of the switch to an external location.
The paper points out that none of this is specific to particular devices: “the KYE attack exploits a structural vulnerability of SDN, which derives from the on-demand management of network flows, that in turn is one of the main features and strengths” of SDN.
Because SDN is designed to respond to the network by pushing flow rules out to switches, the attacker can easily work out what conditions will make the controller push a flow rule out to the switches.
Hence the KYE attack only needs to probe the environment (to discover what flow rules are on the switch they can access, either internally or remotely); and use the information gained in the “inference phase” to work out what policies will trigger activation of a particular rule.
Their proposal is that SDN architects consider applying some kind of flow obfuscation to their network, to stop an attacker using SDN responses to reveal information about the network: “if it was possible to prevent the attacker from understanding which network flow caused the installation of which flow rule, the KYE attack would become unfeasible”.
That's not too hard, it seems: one example given in the paper is that the controller push its instructions around the network on paths other than the most direct connection to switches, to make it harder for the attacker to correlate flow instructions with their fake stimuli. ®