Part 2
Authors: Marco Cova, et al.
Presented by Brett Parker
Some review
Outline
 Intro, Background, Trends
 Technologies
 Attacks
 Vulnerability Analysis
 MiMoSA
Vulnerability analysis
 The process of assessing the security of an application
through auditing of either the application’s code or the
application’s behavior for possible security problems
 Detection models
 Negative
 Positive
 Analysis techniques
 Static
 Dynamic
Negative detection model
 Model known vulnerabilities using expert knowledge
 Match the models against application
 Identify instances of vulnerabilities
Positive detection model
 Analysis based on “normal” behavior of application
 Want to see if application deviates from “normal”
behavior
 Detection of vulnerabilities or attacks almost always
done at runtime; not purely static or dynamic
approach, but hybrid of both
Static analysis
 Models of correctness are built before program
execution and tested during execution
AMNESIA
 Halfond and Orso
 Detection of SQL injection for Java-based apps
 Builds model of “expected” SQL queries
 At runtime, attempt to detect violations by seeing if
the structure of the SQL statement is changed by user
input (SQL keywords?)
 Example: ’ OR 1=1
AMNESIA
AMNESIA

Assumptions of system
1.
2.

Source code of program contains enough information
to build models of legitimate queries
Injection attack must violate the model in order to be
detected
Generates false positives if user input contains SQL
keywords
SqlCheck
 Su and Wasserman
 Modified SQL parser with augmented grammar
 Tracks substrings from user input through program
execution by marking start and end of string with
special characters
 <<< user string >>>
 If parser determines that query syntax is modified by
user string, blocks query
 Since it works only with language grammar, it does not
require analysis of application source code
SqlCheck
Dynamic analysis
 Build models of expected behavior by analyzing
application’s execution when given attack-free input
 Models derived from log files or system call traces
 After modeling, runtime behavior is compared with
established models to identify discrepancies that
might indicate malicious activity
Kruegel and Vigna
 Learning-based anomaly detection system using
statistical models
 Identification of anomalous events in web requests
that pass parameters
 Operates on URLs extracted from successful web
requests stored in logs
Kruegel and Vigna
Kruegel and Vigna
 Learning phase
 Determine “normal” values of each parameter
 Sets dynamic detection threshold
 Detection phase
 Return anomaly score for each observed example of a
parameter value in the interval [0, 1]
 Final anomaly score calculated
 If it is greater than threshold determined during
learning phase, request is considered anomalous
Kruegel and Vigna
 Advantages
 Does not require any human interaction – learn profiles
of normal behavior automatically
 Positive approach means able to detect known and
unknown attacks
 Server-side analysis means language independent
 Disadvantage
 Assumes that anomaly  malicious behavior; not
always the case
Positive approaches adv/disadv
 Advantage
 Since model “normal” behavior, they can detect both
known and unknown attacks
 Disadvantages
 But what is “normal behavior” ?
 Systems vulnerable to “mimicry attacks” – exploit avoids
detection by looking like normal behavior
 Runtime monitoring of the application introduces
overhead
 Negative approaches used more in practice
Open issues
 No approach can be considered “silver bullet” for all
conditions and cases
 Sometimes, vulnerability analysis for traditional
applications is used for web apps – this is difficult due
to shared persistent state often found in web apps
 Web apps are usually composed of many modules,
sometimes written in different languages
Open issues
 Each analysis technique requires different models and
detects vulnerabilities in different ways
 Difficult to correctly model sanitization
 Some attacks violate intended logic of web application
which can be difficult to express in analysis tools
 No standard accepted dataset available for use as
“base-line” for evaluation; all tools operate on their
own dataset, making it difficult to compare results
Questions?
Authors: Davide Balzarotti, Marco Cova, et al.
Presented by Brett Parker
Some content inspired by slides by Benjamin Prosnitz
Outline
 Intro, Background, Trends
 Technologies
 Attacks
 Vulnerability Analysis
 MiMoSA
Intro and motivation
 Current approaches to securing web apps focus on
 Application-level firewalls – analyze requests sent to
web applications/servers
 Vulnerability analysis techniques – negative, positive,
static, dynamic
 Limitations of these approaches
 Can only detect vulnerabilities in single modules
 Cannot model interactions among multiple
technologies and languages
 Do not account for intended workflow or extended state
