This chapter is from the book
This chapter is from the book
This chapter is from the book
3.6 Simple Network Management Protocol—SNMP
The Simple Network Management Protocol (SNMP) [Case et al., 1990] is used to control routers bridges, and other network elements. It is used to read and write an astonishing variety of information about the device: operating system, version, routing tables, default TTL, traffic statistics, interface names, ARP tables, and so on. Some of this data can be surprisingly sensitive. For example, ISPs may jealously guard their traffic statistics for business reasons.
The protocol supports read, write, and alert messages. The reads are performed by GET and GETNEXT messages. (GET returns a specific item; GETNEXT is used to enumerate all of the entries in a data structure.) A single record is returned for each, as this uses UDP packets. SET messages write data, and TRAPs can indicate alarms asynchronously. A heavy series of messages can load down a router's CPU.
The data object is defined in a management information base (MIB). MIB entries are in turn encoded in ASN.1, a data specification language of some complexity. To obtain a piece of information from a router, one uses a standard MIB, or perhaps downloads a special MIB entry from the manufacturer. These MIBS are not always well tested for security issues.
Given ASN.1's complexity, few compilers have been written for it—instead, they were shared and propagated. In late 2001, several of these implementations failed a series of tests run by the Oulu University Secure Programming Group, resulting in CERT Advisory CA-2002-03. Numerous implementations of SNMP (and other vital protocols) were subject to possible attack through their ASN.1 processing.
In principle, at least some of the encoded ASN.1 fields can be passed through a sanity checker that will eliminate the more egregious mistakes. But there's not much an outboard parser can do if a field is 1024 bytes long when the application is expecting 128 bytes. Furthermore, there are ill-behaved specifications based on ASN.1, whereby substructures are encoded as byte strings, thus rendering them almost opaque to such sanity checkers. (In some cases, it's possible to use heuristics to detect such things. But those can obviously encounter false positives; in addition, they can have false negatives in exactly the situation where you want to find them: where the data is ill-formed.) The SNMP protocol itself comes in two major versions, numbers one and three. (SNMPv2 was never deployed.) The most widely deployed is version 1. It is also the least secure. Access is granted using a community string (i.e., password), which is transmitted in the clear in version 1.
Most implementations default to the well-known string "public," but hackers publish extensive and effective lists of other community strings in use. In many cases, the community string (especially "public") grants only read access, but we have seen that this can leak sensitive data. For network management, write permission is usually needed as well. Many sites find SNMP useless for configuring routers, but many small devices like printers and access hubs require SNMP access as the only way to administer them, and a community string for write access. Some hosts, such as Solaris machines, also run SNMP servers.
Clearly, it is dangerous to allow strangers access to SNMP servers running version.1. SNMP version.3 has much better security—cryptographic authentication, optional encryption, and most important, the ability to grant different access rights to portions of the MIB to different users. The crypto authentication can be expensive, and routers typically have weak CPUs, so it may be best to restrict access to these services as well. Version 3 security is discussed further in [Blumenthal and Wijnen, 1999].