Automated Patching for Vulnerable Source Code

Automated Patching for Vulnerable Source Code

Vladimir KochetkovApplication Inspector/Compiling Applications

Analysis/Team LeadPositive Technologies

Positive Hack Days V

Disclaimer

Who are we?

Developers of PT Application Inspector!

Application Inspector― Strong dogfooding

― Analysis is performed on the limit of ?AST approaches

― Generation of attack vectors

― The Big Red Button Concept

― A proprietary solution

Application Inspector― Integration with PT Application Firewall (aka virtual

patches)

Well... still we want more

What do we want?

To generate patches for the source code!!

How to catch the vulnerability?― Know "how it shouldn't be": necessary and

sufficient formal symptoms of vulnerabilities

― Know "how it is": prove the existence of these symptoms in the analyzed code

― Build an attack vector based on the revealed set of symptoms

Formal symptoms of injection― Potentially vulnerable operation PVO(text):

operation of direct or indirect "text" interpretation in a formal language

― text = transform(argument), where argument – number of arguments passed to the EP entry point, and transform – the function of intermediate transformations

― There is at least one set of such values of EP elements that can be reached. At these values the syntax tree structure of the "text" value, that reaches PVO, changes.

Formalizability of vulnerabilities

Strictly formalizable Poorly formalizable

Injections Access Control

Buffer Overflow Session Management

Heap Overflow CSRFInteger Overflow Concurrency

Memory Management Domain(Logical)

… …

What do we have?

Symbolic Execution Context Graph!

DisclaimerThere is just a review. Further details will be presented at

SIBECRYPT’15Novosibirsk, September 7-12, 2015

Symbolic Execution Context Graph!SECG is a graph, an isomorphic CFG, each of its vertices contains information on the context of symbolic execution

The context of symbolic execution - a condition for accessing the current point of execution + a set of conditional states of all objects and variables that can be reached within the current scope

Symbolic Execution Context Graph

ε �֜ {}


