by Rik Farrow
Simple Network Management Protocol (SNMP) was developed in the late eighties and early nineties to help make large networks more manageable. Network devices, such as routers, switches, and terminal servers, would run agents, and network managers (such as Sun's Solstice and HP OpenView) could query those agents. The agents can report hundreds of statistics relevant to the proper running of a network device.
And these same agents can give up lots of useful information to attackers as well.
Fixing your exposure to remote abusers of SNMP is as easy as using a correctly implemented firewall. Just block accesses to UDP port 161 (or even better, all UDP except DNS). And there are other simple ways to prevent remote abuses. Solving the internal exposure SNMP provides hostile insiders is a much more intractable problem.
The "simple" in SNMP is a bit misleading. The SNMP protocol itself is designed so that agents can be rather simple. Just about everything else about SNMP is not so simple. As example, the library required to build a set of command line tools you can get from Carnegie-Mellon is over two megabytes in size (see resources).
Conceptually, SNMP is wonderfully simple. Managers send requests to agents, and the agents send back replies. The requests and replies refer to variables accessible to the agent software. Managers can also send requests to set values for certain variables. And finally, agents can respond on their own to the manager by sending a trap message. Traps let the manager know that something significant has happened at the agent's end of things: a reboot, an interface failure, or that something else that is potentially bad has happened.
The SNMP protocol itself is defined in RFC 1157, and is designed to be transport independent--it will work over X.25 and TP-4 as well. The preferred transport is UDP over IP, and that is where part of the trouble lies. But I am getting ahead of myself.
Where SNMP is complex is in the definition of the variables. An agent's variables are stored in a database known as the Management Information Base (MIB, see RFC 1213 for MIB-II). The manager (or a command line tool) refers to variables in the MIB using object identifiers. To keep things as interesting as possible (and simple for the agent), object identifiers are hierarchically organized, with the root of the tree of objects being "dot" (.), and the remainder of the nodes in the tree represented as numbers. For example, to query the TCP connection table, you would begin with the object id .1.3.6.1.2.1.6.13, which is not a very humanfriendly name. But this does work well for the agents.
In RFC 1157, as well as in RFCs 1901 to 1907 that describe version 2 of SNMP, you will find a short description of the security: "Security issues are not discussed in this memo." Like many other Internet protocols, security was not designed into the first two versions of the protocol at all. The designers of SNMP were focused on managing networks that were already too large and ungainly.
What versions one and two of SNMP do have is something called a community. The community defines which of several sets of variables a manager has access to: read-only, read-write, and write-only. In practice, there are two communities, the read community and the write community. It is possible to define other communities on host-based SNMP agents, and use this community to limit the view into the object hierarchy. For a security practitioner or attacker, any community that produces information is interesting.
A version one or two SNMP request from a manager is consider "authentic" if it contains one of the two community names configured into agents. Most agents use the name "public" as the read-only community, and "private" as the read-write community. This is a boon for the makers of network manager software, as SNMP-enabled devices and systems will readily communicate with the managers using the default communities.
It is pretty horrific for security, however. While the community name is not authentication, a request that does not contain the correct community name will be ignored (or a trap will be generated, but more on that later). If you have not changed the default values, then anyone who has access to UDP port 161 on your networks can query, and possibly modify, variables accessible to the SNMP agent.
An attacker can shutdown your network using SNMP if the read-write community name has not been changed. Using the default name public, an attacker can get a list of interfaces on a router, and then using the read-write community (private), disable them. This must be done carefully, or the attacker can shut down his or her access to the router before disabling all the interfaces.
Obviously, this scenario should be ample motivation for changing the default community names on your network. You say there are over a thousand devices to change? While changing the communities is important, and not unreasonable in theory, in practice it may not be easy.
Networking devices are not the only targets of SNMP mayhem. UNIX systems can have agents enabled. The SNMP agent for UNIX that I have played with is part of the contributed ISODE library. You can control the views into the variables by editing the smnpd.rc file, and hide whatever variables you choose. Other agents may be less flexible.
Your NT 4.0 server may include an
SNMP agent, with the default read-only community of public.
Bring up the Services Control Panel, and see if the SNMP agent
is present, and enabled. If it is you may wish to simply disable
it, but at least change the community name.
The NT SNMP agent will spill lots of interesting information, some of it similar to what you can get using NBTSTAT or RPC calls. If the NT server is running WINS or DHCP, this information will also be available through SNMP. That is, a map of your network, providing names (WINS) or IP address to MAC address mappings (DHCP). If a read-write password has been set, and is known, a miscreant with SNMP manager software can change WINS and DHCP databases remotely.
SNMP can also be used for probing. Many MIBs include the TCP connection table, which lists all of the ports passively listening for connections, as well as all of the active TCP connections. In other words, you can perform a remote netstat -a command using SNMP, and get more information than you get would using remote scanning tools. Listing 1 includes a portion of a connection table. Note that some SNMP agents, like the one found in Cisco's IOS 11 and the ISODE snmpd, will hide some or all of the connection table.
SNMP MIBs also include information about the identity of the agent's host. The standard MIB-II will include the product name and the version of the software currently running (see listing 2). Again, this may be a boon for an attacker, although it is really designed to assist in managing a widely-distributed network. The MIB includes variables for the location as well as the name of a local contact, but these were not set in the example.
Scanning using SNMP is not terribly subtle. Current SNMP agents will return only one variable at a time, so walking an object hierarchy results in a pair of UDP packets for each entry. If you have a configurable IDS system, such as Shadow or NFR, you might consider looking for lots of traffic to UDP port 161 from external addresses (or any address that is not that of a manager).
Preventing access to SNMP agents is as simple as blocking UDP port 161. It is possible for SNMP to use other UDP ports, and if you have done this, protect these ports as well. Scanning tools can detect when there is no service listening at a UDP port, so why take chances?
If you don't have any firewall at all, you have more problems than just SNMP. At the very least, change your community names from "public" and "private", please. While SNMP cannot be used to break-in, it is useful for what will be very mysterious denial-of-service attacks and probing.
Denying potentially hostile internal users access to SNMP is much more difficult. SNMP has no authentication, just the community name that identifies views into the agent's database of objects (the MIB). An attacker can quickly learn the community name by sniffing for packets going to the SNMP agent.
Some SNMP agents, such as Windows NT's and the ISODE snmpd, can use an access list to limit which source IP addresses the agent will respond to. For example, you could set this list up so that only an SNMP manager coming from one of two IP addresses will be permitted to query the agent, or write to variables.
The problem with this approach is that SNMP is eminently spoofable because it uses the UDP protocol. Using a tool like Netcat, an SNMP request coming from a permitted source address can be spoofed, and the response from the agent can be sniffed. The true manager will likely ignore any unrequested responses silently.
SNMP v3 will provide the first real security for SNMP. RFC 2274 describes mechanisms for authenticating agents, providing for data integrity, protection against replay attacks, and confidentiality. SNMP engines (both managers and agents) will need to be configured with two private "keys". The first key will be used in creating digital signatures 96 bits long for authentication and integrity purposes. The second is a real key that can be used to encrypt responses from an agent (currently using DES in CBC mode).
Implementing version 3 will take a while, and there is still resistance to using it. For example, each SNMP agent will need to be configured before it will work, unlike the current, insecure scheme. SNMP managers will also need to be replaced or upgraded. Still, this seems a small price to pay for reasonable security in a useful, but not very simple, system.
You can find a complete index of all the RFCs at http://www.landfield.com/rfcs/rfc-titles.html. Key RFCs referred to in this article:
Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990.
Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996
Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2274, January 1998.
SNMP Tool Library (can be compiled under UNIX or NT): http://www.net.cmu.edu/projects/snmp and http://www.net.cmu.edu/projects/snmp/snmpapps/
NEW: CERT advisory of additional dangers found in SNMP: http://www.cert.org/advisories/CA-2002-03.html
C> snmputil walk termserv1 public .1.3.6.1.2.1.6.13 ...
Name: tcp.tcpConnTable.tcpConnEntry.tcpConnState/ .203.18.241.41.23.0.0.0.0.0 -> INTEGER: listen(2) Name: tcp.tcpConnTable.tcpConnEntry.tcpConnState/ .203.18.241.41.1008.0.0.0.0.0 -> INTEGER: listen(2) Name: tcp.tcpConnTable.tcpConnEntry.tcpConnState/ .203.18.241.41.1643.0.0.0.0.0 -> INTEGER: listen(2) Name: tcp.tcpConnTable.tcpConnEntry.tcpConnState/ .203.18.241.41.1643.203.18.241.97.1027 -> INTEGER: established(5) ...
Listing 1: Using snmputil, part of the NT resource kit, you can 'walk' the TCP connection table of the host named termserv1 and with the community name public. The portion of the output shown here depicts services listening at ports 23 (telnet), 1008 and 1643. There is currently a connection to termserv1's (203.18.241.41) port 1643 from 203.18.241.97 and port 1027. Although the format is very different, the output provides information similar to the netstat command found in UNIX and NT.
% snmpwalk router1 sEKr33t-- system
Name: system.1.0 -> OCTET STRING- (ascii): Cisco Internetwork Operating System Software ..IOS (tm) 2500 Software (C2500-I-L), Version 11.2(8), RELEASE SOFTWARE (fc1)..Copyright (c) 1986-1997 by cisco Systems, Inc...Compiled Tue 05-Aug-97 00:36 by ckralik Name: system.2.0 -> OBJECT IDENTIFIER: .iso.org.dod.internet.private.enterprises.cisco.ciscoProducts.cisco2524 Name: system.3.0 -> Timeticks: (69630710) 8 days, 1:25:07 Name: system.4.0 -> OCTET STRING- (ascii): Rik Farrow, x2468 Name: system.5.0 -> OCTET STRING- (ascii): router1.spirit.com/ Name: system.6.0 -> OCTET STRING- (ascii): north equipment bay, #2 Name: system.7.0 -> INTEGER: 6Listing 2: Using the snmpwalk utility from the CMU SNMP toolkit, you can 'walk' the object hierarchy of router1 starting with the system subtree. This time, the community used is sEKr33t--. The output shows us the name of the vendor (Cisco), version of the operating system (IOS 11.2.8), the uptime (timeticks), as well as the person responsible and the location of the router.