Defensics Monitor Introduction

If you don't already understand fuzz testing, or if you want to refresh your memory, try these resources:

Read:

• What is Fuzzing? The Poet, the Courier, and the Oracle (PDF, 11 pages)

Watch:

• Unknown Vulnerability Management and Discovery Using Fuzzing
• Part 1: What are unknown vulnerabilities and why should I care
• Part 2: What is fuzz testing, and where does it fit in the world of software?
• Part 3: How and why fuzz testing, and managing your unknown vulnerabilities saves money
• Part 4: Fuzz testing techniques: unfuzzing the fuzzing
• Defensics Tutorials

You'll learn best if you work with Defensics as you're reading this guide. Try things as you go along! Practice with Defensics to improve your skills.

Before you start reading the rest of this guide, make sure you have Defensics installed. Consult the Defensics Installation Guide for details. Setup steps for running Defensics for the first time are in Running Defensics for the First Time.

Remember, software testing is a noble pursuit. You are finding bugs so that they can be fixed, making the world safer, more robust, and more secure. Keep honing your skills to find as many bugs as you can. It's your job to break things!

You should read straight from the beginning of this guide to the chapter on remediation. This will give you the full life cycle of using Defensics to locate and fix bugs in software.

The rest of the chapters are recommended, but you can choose topics as necessary if you're short on time. Not everyone, for example, will have to tackle file testing. Feel free to read chapters as you need them, and in any order.

This chapter describes the larger picture of fuzz testing. You'll read about general guidelines for fuzz testing as well as how to approach testing a specific target.

Defensics contains copious help text inside the application itself. Click on any field for context-sensitive help in the right pane.

For more general information, choose GUI Help or Suite Help in the right pane.

The purpose of this document is to supplement the reference information available in Defensics with clear explanations of the process of fuzzing with Defensics.

A good fuzzer is dangerous. Defensics is very dangerous. The whole point of fuzz testing is to break things--this is how you locate vulnerabilities so that they can be fixed.

With this in mind, a few simple guidelines will keep you from getting in serious trouble. These are general guidelines rather than strict rules.

Fuzzing is destructive testing and can damage production targets. Don't test anything that anyone is using.

Fuzz testing can leave targets in unusual internal states. For example, a device that still appears to respond normally after testing might have a severely damaged internal database.

If you were a patient in a hospital, would you want to use that infusion pump that had previously been fuzz tested?

If you are confident that the tested device can be returned to its factory state, you might be able to use it after fuzz testing. Use your common sense.

Any devices or equipment between Defensics and the test target can cause three kinds of trouble.

• The testing speed you are able to achieve will be lower if the test cases have farther to travel.
• Devices between Defensics and the target might modify or discard test cases before they reach the target.
• Test cases sent by Defensics to the target might end up causing a failure in one of the intermediary hops. For example, a firewall that parses and examines protocol messages as they pass through might get broken by a test case from Defensics.

Let's say, for example, that you are fuzzing SIP (Session Initiation Protocol) on a piece of VoIP (Voice over IP) equipment.

Wrong: Install Defensics on your desktop computer in your cubicle. Point the SIP fuzzer at the target in the lab and fire away!

This is a bad idea. Let's say your desktop computer is connected to a switch, which connects through a firewall to the lab switch, which is connected to the target device. If either of switches examines SIP messages (perhaps for optimization), or the firewall examines SIP messages, you might end up breaking one of the switches or the firewall instead of your target.

Even if the switches and the firewall don't fail, they might modify or discard test cases before they reach the target.

Even if none of that happens, you'll be flooding the office and lab network with traffic from Defensics. Somebody will be angry about it.

Much better: Install Defensics on a machine in the lab and connect through the lab switch to the target. Alternately, install Defensics on a laptop and connect through the lab switch to the target.

Best: Plug your Defensics machine directly into the target device.

Some targets have built-in security countermeasures, such as firewalls and connection throttling.

Our recommendation is to disable those features to make the target as vulnerable as possible. The point of fuzzing is to find and fix vulnerabilities. Disabling security countermeasures means you will find the maximum number of bugs given the tools and time you have available.

On the other hand, disabling these features means that you are testing a target that is not in its eventual production configuration. You'll have to decide what's most important to you. Perhaps you can perform most of your testing with security features disabled. After fixing all the bugs you find, re-enable the security features and re-test. If you're short on time, the second set of testing could be a shorter test run.

You need to understand a target's attack surface to do meaningful security testing. The attack surface is a collection of attack vectors, where an attack vector is a place that the target takes any form of input. For more information about attack surface analysis, see Attack Surface Analysis.

Attack surface analysis is described more fully elsewhere, including the Fuzz Testing Maturity Model. For now, think of it as a list of protocols that are supported by the target.

Based on your list of attack vectors, you can plan the fuzz testing that you intend to do. Which test suites will you use? What configurations? How much testing will you do? Again, the Fuzz Testing Maturity Model can help you answer these questions.

Defensics is supported by a global team of security engineers. Ask for help in any of the following situations:

• You need help installing Defensics or installing a license server.
• You are having trouble with interoperability.
• You've located a bug in Defensics or a test suite.
• You want to request an enhancement to Defensics or a test suite.

You can post questions to Community here: https://community.blackduck.com/s/discussions

You can post ideas to enhance the product here: https://community.blackduck.com/s/ideas-portal

Another way to contact Defensics support is by sending an email to tech-support@blackduck.com.

For the quickest and best response, provide the following information with your question:

• Test results as needed
• Packet captures as needed
• Configuration files

• Anything else that might help

Defensics helps you package information for support. Use one of the following choices from the Defensics menu:

• Help > Report Defensics issue > Support package from existing results

• Help > Report Defensics issue > Support package by running a debug run