CSA Ev

1. Bryan Nairn, CISSP
Senior Manager, Trustworthy Computing
Microsoft Corporation
bryan.nairn@microsoft.com

2. Why should I care?
 Server virtualization is now a given in the majority of
enterprise datacenters – source IDC
 The virtual server and virtual server management
software market is forecast to reach a market opportunity
of approximately $4.1 billion by 2014. This represents a
CAGR of 13.1%. – source IDC
 Over 40% of production virtual machines will be less
secure than their physical counterparts through 2014 –
source Gartner

3. Virtualization powers the cloud
Private Cloud Public Cloud
• Mimics public cloud • Available to anyone
• Benefits enterprise with a network
users connection
• Highly virtualized • Pay-as-you-go
• Strings together IT • Multi-tenant and
infrastructure into virtualized
resources pools • Self-service portals

4. Virtualization is a good thing!

5. Some Common VM Security Myths
 “I only have to patch my host OS / Kernel”
 “If I protect my Host machine, it will protect my
VMs.”
 “Virtual Hard Disk files are secure by default.”
 “If you expose the virtual machine, you have to
expose all virtual machines and the host.”
 “All virtual machines can see each other.”
 “I don’t need Anti-Virus with Virtualization”

6. Protection Rings

7. Virtualization Architecture- Hypervisor
Primary Partition Child Partitions
Virtualization Stack
WMI Provider
Applications
VM VM Worker
Service Processes
Ring 3
MinWin Virtualization Virtualization
Service Service
Providers Clients
Windows (VSPs) (VSCs) Guest OS
Kernel IHV Kernel
Drivers VMBus VMBus Enlightenments
Ring 0
Windows hypervisor Ring “-1”
Server Hardware

8. Hypervisor Security Assumptions
 Guests are untrusted
 Trust relationships
 Parent must be trusted by hypervisor
 Parent must be trusted by children
 Hypercall interface will be well documented and widely
available to attackers
 All hypercalls can be attempted by guests
 Can detect you are running on a hypervisor + version
 The internal design of the hypervisor will be well understood

9. Hypervisor Security Goals
 Strong isolation between partitions
 Protect confidentiality and integrity of guest data
 Separation
 Unique hypervisor resource pools per guest
 Separate worker processes per guest
 Guest-to-parent communications over unique channels
 Non-interference
 Guests cannot affect the contents of other guests, parent, hypervisor
 Guest computations protected from other guests
 Guest-to-guest communications not allowed through VM interfaces

10. Hyper-V Isolation
 No sharing of virtualized devices
 Separate VMBus per VM to the parent
 No sharing of memory
 Each has its own address space
 VMs cannot communicate with each other, except through
traditional networking
 Guests can’t perform DMA attacks because they’re never
mapped to physical devices
 Guests cannot write to the hypervisor
 Parent partition cannot write to the hypervisor

11. Hyper-V Security Hardening
 Hypervisor has separate address space
 Guest addresses != Hypervisor addresses
 No 3rd party code in the Hypervisor
 Limited number of channels from guests to
hypervisor
 No “IOCTL”-like things
 Guest to guest communication through hypervisor is
prohibited
 No shared memory mapped between guests
 Guests never touch real hardware I/O

12. Hyper-V Security Model
 Uses Authorization Manager
(AzMan)
 Fine grained authorization and access
control
 Department and role based
 Segregate who can manage groups of
VMs
 Define specific functions for
individuals or roles
 Start, stop, create, add
hardware, change drive image
 VM administrators don’t have to be
Server 2008 administrators
 Guest resources are controlled by
per VM configuration files
 Shared resources are protected
 Read-only (CD ISO file)
 Copy on write (differencing disks)

13. Virtualization Attack Vectors
Host Hardware
Virtual Machine Host OS
Virtual Machine Hard Disk Files
Virtual Machine Configuration Files
Remote Management/Control interfaces
Guest Operating System
Virtual Networks

14. Common Attacks: Host
 Host Compromise for
 Deployment, Duplication and Deletion
 Control of Virtual Machines
 Direct Code / File injection to Virtualization File
Structure
 Virtual Hard Disks
 Virtual Configuration Files
 Time Sync
 Hardware
 Rootkits / Malware
 Drivers (Attack Surface / Stability)

15. It’s all about the what’s underneath…

16. Use Remote Management
 All Virtualization Solutions include some form of remote
control.
 Access to these tools should be limited.
 Limit scope of access / control
 Protect the remote control mechanisms!
 Use limited use accounts for control
 Make sure the connections are encrypted / authenticated (SSL, RDP
over SSL)
 Use logging
VM
VM VM
VM
VM VMVM VM
VM VM VMVM VM
VM VM
VM VM
V VMVM VM
VM VM VM
M

