FuzzDB is an open source database of attack patterns, predictable resource names,  regex patterns for identifying interesting server responses, and documentation resources. It’s most often used testing the security of web applications but can be useful for many other things. FuzzDB started off as years of my own personal documentation and research notes and gradually evolved into its current form.

This is the first of a series of blog posts about FuzzDB. It discusses:

• The problem that led to the creation of FuzzDB
• What kinds of things are in FuzzDB
• The different ways in which FuzzDB could be used
• The future of FuzzDB

FuzzDB, is hosted at Google Code: https://code.google.com/p/fuzzdb/

A lot of attention has been paid to identifying attackable surface areas, but less to the development of attack pattern libraries. When we dynamically test web applications for security vulnerabilities, how good are the test cases we’re using?

Commercial web scanning tool vendors put significant research effort into this problem, but the product of this research is considered intellectual property and locked up inside the application. As users, in order to learn what kinds of test cases are being generated we would need to painstakingly record and analyze its traffic. At the time I initially released FuzzDB, most open source web fault injection tools had sets of test cases which were woefully incomplete and inadequate. There are too many permutations of symbols and encodings used in web protocols for anyone to reliably and repeatably recall all of them. As for the commercial tools, how complete are their sets of test cases, anyway? It’s not always easy to tell. What were they actually testing for? These tools aren’t just test case lists, they’re lists wrapped in complex sets of rules that determine which test cases to use when  and where. After considering these details, I had some doubts about the effectiveness of the typical application testing process.

My thoughts turned to increasing the speed and accuracy with which I could find certain classes of vulnerabilities during assessments. I began collecting, categorizing, and using lists of attack strings and of common file and directory names. Eventually I organized them into what is now FuzzDB and made it freely available under an Open Source license, the Creative Commons Attribution license.

As with any tool, an individual with malicious intent could potentially use FuzzDB in bad ways. However, I believe that it’s better to provide this information for the security of all. More importantly, if developers and testers have access to a good set of test cases, software will be released that has already passed this list of test cases.

That’s my ultimate goal for FuzzDB: for it to become obsolete as an attack tool because the applications become more secure. When applications and frameworks are inoculated against its patterns through testing and secure coding techniques, bad actors will no longer find the patterns in FuzzDB to be useful.

Predictable Resource Locations – Because there are a small number of popular server OS and infrastructure application packaging systems, resources such as logfiles and administrative directories are typically located in a small number of predictable locations. FuzzDB contains a comprehensive database of these, categorized by OS platform, web server, and  application. The intent is for a tester to use these lists to be able to make educated rather than brute-force guesses, significantly increasing the likelihood of successfully forcible browsing interesting and vulnerable resources. Also, they’re appropriate to be used in creating automated scanners as well as IDS/IPS signatures.

Attack Patterns – The attack pattern test-case sets are categorized by platform, language, and attack type. These are malicious and malformed inputs known to cause information leakage and exploitation. FuzzDB contains comprehensive lists of attack payloads known to cause issues like OS command injection, directory listings, directory traversals, source exposure, file upload bypass, authentication bypass, http header crlf injections, and more.

When I say “malicious inputs,” I mean it. Downloading the project may cause antivirus alerts or trigger pattern-based malicious code sensors. While FuzzDB is itself nothing but a collection of text files that are harmless on their own, some of the patterns included in the files have been used extensively in worms, malware, and other exploits.

Response Analysis – Since system responses also contain predictable strings, FuzzDB contains a set of regex pattern dictionaries such as interesting error messages to aid detection software security defects, lists of common Session ID cookie names, regex for numerous Personally Identifiable Information, and more.

Documentation – Helpful documentation and cheatsheets sourced from around the web that are relevant to the payload categories are provided.

Other useful stuff – Webshells, common password and username lists, and some handy wordlists.

You can browse it’s contents using Google Code’s Source browser.

• Web application penetration testing using popular penetration testing tools like OWASP Zap or Burp Suite
• A standard ZAP Intercepting Proxy add-on
• Building new automated scanners and automation-assisted manual penetration test tools
• Testing network services that use something other than HTTP semantics
• As malicious inputs for testing GUI or command-line software
• Using the patterns to make your open source or commercially licensed application better
• Identifying interesting responses to your probes. Here is a screenshot illustrating how this looks in Burp Suite
• Testing your IDS or IPS by using these test cases to “attack” your web server
• Testing during a bake-off of web security product vendors
• Testing a new custom web server or other network service for vulnerability to the patterns that have worked on one or more other platforms in the past
• Building intrusion identification and response systems
• Winning app security Capture the Flag competitions
• As a learning tool for better understanding various different malicious byte combinations which can cause the same vulnerability

If you’re using FuzzDB in a novel way, I’d love to hear about it!

The Future of FuzzDB