hidden processes: the implication for intrusion detection james butler dr. jeff undercoffer dr. john...

23
Hidden Processes: The Implication for Intrusion Detection James Butler Dr. Jeff Undercoffer Dr. John Pinkston

Upload: audra-rich

Post on 04-Jan-2016

215 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Hidden Processes: The Implication for Intrusion Detection James Butler Dr. Jeff Undercoffer Dr. John Pinkston James Butler Dr. Jeff Undercoffer Dr. John

Hidden Processes: The Implication for Intrusion

Detection

Hidden Processes: The Implication for Intrusion

Detection

James ButlerDr. Jeff UndercofferDr. John Pinkston

James ButlerDr. Jeff UndercofferDr. John Pinkston

Page 2: Hidden Processes: The Implication for Intrusion Detection James Butler Dr. Jeff Undercoffer Dr. John Pinkston James Butler Dr. Jeff Undercoffer Dr. John

RootkitsRootkits

• First appeared in 1993 as a collection of compromised system binaries:• ls, ps, netstat, login, du, • Facilitated access and masked activity

• Why – because they could• Consider the case of Kevin Mitnick:• served five years in prison, 8 months of that in

solitary confinement• tested then-nascent laws that had been enacted

for dealing with computer crime• Most famous for the “Mitnick Attack”

Page 3: Hidden Processes: The Implication for Intrusion Detection James Butler Dr. Jeff Undercoffer Dr. John Pinkston James Butler Dr. Jeff Undercoffer Dr. John

The Mitnick AttackThe Mitnick Attack

Host A

Host B{TrustsHost A}

Attacker

Step 1. Initiate Syn/Flood to prevent

Host A from Responding to Host B

Step 2. Probe Host B

to determine TCP

sequence numbering

Step 3. Pretending to be Host A, in

itiate a

TCP session With Host B.

Step 4. Host B sendsSYN/ACK to Host A, inresponse to step 3. HostA’s input queue is fulland does not receive themessage

Step 5. Using Host A

’s address and the calculated

TCP sequence number of Host B, th

e attacker responds to the

SYN/ACK sent by Host B in Step 4,

Page 4: Hidden Processes: The Implication for Intrusion Detection James Butler Dr. Jeff Undercoffer Dr. John Pinkston James Butler Dr. Jeff Undercoffer Dr. John

Anomaly Based IDSsAnomaly Based IDSs

• Detect:• Aberrant processes and services• Files that are created/deleted/modified• Network connections

• Uses and trusts the underlying operating system• If the underlying operating system is compromised,

the IDS fails.

Page 5: Hidden Processes: The Implication for Intrusion Detection James Butler Dr. Jeff Undercoffer Dr. John Pinkston James Butler Dr. Jeff Undercoffer Dr. John

Basic TypesBasic Types

• Kernel• Device Driver (Microsoft)• LKM (Linux)

• Application• Library

Page 6: Hidden Processes: The Implication for Intrusion Detection James Butler Dr. Jeff Undercoffer Dr. John Pinkston James Butler Dr. Jeff Undercoffer Dr. John

Attack ScenarioAttack Scenario

• Attacker gains elevated access to computer system

• Attacker installs a Rootkit• Rootkit’s functions

• Hide processes• Hide files• Hide network connections• Install a backdoor for future access to the system

• Rootkits act as a part of the operating system so they have access to kernel memory.

Page 7: Hidden Processes: The Implication for Intrusion Detection James Butler Dr. Jeff Undercoffer Dr. John Pinkston James Butler Dr. Jeff Undercoffer Dr. John

State of Current RootkitsState of Current Rootkits

Advanced rootkits filter data• Hook the System Call Table of the operating

system (the functions exported by the kernel)• Hook the Interrupt Descriptor Table (IDT)

• Interrupts are used to signal to the kernel that it has work to perform.

• By hooking one interrupt, a clever rootkit can filter all exported kernel functions.

Page 8: Hidden Processes: The Implication for Intrusion Detection James Butler Dr. Jeff Undercoffer Dr. John Pinkston James Butler Dr. Jeff Undercoffer Dr. John

Next Generation Rootkit TechniquesNext Generation Rootkit Techniques

• Direct kernel object modification in memory• A device driver or loadable kernel module has

