The Finest Penetration Testing Framework for Software-Defined Networks
•
2 likes•1,205 views
Software-Defined Networking (SDN) is getting attention for the next-generation networking today. The key concept of SDN is to decouple the control logic from the traditional network devices so that network developers can design innovative network functions in a more flexible and programmable way. However, SDN is not always bringing advantages to us. Security experts have constantly raised security concerns about SDN, and some vulnerabilities have been uncovered in the real world. If SDN is not secure, how can we measure the security level of SDN environments? In this talk, we introduce a powerful penetration testing tool for SDN called DELTA, which is officially supported by Open Networking Foundation (ONF). First, DELTA can automate diverse published attack scenarios against various SDN components from testing to evaluating. Also, to discover unknown vulnerabilities that may exist in SDN, DELTA leverages a blackbox fuzzing technique that randomizes different control flows in SDN. It enables us to systemically reveal unknown security issues rather than the empirical and ad-hoc methods that most previous studies use. By using DELTA, anyone can easily and thoroughly test not only popular open source SDN controllers (i.e., ONOS, OpenDaylight, Floodlight, and Ryu), but also SDN-enabled switches (i.e., OpenvSwitch, HP, and Pica8) in the real world. We will show nine new attack cases that have been found by DELTA but never been announced before. Also, we will discuss: - What control flows are in SDN, and why those are important as a key feature compared to the traditional networks. - What key components and workflow of DELTA to attack the real SDN components. - Which nine new attack cases have been discovered by DELTA, and we will demonstrate it. For example, one of the new attacks violates the table condition, leading to the black hole of handling packets in the switch.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to The Finest Penetration Testing Framework for Software-Defined Networks
Similar to The Finest Penetration Testing Framework for Software-Defined Networks (20)
More from Priyanka Aash
More from Priyanka Aash (20)
Recently uploaded
Recently uploaded (20)
The Finest Penetration Testing Framework for Software-Defined Networks
- 1. The Finest Penetration Testing Framework for Software-Defined Networks Seungsoo Lee, Jinwoo Kim, Seungwon Woo and Seungwon Shin {lss365, jinwoo.kim, seungwonwoo, claude}@kaist.ac.kr
- 2. / 58 About us 2 Seungsoo Lee - PhD student at KAIST Seungwon Shin - Associate Professor of EE dept. at KAIST - Leading Network and System Security Lab. Jinwoo Kim - PhD student at KAIST Seungwon Woo - Master student at KAIST
- 3. / 58 1. Motivation of DELTA 2. Software-Defined Networking (SDN) • SDN & OpenFlow basics • Security of SDN 3. DELTA framework • Architecture • Attack case demonstrations 4. Final remarks 3 Contents
- 4. / 58 • Why needed? • Software-defined Networking (SDN) are still prone to security threats • We need to run security tests against our SDNs • But, manually testing each attack is time consuming and annoying job • DELTA can AUTOMATICALLY… • Construct an SDN security test environment • (i) Reproduce the known attacks • (ii) Find new attacks by randomizing SDN control flows (i.e., OpenFlow) 4 Motivation of DELTA
- 6. / 586 SDN controller Switch • Separation & Centralization of the control plane Switch Switch Switch • OpenFlow: • A de-facto standard SDN protocol Control Plane Data Plane Control Plane Data Plane Control Plane Data Plane Control Plane Data Plane Host A Host B Host C Control Plane Software-defined Networking (SDN)
- 7. / 58 7 SDN controller OpenFlow Switch OpenFlow Switch OpenFlow Switch OpenFlow Switch H-A SW1 H-B SW2 SW3 SW4 H-C Global network view • Global network view + APPs + Dynamic network control = PROGRAMMABLE NETWORK !! • Flexible service customization • Various network functions in SDN APPs • DHCP, Firewall, DDoS detector, and etc. • New opportunities • Global network view + SDN APPs = Intelligent & innovative network/security services • Automated network management SDN: New opportunities Host A Host B Host C
- 8. / 58 • A De-facto standard protocol in SDN • Maintained by Open Networking Foundation • Supported by 120+ industrial members • Version timeline 8 OpenFlow Dec. 2009 Feb. 2011 Dec. 2011 Apr. 2012 Aug. 2013 Jan. 2015 OpenFlow 1.0 Single table Fixed 12 tuple match field OpenFlow 1.1 Multi-table Group-table OpenFlow 1.2 Role change IPv6 OpenFlow 1.4 Synchronized Table Default Port to 6653 OpenFlow 1.3 Long term release: 1.3.1, 1.3.2, 1.3.3 Meters OpenFlow 1.5 Egress Table Packet Type Aware Pipeline https://www.opennetworking.org/
- 9. / 58 • 22 message types • Flow table structure • Header fields, actions and counters PKT 9 OpenFlow 1.0 OpenFlow Switch Header Fields (i.e., Match fields) Actions Counters InPort EthSrc EthDst EthType VLANID VLANPri IPSrc IPDst IPProto IPToS TCP/UDP SrcPort TCP/UDP DstPort Flow Table Structure version type length xid (transaction identifier) Body 32 bits OpenFlow Structure • Fixed 12 match fields • If matched, perform actions and update counters • Forward packet to controller or ports • Drop packet • Modify fields • Per-table, per-flow, per-port and per queue • Packet and byte counters HELLO FLOW_MOD PACKET_IN
- 10. / 5810 OpenFlow 1.0: Basic Operation SDN controller Host A (10.0.0.1) Host B (10.0.0.2)OpenFlow Switch Header Fields (i.e., Match fields) Actions Counters Priority InPort EthSrc EthDst EthType VLANID VLANPri IPSrc IPDst IPProto IPToS TCP/UDP SrcPort TCP/UDP DstPort Flow Table Structure 1 2 PKT PKT HELLO HELLOPACKET_IN FLOW_MOD 10 [InPort]: 1, [EthType]: 0x0800, [IPDst]: 10.0.0.2 Forward 2 P: 0, B: 0P: 1, B: 64
- 11. / 58 • Released in Dec. 2009. • 22 message types • Single controller • Single flow table • Fixed 12 tuple match fields 11 OpenFlow 1.0 vs. OpenFlow 1.3 OpenFlow 1.0 • Released in Apr. 2012. • 30 message types • Multiple controllers • Multiple flow tables • Extensible match (OXM) • Group table • Meter table • Instruction (action set) OpenFlow 1.3
- 15. / 58 3470 4830 6160 8140 9720 2013 2014 2015 2016 2017 2018 Keywords: SDN & Security Paper Counts 15 * Google scholar [scholar.google.com] Attention to SECURITY has been growing! 3470 9720 BlackHat USA 15’ Briefing BlackHat USA 16’ Briefing BlackHat USA 17’ Arsenal BlackHat USA 17’ Briefing
- 18. / 5818 Application Plane Control Plane Data PlaneSDN Switch SDN Switch SDN Controller Switch Firmware HardwareSoftware Flow Table Network Operating System App Southbound API Northbound API App [A-5] Control Message Abuse Control Channel Control Channel [A-6] Northbound API Abuse [A-3] Internal Storage Manipulation[A-1] Packet-In Flooding [A-2] Service Chain Interference [A-4] Control Message Manipulation [A-7] Resource Exhaustion [A-8] System Variable Manipulation [A-9] System Command Execution [B-1] Eavesdrop [B-2] Man-In-The-Middle [C-1] Flow Rule Flooding [C-2] Firmware Abuse [C-3] Control Message Manipulation [A-10] Network Topology Poisoning [1] Yoon, Changhoon, et al. "Flow wars: Systemizing the attack surface and defenses in software-defined networks." IEEE/ACM Transactions on Networking 6 (2017): 3514-3530. Control plane Data plane Control channel SDN Vulnerability Genome Project [1]
- 20. / 58 • DELTA: A Security Assessment Framework for SDN 20 Covering many attack casesAutomating a working process Supporting diverse SDN components Finding new attacks Don’t worry, run DELTA
- 21. / 5821 SDN controller OpenFlow Switch OpenFlow Switch OpenFlow Switch OpenFlow Switch Host Agent Host A Host B Core APIs DB App 2 App 3 Agent Manager Channel Agent App Agent . Network hub DELTA: System Design DELTA control channel
- 22. / 5822 Agent Manager ● Agent Manager • The ‘Control tower’ • Remotely controls the agents deployed to the target network • Leverages different agents to perform various security test cases • Analyzes the test results collected from the agents DELTA: System Design
- 23. / 5823 App Agent . ● Application Agent • SDN applications that conduct attack procedures as instructed by the manager • Implements the known malicious functions as an application agent library • Includes fuzzing modules that randomize the SDN control flows DELTA: System Design
- 24. / 58 DELTA: System Design 24 Channel Agent ● ‘Channel Agent’ • Located between the controller and the switch • Includes fuzzing modules that sniff and modify the unencrypted SDN control messages • Mimics a dummy controller / switch
- 25. / 5825 Host Agent ● ‘Host Agent’ • A legitimate network host participating in the target SDN • Generates network traffic as instructed by the agent manager ( e.g. DDoS, LLDP injection etc. ) • Checks the connectivity to other hosts DELTA: System Design
- 26. / 5826 SDN controller OpenFlow Switch OpenFlow Switch OpenFlow Switch OpenFlow Switch Host Agent Host A Host B Core APIs DB App B App C Channel Agent Agent Manager App Agent . Network hub 1. Select reproducing known test case or finding unknown test case 2. Instruct each agent to conduct the test 3. Collect the result of the test from each agent 4. Notify the result Automating a working process Automated Operation
- 27. / 58 • Find NEW security holes in SDN (i.e., OpenFlow protocol based) • Define three types of control flow operations 1. Symmetric control flow: Req. & Res. message pair 2. Asymmetric control flow: One-way message 3. Intra-controller control flow: between applications and core services 27 OpenFlow Switch Core Services DB App A App B SDN controller App C REQRESMSG MSG SDN Control Flow Fuzzing ECHO_REQECHO_RES PACKET_INFLOW_MOD
- 28. / 5828 r S1 S2 S3 S4 receive HELLOsend HELLO send FEATURES_REQ receive FEATURES_RES S5 send GET_CONFIG_REQ S6 receive GET_CONFIG_RES S7 send SET_CONFIG I1 update topology A1 receive PORT_STATUS S8 send STATS_REQ S9 receive STATS_RES A3 update topology deliver to applications update topology A2 receive PACKET_IN deliver to applications A4 send FLOW_MOD S14 A7 send PACKET_OUT S15 receive BARRIER_RESsend BARRIER_REQ I2 send PACKET_OUT update internal flow tables update internal flow tables update internal flow tables A5receive FLOW_REMOVED update internal flow tables S10 send ECHO_REQ S11 receive ECHO_RES R eE S12 S13 send VENDOR receive VENDOR A6 send PORT_MOD update internal flow tables send FLOW_MOD Operational State Diagram R S* à Symmetric flow transitions A* à Asymmetric flow transitions I*Intra-controller flow transitions à To find new vulnerabilities, 1. Infer the current state of the controller 2. Manipulate the control flow sequence or the input values
- 29. / 58 Agent Manager 29 Identifying Current State of Controller OpenFlow Switch App A SDN controller App C R A2 A3 A4 Receive PACKET_IN Deliver to applications Send FLOW_MOD PACKET_IN Channel Agent FLOW_MOD PACKET_IN App Agent DB
- 30. / 5830 S1 S2 S3 S4 receive HELLOsend HELLO send FEATURES_REQ receive FEATURES_RES S5 send GET_CONFIG_REQ S6 receive GET_CONFIG_RES S7 send SET_CONFIG R SDN controller HELLO HELLO FEATURE_REQ FEATURE_RES GET_CONFIG_REQ GET_CONFIG_RES SET_CONFIG OpenFlow Switch Randomizing Symmetric Control Flow Sequence SDN controller HELLO HELLO FEATURE_REQ GET_CONFIG_RES SET_CONFIG OpenFlow Switch Channel Agent
- 31. / 5831 A3 A2 receive PACKET_IN deliver to applications R (1) Randomizing Asymmetric Control Flow Sequence Host A Host BOpenFlow Switch SDN controller Core Services DB App A App B App C Packet-IN Notifier App D PACKET_IN (2) App D App C App B App AApp Agent .
- 32. / 58 • Between an SDN controller and an SDN switch • Between SDN applications 32 e.g.) ADD (0x0000) à (Undefined) (0xFFFF) SDN controller OpenFlow Switch Channel Agent Core Services DB App A App CApp Agent . Randomizing Input Values PACKET_INFLOW_MOD Finding new attacks 9
- 34. / 58 • Supports four different SDN controllers • 4 open source controllers (ONOS, OpenDaylight, Floodlight and Ryu!) • OpenFlow v1.0 and v1.3 supported (HW and SW) 34 ONOS OpenDaylight Floodlight Ryu Version 1.2 1.3 . . . 1.13 Hydrogen Helium . . . Oxygen 0.91 1.0 1.1 1.2 4.26 Release Date 6/5/15 9/18/15 . . . 5/2/18 2/4/14 9/29/14 . . . 3/22/18 12/8/14 12/30/14 4/17/15 2/7/16 7/1/18 Supported ✓ ✓ . . . ✓ ✓ ✓ . . . ✓ ✓ ✓ ✓ ✓ ✓ Supported SDN Components Vendor Switch OpenFlow Version Pica8 P-3290 1.0, 1.3 Arista Networks 7050-T36 1.0 HPE E3800 24G-2SFP+ 1.0 Linux Foundation Collaborative Project OpenVSwitch 1.0, 1.3 Supporting diverse SDN components
- 37. / 58 Test Case Inventory • Test set 1: Data plane security • OpenFlow messages from a controller to a switch • Test set 2: Control plane security • OpenFlow messages from a switch to a controller • Test set 3: Advanced security • Sophisticated security tests exploiting a variety of vulnerabilities • e.g., SDN applications exploiting SDN controllers’ architectural vulnerabilities Covering many attack cases 40+
- 39. / 58 • Test environments • 1 KNOWN attack for Floodlight • 2 NEW attacks for ONOS, OpenDaylight 39 Demonstration
- 40. / 5840 SDN controller Host Agent Normal Host B Core Services DB Firewall App Forwarding App Switch A Switch B Network hub Test Environments
- 41. / 5841 SDN controller Host Agent Normal Host B App Agent . Core Services DB Firewall App Forwarding App Channel Agent Agent Manager Switch A Switch B Network hub Test Environments
- 42. / 58 • An SDN controller maintains an event subscription list • Packet-In events are processed according to a priority 42 Event Subscription in SDN SDN Controller PACKET_IN Topology Manager Firewall App Load balancer App Core Services DB OpenFlow Switch 1. Load balancer 2. Topology Manager 3. Firewall App Packet-IN Subscription List PACKET_IN BA PKT PACKET_IN
- 43. / 58 SDN controller 43 Attack Strategy: Smash the subscription! Topology Manager Firewall App DB SDN Controller Core Services 1. Load balancer 2. Topology Manager 3. Firewall App Packet-IN Subscription List 1 Modify the priority Malicious App 1. Malicious App PACKET_IN 2 manipulate the Packet-In, and deliver it to the next The application refers the wrong value 3
- 44. / 5844 SDN controller Host Agent Host B App Agent . Core Services DB Topology Manager Firewall App Channel Agent Agent Manager Switch A Switch B Network hub 1 2 1. Link Discovery App 2. Topology Manager App 3. Device Manager App 4. Firewall App … 7. DELTA App Agent Packet-IN Notifier 1. DELTA App Agent 2. Topology Manager App 3. Device Manager App 4. Firewall App … 7. Link Discovery App Packet-IN Notifier 3 PKT PACKET_IN4 5 PACKET_IN 6 The AM instructs the app agent to randomize the sequence of the packet-In subscription list1 The app agent modifies the priority2 The AM Instructs the host agent to generate a packet3 The SW1 delivers a Packet-In message to the controller4 The app agent removes the data field of the message, and then hands it over to the next one5 NULL point exception occurred and the switch connections are closed6 DEMO 1: Packet-In Data Forge attack 1. DELTA App Agent in_port: 1 reason: NoMatch DATA: Packet-IN Message Packet-IN Message in_port: 1 reason: NoMatch DATA: PKT (empty)
- 46. / 58 • Feasible to Floodlight 1.1 • Why? • SDN applications granted powerful authority • How to defend? • Policy-based access control to SDN applications • e.g., Security-Mode ONOS [1] 46 DEMO 1: Packet-In Data Forge attack BRING ME APIs!!! [1] https://wiki.onosproject.org/display/ONOS/Security-Mode+ONOS
- 47. / 58 • OpenDaylight (ODL) manages two types of databases 47 Databases in OpenDaylight DB Config Proactive and persistent rules, Non-volatile memory Operational Reactive and temporary rules Volatile memory
- 48. / 58 • ODL refers the configuration DB, when handshaking with a switch 48 Attack Strategy: Exploit the config. DB Core Services Config OpenFlow Switch Malicious App 1 Inject a malformed rule to DB MITM Proxy Attacker HELLO 3 Ask a handshake 4 Access the DB 2 Cut the channel temporarily
- 49. / 5849 DEMO 2: Malformed Flow Rule Generation SDN controller Host Agent Normal Host B App Agent . Core Services Config Firewall App Forwarding App Channel Agent Agent Manager Switch A (OF 1.0) Switch B (OF 1.0) Network hub 2 ID IN Match Action F2 1 HA to B GROUP [NULL] The AM instructs the app agent to make a malformed flow rule1 The app agent makes a malformed flow rule including NULL group action2 The switch A fails INFINITELY5 The switch A tries to connect to the controller4 3 1 2 2 1 1 The AM instructs the channel agent to disconnect the switch A3 5 4 HELLO OF 1.3
- 51. / 58 • Feasible to OpenDaylight oxygen (latest version) • Why? • Improper exception handling in the handshake process • Absence of malformed flow rule management • How to defend? • Detecting the infinite failures and resolving root causes • Filtering an input that has incompatible fields 51 DEMO 2: Malformed Flow Rule Generation
- 52. / 58 • ONOS synchronizes the internal flow tables with switches using flow statistics • Consistency is periodically and strongly investigated 52 Core Services Flow Synchronization in ONOS OpenFlow Switch Are they same with me? STATS_REQ STATS_RES Forwarding App Controller’s Flow Table ID DPID Match Action Switch’s Flow Table A1 A HA to B FWD 1 1 HA to B FWD 1 IN Match Action FLOW_RULE DB FLOW_MOD Make a rule
- 53. / 58 • If consistency is broken, ONOS removes and reinstalls everything • Let’s break the consistency by installing a malformed flow rule 53 Attack Strategy: Exploit the synchronization! 53 Core Services DB Malicious App Controller’s Flow Table 2 Install a wrong flow rule Switch’s Flow Table IN Match Action 1 HA to B FWD 16959 Inject an invalid flow rule1 Reinstall them! 4 OpenFlow Switch ID DPID Match Action A1 A * FWD 999999 Compare it with the original 3 Get a flow statistics
- 54. / 5854 DEMO 3: Infinite Flow Rule Synchronization SDN controller Host Agent Normal Host B App Agent . Core Services DB Firewall App Forwarding App Channel Agent Agent Manager Switch A Switch B Network hub 1 6 2 3 IN Src Dst Action 1 HA B FWD 2 2 B HA FWD 1 IN Src Dst Action 1 HA B FWD 2 2 B HA FWD 1 ID IN Src Dst Action A1 1 HA B FWD 2 A2 2 B HA FWD 1 B1 3 B HA FWD 2 B2 4 HA B FWD 1 A3 - - - FWD 999999 Host Agent communicates with the Host B1 Instruct App Agent to generate a malformed flow rule 2 Make a flow rule including an abnormal outport number 3 Send a flow rule overflowed outport number4 - - - FWD 16959 FLOW_ADD Delete ALL flow rules on the switch and then retry to install 5 Repeat this every 5 seconds6 4 5
- 55. / 5855 DEMO 3: Infinite Flow Rule Synchronization / 5018 DEMO 3: Infinite Flow Rule Synchronization / 5018 DEMO 3: Infinite Flow Rule Synchronization
- 56. / 58 • Feasible to ONOS 1.13 (latest version) • Why? • Careless range check against to field values • Meaningless flow synchronization • How to defend? • Thorough range check in critical fields • Root cause analysis of synchronization failures 56 DEMO 3: Infinite Flow Rule Synchronization
- 57. / 5857 No. Attack Name Control Flow Type Controller 1 Malformed Flow Rule Generation 1 Intra-Controller Flow OpenDaylight 2 Malformed Flow Rule Generation 2 Intra-Controller Flow ONOS 3 Flow Rule Inconsistency 1 Asymmetric Flow ONOS 4 Flow Rule Inconsistency 2 Asymmetric Flow Floodlight 5 Flow Rule Inconsistency 3 Asymmetric Flow ONOS 6 Infinite Flow Rule Synchronization 1 Asymmetric Flow ONOS 7 Infinite Flow Rule Synchronization 2 Asymmetric Flow ONOS 8 Flow Rule ID Spoofing 1 Asymmetric Flow Floodlight 9 Flow Rule ID Spoofing 2 Asymmetric Flow Floodlight Summary of NEW attack cases
- 58. / 58 • Although SDN offers significant benefits as a next-gen networking, a lot of work still needs to be done to improve the security of SDN. • DELTA helps to verify the security of SDN architecture thoroughly. • DELTA fuzzing techniques enable us to discover new vulnerabilities. 58 Final Remarks DELTA is now available as an open source project, so anyone can join us! (https://github.com/OpenNetworkingFoundation/delta)
- 59. / 5859 Q&A Thanks to Changhoon Yoon and Haney Kang for helping us make the slides J
- 60. / 58 • This work was supported by Institute for Information & communications Technology Promotion(IITP) grant funded by the Korea government(MSIT) (No.2018-0-00254, SDN security technology development) • And also, this work was supported by Institute for Information & communications Technology Promotion(IITP) grant funded by the Korea government(MSIP) (No. B0190-16-2012, Global SDN/NFV OpenSource Software Core Module/Function Development) 60 Acknowledgement