Home page logo

bugtraq logo Bugtraq mailing list archives

Re: Analysis of trin00
From: stefan () AESCHBACHER COM (Stefan Aeschbacher)
Date: Thu, 9 Dec 1999 16:39:02 -0800

Jacob Langseth wrote:

Stefan Aeschbacher scribed:
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 thought of the problem of fighting the default configuration and this
is definitely a valuable point. I think that the (malicuous) people
reading Bugtraq need a certain amount of technical knowledge and such
a person will change the default configs. So this rules are mainly
to protect against script-kiddies.
Searching a master is definitely the better alternative but I have the
problem that one of my servers is located in a subnet where I am not
allowed to do any administrative actions on the other machines
and the people there don't really care about security. (Yea, I should
move this server to another location ;). I even assume a check for a
master server could be regarded as an attack (If they notice it).
So the only thing I (and probably some more people on this list) can
do is listen for trin00.

I have a few suggestions, if I may.

alert tcp any any -> 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.

right, didn't think to far when I wrote this rule.

alert tcp any any -> 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 you for your corrections


   Stefan Aeschbacher
   Federal Institute of Technology     Where do you want to go today?
   Lausanne Switzerland
   http://www.aeschbacher.ch/stefan       - NOT in your direction! -

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]