SEPTEMBER 17, 2009

How To Create Custom Strikes in Testing: Finding, Validating and Understanding Vulnerabilities

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

According to the National Institute of Standards and Technology’s National Vulnerability Database, there are currently more than 38,000 known security vulnerabilities. Not only is this number growing, but there are thousands of additional unknown vulnerabilities being discovered and written each day. Although BreakingPoint leads the testing industry in both security and application coverage, providing 4,200+ security strikes and 80+ application protocols, we also recognize the need to create customized vulnerability exploits. Last month we introduced the Custom Strike Toolkit to provide the ability for our users to create and generate any strike they want during testing (we provide a similar Custom Application Toolkit).

In order to detail how the Custom Strike Toolkit works we put together a “How-To” guide that not only describes the step-by-step process necessary to utilize the BreakingPoint Custom Strike Toolkit, but uses a real-world example of a zero-day exploit for the Internet Information Services (IIS) FTP service.

Today I look at part one of our "How To Create a Custom Strike" guide, examining how to find, validate and understand a vulnerability. Soon we will look at exploits versus vulnerabilities and finally finish it off with a detailed look at how to build and generate your own custom strike.

Finding and Validating the Vulnerability

For the purposes of the how-to guide, we will be using an FTP denial of service vulnerability, CVE-2009-2521, published by Nikolaos Rangos in September 2009. Utilizing a specially crafted ‘ls’ command, an FTP client may cause the IIS service to crash.

The first step in the process is to validate that the vulnerability exists, and is exploitable. In this case, IIS 5.0 was installed on a standard PC platform running Windows XP. The screenshot below illustrates the Microsoft IIS configuration utility.

Figure 1: Microsoft Configuration Utility

Once the FTP service has been installed and configured, the installation must be validated. The following screenshot shows the initial login screen illustrating that the FTP service is up and running.

Figure 2: Connected to Local FTP Service

As noted in the vulnerability publication, the only thing required to exploit this vulnerability is a directory that may be read by a user. To illustrate the severity of this vulnerability, an “anonymous” FTP user will read the “pub” folder in the root directory.

Figure 3: Anonymous User Successfully Logged In to IIS FTP Service

The next step in the exploit process is to issue the appropriate FTP command to trigger the vulnerability.

Figure 4: Specially Crafted ‘ls’ Command

Once this command has been issued, the damage has commenced. The following screenshot illustrates the output from the FTP client indicating that the server aborted the connection.

Figure 5: Many Directory Listings Followed By Server-side Close

In order to fully verify that the FTP service has been exploited, a quick look at the IIS management console shows that the service has stopped.

Figure 6: IIS FTP Service Crashed Due to Exploit

Understanding the Vulnerability

Now that we have successfully validated that the vulnerability does in fact exist, we now have to understand what the network traffic looks like that would actually exploit it. The following Wireshark stream flow shows the actual ASCII characters transmitted over the wire.

Figure 7: ASCII Output from Network Capture

Upon completion of the TCP handshake, the IIS FTP server responds with a “220 Microsoft FTP Service” message. The client must now authenticate, in this case, as an anonymous user with the “USER anonymous” command. The server responds with a “331” code allowing anonymous access to the FTP site. The “PORT” command then follows with the appropriate successful response. The key packet in the transaction happens when the “NLST –R p*/../” command is issued. A “150” response follows and the data channel starts streaming the directory listings recursively until the service dies. Once this happens, the server terminates the connection with a TCP Reset.

Figure 8: All Relevant FTP Control Channel Packets

Figure 9: All Relevant FTP Data Channel Packets