Application and OS Attacks - PowerPoint PPT Presentation

About This Presentation
Title:

Application and OS Attacks

Description:

Race conditions can arise when security-critical process occurs in stages ... Often, between stage that gives authorization, but before stage that transfers ownership ... – PowerPoint PPT presentation

Number of Views:19
Avg rating:3.0/5.0
Slides: 111
Provided by: marks9
Learn more at: http://www.cs.sjsu.edu
Category:

less

Transcript and Presenter's Notes

Title: Application and OS Attacks


1
Application and OS Attacks
2
Attack Phases
  • Phase 1 Reconnaissance
  • Phase 2 Scanning
  • Phase 3 Gaining access
  • Application/OS attacks
  • Network attacks/DoS attacks
  • Phase 4 Maintaining access
  • Phase 5 Covering tracks and hiding

3
So Far
  • Recon and Scanning completed
  • Attacker has inventory of target system and
    possible vulnerabilities
  • How to exploit vulnerabilities?
  • Application OS attacks (this chapter)
  • Network-based attacks (next chapter)

4
Main Topics
  • Buffer Overflow
  • Stack, heap, and integer overflow
  • Passwords
  • Web-based attacks
  • Session tracking, SQL injection,
  • Browser flaws

5
Script Kiddies
  • Attacks are widely available
  • French Security Response Team (FrSIRT)
  • Packet Storm Security
  • Bugtraq Archives
  • Metasploit Project
  • Little or no knowledge required

6
FrSIRT
7
Sophisticated Attacks
  • Next, we consider common attacks
  • Useful to understand how attacks work
  • Advanced attackers can use these for
  • Original attacks
  • More clever uses of existing attacks

8
Buffer Overflow
9
Some C Code
10
The Stack
11
Vulnerable C Code
12
Stack for Vulnerable Code
13
Smashed Stack
14
Typical Exploit
15
Heap Overflow Vulnerability
16
Heap
17
Heap Normal and Attack
18
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

19
Buffer Overflow
int main() int buffer10
buffer20 37
  • Q What happens when this is executed?
  • A Depending on what resides in memory at
    location buffer20
  • Might overwrite user data or code
  • Might overwrite system data or code

20
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, attacker need not be so lucky as
    to have overflow overwrite flag

21
Memory Organization
  • low
  • address

text
  • Text code
  • Data static variables
  • Heap dynamic data
  • Stack scratch paper
  • Dynamic local variables
  • Parameters to functions
  • Return address

data
heap
? ?
  • SP

stack
  • high
  • address

22
Simplified Stack Example
low ?
void func(int a, int b) char buffer10 void
main() func(1, 2)
  • SP

buffer
  • SP

ret
  • return
  • address

a
  • SP

b
  • SP

high ?
23
Smashing the Stack
low ?
  • What happens if buffer overflows?


???
  • Program returns to wrong location
  • SP

buffer
  • SP
  • ret

ret
overflow
NOT!
  • A crash is likely

a
  • SP

overflow
b
  • SP

high ?
24
Smashing the Stack
low ?
  • Trudy has a better idea

  • Code injection
  • Trudy can run code of her choosing!
  • SP

evil code
ret
ret
  • SP

a
  • SP

b
  • SP

high ?
25
Smashing the Stack
  • Trudy may not know
  • Address of evil code
  • Location of ret on stack
  • Solutions
  • Precede evil code with NOP landing pad
  • Insert lots of new ret

NOP

NOP
evil code
ret
ret
  • ret


ret

26
Stack Smashing Summary
  • A buffer overflow must exist in the code
  • Not all buffer overflows are exploitable
  • Things must line up just right
  • 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 heap overflow, integer overflow, etc.
  • Stack smashing is attack of the decade

27
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

28
Example
  • By trial and error, attacker discovers an
    apparent buffer overflow
  • Note that 0x41 is A
  • Looks like ret overwritten by 2 bytes!

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

30
Example
  • Find that 0x401034 is _at_P4 in ASCII
  • Byte order is reversed? Why?
  • X86 processors are little-endian

31
Example
  • Reverse the byte order to 4P_at_ and
  • Success! Weve bypassed serial number check by
    exploiting a buffer overflow
  • Overwrote the return address on the stack

32
Example
  • Attacker did not require access to the source
    code
  • Only tool used was a disassembler to determine
    address to jump to
  • May be possible to find address by trial and
    error
  • Necessary if attacker does not have exe

33
Example
  • Source code for bo example
  • Note Flaw easily found by attacker
  • Without the source code!

34
Stack Smashing Prevention
  • 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)
  • Use safe languages (Java, C)
  • Use safer C functions
  • For unsafe functions, there are safer versions
  • For example, strncpy instead of strcpy

