Open source SDN is a “hot” technology, with development being driven by a wide range of commercial and non-profit entities. 2015 is emerging as the year when open source SDN starts to move from the lab to widespread deployment for production networks. This transition from development to deployment brings questions of stability, scalability, and security to the fore. If 2015 is the year when open source SDN goes mainstream, then 2015 is the year that we need to identify and resolve security flaws in SDN controllers and switches.
Traditional networks conflate the control and data planes on a physical device, which typically consists of proprietary hardware and software. Software-defined networks factor the control plane out to a SDN controller. The controller uses a protocol such as OpenFlow to control switches, which are now only responsible for handling the data plane. From a security perspective, this division of responsibility has both advantages and disadvantages. The ability to easily segregate the control plane network from the production data network is an obvious advantage. The SDN controller’s ability to control an entire network makes it a very high value target, which is a potential disadvantage compared to a traditional network with a more distributed control plane.
In addition to the control plane administration interfaces exposed by the SDN controller, it has another attack surface: the data plane of the switches it manages. When an OpenFlow switch encounters a packet that does not match any forwarding rules, it passes this packet to the controller for advice. As a result, it is possible for an attacker who is simply able to send data through an SDN switch to exploit a vulnerability on the controller.
As SDN has begun to emerge as a mainstream technology, it has drawn the attention of security researchers. In the last few months, several new vulnerabilities affecting open source SDN controllers have been reported. We’ll look at three in particular that demonstrate the SDN attack surface, and provide examples of the kind of issues we’re likely to see in the future.
1) XML eXternal Entity (XXE) vulnerability in OpenDaylight netconf (CVE-2014-5035)
In late 2014 an XXE flaw was found in OpenDaylight’s netconf interface. Netconf allows for network configuration changes to be instigated using an XML vocabulary. OpenDaylight’s netconf implementation did not disable external entities when processing user-supplied XML documents, thereby exposing an XXE flaw. This is a very common flaw in server-side processes that handle user-supplied XML, and is particularly common in Java applications. A remote attacker, if able to interact with one of OpenDaylight’s netconf interfaces, could use this flaw to exfiltrate files on the OpenDaylight controller. This could include configuration details and plaintext credentials.
For an attacker to exploit this flaw, they need to have access to a netconf interface, which is part of the control plane. Strong access controls for control plane interfaces will greatly reduce the impact of flaws of this nature. To maximize their effectiveness, these access controls should be enabled by default. For more details on this flaw and how to apply a patch, see: https://wiki.opendaylight.org/view/Security_Advisories#.5BImportant.5D_CVE-2014-5035_netconf:_XML_eXternal_Entity_.28XXE.29_vulnerability
2) Denial-of-service (DoS) when deserializing malformed packets in ONOS (CVE-2015-1166)
In early 2015 an interesting DoS flaw was reported to the ONOS project. As mentioned earlier, when an OpenFlow switch encounters a packet that does not match any forwarding rules, it passes this packet to the controller for advice. It was found that the packet deserializers in ONOS would throw exceptions when handling malformed, truncated, or maliciously-crafted packets. The exceptions were not caught and handled, which would result in the relevant switch being disconnected because an exception occurred in an I/O thread. A remote attacker could use this flaw to perform a DoS attack by causing ONOS to disconnect switches.
For an attacker to exploit this flaw, they only need to be able to send malicious crafted packets through a switch controlled by ONOS. This is an example of how the data plane can be used to exploit a vulnerability on the controller. For more details on this flaw and how to apply a patch, see: https://jira.onosproject.org/browse/ONOS-605
3) Topology spoofing via host tracking
In mid-February 2015, another interesting flaw that can be exploited via the data plane was reported. Most SDN controllers include host tracking, allowing hosts to migrate between different physical locations in the network. This host tracking functionality is based on monitoring of Packet-In messages, and does not require any validation, authentication, or authorization. This makes it possible for an attacker to impersonate a host and make the SDN controller believe it has migrated to a physical network location controlled by the attacker.
For an attacker to exploit this flaw, they only need to be able to send malicious messages through a switch controlled by an SDN controller. The only prerequisite is that the attacker must know the MAC address of the target host. For more details on this flaw, see: http://www.internetsociety.org/sites/default/files/10_4_2.pdf
Same same, but different
It is worth noting that while the three vulnerabilities discussed above are new, none of them are particularly novel. XXE is a very well established issue that has affected dozens of Java-based projects. DoS attacks based on triggering an unhandled exception are also common and well established. The topology spoofing flaw is novel in a sense, but it is closely related to MAC spoofing, which is a very old and well-known issue (http://en.wikipedia.org/wiki/MAC_spoofing). This highlights that while SDN is a new and novel technology, it is still just software, and a relatively small number of fundamental issues represent the vast majority of security flaws. As a result, applying tried and true countermeasures is likely to be effective for many of the security flaws that will affect SDN.
The most important countermeasure for security flaws in any software project is an effective security response process. This process should be run by a dedicated team who can handle reports of security flaws discretely. At a minimum, a security response process should provide the following:
* A private channel for people to report security flaws
* The ability to drive the preparation of patches without any details of the flaw becoming publicly visible
* The ability to ship patches quickly
* Clear and concise advisories that communicate the impact of flaws to users, and provide details on how to apply patches
ONOS has now implemented a security response process, which is an important first step. For more details, see: https://wiki.onosproject.org/display/ONOS/Security
Security response is reactive: a flaw is found, and it is addressed by a patch and a corresponding advisory. Of course, it is preferable to address security flaws in a proactive fashion. Several open source projects are now underway that aim to improve the security of SDN controllers, and limit the ability of an attacker to exploit any flaws that become known. We’ll look at two of these projects.
1) Security-mode ONOS
Security-mode ONOS is a new feature that is targeting the upcoming ONOS ‘Cardinal’ release. It is effectively a mandatory access control (MAC) implementation for ONOS applications. Applications can be constrained by a policy dictating which actions they are permitted to perform. This is an important development, as it means that a vulnerability in an ONOS application could not be exploited to perform actions that are not permitted by security-mode ONOS. This is similar to the protection SELinux provides for applications running on Linux systems. For more details, see: https://wiki.onosproject.org/display/ONOS/Security-Mode+ONOS
The same research team that reported the topology spoofing flaw noted above also developed a tool to mitigate it, called Topoguard. It works by verifying the conditions of a host migration. A legitimate host migration would involve a Port Down signal before the host migration finishes. It would also mean that the host would be unreachable at its old physical network location after the migration is complete. Topoguard verifies host migrations by ensuring that these conditions are met, effectively mitigating topology spoofing via host tracking. Topoguard is currently tightly coupled to the Floodlight controller, but it could be ported to other controllers. For more details, see: https://github.com/xuraylei/floodlight_with_topoguard
When I first became involved in the open source SDN community in November 2014, very few meaningful security measures were in place. Since then, the community has started to audit SDN controllers and report flaws, security response processes have been documented and security response teams formed, and powerful defensive technology is starting to be developed. This is a very impressive and encouraging pace of development, and in my opinion open source SDN controllers are on track to provide that level of security that they need to go mainstream.
There are two thorny security problems that open source projects have struggled to handle, and I think ONOS and the wider open source SDN community is now in a position to tackle them.
1) Coordination of vulnerability disclosure
When multiple commercial vendors support a given project, each is incentivized to hold information about security flaws that the other vendors do not. This can be a major source of conflict. It is important that projects are able to coordinate the disclosure of vulnerabilities to all stakeholders simultaneously, without details leaking prior to an agreed upon embargo date.
2) Proactive secure engineering
The defensive technologies discussed above limit the ability of an attacker to exploit flaws, but they do not minimize the risk of security flaws entering the code base in the first place.This can be achieved by implementing measures such as the following:
- Establishing automated QE/CI jobs to catch security flaws and regressions.
- Establishing automated QE/CI jobs to catch known-vulnerable dependencies.
- Documenting a threat model
- Improving documentation to capture security best practices at installation and configuration time
I would like to challenge the vibrant and growing open source SDN community to tackle these problems. I’m ready and willing to help, so please reach out to me at email@example.com if you’d like to get involved.