https://wiki.owasp.org/api.php?action=feedcontributions&feedformat=atom&user=Fthiery 2026-04-26T15:05:48Z User contributions MediaWiki 1.27.2 https://wiki.owasp.org/index.php?title=Guide_Introduction&diff=17903 2007-04-18T11:50:40Z

<p>Fthiery: </p> <hr /> <div>[[Guide Table of Contents]]<br /> __TOC__<br /> <br /> Welcome to the OWASP Guide 3.0! <br /> <br /> Web application security is an essential component of any successful project, whether open source PHP applications, web services such as straight through processing, or proprietary business web sites. Hosters (rightly) shun insecure code, and users shun insecure services that lead to fraud. <br /> <br /> The aim of this Guide is to allow businesses, developers, designers and solution architects to produce secure web applications. If done from the earliest stages, secure applications cost about the same to develop as insecure applications, but are far more cost effective in the long run.<br /> <br /> ==Developing Secure Applications ==<br /> <br /> Unlike other forms of security (such as firewalls and secure lockdowns), web applications have the ability to make a skilled attacker rich, or make the life of a victim a complete misery. At this highest level of the OSI software map, traditional firewalls, and other controls simply do not help. The application itself must be self-defending. The Guide can help you get there. <br /> <br /> The Guide has been written to cover all forms of web application security issues, from old hoary chestnuts such as SQL injection, through modern concerns such as AJAX, phishing, credit card handling, session fixation, cross-site request forgeries, compliance, and privacy issues.<br /> <br /> ==Improvements in this edition ==<br /> <br /> This latest edition of the Guide builds upon the successful release of the Guide 2.0 at BlackHat Las Vegas in July 2005. With fearless editing by our publisher, No Starch Press, this edition aims to be concise and accurate. There are three new chapters, and a great deal of new content throughout. <br /> <br /> Each chapter is organized into roughly three sections:<br /> <br /> * Best practices – Practices or features every application should possess<br /> * Secure patterns – Optional secure patterns, such as the best way to do password self-help<br /> * Anti-patterns – if you have these in your code, you are more insecure<br /> <br /> ==How to use this Guide ==<br /> <br /> This Guide is a large work as it aims for completeness. The best way to treat the Guide is as a dictionary of best practices. However, web application security is like a language – without some form of context – it is nearly impossible to speak it well. Therefore, readers are well advised to read the “Security Principles” chapter in its entirety. <br /> <br /> ==Updates and errata ==<br /> <br /> The Guide will likely have errors and deficiencies. We will publish errata on our web site from time to time if you’d like to keep your copy up to date.<br /> <br /> If you have any comments or suggestions on the Guide, please e-mail the Guide mail list (see our web site for details) or contact me directly. <br /> <br /> ==With thanks ==<br /> <br /> I wish to extend my thanks to the many authors, reviewers, and editors for their hard work in producing this guide. We stand on the shoulders of giants, and this Guide is no exception.<br /> <br /> Lastly, I wish to thank No Starch Press, particularly our editors and Bill Pollock for believing in us, and bringing our community’s text into a publishable state. <br /> <br /> Andrew van der Stock, vanderaj@owasp.org<br /> Melbourne, Australia<br /> December, 2005<br /> <br /> <br /> [[Guide Table of Contents]]<br /> [[Category:OWASP_Guide_Project]]</div>

Fthiery https://wiki.owasp.org/index.php?title=Fuzzing&diff=17393 2007-03-22T15:26:19Z

<p>Fthiery: </p> <hr /> <div>''Fuzz testing'' or ''Fuzzing'' is a Black Box software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection in an automated fashion.<br /> <br /> == A trivial example: ==<br /> <br /> Lets's consider an integer in a program, which stores the result of a user's choice between 3 questions. When the user picks one, the choice will be 0, 1 or 2. Which makes three practical cases. But what if we transmit 3, or 255 ? We can, because integers are stored a static size variable. If the default switch case hasn't been implemented securely, the program may crash and lead to &quot;classical&quot; security issues: (un)exploitable buffer overflows, DoS, ...<br /> <br /> Fuzzing is the art of automatic bug finding, and it's role is to find software implementation faults, and identify them if possible.<br /> <br /> == History ==<br /> <br /> Fuzz testing was developed at the University of Wisconsin Madison in 1989 by Professor Barton Miller and his students. Their (continued) work can be found at http://www.cs.wisc.edu/~bart/fuzz/ ; it's mainly oriented towards command-line and UI fuzzing, and shows that modern operating systems are vulnerable to even simple fuzzing.<br /> <br /> == Fuzzer implementations ==<br /> <br /> A fuzzer is a program which injects automatically semi-random data into a program/stack and detect bugs.<br /> <br /> The data-generation part is made of generators, and vulnerability identification relies on debugging tools. Generators usually use combinations of static fuzzing vectors (known-to-be-dangerous values), or totally random data. New generation fuzzers use genetic algorithms to link injected data and observed impact. Such tools are not public yet.<br /> <br /> == Comparison with cryptanalysis ==<br /> <br /> The number of possible tryable solutions is ''the explorable solutions space''. The aim of cryptanalysis is to reduce this space, which means finding a way of having less keys to try than pure bruteforce to decrypt something. <br /> <br /> Most of the fuzzers are:<br /> <br /> - protocol/file-format dependant<br /> <br /> - data-type dependant<br /> <br /> <br /> Why? <br /> <br /> <br /> * First, because the fuzzer has to connect to the input channel, which is bound to the target.<br /> <br /> * Second, because a program only understands structured-enough data. If you connect to a web server in a raw way, it will only respond to listed commands such as GET (or eventually crash). It will take less time to start the string with &quot;GET &quot;, and fuzz the rest, but the drawback is that you'll skip all the tests on the first verb.<br /> <br /> <br /> In this regard, Fuzzers try to reduce the number of unuseful tests, i.e. the values we already know that there's little chance they'll work: you reduce impredictibility, in favor of speed.<br /> <br /> == Attack types ==<br /> <br /> A fuzzer would try combinations of attacks on:<br /> <br /> - numbers (signed/unsigned integers/float...)<br /> <br /> - chars (urls, command-line inputs)<br /> <br /> - metadata : user-input text (id3 tag)<br /> <br /> - pure binary sequences<br /> <br /> <br /> A common approach to fuzzing is to define lists of &quot;known-to-be-dangerous values&quot; (''fuzz vectors'') for each type, and to inject them or recombinations.<br /> <br /> - for integers: zero, possibly negative or very big numbers<br /> <br /> - for chars: escaped, interpretable characters / instructions (ex: For SQL Requests, quotes / commands...)<br /> <br /> - for binary: random ones<br /> <br /> Please refer to OWASP's Fuzz Vector's resource[http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors] for real-life fuzzing vectors examples and methodology.<br /> <br /> <br /> Protocols and file formats imply norms, which are sometimes blurry, very complicated or badly implemented : that's why developers sometimes mess up in the implementation process (because of time/cost constraints). That's why it can be interesting to take the opposite approach: take a norm, look at all mandatory features and constraints, and try all of them; forbidden/reserved values, linked parameters, field sizes. That would be ''conformance testing oriented'' fuzzing.<br /> <br /> == Application fuzzing ==<br /> <br /> Whatever the fuzzed system is, the attack vectors are within it's I/O. For a desktop app:<br /> <br /> - the UI (testing all the buttons sequences / text inputs)<br /> <br /> - the command-line options<br /> <br /> - the import/export capabilities (see file format fuzzing below)<br /> <br /> For a web app: urls, forms, user-generated content, RPC requests, ...<br /> <br /> == Protocol fuzzing ==<br /> <br /> A protocol fuzzer sends forged packets to the tested application, or eventually acts as a proxy, modifying requests on the fly and replaying them.<br /> <br /> == File format fuzzing ==<br /> <br /> A file format fuzzer generates multiple malformed samples, and opens them sequentially. When the program crashes, debug information is kept for further investigation.<br /> <br /> One can attack:<br /> <br /> <br /> - the parser layer (container layer): file format constraints, structure, conventions, field sizes, flags, ...<br /> <br /> - the codec/application layer: lower-level attacks, aiming at the program's deeper internals<br /> <br /> One example of file format related vulnerabilities: MS04-028[http://www.microsoft.com/technet/security/bulletin/ms04-028.mspx] (KB833987) Microsoft's JPEG GDI+ vulnerability was a zero sized comment field, without content.<br /> <br /> <br /> Surprisingly, file format fuzzers are not that common, but tend to appear these days; some examples:<br /> <br /> * A generic file format fuzzer : Ilja van Sprundel's mangle.c[http://www.digitaldwarf.be/products/mangle.c]; &quot;it's usage is very simple, it takes a filename and headersize as input. it will then change approximatly between 0 and 10% of the header with random bytes.&quot; (from the author)<br /> <br /> * Zzuf can act as a fuzzed file generator, http://sam.zoy.org/zzuf/<br /> <br /> * One may use tools like Hachoir[http://hachoir.org/] as a generic parser for file format fuzzers development.<br /> <br /> == Fuzzers advantages ==<br /> <br /> ''The great advantage of fuzz testing is that the test design is extremely simple, and free of preconceptions about system behavior'' (from Wikipedia [http://en.wikipedia.org/wiki/Fuzz_testing]).<br /> <br /> The systematical/random approach allows this method to find bugs that would have often been missed by human eyes. Plus, when the tested system is totally closed (say, a SIP phone), fuzzing is one of the only means of reviewing it's quality.<br /> <br /> == Fuzzers limitations ==<br /> <br /> Fuzzers usually tend to find simple bugs; plus, the more a fuzzer is protocol-aware, the less weird errors it will find. This is why the exhaustive / random approach is still popular among the fuzzing community.<br /> <br /> Another problem is that when you do some black-box-testing, you usually attack a closed system, which increases difficulty to evaluate the dangerosity/impact of the found vulnerability (no debugging possibilities).<br /> <br /> == Why Fuzz? ==<br /> <br /> The purpose of fuzzing relies on the assumption that there are bugs within every program, which are waiting to be discovered. Therefore, a systematical approach should find them sooner or later.<br /> <br /> Fuzzing can add another point of view to classical software testing techniques (hand code review, debugging) because of it's non-human approach. It doesn't replace them, but is a reasonable complement, thanks to the limited work needed to put the procedure in place.<br /> <br /> Recent fuzzing initiatives:<br /> <br /> - The Month of Kernel Bugs[http://projects.info-pull.com/mokb/], which revealed an Apple Wireless flaw; see here[http://kernelfun.blogspot.com/]; mainly used file system fuzzing tools<br /> <br /> - The Month of Browser Bugs[http://browserfun.blogspot.com/] (review here[http://osvdb.org/blog/?p=127]); number of bugs found: MSIE: 25 Apple Safari: 2 Mozilla: 2 Opera: 1 Konqueror: 1; used DHTML, Css, DOM, ActiveX fuzzing tools<br /> <br /> == Fuzzers from OWASP ==<br /> <br /> Fuzzing with WebScarab [http://www.owasp.org/index.php/Fuzzing_with_WebScarab]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br /> <br /> JBroFuzz [http://www.owasp.org/index.php/JBroFuzz]: a stateless network protocol fuzzer<br /> <br /> WSFuzzer [http://www.owasp.org/index.php/WSFuzzer]: real-world manual SOAP pen testing tool<br /> <br /> == Technical resources on OWASP ==<br /> <br /> Fuzzing vectors [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors]<br /> <br /> == Sources ==<br /> <br /> Wikipedia article [http://en.wikipedia.org/wiki/Fuzz_testing]<br /> <br /> Fuzzing-related papers [http://www.threatmind.net/secwiki/FuzzingPapers]<br /> <br /> == Fuzzing tools ==<br /> <br /> Huge tools list @ scadasec [http://www.scadasec.net/secwiki/FuzzingTools]<br /> <br /> The ultimate fuzzers list @ infosec [http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html]<br /> <br /> Another list @ hacksafe<br /> [http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/]<br /> <br /> The fuzzing mailing list [http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing]<br /> <br /> == Commercial products ==<br /> <br /> Codenomicon's product suite: [http://www.codenomicon.com/products/all.shtml]<br /> <br /> Beyond Security's beSTORM product: [http://www.beyondsecurity.com/bestorm_overview.html]</div>

Fthiery https://wiki.owasp.org/index.php?title=Fuzzing&diff=15745 2007-01-23T10:20:13Z

<p>Fthiery: /* Why Fuzz? */</p> <hr /> <div>''Fuzz testing'' or ''Fuzzing'' is a Black Box software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection in an automated fashion.<br /> <br /> == A trivial example: ==<br /> <br /> Lets's consider an integer in a program, which stores the result of a user's choice between 3 questions. When the user picks one, the choice will be 0, 1 or 2. Which makes three practical cases. But what if we transmit 3, or 255 ? We can, because integers are stored a static size variable. If the default switch case hasn't been implemented securely, the program may crash and lead to &quot;classical&quot; security issues: (un)exploitable buffer overflows, DoS, ...<br /> <br /> Fuzzing is the art of automatic bug finding, and it's role is to find software implementation faults, and identify them if possible.<br /> <br /> == History ==<br /> <br /> Fuzz testing was developed at the University of Wisconsin Madison in 1989 by Professor Barton Miller and his students. Their (continued) work can be found at http://www.cs.wisc.edu/~bart/fuzz/ ; it's mainly oriented towards command-line and UI fuzzing, and shows that modern operating systems are vulnerable to even simple fuzzing.<br /> <br /> == Fuzzer implementations ==<br /> <br /> A fuzzer is a program which injects automatically semi-random data into a program/stack and detect bugs.<br /> <br /> The data-generation part is made of generators, and vulnerability identification relies on debugging tools. Generators usually use combinations of static fuzzing vectors (known-to-be-dangerous values), or totally random data. New generation fuzzers use genetic algorithms to link injected data and observed impact. Such tools are not public yet.<br /> <br /> == Comparison with cryptanalysis ==<br /> <br /> The number of possible tryable solutions is ''the explorable solutions space''. The aim of cryptanalysis is to reduce this space, which means finding a way of having less keys to try than pure bruteforce to decrypt something. <br /> <br /> Most of the fuzzers are:<br /> <br /> - protocol/file-format dependant<br /> <br /> - data-type dependant<br /> <br /> <br /> Why? <br /> <br /> <br /> * First, because the fuzzer has to connect to the input channel, which is bound to the target.<br /> <br /> * Second, because a program only understands structured-enough data. If you connect to a web server in a raw way, it will only respond to listed commands such as GET (or eventually crash). It will take less time to start the string with &quot;GET &quot;, and fuzz the rest, but the drawback is that you'll skip all the tests on the first verb.<br /> <br /> <br /> In this regard, Fuzzers try to reduce the number of unuseful tests, i.e. the values we already know that there's little chance they'll work: you reduce impredictibility, in favor of speed.<br /> <br /> == Attack types ==<br /> <br /> A fuzzer would try combinations of attacks on:<br /> <br /> - numbers (signed/unsigned integers/float...)<br /> <br /> - chars (urls, command-line inputs)<br /> <br /> - metadata : user-input text (id3 tag)<br /> <br /> - pure binary sequences<br /> <br /> <br /> A common approach to fuzzing is to define lists of &quot;known-to-be-dangerous values&quot; (''fuzz vectors'') for each type, and to inject them or recombinations.<br /> <br /> - for integers: zero, possibly negative or very big numbers<br /> <br /> - for chars: escaped, interpretable characters / instructions (ex: For SQL Requests, quotes / commands...)<br /> <br /> - for binary: random ones<br /> <br /> Please refer to OWASP's Fuzz Vector's resource[http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors] for real-life fuzzing vectors examples and methodology.<br /> <br /> <br /> Protocols and file formats imply norms, which are sometimes blurry, very complicated or badly implemented : that's why developers sometimes mess up in the implementation process (because of time/cost constraints). That's why it can be interesting to take the opposite approach: take a norm, look at all mandatory features and constraints, and try all of them; forbidden/reserved values, linked parameters, field sizes. That would be ''conformance testing oriented'' fuzzing.<br /> <br /> == Application fuzzing ==<br /> <br /> Whatever the fuzzed system is, the attack vectors are within it's I/O. For a desktop app:<br /> <br /> - the UI (testing all the buttons sequences / text inputs)<br /> <br /> - the command-line options<br /> <br /> - the import/export capabilities (see file format fuzzing below)<br /> <br /> For a web app: urls, forms, user-generated content, RPC requests, ...<br /> <br /> == Protocol fuzzing ==<br /> <br /> A protocol fuzzer sends forged packets to the tested application, or eventually acts as a proxy, modifying requests on the fly and replaying them.<br /> <br /> == File format fuzzing ==<br /> <br /> A file format fuzzer generates multiple malformed samples, and opens them sequentially. When the program crashes, debug information is kept for further investigation.<br /> <br /> One can attack:<br /> <br /> <br /> - the parser layer (container layer): file format constraints, structure, conventions, field sizes, flags, ...<br /> <br /> - the codec/application layer: lower-level attacks, aiming at the program's deeper internals<br /> <br /> One example of file format related vulnerabilities: MS04-028[http://www.microsoft.com/technet/security/bulletin/ms04-028.mspx] (KB833987) Microsoft's JPEG GDI+ vulnerability was a zero sized comment field, without content.<br /> <br /> <br /> Surprisingly, file format fuzzers are not that common, but tend to appear these days; some examples:<br /> <br /> * A generic file format fuzzer : Ilja van Sprundel's mangle.c[http://www.digitaldwarf.be/products/mangle.c]; &quot;it's usage is very simple, it takes a filename and headersize as input. it will then change approximatly between 0 and 10% of the header with random bytes.&quot; (from the author)<br /> <br /> * Zzuf can act as a fuzzed file generator, http://sam.zoy.org/zzuf/<br /> <br /> * One may use tools like Hachoir[http://hachoir.org/] as a generic parser for file format fuzzers development.<br /> <br /> == Fuzzers advantages ==<br /> <br /> ''The great advantage of fuzz testing is that the test design is extremely simple, and free of preconceptions about system behavior'' (from Wikipedia [http://en.wikipedia.org/wiki/Fuzz_testing]).<br /> <br /> The systematical/random approach allows this method to find bugs that would have often been missed by human eyes. Plus, when the tested system is totally closed (say, a SIP phone), fuzzing is one of the only means of reviewing it's quality.<br /> <br /> == Fuzzers limitations ==<br /> <br /> Fuzzers usually tend to find simple bugs; plus, the more a fuzzer is protocol-aware, the less weird errors it will find. This is why the exhaustive / random approach is still popular among the fuzzing community.<br /> <br /> Another problem is that when you do some black-box-testing, you usually attack a closed system, which increases difficulty to evaluate the dangerosity/impact of the found vulnerability (no debugging possibilities).<br /> <br /> == Why Fuzz? ==<br /> <br /> The purpose of fuzzing relies on the assumption that there are bugs within every program, which are waiting to be discovered. Therefore, a systematical approach should find them sooner or later.<br /> <br /> Fuzzing can add another point of view to classical software testing techniques (hand code review, debugging) because of it's non-human approach. It doesn't replace them, but is a reasonable complement, thanks to the limited work needed to put the procedure in place.<br /> <br /> Recent fuzzing initiatives:<br /> <br /> - The Month of Kernel Bugs[http://projects.info-pull.com/mokb/], which revealed an Apple Wireless flaw; see here[http://kernelfun.blogspot.com/]; mainly used file system fuzzing tools<br /> <br /> - The Month of Browser Bugs[http://browserfun.blogspot.com/] (review here[http://osvdb.org/blog/?p=127]); number of bugs found: MSIE: 25 Apple Safari: 2 Mozilla: 2 Opera: 1 Konqueror: 1; used DHTML, Css, DOM, ActiveX fuzzing tools<br /> <br /> == Fuzzers from OWASP ==<br /> <br /> Fuzzing with WebScarab [http://www.owasp.org/index.php/Fuzzing_with_WebScarab]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br /> <br /> JBroFuzz [http://www.owasp.org/index.php/JBroFuzz]: a stateless network protocol fuzzer<br /> <br /> WSFuzzer [http://www.owasp.org/index.php/WSFuzzer]: real-world manual SOAP pen testing tool<br /> <br /> == Technical resources on OWASP ==<br /> <br /> Fuzzing vectors [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors]<br /> <br /> == Sources ==<br /> <br /> Wikipedia article [http://en.wikipedia.org/wiki/Fuzz_testing]<br /> <br /> Fuzzing-related papers [http://www.threatmind.net/secwiki/FuzzingPapers]<br /> <br /> == Fuzzing tools ==<br /> <br /> The ultimate fuzzers list @ infosec [http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html]<br /> <br /> Another list @ hacksafe<br /> [http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/]<br /> <br /> The fuzzing mailing list [http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing]<br /> <br /> == Commercial products ==<br /> <br /> Codenomicon's product suite: [http://www.codenomicon.com/products/all.shtml]<br /> <br /> Beyond Security's beSTORM product: [http://www.beyondsecurity.com/bestorm_overview.html]</div>

Fthiery https://wiki.owasp.org/index.php?title=Fuzzing&diff=15744 2007-01-23T10:19:08Z

<p>Fthiery: /* Why Fuzz? */</p> <hr /> <div>''Fuzz testing'' or ''Fuzzing'' is a Black Box software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection in an automated fashion.<br /> <br /> == A trivial example: ==<br /> <br /> Lets's consider an integer in a program, which stores the result of a user's choice between 3 questions. When the user picks one, the choice will be 0, 1 or 2. Which makes three practical cases. But what if we transmit 3, or 255 ? We can, because integers are stored a static size variable. If the default switch case hasn't been implemented securely, the program may crash and lead to &quot;classical&quot; security issues: (un)exploitable buffer overflows, DoS, ...<br /> <br /> Fuzzing is the art of automatic bug finding, and it's role is to find software implementation faults, and identify them if possible.<br /> <br /> == History ==<br /> <br /> Fuzz testing was developed at the University of Wisconsin Madison in 1989 by Professor Barton Miller and his students. Their (continued) work can be found at http://www.cs.wisc.edu/~bart/fuzz/ ; it's mainly oriented towards command-line and UI fuzzing, and shows that modern operating systems are vulnerable to even simple fuzzing.<br /> <br /> == Fuzzer implementations ==<br /> <br /> A fuzzer is a program which injects automatically semi-random data into a program/stack and detect bugs.<br /> <br /> The data-generation part is made of generators, and vulnerability identification relies on debugging tools. Generators usually use combinations of static fuzzing vectors (known-to-be-dangerous values), or totally random data. New generation fuzzers use genetic algorithms to link injected data and observed impact. Such tools are not public yet.<br /> <br /> == Comparison with cryptanalysis ==<br /> <br /> The number of possible tryable solutions is ''the explorable solutions space''. The aim of cryptanalysis is to reduce this space, which means finding a way of having less keys to try than pure bruteforce to decrypt something. <br /> <br /> Most of the fuzzers are:<br /> <br /> - protocol/file-format dependant<br /> <br /> - data-type dependant<br /> <br /> <br /> Why? <br /> <br /> <br /> * First, because the fuzzer has to connect to the input channel, which is bound to the target.<br /> <br /> * Second, because a program only understands structured-enough data. If you connect to a web server in a raw way, it will only respond to listed commands such as GET (or eventually crash). It will take less time to start the string with &quot;GET &quot;, and fuzz the rest, but the drawback is that you'll skip all the tests on the first verb.<br /> <br /> <br /> In this regard, Fuzzers try to reduce the number of unuseful tests, i.e. the values we already know that there's little chance they'll work: you reduce impredictibility, in favor of speed.<br /> <br /> == Attack types ==<br /> <br /> A fuzzer would try combinations of attacks on:<br /> <br /> - numbers (signed/unsigned integers/float...)<br /> <br /> - chars (urls, command-line inputs)<br /> <br /> - metadata : user-input text (id3 tag)<br /> <br /> - pure binary sequences<br /> <br /> <br /> A common approach to fuzzing is to define lists of &quot;known-to-be-dangerous values&quot; (''fuzz vectors'') for each type, and to inject them or recombinations.<br /> <br /> - for integers: zero, possibly negative or very big numbers<br /> <br /> - for chars: escaped, interpretable characters / instructions (ex: For SQL Requests, quotes / commands...)<br /> <br /> - for binary: random ones<br /> <br /> Please refer to OWASP's Fuzz Vector's resource[http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors] for real-life fuzzing vectors examples and methodology.<br /> <br /> <br /> Protocols and file formats imply norms, which are sometimes blurry, very complicated or badly implemented : that's why developers sometimes mess up in the implementation process (because of time/cost constraints). That's why it can be interesting to take the opposite approach: take a norm, look at all mandatory features and constraints, and try all of them; forbidden/reserved values, linked parameters, field sizes. That would be ''conformance testing oriented'' fuzzing.<br /> <br /> == Application fuzzing ==<br /> <br /> Whatever the fuzzed system is, the attack vectors are within it's I/O. For a desktop app:<br /> <br /> - the UI (testing all the buttons sequences / text inputs)<br /> <br /> - the command-line options<br /> <br /> - the import/export capabilities (see file format fuzzing below)<br /> <br /> For a web app: urls, forms, user-generated content, RPC requests, ...<br /> <br /> == Protocol fuzzing ==<br /> <br /> A protocol fuzzer sends forged packets to the tested application, or eventually acts as a proxy, modifying requests on the fly and replaying them.<br /> <br /> == File format fuzzing ==<br /> <br /> A file format fuzzer generates multiple malformed samples, and opens them sequentially. When the program crashes, debug information is kept for further investigation.<br /> <br /> One can attack:<br /> <br /> <br /> - the parser layer (container layer): file format constraints, structure, conventions, field sizes, flags, ...<br /> <br /> - the codec/application layer: lower-level attacks, aiming at the program's deeper internals<br /> <br /> One example of file format related vulnerabilities: MS04-028[http://www.microsoft.com/technet/security/bulletin/ms04-028.mspx] (KB833987) Microsoft's JPEG GDI+ vulnerability was a zero sized comment field, without content.<br /> <br /> <br /> Surprisingly, file format fuzzers are not that common, but tend to appear these days; some examples:<br /> <br /> * A generic file format fuzzer : Ilja van Sprundel's mangle.c[http://www.digitaldwarf.be/products/mangle.c]; &quot;it's usage is very simple, it takes a filename and headersize as input. it will then change approximatly between 0 and 10% of the header with random bytes.&quot; (from the author)<br /> <br /> * Zzuf can act as a fuzzed file generator, http://sam.zoy.org/zzuf/<br /> <br /> * One may use tools like Hachoir[http://hachoir.org/] as a generic parser for file format fuzzers development.<br /> <br /> == Fuzzers advantages ==<br /> <br /> ''The great advantage of fuzz testing is that the test design is extremely simple, and free of preconceptions about system behavior'' (from Wikipedia [http://en.wikipedia.org/wiki/Fuzz_testing]).<br /> <br /> The systematical/random approach allows this method to find bugs that would have often been missed by human eyes. Plus, when the tested system is totally closed (say, a SIP phone), fuzzing is one of the only means of reviewing it's quality.<br /> <br /> == Fuzzers limitations ==<br /> <br /> Fuzzers usually tend to find simple bugs; plus, the more a fuzzer is protocol-aware, the less weird errors it will find. This is why the exhaustive / random approach is still popular among the fuzzing community.<br /> <br /> Another problem is that when you do some black-box-testing, you usually attack a closed system, which increases difficulty to evaluate the dangerosity/impact of the found vulnerability (no debugging possibilities).<br /> <br /> == Why Fuzz? ==<br /> <br /> The purpose of fuzzing relies on the assumption that there are bugs within every program, which are waiting to be discovered. Therefore, a systematical approach should find them sooner or later.<br /> <br /> Fuzzing can add another point of view to classical software testing techniques (hand code review, debugging) because of it's non-human approach. It doesn't replace them, but is a reasonable complement, thanks to the limited work needed to put the procedure in place.<br /> <br /> Recent fuzzing initiatives:<br /> <br /> - The Month of Kernel Bugs[http://projects.info-pull.com/mokb/], which revealed an Apple Wireless flaw; see here[http://kernelfun.blogspot.com/]; mainly used file system fuzzing tools<br /> <br /> - The Month of Browser Bugs[http://browserfun.blogspot.com/] (review here[http://osvdb.org/blog/?p=127]); number of bugs found: MSIE: 25 Apple Safari: 2 Mozilla: 2 Opera: 1 Konqueror: 1; used DHTML, ActiveX fuzzing tools<br /> <br /> == Fuzzers from OWASP ==<br /> <br /> Fuzzing with WebScarab [http://www.owasp.org/index.php/Fuzzing_with_WebScarab]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br /> <br /> JBroFuzz [http://www.owasp.org/index.php/JBroFuzz]: a stateless network protocol fuzzer<br /> <br /> WSFuzzer [http://www.owasp.org/index.php/WSFuzzer]: real-world manual SOAP pen testing tool<br /> <br /> == Technical resources on OWASP ==<br /> <br /> Fuzzing vectors [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors]<br /> <br /> == Sources ==<br /> <br /> Wikipedia article [http://en.wikipedia.org/wiki/Fuzz_testing]<br /> <br /> Fuzzing-related papers [http://www.threatmind.net/secwiki/FuzzingPapers]<br /> <br /> == Fuzzing tools ==<br /> <br /> The ultimate fuzzers list @ infosec [http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html]<br /> <br /> Another list @ hacksafe<br /> [http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/]<br /> <br /> The fuzzing mailing list [http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing]<br /> <br /> == Commercial products ==<br /> <br /> Codenomicon's product suite: [http://www.codenomicon.com/products/all.shtml]<br /> <br /> Beyond Security's beSTORM product: [http://www.beyondsecurity.com/bestorm_overview.html]</div>

Fthiery https://wiki.owasp.org/index.php?title=Fuzzing&diff=15743 2007-01-23T10:18:14Z

<p>Fthiery: /* Why Fuzz? */</p> <hr /> <div>''Fuzz testing'' or ''Fuzzing'' is a Black Box software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection in an automated fashion.<br /> <br /> == A trivial example: ==<br /> <br /> Lets's consider an integer in a program, which stores the result of a user's choice between 3 questions. When the user picks one, the choice will be 0, 1 or 2. Which makes three practical cases. But what if we transmit 3, or 255 ? We can, because integers are stored a static size variable. If the default switch case hasn't been implemented securely, the program may crash and lead to &quot;classical&quot; security issues: (un)exploitable buffer overflows, DoS, ...<br /> <br /> Fuzzing is the art of automatic bug finding, and it's role is to find software implementation faults, and identify them if possible.<br /> <br /> == History ==<br /> <br /> Fuzz testing was developed at the University of Wisconsin Madison in 1989 by Professor Barton Miller and his students. Their (continued) work can be found at http://www.cs.wisc.edu/~bart/fuzz/ ; it's mainly oriented towards command-line and UI fuzzing, and shows that modern operating systems are vulnerable to even simple fuzzing.<br /> <br /> == Fuzzer implementations ==<br /> <br /> A fuzzer is a program which injects automatically semi-random data into a program/stack and detect bugs.<br /> <br /> The data-generation part is made of generators, and vulnerability identification relies on debugging tools. Generators usually use combinations of static fuzzing vectors (known-to-be-dangerous values), or totally random data. New generation fuzzers use genetic algorithms to link injected data and observed impact. Such tools are not public yet.<br /> <br /> == Comparison with cryptanalysis ==<br /> <br /> The number of possible tryable solutions is ''the explorable solutions space''. The aim of cryptanalysis is to reduce this space, which means finding a way of having less keys to try than pure bruteforce to decrypt something. <br /> <br /> Most of the fuzzers are:<br /> <br /> - protocol/file-format dependant<br /> <br /> - data-type dependant<br /> <br /> <br /> Why? <br /> <br /> <br /> * First, because the fuzzer has to connect to the input channel, which is bound to the target.<br /> <br /> * Second, because a program only understands structured-enough data. If you connect to a web server in a raw way, it will only respond to listed commands such as GET (or eventually crash). It will take less time to start the string with &quot;GET &quot;, and fuzz the rest, but the drawback is that you'll skip all the tests on the first verb.<br /> <br /> <br /> In this regard, Fuzzers try to reduce the number of unuseful tests, i.e. the values we already know that there's little chance they'll work: you reduce impredictibility, in favor of speed.<br /> <br /> == Attack types ==<br /> <br /> A fuzzer would try combinations of attacks on:<br /> <br /> - numbers (signed/unsigned integers/float...)<br /> <br /> - chars (urls, command-line inputs)<br /> <br /> - metadata : user-input text (id3 tag)<br /> <br /> - pure binary sequences<br /> <br /> <br /> A common approach to fuzzing is to define lists of &quot;known-to-be-dangerous values&quot; (''fuzz vectors'') for each type, and to inject them or recombinations.<br /> <br /> - for integers: zero, possibly negative or very big numbers<br /> <br /> - for chars: escaped, interpretable characters / instructions (ex: For SQL Requests, quotes / commands...)<br /> <br /> - for binary: random ones<br /> <br /> Please refer to OWASP's Fuzz Vector's resource[http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors] for real-life fuzzing vectors examples and methodology.<br /> <br /> <br /> Protocols and file formats imply norms, which are sometimes blurry, very complicated or badly implemented : that's why developers sometimes mess up in the implementation process (because of time/cost constraints). That's why it can be interesting to take the opposite approach: take a norm, look at all mandatory features and constraints, and try all of them; forbidden/reserved values, linked parameters, field sizes. That would be ''conformance testing oriented'' fuzzing.<br /> <br /> == Application fuzzing ==<br /> <br /> Whatever the fuzzed system is, the attack vectors are within it's I/O. For a desktop app:<br /> <br /> - the UI (testing all the buttons sequences / text inputs)<br /> <br /> - the command-line options<br /> <br /> - the import/export capabilities (see file format fuzzing below)<br /> <br /> For a web app: urls, forms, user-generated content, RPC requests, ...<br /> <br /> == Protocol fuzzing ==<br /> <br /> A protocol fuzzer sends forged packets to the tested application, or eventually acts as a proxy, modifying requests on the fly and replaying them.<br /> <br /> == File format fuzzing ==<br /> <br /> A file format fuzzer generates multiple malformed samples, and opens them sequentially. When the program crashes, debug information is kept for further investigation.<br /> <br /> One can attack:<br /> <br /> <br /> - the parser layer (container layer): file format constraints, structure, conventions, field sizes, flags, ...<br /> <br /> - the codec/application layer: lower-level attacks, aiming at the program's deeper internals<br /> <br /> One example of file format related vulnerabilities: MS04-028[http://www.microsoft.com/technet/security/bulletin/ms04-028.mspx] (KB833987) Microsoft's JPEG GDI+ vulnerability was a zero sized comment field, without content.<br /> <br /> <br /> Surprisingly, file format fuzzers are not that common, but tend to appear these days; some examples:<br /> <br /> * A generic file format fuzzer : Ilja van Sprundel's mangle.c[http://www.digitaldwarf.be/products/mangle.c]; &quot;it's usage is very simple, it takes a filename and headersize as input. it will then change approximatly between 0 and 10% of the header with random bytes.&quot; (from the author)<br /> <br /> * Zzuf can act as a fuzzed file generator, http://sam.zoy.org/zzuf/<br /> <br /> * One may use tools like Hachoir[http://hachoir.org/] as a generic parser for file format fuzzers development.<br /> <br /> == Fuzzers advantages ==<br /> <br /> ''The great advantage of fuzz testing is that the test design is extremely simple, and free of preconceptions about system behavior'' (from Wikipedia [http://en.wikipedia.org/wiki/Fuzz_testing]).<br /> <br /> The systematical/random approach allows this method to find bugs that would have often been missed by human eyes. Plus, when the tested system is totally closed (say, a SIP phone), fuzzing is one of the only means of reviewing it's quality.<br /> <br /> == Fuzzers limitations ==<br /> <br /> Fuzzers usually tend to find simple bugs; plus, the more a fuzzer is protocol-aware, the less weird errors it will find. This is why the exhaustive / random approach is still popular among the fuzzing community.<br /> <br /> Another problem is that when you do some black-box-testing, you usually attack a closed system, which increases difficulty to evaluate the dangerosity/impact of the found vulnerability (no debugging possibilities).<br /> <br /> == Why Fuzz? ==<br /> <br /> The purpose of fuzzing relies on the assumption that there are bugs within every program, which are waiting to be discovered. Therefore, a systematical approach should find them sooner or later.<br /> <br /> Fuzzing can add another point of view to classical software testing techniques (hand code review, debugging) because of it's non-human approach. It doesn't replace them, but is a reasonable complement, thanks to the limited work needed to put the procedure in place.<br /> <br /> Recent fuzzing initiatives:<br /> <br /> - The Month of Kernel Bugs[http://projects.info-pull.com/mokb/], which revealed an Apple Wireless flaw; see here[http://kernelfun.blogspot.com/]; mainly used file system fuzzing tools<br /> <br /> - The Month of Browser Bugs (review here[http://osvdb.org/blog/?p=127]); number of bugs found: MSIE: 25 Apple Safari: 2 Mozilla: 2 Opera: 1 Konqueror: 1; used DHTML, ActiveX fuzzing tools<br /> <br /> == Fuzzers from OWASP ==<br /> <br /> Fuzzing with WebScarab [http://www.owasp.org/index.php/Fuzzing_with_WebScarab]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br /> <br /> JBroFuzz [http://www.owasp.org/index.php/JBroFuzz]: a stateless network protocol fuzzer<br /> <br /> WSFuzzer [http://www.owasp.org/index.php/WSFuzzer]: real-world manual SOAP pen testing tool<br /> <br /> == Technical resources on OWASP ==<br /> <br /> Fuzzing vectors [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors]<br /> <br /> == Sources ==<br /> <br /> Wikipedia article [http://en.wikipedia.org/wiki/Fuzz_testing]<br /> <br /> Fuzzing-related papers [http://www.threatmind.net/secwiki/FuzzingPapers]<br /> <br /> == Fuzzing tools ==<br /> <br /> The ultimate fuzzers list @ infosec [http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html]<br /> <br /> Another list @ hacksafe<br /> [http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/]<br /> <br /> The fuzzing mailing list [http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing]<br /> <br /> == Commercial products ==<br /> <br /> Codenomicon's product suite: [http://www.codenomicon.com/products/all.shtml]<br /> <br /> Beyond Security's beSTORM product: [http://www.beyondsecurity.com/bestorm_overview.html]</div>

Fthiery https://wiki.owasp.org/index.php?title=Fuzzing&diff=15742 2007-01-23T10:17:17Z

<p>Fthiery: /* File format fuzzing */</p> <hr /> <div>''Fuzz testing'' or ''Fuzzing'' is a Black Box software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection in an automated fashion.<br /> <br /> == A trivial example: ==<br /> <br /> Lets's consider an integer in a program, which stores the result of a user's choice between 3 questions. When the user picks one, the choice will be 0, 1 or 2. Which makes three practical cases. But what if we transmit 3, or 255 ? We can, because integers are stored a static size variable. If the default switch case hasn't been implemented securely, the program may crash and lead to &quot;classical&quot; security issues: (un)exploitable buffer overflows, DoS, ...<br /> <br /> Fuzzing is the art of automatic bug finding, and it's role is to find software implementation faults, and identify them if possible.<br /> <br /> == History ==<br /> <br /> Fuzz testing was developed at the University of Wisconsin Madison in 1989 by Professor Barton Miller and his students. Their (continued) work can be found at http://www.cs.wisc.edu/~bart/fuzz/ ; it's mainly oriented towards command-line and UI fuzzing, and shows that modern operating systems are vulnerable to even simple fuzzing.<br /> <br /> == Fuzzer implementations ==<br /> <br /> A fuzzer is a program which injects automatically semi-random data into a program/stack and detect bugs.<br /> <br /> The data-generation part is made of generators, and vulnerability identification relies on debugging tools. Generators usually use combinations of static fuzzing vectors (known-to-be-dangerous values), or totally random data. New generation fuzzers use genetic algorithms to link injected data and observed impact. Such tools are not public yet.<br /> <br /> == Comparison with cryptanalysis ==<br /> <br /> The number of possible tryable solutions is ''the explorable solutions space''. The aim of cryptanalysis is to reduce this space, which means finding a way of having less keys to try than pure bruteforce to decrypt something. <br /> <br /> Most of the fuzzers are:<br /> <br /> - protocol/file-format dependant<br /> <br /> - data-type dependant<br /> <br /> <br /> Why? <br /> <br /> <br /> * First, because the fuzzer has to connect to the input channel, which is bound to the target.<br /> <br /> * Second, because a program only understands structured-enough data. If you connect to a web server in a raw way, it will only respond to listed commands such as GET (or eventually crash). It will take less time to start the string with &quot;GET &quot;, and fuzz the rest, but the drawback is that you'll skip all the tests on the first verb.<br /> <br /> <br /> In this regard, Fuzzers try to reduce the number of unuseful tests, i.e. the values we already know that there's little chance they'll work: you reduce impredictibility, in favor of speed.<br /> <br /> == Attack types ==<br /> <br /> A fuzzer would try combinations of attacks on:<br /> <br /> - numbers (signed/unsigned integers/float...)<br /> <br /> - chars (urls, command-line inputs)<br /> <br /> - metadata : user-input text (id3 tag)<br /> <br /> - pure binary sequences<br /> <br /> <br /> A common approach to fuzzing is to define lists of &quot;known-to-be-dangerous values&quot; (''fuzz vectors'') for each type, and to inject them or recombinations.<br /> <br /> - for integers: zero, possibly negative or very big numbers<br /> <br /> - for chars: escaped, interpretable characters / instructions (ex: For SQL Requests, quotes / commands...)<br /> <br /> - for binary: random ones<br /> <br /> Please refer to OWASP's Fuzz Vector's resource[http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors] for real-life fuzzing vectors examples and methodology.<br /> <br /> <br /> Protocols and file formats imply norms, which are sometimes blurry, very complicated or badly implemented : that's why developers sometimes mess up in the implementation process (because of time/cost constraints). That's why it can be interesting to take the opposite approach: take a norm, look at all mandatory features and constraints, and try all of them; forbidden/reserved values, linked parameters, field sizes. That would be ''conformance testing oriented'' fuzzing.<br /> <br /> == Application fuzzing ==<br /> <br /> Whatever the fuzzed system is, the attack vectors are within it's I/O. For a desktop app:<br /> <br /> - the UI (testing all the buttons sequences / text inputs)<br /> <br /> - the command-line options<br /> <br /> - the import/export capabilities (see file format fuzzing below)<br /> <br /> For a web app: urls, forms, user-generated content, RPC requests, ...<br /> <br /> == Protocol fuzzing ==<br /> <br /> A protocol fuzzer sends forged packets to the tested application, or eventually acts as a proxy, modifying requests on the fly and replaying them.<br /> <br /> == File format fuzzing ==<br /> <br /> A file format fuzzer generates multiple malformed samples, and opens them sequentially. When the program crashes, debug information is kept for further investigation.<br /> <br /> One can attack:<br /> <br /> <br /> - the parser layer (container layer): file format constraints, structure, conventions, field sizes, flags, ...<br /> <br /> - the codec/application layer: lower-level attacks, aiming at the program's deeper internals<br /> <br /> One example of file format related vulnerabilities: MS04-028[http://www.microsoft.com/technet/security/bulletin/ms04-028.mspx] (KB833987) Microsoft's JPEG GDI+ vulnerability was a zero sized comment field, without content.<br /> <br /> <br /> Surprisingly, file format fuzzers are not that common, but tend to appear these days; some examples:<br /> <br /> * A generic file format fuzzer : Ilja van Sprundel's mangle.c[http://www.digitaldwarf.be/products/mangle.c]; &quot;it's usage is very simple, it takes a filename and headersize as input. it will then change approximatly between 0 and 10% of the header with random bytes.&quot; (from the author)<br /> <br /> * Zzuf can act as a fuzzed file generator, http://sam.zoy.org/zzuf/<br /> <br /> * One may use tools like Hachoir[http://hachoir.org/] as a generic parser for file format fuzzers development.<br /> <br /> == Fuzzers advantages ==<br /> <br /> ''The great advantage of fuzz testing is that the test design is extremely simple, and free of preconceptions about system behavior'' (from Wikipedia [http://en.wikipedia.org/wiki/Fuzz_testing]).<br /> <br /> The systematical/random approach allows this method to find bugs that would have often been missed by human eyes. Plus, when the tested system is totally closed (say, a SIP phone), fuzzing is one of the only means of reviewing it's quality.<br /> <br /> == Fuzzers limitations ==<br /> <br /> Fuzzers usually tend to find simple bugs; plus, the more a fuzzer is protocol-aware, the less weird errors it will find. This is why the exhaustive / random approach is still popular among the fuzzing community.<br /> <br /> Another problem is that when you do some black-box-testing, you usually attack a closed system, which increases difficulty to evaluate the dangerosity/impact of the found vulnerability (no debugging possibilities).<br /> <br /> == Why Fuzz? ==<br /> <br /> The purpose of fuzzing relies on the assumption that there are bugs within every program, which are waiting to be discovered. Therefore, a systematical approach should find them sooner or later.<br /> <br /> Fuzzing can add another point of view to classical software testing techniques (hand code review, debugging) because of it's non-human approach. It doesn't replace them, but is a reasonable complement, thanks to the limited work needed to put the procedure in place.<br /> <br /> Recent fuzzing initiatives:<br /> <br /> - The Month of Kernel Bugs[http://projects.info-pull.com/mokb/], which revealed an Apple Wireless flaw; see here[http://kernelfun.blogspot.com/]<br /> <br /> - The Month of Browser Bugs (review here[http://osvdb.org/blog/?p=127]); number of bugs found: MSIE: 25 Apple Safari: 2 Mozilla: 2 Opera: 1 Konqueror: 1<br /> <br /> == Fuzzers from OWASP ==<br /> <br /> Fuzzing with WebScarab [http://www.owasp.org/index.php/Fuzzing_with_WebScarab]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br /> <br /> JBroFuzz [http://www.owasp.org/index.php/JBroFuzz]: a stateless network protocol fuzzer<br /> <br /> WSFuzzer [http://www.owasp.org/index.php/WSFuzzer]: real-world manual SOAP pen testing tool<br /> <br /> == Technical resources on OWASP ==<br /> <br /> Fuzzing vectors [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors]<br /> <br /> == Sources ==<br /> <br /> Wikipedia article [http://en.wikipedia.org/wiki/Fuzz_testing]<br /> <br /> Fuzzing-related papers [http://www.threatmind.net/secwiki/FuzzingPapers]<br /> <br /> == Fuzzing tools ==<br /> <br /> The ultimate fuzzers list @ infosec [http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html]<br /> <br /> Another list @ hacksafe<br /> [http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/]<br /> <br /> The fuzzing mailing list [http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing]<br /> <br /> == Commercial products ==<br /> <br /> Codenomicon's product suite: [http://www.codenomicon.com/products/all.shtml]<br /> <br /> Beyond Security's beSTORM product: [http://www.beyondsecurity.com/bestorm_overview.html]</div>

Fthiery https://wiki.owasp.org/index.php?title=Fuzzing&diff=15741 2007-01-23T10:16:11Z

<p>Fthiery: /* File format fuzzing */</p> <hr /> <div>''Fuzz testing'' or ''Fuzzing'' is a Black Box software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection in an automated fashion.<br /> <br /> == A trivial example: ==<br /> <br /> Lets's consider an integer in a program, which stores the result of a user's choice between 3 questions. When the user picks one, the choice will be 0, 1 or 2. Which makes three practical cases. But what if we transmit 3, or 255 ? We can, because integers are stored a static size variable. If the default switch case hasn't been implemented securely, the program may crash and lead to &quot;classical&quot; security issues: (un)exploitable buffer overflows, DoS, ...<br /> <br /> Fuzzing is the art of automatic bug finding, and it's role is to find software implementation faults, and identify them if possible.<br /> <br /> == History ==<br /> <br /> Fuzz testing was developed at the University of Wisconsin Madison in 1989 by Professor Barton Miller and his students. Their (continued) work can be found at http://www.cs.wisc.edu/~bart/fuzz/ ; it's mainly oriented towards command-line and UI fuzzing, and shows that modern operating systems are vulnerable to even simple fuzzing.<br /> <br /> == Fuzzer implementations ==<br /> <br /> A fuzzer is a program which injects automatically semi-random data into a program/stack and detect bugs.<br /> <br /> The data-generation part is made of generators, and vulnerability identification relies on debugging tools. Generators usually use combinations of static fuzzing vectors (known-to-be-dangerous values), or totally random data. New generation fuzzers use genetic algorithms to link injected data and observed impact. Such tools are not public yet.<br /> <br /> == Comparison with cryptanalysis ==<br /> <br /> The number of possible tryable solutions is ''the explorable solutions space''. The aim of cryptanalysis is to reduce this space, which means finding a way of having less keys to try than pure bruteforce to decrypt something. <br /> <br /> Most of the fuzzers are:<br /> <br /> - protocol/file-format dependant<br /> <br /> - data-type dependant<br /> <br /> <br /> Why? <br /> <br /> <br /> * First, because the fuzzer has to connect to the input channel, which is bound to the target.<br /> <br /> * Second, because a program only understands structured-enough data. If you connect to a web server in a raw way, it will only respond to listed commands such as GET (or eventually crash). It will take less time to start the string with &quot;GET &quot;, and fuzz the rest, but the drawback is that you'll skip all the tests on the first verb.<br /> <br /> <br /> In this regard, Fuzzers try to reduce the number of unuseful tests, i.e. the values we already know that there's little chance they'll work: you reduce impredictibility, in favor of speed.<br /> <br /> == Attack types ==<br /> <br /> A fuzzer would try combinations of attacks on:<br /> <br /> - numbers (signed/unsigned integers/float...)<br /> <br /> - chars (urls, command-line inputs)<br /> <br /> - metadata : user-input text (id3 tag)<br /> <br /> - pure binary sequences<br /> <br /> <br /> A common approach to fuzzing is to define lists of &quot;known-to-be-dangerous values&quot; (''fuzz vectors'') for each type, and to inject them or recombinations.<br /> <br /> - for integers: zero, possibly negative or very big numbers<br /> <br /> - for chars: escaped, interpretable characters / instructions (ex: For SQL Requests, quotes / commands...)<br /> <br /> - for binary: random ones<br /> <br /> Please refer to OWASP's Fuzz Vector's resource[http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors] for real-life fuzzing vectors examples and methodology.<br /> <br /> <br /> Protocols and file formats imply norms, which are sometimes blurry, very complicated or badly implemented : that's why developers sometimes mess up in the implementation process (because of time/cost constraints). That's why it can be interesting to take the opposite approach: take a norm, look at all mandatory features and constraints, and try all of them; forbidden/reserved values, linked parameters, field sizes. That would be ''conformance testing oriented'' fuzzing.<br /> <br /> == Application fuzzing ==<br /> <br /> Whatever the fuzzed system is, the attack vectors are within it's I/O. For a desktop app:<br /> <br /> - the UI (testing all the buttons sequences / text inputs)<br /> <br /> - the command-line options<br /> <br /> - the import/export capabilities (see file format fuzzing below)<br /> <br /> For a web app: urls, forms, user-generated content, RPC requests, ...<br /> <br /> == Protocol fuzzing ==<br /> <br /> A protocol fuzzer sends forged packets to the tested application, or eventually acts as a proxy, modifying requests on the fly and replaying them.<br /> <br /> == File format fuzzing ==<br /> <br /> A file format fuzzer generates multiple malformed samples, and opens them sequentially. When the program crashes, debug information is kept for further investigation.<br /> <br /> One can attack:<br /> <br /> <br /> - the parser layer (container layer): file format constraints, structure, conventions, field sizes, flags, ...<br /> <br /> - the codec/application layer: lower-level attacks, aiming at the program's deeper internals<br /> <br /> One example of file format related vulnerabilities: MS04-028[http://www.microsoft.com/technet/security/bulletin/ms04-028.mspx] (KB833987) Microsoft's JPEG GDI+ vulnerability was a zero sized comment field, without content.<br /> <br /> <br /> Surprisingly, file format fuzzers are not that common;<br /> <br /> A generic file format fuzzer : Ilja van Sprundel's mangle.c[http://www.digitaldwarf.be/products/mangle.c]; &quot;it's usage is very simple, it takes a filename and headersize as input. it will then change approximatly between 0 and 10% of the header with random bytes.&quot; (from the author)<br /> <br /> Zzuf can act as a fuzzed file generator, http://sam.zoy.org/zzuf/<br /> <br /> One may use tools like Hachoir[http://hachoir.org/] as a generic parser for file format fuzzers development.<br /> <br /> == Fuzzers advantages ==<br /> <br /> ''The great advantage of fuzz testing is that the test design is extremely simple, and free of preconceptions about system behavior'' (from Wikipedia [http://en.wikipedia.org/wiki/Fuzz_testing]).<br /> <br /> The systematical/random approach allows this method to find bugs that would have often been missed by human eyes. Plus, when the tested system is totally closed (say, a SIP phone), fuzzing is one of the only means of reviewing it's quality.<br /> <br /> == Fuzzers limitations ==<br /> <br /> Fuzzers usually tend to find simple bugs; plus, the more a fuzzer is protocol-aware, the less weird errors it will find. This is why the exhaustive / random approach is still popular among the fuzzing community.<br /> <br /> Another problem is that when you do some black-box-testing, you usually attack a closed system, which increases difficulty to evaluate the dangerosity/impact of the found vulnerability (no debugging possibilities).<br /> <br /> == Why Fuzz? ==<br /> <br /> The purpose of fuzzing relies on the assumption that there are bugs within every program, which are waiting to be discovered. Therefore, a systematical approach should find them sooner or later.<br /> <br /> Fuzzing can add another point of view to classical software testing techniques (hand code review, debugging) because of it's non-human approach. It doesn't replace them, but is a reasonable complement, thanks to the limited work needed to put the procedure in place.<br /> <br /> Recent fuzzing initiatives:<br /> <br /> - The Month of Kernel Bugs[http://projects.info-pull.com/mokb/], which revealed an Apple Wireless flaw; see here[http://kernelfun.blogspot.com/]<br /> <br /> - The Month of Browser Bugs (review here[http://osvdb.org/blog/?p=127]); number of bugs found: MSIE: 25 Apple Safari: 2 Mozilla: 2 Opera: 1 Konqueror: 1<br /> <br /> == Fuzzers from OWASP ==<br /> <br /> Fuzzing with WebScarab [http://www.owasp.org/index.php/Fuzzing_with_WebScarab]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br /> <br /> JBroFuzz [http://www.owasp.org/index.php/JBroFuzz]: a stateless network protocol fuzzer<br /> <br /> WSFuzzer [http://www.owasp.org/index.php/WSFuzzer]: real-world manual SOAP pen testing tool<br /> <br /> == Technical resources on OWASP ==<br /> <br /> Fuzzing vectors [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors]<br /> <br /> == Sources ==<br /> <br /> Wikipedia article [http://en.wikipedia.org/wiki/Fuzz_testing]<br /> <br /> Fuzzing-related papers [http://www.threatmind.net/secwiki/FuzzingPapers]<br /> <br /> == Fuzzing tools ==<br /> <br /> The ultimate fuzzers list @ infosec [http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html]<br /> <br /> Another list @ hacksafe<br /> [http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/]<br /> <br /> The fuzzing mailing list [http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing]<br /> <br /> == Commercial products ==<br /> <br /> Codenomicon's product suite: [http://www.codenomicon.com/products/all.shtml]<br /> <br /> Beyond Security's beSTORM product: [http://www.beyondsecurity.com/bestorm_overview.html]</div>

Fthiery https://wiki.owasp.org/index.php?title=Fuzzing&diff=15740 2007-01-23T10:15:34Z

<p>Fthiery: /* Attack types */</p> <hr /> <div>''Fuzz testing'' or ''Fuzzing'' is a Black Box software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection in an automated fashion.<br /> <br /> == A trivial example: ==<br /> <br /> Lets's consider an integer in a program, which stores the result of a user's choice between 3 questions. When the user picks one, the choice will be 0, 1 or 2. Which makes three practical cases. But what if we transmit 3, or 255 ? We can, because integers are stored a static size variable. If the default switch case hasn't been implemented securely, the program may crash and lead to &quot;classical&quot; security issues: (un)exploitable buffer overflows, DoS, ...<br /> <br /> Fuzzing is the art of automatic bug finding, and it's role is to find software implementation faults, and identify them if possible.<br /> <br /> == History ==<br /> <br /> Fuzz testing was developed at the University of Wisconsin Madison in 1989 by Professor Barton Miller and his students. Their (continued) work can be found at http://www.cs.wisc.edu/~bart/fuzz/ ; it's mainly oriented towards command-line and UI fuzzing, and shows that modern operating systems are vulnerable to even simple fuzzing.<br /> <br /> == Fuzzer implementations ==<br /> <br /> A fuzzer is a program which injects automatically semi-random data into a program/stack and detect bugs.<br /> <br /> The data-generation part is made of generators, and vulnerability identification relies on debugging tools. Generators usually use combinations of static fuzzing vectors (known-to-be-dangerous values), or totally random data. New generation fuzzers use genetic algorithms to link injected data and observed impact. Such tools are not public yet.<br /> <br /> == Comparison with cryptanalysis ==<br /> <br /> The number of possible tryable solutions is ''the explorable solutions space''. The aim of cryptanalysis is to reduce this space, which means finding a way of having less keys to try than pure bruteforce to decrypt something. <br /> <br /> Most of the fuzzers are:<br /> <br /> - protocol/file-format dependant<br /> <br /> - data-type dependant<br /> <br /> <br /> Why? <br /> <br /> <br /> * First, because the fuzzer has to connect to the input channel, which is bound to the target.<br /> <br /> * Second, because a program only understands structured-enough data. If you connect to a web server in a raw way, it will only respond to listed commands such as GET (or eventually crash). It will take less time to start the string with &quot;GET &quot;, and fuzz the rest, but the drawback is that you'll skip all the tests on the first verb.<br /> <br /> <br /> In this regard, Fuzzers try to reduce the number of unuseful tests, i.e. the values we already know that there's little chance they'll work: you reduce impredictibility, in favor of speed.<br /> <br /> == Attack types ==<br /> <br /> A fuzzer would try combinations of attacks on:<br /> <br /> - numbers (signed/unsigned integers/float...)<br /> <br /> - chars (urls, command-line inputs)<br /> <br /> - metadata : user-input text (id3 tag)<br /> <br /> - pure binary sequences<br /> <br /> <br /> A common approach to fuzzing is to define lists of &quot;known-to-be-dangerous values&quot; (''fuzz vectors'') for each type, and to inject them or recombinations.<br /> <br /> - for integers: zero, possibly negative or very big numbers<br /> <br /> - for chars: escaped, interpretable characters / instructions (ex: For SQL Requests, quotes / commands...)<br /> <br /> - for binary: random ones<br /> <br /> Please refer to OWASP's Fuzz Vector's resource[http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors] for real-life fuzzing vectors examples and methodology.<br /> <br /> <br /> Protocols and file formats imply norms, which are sometimes blurry, very complicated or badly implemented : that's why developers sometimes mess up in the implementation process (because of time/cost constraints). That's why it can be interesting to take the opposite approach: take a norm, look at all mandatory features and constraints, and try all of them; forbidden/reserved values, linked parameters, field sizes. That would be ''conformance testing oriented'' fuzzing.<br /> <br /> == Application fuzzing ==<br /> <br /> Whatever the fuzzed system is, the attack vectors are within it's I/O. For a desktop app:<br /> <br /> - the UI (testing all the buttons sequences / text inputs)<br /> <br /> - the command-line options<br /> <br /> - the import/export capabilities (see file format fuzzing below)<br /> <br /> For a web app: urls, forms, user-generated content, RPC requests, ...<br /> <br /> == Protocol fuzzing ==<br /> <br /> A protocol fuzzer sends forged packets to the tested application, or eventually acts as a proxy, modifying requests on the fly and replaying them.<br /> <br /> == File format fuzzing ==<br /> <br /> A file format fuzzer generates multiple malformed samples, and opens them sequentially. When the program crashes, debug information is kept for further investigation.<br /> <br /> One can attack:<br /> <br /> - the parser layer (container layer): file format constraints, structure, conventions, field sizes, flags, ...<br /> <br /> - the codec/application layer: lower-level attacks, aiming at the program's deeper internals<br /> <br /> One example of file format related vulnerabilities: MS04-028[http://www.microsoft.com/technet/security/bulletin/ms04-028.mspx] (KB833987) Microsoft's JPEG GDI+ vulnerability was a zero sized comment field, without content.<br /> <br /> <br /> Surprisingly, file format fuzzers are not that common;<br /> <br /> A generic file format fuzzer : Ilja van Sprundel's mangle.c[http://www.digitaldwarf.be/products/mangle.c]; &quot;it's usage is very simple, it takes a filename and headersize as input. it will then change approximatly between 0 and 10% of the header with random bytes.&quot; (from the author)<br /> <br /> Zzuf can act as a fuzzed file generator, http://sam.zoy.org/zzuf/<br /> <br /> One may use tools like Hachoir[http://hachoir.org/] as a generic parser for file format fuzzers development.<br /> <br /> == Fuzzers advantages ==<br /> <br /> ''The great advantage of fuzz testing is that the test design is extremely simple, and free of preconceptions about system behavior'' (from Wikipedia [http://en.wikipedia.org/wiki/Fuzz_testing]).<br /> <br /> The systematical/random approach allows this method to find bugs that would have often been missed by human eyes. Plus, when the tested system is totally closed (say, a SIP phone), fuzzing is one of the only means of reviewing it's quality.<br /> <br /> == Fuzzers limitations ==<br /> <br /> Fuzzers usually tend to find simple bugs; plus, the more a fuzzer is protocol-aware, the less weird errors it will find. This is why the exhaustive / random approach is still popular among the fuzzing community.<br /> <br /> Another problem is that when you do some black-box-testing, you usually attack a closed system, which increases difficulty to evaluate the dangerosity/impact of the found vulnerability (no debugging possibilities).<br /> <br /> == Why Fuzz? ==<br /> <br /> The purpose of fuzzing relies on the assumption that there are bugs within every program, which are waiting to be discovered. Therefore, a systematical approach should find them sooner or later.<br /> <br /> Fuzzing can add another point of view to classical software testing techniques (hand code review, debugging) because of it's non-human approach. It doesn't replace them, but is a reasonable complement, thanks to the limited work needed to put the procedure in place.<br /> <br /> Recent fuzzing initiatives:<br /> <br /> - The Month of Kernel Bugs[http://projects.info-pull.com/mokb/], which revealed an Apple Wireless flaw; see here[http://kernelfun.blogspot.com/]<br /> <br /> - The Month of Browser Bugs (review here[http://osvdb.org/blog/?p=127]); number of bugs found: MSIE: 25 Apple Safari: 2 Mozilla: 2 Opera: 1 Konqueror: 1<br /> <br /> == Fuzzers from OWASP ==<br /> <br /> Fuzzing with WebScarab [http://www.owasp.org/index.php/Fuzzing_with_WebScarab]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br /> <br /> JBroFuzz [http://www.owasp.org/index.php/JBroFuzz]: a stateless network protocol fuzzer<br /> <br /> WSFuzzer [http://www.owasp.org/index.php/WSFuzzer]: real-world manual SOAP pen testing tool<br /> <br /> == Technical resources on OWASP ==<br /> <br /> Fuzzing vectors [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors]<br /> <br /> == Sources ==<br /> <br /> Wikipedia article [http://en.wikipedia.org/wiki/Fuzz_testing]<br /> <br /> Fuzzing-related papers [http://www.threatmind.net/secwiki/FuzzingPapers]<br /> <br /> == Fuzzing tools ==<br /> <br /> The ultimate fuzzers list @ infosec [http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html]<br /> <br /> Another list @ hacksafe<br /> [http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/]<br /> <br /> The fuzzing mailing list [http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing]<br /> <br /> == Commercial products ==<br /> <br /> Codenomicon's product suite: [http://www.codenomicon.com/products/all.shtml]<br /> <br /> Beyond Security's beSTORM product: [http://www.beyondsecurity.com/bestorm_overview.html]</div>

Fthiery https://wiki.owasp.org/index.php?title=Fuzzing&diff=15739 2007-01-23T10:13:58Z

<p>Fthiery: /* Comparison with cryptanalysis */</p> <hr /> <div>''Fuzz testing'' or ''Fuzzing'' is a Black Box software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection in an automated fashion.<br /> <br /> == A trivial example: ==<br /> <br /> Lets's consider an integer in a program, which stores the result of a user's choice between 3 questions. When the user picks one, the choice will be 0, 1 or 2. Which makes three practical cases. But what if we transmit 3, or 255 ? We can, because integers are stored a static size variable. If the default switch case hasn't been implemented securely, the program may crash and lead to &quot;classical&quot; security issues: (un)exploitable buffer overflows, DoS, ...<br /> <br /> Fuzzing is the art of automatic bug finding, and it's role is to find software implementation faults, and identify them if possible.<br /> <br /> == History ==<br /> <br /> Fuzz testing was developed at the University of Wisconsin Madison in 1989 by Professor Barton Miller and his students. Their (continued) work can be found at http://www.cs.wisc.edu/~bart/fuzz/ ; it's mainly oriented towards command-line and UI fuzzing, and shows that modern operating systems are vulnerable to even simple fuzzing.<br /> <br /> == Fuzzer implementations ==<br /> <br /> A fuzzer is a program which injects automatically semi-random data into a program/stack and detect bugs.<br /> <br /> The data-generation part is made of generators, and vulnerability identification relies on debugging tools. Generators usually use combinations of static fuzzing vectors (known-to-be-dangerous values), or totally random data. New generation fuzzers use genetic algorithms to link injected data and observed impact. Such tools are not public yet.<br /> <br /> == Comparison with cryptanalysis ==<br /> <br /> The number of possible tryable solutions is ''the explorable solutions space''. The aim of cryptanalysis is to reduce this space, which means finding a way of having less keys to try than pure bruteforce to decrypt something. <br /> <br /> Most of the fuzzers are:<br /> <br /> - protocol/file-format dependant<br /> <br /> - data-type dependant<br /> <br /> <br /> Why? <br /> <br /> <br /> * First, because the fuzzer has to connect to the input channel, which is bound to the target.<br /> <br /> * Second, because a program only understands structured-enough data. If you connect to a web server in a raw way, it will only respond to listed commands such as GET (or eventually crash). It will take less time to start the string with &quot;GET &quot;, and fuzz the rest, but the drawback is that you'll skip all the tests on the first verb.<br /> <br /> <br /> In this regard, Fuzzers try to reduce the number of unuseful tests, i.e. the values we already know that there's little chance they'll work: you reduce impredictibility, in favor of speed.<br /> <br /> == Attack types ==<br /> <br /> A fuzzer would try combinations of attacks on:<br /> <br /> - numbers (signed/unsigned integers/float...)<br /> <br /> - chars (urls, command-line inputs)<br /> <br /> - metadata : user-input text (id3 tag)<br /> <br /> - pure binary sequences<br /> <br /> <br /> A common approach to fuzzing is to define lists of &quot;known-to-be-dangerous values&quot; (''fuzz vectors'') for each type, and to inject them or recombinations.<br /> <br /> - for integers: zero, possibly negative or very big numbers<br /> <br /> - for chars: escaped, interpretable characters / instructions (ex: For SQL Requests, quotes / commands...)<br /> <br /> - for binary: random ones<br /> <br /> Please refer to OWASP's Fuzz Vector's resource[http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors] for real-life fuzzing vectors examples and methodology.<br /> <br /> <br /> Protocols and file formats imply norms, which are sometimes blurry, very complicated or badly implemented : that's why developers sometimes mess up in the implementation process (because of time/cost constraints). That's why it can be interesting to take the opposite approach: take a norm, look at all mandatory features and constraints, and try all of them; forbidden/reserved values, linked parameters, field sizes. That would be ''hand-fuzzing''.<br /> <br /> == Application fuzzing ==<br /> <br /> Whatever the fuzzed system is, the attack vectors are within it's I/O. For a desktop app:<br /> <br /> - the UI (testing all the buttons sequences / text inputs)<br /> <br /> - the command-line options<br /> <br /> - the import/export capabilities (see file format fuzzing below)<br /> <br /> For a web app: urls, forms, user-generated content, RPC requests, ...<br /> <br /> == Protocol fuzzing ==<br /> <br /> A protocol fuzzer sends forged packets to the tested application, or eventually acts as a proxy, modifying requests on the fly and replaying them.<br /> <br /> == File format fuzzing ==<br /> <br /> A file format fuzzer generates multiple malformed samples, and opens them sequentially. When the program crashes, debug information is kept for further investigation.<br /> <br /> One can attack:<br /> <br /> - the parser layer (container layer): file format constraints, structure, conventions, field sizes, flags, ...<br /> <br /> - the codec/application layer: lower-level attacks, aiming at the program's deeper internals<br /> <br /> One example of file format related vulnerabilities: MS04-028[http://www.microsoft.com/technet/security/bulletin/ms04-028.mspx] (KB833987) Microsoft's JPEG GDI+ vulnerability was a zero sized comment field, without content.<br /> <br /> <br /> Surprisingly, file format fuzzers are not that common;<br /> <br /> A generic file format fuzzer : Ilja van Sprundel's mangle.c[http://www.digitaldwarf.be/products/mangle.c]; &quot;it's usage is very simple, it takes a filename and headersize as input. it will then change approximatly between 0 and 10% of the header with random bytes.&quot; (from the author)<br /> <br /> Zzuf can act as a fuzzed file generator, http://sam.zoy.org/zzuf/<br /> <br /> One may use tools like Hachoir[http://hachoir.org/] as a generic parser for file format fuzzers development.<br /> <br /> == Fuzzers advantages ==<br /> <br /> ''The great advantage of fuzz testing is that the test design is extremely simple, and free of preconceptions about system behavior'' (from Wikipedia [http://en.wikipedia.org/wiki/Fuzz_testing]).<br /> <br /> The systematical/random approach allows this method to find bugs that would have often been missed by human eyes. Plus, when the tested system is totally closed (say, a SIP phone), fuzzing is one of the only means of reviewing it's quality.<br /> <br /> == Fuzzers limitations ==<br /> <br /> Fuzzers usually tend to find simple bugs; plus, the more a fuzzer is protocol-aware, the less weird errors it will find. This is why the exhaustive / random approach is still popular among the fuzzing community.<br /> <br /> Another problem is that when you do some black-box-testing, you usually attack a closed system, which increases difficulty to evaluate the dangerosity/impact of the found vulnerability (no debugging possibilities).<br /> <br /> == Why Fuzz? ==<br /> <br /> The purpose of fuzzing relies on the assumption that there are bugs within every program, which are waiting to be discovered. Therefore, a systematical approach should find them sooner or later.<br /> <br /> Fuzzing can add another point of view to classical software testing techniques (hand code review, debugging) because of it's non-human approach. It doesn't replace them, but is a reasonable complement, thanks to the limited work needed to put the procedure in place.<br /> <br /> Recent fuzzing initiatives:<br /> <br /> - The Month of Kernel Bugs[http://projects.info-pull.com/mokb/], which revealed an Apple Wireless flaw; see here[http://kernelfun.blogspot.com/]<br /> <br /> - The Month of Browser Bugs (review here[http://osvdb.org/blog/?p=127]); number of bugs found: MSIE: 25 Apple Safari: 2 Mozilla: 2 Opera: 1 Konqueror: 1<br /> <br /> == Fuzzers from OWASP ==<br /> <br /> Fuzzing with WebScarab [http://www.owasp.org/index.php/Fuzzing_with_WebScarab]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br /> <br /> JBroFuzz [http://www.owasp.org/index.php/JBroFuzz]: a stateless network protocol fuzzer<br /> <br /> WSFuzzer [http://www.owasp.org/index.php/WSFuzzer]: real-world manual SOAP pen testing tool<br /> <br /> == Technical resources on OWASP ==<br /> <br /> Fuzzing vectors [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors]<br /> <br /> == Sources ==<br /> <br /> Wikipedia article [http://en.wikipedia.org/wiki/Fuzz_testing]<br /> <br /> Fuzzing-related papers [http://www.threatmind.net/secwiki/FuzzingPapers]<br /> <br /> == Fuzzing tools ==<br /> <br /> The ultimate fuzzers list @ infosec [http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html]<br /> <br /> Another list @ hacksafe<br /> [http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/]<br /> <br /> The fuzzing mailing list [http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing]<br /> <br /> == Commercial products ==<br /> <br /> Codenomicon's product suite: [http://www.codenomicon.com/products/all.shtml]<br /> <br /> Beyond Security's beSTORM product: [http://www.beyondsecurity.com/bestorm_overview.html]</div>

Fthiery https://wiki.owasp.org/index.php?title=Fuzzing&diff=15738 2007-01-23T10:13:06Z

<p>Fthiery: /* Why Fuzz? */</p> <hr /> <div>''Fuzz testing'' or ''Fuzzing'' is a Black Box software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection in an automated fashion.<br /> <br /> == A trivial example: ==<br /> <br /> Lets's consider an integer in a program, which stores the result of a user's choice between 3 questions. When the user picks one, the choice will be 0, 1 or 2. Which makes three practical cases. But what if we transmit 3, or 255 ? We can, because integers are stored a static size variable. If the default switch case hasn't been implemented securely, the program may crash and lead to &quot;classical&quot; security issues: (un)exploitable buffer overflows, DoS, ...<br /> <br /> Fuzzing is the art of automatic bug finding, and it's role is to find software implementation faults, and identify them if possible.<br /> <br /> == History ==<br /> <br /> Fuzz testing was developed at the University of Wisconsin Madison in 1989 by Professor Barton Miller and his students. Their (continued) work can be found at http://www.cs.wisc.edu/~bart/fuzz/ ; it's mainly oriented towards command-line and UI fuzzing, and shows that modern operating systems are vulnerable to even simple fuzzing.<br /> <br /> == Fuzzer implementations ==<br /> <br /> A fuzzer is a program which injects automatically semi-random data into a program/stack and detect bugs.<br /> <br /> The data-generation part is made of generators, and vulnerability identification relies on debugging tools. Generators usually use combinations of static fuzzing vectors (known-to-be-dangerous values), or totally random data. New generation fuzzers use genetic algorithms to link injected data and observed impact. Such tools are not public yet.<br /> <br /> == Comparison with cryptanalysis ==<br /> <br /> The number of possible tryable solutions is ''the explorable solutions space''. The aim of cryptanalysis is to reduce this space, which means finding a way of having less keys to try than pure bruteforce to decrypt something. <br /> <br /> Most of the fuzzers are:<br /> <br /> - protocol/file-format dependant<br /> <br /> - data-type dependant<br /> <br /> <br /> Why? <br /> <br /> First, because the fuzzer has to connect to the input channel, which is bound to the target.<br /> <br /> Second, because a program only understands structured-enough data. If you connect to a web server in a raw way, it will only respond to listed commands such as GET (or eventually crash). It will take less time to start the string with &quot;GET &quot;, and fuzz the rest, but the drawback is that you'll skip all the tests on the first verb.<br /> <br /> In this regard, Fuzzers try to reduce the number of unuseful tests, i.e. the values we already know that there's little chance they'll work: you reduce impredictibility, in favor of speed.<br /> <br /> == Attack types ==<br /> <br /> A fuzzer would try combinations of attacks on:<br /> <br /> - numbers (signed/unsigned integers/float...)<br /> <br /> - chars (urls, command-line inputs)<br /> <br /> - metadata : user-input text (id3 tag)<br /> <br /> - pure binary sequences<br /> <br /> <br /> A common approach to fuzzing is to define lists of &quot;known-to-be-dangerous values&quot; (''fuzz vectors'') for each type, and to inject them or recombinations.<br /> <br /> - for integers: zero, possibly negative or very big numbers<br /> <br /> - for chars: escaped, interpretable characters / instructions (ex: For SQL Requests, quotes / commands...)<br /> <br /> - for binary: random ones<br /> <br /> Please refer to OWASP's Fuzz Vector's resource[http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors] for real-life fuzzing vectors examples and methodology.<br /> <br /> <br /> Protocols and file formats imply norms, which are sometimes blurry, very complicated or badly implemented : that's why developers sometimes mess up in the implementation process (because of time/cost constraints). That's why it can be interesting to take the opposite approach: take a norm, look at all mandatory features and constraints, and try all of them; forbidden/reserved values, linked parameters, field sizes. That would be ''hand-fuzzing''.<br /> <br /> == Application fuzzing ==<br /> <br /> Whatever the fuzzed system is, the attack vectors are within it's I/O. For a desktop app:<br /> <br /> - the UI (testing all the buttons sequences / text inputs)<br /> <br /> - the command-line options<br /> <br /> - the import/export capabilities (see file format fuzzing below)<br /> <br /> For a web app: urls, forms, user-generated content, RPC requests, ...<br /> <br /> == Protocol fuzzing ==<br /> <br /> A protocol fuzzer sends forged packets to the tested application, or eventually acts as a proxy, modifying requests on the fly and replaying them.<br /> <br /> == File format fuzzing ==<br /> <br /> A file format fuzzer generates multiple malformed samples, and opens them sequentially. When the program crashes, debug information is kept for further investigation.<br /> <br /> One can attack:<br /> <br /> - the parser layer (container layer): file format constraints, structure, conventions, field sizes, flags, ...<br /> <br /> - the codec/application layer: lower-level attacks, aiming at the program's deeper internals<br /> <br /> One example of file format related vulnerabilities: MS04-028[http://www.microsoft.com/technet/security/bulletin/ms04-028.mspx] (KB833987) Microsoft's JPEG GDI+ vulnerability was a zero sized comment field, without content.<br /> <br /> <br /> Surprisingly, file format fuzzers are not that common;<br /> <br /> A generic file format fuzzer : Ilja van Sprundel's mangle.c[http://www.digitaldwarf.be/products/mangle.c]; &quot;it's usage is very simple, it takes a filename and headersize as input. it will then change approximatly between 0 and 10% of the header with random bytes.&quot; (from the author)<br /> <br /> Zzuf can act as a fuzzed file generator, http://sam.zoy.org/zzuf/<br /> <br /> One may use tools like Hachoir[http://hachoir.org/] as a generic parser for file format fuzzers development.<br /> <br /> == Fuzzers advantages ==<br /> <br /> ''The great advantage of fuzz testing is that the test design is extremely simple, and free of preconceptions about system behavior'' (from Wikipedia [http://en.wikipedia.org/wiki/Fuzz_testing]).<br /> <br /> The systematical/random approach allows this method to find bugs that would have often been missed by human eyes. Plus, when the tested system is totally closed (say, a SIP phone), fuzzing is one of the only means of reviewing it's quality.<br /> <br /> == Fuzzers limitations ==<br /> <br /> Fuzzers usually tend to find simple bugs; plus, the more a fuzzer is protocol-aware, the less weird errors it will find. This is why the exhaustive / random approach is still popular among the fuzzing community.<br /> <br /> Another problem is that when you do some black-box-testing, you usually attack a closed system, which increases difficulty to evaluate the dangerosity/impact of the found vulnerability (no debugging possibilities).<br /> <br /> == Why Fuzz? ==<br /> <br /> The purpose of fuzzing relies on the assumption that there are bugs within every program, which are waiting to be discovered. Therefore, a systematical approach should find them sooner or later.<br /> <br /> Fuzzing can add another point of view to classical software testing techniques (hand code review, debugging) because of it's non-human approach. It doesn't replace them, but is a reasonable complement, thanks to the limited work needed to put the procedure in place.<br /> <br /> Recent fuzzing initiatives:<br /> <br /> - The Month of Kernel Bugs[http://projects.info-pull.com/mokb/], which revealed an Apple Wireless flaw; see here[http://kernelfun.blogspot.com/]<br /> <br /> - The Month of Browser Bugs (review here[http://osvdb.org/blog/?p=127]); number of bugs found: MSIE: 25 Apple Safari: 2 Mozilla: 2 Opera: 1 Konqueror: 1<br /> <br /> == Fuzzers from OWASP ==<br /> <br /> Fuzzing with WebScarab [http://www.owasp.org/index.php/Fuzzing_with_WebScarab]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br /> <br /> JBroFuzz [http://www.owasp.org/index.php/JBroFuzz]: a stateless network protocol fuzzer<br /> <br /> WSFuzzer [http://www.owasp.org/index.php/WSFuzzer]: real-world manual SOAP pen testing tool<br /> <br /> == Technical resources on OWASP ==<br /> <br /> Fuzzing vectors [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors]<br /> <br /> == Sources ==<br /> <br /> Wikipedia article [http://en.wikipedia.org/wiki/Fuzz_testing]<br /> <br /> Fuzzing-related papers [http://www.threatmind.net/secwiki/FuzzingPapers]<br /> <br /> == Fuzzing tools ==<br /> <br /> The ultimate fuzzers list @ infosec [http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html]<br /> <br /> Another list @ hacksafe<br /> [http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/]<br /> <br /> The fuzzing mailing list [http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing]<br /> <br /> == Commercial products ==<br /> <br /> Codenomicon's product suite: [http://www.codenomicon.com/products/all.shtml]<br /> <br /> Beyond Security's beSTORM product: [http://www.beyondsecurity.com/bestorm_overview.html]</div>

Fthiery https://wiki.owasp.org/index.php?title=Fuzzing&diff=15737 2007-01-23T09:57:23Z

<p>Fthiery: /* Comparison with cryptanalysis */</p> <hr /> <div>''Fuzz testing'' or ''Fuzzing'' is a Black Box software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection in an automated fashion.<br /> <br /> == A trivial example: ==<br /> <br /> Lets's consider an integer in a program, which stores the result of a user's choice between 3 questions. When the user picks one, the choice will be 0, 1 or 2. Which makes three practical cases. But what if we transmit 3, or 255 ? We can, because integers are stored a static size variable. If the default switch case hasn't been implemented securely, the program may crash and lead to &quot;classical&quot; security issues: (un)exploitable buffer overflows, DoS, ...<br /> <br /> Fuzzing is the art of automatic bug finding, and it's role is to find software implementation faults, and identify them if possible.<br /> <br /> == History ==<br /> <br /> Fuzz testing was developed at the University of Wisconsin Madison in 1989 by Professor Barton Miller and his students. Their (continued) work can be found at http://www.cs.wisc.edu/~bart/fuzz/ ; it's mainly oriented towards command-line and UI fuzzing, and shows that modern operating systems are vulnerable to even simple fuzzing.<br /> <br /> == Fuzzer implementations ==<br /> <br /> A fuzzer is a program which injects automatically semi-random data into a program/stack and detect bugs.<br /> <br /> The data-generation part is made of generators, and vulnerability identification relies on debugging tools. Generators usually use combinations of static fuzzing vectors (known-to-be-dangerous values), or totally random data. New generation fuzzers use genetic algorithms to link injected data and observed impact. Such tools are not public yet.<br /> <br /> == Comparison with cryptanalysis ==<br /> <br /> The number of possible tryable solutions is ''the explorable solutions space''. The aim of cryptanalysis is to reduce this space, which means finding a way of having less keys to try than pure bruteforce to decrypt something. <br /> <br /> Most of the fuzzers are:<br /> <br /> - protocol/file-format dependant<br /> <br /> - data-type dependant<br /> <br /> <br /> Why? <br /> <br /> First, because the fuzzer has to connect to the input channel, which is bound to the target.<br /> <br /> Second, because a program only understands structured-enough data. If you connect to a web server in a raw way, it will only respond to listed commands such as GET (or eventually crash). It will take less time to start the string with &quot;GET &quot;, and fuzz the rest, but the drawback is that you'll skip all the tests on the first verb.<br /> <br /> In this regard, Fuzzers try to reduce the number of unuseful tests, i.e. the values we already know that there's little chance they'll work: you reduce impredictibility, in favor of speed.<br /> <br /> == Attack types ==<br /> <br /> A fuzzer would try combinations of attacks on:<br /> <br /> - numbers (signed/unsigned integers/float...)<br /> <br /> - chars (urls, command-line inputs)<br /> <br /> - metadata : user-input text (id3 tag)<br /> <br /> - pure binary sequences<br /> <br /> <br /> A common approach to fuzzing is to define lists of &quot;known-to-be-dangerous values&quot; (''fuzz vectors'') for each type, and to inject them or recombinations.<br /> <br /> - for integers: zero, possibly negative or very big numbers<br /> <br /> - for chars: escaped, interpretable characters / instructions (ex: For SQL Requests, quotes / commands...)<br /> <br /> - for binary: random ones<br /> <br /> Please refer to OWASP's Fuzz Vector's resource[http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors] for real-life fuzzing vectors examples and methodology.<br /> <br /> <br /> Protocols and file formats imply norms, which are sometimes blurry, very complicated or badly implemented : that's why developers sometimes mess up in the implementation process (because of time/cost constraints). That's why it can be interesting to take the opposite approach: take a norm, look at all mandatory features and constraints, and try all of them; forbidden/reserved values, linked parameters, field sizes. That would be ''hand-fuzzing''.<br /> <br /> == Application fuzzing ==<br /> <br /> Whatever the fuzzed system is, the attack vectors are within it's I/O. For a desktop app:<br /> <br /> - the UI (testing all the buttons sequences / text inputs)<br /> <br /> - the command-line options<br /> <br /> - the import/export capabilities (see file format fuzzing below)<br /> <br /> For a web app: urls, forms, user-generated content, RPC requests, ...<br /> <br /> == Protocol fuzzing ==<br /> <br /> A protocol fuzzer sends forged packets to the tested application, or eventually acts as a proxy, modifying requests on the fly and replaying them.<br /> <br /> == File format fuzzing ==<br /> <br /> A file format fuzzer generates multiple malformed samples, and opens them sequentially. When the program crashes, debug information is kept for further investigation.<br /> <br /> One can attack:<br /> <br /> - the parser layer (container layer): file format constraints, structure, conventions, field sizes, flags, ...<br /> <br /> - the codec/application layer: lower-level attacks, aiming at the program's deeper internals<br /> <br /> One example of file format related vulnerabilities: MS04-028[http://www.microsoft.com/technet/security/bulletin/ms04-028.mspx] (KB833987) Microsoft's JPEG GDI+ vulnerability was a zero sized comment field, without content.<br /> <br /> <br /> Surprisingly, file format fuzzers are not that common;<br /> <br /> A generic file format fuzzer : Ilja van Sprundel's mangle.c[http://www.digitaldwarf.be/products/mangle.c]; &quot;it's usage is very simple, it takes a filename and headersize as input. it will then change approximatly between 0 and 10% of the header with random bytes.&quot; (from the author)<br /> <br /> Zzuf can act as a fuzzed file generator, http://sam.zoy.org/zzuf/<br /> <br /> One may use tools like Hachoir[http://hachoir.org/] as a generic parser for file format fuzzers development.<br /> <br /> == Fuzzers advantages ==<br /> <br /> ''The great advantage of fuzz testing is that the test design is extremely simple, and free of preconceptions about system behavior'' (from Wikipedia [http://en.wikipedia.org/wiki/Fuzz_testing]).<br /> <br /> The systematical/random approach allows this method to find bugs that would have often been missed by human eyes. Plus, when the tested system is totally closed (say, a SIP phone), fuzzing is one of the only means of reviewing it's quality.<br /> <br /> == Fuzzers limitations ==<br /> <br /> Fuzzers usually tend to find simple bugs; plus, the more a fuzzer is protocol-aware, the less weird errors it will find. This is why the exhaustive / random approach is still popular among the fuzzing community.<br /> <br /> Another problem is that when you do some black-box-testing, you usually attack a closed system, which increases difficulty to evaluate the dangerosity/impact of the found vulnerability (no debugging possibilities).<br /> <br /> == Why Fuzz? ==<br /> <br /> The purpose of fuzzing relies on the assumption that there are bugs within every program, which are waiting to be discovered. Therefore, a systematical approach should find them sooner or later.<br /> <br /> Fuzzing can add another point of view to classical software testing techniques (hand code review, debugging) because of it's non-human approach. It doesn't replace them, but is a reasonable complement, thanks to the limited work needed to put the procedure in place.<br /> <br /> == Fuzzers from OWASP ==<br /> <br /> Fuzzing with WebScarab [http://www.owasp.org/index.php/Fuzzing_with_WebScarab]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br /> <br /> JBroFuzz [http://www.owasp.org/index.php/JBroFuzz]: a stateless network protocol fuzzer<br /> <br /> WSFuzzer [http://www.owasp.org/index.php/WSFuzzer]: real-world manual SOAP pen testing tool<br /> <br /> == Technical resources on OWASP ==<br /> <br /> Fuzzing vectors [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors]<br /> <br /> == Sources ==<br /> <br /> Wikipedia article [http://en.wikipedia.org/wiki/Fuzz_testing]<br /> <br /> Fuzzing-related papers [http://www.threatmind.net/secwiki/FuzzingPapers]<br /> <br /> == Fuzzing tools ==<br /> <br /> The ultimate fuzzers list @ infosec [http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html]<br /> <br /> Another list @ hacksafe<br /> [http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/]<br /> <br /> The fuzzing mailing list [http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing]<br /> <br /> == Commercial products ==<br /> <br /> Codenomicon's product suite: [http://www.codenomicon.com/products/all.shtml]<br /> <br /> Beyond Security's beSTORM product: [http://www.beyondsecurity.com/bestorm_overview.html]</div>

Fthiery https://wiki.owasp.org/index.php?title=Fuzzing&diff=15736 2007-01-23T09:56:38Z

<p>Fthiery: /* Fuzzer implementations */</p> <hr /> <div>''Fuzz testing'' or ''Fuzzing'' is a Black Box software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection in an automated fashion.<br /> <br /> == A trivial example: ==<br /> <br /> Lets's consider an integer in a program, which stores the result of a user's choice between 3 questions. When the user picks one, the choice will be 0, 1 or 2. Which makes three practical cases. But what if we transmit 3, or 255 ? We can, because integers are stored a static size variable. If the default switch case hasn't been implemented securely, the program may crash and lead to &quot;classical&quot; security issues: (un)exploitable buffer overflows, DoS, ...<br /> <br /> Fuzzing is the art of automatic bug finding, and it's role is to find software implementation faults, and identify them if possible.<br /> <br /> == History ==<br /> <br /> Fuzz testing was developed at the University of Wisconsin Madison in 1989 by Professor Barton Miller and his students. Their (continued) work can be found at http://www.cs.wisc.edu/~bart/fuzz/ ; it's mainly oriented towards command-line and UI fuzzing, and shows that modern operating systems are vulnerable to even simple fuzzing.<br /> <br /> == Fuzzer implementations ==<br /> <br /> A fuzzer is a program which injects automatically semi-random data into a program/stack and detect bugs.<br /> <br /> The data-generation part is made of generators, and vulnerability identification relies on debugging tools. Generators usually use combinations of static fuzzing vectors (known-to-be-dangerous values), or totally random data. New generation fuzzers use genetic algorithms to link injected data and observed impact. Such tools are not public yet.<br /> <br /> == Comparison with cryptanalysis ==<br /> <br /> The number of possible tryable solutions is ''the explorable solutions space''. The aim of cryptanalysis is to reduce this space, which means finding a way of having less keys to try than pure bruteforce to decrypt something. <br /> <br /> Most of the fuzzers are:<br /> <br /> - protocol/file-format dependant<br /> <br /> - data-type dependant<br /> <br /> Why? <br /> <br /> First, because the fuzzer has to connect to the input channel, which is bound to the target.<br /> <br /> Second, because a program only understands structured-enough data. If you connect to a web server in a raw way, it will only respond to listed commands such as GET (or eventually crash). It will take less time to start the string with &quot;GET &quot;, and fuzz the rest, but the drawback is that you'll skip all the tests on the first verb.<br /> <br /> In this regard, Fuzzers try to reduce the number of unuseful tests, i.e. the values we already know that there's little chance they'll work: you reduce impredictibility, in favor of speed.<br /> <br /> == Attack types ==<br /> <br /> A fuzzer would try combinations of attacks on:<br /> <br /> - numbers (signed/unsigned integers/float...)<br /> <br /> - chars (urls, command-line inputs)<br /> <br /> - metadata : user-input text (id3 tag)<br /> <br /> - pure binary sequences<br /> <br /> <br /> A common approach to fuzzing is to define lists of &quot;known-to-be-dangerous values&quot; (''fuzz vectors'') for each type, and to inject them or recombinations.<br /> <br /> - for integers: zero, possibly negative or very big numbers<br /> <br /> - for chars: escaped, interpretable characters / instructions (ex: For SQL Requests, quotes / commands...)<br /> <br /> - for binary: random ones<br /> <br /> Please refer to OWASP's Fuzz Vector's resource[http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors] for real-life fuzzing vectors examples and methodology.<br /> <br /> <br /> Protocols and file formats imply norms, which are sometimes blurry, very complicated or badly implemented : that's why developers sometimes mess up in the implementation process (because of time/cost constraints). That's why it can be interesting to take the opposite approach: take a norm, look at all mandatory features and constraints, and try all of them; forbidden/reserved values, linked parameters, field sizes. That would be ''hand-fuzzing''.<br /> <br /> == Application fuzzing ==<br /> <br /> Whatever the fuzzed system is, the attack vectors are within it's I/O. For a desktop app:<br /> <br /> - the UI (testing all the buttons sequences / text inputs)<br /> <br /> - the command-line options<br /> <br /> - the import/export capabilities (see file format fuzzing below)<br /> <br /> For a web app: urls, forms, user-generated content, RPC requests, ...<br /> <br /> == Protocol fuzzing ==<br /> <br /> A protocol fuzzer sends forged packets to the tested application, or eventually acts as a proxy, modifying requests on the fly and replaying them.<br /> <br /> == File format fuzzing ==<br /> <br /> A file format fuzzer generates multiple malformed samples, and opens them sequentially. When the program crashes, debug information is kept for further investigation.<br /> <br /> One can attack:<br /> <br /> - the parser layer (container layer): file format constraints, structure, conventions, field sizes, flags, ...<br /> <br /> - the codec/application layer: lower-level attacks, aiming at the program's deeper internals<br /> <br /> One example of file format related vulnerabilities: MS04-028[http://www.microsoft.com/technet/security/bulletin/ms04-028.mspx] (KB833987) Microsoft's JPEG GDI+ vulnerability was a zero sized comment field, without content.<br /> <br /> <br /> Surprisingly, file format fuzzers are not that common;<br /> <br /> A generic file format fuzzer : Ilja van Sprundel's mangle.c[http://www.digitaldwarf.be/products/mangle.c]; &quot;it's usage is very simple, it takes a filename and headersize as input. it will then change approximatly between 0 and 10% of the header with random bytes.&quot; (from the author)<br /> <br /> Zzuf can act as a fuzzed file generator, http://sam.zoy.org/zzuf/<br /> <br /> One may use tools like Hachoir[http://hachoir.org/] as a generic parser for file format fuzzers development.<br /> <br /> == Fuzzers advantages ==<br /> <br /> ''The great advantage of fuzz testing is that the test design is extremely simple, and free of preconceptions about system behavior'' (from Wikipedia [http://en.wikipedia.org/wiki/Fuzz_testing]).<br /> <br /> The systematical/random approach allows this method to find bugs that would have often been missed by human eyes. Plus, when the tested system is totally closed (say, a SIP phone), fuzzing is one of the only means of reviewing it's quality.<br /> <br /> == Fuzzers limitations ==<br /> <br /> Fuzzers usually tend to find simple bugs; plus, the more a fuzzer is protocol-aware, the less weird errors it will find. This is why the exhaustive / random approach is still popular among the fuzzing community.<br /> <br /> Another problem is that when you do some black-box-testing, you usually attack a closed system, which increases difficulty to evaluate the dangerosity/impact of the found vulnerability (no debugging possibilities).<br /> <br /> == Why Fuzz? ==<br /> <br /> The purpose of fuzzing relies on the assumption that there are bugs within every program, which are waiting to be discovered. Therefore, a systematical approach should find them sooner or later.<br /> <br /> Fuzzing can add another point of view to classical software testing techniques (hand code review, debugging) because of it's non-human approach. It doesn't replace them, but is a reasonable complement, thanks to the limited work needed to put the procedure in place.<br /> <br /> == Fuzzers from OWASP ==<br /> <br /> Fuzzing with WebScarab [http://www.owasp.org/index.php/Fuzzing_with_WebScarab]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br /> <br /> JBroFuzz [http://www.owasp.org/index.php/JBroFuzz]: a stateless network protocol fuzzer<br /> <br /> WSFuzzer [http://www.owasp.org/index.php/WSFuzzer]: real-world manual SOAP pen testing tool<br /> <br /> == Technical resources on OWASP ==<br /> <br /> Fuzzing vectors [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors]<br /> <br /> == Sources ==<br /> <br /> Wikipedia article [http://en.wikipedia.org/wiki/Fuzz_testing]<br /> <br /> Fuzzing-related papers [http://www.threatmind.net/secwiki/FuzzingPapers]<br /> <br /> == Fuzzing tools ==<br /> <br /> The ultimate fuzzers list @ infosec [http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html]<br /> <br /> Another list @ hacksafe<br /> [http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/]<br /> <br /> The fuzzing mailing list [http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing]<br /> <br /> == Commercial products ==<br /> <br /> Codenomicon's product suite: [http://www.codenomicon.com/products/all.shtml]<br /> <br /> Beyond Security's beSTORM product: [http://www.beyondsecurity.com/bestorm_overview.html]</div>

Fthiery https://wiki.owasp.org/index.php?title=Fuzzing&diff=15735 2007-01-23T09:56:11Z

<p>Fthiery: /* Fuzzer implementations */</p> <hr /> <div>''Fuzz testing'' or ''Fuzzing'' is a Black Box software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection in an automated fashion.<br /> <br /> == A trivial example: ==<br /> <br /> Lets's consider an integer in a program, which stores the result of a user's choice between 3 questions. When the user picks one, the choice will be 0, 1 or 2. Which makes three practical cases. But what if we transmit 3, or 255 ? We can, because integers are stored a static size variable. If the default switch case hasn't been implemented securely, the program may crash and lead to &quot;classical&quot; security issues: (un)exploitable buffer overflows, DoS, ...<br /> <br /> Fuzzing is the art of automatic bug finding, and it's role is to find software implementation faults, and identify them if possible.<br /> <br /> == History ==<br /> <br /> Fuzz testing was developed at the University of Wisconsin Madison in 1989 by Professor Barton Miller and his students. Their (continued) work can be found at http://www.cs.wisc.edu/~bart/fuzz/ ; it's mainly oriented towards command-line and UI fuzzing, and shows that modern operating systems are vulnerable to even simple fuzzing.<br /> <br /> == Fuzzer implementations ==<br /> <br /> A fuzzer is a program which injects automatically semi-random data into a program/stack and detect bugs.<br /> <br /> The data-generation part is made of generators, and vulnerability identification relies on debugging tools.<br /> <br /> Generators usually use combinations of static fuzzing vectors (known-to-be-dangerous values), or totally random data.<br /> <br /> New generation fuzzers use genetic algorithms to link injected data and observed impact. Such tools are not public yet.<br /> <br /> == Comparison with cryptanalysis ==<br /> <br /> The number of possible tryable solutions is ''the explorable solutions space''. The aim of cryptanalysis is to reduce this space, which means finding a way of having less keys to try than pure bruteforce to decrypt something. <br /> <br /> Most of the fuzzers are:<br /> <br /> - protocol/file-format dependant<br /> <br /> - data-type dependant<br /> <br /> Why? <br /> <br /> First, because the fuzzer has to connect to the input channel, which is bound to the target.<br /> <br /> Second, because a program only understands structured-enough data. If you connect to a web server in a raw way, it will only respond to listed commands such as GET (or eventually crash). It will take less time to start the string with &quot;GET &quot;, and fuzz the rest, but the drawback is that you'll skip all the tests on the first verb.<br /> <br /> In this regard, Fuzzers try to reduce the number of unuseful tests, i.e. the values we already know that there's little chance they'll work: you reduce impredictibility, in favor of speed.<br /> <br /> == Attack types ==<br /> <br /> A fuzzer would try combinations of attacks on:<br /> <br /> - numbers (signed/unsigned integers/float...)<br /> <br /> - chars (urls, command-line inputs)<br /> <br /> - metadata : user-input text (id3 tag)<br /> <br /> - pure binary sequences<br /> <br /> <br /> A common approach to fuzzing is to define lists of &quot;known-to-be-dangerous values&quot; (''fuzz vectors'') for each type, and to inject them or recombinations.<br /> <br /> - for integers: zero, possibly negative or very big numbers<br /> <br /> - for chars: escaped, interpretable characters / instructions (ex: For SQL Requests, quotes / commands...)<br /> <br /> - for binary: random ones<br /> <br /> Please refer to OWASP's Fuzz Vector's resource[http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors] for real-life fuzzing vectors examples and methodology.<br /> <br /> <br /> Protocols and file formats imply norms, which are sometimes blurry, very complicated or badly implemented : that's why developers sometimes mess up in the implementation process (because of time/cost constraints). That's why it can be interesting to take the opposite approach: take a norm, look at all mandatory features and constraints, and try all of them; forbidden/reserved values, linked parameters, field sizes. That would be ''hand-fuzzing''.<br /> <br /> == Application fuzzing ==<br /> <br /> Whatever the fuzzed system is, the attack vectors are within it's I/O. For a desktop app:<br /> <br /> - the UI (testing all the buttons sequences / text inputs)<br /> <br /> - the command-line options<br /> <br /> - the import/export capabilities (see file format fuzzing below)<br /> <br /> For a web app: urls, forms, user-generated content, RPC requests, ...<br /> <br /> == Protocol fuzzing ==<br /> <br /> A protocol fuzzer sends forged packets to the tested application, or eventually acts as a proxy, modifying requests on the fly and replaying them.<br /> <br /> == File format fuzzing ==<br /> <br /> A file format fuzzer generates multiple malformed samples, and opens them sequentially. When the program crashes, debug information is kept for further investigation.<br /> <br /> One can attack:<br /> <br /> - the parser layer (container layer): file format constraints, structure, conventions, field sizes, flags, ...<br /> <br /> - the codec/application layer: lower-level attacks, aiming at the program's deeper internals<br /> <br /> One example of file format related vulnerabilities: MS04-028[http://www.microsoft.com/technet/security/bulletin/ms04-028.mspx] (KB833987) Microsoft's JPEG GDI+ vulnerability was a zero sized comment field, without content.<br /> <br /> <br /> Surprisingly, file format fuzzers are not that common;<br /> <br /> A generic file format fuzzer : Ilja van Sprundel's mangle.c[http://www.digitaldwarf.be/products/mangle.c]; &quot;it's usage is very simple, it takes a filename and headersize as input. it will then change approximatly between 0 and 10% of the header with random bytes.&quot; (from the author)<br /> <br /> Zzuf can act as a fuzzed file generator, http://sam.zoy.org/zzuf/<br /> <br /> One may use tools like Hachoir[http://hachoir.org/] as a generic parser for file format fuzzers development.<br /> <br /> == Fuzzers advantages ==<br /> <br /> ''The great advantage of fuzz testing is that the test design is extremely simple, and free of preconceptions about system behavior'' (from Wikipedia [http://en.wikipedia.org/wiki/Fuzz_testing]).<br /> <br /> The systematical/random approach allows this method to find bugs that would have often been missed by human eyes. Plus, when the tested system is totally closed (say, a SIP phone), fuzzing is one of the only means of reviewing it's quality.<br /> <br /> == Fuzzers limitations ==<br /> <br /> Fuzzers usually tend to find simple bugs; plus, the more a fuzzer is protocol-aware, the less weird errors it will find. This is why the exhaustive / random approach is still popular among the fuzzing community.<br /> <br /> Another problem is that when you do some black-box-testing, you usually attack a closed system, which increases difficulty to evaluate the dangerosity/impact of the found vulnerability (no debugging possibilities).<br /> <br /> == Why Fuzz? ==<br /> <br /> The purpose of fuzzing relies on the assumption that there are bugs within every program, which are waiting to be discovered. Therefore, a systematical approach should find them sooner or later.<br /> <br /> Fuzzing can add another point of view to classical software testing techniques (hand code review, debugging) because of it's non-human approach. It doesn't replace them, but is a reasonable complement, thanks to the limited work needed to put the procedure in place.<br /> <br /> == Fuzzers from OWASP ==<br /> <br /> Fuzzing with WebScarab [http://www.owasp.org/index.php/Fuzzing_with_WebScarab]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br /> <br /> JBroFuzz [http://www.owasp.org/index.php/JBroFuzz]: a stateless network protocol fuzzer<br /> <br /> WSFuzzer [http://www.owasp.org/index.php/WSFuzzer]: real-world manual SOAP pen testing tool<br /> <br /> == Technical resources on OWASP ==<br /> <br /> Fuzzing vectors [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors]<br /> <br /> == Sources ==<br /> <br /> Wikipedia article [http://en.wikipedia.org/wiki/Fuzz_testing]<br /> <br /> Fuzzing-related papers [http://www.threatmind.net/secwiki/FuzzingPapers]<br /> <br /> == Fuzzing tools ==<br /> <br /> The ultimate fuzzers list @ infosec [http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html]<br /> <br /> Another list @ hacksafe<br /> [http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/]<br /> <br /> The fuzzing mailing list [http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing]<br /> <br /> == Commercial products ==<br /> <br /> Codenomicon's product suite: [http://www.codenomicon.com/products/all.shtml]<br /> <br /> Beyond Security's beSTORM product: [http://www.beyondsecurity.com/bestorm_overview.html]</div>

Fthiery https://wiki.owasp.org/index.php?title=Fuzzing&diff=15734 2007-01-23T09:50:28Z

<p>Fthiery: /* History */</p> <hr /> <div>''Fuzz testing'' or ''Fuzzing'' is a Black Box software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection in an automated fashion.<br /> <br /> == A trivial example: ==<br /> <br /> Lets's consider an integer in a program, which stores the result of a user's choice between 3 questions. When the user picks one, the choice will be 0, 1 or 2. Which makes three practical cases. But what if we transmit 3, or 255 ? We can, because integers are stored a static size variable. If the default switch case hasn't been implemented securely, the program may crash and lead to &quot;classical&quot; security issues: (un)exploitable buffer overflows, DoS, ...<br /> <br /> Fuzzing is the art of automatic bug finding, and it's role is to find software implementation faults, and identify them if possible.<br /> <br /> == History ==<br /> <br /> Fuzz testing was developed at the University of Wisconsin Madison in 1989 by Professor Barton Miller and his students. Their (continued) work can be found at http://www.cs.wisc.edu/~bart/fuzz/ ; it's mainly oriented towards command-line and UI fuzzing, and shows that modern operating systems are vulnerable to even simple fuzzing.<br /> <br /> == Fuzzer implementations ==<br /> <br /> A fuzzer is a program which injects automatically semi-random data into a program/stack and detect bugs.<br /> The data-generation part is made of generators, and vulnerability identification relies on debugging tools.<br /> <br /> == Comparison with cryptanalysis ==<br /> <br /> The number of possible tryable solutions is ''the explorable solutions space''. The aim of cryptanalysis is to reduce this space, which means finding a way of having less keys to try than pure bruteforce to decrypt something. <br /> <br /> Most of the fuzzers are:<br /> <br /> - protocol/file-format dependant<br /> <br /> - data-type dependant<br /> <br /> Why? <br /> <br /> First, because the fuzzer has to connect to the input channel, which is bound to the target.<br /> <br /> Second, because a program only understands structured-enough data. If you connect to a web server in a raw way, it will only respond to listed commands such as GET (or eventually crash). It will take less time to start the string with &quot;GET &quot;, and fuzz the rest, but the drawback is that you'll skip all the tests on the first verb.<br /> <br /> In this regard, Fuzzers try to reduce the number of unuseful tests, i.e. the values we already know that there's little chance they'll work: you reduce impredictibility, in favor of speed.<br /> <br /> == Attack types ==<br /> <br /> A fuzzer would try combinations of attacks on:<br /> <br /> - numbers (signed/unsigned integers/float...)<br /> <br /> - chars (urls, command-line inputs)<br /> <br /> - metadata : user-input text (id3 tag)<br /> <br /> - pure binary sequences<br /> <br /> <br /> A common approach to fuzzing is to define lists of &quot;known-to-be-dangerous values&quot; (''fuzz vectors'') for each type, and to inject them or recombinations.<br /> <br /> - for integers: zero, possibly negative or very big numbers<br /> <br /> - for chars: escaped, interpretable characters / instructions (ex: For SQL Requests, quotes / commands...)<br /> <br /> - for binary: random ones<br /> <br /> Please refer to OWASP's Fuzz Vector's resource[http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors] for real-life fuzzing vectors examples and methodology.<br /> <br /> <br /> Protocols and file formats imply norms, which are sometimes blurry, very complicated or badly implemented : that's why developers sometimes mess up in the implementation process (because of time/cost constraints). That's why it can be interesting to take the opposite approach: take a norm, look at all mandatory features and constraints, and try all of them; forbidden/reserved values, linked parameters, field sizes. That would be ''hand-fuzzing''.<br /> <br /> == Application fuzzing ==<br /> <br /> Whatever the fuzzed system is, the attack vectors are within it's I/O. For a desktop app:<br /> <br /> - the UI (testing all the buttons sequences / text inputs)<br /> <br /> - the command-line options<br /> <br /> - the import/export capabilities (see file format fuzzing below)<br /> <br /> For a web app: urls, forms, user-generated content, RPC requests, ...<br /> <br /> == Protocol fuzzing ==<br /> <br /> A protocol fuzzer sends forged packets to the tested application, or eventually acts as a proxy, modifying requests on the fly and replaying them.<br /> <br /> == File format fuzzing ==<br /> <br /> A file format fuzzer generates multiple malformed samples, and opens them sequentially. When the program crashes, debug information is kept for further investigation.<br /> <br /> One can attack:<br /> <br /> - the parser layer (container layer): file format constraints, structure, conventions, field sizes, flags, ...<br /> <br /> - the codec/application layer: lower-level attacks, aiming at the program's deeper internals<br /> <br /> One example of file format related vulnerabilities: MS04-028[http://www.microsoft.com/technet/security/bulletin/ms04-028.mspx] (KB833987) Microsoft's JPEG GDI+ vulnerability was a zero sized comment field, without content.<br /> <br /> <br /> Surprisingly, file format fuzzers are not that common;<br /> <br /> A generic file format fuzzer : Ilja van Sprundel's mangle.c[http://www.digitaldwarf.be/products/mangle.c]; &quot;it's usage is very simple, it takes a filename and headersize as input. it will then change approximatly between 0 and 10% of the header with random bytes.&quot; (from the author)<br /> <br /> Zzuf can act as a fuzzed file generator, http://sam.zoy.org/zzuf/<br /> <br /> One may use tools like Hachoir[http://hachoir.org/] as a generic parser for file format fuzzers development.<br /> <br /> == Fuzzers advantages ==<br /> <br /> ''The great advantage of fuzz testing is that the test design is extremely simple, and free of preconceptions about system behavior'' (from Wikipedia [http://en.wikipedia.org/wiki/Fuzz_testing]).<br /> <br /> The systematical/random approach allows this method to find bugs that would have often been missed by human eyes. Plus, when the tested system is totally closed (say, a SIP phone), fuzzing is one of the only means of reviewing it's quality.<br /> <br /> == Fuzzers limitations ==<br /> <br /> Fuzzers usually tend to find simple bugs; plus, the more a fuzzer is protocol-aware, the less weird errors it will find. This is why the exhaustive / random approach is still popular among the fuzzing community.<br /> <br /> Another problem is that when you do some black-box-testing, you usually attack a closed system, which increases difficulty to evaluate the dangerosity/impact of the found vulnerability (no debugging possibilities).<br /> <br /> == Why Fuzz? ==<br /> <br /> The purpose of fuzzing relies on the assumption that there are bugs within every program, which are waiting to be discovered. Therefore, a systematical approach should find them sooner or later.<br /> <br /> Fuzzing can add another point of view to classical software testing techniques (hand code review, debugging) because of it's non-human approach. It doesn't replace them, but is a reasonable complement, thanks to the limited work needed to put the procedure in place.<br /> <br /> == Fuzzers from OWASP ==<br /> <br /> Fuzzing with WebScarab [http://www.owasp.org/index.php/Fuzzing_with_WebScarab]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br /> <br /> JBroFuzz [http://www.owasp.org/index.php/JBroFuzz]: a stateless network protocol fuzzer<br /> <br /> WSFuzzer [http://www.owasp.org/index.php/WSFuzzer]: real-world manual SOAP pen testing tool<br /> <br /> == Technical resources on OWASP ==<br /> <br /> Fuzzing vectors [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors]<br /> <br /> == Sources ==<br /> <br /> Wikipedia article [http://en.wikipedia.org/wiki/Fuzz_testing]<br /> <br /> Fuzzing-related papers [http://www.threatmind.net/secwiki/FuzzingPapers]<br /> <br /> == Fuzzing tools ==<br /> <br /> The ultimate fuzzers list @ infosec [http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html]<br /> <br /> Another list @ hacksafe<br /> [http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/]<br /> <br /> The fuzzing mailing list [http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing]<br /> <br /> == Commercial products ==<br /> <br /> Codenomicon's product suite: [http://www.codenomicon.com/products/all.shtml]<br /> <br /> Beyond Security's beSTORM product: [http://www.beyondsecurity.com/bestorm_overview.html]</div>

Fthiery https://wiki.owasp.org/index.php?title=Fuzzing&diff=15733 2007-01-23T09:48:46Z

<p>Fthiery: /* Application fuzzing */</p> <hr /> <div>''Fuzz testing'' or ''Fuzzing'' is a Black Box software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection in an automated fashion.<br /> <br /> == A trivial example: ==<br /> <br /> Lets's consider an integer in a program, which stores the result of a user's choice between 3 questions. When the user picks one, the choice will be 0, 1 or 2. Which makes three practical cases. But what if we transmit 3, or 255 ? We can, because integers are stored a static size variable. If the default switch case hasn't been implemented securely, the program may crash and lead to &quot;classical&quot; security issues: (un)exploitable buffer overflows, DoS, ...<br /> <br /> Fuzzing is the art of automatic bug finding, and it's role is to find software implementation faults, and identify them if possible.<br /> <br /> == History ==<br /> <br /> Fuzz testing was developed at the University of Wisconsin Madison in 1989 by Professor Barton Miller and his students. Their (continued) work can be found at http://www.cs.wisc.edu/~bart/fuzz/ ; it's mainly oriented towards command-line and UI fuzzing.<br /> <br /> == Fuzzer implementations ==<br /> <br /> A fuzzer is a program which injects automatically semi-random data into a program/stack and detect bugs.<br /> The data-generation part is made of generators, and vulnerability identification relies on debugging tools.<br /> <br /> == Comparison with cryptanalysis ==<br /> <br /> The number of possible tryable solutions is ''the explorable solutions space''. The aim of cryptanalysis is to reduce this space, which means finding a way of having less keys to try than pure bruteforce to decrypt something. <br /> <br /> Most of the fuzzers are:<br /> <br /> - protocol/file-format dependant<br /> <br /> - data-type dependant<br /> <br /> Why? <br /> <br /> First, because the fuzzer has to connect to the input channel, which is bound to the target.<br /> <br /> Second, because a program only understands structured-enough data. If you connect to a web server in a raw way, it will only respond to listed commands such as GET (or eventually crash). It will take less time to start the string with &quot;GET &quot;, and fuzz the rest, but the drawback is that you'll skip all the tests on the first verb.<br /> <br /> In this regard, Fuzzers try to reduce the number of unuseful tests, i.e. the values we already know that there's little chance they'll work: you reduce impredictibility, in favor of speed.<br /> <br /> == Attack types ==<br /> <br /> A fuzzer would try combinations of attacks on:<br /> <br /> - numbers (signed/unsigned integers/float...)<br /> <br /> - chars (urls, command-line inputs)<br /> <br /> - metadata : user-input text (id3 tag)<br /> <br /> - pure binary sequences<br /> <br /> <br /> A common approach to fuzzing is to define lists of &quot;known-to-be-dangerous values&quot; (''fuzz vectors'') for each type, and to inject them or recombinations.<br /> <br /> - for integers: zero, possibly negative or very big numbers<br /> <br /> - for chars: escaped, interpretable characters / instructions (ex: For SQL Requests, quotes / commands...)<br /> <br /> - for binary: random ones<br /> <br /> Please refer to OWASP's Fuzz Vector's resource[http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors] for real-life fuzzing vectors examples and methodology.<br /> <br /> <br /> Protocols and file formats imply norms, which are sometimes blurry, very complicated or badly implemented : that's why developers sometimes mess up in the implementation process (because of time/cost constraints). That's why it can be interesting to take the opposite approach: take a norm, look at all mandatory features and constraints, and try all of them; forbidden/reserved values, linked parameters, field sizes. That would be ''hand-fuzzing''.<br /> <br /> == Application fuzzing ==<br /> <br /> Whatever the fuzzed system is, the attack vectors are within it's I/O. For a desktop app:<br /> <br /> - the UI (testing all the buttons sequences / text inputs)<br /> <br /> - the command-line options<br /> <br /> - the import/export capabilities (see file format fuzzing below)<br /> <br /> For a web app: urls, forms, user-generated content, RPC requests, ...<br /> <br /> == Protocol fuzzing ==<br /> <br /> A protocol fuzzer sends forged packets to the tested application, or eventually acts as a proxy, modifying requests on the fly and replaying them.<br /> <br /> == File format fuzzing ==<br /> <br /> A file format fuzzer generates multiple malformed samples, and opens them sequentially. When the program crashes, debug information is kept for further investigation.<br /> <br /> One can attack:<br /> <br /> - the parser layer (container layer): file format constraints, structure, conventions, field sizes, flags, ...<br /> <br /> - the codec/application layer: lower-level attacks, aiming at the program's deeper internals<br /> <br /> One example of file format related vulnerabilities: MS04-028[http://www.microsoft.com/technet/security/bulletin/ms04-028.mspx] (KB833987) Microsoft's JPEG GDI+ vulnerability was a zero sized comment field, without content.<br /> <br /> <br /> Surprisingly, file format fuzzers are not that common;<br /> <br /> A generic file format fuzzer : Ilja van Sprundel's mangle.c[http://www.digitaldwarf.be/products/mangle.c]; &quot;it's usage is very simple, it takes a filename and headersize as input. it will then change approximatly between 0 and 10% of the header with random bytes.&quot; (from the author)<br /> <br /> Zzuf can act as a fuzzed file generator, http://sam.zoy.org/zzuf/<br /> <br /> One may use tools like Hachoir[http://hachoir.org/] as a generic parser for file format fuzzers development.<br /> <br /> == Fuzzers advantages ==<br /> <br /> ''The great advantage of fuzz testing is that the test design is extremely simple, and free of preconceptions about system behavior'' (from Wikipedia [http://en.wikipedia.org/wiki/Fuzz_testing]).<br /> <br /> The systematical/random approach allows this method to find bugs that would have often been missed by human eyes. Plus, when the tested system is totally closed (say, a SIP phone), fuzzing is one of the only means of reviewing it's quality.<br /> <br /> == Fuzzers limitations ==<br /> <br /> Fuzzers usually tend to find simple bugs; plus, the more a fuzzer is protocol-aware, the less weird errors it will find. This is why the exhaustive / random approach is still popular among the fuzzing community.<br /> <br /> Another problem is that when you do some black-box-testing, you usually attack a closed system, which increases difficulty to evaluate the dangerosity/impact of the found vulnerability (no debugging possibilities).<br /> <br /> == Why Fuzz? ==<br /> <br /> The purpose of fuzzing relies on the assumption that there are bugs within every program, which are waiting to be discovered. Therefore, a systematical approach should find them sooner or later.<br /> <br /> Fuzzing can add another point of view to classical software testing techniques (hand code review, debugging) because of it's non-human approach. It doesn't replace them, but is a reasonable complement, thanks to the limited work needed to put the procedure in place.<br /> <br /> == Fuzzers from OWASP ==<br /> <br /> Fuzzing with WebScarab [http://www.owasp.org/index.php/Fuzzing_with_WebScarab]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br /> <br /> JBroFuzz [http://www.owasp.org/index.php/JBroFuzz]: a stateless network protocol fuzzer<br /> <br /> WSFuzzer [http://www.owasp.org/index.php/WSFuzzer]: real-world manual SOAP pen testing tool<br /> <br /> == Technical resources on OWASP ==<br /> <br /> Fuzzing vectors [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors]<br /> <br /> == Sources ==<br /> <br /> Wikipedia article [http://en.wikipedia.org/wiki/Fuzz_testing]<br /> <br /> Fuzzing-related papers [http://www.threatmind.net/secwiki/FuzzingPapers]<br /> <br /> == Fuzzing tools ==<br /> <br /> The ultimate fuzzers list @ infosec [http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html]<br /> <br /> Another list @ hacksafe<br /> [http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/]<br /> <br /> The fuzzing mailing list [http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing]<br /> <br /> == Commercial products ==<br /> <br /> Codenomicon's product suite: [http://www.codenomicon.com/products/all.shtml]<br /> <br /> Beyond Security's beSTORM product: [http://www.beyondsecurity.com/bestorm_overview.html]</div>

Fthiery https://wiki.owasp.org/index.php?title=Fuzzing&diff=15732 2007-01-23T09:46:34Z

<p>Fthiery: /* File format fuzzing */</p> <hr /> <div>''Fuzz testing'' or ''Fuzzing'' is a Black Box software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection in an automated fashion.<br /> <br /> == A trivial example: ==<br /> <br /> Lets's consider an integer in a program, which stores the result of a user's choice between 3 questions. When the user picks one, the choice will be 0, 1 or 2. Which makes three practical cases. But what if we transmit 3, or 255 ? We can, because integers are stored a static size variable. If the default switch case hasn't been implemented securely, the program may crash and lead to &quot;classical&quot; security issues: (un)exploitable buffer overflows, DoS, ...<br /> <br /> Fuzzing is the art of automatic bug finding, and it's role is to find software implementation faults, and identify them if possible.<br /> <br /> == History ==<br /> <br /> Fuzz testing was developed at the University of Wisconsin Madison in 1989 by Professor Barton Miller and his students. Their (continued) work can be found at http://www.cs.wisc.edu/~bart/fuzz/ ; it's mainly oriented towards command-line and UI fuzzing.<br /> <br /> == Fuzzer implementations ==<br /> <br /> A fuzzer is a program which injects automatically semi-random data into a program/stack and detect bugs.<br /> The data-generation part is made of generators, and vulnerability identification relies on debugging tools.<br /> <br /> == Comparison with cryptanalysis ==<br /> <br /> The number of possible tryable solutions is ''the explorable solutions space''. The aim of cryptanalysis is to reduce this space, which means finding a way of having less keys to try than pure bruteforce to decrypt something. <br /> <br /> Most of the fuzzers are:<br /> <br /> - protocol/file-format dependant<br /> <br /> - data-type dependant<br /> <br /> Why? <br /> <br /> First, because the fuzzer has to connect to the input channel, which is bound to the target.<br /> <br /> Second, because a program only understands structured-enough data. If you connect to a web server in a raw way, it will only respond to listed commands such as GET (or eventually crash). It will take less time to start the string with &quot;GET &quot;, and fuzz the rest, but the drawback is that you'll skip all the tests on the first verb.<br /> <br /> In this regard, Fuzzers try to reduce the number of unuseful tests, i.e. the values we already know that there's little chance they'll work: you reduce impredictibility, in favor of speed.<br /> <br /> == Attack types ==<br /> <br /> A fuzzer would try combinations of attacks on:<br /> <br /> - numbers (signed/unsigned integers/float...)<br /> <br /> - chars (urls, command-line inputs)<br /> <br /> - metadata : user-input text (id3 tag)<br /> <br /> - pure binary sequences<br /> <br /> <br /> A common approach to fuzzing is to define lists of &quot;known-to-be-dangerous values&quot; (''fuzz vectors'') for each type, and to inject them or recombinations.<br /> <br /> - for integers: zero, possibly negative or very big numbers<br /> <br /> - for chars: escaped, interpretable characters / instructions (ex: For SQL Requests, quotes / commands...)<br /> <br /> - for binary: random ones<br /> <br /> Please refer to OWASP's Fuzz Vector's resource[http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors] for real-life fuzzing vectors examples and methodology.<br /> <br /> <br /> Protocols and file formats imply norms, which are sometimes blurry, very complicated or badly implemented : that's why developers sometimes mess up in the implementation process (because of time/cost constraints). That's why it can be interesting to take the opposite approach: take a norm, look at all mandatory features and constraints, and try all of them; forbidden/reserved values, linked parameters, field sizes. That would be ''hand-fuzzing''.<br /> <br /> == Application fuzzing ==<br /> <br /> Whatever the fuzzed system is, the attack vectors are within it's I/O. For a desktop app:<br /> <br /> - the UI (testing all the buttons sequences / text inputs)<br /> <br /> - the command-line options<br /> <br /> - the import/export capabilities (see file format fuzzing below)<br /> <br /> For a web app, urls and forms are the inputs, and eventually (especially for user-generated content websites) media files.<br /> <br /> == Protocol fuzzing ==<br /> <br /> A protocol fuzzer sends forged packets to the tested application, or eventually acts as a proxy, modifying requests on the fly and replaying them.<br /> <br /> == File format fuzzing ==<br /> <br /> A file format fuzzer generates multiple malformed samples, and opens them sequentially. When the program crashes, debug information is kept for further investigation.<br /> <br /> One can attack:<br /> <br /> - the parser layer (container layer): file format constraints, structure, conventions, field sizes, flags, ...<br /> <br /> - the codec/application layer: lower-level attacks, aiming at the program's deeper internals<br /> <br /> One example of file format related vulnerabilities: MS04-028[http://www.microsoft.com/technet/security/bulletin/ms04-028.mspx] (KB833987) Microsoft's JPEG GDI+ vulnerability was a zero sized comment field, without content.<br /> <br /> <br /> Surprisingly, file format fuzzers are not that common;<br /> <br /> A generic file format fuzzer : Ilja van Sprundel's mangle.c[http://www.digitaldwarf.be/products/mangle.c]; &quot;it's usage is very simple, it takes a filename and headersize as input. it will then change approximatly between 0 and 10% of the header with random bytes.&quot; (from the author)<br /> <br /> Zzuf can act as a fuzzed file generator, http://sam.zoy.org/zzuf/<br /> <br /> One may use tools like Hachoir[http://hachoir.org/] as a generic parser for file format fuzzers development.<br /> <br /> == Fuzzers advantages ==<br /> <br /> ''The great advantage of fuzz testing is that the test design is extremely simple, and free of preconceptions about system behavior'' (from Wikipedia [http://en.wikipedia.org/wiki/Fuzz_testing]).<br /> <br /> The systematical/random approach allows this method to find bugs that would have often been missed by human eyes. Plus, when the tested system is totally closed (say, a SIP phone), fuzzing is one of the only means of reviewing it's quality.<br /> <br /> == Fuzzers limitations ==<br /> <br /> Fuzzers usually tend to find simple bugs; plus, the more a fuzzer is protocol-aware, the less weird errors it will find. This is why the exhaustive / random approach is still popular among the fuzzing community.<br /> <br /> Another problem is that when you do some black-box-testing, you usually attack a closed system, which increases difficulty to evaluate the dangerosity/impact of the found vulnerability (no debugging possibilities).<br /> <br /> == Why Fuzz? ==<br /> <br /> The purpose of fuzzing relies on the assumption that there are bugs within every program, which are waiting to be discovered. Therefore, a systematical approach should find them sooner or later.<br /> <br /> Fuzzing can add another point of view to classical software testing techniques (hand code review, debugging) because of it's non-human approach. It doesn't replace them, but is a reasonable complement, thanks to the limited work needed to put the procedure in place.<br /> <br /> == Fuzzers from OWASP ==<br /> <br /> Fuzzing with WebScarab [http://www.owasp.org/index.php/Fuzzing_with_WebScarab]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br /> <br /> JBroFuzz [http://www.owasp.org/index.php/JBroFuzz]: a stateless network protocol fuzzer<br /> <br /> WSFuzzer [http://www.owasp.org/index.php/WSFuzzer]: real-world manual SOAP pen testing tool<br /> <br /> == Technical resources on OWASP ==<br /> <br /> Fuzzing vectors [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors]<br /> <br /> == Sources ==<br /> <br /> Wikipedia article [http://en.wikipedia.org/wiki/Fuzz_testing]<br /> <br /> Fuzzing-related papers [http://www.threatmind.net/secwiki/FuzzingPapers]<br /> <br /> == Fuzzing tools ==<br /> <br /> The ultimate fuzzers list @ infosec [http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html]<br /> <br /> Another list @ hacksafe<br /> [http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/]<br /> <br /> The fuzzing mailing list [http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing]<br /> <br /> == Commercial products ==<br /> <br /> Codenomicon's product suite: [http://www.codenomicon.com/products/all.shtml]<br /> <br /> Beyond Security's beSTORM product: [http://www.beyondsecurity.com/bestorm_overview.html]</div>

Fthiery https://wiki.owasp.org/index.php?title=Fuzzing&diff=15731 2007-01-23T09:43:47Z

<p>Fthiery: /* Fuzzers limitations */</p> <hr /> <div>''Fuzz testing'' or ''Fuzzing'' is a Black Box software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection in an automated fashion.<br /> <br /> == A trivial example: ==<br /> <br /> Lets's consider an integer in a program, which stores the result of a user's choice between 3 questions. When the user picks one, the choice will be 0, 1 or 2. Which makes three practical cases. But what if we transmit 3, or 255 ? We can, because integers are stored a static size variable. If the default switch case hasn't been implemented securely, the program may crash and lead to &quot;classical&quot; security issues: (un)exploitable buffer overflows, DoS, ...<br /> <br /> Fuzzing is the art of automatic bug finding, and it's role is to find software implementation faults, and identify them if possible.<br /> <br /> == History ==<br /> <br /> Fuzz testing was developed at the University of Wisconsin Madison in 1989 by Professor Barton Miller and his students. Their (continued) work can be found at http://www.cs.wisc.edu/~bart/fuzz/ ; it's mainly oriented towards command-line and UI fuzzing.<br /> <br /> == Fuzzer implementations ==<br /> <br /> A fuzzer is a program which injects automatically semi-random data into a program/stack and detect bugs.<br /> The data-generation part is made of generators, and vulnerability identification relies on debugging tools.<br /> <br /> == Comparison with cryptanalysis ==<br /> <br /> The number of possible tryable solutions is ''the explorable solutions space''. The aim of cryptanalysis is to reduce this space, which means finding a way of having less keys to try than pure bruteforce to decrypt something. <br /> <br /> Most of the fuzzers are:<br /> <br /> - protocol/file-format dependant<br /> <br /> - data-type dependant<br /> <br /> Why? <br /> <br /> First, because the fuzzer has to connect to the input channel, which is bound to the target.<br /> <br /> Second, because a program only understands structured-enough data. If you connect to a web server in a raw way, it will only respond to listed commands such as GET (or eventually crash). It will take less time to start the string with &quot;GET &quot;, and fuzz the rest, but the drawback is that you'll skip all the tests on the first verb.<br /> <br /> In this regard, Fuzzers try to reduce the number of unuseful tests, i.e. the values we already know that there's little chance they'll work: you reduce impredictibility, in favor of speed.<br /> <br /> == Attack types ==<br /> <br /> A fuzzer would try combinations of attacks on:<br /> <br /> - numbers (signed/unsigned integers/float...)<br /> <br /> - chars (urls, command-line inputs)<br /> <br /> - metadata : user-input text (id3 tag)<br /> <br /> - pure binary sequences<br /> <br /> <br /> A common approach to fuzzing is to define lists of &quot;known-to-be-dangerous values&quot; (''fuzz vectors'') for each type, and to inject them or recombinations.<br /> <br /> - for integers: zero, possibly negative or very big numbers<br /> <br /> - for chars: escaped, interpretable characters / instructions (ex: For SQL Requests, quotes / commands...)<br /> <br /> - for binary: random ones<br /> <br /> Please refer to OWASP's Fuzz Vector's resource[http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors] for real-life fuzzing vectors examples and methodology.<br /> <br /> <br /> Protocols and file formats imply norms, which are sometimes blurry, very complicated or badly implemented : that's why developers sometimes mess up in the implementation process (because of time/cost constraints). That's why it can be interesting to take the opposite approach: take a norm, look at all mandatory features and constraints, and try all of them; forbidden/reserved values, linked parameters, field sizes. That would be ''hand-fuzzing''.<br /> <br /> == Application fuzzing ==<br /> <br /> Whatever the fuzzed system is, the attack vectors are within it's I/O. For a desktop app:<br /> <br /> - the UI (testing all the buttons sequences / text inputs)<br /> <br /> - the command-line options<br /> <br /> - the import/export capabilities (see file format fuzzing below)<br /> <br /> For a web app, urls and forms are the inputs, and eventually (especially for user-generated content websites) media files.<br /> <br /> == Protocol fuzzing ==<br /> <br /> A protocol fuzzer sends forged packets to the tested application, or eventually acts as a proxy, modifying requests on the fly and replaying them.<br /> <br /> == File format fuzzing ==<br /> <br /> A file format fuzzer generates multiple malformed samples, and opens them sequentially. When the program crashes, debug information is kept for further investigation.<br /> <br /> One can attack:<br /> <br /> - the parser layer (container layer): file format constraints, structure, conventions, field sizes, flags, ...<br /> <br /> - the codec/application layer: lower-level attacks, aiming at the program's deeper internals<br /> <br /> Example found vulnerability: Microsoft's JPEG GDI+ vulnerability was a zero sized comment field, without content.<br /> <br /> <br /> Surprisingly, file format fuzzers are not that common;<br /> <br /> A generic file format fuzzer : Ilja van Sprundel's mangle.c[http://www.digitaldwarf.be/products/mangle.c]; &quot;it's usage is very simple, it takes a filename and headersize as input. it will then change approximatly between 0 and 10% of the header with random bytes.&quot; (from the author)<br /> <br /> Zzuf can act as a fuzzed file generator, http://sam.zoy.org/zzuf/<br /> <br /> One may use tools like Hachoir[http://hachoir.org/] as a generic parser for file format fuzzers development.<br /> <br /> == Fuzzers advantages ==<br /> <br /> ''The great advantage of fuzz testing is that the test design is extremely simple, and free of preconceptions about system behavior'' (from Wikipedia [http://en.wikipedia.org/wiki/Fuzz_testing]).<br /> <br /> The systematical/random approach allows this method to find bugs that would have often been missed by human eyes. Plus, when the tested system is totally closed (say, a SIP phone), fuzzing is one of the only means of reviewing it's quality.<br /> <br /> == Fuzzers limitations ==<br /> <br /> Fuzzers usually tend to find simple bugs; plus, the more a fuzzer is protocol-aware, the less weird errors it will find. This is why the exhaustive / random approach is still popular among the fuzzing community.<br /> <br /> Another problem is that when you do some black-box-testing, you usually attack a closed system, which increases difficulty to evaluate the dangerosity/impact of the found vulnerability (no debugging possibilities).<br /> <br /> == Why Fuzz? ==<br /> <br /> The purpose of fuzzing relies on the assumption that there are bugs within every program, which are waiting to be discovered. Therefore, a systematical approach should find them sooner or later.<br /> <br /> Fuzzing can add another point of view to classical software testing techniques (hand code review, debugging) because of it's non-human approach. It doesn't replace them, but is a reasonable complement, thanks to the limited work needed to put the procedure in place.<br /> <br /> == Fuzzers from OWASP ==<br /> <br /> Fuzzing with WebScarab [http://www.owasp.org/index.php/Fuzzing_with_WebScarab]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br /> <br /> JBroFuzz [http://www.owasp.org/index.php/JBroFuzz]: a stateless network protocol fuzzer<br /> <br /> WSFuzzer [http://www.owasp.org/index.php/WSFuzzer]: real-world manual SOAP pen testing tool<br /> <br /> == Technical resources on OWASP ==<br /> <br /> Fuzzing vectors [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors]<br /> <br /> == Sources ==<br /> <br /> Wikipedia article [http://en.wikipedia.org/wiki/Fuzz_testing]<br /> <br /> Fuzzing-related papers [http://www.threatmind.net/secwiki/FuzzingPapers]<br /> <br /> == Fuzzing tools ==<br /> <br /> The ultimate fuzzers list @ infosec [http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html]<br /> <br /> Another list @ hacksafe<br /> [http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/]<br /> <br /> The fuzzing mailing list [http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing]<br /> <br /> == Commercial products ==<br /> <br /> Codenomicon's product suite: [http://www.codenomicon.com/products/all.shtml]<br /> <br /> Beyond Security's beSTORM product: [http://www.beyondsecurity.com/bestorm_overview.html]</div>

Fthiery https://wiki.owasp.org/index.php?title=Fuzzing&diff=15730 2007-01-23T09:38:43Z

<p>Fthiery: /* File format fuzzing */</p> <hr /> <div>''Fuzz testing'' or ''Fuzzing'' is a Black Box software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection in an automated fashion.<br /> <br /> == A trivial example: ==<br /> <br /> Lets's consider an integer in a program, which stores the result of a user's choice between 3 questions. When the user picks one, the choice will be 0, 1 or 2. Which makes three practical cases. But what if we transmit 3, or 255 ? We can, because integers are stored a static size variable. If the default switch case hasn't been implemented securely, the program may crash and lead to &quot;classical&quot; security issues: (un)exploitable buffer overflows, DoS, ...<br /> <br /> Fuzzing is the art of automatic bug finding, and it's role is to find software implementation faults, and identify them if possible.<br /> <br /> == History ==<br /> <br /> Fuzz testing was developed at the University of Wisconsin Madison in 1989 by Professor Barton Miller and his students. Their (continued) work can be found at http://www.cs.wisc.edu/~bart/fuzz/ ; it's mainly oriented towards command-line and UI fuzzing.<br /> <br /> == Fuzzer implementations ==<br /> <br /> A fuzzer is a program which injects automatically semi-random data into a program/stack and detect bugs.<br /> The data-generation part is made of generators, and vulnerability identification relies on debugging tools.<br /> <br /> == Comparison with cryptanalysis ==<br /> <br /> The number of possible tryable solutions is ''the explorable solutions space''. The aim of cryptanalysis is to reduce this space, which means finding a way of having less keys to try than pure bruteforce to decrypt something. <br /> <br /> Most of the fuzzers are:<br /> <br /> - protocol/file-format dependant<br /> <br /> - data-type dependant<br /> <br /> Why? <br /> <br /> First, because the fuzzer has to connect to the input channel, which is bound to the target.<br /> <br /> Second, because a program only understands structured-enough data. If you connect to a web server in a raw way, it will only respond to listed commands such as GET (or eventually crash). It will take less time to start the string with &quot;GET &quot;, and fuzz the rest, but the drawback is that you'll skip all the tests on the first verb.<br /> <br /> In this regard, Fuzzers try to reduce the number of unuseful tests, i.e. the values we already know that there's little chance they'll work: you reduce impredictibility, in favor of speed.<br /> <br /> == Attack types ==<br /> <br /> A fuzzer would try combinations of attacks on:<br /> <br /> - numbers (signed/unsigned integers/float...)<br /> <br /> - chars (urls, command-line inputs)<br /> <br /> - metadata : user-input text (id3 tag)<br /> <br /> - pure binary sequences<br /> <br /> <br /> A common approach to fuzzing is to define lists of &quot;known-to-be-dangerous values&quot; (''fuzz vectors'') for each type, and to inject them or recombinations.<br /> <br /> - for integers: zero, possibly negative or very big numbers<br /> <br /> - for chars: escaped, interpretable characters / instructions (ex: For SQL Requests, quotes / commands...)<br /> <br /> - for binary: random ones<br /> <br /> Please refer to OWASP's Fuzz Vector's resource[http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors] for real-life fuzzing vectors examples and methodology.<br /> <br /> <br /> Protocols and file formats imply norms, which are sometimes blurry, very complicated or badly implemented : that's why developers sometimes mess up in the implementation process (because of time/cost constraints). That's why it can be interesting to take the opposite approach: take a norm, look at all mandatory features and constraints, and try all of them; forbidden/reserved values, linked parameters, field sizes. That would be ''hand-fuzzing''.<br /> <br /> == Application fuzzing ==<br /> <br /> Whatever the fuzzed system is, the attack vectors are within it's I/O. For a desktop app:<br /> <br /> - the UI (testing all the buttons sequences / text inputs)<br /> <br /> - the command-line options<br /> <br /> - the import/export capabilities (see file format fuzzing below)<br /> <br /> For a web app, urls and forms are the inputs, and eventually (especially for user-generated content websites) media files.<br /> <br /> == Protocol fuzzing ==<br /> <br /> A protocol fuzzer sends forged packets to the tested application, or eventually acts as a proxy, modifying requests on the fly and replaying them.<br /> <br /> == File format fuzzing ==<br /> <br /> A file format fuzzer generates multiple malformed samples, and opens them sequentially. When the program crashes, debug information is kept for further investigation.<br /> <br /> One can attack:<br /> <br /> - the parser layer (container layer): file format constraints, structure, conventions, field sizes, flags, ...<br /> <br /> - the codec/application layer: lower-level attacks, aiming at the program's deeper internals<br /> <br /> Example found vulnerability: Microsoft's JPEG GDI+ vulnerability was a zero sized comment field, without content.<br /> <br /> <br /> Surprisingly, file format fuzzers are not that common;<br /> <br /> A generic file format fuzzer : Ilja van Sprundel's mangle.c[http://www.digitaldwarf.be/products/mangle.c]; &quot;it's usage is very simple, it takes a filename and headersize as input. it will then change approximatly between 0 and 10% of the header with random bytes.&quot; (from the author)<br /> <br /> Zzuf can act as a fuzzed file generator, http://sam.zoy.org/zzuf/<br /> <br /> One may use tools like Hachoir[http://hachoir.org/] as a generic parser for file format fuzzers development.<br /> <br /> == Fuzzers advantages ==<br /> <br /> ''The great advantage of fuzz testing is that the test design is extremely simple, and free of preconceptions about system behavior'' (from Wikipedia [http://en.wikipedia.org/wiki/Fuzz_testing]).<br /> <br /> The systematical/random approach allows this method to find bugs that would have often been missed by human eyes. Plus, when the tested system is totally closed (say, a SIP phone), fuzzing is one of the only means of reviewing it's quality.<br /> <br /> == Fuzzers limitations ==<br /> <br /> Fuzzers usually tend to try one-level-imbrication-level attacks, which means changing only one parameter at a time. Therefore, fuzzing tools can detect trivial errors, but are less gifted with deep ones.<br /> <br /> Another problem is that when you do some black-box-testing, you usually attack a closed system, which increases difficulty to evaluate the dangerosity/impact of the found vulnerability.<br /> <br /> == Why Fuzz? ==<br /> <br /> The purpose of fuzzing relies on the assumption that there are bugs within every program, which are waiting to be discovered. Therefore, a systematical approach should find them sooner or later.<br /> <br /> Fuzzing can add another point of view to classical software testing techniques (hand code review, debugging) because of it's non-human approach. It doesn't replace them, but is a reasonable complement, thanks to the limited work needed to put the procedure in place.<br /> <br /> == Fuzzers from OWASP ==<br /> <br /> Fuzzing with WebScarab [http://www.owasp.org/index.php/Fuzzing_with_WebScarab]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br /> <br /> JBroFuzz [http://www.owasp.org/index.php/JBroFuzz]: a stateless network protocol fuzzer<br /> <br /> WSFuzzer [http://www.owasp.org/index.php/WSFuzzer]: real-world manual SOAP pen testing tool<br /> <br /> == Technical resources on OWASP ==<br /> <br /> Fuzzing vectors [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors]<br /> <br /> == Sources ==<br /> <br /> Wikipedia article [http://en.wikipedia.org/wiki/Fuzz_testing]<br /> <br /> Fuzzing-related papers [http://www.threatmind.net/secwiki/FuzzingPapers]<br /> <br /> == Fuzzing tools ==<br /> <br /> The ultimate fuzzers list @ infosec [http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html]<br /> <br /> Another list @ hacksafe<br /> [http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/]<br /> <br /> The fuzzing mailing list [http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing]<br /> <br /> == Commercial products ==<br /> <br /> Codenomicon's product suite: [http://www.codenomicon.com/products/all.shtml]<br /> <br /> Beyond Security's beSTORM product: [http://www.beyondsecurity.com/bestorm_overview.html]</div>

Fthiery https://wiki.owasp.org/index.php?title=Fuzzing&diff=15729 2007-01-23T09:36:20Z

<p>Fthiery: /* File format fuzzing */</p> <hr /> <div>''Fuzz testing'' or ''Fuzzing'' is a Black Box software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection in an automated fashion.<br /> <br /> == A trivial example: ==<br /> <br /> Lets's consider an integer in a program, which stores the result of a user's choice between 3 questions. When the user picks one, the choice will be 0, 1 or 2. Which makes three practical cases. But what if we transmit 3, or 255 ? We can, because integers are stored a static size variable. If the default switch case hasn't been implemented securely, the program may crash and lead to &quot;classical&quot; security issues: (un)exploitable buffer overflows, DoS, ...<br /> <br /> Fuzzing is the art of automatic bug finding, and it's role is to find software implementation faults, and identify them if possible.<br /> <br /> == History ==<br /> <br /> Fuzz testing was developed at the University of Wisconsin Madison in 1989 by Professor Barton Miller and his students. Their (continued) work can be found at http://www.cs.wisc.edu/~bart/fuzz/ ; it's mainly oriented towards command-line and UI fuzzing.<br /> <br /> == Fuzzer implementations ==<br /> <br /> A fuzzer is a program which injects automatically semi-random data into a program/stack and detect bugs.<br /> The data-generation part is made of generators, and vulnerability identification relies on debugging tools.<br /> <br /> == Comparison with cryptanalysis ==<br /> <br /> The number of possible tryable solutions is ''the explorable solutions space''. The aim of cryptanalysis is to reduce this space, which means finding a way of having less keys to try than pure bruteforce to decrypt something. <br /> <br /> Most of the fuzzers are:<br /> <br /> - protocol/file-format dependant<br /> <br /> - data-type dependant<br /> <br /> Why? <br /> <br /> First, because the fuzzer has to connect to the input channel, which is bound to the target.<br /> <br /> Second, because a program only understands structured-enough data. If you connect to a web server in a raw way, it will only respond to listed commands such as GET (or eventually crash). It will take less time to start the string with &quot;GET &quot;, and fuzz the rest, but the drawback is that you'll skip all the tests on the first verb.<br /> <br /> In this regard, Fuzzers try to reduce the number of unuseful tests, i.e. the values we already know that there's little chance they'll work: you reduce impredictibility, in favor of speed.<br /> <br /> == Attack types ==<br /> <br /> A fuzzer would try combinations of attacks on:<br /> <br /> - numbers (signed/unsigned integers/float...)<br /> <br /> - chars (urls, command-line inputs)<br /> <br /> - metadata : user-input text (id3 tag)<br /> <br /> - pure binary sequences<br /> <br /> <br /> A common approach to fuzzing is to define lists of &quot;known-to-be-dangerous values&quot; (''fuzz vectors'') for each type, and to inject them or recombinations.<br /> <br /> - for integers: zero, possibly negative or very big numbers<br /> <br /> - for chars: escaped, interpretable characters / instructions (ex: For SQL Requests, quotes / commands...)<br /> <br /> - for binary: random ones<br /> <br /> Please refer to OWASP's Fuzz Vector's resource[http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors] for real-life fuzzing vectors examples and methodology.<br /> <br /> <br /> Protocols and file formats imply norms, which are sometimes blurry, very complicated or badly implemented : that's why developers sometimes mess up in the implementation process (because of time/cost constraints). That's why it can be interesting to take the opposite approach: take a norm, look at all mandatory features and constraints, and try all of them; forbidden/reserved values, linked parameters, field sizes. That would be ''hand-fuzzing''.<br /> <br /> == Application fuzzing ==<br /> <br /> Whatever the fuzzed system is, the attack vectors are within it's I/O. For a desktop app:<br /> <br /> - the UI (testing all the buttons sequences / text inputs)<br /> <br /> - the command-line options<br /> <br /> - the import/export capabilities (see file format fuzzing below)<br /> <br /> For a web app, urls and forms are the inputs, and eventually (especially for user-generated content websites) media files.<br /> <br /> == Protocol fuzzing ==<br /> <br /> A protocol fuzzer sends forged packets to the tested application, or eventually acts as a proxy, modifying requests on the fly and replaying them.<br /> <br /> == File format fuzzing ==<br /> <br /> A file format fuzzer generates multiple malformed samples, and opens them sequentially. When the program crashes, debug information is kept for further investigation.<br /> <br /> One can attack:<br /> <br /> - the parser layer (container layer): file format constraints, structure, conventions, field sizes, flags, ...<br /> <br /> - the codec/application layer: lower-level attacks, aiming at the program's deeper internals<br /> <br /> Example found vulnerability: Microsoft's JPEG GDI+ vulnerability was a zero sized comment field, without content.<br /> <br /> <br /> Surprisingly, file format fuzzers are not that common.<br /> <br /> A generic file format fuzzer : Ilja van Sprundel's mangle.c[http://www.digitaldwarf.be/products/mangle.c]; &quot;it's usage is very simple, it takes a filename and headersize as input. it will then change approximatly between 0 and 10% of the header with random bytes.&quot; (from the author)<br /> <br /> Zzuf can act as a fuzzed file generator, http://sam.zoy.org/zzuf/<br /> <br /> One may use tools like Hachoir[http://hachoir.org/] as a generic parser for file format fuzzers development.<br /> <br /> == Fuzzers advantages ==<br /> <br /> ''The great advantage of fuzz testing is that the test design is extremely simple, and free of preconceptions about system behavior'' (from Wikipedia [http://en.wikipedia.org/wiki/Fuzz_testing]).<br /> <br /> The systematical/random approach allows this method to find bugs that would have often been missed by human eyes. Plus, when the tested system is totally closed (say, a SIP phone), fuzzing is one of the only means of reviewing it's quality.<br /> <br /> == Fuzzers limitations ==<br /> <br /> Fuzzers usually tend to try one-level-imbrication-level attacks, which means changing only one parameter at a time. Therefore, fuzzing tools can detect trivial errors, but are less gifted with deep ones.<br /> <br /> Another problem is that when you do some black-box-testing, you usually attack a closed system, which increases difficulty to evaluate the dangerosity/impact of the found vulnerability.<br /> <br /> == Why Fuzz? ==<br /> <br /> The purpose of fuzzing relies on the assumption that there are bugs within every program, which are waiting to be discovered. Therefore, a systematical approach should find them sooner or later.<br /> <br /> Fuzzing can add another point of view to classical software testing techniques (hand code review, debugging) because of it's non-human approach. It doesn't replace them, but is a reasonable complement, thanks to the limited work needed to put the procedure in place.<br /> <br /> == Fuzzers from OWASP ==<br /> <br /> Fuzzing with WebScarab [http://www.owasp.org/index.php/Fuzzing_with_WebScarab]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br /> <br /> JBroFuzz [http://www.owasp.org/index.php/JBroFuzz]: a stateless network protocol fuzzer<br /> <br /> WSFuzzer [http://www.owasp.org/index.php/WSFuzzer]: real-world manual SOAP pen testing tool<br /> <br /> == Technical resources on OWASP ==<br /> <br /> Fuzzing vectors [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors]<br /> <br /> == Sources ==<br /> <br /> Wikipedia article [http://en.wikipedia.org/wiki/Fuzz_testing]<br /> <br /> Fuzzing-related papers [http://www.threatmind.net/secwiki/FuzzingPapers]<br /> <br /> == Fuzzing tools ==<br /> <br /> The ultimate fuzzers list @ infosec [http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html]<br /> <br /> Another list @ hacksafe<br /> [http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/]<br /> <br /> The fuzzing mailing list [http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing]<br /> <br /> == Commercial products ==<br /> <br /> Codenomicon's product suite: [http://www.codenomicon.com/products/all.shtml]<br /> <br /> Beyond Security's beSTORM product: [http://www.beyondsecurity.com/bestorm_overview.html]</div>

Fthiery https://wiki.owasp.org/index.php?title=Fuzzing&diff=15728 2007-01-23T09:33:40Z

<p>Fthiery: </p> <hr /> <div>''Fuzz testing'' or ''Fuzzing'' is a Black Box software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection in an automated fashion.<br /> <br /> == A trivial example: ==<br /> <br /> Lets's consider an integer in a program, which stores the result of a user's choice between 3 questions. When the user picks one, the choice will be 0, 1 or 2. Which makes three practical cases. But what if we transmit 3, or 255 ? We can, because integers are stored a static size variable. If the default switch case hasn't been implemented securely, the program may crash and lead to &quot;classical&quot; security issues: (un)exploitable buffer overflows, DoS, ...<br /> <br /> Fuzzing is the art of automatic bug finding, and it's role is to find software implementation faults, and identify them if possible.<br /> <br /> == History ==<br /> <br /> Fuzz testing was developed at the University of Wisconsin Madison in 1989 by Professor Barton Miller and his students. Their (continued) work can be found at http://www.cs.wisc.edu/~bart/fuzz/ ; it's mainly oriented towards command-line and UI fuzzing.<br /> <br /> == Fuzzer implementations ==<br /> <br /> A fuzzer is a program which injects automatically semi-random data into a program/stack and detect bugs.<br /> The data-generation part is made of generators, and vulnerability identification relies on debugging tools.<br /> <br /> == Comparison with cryptanalysis ==<br /> <br /> The number of possible tryable solutions is ''the explorable solutions space''. The aim of cryptanalysis is to reduce this space, which means finding a way of having less keys to try than pure bruteforce to decrypt something. <br /> <br /> Most of the fuzzers are:<br /> <br /> - protocol/file-format dependant<br /> <br /> - data-type dependant<br /> <br /> Why? <br /> <br /> First, because the fuzzer has to connect to the input channel, which is bound to the target.<br /> <br /> Second, because a program only understands structured-enough data. If you connect to a web server in a raw way, it will only respond to listed commands such as GET (or eventually crash). It will take less time to start the string with &quot;GET &quot;, and fuzz the rest, but the drawback is that you'll skip all the tests on the first verb.<br /> <br /> In this regard, Fuzzers try to reduce the number of unuseful tests, i.e. the values we already know that there's little chance they'll work: you reduce impredictibility, in favor of speed.<br /> <br /> == Attack types ==<br /> <br /> A fuzzer would try combinations of attacks on:<br /> <br /> - numbers (signed/unsigned integers/float...)<br /> <br /> - chars (urls, command-line inputs)<br /> <br /> - metadata : user-input text (id3 tag)<br /> <br /> - pure binary sequences<br /> <br /> <br /> A common approach to fuzzing is to define lists of &quot;known-to-be-dangerous values&quot; (''fuzz vectors'') for each type, and to inject them or recombinations.<br /> <br /> - for integers: zero, possibly negative or very big numbers<br /> <br /> - for chars: escaped, interpretable characters / instructions (ex: For SQL Requests, quotes / commands...)<br /> <br /> - for binary: random ones<br /> <br /> Please refer to OWASP's Fuzz Vector's resource[http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors] for real-life fuzzing vectors examples and methodology.<br /> <br /> <br /> Protocols and file formats imply norms, which are sometimes blurry, very complicated or badly implemented : that's why developers sometimes mess up in the implementation process (because of time/cost constraints). That's why it can be interesting to take the opposite approach: take a norm, look at all mandatory features and constraints, and try all of them; forbidden/reserved values, linked parameters, field sizes. That would be ''hand-fuzzing''.<br /> <br /> == Application fuzzing ==<br /> <br /> Whatever the fuzzed system is, the attack vectors are within it's I/O. For a desktop app:<br /> <br /> - the UI (testing all the buttons sequences / text inputs)<br /> <br /> - the command-line options<br /> <br /> - the import/export capabilities (see file format fuzzing below)<br /> <br /> For a web app, urls and forms are the inputs, and eventually (especially for user-generated content websites) media files.<br /> <br /> == Protocol fuzzing ==<br /> <br /> A protocol fuzzer sends forged packets to the tested application, or eventually acts as a proxy, modifying requests on the fly and replaying them.<br /> <br /> == File format fuzzing ==<br /> <br /> A file format fuzzer generates multiple malformed samples, and opens them sequentially. When the program crashes, debug information is kept for further investigation.<br /> <br /> One can attack:<br /> <br /> - the parser layer (container layer): file format constraints, structure, conventions, field sizes, flags, ...<br /> <br /> - the codec/application layer: lower-level attacks, aiming at the program's deeper internals<br /> <br /> Example found vulnerability: Microsoft's JPEG GDI+ vulnerability was a zero sized comment field, without content.<br /> <br /> <br /> Surprisingly, file format fuzzers are not common.<br /> <br /> A generic file format fuzzer is Ilja van Sprundel's mangle.c[http://www.digitaldwarf.be/products/mangle.c]; &quot;it's usage is very simple, it takes a filename and headersize as input. it will then change approximatly between 0 and 10% of the header with random bytes.&quot; (from the author)<br /> <br /> One may use tools like Hachoir[http://hachoir.org/] as a generic parser for file format fuzzers development.<br /> <br /> == Fuzzers advantages ==<br /> <br /> ''The great advantage of fuzz testing is that the test design is extremely simple, and free of preconceptions about system behavior'' (from Wikipedia [http://en.wikipedia.org/wiki/Fuzz_testing]).<br /> <br /> The systematical/random approach allows this method to find bugs that would have often been missed by human eyes. Plus, when the tested system is totally closed (say, a SIP phone), fuzzing is one of the only means of reviewing it's quality.<br /> <br /> == Fuzzers limitations ==<br /> <br /> Fuzzers usually tend to try one-level-imbrication-level attacks, which means changing only one parameter at a time. Therefore, fuzzing tools can detect trivial errors, but are less gifted with deep ones.<br /> <br /> Another problem is that when you do some black-box-testing, you usually attack a closed system, which increases difficulty to evaluate the dangerosity/impact of the found vulnerability.<br /> <br /> == Why Fuzz? ==<br /> <br /> The purpose of fuzzing relies on the assumption that there are bugs within every program, which are waiting to be discovered. Therefore, a systematical approach should find them sooner or later.<br /> <br /> Fuzzing can add another point of view to classical software testing techniques (hand code review, debugging) because of it's non-human approach. It doesn't replace them, but is a reasonable complement, thanks to the limited work needed to put the procedure in place.<br /> <br /> == Fuzzers from OWASP ==<br /> <br /> Fuzzing with WebScarab [http://www.owasp.org/index.php/Fuzzing_with_WebScarab]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br /> <br /> JBroFuzz [http://www.owasp.org/index.php/JBroFuzz]: a stateless network protocol fuzzer<br /> <br /> WSFuzzer [http://www.owasp.org/index.php/WSFuzzer]: real-world manual SOAP pen testing tool<br /> <br /> == Technical resources on OWASP ==<br /> <br /> Fuzzing vectors [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors]<br /> <br /> == Sources ==<br /> <br /> Wikipedia article [http://en.wikipedia.org/wiki/Fuzz_testing]<br /> <br /> Fuzzing-related papers [http://www.threatmind.net/secwiki/FuzzingPapers]<br /> <br /> == Fuzzing tools ==<br /> <br /> The ultimate fuzzers list @ infosec [http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html]<br /> <br /> Another list @ hacksafe<br /> [http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/]<br /> <br /> The fuzzing mailing list [http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing]<br /> <br /> == Commercial products ==<br /> <br /> Codenomicon's product suite: [http://www.codenomicon.com/products/all.shtml]<br /> <br /> Beyond Security's beSTORM product: [http://www.beyondsecurity.com/bestorm_overview.html]</div>

Fthiery https://wiki.owasp.org/index.php?title=Fuzzing&diff=14357 2006-12-14T14:25:58Z

<p>Fthiery: /* Attack types */</p> <hr /> <div>''Fuzz testing'' or ''Fuzzing'' is a Black Box software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection in an automated fashion.<br /> <br /> == A trivial example: ==<br /> <br /> Lets's consider an integer in a program, which stores the result of a user's choice between 3 questions. When the user picks one, the choice will be 0, 1 or 2. Which makes three practical cases. But what if we transmit 3, or 255 ? We can, because integers are stored a static size variable. If the default switch case hasn't been implemented securely, the program may crash and lead to &quot;classical&quot; security issues: (un)exploitable buffer overflows, DoS, ...<br /> <br /> Fuzzing is the art of automatic bug finding, and it's role is to find software implementation faults, and identify them if possible.<br /> <br /> == History ==<br /> <br /> Fuzz testing was developed at the University of Wisconsin Madison in 1989 by Professor Barton Miller and his students. Their (continued) work can be found at http://www.cs.wisc.edu/~bart/fuzz/ ; it's mainly oriented towards command-line and UI fuzzing.<br /> <br /> == Fuzzer implementations ==<br /> <br /> A fuzzer is a program which injects automatically semi-random data into a program/stack and detect bugs.<br /> The data-generation part is made of generators, and vulnerability identification relies on debugging tools.<br /> <br /> == Comparison with cryptanalysis ==<br /> <br /> The number of possible tryable solutions is ''the explorable solutions space''. The aim of cryptanalysis is to reduce this space, which means finding a way of having less keys to try than pure bruteforce to decrypt something. <br /> <br /> Most of the fuzzers are:<br /> <br /> - protocol/file-format dependant<br /> <br /> - data-type dependant<br /> <br /> Why? <br /> <br /> First, because the fuzzer has to connect to the input channel, which is bound to the target.<br /> <br /> Second, because a program only understands structured-enough data. If you connect to a web server in a raw way, it will only respond to listed commands such as GET (or eventually crash). It will take less time to start the string with &quot;GET &quot;, and fuzz the rest, but the drawback is that you'll skip all the tests on the first verb.<br /> <br /> In this regard, Fuzzers try to reduce the number of unuseful tests, i.e. the values we already know that there's little chance they'll work: you reduce impredictibility, in favor of speed.<br /> <br /> == Attack types ==<br /> <br /> A fuzzer would try combinations of attacks on:<br /> <br /> - numbers (signed/unsigned integers/float...)<br /> <br /> - chars (urls, command-line inputs)<br /> <br /> - metadata : user-input text (id3 tag)<br /> <br /> - pure binary sequences<br /> <br /> <br /> A common approach to fuzzing is to define lists of &quot;known-to-be-dangerous values&quot; (''fuzz vectors'') for each type, and to inject them or recombinations.<br /> <br /> - for integers: zero, possibly negative or very big numbers<br /> <br /> - for chars: escaped, interpretable characters / instructions (ex: For SQL Requests, quotes / commands...)<br /> <br /> - for binary: random ones<br /> <br /> Please refer to OWASP's Fuzz Vector's resource[http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors] for real-life fuzzing vectors examples and methodology.<br /> <br /> <br /> Protocols and file formats imply norms, which are sometimes blurry, very complicated or badly implemented : that's why developers sometimes mess up in the implementation process (because of time/cost constraints). That's why it can be interesting to take the opposite approach: take a norm, look at all mandatory features and constraints, and try all of them; forbidden/reserved values, linked parameters, field sizes. That would be ''hand-fuzzing''.<br /> <br /> == Application fuzzing ==<br /> <br /> Whatever the fuzzed system is, the attack vectors are within it's I/O. For a desktop app:<br /> - the UI (testing all the buttons sequences / text inputs)<br /> - the command-line options<br /> - the import/export capabilities (see file format fuzzing below)<br /> <br /> For a web app, urls and forms are the inputs, and eventually (especially for user-generated content websites) media files.<br /> <br /> == Protocol fuzzing ==<br /> <br /> A protocol fuzzer sends forged packets to the tested application, or eventually acts as a proxy, modifying requests on the fly and replaying them.<br /> <br /> == File format fuzzing ==<br /> <br /> A file format fuzzer generates multiple malformed samples, and opens them sequentially. When the program crashes, debug information is kept for further investigation.<br /> <br /> One can attack:<br /> <br /> - the parser layer (container layer): file format constraints, structure, conventions, field sizes, flags, ...<br /> <br /> - the codec/application layer: lower-level attacks, aiming at the program's deeper internals<br /> <br /> Example found vulnerability: Microsoft's JPEG GDI+ vulnerability was a zero sized comment field, without content.<br /> <br /> <br /> Surprisingly, file format fuzzers are not common.<br /> <br /> A generic file format fuzzer is Ilja van Sprundel's mangle.c[http://www.digitaldwarf.be/products/mangle.c]; &quot;it's usage is very simple, it takes a filename and headersize as input. it will then change approximatly between 0 and 10% of the header with random bytes.&quot; (from the author)<br /> <br /> One may use tools like Hachoir[http://hachoir.org/] as a generic parser for file format fuzzers development.<br /> <br /> == Fuzzers advantages ==<br /> <br /> ''The great advantage of fuzz testing is that the test design is extremely simple, and free of preconceptions about system behavior'' (from Wikipedia [http://en.wikipedia.org/wiki/Fuzz_testing]).<br /> <br /> The systematical/random approach allows this method to find bugs that would have often been missed by human eyes. Plus, when the tested system is totally closed (say, a SIP phone), fuzzing is one of the only means of reviewing it's quality.<br /> <br /> == Fuzzers limitations ==<br /> <br /> Fuzzers usually tend to try one-level-imbrication-level attacks, which means changing only one parameter at a time. Therefore, fuzzing tools can detect trivial errors, but are less gifted with deep ones.<br /> <br /> Another problem is that when you do some black-box-testing, you usually attack a closed system, which increases difficulty to evaluate the dangerosity/impact of the found vulnerability.<br /> <br /> == Why Fuzz? ==<br /> <br /> The purpose of fuzzing relies on the assumption that there are bugs within every program, which are waiting to be discovered. Therefore, a systematical approach should find them sooner or later.<br /> <br /> Fuzzing can add another point of view to classical software testing techniques (hand code review, debugging) because of it's non-human approach. It doesn't replace them, but is a reasonable complement, thanks to the limited work needed to put the procedure in place.<br /> <br /> == Fuzzers from OWASP ==<br /> <br /> Fuzzing with WebScarab [http://www.owasp.org/index.php/Fuzzing_with_WebScarab]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br /> <br /> JBroFuzz [http://www.owasp.org/index.php/JBroFuzz]: a stateless network protocol fuzzer<br /> <br /> WSFuzzer [http://www.owasp.org/index.php/WSFuzzer]: real-world manual SOAP pen testing tool<br /> <br /> == Technical resources on OWASP ==<br /> <br /> Fuzzing vectors [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors]<br /> <br /> == Sources ==<br /> <br /> Wikipedia article [http://en.wikipedia.org/wiki/Fuzz_testing]<br /> <br /> Fuzzing-related papers [http://www.threatmind.net/secwiki/FuzzingPapers]<br /> <br /> == Fuzzing tools ==<br /> <br /> The ultimate fuzzers list @ infosec [http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html]<br /> <br /> Another list @ hacksafe<br /> [http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/]<br /> <br /> The fuzzing mailing list [http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing]<br /> <br /> == Commercial products ==<br /> <br /> Codenomicon's product suite: [http://www.codenomicon.com/products/all.shtml]<br /> <br /> Beyond Security's beSTORM product: [http://www.beyondsecurity.com/bestorm_overview.html]</div>

Fthiery https://wiki.owasp.org/index.php?title=Fuzzing&diff=14250 2006-12-12T15:49:54Z

<p>Fthiery: /* Comparison with cryptanalysis */</p> <hr /> <div>''Fuzz testing'' or ''Fuzzing'' is a Black Box software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection in an automated fashion.<br /> <br /> == A trivial example: ==<br /> <br /> Lets's consider an integer in a program, which stores the result of a user's choice between 3 questions. When the user picks one, the choice will be 0, 1 or 2. Which makes three practical cases. But what if we transmit 3, or 255 ? We can, because integers are stored a static size variable. If the default switch case hasn't been implemented securely, the program may crash and lead to &quot;classical&quot; security issues: (un)exploitable buffer overflows, DoS, ...<br /> <br /> Fuzzing is the art of automatic bug finding, and it's role is to find software implementation faults, and identify them if possible.<br /> <br /> == History ==<br /> <br /> Fuzz testing was developed at the University of Wisconsin Madison in 1989 by Professor Barton Miller and his students. Their (continued) work can be found at http://www.cs.wisc.edu/~bart/fuzz/ ; it's mainly oriented towards command-line and UI fuzzing.<br /> <br /> == Fuzzer implementations ==<br /> <br /> A fuzzer is a program which injects automatically semi-random data into a program/stack and detect bugs.<br /> The data-generation part is made of generators, and vulnerability identification relies on debugging tools.<br /> <br /> == Comparison with cryptanalysis ==<br /> <br /> The number of possible tryable solutions is ''the explorable solutions space''. The aim of cryptanalysis is to reduce this space, which means finding a way of having less keys to try than pure bruteforce to decrypt something. <br /> <br /> Most of the fuzzers are:<br /> <br /> - protocol/file-format dependant<br /> <br /> - data-type dependant<br /> <br /> Why? <br /> <br /> First, because the fuzzer has to connect to the input channel, which is bound to the target.<br /> <br /> Second, because a program only understands structured-enough data. If you connect to a web server in a raw way, it will only respond to listed commands such as GET (or eventually crash). It will take less time to start the string with &quot;GET &quot;, and fuzz the rest, but the drawback is that you'll skip all the tests on the first verb.<br /> <br /> In this regard, Fuzzers try to reduce the number of unuseful tests, i.e. the values we already know that there's little chance they'll work: you reduce impredictibility, in favor of speed.<br /> <br /> == Attack types ==<br /> <br /> A fuzzer would try combinations of attacks on:<br /> <br /> - numbers (signed/unsigned integers/float...)<br /> <br /> - chars (urls, command-line inputs)<br /> <br /> - metadata : user-input text (id3 tag)<br /> <br /> - pure binary sequences<br /> <br /> <br /> A common approach to fuzzing is to define lists of &quot;known-to-be-dangerous values&quot; (''fuzz vectors'') for each type, and to inject them or recombinations.<br /> <br /> - for integers: zero, possibly negative or very big numbers<br /> <br /> - for chars: escaped, interpretable characters / instructions (ex: For SQL Requests, quotes / commands...)<br /> <br /> - for binary: random ones<br /> <br /> Please refer to OWASP's Fuzz Vector's resource[http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors] for real-life examples.<br /> <br /> <br /> Protocols and file formats imply norms, which are sometimes blurry, very complicated or badly implemented : that's why developers sometimes mess up in the implementation process (because of time/cost constraints). That's why it can be interesting to take the opposite approach: take a norm, look at all mandatory features and constraints, and try all of them; forbidden/reserved values, linked parameters, field sizes. That would be ''hand-fuzzing''.<br /> <br /> == Application fuzzing ==<br /> <br /> Whatever the fuzzed system is, the attack vectors are within it's I/O. For a desktop app:<br /> - the UI (testing all the buttons sequences / text inputs)<br /> - the command-line options<br /> - the import/export capabilities (see file format fuzzing below)<br /> <br /> For a web app, urls and forms are the inputs, and eventually (especially for user-generated content websites) media files.<br /> <br /> == Protocol fuzzing ==<br /> <br /> A protocol fuzzer sends forged packets to the tested application, or eventually acts as a proxy, modifying requests on the fly and replaying them.<br /> <br /> == File format fuzzing ==<br /> <br /> A file format fuzzer generates multiple malformed samples, and opens them sequentially. When the program crashes, debug information is kept for further investigation.<br /> <br /> One can attack:<br /> <br /> - the parser layer (container layer): file format constraints, structure, conventions, field sizes, flags, ...<br /> <br /> - the codec/application layer: lower-level attacks, aiming at the program's deeper internals<br /> <br /> Example found vulnerability: Microsoft's JPEG GDI+ vulnerability was a zero sized comment field, without content.<br /> <br /> <br /> Surprisingly, file format fuzzers are not common.<br /> <br /> A generic file format fuzzer is Ilja van Sprundel's mangle.c[http://www.digitaldwarf.be/products/mangle.c]; &quot;it's usage is very simple, it takes a filename and headersize as input. it will then change approximatly between 0 and 10% of the header with random bytes.&quot; (from the author)<br /> <br /> One may use tools like Hachoir[http://hachoir.org/] as a generic parser for file format fuzzers development.<br /> <br /> == Fuzzers advantages ==<br /> <br /> ''The great advantage of fuzz testing is that the test design is extremely simple, and free of preconceptions about system behavior'' (from Wikipedia [http://en.wikipedia.org/wiki/Fuzz_testing]).<br /> <br /> The systematical/random approach allows this method to find bugs that would have often been missed by human eyes. Plus, when the tested system is totally closed (say, a SIP phone), fuzzing is one of the only means of reviewing it's quality.<br /> <br /> == Fuzzers limitations ==<br /> <br /> Fuzzers usually tend to try one-level-imbrication-level attacks, which means changing only one parameter at a time. Therefore, fuzzing tools can detect trivial errors, but are less gifted with deep ones.<br /> <br /> Another problem is that when you do some black-box-testing, you usually attack a closed system, which increases difficulty to evaluate the dangerosity/impact of the found vulnerability.<br /> <br /> == Why Fuzz? ==<br /> <br /> The purpose of fuzzing relies on the assumption that there are bugs within every program, which are waiting to be discovered. Therefore, a systematical approach should find them sooner or later.<br /> <br /> Fuzzing can add another point of view to classical software testing techniques (hand code review, debugging) because of it's non-human approach. It doesn't replace them, but is a reasonable complement, thanks to the limited work needed to put the procedure in place.<br /> <br /> == Fuzzers from OWASP ==<br /> <br /> Fuzzing with WebScarab [http://www.owasp.org/index.php/Fuzzing_with_WebScarab]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br /> <br /> JBroFuzz [http://www.owasp.org/index.php/JBroFuzz]: a stateless network protocol fuzzer<br /> <br /> WSFuzzer [http://www.owasp.org/index.php/WSFuzzer]: real-world manual SOAP pen testing tool<br /> <br /> == Technical resources on OWASP ==<br /> <br /> Fuzzing vectors [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors]<br /> <br /> == Sources ==<br /> <br /> Wikipedia article [http://en.wikipedia.org/wiki/Fuzz_testing]<br /> <br /> Fuzzing-related papers [http://www.threatmind.net/secwiki/FuzzingPapers]<br /> <br /> == Fuzzing tools ==<br /> <br /> The ultimate fuzzers list @ infosec [http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html]<br /> <br /> Another list @ hacksafe<br /> [http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/]<br /> <br /> The fuzzing mailing list [http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing]<br /> <br /> == Commercial products ==<br /> <br /> Codenomicon's product suite: [http://www.codenomicon.com/products/all.shtml]</div>

Fthiery https://wiki.owasp.org/index.php?title=Fuzzing&diff=14244 2006-12-12T10:17:37Z

<p>Fthiery: /* File format fuzzing */</p> <hr /> <div>''Fuzz testing'' or ''Fuzzing'' is a Black Box software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection in an automated fashion.<br /> <br /> == A trivial example: ==<br /> <br /> Lets's consider an integer in a program, which stores the result of a user's choice between 3 questions. When the user picks one, the choice will be 0, 1 or 2. Which makes three practical cases. But what if we transmit 3, or 255 ? We can, because integers are stored a static size variable. If the default switch case hasn't been implemented securely, the program may crash and lead to &quot;classical&quot; security issues: (un)exploitable buffer overflows, DoS, ...<br /> <br /> Fuzzing is the art of automatic bug finding, and it's role is to find software implementation faults, and identify them if possible.<br /> <br /> == History ==<br /> <br /> Fuzz testing was developed at the University of Wisconsin Madison in 1989 by Professor Barton Miller and his students. Their (continued) work can be found at http://www.cs.wisc.edu/~bart/fuzz/ ; it's mainly oriented towards command-line and UI fuzzing.<br /> <br /> == Fuzzer implementations ==<br /> <br /> A fuzzer is a program which injects automatically semi-random data into a program/stack and detect bugs.<br /> The data-generation part is made of generators, and vulnerability identification relies on debugging tools.<br /> <br /> == Comparison with cryptanalysis ==<br /> <br /> The number of possible tryable solutions is ''the explorable solutions space''. The aim of cryptanalysis is to reduce this space, which means finding a way of having less keys to try than pure bruteforce to decrypt something. <br /> <br /> Most of the fuzzers are:<br /> <br /> - protocol/file-format dependant<br /> <br /> - data-type dependant<br /> <br /> Why? <br /> <br /> Because a program only understands structured-enough data. If you connect to a web server in a raw way, it will only respond to listed commands such as GET (or eventually crash). It will take less time to start the string with &quot;GET &quot;, and fuzz the rest, but the drawback is that you'll skip all the tests on the first verb.<br /> <br /> In this regard, Fuzzers try to reduce the number of unuseful tests, i.e. the values we already know that there's little chance they'll work: you reduce impredictibility, in favor of speed.<br /> <br /> == Attack types ==<br /> <br /> A fuzzer would try combinations of attacks on:<br /> <br /> - numbers (signed/unsigned integers/float...)<br /> <br /> - chars (urls, command-line inputs)<br /> <br /> - metadata : user-input text (id3 tag)<br /> <br /> - pure binary sequences<br /> <br /> <br /> A common approach to fuzzing is to define lists of &quot;known-to-be-dangerous values&quot; (''fuzz vectors'') for each type, and to inject them or recombinations.<br /> <br /> - for integers: zero, possibly negative or very big numbers<br /> <br /> - for chars: escaped, interpretable characters / instructions (ex: For SQL Requests, quotes / commands...)<br /> <br /> - for binary: random ones<br /> <br /> Please refer to OWASP's Fuzz Vector's resource[http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors] for real-life examples.<br /> <br /> <br /> Protocols and file formats imply norms, which are sometimes blurry, very complicated or badly implemented : that's why developers sometimes mess up in the implementation process (because of time/cost constraints). That's why it can be interesting to take the opposite approach: take a norm, look at all mandatory features and constraints, and try all of them; forbidden/reserved values, linked parameters, field sizes. That would be ''hand-fuzzing''.<br /> <br /> == Application fuzzing ==<br /> <br /> Whatever the fuzzed system is, the attack vectors are within it's I/O. For a desktop app:<br /> - the UI (testing all the buttons sequences / text inputs)<br /> - the command-line options<br /> - the import/export capabilities (see file format fuzzing below)<br /> <br /> For a web app, urls and forms are the inputs, and eventually (especially for user-generated content websites) media files.<br /> <br /> == Protocol fuzzing ==<br /> <br /> A protocol fuzzer sends forged packets to the tested application, or eventually acts as a proxy, modifying requests on the fly and replaying them.<br /> <br /> == File format fuzzing ==<br /> <br /> A file format fuzzer generates multiple malformed samples, and opens them sequentially. When the program crashes, debug information is kept for further investigation.<br /> <br /> One can attack:<br /> <br /> - the parser layer (container layer): file format constraints, structure, conventions, field sizes, flags, ...<br /> <br /> - the codec/application layer: lower-level attacks, aiming at the program's deeper internals<br /> <br /> Example found vulnerability: Microsoft's JPEG GDI+ vulnerability was a zero sized comment field, without content.<br /> <br /> <br /> Surprisingly, file format fuzzers are not common.<br /> <br /> A generic file format fuzzer is Ilja van Sprundel's mangle.c[http://www.digitaldwarf.be/products/mangle.c]; &quot;it's usage is very simple, it takes a filename and headersize as input. it will then change approximatly between 0 and 10% of the header with random bytes.&quot; (from the author)<br /> <br /> One may use tools like Hachoir[http://hachoir.org/] as a generic parser for file format fuzzers development.<br /> <br /> == Fuzzers advantages ==<br /> <br /> ''The great advantage of fuzz testing is that the test design is extremely simple, and free of preconceptions about system behavior'' (from Wikipedia [http://en.wikipedia.org/wiki/Fuzz_testing]).<br /> <br /> The systematical/random approach allows this method to find bugs that would have often been missed by human eyes. Plus, when the tested system is totally closed (say, a SIP phone), fuzzing is one of the only means of reviewing it's quality.<br /> <br /> == Fuzzers limitations ==<br /> <br /> Fuzzers usually tend to try one-level-imbrication-level attacks, which means changing only one parameter at a time. Therefore, fuzzing tools can detect trivial errors, but are less gifted with deep ones.<br /> <br /> Another problem is that when you do some black-box-testing, you usually attack a closed system, which increases difficulty to evaluate the dangerosity/impact of the found vulnerability.<br /> <br /> == Why Fuzz? ==<br /> <br /> The purpose of fuzzing relies on the assumption that there are bugs within every program, which are waiting to be discovered. Therefore, a systematical approach should find them sooner or later.<br /> <br /> Fuzzing can add another point of view to classical software testing techniques (hand code review, debugging) because of it's non-human approach. It doesn't replace them, but is a reasonable complement, thanks to the limited work needed to put the procedure in place.<br /> <br /> == Fuzzers from OWASP ==<br /> <br /> Fuzzing with WebScarab [http://www.owasp.org/index.php/Fuzzing_with_WebScarab]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br /> <br /> JBroFuzz [http://www.owasp.org/index.php/JBroFuzz]: a stateless network protocol fuzzer<br /> <br /> WSFuzzer [http://www.owasp.org/index.php/WSFuzzer]: real-world manual SOAP pen testing tool<br /> <br /> == Technical resources on OWASP ==<br /> <br /> Fuzzing vectors [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors]<br /> <br /> == Sources ==<br /> <br /> Wikipedia article [http://en.wikipedia.org/wiki/Fuzz_testing]<br /> <br /> Fuzzing-related papers [http://www.threatmind.net/secwiki/FuzzingPapers]<br /> <br /> == Fuzzing tools ==<br /> <br /> The ultimate fuzzers list @ infosec [http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html]<br /> <br /> Another list @ hacksafe<br /> [http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/]<br /> <br /> The fuzzing mailing list [http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing]<br /> <br /> == Commercial products ==<br /> <br /> Codenomicon's product suite: [http://www.codenomicon.com/products/all.shtml]</div>

Fthiery https://wiki.owasp.org/index.php?title=Fuzzing&diff=14243 2006-12-12T10:16:43Z

<p>Fthiery: /* File format fuzzing */</p> <hr /> <div>''Fuzz testing'' or ''Fuzzing'' is a Black Box software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection in an automated fashion.<br /> <br /> == A trivial example: ==<br /> <br /> Lets's consider an integer in a program, which stores the result of a user's choice between 3 questions. When the user picks one, the choice will be 0, 1 or 2. Which makes three practical cases. But what if we transmit 3, or 255 ? We can, because integers are stored a static size variable. If the default switch case hasn't been implemented securely, the program may crash and lead to &quot;classical&quot; security issues: (un)exploitable buffer overflows, DoS, ...<br /> <br /> Fuzzing is the art of automatic bug finding, and it's role is to find software implementation faults, and identify them if possible.<br /> <br /> == History ==<br /> <br /> Fuzz testing was developed at the University of Wisconsin Madison in 1989 by Professor Barton Miller and his students. Their (continued) work can be found at http://www.cs.wisc.edu/~bart/fuzz/ ; it's mainly oriented towards command-line and UI fuzzing.<br /> <br /> == Fuzzer implementations ==<br /> <br /> A fuzzer is a program which injects automatically semi-random data into a program/stack and detect bugs.<br /> The data-generation part is made of generators, and vulnerability identification relies on debugging tools.<br /> <br /> == Comparison with cryptanalysis ==<br /> <br /> The number of possible tryable solutions is ''the explorable solutions space''. The aim of cryptanalysis is to reduce this space, which means finding a way of having less keys to try than pure bruteforce to decrypt something. <br /> <br /> Most of the fuzzers are:<br /> <br /> - protocol/file-format dependant<br /> <br /> - data-type dependant<br /> <br /> Why? <br /> <br /> Because a program only understands structured-enough data. If you connect to a web server in a raw way, it will only respond to listed commands such as GET (or eventually crash). It will take less time to start the string with &quot;GET &quot;, and fuzz the rest, but the drawback is that you'll skip all the tests on the first verb.<br /> <br /> In this regard, Fuzzers try to reduce the number of unuseful tests, i.e. the values we already know that there's little chance they'll work: you reduce impredictibility, in favor of speed.<br /> <br /> == Attack types ==<br /> <br /> A fuzzer would try combinations of attacks on:<br /> <br /> - numbers (signed/unsigned integers/float...)<br /> <br /> - chars (urls, command-line inputs)<br /> <br /> - metadata : user-input text (id3 tag)<br /> <br /> - pure binary sequences<br /> <br /> <br /> A common approach to fuzzing is to define lists of &quot;known-to-be-dangerous values&quot; (''fuzz vectors'') for each type, and to inject them or recombinations.<br /> <br /> - for integers: zero, possibly negative or very big numbers<br /> <br /> - for chars: escaped, interpretable characters / instructions (ex: For SQL Requests, quotes / commands...)<br /> <br /> - for binary: random ones<br /> <br /> Please refer to OWASP's Fuzz Vector's resource[http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors] for real-life examples.<br /> <br /> <br /> Protocols and file formats imply norms, which are sometimes blurry, very complicated or badly implemented : that's why developers sometimes mess up in the implementation process (because of time/cost constraints). That's why it can be interesting to take the opposite approach: take a norm, look at all mandatory features and constraints, and try all of them; forbidden/reserved values, linked parameters, field sizes. That would be ''hand-fuzzing''.<br /> <br /> == Application fuzzing ==<br /> <br /> Whatever the fuzzed system is, the attack vectors are within it's I/O. For a desktop app:<br /> - the UI (testing all the buttons sequences / text inputs)<br /> - the command-line options<br /> - the import/export capabilities (see file format fuzzing below)<br /> <br /> For a web app, urls and forms are the inputs, and eventually (especially for user-generated content websites) media files.<br /> <br /> == Protocol fuzzing ==<br /> <br /> A protocol fuzzer sends forged packets to the tested application, or eventually acts as a proxy, modifying requests on the fly and replaying them.<br /> <br /> == File format fuzzing ==<br /> <br /> A file format fuzzer generates multiple malformed samples, and opens them sequentially. When the program crashes, debug information is kept for further investigation.<br /> <br /> One can attack:<br /> <br /> - the parser layer (container layer): file format constraints, structure, conventions, field sizes, flags, ...<br /> <br /> - the codec/application layer: lower-level attacks, aiming at the program's deeper internals<br /> <br /> Example found vulnerability: Microsoft's JPEG GDI+ vulnerability was a zero sized comment field, without content.<br /> <br /> <br /> A generic file format fuzzer is Ilja van Sprundel's mangle.c[http://www.digitaldwarf.be/products/mangle.c]; &quot;it's usage is very simple, it takes a filename and headersize as input. it will then change approximatly between 0 and 10% of the header with random bytes.&quot; (from the author)<br /> <br /> <br /> One may use tools like Hachoir[http://hachoir.org/] as a generic parser for file format fuzzers development.<br /> <br /> <br /> Surprisingly, file format fuzzers are not common, but shall see a regain of interest.<br /> <br /> == Fuzzers advantages ==<br /> <br /> ''The great advantage of fuzz testing is that the test design is extremely simple, and free of preconceptions about system behavior'' (from Wikipedia [http://en.wikipedia.org/wiki/Fuzz_testing]).<br /> <br /> The systematical/random approach allows this method to find bugs that would have often been missed by human eyes. Plus, when the tested system is totally closed (say, a SIP phone), fuzzing is one of the only means of reviewing it's quality.<br /> <br /> == Fuzzers limitations ==<br /> <br /> Fuzzers usually tend to try one-level-imbrication-level attacks, which means changing only one parameter at a time. Therefore, fuzzing tools can detect trivial errors, but are less gifted with deep ones.<br /> <br /> Another problem is that when you do some black-box-testing, you usually attack a closed system, which increases difficulty to evaluate the dangerosity/impact of the found vulnerability.<br /> <br /> == Why Fuzz? ==<br /> <br /> The purpose of fuzzing relies on the assumption that there are bugs within every program, which are waiting to be discovered. Therefore, a systematical approach should find them sooner or later.<br /> <br /> Fuzzing can add another point of view to classical software testing techniques (hand code review, debugging) because of it's non-human approach. It doesn't replace them, but is a reasonable complement, thanks to the limited work needed to put the procedure in place.<br /> <br /> == Fuzzers from OWASP ==<br /> <br /> Fuzzing with WebScarab [http://www.owasp.org/index.php/Fuzzing_with_WebScarab]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br /> <br /> JBroFuzz [http://www.owasp.org/index.php/JBroFuzz]: a stateless network protocol fuzzer<br /> <br /> WSFuzzer [http://www.owasp.org/index.php/WSFuzzer]: real-world manual SOAP pen testing tool<br /> <br /> == Technical resources on OWASP ==<br /> <br /> Fuzzing vectors [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors]<br /> <br /> == Sources ==<br /> <br /> Wikipedia article [http://en.wikipedia.org/wiki/Fuzz_testing]<br /> <br /> Fuzzing-related papers [http://www.threatmind.net/secwiki/FuzzingPapers]<br /> <br /> == Fuzzing tools ==<br /> <br /> The ultimate fuzzers list @ infosec [http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html]<br /> <br /> Another list @ hacksafe<br /> [http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/]<br /> <br /> The fuzzing mailing list [http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing]<br /> <br /> == Commercial products ==<br /> <br /> Codenomicon's product suite: [http://www.codenomicon.com/products/all.shtml]</div>

Fthiery https://wiki.owasp.org/index.php?title=Fuzzing&diff=14242 2006-12-12T10:16:30Z

<p>Fthiery: /* File format fuzzing */</p> <hr /> <div>''Fuzz testing'' or ''Fuzzing'' is a Black Box software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection in an automated fashion.<br /> <br /> == A trivial example: ==<br /> <br /> Lets's consider an integer in a program, which stores the result of a user's choice between 3 questions. When the user picks one, the choice will be 0, 1 or 2. Which makes three practical cases. But what if we transmit 3, or 255 ? We can, because integers are stored a static size variable. If the default switch case hasn't been implemented securely, the program may crash and lead to &quot;classical&quot; security issues: (un)exploitable buffer overflows, DoS, ...<br /> <br /> Fuzzing is the art of automatic bug finding, and it's role is to find software implementation faults, and identify them if possible.<br /> <br /> == History ==<br /> <br /> Fuzz testing was developed at the University of Wisconsin Madison in 1989 by Professor Barton Miller and his students. Their (continued) work can be found at http://www.cs.wisc.edu/~bart/fuzz/ ; it's mainly oriented towards command-line and UI fuzzing.<br /> <br /> == Fuzzer implementations ==<br /> <br /> A fuzzer is a program which injects automatically semi-random data into a program/stack and detect bugs.<br /> The data-generation part is made of generators, and vulnerability identification relies on debugging tools.<br /> <br /> == Comparison with cryptanalysis ==<br /> <br /> The number of possible tryable solutions is ''the explorable solutions space''. The aim of cryptanalysis is to reduce this space, which means finding a way of having less keys to try than pure bruteforce to decrypt something. <br /> <br /> Most of the fuzzers are:<br /> <br /> - protocol/file-format dependant<br /> <br /> - data-type dependant<br /> <br /> Why? <br /> <br /> Because a program only understands structured-enough data. If you connect to a web server in a raw way, it will only respond to listed commands such as GET (or eventually crash). It will take less time to start the string with &quot;GET &quot;, and fuzz the rest, but the drawback is that you'll skip all the tests on the first verb.<br /> <br /> In this regard, Fuzzers try to reduce the number of unuseful tests, i.e. the values we already know that there's little chance they'll work: you reduce impredictibility, in favor of speed.<br /> <br /> == Attack types ==<br /> <br /> A fuzzer would try combinations of attacks on:<br /> <br /> - numbers (signed/unsigned integers/float...)<br /> <br /> - chars (urls, command-line inputs)<br /> <br /> - metadata : user-input text (id3 tag)<br /> <br /> - pure binary sequences<br /> <br /> <br /> A common approach to fuzzing is to define lists of &quot;known-to-be-dangerous values&quot; (''fuzz vectors'') for each type, and to inject them or recombinations.<br /> <br /> - for integers: zero, possibly negative or very big numbers<br /> <br /> - for chars: escaped, interpretable characters / instructions (ex: For SQL Requests, quotes / commands...)<br /> <br /> - for binary: random ones<br /> <br /> Please refer to OWASP's Fuzz Vector's resource[http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors] for real-life examples.<br /> <br /> <br /> Protocols and file formats imply norms, which are sometimes blurry, very complicated or badly implemented : that's why developers sometimes mess up in the implementation process (because of time/cost constraints). That's why it can be interesting to take the opposite approach: take a norm, look at all mandatory features and constraints, and try all of them; forbidden/reserved values, linked parameters, field sizes. That would be ''hand-fuzzing''.<br /> <br /> == Application fuzzing ==<br /> <br /> Whatever the fuzzed system is, the attack vectors are within it's I/O. For a desktop app:<br /> - the UI (testing all the buttons sequences / text inputs)<br /> - the command-line options<br /> - the import/export capabilities (see file format fuzzing below)<br /> <br /> For a web app, urls and forms are the inputs, and eventually (especially for user-generated content websites) media files.<br /> <br /> == Protocol fuzzing ==<br /> <br /> A protocol fuzzer sends forged packets to the tested application, or eventually acts as a proxy, modifying requests on the fly and replaying them.<br /> <br /> == File format fuzzing ==<br /> <br /> A file format fuzzer generates multiple malformed samples, and opens them sequentially. When the program crashes, debug information is kept for further investigation.<br /> <br /> One can attack:<br /> <br /> - the parser layer (container layer): file format constraints, structure, conventions, field sizes, flags, ...<br /> <br /> - the codec/application layer: lower-level attacks, aiming at the program's deeper internals<br /> <br /> Example found vulnerability: Microsoft's JPEG GDI+ vulnerability was a zero sized comment field, without content.<br /> <br /> <br /> A generic file format fuzzer is Ilja van Sprundel's mangle.c[http://www.digitaldwarf.be/products/mangle.c]; &quot;it's usage is very simple, it takes a filename and headersize as input. it will then change approximatly between 0 and 10% of the header with random bytes.&quot; (from the author)<br /> <br /> One may use tools like Hachoir[http://hachoir.org/] as a generic parser for file format fuzzers development.<br /> <br /> Surprisingly, file format fuzzers are not common, but shall see a regain of interest.<br /> <br /> == Fuzzers advantages ==<br /> <br /> ''The great advantage of fuzz testing is that the test design is extremely simple, and free of preconceptions about system behavior'' (from Wikipedia [http://en.wikipedia.org/wiki/Fuzz_testing]).<br /> <br /> The systematical/random approach allows this method to find bugs that would have often been missed by human eyes. Plus, when the tested system is totally closed (say, a SIP phone), fuzzing is one of the only means of reviewing it's quality.<br /> <br /> == Fuzzers limitations ==<br /> <br /> Fuzzers usually tend to try one-level-imbrication-level attacks, which means changing only one parameter at a time. Therefore, fuzzing tools can detect trivial errors, but are less gifted with deep ones.<br /> <br /> Another problem is that when you do some black-box-testing, you usually attack a closed system, which increases difficulty to evaluate the dangerosity/impact of the found vulnerability.<br /> <br /> == Why Fuzz? ==<br /> <br /> The purpose of fuzzing relies on the assumption that there are bugs within every program, which are waiting to be discovered. Therefore, a systematical approach should find them sooner or later.<br /> <br /> Fuzzing can add another point of view to classical software testing techniques (hand code review, debugging) because of it's non-human approach. It doesn't replace them, but is a reasonable complement, thanks to the limited work needed to put the procedure in place.<br /> <br /> == Fuzzers from OWASP ==<br /> <br /> Fuzzing with WebScarab [http://www.owasp.org/index.php/Fuzzing_with_WebScarab]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br /> <br /> JBroFuzz [http://www.owasp.org/index.php/JBroFuzz]: a stateless network protocol fuzzer<br /> <br /> WSFuzzer [http://www.owasp.org/index.php/WSFuzzer]: real-world manual SOAP pen testing tool<br /> <br /> == Technical resources on OWASP ==<br /> <br /> Fuzzing vectors [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors]<br /> <br /> == Sources ==<br /> <br /> Wikipedia article [http://en.wikipedia.org/wiki/Fuzz_testing]<br /> <br /> Fuzzing-related papers [http://www.threatmind.net/secwiki/FuzzingPapers]<br /> <br /> == Fuzzing tools ==<br /> <br /> The ultimate fuzzers list @ infosec [http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html]<br /> <br /> Another list @ hacksafe<br /> [http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/]<br /> <br /> The fuzzing mailing list [http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing]<br /> <br /> == Commercial products ==<br /> <br /> Codenomicon's product suite: [http://www.codenomicon.com/products/all.shtml]</div>

Fthiery https://wiki.owasp.org/index.php?title=Fuzzing&diff=14241 2006-12-12T10:14:56Z

<p>Fthiery: /* Attack types */</p> <hr /> <div>''Fuzz testing'' or ''Fuzzing'' is a Black Box software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection in an automated fashion.<br /> <br /> == A trivial example: ==<br /> <br /> Lets's consider an integer in a program, which stores the result of a user's choice between 3 questions. When the user picks one, the choice will be 0, 1 or 2. Which makes three practical cases. But what if we transmit 3, or 255 ? We can, because integers are stored a static size variable. If the default switch case hasn't been implemented securely, the program may crash and lead to &quot;classical&quot; security issues: (un)exploitable buffer overflows, DoS, ...<br /> <br /> Fuzzing is the art of automatic bug finding, and it's role is to find software implementation faults, and identify them if possible.<br /> <br /> == History ==<br /> <br /> Fuzz testing was developed at the University of Wisconsin Madison in 1989 by Professor Barton Miller and his students. Their (continued) work can be found at http://www.cs.wisc.edu/~bart/fuzz/ ; it's mainly oriented towards command-line and UI fuzzing.<br /> <br /> == Fuzzer implementations ==<br /> <br /> A fuzzer is a program which injects automatically semi-random data into a program/stack and detect bugs.<br /> The data-generation part is made of generators, and vulnerability identification relies on debugging tools.<br /> <br /> == Comparison with cryptanalysis ==<br /> <br /> The number of possible tryable solutions is ''the explorable solutions space''. The aim of cryptanalysis is to reduce this space, which means finding a way of having less keys to try than pure bruteforce to decrypt something. <br /> <br /> Most of the fuzzers are:<br /> <br /> - protocol/file-format dependant<br /> <br /> - data-type dependant<br /> <br /> Why? <br /> <br /> Because a program only understands structured-enough data. If you connect to a web server in a raw way, it will only respond to listed commands such as GET (or eventually crash). It will take less time to start the string with &quot;GET &quot;, and fuzz the rest, but the drawback is that you'll skip all the tests on the first verb.<br /> <br /> In this regard, Fuzzers try to reduce the number of unuseful tests, i.e. the values we already know that there's little chance they'll work: you reduce impredictibility, in favor of speed.<br /> <br /> == Attack types ==<br /> <br /> A fuzzer would try combinations of attacks on:<br /> <br /> - numbers (signed/unsigned integers/float...)<br /> <br /> - chars (urls, command-line inputs)<br /> <br /> - metadata : user-input text (id3 tag)<br /> <br /> - pure binary sequences<br /> <br /> <br /> A common approach to fuzzing is to define lists of &quot;known-to-be-dangerous values&quot; (''fuzz vectors'') for each type, and to inject them or recombinations.<br /> <br /> - for integers: zero, possibly negative or very big numbers<br /> <br /> - for chars: escaped, interpretable characters / instructions (ex: For SQL Requests, quotes / commands...)<br /> <br /> - for binary: random ones<br /> <br /> Please refer to OWASP's Fuzz Vector's resource[http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors] for real-life examples.<br /> <br /> <br /> Protocols and file formats imply norms, which are sometimes blurry, very complicated or badly implemented : that's why developers sometimes mess up in the implementation process (because of time/cost constraints). That's why it can be interesting to take the opposite approach: take a norm, look at all mandatory features and constraints, and try all of them; forbidden/reserved values, linked parameters, field sizes. That would be ''hand-fuzzing''.<br /> <br /> == Application fuzzing ==<br /> <br /> Whatever the fuzzed system is, the attack vectors are within it's I/O. For a desktop app:<br /> - the UI (testing all the buttons sequences / text inputs)<br /> - the command-line options<br /> - the import/export capabilities (see file format fuzzing below)<br /> <br /> For a web app, urls and forms are the inputs, and eventually (especially for user-generated content websites) media files.<br /> <br /> == Protocol fuzzing ==<br /> <br /> A protocol fuzzer sends forged packets to the tested application, or eventually acts as a proxy, modifying requests on the fly and replaying them.<br /> <br /> == File format fuzzing ==<br /> <br /> A file format fuzzer generates multiple malformed samples, and opens them sequentially. When the program crashes, debug information is kept for further investigation.<br /> <br /> One can attack:<br /> <br /> - the parser layer (container layer): file format constraints, structure, conventions, field sizes, flags, ...<br /> <br /> - the codec/application layer: lower-level attacks, aiming at the program's deeper internals<br /> <br /> Example found vulnerability: Microsoft's JPEG GDI+ vulnerability was a zero sized comment field, without content.<br /> <br /> A generic file format fuzzer is Ilja van Sprundel's mangle.c[http://www.digitaldwarf.be/products/mangle.c]; &quot;it's usage is very simple, it takes a filename and headersize as input. it will then change approximatly between 0 and 10% of the header with random bytes.&quot;<br /> <br /> One may use tools like Hachoir[http://hachoir.org/] as a generic parser for file format fuzzers development.<br /> <br /> == Fuzzers advantages ==<br /> <br /> ''The great advantage of fuzz testing is that the test design is extremely simple, and free of preconceptions about system behavior'' (from Wikipedia [http://en.wikipedia.org/wiki/Fuzz_testing]).<br /> <br /> The systematical/random approach allows this method to find bugs that would have often been missed by human eyes. Plus, when the tested system is totally closed (say, a SIP phone), fuzzing is one of the only means of reviewing it's quality.<br /> <br /> == Fuzzers limitations ==<br /> <br /> Fuzzers usually tend to try one-level-imbrication-level attacks, which means changing only one parameter at a time. Therefore, fuzzing tools can detect trivial errors, but are less gifted with deep ones.<br /> <br /> Another problem is that when you do some black-box-testing, you usually attack a closed system, which increases difficulty to evaluate the dangerosity/impact of the found vulnerability.<br /> <br /> == Why Fuzz? ==<br /> <br /> The purpose of fuzzing relies on the assumption that there are bugs within every program, which are waiting to be discovered. Therefore, a systematical approach should find them sooner or later.<br /> <br /> Fuzzing can add another point of view to classical software testing techniques (hand code review, debugging) because of it's non-human approach. It doesn't replace them, but is a reasonable complement, thanks to the limited work needed to put the procedure in place.<br /> <br /> == Fuzzers from OWASP ==<br /> <br /> Fuzzing with WebScarab [http://www.owasp.org/index.php/Fuzzing_with_WebScarab]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br /> <br /> JBroFuzz [http://www.owasp.org/index.php/JBroFuzz]: a stateless network protocol fuzzer<br /> <br /> WSFuzzer [http://www.owasp.org/index.php/WSFuzzer]: real-world manual SOAP pen testing tool<br /> <br /> == Technical resources on OWASP ==<br /> <br /> Fuzzing vectors [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors]<br /> <br /> == Sources ==<br /> <br /> Wikipedia article [http://en.wikipedia.org/wiki/Fuzz_testing]<br /> <br /> Fuzzing-related papers [http://www.threatmind.net/secwiki/FuzzingPapers]<br /> <br /> == Fuzzing tools ==<br /> <br /> The ultimate fuzzers list @ infosec [http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html]<br /> <br /> Another list @ hacksafe<br /> [http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/]<br /> <br /> The fuzzing mailing list [http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing]<br /> <br /> == Commercial products ==<br /> <br /> Codenomicon's product suite: [http://www.codenomicon.com/products/all.shtml]</div>

Fthiery https://wiki.owasp.org/index.php?title=Fuzzing&diff=14240 2006-12-12T10:14:41Z

<p>Fthiery: /* Attack types */</p> <hr /> <div>''Fuzz testing'' or ''Fuzzing'' is a Black Box software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection in an automated fashion.<br /> <br /> == A trivial example: ==<br /> <br /> Lets's consider an integer in a program, which stores the result of a user's choice between 3 questions. When the user picks one, the choice will be 0, 1 or 2. Which makes three practical cases. But what if we transmit 3, or 255 ? We can, because integers are stored a static size variable. If the default switch case hasn't been implemented securely, the program may crash and lead to &quot;classical&quot; security issues: (un)exploitable buffer overflows, DoS, ...<br /> <br /> Fuzzing is the art of automatic bug finding, and it's role is to find software implementation faults, and identify them if possible.<br /> <br /> == History ==<br /> <br /> Fuzz testing was developed at the University of Wisconsin Madison in 1989 by Professor Barton Miller and his students. Their (continued) work can be found at http://www.cs.wisc.edu/~bart/fuzz/ ; it's mainly oriented towards command-line and UI fuzzing.<br /> <br /> == Fuzzer implementations ==<br /> <br /> A fuzzer is a program which injects automatically semi-random data into a program/stack and detect bugs.<br /> The data-generation part is made of generators, and vulnerability identification relies on debugging tools.<br /> <br /> == Comparison with cryptanalysis ==<br /> <br /> The number of possible tryable solutions is ''the explorable solutions space''. The aim of cryptanalysis is to reduce this space, which means finding a way of having less keys to try than pure bruteforce to decrypt something. <br /> <br /> Most of the fuzzers are:<br /> <br /> - protocol/file-format dependant<br /> <br /> - data-type dependant<br /> <br /> Why? <br /> <br /> Because a program only understands structured-enough data. If you connect to a web server in a raw way, it will only respond to listed commands such as GET (or eventually crash). It will take less time to start the string with &quot;GET &quot;, and fuzz the rest, but the drawback is that you'll skip all the tests on the first verb.<br /> <br /> In this regard, Fuzzers try to reduce the number of unuseful tests, i.e. the values we already know that there's little chance they'll work: you reduce impredictibility, in favor of speed.<br /> <br /> == Attack types ==<br /> <br /> A fuzzer would try combinations of attacks on:<br /> <br /> - numbers (signed/unsigned integers/float...)<br /> <br /> - chars (urls, command-line inputs)<br /> <br /> - metadata : user-input text (id3 tag)<br /> <br /> - pure binary sequences<br /> <br /> A common approach to fuzzing is to define lists of &quot;known-to-be-dangerous values&quot; (''fuzz vectors'') for each type, and to inject them or recombinations.<br /> <br /> - for integers: zero, possibly negative or very big numbers<br /> <br /> - for chars: escaped, interpretable characters / instructions (ex: For SQL Requests, quotes / commands...)<br /> <br /> - for binary: random ones<br /> <br /> Please refer to OWASP's Fuzz Vector's resource[http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors] for real-life examples.<br /> <br /> Protocols and file formats imply norms, which are sometimes blurry, very complicated or badly implemented : that's why developers sometimes mess up in the implementation process (because of time/cost constraints). That's why it can be interesting to take the opposite approach: take a norm, look at all mandatory features and constraints, and try all of them; forbidden/reserved values, linked parameters, field sizes. That would be ''hand-fuzzing''.<br /> <br /> == Application fuzzing ==<br /> <br /> Whatever the fuzzed system is, the attack vectors are within it's I/O. For a desktop app:<br /> - the UI (testing all the buttons sequences / text inputs)<br /> - the command-line options<br /> - the import/export capabilities (see file format fuzzing below)<br /> <br /> For a web app, urls and forms are the inputs, and eventually (especially for user-generated content websites) media files.<br /> <br /> == Protocol fuzzing ==<br /> <br /> A protocol fuzzer sends forged packets to the tested application, or eventually acts as a proxy, modifying requests on the fly and replaying them.<br /> <br /> == File format fuzzing ==<br /> <br /> A file format fuzzer generates multiple malformed samples, and opens them sequentially. When the program crashes, debug information is kept for further investigation.<br /> <br /> One can attack:<br /> <br /> - the parser layer (container layer): file format constraints, structure, conventions, field sizes, flags, ...<br /> <br /> - the codec/application layer: lower-level attacks, aiming at the program's deeper internals<br /> <br /> Example found vulnerability: Microsoft's JPEG GDI+ vulnerability was a zero sized comment field, without content.<br /> <br /> A generic file format fuzzer is Ilja van Sprundel's mangle.c[http://www.digitaldwarf.be/products/mangle.c]; &quot;it's usage is very simple, it takes a filename and headersize as input. it will then change approximatly between 0 and 10% of the header with random bytes.&quot;<br /> <br /> One may use tools like Hachoir[http://hachoir.org/] as a generic parser for file format fuzzers development.<br /> <br /> == Fuzzers advantages ==<br /> <br /> ''The great advantage of fuzz testing is that the test design is extremely simple, and free of preconceptions about system behavior'' (from Wikipedia [http://en.wikipedia.org/wiki/Fuzz_testing]).<br /> <br /> The systematical/random approach allows this method to find bugs that would have often been missed by human eyes. Plus, when the tested system is totally closed (say, a SIP phone), fuzzing is one of the only means of reviewing it's quality.<br /> <br /> == Fuzzers limitations ==<br /> <br /> Fuzzers usually tend to try one-level-imbrication-level attacks, which means changing only one parameter at a time. Therefore, fuzzing tools can detect trivial errors, but are less gifted with deep ones.<br /> <br /> Another problem is that when you do some black-box-testing, you usually attack a closed system, which increases difficulty to evaluate the dangerosity/impact of the found vulnerability.<br /> <br /> == Why Fuzz? ==<br /> <br /> The purpose of fuzzing relies on the assumption that there are bugs within every program, which are waiting to be discovered. Therefore, a systematical approach should find them sooner or later.<br /> <br /> Fuzzing can add another point of view to classical software testing techniques (hand code review, debugging) because of it's non-human approach. It doesn't replace them, but is a reasonable complement, thanks to the limited work needed to put the procedure in place.<br /> <br /> == Fuzzers from OWASP ==<br /> <br /> Fuzzing with WebScarab [http://www.owasp.org/index.php/Fuzzing_with_WebScarab]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br /> <br /> JBroFuzz [http://www.owasp.org/index.php/JBroFuzz]: a stateless network protocol fuzzer<br /> <br /> WSFuzzer [http://www.owasp.org/index.php/WSFuzzer]: real-world manual SOAP pen testing tool<br /> <br /> == Technical resources on OWASP ==<br /> <br /> Fuzzing vectors [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors]<br /> <br /> == Sources ==<br /> <br /> Wikipedia article [http://en.wikipedia.org/wiki/Fuzz_testing]<br /> <br /> Fuzzing-related papers [http://www.threatmind.net/secwiki/FuzzingPapers]<br /> <br /> == Fuzzing tools ==<br /> <br /> The ultimate fuzzers list @ infosec [http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html]<br /> <br /> Another list @ hacksafe<br /> [http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/]<br /> <br /> The fuzzing mailing list [http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing]<br /> <br /> == Commercial products ==<br /> <br /> Codenomicon's product suite: [http://www.codenomicon.com/products/all.shtml]</div>

Fthiery https://wiki.owasp.org/index.php?title=Fuzzing&diff=14239 2006-12-12T10:14:15Z

<p>Fthiery: /* History */</p> <hr /> <div>''Fuzz testing'' or ''Fuzzing'' is a Black Box software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection in an automated fashion.<br /> <br /> == A trivial example: ==<br /> <br /> Lets's consider an integer in a program, which stores the result of a user's choice between 3 questions. When the user picks one, the choice will be 0, 1 or 2. Which makes three practical cases. But what if we transmit 3, or 255 ? We can, because integers are stored a static size variable. If the default switch case hasn't been implemented securely, the program may crash and lead to &quot;classical&quot; security issues: (un)exploitable buffer overflows, DoS, ...<br /> <br /> Fuzzing is the art of automatic bug finding, and it's role is to find software implementation faults, and identify them if possible.<br /> <br /> == History ==<br /> <br /> Fuzz testing was developed at the University of Wisconsin Madison in 1989 by Professor Barton Miller and his students. Their (continued) work can be found at http://www.cs.wisc.edu/~bart/fuzz/ ; it's mainly oriented towards command-line and UI fuzzing.<br /> <br /> == Fuzzer implementations ==<br /> <br /> A fuzzer is a program which injects automatically semi-random data into a program/stack and detect bugs.<br /> The data-generation part is made of generators, and vulnerability identification relies on debugging tools.<br /> <br /> == Comparison with cryptanalysis ==<br /> <br /> The number of possible tryable solutions is ''the explorable solutions space''. The aim of cryptanalysis is to reduce this space, which means finding a way of having less keys to try than pure bruteforce to decrypt something. <br /> <br /> Most of the fuzzers are:<br /> <br /> - protocol/file-format dependant<br /> <br /> - data-type dependant<br /> <br /> Why? <br /> <br /> Because a program only understands structured-enough data. If you connect to a web server in a raw way, it will only respond to listed commands such as GET (or eventually crash). It will take less time to start the string with &quot;GET &quot;, and fuzz the rest, but the drawback is that you'll skip all the tests on the first verb.<br /> <br /> In this regard, Fuzzers try to reduce the number of unuseful tests, i.e. the values we already know that there's little chance they'll work: you reduce impredictibility, in favor of speed.<br /> <br /> == Attack types ==<br /> <br /> A fuzzer would try combinations of attacks on:<br /> <br /> - numbers (signed/unsigned integers/float...)<br /> <br /> - chars (urls, command-line inputs)<br /> <br /> - metadata : user-input text (id3 tag)<br /> <br /> - pure binary sequences<br /> <br /> A common approach to fuzzing is to define lists of &quot;known-to-be-dangerous values&quot; (''fuzz vectors'') for each type, and to inject them or recombinations.<br /> <br /> - for integers: zero, possibly negative or very big numbers<br /> <br /> - for chars: escaped, interpretable characters / instructions (ex: For SQL Requests, quotes / commands...)<br /> <br /> - for binary: random ones<br /> <br /> Please refer to OWASP's Fuzz Vector's resource[http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors] for real-life examples.<br /> <br /> Protocols and file formats imply norms, which are sometimes blurry, very complicated or badly implemented : that's why developers sometimes mess up in the implementation process (because of time/cost constraints). That's why it can be interesting to take the opposite approach: take a norm, look at all mandatory features and constraints, and try all of them; forbidden/reserved values, linked parameters, field sizes. That would be ''hand-fuzzing''.<br /> <br /> <br /> == Application fuzzing ==<br /> <br /> Whatever the fuzzed system is, the attack vectors are within it's I/O. For a desktop app:<br /> - the UI (testing all the buttons sequences / text inputs)<br /> - the command-line options<br /> - the import/export capabilities (see file format fuzzing below)<br /> <br /> For a web app, urls and forms are the inputs, and eventually (especially for user-generated content websites) media files.<br /> <br /> == Protocol fuzzing ==<br /> <br /> A protocol fuzzer sends forged packets to the tested application, or eventually acts as a proxy, modifying requests on the fly and replaying them.<br /> <br /> == File format fuzzing ==<br /> <br /> A file format fuzzer generates multiple malformed samples, and opens them sequentially. When the program crashes, debug information is kept for further investigation.<br /> <br /> One can attack:<br /> <br /> - the parser layer (container layer): file format constraints, structure, conventions, field sizes, flags, ...<br /> <br /> - the codec/application layer: lower-level attacks, aiming at the program's deeper internals<br /> <br /> Example found vulnerability: Microsoft's JPEG GDI+ vulnerability was a zero sized comment field, without content.<br /> <br /> A generic file format fuzzer is Ilja van Sprundel's mangle.c[http://www.digitaldwarf.be/products/mangle.c]; &quot;it's usage is very simple, it takes a filename and headersize as input. it will then change approximatly between 0 and 10% of the header with random bytes.&quot;<br /> <br /> One may use tools like Hachoir[http://hachoir.org/] as a generic parser for file format fuzzers development.<br /> <br /> == Fuzzers advantages ==<br /> <br /> ''The great advantage of fuzz testing is that the test design is extremely simple, and free of preconceptions about system behavior'' (from Wikipedia [http://en.wikipedia.org/wiki/Fuzz_testing]).<br /> <br /> The systematical/random approach allows this method to find bugs that would have often been missed by human eyes. Plus, when the tested system is totally closed (say, a SIP phone), fuzzing is one of the only means of reviewing it's quality.<br /> <br /> == Fuzzers limitations ==<br /> <br /> Fuzzers usually tend to try one-level-imbrication-level attacks, which means changing only one parameter at a time. Therefore, fuzzing tools can detect trivial errors, but are less gifted with deep ones.<br /> <br /> Another problem is that when you do some black-box-testing, you usually attack a closed system, which increases difficulty to evaluate the dangerosity/impact of the found vulnerability.<br /> <br /> == Why Fuzz? ==<br /> <br /> The purpose of fuzzing relies on the assumption that there are bugs within every program, which are waiting to be discovered. Therefore, a systematical approach should find them sooner or later.<br /> <br /> Fuzzing can add another point of view to classical software testing techniques (hand code review, debugging) because of it's non-human approach. It doesn't replace them, but is a reasonable complement, thanks to the limited work needed to put the procedure in place.<br /> <br /> == Fuzzers from OWASP ==<br /> <br /> Fuzzing with WebScarab [http://www.owasp.org/index.php/Fuzzing_with_WebScarab]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br /> <br /> JBroFuzz [http://www.owasp.org/index.php/JBroFuzz]: a stateless network protocol fuzzer<br /> <br /> WSFuzzer [http://www.owasp.org/index.php/WSFuzzer]: real-world manual SOAP pen testing tool<br /> <br /> == Technical resources on OWASP ==<br /> <br /> Fuzzing vectors [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors]<br /> <br /> == Sources ==<br /> <br /> Wikipedia article [http://en.wikipedia.org/wiki/Fuzz_testing]<br /> <br /> Fuzzing-related papers [http://www.threatmind.net/secwiki/FuzzingPapers]<br /> <br /> == Fuzzing tools ==<br /> <br /> The ultimate fuzzers list @ infosec [http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html]<br /> <br /> Another list @ hacksafe<br /> [http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/]<br /> <br /> The fuzzing mailing list [http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing]<br /> <br /> == Commercial products ==<br /> <br /> Codenomicon's product suite: [http://www.codenomicon.com/products/all.shtml]</div>

Fthiery https://wiki.owasp.org/index.php?title=Fuzzing&diff=14238 2006-12-12T10:13:37Z

<p>Fthiery: </p> <hr /> <div>''Fuzz testing'' or ''Fuzzing'' is a Black Box software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection in an automated fashion.<br /> <br /> == A trivial example: ==<br /> <br /> Lets's consider an integer in a program, which stores the result of a user's choice between 3 questions. When the user picks one, the choice will be 0, 1 or 2. Which makes three practical cases. But what if we transmit 3, or 255 ? We can, because integers are stored a static size variable. If the default switch case hasn't been implemented securely, the program may crash and lead to &quot;classical&quot; security issues: (un)exploitable buffer overflows, DoS, ...<br /> <br /> Fuzzing is the art of automatic bug finding, and it's role is to find software implementation faults, and identify them if possible.<br /> <br /> == History ==<br /> <br /> Fuzz testing was developed at the University of Wisconsin Madison in 1989 by Professor Barton Miller and his students. Their (continued) work can be found at http://www.cs.wisc.edu/~bart/fuzz/<br /> <br /> == Fuzzer implementations ==<br /> <br /> A fuzzer is a program which injects automatically semi-random data into a program/stack and detect bugs.<br /> The data-generation part is made of generators, and vulnerability identification relies on debugging tools.<br /> <br /> == Comparison with cryptanalysis ==<br /> <br /> The number of possible tryable solutions is ''the explorable solutions space''. The aim of cryptanalysis is to reduce this space, which means finding a way of having less keys to try than pure bruteforce to decrypt something. <br /> <br /> Most of the fuzzers are:<br /> <br /> - protocol/file-format dependant<br /> <br /> - data-type dependant<br /> <br /> Why? <br /> <br /> Because a program only understands structured-enough data. If you connect to a web server in a raw way, it will only respond to listed commands such as GET (or eventually crash). It will take less time to start the string with &quot;GET &quot;, and fuzz the rest, but the drawback is that you'll skip all the tests on the first verb.<br /> <br /> In this regard, Fuzzers try to reduce the number of unuseful tests, i.e. the values we already know that there's little chance they'll work: you reduce impredictibility, in favor of speed.<br /> <br /> == Attack types ==<br /> <br /> A fuzzer would try combinations of attacks on:<br /> <br /> - numbers (signed/unsigned integers/float...)<br /> <br /> - chars (urls, command-line inputs)<br /> <br /> - metadata : user-input text (id3 tag)<br /> <br /> - pure binary sequences<br /> <br /> A common approach to fuzzing is to define lists of &quot;known-to-be-dangerous values&quot; (''fuzz vectors'') for each type, and to inject them or recombinations.<br /> <br /> - for integers: zero, possibly negative or very big numbers<br /> <br /> - for chars: escaped, interpretable characters / instructions (ex: For SQL Requests, quotes / commands...)<br /> <br /> - for binary: random ones<br /> <br /> Please refer to OWASP's Fuzz Vector's resource[http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors] for real-life examples.<br /> <br /> Protocols and file formats imply norms, which are sometimes blurry, very complicated or badly implemented : that's why developers sometimes mess up in the implementation process (because of time/cost constraints). That's why it can be interesting to take the opposite approach: take a norm, look at all mandatory features and constraints, and try all of them; forbidden/reserved values, linked parameters, field sizes. That would be ''hand-fuzzing''.<br /> <br /> <br /> == Application fuzzing ==<br /> <br /> Whatever the fuzzed system is, the attack vectors are within it's I/O. For a desktop app:<br /> - the UI (testing all the buttons sequences / text inputs)<br /> - the command-line options<br /> - the import/export capabilities (see file format fuzzing below)<br /> <br /> For a web app, urls and forms are the inputs, and eventually (especially for user-generated content websites) media files.<br /> <br /> == Protocol fuzzing ==<br /> <br /> A protocol fuzzer sends forged packets to the tested application, or eventually acts as a proxy, modifying requests on the fly and replaying them.<br /> <br /> == File format fuzzing ==<br /> <br /> A file format fuzzer generates multiple malformed samples, and opens them sequentially. When the program crashes, debug information is kept for further investigation.<br /> <br /> One can attack:<br /> <br /> - the parser layer (container layer): file format constraints, structure, conventions, field sizes, flags, ...<br /> <br /> - the codec/application layer: lower-level attacks, aiming at the program's deeper internals<br /> <br /> Example found vulnerability: Microsoft's JPEG GDI+ vulnerability was a zero sized comment field, without content.<br /> <br /> A generic file format fuzzer is Ilja van Sprundel's mangle.c[http://www.digitaldwarf.be/products/mangle.c]; &quot;it's usage is very simple, it takes a filename and headersize as input. it will then change approximatly between 0 and 10% of the header with random bytes.&quot;<br /> <br /> One may use tools like Hachoir[http://hachoir.org/] as a generic parser for file format fuzzers development.<br /> <br /> == Fuzzers advantages ==<br /> <br /> ''The great advantage of fuzz testing is that the test design is extremely simple, and free of preconceptions about system behavior'' (from Wikipedia [http://en.wikipedia.org/wiki/Fuzz_testing]).<br /> <br /> The systematical/random approach allows this method to find bugs that would have often been missed by human eyes. Plus, when the tested system is totally closed (say, a SIP phone), fuzzing is one of the only means of reviewing it's quality.<br /> <br /> == Fuzzers limitations ==<br /> <br /> Fuzzers usually tend to try one-level-imbrication-level attacks, which means changing only one parameter at a time. Therefore, fuzzing tools can detect trivial errors, but are less gifted with deep ones.<br /> <br /> Another problem is that when you do some black-box-testing, you usually attack a closed system, which increases difficulty to evaluate the dangerosity/impact of the found vulnerability.<br /> <br /> == Why Fuzz? ==<br /> <br /> The purpose of fuzzing relies on the assumption that there are bugs within every program, which are waiting to be discovered. Therefore, a systematical approach should find them sooner or later.<br /> <br /> Fuzzing can add another point of view to classical software testing techniques (hand code review, debugging) because of it's non-human approach. It doesn't replace them, but is a reasonable complement, thanks to the limited work needed to put the procedure in place.<br /> <br /> == Fuzzers from OWASP ==<br /> <br /> Fuzzing with WebScarab [http://www.owasp.org/index.php/Fuzzing_with_WebScarab]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br /> <br /> JBroFuzz [http://www.owasp.org/index.php/JBroFuzz]: a stateless network protocol fuzzer<br /> <br /> WSFuzzer [http://www.owasp.org/index.php/WSFuzzer]: real-world manual SOAP pen testing tool<br /> <br /> == Technical resources on OWASP ==<br /> <br /> Fuzzing vectors [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors]<br /> <br /> == Sources ==<br /> <br /> Wikipedia article [http://en.wikipedia.org/wiki/Fuzz_testing]<br /> <br /> Fuzzing-related papers [http://www.threatmind.net/secwiki/FuzzingPapers]<br /> <br /> == Fuzzing tools ==<br /> <br /> The ultimate fuzzers list @ infosec [http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html]<br /> <br /> Another list @ hacksafe<br /> [http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/]<br /> <br /> The fuzzing mailing list [http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing]<br /> <br /> == Commercial products ==<br /> <br /> Codenomicon's product suite: [http://www.codenomicon.com/products/all.shtml]</div>

Fthiery https://wiki.owasp.org/index.php?title=Fuzzing&diff=14237 2006-12-12T09:45:23Z

<p>Fthiery: /* History */</p> <hr /> <div>''Fuzz testing'' or ''Fuzzing'' is a Black Box software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection in an automated fashion.<br /> <br /> == A trivial example: ==<br /> <br /> Lets's consider an integer in a program, which stores the result of a user's choice between 3 questions. When the user picks one, the choice will be 0, 1 or 2. Which makes three practical cases. But what if we transmit 3, or 255 ? We can, because integers are stored a static size variable. If the default switch case hasn't been implemented securely, the program may crash and lead to &quot;classical&quot; security issues: (un)exploitable buffer overflows, DoS, ...<br /> <br /> Fuzzing is the art of automatic bug finding, and it's role is to find software implementation faults, and identify them if possible.<br /> <br /> == History ==<br /> <br /> Fuzz testing was developed at the University of Wisconsin Madison in 1989 by Professor Barton Miller and his students. Their (continued) work can be found at http://www.cs.wisc.edu/~bart/fuzz/<br /> <br /> == Fuzzer implementations ==<br /> <br /> A fuzzer is a program which injects automatically semi-random data into a program/stack and detect bugs.<br /> The data-generation part is made of generators, and vulnerability identification relies on debugging tools.<br /> <br /> == Comparison with cryptanalysis ==<br /> <br /> The number of possible tryable solutions is ''the explorable solutions space''. The aim of cryptanalysis is to reduce this space, which means finding a way of having less keys to try than pure bruteforce to decrypt something. <br /> <br /> Most of the fuzzers are:<br /> <br /> - protocol/file-format dependant<br /> <br /> - data-type dependant<br /> <br /> Why? <br /> <br /> Because a program only understands structured-enough data. If you connect to a web server in a raw way, it will only respond to listed commands such as GET (or eventually crash). It will take less time to start the string with &quot;GET &quot;, and fuzz the rest, but the drawback is that you'll skip all the tests on the first verb.<br /> <br /> In this regard, Fuzzers try to reduce the number of unuseful tests, i.e. the values we already know that there's little chance they'll work: you reduce impredictibility, in favor of speed.<br /> <br /> == Attack types ==<br /> <br /> A fuzzer would try combinations of attacks on:<br /> <br /> - numbers (signed/unsigned integers/float...)<br /> <br /> - chars (urls, command-line inputs)<br /> <br /> - metadata : user-input text (id3 tag)<br /> <br /> - pure binary sequences<br /> <br /> A common approach to fuzzing is to define lists of &quot;known-to-be-dangerous values&quot; (''fuzz vectors'') for each type, and to inject them or recombinations.<br /> <br /> - for integers: zero, possibly negative or very big numbers<br /> <br /> - for chars: escaped, interpretable characters / instructions (ex: For SQL Requests, quotes / commands...)<br /> <br /> - for binary: random ones<br /> <br /> Please refer to OWASP's Fuzz Vector's resource[http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors] for real-life examples.<br /> <br /> Protocols and file formats imply norms, which are sometimes blurry, very complicated or badly implemented : that's why developers sometimes mess up in the implementation process (because of time/cost constraints). That's why it can be interesting to take the opposite approach: take a norm, look at all mandatory features and constraints, and try all of them; forbidden/reserved values, linked parameters, field sizes. That would be ''hand-fuzzing''.<br /> <br /> == Protocol fuzzing ==<br /> <br /> A protocol fuzzer sends forged packets to the tested application, or eventually acts as a proxy, modifying requests on the fly and replaying them.<br /> <br /> == File format fuzzing ==<br /> <br /> A file format fuzzer generates multiple malformed samples, and opens them sequentially. When the program crashes, debug information is kept for further investigation.<br /> <br /> One can attack:<br /> <br /> - the parser layer (container layer): file format constraints, structure, conventions, field sizes, flags, ...<br /> <br /> - the codec/application layer: lower-level attacks, aiming at the program's deeper internals<br /> <br /> Example found vulnerability: Microsoft's JPEG GDI+ vulnerability was a zero sized comment field, without content.<br /> <br /> A generic file format fuzzer is Ilja van Sprundel's mangle.c[http://www.digitaldwarf.be/products/mangle.c]; &quot;it's usage is very simple, it takes a filename and headersize as input. it will then change approximatly between 0 and 10% of the header with random bytes.&quot;<br /> <br /> One may use tools like Hachoir[http://hachoir.org/] as a generic parser for file format fuzzers development.<br /> <br /> == Fuzzers advantages ==<br /> <br /> ''The great advantage of fuzz testing is that the test design is extremely simple, and free of preconceptions about system behavior'' (from Wikipedia [http://en.wikipedia.org/wiki/Fuzz_testing]).<br /> <br /> The systematical/random approach allows this method to find bugs that would have often been missed by human eyes. Plus, when the tested system is totally closed (say, a SIP phone), fuzzing is one of the only means of reviewing it's quality.<br /> <br /> == Fuzzers limitations ==<br /> <br /> Fuzzers usually tend to try one-level-imbrication-level attacks, which means changing only one parameter at a time. Therefore, fuzzing tools can detect trivial errors, but are less gifted with deep ones.<br /> <br /> Another problem is that when you do some black-box-testing, you usually attack a closed system, which increases difficulty to evaluate the dangerosity/impact of the found vulnerability.<br /> <br /> == Why Fuzz? ==<br /> <br /> The purpose of fuzzing relies on the assumption that there are bugs within every program, which are waiting to be discovered. Therefore, a systematical approach should find them sooner or later.<br /> <br /> Fuzzing can add another point of view to classical software testing techniques (hand code review, debugging) because of it's non-human approach. It doesn't replace them, but is a reasonable complement, thanks to the limited work needed to put the procedure in place.<br /> <br /> == Fuzzers from OWASP ==<br /> <br /> Fuzzing with WebScarab [http://www.owasp.org/index.php/Fuzzing_with_WebScarab]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br /> <br /> JBroFuzz [http://www.owasp.org/index.php/JBroFuzz]: a stateless network protocol fuzzer<br /> <br /> WSFuzzer [http://www.owasp.org/index.php/WSFuzzer]: real-world manual SOAP pen testing tool<br /> <br /> == Technical resources on OWASP ==<br /> <br /> Fuzzing vectors [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors]<br /> <br /> == Sources ==<br /> <br /> Wikipedia article [http://en.wikipedia.org/wiki/Fuzz_testing]<br /> <br /> Fuzzing-related papers [http://www.threatmind.net/secwiki/FuzzingPapers]<br /> <br /> == Fuzzing tools ==<br /> <br /> The ultimate fuzzers list @ infosec [http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html]<br /> <br /> Another list @ hacksafe<br /> [http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/]<br /> <br /> The fuzzing mailing list [http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing]<br /> <br /> == Commercial products ==<br /> <br /> Codenomicon's product suite: [http://www.codenomicon.com/products/all.shtml]</div>

Fthiery https://wiki.owasp.org/index.php?title=Fuzzing&diff=14235 2006-12-12T09:39:19Z

<p>Fthiery: /* File format fuzzing */</p> <hr /> <div>''Fuzz testing'' or ''Fuzzing'' is a Black Box software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection in an automated fashion.<br /> <br /> == A trivial example: ==<br /> <br /> Lets's consider an integer in a program, which stores the result of a user's choice between 3 questions. When the user picks one, the choice will be 0, 1 or 2. Which makes three practical cases. But what if we transmit 3, or 255 ? We can, because integers are stored a static size variable. If the default switch case hasn't been implemented securely, the program may crash and lead to &quot;classical&quot; security issues: (un)exploitable buffer overflows, DoS, ...<br /> <br /> Fuzzing is the art of automatic bug finding, and it's role is to find software implementation faults, and identify them if possible.<br /> <br /> == History ==<br /> <br /> Fuzz testing was developed at the University of Wisconsin Madison in 1989 by Professor Barton Miller and his students. Their work can be found at http://www.cs.wisc.edu/~bart/fuzz/<br /> <br /> == Fuzzer implementations ==<br /> <br /> A fuzzer is a program which injects automatically semi-random data into a program/stack and detect bugs.<br /> The data-generation part is made of generators, and vulnerability identification relies on debugging tools.<br /> <br /> == Comparison with cryptanalysis ==<br /> <br /> The number of possible tryable solutions is ''the explorable solutions space''. The aim of cryptanalysis is to reduce this space, which means finding a way of having less keys to try than pure bruteforce to decrypt something. <br /> <br /> Most of the fuzzers are:<br /> <br /> - protocol/file-format dependant<br /> <br /> - data-type dependant<br /> <br /> Why? <br /> <br /> Because a program only understands structured-enough data. If you connect to a web server in a raw way, it will only respond to listed commands such as GET (or eventually crash). It will take less time to start the string with &quot;GET &quot;, and fuzz the rest, but the drawback is that you'll skip all the tests on the first verb.<br /> <br /> In this regard, Fuzzers try to reduce the number of unuseful tests, i.e. the values we already know that there's little chance they'll work: you reduce impredictibility, in favor of speed.<br /> <br /> == Attack types ==<br /> <br /> A fuzzer would try combinations of attacks on:<br /> <br /> - numbers (signed/unsigned integers/float...)<br /> <br /> - chars (urls, command-line inputs)<br /> <br /> - metadata : user-input text (id3 tag)<br /> <br /> - pure binary sequences<br /> <br /> A common approach to fuzzing is to define lists of &quot;known-to-be-dangerous values&quot; (''fuzz vectors'') for each type, and to inject them or recombinations.<br /> <br /> - for integers: zero, possibly negative or very big numbers<br /> <br /> - for chars: escaped, interpretable characters / instructions (ex: For SQL Requests, quotes / commands...)<br /> <br /> - for binary: random ones<br /> <br /> Please refer to OWASP's Fuzz Vector's resource[http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors] for real-life examples.<br /> <br /> Protocols and file formats imply norms, which are sometimes blurry, very complicated or badly implemented : that's why developers sometimes mess up in the implementation process (because of time/cost constraints). That's why it can be interesting to take the opposite approach: take a norm, look at all mandatory features and constraints, and try all of them; forbidden/reserved values, linked parameters, field sizes. That would be ''hand-fuzzing''.<br /> <br /> == Protocol fuzzing ==<br /> <br /> A protocol fuzzer sends forged packets to the tested application, or eventually acts as a proxy, modifying requests on the fly and replaying them.<br /> <br /> == File format fuzzing ==<br /> <br /> A file format fuzzer generates multiple malformed samples, and opens them sequentially. When the program crashes, debug information is kept for further investigation.<br /> <br /> One can attack:<br /> <br /> - the parser layer (container layer): file format constraints, structure, conventions, field sizes, flags, ...<br /> <br /> - the codec/application layer: lower-level attacks, aiming at the program's deeper internals<br /> <br /> Example found vulnerability: Microsoft's JPEG GDI+ vulnerability was a zero sized comment field, without content.<br /> <br /> A generic file format fuzzer is Ilja van Sprundel's mangle.c[http://www.digitaldwarf.be/products/mangle.c]; &quot;it's usage is very simple, it takes a filename and headersize as input. it will then change approximatly between 0 and 10% of the header with random bytes.&quot;<br /> <br /> One may use tools like Hachoir[http://hachoir.org/] as a generic parser for file format fuzzers development.<br /> <br /> == Fuzzers advantages ==<br /> <br /> ''The great advantage of fuzz testing is that the test design is extremely simple, and free of preconceptions about system behavior'' (from Wikipedia [http://en.wikipedia.org/wiki/Fuzz_testing]).<br /> <br /> The systematical/random approach allows this method to find bugs that would have often been missed by human eyes. Plus, when the tested system is totally closed (say, a SIP phone), fuzzing is one of the only means of reviewing it's quality.<br /> <br /> == Fuzzers limitations ==<br /> <br /> Fuzzers usually tend to try one-level-imbrication-level attacks, which means changing only one parameter at a time. Therefore, fuzzing tools can detect trivial errors, but are less gifted with deep ones.<br /> <br /> Another problem is that when you do some black-box-testing, you usually attack a closed system, which increases difficulty to evaluate the dangerosity/impact of the found vulnerability.<br /> <br /> == Why Fuzz? ==<br /> <br /> The purpose of fuzzing relies on the assumption that there are bugs within every program, which are waiting to be discovered. Therefore, a systematical approach should find them sooner or later.<br /> <br /> Fuzzing can add another point of view to classical software testing techniques (hand code review, debugging) because of it's non-human approach. It doesn't replace them, but is a reasonable complement, thanks to the limited work needed to put the procedure in place.<br /> <br /> == Fuzzers from OWASP ==<br /> <br /> Fuzzing with WebScarab [http://www.owasp.org/index.php/Fuzzing_with_WebScarab]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br /> <br /> JBroFuzz [http://www.owasp.org/index.php/JBroFuzz]: a stateless network protocol fuzzer<br /> <br /> WSFuzzer [http://www.owasp.org/index.php/WSFuzzer]: real-world manual SOAP pen testing tool<br /> <br /> == Technical resources on OWASP ==<br /> <br /> Fuzzing vectors [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors]<br /> <br /> == Sources ==<br /> <br /> Wikipedia article [http://en.wikipedia.org/wiki/Fuzz_testing]<br /> <br /> Fuzzing-related papers [http://www.threatmind.net/secwiki/FuzzingPapers]<br /> <br /> == Fuzzing tools ==<br /> <br /> The ultimate fuzzers list @ infosec [http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html]<br /> <br /> Another list @ hacksafe<br /> [http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/]<br /> <br /> The fuzzing mailing list [http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing]<br /> <br /> == Commercial products ==<br /> <br /> Codenomicon's product suite: [http://www.codenomicon.com/products/all.shtml]</div>

Fthiery https://wiki.owasp.org/index.php?title=Fuzzing&diff=14234 2006-12-12T09:39:03Z

<p>Fthiery: /* File format fuzzing */</p> <hr /> <div>''Fuzz testing'' or ''Fuzzing'' is a Black Box software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection in an automated fashion.<br /> <br /> == A trivial example: ==<br /> <br /> Lets's consider an integer in a program, which stores the result of a user's choice between 3 questions. When the user picks one, the choice will be 0, 1 or 2. Which makes three practical cases. But what if we transmit 3, or 255 ? We can, because integers are stored a static size variable. If the default switch case hasn't been implemented securely, the program may crash and lead to &quot;classical&quot; security issues: (un)exploitable buffer overflows, DoS, ...<br /> <br /> Fuzzing is the art of automatic bug finding, and it's role is to find software implementation faults, and identify them if possible.<br /> <br /> == History ==<br /> <br /> Fuzz testing was developed at the University of Wisconsin Madison in 1989 by Professor Barton Miller and his students. Their work can be found at http://www.cs.wisc.edu/~bart/fuzz/<br /> <br /> == Fuzzer implementations ==<br /> <br /> A fuzzer is a program which injects automatically semi-random data into a program/stack and detect bugs.<br /> The data-generation part is made of generators, and vulnerability identification relies on debugging tools.<br /> <br /> == Comparison with cryptanalysis ==<br /> <br /> The number of possible tryable solutions is ''the explorable solutions space''. The aim of cryptanalysis is to reduce this space, which means finding a way of having less keys to try than pure bruteforce to decrypt something. <br /> <br /> Most of the fuzzers are:<br /> <br /> - protocol/file-format dependant<br /> <br /> - data-type dependant<br /> <br /> Why? <br /> <br /> Because a program only understands structured-enough data. If you connect to a web server in a raw way, it will only respond to listed commands such as GET (or eventually crash). It will take less time to start the string with &quot;GET &quot;, and fuzz the rest, but the drawback is that you'll skip all the tests on the first verb.<br /> <br /> In this regard, Fuzzers try to reduce the number of unuseful tests, i.e. the values we already know that there's little chance they'll work: you reduce impredictibility, in favor of speed.<br /> <br /> == Attack types ==<br /> <br /> A fuzzer would try combinations of attacks on:<br /> <br /> - numbers (signed/unsigned integers/float...)<br /> <br /> - chars (urls, command-line inputs)<br /> <br /> - metadata : user-input text (id3 tag)<br /> <br /> - pure binary sequences<br /> <br /> A common approach to fuzzing is to define lists of &quot;known-to-be-dangerous values&quot; (''fuzz vectors'') for each type, and to inject them or recombinations.<br /> <br /> - for integers: zero, possibly negative or very big numbers<br /> <br /> - for chars: escaped, interpretable characters / instructions (ex: For SQL Requests, quotes / commands...)<br /> <br /> - for binary: random ones<br /> <br /> Please refer to OWASP's Fuzz Vector's resource[http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors] for real-life examples.<br /> <br /> Protocols and file formats imply norms, which are sometimes blurry, very complicated or badly implemented : that's why developers sometimes mess up in the implementation process (because of time/cost constraints). That's why it can be interesting to take the opposite approach: take a norm, look at all mandatory features and constraints, and try all of them; forbidden/reserved values, linked parameters, field sizes. That would be ''hand-fuzzing''.<br /> <br /> == Protocol fuzzing ==<br /> <br /> A protocol fuzzer sends forged packets to the tested application, or eventually acts as a proxy, modifying requests on the fly and replaying them.<br /> <br /> == File format fuzzing ==<br /> <br /> A file format fuzzer generates multiple malformed samples, and opens them sequentially. When the program crashes, debug information is kept for further investigation.<br /> <br /> One can attack:<br /> <br /> - the parser layer (container layer): file format constraints, structure, conventions, field sizes, flags, ...<br /> <br /> - the codec/application layer: lower-level attacks, aiming at the programm's deeper internals<br /> <br /> Example found vulnerability: Microsoft's JPEG GDI+ vulnerability was a zero sized comment field, without content.<br /> <br /> A generic file format fuzzer is Ilja van Sprundel's mangle.c[http://www.digitaldwarf.be/products/mangle.c]; &quot;it's usage is very simple, it takes a filename and headersize as input. it will then change approximatly between 0 and 10% of the header with random bytes.&quot;<br /> <br /> One may use tools like Hachoir[http://hachoir.org/] as a generic parser for file format fuzzers development.<br /> <br /> == Fuzzers advantages ==<br /> <br /> ''The great advantage of fuzz testing is that the test design is extremely simple, and free of preconceptions about system behavior'' (from Wikipedia [http://en.wikipedia.org/wiki/Fuzz_testing]).<br /> <br /> The systematical/random approach allows this method to find bugs that would have often been missed by human eyes. Plus, when the tested system is totally closed (say, a SIP phone), fuzzing is one of the only means of reviewing it's quality.<br /> <br /> == Fuzzers limitations ==<br /> <br /> Fuzzers usually tend to try one-level-imbrication-level attacks, which means changing only one parameter at a time. Therefore, fuzzing tools can detect trivial errors, but are less gifted with deep ones.<br /> <br /> Another problem is that when you do some black-box-testing, you usually attack a closed system, which increases difficulty to evaluate the dangerosity/impact of the found vulnerability.<br /> <br /> == Why Fuzz? ==<br /> <br /> The purpose of fuzzing relies on the assumption that there are bugs within every program, which are waiting to be discovered. Therefore, a systematical approach should find them sooner or later.<br /> <br /> Fuzzing can add another point of view to classical software testing techniques (hand code review, debugging) because of it's non-human approach. It doesn't replace them, but is a reasonable complement, thanks to the limited work needed to put the procedure in place.<br /> <br /> == Fuzzers from OWASP ==<br /> <br /> Fuzzing with WebScarab [http://www.owasp.org/index.php/Fuzzing_with_WebScarab]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br /> <br /> JBroFuzz [http://www.owasp.org/index.php/JBroFuzz]: a stateless network protocol fuzzer<br /> <br /> WSFuzzer [http://www.owasp.org/index.php/WSFuzzer]: real-world manual SOAP pen testing tool<br /> <br /> == Technical resources on OWASP ==<br /> <br /> Fuzzing vectors [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors]<br /> <br /> == Sources ==<br /> <br /> Wikipedia article [http://en.wikipedia.org/wiki/Fuzz_testing]<br /> <br /> Fuzzing-related papers [http://www.threatmind.net/secwiki/FuzzingPapers]<br /> <br /> == Fuzzing tools ==<br /> <br /> The ultimate fuzzers list @ infosec [http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html]<br /> <br /> Another list @ hacksafe<br /> [http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/]<br /> <br /> The fuzzing mailing list [http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing]<br /> <br /> == Commercial products ==<br /> <br /> Codenomicon's product suite: [http://www.codenomicon.com/products/all.shtml]</div>

Fthiery https://wiki.owasp.org/index.php?title=Fuzzing&diff=14233 2006-12-12T09:38:33Z

<p>Fthiery: </p> <hr /> <div>''Fuzz testing'' or ''Fuzzing'' is a Black Box software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection in an automated fashion.<br /> <br /> == A trivial example: ==<br /> <br /> Lets's consider an integer in a program, which stores the result of a user's choice between 3 questions. When the user picks one, the choice will be 0, 1 or 2. Which makes three practical cases. But what if we transmit 3, or 255 ? We can, because integers are stored a static size variable. If the default switch case hasn't been implemented securely, the program may crash and lead to &quot;classical&quot; security issues: (un)exploitable buffer overflows, DoS, ...<br /> <br /> Fuzzing is the art of automatic bug finding, and it's role is to find software implementation faults, and identify them if possible.<br /> <br /> == History ==<br /> <br /> Fuzz testing was developed at the University of Wisconsin Madison in 1989 by Professor Barton Miller and his students. Their work can be found at http://www.cs.wisc.edu/~bart/fuzz/<br /> <br /> == Fuzzer implementations ==<br /> <br /> A fuzzer is a program which injects automatically semi-random data into a program/stack and detect bugs.<br /> The data-generation part is made of generators, and vulnerability identification relies on debugging tools.<br /> <br /> == Comparison with cryptanalysis ==<br /> <br /> The number of possible tryable solutions is ''the explorable solutions space''. The aim of cryptanalysis is to reduce this space, which means finding a way of having less keys to try than pure bruteforce to decrypt something. <br /> <br /> Most of the fuzzers are:<br /> <br /> - protocol/file-format dependant<br /> <br /> - data-type dependant<br /> <br /> Why? <br /> <br /> Because a program only understands structured-enough data. If you connect to a web server in a raw way, it will only respond to listed commands such as GET (or eventually crash). It will take less time to start the string with &quot;GET &quot;, and fuzz the rest, but the drawback is that you'll skip all the tests on the first verb.<br /> <br /> In this regard, Fuzzers try to reduce the number of unuseful tests, i.e. the values we already know that there's little chance they'll work: you reduce impredictibility, in favor of speed.<br /> <br /> == Attack types ==<br /> <br /> A fuzzer would try combinations of attacks on:<br /> <br /> - numbers (signed/unsigned integers/float...)<br /> <br /> - chars (urls, command-line inputs)<br /> <br /> - metadata : user-input text (id3 tag)<br /> <br /> - pure binary sequences<br /> <br /> A common approach to fuzzing is to define lists of &quot;known-to-be-dangerous values&quot; (''fuzz vectors'') for each type, and to inject them or recombinations.<br /> <br /> - for integers: zero, possibly negative or very big numbers<br /> <br /> - for chars: escaped, interpretable characters / instructions (ex: For SQL Requests, quotes / commands...)<br /> <br /> - for binary: random ones<br /> <br /> Please refer to OWASP's Fuzz Vector's resource[http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors] for real-life examples.<br /> <br /> Protocols and file formats imply norms, which are sometimes blurry, very complicated or badly implemented : that's why developers sometimes mess up in the implementation process (because of time/cost constraints). That's why it can be interesting to take the opposite approach: take a norm, look at all mandatory features and constraints, and try all of them; forbidden/reserved values, linked parameters, field sizes. That would be ''hand-fuzzing''.<br /> <br /> == Protocol fuzzing ==<br /> <br /> A protocol fuzzer sends forged packets to the tested application, or eventually acts as a proxy, modifying requests on the fly and replaying them.<br /> <br /> == File format fuzzing ==<br /> <br /> A file format fuzzer generates multiple malformed samples, and opens them sequentially. When the program crashes, debug information is kept for further investigation.<br /> <br /> One can attack:<br /> - the parser layer (container layer): file format constraints, structure, conventions, field sizes, flags, ...<br /> - the codec/application layer: lower-level attacks, aiming at the programm's deeper internals<br /> <br /> Example found vulnerability: Microsoft's JPEG GDI+ vulnerability was a zero sized comment field, without content.<br /> <br /> A generic file format fuzzer is Ilja van Sprundel's mangle.c[http://www.digitaldwarf.be/products/mangle.c]; &quot;it's usage is very simple, it takes a filename and headersize as input. it will then change approximatly between 0 and 10% of the header with random bytes.&quot;<br /> <br /> One may use tools like Hachoir[http://hachoir.org/] as a generic parser for file format fuzzers development.<br /> <br /> == Fuzzers advantages ==<br /> <br /> ''The great advantage of fuzz testing is that the test design is extremely simple, and free of preconceptions about system behavior'' (from Wikipedia [http://en.wikipedia.org/wiki/Fuzz_testing]).<br /> <br /> The systematical/random approach allows this method to find bugs that would have often been missed by human eyes. Plus, when the tested system is totally closed (say, a SIP phone), fuzzing is one of the only means of reviewing it's quality.<br /> <br /> == Fuzzers limitations ==<br /> <br /> Fuzzers usually tend to try one-level-imbrication-level attacks, which means changing only one parameter at a time. Therefore, fuzzing tools can detect trivial errors, but are less gifted with deep ones.<br /> <br /> Another problem is that when you do some black-box-testing, you usually attack a closed system, which increases difficulty to evaluate the dangerosity/impact of the found vulnerability.<br /> <br /> == Why Fuzz? ==<br /> <br /> The purpose of fuzzing relies on the assumption that there are bugs within every program, which are waiting to be discovered. Therefore, a systematical approach should find them sooner or later.<br /> <br /> Fuzzing can add another point of view to classical software testing techniques (hand code review, debugging) because of it's non-human approach. It doesn't replace them, but is a reasonable complement, thanks to the limited work needed to put the procedure in place.<br /> <br /> == Fuzzers from OWASP ==<br /> <br /> Fuzzing with WebScarab [http://www.owasp.org/index.php/Fuzzing_with_WebScarab]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br /> <br /> JBroFuzz [http://www.owasp.org/index.php/JBroFuzz]: a stateless network protocol fuzzer<br /> <br /> WSFuzzer [http://www.owasp.org/index.php/WSFuzzer]: real-world manual SOAP pen testing tool<br /> <br /> == Technical resources on OWASP ==<br /> <br /> Fuzzing vectors [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors]<br /> <br /> == Sources ==<br /> <br /> Wikipedia article [http://en.wikipedia.org/wiki/Fuzz_testing]<br /> <br /> Fuzzing-related papers [http://www.threatmind.net/secwiki/FuzzingPapers]<br /> <br /> == Fuzzing tools ==<br /> <br /> The ultimate fuzzers list @ infosec [http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html]<br /> <br /> Another list @ hacksafe<br /> [http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/]<br /> <br /> The fuzzing mailing list [http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing]<br /> <br /> == Commercial products ==<br /> <br /> Codenomicon's product suite: [http://www.codenomicon.com/products/all.shtml]</div>

Fthiery https://wiki.owasp.org/index.php?title=Fuzzing&diff=14232 2006-12-12T09:37:20Z

<p>Fthiery: /* Fuzzer implementations */</p> <hr /> <div>''Fuzz testing'' or ''Fuzzing'' is a Black Box software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection in an automated fashion.<br /> <br /> == A trivial example: ==<br /> <br /> Lets's consider an integer in a program, which stores the result of a user's choice between 3 questions. When the user picks one, the choice will be 0, 1 or 2. Which makes three practical cases. But what if we transmit 3, or 255 ? We can, because integers are stored a static size variable. If the default switch case hasn't been implemented securely, the program may crash and lead to &quot;classical&quot; security issues: (un)exploitable buffer overflows, DoS, ...<br /> <br /> Fuzzing is the art of automatic bug finding, and it's role is to find software implementation faults, and identify them if possible.<br /> <br /> == History ==<br /> <br /> Fuzz testing was developed at the University of Wisconsin Madison in 1989 by Professor Barton Miller and his students. Their work can be found at http://www.cs.wisc.edu/~bart/fuzz/<br /> <br /> == Fuzzer implementations ==<br /> <br /> A fuzzer is a program which injects automatically semi-random data into a program/stack and detect bugs.<br /> The data-generation part is made of generators, and vulnerability identification relies on debugging tools.<br /> <br /> == Comparison with cryptanalysis ==<br /> <br /> The number of possible tryable solutions is ''the explorable solutions space''. The aim of cryptanalysis is to reduce this space, which means finding a way of having less keys to try than pure bruteforce to decrypt something. <br /> <br /> Most of the fuzzers are:<br /> <br /> - protocol/file-format dependant<br /> <br /> - data-type dependant<br /> <br /> Why? <br /> <br /> Because a program only understands structured-enough data. If you connect to a web server in a raw way, it will only respond to listed commands such as GET (or eventually crash). It will take less time to start the string with &quot;GET &quot;, and fuzz the rest, but the drawback is that you'll skip all the tests on the first verb.<br /> <br /> In this regard, Fuzzers try to reduce the number of unuseful tests, i.e. the values we already know that there's little chance they'll work: you reduce impredictibility, in favor of speed.<br /> <br /> == Attack types ==<br /> <br /> A fuzzer would try combinations of attacks on:<br /> <br /> - numbers (signed/unsigned integers/float...)<br /> <br /> - chars (urls, command-line inputs)<br /> <br /> - metadata : user-input text (id3 tag)<br /> <br /> - pure binary sequences<br /> <br /> A common approach to fuzzing is to define lists of &quot;known-to-be-dangerous values&quot; (''fuzz vectors'') for each type, and to inject them or recombinations.<br /> <br /> - for integers: zero, possibly negative or very big numbers<br /> <br /> - for chars: escaped, interpretable characters / instructions (ex: For SQL Requests, quotes / commands...)<br /> <br /> - for binary: random ones<br /> <br /> Please refer to OWASP's Fuzz Vector's resource[http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors] for real-life examples.<br /> <br /> Protocols and file formats imply norms, which are sometimes blurry, very complicated or badly implemented : that's why developers sometimes mess up in the implementation process (because of time/cost constraints). That's why it can be interesting to take the opposite approach: take a norm, look at all mandatory features and constraints, and try all of them; forbidden/reserved values, linked parameters, field sizes. That would be ''hand-fuzzing''.<br /> <br /> <br /> == Protocol fuzzing ==<br /> <br /> A protocol fuzzer sends forged packets to the tested application, or eventually acts as a proxy, modifying requests on the fly and replaying them.<br /> <br /> <br /> == File format fuzzing ==<br /> <br /> A file format fuzzer generates multiple malformed samples, and opens them sequentially. When the program crashes, debug information is kept for further investigation.<br /> <br /> One can attack:<br /> - the parser layer (container layer): file format constraints, structure, conventions, field sizes, flags, ...<br /> - the codec/application layer: lower-level attacks, aiming at the programm's deeper internals<br /> <br /> Example found vulnerability: Microsoft's JPEG GDI+ vulnerability was a zero sized comment field, without content.<br /> <br /> A generic file format fuzzer is Ilja van Sprundel's mangle.c[http://www.digitaldwarf.be/products/mangle.c]; &quot;it's usage is very simple, it takes a filename and headersize as input. it will then change approximatly between 0 and 10% of the header with random bytes.&quot;<br /> <br /> One may use tools like Hachoir[http://hachoir.org/] as a generic parser for file format fuzzers development.<br /> <br /> == Fuzzers advantages ==<br /> <br /> ''The great advantage of fuzz testing is that the test design is extremely simple, and free of preconceptions about system behavior'' (from Wikipedia [http://en.wikipedia.org/wiki/Fuzz_testing]).<br /> <br /> The systematical/random approach allows this method to find bugs that would have often been missed by human eyes. Plus, when the tested system is totally closed (say, a SIP phone), fuzzing is one of the only means of reviewing it's quality.<br /> <br /> == Fuzzers limitations ==<br /> <br /> Fuzzers usually tend to try one-level-imbrication-level attacks, which means changing only one parameter at a time. Therefore, fuzzing tools can detect trivial errors, but are less gifted with deep ones.<br /> <br /> Another problem is that when you do some black-box-testing, you usually attack a closed system, which increases difficulty to evaluate the dangerosity/impact of the found vulnerability.<br /> <br /> == Why Fuzz? ==<br /> <br /> The purpose of fuzzing relies on the assumption that there are bugs within every program, which are waiting to be discovered. Therefore, a systematical approach should find them sooner or later.<br /> <br /> Fuzzing can add another point of view to classical software testing techniques (hand code review, debugging) because of it's non-human approach. It doesn't replace them, but is a reasonable complement, thanks to the limited work needed to put the procedure in place.<br /> <br /> == Fuzzers from OWASP ==<br /> <br /> Fuzzing with WebScarab [http://www.owasp.org/index.php/Fuzzing_with_WebScarab]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br /> <br /> JBroFuzz [http://www.owasp.org/index.php/JBroFuzz]: a stateless network protocol fuzzer<br /> <br /> WSFuzzer [http://www.owasp.org/index.php/WSFuzzer]: real-world manual SOAP pen testing tool<br /> <br /> == Technical resources on OWASP ==<br /> <br /> Fuzzing vectors [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors]<br /> <br /> == Sources ==<br /> <br /> Wikipedia article [http://en.wikipedia.org/wiki/Fuzz_testing]<br /> <br /> Fuzzing-related papers [http://www.threatmind.net/secwiki/FuzzingPapers]<br /> <br /> == Fuzzing tools ==<br /> <br /> The ultimate fuzzers list @ infosec [http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html]<br /> <br /> Another list @ hacksafe<br /> [http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/]<br /> <br /> The fuzzing mailing list [http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing]<br /> <br /> == Commercial products ==<br /> <br /> Codenomicon's product suite: [http://www.codenomicon.com/products/all.shtml]</div>

Fthiery https://wiki.owasp.org/index.php?title=Fuzzing&diff=14231 2006-12-12T09:36:58Z

<p>Fthiery: </p> <hr /> <div>''Fuzz testing'' or ''Fuzzing'' is a Black Box software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection in an automated fashion.<br /> <br /> == A trivial example: ==<br /> <br /> Lets's consider an integer in a program, which stores the result of a user's choice between 3 questions. When the user picks one, the choice will be 0, 1 or 2. Which makes three practical cases. But what if we transmit 3, or 255 ? We can, because integers are stored a static size variable. If the default switch case hasn't been implemented securely, the program may crash and lead to &quot;classical&quot; security issues: (un)exploitable buffer overflows, DoS, ...<br /> <br /> Fuzzing is the art of automatic bug finding, and it's role is to find software implementation faults, and identify them if possible.<br /> <br /> == History ==<br /> <br /> Fuzz testing was developed at the University of Wisconsin Madison in 1989 by Professor Barton Miller and his students. Their work can be found at http://www.cs.wisc.edu/~bart/fuzz/<br /> <br /> == Fuzzer implementations ==<br /> <br /> A fuzzer is a program which injects automatically semi-random data into a program/stack and detect bugs.<br /> The data-generation part is made of generators, and vulnerability identification relies on debugging tools.<br /> <br /> <br /> == Comparison with cryptanalysis ==<br /> <br /> The number of possible tryable solutions is ''the explorable solutions space''. The aim of cryptanalysis is to reduce this space, which means finding a way of having less keys to try than pure bruteforce to decrypt something. <br /> <br /> Most of the fuzzers are:<br /> <br /> - protocol/file-format dependant<br /> <br /> - data-type dependant<br /> <br /> Why? <br /> <br /> Because a program only understands structured-enough data. If you connect to a web server in a raw way, it will only respond to listed commands such as GET (or eventually crash). It will take less time to start the string with &quot;GET &quot;, and fuzz the rest, but the drawback is that you'll skip all the tests on the first verb.<br /> <br /> In this regard, Fuzzers try to reduce the number of unuseful tests, i.e. the values we already know that there's little chance they'll work: you reduce impredictibility, in favor of speed.<br /> <br /> == Attack types ==<br /> <br /> A fuzzer would try combinations of attacks on:<br /> <br /> - numbers (signed/unsigned integers/float...)<br /> <br /> - chars (urls, command-line inputs)<br /> <br /> - metadata : user-input text (id3 tag)<br /> <br /> - pure binary sequences<br /> <br /> A common approach to fuzzing is to define lists of &quot;known-to-be-dangerous values&quot; (''fuzz vectors'') for each type, and to inject them or recombinations.<br /> <br /> - for integers: zero, possibly negative or very big numbers<br /> <br /> - for chars: escaped, interpretable characters / instructions (ex: For SQL Requests, quotes / commands...)<br /> <br /> - for binary: random ones<br /> <br /> Please refer to OWASP's Fuzz Vector's resource[http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors] for real-life examples.<br /> <br /> Protocols and file formats imply norms, which are sometimes blurry, very complicated or badly implemented : that's why developers sometimes mess up in the implementation process (because of time/cost constraints). That's why it can be interesting to take the opposite approach: take a norm, look at all mandatory features and constraints, and try all of them; forbidden/reserved values, linked parameters, field sizes. That would be ''hand-fuzzing''.<br /> <br /> <br /> == Protocol fuzzing ==<br /> <br /> A protocol fuzzer sends forged packets to the tested application, or eventually acts as a proxy, modifying requests on the fly and replaying them.<br /> <br /> <br /> == File format fuzzing ==<br /> <br /> A file format fuzzer generates multiple malformed samples, and opens them sequentially. When the program crashes, debug information is kept for further investigation.<br /> <br /> One can attack:<br /> - the parser layer (container layer): file format constraints, structure, conventions, field sizes, flags, ...<br /> - the codec/application layer: lower-level attacks, aiming at the programm's deeper internals<br /> <br /> Example found vulnerability: Microsoft's JPEG GDI+ vulnerability was a zero sized comment field, without content.<br /> <br /> A generic file format fuzzer is Ilja van Sprundel's mangle.c[http://www.digitaldwarf.be/products/mangle.c]; &quot;it's usage is very simple, it takes a filename and headersize as input. it will then change approximatly between 0 and 10% of the header with random bytes.&quot;<br /> <br /> One may use tools like Hachoir[http://hachoir.org/] as a generic parser for file format fuzzers development.<br /> <br /> == Fuzzers advantages ==<br /> <br /> ''The great advantage of fuzz testing is that the test design is extremely simple, and free of preconceptions about system behavior'' (from Wikipedia [http://en.wikipedia.org/wiki/Fuzz_testing]).<br /> <br /> The systematical/random approach allows this method to find bugs that would have often been missed by human eyes. Plus, when the tested system is totally closed (say, a SIP phone), fuzzing is one of the only means of reviewing it's quality.<br /> <br /> == Fuzzers limitations ==<br /> <br /> Fuzzers usually tend to try one-level-imbrication-level attacks, which means changing only one parameter at a time. Therefore, fuzzing tools can detect trivial errors, but are less gifted with deep ones.<br /> <br /> Another problem is that when you do some black-box-testing, you usually attack a closed system, which increases difficulty to evaluate the dangerosity/impact of the found vulnerability.<br /> <br /> == Why Fuzz? ==<br /> <br /> The purpose of fuzzing relies on the assumption that there are bugs within every program, which are waiting to be discovered. Therefore, a systematical approach should find them sooner or later.<br /> <br /> Fuzzing can add another point of view to classical software testing techniques (hand code review, debugging) because of it's non-human approach. It doesn't replace them, but is a reasonable complement, thanks to the limited work needed to put the procedure in place.<br /> <br /> == Fuzzers from OWASP ==<br /> <br /> Fuzzing with WebScarab [http://www.owasp.org/index.php/Fuzzing_with_WebScarab]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br /> <br /> JBroFuzz [http://www.owasp.org/index.php/JBroFuzz]: a stateless network protocol fuzzer<br /> <br /> WSFuzzer [http://www.owasp.org/index.php/WSFuzzer]: real-world manual SOAP pen testing tool<br /> <br /> == Technical resources on OWASP ==<br /> <br /> Fuzzing vectors [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors]<br /> <br /> == Sources ==<br /> <br /> Wikipedia article [http://en.wikipedia.org/wiki/Fuzz_testing]<br /> <br /> Fuzzing-related papers [http://www.threatmind.net/secwiki/FuzzingPapers]<br /> <br /> == Fuzzing tools ==<br /> <br /> The ultimate fuzzers list @ infosec [http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html]<br /> <br /> Another list @ hacksafe<br /> [http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/]<br /> <br /> The fuzzing mailing list [http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing]<br /> <br /> == Commercial products ==<br /> <br /> Codenomicon's product suite: [http://www.codenomicon.com/products/all.shtml]</div>

Fthiery https://wiki.owasp.org/index.php?title=Fuzzing&diff=14229 2006-12-12T09:19:33Z

<p>Fthiery: /* Fuzzers advantages */</p> <hr /> <div>''Fuzz testing'' or ''Fuzzing'' is a Black Box software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection in an automated fashion.<br /> <br /> == A trivial example: ==<br /> <br /> Lets's consider an integer in a program, which stores the result of a user's choice between 3 questions. When the user picks one, the choice will be 0, 1 or 2. Which makes three practical cases. But what if we transmit 3, or 255 ? We can, because integers are stored a static size variable. If the default switch case hasn't been implemented securely, the program may crash and lead to &quot;classical&quot; security issues: (un)exploitable buffer overflows, DoS, ...<br /> <br /> Fuzzing is the art of automatic bug finding, and it's role is to find software implementation faults, and identify them if possible.<br /> <br /> == History ==<br /> <br /> Fuzz testing was developed at the University of Wisconsin Madison in 1989 by Professor Barton Miller and his students. Their work can be found at http://www.cs.wisc.edu/~bart/fuzz/<br /> <br /> == Fuzzer implementations ==<br /> <br /> A fuzzer is a program which injects automatically semi-random data into a program/stack and detect bugs.<br /> The data-generation part is made of generators, and vulnerability identification relies on debugging tools.<br /> <br /> A protocol fuzzer sends forged packets to the tested system, and a file format fuzzer generates files and opens them one after another, an application fuzzer sends forged data.<br /> <br /> == Comparison with cryptanalysis ==<br /> <br /> The number of possible tryable solutions is ''the explorable solutions space''. The aim of cryptanalysis is to reduce this space, which means finding a way of having less keys to try than pure bruteforce to decrypt something. <br /> <br /> Most of the fuzzers are:<br /> <br /> - protocol/file-format dependant<br /> <br /> - data-type dependant<br /> <br /> Why? <br /> <br /> Because a program only understands structured-enough data. If you connect to a web server in a raw way, it will only respond to listed commands such as GET (or eventually crash). It will take less time to start the string with &quot;GET &quot;, and fuzz the rest, but the drawback is that you'll skip all the tests on the first verb.<br /> <br /> In this regard, Fuzzers try to reduce the number of unuseful tests, i.e. the values we already know that there's little chance they'll work: you reduce impredictibility, in favor of speed.<br /> <br /> == Attack types ==<br /> <br /> A fuzzer would try combinations of attacks on:<br /> <br /> - numbers (signed/unsigned integers/float...)<br /> <br /> - chars (urls, command-line inputs)<br /> <br /> - metadata : user-input text (id3 tag)<br /> <br /> - pure binary sequences<br /> <br /> A common approach to fuzzing is to define lists of &quot;known-to-be-dangerous values&quot; (''fuzz vectors'') for each type, and to inject them or recombinations.<br /> <br /> - for integers: zero, possibly negative or very big numbers<br /> <br /> - for chars: escaped, interpretable characters / instructions (ex: For SQL Requests, quotes / commands...)<br /> <br /> - for binary: random ones<br /> <br /> Please refer to OWASP's Fuzz Vector's resource[http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors] for real-life examples.<br /> <br /> Protocols and file formats imply norms, which are sometimes blurry, very complicated or badly implemented : that's why developers sometimes mess up in the implementation process (because of time/cost constraints). That's why it can be interesting to take the opposite approach: take a norm, look at all mandatory features and constraints, and try all of them; forbidden/reserved values, linked parameters, field sizes. That would be ''hand-fuzzing''.<br /> <br /> == Fuzzers advantages ==<br /> <br /> ''The great advantage of fuzz testing is that the test design is extremely simple, and free of preconceptions about system behavior'' (from Wikipedia [http://en.wikipedia.org/wiki/Fuzz_testing]).<br /> <br /> The systematical/random approach allows this method to find bugs that would have often been missed by human eyes. Plus, when the tested system is totally closed (say, a SIP phone), fuzzing is one of the only means of reviewing it's quality.<br /> <br /> == Fuzzers limitations ==<br /> <br /> Fuzzers usually tend to try one-level-imbrication-level attacks, which means changing only one parameter at a time. Therefore, fuzzing tools can detect trivial errors, but are less gifted with deep ones.<br /> <br /> Another problem is that when you do some black-box-testing, you usually attack a closed system, which increases difficulty to evaluate the dangerosity/impact of the found vulnerability.<br /> <br /> == Why Fuzz? ==<br /> <br /> The purpose of fuzzing relies on the assumption that there are bugs within every program, which are waiting to be discovered. Therefore, a systematical approach should find them sooner or later.<br /> <br /> Fuzzing can add another point of view to classical software testing techniques (hand code review, debugging) because of it's non-human approach. It doesn't replace them, but is a reasonable complement, thanks to the limited work needed to put the procedure in place.<br /> <br /> == Fuzzers from OWASP ==<br /> <br /> Fuzzing with WebScarab [http://www.owasp.org/index.php/Fuzzing_with_WebScarab]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br /> <br /> JBroFuzz [http://www.owasp.org/index.php/JBroFuzz]: a stateless network protocol fuzzer<br /> <br /> WSFuzzer [http://www.owasp.org/index.php/WSFuzzer]: real-world manual SOAP pen testing tool<br /> <br /> == Technical resources on OWASP ==<br /> <br /> Fuzzing vectors [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors]<br /> <br /> == Sources ==<br /> <br /> Wikipedia article [http://en.wikipedia.org/wiki/Fuzz_testing]<br /> <br /> Fuzzing-related papers [http://www.threatmind.net/secwiki/FuzzingPapers]<br /> <br /> == Fuzzing tools ==<br /> <br /> The ultimate fuzzers list @ infosec [http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html]<br /> <br /> Another list @ hacksafe<br /> [http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/]<br /> <br /> The fuzzing mailing list [http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing]<br /> <br /> == Commercial products ==<br /> <br /> Codenomicon's product suite: [http://www.codenomicon.com/products/all.shtml]</div>

Fthiery https://wiki.owasp.org/index.php?title=Fuzzing&diff=14228 2006-12-12T09:18:59Z

<p>Fthiery: /* Fuzzers advantages */</p> <hr /> <div>''Fuzz testing'' or ''Fuzzing'' is a Black Box software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection in an automated fashion.<br /> <br /> == A trivial example: ==<br /> <br /> Lets's consider an integer in a program, which stores the result of a user's choice between 3 questions. When the user picks one, the choice will be 0, 1 or 2. Which makes three practical cases. But what if we transmit 3, or 255 ? We can, because integers are stored a static size variable. If the default switch case hasn't been implemented securely, the program may crash and lead to &quot;classical&quot; security issues: (un)exploitable buffer overflows, DoS, ...<br /> <br /> Fuzzing is the art of automatic bug finding, and it's role is to find software implementation faults, and identify them if possible.<br /> <br /> == History ==<br /> <br /> Fuzz testing was developed at the University of Wisconsin Madison in 1989 by Professor Barton Miller and his students. Their work can be found at http://www.cs.wisc.edu/~bart/fuzz/<br /> <br /> == Fuzzer implementations ==<br /> <br /> A fuzzer is a program which injects automatically semi-random data into a program/stack and detect bugs.<br /> The data-generation part is made of generators, and vulnerability identification relies on debugging tools.<br /> <br /> A protocol fuzzer sends forged packets to the tested system, and a file format fuzzer generates files and opens them one after another, an application fuzzer sends forged data.<br /> <br /> == Comparison with cryptanalysis ==<br /> <br /> The number of possible tryable solutions is ''the explorable solutions space''. The aim of cryptanalysis is to reduce this space, which means finding a way of having less keys to try than pure bruteforce to decrypt something. <br /> <br /> Most of the fuzzers are:<br /> <br /> - protocol/file-format dependant<br /> <br /> - data-type dependant<br /> <br /> Why? <br /> <br /> Because a program only understands structured-enough data. If you connect to a web server in a raw way, it will only respond to listed commands such as GET (or eventually crash). It will take less time to start the string with &quot;GET &quot;, and fuzz the rest, but the drawback is that you'll skip all the tests on the first verb.<br /> <br /> In this regard, Fuzzers try to reduce the number of unuseful tests, i.e. the values we already know that there's little chance they'll work: you reduce impredictibility, in favor of speed.<br /> <br /> == Attack types ==<br /> <br /> A fuzzer would try combinations of attacks on:<br /> <br /> - numbers (signed/unsigned integers/float...)<br /> <br /> - chars (urls, command-line inputs)<br /> <br /> - metadata : user-input text (id3 tag)<br /> <br /> - pure binary sequences<br /> <br /> A common approach to fuzzing is to define lists of &quot;known-to-be-dangerous values&quot; (''fuzz vectors'') for each type, and to inject them or recombinations.<br /> <br /> - for integers: zero, possibly negative or very big numbers<br /> <br /> - for chars: escaped, interpretable characters / instructions (ex: For SQL Requests, quotes / commands...)<br /> <br /> - for binary: random ones<br /> <br /> Please refer to OWASP's Fuzz Vector's resource[http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors] for real-life examples.<br /> <br /> Protocols and file formats imply norms, which are sometimes blurry, very complicated or badly implemented : that's why developers sometimes mess up in the implementation process (because of time/cost constraints). That's why it can be interesting to take the opposite approach: take a norm, look at all mandatory features and constraints, and try all of them; forbidden/reserved values, linked parameters, field sizes. That would be ''hand-fuzzing''.<br /> <br /> == Fuzzers advantages ==<br /> <br /> ''The great advantage of fuzz testing is that the test design is extremely simple, and free of preconceptions about system behavior'' (from Wikipedia [http://en.wikipedia.org/wiki/Fuzz_testing#Advantages_and_disadvantages]).<br /> <br /> The systematical/random approach allows this method to find bugs that would have often been missed by human eyes. Plus, when the tested system is totally closed (say, a SIP phone), fuzzing is one of the only means of reviewing it's quality.<br /> <br /> == Fuzzers limitations ==<br /> <br /> Fuzzers usually tend to try one-level-imbrication-level attacks, which means changing only one parameter at a time. Therefore, fuzzing tools can detect trivial errors, but are less gifted with deep ones.<br /> <br /> Another problem is that when you do some black-box-testing, you usually attack a closed system, which increases difficulty to evaluate the dangerosity/impact of the found vulnerability.<br /> <br /> == Why Fuzz? ==<br /> <br /> The purpose of fuzzing relies on the assumption that there are bugs within every program, which are waiting to be discovered. Therefore, a systematical approach should find them sooner or later.<br /> <br /> Fuzzing can add another point of view to classical software testing techniques (hand code review, debugging) because of it's non-human approach. It doesn't replace them, but is a reasonable complement, thanks to the limited work needed to put the procedure in place.<br /> <br /> == Fuzzers from OWASP ==<br /> <br /> Fuzzing with WebScarab [http://www.owasp.org/index.php/Fuzzing_with_WebScarab]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br /> <br /> JBroFuzz [http://www.owasp.org/index.php/JBroFuzz]: a stateless network protocol fuzzer<br /> <br /> WSFuzzer [http://www.owasp.org/index.php/WSFuzzer]: real-world manual SOAP pen testing tool<br /> <br /> == Technical resources on OWASP ==<br /> <br /> Fuzzing vectors [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors]<br /> <br /> == Sources ==<br /> <br /> Wikipedia article [http://en.wikipedia.org/wiki/Fuzz_testing]<br /> <br /> Fuzzing-related papers [http://www.threatmind.net/secwiki/FuzzingPapers]<br /> <br /> == Fuzzing tools ==<br /> <br /> The ultimate fuzzers list @ infosec [http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html]<br /> <br /> Another list @ hacksafe<br /> [http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/]<br /> <br /> The fuzzing mailing list [http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing]<br /> <br /> == Commercial products ==<br /> <br /> Codenomicon's product suite: [http://www.codenomicon.com/products/all.shtml]</div>

Fthiery https://wiki.owasp.org/index.php?title=Fuzzing&diff=14227 2006-12-12T09:16:43Z

<p>Fthiery: /* Fuzzers advantages */</p> <hr /> <div>''Fuzz testing'' or ''Fuzzing'' is a Black Box software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection in an automated fashion.<br /> <br /> == A trivial example: ==<br /> <br /> Lets's consider an integer in a program, which stores the result of a user's choice between 3 questions. When the user picks one, the choice will be 0, 1 or 2. Which makes three practical cases. But what if we transmit 3, or 255 ? We can, because integers are stored a static size variable. If the default switch case hasn't been implemented securely, the program may crash and lead to &quot;classical&quot; security issues: (un)exploitable buffer overflows, DoS, ...<br /> <br /> Fuzzing is the art of automatic bug finding, and it's role is to find software implementation faults, and identify them if possible.<br /> <br /> == History ==<br /> <br /> Fuzz testing was developed at the University of Wisconsin Madison in 1989 by Professor Barton Miller and his students. Their work can be found at http://www.cs.wisc.edu/~bart/fuzz/<br /> <br /> == Fuzzer implementations ==<br /> <br /> A fuzzer is a program which injects automatically semi-random data into a program/stack and detect bugs.<br /> The data-generation part is made of generators, and vulnerability identification relies on debugging tools.<br /> <br /> A protocol fuzzer sends forged packets to the tested system, and a file format fuzzer generates files and opens them one after another, an application fuzzer sends forged data.<br /> <br /> == Comparison with cryptanalysis ==<br /> <br /> The number of possible tryable solutions is ''the explorable solutions space''. The aim of cryptanalysis is to reduce this space, which means finding a way of having less keys to try than pure bruteforce to decrypt something. <br /> <br /> Most of the fuzzers are:<br /> <br /> - protocol/file-format dependant<br /> <br /> - data-type dependant<br /> <br /> Why? <br /> <br /> Because a program only understands structured-enough data. If you connect to a web server in a raw way, it will only respond to listed commands such as GET (or eventually crash). It will take less time to start the string with &quot;GET &quot;, and fuzz the rest, but the drawback is that you'll skip all the tests on the first verb.<br /> <br /> In this regard, Fuzzers try to reduce the number of unuseful tests, i.e. the values we already know that there's little chance they'll work: you reduce impredictibility, in favor of speed.<br /> <br /> == Attack types ==<br /> <br /> A fuzzer would try combinations of attacks on:<br /> <br /> - numbers (signed/unsigned integers/float...)<br /> <br /> - chars (urls, command-line inputs)<br /> <br /> - metadata : user-input text (id3 tag)<br /> <br /> - pure binary sequences<br /> <br /> A common approach to fuzzing is to define lists of &quot;known-to-be-dangerous values&quot; (''fuzz vectors'') for each type, and to inject them or recombinations.<br /> <br /> - for integers: zero, possibly negative or very big numbers<br /> <br /> - for chars: escaped, interpretable characters / instructions (ex: For SQL Requests, quotes / commands...)<br /> <br /> - for binary: random ones<br /> <br /> Please refer to OWASP's Fuzz Vector's resource[http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors] for real-life examples.<br /> <br /> Protocols and file formats imply norms, which are sometimes blurry, very complicated or badly implemented : that's why developers sometimes mess up in the implementation process (because of time/cost constraints). That's why it can be interesting to take the opposite approach: take a norm, look at all mandatory features and constraints, and try all of them; forbidden/reserved values, linked parameters, field sizes. That would be ''hand-fuzzing''.<br /> <br /> == Fuzzers advantages ==<br /> <br /> One of the important aspects of a fuzzer is that one doesn't need to look at the internals of the tested system: the systematical/random approach allows this method to find bugs that would have often been missed by human eyes.<br /> <br /> Plus, when the tested system is totally closed (say, a SIP phone), fuzzing is one of the only means of reviewing it's quality.<br /> <br /> == Fuzzers limitations ==<br /> <br /> Fuzzers usually tend to try one-level-imbrication-level attacks, which means changing only one parameter at a time. Therefore, fuzzing tools can detect trivial errors, but are less gifted with deep ones.<br /> <br /> Another problem is that when you do some black-box-testing, you usually attack a closed system, which increases difficulty to evaluate the dangerosity/impact of the found vulnerability.<br /> <br /> == Why Fuzz? ==<br /> <br /> The purpose of fuzzing relies on the assumption that there are bugs within every program, which are waiting to be discovered. Therefore, a systematical approach should find them sooner or later.<br /> <br /> Fuzzing can add another point of view to classical software testing techniques (hand code review, debugging) because of it's non-human approach. It doesn't replace them, but is a reasonable complement, thanks to the limited work needed to put the procedure in place.<br /> <br /> == Fuzzers from OWASP ==<br /> <br /> Fuzzing with WebScarab [http://www.owasp.org/index.php/Fuzzing_with_WebScarab]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br /> <br /> JBroFuzz [http://www.owasp.org/index.php/JBroFuzz]: a stateless network protocol fuzzer<br /> <br /> WSFuzzer [http://www.owasp.org/index.php/WSFuzzer]: real-world manual SOAP pen testing tool<br /> <br /> == Technical resources on OWASP ==<br /> <br /> Fuzzing vectors [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors]<br /> <br /> == Sources ==<br /> <br /> Wikipedia article [http://en.wikipedia.org/wiki/Fuzz_testing]<br /> <br /> Fuzzing-related papers [http://www.threatmind.net/secwiki/FuzzingPapers]<br /> <br /> == Fuzzing tools ==<br /> <br /> The ultimate fuzzers list @ infosec [http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html]<br /> <br /> Another list @ hacksafe<br /> [http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/]<br /> <br /> The fuzzing mailing list [http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing]<br /> <br /> == Commercial products ==<br /> <br /> Codenomicon's product suite: [http://www.codenomicon.com/products/all.shtml]</div>

Fthiery https://wiki.owasp.org/index.php?title=Fuzzing&diff=14226 2006-12-12T09:14:48Z

<p>Fthiery: </p> <hr /> <div>''Fuzz testing'' or ''Fuzzing'' is a Black Box software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection in an automated fashion.<br /> <br /> == A trivial example: ==<br /> <br /> Lets's consider an integer in a program, which stores the result of a user's choice between 3 questions. When the user picks one, the choice will be 0, 1 or 2. Which makes three practical cases. But what if we transmit 3, or 255 ? We can, because integers are stored a static size variable. If the default switch case hasn't been implemented securely, the program may crash and lead to &quot;classical&quot; security issues: (un)exploitable buffer overflows, DoS, ...<br /> <br /> Fuzzing is the art of automatic bug finding, and it's role is to find software implementation faults, and identify them if possible.<br /> <br /> == History ==<br /> <br /> Fuzz testing was developed at the University of Wisconsin Madison in 1989 by Professor Barton Miller and his students. Their work can be found at http://www.cs.wisc.edu/~bart/fuzz/<br /> <br /> == Fuzzer implementations ==<br /> <br /> A fuzzer is a program which injects automatically semi-random data into a program/stack and detect bugs.<br /> The data-generation part is made of generators, and vulnerability identification relies on debugging tools.<br /> <br /> A protocol fuzzer sends forged packets to the tested system, and a file format fuzzer generates files and opens them one after another, an application fuzzer sends forged data.<br /> <br /> == Comparison with cryptanalysis ==<br /> <br /> The number of possible tryable solutions is ''the explorable solutions space''. The aim of cryptanalysis is to reduce this space, which means finding a way of having less keys to try than pure bruteforce to decrypt something. <br /> <br /> Most of the fuzzers are:<br /> <br /> - protocol/file-format dependant<br /> <br /> - data-type dependant<br /> <br /> Why? <br /> <br /> Because a program only understands structured-enough data. If you connect to a web server in a raw way, it will only respond to listed commands such as GET (or eventually crash). It will take less time to start the string with &quot;GET &quot;, and fuzz the rest, but the drawback is that you'll skip all the tests on the first verb.<br /> <br /> In this regard, Fuzzers try to reduce the number of unuseful tests, i.e. the values we already know that there's little chance they'll work: you reduce impredictibility, in favor of speed.<br /> <br /> == Attack types ==<br /> <br /> A fuzzer would try combinations of attacks on:<br /> <br /> - numbers (signed/unsigned integers/float...)<br /> <br /> - chars (urls, command-line inputs)<br /> <br /> - metadata : user-input text (id3 tag)<br /> <br /> - pure binary sequences<br /> <br /> A common approach to fuzzing is to define lists of &quot;known-to-be-dangerous values&quot; (''fuzz vectors'') for each type, and to inject them or recombinations.<br /> <br /> - for integers: zero, possibly negative or very big numbers<br /> <br /> - for chars: escaped, interpretable characters / instructions (ex: For SQL Requests, quotes / commands...)<br /> <br /> - for binary: random ones<br /> <br /> Please refer to OWASP's Fuzz Vector's resource[http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors] for real-life examples.<br /> <br /> Protocols and file formats imply norms, which are sometimes blurry, very complicated or badly implemented : that's why developers sometimes mess up in the implementation process (because of time/cost constraints). That's why it can be interesting to take the opposite approach: take a norm, look at all mandatory features and constraints, and try all of them; forbidden/reserved values, linked parameters, field sizes. That would be ''hand-fuzzing''.<br /> <br /> == Fuzzers advantages ==<br /> <br /> One of the important aspects of a fuzzer is that one doesn't need to look at the internals of the tested system: the systematical/random approach allows this method to find bugs that would have often been missed by human eyes.<br /> <br /> == Fuzzers limitations ==<br /> <br /> Fuzzers usually tend to try one-level-imbrication-level attacks, which means changing only one parameter at a time. Therefore, fuzzing tools can detect trivial errors, but are less gifted with deep ones.<br /> <br /> Another problem is that when you do some black-box-testing, you usually attack a closed system, which increases difficulty to evaluate the dangerosity/impact of the found vulnerability.<br /> <br /> == Why Fuzz? ==<br /> <br /> The purpose of fuzzing relies on the assumption that there are bugs within every program, which are waiting to be discovered. Therefore, a systematical approach should find them sooner or later.<br /> <br /> Fuzzing can add another point of view to classical software testing techniques (hand code review, debugging) because of it's non-human approach. It doesn't replace them, but is a reasonable complement, thanks to the limited work needed to put the procedure in place.<br /> <br /> == Fuzzers from OWASP ==<br /> <br /> Fuzzing with WebScarab [http://www.owasp.org/index.php/Fuzzing_with_WebScarab]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br /> <br /> JBroFuzz [http://www.owasp.org/index.php/JBroFuzz]: a stateless network protocol fuzzer<br /> <br /> WSFuzzer [http://www.owasp.org/index.php/WSFuzzer]: real-world manual SOAP pen testing tool<br /> <br /> == Technical resources on OWASP ==<br /> <br /> Fuzzing vectors [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors]<br /> <br /> == Sources ==<br /> <br /> Wikipedia article [http://en.wikipedia.org/wiki/Fuzz_testing]<br /> <br /> Fuzzing-related papers [http://www.threatmind.net/secwiki/FuzzingPapers]<br /> <br /> == Fuzzing tools ==<br /> <br /> The ultimate fuzzers list @ infosec [http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html]<br /> <br /> Another list @ hacksafe<br /> [http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/]<br /> <br /> The fuzzing mailing list [http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing]<br /> <br /> == Commercial products ==<br /> <br /> Codenomicon's product suite: [http://www.codenomicon.com/products/all.shtml]</div>

Fthiery https://wiki.owasp.org/index.php?title=Fuzzing&diff=14225 2006-12-12T09:06:12Z

<p>Fthiery: /* Attack types */</p> <hr /> <div>''Fuzz testing'' or ''Fuzzing'' is a Black Box software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection in an automated fashion.<br /> <br /> == A trivial example: ==<br /> <br /> Lets's consider an integer in a program, which stores the result of a user's choice between 3 questions. When the user picks one, the choice will be 0, 1 or 2. Which makes three practical cases. But what if we transmit 3, or 255 ? We can, because integers are stored a static size variable. If the default switch case hasn't been implemented securely, the program may crash and lead to &quot;classical&quot; security issues: (un)exploitable buffer overflows, DoS, ...<br /> <br /> Fuzzing is the art of automatic bug finding, and it's role is to find software implementation faults, and identify them if possible.<br /> <br /> == History ==<br /> <br /> Fuzz testing was developed at the University of Wisconsin Madison in 1989 by Professor Barton Miller and his students. Their work can be found at http://www.cs.wisc.edu/~bart/fuzz/<br /> <br /> == Fuzzer implementations ==<br /> <br /> A fuzzer is a program which injects automatically semi-random data into a program/stack and detect bugs.<br /> The data-generation part is made of generators, and vulnerability identification relies on debugging tools.<br /> <br /> A protocol fuzzer sends forged packets to the tested system, and a file format fuzzer generates files and opens them one after another, an application fuzzer sends forged data.<br /> <br /> == Comparison with cryptanalysis ==<br /> <br /> The number of possible tryable solutions is ''the explorable solutions space''. The aim of cryptanalysis is to reduce this space, which means finding a way of having less keys to try than pure bruteforce to decrypt something. <br /> <br /> Most of the fuzzers are:<br /> <br /> - protocol/file-format dependant<br /> <br /> - data-type dependant<br /> <br /> Why? <br /> <br /> Because a program only understands structured-enough data. If you connect to a web server in a raw way, it will only respond to listed commands such as GET (or eventually crash). It will take less time to start the string with &quot;GET &quot;, and fuzz the rest, but the drawback is that you'll skip all the tests on the first verb.<br /> <br /> In this regard, Fuzzers try to reduce the number of unuseful tests, i.e. the values we already know that there's little chance they'll work: you reduce impredictibility, in favor of speed.<br /> <br /> == Attack types ==<br /> <br /> A fuzzer would try combinations of attacks on:<br /> <br /> - numbers (signed/unsigned integers/float...)<br /> <br /> - chars (urls, command-line inputs)<br /> <br /> - metadata : user-input text (id3 tag)<br /> <br /> - pure binary sequences<br /> <br /> A common approach to fuzzing is to define lists of &quot;known-to-be-dangerous values&quot; (''fuzz vectors'') for each type, and to inject them or recombinations.<br /> <br /> - for integers: zero, possibly negative or very big numbers<br /> <br /> - for chars: escaped, interpretable characters / instructions (ex: For SQL Requests, quotes / commands...)<br /> <br /> - for binary: random ones<br /> <br /> Please refer to OWASP's Fuzz Vector's resource[http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors] for real-life examples.<br /> <br /> Protocols and file formats imply norms, which are sometimes blurry, very complicated or badly implemented : that's why developers sometimes mess up in the implementation process (because of time/cost constraints). That's why it can be interesting to take the opposite approach: take a norm, look at all mandatory features and constraints, and try all of them; forbidden/reserved values, linked parameters, field sizes. That would be ''hand-fuzzing''.<br /> <br /> == Fuzzers advantages ==<br /> <br /> One of the important aspects of a fuzzer is that one doesn't need to look at the internals of the tested system: the systematical/random approach allows this method to find bugs that would have often been missed by human eyes.<br /> <br /> == Fuzzers limitations ==<br /> <br /> Fuzzers usually tend to try one-level-imbrication-level attacks, which means changing only one parameter at a time. Therefore, fuzzing tools can detect trivial errors, but are less gifted with deep ones.<br /> <br /> Another problem is that when you do some black-box-testing, you usually attack a closed system, which increases difficulty to evaluate the dangerosity/impact of the found vulnerability.<br /> <br /> == Why Fuzz? ==<br /> <br /> Fuzzing can add another point of view to classical software testing techniques (hand code review, debugging) because of it's non-human approach. It doesn't replace them, but is a reasonable complement, thanks to the limited work needed to put the procedure in place.<br /> <br /> == Fuzzers from OWASP ==<br /> <br /> Fuzzing with WebScarab [http://www.owasp.org/index.php/Fuzzing_with_WebScarab]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br /> <br /> JBroFuzz [http://www.owasp.org/index.php/JBroFuzz]: a stateless network protocol fuzzer<br /> <br /> WSFuzzer [http://www.owasp.org/index.php/WSFuzzer]: real-world manual SOAP pen testing tool<br /> <br /> == Technical resources on OWASP ==<br /> <br /> Fuzzing vectors [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors]<br /> <br /> == Sources ==<br /> <br /> Wikipedia article [http://en.wikipedia.org/wiki/Fuzz_testing]<br /> <br /> Fuzzing-related papers [http://www.threatmind.net/secwiki/FuzzingPapers]<br /> <br /> == Fuzzing tools ==<br /> <br /> The ultimate fuzzers list @ infosec [http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html]<br /> <br /> Another list @ hacksafe<br /> [http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/]<br /> <br /> The fuzzing mailing list [http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing]<br /> <br /> == Commercial products ==<br /> <br /> Codenomicon's product suite: [http://www.codenomicon.com/products/all.shtml]</div>

Fthiery https://wiki.owasp.org/index.php?title=Fuzzing&diff=14224 2006-12-12T09:04:44Z

<p>Fthiery: </p> <hr /> <div>''Fuzz testing'' or ''Fuzzing'' is a Black Box software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection in an automated fashion.<br /> <br /> == A trivial example: ==<br /> <br /> Lets's consider an integer in a program, which stores the result of a user's choice between 3 questions. When the user picks one, the choice will be 0, 1 or 2. Which makes three practical cases. But what if we transmit 3, or 255 ? We can, because integers are stored a static size variable. If the default switch case hasn't been implemented securely, the program may crash and lead to &quot;classical&quot; security issues: (un)exploitable buffer overflows, DoS, ...<br /> <br /> Fuzzing is the art of automatic bug finding, and it's role is to find software implementation faults, and identify them if possible.<br /> <br /> == History ==<br /> <br /> Fuzz testing was developed at the University of Wisconsin Madison in 1989 by Professor Barton Miller and his students. Their work can be found at http://www.cs.wisc.edu/~bart/fuzz/<br /> <br /> == Fuzzer implementations ==<br /> <br /> A fuzzer is a program which injects automatically semi-random data into a program/stack and detect bugs.<br /> The data-generation part is made of generators, and vulnerability identification relies on debugging tools.<br /> <br /> A protocol fuzzer sends forged packets to the tested system, and a file format fuzzer generates files and opens them one after another, an application fuzzer sends forged data.<br /> <br /> == Comparison with cryptanalysis ==<br /> <br /> The number of possible tryable solutions is ''the explorable solutions space''. The aim of cryptanalysis is to reduce this space, which means finding a way of having less keys to try than pure bruteforce to decrypt something. <br /> <br /> Most of the fuzzers are:<br /> <br /> - protocol/file-format dependant<br /> <br /> - data-type dependant<br /> <br /> Why? <br /> <br /> Because a program only understands structured-enough data. If you connect to a web server in a raw way, it will only respond to listed commands such as GET (or eventually crash). It will take less time to start the string with &quot;GET &quot;, and fuzz the rest, but the drawback is that you'll skip all the tests on the first verb.<br /> <br /> In this regard, Fuzzers try to reduce the number of unuseful tests, i.e. the values we already know that there's little chance they'll work: you reduce impredictibility, in favor of speed.<br /> <br /> == Attack types ==<br /> <br /> A fuzzer would try combinations of attacks on:<br /> <br /> - numbers (signed/unsigned integers/float...)<br /> <br /> - chars (urls, command-line inputs)<br /> <br /> - metadata : user-input text (id3 tag)<br /> <br /> - pure binary sequences<br /> <br /> A common approach to fuzzing is to define lists of &quot;known-to-be-dangerous values&quot; (''fuzz vectors'') for each type, and to inject them or recombinations.<br /> <br /> For integers, zero, possibly negative or very big numbers.<br /> <br /> For chars, escaped, interpretable characters / instructions (ex: For SQL Requests, quotes / commands...).<br /> <br /> For binary, random ones.<br /> <br /> <br /> See [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors] for real-life examples.<br /> <br /> Protocols and file formats imply norms, which are sometimes blurry, very complicated or badly implemented : that's why developers sometimes mess up in the implementation process (because of time/cost constraints). That's why it can be interesting to take the opposite approach: take a norm, look at all mandatory features and constraints, and try all of them; forbidden/reserved values, linked parameters, field sizes. That would be ''hand-fuzzing''.<br /> <br /> == Fuzzers advantages ==<br /> <br /> One of the important aspects of a fuzzer is that one doesn't need to look at the internals of the tested system: the systematical/random approach allows this method to find bugs that would have often been missed by human eyes.<br /> <br /> == Fuzzers limitations ==<br /> <br /> Fuzzers usually tend to try one-level-imbrication-level attacks, which means changing only one parameter at a time. Therefore, fuzzing tools can detect trivial errors, but are less gifted with deep ones.<br /> <br /> Another problem is that when you do some black-box-testing, you usually attack a closed system, which increases difficulty to evaluate the dangerosity/impact of the found vulnerability.<br /> <br /> == Why Fuzz? ==<br /> <br /> Fuzzing can add another point of view to classical software testing techniques (hand code review, debugging) because of it's non-human approach. It doesn't replace them, but is a reasonable complement, thanks to the limited work needed to put the procedure in place.<br /> <br /> == Fuzzers from OWASP ==<br /> <br /> Fuzzing with WebScarab [http://www.owasp.org/index.php/Fuzzing_with_WebScarab]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br /> <br /> JBroFuzz [http://www.owasp.org/index.php/JBroFuzz]: a stateless network protocol fuzzer<br /> <br /> WSFuzzer [http://www.owasp.org/index.php/WSFuzzer]: real-world manual SOAP pen testing tool<br /> <br /> == Technical resources on OWASP ==<br /> <br /> Fuzzing vectors [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors]<br /> <br /> == Sources ==<br /> <br /> Wikipedia article [http://en.wikipedia.org/wiki/Fuzz_testing]<br /> <br /> Fuzzing-related papers [http://www.threatmind.net/secwiki/FuzzingPapers]<br /> <br /> == Fuzzing tools ==<br /> <br /> The ultimate fuzzers list @ infosec [http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html]<br /> <br /> Another list @ hacksafe<br /> [http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/]<br /> <br /> The fuzzing mailing list [http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing]<br /> <br /> == Commercial products ==<br /> <br /> Codenomicon's product suite: [http://www.codenomicon.com/products/all.shtml]</div>

Fthiery https://wiki.owasp.org/index.php?title=Fuzzing&diff=14223 2006-12-12T09:01:04Z

<p>Fthiery: </p> <hr /> <div>''Fuzz testing'' or ''Fuzzing'' is a Black Box software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection in an automated fashion.<br /> <br /> <br /> == A trivial example: ==<br /> <br /> Lets's consider an integer in a program, which stores the result of a user's choice between 3 questions. When the user picks one, the choice will be 0, 1 or 2. Which makes three practical cases. But what if we transmit 3, or 255 ? We can, because integers are stored a static size variable. If the default switch case hasn't been implemented securely, the program may crash and lead to &quot;classical&quot; security issues: (un)exploitable buffer overflows, DoS, ...<br /> <br /> Fuzzing is the art of automatic bug finding, and it's role is to find software implementation faults, and identify them if possible.<br /> <br /> <br /> == History ==<br /> <br /> Fuzz testing was developed at the University of Wisconsin Madison in 1989 by Professor Barton Miller and his students. Their work can be found at http://www.cs.wisc.edu/~bart/fuzz/<br /> <br /> <br /> == Fuzzer implementations ==<br /> <br /> A fuzzer is a program which injects automatically semi-random data into a program/stack and detect bugs.<br /> The data-generation part is made of generators, and vulnerability identification relies on debugging tools.<br /> <br /> A protocol fuzzer sends forged packets to the tested system, and a file format fuzzer generates files and opens them one after another, an application fuzzer sends forged data.<br /> <br /> <br /> == Comparison with cryptanalysis ==<br /> <br /> The number of possible tryable solutions is ''the explorable solutions space''. The aim of cryptanalysis is to reduce this space, which means finding a way of having less keys to try than pure bruteforce to decrypt something. <br /> <br /> Most of the fuzzers are:<br /> <br /> - protocol/file-format dependant<br /> <br /> - data-type dependant<br /> <br /> Why? <br /> <br /> Because a program only understands structured-enough data. If you connect to a web server in a raw way, it will only respond to listed commands such as GET (or eventually crash). It will take less time to start the string with &quot;GET &quot;, and fuzz the rest, but the drawback is that you'll skip all the tests on the first verb.<br /> <br /> In this regard, Fuzzers try to reduce the number of unuseful tests, i.e. the values we already know that there's little chance they'll work: you reduce impredictibility, in favor of speed.<br /> <br /> <br /> == Attack types ==<br /> <br /> A fuzzer would try combinations of attacks on:<br /> <br /> - numbers (signed/unsigned integers/float...)<br /> <br /> - chars (urls, command-line inputs)<br /> <br /> - metadata : user-input text (id3 tag)<br /> <br /> - pure binary sequences<br /> <br /> A common approach to fuzzing is to define lists of &quot;known-to-be-dangerous values&quot; (''fuzz vectors'') for each type, and to inject them or recombinations.<br /> <br /> For integers, zero, possibly negative or very big numbers.<br /> <br /> For chars, escaped, interpretable characters / instructions (ex: For SQL Requests, quotes / commands...).<br /> <br /> For binary, random ones.<br /> <br /> <br /> See [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors] for real-life examples.<br /> <br /> Protocols and file formats imply norms, which are sometimes blurry, very complicated or badly implemented : that's why developers sometimes mess up in the implementation process (because of time/cost constraints). That's why it can be interesting to take the opposite approach: take a norm, look at all mandatory features and constraints, and try all of them; forbidden/reserved values, linked parameters, field sizes. That would be ''hand-fuzzing''.<br /> <br /> <br /> == Fuzzers advantages ==<br /> <br /> One of the important aspects of a fuzzer is that one doesn't need to look at the internals of the tested system: the systematical/random approach allows this method to find bugs that would have often been missed by human eyes.<br /> <br /> <br /> == Fuzzers limitations ==<br /> <br /> Fuzzers usually tend to try one-level-imbrication-level attacks, which means changing only one parameter at a time. Therefore, fuzzing tools can detect trivial errors, but are less gifted with deep ones.<br /> <br /> Another problem is that when you do some black-box-testing, you usually attack a closed system, which increases difficulty to evaluate the dangerosity/impact of the found vulnerability.<br /> <br /> <br /> == Why Fuzz? ==<br /> <br /> Fuzzing can add another point of view to classical software testing techniques (hand code review, debugging) because of it's non-human approach. It doesn't replace them, but is a reasonable complement, thanks to the limited work needed to put the procedure in place.<br /> <br /> <br /> == Fuzzers from OWASP ==<br /> <br /> Fuzzing with WebScarab [http://www.owasp.org/index.php/Fuzzing_with_WebScarab]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br /> <br /> JBroFuzz [http://www.owasp.org/index.php/JBroFuzz]: a stateless network protocol fuzzer<br /> <br /> WSFuzzer [http://www.owasp.org/index.php/WSFuzzer]: real-world manual SOAP pen testing tool<br /> <br /> <br /> == Technical resources on OWASP ==<br /> <br /> Fuzzing vectors [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors]<br /> <br /> <br /> == Sources ==<br /> <br /> Wikipedia article [http://en.wikipedia.org/wiki/Fuzz_testing]<br /> <br /> Fuzzing-related papers [http://www.threatmind.net/secwiki/FuzzingPapers]<br /> <br /> <br /> == Fuzzing tools ==<br /> <br /> The ultimate fuzzers list @ infosec [http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html]<br /> <br /> Another list @ hacksafe<br /> [http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/]<br /> <br /> The fuzzing mailing list [http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing]<br /> <br /> <br /> == Commercial products ==<br /> <br /> Codenomicon's product suite: [http://www.codenomicon.com/products/all.shtml]</div>

Fthiery https://wiki.owasp.org/index.php?title=Fuzzing&diff=14222 2006-12-12T08:59:41Z

<p>Fthiery: /* Fuzzers limitations */</p> <hr /> <div>''Fuzz testing'' or ''Fuzzing'' is a Black Box software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection in an automated fashion.<br /> <br /> == A trivial example: ==<br /> <br /> Lets's consider an integer in a program, which stores the result of a user's choice between 3 questions. When the user picks one, the choice will be 0, 1 or 2. Which makes three practical cases. But what if we transmit 3, or 255 ? We can, because integers are stored a static size variable. If the default switch case hasn't been implemented securely, the program may crash and lead to &quot;classical&quot; security issues: (un)exploitable buffer overflows, DoS, ...<br /> <br /> Fuzzing is the art of automatic bug finding, and it's role is to find software implementation faults, and identify them if possible.<br /> <br /> == History ==<br /> <br /> Fuzz testing was developed at the University of Wisconsin Madison in 1989 by Professor Barton Miller and his students. Their work can be found at http://www.cs.wisc.edu/~bart/fuzz/<br /> <br /> == Fuzzer implementations ==<br /> <br /> A fuzzer is a program which injects automatically semi-random data into a program/stack and detect bugs.<br /> The data-generation part is made of generators, and vulnerability identification relies on debugging tools.<br /> <br /> A protocol fuzzer sends forged packets to the tested system, and a file format fuzzer generates files and opens them one after another, an application fuzzer sends forged data.<br /> <br /> == Comparison with cryptanalysis ==<br /> <br /> The number of possible tryable solutions is ''the explorable solutions space''. The aim of cryptanalysis is to reduce this space, which means finding a way of having less keys to try than pure bruteforce to decrypt something. <br /> <br /> Most of the fuzzers are:<br /> <br /> - protocol/file-format dependant<br /> <br /> - data-type dependant<br /> <br /> <br /> Why? <br /> <br /> Because a program only understands structured-enough data. If you connect to a web server in a raw way, it will only respond to listed commands such as GET (or eventually crash). It will take less time to start the string with &quot;GET &quot;, and fuzz the rest, but the drawback is that you'll skip all the tests on the first verb.<br /> <br /> In this regard, Fuzzers try to reduce the number of unuseful tests, i.e. the values we already know that there's little chance they'll work: you reduce impredictibility, in favor of speed.<br /> <br /> == Attack types ==<br /> <br /> A fuzzer would try combinations of attacks on:<br /> <br /> - numbers (signed/unsigned integers/float...)<br /> <br /> - chars (urls, command-line inputs)<br /> <br /> - metadata : user-input text (id3 tag)<br /> <br /> - pure binary sequences<br /> <br /> A common approach to fuzzing is to define lists of &quot;known-to-be-dangerous values&quot; (''fuzz vectors'') for each type, and to inject them or recombinations.<br /> <br /> For integers, zero, possibly negative or very big numbers.<br /> <br /> For chars, escaped, interpretable characters / instructions (ex: For SQL Requests, quotes / commands...).<br /> <br /> For binary, random ones.<br /> <br /> <br /> See [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors] for real-life examples.<br /> <br /> Protocols and file formats imply norms, which are sometimes blurry, very complicated or badly implemented : that's why developers sometimes mess up in the implementation process (because of time/cost constraints). That's why it can be interesting to take the opposite approach: take a norm, look at all mandatory features and constraints, and try all of them; forbidden/reserved values, linked parameters, field sizes. That would be ''hand-fuzzing''.<br /> <br /> <br /> == Fuzzers advantages ==<br /> <br /> One of the important aspects of a fuzzer is that one doesn't need to look at the internals of the tested system: the systematical/random approach allows this method to find bugs that would have often been missed by human eyes.<br /> <br /> <br /> == Fuzzers limitations ==<br /> <br /> Fuzzers usually tend to try one-level-imbrication-level attacks, which means changing only one parameter at a time. Therefore, fuzzing tools can detect trivial errors, but are less gifted with deep ones.<br /> <br /> Another problem is that when you do some black-box-testing, you usually attack a closed system, which increases difficulty to evaluate the dangerosity/impact of the found vulnerability.<br /> <br /> == Why Fuzz? ==<br /> <br /> Fuzzing can add another point of view to classical software testing techniques (hand code review, debugging) because of it's non-human approach. It doesn't replace them, but is a reasonable complement, thanks to the limited work needed to put the procedure in place.<br /> <br /> <br /> == Fuzzers from OWASP ==<br /> <br /> Fuzzing with WebScarab [http://www.owasp.org/index.php/Fuzzing_with_WebScarab]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br /> <br /> JBroFuzz [http://www.owasp.org/index.php/JBroFuzz]: a stateless network protocol fuzzer<br /> <br /> WSFuzzer [http://www.owasp.org/index.php/WSFuzzer]: real-world manual SOAP pen testing tool<br /> <br /> == Technical resources on OWASP ==<br /> <br /> Fuzzing vectors [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors]<br /> <br /> == Sources ==<br /> <br /> Wikipedia article [http://en.wikipedia.org/wiki/Fuzz_testing]<br /> <br /> Fuzzing-related papers [http://www.threatmind.net/secwiki/FuzzingPapers]<br /> <br /> == Fuzzing tools ==<br /> <br /> The ultimate fuzzers list @ infosec [http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html]<br /> <br /> Another list @ hacksafe<br /> [http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/]<br /> <br /> Hachoir, a generic parser: could be quite a good starting point for file format fuzzing [http://www.hachoir.org]<br /> <br /> The fuzzing mailing list [http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing]<br /> <br /> == Commercial products ==<br /> <br /> Codenomicon's product suite: [http://www.codenomicon.com/products/all.shtml]</div>

Fthiery https://wiki.owasp.org/index.php?title=Fuzzing&diff=14221 2006-12-12T08:58:24Z

<p>Fthiery: </p> <hr /> <div>''Fuzz testing'' or ''Fuzzing'' is a Black Box software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection in an automated fashion.<br /> <br /> == A trivial example: ==<br /> <br /> Lets's consider an integer in a program, which stores the result of a user's choice between 3 questions. When the user picks one, the choice will be 0, 1 or 2. Which makes three practical cases. But what if we transmit 3, or 255 ? We can, because integers are stored a static size variable. If the default switch case hasn't been implemented securely, the program may crash and lead to &quot;classical&quot; security issues: (un)exploitable buffer overflows, DoS, ...<br /> <br /> Fuzzing is the art of automatic bug finding, and it's role is to find software implementation faults, and identify them if possible.<br /> <br /> == History ==<br /> <br /> Fuzz testing was developed at the University of Wisconsin Madison in 1989 by Professor Barton Miller and his students. Their work can be found at http://www.cs.wisc.edu/~bart/fuzz/<br /> <br /> == Fuzzer implementations ==<br /> <br /> A fuzzer is a program which injects automatically semi-random data into a program/stack and detect bugs.<br /> The data-generation part is made of generators, and vulnerability identification relies on debugging tools.<br /> <br /> A protocol fuzzer sends forged packets to the tested system, and a file format fuzzer generates files and opens them one after another, an application fuzzer sends forged data.<br /> <br /> == Comparison with cryptanalysis ==<br /> <br /> The number of possible tryable solutions is ''the explorable solutions space''. The aim of cryptanalysis is to reduce this space, which means finding a way of having less keys to try than pure bruteforce to decrypt something. <br /> <br /> Most of the fuzzers are:<br /> <br /> - protocol/file-format dependant<br /> <br /> - data-type dependant<br /> <br /> <br /> Why? <br /> <br /> Because a program only understands structured-enough data. If you connect to a web server in a raw way, it will only respond to listed commands such as GET (or eventually crash). It will take less time to start the string with &quot;GET &quot;, and fuzz the rest, but the drawback is that you'll skip all the tests on the first verb.<br /> <br /> In this regard, Fuzzers try to reduce the number of unuseful tests, i.e. the values we already know that there's little chance they'll work: you reduce impredictibility, in favor of speed.<br /> <br /> == Attack types ==<br /> <br /> A fuzzer would try combinations of attacks on:<br /> <br /> - numbers (signed/unsigned integers/float...)<br /> <br /> - chars (urls, command-line inputs)<br /> <br /> - metadata : user-input text (id3 tag)<br /> <br /> - pure binary sequences<br /> <br /> A common approach to fuzzing is to define lists of &quot;known-to-be-dangerous values&quot; (''fuzz vectors'') for each type, and to inject them or recombinations.<br /> <br /> For integers, zero, possibly negative or very big numbers.<br /> <br /> For chars, escaped, interpretable characters / instructions (ex: For SQL Requests, quotes / commands...).<br /> <br /> For binary, random ones.<br /> <br /> <br /> See [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors] for real-life examples.<br /> <br /> Protocols and file formats imply norms, which are sometimes blurry, very complicated or badly implemented : that's why developers sometimes mess up in the implementation process (because of time/cost constraints). That's why it can be interesting to take the opposite approach: take a norm, look at all mandatory features and constraints, and try all of them; forbidden/reserved values, linked parameters, field sizes. That would be ''hand-fuzzing''.<br /> <br /> <br /> == Fuzzers advantages ==<br /> <br /> One of the important aspects of a fuzzer is that one doesn't need to look at the internals of the tested system: the systematical/random approach allows this method to find bugs that would have often been missed by human eyes.<br /> <br /> <br /> == Fuzzers limitations ==<br /> <br /> Fuzzers usually tend to try one-level-imbrication-level attacks, which means changing only one parameter at a time. Therefore, fuzzing tools can detect trivial errors, but are less gifted with deep ones.<br /> <br /> Another problem is that when you do some black-box-testing, you usually attack a closed system, which increases difficulty to evaluate the dangerosity of the found vulnerability.<br /> <br /> <br /> == Why Fuzz? ==<br /> <br /> Fuzzing can add another point of view to classical software testing techniques (hand code review, debugging) because of it's non-human approach. It doesn't replace them, but is a reasonable complement, thanks to the limited work needed to put the procedure in place.<br /> <br /> <br /> == Fuzzers from OWASP ==<br /> <br /> Fuzzing with WebScarab [http://www.owasp.org/index.php/Fuzzing_with_WebScarab]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br /> <br /> JBroFuzz [http://www.owasp.org/index.php/JBroFuzz]: a stateless network protocol fuzzer<br /> <br /> WSFuzzer [http://www.owasp.org/index.php/WSFuzzer]: real-world manual SOAP pen testing tool<br /> <br /> == Technical resources on OWASP ==<br /> <br /> Fuzzing vectors [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors]<br /> <br /> == Sources ==<br /> <br /> Wikipedia article [http://en.wikipedia.org/wiki/Fuzz_testing]<br /> <br /> Fuzzing-related papers [http://www.threatmind.net/secwiki/FuzzingPapers]<br /> <br /> == Fuzzing tools ==<br /> <br /> The ultimate fuzzers list @ infosec [http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html]<br /> <br /> Another list @ hacksafe<br /> [http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/]<br /> <br /> Hachoir, a generic parser: could be quite a good starting point for file format fuzzing [http://www.hachoir.org]<br /> <br /> The fuzzing mailing list [http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing]<br /> <br /> == Commercial products ==<br /> <br /> Codenomicon's product suite: [http://www.codenomicon.com/products/all.shtml]</div>

Fthiery https://wiki.owasp.org/index.php?title=Fuzzing&diff=14197 2006-12-12T00:40:23Z

<p>Fthiery: /* Attack types */</p> <hr /> <div>''Fuzz testing'' or ''Fuzzing'' is a software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection: it's a type of Black Box Testing, which means testing a closed system on the comportemental point of view.<br /> <br /> == A trivial example: ==<br /> <br /> Lets's consider an integer in a program, which stores the result of a user's choice between 3 questions. When the user picks one, the choice will be 0, 1 or 2. Which makes three practical cases. But what if we transmit 3, or 255 ? We can, because integers are stored a static size variable. If the default switch case hasn't been implemented securely, the program may crash and lead to &quot;classical&quot; security issues: (un)exploitable buffer overflows, DoS, ...<br /> <br /> Fuzzing is the art of automatic bug finding, and it's role is to find software implementation faults, and identify them if possible.<br /> <br /> == Fuzzer implementations ==<br /> <br /> A fuzzer is a program which injects automatically semi-random data into a program/stack and detect bugs.<br /> The data-generation part is made of generators, and vulnerability identification relies on debugging tools.<br /> <br /> A protocol fuzzer sends forged packets to the tested system, and a file format fuzzer generates files and opens them one after another, an application fuzzer sends forged data.<br /> <br /> == Comparison with cryptanalysis ==<br /> <br /> The number of possible tryable solutions is ''the explorable solutions space''. The aim of cryptanalysis is to reduce this space, which means finding a way of having less keys to try than pure bruteforce to decrypt something. <br /> <br /> Most of the fuzzers are:<br /> <br /> - protocol/file-format dependant<br /> <br /> - data-type dependant<br /> <br /> <br /> Why? <br /> <br /> Because a program only understands structured-enough data. If you connect to a web server in a raw way, it will only respond to listed commands such as GET (or eventually crash). It will take less time to start the string with &quot;GET &quot;, and fuzz the rest, but the drawback is that you'll skip all the tests on the first verb.<br /> <br /> In this regard, Fuzzers try to reduce the number of unuseful tests, i.e. the values we already know that there's little chance they'll work: you reduce impredictibility, in favor of speed.<br /> <br /> == Attack types ==<br /> <br /> A fuzzer would try combinations of attacks on:<br /> <br /> - numbers (signed/unsigned integers/float...)<br /> <br /> - chars (urls, command-line inputs)<br /> <br /> - metadata : user-input text (id3 tag)<br /> <br /> - pure binary sequences<br /> <br /> A common approach to fuzzing is to define lists of &quot;known-to-be-dangerous values&quot; (''fuzz vectors'') for each type, and to inject them or recombinations.<br /> <br /> For integers, zero, possibly negative or very big numbers.<br /> <br /> For chars, escaped, interpretable characters / instructions (ex: For SQL Requests, quotes / commands...).<br /> <br /> For binary, random ones.<br /> <br /> <br /> See [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors] for real-life examples.<br /> <br /> Protocols and file formats imply norms, which are sometimes blurry, very complicated or badly implemented : that's why developers sometimes mess up in the implementation process (because of time/cost constraints). That's why it can be interesting to take the opposite approach: take a norm, look at all mandatory features and constraints, and try all of them; forbidden/reserved values, linked parameters, field sizes. That would be ''hand-fuzzing''.<br /> <br /> == Fuzzers limitations ==<br /> <br /> Fuzzers usually tend to try one-level-imbrication-level attacks, which means changing only one parameter at a time. Therefore, fuzzing tools can detect trivial errors, but are less gifted with deep ones.<br /> <br /> Another problem is that when you do some black-box-testing, you usually attack a closed system, which increases difficulty to evaluate the dangerosity of the found vulnerability.<br /> <br /> == Technical resources on OWASP ==<br /> <br /> Fuzzing vectors [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors]<br /> <br /> == Sources ==<br /> <br /> Wikipedia article [http://en.wikipedia.org/wiki/Fuzz_testing]<br /> <br /> Fuzzing-related papers [http://www.threatmind.net/secwiki/FuzzingPapers]<br /> <br /> == Fuzzing tools ==<br /> <br /> The ultimate fuzzers list @ infosec [http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html]<br /> <br /> Another list @ hacksafe<br /> [http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/]<br /> <br /> Hachoir, a generic parser: could be quite a good starting point for file format fuzzing [http://www.hachoir.org]<br /> <br /> The fuzzing mailing list [http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing]<br /> <br /> == Commercial products ==<br /> <br /> Codenomicon's product suite: [http://www.codenomicon.com/products/all.shtml]</div>

Fthiery https://wiki.owasp.org/index.php?title=Fuzzing&diff=14196 2006-12-12T00:39:19Z

<p>Fthiery: /* Attack types */</p> <hr /> <div>''Fuzz testing'' or ''Fuzzing'' is a software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection: it's a type of Black Box Testing, which means testing a closed system on the comportemental point of view.<br /> <br /> == A trivial example: ==<br /> <br /> Lets's consider an integer in a program, which stores the result of a user's choice between 3 questions. When the user picks one, the choice will be 0, 1 or 2. Which makes three practical cases. But what if we transmit 3, or 255 ? We can, because integers are stored a static size variable. If the default switch case hasn't been implemented securely, the program may crash and lead to &quot;classical&quot; security issues: (un)exploitable buffer overflows, DoS, ...<br /> <br /> Fuzzing is the art of automatic bug finding, and it's role is to find software implementation faults, and identify them if possible.<br /> <br /> == Fuzzer implementations ==<br /> <br /> A fuzzer is a program which injects automatically semi-random data into a program/stack and detect bugs.<br /> The data-generation part is made of generators, and vulnerability identification relies on debugging tools.<br /> <br /> A protocol fuzzer sends forged packets to the tested system, and a file format fuzzer generates files and opens them one after another, an application fuzzer sends forged data.<br /> <br /> == Comparison with cryptanalysis ==<br /> <br /> The number of possible tryable solutions is ''the explorable solutions space''. The aim of cryptanalysis is to reduce this space, which means finding a way of having less keys to try than pure bruteforce to decrypt something. <br /> <br /> Most of the fuzzers are:<br /> <br /> - protocol/file-format dependant<br /> <br /> - data-type dependant<br /> <br /> <br /> Why? <br /> <br /> Because a program only understands structured-enough data. If you connect to a web server in a raw way, it will only respond to listed commands such as GET (or eventually crash). It will take less time to start the string with &quot;GET &quot;, and fuzz the rest, but the drawback is that you'll skip all the tests on the first verb.<br /> <br /> In this regard, Fuzzers try to reduce the number of unuseful tests, i.e. the values we already know that there's little chance they'll work: you reduce impredictibility, in favor of speed.<br /> <br /> == Attack types ==<br /> <br /> A fuzzer would try combinations of attacks on:<br /> <br /> - numbers (signed/unsigned integers/float...)<br /> <br /> - chars (urls, command-line inputs)<br /> <br /> - metadata : user-input text (id3 tag)<br /> <br /> - pure binary sequences<br /> <br /> A common approach to fuzzing is to define lists of &quot;known-to-be-dangerous values&quot; (''fuzz vectors'') for each type, and to inject them or recombinations.<br /> <br /> For integers, zero, possibly negative or very big numbers.<br /> <br /> For chars, escaped, interpretable characters / instructions (ex: For SQL Requests, quotes / commands...).<br /> <br /> For binary, random ones.<br /> <br /> <br /> See [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors] for real-life examples.<br /> <br /> Protocols and file formats imply norms, which are sometimes blurry, very complicated or badly implemented : that's why developers sometimes mess up in the implementation process (because of time/cost constraints). That's why it can be interesting to take the opposite approach: take a norm, look at all mandatory features and constraints, and try all of them: forbidden/reserved values, linked parameters, field sizes (a lot of implementations are said not to verify field sizes). That would be ''hand-fuzzing''.<br /> <br /> == Fuzzers limitations ==<br /> <br /> Fuzzers usually tend to try one-level-imbrication-level attacks, which means changing only one parameter at a time. Therefore, fuzzing tools can detect trivial errors, but are less gifted with deep ones.<br /> <br /> Another problem is that when you do some black-box-testing, you usually attack a closed system, which increases difficulty to evaluate the dangerosity of the found vulnerability.<br /> <br /> == Technical resources on OWASP ==<br /> <br /> Fuzzing vectors [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors]<br /> <br /> == Sources ==<br /> <br /> Wikipedia article [http://en.wikipedia.org/wiki/Fuzz_testing]<br /> <br /> Fuzzing-related papers [http://www.threatmind.net/secwiki/FuzzingPapers]<br /> <br /> == Fuzzing tools ==<br /> <br /> The ultimate fuzzers list @ infosec [http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html]<br /> <br /> Another list @ hacksafe<br /> [http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/]<br /> <br /> Hachoir, a generic parser: could be quite a good starting point for file format fuzzing [http://www.hachoir.org]<br /> <br /> The fuzzing mailing list [http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing]<br /> <br /> == Commercial products ==<br /> <br /> Codenomicon's product suite: [http://www.codenomicon.com/products/all.shtml]</div>

Fthiery https://wiki.owasp.org/index.php?title=Fuzzing&diff=14195 2006-12-12T00:38:04Z

<p>Fthiery: /* Comparison with cryptanalysis */</p> <hr /> <div>''Fuzz testing'' or ''Fuzzing'' is a software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection: it's a type of Black Box Testing, which means testing a closed system on the comportemental point of view.<br /> <br /> == A trivial example: ==<br /> <br /> Lets's consider an integer in a program, which stores the result of a user's choice between 3 questions. When the user picks one, the choice will be 0, 1 or 2. Which makes three practical cases. But what if we transmit 3, or 255 ? We can, because integers are stored a static size variable. If the default switch case hasn't been implemented securely, the program may crash and lead to &quot;classical&quot; security issues: (un)exploitable buffer overflows, DoS, ...<br /> <br /> Fuzzing is the art of automatic bug finding, and it's role is to find software implementation faults, and identify them if possible.<br /> <br /> == Fuzzer implementations ==<br /> <br /> A fuzzer is a program which injects automatically semi-random data into a program/stack and detect bugs.<br /> The data-generation part is made of generators, and vulnerability identification relies on debugging tools.<br /> <br /> A protocol fuzzer sends forged packets to the tested system, and a file format fuzzer generates files and opens them one after another, an application fuzzer sends forged data.<br /> <br /> == Comparison with cryptanalysis ==<br /> <br /> The number of possible tryable solutions is ''the explorable solutions space''. The aim of cryptanalysis is to reduce this space, which means finding a way of having less keys to try than pure bruteforce to decrypt something. <br /> <br /> Most of the fuzzers are:<br /> <br /> - protocol/file-format dependant<br /> <br /> - data-type dependant<br /> <br /> <br /> Why? <br /> <br /> Because a program only understands structured-enough data. If you connect to a web server in a raw way, it will only respond to listed commands such as GET (or eventually crash). It will take less time to start the string with &quot;GET &quot;, and fuzz the rest, but the drawback is that you'll skip all the tests on the first verb.<br /> <br /> In this regard, Fuzzers try to reduce the number of unuseful tests, i.e. the values we already know that there's little chance they'll work: you reduce impredictibility, in favor of speed.<br /> <br /> == Attack types ==<br /> <br /> A fuzzer would try combinations of attacks on:<br /> <br /> - numbers (signed/unsigned integers/float...)<br /> <br /> - chars (urls, command-line inputs)<br /> <br /> - metadata : user-input text (id3 tag)<br /> <br /> - pure binary sequences<br /> <br /> A common approach to fuzzing is to define lists of &quot;known-to-be-dangerous values&quot; (''fuzz vectors'') for each type, and to inject them or recombinations.<br /> <br /> For integers, zero, possibly negative or very big numbers.<br /> For chars, escaped, interpretable characters / instructions.<br /> For binary, random ones.<br /> For SQL Requests, quotes / commands...<br /> <br /> See [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors] for real-life examples.<br /> <br /> Protocols and file formats imply norms, which are sometimes blurry, very complicated or badly implemented : that's why developers sometimes mess up in the implementation process (because of time/cost constraints). That's why it can be interesting to take the opposite approach: take a norm, look at all mandatory features and constraints, and try all of them: forbidden/reserved values, linked parameters, field sizes (a lot of implementations are said not to verify field sizes). That would be ''hand-fuzzing''.<br /> <br /> == Fuzzers limitations ==<br /> <br /> Fuzzers usually tend to try one-level-imbrication-level attacks, which means changing only one parameter at a time. Therefore, fuzzing tools can detect trivial errors, but are less gifted with deep ones.<br /> <br /> Another problem is that when you do some black-box-testing, you usually attack a closed system, which increases difficulty to evaluate the dangerosity of the found vulnerability.<br /> <br /> == Technical resources on OWASP ==<br /> <br /> Fuzzing vectors [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors]<br /> <br /> == Sources ==<br /> <br /> Wikipedia article [http://en.wikipedia.org/wiki/Fuzz_testing]<br /> <br /> Fuzzing-related papers [http://www.threatmind.net/secwiki/FuzzingPapers]<br /> <br /> == Fuzzing tools ==<br /> <br /> The ultimate fuzzers list @ infosec [http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html]<br /> <br /> Another list @ hacksafe<br /> [http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/]<br /> <br /> Hachoir, a generic parser: could be quite a good starting point for file format fuzzing [http://www.hachoir.org]<br /> <br /> The fuzzing mailing list [http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing]<br /> <br /> == Commercial products ==<br /> <br /> Codenomicon's product suite: [http://www.codenomicon.com/products/all.shtml]</div>

Fthiery https://wiki.owasp.org/index.php?title=Fuzzing&diff=14194 2006-12-12T00:37:33Z

<p>Fthiery: /* Comparison with cryptanalysis */</p> <hr /> <div>''Fuzz testing'' or ''Fuzzing'' is a software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection: it's a type of Black Box Testing, which means testing a closed system on the comportemental point of view.<br /> <br /> == A trivial example: ==<br /> <br /> Lets's consider an integer in a program, which stores the result of a user's choice between 3 questions. When the user picks one, the choice will be 0, 1 or 2. Which makes three practical cases. But what if we transmit 3, or 255 ? We can, because integers are stored a static size variable. If the default switch case hasn't been implemented securely, the program may crash and lead to &quot;classical&quot; security issues: (un)exploitable buffer overflows, DoS, ...<br /> <br /> Fuzzing is the art of automatic bug finding, and it's role is to find software implementation faults, and identify them if possible.<br /> <br /> == Fuzzer implementations ==<br /> <br /> A fuzzer is a program which injects automatically semi-random data into a program/stack and detect bugs.<br /> The data-generation part is made of generators, and vulnerability identification relies on debugging tools.<br /> <br /> A protocol fuzzer sends forged packets to the tested system, and a file format fuzzer generates files and opens them one after another, an application fuzzer sends forged data.<br /> <br /> == Comparison with cryptanalysis ==<br /> <br /> The number of possible tryable solutions is ''the explorable solutions space''. The aim of cryptanalysis is to reduce this space, which means finding a way of having less keys to try than pure bruteforce to decrypt something. <br /> <br /> Most of the fuzzers are:<br /> <br /> - protocol/file-format dependant<br /> <br /> - data-type dependant<br /> <br /> Why? <br /> <br /> Because a program only understands structured-enough data. If you connect to a web server in a raw way, it will only respond to listed commands such as GET (or eventually crash). It will take less time to start the string with &quot;GET &quot;, and fuzz the rest, but the drawback is that you'll skip all the tests on the first verb.<br /> <br /> In this regard, Fuzzers try to reduce the number of unuseful tests, i.e. the values we already know that there's little chance they'll work: you reduce impredictibility, in favor of speed.<br /> <br /> == Attack types ==<br /> <br /> A fuzzer would try combinations of attacks on:<br /> <br /> - numbers (signed/unsigned integers/float...)<br /> <br /> - chars (urls, command-line inputs)<br /> <br /> - metadata : user-input text (id3 tag)<br /> <br /> - pure binary sequences<br /> <br /> A common approach to fuzzing is to define lists of &quot;known-to-be-dangerous values&quot; (''fuzz vectors'') for each type, and to inject them or recombinations.<br /> <br /> For integers, zero, possibly negative or very big numbers.<br /> For chars, escaped, interpretable characters / instructions.<br /> For binary, random ones.<br /> For SQL Requests, quotes / commands...<br /> <br /> See [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors] for real-life examples.<br /> <br /> Protocols and file formats imply norms, which are sometimes blurry, very complicated or badly implemented : that's why developers sometimes mess up in the implementation process (because of time/cost constraints). That's why it can be interesting to take the opposite approach: take a norm, look at all mandatory features and constraints, and try all of them: forbidden/reserved values, linked parameters, field sizes (a lot of implementations are said not to verify field sizes). That would be ''hand-fuzzing''.<br /> <br /> == Fuzzers limitations ==<br /> <br /> Fuzzers usually tend to try one-level-imbrication-level attacks, which means changing only one parameter at a time. Therefore, fuzzing tools can detect trivial errors, but are less gifted with deep ones.<br /> <br /> Another problem is that when you do some black-box-testing, you usually attack a closed system, which increases difficulty to evaluate the dangerosity of the found vulnerability.<br /> <br /> == Technical resources on OWASP ==<br /> <br /> Fuzzing vectors [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors]<br /> <br /> == Sources ==<br /> <br /> Wikipedia article [http://en.wikipedia.org/wiki/Fuzz_testing]<br /> <br /> Fuzzing-related papers [http://www.threatmind.net/secwiki/FuzzingPapers]<br /> <br /> == Fuzzing tools ==<br /> <br /> The ultimate fuzzers list @ infosec [http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html]<br /> <br /> Another list @ hacksafe<br /> [http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/]<br /> <br /> Hachoir, a generic parser: could be quite a good starting point for file format fuzzing [http://www.hachoir.org]<br /> <br /> The fuzzing mailing list [http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing]<br /> <br /> == Commercial products ==<br /> <br /> Codenomicon's product suite: [http://www.codenomicon.com/products/all.shtml]</div>

Fthiery https://wiki.owasp.org/index.php?title=Fuzzing&diff=14193 2006-12-12T00:36:52Z

<p>Fthiery: /* Comparison with cryptanalysis */</p> <hr /> <div>''Fuzz testing'' or ''Fuzzing'' is a software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection: it's a type of Black Box Testing, which means testing a closed system on the comportemental point of view.<br /> <br /> == A trivial example: ==<br /> <br /> Lets's consider an integer in a program, which stores the result of a user's choice between 3 questions. When the user picks one, the choice will be 0, 1 or 2. Which makes three practical cases. But what if we transmit 3, or 255 ? We can, because integers are stored a static size variable. If the default switch case hasn't been implemented securely, the program may crash and lead to &quot;classical&quot; security issues: (un)exploitable buffer overflows, DoS, ...<br /> <br /> Fuzzing is the art of automatic bug finding, and it's role is to find software implementation faults, and identify them if possible.<br /> <br /> == Fuzzer implementations ==<br /> <br /> A fuzzer is a program which injects automatically semi-random data into a program/stack and detect bugs.<br /> The data-generation part is made of generators, and vulnerability identification relies on debugging tools.<br /> <br /> A protocol fuzzer sends forged packets to the tested system, and a file format fuzzer generates files and opens them one after another, an application fuzzer sends forged data.<br /> <br /> == Comparison with cryptanalysis ==<br /> <br /> The number of possible tryable solutions is ''the explorable solutions space''. The aim of cryptanalysis is to reduce this space, which means finding a way of having less keys to try than pure bruteforce to decrypt something. <br /> <br /> Most of the fuzzers are:<br /> <br /> - protocol/file-format dependant<br /> <br /> - data-type dependant<br /> <br /> Why? <br /> <br /> Because a program only understands structured-enough data. If you connect to a web server in a raw way, it will only respond to listed commands such as GET (or eventually crash). It will take less time to start the string with &quot;GET &quot;, and fuzz the rest, but the drawback is that you'll skip all the tests on the first verb.<br /> <br /> In this regard, Fuzzers try to reduce the number of unuseful tests: the values we already know that here's little chance they'll work: you reduce impredictibility, in favor of speed.<br /> <br /> == Attack types ==<br /> <br /> A fuzzer would try combinations of attacks on:<br /> <br /> - numbers (signed/unsigned integers/float...)<br /> <br /> - chars (urls, command-line inputs)<br /> <br /> - metadata : user-input text (id3 tag)<br /> <br /> - pure binary sequences<br /> <br /> A common approach to fuzzing is to define lists of &quot;known-to-be-dangerous values&quot; (''fuzz vectors'') for each type, and to inject them or recombinations.<br /> <br /> For integers, zero, possibly negative or very big numbers.<br /> For chars, escaped, interpretable characters / instructions.<br /> For binary, random ones.<br /> For SQL Requests, quotes / commands...<br /> <br /> See [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors] for real-life examples.<br /> <br /> Protocols and file formats imply norms, which are sometimes blurry, very complicated or badly implemented : that's why developers sometimes mess up in the implementation process (because of time/cost constraints). That's why it can be interesting to take the opposite approach: take a norm, look at all mandatory features and constraints, and try all of them: forbidden/reserved values, linked parameters, field sizes (a lot of implementations are said not to verify field sizes). That would be ''hand-fuzzing''.<br /> <br /> == Fuzzers limitations ==<br /> <br /> Fuzzers usually tend to try one-level-imbrication-level attacks, which means changing only one parameter at a time. Therefore, fuzzing tools can detect trivial errors, but are less gifted with deep ones.<br /> <br /> Another problem is that when you do some black-box-testing, you usually attack a closed system, which increases difficulty to evaluate the dangerosity of the found vulnerability.<br /> <br /> == Technical resources on OWASP ==<br /> <br /> Fuzzing vectors [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors]<br /> <br /> == Sources ==<br /> <br /> Wikipedia article [http://en.wikipedia.org/wiki/Fuzz_testing]<br /> <br /> Fuzzing-related papers [http://www.threatmind.net/secwiki/FuzzingPapers]<br /> <br /> == Fuzzing tools ==<br /> <br /> The ultimate fuzzers list @ infosec [http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html]<br /> <br /> Another list @ hacksafe<br /> [http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/]<br /> <br /> Hachoir, a generic parser: could be quite a good starting point for file format fuzzing [http://www.hachoir.org]<br /> <br /> The fuzzing mailing list [http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing]<br /> <br /> == Commercial products ==<br /> <br /> Codenomicon's product suite: [http://www.codenomicon.com/products/all.shtml]</div>

Fthiery https://wiki.owasp.org/index.php?title=Fuzzing&diff=14192 2006-12-12T00:36:15Z

<p>Fthiery: /* Fuzzer implementations */</p> <hr /> <div>''Fuzz testing'' or ''Fuzzing'' is a software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection: it's a type of Black Box Testing, which means testing a closed system on the comportemental point of view.<br /> <br /> == A trivial example: ==<br /> <br /> Lets's consider an integer in a program, which stores the result of a user's choice between 3 questions. When the user picks one, the choice will be 0, 1 or 2. Which makes three practical cases. But what if we transmit 3, or 255 ? We can, because integers are stored a static size variable. If the default switch case hasn't been implemented securely, the program may crash and lead to &quot;classical&quot; security issues: (un)exploitable buffer overflows, DoS, ...<br /> <br /> Fuzzing is the art of automatic bug finding, and it's role is to find software implementation faults, and identify them if possible.<br /> <br /> == Fuzzer implementations ==<br /> <br /> A fuzzer is a program which injects automatically semi-random data into a program/stack and detect bugs.<br /> The data-generation part is made of generators, and vulnerability identification relies on debugging tools.<br /> <br /> A protocol fuzzer sends forged packets to the tested system, and a file format fuzzer generates files and opens them one after another, an application fuzzer sends forged data.<br /> <br /> == Comparison with cryptanalysis ==<br /> <br /> The number of possible tryable solutions is ''the explorable solutions space''. The aim of Cryptanalysis is to reduce this space, which means finding a way of having less keys to try than pure bruteforce to decrypt something. <br /> <br /> Most of the fuzzers are:<br /> <br /> - protocol/file-format dependant<br /> <br /> - data-type dependant<br /> <br /> Why? <br /> <br /> Because a program only understands structured-enough data. If you connect to a web server in a raw way, it will only respond to listed commands such as GET (or eventually crash). It will take less time to start the string with &quot;GET &quot;, and fuzz the rest, but the drawback is that you'll skip all the tests on the first verb.<br /> <br /> In this regard, Fuzzers try to reduce the number of unuseful tests: the values we already know that here's little chance they'll work: you reduce impredictibility, in favor of speed.<br /> <br /> == Attack types ==<br /> <br /> A fuzzer would try combinations of attacks on:<br /> <br /> - numbers (signed/unsigned integers/float...)<br /> <br /> - chars (urls, command-line inputs)<br /> <br /> - metadata : user-input text (id3 tag)<br /> <br /> - pure binary sequences<br /> <br /> A common approach to fuzzing is to define lists of &quot;known-to-be-dangerous values&quot; (''fuzz vectors'') for each type, and to inject them or recombinations.<br /> <br /> For integers, zero, possibly negative or very big numbers.<br /> For chars, escaped, interpretable characters / instructions.<br /> For binary, random ones.<br /> For SQL Requests, quotes / commands...<br /> <br /> See [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors] for real-life examples.<br /> <br /> Protocols and file formats imply norms, which are sometimes blurry, very complicated or badly implemented : that's why developers sometimes mess up in the implementation process (because of time/cost constraints). That's why it can be interesting to take the opposite approach: take a norm, look at all mandatory features and constraints, and try all of them: forbidden/reserved values, linked parameters, field sizes (a lot of implementations are said not to verify field sizes). That would be ''hand-fuzzing''.<br /> <br /> == Fuzzers limitations ==<br /> <br /> Fuzzers usually tend to try one-level-imbrication-level attacks, which means changing only one parameter at a time. Therefore, fuzzing tools can detect trivial errors, but are less gifted with deep ones.<br /> <br /> Another problem is that when you do some black-box-testing, you usually attack a closed system, which increases difficulty to evaluate the dangerosity of the found vulnerability.<br /> <br /> == Technical resources on OWASP ==<br /> <br /> Fuzzing vectors [http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors]<br /> <br /> == Sources ==<br /> <br /> Wikipedia article [http://en.wikipedia.org/wiki/Fuzz_testing]<br /> <br /> Fuzzing-related papers [http://www.threatmind.net/secwiki/FuzzingPapers]<br /> <br /> == Fuzzing tools ==<br /> <br /> The ultimate fuzzers list @ infosec [http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html]<br /> <br /> Another list @ hacksafe<br /> [http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/]<br /> <br /> Hachoir, a generic parser: could be quite a good starting point for file format fuzzing [http://www.hachoir.org]<br /> <br /> The fuzzing mailing list [http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing]<br /> <br /> == Commercial products ==<br /> <br /> Codenomicon's product suite: [http://www.codenomicon.com/products/all.shtml]</div>

Fthiery