Setting The Standard

Next week is my favorite week of the year. It's the Sales Operations meetings held at our headquarters in Austin. Each year we bring the sales people and sales engineers together to review the previous year and preview the year moving forward. More importantly I get to show off.

2009, from all facets, was an incredible year here at BreakingPoint. Sales had an amazing year, with huge growth. Our employee base grew by nearly 30%, much of that being our heavy investment in the security group. We put out 3 major releases and 3 minor releases of our firmware for the BreakingPoint Elite. And our application protocol list now tops more than 100 and our strikes are over 4,300.

This news is certainly exciting, but that was last year. And this is a completely new year and we are ramping up in engineering like you could not imagine. The next firmware release will once again improve the performance of everything from our application protocols, security engine and our SSL. And, of course this is all done without having to replace your blades and at no extra cost. Bet your other vendors don't say that every year.

Next month I'll be putting together a screencast showing you all the features in our next release. I'll save all the juicy bits for then, but here is a teaser of what to expect:

• Five new test labs, including huge strides for mobile networks.
• Changes in the way we are using the NetLogic network processor.
• Switch from using our network processor cores to do SSL, to leveraging the encryption engine on the chip itself (the impact this has on our number of handshakes is staggering).

Last year we changed the way people test their network equipment, this year we will set the standard.

Reminds me of when I worked at Cisco many years ago and Kevin Kennedy (Vice President) would show a slide in which Cisco was compared to other similar companies. There must have been 30 companies listed and at the time 3Com was below us, Lucent ahead of us and all the way at the top were companies like HP. At the time HP was 10x the size of Cisco. Today, Cisco is tens of billions of dollars ahead of HP, with a third of the employees. 

Every year that presentation showed Cisco passing yet another company. We have the same chart for our industry and the same goals, and some companies were ahead of us at the beginning of 2009. During 2009 we passed four of them and this year we will pass four more. And one day, like Cisco, we'll be at the top of everyone else's list.

NOTE: Sometimes Cisco didn't pass a company, the company fell. I'm seeing a lot of that lately, maybe I should send some flowers.

VoIP

VoIP resources

White Paper: Simulating Distributed Denial-of-Service with BreakingPoint

Today we have released a new white paper that I've been working on entitled "Simulating Distributed Denial-of-Service with BreakingPoint".  This paper describes how to configure your BreakingPoint product's Network Neighborhood to simulate the traffic profile normally associated with a DDoS attack and then outlines a number of DDoS attack scenarios.  I've also provided a link below to a packaged version that includes product test cases to simulate the scenarios described in the paper.

Of the scenarios presented, there are several recent real-world analogies.  For example, the group of HTTP scenarios in the paper are similar in nature to multiple DDoS attacks that were recently launched simultaneously against our very own HD Moore's Metasploit Project website, alongside other information security and hacking related websites. You can read his ongoing commentary from during and after the attacks on the Metasploit Blog, beginning with this post.

The last scenario discussed in the paper is one of my all-time favorite DDoSes from when I was focusing a lot of my research efforts within the scope of VoIP systems and technologies.  I regularly employed the tactic outlined by this scenario to demonstrate how a DDoS attack can effectively fly under most network security devices' radar by avoiding the usual DDoS traffic model and by shifting the target of the attack from the technology itself to elsewhere.  I won't ruin the surprise here, you'll have to download the paper to find out what I'm talking about...

Finally, some of the test cases were created via scripting within the BreakingPoint TCL interface, so the paper also provides an introduction to that topic as well as the TCL scripts themselves.  Todd Manning has recently been blogging here on this topic, the posts for which you can find by browsing this blog using the "tcl" tag.

We invite you to take a look at the paper, which can be found here (PDF).  The package which includes the paper as well as supporting materials such as test cases and TCL scripts can be found here.

Building a Better Botnet

Earlier this year, Dennis and Kyle put together a screencast overview of BreakingPoint's capabilities for simulating botnets. Today, I'd like to go into a little more detail about the AppSim component that's most associated with malicious traffic, IRC.

While most of our AppSim components are used to simulate good, normal traffic -- HTTP, Oracle, VoIP, etc. -- IRC stands out as a protocol that is, for better or worse, often associated with malicious traffic. Of course, not everything on IRC evil. However, IRC is the traditional medium for setting up command and control channels for botnets, those armies of compromised end-user machines performing attacks such as DDOSes, spam campaigns, vulnerability scanning, and other evil deeds. So, for most ISPs and enterprises, it's not very useful to just detect the presence of IRC traffic; it's much more worthwhile to detect particular patterns associated with botnet activity. Given that, let's build up a quick botnet that your fancy expensive detection device claims coverage for to see what sticks. In this example, we'll model a fictional botnet (DdosHax) that uses channel topic changes to signal to compromised hosts, from the point of view of the bot herder's local network.

First, we'll fire up the IRC AppSim Superflow editor, and populate a new superflow with the IRC actions we're interested in:

That gives us a channel join, a couple of other users joining the same channel (our bots), a topic change (the command), and the bot responses (command acknowledgements).

