BreakingPoint & VMware Networking
Today, I'll show you how you can use a VMware server to quickly switch between different test devices without ever leaving your desk. Then I'll fire up some sample tests against a virtual Linux host.
Why VMware
Working for BreakingPoint Labs, we are faced with rapid release cycles and a broad range of tasks. Sometimes it is working to provide timely Microsoft Patch Tuesday Strike coverage, other times it is reverse engineering a protocol and implementing it with Application Simulator. Frequently we have to quickly pick up strange new aspects of the computer world and just run with it.
Since we switch gears a lot, we make heavy use of VMware Workstation™ on our personal development machines. This works perfectly right up until we need to use BreakingPoint to target our environment. Our development BreakingPoint test products are located in a rack in a lab, but we are living in cubicle land.
VMware Server 2™ is a nice solution. It has a remote web console where all of the BreakingPoint Labs developers can add/configure new virtual servers without affecting each others setup. With a dedicated server in our rack for VMware, we can configure what kind of target our BreakingPoint product is connected to without ever leaving our cubes.
The Setup
You can grab a copy of VMware Server 2 here. You'll need a server with adequate RAM and disk space, as well as at least 3 physical network interfaces. That is one for a regular LAN connection and at least two that connect directly to the ports on you BreakingPoint product.
After getting VMware up and running, you'll need to add two new virtual interfaces in bridged mode. This can be very simply done by the "vmware-config.pl" wizard. I like to name these VMLAN1 and VMLAN2. If you like, you can also add new vmnet interfaces for the other two test ports. These will take the traffic your BreakingPoint product is generating and pipe it into your virtual environment.
When you create a new virtual machine, you should be able to see and add the custom bridged network interfaces via the "add new hardware" wizard. After your virtual machine is booted, you will want to make sure the virtual machine's network settings match up with a configured BreakingPoint "Network Neighborhood".
Blasting Linux with a Packet Cannon
As an example, I'll run a test against a Linux VM that I have set up. I would say the typical use case for Linux networking is a home NAT router/firewall. So, I've set up a standard Ubuntu Server in VMware and configured it to perform NAT for all LAN hosts with a simple iptables script. BreakingPoint is also configured to use a NAT Network Neighborhood so that it will recognize packets with the source address rewritten.
# eth2 is the LAN side, eth1 is the WAN side echo 1 >> /proc/sys/net/ipv4/ip_forward /sbin/iptables -F /sbin/iptables -P FORWARD DROP /sbin/iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE /sbin/iptables -A FORWARD -i eth2 -j ACCEPT # Let LAN traffic through /sbin/iptables -A FORWARD -o eth2 -j ACCEPT /sbin/iptables -A INPUT -i eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT
This firewall script will enable NAT with connection tracking for the traffic that passes through the Linux device. The tracking of every session should be putting quite a load on the virtual CPU. I will also be running ntop on the VM to get some graphs of what traffic it sees from its perspective.
Application Simulator: Small to Medium Business Apps
I'll start off by running the Application Simulator preset for SOHO routers for 10 minutes. This will send a reasonable amount of traffic considering that it is virtual networking on commodity hardware. This test is about right for such a router. Note the CPU usage for the ntop daemon.
Ntop Stats from the Linux VM
Ntop CPU Usage
BreakingPoint Traffic (RX and TX rates match up)
Application Simulator: Max Bandwidth
This Application Simulator preset run as many of the highest bandwidth applications as fast as it can. Considering just how much that can be, this will simply DoS the Linux VM. The data rate is fast enough that even though the traffic is realistic, its effectively just a SYN flood. The gathered data shows effectively the same thing.
NTop Stats (Not much is getting through)
BreakingPoint Traffic (RX rate nowhere near TX rate)
Switching Gears
The real awesomeness of using VMware comes when you finish with one task and need to do something completely different. I started off with a Linux bandwidth test and now I need to run some Strikes against a Windows Vista machine. All I have to do is boot the Vista virtual machine and double check my network settings.
Strike Level 5 Running Against Windows Vista
Have it your way
There is no reason to limit yourself to just one or two test ports either. With VMware, you can configure any number of hosts connected by any number of LAN segments. You could daisy-chain a few software IPS machines and see how far malicous traffic can go within your network. Or you could run a one-armed test against a web server that is behind a firewall all while flooding the router with P2P traffic. The options are nearly limitless.
Block: Fast Application Protocols in Ruby
Combined with our hardware acceleration, our Ruby-backed AppSim engine can easily pump out traffic at 10 or more gigabits per second.
In this library, protocol information is represented by Ruby objects called Blocks. These blocks can contain protocol-specific configuration options (like URIs, usernames or passwords), protocol state information, and can even contain other block objects. Block objects inherit still more information from their parent classes.
By creating custom protocol libraries with nested blocks, the end result is a simple to use way to create complex network messages. Also, using custom nested blocks leaves the resulting static strings with a multitude of valuable type information that we can use. I will cover more on how we can use that with my next blog post.
The Block Object
The Block object is the core of the Block library. It is the base class of every single block type that we create to define our protocols. Using this class as a base, a developer can create a specific block type like "HTTP::Request::Get", for example.
By combining lists of custom block types, a developer can typically reduce a protocol action (like in the AppManager UI) into a single command using Block. This is aided by convention that any options that don't get specified by a user will be randomly generated to look as realistic as possible.
# Simple FTP USER Command
b(FTP::Commands::USER).gen # => "USER akQA12KN\r\n"
# Simple HTTP GET Request
b(HTTP::Request::Get, :uri => "/index.html").gen # => "GET /index.html HTTP/1.1\r\nHost: a21naasd\r\n\r\n"
Block Syntax
This is the basic way to call into the Block library. The 'b' function is a globally accessible object factory that builds any type of your choosing. You can nest blocks within your block, and give them attributes or parameters.
The syntax used draws heavily on use of Ruby code block syntax. While it looks hairy at first, it simplifys things a bit. It reads a lot like XML, in that you have a element type and then that type can contain any number of other types.
Eventually you will take the object you just created and call the "gen" method on it. This lets Block decide how to best create a string matching the parameters that have been specified.
# Basic form
# b(TypeClass,:attribute=>'value') { |d| [BLOCK VALUE] }
# Static string generation
b(ByteString){|d| "hello"}.gen # => "hello"
# Static integer generation
b(Int::UINT16LE){|d| 0x01020304}.gen # => "\x04\x03\x02\x01"
# Random generation
b(String::AlphaNumeric, :min => 4).gen # => "mUw9"
# Compound Lists
b(ByteString){|d| ["one","two"]}.gen # => "onetwo"
# Deeply nested structure
b(Block){|d|[ # anon function returns array, note array commas
b(Block){|d| attr(:stored_object)},
b(Repeat,:times=>2){|b|[ # can use static attributes
b(Char){|d| "H"},
b(Char){|d| "E"},
b(Char){|d| "L"},
b(Char){|d| "O"},
]},
b(EOL) # uses default or random value for EOL ("\r\n")
]}.gen # => "(StoredObject)HELOHELO\r\n"
Custom Block Types
The real power of the Block library is in creating your own custom Block types. When a full suite of custom Block types are implemented for a protocol, generating realistic traffic becomes straight-forward and simple.
class FTP < Block
module Commands
class USER < Command
@operation = b(Operation){|d|"USER"}
@username = b(AlphaNum,:min=>1,:max=>24)
def encode(data)
b(FTP::Command::Line,:operation=>attr(:operation),:arguments=>[attr(:username)])
end
end
end
end
Block + AppSim
The BreakingPoint AppSim architecture exists to provide high-performance realistic application traffic with the easiest possible user interface. The user is able to supply a multitude of options that fine tune all of this network traffic.
Block was orginally created as an aid for the BreakingPoint Labs to help deal with the often very complex sets of options coming in from the users. Since Block can handle very complex options and auto-generate content, just passing on the AppSim options to a simple command like "b(HTTP::Request::Gen,@user_options)" can transform a simple HTTP message into a very realistic looking one. Easy:
GET /~sean/authd/index.html HTTP/1.1
Host: localhost
Connection: close
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.0.3705; .NET CLR 1.1.4322; Media Center PC 4.0; .NET CLR 2.0.50727)
Accept: */*
Accept-Language: en-us
Accept-Encoding: gzip,deflate
UA-CPU: x86
Authorization: Digest username="httpuser",realm="private",nonce="408b6c576464477d675f04eb86609d90",uri="/~sean/authd/index.html",qop=auth,nc=00000001,cnonce="c9ea9ac0",response="da59792735e59ab97ddf3db1c7a5acde",opaque="5b168ba031c8cfa782b94ae587b79f67"
Fuzzy Logic; Fuzzing BGP
The most recent BreakingPoint StrikePack adds support for BGP, the latest in a series of new fuzzers for routing protocols. Since the last blog post about our Routing Information Protocol (RIP) fuzzers focused more on usage and the BreakingPoint UI, this time the focus will be placed on how BreakingPoint implements it's fuzzers.
What's BGP, you ask?
The Border Gateway Protocol is yet another protocol that is used by routers to share their network topology information and status with other routers. Unlike RIP and OSPF, BGP is an exterior gateway protocol, meaning mostly used to connect (peer) large networks and ISPs together. Also unlike the other routing protocols BGP takes on a very different implementation using a stateful TCP connection and a database of all known router information instead of the more mathematical approach of minimal UDP broadcasts.
Whats in a fuzzer anyway?
Why would someone want to send strange or invalid data to themselves? In short, invalid data is better at getting to the little tested parts of an application and putting it through it's paces. Fuzzers have long been part of the Security Auditor's toolkit, but more and more projects are beginning to use fuzzing as part of their normal Q/A process.
BreakingPoint fuzzers are supported by the Security component in the form of special Strikes. On the BreakingPoint Labs side, a protocol library is written in Ruby and various test cases are created using this code. Each test case is then written up in the BreakingPoint Strike XML format and presented to the user as an individual strike. There are currently 33 such fuzzer strikes provided for the BGP protocol.
Each fuzzer strike typically targets a specific data value or packet type and tries a multitude of different values in turn. The goal is to provide malicious data or to provide too much data in hopes that something will break, showing the user where he needs to focus bug fixing efforts.
When inserting bad data, strings usually get filled with lots of quotes, null characters, and format or other special character sequences in order to try to make the application fail. Integer data types usually get hit with a list of commonly special values like powers of two.
Other types of fuzzers can benchmark certain constraints on the input data. For example, a data packet's size can be increased repeatedly until its maximum size is determined and reported to the user.
Peeking at the BGP Fuzzer
BGP Packet Header
The BGP header is rather simple. It consists of a 16-byte magic value (marker) field to signify itself as the BGP protocol, an 8-bit message type id, and a payload length. Here close attention is paid to the length-encoded payload field. A very common mistake made by application developers is access invalid memory because a length field is not checked.
- header_bad_marker_strings.xml
- header_bad_payload_strings.xml
- header_random_long_payloads.xml
- header_random_payload_bad_length.xml
KeepAlive Message
The KeepAlive message by design has no extra data included in addition to what is sent in the header. Here we add random data to the header's payload section, even though it is not expecting anything. Again the payload lengths are also fuzzed.
- keepalive_extraneous_payload_data_bad_lengths.xml
- keepalive_extraneous_payload_data.xml
Notification Message
There are only two fields in this message type, code and subcode, which are used to convey errors and other messages within the BGP session. All possible valid code combination's are sent, as well as totally random ones.
- notification_all_capability_codes.xml
- notification_all_cease_codes.xml
- notification_all_message_header_codes.xml
- notification_all_open_message_codes.xml
- notification_all_update_message_codes.xml
- notification_random_codes.xml
Open Message
This message type is the most complex of all because it must negotiate a multitude of options between client and server. Since these options consist of several nested layers of length-encoded bit structures, they are a good place to look for parser bugs.
- open_bad_payload_strings.xml
- open_params_bad_parameter_fields.xml
- open_params_bad_string_capabilities.xml
- open_params_invalid_field_length.xml
- open_params_invalid_length_capabilities_entries.xml
- open_params_invalid_length_parameter_entries.xml
- open_params_long_capabilities_entries.xml
- open_params_long_parameter_entries.xml
- open_params_long_parameter_fields.xml
- open_params_random_capability_types.xml
- open_params_random_parameters.xml
- open_params_random_parameter_types.xml
- open_random_bgp_id.xml
- open_random_hold_time.xml
- open_random_version.xml
Update Message
The update message is the main workhorse of BGP. It is responsible for the transfer of routing information to other routers. Again as with the Open type, we have quite a few of variable length-encoded structures to fuzz here.
- update_long_nlri.xml
- update_long_random_path_attributes_bad_length.xml
- update_long_random_path_attributes.xml
- update_long_withdrawn_routes_bad_lengths.xml
- update_long_withdrawn_routes.rb
- update_path_attributes_bad_length.xml
- update_random_path_attributes.xml
Fuzzing the Routing Information Protocol (RIP)
As of the time of this writing, BreakingPoint has implemented 115 unique fuzzer strikes for 13 different protocols, most recently we added support for RIP and OSPF and a fuzzer for BGP will be coming soon. Since BreakingPoint's fuzzers are implemented as security strikes, our users are free to create any number of combinations of individual fuzzer test cases by building a custom strike-set in the Attack Manager. You can also globally tweak certain protocol parameters such as IP fragmentation or enabling several IPS evasion profiles.
Additionally, because we are talking about BreakingPoint testing tools, you can do all of your fuzzing while concurrently sending 10+ gigabits of realistic application traffic.
RIP Background
One of the best features of the modern Internet its amazing level of interconnectedness and fault tolerance. The Internet is able to repair itself as needed because of its fundamental design. As old routers fail or new ones are added, information about those routers is automatically spread around to facilitate the optimization of its resources. The Routing Information Protocol (RIP) is the oldest and simplest of routing protocols still in use today. Its current incarnation (RIP Version 2) is defined by RFC2453, adding several improvements like support for CIDR and authentication. RIP was originally implemented as the “routed” daemon for BSD Unix. Although newer protocols have largely obsoleted RIP, it is still in use today.
RIP takes a very simplistic approach to disseminating routing information based on the Bellman-Ford algorithm for finding shortest paths. This is a distance vector algorithm, meaning the hop count between routers is used to weight which route the protocol sees as optimal. Due to constraints and limitations of the protocol itself, modern RIP only gets limited use as an Interior Gateway Protocol on smaller internal networks.
Getting started
BreakingPoint users can easily set up a custom fuzzer within the BreakingPoint Control Center and create a new Attack Series containing the fuzzer strike-sets that you want to use. You can then create a new test with a security component that uses your new attack series. It is a pretty quick and intuitive process using the same general process you would use to run any of the BreakingPoint fuzzers:
- Figure 1: The Attack Manager screen
After logging on, go to the Attack Manager screen by selecting that option from the “Managers” drop down menu on the top of the screen.
- Figure 2: Creating a new Attack Series
With the Attack Manager screen open, find the panel (in the left middle) labeled “Attack Series” and click the red plus sign button. This creates an empty list of strikes that you will fill with fuzzer strikes and link to a new test later on.
Now you'll need to populate your new attack series with some strikes. To do this locate the panel labeled “Strikes and Strikesets” on the right of the Attack Manager. Click the red plus sign to search for strikes to add.
- Figure 3: Adding the RIP strike set
- Figure 4: Creating the test
- Figure 5: Running the test
From this point everything works just like any normal test. Click “Save and Run” to start it up. Be sure to monitor your test device for any errors that the fuzzers might induce.
Finally, if you get tired of seeing “test failed” every time you run because your device passes some of the fuzzer traffic, you can go to the “Define Test Criteria” menu from the test screen and click “Disable all default criteria” so that your test will always list as passed.
Toorcon X Mini Wrap-Up
On the whole, I was very happy to have attended the 10th Toorcon in San Diego, CA. Toorcon is probably my favorite small con. The attendance isn't massive but the people are generally more interested and knowledgeable in hacking and security. Not to mention that downtown San Diego is a blast and the weather is absolutely perfect. These were my highlights:
The Future of Lockpicking, datagram
I was glad to see a talk on lock picking that went beyond the realm of a simple how to or a single type attack. Datagram didn't spend too long explaining the lockpicking techniques even though he did have some good animated visual aids. Instead, he focused a lot on how a lock vendor would react to new attacks getting media publicity. Just like in the software security world, some vendors wouldn't ever go beyond a PR response. Some vendors would add a metal plate in a certain place, much like a software patch, and others still redesigned the locks entirely. Some very interesting industry parallels.
Owning Telephone Entry Systems, Joshua Brashers
So many apartment complexes, condos, and gated communities have computerized panels that visitors can use to ask permission to gain entry. The talk outlined many different types of attacks against these types of systems. Most of these appear to be serviced by 3rd parties and allow you to remotely dial-in. And of course, default passwords are rarely changed. He showed how he was able to “back door the front gate” by adding a new entry that played a “Rick Roll” instead of calling a resident and later opened the gate. Another and more scary attack he outlined was the ability to proxy normal entry calls to his apartment using a VoIP server to perform the MiTM. This looked like it was a lot of fun.
How To Impress Girls With Browser Memory Protection Bypasses, Alexander Sotirov
This was a great talk. Although Dowd and Sotirov gave this talk at Blackhat almost two months ago. It was still a fun and entertaining talk to sit though. Alex outlined the implementations of the newer Microsoft memory protection schemes like SafeSEH, DEP, and ASLR. Then showed how and why none of them were effective in defending Internet Explorer from attacks and how much that impressed the ladies. The paper is here.
Tags: blog post // cloud computing and virtualization //