The protocol used by the majority of Internet networks around the world is
at risk from a new vulnerability discovered by the Oulu University Secure
Programming Group (OUSPG) in Finland recently.
The Computer Emergency Response Team Coordination Center (CERT/CC) issued an advisory to all network
administrators of a flaw in the simple network management protocol (SNMP),
the protocol used to remotely administer routers, switches and network
management systems.
The culprit responsible for the security breach seems to be one that
underlies most vulnerabilities: buffer overflow and format string errors.
Ian Finlay, CERT/CC Internet security analyst, said vendors were contacted
last year about the vulnerability, giving them a chance to create a security
patch to address the problem before the rest of the world (notably hackers)
found out. All told, more than 240 vendors were contacted after the Oulu
group ran a test program on networks that use SNMP as its protocol.
The problem is especially vexing because the problem can’t be pinned down
to one specific vendor, as is often the case with security vulnerabilities,
but must be corrected by many vendors.
If software vendors don’t get patches to their customers, CERT/CC predicts
“large-scale outages of these devices (that) could disable significant
portions of the global network.”
The biggest problem with patches, Finlay said, doesn’t reside with vendors
getting them published and out to their custmers. It’s getting system
administrators to deploy those patches across their networks.
“As we’ve seen in the past, getting administrators to actually deploy the
patch is the other half of the (problem),” Finlay said. “We haven’t seen
any (breaches) yet, but we would expect because SNMP is so common and so
pervasively deployed that we may see that shortly.”
Vendors with vulnerable systems follow: Nokia, Lucent Technologies,
Caldera, Hewlett-Packard, Multinet, Lotus, Juniper Networks, 3Com, Novell,
Cisco Systems, Microsoft Corp., NET-SNMP, Lantronix, Novell, Marconi,
Computer Associates, Red Hat Linux, AdventNet, COMTEK Services Inc.,
Innerdive Solutions LLC, CacheFlow Inc., Hirschmann Electronics GmbH & Co.,
FreeBSD, SNMP Research, Redback Networks Inc., and Netscape Communications
Corp.
This represents only a partial list of all vendors using SNMP, it’s unclear
whether others may be affected. CERT/CC recommends administrators visit
their Web page of
companies that are possibly affected by the vulnerability.
A Web page with security patches, by vendor, is available here.
Many listed in the previous paragraph already have patches available or
have release dates scheduled.
The organization reported increased information about the SNMP
vulnerability making its way through the hacker community, so it’s likely
only a matter of time before an enterprising cracker creates a distributed
denial of service (DDoS) to bring a network to its knees.
The breach is such that it can also let hackers create a “back door” to
devices using SNMP, giving hackers the leisure of breaking into the network
and returning at a more leisurely pace later.
Security experts warn that disabling SNMP as a defensive measure, which
would give administrators time to install a patch, is not an option for
many corporations around the world who conduct e-business, since billing
functions and ordering will be interrupted.
CERT/CC instead recommends the temporary stopgap of ingress filtering to
prevent outside machines from logging into corporate servers. The
organization recommends filtering ports 161/udp and 162/udp.
If the two measures above aren’t feasible, CERT/CC also suggests
restricting SNMP traffic to virtual private networks (VPNs) or to separate,
isolated management networks not available to the public.
SNMP 1 has been around since the early 1980s and several efforts have been
made to update the standard to SNMP 2 on a global basis, with no
success. Though there are some networks using SNMP 2 and SNMP 3, and some
networks have switched their remote administration protocol to remote
monitoring (RMON – which tells technicians more than whether the equipment
is functioning or not), most still use SNMP 1.
Finlay suspects the nature of the vulnerability doesn’t make versions two
or three any more secure than SNMP 1.
