Problem solve Get help with specific problems with your technologies, process and projects.

Lifecycle of a network security vulnerability

In a chapter excerpt from Practical Intrusion Analysis: Prevention and Detection for the Twenty-First Century,author Ryan Trost reveals the full process of providing intrusion detection system coverage for a security vulnerability.

The chapter below walks you through the process of providing network intrusion detection system (IDS) coverage...

for a security vulnerability from start to finish, using practical examples and highlighting popular and useful open source tools.

After the process is introduced, author Ryan Trost focuses on how to write Snort signatures for more complex vulnerabilities by using features such as flowbits, Perl-Compatible Regular Expressions (PCRE), and the relatively new shared object rules, which allow the Snort intrusion detection system to leverage all the power of the C programming language. Throughout the rest of the book, Trost offers more true-life lessons learned from his network penetration testing work. See sidebar below to listen to an interview with the author.

Practical Intrusion Analysis: Prevention and Detection for the Twenty-First Century
Chapter 4: Lifecycle of a vulnerability

Table of contents:
A network security vulnerability is born
FlashGet vulnerability
Collecting a sample packet capture

Download Chapter 4 of "Practical Intrusion Analysis" as a .pdf


The vast majority of new software vulnerabilities are announced on public forums, such as the SecurityFocus Bugtraq mailing list; official government sites, such as US-CERT or NIST's CVE database; or directly on vendor Web sites or mailing lists, such as Microsoft's monthly security bulletin releases. These sites tend to cross-reference each other and typically sync vulnerability references and information within a matter of a day or two. Thus, for all but the newest vulnerability announcements, just about any major information source suffices.

Interview with the author

In a "Hot Type" podcast with Ryan Trost, the author reviews the latest advancements in intrusion detection.

In many cases, the details associated with a vulnerability release are vague; any IDS analyst who's been in the field for more than a few months is familiar with statements like, "Sending malformed packets cause the application to crash, which creates a denial of service condition." This lack of detail is usually the result of a conscious decision by the vendor to make one last stab at security through obscurity, essentially hoping that, by not releasing the exact mechanism of exploitation, it can save its users from having their software hijacked because no one takes the time to figure out how to use the newly announced security hole.

Although most users of a piece of affected software generally find this practice laudable, refusing to release technical details about a vulnerability usually only serves to annoy IDS analysts and challenge malicious adversaries. For the IDS analyst, the problem is obvious:Without details of how a successful exploit can be accomplished, it's impossible to determine what that exploit looks like coming across the network; thus, it is impossible to create an IDS signature to detect such behavior. For others, a newly announced vulnerability can be anything from a potential profit center (for example, for criminal crackers using it to further their nefarious goals) to a fascinating puzzle (see the excellent XKCD comic "Nerd Sniping").

Given these pressures, a large number of vulnerabilities that are initially disclosed without details are soon followed by proof-of-concept code or an actual working exploit. (The difference between the two being that the latter actually injects shellcode into the vulnerable piece of software, which causes it to spawn a shell, open a TCP connection, or do something else that the cracker finds useful; the former simply crashes the application.) Generally speaking, the wider the installed base of the software, the more highprofile the vulnerability and the less complex the software, the more likely it is that a working exploit emerges soon after the initial announcement. For example, a buffer overflow in Microsoft Exchange almost certainly has a working exploit released within a day or less of the initial announcement; conversely, a format string bug in an obscure piece of proprietary software might never have one developed.

Luckily for IDS analysts, especially those without ties into the network security underground, several good publicly accessible Web sites publish working exploits, sometimes even before a vulnerability announcement is made. Sites such as Milw0rm, Packet Storm, and Metasploit serve as repositories for thousands of publicly available exploits, along with detailed information on how to break software, commonly used network security tools, and so on, all of which are extremely valuable to IDS analysts.

Let's start out with a relatively simple buffer overflow exploit written in Perl, which is a language that about any Linux or BSD user has installed by default and that can be easily installed on Windows. By selecting something that's easily readable for anyone who knows Perl and that takes no effort to get running, you can focus on the necessary tools to do the analysis and get into the details about the actual analysis later. Note that the console listings are straight copy and pastes from the machines used to actually run this exploit—you see exactly what I saw while I ran it.

The vulnerable software is FlashGet, which is a popular download manager for numerous protocols, such as HTTP, FTP, and BitTorrent. As originally disclosed on August 13, 2008, FlashGet is prone to a buffer overflow when parsing the FTP command PWD, and successful attacks can lead to remote code execution (for example, an attacker can run whatever it wants on the victim machine).

First, download the exploit to a machine that can have clients connect to it on TCP port 21, the standard FTP port, and verify that you can run it properly. (Note that if you simply use a tool like wget to fetch the file, it comes down as HTML that you need to clean up; it's simpler to copy and paste the exploit manually into a file.)

alex@gateway: ~$ sudo perl
usage: [1,2,3]

  • 1 -> Windows XP SP1
  • 2 -> Windows XP SP2
  • 3 -> Windows XP SP3

    Official book page

    Practical Intrusion Analysis: Prevention and Detection for the Twenty-First Century

    Publisher: Addison-Wesley

    This result isn't too surprising. It tells you that you need to choose the operating system (OS) that you want to exploit. This often becomes a choice between different service packs of Windows XP, because each service pack includes different security mechanisms and each has important kernel functions that the shellcode uses for actually executing code in different memory locations. If you have a vulnerable copy of this software, try running the exploit first for the incorrect XP service pack and then the right one—you see that the first attack fails and the second works, popping up calc.exe on the compromised machine.

    Because there isn't actually a vulnerable client on the receiving end of the exploit—as an IDS analyst, it's often more hassle than it's worth to set up the actual vulnerable software when recording an exploit—I arbitrarily choose to do SP2, because that's the most common version of XP. Running the command again with 2 as the argument, no prompt returned. The program simply sat and waited. To verify that it is actually listening properly, I used another window on the machine and ran netstat, which is a standard Linux/BSD command that displays open sockets:

    alex@gateway: ~$ netstat -tna
    Active Internet connections (including servers)

    Proto Recv-Q Send-Q Local Address Foreign Address (state)
    tcp 0 0 *.21 *.* LISTEN
    tcp 0 320 68.55.r.s 71.163.x.y ESTABLISHED
    tcp 0 0 *.22 *.* LISTEN

    The first line of actual data confirms that there is something listening to port 21. Because I am not running an FTP server on this machine, it's clearly the exploit.

    Now that you are ready to test the exploit, let's pause for a moment to ensure that you can actually record the traffic that it sends across the wire; after all, an exploit is useless to an IDS analyst if he can't see what it actually looks like on the network.

    To read more about collecting a sample packet capture, download the rest of Chapter 4: Lifecycle of a Vulnerability (.pdf).

This was last published in September 2009

Dig Deeper on Real-time network monitoring and forensics

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.