Transcript Introduction CS 239 Security for Networks and System

Evaluating System Security
Web Security
CS 136
Computer Security
Peter Reiher
December 2, 2010
CS 136, Fall 2010
Lecture 18
Page 1
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?
CS 136, Fall 2010
Lecture 18
Page 2
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
CS 136, Fall 2010
Lecture 18
Page 3
Some Security Standards
• U.S. Orange Book
• Common Criteria for Information
Technology Security Evaluation
• There were others we won’t discuss in
detail
CS 136, Fall 2010
Lecture 18
Page 4
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
CS 136, Fall 2010
Lecture 18
Page 5
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
CS 136, Fall 2010
Lecture 18
Page 13
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
CS 136, Fall 2010
Lecture 18
Page 14
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?
CS 136, Fall 2010
Lecture 18
Page 16
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
CS 136, Fall 2010
Lecture 18
Page 17
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
CS 136, Fall 2010
Lecture 18
Page 18
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
CS 136, Fall 2010
Lecture 18
Page 19
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
CS 136, Fall 2010
Lecture 18
Page 20
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
CS 136, Fall 2010
Lecture 18
Page 21
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
CS 136, Fall 2010
Lecture 18
Page 22
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
CS 136, Fall 2010
Lecture 18
Page 23
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
CS 136, Fall 2010
Lecture 18
Page 24
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
CS 136, Fall 2010
Lecture 18
Page 25
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
CS 136, Fall 2010
Lecture 18
Page 26
1. Information Collection
• Collect all available information on design
• Try to identify:
– Assets
– Entry points
– External entities
– External trust levels
– Major components
– Use scenarios
CS 136, Fall 2010
Lecture 18
Page 27
1
One Approach
• 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
1From
http://msdn.microsoft.com/en-us/library/ms978527.aspx
CS 136, Fall 2010
Lecture 18
Page 28
Sources of Information
•
•
•
•
Documentation
Interviewing developers
Standards documentation
Source code profiling
– If source already exists
• System profiling
– If a working version is available
CS 136, Fall 2010
Lecture 18
Page 29
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
CS 136, Fall 2010
Lecture 18
Page 30
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
CS 136, Fall 2010
Lecture 18
Page 31
3. Threat Identification
• Based on models and other information
gathered
• Identify major security threats to the
system’s assets
• Sometimes done with attack trees
CS 136, Fall 2010
Lecture 18
Page 32
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
CS 136, Fall 2010
Lecture 18
Page 33
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.1.1
Exploit
application
hole
CS 136, Fall 2010
1.2 Login
as target
user
1.2.1 Brute
force
password
attack
1.3 Hijack
user
session
1.2.2 Steal
user
credentials
1.3.1
Steal
user
cookie
1.4
Intercept
personal
data
1.4.1 ID
user
connection
1.4.2
Sniff
network
Lecture 18
Page 34
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
CS 136, Fall 2010
Lecture 18
Page 35
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
CS 136, Fall 2010
Lecture 18
Page 36
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
CS 136, Fall 2010
Lecture 18
Page 37
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
CS 136, Fall 2010
Lecture 18
Page 38
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?
CS 136, Fall 2010
Lecture 18
Page 39
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
CS 136, Fall 2010
Lecture 18
Page 40
Review Process Outline
1.
2.
3.
4.
•
Preassessment
– Get high level view of system
Application review
– Design review, code review, maybe live
testing
Documentation and analysis
Remediation support
– Help them fix the problems
May need to iterate
CS 136, Fall 2010
Lecture 18
Page 41
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
CS 136, Fall 2010
Lecture 18
Page 43
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
CS 136, Fall 2010
Lecture 18
Page 44
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
CS 136, Fall 2010
Lecture 18
Page 45
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
CS 136, Fall 2010
Lecture 18
Page 46
Useful Auditing Tools
•
•
•
•
Source code navigators
Debuggers
Binary navigation tools
Fuzz-testing tools
– Automates testing of range of
important values
CS 136, Fall 2010
Lecture 18
Page 47
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
CS 136, Fall 2010
Lecture 18
Page 49
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
Lecture 18
CS 136, Fall 2010
Page 50
Some Real Threats
• Buffer overflows and other
compromises
– Client attacks server
• SQL injection
– Client attacks server
• Malicious downloaded code
– Server attacks client
CS 136, Fall 2010
Lecture 18
Page 54
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)
CS 136, Fall 2010
Lecture 18
Page 55
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
CS 136, Fall 2010
Lecture 18
Page 56
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 . . .
CS 136, Fall 2010
Lecture 18
Page 59
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
CS 136, Fall 2010
Lecture 18
Page 60
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; -- ‘
CS 136, Fall 2010
Lecture 18
Page 61
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
CS 136, Fall 2010
Lecture 18
Page 62
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
CS 136, Fall 2010
Lecture 18
Page 63
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
CS 136, Fall 2010
Lecture 18
Page 64
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
CS 136, Fall 2010
Lecture 18
Page 65
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
CS 136, Fall 2010
Lecture 18
Page 67
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 . . .
CS 136, Fall 2010
Lecture 18
Page 68
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
CS 136, Fall 2010
Lecture 18
Page 69
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
CS 136, Fall 2010
Lecture 18
Page 70
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
CS 136, Fall 2010
Lecture 18
Page 71
Solution Approaches
• Don’t allow uploading of scripts
– Usually by carefully analyzing
uploaded data
• Provide some form of protection in
browser
CS 136, Fall 2010
Lecture 18
Page 72
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
CS 136, Fall 2010
Lecture 18
Page 73
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
CS 136, Fall 2010
Lecture 18
Page 78
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
CS 136, Fall 2010
Lecture 18
Page 79
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
CS 136, Fall 2010
Lecture 18
Page 80