1. Lecture 18 Page 1 CS 136, Fall 2010 Evaluating System Security Web Security CS 136 Computer Security Peter Reiher December 2, 2010

2. Lecture 18 Page 2 CS 136, Fall 2010 Evaluating Program Security What if your task isn’t writing secure code? It’s determining if someone else’s code is secure –Or, perhaps, their overall system How do you go about evaluating code for security?

3. Lecture 18 Page 3 CS 136, Fall 2010 Secure System Standards Several methods have been proposed over the years to evaluate system security Meant for head-to-head comparisons of systems –Often operating systems, sometimes other types of systems

4. Lecture 18 Page 4 CS 136, Fall 2010 Some Security Standards U.S. Orange Book Common Criteria for Information Technology Security Evaluation There were others we won’t discuss in detail

5. Lecture 18 Page 5 CS 136, Fall 2010 The U.S. Orange Book The earliest evaluation standard for trusted operating systems Defined by the Department of Defense in the late 1970s Now largely a historical artifact

6. Lecture 18 Page 6 CS 136, Fall 2010 Purpose of the Orange Book To set standards by which OS security could be evaluated Fairly strong definitions of what features and capabilities an OS had to have to achieve certain levels Allowing “head-to-head” evaluation of security of systems –And specification of requirements

7. Lecture 18 Page 7 CS 136, Fall 2010 Orange Book Security Divisions A, B, C, and D –In decreasing order of degree of security Important subdivisions within some of the divisions Required formal certification from the government (NCSC) –Except for the D level

8. Lecture 18 Page 8 CS 136, Fall 2010 Some Important Orange Book Divisions and Subdivisions C2 - Controlled Access Protection B1 - Labeled Security Protection B2 - Structured Protection

9. Lecture 18 Page 9 CS 136, Fall 2010 The C2 Security Class Discretionary access control –At fairly low granularity Requires auditing of accesses And password authentication and protection of reused objects Windows NT was certified to this class

10. Lecture 18 Page 10 CS 136, Fall 2010 The B1 Security Class Includes mandatory access control –Using Bell-La Padula model –Each subject and object is assigned a security level Requires both hierarchical and non- hierarchical access controls

11. Lecture 18 Page 11 CS 136, Fall 2010 The B3 Security Class Requires careful security design –With some level of verification And extensive testing Doesn’t require formal verification –But does require “a convincing argument” Trusted Mach was in this class

12. Lecture 18 Page 12 CS 136, Fall 2010 Why Did the Orange Book Fail? Expensive to use Didn’t meet all parties’ needs –Really meant for US military –Inflexible Certified products were slow to get to market Not clear certification meant much –Windows NT was C2, but didn’t mean NT was secure in usable conditions Review procedures tied to US government

13. Lecture 18 Page 13 CS 136, Fall 2010 The Common Criteria Modern international standards for computer systems security Covers more than just operating systems –Other software (e.g., databases) –Hardware devices (e.g., firewalls) Design based on lessons learned from earlier security standards Lengthy documents describe the Common Criteria

14. Lecture 18 Page 14 CS 136, Fall 2010 Common Criteria Approach The CC documents describe –The Evaluation Assurance Levels (EAL) 1-7, in increasing order of security The Common Evaluation Methodology (CEM) details guidelines for evaluating systems PP – Protection Profile –Implementation-independent set of security requirements

15. Lecture 18 Page 15 CS 136, Fall 2010 Another Bowl of Common Criteria Alphabet Soup TOE – Target of Evaluation TSP – TOE Security Policy –Security policy of system being evaluated TSF – TOE Security Functions –HW, SW used to enforce TSP PP – Protection Profile –Implementation-independent set of security requirements ST – Security Target –Predefined sets of security requirements

16. Lecture 18 Page 16 CS 136, Fall 2010 What’s the Common Criteria About? Highly detailed methodology for specifying : 1.What security goals a system has? 2.What environment it operates in? 3.What mechanisms it uses to achieve its security goals? 4.Why anyone should believe it does so?

