VM Introspection for Cognitive Immunity (VICI)

VM Introspection for Cognitive Immunity (VICI)

Komoku, Inc.Tim Fraser [email protected]

June 2007 SRS2 PI Meeting

mailto:[email protected]

VICI = VMI + repair + learning

Problem:• Adversaries install kernel rootkits to

hide, facilitate access, spy for days, weeks, months...

• Difficult to detect.• Difficult to remove.Proposed Solution:• VM Introspection for self-diagnosis.• Automated repair for self-healing.• Learning to optimize repair selection =

“cognitive immunity”.

Rootkit attacks

VM runningmission apps

VICI

diagnosticinformation

repairs

2VICI – Tim Fraser <[email protected] – Komoku, Inc.

VICI prototype testbed

4. refinements

REPAIRAGENT

KME XEN KERNEL

LEARNINGENGINE

On privileged “Domain0” VM On User VM

Know-ledgebase

EXISTSNOW

TODO

2. Nooks, Microreboot, ReVirt repair problems

1. VM introspection reports problems

3. VM introspection evaluates repair effectiveness


Project timeline

Phase 1 prototype:diagnostics and repairs

Phase 2 prototype:adds learning for cognitive immunity

Phase 3 (final) prototype:adds coverage for Red Team exercises

Current status:Phase 1 prototype complete!

Q1 Q2 Q3 Q4 Q5 Q6

(Jun 07) (Dec 07) (Jun 08)


Summary of Phase 1 Results

• Demonstrated useful self-diagnosis:– Prototype detects 6 kinds of kernel rootkit

tampering.

• Demonstrated useful self-healing:– Prototype repairs above 6 attacks.• 5 “surgical” repairs• 1 more complex Nooks-style repair

– Alternate “Core War” approach to repair may prove to be equally effective at lower cost.


Demo: diagnostics and surgical repair

rootsim

REPAIRAGENT

KME XEN KERNEL


Know-ledgebase

EXISTSNOW2. “Surgical repairs” by writing RAM, regisers



Attack: text modificationint cap_capable (struct task_struct *tsk, int cap){ if (tsk->cap_effective & CAP_TO_MASK(cap)) return 0; return -EPERM;}

------------- G O O D --------------- -------------- B A D ----------------

cap_capable() text: cap_capable() text:89 d1 mov %edx,%ecx 89 d1 mov %edx,%ecxba 01 00 00 00 mov $0x1,%edx ba 01 00 00 00 mov $0x1,%edxd3 e2 shl %cl,%edx d3 e2 shl %cl,%edx23 90 74 01 00 and 0x174(%eax),%edx | 0b 90 74 01 00 or 0x174(%eax),%edx

Original check: you need this AND that to pass.

Tampered check: you need this OR that to pass(always passes).


Text diagnostic and repair

1. Agent reads text in 4KB blocks.

2. Agent computesMD5 checksums,compares toproper values.

3. Agent writes back good text.

XEN

Domain 0 Guest Domain

VICI Agent Victim kernel:• Text• Static data• Dynamic data

Virtual Hardware:• Registers


Attack: system call interpositionidt register

InterruptDescriptorTable

0x80 handlerfunction

System CallTable

Rootkit function

Kernel function

• Code taken from “override” rootkit.• Hides files.• Interposes on getdents64

system call.

• Override getdents64:• Call real getdents64,• Removes files named

“Root_*”.


Attack: procfs jump table interposition

System CallTable

Kernel readfunction

Procfs jumpTable

Rootkit function

Procfs function

• Code taken from “Adore-ng”.• Hides processes.• Interposes on procfs readdir

function.

• Adore-ng readdir:• Call real readdir,• Removes processes with

euid != 0.• (The real Adore-ng has

different removal criteria.)


Table diagnostic and repair

1. Agent reads tables

2. Agent computesMD5 checksums,compares toproper values.

3. Agent writes back good table values.

XEN


VICI Agent Victim kernel:• Text• Static data (tables)• Dynamic data



• Home-grown privilege escalation technique.• Makes idt register point to

