Re: Some security-related suggestions

Ned Freed <NED@sigurd.innosoft.com> Thu, 09 June 1994 00:49 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08967; 8 Jun 94 20:49 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08963; 8 Jun 94 20:49 EDT
Received: from PO5.ANDREW.CMU.EDU by CNRI.Reston.VA.US id aa19099; 8 Jun 94 20:49 EDT
Received: (from postman@localhost) by po5.andrew.cmu.edu (8.6.7/8.6.6) id UAA07938; Wed, 8 Jun 1994 20:44:31 -0400
Received: via switchmail for ietf-pop3+@andrew.cmu.edu; Wed, 8 Jun 1994 20:44:30 -0400 (EDT)
Received: from po2.andrew.cmu.edu via qmail ID </afs/andrew.cmu.edu/service/mailqs/q003/QF.0hxaKsy00Uda5ioE51>; Wed, 8 Jun 1994 20:43:38 -0400 (EDT)
Received: from sigurd.innosoft.com (SIGURD.INNOSOFT.COM [192.160.253.70]) by po2.andrew.cmu.edu (8.6.7/8.6.6) with ESMTP id UAA28352 for <ietf-pop3+@andrew.cmu.edu>; Wed, 8 Jun 1994 20:43:08 -0400
Received: from SIGURD.INNOSOFT.COM by SIGURD.INNOSOFT.COM (PMDF V4.4-0 #1234) id <01HDAYPYTXCW9KM1RM@SIGURD.INNOSOFT.COM>; Wed, 08 Jun 1994 17:42:51 -0800 (PST)
Date: Wed, 08 Jun 1994 17:18:57 -0800 (PST)
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Ned Freed <NED@sigurd.innosoft.com>
Subject: Re: Some security-related suggestions
In-reply-to: Your message dated "Wed, 08 Jun 1994 16:56:01 -0400 (EDT)" <ghxX1V600WBwA10EIh@andrew.cmu.edu>
To: John Gardiner Myers <jgm+@cmu.edu>
Cc: POP3 IETF Mailing List <ietf-pop3+@andrew.cmu.edu>
Message-id: <01HDB3JNDOLO9KM1RM@SIGURD.INNOSOFT.COM>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
Content-transfer-encoding: 7BIT

> Ned Freed <NED@SIGURD.INNOSOFT.COM> writes:
> >    "Providing an indication of the existence of an account in the absence of
> >    a proper password lets attackers narrow the search to known accounts, and
> >    thus represents an increased security risk."

> There are people who still believe this?

Yeah, I happen to believe it because it happens to be true.

> Attackers can narrow the
> search to known accounts by examining the local-parts of addresses in
> messages sent from the site.

Not at most of the larger sites I deal with, they can't. Most of them
unconditionally rewrite all addresses on outgoing mail so that no information
is given about the actual account names involved. The local-parts are therefore
totally worthless in determining actual account names and even specific systems
containing the accounts (getting rid of system names in headers is a harder
problem, but it can be done if you torque on it hard enough).

Often as not their account names then become some numeric code or other crap I
don't care for and which make my life hard when I have to debug stuff, but hey,
I wasn't asked for permission to do this, you know?

Besides, even the dumbest crackers out there know that the best accounts to
break into are the old ones lying around that nobody ever uses (and hence never
appear in a local-part). Find one of these and you'll be sitting pretty, since
nobody will ever go running to the system manager saying that they saw someone
else logged in on their account.

> These issues aren't mentioned at all in RFC 1510.  If the issues
> aren't important enough to deal with in Kerberos, why should they be
> addressed in POP?

I never said that the IESG is consistent in its consideration of such issues.
(No disrespect intended, but my observations have indicated that they aren't.)
All I said was that documents have been sent back to committee for their
failure to address such issues. This is proven fact. Since someone has been
kind enough to specify some prose that may help, I don't see any compelling
reason for its exclusion and at least one good reason to include it.

				Ned

P.S. I once spent almost three months tracking down a cracker. They found an
unused account using precisely this sort of attack and then used this account
as a springboard to attack systems all over the Internet. We caught on early
and started in on a daily ritual where we watched this clown break into system
after system after system using this sort of technique as well as several
others. (There was a strong preference for military sites, which on average
seemed to be a bit more vulnerable than most.)

After that came the daily ritual of cold-calling administrative contacts listed
by WHOIS and telling incredulous people that their systems had just been
invaded. Then there were the return calls, personal visits from military
personnel, and whatnot as we worked out ways to reliably exchange information
about how the breakins were done back to these admins so they could plug the
holes.

And finally, after this clown broke into some important military databases and
did some really serious damage once again using this same sort of attack, the
FBI managed to bestir itself enough to issue the warrants we'd been asking for,
and they nailed the cracker. Needless to say, my stolen three months of time
weren't returned to me...