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.
[IMAGE]
Practical Intrusion Analysis: Prevention and Detection for the Twenty-First Century
Chapter 4: Lifecycle of a vulnerability
Table of contents:
[IMAGE] A network security vulnerability is born
[IMAGE] FlashGet vulnerability
[IMAGE] Collecting a sample packet capture
Download Chapter 4 of "Practical Intrusion Analysis" as a .pdf
[IMAGE]
A VULNERABILITY IS BORN
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 typica...
To continue reading for free, register below or login
To read more you must become a member of SearchSecurity.com
lly
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.
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.
FLASHGET VULNERABILITY
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 flashget-overflow.pl
usage: flashget-overflow.pl [1,2,3]
1 -> Windows XP SP1
2 -> Windows XP SP2
3 -> Windows XP SP3
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.
COLLECTING A SAMPLE PACKET CAPTURE
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).
