Usenix 2015 study

1. ADDioS!
C.K.Chen

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

23. SYN Flood Defense

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

34. Pitfalls

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

41. Zip Bombs Everywhere

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