Worms and Worm Mitigation Saman Amarasinghe Associate Professor, MIT EECS/CSAIL CTO, Determina Inc

Worms and Worm MitigationSaman 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


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

What is a worm?

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

History of Worms1982 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 user’s 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 Worm2003 Blaster Worm2004 Sasser Worm2004 Witty Worm

Today’s 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


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 application’s 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

An Example: Buffer Overflow Attack

OperatingOperatingSystemSystem

NetworkNetwork

ApplicationApplicationDataData

InstructionsInstructions

handle_URL(handle * h){

char url[64];…char * tmp =geturl(h)strcpy(url, tmp);…

}

Local Variables: URLLocal Variables: URL

Local Variables: tmpLocal Variables: tmpReturn AddressReturn Address

Argument: hArgument: h

Local Variables: …Local Variables: …

Return AddressReturn Address

Arguments: …Arguments: …

StackStackCodeCode



NetworkNetwork



Program Counter: Program Counter: Executes the Executes the

Program Instruction Program Instruction by Instructionby Instruction




}







StackStackCodeCode

http://cag.lcs.mit.edu/~saman/tmp/doitnow.pl?helper=“foobar”http://cag.lcs.mit.edu/~saman/tmp/doitnow.pl?helper=“foobar”myid=123453;junk=23#42@$@FFNLQ!_@##*RFNL!~@#+myid=123453;junk=23#42@$@FFNLQ!_@##*RFNL!~@#+

URL:URL:




}







StackStackCodeCode

http://cag.lcs.mit.edu/~saman/tmp/doitnow.pl?helper=“foobar”http://cag.lcs.mit.edu/~saman/tmp/doitnow.pl?helper=“foobar”myid=123453;junk=23#42@$@FFNLQ!_@##*RFNL!~@#+myid=123453;junk=23#42@$@FFNLQ!_@##*RFNL!~@#+

URL:URL:



NetworkNetwork



EnterEnter








StackStack

http://0011101101101110110100010101101011010101101101http://001110110110111011010001010110101101010110110110110110110110101011010101010110101011010101010110...10110110110110101011010101010110101011010101010110...

URL:URL:

0x12FA20x12FA2

0x12FA20x12FA2

Malicious code segmentMalicious code segment

lea %ecx%eaxlea %ecx%eaxsub 0x1c(%edi) %eaxsub 0x1c(%edi) %eaxmovzx 0x8(%edi) %ecxmovzx 0x8(%edi) %ecxshl $0x07 %ecxshl $0x07 %ecxcmp %eax %ecxcmp %eax %ecx……………………



}

CodeCode

0x12FA20x12FA2



NetworkNetwork



AttackAttack

HijackHijack

EnterEnter

Enter Monitoring is simple

Port monitoring or system call monitoring Don’t 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 Leads to false positives

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

When to stop an attack?

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

Stop Applications From Being Hijacked

Processor Execution Environment

ABI

Restricted Control Transfer:Restricted Control Transfer:Is it legal to go from here to there?Is it legal to go from here to there?

Restricted Code Origins:Restricted Code Origins:Is this code came from a code page?Is this code came from a code page?

Restricted Control Transfer:Restricted Control Transfer:Is it legal to go from here to there?Is it legal to go from here to there?


jmp

How Program Shepherding Work?

ProgramProgram

call

br

ret

Run-time Run-time SystemSystem

CodeCodeCacheCache

call

jmp

br

Program Counter: Program Counter: Executes the Executes the

Program Program Instruction by Instruction by

InstructionInstruction

Never Let go of the Never Let go of the Program CounterProgram Counter


next VPC

Instruction Interpreter

A Basic Interpreter

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

decodefetch next instruction execute

exception handling

update VPC

Validate

Performance of the Basic Interpreter

vpr (Spec2000)

1.20 1.082.9726.03

0

50

100

150

200

250

300

Simple Interpreter basic block cache basic block cachewith direct linking

basic block cachewith linking

(direct+indirect)

basic block+tracecaches with linking

Slo

wd

ow

n fa

cto

rS

low

do

wn

fact

or

context switch

BASIC BLOCK CACHE

non-control-flow instructions

Trick I: Adding a Code Cache

next VPC

fetch block at VPC

lookup VPC

emitblock

exception handling

executeblock

vpr (Spec2000)

1.20 1.082.9726.03

0

50

100

150

200

250

300



(direct+indirect)


Slo

wd

ow

n fa

cto

rS

low

do

wn

fact

or

