Original Publication Date: February 13, 2002

(Accompanying <a
href="http://www.cert.org/advisories/CA-2002-03.html">CERT 
advisory CA-2002-03</a>)
<br>

<!-- begin index -->
<ol>
<li><a href="#1">What is SNMP?</a>
<li><a href="#2">How is SNMP vulnerable?</a>
<li><a href="#3">Is our network or system in danger of attack?</a>
<li><a href="#4">What can happen if we are attacked?</a>
<li><a href="#5">How can we protect our network or system?</a>
<li><a href="#6">Are there any alternatives to using SNMP?</a>
<li><a href="#7">Do these vulnerabilities affect home users?</a>
<li><a href="#8">What are managers and agents?</a>
<li><a href="#9">What is a community string and how is it used?</a>
<li><a href="#10">What protocols/ports does SNMP use?</a>
<li><a href="#11">Where can I find the specifications for 
SNMP?</a>
<li><a href="#12">Where can I find additional information about 
SNMP?</a>
<li><a href="#13">Has the CERT/CC received any reports of SNMP 
scanning?</a>
<li><a href="#14">I have detected scanning of my network or systems
for SNMP. Should I report that to the CERT/CC?</a>
<li><a href="#15">Has the CERT/CC received any reports of exploitation
of these vulnerabilities?</a>
<li><a href="#16">An intruder has exploited these SNMP vulnerabilities
on my system. What should I do?</a>
<li><a href="#17">I am not a vendor, but I use or otherwise have
first-hand knowledge of an SNMP product that is vulnerable, but it is
not on the CERT/CC's list. Should I report that to the CERT/CC?</a>
<li><a href="#18">Our company manufactures a product that uses SNMP,
and we think it might be vulnerable, but we are not sure. How can we
get more information on these vulnerabilities?</a>
<li><a href="#19">Our company manufactures a product that uses SNMP,
and we know it to be affected by these vulnerabilities, but we are not
listed in any of your vendor statements. How can we get added to your
list of vendors?</a>
<li><a href="#20">Our company manufactures a product that uses SNMP,
but we know it is not affected by these vulnerabilities. Nonetheless,
we are being swamped with calls to our help desk about this issue. We
are not currently listed in any of your vendor statements, but we'd
like to be. How can we get added to your list of vendors?</a>
<li><a href="#21">Who is OUSPG?</a>
</ol>

<!-- end index -->

<hr>

<ol>
<a name="1"></a>
<li><b>What is SNMP?</b>
<blockquote>
<p>
The Simple Network Management Protocol (SNMP) is the most popular 
protocol in use to manage networked devices. SNMP was designed in the 
late 80's to facilitate the exchange of management information between 
networked devices, operating at the application layer of the ISO/OSI 
model. The SNMP protocol enables network and system administrators to 
remotely monitor and configure devices on the network (devices such as 
switches and routers). Software and firmware products designed for 
networks often make use of the SNMP protocol. Support for SNMP is 
available on a multitude of systems, including, but not limited to, 
<br><br>
<ul type="disc">
<li>Core Network Devices (Routers, Switches, Hubs, Bridges, and 
Wireless Network Access Points) 
<li>Operating systems (on nearly all architectures)
<li>Consumer Broadband Network Devices (Cable Modems and DSL 
Modems) 
<li>Consumer Electronic Devices (Cameras and Image Scanners) 
<li>Networked Office Equipment (Printers, Copiers, and FAX 
Machines) 
<li>Network and Systems Management/Diagnostic Frameworks (Network 
Sniffers and Network Analyzers) 
<li>Uninterruptible Power Supplies (UPS)
<li>Networked Medical Equipment (Imaging Units and Oscilloscopes) 
<li>Manufacturing and Processing Equipment 
</ul>
</p>
</blockquote>

<a name="2"></a> 
<li><b>How is SNMP vulnerable?</b> <blockquote>

