The subject of what and how information about computer security problems
should and should not be made available has been discussed here and in a
variety of other forums. Typically these discussions are in abstract
terms, and focusing on the difficulties of balancing competing problems.
I have been encouraged to submit the below description of my interactions
with CERT (Computer Emergency Response Team) because people who don't
deal directly with CERT have been surprised at the extreme position that
CERT takes on these matters: it is not much of an exaggeration to say
that CERT's position is that they are an input-only channel. Since
CERT is being used as a model for similar groups, their approach takes
on even wider significance.
My background: I handle part of the management of a cluster of approx
50 Suns. Because my group collaborates with various companies and
universities, I wind up getting involved in dealing with breakins at
some of those other sites ("collective insecurity" :-) ).
My site is well-known (we were one of the first sites on the original
ARPAnet), and I am known to people at CERT -- I should have no problem
getting vetted as trustworthy if CERT were to do that. The following are
my personal opinions (not my employers) based on my experiences plus those
of the system managers and administrators that I interact with.
Previous Incidents
__________________
Over the years, I have dealt with a variety of breakins and attempts.
When it was possible to trace the cracker forward or backward, I would
send the M.O. (modus operandi = profile) of the cracker (not just the
holes that he tried to exploit, but also a list of symptoms that a site
should look for). After the creation of CERT, I would also send this
MO to them.
I now regard the minuscule effort needed to send CERT a copy of this
MO a waste of time because CERT refuses to provide this information
to sites that have been broken into. I have personal experience with
this on both sides:
1. I have contacted CERT about a particular cracker and given a
substantial profile and asked if CERT could tell me anything more
about this particular cracker. All CERT has been willing to provide
is their generic documents. In backtracking the cracker, I found
a site that had identified the cracker's MO and reported it to CERT.
2. Similarly, I have been the one to report an MO and later be contacted
by a site that had gotten nothing from CERT, but had learned of me
by backtracking the cracker to a site that I had contacted.
Current Incident
________________
A site with which mine has substantial interactions was broken into by
a cracker in mid-September, and consequently I got involved in helping
with the problem. We very quickly found several of his tools and enough
other things to constitute a reasonable signature. We contacted CERT
and they claimed to have no knowledge of this particular cracker.
The cracker was using captured passwords to daisy-chain from site to
site. Unfortunately, we didn't immediately find all the holes and
backdoors that he had planted. Consequently, the cracker persisted
in having access to that site for some time, thereby having a chance to
capture additional passwords. In the followup, we found multiple other
sites that had been broken into by the same cracker (coming or going).
None of these had gotten any useful information from CERT.
Two days before the recent CERT announcement that there was a hole in
sendmail, I got a message from the admins for that site: "he's back".
They found a backdoor that he had installed, but were unable to figure
out how he had gotten in to install it. Suddenly, with the announcement
of the hole, several things we had seen (and reported) seemed to fall
into place.
Because this cracker had earlier probed my site from various other places
on the net (we had already closed the holes he was exploiting), I was
concerned that he might have used this newly found hole to compromise my
site (remember, he had broken into a number of the universities and
companies with which we collaborate). I called CERT and asked if they
could tell me what symptoms to look for to determine whether or not this
hole had been used. I was told that there were definite symptoms, but
that CERT couldn't tell what they were because that would give away what
the hole was. I reminded them that their advisory said
"** This vulnerability is being actively exploited and we strongly
recommend that sites take immediate and corrective action. **"
and that we had already reported a breakin-in-progress (at the site I was
helping), but to no avail. I subsequently got the information I needed
from another source, but only at the cost of not being able to pass it on.
One of the many other sites that had been broken into by this same cracker
posted to various relevant newsgroups a list of the sites that it had
determined to have been compromised (the list was several screens long).
CERT posted the following response to those newsgroups:
> Newsgroups: comp.security.unix,comp.sys.sun.admin,alt.security,
> comp.security.misc
> From: cert@cert.org (CERT Coordination Center)
> Subject: Re: Security Incident -- many sites exposed.
> Reply-To: cert@cert.org
> Organization: CERT Coordination Center
> Date: Tue, 19 Oct 1993 15:51:54 EDT
>
>
> CERT is aware of the incident reported earlier today and we are
> working to help resolve it. It is CERT policy not to publicly
> disclose sensitive incident information, particularly names
> of sites that are, or may have been, involved. Therefore, we will not
> post the list of affected sites here or on any other netnews group.
>
> We are reviewing the information concerning this incident and we will
> endeavor to contact all sites known to be affected within the next
> 24 hours. We would appreciate your patience and ask that you not
> contact us about the earlier posting, via either e-mail or telephone,
> so that we can concentrate our resources on contacting and helping the
> affected sites.
>
> CERT Coordination Center
>From what I can determine, what CERT means by "help" is that they tell
the site that they have been broken into and then provide the generic
documents on security patches and practices. The sites I have talked
to never have gotten information specific to a particular incident.
Note also that this "response" comes more than a month after the first
reports to CERT of this cracker (or a very similar one).
Comments
________
Caveat: since CERT is almost exclusively an input-only channel, it is
hard to determine what they knew and when they knew it.
While I agree with the sentiment in CERT's posting above (that it is
undesirable to publicly identify sites that have been broken into), I
cannot disagree with the action of the site that posted the list of
compromised sites -- the cracker seemed to be spreading faster than he
was being found and excluded. (Note that I am not identifying the site
that I went to help, nor am I free to publicly discuss details).
In my opinion, CERT's policy contributed substantially to the number of
sites broken into and the persistence of this cracker on the network.
First, when a system administrator contacts CERT and is told that CERT
doesn't recognize the pattern of a given breakin, the SysAdmin is likely
to believe that he is dealing with an isolated case, either involving a
local user or just one or two other sites. The MO of this cracker left
little evidence to contradict this view. Consequently, a SysAdmin could
easily focus on the wrong containment measures, allowing the cracker to
continue to use his site as a base to attack other sites.
Second, because CERT is unwilling to release info on the various tricks
and tools that the cracker was using, a SysAdmin could easily stop short
in his cleanup, after finding only some of the holes the cracker was using
or had installed. This is what happened at the site I was helping.
This gave the cracker time to capture passwords needed to daisy-chain to
other sites. Similarly, since CERT refuses to give any advice on what
holes the cracker might be using, the SysAdmin may well spend his time and
efforts closing holes that aren't currently being exploited, giving the
cracker time to further compromise that site and others.
CERT would seem to be a classic RISKy system -- because it doesn't behave
the way people think it does/should, it causes people to take the wrong
actions, especially during crises. And the classic way to deal with such
a system is to teach people to ignore it.
-- Douglas B. Moran [Doug Moran via risks-digest Volume 15, Issue 18]
19:28
#
G!