access to kernel memory• A sophisticated rootkit can modify the objects

directly in memory in a relatively reliable fashion.

Page 9: Hidden Processes: The Implication for Intrusion Detection James Butler Dr. Jeff Undercoffer Dr. John Pinkston James Butler Dr. Jeff Undercoffer Dr. John

Hiding Processes - WindowsHiding Processes - Windows

• Locate the Processor Control Block (KPRCB)• Located at 0xffdff120• fs register in kernel mode points to 0xffdff000

• Within the KPRCB is a pointer to the Current Thread block (ETHREAD)• Located at fs:[124] or 0xffdff124• An ETHREAD contains a KTHREAD structure

Page 10: Hidden Processes: The Implication for Intrusion Detection James Butler Dr. Jeff Undercoffer Dr. John Pinkston James Butler Dr. Jeff Undercoffer Dr. John

Hiding Processes - WindowsHiding Processes - Windows

• The KTHREAD structure contains a pointer to the EPROCESS block of the current process

• The EPROCESS block contains a LIST structure, which has a forward and backward pointer to active processes• This creates the doubly linked list of active

processes in Windows

Page 11: Hidden Processes: The Implication for Intrusion Detection James Butler Dr. Jeff Undercoffer Dr. John Pinkston James Butler Dr. Jeff Undercoffer Dr. John

Hiding Processes - WindowsHiding Processes - Windows

• To hide a process• Locate the EPROCESS block of the process to hide• Change the process behind it to point to the

process after the process you are hiding• Change the process after it to point to the process

before the one you are trying to hide

Page 12: Hidden Processes: The Implication for Intrusion Detection James Butler Dr. Jeff Undercoffer Dr. John Pinkston James Butler Dr. Jeff Undercoffer Dr. John

Hiding Processes - WindowsHiding Processes - Windows• Hiding Processes -

Before (Windows)KPRCB

*CurrentThread *NextThread *IdleThread

ETHREAD

KTHREAD

ApcState

EPROCESS

KPROCESS

LIST_ENTRY { FLINK

BLINK }

EPROCESS

KPROCESS

LIST_ENTRY { FLINK

BLINK }

EPROCESS

KPROCESS

LIST_ENTRY { FLINK

BLINK }

KPRCB

*CurrentThread *NextThread *IdleThread

ETHREAD

KTHREAD

ApcState

EPROCESS

KPROCESS

LIST_ENTRY { FLINK

BLINK }

EPROCESS

KPROCESS

LIST_ENTRY { FLINK

BLINK }

EPROCESS

KPROCESS

LIST_ENTRY { FLINK

BLINK }

• Hiding Processes - After (Windows)

Page 13: Hidden Processes: The Implication for Intrusion Detection James Butler Dr. Jeff Undercoffer Dr. John Pinkston James Butler Dr. Jeff Undercoffer Dr. John

Hiding Processes - WindowsHiding Processes - Windows

• Why does the process continue to run?• Scheduling in the Windows kernel is thread based

and not process based.

• Although scheduling code to run is based upon threads, when the kernel reports what is running on the system, it reports based upon EPROCESS blocks which can be modified with no adverse affect. This is what current tools (IDS’s) rely upon to discover what is running on the system.

Page 14: Hidden Processes: The Implication for Intrusion Detection James Butler Dr. Jeff Undercoffer Dr. John Pinkston James Butler Dr. Jeff Undercoffer Dr. John

Hiding Processes – LINUXHiding Processes – LINUX

• The LINUX kernel contains an array of task_struct’s.

• A task_struct is similar to an EPROCESS block in Windows

• task_struct contains pointers to the prev_task and next_task

• task_struct also contains pointers to the prev_run and next_run for the running processes

Page 15: Hidden Processes: The Implication for Intrusion Detection James Butler Dr. Jeff Undercoffer Dr. John Pinkston James Butler Dr. Jeff Undercoffer Dr. John

Hiding Processes – LINUXHiding Processes – LINUX

• To hide a process, remove the process from the list of prev_task and next_task

• Leave next_run and prev_run alone

Page 16: Hidden Processes: The Implication for Intrusion Detection James Butler Dr. Jeff Undercoffer Dr. John Pinkston James Butler Dr. Jeff Undercoffer Dr. John