17. File Types and Locations
.vhd disk file
– In folder you specify
in settings
.vhdd disk file
– In folder you specify
in settings
.vud disk file
– In vmc-file folder
.vsv disk file
– In vmc-file folder

18. Common Attacks: Guest
 Unpatched Virtual Machines
 Older Operating Systems
 Test or Development machines (these often are not
managed in the same way as production machines)
 Un-managed or user deployed virtual machines
 Backups and archives

19. Guest Attacks
 The Virtualization File Structure
 Virtual Hard Disks
 File / Code Injection
 Can be Directly Mounted / accessed
 Virtual Configuration Files
 Base Configuration changes
 Redirection / addition of Virtual drives / Resoures
 BIOS
<hardware>
<memory>
<ram_size type="integer">256</ram_size>
</memory>
...
<pci_bus>
<ethernet_adapter>
<controller_count type="integer">2</controller_count>
</ethernet_adapter>
</pci_bus>
</hardware>

20. VHD Redirection

21. Threat Landscape: Virtualized Attackers?
 Is this is one of the next big attack vectors on the horizon?
 The VM industry is focused on securing the VMs from attack.
Very little thought of VMs being used as the attacker.
 Cases are starting to appear where people use VMs to
attack, then shutdown the VM to remove any trace of
evidence.

22. Threat Landscape: Virtualized Attackers?
 But we do write all events to the SysLog
 Things that go into drive slack are recoverable using
forensics tools
 We still have network traces…
 …and audit logs
 …and firewall and router logs
 …not to mention video cameras in the server room.

23. Defending Yourself

24. Host Attacks: Potential Solutions
 Harden the Host Servers
 Where a Hypervisor or Specialist Kernel is used, the Host attack surface is
smaller, however updating and patching is still required.
 Use single role servers and remove unwanted and un-necessary services /
attack vectors
 Use a local firewall and only allow limited host control / management ports
over encrypted and authenticated channels.
 Use limited scope admin accounts with strong passwords
 Protect the Virtual Machine files
 Access Control Lists (limited to the security context for the users who manage
them and the services that control them.
 Encryption
 Disk / Volume / Folder / File
 Auditing
 file access, creation, deletion …
 Don’t forget the backup files / archives

25. Guest Attacks: Potential Solutions
 Harden the Guest Operating Systems
 Treat the guest OS as if it was a physical machine
 Isolate the machine with Virtual Networks / VLANs
 Local Only Access
 NAT
 Segmented networks
 IPSec Isolation
 Physical Isolation (Separate NICs)

26. Use Access Control Lists
Deny Read-only Read/Write
• Cannot modify VMC file • See the VM in web • See the VM in web
• Will not appear in web console and VRMC console and VMRC
console or VMRC • Can interact with VM • Can interact with the VM
• Cannot start, stop, pause • Can
or resume VMs start, stop, pause, resume
VMs

27. Deployment Considerations
 Minimize risk to the Parent Partition
 Use Server Core
 Don’t run arbitrary apps, no web surfing
 Run your apps and services in guests
 Moving VMs from Virtual Server to Hyper-V
 FIRST: Uninstall the VM Additions
 Two physical network adapters at minimum
 One for management (use a VLAN too)
 One (or more) for vm networking
 Dedicated iSCSI
 Connect to back-end management network
 Only expose guests to internet traffic

28. Anti-Virus & BitLocker…
 Parent partition
 Run AV software and exclude .vhd
 Child partitions
 Run AV software within each VM
 BitLocker
 Great for branch office
 Can be used within a VM
 http://blogs.technet.com/virtualworld/archive/2008/02/16/using-
bitlocker-under-virtual-pc-virtual-server.aspx

29. Conclusions
 Reduce the attack surface on the Host
 Use least privilege access
 Audit the deployment, maintenance, control and access to
virtual machines
 Leverage backups, snapshots and redundancy to reduce
impact of Host / Guest maintenance
 Secure your Virtual Machine Hard Disk and configuration
files, including backups and archives
 Use Virtual Networks / VLANs / IPSec to Isolate
machines, especially before they are exposed to the network.

30. Resources
 Step-by-Step Guide to Getting Started with Hyper-V
 http://technet2.microsoft.com/windowsserver2008/en/library/c513e254-
adf1-400e-8fcb-c1aec8a029311033.mspx?mfr=true
 Virtualization Team Blog
 http://blogs.technet.com/virtualization
 Microsoft Virtualization Website
 http://www.microsoft.com/virtualization
 Using BitLocker under Virtual PC / Virtual Server
 http://blogs.technet.com/virtualworld/archive/2008/02/16/using-bitlocker-
under-virtual-pc-virtual-server.aspx

31. We would all rather be doing
something else..