17. Lecture 18 Page 17 CS 136, Fall 2010 How Does It Work? Someone who needs a secure system specifies what security he needs –Using CC methodology –Either some already defined PPs –Or he develops his own He then looks for products that meet that PP –Or asks developers to produce something that does

18. Lecture 18 Page 18 CS 136, Fall 2010 How Do You Know a Product Meets a PP? Dependent on individual countries Generally, independent labs verify that product meets a protection profile In practice, a few protection profiles are commonly used Allowing those whose needs match them to choose from existing products

19. Lecture 18 Page 19 CS 136, Fall 2010 Status of the Common Criteria In wide use Several countries have specified procedures for getting certifications –And there are agreements for honoring other countries’ certifications Many products have received various certifications

20. Lecture 18 Page 20 CS 136, Fall 2010 Problems With Common Criteria Expensive to use Slow to get certification –Certified products may be behind the market Practical certification levels might not mean that much –Windows 2000 was certified EAL4+ –But kept requiring security patches... Perhaps more attention to paperwork than actual software security –Lower, commonly used EALs only look at process/documentation, not actual HW/SW

21. Lecture 18 Page 21 CS 136, Fall 2010 Evaluating System Security Instead of relying on a standard, why not carefully examine the system? Obviously something to do with your own systems Sometimes something done for other people’s systems –That’s some companies’ business Beyond just auditing

22. Lecture 18 Page 22 CS 136, Fall 2010 How Do You Evaluate a System’s Security? Assuming you have high degree of access to a system –Because you built it or are working with those who did How and where do you start? Much of this material is from “The Art of Software Security Assessment,” Dowd, McDonald, and Schuh

23. Lecture 18 Page 23 CS 136, Fall 2010 Stages of Review You can review a program’s security at different stages in its life cycle –During design –Upon completion of the coding –When the program is in place and operational Different issues arise in each case

24. Lecture 18 Page 24 CS 136, Fall 2010 Design Reviews Done perhaps before there’s any code Just a design Clearly won’t discover coding bugs Clearly could discover fundamental flaws Also useful for prioritizing attention during later code review

25. Lecture 18 Page 25 CS 136, Fall 2010 Purpose of Design Review To identify security weaknesses in a planned software system Essentially, identifying threats to the system Performed by a process called threat modeling Usually (but not always) performed before system is built

26. Lecture 18 Page 26 CS 136, Fall 2010 Threat Modeling Done in various ways One way uses a five step process: 1.Information collection 2.Application architecture modeling 3.Threat identification 4.Documentation of findings 5.Prioritizing the subsequent implementation review

27. Lecture 18 Page 27 CS 136, Fall 2010 1. Information Collection Collect all available information on design Try to identify: –Assets –Entry points –External entities –External trust levels –Major components –Use scenarios

28. Lecture 18 Page 28 CS 136, Fall 2010 One Approach 1 Draw an end-to-end deployment scenario Identify roles of those involved Identify key usage scenario Identify technologies to be used Identify application security mechanisms 1 From http://msdn.microsoft.com/en-us/library/ms978527.aspx

29. Lecture 18 Page 29 CS 136, Fall 2010 Sources of Information Documentation Interviewing developers Standards documentation Source code profiling –If source already exists System profiling –If a working version is available

30. Lecture 18 Page 30 CS 136, Fall 2010 2. Application Architecture Modeling Using information gathered, develop understanding of the proposed architecture To identify design concerns And to prioritize later efforts Useful to document findings using some type of model

31. Lecture 18 Page 31 CS 136, Fall 2010 Modeling Tools for Design Review Markup languages (e.g., UML) –Particularly diagramming features –Used to describe OO classes and their interactions –Also components and uses Data flow diagrams –Used to describe where data goes and what happens to it

32. Lecture 18 Page 32 CS 136, Fall 2010 3. Threat Identification Based on models and other information gathered Identify major security threats to the system’s assets Sometimes done with attack trees

