How To Create Custom Strikes Part II: Creating the Strike

UDPATE: To download the entire how-to guide, which includes all three parts, simply head over to our how-to guides section.

In Part I of our look at how-to create custom strikes for testing we talked about how to find and validate a vulnerability. Now I want to look at how we go about creating the custom strike and talk about exploit versus vulnerability. In Part III I will provide the step-by-step directions for then generating this custom strike using the BreakingPoint Elite.

Custom Strikes

Now that an appropriate security strike has been identified, we can start to describe the strike through the BreakingPoint Custom Strike Toolkit. The API supports the importing of XML-based description files that describe the flow of information between a client and server. The full XML file used to generate this strike will be included in the Appendix.

The custom strike XML begins with an “application” tag, which is the outer-most XML tag. This tag accepts two parameters: “sport” and “dport” for source port and destination port, respectively. Values of ‘0’ indicate random, and non-zero values are used for fixed ports. Our example looks like this:

Note that the custom strike ends with the closing “application” tag. Everything written for the strike will come between these two tags.

Within the “application” tag, the custom strike API utilizes two additional tagged blocks that represent client and server transactions. Since our example uses FTP, we know that once the TCP connection is established, the server is first to send data.

220 Microsoft FTP Service\r\n

The FTP 220 response with the default Microsoft FTP Service message is sent from the server to the client. This particular XML block corresponds to packet 124 in Figure 8 (described in Part I).

Once the server has issued the greeting, the client must log in. To illustrate the severity of the vulnerability, an anonymous user was used. The server happily accepts anonymous logins.

USER anonymous\r\n

331 Anonymous access allowed, send identity (e-mail name) as password.\r\n

These commands correspond to packets 141 and 142 in Figure 8. Once this process is completed, the password must be sent and accepted to complete the authentication process. Packets 146 and 147 in Figure 8 are represented by the following XML excerpt.

PASS anonymous@localhost\r\n

230 Anonymous user logged in.\r\n

The next several packets in Figure 8 correspond to the “ls –R p*/../” command issued from the FTP client. First a “PORT” command must be issued to open up a connection for the data channel. Packets 223 and 224 in Figure 8 represent this transaction.

PORT $(ip_and_dest)\r\n

200 PORT command successful.\r\n

The glaring difference in this code excerpt is the inclusion of a Ruby code block which handles the FTP formatting of destination IP address and port for the data socket. The Ruby code simply takes a dotted decimal IP address and exchanges the periods with commas, while concatenating a random TCP port with the IP address. This is of the form 10,10,10,20,198,84.

Once these commands have completed, the trigger command is sent.

NLST -R p*/../\r\n

150 Opening ASCII mode data connection for /bin/ls.\r\n

Packets 225 and 226 in Figure 8 illustrate the actual network traffic generated, while packet 244 illustrates the TCP RST packet sent by the server stack when the FTP service crashes.

Exploit vs. Vulnerability

While the XML code listed previously will generate an exploit to the IIS vulnerability exactly as captured from the local recreation, the FTP payload of the network traffic generated by the BreakingPoint Elite will remain static, even though the IP and TCP information will change. This sort of traffic would help to validate an exploit filter but not necessarily a vulnerability filter.

Software exploits are truly singular cases that trigger some sort of bad behavior in an application. Vulnerabilities are the general behavior of applications that allow particular scenarios to trigger bad behavior. The actual transaction sent that crashed the FTP service required there to be a folder named ‘pub’ that was readable by the user that logged into the FTP service. This case is truly an exploit to the IIS FTP service. This was what was actually coded in the XML. In contrast, the exploit is more than just issuing a “ls –R p*/../” command. For example, if we rerun this case with a different scenario, we can still trigger the vulnerability.

Figure 10: IIS Exploited with Different ‘ls’ Command

When testing a network device that would provide protection for this CVE, the tester will want to ensure that the filter in place is a vulnerability filter and not an exploit filter. If the device were using an exploit filter, then “ls –R p*/../” would likely be blocked while “ls –R m*/../” would not be blocked.

In order to test this, we must slightly modify the XML to selectively randomize the trigger string to ensure that the device under test is filtering the vulnerability, in other words, the full set of exploits, and not just a handful of singular cases.

NLST -R

*/../\r\n

The modified XML does not just use a singular exploit pattern but will create many different variations of the traffic necessary to exploit the vulnerability. Figure 11 illustrates this.

Figure 11: Illustration of a Selectively Randomized Exploit