OpenFlow: A Security Analysis

Transcription

1 Introduction OpenFlow: A Security Analysis Rowan Klöti 1 Vasileios Kotronis 2 Paul Smith 3 1 rkloeti@alumni.ethz.ch ETH Zurich 2 vkotroni@tik.ee.ethz.ch ETH Zurich 3 paul.smith@ait.ac.at AIT Austrian Institute of Technology GmbH ICNP NPSec 2013, Göttingen, Germany 1 / 36

2 Outline Introduction 1 Introduction Objectives SDN and OpenFlow 2 Attack Model STRIDE Attack Trees Combining the es Experimental Setup 3 Security Analysis Empirical Testing / 36

3 Objectives Introduction Objectives SDN and OpenFlow Security analysis of OpenFlow protocol and networks Focus on v1.0.0, but extensible/adaptable methodology Develop model Analyze model Describe attacks Empirically demonstrate one or more security issues Develop setup to enable this empirical demonstration Suggest potential fixes and mitigations for security issues 3 / 36

4 Introduction Why OpenFlow Security Analysis? Objectives SDN and OpenFlow OpenFlow started as a largely academic endeavour But has recently seen increasing deployment in production systems: Google s OpenFlow WAN Cisco, Juniper, HP products Adoption by cloud hosts and service providers But why security? No official security analysis of the protocol itself Research is just catching up (see HotSDN 2013 program) Security is extremely important for production systems, but can be overlooked 4 / 36

