1 / 48

Enabling Worm and Malware Investigation Using Virtualization (Demo and poster this afternoon) Dongyan Xu , Xuxian Jiang

Enabling Worm and Malware Investigation Using Virtualization (Demo and poster this afternoon) Dongyan Xu , Xuxian Jiang CERIAS and Department of Computer Science Purdue University. The Team. Lab FRIENDS Xuxian Jiang (Ph.D. student) Paul Ruth (Ph.D. student) Dongyan Xu (faculty)

heloise
Télécharger la présentation

Enabling Worm and Malware Investigation Using Virtualization (Demo and poster this afternoon) Dongyan Xu , Xuxian Jiang

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. Enabling Worm and Malware Investigation Using Virtualization (Demo and poster this afternoon) Dongyan Xu, Xuxian Jiang CERIAS and Department of Computer Science Purdue University

  2. The Team • Lab FRIENDS • Xuxian Jiang (Ph.D. student) • Paul Ruth (Ph.D. student) • Dongyan Xu (faculty) • CERIAS • Eugene H. Spafford • External Collaboration • Microsoft Research

  3. Our Goal In-depth understanding of increasingly sophisticated worm/malware behavior

  4. Outline • Motivation • An integrated approach • Front-end : Collapsar (Part I) • Back-end : vGround (Part II) • Bringing them together • On-going work Virtualization

  5. The Big Picture Domain B Domain A GRE Proxy ARP Worm Capture Worm Analysis Worm Analysis

  6. Part I Front-End: Collapsar Enabling Worm/Malware Capture * X. Jiang, D. Xu, “Collapsar: a VM-Based Architecture for Network Attack Detention Center”, 13th USENIX Security Symposium (Security’04), 2004.

  7. General Approach • Promise of honeypots • Providing insights into intruders’ motivations, tactics, and tools • Highly concentrated datasets w/ low noise • Low false-positive and false negative rate • Discovering unknown vulnerabilities/exploitations • Example: CERT advisory CA-2002-01 (solaris CDE subprocess control daemon – dtspcd)

  8. Current Honeypot Operation • Individual honeypots • Limited local view of attacks • Federation of distributed honeypots • Deploying honeypots in different networks • Exchanging logs and alerts • Problems • Difficulties in distributed management • Lack of honeypot expertise • Inconsistency in security and management policies • Example: log format, sharing policy, exchange frequency

  9. Our Approach: Collapsar • Based on the HoneyFarm idea of Lance Spitzner • Achieving two (seemingly) conflicting goals • Distributed honeypot presence • Centralized honeypot operation • Key ideas • Leveraging unused IP addresses in each network • Diverting corresponding traffic to a “detention” center (transparently) • Creating VM-based honeypots in the center Virtualization

  10. Collapsar Architecture Production Network Attacker Redirector Production Network Redirector Redirector Front-End Production Network VM-based Honeypot Collapsar Center Management Station Correlation Engine

  11. Comparison with Current Approaches • Overlay-based approach (e.g., NetBait, Domino overlay) • Honeypots deployed in different sites • Logs aggregated from distributed honeypots • Data mining performed on aggregated log information • Key difference: where the attacks take place (on-site vs. off-site)

  12. Comparison with Current Approaches • Sinkhole networking approach (e.g., iSink ) • “Dark” space to monitor Internet abnormality and commotion (e.g. msblaster worms) • Limited interaction for better scalability • Key difference: contiguous large address blocks (vs. scattered addresses)

  13. Comparison with Current Approaches • Low-interaction approach (e.g., honeyd, iSink ) • Highly scalable deployment • Low security risks • Key difference: emulated services (vs. real things) • Less effective to reveal unknown vulnerabilities • Less effective to capture 0-day worms

  14. Collapsar Design • Functional components • Redirector • Collapsar Front-End • Virtual honeypots • Assurance modules • Logging module • Tarpitting module • Correlation module

  15. Collapsar Deployment • Deployed in a local environment for a two-month period in 2003 • Traffic redirected from five networks • Three wired LANs • One wireless LAN • One DSL network • ~ 50 honeypots analyzed so far • Internet worms (MSBlaster, Enbiei, Nachi ) • Interactive intrusions (Apache, Samba) • OS: Windows, Linux, Solaris, FreeBSD

  16. Incident: Apache Honeypot/VMware • Vulnerabilities • Vul 1: Apache (CERT® CA-2002-17) • Vul 2: Ptrace (CERT® VU-6288429) • Time-line • Deployed: 23:44:03pm, 11/24/03 • Compromised: 09:33:55am, 11/25/03 • Attack monitoring • Detailed log • http://www.cs.purdue.edu/homes/jiangx/collapsar

  17. Incident: Windows XP Honeypot/VMware • Vulnerability • RPC DCOM Vul. (Microsoft Security Bulletin MS03-026) • Time-line • Deployed: 22:10:00pm, 11/26/03 • MSBlaster: 00:36:47am, 11/27/03 • Enbiei: 01:48:57am, 11/27/03 • Nachi: 07:03:55am, 11/27/03

  18. Summary (Front-End) • A novel front-end for worm/malware capture • Distributed presence and centralized operation of honeypots • Good potential in attack correlation and log mining • Unique features • Aggregation ofScatteredunused (dark) IP addresses • Off-site(relative to participating networks) attack occurrences and monitoring • Realservices for unknown vulnerability revelation

  19. Part II Back-End: vGround Enabling Worm/Malware Analysis *X. Jiang, D. Xu, H. J. Wang, E. H. Spafford, “Virtual Playgrounds for Worm Behavior Investigation”, 8th International Symposium on Recent Advances in Intrusion Detection (RAID’05), 2005.

  20. Basic Approach • A dedicated testbed • Internet-inna-box (IBM), Blended Threat Lab (Symantec) • DETER • Goal: understanding worm behavior • Static analysis/ execution trace • Reverse Engineering (IDA Pro, GDB, …) • Worm experiment within a limited scale • Result: • Only enabling relatively static analysis within a small scale

  21. The Reality – Worm Threats • Speed, Virulence, & Sophistication of Worms • Flash/Warhol Worms • Polymorphic/Metamorphic Appearances • Zombie Networks (DDoS Attacks, Spam) • What we also need • A high-fidelity,large-scale,livebut safeworm playground

  22. A Worm Playground Picture by Peter Szor, Symantec Corp.

  23. Requirements • Cost & Scalability • How about a topology with 2000+ nodes? • Confinement • In-house private use? • Management & user convenience • Diverse environment requirement • Recovery from damages from a worm experiment • re-installation, re-configuration, and reboot …

  24. Our Approach • vGround • A virtualization-based approach • Virtual Entities: • Leveraging current virtual machine techniques • Designing new virtual networking techniques • User Configurability • Customizing every node (end-hosts/routers) • Enabling flexible experimental topologies Virtualization

  25. A worm playground Virtual Physical A shared infrastructure (e.g. PlanetLab) An Example Run: Internet Worms

  26. Key Virtualization Techniques • Full-System Virtualization • Network Virtualization

  27. Full-System Virtualization • Emerging and New VM Techniques • VMware, Xen, Denali, UML • Supporting for real-world services • DNS, Sendmail, Apache w/ “native” vulnerabilities • Adopted technique: UML • Deployability • Convenience/Resource Efficiency

  28. User-Mode Linux (http://user-mode-linux.sf.net) • System-Call Virtualization • User-Level Implementation UM User Process 1 UM User Process 2 ptrace Guest OS Kernel MMU Device Drivers Host OS Kernel Device Drivers Hardware

  29. Virtual Node 1 New Network Virtualization • Link Layer Virtualization • User-Level Implementation Virtual Node 2 IP-IP Virtual Switch 1 Host OS

  30. User Configurability • Node Customization • System Template • End Node (BIND, Apach, Sendmail, …) • Router (RIP, OSPF, BGP, …) • Firewall (iptables) • Sniffer/IDS (bro, snort) • Topology Customization • Language • Network, Node • Toolkits

  31. Networked Node Network System Template AS2_H1 AS2_H2 AS3_H1 AS1_H2 AS3_H2 AS1_H1 R1 R2 R3 node AS3_H1 { superclass slapper network eth0 { switch AS3_lan1 address 128.12.1.5/24 gateway 128.12.1.250 } } node AS3_H2 { superclass slapper network eth0 { switch AS3_lan1 address 128.12.1.6/24 gateway 128.12.1.250 } } router R3 { superclass router network eth0 { switch AS3_lan1 address 128.12.1.250/24 } network eth1 { switch AS2_AS3 address 128.9.1.1/24 } } Project Planetlab-Worm template slapper { image slapper.ext2 cow enabled startup { /etc/rc.d/init.d/httpd start } } template router { image router.ext2 routing ospf startup { /etc/rc.d/init.d/ospfd start } } router R1 { superclass router network eth0 { switch AS1_lan1 address 128.10.1.250/24 } network eth1 { switch AS1_AS2 address 128.8.1.1/24 } } switch AS1_lan1 { unix_sock sock/as1_lan1 host planetlab6.millennium. berkeley.edu } switch AS1_AS2 { udp_sock 1500 host planetlab6.millennium. berkeley.edu } node AS1_H1 { superclass slapper network eth0 { switch AS1_lan1 address 128.10.1.1/24 gateway 128.10.1.250 } } node AS1_H2 { superclass slapper network eth0 { switch AS1_lan1 address 128.10.1.2/24 gateway 128.10.1.250 } } switch AS2_lan1 { unix_sock sock/as2_lan1 host planetlab1.cs.purdue.edu } switch AS2_AS3 { udp_sock 1500 host planetlab1.cs.purdue.edu } node AS2_H1 { superclass slapper network eth0 { switch AS2_lan1 address 128.11.1.5/24 gateway 128.11.1.250 } } node AS2_H2 { superclass slapper network eth0 { switch AS2_lan1 address 128.11.1.6/24 gateway 128.11.1.250 } } switch AS3_lan1 { unix_sock sock/as3_lan1 host planetlab8.lcs.mit.edu } router R2 { superclass router network eth0 { switch AS2_lan1 address 128.11.1.250/24 } network eth1 { switch AS1_AS2 address 128.8.1.2/24 } network eth2 { switch AS2_AS3 address 128.9.1.2/24 } }

  32. Features • Scalability • 3000virtual hosts in 10physical nodes • Iterative Experiment Convenience • Virtual node generation time: 60 seconds • Boot-strap time: 90 seconds • Tear-down time: 10 seconds • Strict Confinement • High Fidelity

  33. Evaluation • Current Focus • Worm behavior reproduction • Experiments • Probing, exploitation, payloads, and propagation • Further Potentials – on-going work • Routing worms / Stealthy worms • Infrastructure security (BGP)

  34. Experiment Setup • Two Real-World Worms • Lion, Slapper, and their variants • A vGround Topology • 10 virtual networks • 1500 virtual Nodes • 10 physical machines in an ITaP cluster

  35. Evaluation • Target Host Distribution • Detailed Exploitation Steps • Malicious Payloads • Propagation Pattern

  36. Probing: Target Network Selection Lion Worms 13 243 Slapper Worms 80,81 http://www.iana.org/assignments/ipv4-address-space.

  37. Exploitation (Lion) 1: Probing 2: Exploitation! 3: Propagation!

  38. Exploitation (Slapper) 1: Probing 2: Exploitation! 3: Propagation!

  39. Malicious Payload (Lion)

  40. Propagation Pattern and Strategy • Address-Sweeping • Randomly choose a Class B address (a.b.0.0) • Sequentially scan hosts a.b.0.0 – a.b.255.255 • Island-Hopping • Local subnet preference

  41. Propagation Pattern and Strategy • Address-Sweeping (Slapper Worm) 192.168.a.b Infected Hosts: 2% Infected Hosts: 5% Infected Hosts: 10%

  42. Propagation Pattern and Strategy • Island-Hopping Infected Hosts: 2% Infected Hosts: 5% Infected Hosts: 10%

  43. Summary (Back-End) • vGround – the back-end • A Virtualization-Based Worm Playground • Properties: • High Fidelity • Strict Confinement • Good Scalability • 3000 Virtual Hosts in 10 Physical Nodes • High Resource Efficiency • Flexible and Efficient Worm Experiment Control

  44. Domain B Domain A GRE Worm Capture Worm Analysis Worm Analysis Combining Collapsar and vGround

  45. Conclusions • An integrated virtualization-based platform for worm and malware investigation • Front-end : Collapsar • Back-end : vGround • Great potential for automatic • Characterization of unknown service vulnerabilities • Generation of 0-day worm signatures • Tracking of worm contaminations

  46. On-going Work • More real-world evaluation • Stealthy worms • Polymorphic worms • Additional capabilities • Collapsar center federation • On-demand honeypot customization • Worm/malware contamination tracking • Automated signature generation

  47. Thank you. Stop by our poster and demo this afternoon! For more information: Email:dxu@cs.purdue.edu URL:http://www.cs.purdue.edu/~dxu Google: “Purdue Collapsar Friends”

More Related