Worms and Worm Mitigation

1
Worms and Worm Mitigation

• Saman Amarasinghe
• Associate Professor, MIT EECS/CSAIL
• CTO, Determina Inc.

2
Outline

• Worm Basics
• Program Shepherding
• Intrusion Prevention Systems
• Anatomy of an Attack
• The Determina Story

3
Outline

• Worm Basics
• Program Shepherding
• Intrusion Prevention Systems
• Anatomy of an Attack
• The Determina Story

4
What is a worm?

• Virus - a code segment which replicates by
  attaching copies to existing executables.
• Worm - a program which replicates itself and
  causes execution of the new copy.

• Virus - a code segment which replicates by
  attaching copies to existing executables.
• Self-replication
• Requires a host program as a carrier
• Activated by external action
• Worm - a program which replicates itself and
  causes execution of the new copy.
• Self-replication
• Self-contained does not require a host
• Activated by hijacking or creating a process

5
Types of Worms

• E-mail based worm
• The payload arrives as an e-mail attachment
• Payload gets executed
• Social Engineering or
• Program vulnerability
• Self propagate
• Memory based worm
• The payload arrive as packets on an open port
• Takes advantage of a program vulnerability
• Hijacks the program
• Self propagate

6
History of Worms

• 1982 PARC Worms as an administrative tool
• Perform legitimate tasks on a distributed system
• 1987 Christmas Tree Exec
• attacked IBM mainframes
• E-mail with a program that displayed a x-mas
  tree, but also send it to everyone in the users
  address book
• 1988 The Morris Worm
• First true internet worm
• Attacked both Sun and DEC unix systems
• Used TCP/IP, attacked known OS bugs and admin
  flows
• Automatic penetration, activation and propagation
• Brought down the Internet for the first time
• .
• 2001 Code Red Worm
• 2003 Slammer Worm
• 2003 Blaster Worm
• 2004 Sasser Worm
• 2004 Witty Worm

7
Todays Worm Threat

• One of the biggest threats to the modern
  information infrastructure
• Characteristics of Modern Worm Threat
• Relatively rare (two a year)
• Extreme rapid propagation
• human vs. machine speed
• Infects millions of systems
• May or may not cause real damage
• Catastrophic situations for many enterprises
• Example Blaster and CSX

8
Worldwide Code Red Infections
700,000 machines infected 2-2.9 billion in
damage (Computer Economics) 200 million in
damage per day during attacks
9
Outline

• Worm Basics
• Program Shepherding
• Intrusion Prevention Systems
• Anatomy of an Attack
• The Determina Story

10
Program Shepherding Outline

• Memory based attacks
• Motivating Example A buffer overflow attack
• Dissecting the lifecycle in the penetration phase
  
• Overview of Program Shepherding
• DynamoRIO basics
• Technique 1 Restricted Code Origins
• Technique 2 Restricted Control Transfer
• Technique 3 Uncircumventable Sandboxing
• Self Protection

11
Memory Based Attacks

• Attack that that directly enters an application,
  corrupts the applications memory and hijack the
  application
• Types of memory based attacks
• Buffer Overflow
• Heap Manipulation
• Format String Vulnerabilities
• Shatter Attacks
• Return to Libc Attacks
• Danger of Memory-based attacks
• Once the application is hijacked, the attack can
  do anything that the application can do
• Modern server applications run with a lot of
  privileges

12
An Example Buffer Overflow Attack
Code
Stack
handle_URL(handle h) char url64 char
tmp geturl(h) strcpy(url, tmp)
13
An Example Buffer Overflow Attack
Network
Program Counter Executes the Program Instruction
by Instruction
Application
Data
Instructions
Operating System
14
An Example Buffer Overflow Attack
Code
Stack
handle_URL(handle h) char url64 char
tmp geturl(h) strcpy(url, tmp)
Arguments
Return Address
Local Variables
Argument h
Return Address
Local Variables tmp
Local Variables URL
URL
http//cag.lcs.mit.edu/saman/tmp/doitnow.pl?helpe
rfoobarmyid123453junk2342_at__at_FFNLQ!__at_RFN
L!_at_
15
An Example Buffer Overflow Attack
Code
Stack
handle_URL(handle h) char url64 char
tmp geturl(h) strcpy(url, tmp)
Arguments
Return Address
Local Variables
Argument h
Return Address
Local Variables tmp
Local Variables URL
URL
http//cag.lcs.mit.edu/saman/tmp/doitnow.pl?helpe
rfoobarmyid123453junk2342_at__at_FFNLQ!__at_RFN
L!_at_
16
An Example Buffer Overflow Attack
Network
Application
Data
Instructions
Operating System
17
An Example Buffer Overflow Attack
Code
Stack
handle_URL(handle h) char url64 char
tmp geturl(h) strcpy(url, tmp)
Arguments
0x12FA2
lea ecxeax sub 0x1c(edi) eax movzx 0x8(edi)
ecx shl 0x07 ecx cmp eax ecx
Return Address
Local Variables
Malicious code segment
Argument h
Return Address
0x12FA2
0x12FA2
Local Variables tmp
Local Variables URL
URL
http//0011101101101110110100010101101011010101101
101 1011011011011010101101010101011010101101010101
0110...
18
An Example Buffer Overflow Attack
Network
Application
Data
Instructions
Operating System
19
When to stop an attack?
Stop Applications From Being Hijacked

