1. Part 2 Authors: Marco Cova, et al. Presented by Brett Parker

2. Some review

3. Outline Intro, Background, Trends Technologies Attacks Vulnerability Analysis MiMoSA

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

5. Negative detection model Model known vulnerabilities using expert knowledge Match the models against application Identify instances of vulnerabilities

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

7. Static analysis Models of correctness are built before program execution and tested during execution

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

9. AMNESIA

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

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

12. SqlCheck

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

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

15. Kruegel and Vigna

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

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

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

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

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

21. Questions?

22. Authors: Davide Balzarotti, Marco Cova, et al. Presented by Brett Parker Some content inspired by slides by Benjamin Prosnitz

23. Outline Intro, Background, Trends Technologies Attacks Vulnerability Analysis MiMoSA

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

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

26. Concepts Multi-module vulnerabilities Vulnerabilities that originate from interaction of multiple application modules Modules communicate by reading and modifying application’s extended state

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

28. MiMoSA Multi-Module State Analyzer

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

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

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

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

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

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

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

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!

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

41. Intra-module analysis

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

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

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 application’s intended workflow

45. Intra-module analysis

47. Inter-module analysis

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

49. Inter-module analysis

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

51. Inter-module analysis

52. Results

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

54. Thanks! Questions?