lecture 0 appendix on implementation threats material from warren page & chpt 11, information...

33
Lecture 0 Appendix on Implementation Threats Material from Warren Page & Chpt 11, Information Security by Mark Stamp

Upload: jeffry-fletcher

Post on 12-Jan-2016

217 views

Category:

Documents


3 download

TRANSCRIPT

Page 1: Lecture 0 Appendix on Implementation Threats Material from Warren Page & Chpt 11, Information Security by Mark Stamp

Lecture 0 Appendix on Implementation Threats

Material from

Warren Page

&

Chpt 11, Information Security by Mark Stamp

Page 2: Lecture 0 Appendix on Implementation Threats Material from Warren Page & Chpt 11, Information Security by Mark Stamp

Implementation

• Many security threats result not from incorrect service specifications but from poor service implementation

• Unintentional programming flaws include:

Weak password implementation

Buffer overflow (very common)

Unintended permission of operations

Incomplete mediation

Race conditions

Page 3: Lecture 0 Appendix on Implementation Threats Material from Warren Page & Chpt 11, Information Security by Mark Stamp

Weak password implementations (e.g. not enforcing case-sensitivity)

• Brute force attacks on Unix/Linux /etc/passwd: John/LC4/LC5

• On Windows, backwards compatibility to versions where weak password implementations existed weakens newer versions

http://geodsoft.com/howto/password/nt_password_hashes.htm http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/

DepKit/b4001049-4dec-4f5b-a249-0f4dfd22c732.mspx http://support.microsoft.com/default.aspx?scid=kb;EN-US;q299656 http://support.microsoft.com/default.aspx?scid=kb;EN-US;239869

Page 4: Lecture 0 Appendix on Implementation Threats Material from Warren Page & Chpt 11, Information Security by Mark Stamp

Weak password implementation (contd): WS_FTP

• Use copy of WS_FTP .ini file that stores passwords • Simple changes to the file will display passwords• Obtain a list of users and passwords

Page 5: Lecture 0 Appendix on Implementation Threats Material from Warren Page & Chpt 11, Information Security by Mark Stamp

Buffer Overflow: Typical Attack Scenario

• Users enter data into a Web form

• Web form is sent to server

• Server writes data to buffer, without checking length of input data

• Data overflows from buffer

• Sometimes, overflow can enable an attack

• Web form attack could be carried out by anyone with an Internet

connection

• Many other examples

E.g., exploit implementation bugs in SSH/SSL (take a look); again, backwards

compatibility can imply that known exploit with SSH v.1 carried over to SSH v.2

Page 6: Lecture 0 Appendix on Implementation Threats Material from Warren Page & Chpt 11, Information Security by Mark Stamp

Buffer Overflow

• Q: What happens when this is executed?

• A: Depends on what resides in memory at location “buffer[20]”

Might overwrite user data or code

Might overwrite system data or code

int main(){

int buffer[10];

buffer[20] = 37;}

Page 7: Lecture 0 Appendix on Implementation Threats Material from Warren Page & Chpt 11, Information Security by Mark Stamp

Simple Buffer Overflow

• Consider boolean flag for authentication

• Buffer overflow could overwrite flag allowing anyone to authenticate!

buffer

FTF O U R S C …

Boolean flag

• In some cases, attacker need not be so lucky as to have overflow overwrite flag

Page 8: Lecture 0 Appendix on Implementation Threats Material from Warren Page & Chpt 11, Information Security by Mark Stamp

Memory Organization

• Text segment has code• Data segment has static variables• Heap segment has dynamic data• Stack segment has

Dynamic local variables Parameters to functions Return address

stack

heap

data

text

high address

low address

SP

Page 9: Lecture 0 Appendix on Implementation Threats Material from Warren Page & Chpt 11, Information Security by Mark Stamp

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

Page 10: Lecture 0 Appendix on Implementation Threats Material from Warren Page & Chpt 11, Information Security by Mark Stamp

Smashing the Stack

