SNMP Protocol violation signature 4507

[ktimm]

I would like to understand what exactly this signature is looking for in relation to the new SNMP vulnerabilties. There is not a signature description using SigWizMenu. Does this signature only look for Cisco specific stuff, buffer overflow triggers or what ? It is my understanding there are several vulnerabilities does this catch all of them or only certain subsets, and if so how ? What are the possibilities for benign triggers ?

[bkubesh]

This signature catches a major subset of the new SNMP vulneraiblities. It is NOT Cisco specific.

It alarms off in invalid ASN length field in the SNMP packet. Specifically, when an ASN field length is specified that is larger than the actual data in the packet.

We have not identified any benign triggers, but are actively researching it. I'll let you know when we have more information.

[DSmirnov]

The signature is False Positive for any UDP traffic comming to port 161. It doesn't check if it is a SNMP packet.

I disabled it for DNS servers because some clients are using port 161 for DNS requests and when server replied - I'm have an alarm.

[ktimm]

Agreed it does appear to false alarm on udp port 161 traffic

such as

hping w.x.y.z -2 -p 161

,1001261,2002/02/15,16:43:31,2002/02/15,10:43:31,10008,a,b,OUT,IN,5,4507,0,TCP/IP,207.235.5.106,w.x.y.z,2402,161,0.0.0.0,Not valid ASN sequence

This would seem to cause a huge problem if it alerts this easily.

Thanks

[ptroxell]

Which version of the signature updates are you using. Last night 3.0(5)S17 was released on the ftp site. From another topic it is supposed to have tightened the signature.

[scothrel]

The new signature in 3.0(5)S17 is tighter. We c heck inbound traffic on port 161 with an SNMP protocol decoder(being a reserved port with a WKS assigned, this is reasonable). If the traffic is not, then our SNMP protocol decode detects the non-SNMP protocol as an SNMP protocol violation and fires the alert. The immediate workaround is to use the RecordofExcludedAddress token to exclude alarms from systems you know are using something else on port 161.

We have one report of a false positive from an SNMP management station. We are researching it now to find out the particulars.

Scott Cothrell

[bkubesh]

Details on the false positive:

If a GET Request is issued without a variable-binding (i.e. OID and value) the 4507 signature will fire. Our inperpretation was that the GET actually had to ask for some object. But apparently there is a custom management application that does a GET without any arguments. It is effectively a No-Op, or an odd form of a ping.

Our recommendation is that if you are getting alarms from known SNMP management stations, exclude the SRC IP of your SNMP management station for signature 4507.

[klwiley]

In the 3.0(4)S17 release of this signature there was a false positive situation that would occur when we would try to process fragmented traffic that was incomplete. This problem is fixed in the 3.0(5)S17 release. In addition to updating to 3.0(5)S17 any one who is experiencing this problem should also increase the reassembly timeout on their sensors to 30 to 60 seconds as you sensor is not waiting long enough to allow for fragment transmittals on your network.

An additional source of misfiring of this signature has been found in that some management stations have employed what I will refer to as an SNMP ping for lack of a better term. This SNMP ping has a NULL list of variable bindings. This is not strictly forbidden by the RFC, but is not in accordance with the standard implementation or understanding of the protocol. Our sensors therefore are seeing this as a protocol violation. For the near term if the source of your alarms are from a Network Management Station you can exclude them as a source for the alarm and it will solve the problem.

As far as the sensor seeing DNS traffic running on a reserved SNMP port and alerting on it as a protocol violation I'd have to say that it is correct. The DNS protocol is in conflict with the SNMP protocol and therefore this traffic is in violation.

[ktimm]

It appears to alert on any udp traffic to port 161 that is not SNMP, for instance hping will fire it. There hsould be no payload associated there. I understand the protocol modelling style signatureand the benifits of using it, however many IDS systems are installed with PIX firewalls. Very often PIX will use non priv ports for PAT which could cause that problem. So in the wild you will see legitimate traffic to port 161 that is not SNMP.

[klwiley]

Once again in the case that you are referring to the user must recognize that there is a legitimate reason for non SNMP based traffic on this machine at port 161 and should exclude it from the alarm. It would be impossible for the IDS to determine that although this traffic is in violation of the SNMP protocol that it is OK for that machine (destination) without input from the administrator.

[ktimm]

I'm not sure how accurate the 4507 signature is in 3.0(5)S17 release. It will still trigger on generic udp traffic such as can be generated by hping (or any port scanner). I also attempted sending some real snmp data that appeared to be a buffer overflow to the server (with several continuous no-ops and shell code) and it did not trigger an alarm.

[mlhall]

Typically our signatures do not look for shell code. Looking for shell code is very false positive prone. We do a protocol decode on the SNMP packets. We are looking for someone putting bogus information in the _protocol_. We are not checking for a bogus request. What is a bogus request? Different devices have different ways of representing within the SNMP protocol. I suspect your tool is not violating the protocol and therefore will not fire an alarm.