Overview
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 systems1
on
Ethernet networks and provides an easy to use and understand graphical
user interface2. 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
tests3.
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:664.
NetBSD
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.
Windows 95,98,NT
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.
DNS Tests5
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 Tests6
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.
8. A much more extensible selection of falsified traffic will be included
in
the next major revision of the tool.