high

• What happens if buffer overflows?

::

buffer

a

b

ret…

low

SP

SP

SP

SP

retoverflow

• Program “returns” to wrong location

NOT!

???

• A crash is likelyoverflow

Page 11: Lecture 0 Appendix on Implementation Threats Material from Warren Page & Chpt 11, Information Security by Mark Stamp

Smashing the Stack

high

• With code injection, attacker can run any code on affected system

::

mal. code

a

b

low

SP

SP

SP

SP

retret

Page 12: Lecture 0 Appendix on Implementation Threats Material from Warren Page & Chpt 11, Information Security by Mark Stamp

Smashing the Stack

• Attacker may not know Address of malicious code

Location of ret on stack

• Solutions Precede malicious code with NOP

“landing pad”

Insert lots of new ret

mal. code

::

::

ret

ret

:

NOP

NOP:

ret ret

Page 13: Lecture 0 Appendix on Implementation Threats Material from Warren Page & Chpt 11, Information Security by Mark Stamp

Stack Smashing Summary

• A buffer overflow must exist in the code

• Not all buffer overflows are exploitable

Things must line up correctly

• If exploitable, attacker can inject code

• Trial and error likely required

Lots of help available online

Smashing the Stack for Fun and Profit, Aleph One

• Also possible to overflow the heap

• Stack smashing is popular

Page 14: Lecture 0 Appendix on Implementation Threats Material from Warren Page & Chpt 11, Information Security by Mark Stamp

Stack Smashing Example

• Program asks for a serial number that attacker does not know

• Attacker also does not have source code

• Attacker does have the executable (exe)

• Program quits on incorrect serial number

Page 15: Lecture 0 Appendix on Implementation Threats Material from Warren Page & Chpt 11, Information Security by Mark Stamp

Example

• By trial and error, attacker discovers an apparent buffer overflow

• Note that 0x41 is “A”• Looks like ret overwritten by 2 bytes!

Page 16: Lecture 0 Appendix on Implementation Threats Material from Warren Page & Chpt 11, Information Security by Mark Stamp

Example

• Next, disassemble bo.exe to find

• The goal is to exploit buffer overflow to jump to address 0x401034

Page 17: Lecture 0 Appendix on Implementation Threats Material from Warren Page & Chpt 11, Information Security by Mark Stamp

Example

• Find that 0x401034 is “@^P4” in ASCII

• Byte order is reversed? Why?• X86 processors are “little-endian”

Page 18: Lecture 0 Appendix on Implementation Threats Material from Warren Page & Chpt 11, Information Security by Mark Stamp

Example

• Reverse the byte order to “4^P@” and…

• Success! We’ve bypassed serial number check by exploiting a buffer overflow

• Overwrote the return address on the stack

Page 19: Lecture 0 Appendix on Implementation Threats Material from Warren Page & Chpt 11, Information Security by Mark Stamp

Example

• Attacker did not require access to the source code

• Only tool used was a disassembler to determine

address to jump to

Can find address by trial and error

Necessary if attacker does not have exe

For example, a remote attack

Page 20: Lecture 0 Appendix on Implementation Threats Material from Warren Page & Chpt 11, Information Security by Mark Stamp

Example

• Source code of the buffer overflow

• Flaw easily found by attacker

• Even without the source code!

Page 21: Lecture 0 Appendix on Implementation Threats Material from Warren Page & Chpt 11, Information Security by Mark Stamp

Stack Smashing Prevention

• 1st choice: employ non-executable stack

“No execute” NX bit (if available)

Seems like the logical thing to do, but some real code executes on

the stack! (Java does this)

