The AntiSniff tool from L0pht Heavy Industries came about due to a need to determine which machines on a local network are in promiscuous mode (i.e. collecting and examining data that is not destined to them). A machine in this condition is usually in one of two states: it has been compromised and is being used to collect passwords or data destined to other systems or it is being used legitimately to examine network data for any number of reasons. It is extremely important for the Network administrator / Network Security personnel to know which machines are in this promiscuous mode to permit further directed investigation.
Version 1.X of AntiSniff is designed to run on Windows NT systemson Ethernet networks and provides an easy to use and understand graphical user interface. The tool allows tests to be run that determine, through a variety of fashions, whether a remote system is capturing and analyzing packets that are not destined to its hardware address. AntiSniff determines the state of the remote machine independent of its Operating System.
Whereas most network tools will look for potential vulnerabilities on a remote system or look for malicious traffic signatures, we believe this is the first tool of its kind in detecting what was believed to be a passive scenario often indicative of a compromised machine.
How One Uses AntiSniff V1.X
AntiSniff is run on each local Ethernet network segment. For example, if one has a flat non-switched class C network one instance of AntiSniff can handle the entire net. If however, the network is broken up into workgroups of say 12 machines per port going into a switch then one instance of AntiSniff would be needed per workgroup. The reason for this is the use of non-valid Ethernet addresses in particular tests and the need for some amount of promiscuous monitoring in other tests.
The usage of AntiSniff V1.X is straightforward. A machine or range of machines is selected from the GUI along with a list of the types of checks to be performed. The operator specifies the frequency, which the tests will be run with, and launches the application. For the tests other than network latency (see below) a definitive positive or negative result will be returned for each machine. This result, along with alarm and notification if configured, indicates that a machine was found to be in promiscuous mode if the result is positive.
For network latency test results it is recommended that the operator perform a visual inspection on the first data results and investigate machines that exhibit drastic, two orders of magnitude increase, in response times between flooding and non-flooding tests. Once these machines are taken out of promiscuous mode or deemed to be operating normally, future AntiSniff tests will log positive results upon changes in state between promiscuous and non-promiscuous operations.
It is recommended that the tool be run as frequently as possible. The particular frequency value is obviously site specific and depends upon factors such as network load; number of machines being tested, and site policy.
Technical Details on the Tests AntiSniff Performs
Currently version 1.X of AntiSniff performs three classes of tests: Operating System specific tests, DNS tests, and network latency tests. Each test can stand on its own for determining a machines state or be used in conjunction with the other tests included in the suite. It should be noted that AntiSniff V1.X is designed to work on local network segments in a non-switched environment. The tool will work in switched environments but its functionality will be limited. AntiSniff V2.0 is being designed to work not only on local network segments but also across routers and switches.
Operating System Specific Tests
Linux Kernel Test
Older Linux kernels exhibited a quirk in filtering that could be exercised to elicit responses indicating whether the machine is in promiscuous mode or not. Under normal situations the hardware Network Interface Card filters and discards packets that are not addressed to the machine MAC address or the broadcast Ethernet address. If the packet is destined to the machines actual Ethernet address or broadcast Ethernet address it is copied and passed over to the kernel for processing. Presumably the data inside the Ethernet frame would consist of an IP packet with the machines correct IP address or the broadcast address of the network in question. When a NIC is placed in promiscuous mode every packet is passed on to the operating system to analyze and/or process. Various Linux kernels looked only at the IP address in the packets to determine whether they should be handed to the IP stack for processing as a packet destined to the local system. To exploit this the tool creates a packet with an ether address that does not map to any particular NIC yet contains a valid IP packet with the destination hosts correct IP address. Vulnerable Linux kernels with the network interface set to promiscuous mode look only at the correct IP address and hand the packet to the appropriate stack. By creating an ICMP echo request inside the bogus Ethernet frame the vulnerable systems respond when in promiscuous mode and correctly ignore the packet when not in this monitoring state. Thus betraying the state of the machine. This test works particularly well when the IP address in the bogus ether frame is set to the network broadcast address. It should be noted that the user of the tool has control over the values to be used for the ether addresses inside the ether frame with a default being set to 66:66:66:66:66:66.
Various NetBSD kernels have been seen to exhibit similar characteristics to the above Linux nuance with the noted difference that the IP address in the bogus ether frame needs to be set to the broadcast address.
Upon perusal of the header files for network drivers it was gleaned that Microsoft Operating Systems do indeed check the Ethernet address of unicast packets correctly when in promiscuous mode. If the packet matches the NIC ether address it is handed to the appropriate stack to be operated on as a packet destined to the local machine. The flaw being exploited here is in how broadcast ether packets are analyzed. Under normal circumstances, i.e. the machine is not in promiscuous mode, the NIC only passes packets to the kernel that are destined to its ether address or to the broadcast ether address of ff:ff:ff:ff:ff:ff. When in promiscuous mode the driver checks for the ether address being that of the NIC for unicast packets but only checks the first octet of the ether address against the value of 0xff to determine if the packet is broadcast or not. Thus, to elicit a response from a machine in promiscuous mode AntiSniff creates packets with an ether address of ff:00:00:00:00:00 with the correct destination machines IP address. Upon receipt of this packet a Microsoft Operating System using the driver that exhibits this nuance will respond to the packet when in promiscuous mode and silently discard the packet when in non-promiscuous mode.
It should be noted that this is dependent upon the driver that is being used. The default Microsoft driver exhibits this feature and most vendors have chosen to base their driver off of this thus propagating the idiosyncrasy. However, there are some cards that filter for broadcast based upon the first octet only in hardware. These cards will return positive consistently irrespective of their actual state. This test relies upon the hardware and driver filtering behaving differently. Cards and drivers that return this false positive have been few and a detailed list will be maintained on the AntiSniff V1.X web site.
The DNS tests operate on the premise that many attacker network data gathering tools perform IP to name inverse resolution to provide DNS names in place of IP addresses. This is useful to attackers as often times valuable or cherished machines are named accordingly. To wit: joepc1.foo.bar might be a less interesting target than a machine with a canonical name of payroll.foo.bar. In the act of performing reverse lookups the tool changes from being a passive network tool to becoming an active network tool. Machines not watching traffic that is not destined to them will not attempt to resolve the IP addresses in the packets. To take advantage of this information, AntiSniff V1.X places itself in promiscuous mode and sends packets out on the network destined to fictitious hosts. Upon seeing any reverse lookup requests going by on the wire referencing the fictitious hosts the address sending the requests is flagged as being a system engaged in actively monitoring network traffic not destined to it.
The ether address, target, and destination IP addresses are all configurable.
Network and Machine Latency Tests
This final grouping of tests is arguably the most powerful in that it has the ability to spot machines on the local network that are in promiscuous mode regardless of the make of their Operating System. The caveat is that these tests have the potential to create a large amount of network traffic for short periods of time. In addition, some amount of human analysis is helpful in utilizing the tool to its fullest, but not absolutely required.
These tests operate on the premise that when a network card is not in promiscuous mode it is afforded hardware filtering. That is, packets not destined to the machine in question are dropped by the firmware on the network card. When this is the case, dramatic increases in network traffic not destined to the host in question have a relatively minimal affect on the Operating System. Conversely machines in promiscuous mode do not have the benefit of this low level filtering. Thus dramatic increases in network traffic not destined to the host in question can have a dramatic effect on the underlying operating system as it now needs to do the filtering in kernel or user mode. In the case where a tool is monitoring network traffic and acts upon the data in user space, a context switch occurs from kernel to user mode and incurs additional latency.
Given the above data points, AntiSniff V1.X builds a baseline for the machine(s) being probed by issuing ICMP echo requests with microsecond timers (higher resolution is attained when high resolution performance counters are available)7 and determining the average response time. Once this data has been obtained the tool proceeds to saturate the local network with non-legitimate traffic. While this flooding is taking place the tool again issues timing packets to determine the average response deltas. Non-promiscuous machines show a slight increase in latency while promiscuous machines often show a latency increase of up to 4 orders of magnitude.
To help stress the various applications that attackers and intruders commonly use, three types of network saturation tests are performed8:SIXTYSIX, TCPSYN, and THREEWAY.
SIXTYSIX creates packets that are comprised entirely of the hex value 0x66. This is designed to not be accepted by any non-promiscuous mode host yet create data that is logged and captured by most normal use network monitoring tools such as tcpdump, snoop, etc.
TCPSYN creates packets that contain apparently valid TCP headers inside apparently valid IP headers. The TCP flags field has the SYN bit set signifying the start of a session. This excursuses most malicious tools that are looking to grab login information over TCP streams. Upon seeing the initial TCP packet with the SYN flag set an entry is created signifying that further packets in this session should be watched. In addition, this flood data has the potential to tax such tools as Network Intrusion Detection systems.
THREEWAY operates upon the same principles as TCPSYN but takes it one step further. In the THREEWAY flooding an entire TCP three-way between non-existent machines is created a multitude of times. This test encourages network-monitoring programs that are more sophisticated to set their internal state tables for the completed fictitious session.
It should be noted at this point that while one can use AntiSniff V1.X to spot machines currently in promiscuous mode through these tests the greatest value comes from periodic monitoring and comparison of previous data points. The first run of latency tests can very easily be used with visual inspection to point out machines that show large network performance shifts during flooding as opposed to non-flooding mode. These systems can then be evaluated further via human intervention to determine their absolute state. If the state is determined to be unwarranted it can be remedied. Once the local network is believed to be in a sane state with no machines running in promiscuous mode that are not intended to, the tool is run at periodic intervals. Upon seeing any order of magnitude changes in performance from previous runs the system in question is flagged as being promiscuous. This negates the problem of comparing individual operating system aspects and keeping track of large amounts of data to indicate the “normal” performance shifts for different platforms. Comparing previous data points against the same machine quickly and obviously denotes a machine switching state either into or out of promiscuous mode.
Caveats and Concerns
Due to the nature of AntiSniff V1.X and its extensive use of falsified etherframe flooding, one needs to be aware of limitations in its usage. Many of these concerns are being addressed for the next major revision release that is designed to work across routers and through switched environments.
The tests and functionality inside of AntiSniff V1.X are designed to be used on a local network. By wrapping valid IP addresses inside of ether frames addressed to non-existent addresses the packets will not be forwarded through routers. This can cause confusion if the user points to a machine not on the local network and runs the various tests. Certain packets, such as the ICMP or UDP ECHO packets destined to the end node will successfully be routed. However, flooding and bandwidth utilization techniques will be constrained to the local network. This will render the values returned from the remote machine inconclusive.
Every effort has been made to not impact network devices in a detrimental fashion. With that being said, the results of sending these tests across various types of bridges or switches could potentially produce unforeseen results.
1. AntiSniff V1.X runs on Windows 95, Windows 98, and Windows NT. However, due to the architecture of the non-NT systems certain network intensive tests become less reliable. It is therefor recommended to run the version 1.X tool on NT systems.
2. A stripped down command line only version will be released for Unix systems
3. Several new classes of tests are being incorporated in the next version – they were not included in this version due to time constraints.
4. The ether address of 66:66:66:66:66:66 is chosen as the default since the first three octets do not match any current vendor ID and the address is non-broadcast / multicast.
5. Although these tests were known of for some time, we would be remiss if we did not credit Dr. Who for driving home just how fruitful the DNS checks end up being.
6. These classes of tests came about after conversations with Thomas Ptacek and Tim Newsham who postulated on the validity of said tests in public news forums.
7. The option to use the ECHO service for time deltas, if it is available on the remote machine, is also provided in AntiSniff V1.X.