• Enter
• Monitoring is simple
• Port monitoring or system call monitoring
• Dont know good guy from bad guy
• only known criminals can be identified
• Even known bad guys are hard to detect
• encrypted channels
• Attack
• Monitoring can be done
• System call monitoring
• Hard to distinguish between actions of a normal
  program vs. a compromised program

ABI

• Hijack
• Catch in the act of criminal behavior
• All programs follow strict conventions
• ABI (Application Binary Interface)
• The Calling Convention
• Currently no enforcement
• All attacks violate some of these conventions

• Enforcing conventions
• Systematically catch an entire class of attacks
• No false positives
• Catch them before they do ANY bad activity ? no
  attack code is ever run
• Conventional Wisdom Impossible to do without a
  large performance penalty
• Need to be inside the application
• Need to monitor activity at a very fine-grain
  each instruction at a time
• Overhead will be overwhelming
• Program Shepherding lets you do just that!
• Able to amortize the cost of enforcement,
  eliminating the overhead

Processor Execution Environment
20
How Program Shepherding Work?
Program Counter Executes the Program Instruction
by Instruction
Run-time System
Never Let go of the Program Counter
Code Cache
Program
Restricted Control Transfer Is it legal to go
from here to there?
Restricted Code Origins Is this code came from a
code page?
Restricted Control Transfer Is it legal to go
from here to there?
Restricted Code Origins Is this code came from a
code page?
Restricted Code Origins Is this code came from a
code page?
21
A Basic Interpreter
next VPC
fetch next instruction
decode
execute
update VPC
Validate
exception handling
Instruction Interpreter

• Never give up the Program Counter (PC)
• PC is in the interpreter

22
Performance of the Basic Interpreter
Slowdown factor
23
Trick I Adding a Code Cache
next VPC
lookup VPC
exception handling
fetch block at VPC
emit block
execute block
context switch
BASIC BLOCK CACHE
non-control-flow instructions
24
Adding a Basic Block CachePerformance Effect
Slowdown factor
Slowdown factor
Performance Problem High cost of frequent
context switches
25
Trick II Linking
next VPC
lookup VPC
exception handling
fetch block at VPC
emit block
execute until cache miss
link block
context switch
BASIC BLOCK CACHE
non-control-flow instructions
26
Performance Effect of Basic Block Cache with
direct branch linking
Slowdown factor
Performance Problem High cost of mispredicted
indirect branches
27
Trick III Efficient Indirect Branch Handling
next VPC
basic block builder
context switch
miss
BASIC BLOCK CACHE
miss
indirect branch lookup
non-control-flow instructions
28
Performance Effect of indirect branch linking
Performance Problem inefficient code layout in
code cache
Slowdown factor
29
Trick IV Picking Traces

trace selector
basic block builder
START

dispatch
context switch
BASIC BLOCK CACHE
TRACE CACHE
indirect branch lookup
non-control-flow instructions
non-control-flow instructions
30
Performance Effect of Picking Traces
300
Slowdown factor
31
Monitor all Control Transfers

• Must intercept all windows initiated control
  transfer events
• Exceptions
• Call backs in Windows
• Asynchronous procedure calls
• Setjmp/longjmp
• Set thread context

Code Cache
Kernel
Windows
32
Transparent to the Application

• Application behavior cannot change!
• No assumptions beyond the ISA and the OS
  interface
• Actions of DynamoRIO is transparent to the
  application
• Data Transparency
• I/O Transparency
• Transparent Exception Handling
• Program Address Transparency