35
Stack Smashing Prevention
low ?
  • Canary
  • Run-time stack check
  • Push canary onto stack
  • Canary value could be
  • Constant 0x000aff0d
  • Or depends on ret


buffer
canary
overflow

overflow
ret
a
high ?
b
36
Microsofts Canary
  • 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, safe buffer overflows become exploitable
    when /GS is used!

37
ASLR
  • Address Space Layout Randomization
  • Randomize location of code in memory
  • Makes buffer overflow attacks probabilistic
  • Address to jump to is random
  • Vista uses ASLR
  • With 256 random layouts (roughly)
  • So only 1/256 chance attack succeeds
  • Similar thing is done in Mac OS X

38
ASLR
  • A form of computing diversity
  • Works well with NX
  • Tricky to implement
  • Not a panacea
  • There is no substitute for correct code
  • For more info
  • See slides here

39
Buffer Overflow
  • The attack of the decade for 90s
  • Will be the attack of the decade for 00s
  • Can be greatly reduced
  • ASLR, NX, etc.
  • Use safe languages/safer functions
  • Educate developers, use tools, etc.
  • Buffer overflows will exist for a long time
  • Legacy code
  • Bad software development

40
Incomplete Mediation
41
Input Validation
  • Consider strcpy(buffer, argv1)
  • A buffer overflow occurs if
  • len(buffer) lt len(argv1)
  • Software must validate the input by checking the
    length of argv1
  • Failure to do so is an example of a more general
    problem incomplete mediation

42
Input Validation
  • Consider web form data
  • Suppose input is validated on client
  • For example, the following is valid
  • http//www.things.com/orders/finalcustID112num
    55Aqty20price10shipping5total205
  • 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/finalcustID112num
    55Aqty20price10shipping5total25

43
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 errors can be subtle
  • And tools useful to attackers too!

44
Race Conditions
45
Race Condition
  • Security processes should be atomic
  • Occur all at once
  • Race conditions can arise when security-critical
    process occurs in stages
  • Attacker makes change between stages
  • Often, between stage that gives authorization,
    but before stage that transfers ownership
  • Example Unix mkdir

46
mkdir Race Condition
  • mkdir creates new directory
  • How mkdir is supposed to work

mkdir
1. Allocate space
2. Transfer ownership
47
mkdir Attack
  • The mkdir race condition

mkdir
1. Allocate space
3. Transfer ownership
2. Create link to password file
  • Not really a race
  • But attackers timing is critical

48
Race Conditions
  • Race conditions appear to be common
  • May be more common than buffer overflows
  • But race conditions harder to exploit
  • Buffer overflow is low hanging fruit today
  • To prevent race conditions
  • Make security-critical processes atomic
  • Occur all at once, not in stages
  • Not easy to accomplish in practice

49
Heap Overflow
  • Heap used for dynamic variables
  • For example, malloc in C
  • Can overflow one array into another
  • Makes it possible to change data
  • Like simpleminded example given earlier

50
Heap Overflow Example
  • First print
  • buf2 22222222
  • Second print
  • buf2 11122222

51
Integer Overflow
  • Many integer problems
  • This example
  • What if len is negative?
  • Note that memcpy thinks len is unsigned

52
Exploitation Engines
  • Developing a buffer overflow attack
  • Tedious, lots of trial and error
  • Until Metasploit
  • Metasploit
  • Knows about lots of attacks
  • Has lots of payloads

53
Metasploit
  • Payloads 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 attackers
    choosing)

54
Metasploit Web Interface
55
Metasploit
  • Advantages for attackers?
  • Reduces development cycle
  • Resulting attacks much more reliable
  • Advantages for good guys?
  • Helps identify false positives
  • Help improve IDS
  • Improved penetration testing
  • Improved management awareness

56
Buffer Overflow Defenses
  • NX, safe languages, safer functions (in C),
    canary, ASLR
  • Better software development
  • Use tools, such as
  • ITS4
  • RATS
  • Flawfinder

57
Authentication
58
Who Goes There?
  • How to authenticate a human to a machine?
  • Can be based on
  • Something you know
  • For example, a password
  • Something you have
  • For example, a smartcard
  • Something you are
  • For example, your fingerprint

59
Something You Know
  • Passwords
  • Lots of things act as passwords!
  • PIN
  • Social security number
  • Mothers maiden name
  • Date of birth
  • Name of your pet, etc.

60
Trouble with Passwords
  • Passwords are one of the biggest practical
    problems facing security engineers today.
  • Humans are incapable of securely storing
    high-quality cryptographic keys, and they have
    unacceptable speed and accuracy when performing
    cryptographic operations. (They are also large,
    expensive to maintain, difficult to manage, and
    they pollute the environment. It is astonishing
    that these devices continue to be manufactured
    and deployed.)

