Diversity Algorithms for Worrisome Software and Networks DAWSON

1
Diversity Algorithms for Worrisome Software and
Networks(DAWSON)

• James Just, Nathan Li, Mark Cornwell
• Global InfoTek, Inc.
• Jeff Rowe, Tufan Demir
• UC Davis
• R. Sekar
• SUNY Stony Brook
• 15 December 2005

2
DAWSON Overview

• Explores Biologically Inspired Diversity
• Automatically generates a large number of program
  variants
• Variants differ in terms of memory layout
• Targets memory errors such as buffer overflows
• Implemented on Microsoft Windows

3
Agenda

• Introduction
• Development Update
• Testing Update
• Analytic Update
• Conclusions

4
Diversity System Functional Architecture
Address randomization does not remove
vulnerability but makes effect of attack
unpredictable
Normal user inputs work
Attacker (memory error exploits)
Modifications transform original stored program
User Inputs
Other System Resources
Original Program
Modified PE File, Loader System Calls
Some attacks fail because vulnerability is not at
assumed address
Other attacks fail because injected commands are
wrong
Optional Annotation File
Transformed In-memory program
PRNG
Pseudo-Random Number Generator
5
Multi-Layer Defense Strategy
Layer 1 - Prevent Remote Exploit of Memory Errors
Layer 2 - Prevent Injected Code from Properly
Executing
Layer 3 - Prevent Bypass of Layer 2
6
CharacterizingDAWSONsMulti-Layer Defenses
Kernel memory
Writable memory
Executable memory
USER.EXE
USER.DLL
SYS.DLL
STACK
HEAP
SYS.SYS
Layer 1
Randomize heap base
Exploit
Randomize base of main and thread stack
Rebase DLL
Randomize Code Location
Randomize heap allocs
Layer 2
Payload
IAT Permutation
PEB/SEH Masking
Non-Bypass- ability
Payload
Layer 3
7
DAWSON Randomizing Transformations

• Approach
• Use transformations that dont require source
  code access
• Suggest compilation/distribution conventions that
  enhance ability to perform randomizing
  transformations
• Develop transformations that make it difficult to
  successfully execute injected code, even if
  attacker breaks through randomization
• Absolute address randomization (AAR)
• base of stack (range 1 to 2GB)
• base address of DLLs (range 1 to 2GB, aligned on
  64K)
• base of executable (range 1 to 2GB, aligned on
  64K)
• Requires relocation information to be included in
  executable
• base of the heap (range 1 to 2GB)
• Relative address randomization (RAR) subsumes
  AAR
• distance between heap blocks
• Achieved by randomly increasing heap allocation
  requests
• future possibility random gaps in between stack
  frames
• in other cases, relative address randomization
  cannot be done unless a lot of additional info is
  included in binary
• relocation information isnt sufficient

8
Development Update
9
DAWSON Development Phases

• Phase 1 First 6 months
• Diversity approaches
• Code transformation techniques
• Phase 2 Second 6 months
• Windows randomization integration
• Application protection
• Phase 3Third 6 months
• Host protection
• Performance and memory efficiency
• Extensive tests