33
Technique 1 Restricted Code Origins
Code Cache
Unmodified code pages
A
D
Modified pages
B
E

• As code is copied to the code cache, check where
  its coming from
• Check the security policy only once

34
Technique 1 Restricted Code Origins

• Catches all the injected code attacks
• Most of the popular attacks are of this type
• What is left?
• Malicious reuse of existing code
• Change addresses used by return and indirect jump
  and indirect branch instructions
• Much more difficult

35
An Example Chained Call Attack
Code
Stack
handle_URL(handle h) char url64 char
tmp geturl(h) strcpy(url, tmp)
Arguments
Fake arguments
Return Address
Local Variables
0x8A234
Fake arguments
Argument h
Return Address
0x7F8B0
Local Variables tmp
Local Variables URL
Libraries
setuid()
unlink()
0x7F8B0
0x8A234
URL
http//001110110110111011010001010110101101010110
10110110110110101011010101010110101011010101...
36
Technique 2Restricted Control Transfers
context switch
BASIC BLOCK CACHE
TRACE CACHE
trace branch taken?
indirect branch lookup
non-control-flow instructions
non-control-flow instructions
Restrict based on source address, destination
address, and/or transfer type
37
Technique 2Restricted Control Transfers

• Inter-Segment Indirect Calls and Jumps
• Only to known function entry points
• Only if the function is exported by the
  destination segment
• Only if the function is imported by the source
  segment
• Intra-Segment Jumps
• Only within a known function or to a known
  function entry point
• Intra-Segment Indirect Calls
• Only to known function entry points

38
Technique 2Restricted Control Transfers

• Returns
• Only to after a call instruction
• If a direct call, called function should be the
  same as the function returning from

39
Technique 3 Un-circumventable Sandboxing

• Typical problem with sandboxing
• If attacker gains control, can bypass checks
• DynamoRIO-inserted sandboxing isun-circumventable
  
• DynamoRIO enforces unique entry points

40
Protecting DynamoRIO Itself

• DynamoRIO runs in the applications address space
• Must not allow application to manipulate
  DynamoRIO data or code cache
• How?
• Protect Dynamo data structures and the code cache
• Sandbox system calls that can change protection
  and thread behavior

41
Memory protection
Page type ApplicationPrivileges DynamoRIO Privileges
Application code R R
Application data RW RW
DynamoRIO code R R
DynamoRIO data R RW
Code cache R RW
42
Memory protection
Page type ApplicationPrivileges DynamoRIO Privileges
Application code R R
Application data RW RW
DynamoRIO code R RE
DynamoRIO data R RW
Code cache RE RW
43
Outline

• Worm Basics
• Program Shepherding
• Intrusion Prevention Systems
• Anatomy of an Attack
• The Determina Story

44
Evaluating an Intrusion Prevention Solution

• Accuracy
• Maintainability
• Scalability
• Coverage
• Proactivity
• Uncircumventability
• Containment

45
1. Accuracy

• How much false positives
• Frequency of False positives
• Impact of a false positive
• Why you need and IPS?
• Availability vs. Privacy/Integrity

46
2. Maintainability

• What is a typical enterprise like?
• How many machines, how many IT people?
• Cost of operations
• How do you manage a large enterprise?
• What impact maintainability?
• Shelfware vs. deployed software

47
3. Scalability

• Requirements to run enterprise-wide
• Critical bottlenecks
• Deployment / maintenance
• Performance

48
4. Coverage

• What attacks are stopped?
• What is the attack landscape?
• Is there a map anywhere?
• I have N products, what do they stop and where
  are the holes?
• How to define the attack landscape?
• Look at the past and extrapolate
• Look at the vulnerabilities

49
Most Critical Vulnerabilities
of vulnerabilities
Source CVE, Microsoft Security Bulletins,
2003-2004
50
5. Proactivity

• What information do you need to stop an attack?
• Know the application
• Know the vulnerability
• Know the attack
• Day-zero attacks.
• Traditional Timeline of an Attack

51
Shortening attack timelines
Vulnerability Date Time to Outbreak
WebDAV 3/03 0 days
ISS/BlackIce 3/04 1 day (Witty)
SSL (MS04-011) 4/04 1 week (SSL bomb)
Lsass (MS04-011) 4/04 2 weeks (Sasser)
Internet Explorer 11/04 -1day no patch (Mydoom.ag)
52
Speed of PropagationThe Witty Worm
53
6. Uncirumventability

