"The COAST approach has been to look at limits and underlying problems and see
what we can do to change the paradigm. We don't start with the view that
'well, the system gives us X and we know Y, so what can we find using that?'
Instead, we ask questions about the whole process of intrusion and misuse,
and try to find new ideas there."
- Gene Spafford
----| Distributed Denial of Service Attacks
It is perhaps prophetic that the first CERT advisory of the 21st century
should concern a distributed Denial of Service attack (see CA-2000-01 [1]).
In November 1999, CERT even held a 'Distributed-Systems Intruder Tools
Workshop' [2], to discuss "the threat" of distributed DoS (Denial of Service)
tools.
Briefly: in a distributed DoS attack, daemons are installed on multiple
compromised hosts; a client is used to identify a target to the daemons who
each then launch a DoS attack (usually using flood-like attacks i.e. UDP,
ICMP, SYN). The unified and sustained nature of attacks generated by multiple
daemons can often cripple a target network/host.
Some good work has been done on analysis of current distributed DoS tools, and
we direct the interested reader to the work of David Dittrich [3].
----| Applications of a Distributed Approach
It is somewhat depressing that DoS is very often the first application of any
new idea which can be utilized in a security context, and this is especially
true of distributed techniques, since the distributed 'philosophy' is
applicable to many facets of computer network penetration.
Below, we describe two examples of the distributed approach applied to very
familiar tasks: port scanning and password sniffing. Source code for an
example distributed port scanner implementation is included at the end of the
article.
----| Port Scanning
In P55-09 - 'Distributed Information Gathering' [4], the advantages in using
a distributed network information gathering approach are described, namely:
I. Stealth
By employing co-operation, time dilation, and randomization techniques we hope
to elude NIDS (network-based intrusion detection systems).
II. Correlation Information
The acquisition of multiple 'points of view' of a target enables a more
complete model of the target to be constructed, including multiple route and
timing information.
III. Pervasive Information Gathering
The countermeasures which some N-IDS can employ, such as injecting a 'deny
rule' into a firewall (for example, using an OPSEC API [5]), become less
effective at stopping ongoing information gathering.
----| Distributed Port Scan Detection
To detect a distributed port scan in which multiple hosts are being used to
distribute and "share the work" of information gathering, the functionality
must exist in a detection system to analyze a recorded event (for example - a
SYN packet sent to a port) in context, i.e. using circumstantial information.
The difficulty lies in knowing which information it is valuable to keep; you
may throw away the one byte which unlocks the puzzle! Resource starvation
and state-holding attacks then become applicable, since the resources
available to the detection system are unlikely to be infinite.
Assuming no pathologically obvious variations of information gathering
techniques are used (e.g. SYN+RST), a detection system must almost ignore
source IP addresses when performing analysis, since by definition, multiple
source hosts can distribute the set of probes to be performed.
For example, if you receive a connect to each port from 1 to 1024 over the
duration of a week, from multiple hosts, you are likely to have been port
scanned; however, the set of ports an individual is interested in determining
are open on your machine (or network), is unlikely to be as easy to recognize
as 1-1024.
There obviously exists an opportunity to perform much more research in
the area of programmatically identifying distributed attacks.
----| Password Sniffing
In P55-16 - 'Distributed Metastasis' [6], the advantages associated with using
a distributed model for password sniffing are described; briefly, the two
primary advantages are in removing the need to revisit a compromised host to
collect sniffer logs, and to increase the speed with which the sniffed
information is made available so that the penetration can be immediately
continued/deepened.
----| The Implementation
An implementation of a distributed port scanner is provided for illustrative
purposes.
DPS (Distributed Port Scanner) consists of a client working in conjunction with
agents located on multiple remote hosts.
The communication between the client and the agents is provided via some basic
commands encapsulated in ICMP_ECHO_REQUEST/REPLY packets, thus providing a
fairly covert channel. Strong data payload encryption is planned for a later
release.
The port scan request is done by the client; the agents perform the port scan
itself, and then report the results back to the client.
Imagine that we have 4 agents, located on 4 different hosts: 'hardbitten',
'doubt', 'ketamine' and 'neurosponge'. Our goal is to obtain the status of
ports 21, 22, 23, 80 and 143 on 10.0.2.10. The client is located on the host
'implode' and agents.txt is a file containing a list of agents.
[root@implode dps]# ./client 10.0.2.10 21-23,80,143 agents.txt eth0
packet sent. 1 of 1
Using device eth0
21 iz open
23 iz open
80 iz open
[root@implode dps]#
The client distributes the "workload" (the set of ports) between the different
agents; each agent scans the target host for a subset of the total ports,
then reports the results back to the client.
This isn't by any means a finished product - it is proof-of-concept. Planned
features for future releases include: distributed password sniffing,
distributed remote OS detection, strong crypto, multi-threaded agents, and
other ideas that people have been throwing seen this project was begun. Stay
tuned. Take your time to browse through the source code. Both Libnet and
Libpcap are needed by both the agent and the client.
----| Conclusions
It is interesting to see historically the wave-like effect that exists between
centralized and distributed computing: mainframe, client/server, thin-client
(such as Windows Terminal Server and the JavaStation Network Computer), etc.
This same effect has not yet been fully witnessed in computer security (the
Morris Worm [7] is an obvious exception).
Conversely, the concept of 'remote control' is not new to security; Loki [8],
Back Orifice [9], and NetBus [10] all provide client/server style remote
control functionality.
To conclude, the key to the distributed 'philosophy', is the _combination_
of the above two concepts.
----| References
[1] CERT Advisory CA-2000-01 - Denial-of-Service Developments, CERT/CC and
FedCIRC, January 3, 2000,
http://www.cert.org/advisories/CA-2000-01.html
[2] Results of the Distributed-Systems Intruder Tools Workshop,
Pittsburgh, Pennsylvania USA, November 2-4, 1999, Published at
the CERT Coordination Center, Software Engineering Institute,
Carnegie Mellon University, Pittsburgh, PA, 15213, December 7,
1999, http://www.cert.org/reports/dsit_workshop.pdf
[3] The Dos Project's "trinoo" distributed denial of service attack tool,
The "Tribal Flood Network" distributed denial of service attack tool,
The "stacheldraht" distributed denial of service attack tool, David
Dittrich, University of Washington, December 31, 1999,
http://www.washington.edu/People/dad/
[4] Distributed Information Gathering, hybrid, Phrack Magazine, Vol. 9,
Issue 55, Article 9 of 16, 09.09.99,
http://www.phrack.com/search.phtml?view&article=p55-9
[5] Check Point Open Platform for Security (OPSEC), Check Point Software
Technologies Ltd, 1999, http://www.opsec.com
[6] Distributed Metastasis: A Computer Network Penetration Methodology,
Andrew J. Stewart, Phrack Magazine Vol. 9, Issue 55, Article 16 of 19,
09.09.99, http://www.phrack.com/search.phtml?view&article=p55-16
[7] The Internet Worm Program: An Analysis, Eugene H. Spafford, Purdue
University, 1998,
http://www.cerias.purdue.edu/coast/archive/data/categ29.html
[8] Project Loki, daemon9 & alhambra, Phrack Magazine Vol. 7, Issue 49,
Article 06 of 19, August 1996,
http://www.phrack.com/search.phtml?view&article=p49-6
[9] Back Orifice 2000, Cult of the Dead Cow, http://www.b02k.com
dps is a distributed portscanning tool. It consists in a client working
in conjuction with agents located in several remote hosts thus providing
'many-to-one' and 'many-to-many' portscanning.
The communication between the client and the agents is provided via some
basic commands encapsulated in ICMP ECHO_REQUEST/ECHO_REPLY packets this way
providing a fairly covert channel.
Data payload encryptation is also available
using the most popular symmetric-key algorithms (except for DES due to the
pathetic export restrictions is U.S.).
(*not* yet implemented)
The portscan request is done by the client, being the portscan itself done by
the agents which then report back to the client the results obtained.
Compilation notes:
1. make client
2. make agent
and that'z it!
<-->
<++> p56/dps/agents.txt !96b84d09
foo
bar
neuro.somewieirddomain.org
10.0.2.10
<-->
<++> p56/dps/localtest.txt !ea0d9aae
127.0.0.1
<-->
<++> p56/dps/include/config.h !5d33c259
#define MAGIC "lifeline" /* magic string, only alphanumerical
characters please. Btw, you will
become an idiot if you don't change this.
*/
#define BLOWFISH_KEY "lifelinerox"
#define MAX_HOST_SIZE 64 /* maximum hostname size allowed */
#define MAX_ICMP_PAYLOAD_SIZE 56 /* ok, this one is tricky. A maximum payload
of 56 bytes is recommended is you want
the packets to seem real. But 56 may not
be enough to store all the port
information, in this case the program
will split up in various ICMP packets,
however in the case that the port
information may be really large it will
cause a tremendous ICMP flood in the
network, so deal with it and use the
option that fits you best.
*/
<-->
<++> p56/dps/include/dps_pcap.h !3dca6d72
#ifndef DPS_PCAP
#define DPS_PCAP
struct agentnfo {
u_long address; /* agent's IP address */
u_long victim; /* victim's IP address */
char *ports; /* ports to scan separated by comas(",") and minus("-"); */
struct agentnfo *next; /* next agent in list, this is a linked list */
};
/* dps control header construction */
head = malloc(16);
memset(head, ' ', 16);
memcpy(head, &MAGIC, 8);/* MAGIC string should be no longer than 8 chars */
sock = libnet_open_raw_sock(IPPROTO_RAW);
if (sock == -1) return -1;
for (agent = first_agent ; agent != NULL ; agent = agent->next) {
/*
* First let'z take care of our special payload.
*
* -------------------------
* | MAGIC |+|R|R|R|R|R|R|R|
* -------------------------------------
* cli_addr | victim_addr | ports_info |
* -------------------------------------
*/
/* Space available in each packet */
each_p = MAX_ICMP_PAYLOAD_SIZE - 16;
/* Total information size */
info_s = 2*sizeof(u_long) + strlen(agent->ports);
/* Calculate the number of packets needed for all the info. */
packets_n = (info_s % each_p ? info_s / each_p + 1 : info_s / each_p);
switch (pcap_datalink(pd))
{
/* There'z no such DLT in OpenBSD, I'm changing to NULL, should work
on solaris.
*/
case DLT_NULL:
offset = LOOPBACK_OFFSET;
break;
case DLT_SLIP:
case DLT_PPP:
offset = SLIP_PPP_OFFSET;
break;
case DLT_EN10MB:
default:
offset = ETHERNET_OFFSET;
break;
}
return (offset);
}
Vova
