Possible false positive issue with SigID 3353

[a.arndt]

Here is a packet captured by the IDS that triggered SigID 3353 - SMB Request Overflow

evAlert: eventId=1075708170032493259 severity=high

originator:

hostId: cisco-ids-v4.1

appName: sensorApp

appInstanceId: 1134

time: 2005/07/18 14:53:30 2005/07/18 14:53:30 UTC

interfaceGroup: 0

vlan: 0

signature: sigId=3353 sigName=SMB Request Overflow subSigId=0 version=S180 Malformed SMB Request

context:

fromVictim:

000000 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 ................

000010 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 ................

000020 01 00 00 00 00 00 00 00 00 00 00 68 FF 53 4D 42 ...........h.SMB

000030 25 00 00 00 00 98 07 C8 00 00 00 00 00 00 00 00 %...............

000040 00 00 00 00 00 50 78 07 01 90 81 0C 0A 00 00 30 .....Px........0

000050 00 00 00 00 00 38 00 00 00 30 00 38 00 00 00 00 .....8...0.8....

000060 00 31 00 2C 05 00 02 03 10 00 00 00 30 00 00 00 .1.,........0...

000070 0A 00 00 00 18 00 00 00 00 00 00 00 00 00 00 00 ................

000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

000090 00 00 00 00 00 00 00 68 FF 53 4D 42 25 00 00 00 .......h.SMB%...

0000A0 00 98 07 C8 00 00 00 00 00 00 00 00 00 00 00 00 ................

0000B0 00 50 78 07 01 90 C1 0C 0A 00 00 30 00 00 00 00 .Px........0....

0000C0 00 38 00 00 00 30 00 38 00 00 00 00 00 31 00 2C .8...0.8.....1.,

0000D0 05 00 02 03 10 00 00 00 30 00 00 00 0B 00 00 00 ........0.......

0000E0 18 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

0000F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

fromAttacker:

000000 00 00 00 00 00 54 00 2C 00 54 00 02 00 26 00 0F .....T.,.T...&..

000010 70 3D 00 00 5C 00 50 00 49 00 50 00 45 00 5C 00 p=..\.P.I.P.E.\.

000020 00 00 00 00 05 00 00 03 10 00 00 00 2C 00 00 00 ............,...

000030 0A 00 00 00 14 00 00 00 00 00 01 00 00 00 00 00 ................

000040 BB E2 9E 20 19 4C 0D 4B B7 17 DF 44 B9 00 52 40 ... .L.K...D..R@

000050 00 00 00 80 FF 53 4D 42 25 00 00 00 00 18 07 C8 .....SMB%.......

000060 00 00 00 00 00 00 00 00 00 00 00 00 00 50 78 07 .............Px.

000070 01 90 C1 0C 10 00 00 2C 00 00 00 54 05 00 00 00 .......,...T....

000080 00 00 00 00 00 00 00 00 00 54 00 2C 00 54 00 02 .........T.,.T..

000090 00 26 00 0F 70 3D 00 00 5C 00 50 00 49 00 50 00 .&..p=..\.P.I.P.

0000A0 45 00 5C 00 00 00 00 00 05 00 00 03 10 00 00 00 E.\.............

0000B0 2C 00 00 00 0B 00 00 00 14 00 00 00 00 00 01 00 ,...............

0000C0 00 00 00 00 15 FD E7 ED 7D DD E4 40 8A E9 7C 39 ........}..@..|9

0000D0 30 15 BC C3 00 00 00 80 FF 53 4D 42 25 00 00 00 0........SMB%...

0000E0 00 18 07 C8 00 00 00 00 00 00 00 00 00 00 00 00 ................

0000F0 00 50 F0 06 01 90 00 0D 10 00 00 2C 00 00 00 80 .P.........,....

participants:

attack:

attacker: proxy=false

addr: locality=IN 10.24.238.193

port: 1071

victim:

addr: locality=IN 10.24.4.42

port: 139

alertDetails: Traffic Source: int0 ;

As you can see, looks like a pretty normal SMB packet. This sensor is on an internal network, so Windows file and printer sharing is the norm.

I think there is a false positive issue that was introduced with the signature’s tuning via the S180 update. As a result, I have two questions:

1) Am I right, or is the signature working as it should?

2) Is anyone else having this problem?

Any and all feedback will be greatly appreciated,

Alex Arndt

[craiwill]

We are looking into this issue. It would be helpful if you could provide a verbose alert or capture packet.

Thanks,

Craig Williams

Cisco Systems

[a.arndt]

I believe I already have...

My original post was a verbose alert. The only thing I changed on the sensor to get that alert was to modify the SigID so that the alarm would include the offending packet (CapturePacket=true).

Is there something else you're looking for?

Alex Arndt

[craiwill]

There is not enough information in this alert to determine if this is a false positive. We will continue to test this signature against smb traffic in our lab but so far we have been unable to produce a false positive.

[craiwill · Accepted solution]

We have identified the problem; an updated version of this signature will be in an upcoming signature update.

[a.arndt]

Thank you. Is it safe to assume S182 will bring us the fix?

BTW, is there anything we can do to customize the S180 version, other than turning it off, to reduce the false positives?

Any enlightenment and/or explanation would be greatly appreciated.

Alex Arndt

[craiwill]

The new version of this signature should be included in the S182 update. As a workaround if you are using 5.x you may to create 2 meta signatures using this signature and the no-op sled signatures (3328 for better coverage create a meta associated with each one and the existing sig). In your component list be sure to set 3353 prior to 3328. Set unique attackers to 1, meta interval to 2, and component list in order to true. This should eliminate all benign triggers.

[a.arndt]

Can those of us still running v4.1 do anything with our signature configuration to fix this until S182 is released?

Alex Arndt