SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Technology Stocks : Frank Coluccio Technology Forum - ASAP -- Ignore unavailable to you. Want to Upgrade?


To: Raymond Duray who wrote (1112)2/10/2000 1:17:00 AM
From: ftth  Respond to of 1782
 
A couple other places to look:
securityfocus.com
ukhackers.com

securityfocus.com
=========================================================================

The DoS Project's "trinoo" distributed denial of service attack tool

==========================================================================

David Dittrich <dittrich@cac.washington.edu>
University of Washington
Copyright 1999. All rights reserved.
October 21, 1999

Introduction
------------

The following is an analysis of the DoS Project's "trinoo" (a.k.a.
"trin00") master/slave programs, which implement a distributed
network denial of service tool.

Trinoo daemons were originally found in binary form on a number of
Solaris 2.x systems, which were identified as having been compromised
by exploitation of buffer overrun bugs in the RPC services "statd",
"cmsd" and "ttdbserverd". These attacks are described in CERT
Incident Note 99-04:

cert.org

The trinoo daemons were originally believed to be UDP based,
access-restricted remote command shells, possibly used in conjunction
with sniffers to automate recovering sniffer logs.

During investigation of these intrusions, the installation of a trinoo
network was caught in the act and the trinoo source code was obtained
from the account used to cache the intruders' tools and log files.
This analysis was done using this recovered source code.

Modification of the source code would change any of the details
in this analysis, such as prompts, passwords, commands, TCP/UDP port
numbers, or supported attack methods, signatures, and features.

The daemon was compiled and run on Solaris 2.5.1 and Red Hat Linux 6.0
systems. The master was compiled and run on Red Hat Linux 6.0. It is
believed that both master and daemon have been witnessed "in the
wild" on these same platforms.

Trinoo networks are probably being set up on hundreds, perhaps
thousands, of systems on the Internet that are being compromised by
remote buffer overrun exploitation. Access to these systems is
probably being perpetuated by the installation of multiple "back
doors" along with the trinoo daemons.

A trinoo network of at least 227 systems -- 114 of these at Internet2
sites -- was used on August 17, 1999 to flood a single system at the
University of Minnessota, swamping the target network and rendering it
unusable for over two days. While responding to this attack, large
flows were also noticed going to at least sixteen other systems, some
outside the US. (See Appendix D for a report of part of this trinoo
attack.)

Attack scenario
---------------

A typical installation might go something like this.

1). A stolen account is set up as a repository for pre-compiled
versions of scanning tools, attack (i.e. buffer overrun exploit)
tools, root kits and sniffers, trinoo daemon and master programs,
lists of vulnerable hosts and previously compromised hosts, etc. This
would normally be a large system with many users, one with little
administrative oversight, and on a high-bandwidth connection for rapid
file transfer.

2). A scan is performed of large ranges of network blocks to identify
potential targets. Targets would include systems running various
services known to have remotely exploitable buffer overflow security
bugs, such as wu-ftpd, RPC services for "cmsd", "statd",
"ttdbserverd", "amd", etc. Operating systems being targeted appear to
be primarily Sun Solaris 2.x and Linux (due to the ready availability
of network sniffers and "root kits" for concealing back doors, etc.),
but stolen accounts on any architecture can be used for caching tools
and log files.

3). A list of vulnerable systems is then used to create a script that
performs the exploit, sets up a command shell running under the root
account that listens on a TCP port (commonly 1524/tcp, the
"ingreslock" service port), and connects to this port to confirm the
success of the exploit. In some cases, an electronic mail message is
sent to an account at a free web based email service to confirm which
systems have been compromised.

The result is a list of "owned" systems ready for setting up
back doors, sniffers, or the trinoo daemons or masters.

4). From this list of compromised systems, subsets with the desired
architecture are chosen for the trinoo network. Pre-compiled binaries
of the trinoo daemon are created and stored on a stolen account
somewhere on the Internet.

5). A script is then run which takes this list of "owned" systems and
produces yet another script to automate the installation process,
running each installation in the background for maximum multitasking.
==========
the rest of this is at the above url