OUSPG

[This page is CSS2 enabled. Your browser might not fully support it]

PROTOS Test-Suite: c06-snmpv1

$RCSfile: index.html,v $ $Revision: 1.141 $ $Date: 2002/10/17 18:58:44 $

Permission is hereby granted for quoting, reprinting and redistributing
this document, provided that a link to this document is given, and all
changes made are clearly separated from the original text.

ABSTRACT

The Simple Network Management Protocol (SNMP) enables monitoring and configuration of network nodes. The venerable SNMP is almost omni-present amongst a wide variety networked devices ranging from Internet gateways to information appliances. The SNMP version one (SNMPv1) was chosen as the subject protocol for vulnerability assessment through syntax testing and test-suite creation. A survey of the related standards was made. Test-material was prepared and tests were carried out against a sample set of existing implementations. Results were gathered and reported. Many of the implementations available for evaluation failed to perform in a robust manner under test. Some failures had information security implications, and should be considered as vulnerabilities. In order to achieve a robustness baseline for SNMPv1 products this test-material should be adopted for their evaluation and development.

Table of Contents

• ABSTRACT
• Table of Contents
• Introduction
• Analysis
• Design
  • Standard Survey
  • Subject Survey
  • Injection Vector Survey
    • About SNMP Architecture
  • Specifications Design
  • Design of Exceptional Elements
    • Exceptional Element Categories
  • Design of Test-Material
    • Req-App
    • Req-Enc
    • Trap-App
    • Trap-Enc
    • Test-Material Default Values
• Injection
• Semantic Rules
• Instrumentation
• Implementation
  • Results from the Test-Runs
    • Test-Result Definitions
    • Test-Results by Test-Groups
    • Test-Results Summary
  • Verification via Exploits
• Test-Material Package
  • Package Information
  • Licence and Copyright
  • Usage
    • Using with Java
    • Using without Java
  • Download
    • Request Material
    • Trap Material
  • Notes
• Conclusions
  • Acknowledgments
• Vulnerability Management
  • Prior Public Vulnerabilities
  • The Vulnerability Process
  • Advisories and Vendor Statements
• References
• Appendix A: Guidelines for Securing SNMP
• Appendix B: Related Test-Suites

Introduction

This test-suite is a byproduct of the "PROTOS - Security Testing of Protocol Implementations" project. Important: Background, goals, limitations, terminology and licensing for this test-suite release are explained in the "Test-suite releases in Theory and Practice" document.

This test-suite covers a limited set of information security and robustness related implementation errors for a subset of the chosen protocol. The subject protocol and the chosen subset of it are illustrated in the "Analysis" section below.

Analysis

"SNMP is a communication protocol that has gained widespread acceptance since 1993 as a method of managing TCP/IP works, including individual network devices, and devices in aggregate. SNMP was developed by the IETF (Internet Engineering Task Force), and is applicable to any TCP/IP network, as well as other types of networks." - Open Directory Project [1]

"The Internet Activities Board recommends that all IP and TCP implementations be network manageable." - RFC1157 [2]

The purpose of this test-suite is to evaluate implementation level security and robustness of Simple Network Management Protocol (SNMP) implementations. The factors behind choosing SNMP included:

• SNMP is widely adopted for managing IP networks, including individual network devices, and devices in aggregate. In other words - there are plenty of different implementations and a myriad of installations. Moreover, even if the SNMP is not in active use inside a network, it may be lying dormant on individual devices by virtue of being included in default configurations.
• A SNMP manageable devices may be critical for the network infrastructure. Even a denial-of-service attack against such of a device may have serious implications. Therefore locating and fixing common implementation errors should be encouraged.
• Robustness problems in decoding exceptional BER encoding may lead to situation where application level authentication based access control is ineffective since errors may reside in code that will be involved in parsing the packets before authentication takes place.
• Since SNMP has been around for a relatively long time implementations should have had time to mature, making them more robust against implementation type errors. Evaluating such mature products should provide us useful feedback on the current state of implementation level robustness in general.

