Fuzzer 이론 정리

Fuzzing for Software Security Testing and Quality Assurance (Artech House Information Security and Privacy)

Coverage -  how many lines of the existing source code or compiled code has been tested or executed during the test.

Attack Surface - the amount of code actually exposed to an attacker. (example : Examples of this include when a network server parses a configuration file or initially binds to a socket.)

trust boundary -  any place that data or execution goes from one trust level to another, where a trust level is a set of permissions to resources.

Attack heursitics - These are known techniques for finding bugs in applications, normally based on the types of bugs discovered in the past.

Parse error example

[ user jared\r\n ] 

-> desired input

1. user jared0x00 

-> using null byte

2. pass jared\r\n user jared\r\n 

-> out of order

3. \xff\xfe\x00\x01\x42\xb5... 

-> particular character parse error(random binary data)

4. pass jared\r\n

-> logical bug

5. pass jared\r\n / get [1] files: {{../../../../etc/password\r\n 

-> Wrong number of statement helpers such as  ‘../’, ‘{’, ‘(’, ‘[’,

6. user jared\r (@ 10000 pkts/second with no read for server response)

->  Timing issue with incomplete command termination.

Goal of Fuzzer..?

The goal is to cover every unique test case, input space (without too much duplication or unneeded sessions), and to log the ones that succeed in causing the target to fail in some way. It is still an open question as to how many test cases are “enough,” but using a metric based approach and code coverage results, it may be possible to shed light on this difficult decision.

Basic Bug

Memory Corruption Errors

Web Applications

Brite Force Login

Race Conditions

Denials of Service

Session Hijacking

Man in the Middle

Cryptographic Attack

Defence

Reduce code complexity

Source code reviews (example, in C, strcpy() should never be used.)

Quality control - All code should be thoroughly tested.

Code reuse - If there are snippets that have been well tested, reuse is better than a rewrite when applicable.

Secure input/output handling - All user input should be rigorously verified before being used by the application.

Canonicalization - Input string auditing may require the use of canonicalization APIs to defend against such tricks (tricks example : '/etc/ passwd' is the same as '/etc/.///passwd' in Unix system)

Principle of least privilege

Assume the worst

Encrypt/Authenticate - Encrypt everything transmitted over networks (when possible). Mistakes are often made in home-grown encryption.

Stay up to date

Input Verification

- Whitelist

- Blacklist

- Terminate on input problem

- Filter input

- Formal grammar

Software Overflow Protection

Hardware Overflow Protection

Hardware DEP

Software DEP

Secure Bit

GS

SafeSEH

PAX and ExecShield

StackGuard

** Vulnerability List : https://vulncat.hpefod.com/ko