[12902] in bugtraq
Re: Analysis of trin00
daemon@ATHENA.MIT.EDU (Jacob Langseth)
Thu Dec 9 13:40:11 1999
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-Id: <19991209035831.A19385@darkphiber.net>
Date: Thu, 9 Dec 1999 03:58:32 -0500
Reply-To: Jacob Langseth <jwl@POBOX.COM>
From: Jacob Langseth <jwl@POBOX.COM>
X-To: Stefan Aeschbacher <stefan@aeschbacher.com>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <384F669F.2C4C049D@aeschbacher.com>; from stefan@AESCHBACHER.COM
on Thu, Dec 09, 1999 at 12:21:51AM -0800
Stefan Aeschbacher scribed:
> Hi
> here are some snort rules which could show the presence of a trin00
The nature of these attacks do not lend themselves to an
easy defense; finding a master and retrieving its list of
clients is currently one of the best, albeit proactive,
countermeasures. By making rules to detect the master
available for a free IDS, you greatly improve the chances
of fighting the default configuration. Thank you.
I have a few suggestions, if I may.
> alert tcp any any -> 192.168.1.0/24 27665 (msg:"Trin00: Attacker to
> Master (default startup pass detected!)"; content:"betaalmostdone";))
Trinoo uses crypt(3) to verify this password. Stock crypt(3)
bases its one-way function on DES, which is limited to a 56-bit
key. Passwords exceeding this length are truncated, making
"betaalmo" sufficient to authenticate.
> alert tcp any any -> 192.168.1.0/24 27665 (msg:"Trin00: Attacker to
> Master (default r.i. pass detected!)"; content:"gOrave";))
The gOrave password is read via stdin during master startup,
making its occurance on the control channel highly unlikely.
(As gOrave is required for startup, it's verification takes
place before the control port is listening.) I think this
rule may be safely dropped.
Thanks again,
Jacob
--
Jacob Langseth <jwl@pobox.com>
