OpenFlow: A Security Analysis oti 1 Vasileios Kotronis 2 Paul Smith 3 - - PowerPoint PPT Presentation

Introduction Approach Results Recommendations Conclusion

OpenFlow: A Security Analysis

Rowan Kl¨

• ti1

Vasileios Kotronis2 Paul Smith3

1rkloeti@alumni.ethz.ch

ETH Zurich

2vkotroni@tik.ee.ethz.ch

ETH Zurich

3paul.smith@ait.ac.at

AIT Austrian Institute of Technology GmbH

07.10.2013 ICNP NPSec 2013, G¨

• ttingen, Germany

1 / 36

Introduction Approach Results Recommendations Conclusion

Outline

1

Introduction Objectives SDN and OpenFlow

2

Approach Attack Model STRIDE Attack Trees Combining the Approaches Experimental Setup

3

Results Security Analysis Empirical Testing

4

Recommendations

5

Conclusion

2 / 36

Introduction Approach Results Recommendations Conclusion Objectives SDN and OpenFlow

Objectives

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

Introduction Approach Results Recommendations Conclusion Objectives SDN and OpenFlow

Why OpenFlow Security Analysis?

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

Introduction Approach Results Recommendations Conclusion Objectives SDN and OpenFlow

SDN and OpenFlow 101

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

Header Fields Counters Actions

5 / 36

Introduction Approach Results Recommendations Conclusion Attack Model STRIDE Attack Trees Combining the Approaches Experimental Setup

Attack Model

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

Introduction Approach Results Recommendations Conclusion Attack Model STRIDE Attack Trees Combining the Approaches Experimental Setup

STRIDE

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 Web application Database Request Reply Query Results

Figure : Data flow diagram

7 / 36

Introduction Approach Results Recommendations Conclusion Attack Model STRIDE Attack Trees Combining the Approaches Experimental Setup

Attack Trees

Used to describe and analyze attacks Based on fault tree analysis[4] Represent prerequisites for attacks

Leaf nodes represent actions

• r events

These propagate through AND and OR gates Root node is objective Can calculate various metrics if values for leaf nodes are known

Get root access Dictionary attack Social engineering Exploit vulnerability Develop exploit Find vulnerability Execute attack

Figure : Attack tree

8 / 36

Introduction Approach Results Recommendations Conclusion Attack Model STRIDE Attack Trees Combining the Approaches 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

Introduction Approach Results Recommendations Conclusion Attack Model STRIDE Attack Trees Combining the Approaches Experimental Setup

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

Introduction Approach Results Recommendations Conclusion Attack Model STRIDE Attack Trees Combining the Approaches Experimental Setup

Setup Schematics

h1 h1 h2 h2 c0 c0 s1 s1

Figure : Network topology for Denial of Service attack demonstration

h1-1 h1-1 h2-1 h2-1 c0 c0 s1 s1 s2 s2 h1-3 h1-3 h2-3 h2-3 h1-2 h1-2 h1-2 h1-2 h2-2 h2-2

Figure : Network topology for Information Disclosure attack demonstration

11 / 36

Introduction Approach Results Recommendations Conclusion Security Analysis Empirical Testing

Denial of Service I

Asynchronous message Input buffer 1 Secure Channel Data path Packet to process Read flow table Update counter Set state/action Packet sample Read flow table Interface 1 Received packet Interface 2 Transmitted packet Output buffer 2 Forwarded/Enqueued packet Output buffer 1 Forwarded/Enqueued packet Transmitted packet Remove/modify packet Input buffer 2 Received packet Packet to process OpenFlow Module Transmit packet Modify flow table Get state/event Received packet from 1 Sent packet to 1 Sent packet to 2 Received packet from 2 Controller-to-switch message Remove/modify packet

Denial of Service Information Disclosure Tampering

Flow table

Figure : Data flow diagram of switch

12 / 36

