note | Fuzzing basic terms

1. Vulnerability

In short, vulnerabilities are the result of three kinds of flaws:

• Implementation errors (e.g., overflows);
• Design flaws (e.g., weak authentication), missing authorization checks;
• Configuration errors or other system or network infrastructure errors.

2. Basic Bug Categories

• Memory corruption errors
  Memory corruption errors have been the most prevalent and effective method for maliciously exploiting a remote or a local computer system. If memory can be corrupted often execution can be redirected to attacker supplied code.

• Stack Overflow (due to improper bounds checking when a memory write operation takes place)
• Format String Errors
• Integer Errors
• Off-by-One
• Heap Overflow ( when data is written beyond the boundary of an allocated chunk of memory on the heap)
• (Uninitialized)Stack or Heap Variable Overwrites
• Other Memory Overwrites

As we have seen from stack, heap, and variable overflows, any time an attacker can modify the internal memory of an application in unintended ways, bad things can happen, including the attacker’s gaining complete control of the system.

• Web Applications

• PHP File Inclusions (R F I)
• SQL Injections
• X Path, X Query, and Other Injection Attacks
• Cross-Site Scripting

• Brute Force Login
• Race Condition
  (due to unforeseen timing events. It’s sometimes called time-of-check-to-time-of-use bug.)
• Denial of Service
• Session Hijacking
• Man in the Middle
• Cryptographic Attacks

3. Bug Hunting Techniques

Once a bug has been identified, the process of creating an exploit begins.

• Reverse Engineering
  Turn compiled binary code back into its high-level representation to understand the product, so that implementation errors can be sought out ( this is nontrivial and potentially time consuming ).
  Next, manually determine the purpose of a block of assembly instructions.

• Source Code Auditing
  Involves automated tools, plus manual verification, to search source code for bugs. The process will vary from language to language.

• Fuzzing
  One of the main strengths of fuzzing is that if an input crashes an application, a problem definitely exists in the application (no false positives).

4. Fuzzing

• Coverage is an important term that is used in testing, and the same applies for fuzzing. From a vulnerability analysis perspective, coverage typically refers to simple code coverage – that is, how many lines of the existing source code or compiled code have been tested or executed during the test. Coverage could also measure path, branch permutations, or a variety of other code coverage metrics.
• A Attack Surface is the amount of code actually exposed to an attacker. Some code is internal and cannot be influenced by external data, and this code should be tested, but cannot be externally fuzzed.
• A Trust boundary is any place that data or execution goes from one trust level to another, where a trust level is a set of permissions to resources.
• Input source and input space are similar terms that refer to how data will be generated to the application to be fuzzed.
• Hostile data. To find a vulnerability, you need to know what type of inputs will trigger the flaws. And when you know why these inputs will cause an exception or a crash, you will be able to optimize the tests that you need to do.