Spoofing

Spoofing can occur at all layers of the IP system. The hardware layer, the data link layer, the IP
layer, the transport layer, and the application layer are susceptible. All application layer
protocols are at risk if the lower layers have been compromised. In this chapter, only the
application layer protocols intimately linked to the IP protocol are discussed. This includes
routing protocols and the DNS naming protocol. Other application layer protocols depend on
these two protocols to provide basic services to almost all applications using the Internet.

-Hardware Address Spoofing
At the hardware layer, any network interface for a shared-media network will have a hardware
interface address. As you read earlier in the discussion on sniffing, most network interfaces can
be put into promiscuous mode and receive frames with any destination address. A much more
serious problem occurs if the network interface can alter the source address and send data that
appears to come from various source addresses. In the IEEE 802 standards for networking (of
which Ethernet is a variant), each network interface has a 48-bit hardware address. It uses this
hardware address to match the variety of destination addresses of the frames it sees. The
interface copies frames with matching destination addresses into its internal buffer and notifies
the operating system that they are available for further processing. Packets coming from the
operating system to the interface do not typically specify a source address; the interface always
puts its hardware address in the source field.
Most software does not typically control the source field of frames leaving an Ethernet
interface. When another host examines a packet containing a hardware source address associated
with an interface of a particular machine, it assumes that the packet originated on that
machine and accepts it as authentic. An IEEE standards committee assigns each network
interface manufacturer a unique 24-bit prefix for the 48-bit hardware address; the manufacturer
assigns a unique 24-bit suffix to each interface it makes. Regardless, many interface cards
are configurable and allow host software to specify a source address other than the one assigned
by the manufacturer. This configurability makes it possible to use them to spoof the source
address.
DECNet, for example, uses 16-bit identifiers and requires that the leading 32 bits of the
hardware address be set to a fixed value to indicate that the packet is a DECNet packet. Any
network interface that is compatible with DECNet can have its hardware source address
altered in some way, either by software or switches on the interface board.
To see how common it is for a network interface to be able to spoof the source address,
however, recall how a bridge works. A bridge not only puts its interfaces into promiscuous
mode, but it also sets the hardware source address of packets sent out on its interfaces to match
the hardware source address of the originating interface. A PC with two software configurable
interfaces can be configured to be used as a bridge. Clearly, such software configurability has a
variety of malicious uses. The drawbridge software mentioned in the previous section on
hardware barriers to prevent sniffing is compatible with most Ethernet boards which means
most Ethernet boards will permit source address spoofing.
As you can see, it is not entirely safe to base the authenticity of a packet on the hardware
source address. Unfortunately, there is very little you can do to protect yourself against such
deviousness. One solution is to use digital signatures at the application layer. Unfortunately,
currently there are no protections in the IP network layer that will prevent a hardware address
spoofer from disguising one machine as another. If the victim machine is trusted (for example,
is allowed to NFS mount filesystems from another machine), the spoofer will be able to take
advantage of that trust and violate security without being detected. Fortunately, hardware
address spoofing is difficult (relative to many other spoofing methods) and requires penetration
of physical security.
Countering hardware level spoofing is difficult because it is virtually undetectable without
tracing the physical wiring. You need to trace the wiring to be certain no one has connected an
unauthorized machine and you also need to check to see if the authorized machines are using
the hardware address they should. The latter can be checked using sufficiently “intelligent”
hubs in secure locations.
All machines not in physically secure locations can be connected to hubs in secure locations.
Some “intelligent” hubs can be configured to accept or send packets or both to or from specific
hardware addresses on each port they service. Thus, you can configure the hub to accept only
packets with hardware addresses matching the manufacturer-assigned hardware address of the
interface on the authorized machine. This interface should be connected to the wall plate on
the far side of the wires connected to that port. Clearly, you are still relying on physical
security to be sure that the hub, wires, and authorized machine remain as they should.
Note Devices that perform hardware address verifications cannot be categorized as
“hubs” in the traditional sense and are probably actually specialized switches or
bridges. However, they are marketed as “active hubs” or “filtering hubs.” Such hubs
are available from 3Com, HP, and IBM.


