Vulnerability Assessment

Vulnerability Assessment.

Hello guys I'm here trying to share some information about code auditing for vulnerability assessment. I'm gonna talk about the strategies used to perform the best code review as fast as possible, and hopefully finding the vulnerability at the end.

Let's start by the review process, these are the steps you can follow in every audit :

Preassessment  : here you setup a plan and a target (software) to review, collecting as much information as you can about your target.

Application review : the majority of the work apply here,  different strategies can work depending on the application access.

Documentation and analysis : you document everything you find when auditing the code, what I mean by everything is for example a new code-path you discovered or maybe a faulty condition in the code.

Remediation support : this step is all about helping developers or anyone that have to act based on your findings (help the developer to patch the vulnerability)

Now depending on what you have, the code auditing process can take 1 week or 4 months, it's all depends on the application access.

There are 5 categories for the application access.

Source only : you only have the source code, no build environment.

Binary only : you only got the binary, all you can do is reverse engineering. This type of access is common for closed-source commercial software.

Both : This type of access is the best you can have.

Checked build : it's same as "binary only" but here you have debugging symbols on it, developers add symbols to facilitate debugging but exploit developers benefit from it too.

Strict black box : to be honest this type of access is pain in the ass xD you can do nothing but blind techniques, fuzz it all the night and wait for the crash to occur, then analyze it.

Now let's talk about the strategies used. You got to choose the strategy to apply depending on the target, time and how much you want to understand the software.

Before digging into the source code the first thing you want to do is design review.

Let's say you want to audit a software and you begin by reading the documentation and you found that if you provide a name that starts with /bin/ to the target software it will be executed immediately, then you tested /bin/sh and it works, congrats RCE xD

That's called design flaw, you already done no need to search for memory corruption or UAF vulnerabilities.

Now you have to choose a strategy  it can be one of these (just to review the application not to audit it) : 

Top-Down approach (from the start to the end of the source code line by line).

Bottom-Up approach.

Hybrid.

Now that you have feelings that you understand a little bit what's going on inside the software, you can jump into code-auditing.

 Code-Auditing strategies :

Code comprehension strategies : these are organized around discovering vulnerabilities by directly analyzing the code. You can use these to trace malicious input (follow your input around the functions and the branches of the software) buffer overflows for examples, CCS are used to analyze modules, classes, objects, algorithms (it can be  cryptography). 

        These are the characteristics of these strategies : 

        - Speed -> Very slow.

        - Comprehension impact -> Very high.

        - Difficulty -> Hard.

Candidate point strategies :

        Create a list of potential issues and examine the source code 

        to determine if they are present is the source code.

        for example :

        cat ./source_code.c | grep gets

        easy, huh xD

        in these strategies you can use fuzzers, source code analysis 

        tools, simple lexical candidate points (the example given 

        above), or binary candidate points (if you don't have the 

        source code)

        Here you start from the vulnerability and go backward 

        (Bottom-Up)

        - Speed -> Medium.

        - Comprehension impact -> Low.

        - Difficulty -> Easy.

Design generalization strategies : intended for analyzing high level logic bugs, and implementation            vulnerabilities that can not be found by looking at the source code. Here you make the system looks         simple by system modeling, and you make hypothesis about what the function is doing maybe                from  its name and you test it to see if it's doing exactly what's intended to do.

        - Speed -> Medium.

        - Comprehension impact -> High.

        - Difficulty -> Hard.

Now comes the time when you want to document your findings (for future research in the same target for example, or the vulnerability you found isn't enough to trigger RCE so you document it and wait until you find another one to combine the two)

Documentation format : 

    Location of the vulnerability.

    Vulnerability class (BOF, OOB, Logic bug ... ).

    Vulnerability description.

    Prerequisites (conditions to access the code branch where the vulnerability resides)

    Probability (if it's a bruteforce solution, for example if you're bruteforcing 1 byte the probability is     1/256)

    Risk (the damage)

They are billion techniques out there, and ton of vulnerabilities yet to be found.

And everything is open-source if you try hard enough.