OpenFlow: A Security Analysis · components and the basic functions of the switch, ... Runs Open...

IntroductionApproach

ResultsRecommendations

Conclusion

OpenFlow: A Security Analysis

Rowan Kloti1 Vasileios Kotronis2 Paul Smith3

[email protected] Zurich

[email protected] Zurich

[email protected] Austrian Institute of Technology GmbH

07.10.2013ICNP NPSec 2013, Gottingen, Germany

1 / 36



Conclusion

Outline

1 IntroductionObjectivesSDN and OpenFlow

2 ApproachAttack ModelSTRIDEAttack TreesCombining the ApproachesExperimental Setup

3 ResultsSecurity AnalysisEmpirical Testing

4 Recommendations

5 Conclusion2 / 36



Conclusion

ObjectivesSDN and OpenFlow

Objectives

Security analysis of OpenFlow protocol and networks

Focus on v1.0.0, but extensible/adaptable methodologyDevelop modelAnalyze modelDescribe 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



Conclusion


Why OpenFlow Security Analysis?

OpenFlow started as a largely academic endeavour

But has recently seen increasing deployment in productionsystems:

Google’s OpenFlow WANCisco, Juniper, HP productsAdoption by cloud hosts and service providers

But why security?

No official security analysis of the protocol itselfResearch is just catching up (see HotSDN 2013 program)Security is extremely important for production systems, butcan be overlooked

4 / 36



Conclusion


SDN and OpenFlow 101

Software Defined Networks (SDNs)separate data plane and control plane

OpenFlow implements SDN:

Switch implements data planeController implements control planeSwitch and controller connected withsecure channel over control networkController installs flow rules onswitchFlow rule header fields match packetheadersPackets matching a flow rule haveactions performed on them

Header

Fields

Counters

Actions

OpenFlow Switch Specification

Version 1.0.0 ( Wire Protocol 0x01 )

December 31, 2009

1 Introduction