Introduction Approach Results Recommendations Conclusion Security Analysis Empirical Testing

Denial of Service II

Secure Channel Read flow table Update counter Set state/action Packet sample Read OpenFlow Module Transmit packet Modify Get state/event

Denial of Service Information Disclosure Tampering

Flow table Data path

Figure : Close-up of data flow diagram

13 / 36

Introduction Approach Results Recommendations Conclusion Security Analysis Empirical Testing

Denial of Service III

Denial of service Against switch Against controller Against Flow table Against OpenFlow Interface and data flow Asynchronous message Against OpenFlow Module Generate very high traffic load

• n interface

Exploit security hole in controller (if present) Against Input buffer Attack controller OpenFlow Interface directly Perform regular denial of service attack against controller Attack OpenFlow Interface and Asynchronous message Generate very high rate of new flows on several interfaces Generate very high traffic load

• n each

interface Generate extremely high traffic load on interface Obtain access to multiple client interfaces Obtain access to multiple client interfaces Obtain access to management network Locate security hole in controller software Develop exploit Perform processor intensive tasks

• n several

connections Identify which flow rules are created without wildcards Identify which flow rules are created without wildcards Identify which flow rules are created without wildcards Against Decision process 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

Introduction Approach Results Recommendations Conclusion Security Analysis Empirical Testing

Denial of Service IV

Denial of service Against switch Against Flow table Generate very high traffic load on interface Identify which flow rules are created without wildcards

Figure : Close-up of highlighted attack path

15 / 36

Introduction Approach Results Recommendations Conclusion Security Analysis Empirical Testing

Information Disclosure I

Asynchronous message Controller-to-switch message OpenFlow Interface Policy Administration interface Write policy Read policy Administrator Get value Decision Get state/event Set state/action Get policy Log Write log Read log Write log Set configuration Get configuration Set value

Denial of Service Information Disclosure Tampering

Figure : Data flow diagram of controller

16 / 36

Introduction Approach Results Recommendations Conclusion Security Analysis Empirical Testing

Information Disclosure II

Asynchronous message Controller-to-switch message OpenFlow Interface Decision Get state/event Set state/action

Denial of Service Information Disclosure Tampering

Switch

Figure : Close-up of data flow diagram

17 / 36

Introduction Approach Results Recommendations Conclusion Security Analysis Empirical Testing

Information Disclosure III

Information disclosure Against switch Against controller Disclose existing flows with side channel attack Disclose whether a new flow rule is created Send packets between clients, measure time Disclose existing flow actions with side channel attack Obtain hardware, measure reaction times Send many packets between clients, measure time Send packet between clients, measure time Repeat procedure second time, measure time difference Obtain access to multiple client interfaces Obtain access to multiple client interfaces Force another client to reflect traffic or produce response 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

• n policy query

type Select packet contents based

• n flow rule

query type Against data flow Packet sample Against data flow Asynchronous message

Figure : Information Disclosure attack tree with attack path highlighted

18 / 36

Introduction Approach Results Recommendations Conclusion Security Analysis Empirical Testing

Information Disclosure IV

Information disclosure Against controller Disclose existing flows with side channel attack Send packets, measure time Obtain access to multiple client interfaces Force another client to produce response Select packet contents Against data flow Asynchronous message

Figure : Close-up of highlighted attack path

19 / 36

Introduction Approach Results Recommendations Conclusion Security Analysis Empirical Testing

Denial of Service

10 13 16 19 22 25 28 31 34 37 40 43 46 49 52 55 58 61 64 67 70 73 76 79 82 85 10000 20000 30000 40000 50000 60000 Soft timeout [s] Packets lost

Figure : Number of lost packets vs rule timeout value due to flow table

• verflow (with control link at 100 Mbps and 1ms latency)

20 / 36

Introduction Approach Results Recommendations Conclusion Security Analysis Empirical Testing

Information Disclosure I

