1 Large Scale Malicious Code: A Research Agenda N. Weaver, V. Paxson, S. Staniford, R. Cunningham Presented by Stefan Birrer

2 Motivation and Goal ● Networking infrastructure is essential to many activities – Address the “worm thread” ● Establish taxonomy for worms ● Motivate Cyber “CDC” ● Establish a road map for research efforts

3 Challenges ● Prevention – i.e. Non-executable stacks ● Avoidance – i.e. Filter ports ● Detection – i.e. Network telescopes ● Recovery – i.e. Fix vulnerability

4 Challenges ● Spread speed is faster than human reaction time ● Further generations of worms address previous counter measurements – Smart guys behind the scene ● Monocultures in today Internet ● People are not sensitive to security

5 Taxonomy ● Activation techniques ● Propagation strategies ● Propagation carriers ● Motivation and Attackers ● Payloads

6 Ecology of Worms ● Application Design ● Buffer Overflows ● Privileges – Mail worms ● Application Deployment ● Economic Factors ● Monocultures

7 Cooperative Information Technology Org. ● CERT/CC – Human analysis and aggregation ● IIAP – Human-time analysis ● ISAC – Practices and background ● FIRST ● Public Mailing Lists

8 Commercial Entities ● Anti-virus Companies ● Network based IDS Vendors ● Centralized Security Monitoring ● Training Organizations ● Limited Scope of Commercial Response

9 Cyber CDC ● Identify outbreaks ● Rapidly analyzing pathogens ● Fighting infections ● Anticipating new vectors ● Proactively devising detectors for new vectors ● Resisting future threats

10 Vulnerability Prevention Defenses ● Programming Languages and Compilers – Safe C Dialects (C, active area) ● Enforcing type- and memory-safety ● Ccured / Cyclone ● [future] extending to C++ – Software Fault Isolation (C, active area) ● Memory safe sandboxes ● Lack of availability of SFI-based systems – StackGuard (C, active area) ● Compiler calling-convention ● Works well against conventional stack attacks

11 Vulnerability ● Programming Languages and Compilers – Nonexecutable Stacks and Heaps w/ Randomized Layouts (B, mostly engineering) ● Randomizing layout ● Guard pages, exception when accessed ● No attempt to build such a complete system – Monitoring for Policy- and Semantics-Enforcement (B, opportunities for worm specific monitoring) ● System call patterns (“mimicry” attack) ● Static analysis ● [future] increase performance and precision

12 Vulnerability ● Automatic vulnerability analysis (B, highly difficult, active area) – Discover buffer overflow in C – Sanitized integers – User-supplied pointers for kernel – [future] assemply level – [future] specific patterns of system calls

13 Vulnerability Prevention Defenses ● Privilege Issues – Fine-grained Access Control (C, active area) ● [future] integrating into commodity OS – Code Signing (C, active area) ● Publi-key authentication – Privilege Isolation (C, some active research, difficult) ● Mach kernel

14 Vulnerability ● Protocol Design – Design Principles (A, difficult, low cost, high reward) ● Open problem – Proving Proto Properties (A, difficult, high reward) ● Worm resistant properties -> verify ● [future] interpreter detects violation of protocol – Distributed Minable Topology (A, hard but critical) ● Match subset, not the entire list – Network Layout (C, costly) ● Never co-occur (i.e. strictly client / server)

15 Vulnerability ● Network Provider Practices – Machine Removal (C, already under development) ● No standard protocol ● Implementation Diversity – Monoculture is a dangerous phenomena

16 Vulnerability ● Synthetic Polycultures – Synthetic polycultures (C, difficult, may add unpredictability) ● [future] techniques to develop synthetic polycultures ● [future] Code obfuscation ● Economic and Social – Why is Security Hard (B, active area of research) ● [future] understanding of why practices remain so poor

17 Automatic Detection of Malicous Code ● Host-based detectors – Host-based Worm Detection (A, Critical) ● Contagion worms ● IDS – Existing Anti-virus Behavior Blocking (A, Critical) ● Behavior blocking (usability and false positives) – Wormholes / honeyfarms (A, Low Hanging Fruit) ● Excellent detector / machine cost ● Must target the cultured honepots...

18 Detection ● Network-level detectors – Edge Network Detection (A, critical, powerfull) ● Large number of scans – Backbone Level Detection (B, hard, difficult to deplay) ● Routing is highly asymmetric ● Correlation of Results – Centralized (B, Some commercial work) – Distributed (A, powerful, flexible) – Worm Traceback (A, high risk, high payoff) ● No attention to date in research community ● [future] Network telescopes

19 Automated Response to Malicious Code ● Host-Based (B, overlaps with personal firewall) – Open question ● Edge Network (A, poweful, flexible) – [future] Filter traffic (side effects...) ● Backbone/ISP Level (B, difficult, deployment issues) – [future] Limitation of outbound scanning ● National Boundaries (C, too coarse grained) ● Graceful Degradation and Containment (B, mostly engineering) – [future] Quarantine sections

20 Aids to Manual Analysis of Malicious Code ● Collaborative Code Analysis Tool (A, scaling is important, some ongoing research) ● Higher Level Analysis (B, important, Halting problem imposes limitations ● Hybrid Static-Dynamic Analysis (A, hard but valuable) ● Visualization (B, mostly educational value) – [future] Real-time analysis – [future] what information might be gathered

21 Aids to Recovery ● Anti-worms (C, impractical, illegal) ● Patch distribution in a hostile environment (C, already evolving commercially) ● Updating in a hostile environment (C, hard engineering, already evolving) – Metamorphic code to insert a small bootstrap program

22 Policy considerations ● Privacy and Data Analysis ● Obscurity ● Internet Sanitation – Scan limiters ● The “Closed” Alternative – Apply restrictions

23 Challenging Problems ● Common evaluation framework ● Milestones for detection – False positive ● Milestones for analysis – Capture – Understand ● Detecting targeted worms ● Tools for validating defenses – Internet Wide Worm Testbed (A, essential) – Testing in the Wild (A, essential)

24 Conclusions ● Worms are a significant thread ● Limited number of strategies ● Inadequate defensive infrastructure ● Cyber CDC – Prevention role ● Huge potential damage

25 Problems ● Build tomorrows security system based on todays worm technologies – Will always be one step behind – Reactive ● Need to address root cause instead of patching things – Prevention

26 ?