automated patching for vulnerable source code
Post on 08-Aug-2015
384 Views
Preview:
TRANSCRIPT
Automated Patching for Vulnerable Source Code
Vladimir KochetkovApplication Inspector/Compiling Applications
Analysis/Team LeadPositive Technologies
Positive Hack Days V
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
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)
… …
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
Request.Params["cond1"] == "true" �֜ { parm' א { ε �֜ Request.Params["parm1"] } }
Symbolic Execution Context Graph
Request.Params["cond1"] != "true" �֜ { parm' א { Request.Params["cond1"] != "true" �֜ Request.Params["parm1"] } }
Symbolic Execution Context Graph
Request.Params["cond1"] != "true" && Request.Params["cond2"] == "true" �֜ { parm' א { Request.Params["cond1"] != "true" �֜ Request.Params["parm1"] } }
Symbolic Execution Context Graph
Request.Params["cond1"] != "true" && Request.Params["cond2"] != "true" �֜ { parm' א { Request.Params["cond1"] != "true" �֜ Request.Params["parm1"] } }
Symbolic Execution Context Graph
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>" } }
Symbolic Execution Context Graph
Using the SECG for each PVO we can...
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"] + "\">" )
Vulnerability formulaRequest.Params["cond1"] != "true"&&
Request.Params["cond2"] == "true" ⇒
Response.Write( "<a href=\"" + Request.Params["parm2"] + "\">" )
What value of Request.Params["parm2"] will result in exceeding the limits of the token?
<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
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"] + "\">" )
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...
-
-
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"
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
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
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
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 LeadPositive Technologies
top related