Start Secure. Stay Secure.TM Web Application Testing with SPI Fuzzer Are your web applications vulnerable? By Sacha Faust Start Secure. Stay Secure.TM Web Application Testing with SPI Fuzzer Table of Contents Introduction HTTP Fuzzing Server Protocol Implementation Web Application SPI Fuzzer Creating a Fuzzing Scenario Basic Example Testing Validation Routines Testing Session State Randomness Testing for Buffer Overflows Conclusion The Business Case for Application Security About SPI Labs About SPI Dynamics About SPI ToolKitTM About the WebInspectTM Product Line About the Author Contact Information 1 1 4 4 5 10 10 17 21 30 33 33 33 34 34 35 35 35 © 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. ii Start Secure. Stay Secure.TM Web Application Testing with SPI Fuzzer Introduction "Fuzzing" is an automated software testing technique that generates and submits random or sequential data to various areas of an application in an attempt to uncover security vulnerabilities. For example, when searching for buffer overflows, a tester can simply generate data of various sizes and send it to one of the application entry points to observe how the application handles it. Fuzzing protocols is no different then fuzzing applications. Each protocol has its own set of parameters and structure that can be tested. For example, possible parameters for an HTTP request are the request method, Uniform Resource Identifier (URI), version, headers, cookies, post data, and other protocol components. When dealing with web applications, the main entry point is the request sent to the web server and its parameters (headers, cookies, query strings, post data, etc.). This white paper describes simple fuzzing scenarios to perform tests against web applications using the SPI Fuzzer, which is part of the SPI ToolKitTM product from SPI Dynamics, Inc. Readers are assumed to have a general knowledge of web application programming and should be familiar with the HTTP request and response structure for both HTTP/1.0 and HTTP/1.1. HTTP Fuzzing Web applications receive their input by reading sections of the HTTP request sent by the client to the server. When working with HTTP fuzzing, we generally focus on the following protocol components. © 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 1 Start Secure. Stay Secure.TM Web Application Testing with SPI Fuzzer Method The method simply indicates which command we want to perform on the resource identified by the Request-URI. The most commonly used methods are GET and POST. Request-URI The Request-URI specifies the resource to which we want to apply the request and the parameters we want to send to that resource. The resource location can be composed of a path, file, and file extension. The parameters are defined in a query string, with each parameter formatted as parameter=value and separated by an ampersand ( & ). The resource is separated from the query by a delimiter character (usually a question mark, although other characters can be used depending on the application). The Request-URL alone provides us with eight sections that could be fuzzed. They are: Section resource path resource file resource file extension resource and query delimiter parameter name parameter name value assignment parameter value parameter separator Example /folder/file.html /folder/file.html /folder/file.html /folder/file.html?parameter=value /folder/file.html?parameter=value /folder/file.html?parameter=value /folder/file.html?parameter=value /folder/file.html?parameter=value¶meter2=value2 © 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 2 Start Secure. Stay Secure.TM Web Application Testing with SPI Fuzzer Protocol Version The version indicates to the server which HTTP version to use for interpreting the request. Valid versions are 0.9, 1.0 and 1.1. The version information is formatted as "HTTP/version," which is a name-value pair separated by a forward slash ( / ). Based on this, we can conclude that we can fuzz three sections: Protocol Separator Version Header Fields Headers contain basic information issued by the client to help the server or application handle the request. Common headers are Host and User-Agent. Each header is defined by using the "header name: value" syntax. Again, this is a name-value structure that can be separated into three fuzzing structures. Cookies Cookies are special headers that contain parameters used by the application to manage users and states. The format of a cookie definition is Cookie: name=value;name=value Each parameter is a name-value pair that can be independently fuzzed. Post Data (Entity Body) While a query can be appended to the Request-URI, post data is added to the end of the request. The format is similar to the URI query and is mostly used with the POST method. When post data are used, the request must contain a Content-Length header that indicates the size of the post data. We can fuzz © 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 3 Start Secure. Stay Secure.TM Web Application Testing with SPI Fuzzer not only the post data, but also the Content-Length value to test how the server or application handles the differences. When fuzzing the HTTP request message, we affect two main layers of the application environment: server protocol implementation and web application. Server Protocol Implementation Since fuzzing the protocol consists of modifying request messages, the server will attempt to handle whatever we send. Changing the way requests are formatted can test the implementation's exception handling. Fuzzing various request options such as the method or version number can also reveal how well the implementation complies with RFC, or it can be used to test HTTP server fingerprinting. Areas that could impact the server implementation are: Method Resource location Version Headers Web Application The server will process the request and pass it to the application (either directly or indirectly) via an application container such as IBM WebSphere, BEA Weblogic, etc. The application will obtain parameters by accessing sections of the request and extracting the name-value pairs that define its options. By fuzzing some of the name-value pairs and manipulating the format, we can directly test the way the application handles exceptions. The following areas could directly test the application: © 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 4 Start Secure. Stay Secure.TM Web Application Testing with SPI Fuzzer Method Parameter Name and Value (present in various sections of the request; each section of the parameter definition can be fuzzed as well as the format in which it is represented) Post data content SPI Fuzzer SPI Fuzzer is a powerful tool that allows the user to create complex fuzzing scenarios for testing web applications and server implementation. The user can capture a raw request, identify a request section that appears susceptible to manipulation, and then insert a module that will generate parameter values and inject them into multiple HTTP request messages. The following procedure demonstrates how to test for a buffer overflow in the id parameter of the HTTP request. 1. Launch the Fuzzer. 2. Capture a URL. © 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 5 Start Secure. Stay Secure.TM Web Application Testing with SPI Fuzzer 3. Right-click the value assigned to the id parameter and select Generator from the shortcut menu. 4. The fuzzer contains several data generators. To insert characters to create a value for the id parameter, select Character Generator and click Configure. 5. Each generator has a unique set of options. The Character Generator allows you to define the length of the starting and ending character string © 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 6 Start Secure. Stay Secure.TM Web Application Testing with SPI Fuzzer it will generate, the contents of the string, and the increment to use each time a new string is requested. In this example, the first HTTP request sent by the Fuzzer will assign to the parameter id a value represented by a string of 500 A's (the character "A," whose ASCII value is decimal 65). The second request will assign to the parameter id a value represented by a string of 1,000 A's. The last request will assign to the parameter id a value represented by a string of 65,000 A's. 6. After inserting the generator, click OK. The Raw Editor displays the fuzzing scenario (with the character generator inserted). © 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 7 Start Secure. Stay Secure.TM Web Application Testing with SPI Fuzzer 7. Once the fuzzing scenario is created, click Start. The tool begins sending requests. To view a response (either the raw request or the HTML rendering) click an entry in the Sessions group. © 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 8 Start Secure. Stay Secure.TM Web Application Testing with SPI Fuzzer © 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 9 Start Secure. Stay Secure.TM Web Application Testing with SPI Fuzzer Creating a Fuzzing Scenario With a good understanding of the various sections that could be fuzzed, let's create simple fuzzing scenarios to test common features in web applications. Basic Example To demonstrate some of the basics of fuzzing, we will use a simple ASP .Net application that displays product information based on a product ID. The following illustration depicts a normal request and response. © 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 10 Start Secure. Stay Secure.TM Web Application Testing with SPI Fuzzer We will try to get information about products having an ID between 0 and 500 by fuzzing the value sent to the ID parameter. © 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 11 Start Secure. Stay Secure.TM Web Application Testing with SPI Fuzzer 1. Use the Raw Editor to insert a number generator as the id parameter value. 2. Then specify the parameters for generating the numbers zero through 500. © 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 12 Start Secure. Stay Secure.TM Web Application Testing with SPI Fuzzer For our testing, we also need to find a way to differentiate between valid and invalid product IDs. By examining the result of a normal request, we see that the application returns the price of the requested product using a decimal number followed by the dollar sign. This can be used to determine if we received a response containing product information. © 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 13 Start Secure. Stay Secure.TM Web Application Testing with SPI Fuzzer Performing the validation manually can be very time-consuming, so we will use filters inside the SPI Fuzzer. 3. To create a filter, select Edit from the Filters menu. The Filters dialog appears. 4. Click Add. 5. Enter the name, description, and rule as depicted in the following illustration. © 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 14 Start Secure. Stay Secure.TM Web Application Testing with SPI Fuzzer This filter is configured to flag only when the response body contains the "not found" string. The rule syntax is based on regular expressions that can be applied to the response sections defined below. Entire response: [ALL] Headers : [HEADERS] Status line: [STATUSLINE] Status Code: [STATUSCODE] Status description: [STATUSDESCRIPTION] Response body: [BODY] Cookies: [SETCOOKIES] © 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 15 Start Secure. Stay Secure.TM Web Application Testing with SPI Fuzzer 6. Select the Enable check box and click Apply. 7. Click OK. 8. On the SPI Fuzzer dialog, click the Filters menu and select Enable. 9. Click Start. © 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 16 Start Secure. Stay Secure.TM Web Application Testing with SPI Fuzzer The fuzzing sessions reveal that only product IDs 1 through 5 are valid within the range we specified. Using filters to sort the responses can be very useful when managing large fuzzing sessions. Testing Validation Routines When testing validation routines, we want to determine if a particular input is correctly validated before being used. This would reveal susceptibility to SQL injection or cross-site scripting, or simply the ability to crash the system. To test the input validation, we will fuzz the value sent to the id parameter and see how the application reacts. Since we already know that a value of 2 is valid, we will fuzz the parameter by appending printable ASCII characters between 32 and 126 inclusively (refer to http://www.asciitable.com/ for a list of ASCII values). To do this, we will use the Raw Editor to insert an ASCII Generator following the parameter value "2." The figures 9 to 11 below will demonstrate how to do this. 1. Place the cursor to the right of "id=2" and right-click to invoke a shortcut menu. 2. Select Generator. © 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 17 Start Secure. Stay Secure.TM Web Application Testing with SPI Fuzzer 3. Select ASCII Generator from the list of generators and click Configure. 4. Set the options as depicted in the following illustration, then click OK. © 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 18 Start Secure. Stay Secure.TM Web Application Testing with SPI Fuzzer Using the ASCII Generator, we will start generating ASCII characters 32 to 126, which represent the following printable characters: !"#$%&'()*+,./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]_` abcdefghijklmnopqrstuvwxyz{|}~ This fuzzing scenario generates request lines illustrated by the following examples: GET /Fuzzing/SimpleValidation.aspx?id=2a HTTP/1.0 GET /Fuzzing/SimpleValidation.aspx?id=2{ HTTP/1.0 GET /Fuzzing/SimpleValidation.aspx?id=2@ HTTP/1.0 GET /Fuzzing/SimpleValidation.aspx?id=2! HTTP/1.0 GET /Fuzzing/SimpleValidation.aspx?id=2, HTTP/1.0 © 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 19 Start Secure. Stay Secure.TM Web Application Testing with SPI Fuzzer Results Our testing yielded the following results: ASCII 32 to 47 and 58 to 126 The characters in this range are mostly punctuation characters. When they were injected into our request, the application returned Unable to get product id 2+ our input. We also found two exceptions that didn't return the same data: ASCII 59 (;) and ASCII 32 (white space). For these characters, the server returned the normal product information. In addition, when ASCII 39 (`) was injected, the application returned "Invalid product id specified." © 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 20 Start Secure. Stay Secure.TM Web Application Testing with SPI Fuzzer ASCII 48 to 57 Theses characters represent basic numbers and returned various product information as expected. Based on the results received by the application, we can make the following assumptions: · The application will display between "product id" and "was not found" the value we entered, which could indicate the possibility of cross-site scripting (XSS). · The application is handling the single quote character differently. This could be an indication that the application is escaping or looking for the presence of the character (which is often used to perform SQL injections). · The application doesn't seem to care about the semicolon character, which is used in SQL to separate multiple queries. The fact that we are getting the same results with or without the character might indicate that the application validation function may not look for this character, therefore allowing it. Since our input was 2; it would mean that no other query is defined and the database returns only results for a main query. Testing Session State Randomness Since the HTTP protocol is stateless, a web application must manage state manually. Many good off-the-shelf products are available that will make this task easier, but many web application developers still manage state manually because a commercial solution is beyond their budget or the solution doesn't fit their infrastructure. Web application state management basically relies on a unique identifier that is passed to the client and which the client sends back to the server when © 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 21 Start Secure. Stay Secure.TM Web Application Testing with SPI Fuzzer requesting a resource. Making sure that the unique identifier cannot be predicted is crucial because anyone who can predict or quickly generate a new state ID can hijack other user sessions and access their information. For example, guessing an online banking state ID would allow an attacker to impersonate another user. To demonstrate how to test for session state randomness and how to guess them, we will use a transactional site we found online. The application maintains state by setting a cookie named CustomerID that contains an eight-digit number. Set-Cookie: CustomerID=33270912 To analyze for randomness, we need to sample a few state IDs to determine if the number (or part of it) might be easy to predict. To do so using the SPI Fuzzer, we simply edit the folder (or directory) portion of the request and configure the ASCII Generator to generate the same folder name 100 times, thereby obtaining a decent sample of the CustomID cookie. To generate the folder, we configure the ASCII generator to use the character 47 ( / ), then instruct it to loop 99 times after its first run. 1. Using the Raw Editor, highlight the forward slash in the GET command. 2. Right-click and select Generator from the shortcut menu. 3. Select the ASCII Generator and click Configure. 4. Enter options to generate the ASCII character 47 (/) and force it to loop 100 times (0 to 99). © 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 22 Start Secure. Stay Secure.TM Web Application Testing with SPI Fuzzer Here is a sample of the results we obtained from the server. Set-Cookie: CustomerID=33333880 Set-Cookie: CustomerID=33333902 Set-Cookie: CustomerID=33334023 Set-Cookie: CustomerID=33334134 Set-Cookie: CustomerID=33334356 Based on this sample, we can quickly see that the first half of the CustomerID is always the same (3333) and that the second half seems to be in a range that could be predicted. Based on the information, we can assume that we could guess some of the state ID by fuzzing the second half of the number, so we will use the Number generator and generating values from 1489 to 2000. In addition, we will send our request to a page that will display information based on the state ID sent. The page selected is the one showing © 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 23 Start Secure. Stay Secure.TM Web Application Testing with SPI Fuzzer the user profile. This should allow us to identify if we have found a valid ID or not. 1. Using the Raw Editor, highlight the last four digits of the CustomerID. 2. Right-click and select Generator from the shortcut menu. 3. Select the Number generator, enter the options depicted in the following illustration, and click OK. © 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 24 Start Secure. Stay Secure.TM Web Application Testing with SPI Fuzzer 4. To differentiate between a valid and invalid state ID, we need to compare the responses from the server. Using the SPI HTTP Editor, we can send a custom request containing the valid CustomerID we received from the server and view the rendered HTML in the Browser panel. © 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 25 Start Secure. Stay Secure.TM Web Application Testing with SPI Fuzzer 5. Next, we send a request containing an invalid ID. The server returns the user to the CustomerLogin.asp page with a 302 redirect. © 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 26 Start Secure. Stay Secure.TM Web Application Testing with SPI Fuzzer 6. If we filter the 302 status code, we will quickly see if we can guess some of the state ID values. This can be done inside the SPI Fuzzer by creating a session filter that will flag only sessions that do not contain a status code of 302. © 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 27 Start Secure. Stay Secure.TM Web Application Testing with SPI Fuzzer One of the available default filters allows us to filter any response that is not indicating a redirect. We simply select this filter and enable it. 7. Click Start. After running our sessions, the tool shows a few sessions where it was able to generate 27 valid state IDs. Using the new state IDs we discovered, we have direct access to the accounts and can now masquerade as the user. © 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 28 Start Secure. Stay Secure.TM Web Application Testing with SPI Fuzzer Using the browser view, we can see the user information related to the CustomerID that we guessed (we obscured the user's e-mail address in this illustration.) © 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 29 Start Secure. Stay Secure.TM Web Application Testing with SPI Fuzzer Testing for Buffer Overflows The SPI Fuzzer can easily test for susceptibility to buffer overflows. We simply use the Character generator to inject large numbers of characters and then analyze the server's response. When an overflow is present, the server either returns any status code in the 500 range (usually a 500 Server Error or 502 Gateway Error) or the server will no longer respond to current or future requests. The application we will test is a product search CGI that uses the name parameter to find the product. We will insert from 50 to 5000 characters inside the name parameter, incrementing the value by 100 each time. We also need to use a filter that will show only server errors. Network errors are always displayed inside the session list. 1. Using the Raw Editor, place the cursor to the right of "name=" and then right-click and select Generator from the shortcut menu. © 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 30 Start Secure. Stay Secure.TM Web Application Testing with SPI Fuzzer 2. Select the Character generator, enter the options depicted in the following illustration, and click OK. 3. Enable the Server error filter to ensure that we will get any response indicating an error. © 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 31 Start Secure. Stay Secure.TM Web Application Testing with SPI Fuzzer Our testing reveals that the server returned a 502 Gateway Error in response to some of our requests, which is a good indication that the underlying application is not responding properly. To count the number of characters sent in a specific parameter can be annoying and time-consuming. The tool allows us to obtain a count by selecting the data sent in the name parameter, then right-clicking and selecting the Count menu.. © 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 32 Start Secure. Stay Secure.TM Web Application Testing with SPI Fuzzer Conclusion Performing simple and complex test scenarios by using fuzzing technologies can be a very effective way to test various aspects of your application. In addition, there is no limit to what can be fuzzed, so the concept can easily be adapted to any solution. Using this approach, complex fuzzing scenarios can be created and then replayed to determine how an application reacts. The Business Case for Application Security Whether a security breach is made public or confined internally, the fact that a hacker has accessed your sensitive data should be a huge concern to your company, your shareholders and, most importantly, your customers. SPI Dynamics has found that the majority of companies that are vigilant and proactive in their approach to application security are better protected. In the long run, these companies enjoy a higher return on investment for their ebusiness ventures. About SPI Labs SPI Labs is the dedicated application security research and testing team of SPI Dynamics. Composed of some of the industry's top security experts, SPI Labs is focused specifically on researching security vulnerabilities at the web application layer. The SPI Labs mission is to provide objective research to the security community and all organizations concerned with their security practices. SPI Dynamics uses direct research from SPI Labs to provide daily updates to WebInspect, the leading Web application security assessment software. SPI Labs engineers comply with the standards proposed by the Internet Engineering Task Force (IETF) for responsible security vulnerability disclosure. SPI Labs policies and procedures for disclosure are outlined on the SPI Dynamics web site at: http://www.spidynamics.com/spilabs.html. © 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 33 Start Secure. Stay Secure.TM Web Application Testing with SPI Fuzzer About SPI Dynamics SPI Dynamics, the expert in web application security assessment, provides software and services to help enterprises protect against the loss of confidential data through the web application layer. The company's flagship product, WebInspect, assesses the security of an organization's applications and web services, the most vulnerable yet least secure IT infrastructure component. Since its inception, SPI Dynamics has focused exclusively on web application security. SPI Labs, the internal research group of SPI Dynamics, is recognized as the industry's foremost authority in this area. Software developers, quality assurance professionals, corporate security auditors and security practitioners use WebInspect products throughout the application lifecycle to identify security vulnerabilities that would otherwise go undetected by traditional measures. The security assurance provided by WebInspect helps Fortune 500 companies and organizations in regulated industries -- including financial services, health care and government -- protect their sensitive data and comply with legal mandates and regulations regarding privacy and information security. SPI Dynamics is privately held with headquarters in Atlanta, Georgia. About SPI ToolKitTM SPI Dynamics' SPI ToolKitTM product is the first and only comprehensive set of tools for penetration testers to test a web application's susceptibility to exploits. SPI ToolKit consists of tools that allow penetration testers to manually test web applications at a more advanced, in-depth degree than possible with automated vulnerability assessment tools. With a wide-ranging array of tools, pen testers can identify critical vulnerabilities by engaging specific attempts at penetrating the web application. SPI ToolKit users benefit from a commercially supported product that ensures reliability, updates, and © 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 34 Start Secure. Stay Secure.TM Web Application Testing with SPI Fuzzer ease-of-use. Customers can also supplement WebInspect Enterprise Edition's existing tools with the addition of more advanced tools that simplify complex testing methods such as SQL injection, cookie analysis, and HTTP fuzzing. About the WebInspectTM Product Line The WebInspectTM product line ensures the security of your entire network with intuitive, intelligent, and accurate processes that dynamically scan standard and proprietary web applications to identify known and unidentified application vulnerabilities. With WebInspect products, you find and correct vulnerabilities at their source, before attackers can exploit them. Whether you are an application developer, security auditor, QA professional or security consultant, WebInspect provides the tools you need to ensure the security of your web applications through a powerful combination of unique Adaptive-AgentTM technology and SPI Dynamics' industry-leading and continuously updated vulnerability database, SecureBaseTM. Through Adaptive-Agent technology, you can quickly and accurately assess the security of your web content, regardless of your environment. About the Author Sacha Faust is a senior research and development engineer at SPI Dynamics, where his responsibilities include managing the SPI Labs team, researching new techniques for Web auditing, conducting source code reviews to find vulnerabilities, and securing Web applications. Contact Information SPI Dynamics 115 Perimeter Center Place Suite 1100 Atlanta, GA 30346 Telephone: (678) 781-4800 Fax: (678) 781-4850 Email: info@spidynamics.com Web: www.spidynamics.com © 2005 SPI Dynamics, Inc. All Rights Reserved. No reproduction or redistribution without written permission. 35