The Hacker's Encyclopedia 1998/hackers_encyclopedia.iso/zines/phrack2/p49_06.txt

Text File | 2003-06-11 | 9.4 KB | 202 lines

                             .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 [e-mail]/[e-mail]


        --[ 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