codEX Project
Normalizing as the first step to improve
Vulnerability Identification

Vulnerabilities are given under some circumstances only. The vulnerability classes addressed within the codEX analysis are the following. Every vulnerability has some attributes which define the data source and destination, the control behaviour and the conditions.

Cross Site Scripting:
¦ Source: any
¦ Destination: output function (echo, print, ...)
¦ Control: executed
¦ Condition: reserved (>, ', ", ...)

SQL Injection:
¦ Source: any
¦ Destination: sql function
¦ Control: executed
¦ Condition: reserved (', OR, --, ...)

Buffer Overflow:
¦ Source: any
¦ Destination: static/short buffer
¦ Control: executed
¦ Condition: length (>buffer)

Format String:
¦ Source: any
¦ Destination: format function ([v]printf, ...)
¦ Control: executed
¦ Condition: reserved (%)


By combining the control and data flow analysis it is possible to identify these vulnerabilities, their infection and attack vector [Ruef 2007]. According to the following code the varget test is an untrusted input from $_GET. It is first introduced within the control condition from 003:003:012 to 003:006:031. The real vulnerability can be identified within the code block from 005:011:070 to 007:015:116, where the untrusted data is re-used within an output command. The condition for a cross site scripting vulnerability is met and therefore the injection and attack vector in 006:014:113 determined.

001:001:001 .BEGIN_PHP:
003:002:011 if
003:003:012 childopen
003:004:026 varget test
003:005:027 equal
003:006:031 childclose
003:007:032 then
004:008:042 output
004:009:043 string "Variable set to 1"
005:010:065 else
005:011:070 then
006:012:080 output
006:013:081 string "Variable set to "
006:014:113 varget test
007:015:116 fi
009:016:122 .END_PHP;


The discussed vulnerability is only executable if the control structure forks to the else block. This is depending on the input itself which should not be equal 1. Because the malicious input data "<script>alert(document.cookie)<script>" fullfills this condition, a successfull attack is possible. Thus, a detailed analysis will bring up the following results for the analyzed PHP source code:

Cross Site Scripting:
¦ Source: varget test (006:014:113)
¦ Destination: output (006:012:080)
¦ Control: else (005:010:065)
¦ Condition: any input allowed


The other vulnerabilities were not found because of the following reasons. There is no SQL injection because no SQL function or database connection is used. All the data is static or comes from the user. A buffer overflow was also not found because PHP itself is not vulnerable to such attacks (however, the Zend engine might be). Furthermore a format string vulnerability was also not found because not such function was used. The cross site scripting vulnerability described before is the only found vulnerability within the discussed source code.

At least, the (semi-)automated generation of an exploit would be possible. In this case of a cross site scripting attack within a web application the following link could be used to prove the vulnerability for sure. The proof is given if the access attempt to this URL brings up a JavaScript alert box which contains the used cookies for the target site (in this case an empty cookie set is expected because none of the were used within the code):

http://127.0.0.1/input.php?test=<script>alert(document.cookie)<script>


As you can see it is possible with codEX to determine vulnerability within a detailed source code analysis. It is not easy and requires many steps of abstraction and analysis. But in the end a very accurate statement about the real-world security of an application can be made. Technical security analysis can be brought to a new level of professionality.

Bibliography

Ruef, M. (2007), Die Kunst des Penetration Testing, C&L Verlag, Böblingen, ISBN-13 978-3936546491