Bug #191: False Negative when matching on negated uricontent. - Suricata - Open Information Security Foundation

Actions

Copy link

Bug #191

closed

False Negative when matching on negated uricontent.

Added by Will Metcalf over 14 years ago. Updated over 14 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Pablo Rincon

Target version:

1.0.1

Affected Versions:

Effort:

Difficulty:

Label:

Description

The attached signature should fire when processing the attached pcap. It is a bad rule, but it should fire none the less ;-).

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"ET USER_AGENTS Suspicious Mozilla User-Agent - Likely Fake (Mozilla/5.0)"; flow:to_server,established; content:"|0d 0a|User-Agent\: Mozilla/5.0|0d 0a|"; nocase; uricontent:!"|0d 0a|Host\: download.releasenotes.nokia.com"; content:!"Mozilla/5.0|0d 0a|Connection\: Close|0d 0a 0d 0a|"; classtype:trojan-activity; reference:url,doc.emergingthreats.net/2009295; reference:url,www.emergingthreats.net/cgi-bin/cvsweb.cgi/sigs/USER_AGENTS/USER_Agents_Suspicious; sid:2009295; rev:6;)

modifying uricontent:!"|0d 0a|Host\: download.releasenotes.nokia.com"; to be content:!"|0d 0a|Host\: download.releasenotes.nokia.com"; causes the sig to fire but it should fire with uricontent as well.

src/suricata c suricata.yaml -s 2009295.rule -r 2009295.pcap -l ./
...
[686] 28/6/2010 - 13:56:01 - (alert-fastlog.c:255) <Info> (AlertFastLogExitPrintStats) -- (Outputs) Alerts 0
[686] 28/6/2010 -- 13:56:01 - (alert-unified2-alert.c:581) <Info> (Unified2AlertThreadDeinit) -- Alert unified2 module wrote 0 alerts
[686] 28/6/2010 -- 13:56:01 - (log-httplog.c:396) <Info> (LogHttpLogExitPrintStats) -- (Outputs) HTTP requests 1

Files

Download all files

2009295.rule (1.05 KB) 2009295.rule	fn negated uricontent rule	Will Metcalf, 06/28/2010 12:51 PM
2009295.pcap (974 Bytes) 2009295.pcap	fn negated uricontent pcap	Will Metcalf, 06/28/2010 12:51 PM
0001-Don-t-avoid-inspecting-uricontents-if-we-get-no-matc.patch (3 KB) 0001-Don-t-avoid-inspecting-uricontents-if-we-get-no-matc.patch	The problem was that we were skipping the checks of uricontent/urilen and pcre on uris if we got no match on uricontents, but also without checking if they were negated. Now what we do is that we call the inspection with or without mpm matches, but if it	Pablo Rincon, 07/02/2010 11:22 AM

Actions

Copy link

Updated by Victor Julien over 14 years ago

Due date changed from 06/29/2010 to 07/06/2010
Assignee changed from OISF Dev to Pablo Rincon
Target version changed from 1.0.0 to 1.0.1
Estimated time changed from 2.50 h to 4.00 h

Actions

Copy link

Updated by Pablo Rincon over 14 years ago

File 0001-Don-t-avoid-inspecting-uricontents-if-we-get-no-matc.patch 0001-Don-t-avoid-inspecting-uricontents-if-we-get-no-matc.patch added
Status changed from New to Resolved

The problem was that we were skipping the checks of uricontent/urilen and pcre on uris if we got no match on uricontents, but also without checking if they were negated. Now what we do is that we call the inspection with or without mpm matches, but if it didn't match on mpm, it avoid searching with boyer moore, and check if it's negated (as usual). This way, we continue the inspection of urilen and pcre uricontents, and avoid lowering performance with boyer moore if we got no mpm match.

Actions

Copy link