ATTACKING SDN INFRASTRUCTURE:
ARE WE READY FOR THE NEXT-GEN NETWORKING?
Changhoon Yoon, Seungsoo Lee{chyoon87, lss365}@kaist.ac.kr

Contents
1. About us
2. Software-defined Networking (SDN) ?
3. Attacking SDN Infrastructure• Scenario: Attacking Software-Defined Data Center (SDDC)• Vulnerabilities

4. Recent work on SDN security
5. Conclusion

About us
http://nss.kaist.ac.kr

Seungwon Shin

- Assistant Professor of EE dept. at KAIST- Research Associate ofOpen Networking Foundation (ONF)- Leading Network and System Security Lab.

Changhoon Yoon
- PhD student at KAIST- Project SM-ONOS

Seungsoo Lee- PhD student at KAIST- Project DELTA

Traditional Networking• Too complicated• Control plane is implemented with complicated S/W and ASIC
• Unstable, increased complexity in management• Closed platform• Vendor specific• Hard to modify (nearly impossible)• Hard to add new functionalities• Barrier to innovation• New proposal: Software Defined Networking (SDN)• Separate the control plane from the data plane

Control Plane
Data Plane
Legacy Network Device

What is Software Defined Networking (SDN)?
• Centralized network management• Via global network view

• Programmable network• Flexible and dynamic network control• useful, innovative SDN applications• CAPEX, OPEX reduction• Commodity servers and switches

Control Plane
App 1App 2

App N

App 3

Northbound Interface
Core ServicesStorage

Southbound Interface
SDN Controller

Data Plane

Basic SDN operation
L2 ForwardingController

Host A

Host BSDN Switch

Flow Table
MATCH
Host Aà Host B

ACTION
FWD

Data Center Network DesignSpine

Leaf

Border
Leaf

Servers

Edge

East-West Traffic• Today’s Data Center involves a LOT of Virtual Machines (VMs)• “Leaf-Spine” Design• Suitable for handling “East-West” traffic; low latency & bottlenecks• Remaining challenges• Increased complexity – frequent VM migrations, a large number of links• Expensive to scale & maintain

Software-Defined Data Center (SDDC)
Distributed NOS
Node #1

Distributed NOS
Node #2

Distributed NOS
Node #3

SDDC
Control Plane

Spine

Leaf

Servers• Low complexity• Global network view + Network programmability• Low cost
• Commodity servers & switches• Centralized & automated management

Border
LeafEdge• Highly available & scalable control plane• Distributed SDN controller• VMs to host controller nodes

Attack Vectors
Distributed NOS
Node #1

Distributed NOS
Node #2

Malware- Malicious libraries/
SDN applications
Update, deploy

Distributed NOS
Node #3

DCN Admin/Operator

SDDC
Control Plane
Update, deploySpine

Build environment

LeafBorder
Leaf

Servers

Edge

Insider(tenant) attacks- DoS/Control plane saturation attack
against the NOS cluster- Topology Poisoning

Misconfiguration- Direct access to critical SDN components- CLI/GUI/SSH etc.

SDN Control Plane Components• Open Source SDN Controller (NOS) implementations• Open Network Operating System (ONOS) & OpenDaylight (ODL)• Cutting-edge, distributed network operating systems (NOS)• Provide base design for commercial SDN controller products• Brocade SDN Controller [1] : ODL-based• Both are Maven projects• Both run on Karaf OSGi container[1] http://www.brocade.com/en/products-services/software-networking/sdn-controllers-applications/sdn-controller.html

Attack Vector: Misconfiguration• Remotely accessible interfaces• Remote SSH to NOS host machines• Karaf container CLI• WebConsole, GUI• REST API• Defenses• Follow the security guideline available here:• http://docs.opendaylight.org/en/latest/getting-startedguide/security_considerations.html• Changing default credentials• Properly configuring Firewall policies to block remote accessAttack Vector: Malware• Malware infection at build-time• Malware infection at runtime

Attack Vector: Malware 1• Compromising SDN Control Plane at Build-timeCompromised build machine- Manipulated hosts file- Manipulated maven repo. setting- Etc.
Compromised build env. network- DNS cache poisoning attack- ARP spoofing attack- Etc.

