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