• Phrack Article Smashing Stack for Fun and
  Profit
• Any fool-proof systems?
• Complex systems are never fool-proof
• Should we just give up?
• Compare system security with crypto
• Is crypto fool-proof?
• How do you evaluate crypto?
• Evaluating system security
• 10/90 rule of thumb
• Nothing is perfect, make it hard...

54
7. Containment

• Where was the attack stopped?
• At the gates vs. inner chamber
• How far did the attack propagate
• Did malicious code got executed?
• Any machine got infected?
• Other machines got compromised?

55
Other Ways to Stop a Memory Based Attack

• Accuracy
• Maintainability
• Scalability
• Coverage
• Proactivity
• Uncircumventability
• Containment

• Network-Based Solutions
• Compliance Enforcement and Isolation
• Correlation Engines
• Event Signature Based Systems
• Scan Detection and Isolation
• Network Firewalls
• Signature Based Deep Packet Inspection
• Vulnerability-Based Deep Packet Inspection

56
Other Ways to Stop a Memory Based Attack

• Accuracy
• Maintainability
• Scalability
• Coverage
• Proactivity
• Uncircumventability
• Containment

• Compile-Time Solutions
• Canaries
• Type-Safe Languages
• Randomization
• Code Obsfucation
• Libsafe

57
Other Ways to Stop a Memory Based Attack

• Accuracy
• Maintainability
• Scalability
• Coverage
• Proactivity
• Uncircumventability
• Containment

• Hardware-Based Solutions
• NX Bit

58
Other Ways to Stop a Memory Based Attack

• Accuracy
• Maintainability
• Scalability
• Coverage
• Proactivity
• Uncircumventability
• Containment

• Host-Based Solutions
• Anti-Virus File scanning
• Personal Firewalls
• File Change Detection
• Patch Management
• Signature-Based System Call Interception
• Policy-Based System Call Interception
• Learning-Based System Call Interception
• Program Shepherding

59
Outline

• Worm Basics
• Program Shepherding
• Intrusion Prevention Systems
• Anatomy of an Attack
• The Determina Story

60
Anatomy of an Attack
61
1. Probing Techniques

• E-mail Based
• Get the address book
• Scan the disk
• Generate random
• Spam generator algorithms
• Network Based
• Random IP
• Weighted Random IP
• Mine the ARP table
• Sniff existing connections

62
2. Penetration Techniques

• Social Engineering
• Ambiguous text
• Generated messages with familiar or privilege
  information
• Compressed attachments
• Compressed and encrypted attachments
• Program Vulnerabilities
• Buffer Overflow
• Heap Manipulation
• Format String Vulnerabilities
• Shatter Attacks
• Return to Libc Attacks
• Privilege Escalation
• Cross-Site Scripting / SQL Injection
• Weak Passwords / Open Network Shares
• Known Backdoors

63
3. Persisting Techniques

• Create new files
• Infect the boot sector
• Modify files (DLLs or executables)
• Install new services
• Modify Registry
• Redirect
• Launch at startup
• Weaken Security Settings
• Install root-kits
• Evade detection
• Clean-up logs
• Patch existing applications / DLLs
• Slow / throttled activity

64
4. Propagation Techniques

• Mail
• Use the e-mail client
• Find an open e-mail relay
• Bring your own SMTP server
• Web connection
• Bring your own http server
• IRC
• FTP
• File Infection
• Via Backdoors

65
5. Paralyzation Techniques

• Impact of killing the host on propagation
• Delete / destroy data
• Example The Witty worm
• Denial of Service
• Sloppy use of excessive resources
• Information leaks
• Spyware
• Not seen in mass worms
• Directed Attacks
• For fun and fame vs. profit
• Worms for Profit
• Zombie farms for DDOS attacks

66
The Determina Story

• From a research project at CSAIL to a Startup
• Timeline
• 1999 DynamoRIO Project Started Optimize
  Programs
• Dec 2001 The Idea of Program Shepherding
• Dec 2002 Provisional Patent Filed
• Jan 2003 The Slammer worm
• Feb 2003 Program Shepherding published at
  USENIX Security
• April 2003 Started talking to VCs
• May 2003 Araksha founded with 3M Series A
  funding
• Jan 2004 Preview version released, 1st
  customers
• April 2004 Series B funding of 16M
• May 2004 Sasser worm stopped at customer
  sites
• June 2004 Company unveiled, name changed to
  Determina
• Nov 2004 Enterprise-ready product released