33. Lecture 18 Page 33 CS 136, Fall 2010 Attack Trees A way to codify and formalize possible attacks on a system Makes it easier to understand relative levels of threats –In terms of possible harm –And probability of occurring

34. Lecture 18 Page 34 CS 136, Fall 2010 A Sample Attack Tree For a web application involving a database Only one piece of the attack tree 1. Attacker gains access to user’s personal information 1.1 Gain direct access to database 1.2 Login as target user 1.3 Hijack user session 1.4 Intercept personal data 1.2.1 Brute force password attack 1.2.2 Steal user credentials 1.1.1 Exploit application hole 1.3.1 Steal user cookie 1.4.1 ID user connection 1.4.2 Sniff network

35. Lecture 18 Page 35 CS 136, Fall 2010 4. Documentation of Findings Summarize threats found –Give recommendations on addressing each Generally best to prioritize threats –How do you determine priorities? –DREAD methodology is one way

36. Lecture 18 Page 36 CS 136, Fall 2010 DREAD Risk Ratings Assign number from 1-10 on these categories: Damage potential Reproducibility Exploitability Affected users Discoverability Then add the numbers up for an overall rating Gives better picture of important issues for each threat

37. Lecture 18 Page 37 CS 136, Fall 2010 5. Prioritizing Implementation Review Review of actual implementation once it’s available Requires a lot of resources You probably can’t look very closely at everything Need to decide where to focus limited amount of attention

38. Lecture 18 Page 38 CS 136, Fall 2010 One Prioritization Approach Make a list of the major components Identify which component each risk (identified earlier) belongs to Total the risk scores for categories Use the resulting numbers to prioritize

39. Lecture 18 Page 39 CS 136, Fall 2010 Application Review Reviewing a mature (possibly complete) application A daunting task if the system is large And often you know little about it –Maybe you performed a design review –Maybe you read design review docs –Maybe less than that How do you get started?

40. Lecture 18 Page 40 CS 136, Fall 2010 Need to Define a Process Don’t just dive into the code Process should be: –Pragmatic –Flexible –Results oriented Will require code review –Which is a skill one must develop

41. Lecture 18 Page 41 CS 136, Fall 2010 Review Process Outline 1.Preassessment –Get high level view of system 2.Application review –Design review, code review, maybe live testing 3.Documentation and analysis 4.Remediation support –Help them fix the problems May need to iterate

42. Lecture 18 Page 42 CS 136, Fall 2010 Reviewing the Application You start off knowing little about the code You end up knowing a lot more You’ll probably find the deepest problems related to logic after you understand things A design review gets you deeper quicker –So worth doing, if not already done The application review will be an iterative process

43. Lecture 18 Page 43 CS 136, Fall 2010 General Approaches To Design Reviews Top-down –Start with high level knowledge, gradually go deeper Bottom-up –Look at code details first, build model of overall system as you go Hybrid –Switch back and forth, as useful

44. Lecture 18 Page 44 CS 136, Fall 2010 Code Auditing Strategies Code comprehension (CC) strategies –Analyze source code to find vulnerabilities and increase understanding Candidate point (CP) strategies –Create list of potential issues and look for them in code Design generalization (DG) strategies –Flexibly build model of design to look for high and medium level flaws

45. Lecture 18 Page 45 CS 136, Fall 2010 Some Example Strategies Trace malicious input (CC) –Trace paths of data/control from points where attackers can inject bad stuff Analyze a module (CC) –Choose one module and understand it Simple lexical candidate points (CP) –Look for text patterns (e.g., strcpy() ) Design conformity check (DG) –Determine how well code matches design

46. Lecture 18 Page 46 CS 136, Fall 2010 Guidelines for Auditing Code Perform flow analysis carefully within functions you examine Re-read code you’ve examined Desk check important algorithms Use test cases for important algorithms –Using real system or desk checking –Choosing inputs carefully