Next, we'll fill in the salient details of the bot herder's user name and the network he's joining.

And finally, we'll set the options for our flow actions so this all looks like a typical botnet communication. We can set the command of "!sf 192.168.1.1" to the channel topic:

And generate a response from several peers:

Here, we can see that the naming convention is pretty flexible for the number of bot hosts we'd like to simulate. In this case, we set a range between "a0" and "b9", which gives 20 remote peers, all of whom include the range indicator in their names (zombie-a0 through zombie-b9). If we'd prefer randomized names, we could uncheck the "Include Range in Name?" options, and if we wanted completely random names, we'd uncheck Peer Nick Prefix as well. If you wanted a hundred peers, simply set the range from 1 to 100, or 'aaa' to 'adv', or whatever other range naming scheme that strikes your fancy.

Once this AppSim is run on the wire, we can take a look at the traffic with a regular packet sniffer:

That looks pretty evil to me -- and best of all, the whole procedure took about five or six minutes to set up from scratch, without all the futzing around with setting up real IRC servers and clients, writing scripted actions and responses, or editing up packet capture files.

Multimedia Message System (MMS) MM1 Protocol

In the most recent StrikePack we included an AppSim to support the Multimedia Messaging Service (MMS) MM1 protocol.  MM1 is the 3GPP interface between the MMS User Agent, which generally resides on the Mobile Station (MS), and the MMS Center (MMSC), and is used for sending and retrieving Multimedia Messages to and from the MMSC and for managing the subscriber's Multimedia Mailbox (MMBox) on the MMSC.  This is essentially how your cellular phone sends and retrieves picture or video messages.

Having worked for nearly my entire tenure at Sipera Systems with cellular protocols (focused on dual-mode VoIP phones), I was already familiar with the overall architecture but I had not had the opportunity while there to dig into the details of the MMS system.  Overall, the MMS system encapsulates eleven different protocols, aptly named MM1 through MM11.  The AppSim included in the most recent StrikePack implements some basic support for the first one, MM1.

MM1, as mentioned above, handles communication for sending and retrieval of media messages via the MMSC, which houses the user's MMBox.  This communication protocol is request and response based and can be sent over either of two transports, the Wireless Session Protocol (WSP, cellular network) or HTTP (data network).  Our AppSim currently only supports transport over HTTP as this is what is more likely to be found on a data network.  In both cases, MMS Protocol Data Units (PDUs) are transported as a content-type of 'application/vnd.wap.mms-message'.  If the message contains media, it is transported as a content-type of 'application/vnd.wap.multipart.related' and is structured per RFC-2387.

The bit about MM1 that I found rather interesting is that, intended to be used over cellular networks, a fairly diligent effort was made to reduce the size of messages as much as possible even though the protocol was seemingly based on the Internet Message Format (IMF, RFC-2822) which is a generalized text (specifically, 7-bit US-ASCII) data messaging format resembling SMTP messages or HTTP responses with single-line header fields and an optional body, or payload, portion.  The size reduction is accomplished using a portion of the Wireless Application Protocol (WAP) standard called Wireless Session Protocol (WSP).  The WSP protocol provides a utility for encoding well-known IMF headers into much shorter, binary representations usually consisting of a single 8-bit integer value called the 'Type' which represents the header name and a Type-specific value of one or more of six primitive data types of 'bit', 'octet', 'uint8', 'uint16', 'uint32' and 'uintvar' which represent the header's value.

'uintvar' is a variable length unsigned integer, itself with it's OWN special type of encoding which consists of taking your normal integer value of whatever size, splicing it up into groups of 7 bits and putting those into subsequent octets using the eighth and most significant bit of each octet as a 'continue' indicator to the decoder so that while decoding it knows the integer value continues with more data in the next octet.  A pretty slick way to do it, but very much unreadable to a human on the wire and a bit of a pain to implement.  I definitely had to dust off my bitwisdom to tackle that one.

Due to there apparently not being an existing Ruby library for encoding/decoding WSP, I essentially had to code most of this up myself from scratch using the specification and a few example pcaps.  Because each header and it's value has it's own, often unique encoding, even for only the headers that we currently support it was a fairly tedious task and required quite a bit of testing and bug fixing.  Luckily Wireshark does have a dissector for MMS (filter for mmse) and was able to lend a hand parsing the development AppSim's output as I built it.  This code is essentially what translates the header setting values that our users provide to the AppSim into the proper binary-encoded header block of data used in the configured action's associated message on the wire.

The BreakingPoint MMS-MM1 AppSim currently supports four actions equating to two types of MM1 messages; Raw Request, Raw Response, Raw Body Request, and Raw Body Response.  The first two require only that the user upload two files, each containing the message to be sent's raw header data and raw body data.  These are ideal for use in replicating messages from a source pcap or other data capture.  The second two require the user upload a single file, the message to be sent's raw body data and have a number of settings which when configured will generate a properly encoded MM1 header to append the supplied raw body data to.

Look for AppSims for both WSP and the remaining MMS protocols (MM2-MM11) in future StrikePack updates!