Software Weaknesses and Exploits

 
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
Data
 
==
 static variables
Heap
 
==
 dynamic data
Stack
 
==
 “scratch paper”
o
Dynamic local variables
o
Parameters to functions
o
Return address
 
stack
 
heap
 
 
 
data
 
text
 
 high
    address
 
 low
    address
 
 
SP
Simplified Stack Example
high 
void func(int a, int b){
 
char buffer[10];
}
 
void main(){
 
func(1, 2);
}
:
:
 
buffer
 
ret
 
a
b
 
 return
     address
low 
 
 
SP
 
 
SP
 
 
SP
 
 
SP
Smashing the Stack
high 
What happens if
buffer overflows?
:
:
 
buffer
 
a
b
 
 
ret…
low 
 
 
SP
 
 
SP
 
 
SP
 
 
SP
 
ret
 
overflow
 
Program “returns”
to wrong location
 
NOT!
 
???
 
A crash is likely
 
overflow
Smashing the Stack
high 
Trudy has a
better idea…
:
:
 
evil code
 
a
b
low 
 
 
SP
 
 
SP
 
 
SP
 
 
SP
 
ret
 
ret
 
Code injection
Trudy can run
code of her
choosing…
o
On your machine!
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
 
evil code
 
:
:
 
:
:
 
ret
 
ret
 
:
 
NOP
 
NOP
 
:
 
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, disassemble 
bo.exe
 to find
 
The 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 code of the buffer overflow
 
Flaw 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
Canary
o
Run-time stack check
o
Push canary onto stack
o
Canary value:
Constant 
0x000aff0d
Or may depends on 
ret
 
high 
:
:
 
buffer
a
b
low 
 
overflow
 
ret
 
canary
 
overflow
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 security-
critical 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!
buffer
 
F
 
T
F
O
U
R
S
C
Boolean flag
 
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:
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, 
x
1
 and 
x
2
 are
other things on the
stack
 
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?
 
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…
Format String
Issue 3
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?
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 include
o
Bind shell to current port
o
Bind shell to arbitrary port
o
Reverse shell
o
Windows VNC Server DLL inject
o
Reverse VNC DLL inject
o
Inject DLL into running application
o
Create local admin user
o
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
Slide Note
Embed
Share

Discover the vulnerabilities present in software such as buffer overflows and format string vulnerabilities, and how these weaknesses can be exploited to cause security issues. Learn about the technical aspects of weaknesses, stack frames, memory organization, and the potential consequences of stack smashing. Explore scenarios where malicious code injection can occur and the solutions to mitigate such risks.

  • Software Weaknesses
  • Security Exploits
  • Buffer Overflows
  • Stack Smashing
  • Code Injection

Uploaded on Sep 07, 2024 | 0 Views


Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

E N D

Presentation Transcript


  1. Chapter 6 Weaknesses Exploited

  2. 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

  3. 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)

  4. Technical Weaknesses C program example

  5. 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.

  6. Stack Frame Stack frame in action

  7. Memory Organization low address text Text == code Data == static variables Heap == dynamic data Stack == scratch paper o Dynamic local variables o Parameters to functions o Return address data heap SP stack high address

  8. Simplified Stack Example low :: void func(int a, int b){ char buffer[10]; } void main(){ func(1, 2); } SP buffer return address SP SP ret a b SP high

  9. Smashing the Stack low What happens if buffer overflows? :: ??? Program returns to wrong location A crash is likely SP buffer ret SP NOT! overflow overflow ret SP a b SP high

  10. Smashing the Stack low Trudy has a better idea Code injection Trudy can run code of her choosing o On your machine! :: SP evil code SP ret ret SP a b SP high

  11. 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 ::

  12. 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

  13. 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.

  14. 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

  15. Example By trial and error, attacker discovers apparent buffer overflow Note that 0x41is A Looks like ret overwritten by 2 bytes!

  16. Example Next, disassemble bo.exe to find The goal is to exploit buffer overflow to jump to address 0x401034

  17. Example Find that, in ASCII, 0x401034is @^P4 Byte order is reversed? Why? X86 processors are little-endian

  18. 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

  19. 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

  20. 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

  21. Example Source code of the buffer overflow Flaw easily found by attacker Without the source code!

  22. 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

  23. Stack Smashing Prevention low :: Canary o Run-time stack check o Push canary onto stack o Canary value: Constant 0x000aff0d Or may depends on ret buffer canary overflow overflow ret a b high

  24. Microsofts 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!

  25. 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

  26. 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

  27. Race Condition Security processes should be atomic o Occur all at once Race conditions can arise when security- critical 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

  28. 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?

  29. 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

  30. 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

  31. 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

  32. Simple Buffer Overflow Consider boolean flag for authentication Buffer overflow could overwrite flag allowing anyone to authenticate! Boolean flag buffer F O U R S C F T In some cases, Trudy can be more systematic

  33. Heap Overflow Example BEFORE: o buf2 = 22222222 AFTER: o buf2 = 11122222

  34. Heap Overflow Bookkeeping info stored on heap Can attacker exploit this?

  35. Heap Overflow Data structure to keep track of free memory o Assume it is a doubly-linked list Heap overflow attacks?

  36. Heap Overflow Here we free block B Unlink B from heap If overflow in A, can overwrite B s pointers

  37. Heap Overflow Overwrite B s pointers Then free B Now if we ever get to B, will go to shellcode

  38. Integer Overflow Many integer problems This example o What if len is negative? o Note that memcpy thinks len is unsigned

  39. Format String Vulnerabilities Format string example printf( The magic number is %d\n , 42); Format strings: Parameter %d %u %x %s %n Meaning int unsigned int hex string bytes written so far Passed by value value value reference reference

  40. 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 );

  41. 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

  42. 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 x2 x3 x4 high

  43. 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

  44. Format String Issue 2 What would this do? printf( %s%s%s%s%s%s%s%s%s%s%s ); For each %s function printfwill 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!

  45. 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

  46. Format String Issue 3 low return 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? Error: %s 1st %d 2nd %d :: %s :: 1234567 buffer %d %d :: high ::

  47. 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?

  48. 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?

  49. 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 )

  50. More Defenses Mentioned by author o NX approach o Canary o ASLR o Safe/safer languages

More Related Content

giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#