Worms and Worm Mitigation

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

Outline

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

Outline

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

What is a worm?

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

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 The payload arrive as packets on an open port Takes advantage of a program vulnerability Hijacks the program Self propagate

Memory based worm

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 2003 2003 2004 2004

Code Red Worm Slammer Worm Blaster Worm Sasser Worm Witty Worm

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

Worldwide Code Red Infections

700,000 machines infected $2-2.9 billion in damage (Computer Economics) $200 million in damage per day during attacks

Outline

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

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

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 Once the application is hijacked, the attack can do anything that the application can do

Danger of Memory-based attacks

Modern server applications run with a lot of privileges

An Example: Buffer Overflow Attack

Code Stack
Arguments: Return Address handle_URL(handle * h) Data { char url[64]; char * tmp =geturl(h) Instructions strcpy(url, tmp); }

Network

Application Local Variables:

Argument: h Return Address Local Variables: tmp

Local Variables: URL

Operating System

An Example: Buffer Overflow Attack

Network
Program Counter: Executes the Data Program Instruction by Instruction

Application

Instructions
Operating System

An Example: Buffer Overflow Attack

Code
handle_URL(handle * h) { char url[64]; char * tmp =geturl(h) strcpy(url, tmp); }

Stack
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?helper=foobar myid=123453;junk=23#42@$@FFNLQ!_@##*RFNL!~@#+

An Example: Buffer Overflow Attack

Code
handle_URL(handle * h) { char url[64]; char * tmp =geturl(h) strcpy(url, tmp); }

Stack
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?helper=foobar myid=123453;junk=23#42@$@FFNLQ!_@##*RFNL!~@#+

An Example: Buffer Overflow Attack

Network
Enter

Application
Data

Instructions
Operating System

An Example: Buffer Overflow Attack

Code
handle_URL(handle * h) { char url[64]; char * tmp =geturl(h) strcpy(url, tmp); }
0x12FA2

Stack
lea %ecx%eax sub 0x1c(%edi) %eax movzx 0x8(%edi) %ecx shl $0x07 %ecx cmp %eax %ecx

Arguments:

Return Address

Local Variables: Malicious code segment Argument: h Return Address 0x12FA2 Local Variables: tmp

Local Variables: URL

URL:

http://0011101101101110110100010101101011010101101101 10110110110110101011010101010110101011010101010110...

An Example: Buffer Overflow Attack

Network
Enter

Application
Data Hijack

Instructions
Attack Operating System

Stop Applications From Being Hijacked When to stop an attack?

Enter

Monitoring is simple

Port monitoring or system call monitoring only known criminals can be identified

Dont know good guy from bad guy

Even known bad guys are hard to detect

ABI
Processor Execution Environment

encrypted channels

Hijack Enforcing conventions

Catch in the act of criminal behavior Systematically catch an entire class of attacks All programs follow strict conventions

No false positives ABI (Application Binary Interface) Catch them before they do ANY bad activity no attack code is ever run The Calling Convention

Currently no enforcement Conventional Wisdom: Impossible to do without a large performance penalty

All attacks violate some of these conventions Need to be inside the application

Attack

Need to monitor activity at a very fine-grain each instruction at a time Overhead will can be overwhelming Monitoring be done Able to amortize the cost of enforcement, eliminating the overhead Leads to false positives
Hard to distinguish between actions of a normal program vs. a compromised program

System call monitoring Program Shepherding lets you do just that!

How Program Shepherding Work?

call

Run-time System
jmp

Program Counter: Executes the Program Instruction by Instruction

br

Never Let go of the Program Counter

Code Cache

ret

Program Restricted Code Origins:

Is this code came from a code page?

Restricted Control Transfer:

Is it legal to go from here to there?

A Basic Interpreter
next VPC

fetch next instruction

decode

execute

update VPC exception handling

Validate
Instruction Interpreter

Never give up the Program Counter (PC)

PC is in the interpreter

Performance of the Basic Interpreter

vpr (Spec2000)
300

Slowdown factor

250 200 150 100 50 0

Simple Interpreter basic block cache

26.03 2.97
basic block cache with direct linking

