Subject: IW Mailing List iw/960313
From: (Ry Jones)
Subject: Re: IW Mailing List iw/960312
Date: Tue, 12 Mar 1996 20:50:32 -0800 (PST)

Don't forget that a person could tag a URL into a popular home page
that causes a telnet session to be fired off... all of your attacks
may be actually benign on the part of the attacker. I doubt it, but
none the less...

[Moderator's Note: See posting below by fc for more details.  Such a
URL was placed and automatically activated in a Web page a part of
this attack, and the source was tracked down and recorded.]
Date: Tue, 12 Mar 1996 21:37:35 -0500
From: "Matthew G. Devost" 
Subject: Re: IW Mailing List iw/960312

>[Moderator's Note: How do we classify this threat? Disgruntled outsider
>participating in a protest? Is this IW and if so, what attacks are not?
>Is all of info-sec defensive IW and vica versa?]

Well congrats for sparking the list back to life! I think it is
definitely an IW attack at the Class I level, but I would agree with
most of the comments from the list that perhaps [ is] overreacting. 

I am concerned over the statement that it will pursue criminal
conspiracy charges against all those that telnet to their site.  I asked
what sort of warning banner was in place and hadn't gotten a reply yet
so I checked to see.  Well, there is NO warning banner.  You simply get
a connection refused by foreign host (and I imagine, a email to root at
my ISP saying I am an evil hacker!).

[Moderator's Note: I believe that the federal computer abuse statutes
don't require a warning banner.  If they did, than any denial of service
attack that ignored responses would be legal.]

Here is my point.  It is obvious that someone (an individual) has a
gripe with you or just wants to target your machine, but I would not
call the other attempts a conspiracy.  I could post the following
message to a cancer survivor newsgroup or list:

	"Hello all! Just wanted you to know that I have set up a Cancer
	Survivors network on my host machine.  It requires telnet access
	for now, but we are hoping to find an easier way to access the
	computer in the near future.  Please give it a try by telneting

So, Jane Doe in Manchester, NH decides to follow the instructions and
test out the system.  She telnets to and gets the connection
refused.  "Oh well", she says, as she unknowingly becomes a suspect of
criminal conspiracy. 

My point, and I realize I am taking a long time getting there, is that
at the very least you should provide a warning banner when folks telnet
to you site telling them that an unauthorized telnet attempt will be
considered an intrusion. 

If I were in your shoes, I would focus my attention on the person that
made the first attempt and replied with the snide remark, and leave the
people who got suckered into telneting to your site alone.  If you can
prove a coordinated conspiracy go for it, but the way the system is set
up anyone could get you 100 attempted telnets an hour just by creating
fake stories like the one above. 

>All email from will be considered an attack and large dosages 
>of ritalin will be fired back at you in return.
>[Moderator's note: Since we don't want to violate anybody's policy, we
>have dropped this subscriber from the list.]

I think this was a poor attempt at humor.  In which case, your dropping the
person from the list is inappropriate.  Just my HO.

[Moderator's note: we didn't actually drop the person from the list - that
was our poor attempt at returning the humor.]
Date: Wed, 13 Mar 96 09:13:49 EST
From: (Ira S. Winkler)
Subject: Re: IW Mailing List iw/960312

There are two separate issues here.  First, is an attempted telnet
session reason to alert an administrator to possible abuse.  And second,
why not just let it pass. 

Let me first start by saying that a telnet attempt is the first and most
obvious step in any electronic intrusion.  The next issue is that if you
have no valid account on a system, and nobody invited you in, then it is
technically an unwanted access attempt, and possibly criminal depending
upon the interpretation of the law.  If someone wanted to download files
legitimately, they would try to come in through a gopher or ftp port. 
Telnet's only purpose is to establish access. 

As for alerting an administrator, it is extremely likely that a person
trying to get into one system also tries to get into dozens of others. 
You never know if that person has been successful, and the other systems
have as good detection tools as Fred's site.  For that reason the CERT
very strongly requests that you notify administration staff at the
"attacker's" site to let them know that an individual might be
participating in possible abuse of their privileges.  If it is an
accident, then the individual is cleared without incident.  If it is
part of a clear pattern of abuse, or possibly results from a compromised
account, then you are doing the administrators a service by alerting
them to the pattern and helping them collect enough evidence to get a
criminal off their system.  (And yes, computer abuse is a crime). 