Hiding Processes - LinuxHiding Processes - Linux• Hiding Processes -

Before (Linux)• Hiding Processes - After

(Linux)task_array

PID1901

State

*next_task*prev_task

*next_run*prev_run

*p_pptr *p_cptr *p_ysptr *p_osptr

...

...

PIDProcess 0

State

*next_task*prev_task

*next_run*prev_run

...

...

PID

State

*next_task*prev_task

*next_run*prev_run

*p_pptr *p_cptr *p_ysptr *p_osptr

...

...

*p_pptr *p_cptr *p_ysptr *p_osptr

task_array

PIDProcess 0

State

*next_task*prev_task

*next_run*prev_run

*p_pptr (null)

*p_cptr *p_ysptr *p_osptr

...

...

PID

State

*next_task*prev_task

*next_run*prev_run

*p_pptr *p_cptr *p_ysptr *p_osptr

...

...

PID

State

*next_task*prev_task

*next_run*prev_run

*p_pptr *p_cptr *p_ysptr *p_osptr

...

...

PID1901

State

*next_task*prev_task

*next_run*prev_run

*p_pptr *p_cptr *p_ysptr *p_osptr

...

...

Page 17: Hidden Processes: The Implication for Intrusion Detection James Butler Dr. Jeff Undercoffer Dr. John Pinkston James Butler Dr. Jeff Undercoffer Dr. John

Hiding Processes - LINUXHiding Processes - LINUX

• Process will freeze?• It is no longer able to be scheduled• The LINUX scheduler walks the list of task_struct’s

to calculate the goodness value of the process to decide rather to schedule it or not.

• In order to make this work, you must also hot-patch the LINUX scheduler to schedule the hidden process.

• Inject binary into the scheduler

Page 18: Hidden Processes: The Implication for Intrusion Detection James Butler Dr. Jeff Undercoffer Dr. John Pinkston James Butler Dr. Jeff Undercoffer Dr. John

Detecting Hidden Processes in Windows

Detecting Hidden Processes in Windows

• Methodology: Examine each thread to ensure its corresponding process descriptor (EPROCESS) is appropriately linked.

• This requires patching the kernel in memory.• Hunt and Brubacher introduced Detours for

intercepting Win32 binary functions.

Page 19: Hidden Processes: The Implication for Intrusion Detection James Butler Dr. Jeff Undercoffer Dr. John Pinkston James Butler Dr. Jeff Undercoffer Dr. John

DetoursDetours

• Overwrite beginning of target function with an unconditional jump to a Detour function

• Detour function calls a Trampoline function• The Trampoline function contains the

overwritten bytes of the original Target function and calls the Target function

• The Target function returns to the Detour function

• The Detour function returns to the source caller

Page 20: Hidden Processes: The Implication for Intrusion Detection James Butler Dr. Jeff Undercoffer Dr. John Pinkston James Butler Dr. Jeff Undercoffer Dr. John

DetoursDetours

Page 21: Hidden Processes: The Implication for Intrusion Detection James Butler Dr. Jeff Undercoffer Dr. John Pinkston James Butler Dr. Jeff Undercoffer Dr. John

Patching the Windows kernelPatching the Windows kernel

• SwapContext does context switching in Windows

• Overwrite the first seven bytes of SwapContext with a jump to our Detour function

• EDI points to the KTHREAD of the thread to be scheduled to run

• Our Detour function follows the KTHREAD to the EPROCESS block and determines if it is still appropriately linked in the list of active processes.

Page 22: Hidden Processes: The Implication for Intrusion Detection James Butler Dr. Jeff Undercoffer Dr. John Pinkston James Butler Dr. Jeff Undercoffer Dr. John

Detecting Hidden Processes in LINUXDetecting Hidden Processes in LINUX

• Injectso is a library similar to Detours• Intended as a means of attack• Uses ELF - Executable and Linkable Format

• Already Has stubs into code

Page 23: Hidden Processes: The Implication for Intrusion Detection James Butler Dr. Jeff Undercoffer Dr. John Pinkston James Butler Dr. Jeff Undercoffer Dr. John

ConclusionConclusion

• Detecting processes that have hidden from the OS by means of unhooking themselves from system accounting processes is computational expensive!

• Prevention is worth a pound of cure!