Transcript Why Cryptosystems Fail Prepared by Geoffrey Foote for CSC

Attack Patterns
Authors: Greg Hoglund
Gary McGraw
Prepared by Geoffrey Foote
CSC 593 Secure Software Engineering Seminar
Spring Semester 2006
Instructors: Dr. Charles Frank
Dr. James Walden
Overview
Definitions
 A Taxonomy
 An Open System View
 Attack Patterns
 Example Exploit: MS C++ Compiler
 Applying Attack Patterns
 Conclusions

Definitions
Target Software – the software
program under attack, either
remotely or locally
 Risk Assessment – analyzing a target
for vulnerabilities


Vulnerabilities are not exploits, but
necessary for one
Definitions

Observability – the probability that a
failure will be noticeable in output
space

Program w/ Low Observability made to
have High Observability using a debugger

Ex: Attach a data flow tracer to the target
Exploiting SW encompasses the idea of
observability
 Basic Idea – gather as much info about
the target as possible

 Statically
– while being constructed
 Dynamically – while running
Definitions

Output
SW that produces no external output has
no way to indicate failures
 The more output SW emits, the easier it
is to detect faulty states

A Taxonomy
To measure risk, vulnerabilities need
to be identified
 Related programming errors give rise
to similar exploit techniques
 Two current collection of
Vulnerabilities

http://www.bugtraq.com
 The CVE


Collections help defend and attack
systems
A Taxonomy

Bugs
A software problem
 Problem at the implementation level
 Generally, are easily fixed
 Easier to attack
 Code scanners are great at finding

 Ex:
Misusing strcpy() and causing a buffer
overflow condition
A Taxonomy

Flaws
Also a software problem, at a deeper level
 More subtle
 Instantiated in code but also present at
the design-level
 Ex: Error handling and recovery systems
that fail in an insecure manor
 Ex: Exposure to Cross-Site scripting
attacks due to poor design

A Taxonomy

Vulnerabilities
Problem that can be exploited by an
attacker
 Bugs and Flaws are vulnerabilities
 Trivial errors can often be fixed in a single
line of code
 Design errors almost always require
redesign and touch multiple areas

A Taxonomy

Design Vulnerabilities
Much harder to find
 Require greater expertise
 Harder to Automate
 Microsoft’s “Security Push” of 2002

 %50
of flaws found where design-level
problems
An Open-Systems View


Fundamental Concept: almost every
technical system exists as a part of a larger
whole, and all the components are in a
constant state of interaction.
Separating code from the environment is a
mistake


Majority of high-level applications call directly
into low-level OS constructs
Instead of everything being self-contained,
almost anything can communicate with
everything else on all sorts of disjoint levels
An Open-Systems View

Ultimately, environment really does
matter


Trying to treat code separately is
doomed to fail
Two Distinct Approach Subfields
Software Security
 Application Security

An Open-Systems View

Software Security

Defends against SW exploits by building
SW to be secure in the first place
 Getting
the design right
 Avoiding common mistakes

Mainly Concerned with:
SW to be secure
 Making sure SW is secure
 Educating developers, architects and users
 Designing
An Open-Systems View

Application Security
Defends against SW exploits in a post
facto way, after development is complete
 Enforces reasonable policy about:

 The
kind of things that can run
 How they can change
 What the SW does as it runs
Attack Patterns
“Techniques for exploiting SW tend to
be few in number and fairly specific”
 Attack pattern



A blueprint for exploiting a SW
vulnerability
Exploit

Is an instance of an attack pattern created
to compromise a particular piece of target
SW
Attack Patterns

Cont. Exploits

Usually self-contained, stand alone and
easy to use
 Keeps

them easily organized and accessed
Attack
Act of carrying out an exploit
 Loosely mean/refer to an exploit
 Events that expose a SW system’s
inherent logical errors and invalid states

Attack Patterns

