Post on 28-Dec-2015
Approved for Public Release, Distribution Unlimited
Diversity Algorithms for Worrisome Software and Networks
(DAWSON)
James Just, GITI
Karl Levitt & Jeff Rowe, UC Davis
20 July 2004 2Approved for Public Release, Distribution Unlimited
The DAWSON Team
• Global InfoTek, Inc (GITI)– James Just , Bruce Wilner, Mark Cornwell
• UC Davis– Karl Levitt, Hao Chen, Zhendong Su, Jeff
Rowe– Ivan Balepin, Allen Ting, Ebrima Ceesay,
Tufan Demir
• R. Sekar (consultant, SUNY)
20 July 2004 3Approved for Public Release, Distribution Unlimited
The Problem Space• Increasing monoculture in operating systems and key
applications create opportunity for massive common mode failures– Highly susceptible to viruses and worms – Spread widely and quickly (or slowly)
• Intrusion tolerant systems difficult to build– Expensive, large hw/sw footprints, a priori knowledge of
attack modalities– Need significant diversity of spares -- even if intrusion
tolerance is affordable approach, practical limits exist on diversity of spares
• N-version programming is costly• Limited commercial diversity of similar apps
• Foreseeable cyber-risks dominated by static, durable executable monoculture
20 July 2004 4Approved for Public Release, Distribution Unlimited
Synthetic Diversity Approaches• Source code:
– Easiest area to introduce diversity via compilers
– Complicates distribution and updating
– Significant market penetration problems with software vendors
• Binary (executable) code:– More difficult to introduce diversity
• Disassembly is not exact science
• Runtime and randomized modification is harder still
– Can be implemented by organizations and users who need the benefits
• Binary code with annotations (hints)
20 July 2004 5Approved for Public Release, Distribution Unlimited
DAWSON Approach• Runtime randomized transformations of executable
– Preserve functionality of executable modules (e.g., dll)– Transform binary code, machine addresses, names, etc– Can use annotations to facilitate– Random “cryptographic” keys will cause unique
transformations on each application restart– Similar approach for network protocols
• Low overhead transforms (runtime performance)• Goal: Beat program metric by 10X for large fraction
of exploit space– 100 functional equivalents with no more than 3 susceptible
to same exploit as baseline code for most exploits• Policies can determine which type of transform is
favored
20 July 2004 6Approved for Public Release, Distribution Unlimited
Evaluation
• Internal testing with– Fabricated applications with known vulnerabilities
and exploits– Real applications with known vulnerabilities and
exploits
• Independent test team?
20 July 2004 7Approved for Public Release, Distribution Unlimited
Impacts• Introducing spatial and temporal diversity to common
Windows applications will reduce the effective size of world’s largest computer monoculture– Size and breadth of transform space vs vulnerability space– Extent of penetration– Counter-measures
• Fine-grained diversity mechanisms are key enabler for intrusion tolerance– Fourth generation, secure, survivable systems – Easily integrated with other SRS components.
20 July 2004 8Approved for Public Release, Distribution Unlimited
Transition and Future Work
• Standard research publications
• Integrate with follow-on projects/products
• If successful– Possible GITI commercial product– Possible open source “toolkit” approach– Microsoft or other software vendors– Military users
• More definitive plans as project develops
20 July 2004 9Approved for Public Release, Distribution Unlimited
Software: Concept to
Implementation
SoftwareSpecification
SourceCode
ExecutableCode
Machine-levelCode
LinkerLoader
Machine CodeSpecification
20 July 2004 10Approved for Public Release, Distribution Unlimited
Illustrative Common Techniques & AssumptionsSegment of Code Red 1 Disassembly1
01 loc_4B4: ; CODE XREF: DO_RVA+26Dj02 mov esi, esp03 mov ecx, [ebp-198h]; set ecx with the data segment pointer04 push ecx; push data segment (pointer of function to load)05 mov edx, [ebp-1CCh]; get current RVA base offset06 push edx; push module handle(base loaded address)07 call dword ptr [ebp-190h]; call GetProcAddress
1 Excerpted from Code Red Disassembly Analysis by Ryan Permeh, Marc Maiffret. http://www.eeye.com/html/advisories/codered.zip.
1. Relative Virtual Addressing is Windows name for identifying specific memory addresses in executable files without hardcoding (offset to virtual memory load location).
2. This calls dll’s specific API (GetProcAddress) via IAT. GetProcAddress is one of two key functions for the exploit. LoadLibraryA (not shown) is the other.
3. After this, GetProcAddress and LoadLibraryA are used to load kernel32.DLL, infocomm.DLL and WS2_32.DLLto access the file system, open network sockets and send and receive network packets.
20 July 2004 11Approved for Public Release, Distribution Unlimited
Many Assumptions Made
• Breaking the assumptions mechanically– Re-arrange the run-time stack– Permute the addresses in the jump table– Change the machine code (table transformation)– Change the interpretation of (encrypt) filenames– Change the order of parameters for system calls– Encrypt file name parameters to system calls– Rename ports for network connections– Put return pointers on a separate stack
20 July 2004 12Approved for Public Release, Distribution Unlimited
Current Attack
Problem
SoftwareSpecification
SourceCode
ExecutableCode
Machine-levelCode
LinkerLoader
KnownV-Spec
Attack
Machine CodeSpecification
Vulnerability
20 July 2004 13Approved for Public Release, Distribution Unlimited
Machine-levelCode
Machine-levelCode
Machine-levelCode
Machine-levelCode
Machine-levelCode
Machine-levelCodeMachine-level
Code
Machine-levelCodeMachine-level
Code
Machine-levelCodeMachine-level
Code
Machine-levelCode
Machine-levelCode
SoftwareSpecification
SourceCode
ExecutableCode
Machine-levelCode
TransformerLinkerLoader
KnownV-Spec
Attack X
V-Spec Unknown Until Load-Time
Doesn’tMatch
Breaking the V-Spec
Vulnerability??
Machine CodeSpecification
TransformSpecifications
20 July 2004 14Approved for Public Release, Distribution Unlimited
Transform Techniques in Literature*• Obfuscation
– Layout obfuscation (scramble identifiers, remove comments, change formats)– Control flow obfuscations (Statement grouping, ordering, computation, opaque constructs)– Data obfuscation (Storage, encoding, grouping, ordering)– Preventative transformations (prevent decompilers from operating by exploiting weaknesses)
• Inherent (aliases, variable or bogus dependencies, opaqueness side effect & difficulty)• Targeted
• Source code– N-version programming– Functional-behavior preserving diversity in components used (e.g., different encryption
algorithms, different scales for data such as Celsius or Fahrenheit)– Semantics preserving source code transformations
• Place sensitive data (such as function and data pointer) below the starting address of any buffer• Variable ordering• Equivalent instructions
– Variable compilation --Variable internal names, padding and addresses, linking orders– Insertion of opaque constructs or other dead code to change memory layout
• Binary code– Address transformation on binary code
• Randomize base address of memory regions (Stack, Heap, DLL, routines/static data in executable)• Permute order of variable/routines (Local variables in stack frame, static variables, routines in shared
libraries or routines in executables)• Introduce random gaps between objects (Padding in stack frames, between successive malloc allocation
requests, between variables in the static area; Gaps within routines and add jump instructions to skip over gaps)
– System resource, system call, or DLL name/address transformation– Instruction set transformation
*References at end of document
20 July 2004 15Approved for Public Release, Distribution Unlimited
Effectiveness of Transforms
Vulnerability Class Sample Vulnerabilities in Class N
-ver
sion
Pro
gram
min
g
Beh
avio
r T
rans
form
s (So
urce
Cod
e)
Inte
rnal
Dat
a Fl
ow T
rans
form
s (S
ourc
e C
ode)
Inte
rnal
Con
trol
Flo
w T
rans
form
s (So
urce
Cod
e)
Plac
e Se
nsiti
ve D
ata
Bel
ow B
uffe
rs (S
ourc
e C
ode)
Enc
rypt
Exe
cuta
ble
Obf
usca
te E
xecu
tabl
e C
ode
Tra
nsfo
rm R
elat
ive
Add
ress
es (E
xecu
tabl
e)
Tra
nsfo
rm A
bsol
ute
Add
ress
es (E
xecu
tabl
e)
Tra
nsfo
rm S
yste
m R
esou
rces
(Exe
cuta
ble)
Tra
nsfo
rm (V
irtu
al) H
ost I
nstr
uctio
n Se
t
Tra
nsfo
rm P
roto
cols
Sta
te S
pace
(Sou
rce)
Tra
nsfo
rm E
xecu
tabl
e Pr
otoc
ols v
ia P
roxi
es
Enc
rypt
Net
wor
k/In
terf
ace
Prot
ocol
s
Improper Validation
Memory errorCode injection attacks (stack, heap, and integer overflows) + + + + + < [1] ++ ++ ++ ++
Existing code exploits (printf) + + + + < [1] ++ ++ ++ ++
Code injection attacks (SQL injection, cross site scripting) + + ++
Improper exception handling + + + Protocol errors (IP session hijacking, Unicode attacks, ARP cache poisoning) + + + +
+
Race condition + + + +Address or data leakage + + + + + +Social engineering, dumpster diving
Weak passwords
Weakly encrypted passwords +
Memory leakage +
Resource exhaustion + + +
Key: Effectiveness in preventing attack: ++ = highly effective, + = effective, · = negligable, < = potentially counterproductive
Improper Deallocation
System misconfiguration, e.g., default passwords and accounts
Improper Validation
Improper Exposure
Inadequate Randomness
Memory error
Design errors
Diversity is not a panacea for achieving cyber-security. There are many other ways to penetrate a system
20 July 2004 16Approved for Public Release, Distribution Unlimited
Transformer
Original Program
Analyzer
PolicyKey
Generator
Key Transformed
Code
Wrapper
Loader
Annotation
Input
Input
MonitorExecutio
nSpace
Execution
Space
Diversity System Architecture Overview
20 July 2004 17Approved for Public Release, Distribution Unlimited
Diversity System Functional Architecture
Original Program
Modified Loader
RandomKey
Untranslation
Wrapper
User Inputs
OtherSystem
Resources
Attacker
Transformed In-memory
program
Some attacks fail because
assumed vulnerability
is gone
Other attacks fail because
injected commands are wrong
Response to normal user inputs are
translated & untranslated so they work
Modified loader transforms original stored program and generates wrapper that retranslates
external calls
AnnotationFile
20 July 2004 18Approved for Public Release, Distribution Unlimited
Baseline Tasks
1. Requirement Refinement
2. Program. Code Diversity
3. Protocol Diversity
4. Integration
5. T&E
6. Program Mgt.
Prototype
Optional Task- Self-Monitoring
FY04 FY05 FY06
Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4Q2
1 2 3
DAWSON Project Schedule & Milestones
Approved for Public Release, Distribution Unlimited
Creating heterogeneous environments for malicious code
Karl Levitt, Hao Chen, Zhendong Su, Jeff Rowe, Ivan Balepin, Allen Ting, Ebrima Ceesay, Tufan Demir
UC Davis Computer Security Lab
20 July 2004 20Approved for Public Release, Distribution Unlimited
Why do we want heterogeneity?
• Homogeneity is a natural requirement– As for software: development, distribution,
maintenance, data sharing, etc.– Fixed protocols for communications and
interoperability
• The real challenge is in achieving both– Create a heterogeneous vulnerability environment– Keep all the benefits of homogeneity.
20 July 2004 21Approved for Public Release, Distribution Unlimited
Host level Heterogeneity• Microsoft Windows
– Most prevalent platform
– Many security flaws
• Defense against Scripted Attacks– Windows forms a wide homogeneous environment for
large scale attacks.
– Single attack implementation compromises all machines with the vulnerable service.
– Buffer overflow is the most common vulnerability in widespread attacks.
20 July 2004 22Approved for Public Release, Distribution Unlimited
Windows Execution Environment
• Windows executables must call API functions for any significant tasks– System calls are not accessible by a user program.
• All API functions are provided in DLLs.– Load address of API functions is not known until
the program loads– Load address of API functions varies from host to
host
20 July 2004 23Approved for Public Release, Distribution Unlimited
How does DLL system work?
Call *010031A0 01001000
00070000
heap
.text
65D6000000000000
77E80000
kernel32.dllstack
20000000
LoadLibraryA()
010031A0
77E9D961
80000000
77E9D961
IAT`LoadLibraryA’
20 July 2004 24Approved for Public Release, Distribution Unlimited
Permute IAT
Call *010031A0 01001000
00070000
heap
.text
65D6000000000000
77E80000
kernel32.dllstack
20000000
LoadLibraryA()
010031A0
77E9D961
80000000
Call *010031A0
0100308C GetProcAddress() 77E90332
77E90332 77E9D961
`LoadLibraryA’
`GetProcAddress’
Call *0100308C
IAT
20 July 2004 25Approved for Public Release, Distribution Unlimited
Case study: Code Red
01001000
00070000
heap
.text
00000000
77E80000
kernel32.dllstack
20000000LoadLibraryA()
`KERNEL32’
Injected code
77E9D961
EAT
`LoadLibraryA’ 77E9D961
20 July 2004 26Approved for Public Release, Distribution Unlimited
Case study: SQL Sapphire
01001000
00070000
heap
.text
00000000
77E80000
kernel32.dllstack
20000000LoadLibraryA()
Injected code
77E9D961
sqlsort.dllIAT
77E9D961
20 July 2004 27Approved for Public Release, Distribution Unlimited
Case study: MS Blaster
01001000
00070000
heap
.text
0000000077E80000
kernel32.dll
stack
20000000
Injected code
77E9D961
PEB
LoadLibraryA()
`LoadLibraryA’77E9D961
EAT
`KERNEL32’ 77E80000
20 July 2004 28Approved for Public Release, Distribution Unlimited
Operand hijacking
Call *0100308C 01001000
00070000
heap
.text
65D6000000000000
77E80000
kernel32.dll
stack20000000
LoadLibraryA() 77E9D961
80000000PEB
Injected code
0100308C
IAT
77E9D961
20 July 2004 29Approved for Public Release, Distribution Unlimited
Heterogeneous Network Protocols
• Many common attacks rely upon security flaws in network protocols.
• Invariant properties of protocols are the foundation of network communications.
• How can network protocols be diversified while still maintaining the critical invariant requirements.
20 July 2004 30Approved for Public Release, Distribution Unlimited
Approach• Use a state-machine specification of protocols to
express the required invariant properties.• Transitions between states, representing protocol
messages, can be modified as long as a path to the subsequent state is maintained.
• Variation in the modifications can create a diverse collection of network protocols whose protocol messages may differ, but with the required invariant properties needed for functionality.
20 July 2004 31Approved for Public Release, Distribution Unlimited
Example: The DHCP Protocol
INIT
IP Prepar
e
ReplyWait Bound
END
Request arrive
Allocate IP Selected Expire
Renew/InfoReq
Reallocate Released
Rejected/Timeout
No Available IP
INITOffer
WaitingSelecting Bound Binding
Release
RequestOffer
ConfirmBind
ConfirmBind Relinquish
T2 Timeout
ReplyTimeOut Bind_Dec/Timeout Renew/InfoReq
DHCP Server FSM
DHCP Client FSM
20 July 2004 32Approved for Public Release, Distribution Unlimited
A DHCP Protocol Variation
INIT
IP Prepare
ReplyWait Bound
END
Request arrive
Allocate IP
Selected Expire
Renew/InfoReq
Reallocate
Released
Rejected/Timeout
No Available IP
S1Snew
INIT Offer Waiting
Selecting Bound Binding Release
Request
Offer Confirm
Bind Confirm
Bind Relinquish
T2 Timeout
ReplyTimeOut Bind_Dec/Timeout Renew/InfoReq
C1
Cnew
•Introduce two new states: S1 and C1.
•Introduce two new transitions: Snew and Cnew.
•Standard DHCP protocol messages take the server and client from the new state to the invariant state preserving protocol functionality.
•Attacks depending upon forged AllocateIP messages will fail since the attacker assumes that server is in the IP_prepare state
20 July 2004 33Approved for Public Release, Distribution Unlimited
Research Topics
• Evaluation of diversity approach for known large-scale attacks.
• Evaluation for hypothesized attacks.• Analyze complexity of diversified system
– How does it affect normal system operations– Does it increase the attacker’s work factor
• Prototypes– Heterogeneous host-based Windows environment– Heterogeneous network environments
20 July 2004 34Approved for Public Release, Distribution Unlimited
Related research• Source code checker
– Flawfinder, ITS4, PScan, Splint, etc.• Compiler techniques
– StackGuard, StackShield• Non-executable stack
– OverflowGuard– SecureStack– Service pack for Windows (will be available in ‘04)
• Run-time protection– Baratloo et. al.
• Code Obfuscation
20 July 2004 35Approved for Public Release, Distribution Unlimited
References• Lee Badger, Larry D'Anna, Doug Kilpatrick, Brian Matt, Andrew Reisse, Tom Van Vleck. “Self-Protecting Mobile Agents Obfuscation Techniques
Evaluation Report,” Network Associates Laboratories, Report #01-036, Nov 30, 2001, updated March 22, 2002.• [Balzer-99] R. Balzer, N. Goldman. Mediating Connectors. Proceedings of the 19th IEEE International Conference on Distributed Computing Systems,
Austin, Texas, May 31-June 4, 1999, IEEE Computer Society Press 73-77• Boaz Barak, Oded Goldreich, Russell Impagaliazzo, Steven Rudich, Amit Sahai, Salil Vadhan, and Ke Yang. “On the (im)possibility of obfuscating
programs.” In J. Kilian, editor, Advances in Cryptology-CRYPTO ‘01, Lecture Notes in Computer Science. Springer-Verlag.• Elena Gabriela Barrantes, David H. Ackley, Stephanie Forrest, Trek S. Palmer, Darko Stefanovic and Dino Dai Zovi, “Randomized instruction set
emulation to disrupt binary code injection attacks,” 10th ACM Conference on Computer and Communications Security, Washington DC, October 27-31, 2003.
• Sandeep Bhatkar, Daniel C. DuVarney, and R. Sekar, “Address Obfuscation: An Efficient Approach to Combat a Broad Range of Memory Error Exploits,” 12th USENIX Security Symposium, August 2003.
• M. Chew, D. Song. “Mitigating Buffer Overflows by Operating System Randomization,” Technical Report CMU-CS-02-197.• C. Collberg, C. Thomborson, and D. Low. “A Taxonomy of Obfuscating Transformations”. Technical Report 148, Department of Computer Science,
University of Auckland, July 1997.• C. Collberg, C. Thomborson, and D. Low. “Manufacturing Cheap, Resilient, and Stealthy Opaque Constructs” Department of Computer Science,
University of Auckland. ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages (POPL'98). January 1998• C. Collberg, C. Thomborson, D. Low. “Breaking Abstractions and Unstructuring Data Structures”, Proceedings of the 1998 International Conference on
Computer Languages, pages 28-38. IEEE Computer Society Press. May 1998.• Larry D’Anna, Brian Matt, Andrew Reisse, Tom Van Vleck, Steve Schwab, Patrick LeBlanc, “Self-Protecting Mobile Agents Obfuscation Report - Final
report,” Network Associates Laboratories, Report #03-015, June 30, 2003• Hiroaki Etoh and Kunikazu Yoda. Protecting from stack smashing attacks. Published on World-WideWeb at URL http://
www.trl.ibm.com/projects/security/ssp/main.html, June 2000.• Stephanie Forrest, Anil Somayaji, and David H. Ackley. “Building diverse computer systems.” In 6th Workshop on Hot Topics in Operating Systems,
pages 67-72, Los Alamitos, CA, 1997. IEEE Computer Society Press.• James E. Just, et al., “Learning Unknown Attacks A Start,” Recent Advances in Intrusion Detection, 5th International Symposium, Zurich, Switzerland,
October 16-18, 2002, Proceedings, A. Wespi, G. Vigner, and L. Deri, (Eds.), Springer, Lecture Notes in Computer Science.• Gaurav S. Kc, Angelos D. Keromytis, Vassilis Prevelakis, “Countering Code-Injection Attacks with Instruction-Set Randomization,” 10th ACM
Conference on Computer and Communications Security, Washington DC, October 27-31, 2003.• Cullen Linn, Saumya Debray, “Obfuscation of Executable Code to Improve Resistance to Static Disassembly,” ACM Conference on Computer and
Communications Security, Washington DC, October 27-31, 2003.• D. L. Lough. A Taxonomy of Computer Attacks with Applications to Wireless Networks. PhD Thesis, Virginia Polytechnic and State University,
Blackburg, VA.• Douglas Low, Java Control Flow Obfuscation, MS Thesis, Univ. Auckland, 3 June 1998• Pax. Published on World-Wide Web at URL http://pageexec.virtualave.net, 2001.• Ryan Permeh, Marc Maiffret, Code Red Disassembly Analysis, eEye Digital Security, http://www.eeye.com/html/advisories/codered.zip.• Chenxi Wang, “A Security Architecture for Survivability Mechanisms.” PhD thesis, University of Virginia, October 2000.• Gregory Wroblewski, “General Method of Program Code Obfuscation,” PhD Dissertation, Wroclaw University of Technology, Institute of Engineering
Cybernetics, 2002.• Jun Xu, Z. Kalbarczyk and R. K. Iyer. Transparent Runtime Randomization for Security. Proc. of 22nd Symposium on Reliable