Vulnerability Analysis of Web-Based Applications

1. Vulnerability Analysis of Web-Based Applications 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. AMNESIA • Assumptions of system • 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

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 • <<< 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

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

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. Multi-Module Vulnerability Analysis of Web-based Applications Authors: DavideBalzarotti, 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 • Model of web application’s extended state that is not limited to single procedure or code module • Analyze interaction between application code and back-end architecture (databases) which helps identify data-driven attacks • 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 • Attacker uses some module to inject data into the application’s extended state • 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 loggedinvariable, 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. Intra-module analysis • Control flow and data flow analysis • Uses Pixy PHP parser [9] to determine control and data flow of the PHP module • Database analysis • Translate interaction between application module and back-end database into “variable assignments” • Determine how query results are handled in application

43. Intra-module analysis • 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

46. Intra-module analysis

47. Inter-module analysis

48. Inter-module analysis • 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. 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