A great many server, software, and networking vendors have implemented the Simple Network Management Protocol (SNMP) as a means of remotely managing and monitoring systems attached to networks, including the biggest network of them all—the Internet. It’s one of the most pervasive IT tools, and many administrators make use of it daily. As a result, any problem with SNMP is of critical concern to security professionals.

Details of the vulnerability
Although SNMP has been in use for a long time, CERT just published an advisory (CA-2002-03) outlining two major vulnerabilities recently discovered by the Finnish Oulu University’s Secure Programming Group (OUSPG) as part of the school’s ongoing protocol testing project, PROTOS – Security Testing of Protocol Implementations.

The problem isn’t a single minor bug but a number of important vulnerabilities in several parts of the first version of SNMP, known as SNMPv1. This is an old protocol, and there are newer versions. Unfortunately, most vendors implement the first version, so this is a very widespread threat.

The first vulnerability, VU#107186, relates to SNMP trap message handling. SNMP trap messages are used to communicate error messages, and OUSPG has described a number of problems with the way SNMP decodes and processes these messages.

The second problem, VU#854306, is found in manager-to-agent request messages. Unfortunately, until patches are available, the only way to protect systems using SNMP is to temporarily disable it.

Threat level: Medium
The potential for damage from this flaw is serious, leading to denial of service events or allowing attackers to run any arbitrary code on target systems. However, SNMP is widely known to be an insecure protocol—one never designed for use except between trusted systems. Therefore, this threat will probably not be a major problem despite the fact that it is relatively easy to exploit.

Admins who have already taken SNMP’s weaknesses into account and compensated for them will probably not be affected by this flaw. However, anyone who does rely on SNMP for Internet-based network management and either was not aware of SNMP’s security shortcomings or has not compensated for them needs to take immediate action.

Since SNMP’s UDP Ports 161 and 162 are normally blocked by a well-configured firewall, most firewall-protected networks would only be vulnerable to internal attacks based on these vulnerabilities.

This threat affects nearly 200 different vendor systems. Microsoft has released MS02-006 dealing with the SNMP problems for its systems, but, although all versions of Windows except Me ship with SNMP as an optional component, it isn’t implemented by default in any version. This greatly reduces the level of threat to Windows systems.

Nevertheless, SNMP is widely used, and any network making use of it is potentially vulnerable. On the UNIX front, FreeBSD doesn’t implement SNMP in its basic package, so installations aren’t vulnerable unless you have installed the FreeBSD Ports Collection. IBM has reported that tests on AIX show its version of SNMP is not vulnerable.

For more information on specific software and hardware, please see the CERT bulletin Appendix for information provided by various vendors.

Microsoft recommends that customers who use the SNMP service disable it temporarily, and the same procedure should probably be adopted for other SNMP software and equipment until specific patches are available. However, be warned that disabling SNMP can have adverse consequences where it is implemented and relied upon by other companion services.

Of major concern is the report by CERT that says, “Some of the affected products exhibited unexpected behavior or denial of service conditions when exposed to the OUSPG test suite even if SNMP was not enabled. In these cases, disabling SNMP should be used in conjunction with filtering practices.

“For SNMP, ingress filtering of the following ports can prevent attackers outside of your network from impacting vulnerable devices in the local network that are not explicitly authorized to provide public SNMP services.
snmp     161/udp     # Simple Network Management Protocol (SNMP)
snmp     162/udp     # SNMP system management messages”

CERT also identifies the following services to be filtered, even though attacks are less likely using these ports:
smux               199/tcp     # SNMP Unix Multiplexer
smux               199/udp     # SNMP Unix Multiplexer
synoptics-relay    391/tcp     # SynOptics SNMP Relay Port
synoptics-relay    391/udp     # SynOptics SNMP Relay Port
agentx             705/tcp     # AgentX
snmp-tcp-port     1993/tcp     # cisco SNMP TCP port
snmp-tcp-port     1993/udp     # cisco SNMP TCP port

As CERT points out in CA-2002-03, “The SNMP daemon may bind to all IP interfaces on the device.” This can be important when deciding how to implement filtering. Packets directed to addresses other than the normal network interface may bypass firewalls.

SNMP background
SNMP is best understood as a language used to remotely manage routers, servers, switches, even printers—essentially, any network-managed device.

To understand just how vulnerable SNMP can be, it’s useful to understand its origin as an Internet protocol developed in the 1980s. Back then, TCP/IP networks were just becoming popular in business, and enterprise network management was starting to be a major concern. SNMP was developed when access to the Internet was very limited. SNMP quickly became popular when RFC 1157 was published in 1990. Neither of the first two versions of SNMP included any real security features.

For more information on weaknesses in SNMP, see “Don’t allow SNMP to compromise network security.” To learn why you might want to implement SNMP in W2K shops, see “Let SNMP do the walking.”

Although the first two versions of SNMP weren’t secure, there were secure versions developed. Unfortunately, almost no one ever implemented any of these early, secure versions.

SNMPv1 has been defined by RFC 1157, replacing RFC 1067 and RFC 1098. Security, such as it is, is based on well-known community names. SNMP-Sec added protocol security to SNMPv1, as explained in RFC 1351, RFC 1352, and RFC 1353. It has never really been implemented.

Secure Party-based SNMP, or SNMPv2p, is described in RFC 1441. It includes a lot of changes, not just additional security.

For information on SNMPv3, see the IETF Web site. After years of work, SNMPv3 should soon be published as an RFC. I have seen mention of RFC 2104 in conjunction with SNMPv3, but this is merely a message authentication note, not a standard or an SNMP document.

All administrators need to be acutely aware of these new SNMP flaws because all admins probably have at least a couple servers or pieces of networking equipment that are running SNMP. If these systems are not protected by firewalls or other security provisions, then they could definitely be at risk for being exploited by hackers.