61
Why Passwords?
  • Why is something you know more popular than
    something you have and something you are?
  • Cost passwords are free
  • Convenience easier for SA to reset pwd than to
    issue user a new thumb

62
Keys vs Passwords
  • Crypto keys
  • Spse key is 64 bits
  • Then 264 keys
  • Choose key at random
  • then attacker must try about 263 keys
  • Passwords
  • Spse passwords are 8 characters, and 256
    different characters
  • Then 2568 264 pwds
  • Users do not select passwords at random
  • Attacker has far less than 263 pwds to try
    (dictionary attack)

63
Good and Bad Passwords
  • Bad passwords
  • frank
  • Fido
  • password
  • 4444
  • Pikachu
  • 102560
  • AustinStamp
  • Good Passwords?
  • jfIej,43j-EmmLy
  • 09864376537263
  • P0kem0N
  • FSa7Yago
  • 0nceuP0nAt1m8
  • PokeGCTall150

64
Password Experiment
  • Three groups of users ? each group advised to
    select passwords as follows
  • Group A At least 6 chars, 1 non-letter
  • Group B Password based on passphrase
  • Group C 8 random characters
  • Results
  • Group A About 30 of pwds easy to crack
  • Group B About 10 cracked
  • Passwords easy to remember
  • Group C About 10 cracked
  • Passwords hard to remember

winner ?
65
Password Experiment
  • User compliance hard to achieve
  • In each case, 1/3rd did not comply (and about
    1/3rd of those easy to crack!)
  • Assigned passwords sometimes best
  • If passwords not assigned, best advice is
  • Choose passwords based on passphrase
  • Use pwd cracking tool to test for weak pwds
  • Require periodic password changes?

66
Attacks on Passwords
  • Attacker could
  • Target one particular account
  • Target any account on system
  • Target any account on any system
  • Attempt denial of service (DoS) attack
  • Common attack path
  • Outsider ? normal user ? administrator
  • May only require one weak password!

67
Password Retry
  • Suppose system locks after 3 bad passwords. How
    long should it lock?
  • 5 seconds
  • 5 minutes
  • Until SA restores service
  • What are s and -s of each?

68
Password File
  • Bad idea to store passwords in a file
  • But need a way to verify passwords
  • Cryptographic solution hash the passwords
  • Store y h(password)
  • Can verify entered password by hashing
  • If attacker obtains password file, he does not
    obtain passwords
  • But attacker with password file can guess x and
    check whether y h(x)
  • If so, attacker has found password!

69
Dictionary Attack
  • Attacker pre-computes h(x) for all x in a
    dictionary of common passwords
  • Suppose attacker gets access to password file
    containing hashed passwords
  • Attacker only needs to compare hashes to his
    pre-computed dictionary
  • Same attack will work each time
  • Can we prevent this attack? Or at least make
    attackers job more difficult?

70
Password File
  • Store hashed passwords
  • Better to hash with salt
  • Given password, choose random s, compute
  • y h(password, s)
  • and store the pair (s,y) in the password file
  • Note The salt s is not secret
  • Easy to verify password
  • Attacker must recompute dictionary hashes for
    each user ? lots more work!

71
Password CrackingDo the Math
  • Assumptions
  • Pwds are 8 chars, 128 choices per character
  • Then 1288 256 possible passwords
  • There is a password file with 210 pwds
  • Attacker has dictionary of 220 common pwds
  • Probability of 1/4 that a pwd is in dictionary
  • Work is measured by number of hashes

72
Password Cracking
  • Attack 1 password without dictionary
  • Must try 256/2 255 on average
  • Just like exhaustive key search
  • Attack 1 password with dictionary
  • Expected work is about
  • 1/4 (219) 3/4 (255) 254.6
  • But in practice, try all in dictionary and quit
    if not found ? work is at most 220 and
    probability of success is 1/4

73
Password Cracking
  • Attack any of 1024 passwords in file
  • Without dictionary
  • Assume all 210 passwords are distinct
  • Need 255 comparisons before expect to find
    password
  • If no salt, each hash computation gives 210
    comparisons ? the expected work (number of
    hashes) is 255/210 245
  • If salt is used, expected work is 255 since each
    comparison requires a new hash computation

74
Password Cracking
  • Attack any of 1024 passwords in file
  • With dictionary
  • Probability at least one password is in
    dictionary is 1 (3/4)1024 1
  • We ignore case where no pwd is in dictionary
  • If no salt, work is about 219/210 29
  • If salt, expected work is less than 222
  • Note If no salt, we can precompute all
    dictionary hashes and amortize the work