Roguemaven repository

Maven
Repository
Automaticallyfetch
required components

Build environmentFetch source code

SDN controller
source code
repository

Build

Maven project build
Deployable
SDN controller package

SDN controller projectsourceConfiguration

Rogue
SDN controller
source code
repository

Deployment environment

Distributed NOS
Node #1

Distributed NOS
Node #2

Distributed NOS
Node #3

Attack Vector: Malware 2• Compromising SDN Control Plane at Runtime
Social Engineering attacks- Phishing (Spamming, Distribution via Web (Blogs, SNS, etc.)
Repackaging & Redistributing
DCN Admin/Operator

Deployment environment

Can install
SDN apps
at runtime

RESTAPIGUI
CLIApp1

App 2

App 3

App 4Malicious
AppApp 5

Northbound API
Core Services
Southbound API
Controller
Distributed NOS Node #1

Distributed NOS
Node #2

Distributed NOS
Node #3

Attack Vectors: Insider (tenant) attacks• Malicious tenants• Control plane saturation attack (DoS) against the NOS cluster [1]• Topology Poisoning [2]Distributed NOS
Node #1

Distributed NOS
Node #2

Distributed NOS
Node #3

SDDC
Control Plane

Spine

LeafServers[1] Shin, Seungwon, and Guofei Gu. "Attacking software-defined networks: A first feasibility study." Proceedings of the second ACM SIGCOMM workshop on Hot topics in software defined networking. ACM, 2013.
[2] Hong, Sungmin, et al. "Poisoning Network Visibility in Software-Defined Networks: New Attacks and Countermeasures." NDSS. 2015.

Border
LeafEdge

Attack Scenario 1
Compromising SDN control plane at build time to launch arbitrary SDN controller node injection attack
Rogue Maven Repository

Build environment
Maven project build
SDN controller projectsourceDeployable
SDN controller package

Deploymentenvironment

Distributed NOS
Node #1

reverse shell
Inject a rogue NOS node to the cluster

Distributed NOS
Node #2

Distributed NOS
Node #3

Attack Scenario 2
Compromising SDN control plane at runtime to launch stealth network performance attack

Third-Party SDN
APP StoreDownload

Stealthily degrade thenetwork performance!

DeployDCN Admin/Operator

Distributed NOS
Node #1

Distributed NOS
Node #2

Manipulate the Leaf-Spine fabric toaﬀect the overall network performance

DCN

Distributed NOS
Node #3

Deploymentenvironment

The Vulnerabilities (selected from the scenario)
1.
2.
3.
4.

No System Integrity Protection
No authentication of NOS cluster nodes
No application access control
Switch Device Firmware Abuse

5.

Packet-IN Flooding

6.
7.

Control Message Manipulation
Eavesdrop

8.

Internal Storage Manipulation

9.

….

Want more?
Visit http://sdnsecurity.org !!
(will open in 09/2016)

Vulnerability 1. No system integrity protection• There is no system integrity protection for NOS components• Integrity of the CORE NOS components must be guaranteed
Maven project build
Deployable
SDN controller package• Possible Defenses
Configuration- Code signing- Integrity protection mechanisms (e.g. checksum)Distributed NOS
Node #1

Distributed NOS
Node #2

Distributed NOS
Node #3

Vulnerability 2. No authentication of NOS cluster nodes
Distributed NOS
Node #1

Distributed NOS
Node #2

San Francisco AS
NewYork AS
External
BGP Routers

External
BGP Routers• Possible Defense

SD-WAN- PKI-based authentication
for the NOS components

Los Angeles AS

Malicious NOS
NodeExternal
BGP Routers• The malicious node can completely take overthe control of the entire control plane and the network

External
BGP Routers

Florida AS

Vulnerability 3. No application access control[CP-1] Service Chain Interference[CP-2] Flow Table Manipulation

App1App 2

App 3

DistributedNOS cluster[CP-3] Flow
Rule Flooding

Malicious
AppApp 4DCN Admin/Operator[CP-4] Controller Shutdown[CP-5] Resource Exhaustion

Northbound APIRESTAPIGUI
CLI[CP-6] System Variable Manipulation[CP-7] Internal Storage Manipulation

Core Services[CP-8] Application Eviction
Southbound API• Possible Defense

Controller
Distributed NOS Node #1[CP-8] Switch Firmware Abuse

Distributed NOS
Node #2- Policy-based access control for SDN application

Distributed NOS
Node #3

SSH
SDN-SW 1SDN-SW 3SDN-SW 2SDN-SW 5SDN-SW 4SDN-SW 7SDN-SW 6• SDN applications are granted very powerful authority; need to limit

SDN-SW 9SDN-SW 8SDN-SW 10

Data PlaneVulnerability 4. Switch device firmware abuse
App 1App 2

App NController• Packet matching strategy:
Hardware-based vs. Software-based• The strategy depends onthe vendor or the firmware version

Host A[1] HP. HP Switch Software OpenFlow Administrator's Guide K/KA/WB 15.14

HP 3800 Switch Match Chart [1]Hardware Table
MATCH
IP.HOST A -> IP.HOST B
IP.HOST B -> IP.HOST A

OpenFlow
SwitchACTIONOUT: FW1
OUT: FW2

Software Table
Hardwarematch ACTION
MATCHSoftware
HostmatchB

Vulnerability 4. Switch device firmware abuse
Network performance degradation
App 1

Latency

Malicious
App

App N

2aX2Controller

aHardware
Table
Software Table
MATCH
IP.HOST A ->-> MAC.HOST
IP.HOST B B
MAC.HOST
IP.HOST BB -> IP.HOST
AA
MAC.HOST
MAC.HOSTFLOW_MOD

FLOW_MOD• Override IP matching flow ruleswith MAC matching flow rules!

Host A• Possible Defense

ACTIONOUT: FW1
OUT: FW2- Flow rule conflict detection & arbitration
OpenFlow
SwitchHost BSDN Security Assessment: Project DELTA• Delta (collaborate with ONF) is a new SDN security evaluation frameworkwith two main functions [1]:1.
2.

Automatically instantiates known attack cases
against SDN elements across diverse environments
AppAssists in uncovering unknown security
Agentproblems within an SDN deployment

App N

App 2
Northbound Interface
Core Services

Web UI

StorageSouthbound Interface
SDN Controller
Channel
Agent
Agent Manager[1] http://opensourcesdn.org/projects/project-delta-sdn-security-evaluation-framework/

Host Agent

SDN Application security policy enforcement• Security-Mode ONOS
• Inspired by Mobile application security mechanisms• Constrains ONOS (SDN) applications’ behavior• A security policy per app• Detects and blocks
security policy violations at runtime

OSGi protection domain
A

ONOS App 1Policy
file

OSGi protection domain
ONOS App 2

grantpermissionsBB
NB APIAdmin Service

Service

ONOS NB-API permission checker
CoreSB APIPolicy
file

Device Manager
Provider Service

parseC

Host Manager
Provider Registry

Providers

Security Manager

A

Bundle-level RBACB

App-level RBAC

CAPI-level
permission-based ACProtocols
Network Elements

SDNSecurity.org(will open in 09/2016)• We try to discover SDN specific vulnerabilities and devote to systematizing
and characterizing all related points.
• Currently, we have 8 on-going projects and 8 finished projects.
[A-5] Control Message Abuse[A-2] Service Chain Interference

Application Plane[A-6] Northbound API Abuse

AppApp[A-7] Resource Exhaustion[A-9] System Command Execution

Northbound API[A-3] Internal Storage Manipulation[A-1] Packet-In Flooding[A-8] System Variable Manipulation

Network Operating System[A-4] Control Message Manipulation[A-10] Network Topology Poisoning

Southbound API
SDN Controller

Control Channel

Control Plane[B-1] Eavesdrop[B-2] Man-In-The-Middle

Control Channel[C-1] Flow Rule Flooding

Switch Firmware

http://sdnsecurity.org[C-3] Control Message Manipulation

Flow TableSDN Switch

SDN Switch

SoftwareHardware[C-2] Firmware Abuse

Data PlaneSDN Vulnerability Genome ProjectFinal remarks• Are we ready for the next-gen networking?
• No, not yet at least from a security point of view

• A LOT of work still needs to be done to improve the security of SDN.
• Your urgent attention is needed!

Thank you