Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

Addios!

•
•
Chong-Kuan Chen
Chong-Kuan Chen

This document summarizes three papers related to data compression and network security. The first paper studies how improper implementation of data decompression in network services can enable denial-of-service attacks. It identifies 12 categories of flaws and evaluates popular services finding 10 vulnerabilities. The second paper proposes the Bohatei system to improve defense against DDoS attacks using SDN/NFV. It presents a hierarchical decomposition approach and proactive tag-based steering. The third paper examines data compression as a source of security issues, studying past attacks like zip bombs and analyzing pitfalls in design, implementation, specification and configuration of compression in network services.

1 of 45
ADDioS! C.K.Chen
Papers • In the Compression Hornet’s Nest: A Security Study of Data Compression in Network Services • Bohatei: Flexible and Elastic DDoS Defense • Boxed Out: Blocking Cellular Interconnect Bypass Fraud at the Network Edge
Bohatei: Flexible and Elastic DDoS Defense Seyed K. Fayaz, Yoshiaki Tobioka, and Vyas Sekar, Carnegie Mellon University; Michael Bailey, University of Illinois at Urbana-Champaign
Outline • Background • DDOS • SDN/NFV • Problem • Contribution • Proposed Scheme • Threat Model • Bohatei
DDOS • DDOS is an emerge threat of network service • A large number of devices control by adversary • Large volume of flow make the victim service uavailable • DDOS attack is getting worse • Increasing in number/volume • New methods of attacks • Evaluation
Traditional DDoS Defense • Buy very expansive security devices against DDOS • Outsource DDOS defense to remote cloud service • Problem ? • Fixed volumes to handle • Fixed type to handle • Fixed location to handle
SDN: Software-Defined Network • Data plan & control plan separation • Centralize management • Open and shared APIs
Data plan & Control plan • Data Plan • Forwards traffic to the next hop along the path to the selected destination network according to control plane logic • Control Plane • Makes decisions about where traffic is sent • Control Data Plan
One Picture for SDN mechanism •
NFV: Network Function Virtualization
Problem • Can SDN/NFV improve the defense of DDOS?
Contribution • Propose the architecture to deploy SDN/NFV against DDOS • Propose several method to enhance the abilities of SDN/NFV to defense DDOS • Hierarchical Decomposition • Proactive tag‐based steering • Open Source • https://github.com/ddos-defense/bohatei
Threat Model • DDoS against the victim who is customer of the ISP • Adversary’s aim is to exhaust the network bandwidth of the victim • Adversary can choose different type of attack • Large number of bots is available for adversary • Adversary can choose from the set of ISP ingress locations ,which the attack traffic can enter the ISP
Dynamic adversaries • Attacker may change the volume and type of attack • How to avoid • wasting compute resources by overprovisioning for attack • not instantiating the required defenses
Bohatei System Overview • Bohatei is an ISP-scale system for ddos defense • Base on SDN/NFV technique
Strategy Layer • Predict the attack pattern • The time window exist between Attack occurring and Bohatei react to attack • Therefore, we need to estimate the volume of future attack • If we over-estimate, attacker can waste resource of ISP • If we under-estimate, attacker can successful deliver attack traffic • Online Adaption • PredicIon = F (Obs. History + Random )
Responsive resource management • Assigning the ISP’s available compute and network resources to DDoS defense • Decide the type and number of machines to deploy • Attack traffic is handled properly while minimizing the latency experienced by legitimate traffic
Resource Manager • Decide how many VMs, what types, where to deploy • Global Optimization • Input: Resources, Suspicious traffic predictions, Defense library • Output: Types, numbers, and locations of VMs? Routing decisions? • Use Global Optimization is too slow • Hierarchical Decomposition
Hierarchical Decomposition • Global controller is only responsible for datacenter level routing • DSP: Datacenter Selection Problem 1. Sort the suspicious traffic by it’s volumes 2. Assign each traffic to the datacenter with minimize cost • Local controller assigns the VMs to defense DDOS within the DC • SSP: Server Selection Problem • Instance the nodes locality closed to attack to handle the attack
Scalable network orchestration • Set up switch forwarding rules in a per-flow and reactive manner • Per-flow: one forwarding entry for one flow • Reactive: once the forwarding entry not exists, the switch queries the controller to update • per-flow and reactive manner is not suitable for DDOS defense • an adversary can easily saturate the control plane bandwidth • installing per-flow rules on the switches will quickly exhaust the limited rule space
Network Orchestration • Configure network to route traffic • Follow the decomposition in Resource Manager, Network Orchestration is also divided into global and local component • Wide-area orchestration • MPLS is more suitable than SDN to configure wide-area network routing • Intra-datacenter orchestration • Classic SDN mechanism, which is a reactive, per‐flow routing, is not scalable • Proactive tag‐based steering
Proactive tag‐based steering • It take times to query remote controller if the flow has no match in local policy cache • DDOS attack may consists large number of flow, which make the policy number increasing exponential • Assign tag to each flow and decide what to do based on tag
SYN Flood Defense
Evaluation • Demonstrate the Bohatei can respond to attacks rapidly • Bohatei restores performance of benign traffic ≈ 1
Evaluation • Is the size of forwarding table increasing exponential?
Conclusion • Demonstrate how SDN/NFV can help defensing DDOS • Propose Bohatei to improve the power against DDOS • Online Learning • Hierarchical Decomposition • Proactive tag‐based steering • Evaluate Bohatei to defense DDOS • Open source • https://github.com/ddos-defense/bohatei
In the Compression Hornet’s Nest: A Security Study of Data Compression in Network Services Giancarlo Pellegrino, Saarland University; Davide Balzarotti, Eurecom; Stefan Winter and Neeraj Suri, Technische Universität Darmstadt
Outline • Data Compression • Problem - DOS Due to Data Compression • Contribution • Problem of Data Compression in Network Service • Implementation • Specification • Configuration • Conclusion
Data Compression • Data Compression is the common technique in network service such as HTTP, XMPP (eXtensible Messaging and Presence Protocol), IMAP (Internet Message Access Protocol)… • Save the bandwidth to transfer large data • Deflate Algorithm • Defined in RFC 1951 • Implemented in libraries, e.g., zlib, or as a tool, e.g., gzip, and Zip archive tool • Available in most of the programming languages
DDOS v.s. Data Compression • Advantage • Save large amount of bandwidth • Disadvantage • Unbalanced Client-Server Scenario • Computation Intensive Task • Space in Disk/Memory • Can be precomputed
1996: Zip Bombs Attack • http://www.unforgettable.dk/42.zi p • 5 layers of nested zip files in blocks of 16, last layer with text files of 4.3 GB each • So, if you extract all files, you will most likely run out of space • 4.503.599.626.321.920 (4,5PB)
2003: Billion Laughs • Resource exhaustion in libxml2 when processing nested XML entity definitions • 810 bytes of XML document expanded to 3GB <?xml version="1.0"?> <!DOCTYPE lolz [ <!ENTITY lol "lol"> <!ELEMENT lolz (#PCDATA)> <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;"> <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;"> <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;"> <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;"> <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;"> <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;"> <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;"> <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;"> <!ENT ITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;"> ]> <lolz> &lol9; </lolz>
Contribution • Study and Categorize the DOS method due to improper decompression design and implementation • 12 types of design/implement flaw lead to DOS • Based on their study, the popular network service is evaluated for it’s decompression design/implement • Discovered 10 previously unknown vulnerabilities
Pitfalls
Decompression before Authentication • Less access control can be enforced before authentication • Adversary can send compression bomb to exhaust server’s resource • Prosody accepted compressed messages before user authentication • Implementation may diverge from the specs
Improper Input Validation during Decompression • If the size of data is larger than threshold, stop handle the data • How to set the threshold? • How to evaluate the size after decompression ? 1. Compressed message size • Mistake way • mod-deflate: If ( compr.size > LimitRequestBody) → Reject 2. Decompression ratio 3. Decompressed message size during the decompression process • Best way, decompression each small chunk and check the size • mod-deflate + mod-dav: If (decompr.size > LimitXMLRequestBody) → Reject CVE-2014-0118
Improper Inter-Units Communication • Many network service implement data processing procedure in the pipeline manner • Upon exception, the pipeline should halts and rejects message in all processing unit • mod-php and mod-gsoap limit the size of incoming (decompressed) message, but had no means to halt mod-deflate • mod_deflate continue to decompress data CVE-2014-0118
Logging Decompressed Messages • Frequency and verbosity of log events can cause DoS • Upon invalid requests, Apache CXF logs first 100KB of incoming message • However, first it decompresses the entire message on a file, then logs the first 100KB • DoS due to memory/disk space exhaustion CVE-2014-0109/-0110
Specification Level • Misleading or No(most cases) Documentation • IDS04-J. Safely extract files from ZipInputStream • it suggests developers verify the decompressed size reported in the file headers before accepting a Zip archive. • this information can be easily forged by an attacker to contain any arbitrary value
Configuration Level • Insufficient Configuration Options • Insecure Default Values • Decentralized Configuration Parameters
Zip Bombs Everywhere
Conclusion • ~20 years after the zip bombs, developers still unaware of the risks of handling data compression • Discovered 10 previously-unknown vulns. in popular network services • Presented 12 pitfalls which can be used by developers to build more secure services
Boxed Out: Blocking Cellular Interconnect Bypass Fraud at the Network Edge Bradley Reaves, Adam Bates, Patrick Traynor, University of Florida; Ethan Shernan, Henry Carter, Georgia Institute of Technology;
Simbox Fraud • Simbox Fraud • Adversaries, ex. ISP, use VoIP to transfer the phone call • VoIP based on internet may have lower QOS • Use Simbox to convert back to phone call and deliver to user • Use VoIP-GSM gateways informally known as “simboxes”
Detecting Unconcealed Losses • We can compute the short-term energy of audio and look for sudden drops and rises again

More Related Content

Addios!

  • 2. Papers • In the Compression Hornet’s Nest: A Security Study of Data Compression in Network Services • Bohatei: Flexible and Elastic DDoS Defense • Boxed Out: Blocking Cellular Interconnect Bypass Fraud at the Network Edge
  • 3. Bohatei: Flexible and Elastic DDoS Defense Seyed K. Fayaz, Yoshiaki Tobioka, and Vyas Sekar, Carnegie Mellon University; Michael Bailey, University of Illinois at Urbana-Champaign
  • 4. Outline • Background • DDOS • SDN/NFV • Problem • Contribution • Proposed Scheme • Threat Model • Bohatei
  • 5. DDOS • DDOS is an emerge threat of network service • A large number of devices control by adversary • Large volume of flow make the victim service uavailable • DDOS attack is getting worse • Increasing in number/volume • New methods of attacks • Evaluation
  • 6. Traditional DDoS Defense • Buy very expansive security devices against DDOS • Outsource DDOS defense to remote cloud service • Problem ? • Fixed volumes to handle • Fixed type to handle • Fixed location to handle
  • 7. SDN: Software-Defined Network • Data plan & control plan separation • Centralize management • Open and shared APIs
  • 8. Data plan & Control plan • Data Plan • Forwards traffic to the next hop along the path to the selected destination network according to control plane logic • Control Plane • Makes decisions about where traffic is sent • Control Data Plan
  • 9. One Picture for SDN mechanism •
  • 10. NFV: Network Function Virtualization
  • 11. Problem • Can SDN/NFV improve the defense of DDOS?
  • 12. Contribution • Propose the architecture to deploy SDN/NFV against DDOS • Propose several method to enhance the abilities of SDN/NFV to defense DDOS • Hierarchical Decomposition • Proactive tag‐based steering • Open Source • https://github.com/ddos-defense/bohatei
  • 13. Threat Model • DDoS against the victim who is customer of the ISP • Adversary’s aim is to exhaust the network bandwidth of the victim • Adversary can choose different type of attack • Large number of bots is available for adversary • Adversary can choose from the set of ISP ingress locations ,which the attack traffic can enter the ISP
  • 14. Dynamic adversaries • Attacker may change the volume and type of attack • How to avoid • wasting compute resources by overprovisioning for attack • not instantiating the required defenses
  • 15. Bohatei System Overview • Bohatei is an ISP-scale system for ddos defense • Base on SDN/NFV technique
  • 16. Strategy Layer • Predict the attack pattern • The time window exist between Attack occurring and Bohatei react to attack • Therefore, we need to estimate the volume of future attack • If we over-estimate, attacker can waste resource of ISP • If we under-estimate, attacker can successful deliver attack traffic • Online Adaption • PredicIon = F (Obs. History + Random )
  • 17. Responsive resource management • Assigning the ISP’s available compute and network resources to DDoS defense • Decide the type and number of machines to deploy • Attack traffic is handled properly while minimizing the latency experienced by legitimate traffic
  • 18. Resource Manager • Decide how many VMs, what types, where to deploy • Global Optimization • Input: Resources, Suspicious traffic predictions, Defense library • Output: Types, numbers, and locations of VMs? Routing decisions? • Use Global Optimization is too slow • Hierarchical Decomposition
  • 19. Hierarchical Decomposition • Global controller is only responsible for datacenter level routing • DSP: Datacenter Selection Problem 1. Sort the suspicious traffic by it’s volumes 2. Assign each traffic to the datacenter with minimize cost • Local controller assigns the VMs to defense DDOS within the DC • SSP: Server Selection Problem • Instance the nodes locality closed to attack to handle the attack
  • 20. Scalable network orchestration • Set up switch forwarding rules in a per-flow and reactive manner • Per-flow: one forwarding entry for one flow • Reactive: once the forwarding entry not exists, the switch queries the controller to update • per-flow and reactive manner is not suitable for DDOS defense • an adversary can easily saturate the control plane bandwidth • installing per-flow rules on the switches will quickly exhaust the limited rule space
  • 21. Network Orchestration • Configure network to route traffic • Follow the decomposition in Resource Manager, Network Orchestration is also divided into global and local component • Wide-area orchestration • MPLS is more suitable than SDN to configure wide-area network routing • Intra-datacenter orchestration • Classic SDN mechanism, which is a reactive, per‐flow routing, is not scalable • Proactive tag‐based steering
  • 22. Proactive tag‐based steering • It take times to query remote controller if the flow has no match in local policy cache • DDOS attack may consists large number of flow, which make the policy number increasing exponential • Assign tag to each flow and decide what to do based on tag
  • 24. Evaluation • Demonstrate the Bohatei can respond to attacks rapidly • Bohatei restores performance of benign traffic ≈ 1
  • 25. Evaluation • Is the size of forwarding table increasing exponential?
  • 26. Conclusion • Demonstrate how SDN/NFV can help defensing DDOS • Propose Bohatei to improve the power against DDOS • Online Learning • Hierarchical Decomposition • Proactive tag‐based steering • Evaluate Bohatei to defense DDOS • Open source • https://github.com/ddos-defense/bohatei
  • 27. In the Compression Hornet’s Nest: A Security Study of Data Compression in Network Services Giancarlo Pellegrino, Saarland University; Davide Balzarotti, Eurecom; Stefan Winter and Neeraj Suri, Technische Universität Darmstadt
  • 28. Outline • Data Compression • Problem - DOS Due to Data Compression • Contribution • Problem of Data Compression in Network Service • Implementation • Specification • Configuration • Conclusion
  • 29. Data Compression • Data Compression is the common technique in network service such as HTTP, XMPP (eXtensible Messaging and Presence Protocol), IMAP (Internet Message Access Protocol)… • Save the bandwidth to transfer large data • Deflate Algorithm • Defined in RFC 1951 • Implemented in libraries, e.g., zlib, or as a tool, e.g., gzip, and Zip archive tool • Available in most of the programming languages
  • 30. DDOS v.s. Data Compression • Advantage • Save large amount of bandwidth • Disadvantage • Unbalanced Client-Server Scenario • Computation Intensive Task • Space in Disk/Memory • Can be precomputed
  • 31. 1996: Zip Bombs Attack • http://www.unforgettable.dk/42.zi p • 5 layers of nested zip files in blocks of 16, last layer with text files of 4.3 GB each • So, if you extract all files, you will most likely run out of space • 4.503.599.626.321.920 (4,5PB)
  • 32. 2003: Billion Laughs • Resource exhaustion in libxml2 when processing nested XML entity definitions • 810 bytes of XML document expanded to 3GB <?xml version="1.0"?> <!DOCTYPE lolz [ <!ENTITY lol "lol"> <!ELEMENT lolz (#PCDATA)> <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;"> <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;"> <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;"> <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;"> <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;"> <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;"> <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;"> <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;"> <!ENT ITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;"> ]> <lolz> &lol9; </lolz>
  • 33. Contribution • Study and Categorize the DOS method due to improper decompression design and implementation • 12 types of design/implement flaw lead to DOS • Based on their study, the popular network service is evaluated for it’s decompression design/implement • Discovered 10 previously unknown vulnerabilities
  • 35. Decompression before Authentication • Less access control can be enforced before authentication • Adversary can send compression bomb to exhaust server’s resource • Prosody accepted compressed messages before user authentication • Implementation may diverge from the specs
  • 36. Improper Input Validation during Decompression • If the size of data is larger than threshold, stop handle the data • How to set the threshold? • How to evaluate the size after decompression ? 1. Compressed message size • Mistake way • mod-deflate: If ( compr.size > LimitRequestBody) → Reject 2. Decompression ratio 3. Decompressed message size during the decompression process • Best way, decompression each small chunk and check the size • mod-deflate + mod-dav: If (decompr.size > LimitXMLRequestBody) → Reject CVE-2014-0118
  • 37. Improper Inter-Units Communication • Many network service implement data processing procedure in the pipeline manner • Upon exception, the pipeline should halts and rejects message in all processing unit • mod-php and mod-gsoap limit the size of incoming (decompressed) message, but had no means to halt mod-deflate • mod_deflate continue to decompress data CVE-2014-0118
  • 38. Logging Decompressed Messages • Frequency and verbosity of log events can cause DoS • Upon invalid requests, Apache CXF logs first 100KB of incoming message • However, first it decompresses the entire message on a file, then logs the first 100KB • DoS due to memory/disk space exhaustion CVE-2014-0109/-0110
  • 39. Specification Level • Misleading or No(most cases) Documentation • IDS04-J. Safely extract files from ZipInputStream • it suggests developers verify the decompressed size reported in the file headers before accepting a Zip archive. • this information can be easily forged by an attacker to contain any arbitrary value
  • 40. Configuration Level • Insufficient Configuration Options • Insecure Default Values • Decentralized Configuration Parameters
  • 42. Conclusion • ~20 years after the zip bombs, developers still unaware of the risks of handling data compression • Discovered 10 previously-unknown vulns. in popular network services • Presented 12 pitfalls which can be used by developers to build more secure services
  • 43. Boxed Out: Blocking Cellular Interconnect Bypass Fraud at the Network Edge Bradley Reaves, Adam Bates, Patrick Traynor, University of Florida; Ethan Shernan, Henry Carter, Georgia Institute of Technology;
  • 44. Simbox Fraud • Simbox Fraud • Adversaries, ex. ISP, use VoIP to transfer the phone call • VoIP based on internet may have lower QOS • Use Simbox to convert back to phone call and deliver to user • Use VoIP-GSM gateways informally known as “simboxes”
  • 45. Detecting Unconcealed Losses • We can compute the short-term energy of audio and look for sudden drops and rises again