Possible problem with SigID 5442

[a.arndt]

We've been experiencing some false-positives with the Cursor/Icon File Format Buffer Overflow (SigID 5442) signature.

We've had some instances where the alarm has fired on a string containing ".ani", but not at all related to a file of this type.

Here's an example lifted right out of one such alarm...

ACON[\x00-\xFF]*anih([^\x24][\x00-\xFF][\x00-\xFF][\x00-\xFF]|[\x24][^\x00][\x00-\xFF][\x00-\xFF]|[\x24][\x00][^\x00][\x00-\xFF]|[\x24][\x00][\x00][^\x00])

Note that there is no leading "." in front of "ani" and that the text is actually "anih".

Is this intended behaviour for this SigID, or have I found a bug?

Thanks in advance,

Alex Arndt

[craiwill]

Could you provide more details on the traffic that fired this signature? A string containing “.ani” should not have fired this signature. 5442 is looking for an invalid resource interchange file format (RIFF) chunk within an ani file. This signature looks for the header ID “ACON” followed by the anih sub-chunk identifier specifying an invalid size. If you could provide a traffic sample it would be extremely helpful.

Thanks,

Craig Williams

Cisco Systems

[a.arndt]

Thanks for the reply.

First off, I'd like to admit an error. The string I originally posted is not in fact from an alarm, but rather the regex used in SigID 5442 to detect the undesirable traffic.

I had captured it some time ago in an effort to figure out what it was trying to do and accidentally thought that I'd actually captured some example traffic.

I'll review my logs and post an example shortly.

Sorry for the confusion,

Alex Arndt

[a.arndt]

Here's an example:

evAlert: eventId=1075979538832443912 severity=high

originator:

hostId: tunneys_gpnet

appName: sensorApp

appInstanceId: 1261

time: 2005/05/12 19:13:22 2005/05/12 19:13:22 UTC

interfaceGroup: 0

vlan: 0

signature: sigId=5442 sigName=Cursor/Icon File Format Buffer Overflow subSigId=0 version=S137 Malicious ANI File

context:

fromAttacker:

000000 67 77 6D 63 79 52 6D 54 76 37 6D 63 77 42 6D 57 gwmcyRmTv7mcwBmW

000010 0D 0A 74 76 6D 55 33 62 6D 5A 6A 72 6D 58 78 33 ..tvmU3bmZjrmXx3

000020 6D 59 33 72 6D 59 4A 2F 39 4A 6D 47 63 5A 6C 58 mY3rmYJ/9JmGcZlX

000030 62 35 6E 4F 69 35 6D 39 5A 4A 6E 64 69 35 6C 74 b5nOi5m9ZJndi5lt

000040 71 5A 6D 39 78 70 6D 65 6F 5A 6D 2F 42 35 6D 5A qZm9xpmeoZm/B5mZ

000050 56 5A 6B 75 52 70 6D 48 54 35 53 66 72 4A 6E 50 VZkuRpmHT5SfrJnP

000060 78 4A 0D 0A 6E 54 54 5A 6E 6E 62 5A 6C 6D 49 5A xJ..nTTZnnbZlmIZ

000070 6E 38 78 70 6E 4B 69 5A 6E 6D 35 70 6B 37 65 35 n8xpnKiZnm5pk7e5

000080 6C 64 57 35 6D 50 57 5A 6E 2F 65 70 6F 41 6B 36 ldW5mPWZn/epoAk6

000090 6D 47 55 70 6F 4F 48 4A 6E 71 46 6B 6F 42 6D 71 mGUpoOHJnqFkoBmq

0000A0 6E 4D 56 35 6F 73 47 4A 6F 48 41 4A 6F 45 48 51 nMV5osGJoHAJoEHQ

0000B0 6F 76 52 5A 0D 0A 6E 36 50 70 6F 52 48 4B 6D 78 ovRZ..n6PpoRHKmx

0000C0 72 36 6F 67 37 4B 41 32 51 35 6E 79 45 61 6E 79 r6og7KA2Q5nyEany

0000D0 2F 70 6C 31 7A 4A 6D 69 73 4B 70 42 55 61 70 44 /pl1zJmisKpBUapD

0000E0 76 36 6D 70 46 4A 70 42 42 36 6E 54 4F 4A 6F 6A v6mpFJpBB6nTOJoj

