Garett Montgomery, Sr. Security Research Engineer at Ixia
Sr. Security Research Engineer at Ixia

Checking Vulnerability Coverage Using StrikeVariants

April 28, 2015 by Garett Montgomery

StrikeVariants was first introduced with the Ixia BreakingPoint 3.4 firmware release. It began life as a tool for strike developers to ensure validity of all exploit versions of a strike. StrikeVariants deconstructs each strike by generating a separate version for each combination and removing the randomness from each one. In short, a separate strike is generated for each possible combination of options within the strike.

We've now integrated StrikeVariants into the Ixia BreakingPoint Security Engine, enabling several powerful use cases. Today, I'll describe how it can be used to test the coverage of a particular vulnerability by a network protection device.

If you'd like to follow along, be sure you're running Ixia BreakingPoint firmware 3.4 or greater. You should also download the latest ATI strike pack to ensure that you can test the same strikes.

StrikeVariants has been implemented as an Evasion Profile (with several different test modes), which means it can be applied to any strike in a strike list. However, this also means that, like any other Evasion Profile, if the evasion does not apply to the strike, you won't see any changes to the way the strike is run. The Evasion will only be applied to strikes with a Variants count of two (2) or more.

StrikeVariant 1

Today, we're going to see how well one of the IPS devices in our lab does against some recently-released strikes.

StrikeVariant 3

StrikeVariant tests can take a little longer to start because the Variants are created as part of the test run. Once the test starts, you can go to the Attacks tab to check on the progress.

Once there, you may notice something counter-intuitive about the progress being displayed:

StrikeVariant 4

Note that the example shows “Completed 12 out if 1 strikes.” How can the completed count be greater than the total count? And why is the total count 1?— I thought this strike had 24 Variants?

When running a StrikeVariants test, the number shown on the right (Total) represents the number of strikes in the strike list. The number on the left (Completed) refers to the number of individual Variants being replayed. At the top, the progress bar measures the completion of all StrikeVariants. And, lastly, a test may sometimes finish and, under Completed, may show less than the total number of StrikeVariants. If this happens, check the Test Report. —All StrikeVariants should be listed in the StrikeDetails section.

In any case, once the Test completed, I was happy to see that all the StrikeVariants had been blocked. But, when I checked the IPS, I saw that they had been blocked, not because they were flagged as malicious, but because the PDF files made use of a compression method (Flate- and ASCIIHex- encoding). Considering how often PDF files make use of compression, this signature is not likely to be enabled, and this IPS won't block the strike in a real-world situation.

Additionally, for my testing, I set the FileTransportProtocol to HTTP. This—makes it easier to view the payload in a pcap. With the FileTransportMethod set to SMTP —(the default—), the IPS didn't flag a single one of the strikes.

While the above test results were illuminating—and concerning—it didn't do a very good job of showing the full potential of how you can use the StrikeVariants feature. To do that, we're going to need to find a strike that an IPS legitimately blocks. (I would say the IPS failed to cover the previous vulnerability.) Turns out a strike released in ATI-2015-07 for a Memory Corruption vulnerability in Internet Explorer (CVE-2015-0099) will work nicely.

I created a new strike list with /strikes/exploits/browser/cve_2015_0099_ms_ie_buildAnimation.xml (288 Variants) and modified the test from above to use the strike list.

StrikeVariant 5

In the graphic above, you can see that the IPS is able to block some of the variants, but not all of them. At the end of the run, the IPS had blocked exactly half of the Variants: —144. Unfortunately, the IPS again failed to block on the exploitation of the vulnerability—a generic alert about JavaScript Obfuscation is all we get. But, at least this time, it is flagged with a higher severity.

Even though we didn't get the results we were hoping for, it does show one of the primary benefits of testing using the StrikeVariants feature. Prior to StrikeVariants (Ixia BreakingPoint < 3.4), you would have had to run the strike many, many times in order to see similar results. And you would never have known if you had tested all the different versions—(e.g., some strikes have 10,000+ Variants).

Using StrikeVariants, you know exactly how many variations a strike has, and you only have to run one test to go through them all. Using the variant number in the Strike Name field you can easily see which variants are blocked and which are allowed. The Test Report makes it easy to determine which stream within the pcap you need to examine (rather than trying to comb through the packet capture and correlate each of the individual payloads).

StrikeVariant 6

So now what? Well, you can take a strike from the allowed list and compare it with a strike from the blocked list. To do that you'll need to examine the TCP streams within the pcap. But at least you don't have to try comparing 200+ streams against each other. —You can just match up the stream numbers with the strike numbers.

When I opened up my pcap and looked at the first stream, I could see immediately why the IPS had flagged it—: the JavaScript does indeed look suspicious. In fact, all the blocked strikes will have obfuscated JavaScript similar to below.

StrikeVariant 7

In the case of this strike, the difference between allowed and blocked strikes is quite clear. But if we open up two other TCP streams, we can compare them to get a better sense of what StrikeVariant actually means.

StrikeVariant 8

Looking at the files above, can you spot the differences? There are some obvious differences in variable names and the text in the code tag, but those are due to the randomness inherent in the functions used to generate them.* This particular exploit has a few requirements that must be present, but they can be implemented in various ways.

In the file on the left, you can see that there are two child CSS rules, one of which begins with a percentage value. Only one rule is used by the variant on the right; —it relies on the default @keyframes value. There is also a CSS style rule that gets applied to all code tags in the variant on the right, but it is applied specifically to one tag, by using an attribute, in the variant on the left.

There are also other differences among the other variants for this strike. If you have time, see if you can spot all the differences. Meanwhile, the examples highlighted above illustrate the point.

Hopefully this post has helped shed some light on the StrikeVariants feature, including what it does and how to you can use it. And hopefully this feature will get put to good use by the IPS vendors who are supposed to protect our networks from all the different ways a vulnerability can be exploited.

More details on StrikeVariants can be found at

*Variants refer to the different combinations and ordering of building blocks that can be used to construct an exploit, —not the content of the individual building blocks. If you want the exact same payload—exploit structure, as well as contents —then you must use the same non-zero seed value for each of your tests.

Leverage Subscription Service to Stay Ahead of Attacks

The Ixia BreakingPoint Application and Threat Intelligence (ATI) program provides bi-weekly updates of the latest application protocols and attacks for use with Ixia platforms.

Additional Resources:

View Ixia’s Full ATI Protocol List