Automated Patching for Vulnerable Source Code

Automated Patching for
Vulnerable Source Code
Vladimir Kochetkov
Application Inspector/Compiling Applications Analysis/Team Lead
Positive Technologies
Positive Hack Days V

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

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 CSRF
Integer Overflow Concurrency
Memory Management Domain(Logical)
… …

Symbolic Execution
Context Graph!

Disclaimer
There is just a review. Further details will be presented at
SIBECRYPT’15
Novosibirsk, 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["cond2"] == "true" {
parm' {
}
}

&&
parm' {
}
}

parm' {
Request.Params["cond2"] == "true"
||
"<div>Harmless value</div>"
}
}

parm' {
||
}
}
Using the SECG for each PVO we can...

Figure out a vulnerability
formula!

Vulnerability formula
Request.Params["cond1"] != "true" ⇒
Response.Write(
"<a href="" +
parm ∈ {
Request.Params["cond2"] == "true" ⇒
;
}
+ "">"
)

Response.Write(
"<a href="" +
parm ∈ {
}
+ "">"
)

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

&&
Response.Write(
)
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["parm2"] == ""><script>alert(0)</script>"
||
Request.Params["parm2"] == ""onmouseover="alert(0)") ⇒
Response.Write(
)

&&
&&
(Request.Params["parm2"] == ""><script>alert(0)</script>"
||
Request.Params["parm2"] == ""onmouseover="alert(0)") ⇒
Response.Write(
)
As a result of finding the values unknown in the context of the
vulnerability formula you can get...
-
-

The contextual attack vector
Vulnerable expression:
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"

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 injection
http://www.slideshare.net/kochetkov.vladimir/how-to-develop-
a-secure-web-application-and-stay-in-mind-phdays-3/87
• Typing
• Validation
• Sanitization

Attack vector vs patch
Attack 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) Typing
2) Sanitizing
3) 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
2-quoted attribute
(semantic: URL) value
- typing is possible
Recording a dangerous
value to parm

Sanitizing
Text
(semantic: TEXT) value
- typing is not possible,
sanitizing may be applied
Recording a dangerous
value to parm

Validation
Typing and sanitizing
are not possible,
validation is possible

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

Any questions?
Vladimir Kochetkov
vkochetkov@ptsecurity.com
@kochetkov_v
Application Inspector/Compiling Applications Analysis/Team Lead
Positive Technologies

Automated Patching for Vulnerable Source Code

Automated Patching for Vulnerable Source Code

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Automated Patching for Vulnerable Source Code

Similar to Automated Patching for Vulnerable Source Code (20)

More from Vladimir Kochetkov

More from Vladimir Kochetkov (14)

Automated Patching for Vulnerable Source Code