202 lines
9.4 KiB
Plaintext
202 lines
9.4 KiB
Plaintext
.oO Phrack Magazine Oo.
|
|
|
|
Volume Seven, Issue Forty-Nine
|
|
|
|
File 06 of 16
|
|
|
|
[ Project Loki ]
|
|
|
|
whitepaper by daemon9 AKA route
|
|
sourcecode by daemon9 && alhambra
|
|
for Phrack Magazine
|
|
August 1996 Guild Productions, kid
|
|
|
|
comments to route@infonexus.com/alhambra@infonexus.com
|
|
|
|
|
|
--[ Introduction ]--
|
|
|
|
|
|
Ping traffic is ubiquitous to almost every TCP/IP based network and
|
|
subnetwork. It has a standard packet format recognized by every IP-speaking
|
|
router and is used universally for network management, testing, and
|
|
measurement. As such, many firewalls and networks consider ping traffic
|
|
to be benign and will allow it to pass through, unmolested. This project
|
|
explores why that practice can be insecure. Ignoring the obvious threat of
|
|
the done-to-death denial of service attack, use of ping traffic can open up
|
|
covert channels through the networks in which it is allowed.
|
|
|
|
Loki, Norse God of deceit and trickery, the 'Lord of Misrule' was
|
|
well known for his subversive behavior. Inversion and reversal of all sorts
|
|
was typical for him. Due to it's clandestine nature, we chose to name this
|
|
project after him.
|
|
|
|
The Loki Project consists of a whitepaper covering this covert channel
|
|
in detail. The sourcecode is not for distribution at this time.
|
|
|
|
|
|
--[ Overview ]--
|
|
|
|
|
|
This whitepaper is intended as a complete description of the covert
|
|
channel that exists in networks that allow ping traffic (hereon referred to
|
|
in the more general sense of ICMP_ECHO traffic --see below) to pass. It is
|
|
organized into sections:
|
|
|
|
Section I. ICMP Background Info and the Ping Program
|
|
Section II. Basic Firewall Theory and Covert Channels
|
|
Section III. The Loki Premise
|
|
Section IV. Discussion, Detection, and Prevention
|
|
Section V. References
|
|
|
|
(Note that readers unfamiliar with the TCP/IP protocol suite may wish to first
|
|
read ftp://ftp.infonexus.com/pub/Philes/NetTech/TCP-IP/tcipIp.intro.txt.gz)
|
|
|
|
|
|
Section I. ICMP Background Info and the Ping Program
|
|
|
|
|
|
The Internet Control Message Protocol is an adjunct to the IP layer.
|
|
It is a connectionless protocol used to convey error messages and other
|
|
information to unicast addresses. ICMP packets are encapsulated inside of IP
|
|
datagrams. The first 4-bytes of the header are same for every ICMP message,
|
|
with the remainder of the header differing for different ICMP message types.
|
|
There are 15 different types of ICMP messages.
|
|
|
|
The ICMP types we are concerned with are type 0x0 and type 0x8.
|
|
ICMP type 0x0 specifies an ICMP_ECHOREPLY (the response) and type
|
|
0x8 indicates an ICMP_ECHO (the query). The normal course of action is
|
|
for a type 0x8 to elicit a type 0x0 response from a listening server.
|
|
(Normally, this server is actually the OS kernel of the target host. Most
|
|
ICMP traffic is, by default, handled by the kernel). This is what the ping
|
|
program does.
|
|
|
|
Ping sends one or more ICMP_ECHO packets to a host. The purpose
|
|
may just be to determine if a host is in fact alive (reachable). ICMP_ECHO
|
|
packets also have the option to include a data section. This data section
|
|
is used when the record route option is specified, or, the more common case,
|
|
(usually the default) to store timing information to determine round-trip
|
|
times. (See the ping(8) man page for more information on these topics).
|
|
An excerpt from the ping man page:
|
|
|
|
"...An IP header without options is 20 bytes. An ICMP ECHO_REQUEST packet
|
|
contains an additional 8 bytes worth of ICMP header followed by an
|
|
arbitrary-amount of data. When a packetsize is given, this indicated the
|
|
size of this extra piece of data (the default is 56). Thus the amount of
|
|
data received inside of an IP packet of type ICMP ECHO_REPLY will always
|
|
be 8 bytes more than the requested data space (the ICMP header)..."
|
|
|
|
Although the payload is often timing information, there is no check by
|
|
any device as to the content of the data. So, as it turns out, this amount of
|
|
data can also be arbitrary in content as well. Therein lies the covert
|
|
channel.
|
|
|
|
|
|
Section II. Basic Firewall Theory and Covert Channels
|
|
|
|
|
|
The basic tenet of firewall theory is simple: To shield one network
|
|
from another. This can be clarified further into 3 provisional rules:
|
|
1. All traffic passing between the two networks must pass through the firewall.
|
|
2. Only traffic authorized by the firewall may pass through (as dictated by
|
|
the security policy of the site it protects).
|
|
3. The firewall itself is immune to compromise.
|
|
|
|
A covert channel is a vessel in which information can pass, but this
|
|
vessel is not ordinarily used for information exchange. Therefore, as a
|
|
matter of consequence, covert channels are impossible to detect and deter
|
|
using a system's normal (read: unmodified) security policy. In theory,
|
|
almost any process or bit of data can be a covert channel. In practice, it
|
|
is usually quite difficult to elicit meaningful data from most covert
|
|
channels in a timely fashion. In the case of Loki, however, it is quite
|
|
simple to exploit.
|
|
|
|
A firewall, in it's most basic sense, seeks to preserve the security
|
|
policy of the site it protects. It does so by enforcing the 3 rules above.
|
|
Covert channels, however, by very definition, are not subject to a site's
|
|
normal security policy.
|
|
|
|
|
|
Section III. The Loki Premise
|
|
|
|
|
|
The concept of the Loki Project is simple: arbitrary information
|
|
tunneling in the data portion of ICMP_ECHO and ICMP_ECHOREPLY packets. Loki
|
|
exploits the covert channel that exists inside of ICMP_ECHO traffic. This
|
|
channel exists because network devices do not filter the contents of ICMP_ECHO
|
|
traffic. They simply pass them, drop them, or return them. The trojan packets
|
|
themselves are masqueraded as common ICMP_ECHO traffic. We can encapsulate
|
|
(tunnel) any information we want. From here on out, Loki traffic will refer
|
|
to ICMP_ECHO traffic that tunnels information. (Astute readers will note that
|
|
Loki is simply a form of steganography).
|
|
|
|
Loki is not a compromise tool. It has many uses, none of which are
|
|
breaking into a machine. It can be used as a backdoor into a system by
|
|
providing a covert method of getting commands executed on a target machine.
|
|
It can be used as a way of clandestinely leeching information off of a
|
|
machine. It can be used as a covert method of user-machine or user-user
|
|
communication. In essence the channel is simply a way to secretly shuffle
|
|
data (confidentiality and authenticity can be added by way of cryptography).
|
|
|
|
Loki is touted as a firewall subversion technique, but in reality it
|
|
is simple a vessel to covertly move data. *Through* exactly what we move this
|
|
data is not so much an issue, as long as it passes ICMP_ECHO traffic. It does
|
|
not matter: routers, firewalls, packet-filters, dual-homed hosts, etc... all
|
|
can serve as conduits for Loki.
|
|
|
|
|
|
Section IV. Discussion, Detection and Prevention
|
|
|
|
|
|
If ICMP_ECHO traffic is allowed, then this channel exists. If this
|
|
channel exists, then it is unbeatable for a backdoor (once the system is
|
|
compromised). Even with extensive firewalling and packet-filtering
|
|
mechanisms in place, this channel continues to exist (provided, of course,
|
|
they do not deny the passing of ICMP_ECHO traffic). With a proper
|
|
implementation, the channel can go completely undetected for the duration of
|
|
its existence.
|
|
|
|
Detection can be difficult. If you know what to look for, you may
|
|
find that the channel is being used on your system. However, knowing when
|
|
to look, where to look, and the mere fact that you *should* be looking all
|
|
have to be in place. A surplus of ICMP_ECHOREPLY packets with a garbled
|
|
payload can be ready indication the channel is in use. The standalone Loki
|
|
server program can also be a dead give-away. However, if the attacker can
|
|
keep traffic on the channel down to a minimum, and was to hide the Loki
|
|
server *inside* the kernel, detection suddenly becomes much more difficult.
|
|
|
|
Disruption of this channel is simply preventative. Disallow ICMP_ECHO
|
|
traffic entirely. ICMP_ECHO traffic, when weighed against the security
|
|
liabilities it imposes, is simply not *that* necessary. Restricting ICMP_ECHO
|
|
traffic to be accepted from trusted hosts only is ludicrous with a
|
|
connectionless protocol such as ICMP. Forged traffic can still reach the
|
|
target host. The LOKI packet with a forged source IP address will arrive at
|
|
the target (and will elicit a legitimate ICMP_ECHOREPLY, which will
|
|
travel to the spoofed host, and will be subsequently dropped silently) and
|
|
can contain the 4-byte IP address of the desired target of the Loki response
|
|
packets, as well as 51-bytes of malevolent data... While the possibility
|
|
exists for a smart packet filter to check the payload field and ensure that
|
|
it *only* contains legal information, such a filter for ICMP is not in wide
|
|
usage, and could still be open to fooling. The only sure way to destroy this
|
|
channel is to deny ALL ICMP_ECHO traffic into your network.
|
|
|
|
NOTE: This channel exists in many other protocols. Loki Simply covers
|
|
ICMP, but in theory (and practice) any protocol is vulnerable to covert
|
|
data tunneling. All that is required is the ingenuity...
|
|
|
|
Section V. References
|
|
|
|
|
|
Books: TCP Illustrated vols. I, II, III
|
|
RFCs: rfc 792
|
|
Source: Loki v1.0
|
|
Ppl: We did not pioneer this concept To our knowledge,
|
|
it was discovered independently of our efforts, prior to our
|
|
research. This party wishes to remain aloof.
|
|
|
|
|
|
This project made possible by a grant from the Guild Corporation.
|
|
|
|
|
|
EOF
|