[EXTREMELY URGENT!!!] Widespread SNMP vulnerabilities subject to DoS

[Deepak Extross]

It's Chinese New Year and Steven is worrying about DoS vulnerabilities!

Gong Xi Fa Cai, Steven, and good luck in the Year of the Horse to you and our other Chinese friends out there.

[Wodisch]

Ni'men Hao, Steven and Deepak!

(are you trying to make it happen earlier, that more than half of the internet is speaking chinese? This was expected to happen in two or three years from now, but not yet ;-)

Anyway, since even Fred Reimer (at OVFORUM) is complaining about me being silent on that issue, I will try to give it a shot:

* This my own, private, not-related-to-or-by-any-company opinion and I would
not like to be sued for it ;-)

- SNMP is a security risc, and has always been! Nobody knowing it will doubt that...
- SNMPv2 or SNMPv3 would be a huge step in the right direction, but due to SNMPv2
having been banned from export out of the USA, and missing support from almost
every vendor (including OVBU), it is still not an option available to most of us :-(
- SNMPv3 *is* supported with NNM (though indirectly, by buying the SNMPv3 add-on
from SNMP Resarch, Inc) it is as badly supported by the hardware vendors as SNMPv2 is.
- SNMPv1 and SNMPv2C are the only versions available to the public, and everybody
seems to have accepted the inherent security problems :-(
- As long as almost everybody is using SNMPv1/SNMPv2C and hence sendling "get"
and "set" community strings in plain text over unsecured LANs - even WANs - there is
no additional weakness/vulnerability: whatever can be caused by the *newly* detected
implementation problems (the protocol isn't the real problem) was *available* to the
black-hats/crackers/crunchers/spies all the time!

So much about "FUD" (Fear Uncertainty Doubt) spread by that CERT-advisory...

Now for the "cure(s)":
- most equipment is perhaps not even able to be updated to a (not existing yet) newer
version of its SNMP-agent, especially not "in the field" (try to imagine yourself running
around with a laptop/notebook with ALL the different packages to this, and the needed
hardware, i.e. patch-cables, serial-cables, adaptors, gender-changers, and such,
kneeling on the floor, ducking under tables, creeping behind cabinets to attach to
that equipment)
=> no cure, except for buying new stuff!

- even the pieces of equipment being able to be updated, or to boot from network,
how big is the effort of testing the *new* SNMP-agent, before releasing it into productive
networks? I can only guess that we will not even be able to get that *new* release
for older hardware (say, older than two years), even if that equipment COULD or DOES
boot from a boot-/file-server...
=> no cure, at least not immediately, or buying new stuff!

- So you could try to go for SNMPv2:
Do you live/does your company reside in the USA?
Not certain if it is still banned, but in the past we (I am german) could not get it here
(vendor: "deliver it where?" me:"Frankfurt"
vendor: "Frankfort/Ohio?" me: "no, Frankfurt/germany"
vendor: "no chance" me: "... thank you...")
=> not available to at least some of us (my guess: most of us)

- How about SNMPv3?
Well, we can get the add-on from Jeffrey D. Cases company "SNMP Research",
which is supported (well, kind of) for NNM
But: can you get an SNMPv3 agent for your equipment?
=> not available to some of us...

Conclusion:
- no "sinlge-solution" in sight
- perhaps we could go for (proprietary) VPN-implementations of the equipment's vendors
to transport SNMP packages encrypted (not even certain wether the "back-end" software
is available for NNM (that's three platforms: HP-UX, Solaris, Windows). Maybe "ssh" (i.e.
secure shell) is available (almost) everywhere and SNMP can be *tunneled* through it?

Can you see the/some reason for being on the "silent" side on this topic?
AFAIK we (the admins) cannot change that much :-(

FWIW, just my $0.00002,
Wodisc

[Steven Sim Kok Leong]

Hi,

Some information extract from other security organisation/vendor:

1) From SANS flash alert,

"The problems were caused by programming errors that have been in the SNMP implementations for a long time, but only recently discovered.

CERT/CC is taking the lead on the process of getting the vendors to get their patches out."

2) From Microsoft MS02-006,

"A buffer overrun is present in all implementations. By sending a specially malformed management request to a system running an affected version of the SNMP service, an attacker could cause a denial of service. In addition, it is possible that he cause code to run on the system in LocalSystem context. This could potentially give the attacker the ability to take any desired action on the system.

A patch is under development to eliminate the vulnerability. In the meantime, Microsoft recommends that customers who use the SNMP service disable it temporarily. Patches will be available shortly, at which time we will re-release this bulletin with updated details."

Hope this helps. Regards.

Steven Sim Kok Leong

[John Payne_2]

But if you are just worried about HPUX, it appears that you can install the patches
PHSS_26137 s700_800 10.20 OV EMANATE14.2 Agent Consolidated Patch
PHSS_26138 s700_800 11.X OV EMANATE14.2 Agent Consolidated Patch
and be ok. (Assuming that you have just vanilla HPUX...) We have applied these patches, and the snmpdm is replaced via the patch. 3rd party software may need to be patched also. We use CA Unicenter, and they have to develop their own patch, because they run their own snmp stuff via port 6665 or something like that...

John

[Martin Burnett_2 · Accepted solution]

Hello All,

All current security bulletins are available through the ITRC. Follow these steps and you can subscribe to bulletins or just keep up to date on the latest:

Maintenance & Support -> Notifications -> Support Information Digests

Stop here and subscribe if you want to receive daily security updates.

Use the link at the bottom of the page to view the current security bulletins:

HP Security Bulletins Archive

These include HP-UX, MPE and Non-HP Security Bulletins.

Thanks for using the ITRC.

Martin

[Christopher Caldwell]

Filter SNMP at your border (you probably should filter regardless of the patch state of your equipment:

With Cisco, it would look like this:

access-list 102 permit ip A.B.C.D E.F.G.H any
access-list 102 deny udp any any eq snmp
access-list 102 deny udp any any eq snmptrap
access-list 102 permit ip any any

Where A.B.C.D E.F.G.H is the network address / mask for your network.

Appy the filter to the inbound side of your most external interfaces:

ip access-group 102 in

[Steven Sim Kok Leong]

Hi Caldwell,

Not only should both TCP and UDP service ports 161 and 162 be filtered at the border CISCO router, TCP and UDP 1993 (prioprietary to CISCO older IOSes for snmp over tcp) should also be filtered just in case someone internally is using a much older IOS version.

Hope this helps. Regards.

Steven Sim Kok Leong