1 / 27

CloudSec: A Security Monitoring Appliance For Virtual Machines In The IaaS Cloud Model

The 5 th International conference On Network and Systems Security (NSS 2011). CloudSec: A Security Monitoring Appliance For Virtual Machines In The IaaS Cloud Model. Amani S. Ibrahim James Hamlyn-Harris, John Grundy and Mohamed Almorsy. Center for Computing and Engineering Software Systems

dysis
Télécharger la présentation

CloudSec: A Security Monitoring Appliance For Virtual Machines In The IaaS Cloud Model

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The 5th International conference On Network and Systems Security (NSS 2011) CloudSec:A Security Monitoring ApplianceFor Virtual Machines In TheIaaS Cloud Model Amani S. Ibrahim James Hamlyn-Harris, John Grundy and Mohamed Almorsy Center for Computing and Engineering Software Systems Swinburne University of Technology 7 September 2011

  2. Agenda IaaS Cloud Computing Model IaaS Security Problem Key Problems CloudSec Future Work

  3. IaaS Cloud Computing Model • IaaS allows customers to increase their computational and storage resources on the fly • IaaS is characterized by the concept of resource virtualization Server Aggregation 1/20

  4. Agenda IaaS Cloud Computing Model IaaS Cloud Computing Model IaaS Security Problem IaaS Security Problem Key Problems CloudSec Conclusions

  5. IaaS Security Problem • VMs are hosted by the Cloud Provider and controlled by the Cloud Consumer. CC3 CC1 CC2 VM VM VM VM Cloud Platform CP 2/20

  6. IaaS Security Problem (cont.) • Cloud Providers who are hosting Virtual Machines (VMs) are not aware of the actual contents of VMs. • VMs can be easily compromised • Compromised VMs can impact other CCs and CP VMs cannot be trusted from Cloud Provider’s perspective to host security software New Virtualization-aware security solutions need to be provided that can protect VMs from outside the VM itself 3/20

  7. Virtualization For Security • As we need security for virtualization, virtualization can be utilized to enhance security • External Monitoring (Virtual Machine Introspection) • Isolation • Control Security Software VM VM VMI Layer Virtualization Software (Hypervisor) Hardware 4/20

  8. Agenda IaaS Cloud Computing Model IaaS Security Problem Key Problems Key Problems CloudSec Conclusions

  9. Key Problems to Overcome • The “Semantic Gap” • How can we interpret hardware bytes to provide useful information about a running OS (Running DS instances) • Fully externally to the VM. • Without relying on the OS kernel. Security Software VM VM f875a020 001b0003 00000001 f875a028 f875a02c f875a028 f875a030 f875a030 f875a038 0b0c1640 000c2fe0 00000000 External View (Hardware Bytes) VMI Layer Virtualization Software (Hypervisor) Hardware PROCESS f875a020 SessionId: 2 Peb: 7ffdb000 ParentCid: 0460 DirBase: 0b0c1640 ObjectTable: 00000000 HandleCount: 0. Image: csrss.exe Internal View (High-Level OS Information) 5/20

  10. Key Problems to Overcome (Cont.) • Real-Time • Security software needs to trap and verify most system activities • This has a (potentially large) Performance Overhead. • Active Monitoring • Active monitoring requires installing hooks inside the hosted VMs to suspend system activities until they are analysed (In-Guest Code) • A major reason for moving to VASSs is to remove any security code form VMs. 6/20

  11. Agenda IaaS Cloud Computing Model IaaS Security Problem Key Problems CloudSec CloudSec Conclusion

  12. Agenda IaaS Cloud Computing Model IaaS Security Problem Key Problems CloudSec Threat Model System Architecture Monitoring Scenario Implementation Evaluation

  13. CloudSec • Utilizes VMI techniques to monitor VMs at a hypervisor level • Inspects physical memory to construct an external high-level semantic view of the running OS kernel data structure instances • Uses this view to write and enforce integrity constraints on the running data structures instances to protect against data hooks and DKOM attacks. Semantic Gap • Map between the hardware memory layout and the OS kernel structure • Recursive traversing for OS global variables 7/20

  14. Threat Model 8/20

  15. System Architecture • VMI Layer • Back-end • Inspect VM’s hardware • Enables us to gain control over the hosted VMs to suspend access to VM’s hardware • Front-end • A set of APIs that allow communication with the back-end • Allows installing triggers (access or timer) on the physical memory pages need to be monitored SGB Defense Modules Profiles VMIBack-end VM-Thread Pool Manager Memory Access Handler KSDs KSDs KSDs KSDs MPB KSDs Hypervisor Kernel VMI APIs Front-end Hypervisor CloudSec Hosted VMs Host Physical Memory 9/20

  16. Monitoring Scenario • VM Power on: • The back-end notifies CloudSec • CloudSec creates a separate thread • Checks processor control registers (CR0 + CR4) • egCR0.PG is set + CR4.PAE is clear = 32-bit paging, PAE disabled • Loads the appropriate kernel structure definition • Microsoft Symbols • Building Semantic Gap Knowledge • Locate global variables and Read the corresponding memory pages • Recursively traverse and map bytes to the KSD • Profiling and Security • Create profile for VM's reconstructed view • Install timer-based or memory-access triggers • Start Security Modules 10/20

  17. Deployment Model • ESX 4.1 Server • CloudSec • vCompute + Posix Threads + CloudSec Code • Isolated in a dedicated vSwitch • Windows XP VMs • Connected to another vSwitch CloudSec VM2 VM1 vSwitch 1 vSwitch 2 ESX 41 Hypervisor vCompute APIs Backend 11/20

  18. Implementation Data Structures EPROCESS KeServiceDescriptorTable 12/20

  19. Implementation Data Structures EPROCESS KeServiceDescriptorTable EPROCESS1 EPROCESS2 EPROCESSLast ActiveProcessLink ActiveProcessLink ActiveProcessLink FLINK FLINK FLINK BLINK BLINK BLINK PsActiveProcessHead 13/20

  20. Implementation Data Structures EPROCESS KeServiceDescriptorTable List_Entry LDR_DATA_TABLE_ENTRY FLINK ActiveProcessLinks BLINK PCB (0x000) DirectoryTableBase (DTB) (0x018) EPROCESS ActiveProcessLinks (0x088) ImageName (0x174) …… OriginalFirstThunk OriginalFirstThunk …… OriginalFirstThunk OriginalFirstThunk …… ForwarderString OriginalFirstThunk _PEB_LDR_DATA (0x00c) InLoadOrderModuleList ( 0x00c) _LDR_DATA_TABLE_ENTRY (0x000) InMemoryLoadedModules InMemoryLoadedModules InMemoryLoadedModules Name Name Name Name Name Name Name Name Function PEB (0x1b0) DllBase DllBase DllBase PsActiveProcessHead FirstThunk FirstThunk FirstThunk FirstThunk FirstThunk Ordinal ImageBaseAddress (oxoo8) IMAGE_DOS_HEADER (0X000) e_lfanew member (0x3C) IMAGE_NT_HEADERS (0X000) DllName DllName DllName …… …… …… …… …… …… …… …… …… IMAGE_DIRECTORY_ENTRY_IMPORT (0X008) DataDirectory (0X060) OptionalHeader (0X018) IMAGE_IMPORT_DESCRIPTOR _IMAGE_THUNK_DATA _IMAGE_IMPORT_BY_NAME 14/20

  21. Implementation Data Structures EPROCESS KeServiceDescriptorTable • Data structure hiding eg Process Hiding • Keep our process list updated as allocation or de-allocation happens in the heap memory • NtCreateProcess + NtTerminateProcess + EAX Register • Check the Process ID, PDT and ThreadListHead EPROCESS1 EPROCESS2 EPROCESS3 ActiveProcessLink ActiveProcessLink ActiveProcessLink FLINK FLINK FLINK BLINK BLINK BLINK 15/20

  22. Implementation Data Structures EPROCESS KeServiceDescriptorTable • typedef struct ServiceDescriptorTable { • SDE ServiceDescriptor[4]; • } SDT; • typedef struct ServiceDescriptorEntry { • PDWORD ServiceTable; • PDWORD CounterTableBase; • DWORD ServiceLimit; • PBYTE ArgumentTable; • } SDE; 16/20

  23. Implementation Data Structures EPROCESS KeServiceDescriptorTable Set KiServiceDescriptorTable address Read SSDT table address (Offset 0x00) Read SSDT table entries number (Offset 0x0C) Entry_offset = 0 Entry_index = 0 Read SSDT table Memory pages Read Entry [i] address Entry_offset = Entry_offset + 4 Entry_Index = Entry_Index + 1 Yes Entry Index = No of entries No 17/20

  24. Evaluation • CloudSec was able to get all running kernel data structure instances externally • Comparison between external and internal views 18/20

  25. Performance • CloudSec builds all the necessary information to bridge the semantic gap and install monitoring triggers once a VM is booted-up 19/20

  26. Future Work • Developing and enforcing integrity constraints on the extracted data structures with their instances to detect and prevent DKOM and data hooks attacks. • e.g. Object Hiding (process and DLL), Hooking (IAT, SSDT and GDT Hooking) and Code injection (DLL injection) • This method has two main drawbacks • You need to get a complete list of structure offsets for each kernel build. • Cannot cover all data structures in the kernel (thousands) because this mainly depends on security expert analysis. Detect all kernel data structures automatically, beyond the kernel version (Pointer Analysis) 20/20

  27. Questions Amani S. Ibrahim aibrahim@swineduau

More Related