“I couldn’t imagine somebody like Osama bin Laden understanding the joy of Hanukkah.” | ||
| --George W. Bush, White House Menorah lighting ceremony, Washington, DC, December 10, 2001 | ||
Although UNIX systems might dominate in the server room, there are more installations of the Microsoft Windows operating system worldwide, which make it an equally coveted attack target. Vulnerabilities affecting the Windows desktop are frequently leveraged in the creation of the many bot nets in existence today. Consider the Slammer worm,[1] which exploits a buffer overflow in Microsoft SQL Server, as a demonstration of the power of a network enabled Windows vulnerability. The vulnerability was addressed in Microsoft Security Bulletin MS02-039[2] on July 24, 2002 and the Slammer worm surfaced on January 25, 2003. The worm has virtually no payload; it simply utilizes the infected host to scan for and spread to other infected machines.[3] Despite its lack of payload, the aggressive scanning generated enough traffic to cause disruption of the Internet, credit card processing, and in some cases cell phone network availability. What is most interesting is that even after four years, the Slammer worm is still among the top five most seen traffic-generating events.[4], [5] Clearly an exposed network vulnerability in Windows has far-reaching implications.
In the previous chapter, we leveraged an existing fuzzer framework, SPIKE, to build a protocol fuzzer in a UNIX environment that targeted the Novell NetMail NMAP daemon. In this chapter, we take a different approach by walking through the construction of a simple Windows-based, GUI-enabled, and user-friendly fuzzer from start to finish. Although the final product, named ProtoFuzz, will only offer basic functionality, it serves as a good platform for expansion and provides a different perspective on fuzzer creation. We kick off the process with a discussion of the desired feature set.
Before we can dive into development, we must first take a step back and consider the features that we both require and desire. At the most basic level, a protocol fuzzer simply transmits mutated packets at a target. So long as the fuzzer has the ability to generate and send data packets, it fits the bill. It would, however, also be nice if we could arm ProtoFuzz with the ability to understand the structure of the packets that we want to fuzz. Let’s expand on these basic requirements.
Before our fuzzer can send a data packet, it needs to understand how to build one. Existing fuzzers take one of three basic approaches when it comes to assembling packets for fuzzing:
Crafted test suites. Both the PROTOS Test Suite[6] and its commercial sister, Codenomicon,[7] hard-code the structure of data packets used for fuzzing. Building test suites such as these is a time-consuming task, as it requires analyzing a protocol specification and then developing perhaps thousands of hard-coded test cases.
Generation fuzzers. As we saw in the previous chapter, tools such as SPIKE require that the user build a template that describes the structure of the data packet. The fuzzer is then responsible for generating and transmitting individual test cases at runtime.
Mutation fuzzers. Rather than building a packet from scratch, an alternate approach is to begin with a known good packet and then successively mutate portions of the packet. Although every byte within the packet could be mutated in a brute force fashion, this would not generally be appropriate for protocol fuzzing, as that approach would be inefficient and produce an abundance of packets that don’t adhere to network protocols and might not even be routed to the target. This approach can be revised slightly by stealing a trick from the protocol template approach. The fuzzer begins with a known good packet, then the user creates a template from that packet by identifying portions of data that should be targeted for fuzzing. This is the approach that will be leveraged by ProtoFuzz.
No single approach is superior to the others and each will be better suited to various situations. Packet mutation was selected for ProtoFuzz due to its simplicity. Starting with a known good packet that can be captured from observed network traffic permits the user to begin fuzzing almost immediately without the need for excessive groundwork researching the protocol and building generation templates.
Because packet mutation has been chosen as the fuzzing approach, it would be prudent for ProtoFuzz to be able to capture network data in promiscuous mode, just like a sniffer. We’ll build a network protocol analyzer into ProtoFuzz so that it will be able to capture traffic to and from our target application and we’ll then select individual packets to fuzz. To implement this capability, we’ll leverage an existing packet capture library as detailed in the “Development” section.
Although not absolutely essential, beyond capturing data, we want ProtoFuzz to be able to present the contents of captured packets in an easy-to-digest format. This will assist the user in identifying portions of the packet that are appropriate for fuzzing. Network packet data is nothing more than a series of bytes that follow a defined pattern. Displaying the data in a human-readable format requires leveraging a capture library capable of understanding packet structure and breaking it down into the various protocol headers and data segments that construct the data stream. Most people are familiar with the presentation format used by Wireshark, so we’ll use that as the basis of our display format. Figure 16.1 displays a simple TCP packet captured by Wireshark.
This specific screen shot from Wireshark shows the display segmented into three panes. The top pane lists the individually captured packets. Selecting one of these packets loads the contents of that packet into the bottom two panes. The middle pane shows the deconstruction of the packet into its individual fields. In this case we can see that Wireshark is familiar with the AOL Instant Messenger protocol, as it has successfully decoded the entire data segment of the TCP packet. Finally, the bottom pane displays the raw hex and ASCII bytes of the selected packet.
Once network data is observed and captured, we want to allow the user to identify portions of it that are to be mutated for fuzzing. To do this, we’ll use a very simple format that encloses portions of the hexadecimal representation of the packet with opening and closing tags. Different tags will be used to represent different types of runtime fuzz variables. This simple format will both allow the user to visually identify fuzz variables and allow ProtoFuzz to identify areas that are to be replaced with fuzz data while parsing the packet structure. We’ll use the following tags:
[XX] Brute force. Bytes enclosed by square brackets will be fuzzed using all possible byte values. Therefore, a single byte will be fuzzed 256 times, whereas a word value (2 bytes) would be fuzzed 65,536 times.
<XX> Strings. Bytes can also be fuzzed by the hexadecimal representation of predefined variable-length strings from a user-controlled text file (Strings.txt). This type of fuzzing would typically be done in the data portions of packets as opposed to header fields, which require a defined structure.
The following template illustrates a TCP packet with both brute force and string fuzz variables.
00 0C F1 A4 83 57 00 13 49 25 D5 72 08 00 45 00 00 28<B0 3B>00 00 FE 06 89 40 C0 A8 01 01 C0 A8 01 02 08 A6 0B 35 14 9E E1 9F 9F 33 69 E5 50 11 10 00 09 4E 00 00 01 00 5E 00 00[16]
Protocol libraries typically take two different approaches when sending data. First, they might have a series of functions that allow you to set certain pieces of data such as the target IP and MAC addresses. However, the majority of the packet structure is built for you, based on the appropriate RFC. A .NET Framework class such as HttpRequest would be an example of such a class. This class allows you to define properties such as the method and URL, but most HTTP headers and all Ethernet, TCP, and IP headers would be created for you. An alternate approach is to create a raw data packet whereby individual bytes are specified and it is up to the programmer to ensure that the packets follow the structure defined in the appropriate RFC. Although the second approach requires more work on the part of the researcher, providing a more granular level of control will provide the ability to fuzz protocol headers as well as the data segments.
Before we discuss how ProtoFuzz was developed, we should first highlight a few important pieces of background information.
As with any type of fuzzing, detecting faults in the target application is critical to uncovering vulnerabilities. There is no perfect way to do this, but some approaches are certainly better than others. One hurdle in protocol fuzzing is that unlike file fuzzing, for example, the fuzzer and target application will likely be separated across two systems. When fuzzing network protocols, attaching a debugger to the target application is a good starting point that allows you to pinpoint both handled and unhandled exceptions that might not otherwise be identified. When using a debugger you will still face the challenge of correlating fuzz packets to the exceptions that they create. Although not foolproof, a workaround for this would involve sending some form of probe after each packet to ensure that the target is still responsive. For example, you could send a ping request to the target and ensure that a reply is received before sending the next fuzz packet. This is far from perfect as an exception could have occurred that would not affect the target’s ability to reply to the ping. However, you can customize the probe for the target in question.
In addition to fault monitoring, we can also monitor the target application for performance degradation. Consider, for example, a malformed data packet that causes an infinite loop within the application logic of the target. No actual fault is generated in this situation, but we do have a DoS condition. Running performance monitors on the target machine such as the Performance Logs and Alerts or System Monitor snap-ins available for Microsoft Management Console can help identify such situations.
Not all transmitted fuzz packets will elicit a response. However, for those that do, it’s important to monitor for the response to ensure that the target application is still properly functioning. This could be taken one step further to also parse the contents of the response packet. That way you would be able to not only identify when responses aren’t received, but additionally identify responses that contain unexpected data.
Many packet capture libraries require the use of a custom protocol driver. The Metro Packet Library[8] selected for ProtoFuzz includes ndisprot.inf, a sample Network Driver Interface Specification (NDIS) protocol driver supplied by Microsoft as part of their Driver Development Kit. NDIS is effectively an API for network adapters that provides applications with the ability to send and receive raw Ethernet packets. Before ProtoFuzz can be used, this driver must be manually installed and started, which can be done from the command line by running net start ndisprot. One downside to using a library that requires a custom driver such as this is the fact that the driver might not be able to handle all types of network adapters. In the case of Metro, the driver will not work, for example, with a wireless adapter.
There are already a number of protocol fuzzers that work perfectly well. If we’re going to create a new one, to avoid building a “me too” project, it will need to offer something that others don’t. Given that many existing fuzzers run from the command line, we aim to differentiate ProtoFuzz with the following goals:
Intuitive. Use of ProtoFuzz should not require a long learning curve. An end user should be able to figure out the basics of the tool without wrestling with a manual or remembering convoluted command-line options.
Ease of use. ProtoFuzz should be immediately functional once it’s started. Rather than require that the user build cumbersome templates to define the structure of a data packet, we’ll leverage the structure of previously captured data packets to build fuzzing templates.
Access to all protocol layers. Some network fuzzers focus on data within the packet as opposed to the protocol headers themselves. ProtoFuzz should be able to fuzz any and all portions of a packet from the Ethernet header down to the TCP/UDP data.
Our goal in producing ProtoFuzz is certainly not to replace existing tools. Rather, it is an effort to construct a basic platform for network fuzzing from a Windows environment that will serve as both a learning tool and as an open source effort available for extension by any interested parties.
As with FileFuzz, our Windows-based file format fuzzing tool, we turned to C# and the Microsoft .NET Framework for the construction of this GUI-driven network protocol fuzzer. The .NET platform handles much of the heavy lifting when it comes to developing GUI applications, allowing you to focus on the business logic of the application, or in our case, the business-breaking logic. .NET applications do require users to install the .NET Framework as a prerequisite. However, the growing prevalence of .NET-based applications is turning this into a minor inconvenience as most systems will already have the library available.
One of the key decisions in the construction of our network protocol fuzzer is the selection of a suitable packet capture library. This library is responsible for three core components: capturing, parsing, and transmitting packets. Although it would certainly be possible to build this functionality from scratch, it is not generally advisable given that a number a robust, open source packet capture libraries already exist.
The fact that we’ve chosen to develop ProtoFuzz on a Windows platform automatically limits our choices in this area. Typically, the library of choice for Microsoft Windows would be WinPcap,[9] an excellent packet capture library that originated when Piero Viano ported libpcap to Windows as part of his graduate thesis. WinPcap has been around for many years now as an open source project and as such has evolved into a strong code base that supports most major protocols. In fact, it is a prerequisite for many commercial and open source applications that need to work with data packets such as Wireshark (previously known as Ethereal) and Core Impact.[10] The WinPcap Web site lists more than 100 tools that leverage the library for packet capture functionality, and that’s just the ones that they know about!
Although WinPcap was considered for ProtoFuzz, the decision to use C# for the development language limited the ease of working with the popular library. WinPcap is written in C and although there have been a handful of attempts to write wrappers to simplify the use of WinPcap from a C# application, we have yet to see a comprehensive project that incorporates all WinPcap functionality. PacketX,[11] a COM class library that provides a wrapper for WinPcap was also considered for this project but was ultimately vetoed due to the fact that it is a commercial library, and when writing this book, we wanted to make every effort to leverage freely distributable libraries.
After a fair bit of searching, we were pleased to stumble across the Metro Packet Library. Although not as robust as WinPcap, this library is written entirely in C#, comes with strong tutorials and documentation, and was more than adequate for the basic fuzzer that we sought to create. The one weakness that Metro suffers from is limited parsing capabilities. It has classes designed to recognize all high-level packet headers—Ethernet, TCP, UDP, ICMP, IPv4, and Address Resolution Protocol (ARP)—but it does not yet have classes designed to understand data within the packets below these headers. Once again, given the modest goals of ProtoFuzz, this was not a major concern and given that Metro is an open source project, we always have the option of extending current classes to develop any needed functionality.
Enough with the theory; it’s time to code. As always, all of the source code for ProtoFuzz is available from the www.fuzzing.org Web site. We won’t go through all portions of the code but in the following sections we highlight some of the more important code segments.
We want ProtoFuzz to be able to capture the traffic that will be used to generate fuzz templates. To do that, the user must first select the network adapter that will be placed in promiscuous mode to sniff traffic. Rather than require that users provide an adapter name or identifier that they’ve discovered manually, we’d like to present them with a simple drop-down menu from which they can select any of the active network adapters on the system. Fortunately, Metro provides classes to make this a relatively simple process, as shown in the following code excerpt:
private const string DRIVER_NAME = @"\.
disprot";
NdisProtocolDriverInterface driver = new NdisProtocolDriverInterface();
try
{
driver.OpenDevice (DRIVER_NAME);
}
catch (SystemException ex)
{
string error = ex.Message;
error += "
";
error += "Please ensure that you have correctly installed the " +
DRIVER_NAME + " device driver.";
error += "Also, make sure it has been started.";
error += "You can start the driver by typing "net start " +
DRIVER_NAME.Substring(DRIVER_NAME.LastIndexOf("\") + 1) +
"" at a command prompt.";
error += "To stop it again, type "net stop " +
DRIVER_NAME.Substring(DRIVER_NAME.LastIndexOf("\") + 1) +
"" in a command prompt.";
error += "
";
error += "Press 'OK' to continue...";
MessageBox.Show(error, "Error", MessageBoxButtons.OK,
MessageBoxIcon.Error);
return;
}
foreach (NetworkAdapter adapter in driver.Adapters)
{
cbxAdapters.Items.Add(adapter.AdapterName);
if (cbxAdapters.Items.Count > 0)
cbxAdapters.SelectedIndex = 0;
}First, we instantiate a new NdisProtocolDriverInterface and then call the OpenDevice() function using the ndisprot network adapter, which the user should already have manually installed. If the adapter is not available, a SystemException will be caught and the user will be instructed to install and start the adapter. Once this successfully completes, we then have a NetworkAdapter array containing information on all available network adapters. With this, we use a simple foreach loop to iterate through the array and add the AdapterName property to the combo box control.
Once we’ve opened an adapter, we can now place it in promiscuous mode and begin to capture traffic:
try
{
maxPackets = Convert.ToInt32(tbxPackets.Text);
capturedPackets = new byte[maxPackets][];
driver.BindAdapter(driver.Adapters[cbxAdapters.SelectedIndex]);
ThreadStart packets = new ThreadStart(capturePacket);
captureThread = new Thread(packets);
captureThread.Start();
}
catch (IndexOutOfRangeException ex)
{
MessageBox.Show(ex.Message +
"
You must select a valid network adapter.",
"Error", MessageBoxButtons.OK, MessageBoxIcon.Error);
}We begin by creating a two-dimensional array (capturedPackets), containing an array of captured packets that in turn contain an array of the bytes within that packet. We then call the BindAdapter() function to bind the selected network adapter to the previously instantiated NdisProtocolDriverInterface (driver). At this point we then call capturePacket in a separate thread. It is important to launch a separate thread for this so that the GUI doesn’t lock up while packets are being captured.
private void capturePacket()
{
while (packetCount < maxPackets)
{
byte[] packet = driver.RecievePacket();
capturedPackets[packetCount] = packet;
packetCount++;
}
}To obtain the byte array for a captured packet, we simply call the ReceivePacket() function. From there, we need only to add them to the capturedPackets array.
Parsing data is a two-step process as we display captured packets in two separate ways. In keeping with the layout used by Wireshark, when a user selects a captured packet, a summary of the packet contents is displayed in a TreeView control, and all raw bytes are displayed in a RichTextBox control at the same time. This way, the user has a clean and easy-to-understand overview but still has control over individual bytes for fuzzing. We’ve attempted to tie the two windows together by highlighting the associated raw bytes in red text when a line item from the TreeView is selected. The full layout of ProtoFuzz with a captured packet is shown in Figure 16.2.
The summary view of a captured packet is shown in the middle TreeView pane. The code to create the TreeView is contained within the packetTvwDecode() function, which has separate code blocks for parsing each of the following headers: Ethernet, TCP, UDP, IP, ARP, and ICMP. For simplicity, the following code segment illustrates parsing only the Ethernet headers:
Ethernet802_3 ethernet = new Ethernet802_3(capPacket); strSourceMacAddress = ethernet.SourceMACAddress.ToString(); strDestMacAddress = ethernet.DestinationMACAddress.ToString(); strEthernet = "Ethernet II, Src: " + strSourceMacAddress + ", Dst: " + strDestMacAddress; strSrcMac = "Source: " + strSourceMacAddress; strDstMac = "Destination: " + strDestMacAddress; strEthernetType = "Type: " + ethernet.NetworkProtocol.ToString(); strData = "Data: " + ethernet.Data.ToString(); TreeNode nodeEthernet = tvwDecode.Nodes.Add(strEthernet); TreeNode nodeEthernetDstMac = nodeEthernet.Nodes.Add(strDstMac); TreeNode nodeEthernetSrcMac = nodeEthernet.Nodes.Add(strSrcMac); TreeNode nodeType = nodeEthernet.Nodes.Add(strEthernetType); TreeNode nodeData = nodeEthernet.Nodes.Add(strData);
As can be seen, the Ethernet802_3 class is instantiated with the byte array from capPacket provided to the constructor and each of the nodes displayed in the TreeView is simply a property of the class. The following code segment is a basic loop that displays the raw packet bytes in a grid pattern. The loop prints 16 bytes per row.
static string PrintData(byte [] packet)
{
string sData = null;
int nPosition = 0, nColumns = 16;
for (int i = 0; i < packet.Length; i++)
{
if (nPosition >= nColumns)
{
nPosition = 1;
sData += "
";
}
else
nPosition++;
byte nByte = (byte) packet.GetValue(i);
if (nByte < 16)
sData += "0";
sData += nByte.ToString("X", oCulture.NumberFormat) + " ";
}
sData += "
";
return (sData);
}Fuzz variables are represented by bytes enclosed in either square brackets ([]) for brute force fuzzing or angle brackets (<>) for string-based fuzzing. When sending the packet, the code simply reads the raw packets and looks for enclosing brackets. When these fuzz variables are encountered, the original data is replaced with fuzz data before the packet is sent.
One final concern is encoding and decoding hexadecimal representations of bytes that are used to display the contents of captured data packets. The .NET Framework provides the ToString(“X”) function for converting a byte array into a hexadecimal string, but it does not provide similar functionality for converting a string into a byte array.[12] For this reason, the HexEncoding class was added, much of which was borrowed from “Converting Hexadecimal String to/from Byte Array in C#” at www.codeproject.com.
Now that we’ve built a network fuzzer, it’s time to ensure that it works. ProtoFuzz is a single-shot tool that takes a packet and mutates it repeatedly before sending it to the target. It is not capable of sending a series of initial packets designed to place the target, for example, into a vulnerable state before sending the packet that causes the crash. Consider, for example, a buffer overflow in an SMTP server that occurs in the RCPT TO command as shown here:
220 smtp.example.com ESMTP HELO mail.heaven.org 250 smtp.example.com Hello smtp.example.com MAIL FROM:[email protected] 250 2.1.0 [email protected]... Sender ok RCPT TO:[Ax1000]
In this example, we would need to send a number of the requests to the SMTP server. We would need to establish the initial TCP connection and then send one request each for the HELO, MAIL FROM, and RCPT TO commands as indicated in bold text. The initial requests are necessary to place the server in state where it is ready to receive the RCPT TO command and the long string that will ultimately lead to the overflow. A vulnerability such as this is better suited to a tool such as SPIKE, which allows for scripts to be created that define packets structure and allow for multiple requests to be sent.
ProtoFuzz is better suited to a situation where you simply want to capture a packet in transit, select a particular portion of data, and begin fuzzing immediately. Perhaps you are dealing with a proprietary protocol and don’t have adequate information to generate a script detailing the structure of the protocol. Alternately, you might simply want to do a quick test without taking the time to describe the protocol to the fuzzer.
A stack overflow vulnerability in Hewlett-Packard’s Mercury LoadRunner was disclosed by TippingPoint’s Zero Day Initiative (ZDI), which suits our needs.[13] The overflow occurs in an agent that binds to TCP port 54345 and listens for incoming connections. The agent does not require any form of authentication before accepting packets and we therefore have the single-shot vulnerability that we’re looking for. Furthermore, the protocol used by the agent is proprietary and inadequate details are provided in the security advisory to allow us to build a proof of concept exploit from scratch. All that the advisory tells us is that the overflow is triggered by an overly long value in the server_ip_name field. We’ll therefore use ProtoFuzz to capture legitimate traffic, identify the server_ip_name field, and mutate the packet accordingly.
Once we have Mercury LoadRunner installed and configured appropriately, we can begin searching for a transaction that might contain the vulnerability. When sniffing traffic, we identify the following packet, which contains a combination of binary and ASCII readable text and clearly contains the server_ip_name field that we’re looking for.
0070 2b 5b b6 00 00 05 b2 00 00 00 07 00 00 00 12 6d +[...... .......m 0080 65 72 63 75 72 79 32 3b 31 33 30 34 3b 31 33 30 ercury2; 1304;130 0090 30 00 00 00 00 05 88 28 2d 73 65 72 76 65 72 5f 0......( -server_ 00a0 69 70 5f 6e 61 6d 65 3d ip_name=
With the packet captured, we next highlight the value contained in the server_ip_name field, right-click, and select Fuzz → Strings. This will enclose the selected bytes in angle brackets (<>). When ProtoFuzz parses the captured packet, it will replace the identified bytes with each value supplied in the Strings.txt file. Therefore, to trigger the overflow, we’ll need to experiment with adding successively larger strings to the file. Separate fuzz packets will be sent for each line in the Strings.txt file.
While fuzz data is being sent to our target, it is important that we monitor for exceptions. Magentproc.exe is the application that binds to TCP port 54345, so we’ll attach a debugger to that process and begin fuzzing. Once the crash is triggered, the output from OllyDbg can be seen in the following code segment:
Registers EAX 00000000 ECX 41414141 EDX 00C20658 EBX 00E263BC ESP 00DCE7F0 EBP 41414141 ESI 00E2549C EDI 00661221 two_way_.00661221 EIP 41414141 Stack 00DCE7F0 00000000 00DCE7F4 41414141 00DCE7F8 41414141 00DCE7FC 41414141 00DCE800 41414141 00DCE804 41414141 00DCE808 41414141 00DCE80C 41414141 00DCE810 41414141 00DCE814 41414141
Similar to the NetMail case study from the last chapter, this is a clear example of a remotely exploitable stack overflow. The fact that the service requires no authentication certainly increases the risk posed by this vulnerability in a popular quality assurance testing tool.
At present, ProtoFuzz is not capable of handling data blocks in which a series of bytes are preceded by the size of the data. In this situation, fuzzing the data bytes requires a parallel update to the size of the data block for the packet to remain valid. This capability would greatly extend the functionality of ProtoFuzz and would be fairly simple to implement.
ProtoFuzz also does not presently provide probing functionality to determine if during fuzzing the target host remains available. As mentioned earlier in the chapter, probe packets could be sent following a fuzz packet to determine the health of the target application. Fuzzing could be halted if the target is unresponsive as further test cases would be falling on deaf ears. This feature would also assist the end user when trying to correlate the fuzz packet(s) responsible for causing anomalous behavior in the target. ProtoFuzz can also benefit from an extension allowing it to handle complex request–response pairs. Rather than simply being able to send fuzz packets, ProtoFuzz could put the target in a particular state prior to fuzzing by first sending known good packets and waiting for the appropriate responses and even parsing and interpreting their contents.
Fault detection could be further improved by designing a remote agent that resides on the target machine to monitor the state of the target application. This agent could then communicate with ProtoFuzz and halt fuzzing when a fault is detected. This can assist in directly identifying which packet caused the fault.
ProtoFuzz has a long development laundry list before it can seize the label of being a robust fuzzer. However, it serves its purpose in demonstrating a basic framework for network protocol fuzzing that can easily be extended for specific targets. A key factor in building this network fuzzer was finding a library that can handle capturing, parsing, and transmission of raw packets. Avoid libraries that do not allow raw packets to be assembled unless you are creating a fuzzer for specific network protocols that do not require accessing all packet headers. For our purposes, the Metro library provided a strong base for ProtoFuzz and the .NET Framework allowed us to build it with an intuitive GUI front end. We encourage you to build on ProtoFuzz and take it in different directions.