0000F0 45 36 6D 52 51 71 6E 52 6A 61 6E 69 68 36 6F 2F E6mRQqnRjanih6o/

participants:

attack:

attacker: proxy=false

addr: locality=OUT their.net.185.21

port: 80

victim:

addr: locality=IN my.net.245.198

port: 1221

alertDetails: Traffic Source: int0

Does this help?

Alex Arndt

[craiwill]

It doesn’t look like there is enough information in the alert to determine if this is a false positive. Is it possible to obtain a capture packet from this alert? We will continue to research this signature in our lab but we have yet to recreate the situation you describe.

Thanks,

Craig Williams

Cisco Systems

[a.arndt]

I will have to reconfig that signatue to "iplog" in order to get that for you.

Let me set it up and I'll see what I can get...

Alex Arndt

[a.arndt]

I've uploaded a log file containing the trigger packet for one of these alerts.

Note that the string "anih" appears, but nothing else seems amiss. BTW this came from a web server that, to my knowledge, is not offering any files that would be considered to be the type SigID 5442 is looking for.

Have a look and let me know if this helps.

Thank in advance,

Alex Arndt

[craiwill]

It looks like this may indeed be a false positive. I believe the problem stems from the variable length fields that can appear between the ACON header and the anih stub chuck identifier. To eliminate the possibility of false negatives we chose to use the [\x00-\xff] wildcard; this does allow for a slim chance of false positives. This signature was chosen because it addresses the vulnerability and cannot false negative. That being said we will continue to research this signature for modification in a future signature update.

In the meantime the following 5.x custom signatures may be of use. The main signature is a meta signature consisting of 2 component signatures. In order to create 5.x custom meta signatures the sensor must be running signature update S167 or later.

Component Signature 1: RIFF ACON

Engine: String.TCP

Direction: From Service

Ports: #WEBPORTS

Severity: Informational

Regex: RIFF[\x00-\xff][\x00-\xff][\x00-\xff][\x00-\xff]ACON

Do not associate an alarm event action with this signature

Component Signature 2: anih

Engine: String.TCP

Direction: From Service

Ports: #WEBPORTS

Severity: Informational

Regex: anih([^\x24][\x00-\xFF][\x00-\xFF][\x00-\xFF]|[\x24][^\x00][\x00-\xFF][\x00-\xFF]|[\x24][\x00][^\x00][\x00-\xFF]|[\x24][\x00][\x00][^\x00])

Do not associate an alarm event action with this signature

Meta Signature: ANI Cursor Overflow

Engine: META

Component List: Component Signature 1, Component Signature 2 (use their signature IDs)

Meta-Reset-Interval: 1

Component List In Order: True

Meta-Key: Attacker Address

Unique Victims: 1

Severity: High

Associate an alarm event action with this signature

This signature will reduce the length of time allowed to pass between seeing the ACON header and anih sub-chuck identifier; this time is set by the Meta Reset Interval parameter. Since all of these events must occur in the same file in an actual attack they will be seen almost immediately. To eliminate false negatives increase this interval; to eliminate false positives decrease this interval. The reset interval of 1 should not false negative unless an extremely slow connection is being monitored (sub 1kB/s).

Here is a 4.x custom signature; it should reduce the chance of any false positives.

RIFF[\x00-\xff][\x00-\xff][\x00-\xff][\x00-\xff]ACON((LIST|INAM|IART|fram|icon|rate|seq)[\x00-\xFF]+)?anih([^\x24][\x00-\xFF][\x00-\xFF][\x00-\xFF]|[\x24][^\x00][\x00-\xFF][\x00-\xFF]|[\x24][\x00][^\x00][\x00-\xFF]|[\x24][\x00][\x00][^\x00]))

This signature looks for the anih field immediately following the ACON header or following another header that immediately follows the ACON header. This signature may not be as effective as the 5.x signature.

[a.arndt]

Thanks for the confirmation (and sorry for the delayed response - didn't get the notification that a reply had been made...).

I'll try out the custom sig. I guess if 5442 fires, but not the custom one, we have a false positive. If they both fire, game on. Is that the intent here?

Alex Arndt

[craiwill]

It looks like this was a false positive but due to the nature of this vulnerability any other sig may false negative. The signatures I provided will reduce false positives but they MAY also create the possibility of a false negative.