DECEMBER 19, 2008

Fuzzing the Internet Printing Protocol (IPP)

The Internet Printing Protocol (IPP) was designed as a next-generation printing and print job management protocol. Unlike the older line printer protocol (LP), IPP supports a number of advanced features, including authentication and encryption. IPP is loosely based around HTTP 1.1 and takes advantage of many of HTTP's features and conventions. The amount of code required to implement IPP is helped by its similarity to normal HTTP traffic. Microsoft Windows, Mac OS X, and most Linux distributions all support client and server modes of IPP. On the Windows side, the IPP server is integrated into the Microsoft IIS web server (/printers/). On Mac OS X and most Unix flavors, IPP is implemented via the Common Unix Printing System (CUPS), an open source implementation that is current maintained by Apple. Most network printers also support IPP and enable this protocol by default, however they tend to use custom implementations that have less features (and as we will demonstrate, stability) than the IPP implementations available for consumer operating systems.

In this article, we will be launching the BreakingPoint IPP fuzzer against a HP LaserJet 4250 network printer as well as an Ubuntu Linux system running CUPS. To get started, we access the web interface of a BreakingPoint BPS 1K appliance running the latest StrikePack. This system has interface 3 connected to the network that our targets are on and interfaces 1, 2, and 4 unplugged. After authenticating, the first thing we need to do is create a new Attack Series containing the list of Strikes we want to run. To create the Attack Series, we need to access the Attack Manager from the Managers drop down menu at the top of the interface. Once the Attack Manager has loaded, click on the Create Attack Series button. When the system prompts for a name, enter “IPP Fuzzer”. After the Series has been created, click the Add Strikes button in the right-hand pane. This will load the Strike Browser interface. From this interface, select the “ipp” keyword from the Keywords list and click the Strikes radio button. The results should look like Figure 1.

Figure 1: Searching for IPP strikes by keyword

Click the Search button to look for all individual Strikes which have the “ipp” keyword. The resulting list will contain a number of Strikes in the fuzzer category as well as an exploit. Since we are interested in fuzzing, we will select all of the fuzzer strikes and use the right-pointing arrow to add them to this test. The result should look like Figure 2.

Figure 2: Adding the IPP fuzzer Strikes to the Attack Group

Click the Add Strikes button to save this Attack Group and return to the main Attack Manager screen. The “IPP Fuzzer” Series should be selected and show the Strikes that were added to the list on the right-hand pane. This screen should look like Figure 3.

Figure 3: The configured Attack Series

The next thing we need to do is configure the IP address of the fuzzer and the target system. From the Control Center menu, select Network Neighborhood. Click the Create Neighborhood button and name the new setting “IPP Fuzzer Endpoint”. Once named, the right-hand pane will show a list of tabs for each interface and an additional interface labeled “External”. To configure the IP address used by the Fuzzer, select the tab for Interface 3. The network we are on is 10.10.10.0/23 and we want to confine the fuzzer to a single IP address, 10.10.11.165. Uncheck the “Use Address Range” box to ensure only a single IP address is used. Once configured, click the Apply Changes button. The result should look like Figure 4.

Figure 4: Configuring the fuzzer source IP address

Now that the source address has been configured, select the tab labeled “External”. This screen is used to configure the target IP address. First we need to select the preset range and use the delete button to remove it. Next we enter the target address into the Minimum Address field, uncheck the “Use Address Range” box, and click Add Range. The address we chose (10.10.10.251) points to the HP LaserJet printer that we want to test. Finally, click the Apply Changes button to save these settings. The result should look like Figure 5.

Figure 5: Configuring the target IP address

At this point, our Attack Series and Network Neighborhood is configured. The next step is to create a new test using these settings. From the Test menu at the top of the screen, select the New Test option. On the left hand side of the new test screen is a link for selecting the DUT and Network Neighborhood. Click this link, select the newly created “IPP Fuzzer Endpoint” option from the list of neighborhoods, and click the Accept button.

Once the interface has returned to the New Test screen, select the link labeled “Add a Test Component”. This will display a screen of 7 test components. Choose the component labeled Security from the bottom left of this screen. Once the Security component has been added, select the Interfaces tab, uncheck the presets, and use the checkboxes to select Interface 3 as the Client and the External interface as the Server. Click the Apply Changes button. The result should look like Figure 6.

Figure 6: Configuring the Security component interfaces

Select the Parameters tab of the Security component. Click the Attack Series option in the list of parameters and choose the IPP Fuzzer option that was created in the previous steps. Click the Apply Changes button. The result should look like Figure 7.

Figure 7: Selecting the IPP Fuzzer Attack Series

Finally, click the Save and Run button from the left side of the screen. The interface will prompt for a name for the test and start running the IPP Fuzzer Strikes against the target device. Once the test starts running, we will see a progress screen like the one shown in Figure 8.

Figure 8: Running the IPP Fuzzer Attack Series

In the graph above, we see a short spike of packets, followed by a long series of almost no traffic. Once the test completes, we can look at the report and determine what happened. Figure 9 shows a sample report for this test.

Figure 9: IPP Fuzzer vs HP LaserJet

In the Strike Detail section of the report, we see that the “IPP Print Operation Long Job Name” Strike reported a maximum job size of 64 bytes (of a maximum tested size of 65528). All of the following Strikes reported a maximum length of zero while the last Strike indicates that zero operations were accepted. If we try to telnet to the IPP port of the target device, we can see that the service is down and is no longer accepting requests. It appears that an IPP Job Name that is 65 bytes long will crash the HP LaserJet IPP service. The bandwidth graph showed a quick spike as the first 64 requests were sent to the IPP service, but after the 65^th test, the IPP service stopped responding and the subsequent Strikes quickly gave up after not being able to connect.

The second target we want to test is a Ubuntu Linux system running CUPS, which happens to expose an IPP service as well. To change the target IP address, we access the Network Neighborhood we created, click on the External tab, change the IP address, and click Apply Changes. The next time we run this test, the fuzzer will target the Ubuntu system instead. Figure 10 shows a sample run of the exact same test against a CUPS IPP server.

Figure 10: IPP Fuzzer vs CUPS

In this test, we see that the service refused requests with field lengths over a threshold (~14100), but did not crash. At the end of the test, the IPP service was still online and functional, and the logs of the CUPS server did not show any fatal errors. Since the IPP service did not crash during this test, all six Strikes were able to run to completion, extending the test time to about one hour.

The BreakingPoint architecture makes it easy to integrate fuzzing with performance, application, and live exploit testing. This combination provides a way to flush out bugs that only trigger when the device is under a heavy load, something that is difficult to do with other products on the market. While IPP is a simple example, the same technique applies to all of our fuzzers. We design them to test live services as well as content-inspection devices that route traffic. The reports make it possible to determine exactly what requests can break a service and allow our users to reverse-engineer a content-filter's traffic normalization rules.