Sending a message to an administrator does nothing more than alerting
them to a possible incident, which is how the message was worded
(admittedly strongly).  Again, the CERT advises this course of action,
and IMO for good reason.
[Moderator's Note: We have consolidated Fred Cohen's postings below and
(slightly) rewritten them.]

From: fc (Fred Cohen)
Subject: incident at - tracked down

7:05 AM At least part of the incident at has now been tracked
down to malicious code at Community Connection (  Someone
apparently placed a pointer to our telnet port in their Web page and it
is now causing about 1,000 automated responses every 8 hours.  We have
changed our message to point to as the place to contact,
forwarded copies of all of the details of the incident to that site for
their examination and action, contacted the FBI, and are in the process
of contacting all of the notified systems administrators of the

We also detected a port scan by one of these sites.  This indicates that
the person at that site may have been trying to slip one by us while the
larger incident was underway.

As a postscript, based on overnight performance, I now believe we can
handle more like 50,000 such attempts per day without significant
degradation or time impact on people or our other detection capabilities. 

9:50 AM We are now getting connections at the rate of about 3 per minute
average - 10/minute peak - or over 4300 per day.  Earlier, we switched
from semi-automatic response mode (where admins get notified of all
telnets) to a more automatic mode (they are logged, counted, and
displayed in near-real-time in one of the console windows on the
manager's machine).  After that, I went for a walk, got the mail, and
stopped back in.

We also just found out that postings to several mailing lists were used
in the incident.  That's apparently what got the 10/day level started.

10:57 AM The following log entries are a good sign:

Mar 13 10:18:38 all in.telnetd[24288]: refused connect from
Mar 13 10:22:20 all in.telnetd[24698]: refused connect from
Mar 13 10:25:40 all in.telnetd[25050]: refused connect from MAPS.CS.CMU.EDU
Mar 13 10:39:37 all in.telnetd[26465]: refused connect from 209@celtic.UU.NET

Apparently, finally got the message and the malicious code was
removed from their Web page.  (We checked their page after the threat
level fell, and the code was removed.)  Of course Web pages are cached
in many places so it may take some time for the overall effect to go away.

12:30 I spoke too soon.  A user at has decided to
provide a telnet pointer with an enticing message on their page.  I
guess they want the FBI to consider them part of the incident.  When I
told them so, they did not disagree.

14:30 A good question posed by one alert admin:

How did we ever find the URL?

	Our notification of systems administrators eventually led to an
	admin who had audit records of Web accesses made through their
	firewall.  Our audit record of their user combined with their
	audit records of times of Web accesses led to a specific URL
	being accessed at the time of the autoresponse. 

	I examined the page associated with the URL and it contained
	code that caused the browser of an innocent user to attempt to
	telnet to our site.  It was the correlation of audit records
	with our automated response that made the detection possible. 
	Otherwise it might be impossible to track down.

The incident rate is down to only 3 or 4 tries per hour now, and
apparently the underlying issues are starting to be discussed on forums
throughout the Internet.  As a side note, this Web vulnerability is a
minor variation on an attack reported last week and is similar to many
vulnerabilities known in the Web environment that have shown up in
growing numbers in the last few months.

18:00 I spoke too soon again. It picked back up again.  Apparently,
someone again modified's home page and the rate went back
up to several per minute for a few hours.  We contacted the ISP for (themselves a provider) and the ISP contacted who has
now again removed this code.

In responding to these incidents, we also noticed a lone port scan. 
This type of event is handled differently, but it generates a message to
the location as well.  In this case, when we looked more deeply, the
port scan came from a site with literally hundreds of telnet attempts
interspursed through the other less numerous attempts.  Was the rest of
the incident created by this person as a cover for their concerted
attack? Were the numerous telnets an attempt to overwhealm our defenses?
We're still trying to track it down, but we do believe (based on rc5
checksums of all system files) that no system files were altered in the
process and that no logins succeeded during the period of the attack.

We are now down to one attempted telnet per 4-5 minutes again.  The
total size of this incident to date is about 1,500 telnet attempts
and 2 port scans.

A final note.  I now believe (but haven't yet been able to prove) that
the person sending the email references in my last posting on this topic
is not a party to this particular incident.  We do have a few other
suspects, but we will see.