Attacker – person who uses an exploit
to carry out an attack
Without an attack, an attack is only a plan
 Includes “script kiddies”

 Even
though they aren’t capable of creating
attack patterns or exploits themselves
Attack Patterns

Attack Pattern
Involves an injection vector that
simultaneously exposes an activation
zone and contains a payload
 Most Important: distinction between the
Injection Vector and the Payload
 Good Exploit: will not only break the
code but will also leverage problems to
execute some payload code
 The trick is to use some flaw or bug to
drop a payload into place and start
running it

Attack Patterns

Injection Vector




Describes the format of an input-driven attack
Each target environment imposes certain
format restrictions on the attack
Goal: to place a payload into a target activation
zone
Must Consider:





Grammar of an attack
Syntax accepted by the system
Position of various fields
Numerical ranges of data that are acceptable
Must produce feedback events so that we can
observe attack behavior
Attack Patterns

Activation Zone
Area within the target SW that is capable
of executing or otherwise activating the
payload
 A.Z. May be:

A
Command Interpreter
 Some Active Machine Code in a buffer
 System API call
Produces the output event
 When a payload is executed, this is
called Payload Activation

Attack Patterns

Output Event

Indicates that the desired outcome of an
attack has occurred
 From

the attackers point of view
Possible Forms:
 Creation
of a remote shell
 Execution of a Command
 Destruction of Data

Could be decomposed into a set of small,
of supporting events
 Referred
to as the Aggregation Elements
Attack Patterns

Feedback Event




While a system is actively probed to assess its
vulnerability, feedback event occur
These are the events that are readily visible to
the attacker
Amount of visibility depends on the environment
of the attack
Examples of Feedback Events:



Content/result data from queries
Timing Information about those events
Instrumental in determining if an attack is
succeeding
Example Exploit: MS C++ Compiler
Example of how an attack pattern can
be turned into an exploit
 Design-Level flaw in the “Security Error
Handler”


Attempted to detect error runtime
 Efficiency/Security


tradeoff
Should have originally prevent the
problem in code
Resulted in a buffer-overflow
vulnerability - Ironic
Example Exploit: MS C++ Compiler

Solution

Best
 Have
developers adopt a type-safe language
(Java or C#)

Next Best
 Compile
in dynamic checks on string
functions that occur at runtime

However, these solutions my not make
sense given project constraints
Applying Attack Patterns

Logical Steps of a Successful Attack

Qualify the Target
 learn
what input points exist
Determine what type of transactions are
accepted at each input
 Explore each type of transaction

 Used
work

to determine which types of attacks will
Use attack patterns
 Construct
malformed but “legal” transactions
that manipulate the SW in interesting ways
Applying Attack Patterns

Several Broad Categories
Networking Scanning
 OS Stack Identification

 Determines
device

the OS version on the target
Ports Scans
 Used
to determine which services are
running on the target system
Applying Attack Patterns

Target Components
Check systems for low hanging fruit
 Easily compromised Target Components

 CGI
Programs
 Scripts
 Servlets
 EJBs
Applying Attack Patterns

Choosing an Attack Pattern

Once a valid transaction pattern is
discovered, it can be mutated using a
variety of attack patterns
 Command
Injection
 File System API Injection
 SQL Insertion
 Application-Level Denial of Service
 Network-Based Denial of Service
 Explore Input Space for Buffer Overflows
Applying Attack Patterns

Using Indirection
Clear goal of an attacker is to hide their
identity
 Made Easy By:

 Unprotected
 Geopolitics
802.11 wireless networks
Applying Attack Patterns

Planting Backdoors

Locations
 Rootkit
 Within
the BIOS
 Within the EEPROM memory of peripheral
cards and equipment

Backdoors may perform duties
 Keystroke
logging
 Packet Sniffing
 Email Reading
Conclusion/Questions
Short intro to attack patterns
 Covered a standard process for
carrying out an attack


Comments/Questions???