2 4 6 8 10 12 14 16 18 20 50 60 70 80 90 100 110 120 130 140 150 160 170 180 190 200 Frequency Measured response time [ms] Single flow (initial) Two flows (new+initial), distinct

Figure : Distribution of measured times with exact matching flow rules

21 / 36

Introduction Approach Results Recommendations Conclusion Security Analysis Empirical Testing

Information Disclosure II

50 60 70 80 90 100 110 120 130 140 150 160 170 180 190 200 2 4 6 8 10 12 14 16 18 20 Measured response time [ms] Frequency Single flow (initial) Two flows (new+initial), aggregated

Figure : Distribution of times with source address and port as wildcards

22 / 36

Introduction Approach Results Recommendations Conclusion

Denial of Service

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

Introduction Approach Results Recommendations Conclusion

Information Disclosure

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

Introduction Approach Results Recommendations Conclusion

Conclusion

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

Introduction Approach Results Recommendations Conclusion

Discussion

Thank you very much for your attention! Questions?

26 / 36

Approach (supplemental material) Results (supplemental material) References

Other Approaches

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

Approach (supplemental material) Results (supplemental material) References

Denial of Service V

Identify which flow rules are created with or without wildcards Determine from timing analysis Obtain access to multiple client interfaces Force another client to reflect traffic or produce response Compromise controller Social engineering or educated guess Send packet between clients, measure time Repeat procedure second time, measure time difference For each header column, select two neighboring values 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. Send falsified ARP or LLDP or routing packets to redirect traffic Obtain access to multiple client interfaces Use forged source addresses

Figure : Denial of service attack tree with attack path highlighted

28 / 36

Approach (supplemental material) Results (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

Approach (supplemental material) Results (supplemental material) References

Information Disclosure V

Force another client to reflect traffic or produce response UDP based traffic ICMP 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 NB: This attack tree should not be considered exhaustive.

Figure : Information disclosure attack tree with attack path highlighted

30 / 36

Approach (supplemental material) Results (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

Approach (supplemental material) Results (supplemental material) References

Denial of Service (Empirical) II

10 13 16 19 22 25 28 31 34 37 40 43 46 49 52 55 58 61 64 67 70 73 76 79 82 85 10000 20000 30000 40000 50000 60000 Soft timeout [s] Packets lost

Figure : Number of lost packets vs timeout value due to flow table

• verflow (with control link at 10 Mbps and 10ms latency)

32 / 36

Approach (supplemental material) Results (supplemental material) References

Information Disclosure (Empirical) III

40 45 50 55 60 65 70 75 80 85 90 95 100 105 110 115 120 1 2 3 4 5 6 7 8 9 10 Measured response time [ms] Frequency Without aggregation With aggregation

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

Approach (supplemental material) Results (supplemental material) References

References I

• 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 2011. doi:10.1109/SSIRI.2011.11. 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

Approach (supplemental material) Results (supplemental material) References

References II

– ISARCS, QoSA-ISARCS ’11, pages 123–132, New York, NY, USA, 2011. ACM. URL: http://doi.acm.org/10.1145/2000259.2000281, doi:10.1145/2000259.2000281. Shawn Hernan, Scott Lambert, Tomasz Ostwald, and Adam Shostack. Uncover Security Design Flaws Using The STRIDE Approach, 2006. URL: http: //msdn.microsoft.com/en-gb/magazine/cc163519.aspx.

35 / 36

Approach (supplemental material) Results (supplemental material) References

References III

Wikipedia. Fault tree analysis. http://en.wikipedia.org/wiki/Fault_tree_analysis. Accessed on 02.04.2013. Ruoyu Wu, Weiguo Li, and He Huang. An Attack Modeling Based on Hierarchical Colored Petri Nets. In Computer and Electrical Engineering, 2008. ICCEE 2008. International Conference on, pages 918–921, dec. 2008. doi:10.1109/ICCEE.2008.69.

36 / 36