Project

General

Profile

Actions
Copy link

Bug #5176

open

False positive when negated content is far ahead of matching content.

Added by Brandon Murphy almost 3 years ago. Updated almost 3 years ago.

Status:
New
Priority:
Normal
Assignee:
OISF Dev
Target version:
TBD
Affected Versions:
5.0.8, 6.0.4, git master
Effort:
Difficulty:
Label:

Description

In looking at alerts for a signature designed to detect powershell command line options returned by http servers, but not part of an HTML page, many false positives were discovered. I have been able to able to reliability reproduce the False Positive alert with the attached pcap gathered from any.run.

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"test with http buffers - SHOULD NOT ALERT"; flow:established,from_server; http.response_body; content:!"<html"; content:"-ExecutionPolicy"; nocase; sid:1;)

Files

f38cbd74-d97e-4b1a-94d9-527eb4a7ad3f.pcap (720 KB) f38cbd74-d97e-4b1a-94d9-527eb4a7ad3f.pcap Brandon Murphy, 03/06/2022 03:07 AM
Actions
Copy link
 #1

Updated by Jeff Lucovsky almost 3 years ago

I've confirmed that alerts are generated on
- master-5.0.x
- master-6.0.x
- master

Actions
Copy link
 #2

Updated by Victor Julien almost 3 years ago

Initial analysis:

content:"-ExecutionPolicy"; is the fast_pattern.
Engine buffers up initial response body to ~40k, then inspects rest in smaller 16k chunks.
Chunk at offset ~83k hits contains the fast pattern.
Inspection then checks for the content:!"<html"; condition, but since it only has bytes ~83k to ~99k, it won't find it because its before the window.

FP can be avoided by anchoring the content:!<html"; startswith;. But this doesn't actually check the pattern, it just fails to match as we don't have data at offset 0.

Actions
Copy link

Also available in: Atom PDF