1.20

1.08

basic block cache basic block+trace with linking caches with linking (direct+indirect)

Trick I: Adding a Code Cache

next VPC
lookup VPC exception handling emit block execute block

fetch block at VPC

context switch

BASIC BLOCK CACHE

non-control-flow instructions

Adding a Basic Block Cache Performance Effect

vpr (Spec2000)
300

Slowdown factor

250 200 150 100 50 0

Simple Interpreter basic block cache

26.03

Performance Problem: basic block cache basic block cache basic block+trace High cost of frequent with direct linking with linking caches with linking (direct+indirect) context switches

2.97

1.20

1.08

Trick II: Linking

next VPC
lookup VPC
exception handling link block emit block execute until cache miss

fetch block at VPC

context switch

BASIC BLOCK CACHE

non-control-flow instructions

Performance Effect of Basic Block Cache with direct branch linking

vpr (Spec2000)
300

Slowdown factor

250 200 150 100 50 0

Simple Interpreter basic block cache

26.03 2.97
basic block cache with direct linking

Performance Problem: basic High block cache cost basic of block+trace with linking caches with linking mispredicted indirect (direct+indirect) branches

1.20

1.08

Trick III: Efficient Indirect Branch Handling

next VPC

basic block builder

context switch miss

BASIC BLOCK CACHE

non-control-flow instructions

miss

indirect branch lookup

Performance Effect of indirect branch linking

vpr (Spec2000)
300

Slowdown factor

250 200 150 100 50 0

Simple Interpreter basic block cache

26.03 2.97
basic block cache with direct linking

1.20

Performance Problem: inefficient code layout in code cache

1.08

basic block cache basic block+trace with linking caches with linking (direct+indirect)

Trick IV: Picking Traces

START
basic block builder trace selector

dispatch

context switch BASIC BLOCK CACHE

non-control-flow instructions

TRACE CACHE indirect branch lookup

non-control-flow instructions

Performance Effect of Picking Traces

Slowdown factor
300 250 200 150 100 50 0
Simple Interpreter basic block cache

vpr (Spec2000) 300

26.03 2.97
basic block cache with direct linking

1.20

1.08

basic block cache basic block+trace with linking caches with linking (direct+indirect)

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 Application
ntdll.dll / *32.dll Code Cache

Kernel
Windows

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

Technique 1: Restricted Code Origins

Unmodified code pages

Code Cache
A D E

Modified pages

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

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

An Example: Chained Call Attack

Code
handle_URL(handle * h) { char url[64]; char * tmp =geturl(h) strcpy(url, tmp); }

Stack
Arguments: Fake arguments Return Address Local Variables: Fake arguments Argument: h Return Address 0x7F8B0 Local Variables: tmp

0x8A234

Libraries
0x7F8B0setuid() 0x8A234 unlink()

Local Variables: URL

URL:

http://001110110110111011010001010110101101010110 10110110110110101011010101010110101011010101...

Technique 2: Restricted Control Transfers

context switch BASIC BLOCK CACHE

non-control-flow instructions

TRACE CACHE indirect branch lookup

non-control-flow instructions

trace branch taken?

Restrict based on source address, destination address, and/or transfer type

Technique 2: Restricted 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
Only within a known function or to a known function entry point

Intra-Segment Jumps

Intra-Segment Indirect Calls

Only to known function entry points

Technique 2: Restricted Control Transfers

Returns

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

Technique 3: Un-circumventable Sandboxing

Typical problem with sandboxing:

If attacker gains control, can bypass checks

DynamoRIO-inserted sandboxing is un-circumventable

DynamoRIO enforces unique entry points

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

Memory protection
Application Privileges DynamoRIO Privileges

Page type

Application code
Application data DynamoRIO code DynamoRIO data

R
RW R R

R
RW R RW

Code cache

RW

Memory protection
Application Privileges DynamoRIO Privileges

Page type

Application code
Application data DynamoRIO code DynamoRIO data

R
RW R R

R
RW RE RW

Code cache

RE

RW

Outline

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

Evaluating an Intrusion Prevention Solution

1.

2.
3. 4. 5. 6.