ε �֜ { parm' א { ε �֜ Request.Params["parm1"] } }


Request.Params["cond1"] == "true" �֜ { parm' א { ε �֜ Request.Params["parm1"] } }


Request.Params["cond1"] != "true" �֜ { parm' א { Request.Params["cond1"] != "true" �֜ Request.Params["parm1"] } }


Request.Params["cond1"] != "true" && Request.Params["cond2"] == "true" �֜ { parm' א { Request.Params["cond1"] != "true" �֜ Request.Params["parm1"] } }


Request.Params["cond1"] != "true" && Request.Params["cond2"] != "true" �֜ { parm' א { Request.Params["cond1"] != "true" �֜ Request.Params["parm1"] } }


Request.Params["cond1"] != "true" �֜ { parm' א { Request.Params["cond2"] == "true" �֜ Request.Params["parm2"] || Request.Params["cond2"] != "true" �֜ "<div>Harmless value</div>" } }

Request.Params["cond1"] != "true" �֜ { parm' א { Request.Params["cond2"] == "true" �֜ Request.Params["parm2"] || Request.Params["cond2"] != "true" �֜ "<div>Harmless value</div>" } }


Using the SECG for each PVO we can...

Figure out a vulnerability formula!

Vulnerability formulaRequest.Params["cond1"] != "true" ⇒

Response.Write( "<a href=\"" + parm ∈ { Request.Params["cond2"] == "true" ⇒ Request.Params["parm2"] ; Request.Params["cond2"] != "true" ⇒ "<div>Harmless value</div>" } + "\">" )

Vulnerability formulaRequest.Params["cond1"] != "true" ⇒

Response.Write( "<a href=\"" + parm ∈ { Request.Params["cond2"] == "true" ⇒ Request.Params["parm2"] } + "\">" )

Vulnerability formulaRequest.Params["cond1"] != "true"&&

Request.Params["cond2"] == "true" ⇒

Response.Write( "<a href=\"" + Request.Params["parm2"] + "\">" )


Request.Params["cond2"] == "true" ⇒


What value of Request.Params["parm2"] will result in exceeding the limits of the token?

The one that is defined by the type of the injection point!

<a href=" ">

The type of the injection point is figured out by syntactic heuristics applied to the vulnerable

expression on either side of the point.

Finding the type of the injection point


Request.Params["cond2"] == "true" &&(Request.Params["parm2"] == "\"><script>alert(0)</script>"

|| Request.Params["parm2"] == "\"onmouseover=\"alert(0)") ⇒


Vulnerability formulaRequest.Params["cond1"] != "true"&&Request.Params["cond2"] == "true" &&(Request.Params["parm2"] == "\"><script>alert(0)</script>" || Request.Params["parm2"] == "\"onmouseover=\"alert(0)") ⇒

Response.Write( "<a href=\"" + Request.Params["parm2"] + "\">" ) As a result of finding the values unknown in

the context of the vulnerability formula you can get...

-

-

A contextual attack vector!

The contextual attack vectorVulnerable expression:"<a href=\"" + Request.Params["parm2"] + "\">"

The type of the injection point:HTML: 2-quoted attribute value

Vector variables:Request.Params["parm2"] = "\"><script>alert(0)</script>"

Conditional variables:Request.Params["cond1"] = "__AI_akhivldp"Request.Params["cond2"] = "true"

What is missing?

SECG gives us anything we need!*

* it also gives us anything we don't need yet

The proper patch

― Makes a minimum of changes

― Keeps the semantics of the code

― Solves the problem

― Never makes more problems

― Know "how it shouldn't be": necessary and sufficient formal symptoms of vulnerabilities

― Know "how it is": prove the existence of these symptoms in the analyzed code

― eliminate at least one of the required symptoms by changing the code

How to generate a patch?

Symptoms of injection that can be eliminated

― Potentially vulnerable operation PVO(text): operation of direct or indirect "text" interpretation in a formal language

― text = transform(argument), where argument – number of arguments passed to the EPentry point, and transform – the function of intermediate transformations

― At least one set of such values of the EP elements exists and is likely to be achieved. At these values the syntax tree structure of the "text" value, that reaches PVO, changes.

Ways to eliminate the injectionhttp://www.slideshare.net/kochetkov.vladimir/how-to-develop-a-secure-web-application-and-stay-in-mind-phdays-3/87

• Typing

• Validation

• Sanitization

http://www.slideshare.net/kochetkov.vladimir/how-to-develop-a-secure-web-application-and-stay-in-mind-phdays-3/87



Attack vector vs patchAttack vector Patch

It suffices to find a single path from the entry point to the PVO and a single set of values of vector variables

It is necessary to find all paths from the entry point to the PVO and all sets of values of vector variables

The type of the injection point can be figured out by using heuristics

The type of the injection point must be figured out strictly along with its semantics

The availability of the application may be compromised

The application should stay available

Strong finding the type of the injection point

Step #1: replace each taint source in the vulnerable expression by an unique special character:

<a href='∅'>

Step #2: parse the string with the modified parser of an island language that allows using special characters in the arbitrary token.

Step #3: find in the parsing tree the vertex containing a special character and define the type of the injection point on the basis of the vertex type.

Step #4: According to the type injection point define its semantics.

Opening bracket: <

Tag name: a

Attribute definition

Attribute name: href

Assignment sign

2-quoted attr. value: Closing bracket: >

Strong finding the type of the injection point

2-quoted attribute (semantic: URL) value

Keeps the semantics of the code- The priority of countermeasures:

1) Typing2) Sanitizing3) Validation

- Consideration of all conditions for executing the PVO as well as values of its arguments during typing and sanitizing

- Applying countermeasures exactly at the source of the vulnerability

Typing

Typing

2-quoted attribute(semantic: URL) value- typing is possible

Recording a dangerous

value to parm

Typing

Sanitizing

Sanitizing

Text(semantic: TEXT) value- typing is not possible,sanitizing may be applied

Recording a dangerous

value to parm

Sanitizing

Validation

Validation

Typing and sanitizing are not possible, validation is possible

Validation

Any patches for other attack types?√ Injections

√ Buffer Overflow

√ Heap Overflow

√ Integer Overflow

? Memory Management Attacks

? Access Control Attacks

? Session Fixation

? CSRF

x Race Conditions

x Domain(Logical) Attacks

When do we want it?

Right now!!!

{DEMO}

Any questions?

Vladimir Kochetkov

[email protected]@kochetkov_v

Application Inspector/Compiling Applications Analysis/Team LeadPositive Technologies

Automated Patching for Vulnerable Source Code

Documents