Bug #5162
closedinspection of smb traffic without smb/dcerpc doesn't work correct.
Description
This is a very strange issue, I haven't a clue what is going on. In trying to figure out how to write this up, I seem to have found multiple ways to reproduce it.
Suricata 4.0.x appears to be unaffected by this.
Method 1¶
Consider the following rules.
alert tcp any any -> any 445 (msg:"SVCCTL CreateService Command via SMB"; flow:established,to_server; content:"SMB"; depth:8; content:"|09 00|"; distance:8; within:2; content:"|05 00 00|"; distance:0; content:"|0c 00|"; distance:19; within:2; content:"|15 00 00 00|"; distance:20; within:4; sid:1;) alert tcp any any -> any 445 (msg:"SVCCTL CreateService Command via SMB"; flow:established,to_server; content:"|fe|SMB"; depth:8; content:"|09 00|"; distance:8; within:2; content:"|05 00 00|"; distance:0; content:"|0c 00|"; distance:19; within:2; content:"|15 00 00 00|"; distance:20; within:4; sid:2;)
The only difference in these two signatures is that sid:2; contains and extra byte in the first content match.
Only sid:2;
alerts, despite, logically sid:1;
should as well.
02/25/2022-16:33:47.258334 [**] [1:2:0] SVCCTL CreateService Command via SMB [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.56.104:62618 -> 192.168.56.102:445 02/25/2022-16:33:47.426685 [**] [1:2:0] SVCCTL CreateService Command via SMB [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.56.104:62619 -> 192.168.56.102:445
Method 1 - Workaround¶
Making use of a standalone "within" instead of a distance/within combination appears to work
alert tcp any any -> any 445 (msg:"SVCCTL CreateService Command via SMB"; flow:established,to_server; content:"SMB"; depth:8; content:"|09 00|"; distance:8; within:2; content:"|05 00 00|"; distance:0; content:"|0c 00|"; distance:19; within:2; content:"|15 00 00 00|"; within:24; sid:10;)
02/25/2022-16:33:47.258334 [**] [1:10:0] SVCCTL CreateService Command via SMB [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.56.104:62618 -> 192.168.56.102:445 02/25/2022-16:33:47.426685 [**] [1:10:0] SVCCTL CreateService Command via SMB [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.56.104:62619 -> 192.168.56.102:445
I have no idea why this works....
Method 2¶
Consider the following rules (separate or combined with the above rules, doesn't seem to matter) - I've just used the version that includes the |fe|
to isolate/replicate the problem in another way.
alert tcp any any -> any 445 (msg:"SVCCTL CreateService Command via SMB"; flow:established,to_server; content:"|fe|SMB"; depth:8; content:"|09 00|"; distance:8; within:2; content:"|05 00 00|"; distance:0; content:"|0c 00|"; distance:19; within:2; content:"|15 00 00 00 00|"; distance:20; within:5; sid:3;) alert tcp any any -> any 445 (msg:"SVCCTL CreateService Command via SMB"; flow:established,to_server; content:"|fe|SMB"; depth:8; content:"|09 00|"; distance:8; within:2; content:"|05 00 00|"; distance:0; content:"|0c 00|"; distance:19; within:2; content:"|15 00 00 00|"; distance:20; within:4; pcre:"/^\x00/R"; sid:4;)
Only sid:4;
alerts, despite, the logic contained in sid:4;
proving that sid:3
should have alerted as well.
02/25/2022-16:33:47.258334 [**] [1:4:0] SVCCTL CreateService Command via SMB [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.56.104:62618 -> 192.168.56.102:445 02/25/2022-16:33:47.426685 [**] [1:4:0] SVCCTL CreateService Command via SMB [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.56.104:62619 -> 192.168.56.102:445
Files