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