Vulnerability Analysis of Web-Based Applications

Vulnerability Analysis of Web-Based ApplicationsPart 2

Authors: Marco Cova, et al.Presented by Brett ParkerSome reviewOutlineIntro, Background, TrendsTechnologiesAttacksVulnerability AnalysisMiMoSAVulnerability analysisThe process of assessing the security of an application through auditing of either the applications code or the applications behavior for possible security problemsDetection modelsNegativePositive Analysis techniquesStaticDynamicNegative detection model Model known vulnerabilities using expert knowledgeMatch the models against applicationIdentify instances of vulnerabilitiesPositive detection modelAnalysis based on normal behavior of applicationWant to see if application deviates from normal behaviorDetection of vulnerabilities or attacks almost always done at runtime; not purely static or dynamic approach, but hybrid of bothStatic analysisModels of correctness are built before program execution and tested during execution AMNESIAHalfond and OrsoDetection of SQL injection for Java-based appsBuilds model of expected SQL queriesAt runtime, attempt to detect violations by seeing if the structure of the SQL statement is changed by user input (SQL keywords?)Example: OR 1=1AMNESIA

AMNESIAAssumptions of systemSource code of program contains enough information to build models of legitimate queriesInjection attack must violate the model in order to be detectedGenerates false positives if user input contains SQL keywords SqlCheckSu and WassermanModified SQL parser with augmented grammarTracks 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 querySince it works only with language grammar, it does not require analysis of application source code SqlCheck

Dynamic analysisBuild models of expected behavior by analyzing applications execution when given attack-free inputModels derived from log files or system call tracesAfter 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 modelsIdentification of anomalous events in web requests that pass parametersOperates on URLs extracted from successful web requests stored in logsKruegel and Vigna

Kruegel and VignaLearning phaseDetermine normal values of each parameterSets 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 VignaAdvantagesDoes not require any human interaction learn profiles of normal behavior automaticallyPositive approach means able to detect known and unknown attacksServer-side analysis means language independentDisadvantageAssumes that anomaly malicious behavior; not always the casePositive approaches adv/disadvAdvantageSince model normal behavior, they can detect both known and unknown attacksDisadvantages But what is normal behavior ? Systems vulnerable to mimicry attacks exploit avoids detection by looking like normal behavior Runtime monitoring of the application introduces overheadNegative approaches used more in practice Open issuesNo approach can be considered silver bullet for all conditions and casesSometimes, vulnerability analysis for traditional applications is used for web apps this is difficult due to shared persistent state often found in web appsWeb apps are usually composed of many modules, sometimes written in different languagesOpen issuesEach analysis technique requires different models and detects vulnerabilities in different waysDifficult to correctly model sanitization Some attacks violate intended logic of web application which can be difficult to express in analysis toolsNo 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? Multi-Module Vulnerability Analysis of Web-based ApplicationsAuthors: Davide Balzarotti, Marco Cova, et al.Presented by Brett Parker

Some content inspired by slides by Benjamin ProsnitzOutlineIntro, Background, TrendsTechnologiesAttacksVulnerability AnalysisMiMoSAIntro and motivationCurrent approaches to securing web apps focus onApplication-level firewalls analyze requests sent to web applications/serversVulnerability analysis techniques negative, positive, static, dynamicLimitations of these approachesCan only detect vulnerabilities in single modulesCannot model interactions among multiple technologies and languagesDo not account for intended workflow or extended stateConceptsIndented workflowModels the assumptions the developer has made about how a user should navigate through an applicationExtended stateDistributed collection of session-related information, accessed and modified by different modules of a web application at different times during a user sessionExample: LAMPConceptsMulti-module vulnerabilitiesVulnerabilities that originate from interaction of multiple application modules Modules communicate by reading and modifying applications extended state ContributionsModel of web applications extended state that is not limited to single procedure or code moduleAnalyze interaction between application code and back-end architecture (databases) which helps identify data-driven attacksDerive intended workflow of application and provide an analysis technique to identify multi-step attacks that attempt to exploit it MiMoSAMulti-Module State AnalyzerMulti-module attacks2 typesData-flow attacksWorkflow attacksData-flow attacksAttacker uses some module to inject data into the applications extended stateThen, another module uses attackers data in insecure way

ExamplesSQL injectionCross-site scriptingWorkflow attacksAttacker circumvents navigation restrictions of a web application Usually restrictions are enforced using extended state

ExamplesBypassing authentication skipping right to contentSkipping required step in online shopping checkout State entityAny form of state that can be shared between modulesCan be a variable or other organizational unitCan be server-side PHP session variableCan be client-sideCookies, GET or POST parameters Module viewRepresentation of the state-equivalent execution pathsPath followed by the execution path in a moduleSummary of the different possible extended states of the application

Example: one module with two viewsDisplays content if user is authenticated Displays login page if user is not authenticated Module view componentsPreconditionsConditions which must be met for the view to be accessed legallyPostconditionsState entities modified by the viewSinksThe use of some unsanitized state entity to do something dangerous or malicious Application pathsPathBasically, a sequence of views followed by the user through the application Entry pointa view which has no preconditionsIntended pathThe intended workflow of the application, expressed either through explicit links or other navigational features or behaviors

VulnerabilitiesStrings 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 analysisIntra-module phaseExamines each module in isolationDetermine preconditions, postconditions, sinksDetermine links to other modules in same view Inter-module phaseExamines application as a wholeUses intra-module analysis to reconstruct intended workflow of the application Intra-module analysis

Control flow and data flow analysisUses Pixy PHP parser [9] to determine control and data flow of the PHP module Database analysisTranslate interaction between application module and back-end database into variable assignmentsDetermine how query results are handled in applicationIntra-module analysisIntra-module analysisViews extractionPerform state analysis to determine which statements in the control flow graph are relatedState-related operations that modify server-side stateExample: _SESSION or session_start()Sink-related operations where state entities are used in sensitive or potentially dangerous tasksExample: modification of _SESSION[loggedin]View creation one view created for each set of preconditions, postconditions, and sinks foundIndentify dependencies between views Intra-module analysisLinks extractionIdentify 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

Intra-module analysis

Intra-module analysis

Inter-module analysis

Inter-module analysisIntended workflow determinationConnect the views identified in intra-module anlysis into single flow graph, representing workflow Check every possible navigation pathDetect vulnerabilities by seeing if there are any violations of intended policy as represented by flow graphInter-module analysis

Inter-module analysisPublic view identification Determine publicly accessible pages which dont require any authentication Example: FAQ or help pagesNot used in vulnerability detection simply used to ensure completeness of workflow graph Inter-module analysis

Results

ResultsFound all known vulnerabilities and identified some new onesSome false positives Takes a long timeFuture workExtend to support more application types and languagesReduce number of false positives Thanks!Questions?