IaaS Clouds: Which Security for VMs and Hypervisors? Marc Lacoste Orange Labs

Transcription

1 IaaS Cloud: Which Security for VM and Hypervior? Marc Lacote Orange Lab ICAR (Intergiciel et Contruction d'application Répartie) Summer School. Grenoble, Augut 28 th, 2013.

2 The Two Facet of Cloud Computing Many benefit Cot reduction. Flexibility. Scalability. Pay-per-ue... Many form Private, public, hybrid, community. IaaS, PaaS, SaaS. Data center, mobile, peronal, on chip Virtualized reource for multiple ervice Many threat Virtualization layer VM-to-VM. Rootkit: Bluepill, CloudBurt, Virtunoid 2

3 Outline Part I: IaaS Threat and Security Challenge. Part II: VM Security. Part III: Hypervior Security. Part IV: What doe the Future Hold for IaaS Security? 3

4 Part I: Iaa Threat and Security Challenge 4

5 Threat 5

6 A Typical IaaS Infratructure VM-to-VM threat Fool VM placement trategy to become co-located with VM attack target. Launch ide-channel attack to teal / corrupt information from target VM. Marc Lacote, Orange Lab, ICAR 2013 Example: Hey You! Get Off My Cloud! on Amazon VM [Ritenpart et al., CCS 09]. Cro-VM Side Channel and Their Ue to Extract Private Key [Zhang et al. CCS 12]. 6

7 Threat in a IaaS Infratructure Hypervior ubverion Compromie VMM from maliciou VM. Miconfiguration, device driver. Threaten hypervior integrity, CIA attack againt VM. Marc Lacote, Orange Lab, ICAR 2013 Example: Virtunoid: KVM iolation breakout [Elhage, DEFCON 11]. CloudBurt: VMware guet VM ecape [Kortchinky et al. BLACKHAT 09]. Bluepill: rogue hypervior beneath VM [Rutkowka et al., BLACKHAT 06]. SubVirt: VM-baed rootkit [King et al., Security&Privacy 06]. 7

8 Threat in a IaaS Infratructure Network threat Traffic nooping. Addre poofing. VLAN hopping. Example: Critical vulnerability in Eucalyptu open ource cloud (2011). 8 Marc Lacote, Orange Lab, ICAR 2013

9 Threat in a IaaS Infratructure Availability threat Reource tarvation due to faulty or maliciou VM behavior. Crimeware-a-a-Service. Example: Major outage on Amazon EC2 torage (2011) DDoS attack on AWS bring Bitbucket ervice to a halt (2009). EC2 cloud ued againt Sony PlayStation Network (2011). 9 Marc Lacote, Orange Lab, ICAR 2013

10 BotCloud Threat 10

11 Security Challenge 11

12 Endpoint Security Guarantee ecurity when computing reource are virtualized.. Barrier #1: Hypervior Security Virtualization bring many threat. Hyperjacking, miconfiguration, maliciou device driver, backdoor between VM and hardware VM alo have their vulnerabilitie. Such threat may be mitigated by: Hardened image. Strict VM ecurity life-cycle management. Apply ecurity-by-default configuration. 12 Marc Lacote, Orange Lab, ICAR 2013

13 Network Security Guarantee ecurity when network reource are virtualized.???? Barrier #2: Network iolation I traditional ecurity till effective? Rik are imilar to known network. Many mechanim are till applicable. VPN, VLAN, firewall, IDS/IPS, encryption, ignature Iolation i no longer phyical but logical. Iolation i le precie. Security guarantee are weaker. Challenge: mapping exiting network ecurity component to new cloud architecture. 13 Marc Lacote, Orange Lab, ICAR 2013

14 Network Security Guarantee ecurity when network reource are virtualized. Barrier #3: Elatic Security Flexible ecurity proviioning to match fat evolving rik. Firt olution: Flexible management of VPN. Overlay in full network virtualization. Fully automated ecurity management i till lacking. Reearch: autonomic (elf-protecting) ecurity architecture. Operational: early warning, proactive ecurity ytem. 14 Marc Lacote, Orange Lab, ICAR 2013

15 Data Protection Guarantee data ecurity in a hared multi-tenant environment. Barrier #4: Identity Lack of end-to-end identity management Iue: calability, heterogeneity. Authentication: hould be overcome. Authorization: in it infancy. Security-a-a-Service opportunitie. Barrier #5: Privacy Strong iolation during peronal information life-cycle. Many tough quetion: Secure data torage, data retention and detruction, legal implication Today PET are not enough! 15 Marc Lacote, Orange Lab, ICAR 2013

16 Data Protection Guarantee data ecurity in a hared multi-tenant environment. Barrier #6: Traceability How to locate the data and it path? Legal, political, and trut iue: Compliance. Data hoted abroad expoed to foreign government. Proving data come from a truted ource? Barrier #7: Legal iue Multiple conflicting juriiction for cloud data flow. Provider: how to provide aurance of regulation compliance? Cutomer: what are the right and obligation of each party? Importance of ecurity SLA. 16 Marc Lacote, Orange Lab, ICAR 2013

17 Trut Enabler Prove to third partie that the cloud infratructure i trutworthy. Barrier #8: Tranparency Prove ecurity hygiene of provider infratructure to third partie. Auditability, certification proce, rik analyi methodologie, compliance. Truted cloud computing technologie provide cryptographic evidence. Source: L. McVittie. Cloud Balancing, Cloud Burting, and the InterCloud, Cloud Computing Journal, Barrier #9: Openne Avoid vendor lock-in. Main iue: API portability acro provider. Bai of inter-cloud infratructure. Flexibility and ecurity benefit of open ource cloud architecture. Clear-cut SLA to clarify reponibilitie. Barrier #10: End-to-End Security Orchetrating ecurity mechanim. A cloud reference ecurity architecture i needed for overall view of cloud ecurity. Importance of tandardization. 17 Marc Lacote, Orange Lab, ICAR 2013

18 Part II: Protecting Virtual Machine 18

19 Virtual Security Appliance Security objective: 360 confidentiality, integrity, and availability of VM. Key propertie Iolation: control ditributed information flow between VM. Zoning. Overight: oberve and intervene in VM tate / behavior. Intropection. Zoning Architecture Deign iue Horizontal: which network ecurity architecture? Phyical, virtual, hybrid Vertical: which oftware layer? vswitch, hypervior, VM, multi-layer. 1. Phyical 2. Virtual Marc Lacote, Orange Lab, ICAR Hybrid 19

20 VM Intropection Monitored VM 1. hook Hypervior 2. monitoring agent Limitation of pure network-baed and hot-baed monitoring for cloud infratructure. 20

21 VM Intropection Monitored VM Security VM (Virtual Appliance) 1. hook VM Intropection Idea: ue the capabilitie of the hypervior to upervie VM behavior 1. Monitoring agent Hypervior 2. Monitoring agent 3. Monitoring agent Compute, network, torage intropection Fat path, low path, hybrid path architecture 1. In-VM monitoring: SIM 2, 3. With no hook in VM: CloudSec 2. monitoring agent Some Sytem 2,3. With hook in VM: Lare, XenAcce, KVMSec In-VM Placement Detection accuracy: proximity to target Stealth: protecting the monitoring component Security Appliance Security, performance improvement Le reactive? Hypervior-Baed Tranparent VM acce Security of monitoring component Semantic gap Little remediation action Check out paper «Engineering Intruion Service for IaaS Cloud : The Way of The Hypervior» at IEEE SOSE 2013 for more information!! Marc Lacote, Orange Lab, ICAR

22 Some VMI-Related IDPS & Anti-Malware Sytem Source: Baliga et al. Paladin: Automated Detection and Containment of Rootkit Attack, Computer & Security, Source: Wang et al. Detecting Stealth Software with Strider GhotButer. DSN 05. An extenive number of generic technique for intruion and malware detection: increaingly ue virtualization to mitigate both known and unknown threat. Policie: ome flexibility. Cro-layering: ome attempt uing VMI and emantic-view recontruction. Openne: to enable election and compoition of multiple detection / reaction algorithm. 22

23 vshield EndPoint vshield = VMware IaaS ecurity uite vshield App/Zone Hypervior-level firewall for VM network ecurity. vshield Manager Centralized adminitration. vshield Edge Virtual appliance firewall for perimetric ecurity. vshield Endpoint Anti-malware virtual appliance for intra-vm ecurity. vshield Endpoint Security feature: anti-malware, integrity monitoring, firewall, Deep Packet Inpection (DPI), log inpection. Policy-baed management. Cro-layering: module in hypervior + ecurity appliance. Openne: EPSec API. Marc Lacote, Orange Lab, ICAR 2013 Source: VMware. 23

24 Part III: Protecting the Hypervior 24

25 Virtualization Reviited 25

26 From Sytem Virtualization to the Hypervior Sytem virtualization i the ue of an encapulating oftware layer that urround or underlie an operating ytem, providing the ame input, output, and behavior that would be expected from phyical hardware. M. Pearce et al. Virtualization: Iue, Security Threat, and Solution. ACM Computing Survey, 45(2), Thi tak i performed by the hypervior or Virtual Machine Monitor (VMM): Allocation of phyical reource (e.g., CPU, torage, network) to Virtual Machine (VM). VM iolation. Type I : Bare Metal Type II : Hoted The hypervior provide it own driver Marc Lacote, Orange Lab, ICAR 2013 Driver may be hared with the hot OS 26

27 Propertie of a Virtualized Architecture Theoretical foundation [Popek and Goldberg74]: Analyi of requirement for a phyical architecture to be virtualizable. VMM requirement: 1. Efficiency The major part of intruction mut be run directly on the CPU, without VMM intervention. 2. Reource Control The VMM mut be in complete control over phyical reource, e.g., for multiplexing, iolation, complete mediation. 3. Equivalence Program running on the VMM mut have the ame behavior a if running directly on an equivalent phyical machine. 27

28 Intruction Senitivity Privilege level Senitive: may interfere with a factor under VMM control. Control enitive. Behavior enitive. Innocuou otherwie. Privileged: require proce to be highly privileged to be called. Trap if CPU in uer mode Not if CPU in upervior mode. Non-privileged otherwie. Reult: The architecture i fully virtualizable if : Senitive Intruction Privileged Intruction. «Trap-and-emulate» approach to virtualization. Unfortunately, x86 architecture i not fully virtualizable! Privileged Non-privileged Senitive Marc Lacote, Orange Lab, ICAR 2013 Intruction that do not trap in privileged mode 28

29 Virtualization and x86 Privilege Ring x86 architecture define 4 protection ring. Software-approach to virtualization: VMM run in ring 0, guet OS in ring 1. Some enitive intruction may not work properly due to inufficient privilege. Hardware-aited virtualization: VMM run in hardware-enforced ring -1. The OS can run tranparently in ring 0 a in non-virtualized ytem. 29

30 Some Method for Virtualizing the x86 Architecture Paravirtualiation: The guet OS i modified to better cooperate with the hypervior. Senitive non-privileged intruction are replaced by hypercall. Only a limited number of paravirtualized driver are needed. Not compatible with proprietary kernel. Binary tranlation: The VMM convert problem intruction in moother binary code Compatible with mot guet OSe. Doe not require pecific hardware upport. Require many optimization to be efficient. Hardware-aited virtualization: The hardware facilitate virtualization with pecific intruction (e.g., Intel VT-x). The guet OS run tranparently without modification. Allow to run OS which cannot be paravirtualized. Security i alo enhanced. Hardware context witching might be cotly. Implementation may alo be difficult. 30

31 I/O Management Device driver implementation: Virtualized: plit (back-end/front-end), emulated (HVM), or hypervior direct. Pathrough: from guet OS driver to device without hypervior intervention. 31

32 I/O Management Device driver implementation: Virtualized: plit (back-end/front-end), emulated (HVM), or hypervior direct. Pathrough: from guet OS driver to device without hypervior intervention. Map device addree to phyical addree in main memory. Very ueful to mitigate DMA attack. 32

33 Network Management The VM virtual network interface (VNIC) can be: Bridged to a phyical network interface (PNIC). Part of a Virtual Network (VN): device are connected to (virtual) hub, connected to other hub or to phyical network via virtual router. VN can be iolated, routed, or NAT-routed. 33

34 Hypervior Security Mechanim 34

35 Hypervior Integrity and Authenticity Threat The VMM i implicitly truted. I thi really true? Security objective: trutworthy VMM, with high aurance for authenticity and integrity. Truted computing technologie. Provide attetation of integrity of oftware/hardware component relying on chain of trut. For the Hypervior 2. monitoring agent VM VM VM VM Hypervior 1. Monitoring agent Sytem Integrity checking TCG IMA, Hyperguard, HyperCheck, HyperSentry Control flow integrity HyperSafe 2. Monitoring agent 35

36 Hypervior Integrity and Authenticity Threat For VM 2. monitoring agent Monitored VM e.g., for integrity Hypervior Management VM 1. Monitoring agent Management VM 2. Monitoring agent 1. hook Truted VMM Terra + TPM In management VM vtpm Sytem 2. monitoring agent Hot OS driver?? 36 Marc Lacote, Orange Lab, ICAR 2013

37 Hypervior Integrity and Authenticity Threat Benefit and Limitation Strong ecurity: attetation capabilitie. Vulnerable if oftware-only. Stealth? SMM vulnerabilitie? Flexibility: different ecurity policie Limited to integrity meaurement. No remediation. Eay to perform tatically In-context meaurement i hard: hypervior or proceor context? 37

38 DoS Threat Threat againt availability. Local Threat Network Threat VMM bug : privilege ecalation, VMM crah, diable acce to adminitration channel. Reource tarvation: allocation of too many reource cauing failure of other component. From hot or VM. Mitigation: reource allocation limit. Attack vector: network channel, e.g., network flooding. 2. monitoring agent Target: VMM, hot OS, guet OSe. Mitigation: network ecurity countermeaure (NIDS, firewalling, inkhole). Level 2: ebtable (Xen/KVM) Level 3: Open Vwitch (VMware), CISCO Nexu 1000v (Xen/KVM). 38

39 Information Leakage and Privilege Ecalation Threat Threat againt confidentiality and integrity. VM information leakage Privilege ecalation Exfiltrating information out of VM uing covert channel (hardware and oftware). Such channel may alo erve to corrupt VM. Leaked information: cutomer data, reource uage, location, hot or network information. Two repreentative clae of attack: Cache-baed attack. Timing-baed attack. Very few protection againt uch threat. VM ecape: a VM break the hypervior iolation code to become over-privileged. 2. monitoring agent Ecape to hot: Attack vector: device driver, Direct Memory Acce (DMA), CPU/GPU cache. Mitigation: VMM andboxing, hot ecurity. Ecape to other VM. Mitigation: +Truted Virtual Domain. Ecape to Virtual Network. Mitigation: + network ecurity. 39

40 The «Hey You! Get Off My Cloud» Attack 1 Map the Cloud Identify potential target 2 Determine co-reidence Check if two VM are co-located on ame phyical erver VM? VM 3 Send probe VM Co-locate attacker VM with target VM 4 Ue VM ide-channel Extract information, perform DoS Example: infer number of web ite viitor from traffic load. 40

41 Sandboxing Device Driver Threat VM VM VM VM VM Idea: confine maliciou code by controlling communication between driver, and device, kernel, and VM pace. 1. hook 1. RM Example of Sytem Hypervior Driver 2. RM 1. Reference Monitor (RM) between driver / VM pace: MicroDriver, Proxo 3. RM 2. RM between driver and hypervior: Software Fault Iolation (SFI) technique 2. monitoring agent Device 3. RM between driver and device: Nook Strong ecurity Good performance RM difficult to protect without hardware mechanim No remediation, only containment Reduced code ize Hypervior i modified Some iolation flexibility Policie difficult to configure 41

42 Part IV: What doe the Future Hold for IaaS Security? 42

43 Major Evolution in IaaS Architecture Ahead! Architecture i fundamental for IaaS ecurity But hypervior architecture i changing rapidly! New hypervior architecture are defined to mitigate new threat. Virtualization i expanding outide the data center. Two dimenion in change: Scale. Abtraction. Three main trend 1. Virtualization goe embedded. 2. Security move toward the hardware. 3. The cloud become uer-centric. A Big Picture 43

44 Major Evolution in IaaS Architecture Ahead! 44

45 Diruption #1: Virtualization Goe Embedded 45

46 Embedded Hypervior DC Hypervior Embedded Hypervior Cloud-on-chip hypervior Hypervior for mobile phone, enor, automotive ytem, avionic Application BYOD. Segment profeional / peronal environment Which Architecture? Key propertie Hypervior have trong limitation. Reource abtraction. Iolation. Performance. Minimal TCB. Real-time guarantee. Modularity. Fine-grained control. Micro-kernel eem better uited. Micro-vior are perhap even better. One of the mot advanced deign i OKL4 (Open Kernel Lab). 46

47 Microvior Architecture DC Hypervior Embedded Hypervior Cloud-on-chip hypervior Microvior = convergence of hypervior and micro-kernel: Abtraction OKL4 architecture: TCB minimization Source: J. Matthew. Virtualization and Componentization in Embedded Sytem. Open Kernel LabTechnology White Paper,

48 Toward the Cloud-on-Chip DC Hypervior Embedded Hypervior Cloud-on-chip hypervior Hypervior for multi-core architecture Key propertie Strong reource haring limitation. Maive calability. Key point Multiple hypervior on the ame chip. Independent ecurity realm per hypervior, with dedicated core and memory. Two-level reource management: intra-hypervior for VM. inter-hypervior uing multiplexing HAL. Source: Intel. 48 Marc Lacote, Orange Lab, ICAR 2013 Source: W. Shi. Architectural Support of Multiple Hypervior over Single Platform for Enhancing Cloud Computing Security. ACM International Conference on Computing Frontier (CF), 2012.

49 Diruption #2: Security Move Toward the Hardware 49

50 Micro-Hypervior The problem Hypervior are too big, too complex. Source of vulnerabilitie: bounce attack. DC Hypervior Solution Micro-hypervior Virtualized hypervior TCB hardening: mechanim Protect «by hand» hypervior from ubverion. Truted computing, language technique, andboxing TCB reduction: architecture Reduce code ize and complexity and increae modularity. For the core hypervior: Micro-hypervior. For the management VM: Diaggregated hypervior. Reducing the TCB VM VM Service VM Service VM VM Management VM Core hypervior: virtualization ikernel (for driver), NOVA, NoHype VMM Hypervior VMM VMM Micro-hypervior Management VM Service VM VMM Service VM Expel a much code a poible from TCB Strong ecurity Flexibility with open architecture. Extenive code rewriting Limited operational ervice Hard to apply to legacy hypervior. 50

51 Micro-Hypervior The problem Hypervior are too big, too complex. Source of vulnerabilitie: bounce attack. DC Hypervior Solution Micro-hypervior Virtualized hypervior TCB hardening: mechanim Protect «by hand» hypervior from ubverion. Truted computing, language technique, andboxing TCB reduction: architecture Reduce code ize and complexity and increae modularity. For the core hypervior: Micro-hypervior. For the management VM: Diaggregated hypervior. Reducing the TCB VM VMM Hypervior VM VMM VMM Micro-hypervior Management VM Service VM Service VM Service VM VM Management VM VMM Service VM Management VM: componentization XOAR, MinV, Diaggregated Xen Tranform Dom0 into a et of ervice VM, limiting reource haring, reducing priviilege. Improved ecurity, flexibility, and control. Doe not limit operational ervice. More ready to apply to legacy hypervior. 51

52 Some Example DC Hypervior Micro-hypervior Virtualized hypervior NOVA Architecture Source: U. Steinberg and B. Kauer. NOVA: A Microhypervior Baed Secure Virtualization Architecture. EUROSYS XOAR Architecture Source: P. Colp et al. Breaking Up i Hard to Do: Security and Functionality in a Commodity Hypervior. SOSP

53 For Automated Hardening Some hard problem ecurity component heterogeneity between layer and domain. infratructure complexity impoibility of manual adminitration. Autonomic ecurity approach: cloud with elf-defene capabilitie 53

54 For Automated Hardening Some hard problem ecurity component heterogeneity between layer and domain. infratructure complexity impoibility of manual adminitration. Autonomic ecurity approach: cloud with elf-defene capabilitie Lighter adminitration. Increaed reactivity. Lower operational cot. Graduated repone. Security uperviion enabler. 54

55 VESPA: Multi-Layer IaaS Self-Protection = Virtual Environment Self-Protecting Architecture An autonomic ecurity framework for regulating protection of IaaS reource. Implementation: KVM-baed IaaS infratructure. Application to hypervior elf-protection: in progre. 55

56 Illutration Flexible confinement of VM according to rik level 56

57 Illutration Flexible confinement of VM according to rik level 57

58 Virtualized hypervior DC Hypervior Micro-hypervior Virtualized hypervior The problem IaaS infratructure lack: Vertically: ecurity - Untrutworthy, vulnerable layer. Horizontally: flexibility, interoperability - (Security) feature not deployed. - Too monolithic for cutomization. 58

59 Virtualized hypervior DC Hypervior Micro-hypervior Virtualized hypervior Idea: Virtualize the hypervior Hypervior-Secure Virtualization (HSV): - The hypervior i no longer part of the TCB. - Protection by a ecurity layer underneath. - Separation of reource management from ecurity. Software HSV approach: neted virtualization. Source: IBM, Turtle project, OSDI

60 Virtualized hypervior DC Hypervior Micro-hypervior Virtualized hypervior Benefit Vertically: more ecurity - Trutworthy ecurity layer. Horizontally: more flexibility, interoperability - Ditributed ecurity abtraction layer. - Enabler for cro-provider ecurity ervice. Source: Zhang et al., CloudVior, SOSP

61 The Hypervior in Hardware Virtualized hypervior The hypervior in hardware Hardware HSV Benefit A hardware controller a only ecurity manager. - Dedicated Page Ownerhip Table for checking memory mapping permiion. The VMM perform tranparently VM cheduling and reource allocation. Stronger ecurity and better performance than oftware olution Cot might no longer be a barrier: - Change in micro-architecture are fairly mall. - Provider might pay for extra aurance level. 61 Source: J. Szefer and R. Lee, Architectural Support for Hypervior-Secure Virtualization, ASPLOS,2012.

62 Diruption #3: The Cloud Become Uer-Centric 62

63 Provider-centric cloud deficiencie Marc Lacote, Orange Lab, ICAR 2013 The uer-centric cloud (a.k.a uper-cloud) Lack of unified control: vendor-lock-in, monolithic infratructure Lack of interoperability: for infratructure ervice Cloud reource ditribution plane eparating production from conumption. Diruption #3: The Cloud Become Uer-Centric Benefit: Independence from provider. Increaed cutomizability. New buine opportunitie. 63

64 Provider-centric cloud deficiencie Marc Lacote, Orange Lab, ICAR 2013 The uer-centric cloud (a.k.a uper-cloud) Lack of unified control: vendor-lock-in, monolithic infratructure Lack of interoperability: for infratructure ervice Cloud reource ditribution plane eparating production from conumption. Diruption #3: The Cloud Become Uer-Centric Benefit: Independence from provider. Increaed cutomizability. New buine opportunitie. Toward fully ditributed hypervior. 64

65 Perpective Static Cloud Security Flexible Cloud Security Automated Cloud Security Exploitation of virtualization vulnerabilitie are ome of the mot eriou cloud threat, making the hypervior a keytone component of cloud ecurity. Some key point: The main challenge are riing infratructure complexity and rapid threat evolution. Mechanim are not well integrated. New architecture are promiing but far from mature. Two ultimate goal are cro-layer protection and end-to-end ecurity. A virtualization expand, not one but multiple «good» ecurity architecture. A vibrant reearch domain, critical to monitor to protect future cloud ytem. 65

66 Thank! Contact: Marc Lacote Orange Lab Senior Reearch Scientit rue du Général Leclerc Iy-Le-Moulineaux, France