47. Lecture 18 Page 47 CS 136, Fall 2010 Useful Auditing Tools Source code navigators Debuggers Binary navigation tools Fuzz-testing tools –Automates testing of range of important values

48. Lecture 18 Page 48 CS 136, Fall 2010 Conclusion Many computer security problems are rooted in insecure programming We have scratched the surface of the topic here Similarly, we’ve scratched the surface of auditing issues If your job is coding or auditing, you’ll need to dig deeper yourself

49. Lecture 18 Page 49 CS 136, Fall 2010 Web Security Lots of Internet traffic is related to the web Much of it is financial in nature Also lots of private information flow around web applications An obvious target for attackers

50. Lecture 18 Page 50 CS 136, Fall 2010 The Web Security Problem Many users interact with many servers Most parties have little other relationship Increasingly complex things are moved via the web No central authority Many developers with little security experience Many critical elements originally designed with no thought to security Sort of a microcosm of the overall security problem

51. Lecture 18 Page 51 CS 136, Fall 2010 Aspects of the Web Problem

52. Lecture 18 Page 52 CS 136, Fall 2010 Who Are We Protecting? The server From the client The client From the server The clients From each other

53. Lecture 18 Page 53 CS 136, Fall 2010 What Are We Protecting? The client’s private data The server’s private data The integrity (maybe secrecy) of their transactions The client and server’s machines Possibly server availability –For particular clients?

54. Lecture 18 Page 54 CS 136, Fall 2010 Some Real Threats Buffer overflows and other compromises –Client attacks server SQL injection –Client attacks server Malicious downloaded code –Server attacks client

55. Lecture 18 Page 55 CS 136, Fall 2010 More Threats Cross-site scripting –Clients attack each other Threats based on non-transactional nature of communication –Client attacks server Denial of service attacks –Threats on server availability (usually)

56. Lecture 18 Page 56 CS 136, Fall 2010 Compromise Threats Much the same as for any other network application Web server might have buffer overflow –Or other remotely usable flaw Not different in character from any other application’s problem –And similar solutions

57. Lecture 18 Page 57 CS 136, Fall 2010 What Makes It Worse Web servers are complex They often also run supporting code –Which is often user-visible Large, complex code base is likely to contain such flaws Nature of application demands allowing remote use

58. Lecture 18 Page 58 CS 136, Fall 2010 Solution Approaches Patching Use good code base Minimize code that the server executes Maybe restrict server access –When that makes sense Lots of testing and evaluation

59. Lecture 18 Page 59 CS 136, Fall 2010 SQL Injection Attacks Many web servers have backing databases –Much of their information stored in database Web pages are built (in part) based on queries to database –Possibly using some client input...

60. Lecture 18 Page 60 CS 136, Fall 2010 SQL Injection Mechanics Server plans to build a SQL query Needs some data from client to build it –E.g., client’s user name Server asks client for data Client, instead, provides a SQL fragment Server inserts it into planned query –Leading to a “somewhat different” query

61. Lecture 18 Page 61 CS 136, Fall 2010 An Example “select * from mysql.user where username = ‘ “. $uid. “ ‘ and password=password(‘ “. $pwd “ ‘);” Intent is that user fills in his ID and password What if he fills in something else? ‘or 1=1; -- ‘

62. Lecture 18 Page 62 CS 136, Fall 2010 What Happens Then? $uid has the string substituted, yielding “select * from mysql.user where username = ‘ ‘ or 1=1; -- ‘ ‘ and password=password(‘ “. $pwd “ ‘);” This evaluates to true –Since 1 does indeed equal 1 –And -- comments out rest of line If script uses truth of statement to determine valid login, attacker has logged in

63. Lecture 18 Page 63 CS 136, Fall 2010 Basis of SQL Injection Problem Unvalidated input Server expected plain data Got back SQL commands Didn’t recognize the difference and went ahead Resulting in arbitrary SQL query being sent to its database –With its privileges