In this test-suite, the focus was set on the certain protocol data units (PDUs), namely requests (GetRequest, GetNextRequest and SetRequest) and traps. The protocol version one (SNMPv1) was chosen. Rationale behind these selections:

• SNMP agents and trap-aware SNMP managers are by design ready to accept incoming requests and traps without prior session setup. These expose a natural attack vector that should be scrutinized with top priority.
• All SNMP implementations must support SNMPv1. Moreover, newer versions of the protocol (SNMPv2[p,c,u] and SNMPv3) should be considered as protocols of their own due to the changes in the management paradigm.
• SNMPv1 has a less complicated structure in comparison to the newer versions. This enables us to concentrate on other things than the protocol specification. Thus, we could expect a test-suite of good quality and coverage.
• Although SNMPv1 is a venerable protocol, it has no popular and public syntax testing material aimed against robustness problems.
• Due the widespread nature of SNMPv1, there are plenty of implementations by several vendors available for testing, including equipment that are a critical part of the core Internet infrastructure.

In order to understand the typical deployment scenarios of SNMPv1, some guidelines for securing specific SNMP implementations were reviewed (see Appendix A). Typical recommendations are summarized below in no particular order:

• A. Choose non-default community names.
• B. Apply perimeter filtering to SNMP traffic.
• C. Apply SNMP device based network access control to filter the traffic.
• D. Isolate SNMP into a separate management VLAN.
• E. Disable the SNMP functionality if it is not needed.

Assuming recommendation (A) to be the most widely adopted measure, the impact of new potential SNMPv1 vulnerabilities can be roughly categorised based on the dependency on the need-to-know the chosen community names (the authentication scheme). A vulnerability can occur:

• 1. independently of the community name (greatest impact)
• 2. with a known read-only community name
• 3. with a known read-write community name (smallest impact)

The second category was chosen as the initial test-strategy. If a vulnerability is discovered by using a known read-only community name, then it will be verified in context where a correct community name is unknown. Many SNMPv1 implementations appear to use default community names that are well-known, such as 'public'. This fact increases the impact of vulnerabilities in the last two categories.

A survey of pre-existing test-suites was made (see Appendix B). None of the identified test-suites were found to be robustness related, and thus do not contribute in this context.

Design

Standard Survey

The available standards specifying the selected protocol have to be studied, and analysed. The relevant protocol specifications are listed in the table below.

Only the relevant SNMP specifications are listed. Several specifications regarding newer SNMP versions and extensions are left out but are available from IETF. [3]

For further study, a selection of practical material on SNMPv1 and related issues is given below:

• comp.protocols.snmp SNMP FAQ [4]
• TCP/IP Illustrated, Volume 1 by Stevens [5]
• ASN.1 Complete by Prof. Larmouth [6]

Subject Survey

A survey of available implementations is conducted. This should include a diverse selection of implementations in order to gain a better insight into the applications implementing the protocol, and to give a hint of the impact of the potential vulnerabilities. Typically, not all implementations are available for testing, and thus cannot be tested by the project personnel within this test-suite prerelease phase.

No sample list of implementations is presented herein. A large number of vendors include SNMPv1 support in their products for either manager or agent functionality. A list of vendors with SNMPv1 enabled products may include at least 3Com, Alcatel, Amber Networks, Arbor, Banyan Networks, Canon, Cisco, Compaq, Computer Associates, D-Link, Dell, Digi, Ericsson, Extreme networks, F5, Foundry, Fujitsu Siemens, HP, Hitachi, IBM, ICL, Intel, Juniper Networks, Lantronix, Laurel, Lotus Lucent, Marconi-Fore, Microsoft, Multitech, NET-SNMP, NetGear, Nokia, Nortel, Novell, SMC, Shiva, Siemens, Sumimoto, Sun Microsystems, Telebit, Teledat, Windriver, Xerox, Xylan, Zyxel and many others.

