Security Center - SID 1:16540

[JessIT1]

Getting a lot of these alerts from our main office's domain controller server and file server to a remote network.

It's causing their mapped network drive back to our office not to connect.

Microsoft Windows SMB2 client NetBufferList NULL entry remote code execution attempt

anyone else seeing this...

[alemabrahao]

 I would suggest you to contact the Support.

[JessIT1]

ok, yes i did open a case with support. I just know in the past some alerts were false positives, just wanted to see if anyone else is getting same alert.  thanks

[JessIT1]

The Meraki logging the alerts is a MX67W running - 18.211.2

[JessIT1]

Both source servers in the alerts are running Microsoft Windows Server 2022 Standard, so not sure if the snort explanation applies...

 

The SMB client in Microsoft Windows Server 2008 R2 and Windows 7 does not properly handle (1) SMBv1 and (2) SMBv2 response packets, which allows remote SMB servers and man-in-the-middle attackers to execute arbitrary code via a crafted packet that causes the client to read the entirety of the response, and then improperly interact with the Winsock Kernel (WSK), aka "SMB Client Message Size Vulnerability."

[BJF]

Had the same issue this morning.  We have about 34 sites some which have no local servers or domain controllers.  So users were having issues both logging into computers and when logged in being able to access file shares maintained over tunneled connections.   Believe this was some IDS rule change which sparked traffic being classified this am.

[JessIT1]

OK, thank you for confirming that. I do have a ticket open with Meraki support, I don’t want to whitelist these blocked alerts until I hear back from them but sounds like it’s a false positive..?

[RaphaelL]

Same here.  8420 pages of 100logs across my org.  Luckly for us we are running in IDS mode. 

[JessIT1]

Ok. Meaning you are running in Prevention mode like we are where these actions are being blocked? Like I said in my previous reply to someone, this is still causing issues for us I just don’t want to whitelist until I know for sure it’s safe to do so. Thanks 

[RaphaelL]

We are in IDS mode ( Detection with the rule set Security ) so everything is logged and not blocked.  But we do see those logs. 

In your case you are in IPS mode ( Prevention ) so blocking stuff classified in your configured ruleset.  It looks like a false positive, but only Meraki / Snort will be able to confirm.

[BJF]

Correct we were in prevention mode also which created the issues.  Yes, I've whitelisted the rule for time-being as the traffic is legit from the clients to servers.  It's not the first time we've had to do things like this to get production back up.

[JessIT1]

I may have to allow for now too, Remote site needs access to our mapped drive.

[ndjake]

Looks like we're seeing the same alerts in our org. I've just opened a ticket with support, but curious to know if anyone has gotten any feedback from their own support tickets. Luckily, this is at a small branch office so it's not impacting us too much at this point.

[BJF]

No feedback from support at this point.  The CVE is older so I'm fairly confident it's a false-positive at this time.

[JessIT1]

Response I got:  

Thank you for contacting Cisco Meraki support.
There is an issue with the new SNORT update and as a workaround for now, please whitelist the rule.

We are working to get this fixed as soon as possible. Thank you for your patience and co-operation.

[mmenor-tig]

EDIT: Nevermind, I found it!

How do you remove it from the whitelist after Meraki fixes the rule?

[JessIT1]

Go back into - Threat Protection / Intrusion Detection & Prevention / click X under Actions for the rule / save changes

[GiacomoS]

Hey Community,

Just wanted to update everyone here that this is an unfortunate false positive. We are working internally to ensure this is rectified as quickly as possible, but guidance at the moment is to whitelist the rule temporarily. 

We'll circle back once we have confirmation of a permanent fix being rolled out.

Many thanks!

Giac

[MOD NOTE: Marking this post as the "Solution" for visibility, even though the issue is not resolved.]

[GiacomoS · Accepted solution]

Hey everyone,

Another follow up here, we have now rectified the categorisation and you can now safely remove the rule from the whitelist, if you have taken the step of whitelisting. 

Please keep in mind that it can take up to an hour for the changes to apply to the SNORT configuration.

Many thanks!

Giac

[rweaver]

Thank you for providing the resolution status on this.