64. Lecture 18 Page 64 CS 136, Fall 2010 Solution Approaches Carefully examine all input –To filter out injected SQL Use database access controls –Of limited value Randomization of SQL keywords –Making injected SQL meaningless

65. Lecture 18 Page 65 CS 136, Fall 2010 Malicious Downloaded Code The web relies heavily on downloaded code –Full language and scripting language –Mostly scripts Instructions downloaded from server to client –Run by client on his machine –Using his privileges Without defense, script could do anything

66. Lecture 18 Page 66 CS 136, Fall 2010 Types of Downloaded Code Java –Full programming language Scripting languages –Java Script –VB Script –ECMAScript –XSLT

67. Lecture 18 Page 67 CS 136, Fall 2010 Solution Approaches Disable scripts –Not very popular Use secure scripting languages –Also not popular –Particularly with code writers Isolation mechanisms –VM or application-based Vista mandatory access control

68. Lecture 18 Page 68 CS 136, Fall 2010 Cross-Site Scripting XSS Many sites allow users to upload information –Blogs, photo sharing, Facebook, etc. –Which gets permanently stored –And displayed Attack based on uploading a script Other users inadvertently download it –And run it...

69. Lecture 18 Page 69 CS 136, Fall 2010 The Effect of XSS Arbitrary malicious script executes on user’s machine In context of his web browser –At best, runs with privileges of the site storing the script –Often likely to run at full user privileges

70. Lecture 18 Page 70 CS 136, Fall 2010 Why Is XSS Common? Use of scripting languages widespread –For legitimate purposes Most users leave them enabled in browser Only a question of getting user to run your script –Often only requires fetching URL

71. Lecture 18 Page 71 CS 136, Fall 2010 Typical Effects of XSS Attack Most commonly used to steal personal information –That is available to legit web site –User IDs, passwords, credit card numbers, etc. Such information often stored in cookies at client side

72. Lecture 18 Page 72 CS 136, Fall 2010 Solution Approaches Don’t allow uploading of scripts –Usually by carefully analyzing uploaded data Provide some form of protection in browser

73. Lecture 18 Page 73 CS 136, Fall 2010 Exploiting Statelessness HTTP is designed to be stateless But many useful web interactions are stateful Various tricks used to achieve statefulness –Usually requiring programmers to provide the state –Often trying to minimize work for the server

74. Lecture 18 Page 74 CS 136, Fall 2010 A Simple Example Web sites are set up as graphs of links You start at some predefined point –A top level page, e.g. And you traverse links to get to other pages But HTTP doesn’t “keep track” of where you’ve been –Each request is simply the name of a link

75. Lecture 18 Page 75 CS 136, Fall 2010 Why Is That a Problem? What if there are unlinked pages on the server? Should a user be able to reach those merely by naming them? Is that what the site designers intended?

76. Lecture 18 Page 76 CS 136, Fall 2010 A Concrete Example The ApplyYourself system Used by colleges to handle student applications For example, by Harvard Business School in 2005 Once all admissions decisions made, results available to students

77. Lecture 18 Page 77 CS 136, Fall 2010 What Went Wrong? Pages representing results were created as decisions were made Stored on the web server –But not linked to anything, since results not yet released Some appliers figured out how to craft URLs to access their pages –Finding out early if they were admitted

78. Lecture 18 Page 78 CS 136, Fall 2010 The Core Problem No protocol memory of what came before So no protocol way to determine that response matches request Could be built into the application that handles requests But frequently isn’t –Or is wrong

79. Lecture 18 Page 79 CS 136, Fall 2010 Solution Approaches Get better programmers –Or better programming tools Back end system that maintains and compares state Front end program that observes requests and responses –Producing state as a result

80. Lecture 18 Page 80 CS 136, Fall 2010 Conclusion Web security problems not inherently different than general software security But generality, power, ubiquity of the web make them especially important Like many other security problems, constrained by legacy issues