Project

General

Profile

Actions

Bug #7187

open

detect: dcerpc logging and matching issues

Added by Victor Julien about 2 months ago. Updated about 21 hours ago.

Status:
Resolved
Priority:
Normal
Assignee:
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

Description

originally reported here https://forum.suricata.io/t/suricata-protocol-dcerpc-cannot-trigger-alert-when-adding-new-rule/4788

In the DCERPC over TCP pcap, logging and rule matching is disrupted by adding a simple rule:

alert tcp any any -> any any (flow:to_server,established; dce_iface:5d2b62aa-ee0a-4a95-91ae-b064fdb471fc; dce_opnum:1; dce_stub_data; content:"|42 77 4E 6F 64 65 49 50 2E 65 78 65 20|"; content:!"|00|"; within:100; distance:97; sid:1; rev:1; )

Works: alert + 3 dcerpc records.

But when adding a trivial rule:

alert tcp any any -> any any (flow:to_server,established; dce_iface:5d2b62aa-ee0a-4a95-91ae-b064fdb471fc; dce_opnum:1; dce_stub_data; content:"|42 77 4E 6F 64 65 49 50 2E 65 78 65 20|"; content:!"|00|"; within:100; distance:97; sid:1; rev:1; )
alert tcp any any -> any any (dsize:3; sid:2; rev:1; )

The alert for sid:1 disappears and also there is one dcerpc event less.


Files

test.pcap (5.88 KB) test.pcap Victor Julien, 07/31/2024 11:44 AM

Subtasks 1 (1 open0 closed)

Bug #7188: detect: dcerpc logging and matching issues (7.0.x backport)AssignedVictor JulienActions
Actions #1

Updated by OISF Ticketbot about 2 months ago

  • Subtask #7188 added
Actions #2

Updated by OISF Ticketbot about 2 months ago

  • Label deleted (Needs backport to 7.0)
Actions #3

Updated by Victor Julien about 2 months ago

My analysis:

In the single rule case we can aggressively free the transactions, as there is only an sgh in the toserver direction.
This means that when we encounter the 2nd REQUEST, the first 2 transactions have already been processed and freed. So for the 2nd REQUEST we open a new TX and run inspection and logging on it.

When the 2nd rule is added, it adds toclient sgh as well. This means that we will now slightly delay the freeing of the transactions.
As a consequence we still have the TX for the first REQUEST when the 2nd REQUEST is parsed. This leads to the 2nd REQUEST re-using the TX. Since the TX is already marked as inspected, it means the toserver rule now no longer matches. Also we're not logging this TX correctly now.

Actions #4

Updated by Victor Julien about 2 months ago

  • Assignee changed from Victor Julien to Shivani Bhardwaj
Actions #5

Updated by Victor Julien about 2 months ago

  • Status changed from Assigned to In Review
  • Assignee changed from Shivani Bhardwaj to Victor Julien
Actions #6

Updated by Philippe Antoine about 21 hours ago

  • Status changed from In Review to Resolved
Actions

Also available in: Atom PDF