10
DAWSON on a Host
Remote Monitor Controller (e.g., Blackboard)
Messages
Local Host Randomization Configuration
11
DAWSON Changes (Since July '05)

• Primary Stack Randomization
• Native API Augmentation
• Coming Kernel driver integration
• System DLLs Base Randomization (Rebasing)
• Kernel Mode Driver
• PEB/SEH protection
• Debugging API
• 6 New Exploits
• Extensive Testing
• Test in small
• Test in large
• Red team exercise

12
DLL Rebasing Issues

• Rebasing system DLLs like ntdll and kernel32
• Solution use kernel-mode driver to rebase at
  boot-time
• Cost Vs Benefit
• Significant benefits can break exploit and
  payload
• Costs
• Performance impact to relocate code
• Memory impact due to reduced sharing across
  processes
• Options
• Baseline Rebase and Share
• shared, but introduces common vulnerabilities
  across all apps
• Rebase on First Use
• Rebase on Request
• Configurable via registry settings

13
DAWSON Second Layer

• Payload Execution Prevention
• IAT permutation (Done prior to July PI meeting)
• IAT used to lookup addresses of functions in DLLs
• By permuting the order of IAT entries, attack
  code will access the wrong function
• PEB/SEH Protection (New)
• PEB is a data structure with the addresses of
  common API functions
• PEB is memory protected, accessing PEB raises an
  exception
• Exception Handler checks location of caller, if
  it is outside the program boundary, access is
  denied.

14
Rebasing Executables using Exception Handler
Exception Handler with Address Map
stack
IAT
IAT
.text
.text
Address Map
1
3
2
2
1
3
2
15
Limitations
16
Where Absolute Address Randomization Fails

• Non-pointer attacks
• Overflow a buffer to corrupt nearby non-pointer
  data, e.g., string used as argument of execve
• Relies on the ability to find security-critical
  data next to vulnerable buffers Not very easy.
• Attacks that can extract randomization key
• Information leakage attacks
• Relies on a vulnerability that sends back pointer
  values in a response to a request
• Vulnerabilities shared by many other defenses
• StackGuard, StackGhost, PointGuard and some ISR
  implementations

17
Repetitive attacks

• Double-pointer attack
• AAR provides only limited protection
• Guessing attacks
• Require of the order of 15K attempts
• Solutions
• Layer 2 defenses
• Automated response
• Filtering based on automatically generated
  signature is a promising approach to address
  these
• Liang et al 05 generate successful signatures
  to reliably block 10 of 11 attacks in their test
  suite.
• Less than 10 performance overheads, no false
  positives.

18
Expected Attack Attempts for Conventional Attacks
19
Testing Update
20
Implementation Status

• Kernel Driver System DLLs randomization
• Layer 1
• 2-Level Stack Randomization, including primary
  stack
• 2-level Heap Randomization
• Application DLLs randomization
• EXE randomization when .reloc is available
  (included in synthetic vulnerable server)
• Layer 2
• IAT permute and library name erase integrated
• SEH/PEB protection developed, NOT integrated
• Layer 3 Not integrated

21
Testing Changes(Since July 05)

• Extended Benchmark Vulnerable Service to
  incorporate 15 vulnerabilities.
• Extended Attack Corpus to 15 corresponding
  attacks packaged in Metasploit.
• Extensive internal testing
• Performed testing on Emulab to observe
  contributions of individual randomizations.
• Automated testing on small scale 3-node in-house
  testbed and used results to refine/debug
  randomization software.
• Built an iterative test to restart VulnSrv to
  support testing of brute force attacks.
• Conducted Red Team Experiment in November.

22
DAWSON Testing Platform
Monitoring
Metasploit Attack Center
Attack String
23
Key Test Characteristics

• Vulnerabilities
• Stack buffer Overflow
• Format String
• Integer Overflow
• Heap Overflow
• A function may have combinations of the
  vulnerabilities
• Payloads
• Injected Code
• Existing Code
• Existing Program

24
Test Demo
Randomization Blocks most attacks from the test
corpus. All randomizations turned on. Single
Kernel Randomization. Processes re-randomize
every process start.
2 Dec 2005 1212PM Kmd1111 w/ConflResolv1201
25
Comparative Results
26
Overall Layer 1 Effectiveness
Benchmark attacks against unrandomized baseline
avg. penetration rate 100
With initial randomization, avg. penetration rate
fell to 2.4
After further engineering effort, avg.
penetration rate fell to 0.56
Test results show DAWSON randomization
implementation is growing increasingly
effective. Further to go to approach theoretical
limits.
27
Breakdown of Individual Randomization
Effectiveness
Most effective when all techniques are used in
combination.
On unprotected system, all baseline attacks
succeed
Different randomization techniques are effective
against some attack classes and not others.
28
Minor Performance Impacts

• Heap transformations cause 5 overhead for apps
  that are intensive in heap allocations
• Other transformations dont add recurring cost
• One-time overhead for relocation adds modestly to
  the load-time
• Absolute address randomization does not change
  program locality
• Most relocations occur at page granularity
• Relative locations of objects unchanged within a
  page

29
Performance Impact

• Data collected on a Pentium 4 1.2GHz CPU with
  768MB RAM

30
Improving the Test Suite

• Further Work
• Add new exploits focusing on payload execution
• Testing payload execution protection
• Offer to security community
• A package to test memory defense technologies
• Open source vulnerable service with advanced
  memory errors and exploits (packaged as
  Metasploit modules)

31
DAWSON Red Team Exercise

• Layer 1 blocked 15 of 16 attacks (many reps)
• Red team identified a new double vulnerability
• This unintended combination of a stack-buffer
  overflow and format-string vulnerabilities made
  the Red Team exercise a lot more interesting and
  useful!
• Layer 2 blocked the 16th attack

32
Attack Outline

• Vulnerable code (simplified) void
  vulnerable(char attack) char buf1512,
  buf2512 strcpy(buf1, attack) sprintf(buf2
  , buf1)
• Attack
• Guess a writable memory location X
• Use format-string attack to inject code at X
• Overflow buf2 to overwrite return address
• Note attack impossible if the order of
  declaration of buf1 and buf2 were interchanged!
• Use brute-force to guess X

33
Attack Details Layer I
High
DWORD WINAPI FormatStrThread(LPVOID lparameter
char safebuf4096 nRetrecv(peersock,safeBu
f,sizeof(safeBuf),0) formatStrAttack(safeBuf,n
Ret)
MDVULN.dll vulnerable service code
evil
char4096 safeBuf
formatStrThread
sprintf(voiddest, charfmt,) interprets lots
of conversion spex to access stack in flexible
ways
void formatStrAttack(char sbuffer, int nSize)
char buf512 char bufmain512
sprintf(buf, String s,sBuffer) // (1)
sprintf(bufmain,buf) //
(2)
// (4)
(1)

• First sprintf copies the attack string from
  safeBuf into buf.
• Second sprintf interprets 496c in format string
  overflowing waddr into the return address
  location.
• 229chn229chn manipulates chars written to
  write a JMP ESP instruction into 2 bytes at
  waddr.
• Return from formatStrAttack branches to waddr and
  executs JMP ESP instruction. At this time ESP
  points into expanded format string near bufmain..
  
• ESP is manipulated to point to where shell code
  slid to inside the formatStrThread stack frame.
• Normal return now branches to waddr where it
  executes the JMP ESP
• ESP location contains shellcode on stack that
  gains control bootstraps a DLL injection attack.

raddr
(2)
496
some page in memory
formatStrAttack
char512 bufmain
0x7ffdxxxx
(3)
evil
JMP ESP
waddr
Arg5 Arg4 Arg3
char512 buf
Arg2/fmt
Arg1/dest
sprintf
Low
Addresses embedded at start of attack string get
interpreted as arguments to sprintf(dest,fmt,arg
1,arg2,arg3,)
34
Attack Details Layer II

• Metasploit shell code for DLL injection
• Uses PEB to look up GetProcAddress and
  LoadLibrary
• Loads w32.dll and opens socket connection to call
  home.
• Loads the injected DLL payload (hackmark.dll)
  into memory and tricks Windows into treating it
  as a and ordinary DLL linked loaded.
• Transfers execution to the init entry point in
  the DLL.

DAWSON Layer 2 Catches and stops PEB access
since it made from code executing from the stack.
Shell code
char4096 safeBuf
exploit
parms
35
Estimating number of attempts needed

• Attacker needs to guess a writable memory
  location X
• Probability of correctly guessing X fraction of
  writable memory in address space 10MB/2GB
  0.005, for an app using 10MB data
• Vulnerable server uses 0.5MB, so probability of
  success should be about 1/4000
• But Red Team succeeded in 128 attempts! Why?
• Red Team was varying only the leading 8 bits of
  address
• PEB was not relocated, and happened to be located
  at an address that matched the lower 24-bits used
  by Red Team
• Red Team informed by the Blue team of this
  vulnerability
• And the possibility of injecting code into PEB

36
Red Team Attack Conclusions

• DAWSON robust against attacks that exploit any
  single vulnerability in vulnerable server
• Randomization is vulnerable to rare combinations
  of vulnerabilities
• To be effective, all memory regions should be
  randomized
• Non-randomization of PEB was the reason for Red
  Team to succeed in 100 attempts as opposed to
  about 4000
• Ongoing work with kernel driver will relocate
  PEB/SEH, thus addressing this weakness
• Multi-layered approach is important
• Layer 2 was able to defeat the attack even though
  the attack got through layer 1.

37
Tech Transition

• Looking at Service IA entrance points, e.g.,
• CECOM/CERDEC (STCD)
• Navy (NMCI)
• Air Force
• Initial ideas for commercial sales support
• Commercial partner
• Spin-off
• Other (GOTS)?

38
Further Development

• Issues
• Fixed PEB/TEB base location
• Exception handler location
• Initial process heap/CRT heap base randomization
• Some things not exhaustively covered
• Process/thread creation, memory allocation
• Undocumented Native API
• Occasional communication error with Win32
  subsystem
• Inadequate monitoring and control
• Solutions
• Kernel mode driver
• Expanded vulnerabilities and attacks for Layer 2
  testing
• Control and alerting interfaces
• Enterprise capabilities and productization needed

39
Thank You

• Questions?

40
Backup Slides
41
Analytic Update
42
Address Space Randomization (ASR)

• Absolute address randomization
• Randomize absolute address of an object
• Distances between objects may not be randomized
• Relative address randomization
• Randomize distances between objects, even those
  within the same segment

43
Attacks on DAWSON

• Exploit phase
• Defeating randomization
• Payload execution phase
• Difficulty of successfully executing system
  functions needed to carry out the attack
• Comes into play if and when DAWSON exploit
  protection is defeated

44
Probability of Successful Attacks

• Pr(A) Pr(V)/EE(A) PEE(A)
• Success probability of attack A exploiting
  vulnerability V
• EE exploit effort
• Given by range of randomization of addresses
  involved in A
• PEE payload execution effort
• Attempts to successfully execute attack payload
• Multiplicative effect
• requires rerandomization after every failed
  attack
• does not apply if attack defeats the same
  randomization in both layers

45
Layer 2 Threat Model

• Injected code has begun execution
• Attack needs to invoke system APIs to deliver its
  payload
• No direct invocation of system calls
• Supposed to be protected by layer 3 (not
  implemented for DAWSON)
• Existing code attacks
• Still requires breaking layer 1 defense to get to
  exploitable code within application
• We estimate PEE(V) for other types of attacks

46
Data Attacks
47
PE(V) for conventional attacks

• Stack-smashing
• modify return address to point to injected code
  on stack
• Range of possible code addresses is 1GB
• Can improve success using NOP padding
• With 1KB padding, PE(V) 10-6
• Heap overflow
• Relies on knowing absolute addresses
• If target pointer is in static data area,PE(V)
  1GB/64KB 15K
• This estimate applies to many other attack types
  return-to-libc, format-string,

48
Attacks on DAWSON Randomization

• Exploit weaknesses in randomization
• Attacks that can extract randomization key
• information leakage attacks
• Partial overflow attacks
• Overflow only the least significant byte of
  address
• Double pointer attacks
• Rely only on finding a writable address in memory
• All require a combination of vulnerabilities
• Low likelihood of finding them
• Derandomization (brute-force) attacks
• Analyzed work factor in the next slides.
• Liang et al 05 approach promises to block
  these
• Automatically learn signatures of memory error
  exploits and discard subsequent instances of them
• Shown to be very effective on recent attacks on
  Linux

49
Exception Handler Protection The Numbers

• Program address space is 2Gb
• Assume a program size of 200 Mb
• Dummy padding with alert functions and
  fail-crash code size is 1.8 Gb
• Attacker has a 1 in 500 Million chance of
  getting the right DLL address 90 chance of
  tripping an alarm per try.

50
DAWSON Summary

• Approach Introduce synthetic diversity in
  Windows executables at run-time to defeat memory
  errors
• Non-bypassable defense-in-depth breaks exploits,
  payloads
• Transforms absolute addresses, DLL names,
  parameter orders, key data structures, etc
• Pseudo-random numbers produce unique
  transformations on each restart of application
• Source code access enables relative address
  randomization
• Metrics Implementation beats program metric by
  1000x for large fraction of exploit space
• 10,000 functional equivalents with less than 3
  susceptible to same exploit as baseline code for
  non-data attacks
• Low overhead transforms (lt5 runtime performance)

51
Attack Descriptions
52
Composite Results
53
DAWSON Testing Notes

• December 1, 2005

54
Manual Tests3 Node Red Team Testbed
Composite result of 44 manual and 250
semi-automated test runs on fully randomized
system. 65 manual runs on unprotected baseline
system Test run is 15 attacks, one against 15 new
process instances
55
Testing Scale
56
Testing

• Testing in the small
• Fewer test cases, but closer observation
• Much system state available can stop and run
  debugger to observe even closer.
• When interesting phenomena occur can stop and
  drill down into system state with debuggers, etc.
• Testing in the large
• Flexible network based testing on Emulab
• Test defenses on larger networks up to 100 nodes.
• Automate a suite of tests
• Provide feedback to developers
• Provide examples on networks of non-trivial size.
• Observe phenomena scale
• Test on larger networks of up to 100 hosts
• Use parallelism for more test cases over time

57
What is Emulab

• Project at Univ of UTAH (Jay Lepreau)
• Shared network testbed of over 300 hosts
• Dynamically imaged and configured for each
  experiment
• Web-interface to remote users
• Common resource for researchers
• Progenitor of numerous other testbeds

58
What we have done

• Automated Installation Configuration of Emulab
  Images for DAWSON
• Packaged a corpus of attacks in Metasploit
• Added instrumentation to detect marker file
  dropped by attacker
• Automate attacks on variety of defense
  configurations to probe effectiveness of
  individual randomizations.
• Sample test runs
• 15 attacks x 6 defensive configurations 90
  trials
• Target population of 10 nodes
• Empirical validation of expectations

59
Examples

• DAWSON Wiki
• Main Page
• Overview
• Recent script generated results
• Quick Demo
• RDT
• Show log files
• Show summary chart

60
Red Team Meeting

• Notes on Nov 7 Meeting with Red Team
• Attack Ideas
• Does vulnSrv2 have way to send data out a port?
• Potentially speed up probing
• Trigger reversion to old DLLs
• Restore original DLLs convince system these are
  already randomized
• Some critical data structures not randomized
• Direct system calls interrupts/svcs

61
Baseline Effectiviness
62
Catalyst Experiment Monitor
December 6, 2005 KMD1111ConflResolv1201 Called
at approx 223 pm
63
Abstract View of Attacks
Characterize successful attacks as program inputs
e that transition from good states to evil states.
Programs acting on good inputs.
Pg in good states stay in good states. Represents
desired behavior.s wp(Pg,G)ltG Pe describes
flaws where certain inputs allow
compromise Gltwp(Pe,E)
Pg
good states Not compromised.
G
Pe
evil states Attacker compromised system
Program acting on evil inputs.
E
evil states Attacker succeeds
Until we create more nearly perfect programs,
flaws in realization of P will continue to
exhibit Pe cases
S
64
Idealized Effect of Randomizing Transformations
Pg
Pg
Pe
Vulnerability to e randomly remapped to an
unknown f
Pf
G
G
Pf
Pe
E
E
S
S
Randomizing Transform

• f-attack analogs to old e-attack, where
  wp(Pf,G)ltE will appear, but
• f is hard to find for a specific host
• fs are diverse over the host population

After the Transformation Nearly all good inputs
in good states still work wp(Pg,G)ltG Previous
ly successful attacks no longer work
wp(Pe,G)ltG
65
Attack String Construction Phase I
Address to write 1st byte of JMP ESP instr

• my evil pack ('V', "writeAddr")
• evil . "\x41\x41\x41\x41"
• evil . pack ('V',writeAddr1)
• evil . "496c"
• evil . pack ('V',writeAddr)
• evil . "\x90\x90\x90\x90
• \x83\xc4\x7f
• \x83\xc4\x7f
• \x83\xc4\x7f
• \x83\xc4\x5f
• \xff\xe4
• 229chn229chn
• \x83\xec\x7f
• \x83\xec\x7f
• \x83\xec\x7f
• \x83\xec\x5f"
• evil . shellcode

Padding
Address to write 2nd byte of JMP ESP instr
Offset sprintf destination to the return address
on stack
Short NOP sled
Point ESP to a clean copy of attack String and
jmp into it
add esp,7fh (3 times) add esp, 5fh
jmp esp
Format string escapes to write the writeAddr
into the return address.
Entry point of our JMP ESP Fixes up ESP register
to prior value
Falls through into Metasploit shell code for DLL
injection.
66
An Alternative Attack Phase I
DWORD WINAPI FormatStrThread(LPVOID lparameter
char safebuf4096 nRetrecv(peersock,safeBu
f,sizeof(safeBuf),0) formatStrAttack(safeBuf,n
Ret)
MDVULN.dll vulnerable service code
char4096 safeBuf
formatStrThread
void formatStrAttack(char sbuffer, int nSize)
char buf512 char bufmain512
sprintf(buf, String s,sBuffer) // (1)
sprintf(bufmain,buf) //
(2)
// (4)

• First Sprintf overflows buffer putting a magic
  address MA into the return address slot.
• Second sprintf interprets the format string
  poking a JMP ESP instruction into memory at the
  magic address
• ESP is manipulated to point to start of shell
  code inside the stack frame.
• Normal return now branches to MA where it
  executes the JMP ESP

Old ESP
0x7ffdxxxx
return
MA
char512 buff
JMP ESP
formatStrAttack
char512 bufmain
A writeable/executable page in memory
67
Problem Space

• Excessive Homogeneity gtSystemic Vulnerability
• How prevent exponentially cascading failures?
• Attacks exploit dense environment with ease to
  spread fast and/or far
• Foreseeable cyber-risks dominated by static,
  durable monoculture of executables

• Common Mode Failures gt No Intrusion Tolerance
• Intrusion tolerant systems depend on redundant
  components
• Assumption of independent intrusions/faults is
  flawed
• Limited availability of diverse, functionally
  equivalent software
• Rapid learning of attack signatures for blocking
  is not easy

68
Attack Space of Interest
Effects of Memory Errors in Exploits
Broken by absolute address randomization
Memory Error Exploits

• All known and anticipated memory error exploits
  based on overwriting pointer values to attacker
  data/code
• Stack-smashing, heap overflow
• Return-to-libc, format-string, integer overflows,
  

• Most common source of attacks
• 75 of recent advisories from US-CERT are spatial
  memory errors
• The mechanism of choice for worms and other
  large-scale attacks
• Temporal error and uninitialized pointer attacks
  have not been seen in wild

• Memory error pointer expression accessing
  unintended object
• Two basic types spatial and temporal
• Spatial error
• - Out-of-bounds access
• - Corrupted or uninitialized pointer
• access
• Temporal error
• - Dangling pointer access
• - Significant for stack-allocated and heap
• allocated objects
• Not covered

• Control Flow Hijack v. Data Attacks
• Control-flow hijacks corrupt code pointers so
  they point to injected code or existing code
• Data attacks corrupt pointers to data and targets
  of existing pointers

Requires Relative Address Randomization
Vulnerable pointer attacker-provided data is
copied into the target of pointer w/o appropriate
security checks
69
ASR Implementation Approaches (Layer 1)

• Binary-only
• Randomize absolute address of DLLs, heap, stack
• Binary, with very minimal help from compiler
• Compiler/Vendor help needed to randomize absolute
  address of executables
• No help needed to randomize DLLs, stack or heap
• Linux PaX ASLR uses this approach w/ OS
  modifications, Bhatkar et al 03 w/o OS changes
• Windows DAWSON uses this approach, w/o OS
  changes
• Extended compiler support
• Enable relative address randomization, plus
  changes to dynamic memory allocators to defeat
  all memory errors
• Linux Bhatkar et al, USENIX Security 05
• Windows explore in DAWSON with Phoenix/Vulcan
  compilers

70
DAWSONDLL Rebase Design Considerations

• DAWSON DLL Rebase
• Benefits vs Costs
• Functionality vs Flexibility
• DLL Base randomization
• Rebase and Share
• Rebase on Demand
• Rebase on Request
• Local Configuration
• Interface with Blackboard

71
PEB/SEH Protection Exception Handlers

• Monitoring for exceptions are done
• From another process
• Using Win32 DEBUG API
• within the same process
• Using Vectored Exception Handling
• Monitor needs to receive exception events before
  the attacker

72
Four ways to monitor exceptions
73
Red Team Exploit Analysis

• Phase I of the attack is insensitive to DLL
  positions or stack locations. (see 6 7)
• It only needs a location to which it can write a
  JMP ESP instruction.
• It typically finds such a location inside a page
  where the PEB (Process Environment Block) resides
  by default.
• Though marked READ_ONLY in SP1 an exception
  handler in the kernel implements Copy-on-write
  semantics for the first write to this page.
• The fixed address 0xffdc082 is near the PEB but
  not inside of it. Writing to it does not
  typically corrupt the PEB/TEB structures.
• In later testing, it appears that the Red Team
  attack either always succeeds or always fails for
  a particular boot.
• Even in the failures, Phase I of the attack
  appears to work, i.e. the DLL injection callback
  gains control and does execute.
• Attack fails by not successfully writing a marker
  file on the target host.

74
Vulnerable Server

• VulnSrv2.exe
• A program run as a command line console
  application.
• VulnSrv2 loads MdVuln2.dll and listen to the
  specified port for certain vulnerability.
• Each vulnerability on a different port
• Uses multi-threaded server architecture
• One thread for each vulnerability

75
Small Scale Tests
Trials Infected Blocked Blocked Unblocked
Corpus of 15 baseline Attacks (Metasploit)
No Randomization 65 trials
All Randomizations 11/15 Release (Red Team) 294
trials
All Randomizations 12/01 Release 355 trials
76
Further Development

• Expects
• Fixed PEB/TEB base location
• Exception handler location
• Initial process heap/CRT heap base randomization
• Some things not exhaustively covered
• Process/thread creation, memory allocation
• Undocumented Native API
• Occasional communication error with Win32
  subsystem
• Remote monitoring and management
• Solutions
• Kernel mode driver
• Expanded vulnerabilities and attacks for Layer 2
  testing
• Control and alerting interfaces
• Enterprise version capabilities (Army CECOM?)