|
The content and labeling of datasets relies significantly on
reports and feedback from consumers of this data. Please
send feedback on this dataset to Josh Haines
so that your ideas can be incorporated into future datasets. Thanks!
Documentation for Datasets
Lincoln Laboratory Scenario (DDOS), vers. 2.0.2
Overview
This is the second attack scenario example data set to
be created for DARPA as a part of this effort.
It includes a distributed denial of service attack run by an
attacker who is a bit more sophisticiated than the vers. 1.0.
Future versions of this and other example
scenarios will be even stealthier.
This attack scenario is carried out over multiple network
and audit sessions. These sessions have been grouped
into 5 attack phases over the course of which the adversary
probes, breaks-in, installes trojan mstream DDoS software, and launches
a DDoS attack against an off-site server.
ADVERSARY: Novice -- scripted attack, fairly blatant
ADVERSARY_GOAL: Install components for, and carry out, a DDOS attack
DEFENDER: Naive -- sunrpc allowed through firewall, HINFO DNS records contain
some valid host information.
DESCRIPTION:
The premise of the attack is that a relatively novice
adversary seeks to show his/her prowess by using a
scripted attack to break into a variety of
hosts around the Internet, install
the components necessary to run a Distributed Denial
of Service, and then launch a DDOS at a US government
site. As a part of the attack the adversary uses the
Solaris sadmind exploit, a well-known Remote-To-Root
attack to successfully gain root access to three Solaris hosts
at Eyrie Air Force Base. These attacks succeed due
to the relatively poor security model applied at the AFB,
many services, including the dangerous "sunrpc" service,
are proxied through the base's firewall from outside to
inside. The attacker is using the Mstream DDOS tool,
one of the less sophisticated DDOS tools. It does not make
use of encryption and does not offer as wide a range
of attack options as other tools, such as TribeFloodNetwork
or Trinoo. An Mstream "server", the software that actually
generates and sends the DDOS attack packets, is installed
on each of the three victim hosts, while an Mstream "master",
the software that provides a user-interface and controls
the "servers" is installed on one of the victims.
DIFFERENCES FROM VERS. 1.0:
The main difference between 2.0.2 and 1.0 is that in 2.0.2 the attacker
probes for host, platform, operating system by doing DNS HINFO queries, rather
than sweeping IP's and rpc ports,
and that they break-into one host at Eyrie first, then fan out
from there, rather than attacking each host individually.
The five phases of the attack scenario are:
- Probe of mill.eyrie.af.mil, Eyrie's public DNS server, via the HINFO query
- Breakin-to mill.eyrie.af.mil via the sadmind exploit
- FTP upload of mstream DDoS software and attack script, to break-into more
Eyrie hosts.
- Initiate attack on other Eyrie hosts: Telnet to mill.eyrie.af.mil, setup DDoS master and initiate
probing and attack of other Eyrie hosts. Probes are via the HINFO
record query and attacks are via the sadmind exploit. Two break-ins are attempted:
robin.eyrie.af.mil (a linux host listed as Solaris in the HINFO, breakin fails!)
and pascal.eyrie.af.mil (breakin succeeds since the host is Solaris!)
- Launching the DDoS: Telnet to mill, telnet to localhost port 6723, connect to the master, and
launch attack at www.af.mil.
Click the thumbnail below for a "service plot" of the entire attack scenario.
This illustrates the attack as seen in the "tcpdump_inside" sensor (the sniffer on the "inside" network).
Only attack sessions are plotted here and each phase is denoted in
red. The X-axis is time-of-day in Eastern Standard Time and the Y-axis
is the tcp or udp service. The hash-marks indicate the presence of a
network session at that time and of that service.
Attack Scenario Off-Line Data
- Notes
- These data files span approximately 1 hour, 45 minutes on
16 April 2000, from 14:45 to 16:28.
- Background traffic
is of virtually the same content and frequency as was
used in the 1999 datasets, therefore, those data sets
may be used to train for this data. (Let us know if
this is not the case, and a suitable training data
set can be generated!)
- Changes to background traffic from 1999 to the current
year include moving 4 hosts from the 114.0 subnet to the 113.0
subnet and adding the host mill (172.16.115.20) to be the
Eyrie AFB Domain Name Service server as well as a recipient
of telnet traffic.
- Background traffic
generation was started 20min. prior to start of data collection to allow for
any startup "oddities", like ARP or DNS cache population to
disperse.
- The Windows NT server hume.eyrie.af.mil (again!) had a mis-configuration
in the mail server, so there are numerous dns queries from hume that
can be ignored. Hume played no role in the attack scenario.
- To download these datafiles via ftp, do the following:
- ftp to "ideval.ll.mit.edu", login as ideval with the same password as on the website.
- cd to ./2000/LLS_DDOS_2.0.2/data_and_labeling/
- retrieve files as required from the subdirectories tcpdump_[dmz|inside] and audit_bsm_[mill|pascal].
- Tcpdump_Inside: Binary Dump File (gzipped)
- Tcpdump_DMZ: Binary Dump File (gzipped)
- Audit_BSM_Mill (Solaris 2.7): Binary BSM File (gzipped)
- Audit_BSM_Pascal (Solaris 2.5): Binary BSM File (gzipped)
- Mid-Level Labeling, as based on Solaris host BSM sensors, for entire scenario.
Each is a list of XML alerts, each of which represents a BSM "exec" record
that is part of the attack.
- Mid-Level Labeling, as based on Network Tcpdump sensors, by phase.
Each is a list of XML alerts, each of which represents a network
session that is part of the attack.
- Download a tar'd gzip'd file of this entire dataset here
Five Phases of the Attack
PHASE1:
The adversary performs an HINFO query (a valid dns query) of
mill.eyrie.af.mil, the Base's public dns server. The server
has been configured with HINFO records for some of its hosts,
these records contain the platform and operating system of
each host. This allows the adversary to know that the
sadmind attack will probably work and which stack pointer to
use. In the network data, the evidence is two dns queries,
one to lookup the IP and one to get the HINFO information.
PHASE2:
In phase 2 the attacker sucessfully breaks into the
Eyrie dns server, mill.eyrie.af.mil, using the sadmind exploit.
The exploit is invoked twice, once to append a user to the password
file and once to append the user to the shadow-password file.
The stackpointer chosen works on the first try, since the attacker
knew the right one to use from the HINFO output.
PHASE3:
Next the attacker ftp's to mill and places: the attack script which will can the
rest of Eyrie (via dns/hinfo) and breakinto Solaris hosts, the mstream server software, and the
mstream master software.
PHASE4:
In phase 4 the attacker telnets to mill, starts the mstream master software on mill,
and launches the script that will probe other hosts on the 112 network at Eyrie and
breakinto those that are correctly denoted as Solaris according to the HINFO records.
Actions carried out by this script are aslo part of phase 4. Evidence here
includes: a telnet to mill, dns queries local on mill, sadmind attacks vs. robin(linux) and
pascal(Solaris), ftp to pascal to place mstream server software, and a telnet to pascal
to start the mstream server.
PHASE5:
In the final phase, the attacker manually launches the DDOS. This
is performed via a telnet login to the victim on which the master
is running, and then, from the victim, a "telnet" to port 6723 of
the localhost. In the case of scenario 2.0.2 however, the
attacker notices that the server on pascal is not registered with
the master and he/she telnets to pascal to re-start that server.
port 6723/TCP is the port on which the master
listens for connections to its user-interface. After entering
a password for the user-interface, the attacker is given a prompt
at which he/she enters two commands. The command "servers"
causes the UI to list the mstream servers which have registered
with it and are ready to attack. the command "mstream 131.84.1.31 5"
causes a DDOS attack, of 5 second duration, against the given IP address
to be launched by all three servers simultaneously.
The mstream DDOS consists of many, many connection requests to
a variety of ports on the victim. All packets have a spoofed, random
source IP address. The attacker then logs out.
The tiny duration was chosen so that it would be possible to
easily distribute tcpdump and audit logs of these events -- to
avoid them being to large. In real life, one might expect
a DDOS of longer duration, several hours or more.
In the case of this scenario, however, it should be noted that the DDoS
does not exactly succeed. The Mstream DDoS software attempts to flood
the victim with ack packets that go to many random tcp ports on the victim
host. The AirForce base firewall, the Sidewinder firewall, is not
configured to pass traffic on all these ports, thus the only mstream packets
that make it though the firewall are those on well-known ports. All other
mstream packets result in a tcp reset being sent to the spoof source address.
Thus in the DMZ dump file, one sees many resets apparently coming from "www.af.mil"
going to the many spoofed source addresses. These are actually created by
the firewall as a result of the reciept of the tcp packet for which the firewall
is configured not to proxy!
|
