part 2 authors: marco cova, et al. presented by brett parker

54
Vulnerability Analysis of Web-Based Applications Part 2 Authors: Marco Cova, et al. Presented by Brett Parker

Upload: jaheem-knowlden

Post on 15-Dec-2015

213 views

Category:

Documents


0 download

TRANSCRIPT

  • Slide 1

Part 2 Authors: Marco Cova, et al. Presented by Brett Parker Slide 2 Some review Slide 3 Outline Intro, Background, Trends Technologies Attacks Vulnerability Analysis MiMoSA Slide 4 Vulnerability analysis The process of assessing the security of an application through auditing of either the applications code or the applications behavior for possible security problems Detection models Negative Positive Analysis techniques Static Dynamic Slide 5 Negative detection model Model known vulnerabilities using expert knowledge Match the models against application Identify instances of vulnerabilities Slide 6 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 Slide 7 Static analysis Models of correctness are built before program execution and tested during execution Slide 8 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 Slide 9 AMNESIA Slide 10 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 Slide 11 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 Slide 12 SqlCheck Slide 13 Dynamic analysis Build models of expected behavior by analyzing applications 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 Slide 14 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 Slide 15 Kruegel and Vigna Slide 16 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 Slide 17 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 Slide 18 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 Slide 19 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 Slide 20 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 Slide 21 Questions? Slide 22 Authors: Davide Balzarotti, Marco Cova, et al. Presented by Brett Parker Some content inspired by slides by Benjamin Prosnitz Slide 23 Outline Intro, Background, Trends Technologies Attacks Vulnerability Analysis MiMoSA Slide 24 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 Slide 25 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 Slide 26 Concepts Multi-module vulnerabilities Vulnerabilities that originate from interaction of multiple application modules Modules communicate by reading and modifying applications extended state Slide 27 Contributions 1. Model of web applications 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 Slide 28 MiMoSA Multi-Module State Analyzer Slide 29 Multi-module attacks 2 types Data-flow attacks Workflow attacks Slide 30 Data-flow attacks 1. Attacker uses some module to inject data into the applications extended state 2. Then, another module uses attackers data in insecure way Examples SQL injection Cross-site scripting Slide 31 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 Slide 32 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 Slide 33 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 Slide 34 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 Slide 35 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 Slide 36 Slide 37 Slide 38 Slide 39 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! Slide 40 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 Slide 41 Intra-module analysis Slide 42 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 Slide 43 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 Slide 44 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 applications intended workflow Slide 45 Intra-module analysis Slide 46 Slide 47 Inter-module analysis Slide 48 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 Slide 49 Inter-module analysis Slide 50 Public view identification Determine publicly accessible pages which dont require any authentication Example: FAQ or help pages Not used in vulnerability detection simply used to ensure completeness of workflow graph Slide 51 Inter-module analysis Slide 52 Results Slide 53 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 Slide 54 Thanks! Questions?