The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

[Phrack] ICMP (security icmp)


<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>
Ключевые слова: security, icmp,  (найти похожие документы)
Subject: [Phrack] ICMP .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

<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>

 Добавить комментарий
Имя:
E-Mail:
Заголовок:
Текст:




Спонсоры:
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2020 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру