Zines/phrack/49/6.txt

                             .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