75
Other Password Issues
  • Too many passwords to remember
  • Results in password reuse
  • Why is this a problem?
  • Who suffers from bad password?
  • Login password vs ATM PIN
  • Failure to change default passwords
  • Social engineering
  • Error logs may contain almost passwords
  • Bugs, keystroke logging, spyware, etc.

76
Passwords
  • The bottom line
  • Password cracking is too easy!
  • One weak password may break security
  • Users choose bad passwords
  • Social engineering attacks, etc.
  • The bad guy has all of the advantages
  • All of the math favors bad guys
  • Passwords are a big security problem

77
Password Cracking Tools
  • Popular password cracking tools
  • Password Crackers
  • Password Portal
  • L0phtCrack and LC4 (Windows)
  • John the Ripper (Unix)
  • Admins should use these tools to test for weak
    passwords since attackers will!
  • Good article on password cracking
  • Passwords - Conerstone of Computer Security

78
Password Problems
  • Weak passwords
  • Too many passwords
  • Default passwords
  • And so on

79
Default Passwords
80
Password Cracking
  • Cain and Abel

81
Password Cracking
  • John the Ripper

82
Password Cracking Defenses
  • Strong password policy
  • User awareness
  • Pwd filtering software
  • Password Guardian, Strongpass
  • Use other forms of authentication
  • Try password cracking
  • Protect password files

83
Web-Related Attacks
  • Rapidly growing area of interest
  • For up-to-date info, see, for example, The Ghost
    in the Browser
  • Slides are here

84
Web Application Attacks
  • Book discusses
  • Account harvesting
  • Session tracking issues
  • SQL injection

85
Account Harvesting
  • Targets authentication process when application
    requests ID/password
  • Attacker can collect IDs
  • And sometimes passwords too
  • A simple concept
  • Very effective in some Web apps

86
Account Harvesting
  • Error message for bad ID

87
Account Harvesting
  • Error message for good ID, bad password

88
Account Harvesting Defense
  • Have consistent error messages
  • Other?

89
Session Tracking Issues
  • Authenticate to Web application
  • Use a password
  • Then often use a session ID to connect traffic to
    authenticated user
  • Session ID is given to client browser
  • Usually independent of SSL connection
  • Bottom line ID can be changed by client

90
Attacking Session Tracking
  • Session ID can be implemented using
  • URL session tracking (next slide)
  • Hidden form elements (next slide)
  • Nonpersistent cookies (most common)

91
Session Tracking
  • URL session tracking example
  • Hidden form, in html
  • ltINPUT TYPEHIDDEN NAMEID VALUE34213gt

92
Session Tracking Attacks
  • Might be able to alter session ID
  • If so, can hijack an active session
  • Called session cloning
  • Why doesnt Web application connect session ID to
    IP address?

93
Session Tracking Attacks
  • Attacker first needs to find valid ID
  • How to do so?
  • Collect a bunch of IDs
  • Try to see how they change
  • Then make educated guesses

94
Session Tracking Attacks
  • Attacker must change session ID in active session
  • Spse nonpersistent Web cookies used

95
Session Tracking Attacks
  • Can use a Web application manipulation proxy to
    change session ID in active session
  • Web app manipulation proxies include
  • Achilles, Paros Proxy, WebScarab, Web Sleuth, etc.

96
Web Application Manipulation Proxy
97
Achilles
98
Paros Proxy
99
Defenses
  • Integrity protect session ID
  • Sign/MAC/HMAC
  • Then, only legitimate user can properly
    sign/MAC/HMAC
  • Note that this is separate from SSL
  • Is this really necessary???

100
SQL Injection
  • Structured Query Language (SQL)
  • Used by web application to communicate with
    back-end database
  • By manipulating SQL, attacker may
  • Get access to info
  • Change data
  • Weve seen this before

101
WebGoat
  • Fake e-commerce site
  • Intentionally full of vulnerabilities

102
WebGoat
103
WebGoat
104
WebGoat
105
SQL Injection Defenses
  • Complete mediation
  • Filter all user-supplied info
  • Limit permissions of Web app when accessing
    database
  • Parameterized stored procedures
  • I.e., do not compose queries on the fly

106
Browser Flaws
  • Browsers are complex pieces of software
  • Lots of flaws have been found
  • Buffer overflows, for example
  • For example, buffer overflow in Safari (related
    to tiff files) used to break iPhone restrictions

107
Browser Flaws
108
Defenses
  • Use antivirus
  • consider using a browser other than Internet
    Explorer

109
Conclusions
110
Summary
Write a Comment
User Comments (0)
About PowerShow.com