https://wiki.owasp.org/api.php?action=feedcontributions&user=Jtpereyda&feedformat=atomOWASP - User contributions [en]2024-03-28T08:18:14ZUser contributionsMediaWiki 1.27.2https://wiki.owasp.org/index.php?title=OWASP_Portland_2018_Training_Day&diff=242577OWASP Portland 2018 Training Day2018-08-15T21:31:05Z<p>Jtpereyda: add date to first paragraph</p>
<hr />
<div>For the third year in a row, the Portland OWASP chapter is proud to host our information security training day! This is be an excellent opportunity for those interested to receive top quality information security and application security training for prices far lower than normally offered. It's also a great chance to network with the local infosec community and meet those who share your interests. <br />
<br />
OWASP Portland 2018 Training Day will be '''October 3, 2018.''' See [[#Details|Details]] for more info.<br />
<br />
Want to get news and information on our 2018 Training Day? Subscribe to the Portland OWASP mailing list or follow @PortlandOWASP on Twitter!<br />
<br />
=Courses=<br />
Courses will be held in two tracks: four in the morning session, and four in the afternoon session. Each participant can register for one morning course, or one afternoon course, or one of each. <br />
<br />
== Morning Session 8:30 AM - Noon ==<br />
<br />
=== Intro to Hacking Web 3.0 ===<br />
<br />
''Instructor: Mick Ayzenberg''<br />
<br />
Abstract: In this half day course, we will introduce several emerging Blockchain concepts such as Web 3.0, smart contracts, and decentralized applications (DApps). You will get the opportunity to explore and interact with applications on this platform, and will be introduced to several of the most common vulnerability categories found in smart contracts through a capture the flag platform. This class will be highly interactive, so bring a laptop. No previous Blockchain experience required.<br />
<br />
=== Introduction to Computer Forensics ===<br />
<br />
''Instructor: Kris Rosenberg''<br />
<br />
Abstract: It’s 3AM and the phone rings… ok, maybe not 3AM, but you get the call that a computer system on your network is acting strange. After taking a look you realize that this system may be infected with malware, or possibly you have an active intruder inside your network. What do you do next? This session will guide you through the basic initial steps that can be taken in a security incident to effectively isolate and contain the attack and collect evidence for potential future prosecution. We will introduce the PICERL framework for incident handling and discuss each phase in detail: Planning, Identification, Containment, Eradication, Recovery, and Lessons Learned. At the end of the session you should have a basic understanding of how to respond to a potential security incident, and preserve any evidence that may be needed.<br />
<br />
=== Intro to Practical Internal Vulnerability Scanning ===<br />
<br />
==== Sponsored by Summit Security Group, LLC ====<br />
<br />
''Instructor: Patterson Cake''<br />
<br />
Abstract: If your organization has the resources to scan all of the things all of the time, this course may not be for you! If, however, you are like most organizations, struggling to keep up and to make tangible progress towards improving your security posture, read on! In this course, we'll discuss scanning tools and techniques to help you identify unknown devices, sensitive data exposure, and system misconfigurations within your environment, using open-source and built-in tools, like Nmap and PowerShell, along with some good old-fashioned NI (Natural Intelligence). We'll focus on practical, tactical ways to find things like unapproved IoT devices on your network, sensitive data shares with "Everyone" permissions, and web apps with default credentials, things you care about which are often easy to remediate but may not show up on traditional vulnerability or compliance scans.<br />
<br />
Prerequisites: Laptop capable of running a recent version of Nmap (Windows, Linux or Mac) with admin/root privileges.<br />
<br />
=== Incident Handling in Cloud Environment - a primer ===<br />
<br />
==== Sponsored by ForgeRock ====<br />
<br />
''Instructor: Derek Hill''<br />
<br />
Abstract: Have you ever wondered what it takes to investigate an incident inside your company network? What about your assets stored in a public cloud? When does an event become an incident? Who decides this? We will cover the important steps of an incident handling process, including getting you started in creating your own incident handling plan. We will talk about the challenges of doing this in cloud, where you don't have physical access to the machines. You will walk away with an understanding of the fundamental steps of incident handling as well as some examples of what to look for, how to handle collection and preservation of evidence.<br />
<br />
== Afternoon Session: 1:30 PM - 5:00 PM ==<br />
<br />
=== Advanced Application Security Testing ===<br />
<br />
''Instructor: Timothy Morgan''<br />
<br />
Abstract: This course takes students beyond the most basic web application exploitation scenarios, focusing on advanced SQL injection, XML eXternal Entities (XXE) and server-side request forgery (SSRF) attacks. The course also covers out-of-band detection and exfiltration using the DNS, which has recently become a popular technique used by penetration testers.<br />
<br />
=== AppSec Testing Beyond Pen Test ===<br />
<br />
''Instructor: Bhushan Gupta''<br />
<br />
Abstract: Most web application security testing efforts are concentrated around penetration testing, which is an art based on hackers’ psyche, thought process, and determination to exploit software vulnerabilities. However, does it yield a high level of confidence and sense of security in a developer’s mind? The web application developers must begin to think of building security throughout the software development life cycle (SDLC). This workshop paper focuses on an approach that aligns the web application security testing with the three basic principles of security; confidentiality, integrity, and availability (CIA). Using a simple approach, workshop teaches how to identify the most vulnerable processes in an application, highlighting the test-intensive areas. The students will learn:<br />
# How to identify the security requirements for their business <br />
# How to plan security testing using both statics and dynamic code analysis<br />
# How to apply STRIDE model to evaluate critical web application components<br />
# How to prioritizing vulnerabilities based upon DREAD model to minimize breech impact<br />
<br />
=== Applied Physical Attacks on Embedded Systems, Introductory Version ===<br />
<br />
''Instructor: Joe FitzPatrick''<br />
<br />
Abstract: This workshop introduces several different relatively accessible interfaces on embedded systems. Attendees will get hands-on experience with UART, SPI, and JTAG interfaces on a MIPS-based wifi router. After a brief architectural overview of each interface, hands-on labs will guide through the process understanding, observing, interacting with, and exploiting the interface to potentially access a root shell on the target.<br />
<br />
=== Advanced Custom Network Protocol Fuzzing ===<br />
<br />
==== Sponsored by Oracle Cloud Infrastructure ====<br />
<br />
''Instructor: Joshua Pereyda''<br />
<br />
Abstract: Get hands on experience writing custom network protocol fuzzers. This class will cover the basics of network protocol ""smart fuzzing."" Exercises will utilize the open source network protocol fuzzing framework, boofuzz. Attendees will gain practice reverse engineering a network protocol, implementing and iterating on a custom fuzzer, and identifying vulnerabilities. After the course:<br />
<br />
# You will know the basics of fuzzing.<br />
# You will know how to write custom network protocol fuzzers using state of the art open source tools.<br />
# You will have hands on experience with this widely-discussed but still largely mysterious test method.<br />
<br />
=Sponsors=<br />
<br />
'''Interested in becoming a sponsor? Watch this space for 2018 sponsorship information!'''<br />
<br />
=== Mixer Sponsors===<br />
<br />
[[File:github.png|link=https://github.com/]]<br />
<br />
=== Training Session Sponsors ===<br />
<br />
[[File:newrelic.png|link=https://newrelic.com/]]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
[[File:summit.png|link=http://summitinfosec.com/]]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
[[File:OCI Logo.png|link=https://cloud.oracle.com/en_US/iaas]]<br />
<br />
=== Morning Coffee Sponsors ===<br />
<br />
[[File:OCI Logo.png|link=https://cloud.oracle.com/en_US/iaas]] <br />
<br />
=== General Sponsors ===<br />
<br />
[[File:simple.png|link=https://simple.com/]]<br />
<br />
=Details=<br />
OWASP Portland 2018 Training Day will be October 3, 2018. This year we'll be located at:<br />
<br />
World Trade Center Portland<br />
121 SW Salmon St.<br />
Portland, OR 97204. <br />
<br />
Later in the evening, a social mixer will also be held at Rock Bottom Restaurant & Brewery, just a short walk away:<br />
<br />
206 SW Morrison St<br />
Portland, OR 97204<br />
<br />
===Schedule===<br />
{| class="wikitable"<br />
! |Time<br />
! colspan="4" |Activity<br />
|-<br />
| style="padding: 0.5em;" |8:00 AM - 8:30 AM<br />
| colspan="4" style="padding: 0.5em;" |Morning Registration and Continental Breakfast<br />
|-<br />
| style="padding: 0.5em;" |8:30 AM - 12:00 PM<br />
| style="padding: 0.5em;" |Intro to Hacking Web 3.0 <br>(Mick Ayzenberg)<br />
| style="padding: 0.5em;" |Introduction to Computer Forensics <br>(Kris Rosenberg)<br />
| style="padding: 0.5em;" |Intro to Practical Internal Vulnerability Scanning <br>(Patterson Cake)<br />
| style="padding: 0.5em;" |Incident Handling in Cloud Environment - a primer <br>(Derek Hill)<br />
|-<br />
| style="padding: 0.5em;" |12:00 PM - 1:30 PM<br />
| colspan="4" style="padding: 0.5em;" | Lunch on your own - ''Meet a new friend and grab a bite!''<br />
|-<br />
| style="padding: 0.5em;" |1:00 PM - 1:30 PM<br />
| colspan="4" style="padding: 0.5em;" | Afternoon Registration (for those attending only in the afternoon)<br />
|-<br />
| style="padding: 0.5em;" |1:30 PM - 5:00 PM<br />
| style="padding: 0.5em;" |Advanced Application Security Testing <br>(Timothy Morgan)<br />
| style="padding: 0.5em;" |AppSec Testing Beyond Pen Test <br>(Bhushan Gupta)<br />
| style="padding: 0.5em;" |Applied Physical Attacks on Embedded Systems, Introductory Version <br>(Joe FitzPatrick)<br />
| style="padding: 0.5em;" |Advanced Custom Network Protocol Fuzzing <br>(Joshua Pereyda)<br />
|-<br />
| style="padding: 0.5em;" |5:00 PM - 7:30 PM<br />
| colspan="4" style="padding: 0.5em;" | Evening Mixer @ Rock Bottom Restaurant and Brewery<br />
|}<br />
<br />
=== Lunch Ideas ===<br />
<br />
Lunch ideas for 2018 coming soon!<br />
<br />
=How to Register=<br />
Registration information and dates coming soon!</div>Jtpereydahttps://wiki.owasp.org/index.php?title=Web_Application_Firewall&diff=222483Web Application Firewall2016-10-18T23:33:30Z<p>Jtpereyda: Clearing up clutter</p>
<hr />
<div>=Description=<br />
A '''web application firewall (WAF)''' is an [https://en.wikipedia.org/wiki/Application_firewall application firewall] for HTTP applications. It applies a set of rules to an HTTP conversation. Generally, these rules cover common attacks such as [[Cross-site Scripting (XSS)|cross-site scripting (XSS)]] and [[SQL Injection|SQL injection]].<br />
<br />
While proxies generally protect clients, WAFs protect servers. A WAF is deployed to protect a specific web application or set of web applications. A WAF can be considered a [https://en.wikipedia.org/wiki/Reverse_proxy reverse proxy].<br />
<br />
WAFs may come in the form of an appliance, server plugin, or filter, and may be customized to an application. The effort to perform this customization can be significant and needs to be maintained as the application is modified.<br />
<br />
= OWASP Projects =<br />
* The [https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project OWASP ModSecurity CRS Project's] goal is to provide an easily "pluggable" set of generic attack detection rules that provide a base level of protection for any web application.<br />
* Consider the [https://www.owasp.org/index.php/WASC_OWASP_Web_Application_Firewall_Evaluation_Criteria_Project Web Application Firewall Evaluation Criteria Project (WAFEC)] to help evaluate commercial and open source web application firewalls.<br />
<br />
= References =<br />
* https://en.wikipedia.org/wiki/Web_application_firewall<br />
<br />
[[Category: OWASP WAF]]</div>Jtpereydahttps://wiki.owasp.org/index.php?title=Web_Application_Firewall&diff=222482Web Application Firewall2016-10-18T23:16:00Z<p>Jtpereyda: /* Description */ Adding clarifying info comparing with proxies and reverse proxies. Source: http://security.stackexchange.com/a/93847/5997</p>
<hr />
<div>=Description=<br />
A '''web application firewall (WAF)''' is an appliance, server plugin, or filter that applies a set of rules to an HTTP conversation. Generally, these rules cover common attacks such as [[Cross-site Scripting (XSS)|cross-site scripting (XSS)]] and [[SQL Injection|SQL injection]].<br />
<br />
A WAF differs from a proxy in that proxies protect clients, while WAFs protect servers. A WAF is deployed to protect a specific web application or set of web applications. A WAF can be considered a [https://en.wikipedia.org/wiki/Reverse_proxy reverse proxy].<br />
<br />
WAFs may be customized to an application. The effort to perform this customization can be significant and needs to be maintained as the application is modified.<br />
<br />
<br />
A far more detailed description is available at [https://en.wikipedia.org/wiki/Application_firewall Wikipedia].<br />
<br />
= OWASP Projects =<br />
<br />
* The [https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project OWASP ModSecurity CRS Project's] goal is to provide an easily "pluggable" set of generic attack detection rules that provide a base level of protection for any web application.<br />
* Consider the [https://www.owasp.org/index.php/WASC_OWASP_Web_Application_Firewall_Evaluation_Criteria_Project Web Application Firewall Evaluation Criteria Project (WAFEC)] to help evaluate commercial and open source web application firewalls. <br />
<br />
[[Category: OWASP WAF]]<br />
<br />
= References =<br />
*https://en.wikipedia.org/wiki/Application_firewall</div>Jtpereydahttps://wiki.owasp.org/index.php?title=Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet&diff=222381Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet2016-10-12T22:18:33Z<p>Jtpereyda: Moving intro before TOC to match typical Wiki style. Likewise, removed Introduction header.</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-<br />
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}''' <br />
<br />
[[Cross-Site Request Forgery (CSRF)]] is a type of attack that occurs when a malicious web site, email, blog, instant message, or program causes a user’s web browser to perform an unwanted action on a trusted site for which the user is currently authenticated. The impact of a successful CSRF attack is limited to the capabilities exposed by the vulnerable application. For example, this attack could result in a transfer of funds, changing a password, or purchasing an item in the user's context. In effect, CSRF attacks are used by an attacker to make a target system perform a function via the target's browser without knowledge of the target user, at least until the unauthorized transaction has been committed.<br />
<br />
Impacts of successful CSRF exploits vary greatly based on the privileges of each victim. When targeting a normal user, a successful CSRF attack can compromise end-user data and their associated functions. If the targeted end user is an administrator account, a CSRF attack can compromise the entire web application. Sites that are more likely to be attacked by CSRF are community websites (social networking, email) or sites that have high dollar value accounts associated with them (banks, stock brokerages, bill pay services). Utilizing social engineering, an attacker can embed malicious HTML or JavaScript code into an email or website to request a specific 'task URL'. The task then executes with or without the user's knowledge, either directly or by utilizing a Cross-Site Scripting flaw (ex: Samy MySpace Worm).<br />
<br />
For more information on CSRF, please see the OWASP [[Cross-Site Request Forgery (CSRF)]] page.<br />
<br />
__TOC__{{TOC hidden}}<br />
<br />
== Warning: No Cross-Site Scripting (XSS) Vulnerabilities ==<br />
<br />
[[Cross-Site Scripting]] is not necessary for CSRF to work. However, any cross-site scripting vulnerability can be used to defeat token, Double-Submit cookie, referer and origin based CSRF defenses. This is because an XSS payload can simply read any page on the site using a XMLHttpRequest and obtain the generated token from the response, and include that token with a forged request. This technique is exactly how the [http://en.wikipedia.org/wiki/Samy_(XSS) MySpace (Samy) worm] defeated MySpace's anti-CSRF defenses in 2005, which enabled the worm to propagate. XSS cannot defeat challenge-response defenses such as Captcha, re-authentication or one-time passwords. It is imperative that no XSS vulnerabilities are present to ensure that CSRF defenses can't be circumvented. Please see the OWASP [[XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet | XSS Prevention Cheat Sheet]] for detailed guidance on how to prevent XSS flaws.<br />
<br />
<br />
= General Recommendations For Automated CSRF Defense =<br />
<br />
We recommend two separate checks as your standard CSRF defense that does not require user intervention. This discussion ignores for the moment deliberately allowed cross origin requests (e.g., CORS). Your defenses will have to adjust for that if that is allowed.<br />
<br />
# Check standard headers to verify the request is same origin<br />
# AND Check CSRF token<br />
<br />
Each of these is discussed next.<br />
<br />
== Verifying Same Origin with Standard Headers ==<br />
<br />
There are two steps to this check:<br />
<br />
# Determining the origin the request is coming from (source origin)<br />
# Determining the origin the request is going to (target origin)<br />
<br />
=== Identifying Source Origin ===<br />
<br />
To determine the source origin, we recommend using one of these two standard headers that almost all requests include one or both of:<br />
<br />
* Origin Header<br />
* Referer Header<br />
<br />
Although it is trivial to spoof any header from your own browser, it is generally impossible to do so in a CSRF attack, except via an XSS vulnerability. That's why checking headers is a reasonable first step in your CSRF defense, but since they aren't always present, its generally not considered a sufficient defense on its own.<br />
<br />
==== Checking The Origin Header ====<br />
If the Origin header is present, verify its value matches the target origin. The [https://wiki.mozilla.org/Security/Origin Origin HTTP Header] standard was introduced as a method of defending against CSRF and other Cross-Domain attacks. Unlike the Referer, the Origin header will be present in HTTP requests that originate from an HTTPS URL. If the Origin header is present, then it should be checked to make sure it matches the target origin.<br />
<br />
This defense technique is specifically proposed in section 5.0 of [https://seclab.stanford.edu/websec/csrf/csrf.pdf Robust Defenses for Cross-Site Request Forgery]. This paper proposes the creation of the Origin header and its use as a CSRF defense mechanism.<br />
<br />
==== Checking The Referer Header ====<br />
If the Origin header is not present, verify the hostname in the Referer header matches the target origin. Checking the Referer is a commonly used method of preventing CSRF on embedded network devices because it does not require any per-user state. This makes a Referer a useful method of CSRF prevention when memory is scarce or server-side state doesn't exist. This method of CSRF mitigation is also commonly used with unauthenticated requests, such as requests made prior to establishing a session state which is required to keep track of a synchronization token. <br />
<br />
In both cases, just make sure the target origin check is strong. For example, if your site is "site.com" make sure "site.com.attacker.com" doesn't pass your origin check (i.e., match through the trailing / after the origin to make sure you are matching against the entire origin).<br />
<br />
==== What to do when Both Origin and Referer Headers Aren't Present ====<br />
<br />
If neither of these headers is present, which should be VERY rare, you can either accept or block the request. We recommend blocking, particularly if you aren't using a random CSRF token as your second check. You might want to log when this happens for a while and if you basically never see it, start blocking such requests.<br />
<br />
=== Identifying The Target Origin ===<br />
<br />
You might think its easy to determine the target origin, but its frequently not. The first thought is to simply grab the target origin (i.e., its hostname and port #) from the URL in the request. However, the application server is frequently sitting behind one or more proxies and the original URL is different from the URL the app server actually receives. If your application server is directly accessed by its users, then using the origin in the URL is fine and you're all set.<br />
<br />
==== Determining The Target Origin When Behind a Proxy ====<br />
<br />
If you are behind a proxy, there are a number of options to consider:<br />
<br />
# Configure your application to simply know its target origin<br />
# Use the Host header value<br />
# Use the X-Forwarded-Host header value<br />
<br />
Its your application, so clearly you can figure out its target origin and set that value in some server configuration entry. This would be the most secure approach as its defined server side so is a trusted value. However, this can be problematic to maintain if your application is deployed in many different places, e.g., dev, test, QA, production, and possibly multiple production instances. Setting the correct value for each of these situations can be difficult, but if you can do it, that's great.<br />
<br />
If you would prefer the application figure it out on its own, so it doesn't have to be configured differently for each deployed instance, we recommend using the Host family of headers. The Host header's purpose is to contain the target origin of the request. But, if your app server is sitting behind a proxy, the Host header value is most likely changed by the proxy to the target origin of the URL behind the proxy, which is different than the original URL. This modified Host header origin won't match the source origin in the original Origin or Referer headers.<br />
<br />
However, there is another header called X-Forwarded-Host, whose purpose is to contain the original Host header value the proxy received. Most proxies will pass along the original Host header value in the X-Forwarded-Host header. So that header value is likely to be the target origin value you need to compare to the source origin in the Origin or Referer header.<br />
<br />
=== Verifying the Two Origins Match ===<br />
<br />
Once you've identified the source origin (from either the Origin or Referer header), and you've determined the target origin, however you choose to do so, then you can simply compare the two values and if they don't match you know you have a cross-origin request.<br />
<br />
== CSRF Specific Defense ==<br />
<br />
Once you have verified that the request appears to be a same origin request so far, we recommend a second check as an additional precaution to really make sure. This second check can involve custom defense mechanisms using CSRF specific tokens created and verified by your application or can rely on the presence of other HTTP headers depending on the level of rigor/security you want.<br />
<br />
There are numerous ways you can specifically defend against CSRF. We recommend using one of the following (in ADDITION to the check recommended above):<br />
<br />
1. Synchronizer (i.e.,CSRF) Tokens (requires session state)<br />
<br />
Approaches that do require no server side state:<br />
<br />
2. Double Cookie Defense<br /><br />
3. Encrypted Token Pattern<br /><br />
4. Custom Header - e.g., X-Requested-With: XMLHttpRequest<br />
<br />
These are listed in order of strength of defense. So use the strongest defense that makes sense in your situation.<br />
<br />
=== Synchronizer (CSRF) Tokens ===<br />
<br />
* Any state changing operation requires a secure random token (e.g., CSRF token) to prevent CSRF attacks<br />
* Characteristics of a CSRF Token<br />
** Unique per user session<br />
** Large random value<br />
** Generated by a cryptographically secure random number generator <br />
* The CSRF token is added as a hidden field for forms or within the URL if the state changing operation occurs via a GET<br />
* The server rejects the requested action if the CSRF token fails validation<br />
<br />
In order to facilitate a "transparent but visible" CSRF solution, developers are encouraged to adopt the Synchronizer Token Pattern (http://www.corej2eepatterns.com/Design/PresoDesign.htm). The synchronizer token pattern requires the generating of random "challenge" tokens that are associated with the user's current session. These challenge tokens are then inserted within the HTML forms and links associated with sensitive server-side operations. When the user wishes to invoke these sensitive operations, the HTTP request should include this challenge token. It is then the responsibility of the server application to verify the existence and correctness of this token. By including a challenge token with each request, the developer has a strong control to verify that the user actually intended to submit the desired requests. Inclusion of a required security token in HTTP requests associated with sensitive business functions helps mitigate CSRF attacks as successful exploitation assumes the attacker knows the randomly generated token for the target victim's session. This is analogous to the attacker being able to guess the target victim's session identifier. The following synopsis describes a general approach to incorporate challenge tokens within the request.<br />
<br />
When a Web application formulates a request (by generating a link or form that causes a request when submitted or clicked by the user), the application should include a hidden input parameter with a common name such as "CSRFToken". The value of this token must be randomly generated such that it cannot be guessed by an attacker. Consider leveraging the java.security.SecureRandom class for Java applications to generate a sufficiently long random token. Alternative generation algorithms include the use of 256-bit BASE64 encoded hashes. Developers that choose this generation algorithm must make sure that there is randomness and uniqueness utilized in the data that is hashed to generate the random token.<br />
<br />
<form action="/transfer.do" method="post"><br />
<input type="hidden" name="CSRFToken" <br />
value="OWY4NmQwODE4ODRjN2Q2NTlhMmZlYWE...<br />
wYzU1YWQwMTVhM2JmNGYxYjJiMGI4MjJjZDE1ZDZ...<br />
MGYwMGEwOA=="><br />
…<br />
</form><br />
<br />
In general, developers need only generate this token once for the current session. After initial generation of this token, the value is stored in the session and is utilized for each subsequent request until the session expires. When a request is issued by the end-user, the server-side component must verify the existence and validity of the token in the request as compared to the token found in the session. If the token was not found within the request or the value provided does not match the value within the session, then the request should be aborted, token should be reset and the event logged as a potential CSRF attack in progress.<br />
<br />
To further enhance the security of this proposed design, consider randomizing the CSRF token parameter name and/or value for each request. Implementing this approach results in the generation of per-request tokens as opposed to per-session tokens. Note, however, that this may result in usability concerns. For example, the "Back" button browser capability is often hindered as the previous page may contain a token that is no longer valid. Interaction with this previous page will result in a CSRF false positive security event at the server. Regardless of the approach taken, developers are encouraged to protect the CSRF token the same way they protect authenticated session identifiers, such as the use of TLS.<br />
<br />
==== Existing Synchronizer Implementations ====<br />
<br />
Synchronizer Token defenses have been built into many frameworks so we strongly recommend using them first when they are available. External components that add CSRF defenses to existing applications also exist and are recommended. OWASP has two:<br />
<br />
# For Java: OWASP [[CSRF Guard]]<br />
# For PHP and Apache: [[CSRFProtector Project]]<br />
<br />
==== Disclosure of Token in URL ====<br />
<br />
Many implementations of synchronizer tokens include the challenge token in GET (URL) requests as well as POST requests. This is often implemented as a result of sensitive server-side operations being invoked as a result of embedded links in the page or other general design patterns. These patterns are often implemented without knowledge of CSRF and an understanding of CSRF prevention design strategies. While this control does help mitigate the risk of CSRF attacks, the unique per-session token is being exposed for GET requests. CSRF tokens in GET requests are potentially leaked at several locations: browser history, HTTP log files, network appliances that make a point to log the first line of an HTTP request, and Referer headers if the protected site links to an external site.<br />
<br />
In the latter case (leaked CSRF token due to the Referer header being parsed by a linked site), it is trivially easy for the linked site to launch a CSRF attack on the protected site, and they will be able to target this attack very effectively, since the Referer header tells them the site as well as the CSRF token. The attack could be run entirely from JavaScript, so that a simple addition of a script tag to the HTML of a site can launch an attack (whether on an originally malicious site or on a hacked site). Additionally, since HTTPS requests from HTTPS contexts will not strip the Referer header (as opposed to HTTPS to HTTP requests) CSRF token leaks via Referer can still happen on HTTPS Applications.<br />
<br />
The ideal solution is to only include the CSRF token in POST requests and modify server-side actions that have state changing affect to only respond to POST requests. This is in fact what the [http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.1 RFC 2616] requires for GET requests. If sensitive server-side actions are guaranteed to only ever respond to POST requests, then there is no need to include the token in GET requests.<br />
<br />
In most JavaEE web applications, however, HTTP method scoping is rarely ever utilized when retrieving HTTP parameters from a request. Calls to "HttpServletRequest.getParameter" will return a parameter value regardless if it was a GET or POST. This is not to say HTTP method scoping cannot be enforced. It can be achieved if a developer explicitly overrides doPost() in the HttpServlet class or leverages framework specific capabilities such as the AbstractFormController class in Spring.<br />
<br />
For these cases, attempting to retrofit this pattern in existing applications requires significant development time and cost, and as a temporary measure it may be better to pass CSRF tokens in the URL. Once the application has been fixed to respond to HTTP GET and POST verbs correctly, CSRF tokens for GET requests should be turned off.<br />
<br />
==== ASP.NET, MVC and .NET Web Pages ====<br />
<br />
.NET provides comprehensive CSRF defense. For more information visit the following resources.<br />
* https://msdn.microsoft.com/en-us/library/ms972969.aspx#securitybarriers_topic2<br />
* http://software-security.sans.org/developer-how-to/developer-guide-csrf<br />
<br />
=== Double Submit Cookie ===<br />
<br />
If storing the CSRF token in session is problematic, an alternative defense is use of a double submit cookie. A double submit cookie is defined as sending a random value in both a cookie and as a request parameter, with the server verifying if the cookie value and request value match. <br />
<br />
When a user authenticates to a site, the site should generate a (cryptographically strong) pseudorandom value and set it as a cookie on the user's machine separate from the session id. The site does not have to save this value in any way, thus avoiding server side state. The site then requires that every transaction request include this random value as a hidden form value (or other request parameter). A cross origin attacker cannot read any data sent from the server or modify cookie values, per the same-origin policy. This means that while an attacker can force a victim to send any value he wants with a malicious CSRF request, the attacker will be unable to modify or read the value stored in the cookie. Since the cookie value and the request parameter or form value must be the same, the attacker will be unable to successfully force the submission of a request with the random CSRF value.<br />
<br />
As an example, the [http://directwebremoting.org Direct Web Remoting (DWR)] Java library version 2.0 has CSRF protection built in that implements the double cookie submission transparently.<br />
<br />
=== Encrypted Token Pattern ===<br />
<br />
The Encrypted Token Pattern leverages an encryption, rather than comparison, method of Token-validation. After successful authentication, the server generates a unique Token comprised of the user's ID, a timestamp value and a [http://en.wikipedia.org/wiki/Cryptographic_nonce nonce], using a unique key available only on the server. This Token is returned to the client and embedded in a hidden field. Subsequent AJAX requests include this Token in the request-header, in a similar manner to the Double-Submit pattern. Non-AJAX form-based requests will implicitly persist the Token in its hidden field. On receipt of this request, the server reads and decrypts the Token value with the same key used to create the Token. Inability to correctly decrypt suggest an intrusion attempt. Once decrypted, the UserId and timestamp contained within the token are validated to ensure validity; the UserId is compared against the currently logged in user, and the timestamp is compared against the current time.<br />
<br />
On successful Token-decryption, the server has access to parsed values, ideally in the form of [http://en.wikipedia.org/wiki/Claims-based_identity claims]. These claims are processed by comparing the UserId claim to any potentially stored UserId (in a Cookie or Session variable, if the site already contains a means of authentication). The Timestamp is validated against the current time, preventing replay attacks.<br />
Alternatively, in the case of a CSRF attack, the server will be unable to decrypt the poisoned Token, and can block and log the attack.<br />
<br />
This pattern exists primarily to allow developers and architects protect against CSRF without session-dependency. It also addresses some of the shortfalls in other stateless approaches, such as the need to store data in a Cookie, circumnavigating the Cookie-subdomain and HTTPONLY issues.<br />
<br />
=== Protecting REST Services: Use of Custom Request Headers ===<br />
<br />
Adding CSRF tokens, a double submit cookie and value, encrypted token, or other defense that involves changing the UI can frequently be complex or otherwise problematic. An alternate defense which is particularly well suited for AJAX endpoints is the use of a custom request header. This defense relies on the [https://en.wikipedia.org/wiki/Same-origin_policy same-origin policy (SOP)] restriction that only JavaScript can be used to add a custom header, and only within its origin. By default, browsers don't allow JavaScript to make cross origin requests.<br />
<br />
A particularly attractive custom header and value to use is:<br />
* X-Requested-With: XMLHttpRequest<br />
because most JavaScript libraries already add this header to requests they generate by default. Some do not though. For example, AngularJS used to, but doesn't anymore. [https://github.com/angular/angular.js/commit/3a75b1124d062f64093a90b26630938558909e8d Their rationale and how to add it back is here].<br />
<br />
If this is the case for your system, you can simply verify the presence of this header and value on all your server side AJAX endpoints in order to protect against CSRF attacks. This approach has the double advantage of usually requiring no UI changes and not introducing any server side state, which is particularly attractive to REST services. You can always add your own custom header and value if that is preferred.<br />
<br />
This defense technique is specifically discussed in section 4.3 of [https://seclab.stanford.edu/websec/csrf/csrf.pdf Robust Defenses for Cross-Site Request Forgery]. However, bypasses of this defense using Flash were documented as early as 2008 and again as recently as 2015 by [https://hackerone.com/reports/44146 Mathias Karlsson to exploit a CSRF flaw in Vimeo]. But, we believe that the Flash attack can't spoof the Origin or Referer headers so by checking both of them we believe this combination of checks should prevent Flash bypass CSRF attacks. (NOTE: If anyone can confirm or refute this belief, please let us know so we can update this article)<br />
<br />
= Alternate CSRF Defense: Require User Interaction =<br />
<br />
Sometimes its easier or more appropriate to involve the user in the transaction in order to prevent unauthorized transactions (forged or otherwise).<br />
<br />
The following are some examples of challenge-response options:<br />
<br />
*Re-Authentication (password or stronger)<br />
*One-time Token<br />
*CAPTCHA<br />
<br />
While challenge-response is a very strong defense against CSRF (assuming proper implementation), it does impact user experience. For applications in need of high security, tokens (transparent) and challenge-response should be used on high risk functions.<br />
<br />
An example of a transparent use of security tokens that doesn't impact the user experience is the use of transaction IDs. Imagine a user wants to initiate a transaction, like send money via PayPal.<br />
<br />
* In Step 1: the user provides the email address and the amount of money they want to send.<br />
** The server responds with a confirmation dialog that includes a unique transaction ID for this money transfer.<br />
* In Step 2: the user confirms the proposed transaction. <br />
** The confirmation request includes the transaction ID generated in step 1. If the server verifies the transaction ID as part of this step, this prevents CSRF against this transaction flow without using a CSRF specific defense token. The transaction ID as part of the confirm essentially serves as the CSRF defense if the attacker cannot predict this value, The transaction ID 'should' be random/unguessable. Ideally, not just the next transaction number in a growing by one list of transaction IDs.<br />
<br />
This is just one example of site's behavior that might naturally protect certain state changing events against CSRF attacks.<br />
<br />
<br />
= Prevention Measures That Do NOT Work =<br />
<br />
For more information on prevention measures that do NOT work, please see the [[Cross-Site_Request_Forgery_(CSRF)#Prevention_measures_that_do_NOT_work | OWASP CSRF article]].<br />
<br />
= Personal Safety CSRF Tips for Users =<br />
<br />
Since CSRF vulnerabilities are reportedly widespread, it is recommended to follow the following best practices to mitigate risk. These include: <br />
<br />
* Logoff immediately after using a Web application <br />
* Do not allow your browser to save username/passwords, and do not allow sites to “remember” your login <br />
* Do not use the same browser to access sensitive applications and to surf the Internet freely (tabbed browsing). <br />
* The use of plugins such as No-Script makes POST based CSRF vulnerabilities difficult to exploit. This is because JavaScript is used to automatically submit the form when the exploit is loaded. Without JavaScript the attacker would have to trick the user into submitting the form manually. <br />
<br />
Integrated HTML-enabled mail/browser and newsreader/browser environments pose additional risks since simply viewing a mail message or a news message might lead to the execution of an attack.<br />
<br />
<br />
= Authors and Primary Editors =<br />
<br />
Dave Wichers - dave.wichers[at]owasp.org<br/><br />
Paul Petefish - https://www.linkedin.com/in/paulpetefish<br/><br />
Eric Sheridan - eric.sheridan[at]owasp.org<br/><br />
<br />
== Other Cheatsheets ==<br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
<br />
|}<br />
<br />
[[Category:Cheatsheets]][[Category:Popular]]</div>Jtpereydahttps://wiki.owasp.org/index.php?title=Fuzzing&diff=218256Fuzzing2016-06-23T21:58:20Z<p>Jtpereyda: Rename Sources -> References. More generic.</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 "classical" 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 "GET ", 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 unpredictability, 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 "known-to-be-dangerous values" (''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_Testing_Guide_Appendix_C:_Fuzz_Vectors|OWASP's Fuzz Vector's resource]] for real-life fuzzing vectors examples and methodology.<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: [http://www.microsoft.com/technet/security/bulletin/ms04-028.mspx MS04-028] (KB833987) Microsoft's JPEG GDI+ vulnerability was a zero sized comment field, without content.<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 : [http://www.digitaldwarf.be/products/mangle.c Ilja van Sprundel's mangle.c]; "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." (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 [http://hachoir.org/ Hachoir] as a generic parser for file format fuzzer 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 [http://projects.info-pull.com/mokb/ Month of Kernel Bugs], which revealed an Apple Wireless flaw; see http://kernelfun.blogspot.com/; mainly used file system fuzzing tools<br />
<br />
* The [http://browserfun.blogspot.com/ Month of Browser Bugs] ([http://osvdb.org/blog/?p=127 review here]); 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]]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br />
<br />
[[JBroFuzz]]: a web application fuzzer<br />
<br />
[[WSFuzzer]]: real-world manual SOAP pen testing tool<br />
<br />
== Technical resources on OWASP ==<br />
<br />
[[OWASP Testing Guide Appendix C: Fuzz Vectors]]<br />
<br />
== References ==<br />
<br />
Wikipedia article - http://en.wikipedia.org/wiki/Fuzz_testing<br />
<br />
Fuzzing-related papers - http://www.threatmind.net/secwiki/FuzzingPapers<br />
<br />
[https://web.archive.org/web/20090202043027/http://www.whitestar.linuxbox.org/pipermail/fuzzing/ The fuzzing mailing list archive]<br />
<br />
== Fuzzing tools ==<br />
<br />
=== Open Source ===<br />
<br />
==== Mutational Fuzzers ====<br />
[https://en.wikipedia.org/wiki/American_fuzzy_lop_(fuzzer) american fuzzy lop]<br />
<br />
[https://github.com/aoh/radamsa Radamsa - a flock of fuzzers]<br />
<br />
==== Fuzzing Frameworks ====<br />
[https://github.com/OpenRCE/sulley Sulley Fuzzing Framework]<br />
<br />
[https://github.com/jtpereyda/boofuzz boofuzz]<br />
<br />
==== Domain-Specific Fuzzers ====<br />
<br />
[http://www.microsoft.com/download/en/details.aspx?id=21769 Microsoft SDL MiniFuzz File Fuzzer]<br />
<br />
[http://www.microsoft.com/download/en/details.aspx?id=20095 Microsoft SDL Regex Fuzzer]<br />
<br />
[https://github.com/nradov/abnffuzzer ABNF Fuzzer]<br />
<br />
=== Commercial products ===<br />
<br />
[http://www.codenomicon.com/products/all.shtml Codenomicon's product suite]<br />
<br />
[http://peachfuzzer.com Peach Fuzzing Platform]<br />
<br />
[http://www.spirent.com/Products/AvalancheNEXT Spirent Avalanche NEXT]<br />
<br />
[http://www.beyondsecurity.com/bestorm_overview.html Beyond Security's beSTORM product]<br />
[[Category:Externally Linked Page]]<br />
<br />
=== Deprecated Tools ===<br />
<br />
[http://www.bonsai-sec.com/en/research/untidy-xml-fuzzer.php Untidy - XML Fuzzer] (Now integrated into Peach)</div>Jtpereydahttps://wiki.owasp.org/index.php?title=Fuzzing&diff=218255Fuzzing2016-06-23T21:57:52Z<p>Jtpereyda: Categorize open source fuzzers: mutational, frameworks, domain-specific; move mailing list archive to Sources</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 "classical" 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 "GET ", 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 unpredictability, 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 "known-to-be-dangerous values" (''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_Testing_Guide_Appendix_C:_Fuzz_Vectors|OWASP's Fuzz Vector's resource]] for real-life fuzzing vectors examples and methodology.<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: [http://www.microsoft.com/technet/security/bulletin/ms04-028.mspx MS04-028] (KB833987) Microsoft's JPEG GDI+ vulnerability was a zero sized comment field, without content.<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 : [http://www.digitaldwarf.be/products/mangle.c Ilja van Sprundel's mangle.c]; "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." (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 [http://hachoir.org/ Hachoir] as a generic parser for file format fuzzer 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 [http://projects.info-pull.com/mokb/ Month of Kernel Bugs], which revealed an Apple Wireless flaw; see http://kernelfun.blogspot.com/; mainly used file system fuzzing tools<br />
<br />
* The [http://browserfun.blogspot.com/ Month of Browser Bugs] ([http://osvdb.org/blog/?p=127 review here]); 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]]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br />
<br />
[[JBroFuzz]]: a web application fuzzer<br />
<br />
[[WSFuzzer]]: real-world manual SOAP pen testing tool<br />
<br />
== Technical resources on OWASP ==<br />
<br />
[[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 />
[https://web.archive.org/web/20090202043027/http://www.whitestar.linuxbox.org/pipermail/fuzzing/ The fuzzing mailing list archive]<br />
<br />
== Fuzzing tools ==<br />
<br />
=== Open Source ===<br />
<br />
==== Mutational Fuzzers ====<br />
[https://en.wikipedia.org/wiki/American_fuzzy_lop_(fuzzer) american fuzzy lop]<br />
<br />
[https://github.com/aoh/radamsa Radamsa - a flock of fuzzers]<br />
<br />
==== Fuzzing Frameworks ====<br />
[https://github.com/OpenRCE/sulley Sulley Fuzzing Framework]<br />
<br />
[https://github.com/jtpereyda/boofuzz boofuzz]<br />
<br />
==== Domain-Specific Fuzzers ====<br />
<br />
[http://www.microsoft.com/download/en/details.aspx?id=21769 Microsoft SDL MiniFuzz File Fuzzer]<br />
<br />
[http://www.microsoft.com/download/en/details.aspx?id=20095 Microsoft SDL Regex Fuzzer]<br />
<br />
[https://github.com/nradov/abnffuzzer ABNF Fuzzer]<br />
<br />
=== Commercial products ===<br />
<br />
[http://www.codenomicon.com/products/all.shtml Codenomicon's product suite]<br />
<br />
[http://peachfuzzer.com Peach Fuzzing Platform]<br />
<br />
[http://www.spirent.com/Products/AvalancheNEXT Spirent Avalanche NEXT]<br />
<br />
[http://www.beyondsecurity.com/bestorm_overview.html Beyond Security's beSTORM product]<br />
[[Category:Externally Linked Page]]<br />
<br />
=== Deprecated Tools ===<br />
<br />
[http://www.bonsai-sec.com/en/research/untidy-xml-fuzzer.php Untidy - XML Fuzzer] (Now integrated into Peach)</div>Jtpereydahttps://wiki.owasp.org/index.php?title=Fuzzing&diff=218254Fuzzing2016-06-23T21:53:08Z<p>Jtpereyda: Add Deprecated Tools section for Untidy, which has been explicitly merged into Peach and is no longer available at its old SourceForge link</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 "classical" 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 "GET ", 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 unpredictability, 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 "known-to-be-dangerous values" (''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_Testing_Guide_Appendix_C:_Fuzz_Vectors|OWASP's Fuzz Vector's resource]] for real-life fuzzing vectors examples and methodology.<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: [http://www.microsoft.com/technet/security/bulletin/ms04-028.mspx MS04-028] (KB833987) Microsoft's JPEG GDI+ vulnerability was a zero sized comment field, without content.<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 : [http://www.digitaldwarf.be/products/mangle.c Ilja van Sprundel's mangle.c]; "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." (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 [http://hachoir.org/ Hachoir] as a generic parser for file format fuzzer 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 [http://projects.info-pull.com/mokb/ Month of Kernel Bugs], which revealed an Apple Wireless flaw; see http://kernelfun.blogspot.com/; mainly used file system fuzzing tools<br />
<br />
* The [http://browserfun.blogspot.com/ Month of Browser Bugs] ([http://osvdb.org/blog/?p=127 review here]); 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]]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br />
<br />
[[JBroFuzz]]: a web application fuzzer<br />
<br />
[[WSFuzzer]]: real-world manual SOAP pen testing tool<br />
<br />
== Technical resources on OWASP ==<br />
<br />
[[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 />
=== Open Source ===<br />
<br />
[https://en.wikipedia.org/wiki/American_fuzzy_lop_(fuzzer) american fuzzy lop]<br />
<br />
[https://github.com/OpenRCE/sulley Sulley Fuzzing Framework]<br />
<br />
[https://github.com/jtpereyda/boofuzz boofuzz]<br />
<br />
[https://github.com/aoh/radamsa Radamsa - a flock of fuzzers]<br />
<br />
[http://www.microsoft.com/download/en/details.aspx?id=21769 Microsoft SDL MiniFuzz File Fuzzer]<br />
<br />
[http://www.microsoft.com/download/en/details.aspx?id=20095 Microsoft SDL Regex Fuzzer]<br />
<br />
[https://github.com/nradov/abnffuzzer ABNF Fuzzer]<br />
<br />
[https://web.archive.org/web/20090202043027/http://www.whitestar.linuxbox.org/pipermail/fuzzing/ The fuzzing mailing list archive]<br />
<br />
=== Commercial products ===<br />
<br />
[http://www.codenomicon.com/products/all.shtml Codenomicon's product suite]<br />
<br />
[http://peachfuzzer.com Peach Fuzzing Platform]<br />
<br />
[http://www.spirent.com/Products/AvalancheNEXT Spirent Avalanche NEXT]<br />
<br />
[http://www.beyondsecurity.com/bestorm_overview.html Beyond Security's beSTORM product]<br />
[[Category:Externally Linked Page]]<br />
<br />
=== Deprecated Tools ===<br />
<br />
[http://www.bonsai-sec.com/en/research/untidy-xml-fuzzer.php Untidy - XML Fuzzer] (Now integrated into Peach)</div>Jtpereydahttps://wiki.owasp.org/index.php?title=Fuzzing&diff=218253Fuzzing2016-06-23T21:48:44Z<p>Jtpereyda: /* Fuzzing tools */ Updating Radamsa link</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 "classical" 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 "GET ", 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 unpredictability, 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 "known-to-be-dangerous values" (''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_Testing_Guide_Appendix_C:_Fuzz_Vectors|OWASP's Fuzz Vector's resource]] for real-life fuzzing vectors examples and methodology.<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: [http://www.microsoft.com/technet/security/bulletin/ms04-028.mspx MS04-028] (KB833987) Microsoft's JPEG GDI+ vulnerability was a zero sized comment field, without content.<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 : [http://www.digitaldwarf.be/products/mangle.c Ilja van Sprundel's mangle.c]; "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." (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 [http://hachoir.org/ Hachoir] as a generic parser for file format fuzzer 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 [http://projects.info-pull.com/mokb/ Month of Kernel Bugs], which revealed an Apple Wireless flaw; see http://kernelfun.blogspot.com/; mainly used file system fuzzing tools<br />
<br />
* The [http://browserfun.blogspot.com/ Month of Browser Bugs] ([http://osvdb.org/blog/?p=127 review here]); 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]]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br />
<br />
[[JBroFuzz]]: a web application fuzzer<br />
<br />
[[WSFuzzer]]: real-world manual SOAP pen testing tool<br />
<br />
== Technical resources on OWASP ==<br />
<br />
[[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 />
[https://en.wikipedia.org/wiki/American_fuzzy_lop_(fuzzer) american fuzzy lop]<br />
<br />
[https://github.com/OpenRCE/sulley Sulley Fuzzing Framework]<br />
<br />
[https://github.com/jtpereyda/boofuzz boofuzz]<br />
<br />
[https://github.com/aoh/radamsa Radamsa - a flock of fuzzers]<br />
<br />
[http://www.microsoft.com/download/en/details.aspx?id=21769 Microsoft SDL MiniFuzz File Fuzzer]<br />
<br />
[http://untidy.sourceforge.net Untidy - XML Fuzzer]<br />
<br />
[http://www.microsoft.com/download/en/details.aspx?id=20095 Microsoft SDL Regex Fuzzer]<br />
<br />
[https://github.com/nradov/abnffuzzer ABNF Fuzzer]<br />
<br />
[https://web.archive.org/web/20090202043027/http://www.whitestar.linuxbox.org/pipermail/fuzzing/ The fuzzing mailing list archive]<br />
<br />
== Commercial products ==<br />
<br />
[http://www.codenomicon.com/products/all.shtml Codenomicon's product suite]<br />
<br />
[http://peachfuzzer.com Peach Fuzzing Platform]<br />
<br />
[http://www.spirent.com/Products/AvalancheNEXT Spirent Avalanche NEXT]<br />
<br />
[http://www.beyondsecurity.com/bestorm_overview.html Beyond Security's beSTORM product]<br />
[[Category:Externally Linked Page]]</div>Jtpereydahttps://wiki.owasp.org/index.php?title=Fuzzing&diff=218252Fuzzing2016-06-23T21:44:05Z<p>Jtpereyda: lowercase boofuzz, remove extraneous info in link</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 "classical" 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 "GET ", 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 unpredictability, 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 "known-to-be-dangerous values" (''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_Testing_Guide_Appendix_C:_Fuzz_Vectors|OWASP's Fuzz Vector's resource]] for real-life fuzzing vectors examples and methodology.<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: [http://www.microsoft.com/technet/security/bulletin/ms04-028.mspx MS04-028] (KB833987) Microsoft's JPEG GDI+ vulnerability was a zero sized comment field, without content.<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 : [http://www.digitaldwarf.be/products/mangle.c Ilja van Sprundel's mangle.c]; "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." (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 [http://hachoir.org/ Hachoir] as a generic parser for file format fuzzer 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 [http://projects.info-pull.com/mokb/ Month of Kernel Bugs], which revealed an Apple Wireless flaw; see http://kernelfun.blogspot.com/; mainly used file system fuzzing tools<br />
<br />
* The [http://browserfun.blogspot.com/ Month of Browser Bugs] ([http://osvdb.org/blog/?p=127 review here]); 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]]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br />
<br />
[[JBroFuzz]]: a web application fuzzer<br />
<br />
[[WSFuzzer]]: real-world manual SOAP pen testing tool<br />
<br />
== Technical resources on OWASP ==<br />
<br />
[[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 />
[https://en.wikipedia.org/wiki/American_fuzzy_lop_(fuzzer) american fuzzy lop]<br />
<br />
[https://github.com/OpenRCE/sulley Sulley Fuzzing Framework]<br />
<br />
[https://github.com/jtpereyda/boofuzz boofuzz]<br />
<br />
[http://code.google.com/p/ouspg/wiki/Radamsa Radamsa - a flock of fuzzers]<br />
<br />
[http://www.microsoft.com/download/en/details.aspx?id=21769 Microsoft SDL MiniFuzz File Fuzzer]<br />
<br />
[http://untidy.sourceforge.net Untidy - XML Fuzzer]<br />
<br />
[http://www.microsoft.com/download/en/details.aspx?id=20095 Microsoft SDL Regex Fuzzer]<br />
<br />
[https://github.com/nradov/abnffuzzer ABNF Fuzzer]<br />
<br />
[https://web.archive.org/web/20090202043027/http://www.whitestar.linuxbox.org/pipermail/fuzzing/ The fuzzing mailing list archive]<br />
<br />
== Commercial products ==<br />
<br />
[http://www.codenomicon.com/products/all.shtml Codenomicon's product suite]<br />
<br />
[http://peachfuzzer.com Peach Fuzzing Platform]<br />
<br />
[http://www.spirent.com/Products/AvalancheNEXT Spirent Avalanche NEXT]<br />
<br />
[http://www.beyondsecurity.com/bestorm_overview.html Beyond Security's beSTORM product]<br />
[[Category:Externally Linked Page]]</div>Jtpereydahttps://wiki.owasp.org/index.php?title=Fuzzing&diff=218251Fuzzing2016-06-23T21:42:31Z<p>Jtpereyda: /* Fuzzing tools */ Add fuzzing tools: american fuzzy lop (yes it's supposed to be lowercase), Sulley, boofuzz (full disclosure: I'm behind boofuzz)</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 "classical" 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 "GET ", 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 unpredictability, 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 "known-to-be-dangerous values" (''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_Testing_Guide_Appendix_C:_Fuzz_Vectors|OWASP's Fuzz Vector's resource]] for real-life fuzzing vectors examples and methodology.<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: [http://www.microsoft.com/technet/security/bulletin/ms04-028.mspx MS04-028] (KB833987) Microsoft's JPEG GDI+ vulnerability was a zero sized comment field, without content.<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 : [http://www.digitaldwarf.be/products/mangle.c Ilja van Sprundel's mangle.c]; "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." (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 [http://hachoir.org/ Hachoir] as a generic parser for file format fuzzer 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 [http://projects.info-pull.com/mokb/ Month of Kernel Bugs], which revealed an Apple Wireless flaw; see http://kernelfun.blogspot.com/; mainly used file system fuzzing tools<br />
<br />
* The [http://browserfun.blogspot.com/ Month of Browser Bugs] ([http://osvdb.org/blog/?p=127 review here]); 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]]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br />
<br />
[[JBroFuzz]]: a web application fuzzer<br />
<br />
[[WSFuzzer]]: real-world manual SOAP pen testing tool<br />
<br />
== Technical resources on OWASP ==<br />
<br />
[[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 />
[https://en.wikipedia.org/wiki/American_fuzzy_lop_(fuzzer) american fuzzy lop]<br />
<br />
[https://github.com/OpenRCE/sulley Sulley Fuzzing Framework]<br />
<br />
[https://github.com/jtpereyda/boofuzz Boofuzz (Sulley fork)]<br />
<br />
[http://code.google.com/p/ouspg/wiki/Radamsa Radamsa - a flock of fuzzers]<br />
<br />
[http://www.microsoft.com/download/en/details.aspx?id=21769 Microsoft SDL MiniFuzz File Fuzzer]<br />
<br />
[http://untidy.sourceforge.net Untidy - XML Fuzzer]<br />
<br />
[http://www.microsoft.com/download/en/details.aspx?id=20095 Microsoft SDL Regex Fuzzer]<br />
<br />
[https://github.com/nradov/abnffuzzer ABNF Fuzzer]<br />
<br />
[https://web.archive.org/web/20090202043027/http://www.whitestar.linuxbox.org/pipermail/fuzzing/ The fuzzing mailing list archive]<br />
<br />
== Commercial products ==<br />
<br />
[http://www.codenomicon.com/products/all.shtml Codenomicon's product suite]<br />
<br />
[http://peachfuzzer.com Peach Fuzzing Platform]<br />
<br />
[http://www.spirent.com/Products/AvalancheNEXT Spirent Avalanche NEXT]<br />
<br />
[http://www.beyondsecurity.com/bestorm_overview.html Beyond Security's beSTORM product]<br />
[[Category:Externally Linked Page]]</div>Jtpereydahttps://wiki.owasp.org/index.php?title=User:Jtpereyda&diff=217626User:Jtpereyda2016-06-03T23:01:38Z<p>Jtpereyda: rewording</p>
<hr />
<div>Joshua is a software engineer, hacker, and wannabe cryptography engineer. He has education and practical experience in the security field, with expertise in protocol fuzzing.<br />
<br />
As a software engineer, Joshua has an appreciation for clean code and sound engineering practice.<br />
<br />
His master's thesis explored a primitive attack exploiting inter-keystroke timing. His current research is in pragmatic fuzzing.</div>Jtpereydahttps://wiki.owasp.org/index.php?title=Fuzzing&diff=217625Fuzzing2016-06-03T22:58:49Z<p>Jtpereyda: format cleanup</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 "classical" 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 "GET ", 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 unpredictability, 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 "known-to-be-dangerous values" (''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_Testing_Guide_Appendix_C:_Fuzz_Vectors|OWASP's Fuzz Vector's resource]] for real-life fuzzing vectors examples and methodology.<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: [http://www.microsoft.com/technet/security/bulletin/ms04-028.mspx MS04-028] (KB833987) Microsoft's JPEG GDI+ vulnerability was a zero sized comment field, without content.<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 : [http://www.digitaldwarf.be/products/mangle.c Ilja van Sprundel's mangle.c]; "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." (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 [http://hachoir.org/ Hachoir] as a generic parser for file format fuzzer 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 [http://projects.info-pull.com/mokb/ Month of Kernel Bugs], which revealed an Apple Wireless flaw; see http://kernelfun.blogspot.com/; mainly used file system fuzzing tools<br />
<br />
* The [http://browserfun.blogspot.com/ Month of Browser Bugs] ([http://osvdb.org/blog/?p=127 review here]); 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]]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br />
<br />
[[JBroFuzz]]: a web application fuzzer<br />
<br />
[[WSFuzzer]]: real-world manual SOAP pen testing tool<br />
<br />
== Technical resources on OWASP ==<br />
<br />
[[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 />
[http://code.google.com/p/ouspg/wiki/Radamsa Radamsa - a flock of fuzzers]<br />
<br />
[http://www.microsoft.com/download/en/details.aspx?id=21769 Microsoft SDL MiniFuzz File Fuzzer]<br />
<br />
[http://untidy.sourceforge.net Untidy - XML Fuzzer]<br />
<br />
[http://www.microsoft.com/download/en/details.aspx?id=20095 Microsoft SDL Regex Fuzzer]<br />
<br />
[https://github.com/nradov/abnffuzzer ABNF Fuzzer]<br />
<br />
[https://web.archive.org/web/20090202043027/http://www.whitestar.linuxbox.org/pipermail/fuzzing/ The fuzzing mailing list archive]<br />
<br />
== Commercial products ==<br />
<br />
[http://www.codenomicon.com/products/all.shtml Codenomicon's product suite]<br />
<br />
[http://peachfuzzer.com Peach Fuzzing Platform]<br />
<br />
[http://www.spirent.com/Products/AvalancheNEXT Spirent Avalanche NEXT]<br />
<br />
[http://www.beyondsecurity.com/bestorm_overview.html Beyond Security's beSTORM product]<br />
[[Category:Externally Linked Page]]</div>Jtpereydahttps://wiki.owasp.org/index.php?title=Fuzzing&diff=217622Fuzzing2016-06-03T22:52:56Z<p>Jtpereyda: /* Commercial products */ Updating Spirent link and sorting roughly by popularity</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 "classical" 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 "GET ", 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 unpredictability, 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 "known-to-be-dangerous values" (''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_Testing_Guide_Appendix_C:_Fuzz_Vectors|OWASP's Fuzz Vector's resource]] for real-life fuzzing vectors examples and methodology.<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: [http://www.microsoft.com/technet/security/bulletin/ms04-028.mspx MS04-028] (KB833987) Microsoft's JPEG GDI+ vulnerability was a zero sized comment field, without content.<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 : [http://www.digitaldwarf.be/products/mangle.c Ilja van Sprundel's mangle.c]; "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." (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 [http://hachoir.org/ Hachoir] as a generic parser for file format fuzzer 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 [http://projects.info-pull.com/mokb/ Month of Kernel Bugs], which revealed an Apple Wireless flaw; see http://kernelfun.blogspot.com/; mainly used file system fuzzing tools<br />
<br />
- The [http://browserfun.blogspot.com/ Month of Browser Bugs] ([http://osvdb.org/blog/?p=127 review here]); 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]]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br />
<br />
[[JBroFuzz]]: a web application fuzzer<br />
<br />
[[WSFuzzer]]: real-world manual SOAP pen testing tool<br />
<br />
== Technical resources on OWASP ==<br />
<br />
[[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 />
[http://code.google.com/p/ouspg/wiki/Radamsa Radamsa - a flock of fuzzers]<br />
<br />
[http://www.microsoft.com/download/en/details.aspx?id=21769 Microsoft SDL MiniFuzz File Fuzzer]<br />
<br />
[http://untidy.sourceforge.net Untidy - XML Fuzzer]<br />
<br />
[http://www.microsoft.com/download/en/details.aspx?id=20095 Microsoft SDL Regex Fuzzer]<br />
<br />
[https://github.com/nradov/abnffuzzer ABNF Fuzzer]<br />
<br />
[https://web.archive.org/web/20090202043027/http://www.whitestar.linuxbox.org/pipermail/fuzzing/ The fuzzing mailing list archive]<br />
<br />
== Commercial products ==<br />
<br />
[http://www.codenomicon.com/products/all.shtml Codenomicon's product suite]<br />
<br />
[http://peachfuzzer.com Peach Fuzzing Platform]<br />
<br />
[http://www.spirent.com/Products/AvalancheNEXT Spirent Avalanche NEXT]<br />
<br />
[http://www.beyondsecurity.com/bestorm_overview.html Beyond Security's beSTORM product]<br />
[[Category:Externally Linked Page]]</div>Jtpereydahttps://wiki.owasp.org/index.php?title=Fuzzing&diff=217620Fuzzing2016-06-03T22:47:09Z<p>Jtpereyda: Moving Peach to Commercial section. The old code is still OSS, but the corporate backer has switched to closed source.</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 "classical" 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 "GET ", 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 unpredictability, 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 "known-to-be-dangerous values" (''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_Testing_Guide_Appendix_C:_Fuzz_Vectors|OWASP's Fuzz Vector's resource]] for real-life fuzzing vectors examples and methodology.<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: [http://www.microsoft.com/technet/security/bulletin/ms04-028.mspx MS04-028] (KB833987) Microsoft's JPEG GDI+ vulnerability was a zero sized comment field, without content.<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 : [http://www.digitaldwarf.be/products/mangle.c Ilja van Sprundel's mangle.c]; "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." (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 [http://hachoir.org/ Hachoir] as a generic parser for file format fuzzer 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 [http://projects.info-pull.com/mokb/ Month of Kernel Bugs], which revealed an Apple Wireless flaw; see http://kernelfun.blogspot.com/; mainly used file system fuzzing tools<br />
<br />
- The [http://browserfun.blogspot.com/ Month of Browser Bugs] ([http://osvdb.org/blog/?p=127 review here]); 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]]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br />
<br />
[[JBroFuzz]]: a web application fuzzer<br />
<br />
[[WSFuzzer]]: real-world manual SOAP pen testing tool<br />
<br />
== Technical resources on OWASP ==<br />
<br />
[[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 />
[http://code.google.com/p/ouspg/wiki/Radamsa Radamsa - a flock of fuzzers]<br />
<br />
[http://www.microsoft.com/download/en/details.aspx?id=21769 Microsoft SDL MiniFuzz File Fuzzer]<br />
<br />
[http://untidy.sourceforge.net Untidy - XML Fuzzer]<br />
<br />
[http://www.microsoft.com/download/en/details.aspx?id=20095 Microsoft SDL Regex Fuzzer]<br />
<br />
[https://github.com/nradov/abnffuzzer ABNF Fuzzer]<br />
<br />
[https://web.archive.org/web/20090202043027/http://www.whitestar.linuxbox.org/pipermail/fuzzing/ The fuzzing mailing list archive]<br />
<br />
== Commercial products ==<br />
<br />
[http://peachfuzzer.com Peach Fuzzing Platform]<br />
<br />
[http://www.spirent.com/Ethernet_Testing/Software/Studio Spirent Studio Security product suite:]<br />
<br />
[http://www.codenomicon.com/products/all.shtml Codenomicon's product suite:]<br />
<br />
[http://www.beyondsecurity.com/bestorm_overview.html Beyond Security's beSTORM product:]<br />
[[Category:Externally Linked Page]]</div>Jtpereydahttps://wiki.owasp.org/index.php?title=Fuzzing&diff=217619Fuzzing2016-06-03T22:45:39Z<p>Jtpereyda: Updating dead link to mailing list with archive.org link</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 "classical" 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 "GET ", 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 unpredictability, 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 "known-to-be-dangerous values" (''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_Testing_Guide_Appendix_C:_Fuzz_Vectors|OWASP's Fuzz Vector's resource]] for real-life fuzzing vectors examples and methodology.<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: [http://www.microsoft.com/technet/security/bulletin/ms04-028.mspx MS04-028] (KB833987) Microsoft's JPEG GDI+ vulnerability was a zero sized comment field, without content.<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 : [http://www.digitaldwarf.be/products/mangle.c Ilja van Sprundel's mangle.c]; "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." (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 [http://hachoir.org/ Hachoir] as a generic parser for file format fuzzer 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 [http://projects.info-pull.com/mokb/ Month of Kernel Bugs], which revealed an Apple Wireless flaw; see http://kernelfun.blogspot.com/; mainly used file system fuzzing tools<br />
<br />
- The [http://browserfun.blogspot.com/ Month of Browser Bugs] ([http://osvdb.org/blog/?p=127 review here]); 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]]: a framework for analysing applications that communicate using the HTTP and HTTPS protocols<br />
<br />
[[JBroFuzz]]: a web application fuzzer<br />
<br />
[[WSFuzzer]]: real-world manual SOAP pen testing tool<br />
<br />
== Technical resources on OWASP ==<br />
<br />
[[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 />
[http://peachfuzzer.com Peach Fuzzing Platform]<br />
<br />
[http://code.google.com/p/ouspg/wiki/Radamsa Radamsa - a flock of fuzzers]<br />
<br />
[http://www.microsoft.com/download/en/details.aspx?id=21769 Microsoft SDL MiniFuzz File Fuzzer]<br />
<br />
[http://untidy.sourceforge.net Untidy - XML Fuzzer]<br />
<br />
[http://www.microsoft.com/download/en/details.aspx?id=20095 Microsoft SDL Regex Fuzzer]<br />
<br />
[https://github.com/nradov/abnffuzzer ABNF Fuzzer]<br />
<br />
[https://web.archive.org/web/20090202043027/http://www.whitestar.linuxbox.org/pipermail/fuzzing/ The fuzzing mailing list archive]<br />
<br />
== Commercial products ==<br />
<br />
[http://www.spirent.com/Ethernet_Testing/Software/Studio Spirent Studio Security product suite:]<br />
<br />
[http://www.codenomicon.com/products/all.shtml Codenomicon's product suite:]<br />
<br />
[http://www.beyondsecurity.com/bestorm_overview.html Beyond Security's beSTORM product:]<br />
[[Category:Externally Linked Page]]</div>Jtpereyda