* TITLE:
Snort 2.0.2 misbehaviour: some alerts could be missed !!
* DESCRIPTION:
This "security advisory" tries to alert about a misbehaviour found in Snort, version 2.0.2 (build 92), that is, the latest stable version available at the Snort homepage.
As stated in the Snort man page:
"Snort uses a flexible rules language to describe traffic that it should collect or pass,
as well as a detection engine that utilizes a modular plugin architecture."
The problem seems to be in the default detection engine used to process the network traffic against the ruleset. There are some conditions where, if a specific set of rules have been activated through the configuration files, some alerts are not triggered.
The misbehaviour can be reproduced with the default Snort configuration.
* SOLUTION:
As notified by the Snort development team, a new version has been released, 2.0.3, solving this issue. It is recommended to upgrade to the latest Snort version, 2.0.3.
If for some reason you cannot updgrade it now, the Snort misbehaviour can be avoided adding the following line into the Snort configuration file, "snort.conf":
config detection: search-method ac
This directive tells Snort to change its default search algorithm to the "ac" algorithm, using a separate pattern matcher. As stated in the Snort web page, there are two algorithms that can substitute the "mwm" default algorithm, "ac" and "lowmem".
*"PROOF OF CONCEPT" (POC)
A very simple proof of concept has been placed here.
While analyzing some network traffic we have found that a UDP packet, containing a DNS version query, could trigger or NOT the associated alert, id = [1:1616:4], available inside the "dns.rules" files.
The problem was observed when analyzing some traffic from the "www.incidents.org/logs/Raw" repository. When the already mentioned DNS version query packet is analyzed by Snort, using the default rule set, its corresponding alert is not triggered neither logged. The default Snort rule set has been debugged to be able to determine the "wrong" rules that discard the packet and make it disappear from the IDS point of view.
After some testing we have found a total of 5 Snort rules (1 RPC, 2 DoS, 1 SCAN and 1 DNS) that, when activated, make Snort to discard the mentioned packet, so the expected alert is never logged.
To help the Snort development team in reproducing this behaviour, we have created a tar file, "snorttest_nobug.tgz", containing the following files:
snorttest/snort.conf.test - simplified snort.conf file used in the tests.
snorttest/snort_invocation.sh - command line containing the snort invocation needed to reproduce the problem.
snorttest/snort_invocation.out - output obtained from the default command invocation.
snorttest/1-rpc.rules - RPC rules affecting the misbehaviour.
snorttest/2-dos.rules - DoS rules affecting the misbehaviour.
snorttest/1packet - libpcap file containing the UDP packet that triggers the alert.
snorttest/1-scan.rules - SCAN rules affecting the misbehaviour.
snorttest/the-alert-dns.rules - alert rule that should be triggered with the packet in "1packet" file.
snorttest/1-dns.rules - DNS rules affecting the misbehaviour.
snorttest/snort_invocation.out.OK - output obtained when the alert is triggered, so the packet is detected.
snorttest/snort_invocation.out.BAD - output obtained when the alert is NOT triggered, so the packet is NOT detected.
snorttest/snort.conf.no_bug - simplified snort.conf file including the FIX proposed by the Snort development team.
snorttest/snort_invocation_nobug.sh - command line containing the snort invocation using the fixed configuration.
snorttest/snort_invocation_nobug.out - output obtained from the fixed command invocation.
The default configuration included in the tar file shows the wrong behaviour, that is, how Snort doesn't reflect the alert and discards the "evil" packet.
To be able to avoid this incorrect behaviour you just need to remove ANY of the 5 rules involved in the config file. If ANY of the "include" lines available in the "snort.conf.test" file is commented out, then the alert is logged and Snort works as expected:
# SCAN
include ./1-scan.rules
# RPC
include ./1-rpc.rules
# DOS
include ./2-dos.rules
# DNS
include ./1-dns.rules
The last "include" line inside the configuration file is used to trigger the alert:
# The rule that should be triggered
include ./the-alert-dns.rules
No preprocessors were activated, in order to simplify the test as much as possible.
A new configuration file "snort.conf.no_bug" has been included in the tar file to reproduce the correct behaviour.
* PLATFORMS:
The misbehaviour has been tested under Red Hat Linux 9.0, 2.4.20-20.9 kernel version, on the Intel (x86) platform.
* AGREEMENTS:
Chris Green (cmg@sourcefire.com)
* AUTHOR(s):
Raul Siles (raul@raulsiles.com)
David Pérez
|
