Chapter 6
Weaknesses Exploited
Weaknesses
 Bad
software is everywhere, and…
 …flaws can cause security problems
 In this chapter
o Various overflow conditions
o Format string vulnerabilities
o How weaknesses are found
o Defenses
o Human factors
Technical Weaknesses
 Buffer
overflow
 Process address space: 4 sections
1. Fixed-sized code block (code/text)
2. Static data (data)
3. Dynamic data (heap)
4. “Scratch paper” (stack)
Technical Weaknesses
C
program example
Stack Frame
 Stack
frame allocated for functions
 Stack holds…
o Local variables
o Book keeping info, such as
 Input arguments
 Return address
 Saved frame pointer, etc.
Stack Frame
 Stack
frame
in action
Memory Organization

Text == code
text

Data == static variables
data

Heap == dynamic data

Stack == “scratch paper”
heap

o Dynamic local variables
o Parameters to functions
o Return address

stack
 low
address
 SP
 high
address
Simplified Stack Example
low 
:
:
void func(int a, int b){
char buffer[10];
}
void main(){
func(1, 2);
}
buffer
ret
a
high 
b
 SP
 return
SP
address
 SP
 SP
Smashing the Stack
low 
 What
happens if
buffer overflows?
:
??? :
 Program
“returns”
to wrong location
A
buffer
crash is likely
overflow
ret
overflow
a
high 
b
 SP
ret… NOT!
 SP
 SP
 SP
Smashing the Stack
 Trudy
has a
better idea…
low 
:
:
 Code
injection
 Trudy can run
code of her
choosing…
o On your machine!
evil code
high 
 SP
ret
ret
 SP
a
b
 SP
 SP
Smashing the Stack

Trudy may not know…
1) Address of evil code
2) Location of ret on stack

Solutions
1) Precede evil code with
NOP “landing pad”
2) Insert ret many times
:
:
NOP
:
NOP
evil code
ret
ret
:
ret
:
:
 ret
Stack Smashing
 Note
that injected code is usually
known as “shellcode”
 Other overflow attacks are possible
o Some inject code, some don’t
o We discuss a few more examples later
Stack Smashing Summary
A buffer overflow must exist in the code
 Not all buffer overflows are exploitable

o Things must align just right
If exploitable, attacker can inject code
 Trial and error is likely required

o Fear not, lots of help available online
o Smashing the Stack for Fun and Profit, Aleph One

Stack smashing is “attack of the decade”
o Regardless of the decade…

Also heap overflow, integer overflow, etc.
Stack Smashing Example
Program asks for a serial number that the
attacker does not know
 Attacker does not have source code
 Attacker does have the executable (exe)


Program quits on incorrect serial number
Example

By trial and error, attacker discovers
apparent buffer overflow
Note that 0x41 is “A”
 Looks like ret overwritten by 2 bytes!

Example
 Next,
 The
disassemble bo.exe to find
goal is to exploit buffer overflow
to jump to address 0x401034
Example

Find that, in ASCII, 0x401034 is “@^P4”
Byte order is reversed? Why?
 X86 processors are “little-endian”

Example

Reverse the byte order to “4^P@” and…
Success! We’ve bypassed serial number
check by exploiting a buffer overflow
 What just happened?

o We overwrote the return address on the stack
Example
 Note
that in this example…
 We overwrote return address and
jumped to somewhere interesting
 We did not inject any code
 Other interesting places to jump to?
o Without injecting code, that is?
o Often called “return to libc” attacks
Example
 Attacker
did not require access to the
source code
 Only tool used was a disassembler to
determine address to jump to
 Possible to find desired address by trial
and error?
o Necessary if attacker does not have exe
o For example, a remote attack
Example
 Source
 Flaw
code of the buffer overflow
easily
found by
attacker
 Without the
source code!
Stack Smashing Prevention

1st choice: employ non-executable stack
o “No execute” NX bit (if available)
o Seems like the logical thing to do, but some real
code executes on the stack (Java, for example)