This document describes the requirements of an OpenFlow Switch. We rec-ommend that you read the latest version of the OpenFlow whitepaper beforereading this specification. The whitepaper is available on the OpenFlow Con-sortium website (http://OpenFlowSwitch.org). This specification covers thecomponents and the basic functions of the switch, and the OpenFlow protocolto manage an OpenFlow switch from a remote controller.

Version 1.0 of this document will be the first for which official vendor supportis expected. Versions before 1.0 will be marked “Draft”, and will include theheader: “Do not build a switch from this specification!” We hope to generatefeedback prior to Version 1.0 from switch designers and network researchers, sothat the set of features defined in Version 1.0 enables production deploymentson a variety of vendor hardware.

Figure 1: An OpenFlow switch communicates with a controller over a secureconnection using the OpenFlow protocol.

1

5 / 36



Conclusion

Attack ModelSTRIDEAttack TreesCombining the ApproachesExperimental Setup

Attack Model

Three scenarios

Attacker controls a single clientAttacker controls multiple clientsAttacker has access to control network

The first scenario is given greatest consideration

Scenarios where attacker has access to actual secure channelare not considered

This would involve compromising SSL or TLS, which is outsidethe scope of this work

6 / 36



Conclusion


STRIDE

Security modeling methodology

Types of vulnerabilities modeledby the method[3]:

SpoofingTamperingRepudiationInformation DisclosureDenial of Service andElevation of Privilege

Use data flow diagrams touncover potential vulnerabilities

Models how external dataenters into and propagatesthrough system

Client

Web application

Database

Request Reply

Query Results

Figure : Data flow diagram

7 / 36



Conclusion


Attack Trees

Used to describe and analyzeattacks

Based on fault tree analysis[4]

Represent prerequisites forattacks

Leaf nodes represent actionsor eventsThese propagate throughAND and OR gatesRoot node is objectiveCan calculate various metricsif values for leaf nodes areknown

Get root access

Dictionary attack

Social engineering

Exploit vulnerability

Develop exploit

Find vulnerability

Execute attack

Figure : Attack tree

8 / 36



Conclusion


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 pathsAttack trees help to analyze and optimise attack paths

These two approaches are complementary

9 / 36



Conclusion


Experimental Setup

Mininet is a virtual network emulation environment

Based on Linux network namespacesRuns Open vSwitch (virtual OpenFlow switch)

Can emulate performance constraints

BandwidthLatency and jitterThis is required to simulate attacks

Forms the basis of test environment

Use POX as a controller

10 / 36



Conclusion


Setup Schematics

h1h1 h2h2

c0c0

s1s1

Figure : Network topology forDenial of Service attackdemonstration

h1-1h1-1 h2-1h2-1

c0c0

s1s1 s2s2

h1-3h1-3 h2-3h2-3

h1-2h1-2h1-2h1-2 h2-2h2-2

Figure : Network topology forInformation Disclosure attackdemonstration

11 / 36



Conclusion

Security AnalysisEmpirical Testing

Denial of Service I

Asynchronous message

Input buffer 1

Secure ChannelData path

Packet to process

Read flow table

Update counter

Set state/actionPacket 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 ServiceInformation Disclosure

Tampering

Flow table

Figure : Data flow diagram of switch

12 / 36



Conclusion


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


Tampering

Flow table

Data path

Figure : Close-up of data flow diagram

13 / 36



Conclusion


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

on 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

on each interface

Generate extremely high traffic load on

interface

Obtain access to multiple

client interfaces


client interfaces

Obtain access to management

network

Locate security hole in

controller software

Develop exploitPerform processor

intensive tasks on several

connections

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



Conclusion


Denial of Service IV

Denial of service

Against switch

Against Flow table

Generate very high traffic

load on interface


created without

wildcards

Figure : Close-up of highlighted attack path

15 / 36



Conclusion


Information Disclosure I



OpenFlow Interface

Policy

Administration interface

Write policyRead 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


Tampering

Figure : Data flow diagram of controller

16 / 36



Conclusion


Information Disclosure II



OpenFlow Interface

Decision

Get state/event

Set state/action


Tampering

Switch

Figure : Close-up of data flow diagram

17 / 36



Conclusion


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


client interfaces


client interfaces

Force another client to reflect

traffic or produce response




client interfaces



Wait for flow rule timeout,

repeat procedure for

statistical certainty

Select packet contents based on policy query

type

Select packet contents based

on 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



Conclusion


Information Disclosure IV

Information disclosure

Against controller

Disclose existing flows with side channel attack

Send packets, measure

time


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



Conclusion


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

0

10000

20000

30000

40000

50000

60000

Soft timeout [s]

Pac

kets

lost

Figure : Number of lost packets vs rule timeout value due to flow tableoverflow (with control link at 100 Mbps and 1ms latency)

20 / 36



Conclusion


Information Disclosure I

0

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

Fre

qu

en

cy

Measured response time [ms]

Single flow (initial)

Two flows (new+initial),distinct

Figure : Distribution of measured times with exact matching flow rules

21 / 36



Conclusion


Information Disclosure II

50 60 70 80 90 100 110 120 130 140 150 160 170 180 190 200

0

2

4

6

8

10

12

14

16

18

20


Fre

qu

en

cy

Single flow (initial)

Two flows (new+initial),aggregated

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

22 / 36



Conclusion

Denial of Service

Rate Limiting, Event Filtering, Packet Dropping, RuleTimeout Adjustment

Some of them introduced in newer OpenFlow standardsExample of usage: large timeouts lighten load on controllerbut can cause table overflows

Flow Aggregation

Try to reduce load on controller with proactive strategies

Attack Detection

Employ OpenFlow for logically centralized detectionDirect flows to specialized monitoring systems

Access Control - Distributed Firewall

ACLs implemented as sets of flow rules on the switch

23 / 36



Conclusion

Information Disclosure

Proactive Strategies

Remove response time-state dependency

Randomization

Increase variance of measurable response timesClever rule timeout randomization

Direct Attack Detection-Mitigation

Exploit bird’s eye view over traffic to detect suspicious patternsEnact counter-measures using direct flow control

24 / 36



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, parallelismBut further work is required!

Demonstrated two different forms of attack

Developed test setup (could be used for unit tests)

Contributions

Extensible and adaptable methodologyTowards SDN architectures that are more secure by design

25 / 36



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 analyseThis level of formalism is not neededLess suited to fully asynchronous systemDifficult to model system with discrete, fully enumerated states

State-based system models[1, 2]

These systems tend to model control flow rather than data flowOpenFlow specification does not require any particular controlflowMight be useful with a given controller

27 / 36


References

Denial of Service V

Identify which flow rules are created with or without

wildcards

Determine from timing analysis


client interfaces



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


client interfaces

Use forged source addresses

Figure : Denial of service attack tree with attack path highlighted

28 / 36


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


References

Information Disclosure V

Force another client to reflect traffic or produce response

UDP based trafficICMP 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


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


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

0

10000

20000

30000

40000

50000

60000

Soft timeout [s]

Pac

kets

lost

Figure : Number of lost packets vs timeout value due to flow tableoverflow (with control link at 10 Mbps and 10ms latency)

32 / 36


References

Information Disclosure (Empirical) III

40 45 50 55 60 65 70 75 80 85 90 95 100 105 110 115 120

0

1

2

3

4

5

6

7

8

9

10


Freq

uen

cy

Without aggregation

With aggregation

Figure : Distribution of times with source address and port as wildcardsand asymmetrical delay (delay in control network shorter than in datanetwork)

33 / 36


References

References I

O. El Ariss, Jianfei Wu, and Dianxiang Xu.Towards an Enhanced Design Level Security: IntegratingAttack 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 – QoSAand ACM SIGSOFT symposium – ISARCS on Quality ofsoftware architectures – QoSA and architecting critical systems

34 / 36

http://dx.doi.org/10.1109/SSIRI.2011.11


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 AdamShostack.Uncover Security Design Flaws Using The STRIDE Approach,2006.URL: http://msdn.microsoft.com/en-gb/magazine/cc163519.aspx.

35 / 36

http://doi.acm.org/10.1145/2000259.2000281

http://dx.doi.org/10.1145/2000259.2000281

http://msdn.microsoft.com/en-gb/magazine/cc163519.aspx

http://msdn.microsoft.com/en-gb/magazine/cc163519.aspx


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

http://en.wikipedia.org/wiki/Fault_tree_analysis

http://dx.doi.org/10.1109/ICCEE.2008.69

Date post:	31-Aug-2018
Category:	Documents
Upload:	buikhanh
View:	226 times
Download:	0 times

OpenFlow: A Security Analysis · components and the basic functions of the switch, ... Runs Open...

Documents