determina darpa pi meeting 1-9-2007. page 2confidential © determina, inc. agenda liveshield...

Determina

DARPA PI meeting 1-9-2007

Confidential © Determina, Inc.

Agenda

• LiveShield– Product and Technology– Current Status

• Applications to Application Communities– Automation– Patch Test

• What is it• Early Experiments


Determina Stops The Attack At The Hijack Stage

NETWORK

KERNEL

Make paymentChange prefs

Read statement

Write Record Update RegistryOpen port

HIJACK

ProgramCounter

HIJACK

ProgramCounter

COMPROMISECOMPROMISE

ENTERENTER

call

br

jmp

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• Used by IDS, Application Firewalls

HIJACK• “Catch in the act of criminal behavior”• All programs follow strict conventions

– ABI (Application Binary Interface)– The Calling Convention (MS/Intel)

• Currently no enforcement• All attacks violate some of these conventions

COMPROMISE• Monitoring can be done

– System call monitoring• Hard to distinguish between actions of a

normal program vs. a compromised program

– Leads to false positives• Used by “System Call Interception” HIPS

systems

SYSTEM & APPLICATION MEMORY

3) ABI Violatio

n

1) NO ABI

Violation

2) NO ABI

Violation

Attack Code


Determina (DynamoRio) Review

br

ret

call

jmp

Original Code(Never run directly)

VPSAgent

call

jmp

VPSAgent

Runtime

Code CacheApplicationVulnerability

br

Memory Firewall™

Continuously runs checks on all code control transfers:• Restricted Code Origins• Restricted Control Transfer• Uncircumventable Sandboxing

LiveShield™

1. New “Shield” available and vulnerable code block detected in cache

2. Vulnerable code block replaced with “Shield”

br

“Shield” has fixed code for vulnerability

Windows Service or Application


Determina LiveShield®

• Precise vulnerability protection in real-time– Complements Memory Firewall by adding coverage for all

other vulnerabilities– Is performed by ‘hot-patching’ processes that are running

under DynamoRio.– Real-time update - no reboot– Patching-friendly deployment– Approx. 30 shields produced 2005-2006

Vulnerabilities addressed by LiveShield™• DoS• Privilege escalation• Directory traversal• Others


LiveShield® Product Details

• First intrusion prevention to achieve precision (but not delays) of patching– Blocks root-cause vulnerability, not attack behavior – eliminates

malware propagation and cleanup– Strong protection – covers all possible input vectors– Accurate – enforces only activity localized to flaw

• Real-time deployment of new LiveShield “Shields” without a reboot– LiveShield updates issued within days of critical new

vulnerabilities– New sentries automatically protect vulnerable applications with

no downtime

• Capable of protecting any vulnerability that can be fixed with patches– Privilege elevation, directory traversal, DoS, etc.

Determina and LiveShield Experience (2006)

• Began producing shields in 2005 and tracking published vulnerabilities.– Normally able to produce shields (when required) faster than hackers

(Zotob)– Almost all significant vulnerabilities are handled by DR or LiveShield

• Significant trends over that time– Movement from remote exploitation to client-side attacks

• 41 advisories against Office in 2006, only 45 against all of MSFT in 2005– Increase in kernel exploits

• Still a small number– Significant number of 0-days in 2006

• 284 days in 2006 where unpatched PoC existed against IE 6• 0-days after ‘Patch Tuesdays’ in several months

– General increase in the number of vulnerabilities recognized by MSFT• 45 -> 104

– Vista still vulnerable• Determina Security Research recently reported 5 significant 0-days against

IE7 and Vista• Other trends not covered here

– Increase in web application vulnerabilities

LiveShield Process

Proof ofconceptexploit

released

Acquirethe exploit

Trace the exploit activity

Patchreleased

Difference the patch against the previous version to identify modified

code

Find how to force control to flow through the modified code

Attackreleased

Acquire the attack

Trace the attack’s activity

Identify the vulnerability

Develop a ‘shield’

Port the ‘shield’ to multiple versions

Test the ‘shield’

Release the ‘shield’ to customers

Manual Steps

LiveShield Deployment

Security laboratory Internet

Controller server

Enterprise

Host

Node Manager

Applications

Host

Node Manager

Applications

LiveShield and App Communities

• Opportunities for Improvement– Automate the manual steps without the intervention

of the lab.• Daikon constraint is violated on one machine• Based on the constraint violation a LiveShield is

produced• LiveShield is propagated to other machines in the

community

– Use automation to widen the set of applications that are covered.

• Currently, the product only covers MSFT services and applications because of manpower constraints.

– Use automation to provide other capabilities• PatchTest (see later slides)


PatchTest - Vulnerability Management Lifecycle

Vulnerability disclosed:

either zero-day, vendor, third-party

Patch issued by vendorCustomer

starts testing patch

Customer testing

completeCustomer

starts deploying

patch

Customer patch

deployment complete

Appearance of third-party

exploit code for

vulnerability

Average exploit

window –6.8 days

(Symantec)

Average patch release window

– 49 days

(Symantec)

Average patch deployment

window –63 days (Yankee Group)

TESTING DEPLOYMENT

PatchManagement

Vulnerability Protection

Incremental Development – Patch Test

• What is it?– Given a vendor patch, automatically perform a binary

difference between the patch and unpatched code.– Automatically produce a ‘probe’ shield

• Does nothing but report that it was executed

– Deploy to all machines in a community– Examine statistics

• Application to community– 1st step in producing automated patches that can be

deployed to a number of machines in the community– Potential short-term commercial application

• Shortens the patch deployment lifecycle for customers

Patch Test – further details

• Patch Coverage Measurement (PCM) – – Provide a ‘patch test’ for a test patch system– Collect coverage statistics– Report these to a centralized console to provide

patch deployment confidence.

• Execution Similarity Measurement (XSM)– Provide a ‘patch test’ for unpatched systems and for

patched systems– compare the results of running these in the

community for a period of time.

XSM Details

XSM – Use Case

• Lifecycle of 12 machines with XSM

Patch Test - Prototype

• Built ‘automated probes’ for one patch, generated a set of specific tests for that functionality

• DHCP client vulnerability– 14 patch points (as opposed to some IE tests that have

100 or more)– Test consisted of rebooting machine, giving up

reservation, and then renewing the reservation.– 57% patch coverage

• Next steps– Expand the set of automated patches– Create community of machines to test out XSM– Same automation mechanism can form the basis for

Daikon-based experiements.

determina darpa pi meeting 1-9-2007. page 2confidential © determina, inc. agenda liveshield...

Documents