2nd choice: use safe languages (Java, C#)

3rd choice: use safer C functions
o For unsafe functions, there are safer versions
o For example, strncpy instead of strcpy
Stack Smashing Prevention
low 
:
:
 Canary
o Run-time stack check
o Push canary onto stack
o Canary value:
buffer
overflow
canary
 Constant 0x000aff0d
 Or may depends on ret
overflow
ret
a
high 
b

Microsoft’s Canary


Microsoft added buffer security check
feature to C++ with /GS compiler flag
Based on canary (or “security cookie”)
Q: What to do when canary dies?
A: Check for user-supplied “handler”

Handler shown to be subject to attack
o Claims that attacker can specify handler code
o If so, formerly “safe” buffer overflows become
exploitable when /GS is used!
ASLR

Address Space Layout Randomization
o Randomize place where code loaded in memory


Makes most buffer overflow attacks
probabilistic
Vista uses 256 random layouts
o So about 1/256 chance buffer overflow works?

Similar thing in Mac and other OSs

Attacks against Microsoft’s ASLR do exist
o Possible to “de-randomize”
Buffer Overflow
A major threat yesterday, today, and
tomorrow
 Can greatly reduced overflow attacks

o Use safe languages/safer functions
o Educate developers, use tools, etc.

Buffer overflows will exist for a long time
o Legacy code
o Bad software development practices
Race Condition

Security processes should be atomic
o Occur “all at once”


Race conditions can arise when securitycritical process occurs in stages
Attacker makes change between stages
o Often, between stage that gives authorization,
but before stage that transfers ownership

Example: prepaid debit card
Race Condition
 Adding
cash to card
1. User inserts card into card reader
machine
2. Machine reads value of card: x
3. User insert cash into machine: y
4. User presses “enter” key
5. Machine writes x+y to card
6. Machine ejects card
 Race
condition?
Race Condition
 Attacks
on cash card protocol?
 Insert 2 cards, sandwiched together
 Card that is read has $100 value,
unread card has $1 value
o Step 2: Machine reads x = 100
 Insert
$2, so y = 2
 Pull out read card, leaving unread one
 Press “enter”…
Race Conditions

Race conditions appear to be common in
software
o May be more common than buffer overflows

But race conditions harder to exploit
o Buffer overflow is “low hanging fruit” today

To prevent race conditions…
o Make security-critical processes atomic
o Occur all at once, not in stages

Not so easy to accomplish in practice
Heap Overflow
 Heap
used for dynamic variables
o For example, malloc in C
 Can
overflow one array into another
 Makes it possible to change data
o Like example on next slide
Simple Buffer Overflow
Consider boolean flag for authentication
 Buffer overflow could overwrite flag
allowing anyone to authenticate!

Boolean flag
buffer
F OU R S C

…
T
F
In some cases, Trudy can be more
systematic
Heap Overflow Example

BEFORE:
o buf2 = 22222222

AFTER:
o buf2 = 11122222
Heap Overflow
 Bookkeeping
info stored on heap
 Can attacker exploit this?
Heap Overflow
 Data
structure to keep track of free
memory
o Assume it is a doubly-linked list
 Heap
overflow attacks?
Heap Overflow
 Here
we
free block B
 “Unlink” B
from heap
 If overflow
in A, can
overwrite B’s
pointers…
Heap Overflow
 Overwrite
B’s pointers
 Then free B
 Now if we ever get to
B, will go to shellcode
Integer Overflow
 Many
“integer”
problems
 This example…
o What if len is
negative?
o Note that
memcpy thinks
len is unsigned
Format String Vulnerabilities
 Format
string example
printf(“The magic number is %d\n”, 42);
 Format
strings:
Parameter
Meaning
Passed by…
%d
int
value
%u
unsigned int
value
%x
hex
value
%s
string
reference
%n
bytes written so far reference
Format Strings and the Stack
 Formatting
functions retrieve
parameters from the stack
o Assuming that’s where they’re stored…
 Consider
printf(“a has value %d at address %d\n”, a, &a);
 What
if there are too few arguments?
 For example
printf(“a has value %d at address %d\n”);
Format Strings and the Stack
 Consider
again
printf(“a has value %d at
address %d\n”, a, &a);
 Here, x1 and x2 are
other things on the
stack
low 
:
:
“a has … \n”
a
address of a
x1
x2
high 
Format Strings and the Stack
 What
if there are
too few arguments?
 For example
printf(“a has value %d
at address %d\n”);
 What happens?
 Print
stuff on stack
 Is this useful?
low 
:
:
“a has … \n”
x1
high 
x2
x3
x4
Format String Issue 1
 We
can “walk” the stack
 That is, print out items on the stack
 For example
printf(“%08x %08x %08x %08x %08x\n”);
 As a bonus, it’s nicely formatted…
Format String Issue 2
 What
would this do?
printf(“%s%s%s%s%s%s%s%s%s%s%s”);
 For each %s function printf will…
o Fetch a number from the stack
o Treat the number as an address
o Print out whatever is at that address,
until NULL character
 Such
an “address” might not exist!
Format String Example
 What
about something like this…
void print_error(char *s){
char buffer[100];
snprintf(buffer, sizeof(buffer), “Error: %s”, s);
printf(buffer);}
 Suppose
Trudy has control over what
goes into the string s
 Then some interesting possibilities…

1st %d 
2nd %d 
:
:
%s 
return
“Error: %s…”
:
:
1234567
%d
high 
printf
Suppose Trudy sets
string s to
\x78\x56\x34\x12 %d%d%d%s
 Note \x78…\x12 is little
endian for 1234567
 What does code on
previous slide do?
low 
%d
:
:
:
:
buffer
Format String
Issue 3
Format String Issue 4
 The
%n format is used to print the
number of characters written so far
 Q: What does this do?
int i;
printf(“abcde%n, &i);
 A:
Writes 5 to variable i
 Can Trudy take advantage of this?
Format String Issue 4
 Similar
attack as “issue 3”…
 …except use %n in place of %s
 Then a value written to address
1234567
o What value?
 Some
claim that this allows writing of
arbitrary value
o Is this really true?
Format String Defenses
 Source
code auditing
o Relatively few format strings
 Remove
support for %n format
o Would this create any problems?
 Keep
track of number of arguments
 General buffer overflow prevention
o For example, ASLR (next slide…)
More Defenses
 Mentioned
by author
o NX approach
o Canary
o ASLR
o Safe/safer languages
Finding Weaknesses
 How
do attackers find weaknesses?
 Technical analysis
o Study source code (if available)
o Disassemble executables (SRE)
o Decompile (good luck with that!)
o Black box analysis
o Study vendor patches
o Full disclosure websites
 Zero
day exploit?
Finding Weaknesses
 Social
engineering
o Nuclear power plant company example
 Impersonation
 Dumpster
diving
 Shoulder surfing
 Fake email
o For example, ask for passwords
 Phishing
Virus Hoaxes
 Example:
jdbgmgr.exe
I found the little bear in my machine because of
that I am sending this message in order for you to
find it in your machine. The procedure is very
simple: …
 Known
as the teddy bear virus
because this is the icon:
Exploitation Engines
 Developing
a buffer overflow attack
o Tedious, lots of trial and error
o Until Metasploit was invented…
 Metasploit
o Knows about lots of attacks
o Has lots of payloads
o Doesn’t require much thought/effort
Metasploit
 Payloads
o
o
o
o
o
o
o
o
include
Bind shell to current port
Bind shell to arbitrary port
Reverse shell
Windows VNC Server DLL inject
Reverse VNC DLL inject
Inject DLL into running application
Create local admin user
The Meterpreter (run command of
attacker’s choosing)
Metasploit Web Interface
Metasploit
 Advantages
for attackers?
o Reduces “development cycle”
o Resulting attacks much more reliable
 Advantages
for good guys?
o Helps identify false positives
o Help improve IDS
o Improved penetration testing
o Improved management awareness