• 2nd choice: use safe languages (Java, C#)

• 3rd choice: use safer C functions

For unsafe functions, there are safer versions

For example, strncpy instead of strcpy

Page 22: Lecture 0 Appendix on Implementation Threats Material from Warren Page & Chpt 11, Information Security by Mark Stamp

Stack Smashing Prevention

Canary Run-time stack check Push canary onto stack Canary value:

Constant 0x000aff0d Or value depends on ret

high

::

buffer

a

b

low

overflowret

canaryoverflow

Page 23: Lecture 0 Appendix on Implementation Threats Material from Warren Page & Chpt 11, Information Security by Mark Stamp

• Microsoft added buffer security check feature to C++

with /GS compiler flag

• Uses canary (or “security cookie”)

• Q: What to do when canary dies?

• A: Check for user-supplied handler

• Handler may be subject to attack

Claimed that attacker can specify handler code

If so, formerly safe buffer overflows become exploitable

when /GS is used!

Microsoft’s Canary

Page 24: Lecture 0 Appendix on Implementation Threats Material from Warren Page & Chpt 11, Information Security by Mark Stamp

Incomplete mediation: WEB Applications

Page 25: Lecture 0 Appendix on Implementation Threats Material from Warren Page & Chpt 11, Information Security by Mark Stamp

WEB Applications (continued)

Page 26: Lecture 0 Appendix on Implementation Threats Material from Warren Page & Chpt 11, Information Security by Mark Stamp

Incomplete Mediation: Input Validation

• Consider: strcpy(buffer, argv[1])

• A buffer overflow occurs if

len(buffer) < len(argv[1])

• Software must validate the input by checking the length of argv[1]

• Failure to do so is an example of a more general problem: incomplete mediation

Page 27: Lecture 0 Appendix on Implementation Threats Material from Warren Page & Chpt 11, Information Security by Mark Stamp

Input Validation

• Consider web form data

• Suppose input is validated on client

• For example, the following is valid

http://www.things.com/orders/

final&custID=112&num=55A&qty=20&price=10&shipping=5&total=20

5

• Suppose input is not checked on server

Why bother since input checked on client?

Then attacker could send http message

http://www.things.com/orders/

final&custID=112&num=55A&qty=20&price=10&shipping=5&total=25

Page 28: Lecture 0 Appendix on Implementation Threats Material from Warren Page & Chpt 11, Information Security by Mark Stamp

WEB Applications

Page 29: Lecture 0 Appendix on Implementation Threats Material from Warren Page & Chpt 11, Information Security by Mark Stamp

Incomplete Mediation

• Linux kernel Research has revealed many buffer overflows

Many of these are due to incomplete mediation

• Linux kernel is “good” software since Open-source

Kernel written by coding gurus

• Tools exist to help find such problems But incomplete mediation errors can be subtle

And tools useful to attackers too!

Page 30: Lecture 0 Appendix on Implementation Threats Material from Warren Page & Chpt 11, Information Security by Mark Stamp

Bypass security/copyright

• SHIFT • MS Word• SQL Injections• Cross Site Scripting • CTRL-ALT-DEL• Anonymous• PSEXEC• View Source• Google

Able to view protected files

Page 31: Lecture 0 Appendix on Implementation Threats Material from Warren Page & Chpt 11, Information Security by Mark Stamp

Race Condition

• Security processes should occur “all at once”

• Race conditions can arise when security-critical process

occurs in stages

• Attacker can make change between stages

Often, between stage that gives authorization, but before stage

that transfers ownership

• Example: Unix mkdir

Page 32: Lecture 0 Appendix on Implementation Threats Material from Warren Page & Chpt 11, Information Security by Mark Stamp

mkdir Race Condition

• mkdir creates new directory, as follows:

calls mknod, to create the directory,

then chown, to change ownership of the new

directory from root to the real UID

1. Allocate space

mkdir

2. Transfer ownership

Page 33: Lecture 0 Appendix on Implementation Threats Material from Warren Page & Chpt 11, Information Security by Mark Stamp

A mkdir attack

• Attacker’s timing is critical: Between the two system calls one can delete the new directory and make a hard link to any file. chown then changes the ownership of that file

1. Allocate space

mkdir

3. Transfer ownership

2. Create link to password file

• A mkdir race condition