phony IDT.• Phony 0x80 handler:• Promotes callers to

root,• Calls kernel’s 0x80

handler.• No modifications to:• Original IDT,• Original 0x80 handler.

Attack: idt register redirectionidt register


Rootkit InterruptDescriptor Table

Rootkit 0x80handler

Kernel 0x80handler

System call table


Register diagnostic and repair

1. Agent reads idt register value.

2. Agent compares observed value to proper value.

3. Agent writes back good value.

XEN




Bug: causes VM to hang. We do fix from LKM for now.


Attack: pseudo-random number generator (PRNG) weakening

------------- G O O D --------------- -------------- B A D ----------------

PRNG pools and polynomials: PRNG pools and polynomials:polynomial A: 103 76 51 25 1 | polynomial A: 0 0 0 0 0polynomial B: 26 20 14 7 1 | polynomial B: 0 0 0 0 0input pool: 0x15182c1e142ead04 | input pool: 0x0000000000000000nonblocking pool: 0xbc0173de1a09ead2 | nonblocking pool: 0x0000000000000000blocking pool: 0x3725ea43a837418e | blocking pool: 0x0000000000000000

• Attack due to Baliga and others at Oakland 2007.• Weakens Linux PRNG output to make keys guessable.• Linux PRNG:• fills pools with numbers based on interrupt timing,• stirs pools with 5-term polynomial.

• Baliga attack zeroes pools and polynomial exponents.• Baliga attack repeats, ours doesn’t (yet).


PRNG state diagnostic and repair

1. Agent reads PRNG exponents.

2. Agent compares exponents to proper values.

3. Agent writes back good exponents, refills pools with bytes from Domain 0’s PRNG.





Demo: non-surgical repair

REPAIRAGENT

KME XEN KERNEL


Know-ledgebase

EXISTSNOW2. Nooks-style repair action


sidekick

ttysnoop


Ttysnoop: keyboard snifferidt register


0x80 handlerfunction

System CallTable

Ttysnoop read and write functions

Kernel read and write functions

• Code taken from “sk2” and “Linspy” rootkits.• Snoops ttys for passwords.

• Ttysnoop rootkit:• Interposes on read and

write system calls.• When write sees

“password:” prompt,• Dumps next line seen by

read to system log.


Sidekick during normal runtime

Victim kernel

Ttysnoop

Sidekick

----------- blocked -----------

other other write read

gcc Login: User programs make system calls.

Ttysnoop intercepts read and write.

Sidekick keeps track of which processes are blocked (waiting) on read and write.


Sidekick during unload repair

Victim kernel

Ttysnoop

Sidekick

----------- blocked -----------

other other write read

gcc Login: 1. Agent detects interposition.

2. Agent traces read and write function pointers to Ttysnoop (not yet done).

3. Sidekick SIGTERMs processes blocked on read and write to unwind their stacks.

4. Sidekick unloads Ttysnoop.


Proposed “Core War” alternativeTtysnoop write:

Preamble

Call kernel write

Wrote “ssword”?

Log mode on!

Conclusion

Rendered harmless:

Preamble

Call kernel write

NOPNOPNOP

Conclusion


Up next: phase 2 learning

VICI – Tim Fraser <[email protected] – Komoku, Inc. 21

diagnosis

adjust releaser

thresholds

choose repair action

Goal: learn to choose the least costly effective repair.

Problem:The foo data structure has been tampered with!

Set of relevant repair actions:Tweak existing fooReplace entire fooRestart foo-using subsystemRestore system checkpoint (!!)

evaluation

-->...

Phase 3: % of data examined on a single momentary scan (vs. data never

examined at all)

Static dataIncluding

jump tables(ubiquitous)

Text(common)

Dynamic data(rare)

Hardware state(mainly theoretical)

Done nowPlannedfor VICI

Seems possible in theory

100% coverage

(*) for a single kernel version. (**) for a single set of hardware.

(*)

(**)

22

Documents

VM Introspection for Cognitive Immunity (VICI)