Myriad of products with built-in SNMPv1 support include different models of:

• managed network building blocks: bridges, hubs, routers, switches, media converters, UPSes, WLAN access points
• managed network access equipment: cable modems, xDSL equipment, remote access servers
• security products: firewalls, anti-virus frameworks, network analyzers
• networked printers/copiers, networked cameras, networked image-scanners
• managed software components: databases, backup software
• network management frameworks
• operating systems
• networked instruments: oscilloscopes, medical imaging units
• industrial automation equipment: manufacturing, processing ...

Some specific SNMP implementations and related information may be found from the following resources:

• The Simpleweb [7]
• SNMPLink [8]
• SNMPWorld [9]
• comp.protocols.snmp SNMP FAQ [4]

A subset of the implementations was chosen as a sample set to be tested during the test-suite creation and pre-release phases. Most likely reasons for omission of a specific product from the sample set include:

• no evaluation copy of product was available
• or evaluation copy had a restrictive licence prohibiting evaluation
• or we were not aware of the product

Injection Vector Survey

The injection vector survey, or delivery vector survey, analyses the different methods of delivering the test-cases to the implementations under test (IUT). Often, there are several methods of injection and one test-suite cannot cover them all, or might miss some vectors not available in all implementations.

The core specification(s) of the SNMPv1 protocol indicate that UDP over IP is used to transfer SNMPv1 protocol data units (PDU) although the mechanisms of the SNMP are generally suitable for use with a wide variety of transport services. For example RFC1089, RFC1161 and RFC1298 describe the means of transferring SNMPv1 messages over protocols other than UDP over IP. However the UDP over IP is the most used scheme. Hence, the selected UDP delivery vector should provide successful injection of test-cases to all chosen implementations.

About SNMP Architecture

The SNMP architecture is illustrated in the figure below. The figure identifies two major roles (Manager and Agent) and two communication channels (UDP port 161 and UDP port 162).

Figure: Simplified SNMP architecture

SNMP managers can be anything from monolithic GUI based management frameworks to individual console applications that communicate over network using SNMPv1 protocol. There are also specific trap listeners for logging and dispatching incoming trap event messages.

SNMP agents can either work alone or with sub-agents. When sub-agents are present, the agent that listens for SNMPv1 requests from managers is called a master agent. The master agent forwards a received request to corresponding sub-agents. This communication may be done using a special sub-agent protocol. If the sub-agent does not respond directly to the requester, then the master agent may be involved in converting the response into SNMPv1 and delivering it to the manager. The master agent may be completely transparent to the manager.

"A master agent provides access to SNMP variables that may be provided by one or more subagents. The master agent usually uses a subagent protocol (AgentX, DPI, SMUX, EMANATE, ...) to interact with the subagents. One of the key features of such an extensible agent is that it is complete transparent to the manager." - SNMP FAQ [4]

A SNMP proxy agent is an element capable of acting as gateway to the other management agents. Proxies could be used to map different management protocols and to pass through an application level firewall.

"The current definition of a proxy SNMP agent is an agent which acts like a gateway to other SNMP agents. This can be useful in order to pass firewalls or to map SNMP protocol versions. Such a proxy is however not transparent to the manager since the manager usually has to select special parameters to address the target agent through the proxy." - SNMP FAQ [4]

Specifications Design

Protocol data unit specifications are used as a basis for generating the test-cases. Starting point for the design of the test-suite is to acquire or create a machine-readable representation of the protocol specification. The test-tool developed in this project uses a custom dialect of BNF (Backus-Naur Form). The BNF is capable of describing context-free syntax of a specification, but is not usually enough for the PDU generation. The specification is completed by semantic rules which semantically extend the BNF and communication rules which provide communication channels with external components. Rules are implemented in Java.

