Protocol Modeler lets you quickly develop network-layer attacks by using fault-injection components. The attacks are aimed at uncovering vulnerabilities in underlying software, whether it be closed-source "blackbox" testing of a commercial product--say your perimeter firewall's IP-based administrative interfaces--or testing of an in-house Web application under development. Protocol Modeler is capable of virtually any type of test because, even if the prebuilt fault injectors don't address your testing needs, it's possible to create your own fault injectors--albeit with much work.

You can manipulate simpler types of network traffic using the GUI tools and undertake more complex tasks using a PERL-like API, though once you head down that road, you've lost most of the speed and elegance of test creation that make Protocol Modeler attractive.

You Go Test

When we first fired up Protocol Modeler in our Chicago Neohapsis partner labs, we used the product's wizards to walk us through common security-testing activities. One wizard crawls a Web site looking for SQL-disclosure vulnerabilities, cross-site scripting bugs and opportunities for successful command-injection attacks. Unfortunately, even on the small test Web site we pointed this script at--a beta version of our corporate intranet server--Protocol Modeler crashed. Cenzic blamed the crash on bugs that had infiltrated the latest released version of the code (more on this later). A smaller site with less user interaction proved a more digestible target.

Another wizard tests firewalls. Basically, it turns Protocol Modeler into a glorified port scanner--a rather uninteresting use for such a flexible tool.

Features click to enlarge

The wizards quickly show their limitations, though they do serve the highly useful purpose of introducing the user to the application's components. Without this sort of guide, you'd be left to muddle through the complex interface, a frustrating and potentially fruitless experience.

Protocol Modeler's Network Recorder provides a more focused testing method. Hit the record button, then prompt the application under test to execute the network transaction you'd like to investigate. It can be a well-known standards-based application, such as SMTP or IMAP, in which case the packets will be decoded into proper fields. Or, it can be a proprietary application, where the captured traffic will not have an automatically overlaid format. In this case, the user must scroll through the transactions and attempt to decipher what's happening. Finally, it could be a Web application, in which case Protocol Modeler provides additional support for investigating HTTP-based vulnerabilities as well as a browser interface for walking through an application and gathering data for the recorder. Once data is captured, it can be viewed, manipulated, loaded up with fault injectors and played back to test for vulnerabilities.

One of Protocol Modeler's most powerful features is its variety of fault injectors, which can be dragged into the desired components of a transaction and are critical to the program's process. For example, in a Web application providing user input that appears to be fed to a back-end database query, attempting a SQL Disclosure fault injector would be a good choice. After you hit play, the transaction plays back repeatedly using different permutations in an attempt to fool the Web server into passing SQL commands to the back-end database server directly. Protocol Modeler watches for the application to "fail" in this manner. Continuing with this example, if it sees an apparent SQL error coming back on the HTTP return, Protocol Modeler notes this and reports it to the user.

Protocol Modeler uses several strategies to monitor for faults and signs of vulnerabilities. One, previously noted, is to watch for typical return values of a fault; another compares normal return data, as from a normal-size input, to deviant return data, as from a successful buffer overflow applied to the same input.

The fault injectors can be applied in two ways. You can drop one directly into a job, and Protocol Modeler will calculate all the appropriate places to apply it automatically. This blanket method often results in extremely long test times, depending on the fault injectors used. Alternatively, fault injectors can be applied to specific parts of a transaction, for example, an HTTP post field.

Other examples of fault injectors are Bitwalk, which can be applied to any binary payload by applying a large range of values to each byte within the field; Buffer Overflow, which applies incrementally larger values to target fields and monitors for signs of a successful buffer overflow; and Cross-Site Scripting, which attempts to post executable content throughout the site and then goes back to check for its availability to the user (see the features chart for additional details).