Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (10)
Similaire à Distributed Fuzzing Framework Design
Similaire à Distributed Fuzzing Framework Design (20)
Distributed Fuzzing Framework Design
- 1. Distributed Fuzzing bannedit Tuesday, October 9, 12
- 2. Who am I? • David D. Rude II aka bannedit • twitter: @bannedit0 • email: bannedit0@gmail.com • iDefense Labs • Metasploit Developer Tuesday, October 9, 12
- 3. Overview • What is fuzzing? • Why use it? • Distributed fuzzing • Designing a solution • Components • Future ideas • Questions Tuesday, October 9, 12
- 4. What is fuzzing? A testing technique which throws inputs at a target application. Inputs are intentionally malformed with the typical goal of causing abnormal application behavior. Tuesday, October 9, 12
- 5. Why use it? • Automated bug discovery • Can be as simple or complex as wanted • Effective • Blackbox testing • No knowledge of the code required Tuesday, October 9, 12
- 6. Distributed fuzzing • Spread the workload • Dig deeper faster (more test cases / second) • Collaborative fuzzing • Fuzzer independent • Run multiple fuzzers • Multiple target applications Tuesday, October 9, 12
- 7. Designing a solution • Easy deployment • Start/Stop/Pause control • Avoid VMWare specifics • Realtime monitoring • Client Server model (RPC) Tuesday, October 9, 12
- 8. Components Database Fuzzer Web Interface Node RPC Tuesday, October 9, 12
- 9. Database DB Schema Node Crash id integer id integer name string module string ip string disasm string fuzzer_id integer has many crash_hash string debug_output string node_id integer has one Fuzzer id integer name string description string Tuesday, October 9, 12
- 10. Web Interface • Easy creation of nodes • Deployment of fuzzers • RPC client • Database stores crash data (downloadable) • Realtime monitoring of node health/status • Analytics? Tuesday, October 9, 12
- 11. Node • Is a Virtual Machine • Runs the fuzzer • Monitors the application • RPC server • Reports to the web interface (RPC client) • Crash data • Health status Tuesday, October 9, 12
- 12. Fuzzer • Sends inputs to the target application • Might need scripts to enforce some rules (framework support) • Might need scripts to send generated inputs (framework support) • Independent of the actual fuzzing framework Tuesday, October 9, 12
- 13. Debugger • Monitors the target application for abnormal behavior • Windbg is a good option • I’m working on a scriptable debugger for my framework (Rabbit) • Log crashes • Crashes are not the only abnormal behavior to watch for (Launching other applications, file creation, etc) Tuesday, October 9, 12
- 14. RPC Interface • The glue that holds it all together • Web Interface - Client • Node - Server • Allows for Start, Stop, Pause control • Reporting of status, crashes Tuesday, October 9, 12
- 15. Scripts • Run the fuzzer • Send output of fuzzer to target app • Attach the debugger to the target app • Staging source files Tuesday, October 9, 12
- 16. Deployment • Create VM • Install target software • Configure the fuzzer • Copy the scripts, fuzzer, and debugger to VM • Avoid VMWare specifics or make it modular so other VM products can be accommodated • SMB file shares could be a decent solution Tuesday, October 9, 12
- 17. Future ideas • RPC client debug console • Scriptable debugger (Rabbit... WIP) • Code coverage tools • Sample file reduction • Crash binning Tuesday, October 9, 12