7.

Accuracy Maintainability Scalability Coverage Proactivity Uncircumventability Containment

1. Accuracy

How much false positives

Frequency of False positives Impact of a false positive

Why you need and IPS?

Availability vs. Privacy/Integrity

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

3. Scalability

Requirements to run enterprise-wide Critical bottlenecks

Deployment / maintenance Performance

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

Most Critical Vulnerabilities

Source: CVE, Microsoft Security Bulletins, 2003-2004

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

Application Released With a bug Vulnerability announced Patch released
Good guys Patch like crazy
Bad guys Analyze patch & create attack

Attack Released

Shortening attack timelines

Vulnerability WebDAV ISS/BlackIce SSL (MS04-011) Date 3/03 3/04 4/04 Time to Outbreak 0 days 1 day (Witty) 1 week (SSL bomb)

Lsass (MS04-011)
Internet Explorer

4/04
11/04

2 weeks (Sasser)
-1day no patch (Mydoom.ag)

Speed of Propagation The Witty Worm

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? Is crypto fool-proof? How do you evaluate crypto? 10/90 rule of thumb Nothing is perfect, make it hard...

Compare system security with crypto

Evaluating system security

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?

Other Ways to Stop a Memory Based Attack

1. 2. Network-Based Solutions 3. Compliance Enforcement and Isolation 4. Correlation Engines 5. Event Signature Based Systems 6. 7. Scan Detection and Isolation

Accuracy Maintainability Scalability Coverage Proactivity Uncircumventability Containment

Network Firewalls Signature Based Deep Packet Inspection Vulnerability-Based Deep Packet Inspection

Other Ways to Stop a Memory Based Attack

Compile-Time Solutions

Canaries Type-Safe Languages Randomization Code Obsfucation Libsafe

1. 2. 3. 4. 5. 6. 7.

Accuracy Maintainability Scalability Coverage Proactivity Uncircumventability Containment

Other Ways to Stop a Memory Based Attack

Hardware-Based Solutions

NX Bit

1. 2. 3. 4. 5. 6. 7.

Accuracy Maintainability Scalability Coverage Proactivity Uncircumventability Containment

Other Ways to Stop a Memory Based Attack

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

1. 2. 3. 4. 5. 6. 7.

Accuracy Maintainability Scalability Coverage Proactivity Uncircumventability Containment

Outline

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

Anatomy of an Attack

1. Probing Techniques

E-mail Based

Get the address book Scan the disk Generate random Spam generator algorithms
Random IP Weighted Random IP Mine the ARP table Sniff existing connections

Network Based

2. Penetration Techniques

Social Engineering

Ambiguous text Generated messages with familiar or privilege information Compressed attachments Compressed and encrypted attachments Buffer Overflow Heap Manipulation Format String Vulnerabilities Shatter Attacks Return to Libc Attacks

Program Vulnerabilities

Privilege Escalation Cross-Site Scripting / SQL Injection Weak Passwords / Open Network Shares Known Backdoors

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

4. Propagation Techniques

Mail

Use the e-mail client Find an open e-mail relay Bring your own SMTP server
Bring your own http server

Web connection

IRC FTP File Infection Via Backdoors

5. Paralyzation Techniques

Impact of killing the host on propagation Delete / destroy data

Example: The Witty worm Sloppy use of excessive resources Spyware Not seen in mass worms For fun and fame vs. profit Zombie farms for DDOS attacks

Denial of Service

Information leaks

Directed Attacks

Worms for Profit

The Determina Story

From a research project at CSAIL to a Startup Timeline

1999 Dec 2001 Dec 2002 Jan 2003 Feb 2003 April 2003 May 2003 Jan 2004 April 2004 May 2004 June 2004 Nov 2004

DynamoRIO Project Started Optimize Programs The Idea of Program Shepherding Provisional Patent Filed The Slammer worm Program Shepherding published at USENIX Security Started talking to VCs Araksha founded with $ 3M Series A funding Preview version released, 1st customers Series B funding of $ 16M Sasser worm stopped at customer sites Company unveiled, name changed to Determina Enterprise-ready product released