

In the previous two posts on TCL, we've gone from running canned components like Routing Robot and Session Sender to running custom Attack Series with the Security component.
Today, I want to take a look at Security Evasions, explain what they are, and then show how users of the TCL API can apply evasions in their testing.
Evasions are ways an attacker modifies the traffic generated during an attack to cause network security devices to fail in the detection of the attack. They can be applied in different layers; for instance, you can perform layer-3 (IP) evasions by using IP fragmentation, setting your maximum fragment size to 64 bytes. Configuration for IP fragmentation can also accomodate changing the order the fragments are sent, overlapping the fragments in a variety of ways, having the Security component reassemble the frames according to the policy of a given operating system, and even having the client side fragments be a different size than those from the server side.
Of course, IP fragmentation isn't the only way an attacker can attempt evading detection. Evasions exist in each layer of the protocol stack, and they can be applied to Security attacks in the BreakingPoint products individually or in concert to help users find where their IPS fails to detect attacks.
Configuring IP Fragmentation in the Attack Manager

The full list of Security evasion options are available in a couple of ways. They are listed in the BreakingPoint User Guide, which is available from BreakingPoint Systems Documentation page on StrikeCenter (authentication required). Take a look at chapter 6 under Attack Group Options for further information. An alternate way is to use the Attack Manager in the BreakingPoint GUI. The options that are available depend on the specific strikes and strikesets that you have added to your Attack Series.
Getting Back to the Code
So, now's the time to fire up the latest version of harness.tcl to follow along. This is the script that performs the initial connection to your BreakingPoint device and puts you into the interactive TCL shell. Make sure that you're running the script from the directory in which you've extracted lib.tcl, which holds some utility functions that we will need in these examples.
As you have noticed, Security Evasions are grouped together according to what protocols they affect. We've already looked at IP fragmentation, but you can also set options for Ethernet, TCP, UDP, higher-level protocols like HTTP, and even HTML.
So, lets load up the TCL harness and get started:
[*] Connected...
% $bps configure -name "TCL Security Evasion Test"
% set security [$bps createComponent security security-evade]
% $security configure -attackPlan "Clientside Strikes"
% $security setDomain client 1 default
% $security setDomain server 2 default
Here, we've named our test, and selected to use an Attack Series that targets clientside vulnerabilities. If you want to run an existing Attack Series, but are unsure the name to use, you can get a listing with the following command:
% $bps listAttackSeries
When using TCL, we setup the evasion options using nested TCL dictionaries. Most other languages call this data type a hash. Conceptually, the options we will set in this example are hierarchically ordered like this:
This configuration will cause all clientside connections to be made to the server's TCP port 9999, which is useful in testing that the IPS can detect HTTP attacks that are on a port other than the standard port 80. Further, the server's responses will use HTTP chunked encoding, with a chunk size of 100 bytes. This is a good test of the IPS normalization or reassembly engine.
In TCL, this configuration is done as follows:
% set params { TCP { DestinationPortType static DestinationPort 9999 } HTTP { ServerChunkedTransfer true ServerChunkedTransferSize 100 } }
% set xml [_paramOverridesXml [$security id] $params]
% $bps _execXml $xml
% $bps save
% $bps run
The set params line is just the TCL way to define a dictionary, which are key/value pairs. Again, I'm nesting multiple dictionaries. You alternately could use the TCL construct dict create. The second line makes a call to a function I've defined in lib.tcl, _paramOverridesXml. This function generates the XML that we pass to the _execXml call.
With the ability to automate tests, and now with the ability to automate evasions, you can really put an IPS through its paces. You can hone in on a particular filter, and test different evasion techniques to see when detection of a particular attack fails. If you see that a filter fails when non-standard ports are used for HTTP, and you have an HTTP server that listens on a non-standard port, it might make sense to reconfigure the applicable filters to match on that port, and rerun the test again to see how detection rates change. It also makes sense to add background traffic to your test to see how performance changes with the reconfiguration of your filters.
This post shows an API function we haven't used previously, namely the _execXml method. This method is in the TCL API to allow the TCL UI to take advantage of new features that did not exist at the time the TCL API was developed. The GUI communicates with the BreakingPoint device using XML messages. If you're the kind that likes to look at lower-level stuff like this, take your favorite copy of tcpdump and filter on port 8880. You can take XML messages sent from the client, save them in a string in TCL, and use _execXML. If there is some function of the BreakingPoint GUI that doesn't exist in the TCL API, you can extend your scripts using this method call and the appropriate XML.
The code archive for this post updates the previous examples by adding the ability to add evasions to either a single strike, or a set of strikes. Please download, experiment, and post back with questions or examples of your of TCL-fu!
Tags: