LinuxDevCenter.com
oreilly.comSafari Books Online.Conferences.

advertisement


Linux Security Cookbook

Saving Our Bacon: Snort Security Holes and Strategies for Safe Network Monitoring

by Robert G. Byrnes, coauthor of Linux Security Cookbook
06/02/2003

Introduction

In April, a CERT advisory announced the discovery of two separate buffer-overflow vulnerabilities in Snort, a popular security-monitoring tool used for detecting suspicious network activities. This development was disturbing and ironic: system administrators install and run programs like Snort to improve security, and don't often consider the possibility that the tools themselves might be attacked and exploited to create entirely new security holes. It's therefore important to understand precisely what happened here, especially since the same mechanisms used against Snort could threaten other security tools.

In this article, I will review the attacks that have been launched against Snort in the past, as well as the recent (and more serious) buffer overflows. In each case, I'll discuss the ways Snort developers have responded to the attacks, and the strategies system administrators can take to minimize the risks. Furthermore, I'll show that Snort's vulnerabilities extend to other security-monitoring tools, implying that we need to be careful when we use them, as well. Finally, I'll summarize techniques to do just that: secure monitoring.

Evasion and Stealth Techniques

Snort is a network intrusion detection system, or NIDS. It sniffs packets from the network, and analyzes them using a database of pattern-matching rules. These rules identify a wide range of suspicious or hostile activities, such as misuse of network protocols, attempted buffer overflows, denial-of-service attacks, port scans, and so on. When such activities are detected, Snort can be configured to log the network trace data for more detailed examination, and to send alerts so that system administrators will notice.

Related Reading

Linux Security Cookbook
By Daniel J. Barrett, Richard E. Silverman, Robert G. Byrnes

Since the main purpose of Snort is detection, a primary goal of attackers is evasion. If attacks can be structured so that they are overlooked by Snort, then system administrators will be left with a false sense of security -- arguably a worse situation than if Snort had not been used at all.

The evolution of Snort has been driven largely by the endless arms race between the attackers and the defenders. The open source distribution of Snort allows the bad guys to study the detection mechanisms and devise ways to bypass them. The Snort developers, aided by reports from the user community and examination of often widely available attack tools, then respond by enhancing the algorithms, and the cycle continues. The history of innovation on both sides has been fascinating and instructive.

When new malicious network activities are discovered, pattern-matching rules are added to Snort's database. These rules are stateless, meaning that only one packet is examined at a time. Snort also supports a variety of preprocessors that track multiple packets, and hence are stateful. The modular design of Snort allows preprocessors to be easily added or modified, and more complicated evasion attempts have been countered by improvements in the preprocessors. The increasing focus on preprocessors for Snort is reminiscent of the expansion of Linux firewall technology from stateless ipchains to stateful iptables.

Attackers frequently exploit IP fragmentation for evasion. For example, the nmap port-scanning tool provides an option to use tiny, fragmented packets that break headers for higher-level protocols into pieces during transmission. Snort's frag2 preprocessor reassembles the packets, so the headers (and the payload) can be scanned all at once. Similarly, many aspects of TCP can be abused by attackers, for example, by retransmitting packets with slight variations, in the hope that they will be incorrectly handled by Snort. The stream4 preprocessor catches these protocol anomalies and ensures that Snort will interpret the packets as a destination host would. In addition, stream4 reorders packets and reassembles entire TCP sessions, which allows other preprocessors to easily access data as it would have been reliably delivered by TCP. These operations make stream4 one of the most important preprocessors in Snort's arsenal.

A favorite technique for attackers to defeat simple pattern-matching rules is restructuring network data in many different, but equivalent forms. A variety of Snort preprocessors respond by converting specific protocols to standardized, canonical formats for more reliable matching by other rules and preprocessors. The http_decode preprocessor rewrites the URLs used by HTTP. Similarly, the rpc_decode preprocessor reassembles RPC data that has been split into record fragments in various ways. Attackers have also developed tools like ADMutate to generate polymorphic shell code for use in buffer overflows, and the experimental fnord preprocessor attempts to detect these; this is an area of active research.

Some stealth strategies are based on timing. For example, nmap can do very slow port scans, in the hope that probes separated by long intervals will not be noticed. The portscan preprocessor detects these by performing a statistical analysis of the traffic, and the newer, experimental portscan2 and conversation preprocessors offer potentially improved detection.

There is really only one good defense against these evasion techniques for system administrators: keep your Snort installation up to date. Install new rules frequently: fortunately, this is easy, since the rules database can be downloaded separately from the Snort web site. Upgrade Snort frequently too, in order to obtain the latest preprocessors, and be sure that the desired preprocessors are enabled in the snort.conf configuration file.

Denial-of-Service Attacks

Denial-of-service attacks can launched directly against Snort. These attacks are designed to disrupt the NIDS operation, and are in some sense complementary to evasion tactics, since they are certainly easy to detect. A barrage of traffic will at least contribute to the load on whatever machine is running Snort and will consume system resources, which makes this form of attack potentially more serious. Snort is lightweight and efficient, and can therefore tolerate high traffic rates, but other NIDS programs can be overwhelmed, and some have reportedly even crashed when subjected to these assaults.

Attack tools like stick and snot have been developed to construct random noise packets based on Snort rules. These packets are designed to match the patterns in the rules, and hence produce a flood of bogus alerts. The goal is to conceal some other genuine attack within an avalanche of false alarms. A cunning plan.

Snort retaliates by using the stream4 preprocessor: the random noise packets can be readily identified (and ignored) because they do not belong to a valid TCP session. This is a consequence of the stateless nature of the Snort rules used by the noise generators.

System administrators can best defend against denial-of-service attacks by running Snort on a separate, dedicated monitoring machine. Any extra system resources that are consumed by Snort during a denial-of-service attack will therefore not affect network services running on other machines.

If you are being bothered by stick-style attacks, use Snort's -z est option to limit alerts to only known, established TCP connections. The stream4 preprocessor must be enabled for this mode to work.

The Latest Threats: Buffer Overflows

The worst kind of attack to fear is one that allows evildoers to hijack the operation of Snort itself. Unfortunately, two specific buffer-overflow vulnerabilities have recently been discovered that show this is possible.

The security holes occurred in separate preprocessors:

  • rpc_decode: An attacker could exploit a flaw in Snort's computation of the size of packets, and consequently overflow a buffer, causing stack corruption. This problem was found in March 2003, and fixed by Snort 1.9.1.

  • stream4: By using carefully crafted TCP sequence numbers, an attacker could cause the overflow of an integer used to check for buffer overruns, leading to heap corruption. This was exposed in April 2003, and repaired in the latest Snort 2.0 release.

Both of these preprocessors are enabled by default, and as we have seen, stream4 is critical for the stateful operation of other preprocessors, as well as for protection against denial-of-service attacks. You really wouldn't want to run Snort with stream4 disabled.

The impact of these security holes is severe: either can be used to cause Snort to crash, or (even worse) to insert malicious code where it will be executed by Snort.

Pages: 1, 2

Next Pagearrow




Linux Online Certification

Linux/Unix System Administration Certificate Series
Linux/Unix System Administration Certificate Series — This course series targets both beginning and intermediate Linux/Unix users who want to acquire advanced system administration skills, and to back those skills up with a Certificate from the University of Illinois Office of Continuing Education.

Enroll today!


Linux Resources
  • Linux Online
  • The Linux FAQ
  • linux.java.net
  • Linux Kernel Archives
  • Kernel Traffic
  • DistroWatch.com


  • Sponsored by: