Filling the Application Gap
Application traffic continues to grow at an astonishing pace, which certainly means many things to many people, but for Network Equipment Manufacturers (NEMs) and service providers it means that network devices must perform with all of this traffic AND do it at high-speeds of 10 gigabit per second and faster. Today we announced a toolkit to allow for native generation of stateful proprietary application traffic (news release). I thought I would also share a couple of graphics we've been working on to show the "application gap" that exists and what we are trying to do about it:
Legacy test vendors have been unable to meet the application traffic needs of NEMs and service providers due to their locked-down architecture. However it is critical to be able to test network equipment with stateful application traffic including business, recreational, malicious, and proprietary application traffic.
As slide 2 shows, BreakingPoint is closing the "application gap" with the release of this toolkit which allows, for the first time, native generation of stateful proprietary application traffic. The equation becomes simple: business, recreational, malicious, and proprietary application traffic plus the ability to simulate this traffic at speeds of 10 Gigabits per second on a single interface and scale up to 160 Gigabits per second and you are talking "real-world performance testing".
Faster, ActiveX! Kill, Kill!
If you haven't thought about ActiveX Exploitation in a while, a read-through of Warlord's January 2008 article, "ActiveX - Active Exploitation" is in order. I bring this up because the next StrikePack will feature a new strike, "Analysis: Killed ActiveX Instantiation."
As the name implies, this strike iterates through the client-side ActiveX controls that Microsoft has "killed" via the kill bit mechanism, and simulates a series of evil web pages which instantiate those controls. As of today, there are 445 kill bits set on Windows XP and Vista. These are all controls that Microsoft, in no uncertain terms, has labeled as Very Bad For Internet Explorer. If you run any of these controls, your browser will crash in horrible ways, or you risk getting commands passed directly to the shell, or your browser hands over all your personal data, or some other awful desktop fate.
Instantiating these controls is easy -- just deliver an OBJECT tag with the appropriate CLSID, reference the object with your exploitastic Javascript, and you're pretty much done. Thus, you would think that blocking these controls from instantiating in the first place would be as fundamental to malware detection as any string matching Slammer or Blaster signature.
However, informal testing of a couple devices we have around the office proved this assumption to be baseless. Rather than the forty or fifty percent detection rates I was expecting, I found rates between zero and ten percent.
Admittedly, I had low expectations to begin with, so I wasn't exactly shocked. That said, if you're in the market for a fancy expensive device that claims client-side coverage, you may want consider how that gear stacks up against vendor confirmed, publicly disclosed, easy to use browser vectors.
Load Profiles for Layer 4-7 Traffic
Dennis just put together a new screencast which gives you a quick tour of load profiles for Layer 4-7 traffic. He also goes into how to create steps and loops in Layer 2/3 test components. For current BreakingPoint users, the load profiles shown in the screencast will be found in the 1.2.1 release.
Below is a preview or you can always view it in full glory in a Separate Window (it's a little over 6 min.).
Deep Packet Inspection (DPI) Webinar
NSS Labs has announced a Webinar series focused on "High-Speed Deep Packet Inspection (DPI)". The Webinar series starts on July 16th at 10am PDT with NSS Labs Chief Scientist, Bob Walder and CEO, Vik Phatak. After the first one we will certainly be discussing in more detail here on the blog and welcome you to ping us on Twitter during the webinar.
More information and registration.
When Looking Bad Makes You Good
Aren’t you afraid you’re going to make everybody look bad?
I often get asked this question when I am demonstrating the product, discussing test results, or explaining how my product works to the folks who are testing network devices. Why is it that everyone is afraid of looking bad? It seems like the whole network industry has been immersed in this fear for so long that they’re willing to do anything to look good.
Test gear companies are aware of this fear, so they’ve built their products to favor specific network equipment vendors. At the end of the day, test gear companies will do anything to ensure that their customers’ products don’t look bad – even if it means tweaking their test gear to work better with certain network equipment. My problem with this is: how will network equipment manufacturers ever know if their stuff really works if they’re not breaking their equipment?
One of the reasons why the companies I’ve been with have all been successful is because we focused on breaking our equipment. I wanted to find test gear that showed me the problems with our products; I wasn’t particularly looking for test gear that would help improve the specs on our data sheets. Obviously, that’ s not a bad thing, but it’s not the most important thing. The most important thing for us was finding the issues with our products before they were released into the field. After all, the field is the worse place to find an issue, the costs are a lot higher and the debugging time is infinitely longer.
So, my answer to the question, “Aren’t you afraid you’re going to make everyone look bad?” is no. I’m afraid of what will happen if someone installs network equipment that wasn’t properly tested. I’m afraid something terrible will happen, like a CEO not being able to access their e-mail or giant wombats overtaking the world.
What do you use your test gear for?
File Format Vulnerabilities and Dynamic Exploit Generators
File format vulnerabilities make for very interesting network security device test cases. Due to their nature and how they're transported within network traffic, there are generally multiple layers of data structure, formatting, encoding, and potential obfuscation in play. Not only must you consider the file format in question's own internal structure, but quite frequently there is further embedded content within that structure. This entire file object, being it's own self-contained entity, is then potentially being sent over any number of various network transports. Because the vulnerabilities usually lie in some anomalous use of the file format's internal structure, a bad value contained within that structure, or embedded content within the file, a network security device that intends to detect this maliciousness not only needs to be able to recognize it wherever in the network packet flow it may be, but also be able to reconstruct potentially fragmented data, decode potentially encoded data, and then identify the malicious bit itself.
To better illustrate this dilemma, let's take a look at the recent ms08-033 AVI/MJPG vulnerability. AVI is essentially a RIFF file with some particular AVI-specific FourCC tagged LISTs and chunks. The vulnerability here lies in the value of the "biHeight" field within the BITMAPINFOHEADER structure, which is essentially the AVI "stream format" ("strf") chunk. This chunk is part of a "strl" LIST that describes an individual video stream contained within the file, which, along with other "strl" LISTs generally follow the main AVI header ("strh") chunk. By populating the "biHeight" field with a negative value (I had success with values -1 through -31), you can trigger the vulnerability described in the advisory and cause Windows Media Player to crash. Windows Media Player also doesn't seem to care too much about what Codec you indicate that the video stream should be processed with ("fccHandler") in the AVISTREAMHEADER. Either Windows Media Player defaults unrecognized handlers to the MJPG Codec, or it determines where to send stream data with an unrecognized handler value based on recognizing the encoding method applied to the stream data itself. Further explanation of the vulnerability can be found in a post by Mark Dowd over at ISS's Frequency X blog.
The strikes that are included in the Security component of the BPS product generally draw upon a back-end code-base that is capable of generating the various bits of data that are used during the strike's attack. For file format vulnerabilities, this back-end is usually a dynamic file generator that can generate randomized, but still valid, files of the type in question. This back-end is then coupled with individual strike descriptions which describe the parts of the attack such as various meta-data, the network connections involved, and what actual data is sent across the wire within those connections. For file format vulnerabilities, the possibilities here are endless. Due to the file being a self-contained unit, it can be sent from attacker to victim over any number of transports such as HTTP, FTP, POP3, SMTP, IMAP, peer-to-peer applications, tunneled protocols, embedded within other files, and so forth. Many of these available transports also provide for multiple types of data encoding during transport, such as SMTP's Base64, Quoted-Printable, and UUEncoded variations.
For the ms08-033 example given above, we have developed 8 different transport-and-encoding-based strikes, each of which plug into the RIFF(AVI/MJPG)-generating back-end to dynamically generate the malicious file being transferred. When you do the math on all of the permutations of the bits of data that a network security device either MUST (to properly detect the badness) or SHOULD (to avoid false positives) be included in a signature or filter for this vulnerability, not including everything else that is randomized by our RIFF-generating back-end, you end up with 1,065,151,889,408 (yes, that's just over one trillion) attack permutations, or malicious, vulnerability-triggering attacks. These attacks can be produced via the eight ms08-033 strikes that will be included in our next StrikePack. Any network security device's filters or signatures must be able to match on all of these permutations, do it reliably, and not false positive on legitimate AVI/MJPG files in order to legitimately claim coverage for this vulnerability. A daunting task indeed.
National IPS Testing Week
Looks like this is the week to talk about IPS testing. NSS Labs had some very interesting news and a blog post around their upcoming testing of 10 Gbps IPS devices. BreakingPoint is involved with the NSS Labs test, who released their IPS test methodology in conjunction with the announcement. It is important and interesting to watch other testing methods, particularly from a respected group like NSS Labs. This got me thinking about the one video in our series that I mentioned in my earlier post; "Testing Victims". This video brings home a critical issue around testing content-aware devices when Rik and Dennis discuss how the equipment most likely won't come within 50% of their public performance claims. And the guys note that it's not their fault. It's the legacy testing equipment they used that couldn't truly test the devices with stateful application traffic at the right speeds.
Because I hate to see "National IPS Testing Week" (my unofficial claim...for now) come to an end I wanted to highlight some of the individual videos, starting with "Testing Victims". You can check out all eight videos on the IPS Test page.
Test Methodology Released: Calling the Community
A week or so ago I posted our introduction video for a test methodology series that BreakingPoint is putting out to the community. Today we made the first methodology public, this one for Intrusion Prevention Systems (IPS). Dennis and Rik do a fantastic job in the videos, broken into eight “chapters”. They describe the methodology, testing techniques and results. My personal fave...when they talk about the testing "victims".
Here’s the thing, these are a great resource, guidelines if you will, to effective testing of content-aware network equipment. But they are a starting point, and this is exactly what Dennis and Rik had in mind. They want to hear from people about the methodologies. This should be a community effort for anyone interested in testing next-gen network devices.
I’ll get us started…what would you like Dennis and Rik to test next? Leave your thought in the comment below.
Here is the main page with the links to the series of eight videos.
Introduction video is below if you missed it the first time:
P.S. If you haven't already, check us out on Twitter.
Accelerating Development: What We Mean
As you've seen in our new logo and throughout our site the concept of "accelerating development" has become a calling card for BreakingPoint. Stories like the one Dennis shared last week really drive home how test can not only improve the quality, performance and security of a network device, but if done correctly it can speed up the actual development. In an era when our network devices are being asked to do more and NEMs & service providers must deliver, the concept of accelerating development should be a mantra, particularly in the testing world.
This morning BreakingPoint unveiled v1.2 of our testing software, there are a bunch of customer-driven enhancements including support for 50+ application protocols, support for IPv6 and SSL, enhanced multi-box management and real-time reporting. Check out the full release for all the details. The part I've latched onto lately, particularly when you discuss acceleration, is the architecture.
Architecture is the key to future longevity and competitive advantage, whether you are building a new office tower or a testing platform. At BreakingPoint we had a couple of goals with our architecture:
- Loosely couple the application protocol and security layer with test management software and high-performance hardware. This allows for continuous release of new applications, security updates, and testing functionality; critical to adapting rapidly to today’s dynamic content-aware network environments.
- Allow for quick, easy and cost-effective testing using proprietary applications; very important for customers to be able to leverage a high-performance, adaptive architecture, not to mention experts at BreakingPoint Labs, to test their own apps on the network devices.
- Time-to-test...let's just say it needs to be fast...how about being ready to test within 5 minutes of deployment; this one is certainly self-explanatory when it comes to accelerating development.
There is a critical question here that we should all be asking; is the architecture of your testing solution able to handle the twists and turns of testing next-generation content-aware network devices?