In this test-suite, a BNF presentation of SNMPv1 packet types was needed. Since SNMPv1 specification uses ASN.1 notation, the relevant ASN.1 specifications were manually converted into BNF.

Design of Exceptional Elements

An exceptional element is a piece of data designed to provoke undesired behavior of the subject implementation. A single test-case contains one or more exceptional elements. An exceptional element can be illegal according to protocol specification, but often it is legal or in the hazy region between legal and illegal constructs. In a nutshell, an exceptional element is an input that might not have been considered properly when implementing the software.

ASN.1 Basic Encoding Rules (BER) are used along the SNMPv1 specification to resolve the actual representation of the PDUs. Namely constructed types, field lengths, integers, strings and object identifiers are encoded using BER.

The application logic of a SNMPv1 agent receives data objects from a BER decoder, acts according the requests, and replies to the manager though a BER encoder. A SNMPv1 manager sends requests and listens for replies and trap messages. One might suppose that the use of ASN.1/BER protects the application logic from malformed input. However, any exceptional input which is correctly encoded will pass to the application logic.

Exceptional Element Categories

The following table lists the categories of the exceptional elements designed for the test-material:

Legend:

• B: Bit pattern exceptions
• E: BER encoding exceptions
• F: Format string exceptions
• I: Integer value exceptions
• M: Missing symbol exceptions
• O: Overflow exceptions

In "Encoding Exceptions" (letter E), exceptional ASN.1/BER elements are exercised. The purpose is to test the robustness of the BER decoder of the tested SNMPv1 implementation.

In "Application Exceptions" (other letters), correctly formatted ASN.1/BER elements contain exceptional data objects. The purpose is to test the robustness of the application logic of the SNMPv1 implementation.

Design of Test-Material

The tests are divided into four separate test-material packages. Each test-material package consists of a certain amount of test-cases. The test-cases are organized into test-groups so that similar kind of cases reside in a same group. Details for each package are presented below.

Req-App

10601 test-cases: GetRequest, GetNextRequest and SetRequest PDUs with application exceptions

Legend:

• Name column presents the tag-names of the test-groups. Tags map in some extent to field names in SNMPv1 PDUs defined in RFC1157. Tags can be used to follow which parts of the PDU are being tested, and how. For example, get-req-communityname-overflow indicates that exceptional elements aiming to reveal buffer overflow vulnerabilities are inserted to the Community-field of the GetRequest-PDU.
• Category column describes which exceptional element categories are integrated in the test-group. Ie. category O-01 in above example is deduced from this column.
• "Test-cases" and "First index #" columns describe how many test-cases belong to the test-group, describing the first test-case number, and the number of cases from there on.

Req-Enc

18915 test-cases: GetRequest, GetNextRequest and SetRequest PDUs with encoding exceptions

Legend: [see first test-group table above]

Trap-App

15323 test-cases: Trap PDUs with application exceptions

Legend: [see first test-group table above]

Trap-Enc

8777 test-cases: Trap PDUs with encoding exceptions

Legend: [see first test-group table above]

Test-Material Default Values

All test-cases have been initialized with default values listed below. One or more of the listed values are altered when exceptional elements are applied to the PDU.

Default values used in req-app and req-enc:

• Version: 0
• Community: "public"
• PDU-Type: GetRequest | GetNextRequest | SetRequest
• RequestID: test-case index
• ErrorStatus: 0
• ErrorIndex: 0
• Single VarBind:
  • ObjectName: sys.SysName (1.3.6.1.2.1.1.5.0)
  • ObjectSyntax: empty (GetRequest, GetNextRequest) | 'c06-snmpv1' (SetRequest)

Default values used in trap-app and trap-enc:

• Version: 0
• Community: "public"
• PDU-Type: Trap
• Enterprise: unix.agents.fourBSD-isode.21 (1.3.6.1.4.1.4.1.2.21)
• Agent-addr: 127.0.0.1
• Generic-trap: ColdStart (0x00)
• Specific-trap: 0x00
• Time-stamp: test-case index
• Single VarBind:
  • ObjectName: if.ifNumber (1.3.6.1.2.1.2.1.0)
  • ObjectSyntax: 0x21