<p>
The vulnerabilities affect both manager and agent software (see "<a
href="#8">What are managers and agents?</a>" for an explanation of
these terms). Vulnerabilities in both managers and agents include
denial-of-service conditions, format string vulnerabilities, and
buffer overflows. Some of the vulnerabilities do not require the
malicious packet to use the proper community string (see "<a
href="#9">What is a community string and how is it used?</a>").
Several of the more serious vulnerabilities allow the execution of
arbitrary code by a remote unauthenticated attacker. Refer to CERT
advisory CA-2002-03 (<a 
href="http://www.cert.org/advisories/CA-2002-03.html">http://www.cert.org/advisories/CA-2002-03.html</a>)
for a detailed description of the vulnerabilities.
</p>
</blockquote>

<a name="3"></a>
<li><b>Is our network or system in danger of attack?</b>
<blockquote><p>
Because of the relatively large number of products that support SNMP, 
it is unlikely that our list of affected products is comprehensive.  
Therefore, if you use products that support SNMP, we encourage you to 
first refer to CERT advisory CA-2002-03 
(<a 
href="http://www.cert.org/advisories/CA-2002-03.html">http://www.cert.org/advisories/CA-2002-03.html</a>)  
for a partial list 
of affected vendors and products.  If your vendor(s) are not listed 
you should contact them directly for more information to ensure your 
system is protected.  
</p>
</blockquote>

<a name="4"></a>
<li><b>What can happen if we are attacked?</b>
<blockquote><p>
Exploitation of these vulnerabilities can cause denial-of-service 
conditions, service interruptions, and in some cases will allow an 
attacker to gain unauthorized, privileged access to the affected 
device. Effects for some specific products can be found in CERT 
advisory CA-2002-03 
(<a 
href="http://www.cert.org/advisories/CA-2002-03.html">http://www.cert.org/advisories/CA-2002-03.html</a>).  
Contact your vendor(s) for additional information on other products.
</p>
</blockquote>



<a name="5"></a>
<li><b>How can we protect our network or system?</b>
<blockquote><p>
A number of steps can be taken to improve the security of systems 
relying on SNMP:
<br><br> 
<ul type="disc">
<li>Apply a patch from your vendor.
<li>Disable all nonessential SNMP software.
<li>Filter SNMP access to managed devices to ensure the traffic 
originates from known management systems.
<li>Filter SNMP services at your network perimeter (ingress/egress 
filtering).
<li>Change SNMP community strings from their defaults.
<li>Segregate network management traffic onto a separate network.
</ul>
<br>
Refer to CERT advisory CA-2002-03 
(<a 
href="http://www.cert.org/advisories/CA-2002-03.html">http://www.cert.org/advisories/CA-2002-03.html</a>) 
for more details and 
the most recent information regarding recommended solutions.
</p>
</blockquote>

<a name="6"></a>
<li><b>Are there any alternatives to using SNMP?</b>
<blockquote><p>
Although there aren't many practical alternatives to SNMP, there are 
steps that administrators can take to better secure their systems that 
use SNMP.  See the <a href="#5">"How can we protect our network or system?"</a> section 
above or refer to CERT Advisory CA-2002-03 
(<a 
href="http://www.cert.org/advisories/CA-2002-03.html">http://www.cert.org/advisories/CA-2002-03.html</a>) 
for more information.
</p>
</blockquote>

<a name="7"></a>
<li><b>Do these vulnerabilities affect home users?</b>
<blockquote><p>

Most home users are not directly affected by these vulnerabilities.  
However, home users with more advanced configurations may be at risk.  
If you use one or more of the following in your home system or 
network, additional steps might be necessary to ensure protection:
<br><br>
<ul type="disc">
<li>Microsoft Windows operating systems with SNMP services enabled
<li>advanced operating systems (e.g., 
Linux or other Unix operating systems)
<li>network-based router appliances
<li>network-based firewall appliances
<li>wireless Ethernet (802.11a/b) access points
</ul>
<br>
Note that in many cases SNMP services are not enabled by default, so 
merely using one or more of the products above does not mean that you 
are definitely vulnerable. Home users with one or more of the above 
technologies in use on their home networks are encouraged to refer to 
CERT advisory CA-2002-03 
(<a 
href="http://www.cert.org/advisories/CA-2002-03.html">http://www.cert.org/advisories/CA-2002-03.html</a>) 
for a partial list of 
affected vendors and products.  If your vendors are not listed you 
should contact them directly for more information to ensure your 
system is protected.  
</p>
</blockquote>

<a name="8"></a>
<li><b>What are managers and agents?</b>
<blockquote><p>
SNMP is built around the concept of "managers" and "agents."  Manager 
software (commonly installed on a network management system) makes 
requests to agent software running on a host or device to gather data 
on the operational status, configuration, or performance statistics of 
that system (polling).  Some agents allow configuration parameters to 
be changed by managers, while others provide read-only statistics and 
configuration information.  Additionally, agents can generate ad hoc 
messages to manager systems to inform them of unusual events (traps).
</p></blockquote>



<a name="9"></a>
<li><b>What is a community string and how is it used?</b>
<blockquote><p>
The community string (a.k.a. community name) provides a weak 
authentication mechanism to the SNMP protocol.  Agents can be 
configured to allow read-only, read-write, or no access to their 
parameters based on the community string in a request.  Community 
strings are passed in clear text in SNMP messages, so they can be 
easily sniffed and are therefore insufficient for authenticating 
legitimate manager requests.  
</p><p>
Note that many of the vulnerabilities described in CERT advisory 
CA-2002-03 (<a 
href="http://www.cert.org/advisories/CA-2002-03.html">http://www.cert.org/advisories/CA-2002-03.html</a>) 
do <b>not</b> require an attacker to know the configured community 
strings in order to exploit the vulnerability.
</p></blockquote>

<a name="10"></a>
<li><b>What protocols/ports does SNMP use?</b>
<blockquote><p>
SNMP uses 161/udp for general purpose (request/response) 
communications, and 162/udp for traps.  Additionally, the SNMP 
multiplexing protocol (smux, defined in RFC1227 
<a 
href="http://www.ietf.org/rfc/rfc1227.txt">http://www.ietf.org/rfc/rfc1227.txt</a>) uses 199/tcp.  Another SNMP 
extension, the AgentX protocol (RFC2741, 
<a 
href="http://www.ietf.org/rfc/rfc2741.txt">http://www.ietf.org/rfc/rfc2741.txt</a>) 
uses 705/tcp.
</p>
</blockquote>


<a name="11"></a>
<li><b>Where can I find the specifications for SNMP?</b>
<blockquote><p> 
The current SNMPv1 standard is defined in the Internet Engineering 
Task Force (IETF) STD0015 / RFC1157 
(<a 
href="http://www.ietf.org/rfc/rfc1157.txt">http://www.ietf.org/rfc/rfc1157.txt</a>).  
There are also a number of 
draft and proposed standards for SNMPv2 and SNMPv3.  Refer to IETF 
STD0001 / RFC3000 (<a 
href="http://www.ietf.org/rfc/rfc3000.txt">http://www.ietf.org/rfc/rfc3000.txt</a>) 
for the current status of the various SNMP-related RFCs. 
</p>
</blockquote>

<a name="12"></a>
<li><b>Where can I find additional information about SNMP?</b>
<blockquote><p>
The comp.protocols.snmp FAQ may be found at <br><br>

<a 
href="http://www.faqs.org/faqs/snmp-faq/part1/">http://www.faqs.org/faqs/snmp-faq/part1/</a> 
and<br> 
<a 
href="http://www.faqs.org/faqs/snmp-faq/part2/">http://www.faqs.org/faqs/snmp-faq/part2/</a><br>
<br>
There are a number of SNMP-related Working Groups in the "Operations 
and Management" area of the IETF (<a 
href="http://www.ietf.org/">http://www.ietf.org/</a>).
</p>
</blockquote>

<a name="13"></a>
<li><b>Has the CERT/CC received any reports of SNMP scanning?</b>
<blockquote><p>
As of 9:25 EST (UTC-0500) February 12, 2002, we have received reports of scanning for SNMP services related to these 
vulnerabilities and are working to verify.  New incident reports are 
being sent to the CERT/CC 
all the time, though, so you are encouraged to refer to our Current 
Activity page (<a 
href="http://www.cert.org/current/current_activity.html">http://www.cert.org/current/current_activity.html</a>) 
for the latest information on incident trends.
</p>
</blockquote> 

<a name="14"></a>
<li><b>I have detected scanning of my network or systems for SNMP.  
Should I 
report that to the CERT/CC?</b>
<blockquote>
<p>
If you have detected scanning for SNMP services on your network, you 
should first determine whether this scanning has led to a compromise 
or not.  You may wish to refer to our Intruder Detection Checklist 
(<a 
href="http://www.cert.org/tech_tips/intruder_detection_checklist.html">http://www.cert.org/tech_tips/intruder_detection_checklist.html</a>) 
for 
additional tips on determining whether a compromise has occurred.  
</p><p>
Once you are certain that no compromise has occurred and the impact 
was limited to scanning only, you are encouraged to report this 
activity to the CERT/CC using our Incident Reporting Form, available 
at <a 
href="http://www.cert.org/reporting/incident_form.txt">http://www.cert.org/reporting/incident_form.txt</a>.
</p><p>
Reporting scanning activity to the CERT/CC will help us better assist 
you, and allow us to relate ongoing intruder activities. This also 
provides us a better overview of trends in attack profiles and 
provides input for other CERT documents such as advisories and 
summaries. We prefer that Incident Reporting Forms be sent to us via 
email to <a href="mailto:cert@cert.org">cert@cert.org</a>. 
</p></blockquote>

<a name="15"></a>
<li><b>Has the CERT/CC received any reports of exploitation of these 
vulnerabilities? </b>
<blockquote><p>
As of 9:25 EST (UTC-0500) February 12, 2002, we have received reports of exploitation of SNMP services related to these 
vulnerabilities and are working to verify them.  New incident reports 
are being sent to the CERT/CC 
all the time, though, so you are encouraged to refer to our Current 
Activity page (<a 
href="http://www.cert.org/current/current_activity.html">http://www.cert.org/current/current_activity.html</a>) 
for the latest information on incident trends.
</p>
</blockquote> 


<a name="16"></a>
<li><b>An intruder has exploited these SNMP vulnerabilities on my 
system.  
What should I do?</b>
<blockquote>
<p>
As described in CERT advisory CA-2002-03 
(<a 
href="http://www.cert.org/advisories/CA-2002-03.html">http://www.cert.org/advisories/CA-2002-03.html</a>), 
exploitation of 
these SNMP vulnerabilities can cause denial-of-service conditions, 
service interruptions, and in some cases will allow an attacker to 
gain unauthorized, privileged access to the affected device(s).  
</p><p>
If you suspect that your system may have been compromised, you may 
wish to refer to our Intruder Detection Checklist 
(<a 
href="http://www.cert.org/tech_tips/intruder_detection_checklist.html">http://www.cert.org/tech_tips/intruder_detection_checklist.html</a>).  
Once you have confirmed that a compromise has occurred, please refer 
to our Steps for Recovering from a UNIX or NT System Compromise 
(<a 
href="http://www.cert.org/tech_tips/root_compromise.html">http://www.cert.org/tech_tips/root_compromise.html</a>) 
</p><p>
Regardless of whether the exploitation resulted in system compromise 
or denial-of-service, we would appreciate it if you would complete and 
return an Incident Reporting Form as this will help us better assist 
you, and allow us to relate ongoing intruder activities. This also 
provides us a better overview of trends in attack profiles and 
provides input for other CERT documents such as advisories and 
summaries. We prefer that Incident Reporting Forms be sent to us via 
email to cert@cert.org. The Incident Reporting Form is available from 
<a 
href="http://www.cert.org/reporting/incident_form.txt">http://www.cert.org/reporting/incident_form.txt</a>.
</p></blockquote>

<a name="17"></a>
<li><b>I am not a vendor, but I use or otherwise have first-hand 
knowledge of 
an SNMP product that is vulnerable, but it is not on the CERT/CC's 
list.  Should I report that to the CERT/CC?</b>
<blockquote><p>
If you have first-hand knowledge of an SNMP product that is vulnerable 
to either of these vulnerabilities, and that product or vendor is not 
listed in CERT advisory CA-2002-03 
(<a 
href="http://www.cert.org/advisories/CA-2002-03.html">http://www.cert.org/advisories/CA-2002-03.html</a>), 
you are encouraged 
to contact us using our Product Vulnerability Reporting Form.  This 
form can be found at 
<a 
href="http://www.cert.org/reporting/vulnerability_form.txt">http://www.cert.org/reporting/vulnerability_form.txt</a>.
<br><br>
Please send the completed form to <a 
href="mailto:cert@cert.org?subject=CA-2002-03%20Feedback%20VU%23617947">cert@cert.org</a>
with VU#617947 in the subject line.
</p>
</blockquote>

<a name="18"></a>
<li><b>Our company manufactures a product that uses SNMP, and we think 
it 
might be vulnerable, but we are not sure.  How can we get more 
information on these vulnerabilities?</b>
<blockquote><p>
The CERT/CC encourages any vendors whose products are affected 
(whether vulnerable or not) by these or any other security 
vulnerabilities to contact us so that we can establish a working 
relationship on this and any future issues that may arise.  If you are 
authorized to represent your organization on this issue, please 
contact the CERT/CC via our hotline at +1 412-268-7090.  CERT/CC 
personnel answer 8:00 a.m.- 5:00 p.m. EST(GMT-5) / EDT(GMT-4) on 
working days; they are on call for emergencies during other hours and 
on weekends and holidays.
</p>
</blockquote>

<a name="19"></a>
<li><b>Our company manufactures a product that uses SNMP, and we know 
it to 
be affected by these vulnerabilities, but we are not listed in any of 
your vendor statements.  How can we get added to your list of 
vendors?</b>
<blockquote><p>
The CERT/CC encourages any vendors whose products are affected 
(whether vulnerable or not) by these or any other security 
vulnerabilities to contact us so that we can establish a working 
relationship on this and any future issues that may arise.  If you are 
authorized to represent your organization on this issue, please 
contact the CERT/CC via our hotline at +1 412-268-7090.  CERT/CC 
personnel answer 8:00 a.m.- 5:00 p.m. EST(GMT-5) / EDT(GMT-4) on 
working days; they are on call for emergencies during other hours and 
on weekends and holidays.
</p>
</blockquote>

<a name="20"></a>
<li><b>Our company manufactures a product that uses SNMP, but we know 
it is 
not affected by these vulnerabilities.  Nonetheless, we are being 
swamped with calls to our help desk about this issue.  We are not 
currently listed in any of your vendor statements, but we'd like to 
be.  How can we get added to your list of vendors?</b>
<blockquote><p>
The CERT/CC encourages any vendors whose products are affected 
(whether vulnerable or not) by these or any other security 
vulnerabilities to contact us so that we can establish a working 
relationship on this and any future issues that may arise.  If you are 
authorized to represent your organization on this issue, please 
contact the CERT/CC via our hotline at +1 412-268-7090.  CERT/CC 
personnel answer 8:00 a.m.- 5:00 p.m. EST(GMT-5) / EDT(GMT-4) on 
working days; they are on call for emergencies during other hours and 
on weekends and holidays.
</p>
</blockquote>

<a name="21"></a>
<li><b>Who is OUSPG?</b>
<blockquote><p>
The Oulu University Secure Programming Group (OUSPG) is an academic 
research group located at Oulu University in Finland. The purpose of 
this research group is to test software for vulnerabilities. 
</p><p>
History has shown that the techniques used by the OUSPG have 
discovered a large number of previously undetected problems in the 
products and protocols they have tested. Earlier this year, the OUSPG 
produced a comprehensive test suite for evaluating implementations of 
the Lightweight Directory Access Protocol (LDAP). This test suite was 
developed with the strategy of abusing the protocol in unsupported and 
unexpected ways, and it was very effective in uncovering a wide 
variety of vulnerabilities across several products. This approach can 
reveal vulnerabilities that would not manifest themselves under normal 
conditions. 
</p>
</blockquote>

</ol>

<!-- end faq content -->

<br><br>
<a href="#top">Top</a>
<hr noshade>
Copyright 2002 Carnegie Mellon University<br>
CERT<sup>®</sup> and CERT Coordination Center<sup>®</sup> are 
registered in the U.S. Patent 
and Trademark office.<br><br><small>
<font face="arial, geneva, helvetica"><a 
href="/legal_stuff/legal_stuff.html">Disclaimers and copyright 
information</a></small><br><br>
<small><small>
Last updated February 13, 2002
</small></small>