Concepts
 Indented workflow
 Models the assumptions the developer has made about
how a user should navigate through an application
 Extended state
 Distributed collection of session-related information,
accessed and modified by different modules of a web
application at different times during a user session
 Example: LAMP
Concepts
 Multi-module vulnerabilities
 Vulnerabilities that originate from interaction of
multiple application modules
 Modules communicate by reading and modifying
application’s extended state
Contributions
Model of web application’s extended state that is not
limited to single procedure or code module
2. Analyze interaction between application code and
back-end architecture (databases) which helps
identify data-driven attacks
3. Derive intended workflow of application and provide
an analysis technique to identify multi-step attacks
that attempt to exploit it
1.
MiMoSA
Multi-Module State Analyzer
Multi-module attacks
 2 types
 Data-flow attacks
 Workflow attacks
Data-flow attacks
Attacker uses some module to inject data into the
application’s extended state
2. Then, another module uses attacker’s data in
insecure way
1.

Examples


SQL injection
Cross-site scripting
Workflow attacks
 Attacker circumvents navigation restrictions of a web
application
 Usually restrictions are enforced using extended state
 Examples
 Bypassing authentication – skipping right to content
 Skipping required step in online shopping checkout
State entity
 Any form of state that can be shared between modules
 Can be a variable or other organizational unit
 Can be server-side
 PHP session variable
 Can be client-side
 Cookies, GET or POST parameters
Module view
 Representation of the state-equivalent execution paths
 Path followed by the execution path in a module
 Summary of the different possible extended states of
the application
 Example: one module with two views
 Displays content if user is authenticated
 Displays login page if user is not authenticated
Module view components
 Preconditions
 Conditions which must be met for the view to be
accessed legally
 Postconditions
 State entities modified by the view
 Sinks
 The use of some unsanitized state entity to do
something dangerous or malicious
Application paths
 Path
 Basically, a sequence of views followed by the user
through the application
 Entry point
 a view which has no preconditions
 Intended path
 The intended workflow of the application, expressed
either through explicit links or other navigational
features or behaviors
Vulnerabilities
 Strings used in create.php used to create new
usernames now sanitized, and index.php outputs
these usernames – vulnerable to XSS attack!
 In answer.php, verification of user logged-in-ness
done through loggedin variable, when it should be
done throught _SESSION[“loggedin”] – attacker
could manually set that variable in GET or POST
request!
Two phases of analysis
 Intra-module phase
 Examines each module in isolation
 Determine preconditions, postconditions, sinks
 Determine links to other modules in same view
 Inter-module phase
 Examines application as a whole
 Uses intra-module analysis to reconstruct intended
workflow of the application
Intra-module analysis
Intra-module analysis
1.
Control flow and data flow analysis
 Uses Pixy PHP parser [9] to determine control and data
flow of the PHP module
2. Database analysis
 Translate interaction between application module and
back-end database into “variable assignments”
 Determine how query results are handled in application
Intra-module analysis
3. Views extraction
 Perform state analysis to determine which statements in
the control flow graph are related
 State-related – operations that modify server-side state
Example: _SESSION or session_start()
 Sink-related – operations where state entities are used in
sensitive or potentially dangerous tasks
Example: modification of _SESSION[“loggedin”]
 View creation – one view created for each set of
preconditions, postconditions, and sinks found
 Indentify dependencies between views
Intra-module analysis
 Links extraction
 Identify links contained in the module and associate
them with the views they belong to
 This information used in later inter-module analysis to
determine application’s intended workflow
Intra-module analysis
Intra-module analysis
Inter-module analysis
Inter-module analysis
1.
Intended workflow determination
 Connect the views identified in intra-module anlysis
into single flow graph, representing workflow
 Check every possible navigation path
 Detect vulnerabilities by seeing if there are any
violations of intended policy as represented by flow
graph
Inter-module analysis
Inter-module analysis
 Public view identification
 Determine publicly accessible pages which don’t require
any authentication
 Example: FAQ or help pages
 Not used in vulnerability detection – simply used to
ensure completeness of workflow graph
Inter-module analysis
Results
Results
 Found all known vulnerabilities and identified some
new ones
 Some false positives
 Takes a long time
 Future work
 Extend to support more application types and languages
 Reduce number of false positives
Thanks!
 Questions?