Injection

The test-tool provides communication rules for test-case injection. SNMPv1 PDUs can be injected using a simple UDP injector. Optionally, responses from the subject can be monitored.

Semantic Rules

The test-tool provides semantic rules as method for augmenting the (already extended) BNF specification.

SNMPv1 requires use of the basic encoding rules (BER) for formatting octets sent over the UDP over IP connection. BER is a simple encoding method and can be modeled with BNF except for the length fields. Semantic rules for encoding/decoding BER Integers and Object-Identifiers were developed for this test-suite.

Instrumentation

With instrumentation on the target platform we are able to monitor for undesired behavior of the subject implementation. Typically this manifests as exceptions or signals such as 'access violation' or 'segmentation fault'. Unfortunately, the modern trend of abusing the try-catch -type of constructs easily masks the exceptions generated by stack and memory corruption. Catching these hidden exceptions relies on the debugging skills of the developers themselves.

Zero-case instrumentation will be bundled with the test-material. In this rather crude method, a valid PDU (zero-case) that should result in a valid reply is sent to the subject between real test-cases until a response is received. Hence, if no response from the subject is detected, it has failed. This method is especially convenient when testing black-box hardware implementations. Unfortunately, zero-case instrumentation is not available with Trap-PDUs since implementations should never reply to the received traps.

Implementation

Test-runs were conducted against the chosen set of sample implementations. Specifications, exceptional elements, semantic rules, injectors and instrumentation were integrated as a test-tool configuration to enable automatic execution of the tests.

Results from the Test-Runs

Results from the test-runs are summarised herein. Tables below represent the observations from feeding the test-material against the chosen subject software. Product names of the actual subjects are omitted to protect the innocent. Results are presented in a tabular form with test-cases divided into test-groups based on the exceptional element types utilised and PDU fields under examination.

Each failed test-case represents at minimum a denial of service type chance of exploiting the found vulnerability. In most cases, they represent memory corruption, stack corruption or other fatal error conditions. Some of these may lead exposure to typical buffer overflow exploits, allowing running of arbitrary code or modification of the target system.

The recommendations for securing SNMP implementations presented in the Analysis section were tried against each sample implementation when suitable.

Changing the community name worked only for some implementations, but not especially for those which had problems with exceptional community names. Network access control was soon discovered to be insufficient since UDP source address can be easily spoofed. Disabling the SNMP functionality worked usually when there was a possibility to do so. However, there was one implementation that continued to receive SNMP packets even after SNMP was disabled. It did not respond to valid SNMP requests, but crashed when certain test-cases were injected. All sample implementations accepted SNMPv1 packets sent to the network broadcast address, this is most likely due to nature of the typical bind() usage with INADDR_ANY address.

Test-Result Definitions

In this test-suite, the 'failed' status is granted if any of the following criteria are met and a single test-case can be identified to be responsible of it:

• A fatal failure is triggered in a device causing it to stop functioning normally
• A SNMP process or a device crashes or hangs and needs to be restarted manually
• A SNMP process or a device crashes and restarts automatically
• A SNMP process consumes almost all CPU and/or memory resources for an exceptionally long or indefinite time

If no single test-case can be identified but similar effects are observed, the status is 'inconclusive'.

If the 'failed' status happens to be independent of SNMP community names, it is upgraded to 'failed unconditionally'. This is the worst status that can be given.

In some cases, the subject gets corrupted so badly or is fundamentally so instable that there is no way to collect accurate test-results for the whole test-run. The untested regions are marked as 'unknown'.

Otherwise, the status is 'passed'.

Test-Results by Test-Groups

