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

Assumptions of system 1. Source code of program contains enough information to build models of legitimate queries 2. 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 >> 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

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 1. 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

MiMoSA Multi-Module State Analyzer

Multi-module attacks 2 types Data-flow attacks Workflow attacks

Data-flow attacks 1. Attacker uses some module to inject data into the application’s extended state 2. Then, another module uses attacker’s data in insecure way 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

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

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

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

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?