Has anyone else heard of this SNMP problem? Are we up to date with the
security fixes on stable, etc?
Here is a quick excerpt (CRYPTO-GRAM, March 15, 2002):
SNMP Vulnerabilities
SNMP is the Simple Network Management Protocol, the most popular
protocol
to manage network devices. Hundreds, possibly thousands, of products
use
it. Last fall, a group of Finnish researchers discovered multiple
vulnerabilities in SNMP. By exploiting the vulnerabilities, an attacker
could cause a denial-of-service attack, and in some cases take over
control
of the system.
The vulnerabilities concerns SNMP's trap-handling and request-handling
functions, and stem from problems in the reference code (probably) used
inside the Abstract Syntax Notation (ASN.1) and Basic Encoding Rules
(BER). The SNMP vulnerabilities affect hundreds of different devices:
operating systems, network equipment, software packages, even things
like
digital cameras. It's a BIG deal.
It's actually a bigger deal than has been reported. ASN.1 is used
inside a
lot of other applications, such as OpenSSL. These vulnerabilities
aren't
limited to SNMPv1; that's just the only thing that's been
well-publicized
at this point. (The recently reported problems in mod_ssl and Apache
are
apparently related to this, too.)
The history of the vulnerability's discovery and publication is an
interesting story, and illustrates the tension between bug secrecy and
full
disclosure. A research group from the Oulu University Secure
Programming
Group in Oulu, Finland, first discovered this problem in October 2001,
and
decided not to publish because it was such a large problem. CERT took
on
the task of coordinating the fix with the major software vendors, and
has
said that the reason publication was delayed so long is that there were
so
many vendors to contact. CERT even had problems with vendors not taking
the problem seriously, and had to spend considerable effort to get the
right people to pay attention. Lesson #1: If bugs are secret, many
vendors
won't bother patching their systems.
The vulnerability was published on 12 February. Supposedly, this was
two
weeks earlier than planned, and because the story was leaking too
much. CERT felt that early publication was better than widespread
rumors. Some companies were caught off-guard. Even though they had
months
to patch their systems, they weren't ready and needed those two extra
weeks. Some companies didn't bother to start worrying about the problem
until publication was imminent. Lesson #2: It is only the threat of
publication that makes many" vendors patch their systems. (To be fair,
many companies did a great job proactively patching their systems. And
in
many cases, the patches were not trivial. Some vendors were swamped by
the
sheer number of different products and releases they had to patch and
test. And I stress "test", because patching mature code carries a
strong
probability of either not fixing the problem or of introducing new
problems.)
When CERT finally published and the Oulu Web site went live, there were
all
sorts of reactions. Some tried to capitalize on the announcement to
sell
their products; others tried to minimize it. Many vendors had no idea
if
they were vulnerable or not But because publication included
demonstration
code -- the PROTOS tool -- vendors and security companies were able to
test
networks and equipment. Lesson #3: Publication must include enough
information to reproduce the vulnerability; otherwise, there's no way
for
anyone to determine how serious the threat is. And Lesson #4: If there
is
no way to independently verify the vulnerability, then organizations are
forced to rely on information from potentially biased sources.
As of this writing, there have been no credible reports of this
vulnerability being exploited in the wild. Counterpane's monitoring has
not detected any of our customers being attacked via this
vulnerability. This is not to say that no one has -- writing an attack
tool is a straightforward programming task -- but no one has published
such
a tool and put it in the hands of the script kiddies. Lesson #5:
Publication does not automatically mean the vulnerability will be
exploited.
So far we've been lucky. But a tool could show up at any time, so
relying
on that luck would not be smart. And even though everyone has been
urged
to patch their systems and products, some will not. Even if it takes
months before someone writes an attack tool, it will work against a
surprisingly large subset of systems. Lesson #6: Publication increases
the
likelihood that a vulnerability will be exploited.
And there are a lot of systems for which patches will never be
available. Many router vendors have gone out of business in the last
few
years, and not every mom-and-pop software company out there has the
money
or clue to replace their hardware because their code has a problem.
Lesson
#7: Since many, many systems will remain unpatched, this vulnerability
will
pose a risk for years to come.
At Counterpane, we were able to make use of the public demonstration
code
to quickly write filters for our Sentry and push them down to our
customers' networks. We did this within hours, so even if they didn't
patch their systems we could monitor them for evidence of exploitation.
We
patched our own Sentry. This wasn't perfect -- in some systems the
attack
didn't show up in their audit logs -- but it let us know which systems
would benefit from other security tools, like IDS signatures tuned to
detect the PROTOS tool. We collected and maintained a list of intrusion
detection signatures for Snort, RealSecure, CiscoIDS, Network Flight
Recorder, etc., that were specifically designed to collect the PROTOS'
tool's test packets.
We also sent out an advisory to our customers -- a voice of reason among
the slightly hysterical news articles -- and made our Network
Intelligence
group available in a conference call to reassure them. We made our
research available to the FBI and other security organizations. Lesson
#8:
Vigilant monitoring provides another layer of security, if and when
products and patches fail.
While these vulnerabilities are serious, the fact that SNMP is
vulnerable
should not come as a surprise to anyone. Vulnerability "U7" in the SANS
Top 20 talks about SNMP. SANS's recommendation: "If you do not
absolutely
require SNMP, disable it." This was good advice when the list was
released, and it's good advice now.
CERT advisory:
<http://www.cert.org/advisories/CA-2002-03.html>
<http://www.cert.org/tech_tips/snmp_faq.html>
Counterpane advisory:
<http://www.counterpane.com/alert-snmp.html>
Oulu's analysis and PROTOS test suite:
<http://www.ee.oulu.fi/research/ouspg/protos/testing/c06/snmpv1/>
Analyses and articles:
<http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2847924,00.html>
<http://www.theregister.co.uk/content/4/24167.html>
<http://www.infoworld.com/articles/op/xml/02/03/04/020304opsecurity.xml>
--
http://www.eskimo.com/~xeno
[EMAIL PROTECTED]
Physically I'm at: 5101 N. 45th St., Tacoma, WA, 98407-3717, U.S.A.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