These tables show how effective different test-groups were in the test-runs. A test-group is marked failed if any single case or combination of cases cause the subject to fail. Note that if a subject fails in a format string (fmtstring) test-group, the failure may be triggered by a very long format string causing an overflow condition. Should implementation have failed format string category, but not previous overflow category, then implementation is more or very likely to contain real format string type of vulnerability.

Legend:

• nnn: Each different test-run (tr-nnn) represents a different tested implementation.
• X: Verdict is failed
• U: Verdict is failed unconditionally (no need-to-know a valid community name)
• I: Verdict is inconclusive
• -: Verdict is passed

Legend: [see first result table above]

Legend: [see first result table above]

Legend: [see first result table above]

Test-Results Summary

The results are further summarised in the tables below.

Legend:

• N: We were unable to determine the exact number of failures. See the more detailed tables above.

Legend: [see first summary table above]

Legend: [see first summary table above]

Legend: [see first summary table above]

Verification via Exploits

To support the vulnerability reporting process, typically one exploit per implementation is refined and included in the respective vulnerability report. The exploit is only intended for demonstration purposes and is harmless as it is. Simplest of them only executes some harmless commands in the target system, typically with the privileges of the vulnerable process. Some only provide a demonstration by causing a Denial of Service (DoS) against the software.

Buffer overflow exploits allowing execution of arbitrary code were demonstrated against:

• One SNMP master agent bundled in an embedded firewall and VPN appliance
• Two SNMP master agents bundled as part of the operating systems in question
• One SNMP trap listener bundled as part of the operating system in question
• Two add-on trap listeners available as parts of SNMP management frameworks

In the initial set of the tested products, denial of service was demonstrated for the remaining master agents (three network devices) and one trap listener (management framework) identified as vulnerable.

Test-Material Package

Package Information

The test-material is distributed as four JAR packages, two for Request-PDUs (GetRequest, GetNextRequest and SetRequest) and two for Trap-PDUs. Of the two JAR packages for given PDU type one contains the application part and the other the BER encoding part of test-cases. Each package comprises of the following elements:

• Test-cases (PDUs), located in testcases/ directory
• Java code (source and compiled) for feeding the test-cases against the system under test
• LICENSE.TXT - GNU General Public License (GPL) version 2
• README.TXT - Short instructions

Licence and Copyright

The test-material is licensed under GNU General Public License (GPL) version 2, at no charge. This is done in order to ensure that vendors and their customers may freely utilise the test-material. Standard GPL terms for no warranty and no liability apply.

We recommend some additional guidelines, although these do not restrict the test-material licence. These guidelines can be found from the "test-suite releases in Theory and Practice" document.

Usage

A prerequisite for using the test-material is a properly configured SNMPv1 implementation, preferably not in an open network.

The test-material can be used either with the bundled injection code [Using with Java] or with an external injector [Using single test-cases].

Using with Java

Java Runtime is a prerequisite for running the bundled Java code. This package has been tested on Java 2 Platform, Standard Edition (J2SE ). [10]

Usage examples for the injection code bundled in the JAR packages:

java -jar c06-snmpv1-req-app-r1.jar -help

This command displays the built-in help for the available command line options. Options such as selecting the zero-case instrument, a specific range of test-cases, showing the reply from subject or non-standard destination port are high-lighted therein.

java -jar c06-snmpv1-req-app-r1.jar -host hostname -single <index> -showreply

Send the req-app test-case index into SNMP server hostname port 161 and show reply from the server (if any). Please note that -showreply is not relevant with SNMP traps.

java -jar c06-snmpv1-req-app-r1.jar -host hostname -delay 1000

Send all req-app test-cases into SNMP server hostname port 161 with a delay of 1000 milliseconds between each case.

java -jar c06-snmpv1-req-app-r1.jar -host hostname -zerocase

