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

Posted by Sean Bradley

Printer Friendly Create PDF

1 comments
Tags: Application Protocol Fuzzing //