-ARP Spoofing
A more common form of spoofing that is accidental is ARP spoofing. ARP (Address Resolution
Protocol) is part of Ethernet and some other similar protocols (such as token-ring) that
associate hardware addresses with IP addresses. ARP is not part of IP but part of these
Ethernet-like protocols; ARP supports IP and arbitrary network-layer protocols. When an IP
datagram is ready to go out on such a network, the host needs to know the hardware destination
address to associate with the given IP destination address. For local IP destinations, the
hardware address to use will be the hardware address of the destination interface. For non-local
destinations, the hardware address to use will be the hardware address of one of the routers on
the local network.

-How ARP and ARP Spoofing Work
To find the hardware address, the host sends out an ARP request using the hardware broadcast
address. A frame with the hardware broadcast address reaches every network interface on the
local network, and each host on the local network has its operating system interrupted by the
network interface. The ARP request is essentially asking the question, “What is the hardware
address corresponding to the IP address I have here?” Typically, only the host with the
matching IP address sends an ARP reply and the remaining hosts ignore the ARP request. The
ARP request contains the IP address of the sender of the request and reaches all hosts via a
broadcast.
Other hosts could potentially store the association between hardware address and IP address of
the sender of the request for future reference. The target of the request certainly would store
the association. It will almost certainly send an IP datagram in reply to the IP datagram it is
about to receive. The reply will require knowing the association between the IP address and
the hardware address of the sender of the ARP broadcast.
The association between the hardware address and the IP address of other machines on a
network is stored in an ARP cache on each host. When an IP datagram is about to leave a host,
the host consults the ARP cache to find the destination hardware address. If the host finds an
entry for the IP destination address, it need not make an ARP request. The entries in an ARP
cache expire after a few minutes.
Thus, when the ARP cache entry for a machine expires, an ARP request goes out to refresh the
entry. No reply comes back if the target machine goes down. The entries for its interface’s
hardware will disappear from the ARP caches in the other machines on the network. The other
machines will be unable to send out IP datagrams to the downed system after the ARP cache
entries expire. Before that point in time, IP datagrams are sent out but are not received. When
the machine comes back up, it will again be able to reply to ARP requests. If someone replaces
its interface, the now up and running machine will have a new hardware address and will use
that new hardware address in ARP replies. ARP caches throughout the network will reflect the
change, and IP datagrams go out using the new hardware address.
Because you expect the IP address to hardware address association will change over time, the
potential exists that the change may be legitimate. Sometimes it is purely accidental. Someone
may inadvertently assign a machine the same IP address held by another machine. On personal
computers or special purpose devices such as network printers or X Window System terminals,
the end user typically has access to a dialog box, command, or text file that sets the IP address.
On multiuser systems, the system administrator is typically the only one who can set the IP
addresses of the network interface(s). This arrangement is changing, however, as more inexperienced
IP-based end users with PCs set addresses. In addition, bureaucracies often separate
system administrators and network administrators that use the same network. Under such
circumstances it is common for two machines to end up with the same IP address. Duplication
can occur either by copying the network configuration from one personal computer to another
without the end user knowing the need for IP addresses to be unique. Duplication can also
occur if system administrators on a network do not work together when configuring system
addressing.
When two machines end up with the same IP address, both of them will naturally reply to an
ARP request for that address. Two replies to the request come back to the host that originated
the request. These replies will arrive in rapid succession, typically separated by at most a few
milliseconds. Some operating systems will not realize anything is wrong and simply file each
reply in the ARP cache with the slowest response remaining in the ARP cache until the entry
for that IP address expires. Other operating systems will discard ARP replies that correspond to
IP addresses already in the cache. These may or may not bother to check if the second reply
was a harmless duplicate or an indication an ARP spoof may be underway.
Thus, depending on the mechanism used to process duplicate ARP replies, if a spoofer wants
to be the target of the IP datagrams being sent to a particular IP address from a particular host,
it needs to make sure it is either the first or the last to reply to ARP requests made by that
particular host. An easy way to be first or last is to have the only machine that replies to the
ARP requests. An attacker can simply use a machine assigned, via the normal operating system
configuration mechanisms, the same IP address as a machine that is currently not working. An
attacker attempting to masquerade his or her machine can simply turn the legitimate machine
off. The attacker does not need to have direct access to the power switch on the machine. The
machine can be turned off either by unplugging it or flipping the appropriate circuit breaker.
An alternative to disconnecting its power is to disconnect it from the network at some point in
the network wiring scheme. Third, the attacker can change the legitimate machine’s IP address
and leave it turned on if he or she can reconfigure the machine. Doing so is less likely to draw
attention or result in confusion from the machine’s user or administrator.