Secure Your Network
Vulnerabilities have been found in the authentication code in multiple implementations of SNMPv3 including NetSNMP, SNMP Research, and many products derived from these reference implementations.
The vulnerabilities in the implementations are slightly different but both allow a sender to create certain malformed packets which will be accepted as authentic by the receiver even though they are not authentic and thereby allow an interloper to masquerade as another principal.
The vulnerability applies equally to use of either MD5 or SHA-1.
This vulnerability is present in multiple products including those of SNMP Research.
This vulnerability is present in all SNMP Research products which support SNMPv3 up through and including Release 16.1, i.e., the vulnerability was present in SNMP Research product Releases 15.1, 15.2, 15.3, 15.4, and 16.1, as well as products derived from those code bases unless upgraded, (please see the next paragraph).
SNMP Research product Release 16.2 and subsequent releases are believed to not be subject to this vulnerability. SNMP Research product Release 16.2 became generally available in late 2006 and all SNMP Research customers with support agreements should have received product distributions that are not subject to this vulnerability in December 2006 or January 2007. SNMP Research products shipped after that time are not believed to be subject to this vulnerability.
In SNMPv3, the authentication subsystem is responsible for protecting against multiple threats:
Modification of Information,
Masquerade, and
Message Stream Modification
This vulnerability potentially compromises the protections against each of the above threats.
The vulnerability is in the implementations. There are no known problems with the protocol design or specifications in this regard.
It is suggested that users upgrade to current versions of the software which do not have these implementation problems and the resulting vulnerabilities.
A short-term workaround for users who are unable to upgrade in a timely fashion is to modify their configuration data to enable the SNMPv3 privacy subsystem (if it is not already in use), i.e., to encrypt the SNMPv3 traffic using a secret, private key.
By so doing, it is believed that it will not be computationally feasible for interlopers to "forge" valid packets without knowledge of the secret encryption key, i.e., such packets will be dropped at the receiver, thereby somewhat mitigating the problem by thwarting exploitation of the vulnerability.
However, while this workaround provides for data origin authentication of the payload of the message, and thereby defends against the masquerade threat (provided that secret encryption key remains known only to legitimate senders and receivers), it does not protect against the two other threats identified above. In particular, the message headers are not protected against the modification of information threat. The message timeliness indicators, which are in the message headers, are potentially subject to manipulation by an interloper, thereby enabling replay attacks (message stream modification threat). An interloper can sucessfully replay valid packets that have been captured since the encryption key(s) in use were most recently changed.
Therefore, enabling encryption should be viewed as a short-term mitigation strategy that is better than doing nothing but not as good as the recommended remdiation strategy.
These vulnerabilities were first identified by Dr. Tom Dunigan of the University of Tennessee.
Specifications:
Please see RFCs 3410 and 3414.
Technical Support:
support@snmp.com
+1 865 579 3311