Project

General

Profile

Actions

Bug #5208

closed

DCERPC protocol detection when nested in SMB

Added by Brandon Murphy about 2 years ago. Updated over 1 year ago.

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

Description

I'm not sure this is really a bug or maybe just some confusion due to the lack of documentation, or if dcerpc probing is not working in this use case.

Consider the 3 rules, I would expect all three of them to fire given the use case of DCERPC nested in SMB (though I could understand if only sid:1 fires)

alert dcerpc any any -> any any (msg:"ET POLICY DCERPC  SVCCTL OpenSCManagerW Request"; flow:established,to_server; dcerpc.iface:367abb81-9844-35f1-ad32-98f038001003; dcerpc.opnum:15; classtype:bad-unknown; sid:1; rev:1;)
alert smb any any -> any any (msg:"ET POLICY DCERPC  SVCCTL OpenSCManagerW Request"; flow:established,to_server; dcerpc.iface:367abb81-9844-35f1-ad32-98f038001003; dcerpc.opnum:15; classtype:bad-unknown; sid:2; rev:1;)
alert tcp any any -> any [135,139,445,1024:] (msg:"ET POLICY DCERPC  SVCCTL OpenSCManagerW Request"; flow:established,to_server; dcerpc.iface:367abb81-9844-35f1-ad32-98f038001003; dcerpc.opnum:15; classtype:bad-unknown; sid:3; rev:1;)

sid:3 is taken directly from suricata-test https://github.com/OISF/suricata-verify/blob/master/tests/dcerpc/dcerpc-dce-iface-01/test.rules

However, When running these rules against the attached pcap, only sid:2 and sid:3 fire with gitmaster, which is unexpected to me.

It would appear that the DCERPC protocol is not matching when it's nested in SMB, though the dcerpc keywords work fine when using the SMB protocol, so not sure what's going on there.


Files

cool_1.pcap (377 KB) cool_1.pcap Brandon Murphy, 03/25/2022 01:07 PM

Subtasks 2 (0 open2 closed)

Bug #5395: DCERPC protocol detection when nested in SMB (6.0.x backport)ClosedVictor JulienActions
Bug #5423: DCERPC protocol detection when nested in SMB (5.0.x backport)ClosedVictor JulienActions
Actions #1

Updated by Peter Manev about 2 years ago

Yes I can confirm the same ,was testing it a few weeks back, forgot to put in an issue.
Related to https://redmine.openinfosecfoundation.org/issues/5134 in terms of perf.

Actions #2

Updated by Victor Julien about 2 years ago

  • Status changed from New to Assigned
  • Assignee changed from OISF Dev to Victor Julien
  • Target version changed from TBD to 7.0.0-beta1
Actions #4

Updated by Victor Julien almost 2 years ago

Some observations:

The alert dcerpc doesn't match because the app layer protocol of the traffic isn't dcerpc, its smb. However alert dcerpc locks the rule to the "pure" dcerpc.

{
  "raw": "alert dcerpc any any -> any any (msg:\"ET POLICY DCERPC  SVCCTL OpenSCManagerW Request\"; flow:established,to_server; dcerpc.iface:367abb81-9844-35f1-ad32-98f038001003; dcerpc.opnum:15; classtype:bad-unknown; sid:3; rev:1;)",
  "id": 3,
  "gid": 1,
  "rev": 1,
  "msg": "ET POLICY DCERPC  SVCCTL OpenSCManagerW Request",
  "app_proto": "dcerpc",
  "requirements": [
    "flow",
    "dcerpc" 
  ],
  "flags": [
    "src_any",
    "dst_any",
    "sp_any",
    "dp_any",
    "applayer",
    "toserver" 
  ],
  "pkt_engines": [
    {
      "name": "packet",
      "is_mpm": false
    }
  ],
  "frame_engines": [],
  "engines": [
    {
      "name": "dce_generic",
      "direction": "toserver",
      "is_mpm": false,
      "app_proto": "dcerpc",
      "progress": 0,
      "matches": [
        {
          "name": "dcerpc.iface" 
        },
        {
          "name": "dcerpc.opnum" 
        }
      ]
    }
  ],
  "lists": {
    "packet": {
      "matches": [
        {
          "name": "flow" 
        }
      ]
    }
  }
}

However if we don't specify the protocol, so use alert ip or alert tcp, it will do what you expect:

{
  "raw": "alert ip any any -> any any (msg:\"ET POLICY DCERPC  SVCCTL OpenSCManagerW Request\"; flow:established,to_server; dcerpc.iface:367abb81-9844-35f1-ad32-98f038001003; dcerpc.opnum:15; classtype:bad-unknown; sid:4; rev:1;)",
  "id": 4,
  "gid": 1,
  "rev": 1,
  "msg": "ET POLICY DCERPC  SVCCTL OpenSCManagerW Request",
  "requirements": [
    "flow",
    "dcerpc" 
  ],
  "flags": [
    "src_any",
    "dst_any",
    "sp_any",
    "dp_any",
    "toserver" 
  ],
  "pkt_engines": [
    {
      "name": "packet",
      "is_mpm": false
    }
  ],
  "frame_engines": [],
  "engines": [
    {
      "name": "dce_generic",
      "direction": "toserver",
      "is_mpm": false,
      "app_proto": "dcerpc",
      "progress": 0,
      "matches": [
        {
          "name": "dcerpc.iface" 
        },
        {
          "name": "dcerpc.opnum" 
        }
      ]
    },
    {
      "name": "dce_generic",
      "direction": "toserver",
      "is_mpm": false,
      "app_proto": "smb",
      "progress": 0,
      "matches": [
        {
          "name": "dcerpc.iface" 
        },
        {
          "name": "dcerpc.opnum" 
        }
      ]
    }
  ],
  "lists": {
    "packet": {
      "matches": [
        {
          "name": "flow" 
        }
      ]
    }
  }
}

This is because the keywords internally can handle both "pure" dcerpc and smb with dcerpc running over it, so the rule is setup to handle both.

So I guess the question is if the dcerpc app protocol specification in the rule should be overloaded to mean "either exact dcerpc or dcerpc over smb".

Actions #5

Updated by Victor Julien almost 2 years ago

  • Status changed from Assigned to In Review
  • Label Needs backport to 5.0, Needs backport to 6.0 added
Actions #6

Updated by Brandon Murphy almost 2 years ago

So I guess the question is if the dcerpc app protocol specification in the rule should be overloaded to mean "either exact dcerpc or dcerpc over smb".

I'm personally in favor of the rule being "overloaded". It makes sense from a rule writers perspective.

Actions #8

Updated by Victor Julien over 1 year ago

  • Label deleted (Needs backport to 6.0)
Actions #9

Updated by Victor Julien over 1 year ago

  • Status changed from Resolved to Closed
Actions #10

Updated by Victor Julien over 1 year ago

  • Label deleted (Needs backport to 5.0)
Actions

Also available in: Atom PDF