Sriram Presentation 3 Comp

8/2/2019 Sriram Presentation 3 Comp

1/33

Multi-Module Vulnerability Analysis

of Web-based Applications

Sriram A

- Davide Balzarotti, Marco Cova, Viktoria

V. Felmetsger, and Giovanni Vigna


2/33

Securing Web Applications

Focuses on detecting (and possibly blocking) web-

based attacks.

Analyzing the requests sent to web applications or,

Analyzing the data delivered by the applications to the

clients

Focuses on identifying flaws in the implementation

of a web application before deploying using Static analysis

Dynamic analysis

2/14/2012 3


3/33

Three Main Limitations

Scope is limited to a single web application module,

such as a single PHP file or a single ASP component.

Not able to correctly model the interactions among

multiple technologies, such as the use of multiplelanguages in the same application, or the use of back-

end databases to store persistent data.

Do not take into account either the intended

workflow of a web application or its extended state.

2/14/2012 4


4/33

Concept

The Intended Workflow of a web application

represents a model of the assumptions that the

developer has made about how a user should

navigate through the application. Many mechanisms provide ways to store information

that survives a single client-server interaction to track

user activity. These define the Extended State of the

application.

2/14/2012 5


5/33

Concept

Different modules of an application have different

assumptions on how the extended state is stored

and handled, leading to vulnerabilities in the

application. These are called Multi-moduleVulnerabilities.

As they originate from the interaction of multiple

application modules, which communicate by reading

and modifying the applications extended state.

2/14/2012 6


6/33

Contributions

Model of web applications extended state that is not

limited to single procedure or code module

Analyze interaction between application code and

back-end architecture (databases) which helpsidentify data-driven attacks

Derive intended workflow of application and provide

an analysis technique to identify multi-step attacks

that attempt to exploit it

2/14/2012 7


7/33

Multi-Module State Analyzer

(MiMoSA)

Is a prototype analysis tool for PHP-based web

applications.

2 Classes of Multi-module attack:

Data Flow Attack

Work Flow Attack

2/14/2012 8


8/33

Data Flow Attacks

Exploits the insecure handling of user provided

information.

The attacker uses a first module to inject some data

into the web applications extended state. Then, a second module uses the attacker-provided

data in an insecure way.

Examples : SQL injection.

Persistent (or stored) Cross-Site Scripting attacks (XSS)

2/14/2012 9


9/33

Work Flow Attacks

An attacker leverages errors in how the state is

handled by the applications modules in order to use

the application in ways that violate its intended

workflow. Therefore circumventing the navigation restrictions.

Example:

By-pass authorization mechanisms

Subverting correct business logic of application.

2/14/2012 10


10/33

Formal Characterization

State Entity E

Can be a variable or other organizational unit. It is

used to store parts of the applications state.

Different modules can share information byaccessing the same state entities.

Can be server-side

PHP session variable or field in d/b. Can be client-side

Cookies, GET or POST parameters

2/14/2012 11


11/33

Module View or View V

Represents the state-equivalent execution paths in a

single module.

The view abstraction allows us to associate with each

behavior a compact representation that summarizesits effect on the extended state of the application.

A view V is represented as a triple (,, ).

Example: Login module has two views Updates state and displays content if authenticated

Displays error page if user is not authenticated

2/14/2012 12


12/33

Pre-Conditions

Conditions which must be met for the view to beaccessed legally

Post-Conditions

A sequence of write operations on state entities. Eachwrite operation has the following form:

write(EL,ER,).

Sink

A set of sinks contained inside the view. Each sink is a pair

(E,Op) where E is a state entity and Op is a potentially

dangerous operation that uses the entity un sanitized.

2/14/2012 13


13/33

Application Paths

Path PBasically, a sequence of views followed by the user

through the application

Application Entry point

A subset of views which has empty preconditions and can

be used as starting points.

Intended path set I

The subset of navigation paths allowed by theapplication design. The intended workflow of the

application, expressed either through explicit links or

other navigational features or behaviors2/14/2012 14


14/33

Intended Path

At each step of the path the next view satisfies one

of the following:

it is an application entry point,

is reachable through a link, is the same as the previous view (which corresponds

to the user pressing the back button in her browser),

is the same as the current view (which corresponds to

the use of the refresh button).

2/14/2012 15


15/33

A Simple Web App

2/14/2012 16

application entry point


16/33

2/14/2012 17create an account


17/33

2/14/2012 18

accessible only to registered users


18/33

Vulnerabilities

Strings used in create.php used to create new

usernames are not sanitized, and index.php

outputs these usernames vulnerable to XSS attack!

In answer.php, verification of user logged-in-nessdone through loggedin variable, when it should be

done throught_SESSION[loggedin] attacker could

manually set that variable in GET or POST request

2/14/2012 19


19/33

Two Phases of Analysis

Intra-module phase

Examines each module in isolation

Determine preconditions, post conditions, sinks

Determine links to other modules in same view

Inter-module phase

Examines application as a whole

Uses intra-module analysis to reconstruct intendedworkflow of the application

2/14/2012 20


20/33

Intra Module Analysis

2/14/2012 21


21/33

Intra Module Analysis

1. Control flow and data flow analysis

Uses Pixy PHP parser to determine control and data

flow of the PHP module

2. Database analysis Translate interaction between application module and

back-end database into set of variableassignments

Determine how query results are handled in

application

2/14/2012 22


22/33

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_register() Sink-related operations where state entities are used in

sensitive or potentially dangerous tasks.

Example: modification of _SESSION[loggedin] create.php

View creation one view created for each set of

preconditions, post conditions, and sinks found

Identify dependencies between views

2/14/2012 23


23/33

Links extraction

Identify links contained in the module and associate

them with the views they belong to.

Determine the conditional branches to be taken toreach a particular link and compare these expressions

with preconditions of extracted views.

This information used in later inter-module analysis to

determine applications intended workflow

2/14/2012 25


24/33

2/14/2012 26


25/33

Inter-module analysis

2/14/2012 27


26/33

2/14/2012 28


27/33

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

2/14/2012 29


28/33

Detection Algorithm

Graph exploration mechanism simulates a user that

moves from one view to another.

Each path is analyzed to check if it satisfies the

definition for data and work flow vulnerabilities. Detection algorithm traverses the graph following

the intended paths. At each step it checks if it is

possible to jump to one of the views that should not

be reachable from the current position. If it

succeeds, it raises a workflow violation alert and it

does not go any further along that path.

2/14/2012 30


29/33

Inter-module analysis


30/33

Results


31/33

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


32/33

Evaluation

For each application we run the intra-module

analysis in order to extract the set of views

corresponding to the application modules.

We then run the inter-module analysis to connecttogether the views and calculate the intended

application workflow.

Finally, we apply our detection algorithm to find

anomalies in the possible navigation paths and to

detect multi-module data-flow vulnerabilities.

2/14/2012 34


33/33

THANK YOU

2/14/2012 35

Sriram Presentation 3 Comp

Documents

Transcript of Sriram Presentation 3 Comp