Bug #5208: DCERPC protocol detection when nested in SMB - Suricata - Open Information Security Foundation

Actions

Copy link

Bug #5208

closed

DCERPC protocol detection when nested in SMB

Added by Brandon Murphy over 2 years ago. Updated over 2 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Victor Julien

Target version:

7.0.0-beta1

Affected Versions:

git master

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 open — 2 closed)

Actions

Copy link

Updated by Peter Manev over 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

Copy link

Updated by Victor Julien over 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

Copy link

Updated by Shivani Bhardwaj over 2 years ago

s-v test (needs updation): https://github.com/OISF/suricata-verify/pull/798

Actions

Copy link

Updated by Victor Julien over 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

Copy link

Updated by Victor Julien over 2 years ago

Status changed from Assigned to In Review
Label Needs backport to 5.0, Needs backport to 6.0 added

https://github.com/OISF/suricata/pull/7522

Actions

Copy link

Updated by Brandon Murphy over 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

Copy link