Run all req-app test-cases into SNMP server hostname port 161. A valid zero-case (test-case# 0) is injected between the real test-cases and a reply to it is awaited for. Please note that -zerocase switch works only with Request-PDUs, SNMPv1 trap handling does not involve responses.

Using without Java

The test-cases (PDUs) are in raw binary format and can be used by any suitable delivery software, such as nc (netcat). The individual test-cases can be extracted from the JAR package with tools such as unzip, Winzip or jar. Refer to the manual pages and product documentation of the respective tools for additional information.

Download

Request Material

These JAR packages contain the req-app and req-enc test-material and the corresponding PGP signatures.

• c06-snmpv1-req-app-r1.jar (req-app test-material)
• c06-snmpv1-req-app-r1.jar.asc (req-app detached PGP signature)
• c06-snmpv1-req-enc-r1.jar (req-enc test-material)
• c06-snmpv1-req-enc-r1.jar.asc (req-enc detached PGP signature)

Trap Material

These JAR packages contain the trap-app and trap-enc test-material and the corresponding PGP signatures.

• c06-snmpv1-trap-app-r1.jar (trap-app test-material)
• c06-snmpv1-trap-app-r1.jar.asc (trap-app detached PGP signature)
• c06-snmpv1-trap-enc-r1.jar (trap-enc test-material)
• c06-snmpv1-trap-enc-r1.jar.asc (trap-enc detached PGP signature)

Notes

Be sure to check which PDU types the subject accepts. Zero-case instrument requires that the subject has a properly configured 'public' SNMP read community. Otherwise the subject will not respond to valid test-cases. However, if you want to test a subject with a different community, the default zero-case (test-case# 0) can be replaced. Using a hex editor, 'public' can be changed to 'foobar' and because they have the same length, the packet validity is preserved. Remember that zero-case instrumentation works only with Request-PDU packages, because SNMP traps are never replied to.

For the best possible replication of results gathered by us, request JAR test-cases should be ran using switches -zerocase and -showreply. For the trap JARs no additional switches except for the -host should be used. This ensures that timeouts and configuration options match as far as possible those used in our test-runs. As mentioned earlier, community name 'public' was used as read community and no write community was defined.

Sending test-cases with different timeouts, in different order and so on may reveal error modes we did not notice. Also, setting write community to public or read community to something other than public are likely to have significant effect on results and possible error modes observed.

Conclusions

The initial results from the c06-snmpv1 tests indicate that implementation errors plague several SNMP products. None from the sample of twelve implementations survived the test-material. This is most alarming since SNMPv1 is widely used in critical parts of network infrastructure.

Attempts to secure the sample implementations from the found vulnerabilities produced various results. Applying device based access control to SNMP traffic was mostly useless since spoofing the UDP source address is simple. All sample implementations by default accepted SNMP packets sent to the network broadcast address, and this lessens the effort needed to exploit the vulnerabilities. A potential attacker does not need to know the actual IP-addresses of his targets and can in worst case use a single broadcast packet to compromise a whole network without ever having to find out a valid SNMP community name. In some cases, SNMP could not be fully disabled and there was no other way to secure an implementation than to plug it off the network.

Since the test-material can discover only a fraction of potential implementation errors, it is likely that we have simply touched the tip of the iceberg. We hope that a wide adoption of this test-suite will raise the overall quality of SNMP products and will help implementors to fix also those vulnerabilities not directly addressed by it.

Acknowledgments

We wish to express our gratitude to individual vendors who worked with us to protect their customers. We are in debt to Sonera Corporation for providing us facilities and support in determing the impact of the test-suite. Last, but not least, we are grateful to CERT/CC for their patient help, advice and active role during the vulnerability process. We admire CERT/CC's ability and sacrifice in handling the complexity of the issue, number of the vendors involved and the resulting flood of communication during extended time-frame spanning several months.

Vulnerability Management

Prior Public Vulnerabilities

The most common sources for vulnerability information and exploits were covered and cross checked for potential and already known vulnerabilities in the implementations of the chosen protocol. Typical sources for finding out about existing vulnerabilities are databases and mailing-lists. Search-engines may also reveal information on past vulnerabilities.

The Vulnerability Process

During the prerelease phase all verified vulnerabilities were reported to the respective vendors. The vulnerability reports were tracked by the CERT/CC in role of an independent coordinator and advisor. [11] Due to potentially large number of vendors affected, an attempt to establish a channel for discussion and test-material distribution was made with CERT/CC.

Advisories and Vendor Statements

Vendor statements or security advisories issued in order to address the vulnerabilities uncovered by this test-suite are collected. Advisories that we are aware of are listed here-in:

• [CERT/CC 2002-02-12] CERT® Advisory CA-2002-03 Multiple Vulnerabilities in Many Implementations of the Simple Network Management Protocol (SNMP)

References

[1]

"Open Directory Project : Top : Computers : Internet : Protocols". Open directory project. http://dmoz.org/Computers/Internet/Protocols/desc.html.

[2]

Case, J; Fedor, M; Schoffstall, M & Davin J. (1990). "A Simple Network Management Protocol (SNMP)". The Internet Engineering Task Force. http://www.ietf.org/rfc/rfc1157.txt.

[3]

"The Internet Engineering Task Force". http://www.ietf.org/.

[4]

"comp.protocols.snmp SNMP FAQ". http://www.faqs.org/faqs/snmp-faq/.

[5]

Stevens, Richard W. TCP/IP Illustrated, Volume 1. (1994). Addison-Wesley. ISBN: 0-201-63346-9.

[6]

Larmouth, John. ASN.1 Complete. (1999). Morgan Kaufmann. http://www.oss.com/asn1/larmouth.html. ISBN: 0-12233-435-3.

[7]

"The SimpleWeb". http://www.simpleweb.org/.

[8]

"SNMPLink.org". http://www.snmplink.org/.

[9]

"SNMPWorld". http://silver.he.net/~rrg/snmpworld.htm.

[10]

"Java 2 Platform, Standard Edition (J2SE)". http://java.sun.com/j2se/1.3/.

[11]

"CERT/CC". http://www.cert.org/.

Appendix A: Guidelines for Securing SNMP

As part of the analysis for the PROTOS c06-snmpv1 test-suite, some guidelines for securing specific SNMP implementations were reviewed.

Securing SNMP on Solaris

http://ist.uwaterloo.ca/security/howto/2000-10-04/

Securing SNMP in Windows

http://www.sans.org/infosecFAQ/incident/SNMP.htm

Securing your Cisco Router when using SNMP

http://www.sans.org/infosecFAQ/netdevices/router.htm

SNMP - simple management tool for hackers?

http://www.nwfusion.com/newsletters/sec/1004sec1.html

Windows 2000, SNMP and Security

http://www.securityfocus.com/focus/microsoft/2k/snmp.html

Appendix B: Related Test-Suites

A survey of other existing test-suites related to SNMP was conducted. The found test-suites focused on rather semantical issues, with no or only some syntax testing material.

http://www.iwl.com

"InterWorking Labs provides SilverCreek(R), the SNMP Test-Suite, for software engineers to find and fix bugs in their SNMP agent implementations. With nearly 1,000 tests available for SNMPv1, v2, v3, and semantic tests for RMON1, RMON2, and the Printer MIB, InterWorking Labs has revolutionised the process of testing network products."

http://www.smplsft.com/stest.html

"SimpleTester is an easy to use test tool that automatically tests SNMPv1, SNMPv2C and SNMPv3 agents. Using this tool you can exhaustively test agents implementing standard and enterprise specific MIBs within minutes. Over 800 semantic validation tests for popular MIBs like MIB-II, mini-RMON and SNMPv3 are included with source code. Utilities like MIB browser, Trap Checker and Script Generator, along with scripting support for Telnet and Serial I/O is also present."

[This page is CSS2 enabled. Your browser might not fully support it]