5 Introduction SDN and OpenFlow 101 Objectives SDN and OpenFlow Software Defined Networks (SDNs) separate data plane and control plane OpenFlow implements SDN: Switch implements data plane Controller implements control plane Switch and controller connected with secure channel over control network Controller installs flow rules on switch Flow rule header fields match packet headers Packets matching a flow rule have actions performed on them OpenFlow Switch Specification Version ( Wire Protocol 0x01 ) Header Fields 1 Introduction December 31, 2009 This document describes the requirements of an OpenFlow Switch. We recommend that you read the latest version of the OpenFlow whitepaper before reading this specification. The whitepaper is available on the OpenFlow Consortium website ( This specification covers the components and the basic functions of the switch, and the OpenFlow protocol to manage an OpenFlow switch from a remote controller. Counters Actions Version 1.0 of this document will be the first for which official vendor support is expected. Versions before 1.0 will be marked Draft, and will include the header: Do not build a switch from this specification! We hope to generate feedback prior to Version 1.0 from switch designers and network researchers, so that the set of features defined in Version 1.0 enables production deployments on a variety of vendor hardware. Figure 1: An OpenFlow switch communicates with a controller over a secure connection using the OpenFlow protocol. 1 5 / 36

6 Attack Model Introduction Attack Model STRIDE Attack Trees Combining the es Experimental Setup Three scenarios Attacker controls a single client Attacker controls multiple clients Attacker has access to control network The first scenario is given greatest consideration Scenarios where attacker has access to actual secure channel are not considered This would involve compromising SSL or TLS, which is outside the scope of this work 6 / 36

7 STRIDE Introduction Attack Model STRIDE Attack Trees Combining the es Experimental Setup Security modeling methodology Types of vulnerabilities modeled by the method[3]: Spoofing Tampering Repudiation Information Disclosure Denial of Service and Elevation of Privilege Use data flow diagrams to uncover potential vulnerabilities Models how external data enters into and propagates through system Client Request Reply Web application Query Database Figure : Data flow diagram 7 / 36

8 Attack Trees Introduction Attack Model STRIDE Attack Trees Combining the es Experimental Setup Used to describe and analyze attacks Based on fault tree analysis[4] Represent prerequisites for attacks Leaf nodes represent actions or events These propagate through AND and OR gates Root node is objective Can calculate various metrics if values for leaf nodes are known Dictionary attack Find vulnerability Get root access Exploit vulnerability Develop exploit Social engineering Execute attack Figure : Attack tree 8 / 36

9 Introduction Attack Model STRIDE Attack Trees Combining the es Experimental Setup From STRIDE DFDs to Attack Trees Data flow diagrams show us potential vulnerabilities They show us which components present an attack surface Attack trees allow these to be developed into practical attacks A given objective may have multiple attack paths Attack trees help to analyze and optimise attack paths These two approaches are complementary 9 / 36

10 Experimental Setup Introduction Attack Model STRIDE Attack Trees Combining the es Experimental Setup Mininet is a virtual network emulation environment Based on Linux network namespaces Runs Open vswitch (virtual OpenFlow switch) Can emulate performance constraints Bandwidth Latency and jitter This is required to simulate attacks Forms the basis of test environment Use POX as a controller 10 / 36

11 Setup Schematics Introduction Attack Model STRIDE Attack Trees Combining the es Experimental Setup h1-1 h2-1 h1 s1 h2 h1-2 s1 s2 h2-2 c0 h1-3 c0 h2-3 Figure : Network topology for Denial of Service attack demonstration Figure : Network topology for Information Disclosure attack demonstration 11 / 36

12 Denial of Service I Introduction Security Analysis Empirical Testing Received packet from 1 Interface 1 Received packet Input buffer 1 Sent packet to 1 Transmitted packet Output buffer 1 Packet to process Remove/modify packet OpenFlow Module Transmit packet Get state/event Forwarded/Enqueued packet Packet sample Set state/action Controller-to-switch message Data path Read flow table Modify flow table Secure Channel Forwarded/Enqueued packet Read flow table Asynchronous message Update counter Output buffer 2 Remove/modify packet Packet to process Flow table Transmitted packet Received packet from 2 Interface 2 Sent packet to 2 Received packet Input buffer 2 Denial of Service Information Disclosure Tampering Figure : Data flow diagram of switch 12 / 36

13 Denial of Service II Introduction Security Analysis Empirical Testing Transmit packet OpenFlow Module Set state/action Get state/event Secure Channel Packet sample Data path Read Modify Read flow table Update counter Flow table Denial of Service Information Disclosure Tampering Figure : Close-up of data flow diagram 13 / 36

14 Denial of Service III Introduction Security Analysis Empirical Testing Denial of service Against switch Against controller Against Decision process Against Flow table Against Input buffer Against OpenFlow Module Against OpenFlow Interface and data flow Asynchronous message Exploit security hole in controller (if present) Identify which flow rules are created without wildcards Locate security Perform hole in Develop exploit Obtain access processor controller to multiple intensive tasks software client interfaces on several connections Attack OpenFlow Attack controller Interface and OpenFlow Interface Asynchronous directly message Identify which flow rules are created without wildcards Generate extremely high traffic load on interface Generate very high rate of new flows on several interfaces Generate very high traffic load on interface Obtain access to management network Perform regular denial of service attack against controller Obtain access to multiple client interfaces Identify which flow rules are created without wildcards Generate very high traffic load on each interface Identify exact form of flow table entries Identify hash function used for flow table Cause hash collisions on flow table Figure : Denial of Service attack tree with attack path highlighted 14 / 36

15 Denial of Service IV Introduction Security Analysis Empirical Testing Denial of service Against switch Against Flow table Identify which flow rules are created without wildcards Generate very high traffic load on interface Figure : Close-up of highlighted attack path 15 / 36

16 Introduction Information Disclosure I Security Analysis Empirical Testing Denial of Service Information Disclosure Tampering Controller-to-switch message Set state/action Get policy Asynchronous message OpenFlow Interface Get state/event Decision Policy Administrator Read policy Write policy Set value Write log Write log Get value Log Read log Administration interface Set configuration Get configuration Figure : Data flow diagram of controller 16 / 36

17 Introduction Information Disclosure II Security Analysis Empirical Testing Denial of Service Information Disclosure Tampering Switch Controller-to-switch message Asynchronous message OpenFlow Interface Set state/action Get state/event Decision Figure : Close-up of data flow diagram 17 / 36

18 Introduction Information Disclosure III Security Analysis Empirical Testing Information disclosure Against data flow Packet sample Against switch Against controller Against data flow Asynchronous message Disclose existing flow actions with side channel attack Disclose existing flows with side channel attack Disclose whether a new flow rule is created Obtain hardware, measure reaction times Send many packets between clients, measure time Obtain access to multiple client interfaces Force another client to reflect traffic or produce response Obtain access to multiple client interfaces Force another client to reflect traffic or produce response Wait for flow rule timeout, repeat procedure for statistical certainty Select packet contents based on policy query type Send packet between clients, measure time Repeat procedure second time, measure time difference Obtain access to multiple client interfaces Force another client to reflect traffic or produce response Select packet contents based on flow rule query type Send packets between clients, measure time Figure : Information Disclosure attack tree with attack path highlighted 18 / 36

19 Introduction Information Disclosure IV Security Analysis Empirical Testing Information disclosure Against controller Against data flow Asynchronous message Disclose existing flows with side channel attack Select packet contents Send packets, measure time Obtain access to multiple client interfaces Force another client to produce response Figure : Close-up of highlighted attack path 19 / 36

20 Packets lost Denial of Service Introduction Security Analysis Empirical Testing Soft timeout [s] Figure : Number of lost packets vs rule timeout value due to flow table overflow (with control link at 100 Mbps and 1ms latency) 20 / 36

21 Frequency Introduction Information Disclosure I Security Analysis Empirical Testing Single flow (initial) Two flows (new+initial), distinct Measured response time [ms] Figure : Distribution of measured times with exact matching flow rules 21 / 36

22 Frequency Introduction Information Disclosure II Security Analysis Empirical Testing Single flow (initial) Two flows (new+initial), aggregated Measured response time [ms] Figure : Distribution of times with source address and port as wildcards 22 / 36

23 Denial of Service Introduction Rate Limiting, Event Filtering, Packet Dropping, Rule Timeout Adjustment Some of them introduced in newer OpenFlow standards Example of usage: large timeouts lighten load on controller but can cause table overflows Flow Aggregation Try to reduce load on controller with proactive strategies Attack Detection Employ OpenFlow for logically centralized detection Direct flows to specialized monitoring systems Access Control - Distributed Firewall ACLs implemented as sets of flow rules on the switch 23 / 36

24 Information Disclosure Introduction Proactive Strategies Remove response time-state dependency Randomization Increase variance of measurable response times Clever rule timeout randomization Direct Attack Detection-Mitigation Exploit bird s eye view over traffic to detect suspicious patterns Enact counter-measures using direct flow control 24 / 36

25 Introduction Found potentially problematic issues in OpenFlow, including: Denial of service (i.e. resource depletion) Information disclosure (i.e. timing analysis) Newer specifications reflect some of these issues Metering, multiple controllers with fail-over, parallelism But further work is required! Demonstrated two different forms of attack Developed test setup (could be used for unit tests) Contributions Extensible and adaptable methodology Towards SDN architectures that are more secure by design 25 / 36

26 Discussion Introduction Thank you very much for your attention! Questions? 26 / 36

27 Other es (supplemental material) (supplemental material) References Attack nets (from Petri nets)[5] More versatile than DFDs, but also harder to analyse This level of formalism is not needed Less suited to fully asynchronous system Difficult to model system with discrete, fully enumerated states State-based system models[1, 2] These systems tend to model control flow rather than data flow OpenFlow specification does not require any particular control flow Might be useful with a given controller 27 / 36

28 Denial of Service V (supplemental material) (supplemental material) References Identify which flow rules are created with or without wildcards Compromise controller Determine from timing analysis Social engineering or educated guess Wait for flow rule timeout, repeat procedure for statistical certainty Ensure that adjacent client addresses are available, if address is to be probed Secure multiple source addresses, if needed. For each header column, select two neighboring values Send packet between clients, measure time Repeat procedure second time, measure time difference Obtain access to multiple client interfaces Force another client to reflect traffic or produce response Obtain access to multiple client interfaces Use forged source addresses Send falsified ARP or LLDP or routing packets to redirect traffic Figure : Denial of service attack tree with attack path highlighted 28 / 36

29 (supplemental material) (supplemental material) References Denial of Service VI Identify which flow rules are created with or without wildcards Social engineering or educated guess Figure : Close-up on highlighted attack path 29 / 36

30 (supplemental material) (supplemental material) References Information Disclosure V NB: This attack tree should not be considered exhaustive. Force another client to reflect traffic or produce response ICMP based traffic UDP based traffic TCP based traffic ICMP echo request/echo response (ping) DNS request NTP RIP HTTP request NetBIOS (Windows) or network file system SSH or telnet Figure : Information disclosure attack tree with attack path highlighted 30 / 36

31 (supplemental material) (supplemental material) References Information Disclosure VI Force another client to reflect traffic or produce response TCP based traffic HTTP request Figure : Close-up on highlighted attack path 31 / 36

32 Packets lost (supplemental material) (supplemental material) References Denial of Service (Empirical) II Soft timeout [s] Figure : Number of lost packets vs timeout value due to flow table overflow (with control link at 10 Mbps and 10ms latency) 32 / 36

33 Frequency (supplemental material) (supplemental material) References Information Disclosure (Empirical) III Without aggregation With aggregation Measured response time [ms] Figure : Distribution of times with source address and port as wildcards and asymmetrical delay (delay in control network shorter than in data network) 33 / 36

34 References I (supplemental material) (supplemental material) References O. El Ariss, Jianfei Wu, and Dianxiang Xu. Towards an Enhanced Design Level Security: Integrating Attack Trees with Statecharts. In Secure Software Integration and Reliability Improvement (SSIRI), 2011 Fifth International Conference on, pages 1 10, june doi: /ssiri Omar El Ariss and Dianxiang Xu. Modeling security attacks with statecharts. In Proceedings of the joint ACM SIGSOFT conference QoSA and ACM SIGSOFT symposium ISARCS on Quality of software architectures QoSA and architecting critical systems 34 / 36

35 References II (supplemental material) (supplemental material) References ISARCS, QoSA-ISARCS 11, pages , New York, NY, USA, ACM. URL: doi: / Shawn Hernan, Scott Lambert, Tomasz Ostwald, and Adam Shostack. Uncover Security Design Flaws Using The STRIDE, URL: http: //msdn.microsoft.com/en-gb/magazine/cc aspx. 35 / 36

36 References III (supplemental material) (supplemental material) References Wikipedia. Fault tree analysis. Accessed on Ruoyu Wu, Weiguo Li, and He Huang. An Attack Modeling Based on Hierarchical Colored Petri Nets. In Computer and Electrical Engineering, ICCEE International Conference on, pages , dec doi: /iccee / 36