Vulnerability analysis

Vulnerability analysis of a source code is a daunting task especially if it is your first time! There are thousands of questions in your mind:

  • Were should I begin my vulnerability analysis?
  • What should I look for?
  • Should I go deep and jump from one function to the other?
  • How can I be sure whether I did the vulnerability analysis correctly?
  • Should I use tools for vulnerability analysis? Are tools reliable to count on?

And much more…

Well in this article I am going to answer these questions.

In my threat modeling article I explained about the preassessment process and how you can plan your way. If you have some sort of information to begin your work starts from there, but sometimes there are no documents or you don’t have access to them and your only asset is the source code itself. In these situations the first thing you should do before the real code auditing begins is to check the directory structure and the start file (like main method in C). Try to locate any modules that process input (from UI, file or network), deals with the authentication or manage the memory. If the application implements a protocol or an encryption method, identify them too. These files have priority over other files.

After spotting your start points, you should begin your work based on a typical strategy. Generally there are two approaches: either you focus on a file you’re examining or you jump from one function or object to the other. Experts normally acquire the first method! The first category of strategies starts at the beginning of a security relevant algorithm, a file or a class. You assess lines one after the other without jumping from one function to the other. This form of assessment is essential to find logical vulnerabilities. In the second categories of strategies you exactly trace the flow of data and control. For example you run a fuzz tester and you find a candidate point (a point where a malicious input can cause damage) and then trace that input either forward or backward (depending on the place of function) to find a vulnerability. There are tools that can help you do fuzz testing to identify a candidate point, points where a vulnerable code exists e.g. strcpy. Also there are source code analysis tools that are able to identify candidate points.

A day may come that a source code analysis tool do all the vulnerability analysis task but so far these tools only can spot conventional vulnerabilities so use them as a complement to your works not as a replacement. Use tools to identify vulnerable candidate points and then audit them. Bear in mind that Logical and architectural vulnerabilities can only be detected after you learn enough from the application. After a general understanding of the application forms, you should document your findings and threat model the application. Then try to locate architectural vulnerabilities.

Sometimes you are not sure about your vulnerability analysis and this happens a lot at your first experiences. The only way to ensure your assessment is desk-checking. In desk-checking you start by writing all the test scenarios possible (based on input parameters). Then you run the function on a paper! This means you draw a table like this:

Table 4-19(The Art of Software Security Assessment book). Desk-Check of Algorithm

Statement

i

buf

c

for(i = 0;

0

-

-

n = read(sock, &c, 1);

0

-

A

if(i < length) buf[i] = c;

0

buf[0] = 'A'

A

i++;

1

-

A

n = read(sock, &c, 1);

1

-

B

if(i < length) buf[i] = c;

1

buf[1] = 'B'

B

i++;

2

-

B

n = read(sock, &c, 1);

2

-

C

if(i < length) buf[i] = c;

2

buf[2] = 'B'

C

i++;

3

-

C

n = read(sock, &c, 1);

3

-

D

if(i < length) buf[i] = c;

3

buf[3] = 'B'

D

i++;

4

-

D

n = read(sock, &c, 1);

4

-

E

if(i < length) buf[i] = c;

4

-

E

i++;

5

-

E

n = read(sock, &c, 1);

5

-

F

if(i < length) buf[i] = c;

5

-

F

i++;

6

-

F

n = read(sock, &c, 1);

6

-

\n

if(c == '\n') break;

6

-

\n

buf[i] = '\0'

6

buf[6] = '\0'

\n

The first column contains the statements and the rest are concerned variables. For desk checking you must concentrate not on the normal behavior of the function but unexpected paths and inputs that are suspicious. If you can run the source code and you have a debugger you can check your scenario by manipulating inputs in the debugger and tracking the result. One better option is using unit testing if the language is has such feature. One important point when desk-checking is removing impossible scenarios. Sometimes the function you’re testing is being called from one point and in that point you just see that your function will never be called by a special input so you don't need to check that test case at all.

Read 937 times Last modified on Monday, 08 June 2015 10:58
Rate this item
0
(0 votes)
About Author
Leave a comment

Make sure you enter the (*) required information where indicated. HTML code is not allowed.

Advanced Programming Concepts
News Letter

Subscribe our Email News Letter to get Instant Update at anytime