Detecting co residency with active traffic analysis techniques

766 views

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
766
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
13
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Detecting co residency with active traffic analysis techniques

  1. 1. Detecting Co-Residency with Active Traffic Analysis Techniques CCSW 12 Adam Bates, Benjamin Mood, Joe Pletcher,Hannah Pruse,Masoud Valafar, and Kevin Butler Oregon Systems Infrastructure Research and Information Security (OSIRIS) Lab University of Oregon, Eugene
  2. 2. Outline 1. Introduction 2. Cloud co-recidency 3. Active traffic analysis 4. system design 5. Implementation 6. Evaluation 7. Analysis 8. Discussion 9. Related work 10. Conclusion2
  3. 3. 1. Introduction  New challenges to security  sharing of a common physical platform  co-residency determination alternatives that may be available  focus on the network interface  active traffic analysis  create an outbound covert channel for data exfiltration3
  4. 4. 1. Introduction  Investigates virtualization side channels in physical hardware  Assesses severity of threat through extensive evaluation  Introduces proof-of-concept attacks for the network flow channel4
  5. 5. 2. Cloud co-recidency  Victims  legitimate cloud customers  Adversary  wishes to discover valuable information about his target  launch many instances, perform the co-residency check5
  6. 6. 3. Active traffic analysis  Network flow watermarking  a type of network covert timing channel  recently as a method for detecting stepping stone relays  Blind schemes  All necessary information is contained within the watermark  non-blind scheme  Information is stored for access by the exit gateways  Exploits virtualization’s dependence on traffic mixing  Does not require a corrupt network server6
  7. 7. 4. system design  Inject a targets network traffic with a persistent watermarking  Break hypervisor isolation guarantees  on-off interval-based packet arrival scheme  Due to the coarse-grained abilities of a co-located VM to inject network delay  out-of-band communication  overcome its limited ability to inject delay through network activity7
  8. 8. 4.1 threat model  motivation  investigate the existence of hardware-level side channels  the viability of isolation assurances for virtual machines  assume  naive timing channels are unavailable  route all local traffic through a switch  administrators proactively apply patches  administrators not interfere with the activities of customers  victim trust of the cloud infrestructure  victims instances are available to the adversary over an open network8
  9. 9. 4.2 co-resident watermarking  relies on the pigeonhole principle SERVER, CLIENT, FLOODERs9
  10. 10. 4.2 co-resident watermarking  CLIENT initiates a web session with our target instance  CLIENT iterates through its list of registered FLOODERs  FLOODERs injects network activity into the outbound interface  If no watermark signature is detected  terminate all instances and launch a new set  If a signature is detected  use the co-resident FLOODER for a second phase of attack10
  11. 11. 4.3 Signal Encoding  the watermark embedding process  T : length of unwatermarked network flow  n : intervals  ti : length of intervals  pi : a certain number of packet arrivals  +d, -d : two different levels of packet delay  wi = {+d, -d}  +d : injecting a constant stream of UDP packets  -d : taking no action for the length of the interval11
  12. 12. 4.4 Signal Decoding  sorting intervals into X+d, X-d  Poisson distribution  Kolmogorov-Smirnov(KS) test12
  13. 13. 5. Implementation  SERVER  Apache 2  a script simulate background noise  CLIENT  continuously re-requesting a 10MB file  FLOODER  raw socket injection binary  create outbound multi-threaded UDP streams13
  14. 14. 6. Evaluation  Hardware  Dell workstations *2  Dell PowerEdge R610 server *1  4-core Intel Xeon E5606 processor *2  12 GB RAM  Intel 82599 10Gbps Ethernet controller  Hypervisor  VMWare ESXi 4.1  Xenified Linux 2.6.40 kernel  Virtual machine  Linux 2.6.34 kernel  1 vCPU  1.7 GB memory14
  15. 15. 6.1 Xen hypervisor  3200 total measurements  13 minutes and 20 second15
  16. 16. 6.2 VMWare ESXi hypervisor16
  17. 17. 6.3 system load17
  18. 18. 6.4 Network conditions  Measure the resiliency of encoded watermarks  traveling across longer network paths18
  19. 19. 6.5 Science clouds  ACISS compute cloud service  Futuregrid’s Sierra cloud  re-attempted the trial with multiple co-resident FLOODERs19
  20. 20. 6.5 Science clouds20
  21. 21. 6.6 Neighboring instance false positives  This attack must avoid false positives  Instances are not co-resident but share a common network path  inject layer 2 packets that are routed by MAC address21
  22. 22. 6.6 Neighboring instance false positives22
  23. 23. 6.7 Virtualization-Aware hardware  viability of hardware level defenses against co-resident watermarking  Repeated original Xen trial on an SR-IOV-enabled NIC  configured the driver to present two virtual functions (VFs) on a single outgoing port  connected SERVER and FLOODER to one VF each on our Xen testbed23
  24. 24. 6.7 Virtualization-Aware hardware24
  25. 25. 7. Analysis  co-resident watermarking  bypassing VM isolation  exploiting underlying hardware configurations  scouting mechanism25
  26. 26. 7.1 Covert communication  Transmit a secret such as a small key or message26
  27. 27. 7.2 Load measurement  Discovering more accurate traffic information  Monitoring the throughput of the undisturbed CLIENT-SERVER TCP session27
  28. 28. 8. Discussion  Embedding a message into a network flow  effectively multicast to all visitors to the server  retrieve the message while retaining plausible deniability28
  29. 29. 8.1 Invisibility  FLOODER’s activity would arouse immediate suspicion  Invisibility is extremely difficult to achieve29
  30. 30. 8.2 Defences  Provide each virtual machine instance with a dedicated path out of its physical host  Net relative to the network transmission speed of their physical host  Provision networks to not take advantage of the "free" bandwidth  Virtualization-aware hardware can address and close this side channel  random scheduling mechanism30
  31. 31. 9. Related work  9.1 Cloud side channels  9.2 Hypervisor Security  9.3 In-the-wild exploits31
  32. 32. 9.1 Cloud side channels  network timing side channel  challenge fault tolerance guarantees  be used to detect drive-failure vulnerabilities  Cache-based side channel  exploit the timing difference between the cache and main memory32
  33. 33. 9.2 Hypervisor Security  Preventing cache-based side channels  Checks whether organizations has any conflict with the SLA  monitors how the physical memory used by applications  changing how caches assign memory to applications  Reducing the role and size of the hypervisor  proposing the near elimination of the hypervisor33
  34. 34. 9.3 In-the-wild exploits  A handful of privilege escalation exploits in Xen and VMWare  An early version of Xen 3  allowed users to craft malicious grub.conf  buffer overflow error  VMWare  a bug in the folder-sharing  unprivileged user code to be executed by the vmx process34
  35. 35. 10. conclusion  determining co-residency of instances in cloud environments  Leveraged active traffic analysis techniques  co-resident watermarking scheme  determination of co-residency in 10 seconds  interpose a covert channel  performing passive attacks35
  36. 36. End36

×