Adding a Basic Block CachePerformance Effect

Performance Problem: High cost of frequent context switches

Slo

wd

ow

n fa

cto

rS

low

do

wn

fact

or

context switch

BASIC BLOCK CACHE


Trick II: Linking

next VPC

fetch block at VPC

lookup VPC

emitblock

exception handling

execute until cache miss

linkblock

vpr (Spec2000)

1.20 1.082.9726.03

0

50

100

150

200

250

300



(direct+indirect)


Slo

wd

ow

n fa

cto

rS

low

do

wn

fact

or

Performance Effect of Basic Block Cache with direct branch linking

Performance Problem: High cost of mispredicted indirect branches

basic block builder

context switch

indirect branch lookup

BASIC BLOCK CACHE


next VPC

miss

miss

Trick III: Efficient Indirect Branch Handling

vpr (Spec2000)

1.20 1.082.9726.03

0

50

100

150

200

250

300



(direct+indirect)


Slo

wd

ow

n fa

cto

rS

low

do

wn

fact

or

Performance Effect of indirect branch linking

Performance Problem: inefficient code layout in code cache

basic block builder trace selectorSTART

dispatch

context switch


BASIC BLOCK CACHE

TRACE CACHE



Trick IV: Picking TracesTrick IV: Picking Traces

Performance Effect of Performance Effect of Picking TracesPicking Traces

300vpr (Spec2000)

1.20 1.082.9726.03

0

50

100

150

200

250

300



(direct+indirect)


Slo

wd

ow

n fa

cto

rS

low

do

wn

fact

or

Monitor all Control TransfersMonitor all Control Transfers Must intercept all windows initiated control transfer events

Exceptions Call backs in Windows Asynchronous procedure calls Setjmp/longjmp Set thread context

KernelKernel

Code CacheCode Cache

ApplicationApplication

ntdll.dll / *32.dllntdll.dll / *32.dll

WindowsWindows

Transparent to the Transparent to the ApplicationApplication

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

As code is copied to the code cache, check where it’s coming from

Check the security policy only once

A

B

D

E

Code CacheUnmodified code pages

Modified pages

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







StackStack

http://001110110110111011010001010110101101010110http://00111011011011101101000101011010110101011010110110110110101011010101010110101011010101...10110110110110101011010101010110101011010101...

URL:URL:

0x7F8B00x7F8B0

Fake argumentsFake arguments



}

CodeCode

0x8A2340x8A234

Fake argumentsFake arguments

LibrariesLibrariessetuid()

…unlink()

…0x7F8B00x7F8B0 0x8A2340x8A234

Technique 2:Restricted Control Transfers

context switch


trace branch taken?

BASIC BLOCK CACHE

TRACE CACHE



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


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


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 isun-circumventable DynamoRIO enforces unique entry points

Protecting DynamoRIO Itself DynamoRIO runs in the application’s

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

Page typeApplicationPrivileges

DynamoRIO Privileges

Application code R R

Application data RW RW

DynamoRIO code R R

DynamoRIO data R RW

Code cache R RW

Memory protection

Page typeApplicationPrivileges

DynamoRIO Privileges

Application code R R

Application data RW RW

DynamoRIO code R RE

DynamoRIO data R RW

Code cache RE RW

Outline


Evaluating an Intrusion Prevention Solution

1. Accuracy

2. Maintainability

3. Scalability

4. Coverage

5. Proactivity

6. Uncircumventability

7. 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%

of

vuln

erab

ilitie

s

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

Attack Released

Good guys Patch like crazy

Bad guysAnalyze patch &

create attack

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)

Speed of PropagationThe 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?

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...

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

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

1. Accuracy

2. Maintainability

3. Scalability

4. Coverage

5. Proactivity


7. Containment


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

1. Accuracy

2. Maintainability

3. Scalability

4. Coverage

5. Proactivity


7. Containment


Hardware-Based Solutions NX Bit

1. Accuracy

2. Maintainability

3. Scalability

4. Coverage

5. Proactivity


7. 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

1. Accuracy

2. Maintainability

3. Scalability

4. Coverage

5. Proactivity


7. Containment

Outline


Anatomy of an Attack

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

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

3. Persisting Techniques Create new files Infect the boot sector Modify files (DLL’s 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

Web connection Bring your own http server

IRC FTP File Infection Via Backdoors

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

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

Documents

Worms and Worm Mitigation Saman Amarasinghe Associate Professor, MIT EECS/CSAIL CTO, Determina Inc