Possible false positive issue with SigID 3334

[a.arndt]

I have yet another possible false positive signature. This time it is SigID 3334 - Windows Workstation Service Overflow.

Here's a capture from the EventStore on the sensor, again with the signature modified so that it captures the offending packet (CapturePacket=true):

evAlert: eventId=1075708170032497693 severity=high

originator:

hostId: cisco_ids-v4.1

appName: sensorApp

appInstanceId: 1134

time: 2005/07/19 17:08:44 2005/07/19 17:08:44 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 01 00 00 00 01 00 00 00 01 00 00 00 ................

000030 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 ................

000040 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 ................

000050 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 ................

000060 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 ................

000070 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 ................

000080 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 ................

000090 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 ................

0000A0 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 ................

0000B0 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 ................

0000C0 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 ................

0000D0 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 ................

0000E0 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 ................

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

fromAttacker:

000000 00 2C 4C 00 00 46 1B 00 00 6A 38 00 00 5D 16 00 .,L..F...j8..]..

000010 00 19 4E 00 00 F7 13 00 00 B6 54 00 00 25 31 00 ..N.......T..%1.

000020 00 82 29 00 00 7B 3F 00 00 66 53 00 00 5B 3C 00 ..)..{?..fS..[<.

000030 00 BB 40 00 00 BE 57 00 00 9F 4B 00 00 D9 06 00 ..@...W...K.....

000040 00 0C 0D 00 00 56 2C 00 00 D4 14 00 00 0B 13 00 .....V,.........

000050 00 B4 57 00 00 F2 0B 00 00 F8 19 00 00 B9 4B 00 ..W...........K.

000060 00 A6 3D 00 00 3F 1A 00 00 ED 1A 00 00 29 4E 00 ..=..?.......)N.

000070 00 22 38 00 00 53 23 00 00 70 58 00 00 73 58 00 ."8..S#..pX..sX.

000080 00 78 58 00 00 81 58 00 00 1C 1A 00 00 2D 59 00 .xX...X......-Y.

000090 00 50 3A 00 00 00 00 00 3B FF 53 4D 42 2E 00 00 .P:.....;.SMB...

0000A0 00 00 18 07 C8 00 00 00 00 00 00 00 00 00 00 00 ................

0000B0 00 02 10 FF FE 00 18 80 60 0C FF 00 DE DE 08 18 ........`.......

0000C0 00 00 00 00 88 0C 88 0C FF FF FF FF 88 0C 00 00 ................

0000D0 00 00 00 00 00 00 00 80 FF 53 4D 42 25 00 00 00 .........SMB%...

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

0000F0 02 10 94 06 00 18 C0 60 10 00 00 2C 00 00 00 88 .......`...,....

participants:

attack:

attacker: proxy=false

addr: locality=OUT 10.28.108.79

port: 1046

victim:

addr: locality=IN 10.24.4.42

port: 139

alertDetails: Traffic Source: int0 ;

Now if I understand this alarm correctly, it's looking at any SMB data that appears after the "\PIPE" in a packet, right? Given my dump, I don't think there's anything to get excited about... Is this another broken SMB-related signature?

Alex Arndt

[craiwill]

It looks like you posted the wrong event log so I have no way to tell if this is a false positive.

(I'm assuming your referring to signature 3334-0)

If you are using the 4.x version of this signature there may be potential for a false positive, since we do not tie the regex to a uuid. If you are running 5.x I do not think it’s possible for this signature to false positive. To add fidelity we used 5.x’s engine meta and created a signature to ensure a hit on this signature as well as one for the msrpc bind request’s uuid. There is no way to improve the signature in 4.x without creating a risk for false negatives (if you don’t mind the risk just increase the allocation hint). That being said, the 4.x version of this signature does look for very specific things:

3334-0 looks for an msrpc bind request using SMB_COM_Transaction utilizing the PIPE resource with an allocation hint >=1700, function 38 (base-10 for all these values), opcode 25 (base 10), set count of 2, and a word count of 16.

Thanks,

Craig Williams

Cisco Systems

[a.arndt]

Oops, how embarrassing... Sorry about that. I'll try and find a proper example in my logs to provide an example.

FYI, it is in fact SubSig 0 that I'm talking about, and it is on IDS v4.1, which means I'll consider your advice on it.

BTW, when it came to SubSig 1, it fired so often on legitimate SMB on our internal network that I had to turn it off all together...

Alex Arndt

[craiwill]

3334-1 faces the same issues. In 4.x to help eliminate false positives you can create a custom signature. It will fire before signature 3334-0 or 3334-1 on any malicious request.

Engine: String.TCP

Regex:\x98\xd0\xff\x6b\x12\xa1\x10\x36\x98\x33\x46\xc3\xf8\x7e\x34\x5a\x01\x00\x00\x00\x04\x5d\x88\x8a\xeb\x1c\xc9\x11\x9f\xe8\x08\x00\x2b\x10\x48\x60\x02\x00\x00\x00

Ports: 135,139,445,1024-1056

Direction: To-Service

Sev: Info