Using FuzzDB for Testing Website Security

amuntner

After posting an introduction to FuzzDB I received the suggestion to write more detailed walkthroughs of the data files and how they could be used during black-box web application penetration testing. This article highlights some of my favorite FuzzDB files and discusses ways I’ve used them in the past.

If there are particular parts or usages of FuzzDB you’d like to see explored in a future blog post, let me know.

Exploiting Local File Inclusion

Scenario: While testing a website you identify a Local File Inclusion (LFI) vulnerability. Considering the various ways of exploiting LFI bugs, there are several pieces of required information that FuzzDB can help us to identify. (There is a nice cheatsheet here:  http://websec.wordpress.com/2010/02/22/exploiting-php-file-inclusion-overview/)

The first is directory traversal: How far to traverse? How do the characters have to be encoded to bypass possible defensive relative path traversal blacklists, a common but poor security mechanism employed by many applications?
FuzzDB contains an 8 directory deep set of Directory Traversal attack  patterns  using various exotic URL encoding mechanisms: https://code.google.com/p/fuzzdb/source/browse/trunk/attack-payloads/path-traversal/traversals-8-deep-exotic-encoding.txt

For example:

/%c0%ae%c0%ae\{FILE}

/%c0%ae%c0%ae\%c0%ae%c0%ae\{FILE}

/%c0%ae%c0%ae\%c0%ae%c0%ae\%c0%ae%c0%ae/{FILE}

In your fuzzer, you’d replace {FILE} with a known file location appropriate to the type of system you’re testing, such as the string “etc/password” (for a UNIX system target) then review the output of the returned request responses to find responses indicating success, ie, that the targeted file has been successfully retrieved. In terms of workflow, try sorting the responses by number of bytes returned, the successful response will most become immediately apparent.

The cheatsheet discusses a method of including injected PHP code, but in order to do this, you need to be able to write to the server’s disk. Two places that the HTTPD daemon typically would have write permissions are the access and error logs.  FuzzDB contains a file of common location for HTTP server log files culled from popular distribution packages. After finding a working traversal string, configure your fuzzer to try these file locations, appended to the previously located working directory path:

https://code.google.com/p/fuzzdb/source/browse/trunk/attack-payloads/lfi/common-unix-httpd-log-locations.txt

Fuzzing for Unknown Methods

Improper Authorization occurs when an application doesn’t validate whether the current user context has permission to perform the requested command. One common presentation is in applications which utilize role-based access control, where the application uses the current user’s role in order to determine which menu options to display, but never validates that the chosen option is within the current user’s allowed permissions set. Using the application normally, a user would be unlikely to be able to select an option they weren’t allowed to use because it would never be presented. If an attacker were to learn these methods, they’d be able to exceed the expected set of permissions for their user role.
Many applications use human-readable values for application methods passed in parameters. FuzzDB contains list of common web method names can be fuzzed in an attempt to find functionality that may be available to the user but is not displayed by any menu.

https://code.google.com/p/fuzzdb/source/browse/trunk/attack-payloads/BizLogic/CommonMethods.fuzz.txt

These methods can be injected wherever you see others being passed, such as in GET and POST request parameter values, cookies, serialized requests, REST urls, and with web services.

Protip: In addition to this targeted brute-force approach it can also be useful to look inside the site’s Javascript files. If the site designers have deployed monolithic script files that are downloaded by all users regardless of permissions where the application pages displayed to a user only call the functions that are permitted for the current user role, you can sometimes find endpoints and methods that you haven’t observed while crawling the site.

Leftover Debug Functionality

Software sometimes gets accidentally deployed with leftover debug code. When triggered, the results can range from seeing extended error messages that reveal sensitive information about the application state or configuration that can be useful for helping to plan further attacks to bypassing authentication and/or authorization, or to displaying additional test functionality that could violate the integrity or confidentiality of data in ways that the developers didn’t intend to occur in a production scenario.

FuzzDB contains a list of debug parameters that have been observed in bug reports, in my own experience, and some which are totally hypothesized by me but realistic:
https://code.google.com/p/fuzzdb/source/browse/trunk/attack-payloads/BizLogic/DebugParams.fuzz.txt

Sample file content:

admin=1

admin=true

admin=y

admin=yes

adm=true

adm=y

adm=yes

dbg=1

dbg=true

dbg=y

dbg=yes

debug=1

debug=true

debug=y

debug=yes

“1” “true” “y” and “yes” are the most common values I’ve seen. If you observe a different but consistent scheme in use in the application you’re assessing, plug that in.

In practice, I’ve had luck using them as name/value pairs for GET requests, POST requests, as cookie name/value pairs, and inside serialized requests in order to elicit a useful response (for the tester) from the server.

Predictable File Locations

Application installer packages place components into known, predictable locations. FuzzDB contains lists of known file locations for many popular web servers and applications
https://code.google.com/p/fuzzdb/source/browse/trunk/#trunk%2Fdiscovery%2FPredictableRes

Example: You identify that the server you’re testing is running Apache Tomcat. A list of common locations for interesting default Tomcat files is used to identify information leakage and additional attackable functionality. https://code.google.com/p/fuzzdb/source/browse/trunk/discovery/PredictableRes/ApacheTomcat.fuzz.txt

Example: A directory called /admin is located. Sets of files are deployed which will aid in identifying resources likely to be in such a directory.

https://code.google.com/p/fuzzdb/source/browse/trunk/discovery/PredictableRes/Logins.fuzz.txt

Forcible Browsing for Potentially Interesting Files

Certain operating systems and file editors can inadvertently leave backup copies of sensitive files. This can end up revealing source code, pages without any inbound links, credentials, compressed backup files, and who knows what.
FuzzDB contains hundreds of common file extensions including one hundred eighty six compressed file format extensions, extensions commonly used for backup versions of files, and a set of primitives of “COPY OF” as can be prepended to filenames by Windows servers.

https://code.google.com/p/fuzzdb/source/browse/#svn%2Ftrunk%2Fdiscovery%2FFilenameBruteforce

In practice, you’d use these lists in your fuzzer in combination with filenames and paths discovered while crawling the targeted application.

Upcoming posts will discuss other usage scenarios.