Maximum Security:
A Hacker's Guide to Protecting Your Internet Site and Network
  
28
Spoofing Attacks
There has never been more controversy about a cracking technique than the controversy
surrounding IP spoofing. IP spoofing is the most talked about and least understood
method of gaining unauthorized entry to a computer system. For example, a well publicized
spoofing case occurred in December, 1994. John Markoff, in his article that appeared
in The New York Times titled "New Form of Attack on Computers Linked
to Internet is Uncovered," reported:
- The first known attack using the new technique took place on Christmas day against
the computer of a well-known computer security expert at the San Diego Supercomputer
Center. An individual or group of unknown intruders took over his computer for more
than a day and electronically stole a large number of security programs he had developed.
That report was not entirely accurate. The IP spoofing technique was not "new,"
nor was it "uncovered." Rather, it has been known for more than a decade
that IP spoofing was possible. To my knowledge, the first paper written on this subject
was published in February 1985. That paper was titled "A Weakness in the 4.2BSD
UNIX TCP/IP Software," and it was written by Robert Morris, an engineer at AT&T
Bell Laboratories in Murray Hill, New Jersey.
IP Spoofing
Because I want to relay information about IP spoofing as accurately as possible,
I will approach the subject in a slow and deliberate fashion. If you already know
a bit about the technique, you would be wise to skip ahead to the section titled
"Point of Vulnerability: The R Services."
I should immediately make three points about IP spoofing:
- Few platforms are vulnerable to this technique.
- The technique is quite complex and is not commonly understood, even by talented
crackers. It is therefore rare.
- IP spoofing is very easily prevented.
What Is a Spoofing Attack?
A spoofing attack involves nothing more than forging one's source address. It
is the act of using one machine to impersonate another. To understand how this occurs,
you must know a bit about authentication.
Every user has encountered some form of authentication. This encounter most often
occurs while connecting to a network. That network could be located in the user's
home, his office, or, as in this case, the Internet. The better portion of authentication
routines known to the average user occur at the application level. That is, these
methods of authentication are entirely visible to the user. The typical example is
when a user is confronted with a password prompt on FTP or Telnet. The user enters
a username and a password; these are authenticated, and the user gains access to
the resource.
On the Internet, application-level authentication routines are the minority. Each
second, authentication routines that are totally invisible to the user occur. The
difference between these routines and application-level authentication routines is
fundamental. In application-level authentication, a machine challenges the user;
a machine requests that the user identify himself. In contrast, non-application-level
authentication routines occur between machines. One machine demands some form of
identification from another. Until this identification is produced and validated,
no transactions occur between the machines engaged in the challenge-response dialog.
Such machine-to-machine dialogs always occur automatically (that is, they occur
without human intervention). In the IP spoofing attack, the cracker attempts to capitalize
on the automated nature of the dialog between machines. Thus, the IP spoofing attack
is an extraordinary method of gaining access because in it, the cracker never uses
a username or password.
This, for many people, is difficult to grasp. Consequently, reports of IP spoofing
have needlessly caused much fear and paranoia on the Internet.
Who Can Be Spoofed?
The IP spoofing attack is unique in that it can only be implemented against a
certain class of machines running true TCP/IP. True TCP/IP is any fully fledged
implementation of TCP/IP, or one that--in its out-of-the-box state--encompasses all
available ports and services within the TCP/IP suite. By this, I am referring almost
exclusively to those machines running certain versions of UNIX (only a handful are
easily spoofed). PC machines running DOS, Windows, or Windows 95 are not included
in this group. Neither are Macintoshes running MacOS. (It is theoretically possible
that Macs running A/UX and PCs running Linux could be vulnerable, given the right
circumstances.)
I cannot guarantee that other configurations or services will not later be proven
vulnerable to IP spoofing, but for the moment the list of vulnerable services is
short indeed:
- Any configuration using Sun RPC calls
- Any network service that utilizes IP address authentication
- The X Window System from MIT
- The R services
Sun RPC refers to Sun Microsystems' standard of Remote Procedure Calls,
which are methods of issuing system calls that work transparently over networks (that
is, of executing commands over remote machines or networks).
Cross Reference: The RFC that addresses
RPC, titled "RPC: Remote Procedure Call Protocol Specification," can be
found at http://www.pasteur.fr/other/computer/RFC/10xx/1057.
IP address authentication uses the IP address as an index. That is, the target
machine authenticates a session between itself and other machines by examining the
IP address of the requesting machine. There are different forms of IP authentication,
and most of them are vulnerable to attack. A good discussion about this appears in
a classic paper written by Steve M. Bellovin titled "Security Problems in the
TCP/IP Protocol Suite":
- If available, the easiest mechanism to abuse is IP source routing. Assume that
the target host uses the reverse of the source route provided in a TCP open request
for return traffic...The attacker can then pick any IP source address desired, including
that of a trusted machine on the target's local network.
Cross Reference: "Security Problems
in the TCP/IP Protocol Suite" by Steve M. Bellovin can be found on the Web at
ftp://ftp.research.att.com/dist/internet_security/ipext.ps.Z.
Point of Vulnerability: The R Services
In the UNIX environment, the R services are rlogin and rsh. The r represents
the word remote. These two programs are designed to provide users with remote
access to other machines on the Internet. Although these programs may be compared
to programs of a similar ilk (for example, people often liken rlogin to Telnet),
these programs (or services) are unique:
- rlogin provides a means to remotely log in to another machine. It is similar
to Telnet. Today, rlogin is generally restricted to local use. Few networks support
long-distance remote rlogin sessions because rlogin has been deemed a security problem.
- rsh allows you to start an instance of the shell on a remote machine. It can
be used to execute commands on a remote host. For example, in a completely unrestricted
network environment, you could print the password file of a remote machine to the
local one by issuing the command rsh our_target.com cat /etc/passwd >>
our_target.com_passwd. rsh, as you might expect, is a huge security hole and
it is usually disabled.
The R services are vulnerable to IP spoofing attacks.
How Spoofing Attacks Work
Spoofing attacks differ from random scanning and other techniques used to ascertain
holes in the system. Spoofing attacks occur only after a particular machine
has been identified as vulnerable. By the time the cracker is ready to conduct a
spoofing attack, he or she knows the target network is vulnerable and which machine
is to be attacked.
Trust Relationships and Spoofing Generally
Nearly all forms of spoofing (and there are types other than IP spoofing) rely
on trust relationships within the target network. By trust, I don't mean human or
application-layer trust. Instead, I refer to trust between machines.
Chapter 18, "Novell," briefly discusses spoofing of a hardware address
on an Ethernet network. This is accomplished by redefining the network address of
the workstation used to perform the spoof. In Novell networks, this is commonly accomplished
by redefining this value in the NET.CFG file, which contains parameters
that are loaded upon boot and connection to the network. NET.CFG includes
many options for altering the configuration by hand (which is useful, because conventional
configurations sometimes fail to come out correctly). To sidestep possible problems
with factory configurations, changes may be made directly to the interface using
this file. Options include number of buffers, what protocols are to be bound to the
card, port number, MDA values, and the node address.
Hardware address spoofing is, to a certain extent, also dependent upon the card.
Cards that do not allow for software-driven settings of the hardware address are
generally useless in this regard. You might be able to report an address, but in
most instances, the technique does not actually work. Older cards support software-driven
alteration of the address, usually with a jumper setting. (This is done by shorting
out the jumper pins on the card.) A good example is the old Western Digital Ethernet
card. Newer cards are more likely to automatically allow software-driven changes,
whereas IRQ settings may still be a jumper issue. It is likely, however, that in
the near future, Ethernet cards may not have jumpers at all due to the fact that
plug-and-play technology has emerged.
NOTE: Jumpers are small plastic sheaths
that slip over pins on a computer card (this card could be an Ethernet card, a motherboard,
a modem, or a hard disk drive controller). These plastic jumpers are typically used
to set addresses on such cards. The manufacturer of the card generally includes a
manual on their product which shows the locations of jumpers on the board. Such manuals
also usually describe different ways of configuring your jumpers. A jumper pin
set consists of two pins. If these pins are covered by a plastic jumper sheath,
they are deemed to be shorted out. Shorting out different jumpers alters the configuration
of the card. Jumper pin sets are typically arranged in a row on the board. For example,
a modem that has jumpers to assign IRQ addresses will probably have four or five
jumper pin sets. By covering various combinations of these pin sets with plastic
jumper sheaths, you can change the IRQ from three to four, five, seven, and so forth.
CAUTION: Never use MAC addresses as an
index for authentication. Mac addresses on most modern cards can be changed easily
using existing software or quickly hacked code. It is argued that MAC address spoofing
is difficult because when two machines have the same MAC address on the same segment,
communication failures and crashes result. Note, however, that this is not always
true. This generally happens when both are trying to reach the same resource or when
the active protocol is IPX (NetWare). In a passive state, these could co-exist, particularly
in a TCP/IP environment. Nonetheless, there is no guarantee that the packets will
arrive in a pristine state.
This type of spoofing works because each machine on a given network segment trusts
its pals on that same segment. Barring the installation of a hub that hardwire-routes
packets to each machine, at least a few trust relationships between machines will
exist within a segment. Most commonly, those machines know each other because their
addresses are listed within some database on each machine. In IP-based networks,
this is done using the IP address--I hope--or with the hostname. (Using hostnames
is a potential security problem in itself. Whenever possible, hard numeric addresses
should be used.)
Machines within a network segment that are aware of the addresses of their pals
are referred to as machines that trust each other. When such a trust relationship
exists, these machines may remotely execute commands for each other with no more
authentication than is required to identify the source address.
Crackers can determine trust relationships between machines using a wide range
of commands or, more commonly, using scanners. One can, for example, scan a host
and easily determine whether the R services are running. Whatever method is used,
the cracker will attempt to map the trust relationships within the target network.
Anatomy of an IP Spoofing Attack
Let's begin our analysis at a point after the cracker has determined the levels
of trust within the network. An overview of one segment of our mock target network,
called Nexus, is shown in Figure 28.1.
FIGURE 28.1.
Overview of Nexus segment.
As you can see, this segment has two trust relationships: Nexus 1 trusts Nexus
2, and Nexus 2 trusts Nexus 3. To gain access to Nexus, then, the cracker has two
choices:
- He can spoof either Nexus 1 or Nexus 3, claiming to be Nexus 2
- He can spoof Nexus 2, claiming to be either Nexus 1 or Nexus 3
The cracker decides to spoof Nexus 2, claiming to be Nexus 3. Thus, his first
task is to attack Nexus 3 and temporarily incapacitate it.
NOTE: It is not always necessary to incapacitate
the machine from which you are claiming to originate. On Ethernet networks in particular,
however, you may have to. If you do not, you may cause the network to hang.
Step One: Putting Nexus 3 to Sleep
To temporarily incapacitate Nexus 3, the cracker must time out (hang or temporarily
render inoperable) that machine on the targeted port (the port that would normally
respond to requests about to be issued).
Normally, when a request is issued from Nexus 3 to Nexus 2, Nexus 2 replies to
Nexus 3 on a given port. That response generates a response from Nexus 3. The cracker,
however, does not want Nexus 3 to respond because he wants to respond with his own
packets, posing as Nexus 3.
The technique used to time out Nexus 3 is not particularly important as long as
it is successful. The majority of such attacks are accomplished by generating a laundry
list of TCP SYN packets, or requests for a connection. These are generated from a
bogus address and forwarded to Nexus 3, which tries to respond to them. You may remember
that in Chapter 4, I discussed what happens when a flurry of connection requests
are received by a machine that cannot resolve the connection. This is one common
element of a denial-of-service attack, or the technique known as syn_flooding.
The cumulative effect of the flooding times out Nexus 3. That is, Nexus 3 attempts
to resolve all the connection requests it received, one at a time. The machine's
queue is flooded. It cannot respond to additional packets until the queue is at least
partially cleared. Therefore--at least on that port--Nexus 3 is temporarily down,
or unreachable; it will not respond to requests sent by Nexus 2.
Step Two: Discovering Nexus 2's Sequence Number
The next step of the process is fairly simple. The cracker sends a series of connection
requests to Nexus 2, which responds with a series of packets indicating receipt of
the cracker's connection requests. Contained within these response packets is the
key to the spoofing technique.
Nexus 2 generates a series of sequence numbers. Chapter 6, "A Brief
Primer on TCP/IP," mentioned that sequence numbers are used in TCP/IP to mark
and measure the status of a session. An articled titled "Sequence Number Attacks"
by Rik Farrow articulates the construct of the sequence number system. Farrow explains:
- The sequence number is used to acknowledge receipt of data. At the beginning
of a TCP connection, the client sends a TCP packet with an initial sequence number,
but no acknowledgment (there can't be one yet). If there is a server application
running at the other end of the connection, the server sends back a TCP packet with
its own initial sequence number, and an acknowledgment: the initial sequence number
from the client's packet plus one. When the client system receives this packet, it
must send back its own acknowledgment: the server's initial sequence number plus
one. Thus, it takes three packets to establish a TCP connection...
Cross Reference: Find "Sequence Number
Attacks" by Rik Farrow online at http://www.wcmh.com/uworld/archives/95/security/001.txt.html.
Each side must adhere to the sequence number scheme. If not, there is no way to
reliably transfer data across the network. As articulated by Robert Morris in his
article titled "A Weakness in the 4.2BSD UNIX TCP/IP Software":
- 4.2BSD maintains a global initial sequence number, which is incremented by 128
each second and by 64 after each connection is started; each new connection starts
off with this number. When a SYN packet with a forged source is sent from a host,
the destination host will send the reply to the presumed source host, not the forging
host. The forging host must discover or guess what the sequence number in that lost
packet was, in order to acknowledge it and put the destination TCP port in the ESTABLISHED
state.
Cross Reference: Find Morris's article
online at ftp://ftp.research.att.com/dist/internet_security/117.ps.Z.
This procedure begins with reading the sequence numbers forwarded by Nexus 2.
By analyzing these, the cracker can see how Nexus 2 is incrementing them. There must
be a pattern, because this incremental process is based on an algorithm. The key
is identifying by what values these numbers are incremented. When the cracker knows
the standard pattern Nexus 2 is using to increment these numbers, the most difficult
phase of the attack can begin.
Driving Blind
Having obtained the pattern, the cracker generates another connection request
to Nexus 2, claiming to hail from Nexus 3. Nexus 2 responds to Nexus 3 as it normally
would, generating a sequence number for the connection. However, because Nexus 3
is temporarily incapacitated, it does not answer. Instead, the cracker answers.
This is the most difficult part of the attack. Here, the cracker must guess (based
on his observations of the sequence scheme) what sequence number Nexus 2 expects.
In other words, the cracker wants to throw the connection into an ESTABLISHED
state. To do so, he must respond with the correct sequence number. But while the
connection exchange is live, he cannot see the sequence numbers being forwarded by
Nexus 2. Therefore, the cracker must send his requests blind.
NOTE: The cracker cannot see the sequence
numbers because Nexus 2 is sending them (and they are being routed) to Nexus 3, the
actual, intended recipient. These are routed to Nexus 3 because Nexus 3 is the owner
of the actual IP address. The cracker, in contrast, only purports to have Nexus 3's
IP.
If the cracker correctly guesses the sequence number, a connection is established
between Nexus 2 and the cracker's machine. For all purposes, Nexus 2 now believes
the cracker is hailing from Nexus 3. What remains is fairly simple.
Opening a More Suitable Hole
During the time the connection is established, the cracker must create a more
suitable hole through which to compromise the system (he should not be forced to
spoof each time he wants to connect). He therefore fashions a custom hole. Actual
cases suggest that the easiest method is to re-write the .rhosts file so
that Nexus 2 will accept connections from any source without requiring additional
authentication.
The cracker can now shut down all connections and reconnect. He is now able to
log in without a password and has run of the system.
How Common Are Spoofing Attacks?
Spoofing attacks are rare, but they do occur. Consider this Defense Data Network
advisory from July, 1995:
- ASSIST has received information about numerous recent IP spoofing attacks directed
against Internet sites internationally. A large number of the systems targeted in
the IP spoofing attacks are name servers, routers, and other network operation systems,
and the attacks have been largely successful.
Cross Reference: To view the DDN bulletin
online, visit ftp://nic.ddn.mil/scc/sec-9532.txt.
The attack documented by John Markoff in The New York Times occurred over
the Christmas holiday of 1994. By mid-1995, the attack had been discussed in cracker
circles across the Internet. After it was demonstrated that the Morris attack technique
was actually possible, crackers quickly learned and implemented IP spoofing worldwide.
In fact, source code for pre-fabbed spoofing utilities was posted at sites across
the Net. A fad was established.
Cross Reference: One of these individuals
posted to a well-known security list with the subject line "Introducing in the
Left Corner: Some Spoofing Code." The posting was a brief description of a paper
(and accompanying code) available on the author's Web site. It is still available
today. It can be found at http://main.succeed.net/~coder/spoofit/spoofit.html.
Because this is not owned by the user, and because it is located in a foreign country,
I advise you to save it to your local disk. The spoofing code is good. The author
also offers code to hijack Telnet sessions and a general-purpose C program to kill
TCP connections on your subnet.
Even though the word is out on spoofing, the technique is still quite rare. This
is because, again, crackers require particular tools and skills. For example, this
technique cannot--to my knowledge--be implemented on a non-UNIX operating system.
However, I cannot guarantee that this situation will remain. Before long, someone
will introduce a Windows-based auto-spoofer written in Visual C++ or some other implementation
of C/C++. I suspect that these will be available within a year. For the moment, the
technique remains a UNIX thing and therefore, poses all the same obstacles (root
access, knowledge of C, technical prowess to manipulate the kernel, and so forth)
as other UNIX-based cracking techniques.
Spoofing is sometimes purposely performed by system administrators. This type
of spoofing, however, varies considerably from typical IP spoofing. It is referred
to as LAN spoofing or WAN spoofing. These techniques are used primarily
to hold together disparate strings of a WAN (see Figure 28.2).
FIGURE 28.2.
LAN and WAN spoofing in action.
In many WAN environments, networks of widely varying design are attached to a
series of WAN servers, nodes, or devices. For each time a message is trafficked over
these lines, a toll is generally incurred. This can be expensive, depending largely
on the type and speed of the connection. One thing is obvious: The best arrangement
is one in which none of the nodes pays for the connection unless data is being trafficked
across it (it seems wasteful to pay merely for the connection to exist).
To avoid needless charges, some engineers implement a form of spoofing whereby
WAN interfaces answer keep alive requests from remote LAN servers rather than actually
routing those requests within the overall WAN network. Thus, the remote LAN assumes
it is being answered by the remote WAN, but this is not actually true.
Cross Reference: Jeffery Fritz, a telecommunications
engineer for West Virginia University, wrote a consuming article about this type
of technique to save money in Wide Area Network environments. That article, titled
"Network Spoofing: Is Your WAN on the Wane? LAN Spoofing May Help Solve Some
of Your Woes," can be viewed online at http://www.byte.com/art/9412/sec13/art4.htm.
Fritz also wrote the book Sensible ISDN Data Applications, published by West
Virginia University Press. This book is a must read for ISDN users.
This is a very popular technique and is now incorporated into many routers and
routing software. One good example is Lightning's MultiCom Software Release 2.0.
White paper documentation on it explains:
- The Novell SPX/IPX router contains an advanced spoofing algorithm, which keeps
the ISDN line closed when no useful data transits, even while remote users are connected
to a server. Spoofing consists [sic] to simulate the traffic, so that the server
and the remote client both have the impression of being connected without ISDN channels
open.
Cross Reference: The white paper on Lightning's
MultiCom Software Release 2.0 can be found online at http://www.lightning.ch/products/software/ipx/details.html.
There are other router products that perform this function. One is the Ethernet
Router IN-3010/15.
Cross Reference: For further information
about the Ethernet Router IN-3010/15, visit http://www.craycom.co.uk/prodinfo/inetwork/fsin301x.htm.
What Can Be Done to Prevent IP Spoofing Attacks?
IP spoofing attacks can be thwarted by configuring your network to reject packets
from the Net that claim to originate from a local address (that is, reject packets
that purport to have an address of a workstation on your internal network). This
is most commonly done with a router.
Routers work by applying filters on incoming packets; for example, they can block
particular types of packets from reaching your network. Several companies specialize
in these devices:
NOTE: Although routers are a solution
to the general spoofing problem, they too operate by examining the source address.
Thus, they can only protect against incoming packets that purport to originate from
within your internal network. If your network (for some inexplicable reason) trusts
foreign hosts, routers will not protect against a spoofing attack that purports to
originate from those hosts.
Certain security products can also test for your vulnerability to IP spoofing.
Internet Security Systems (ISS), located online at http://iss.net, is a
company that offers such products. In fact, ISS offers a trial version that can be
used on a single local host. These tools are quite advanced.
CAUTION: If you are running a firewall,
this does not automatically protect you from spoofing attacks. If you allow internal
addresses to access through the outside portion of the firewall, you are vulnerable!
At least one authoritative source suggests that prevention can also be realized
through monitoring your network. This starts with identifying packets that purport
to originate within your network, but attempt to gain entrance at the firewall or
first network interface that they encounter on your wire:
- There are several classes of packets that you could watch for. The most basic
is any TCP packet where the network portion (Class A, B, or C or a prefix and length
as specified by the Classless Inter-Domain Routing (CIDR) specification) of the source
and destination addresses are the same but neither are from your local network. These
packets would not normally go outside the source network unless there is a routing
problem, worthy of additional investigation, or the packets actually originated outside
your network. The latter may occur with Mobile IP testing, but an attacker spoofing
the source address is a more likely cause.
Cross Reference: The previous paragraph
is excerpted from Defense Information System Network Security Bulletin #95-29. This
bulletin can be found online at ftp://nic.ddn.mil/scc/sec-9532.txt.
Other Strange and Offbeat Spoofing Attacks
Other forms of spoofing, such as DNS spoofing, exist. DNS spoofing occurs when
a DNS machine has been compromised by a cracker. The likelihood of this happening
is slim, but if it happens, widespread exposure could result. The rarity of these
attacks should not be taken as a comforting indicator. Earlier in this chapter, I
cited a DDN advisory that documented a rash of widespread attacks against DNS machines.
Moreover, an important CIAC advisory addresses this issue:
- Although you might be willing to accept the risks associated with using these
services for now, you need to consider the impact that spoofed DNS information may
have...It is possible for intruders to spoof BIND into providing incorrect name data.
Some systems and programs depend on this information for authentication, so it is
possible to spoof those systems and gain unauthorized access.
Cross Reference: The previous paragraph
is excerpted from the CIAC advisory titled "Domain Name Service Vulnerabilities."
It can be found online at http://ciac.llnl.gov/ciac/bulletins/g-14.shtml.
DNS spoofing is fairly difficult to accomplish, even if a cracker has compromised
a DNS server. One reason is that the cracker may not be able to accurately guess
what address DNS client users are going to request. Arguably, the cracker could assume
a popular address that is likely to appear (www.altavista.digital.com,
for example) or he could simply replace all address translations with the arbitrary
address of his choice. However, this technique would be uncovered very quickly.
Could a cracker implement such an attack wholesale, by replacing all translations
with his own address and still get away with it? Could he, for example, pull from
the victim's environment the address that the user really wanted? If so, what would
prevent a cracker from intercepting every outgoing transmission, temporarily routing
it to his machine, and routing it to the legitimate destination later? Is it possible
via DNS spoofing to splice yourself into all connections without being discovered?
Probably not for more than several minutes, but how many minutes are enough?
In any event, in DNS spoofing, the cracker compromises the DNS server and explicitly
alters the hostname-IP address tables. These changes are written into the translation
table databases on the DNS server. Thus, when a client requests a lookup, he or she
is given a bogus address; this address would be the IP address of a machine completely
under the cracker's control.
You may be wondering why DNS attacks exist. After all, if a cracker has already
compromised the name server on a network, what more can be gained by directing DNS
queries to the cracker's own machine? The answer lies primarily in degrees of compromise.
Compromising the name server of a network does not equal compromising the entire
network. However, one can use the system to compromise the entire network, depending
on how talented the cracker is and how lax security is on the target network. For
example, is it possible to convince a client that the cracker's machine is really
the client's local mail server?
One interesting document that addresses a possible new technique of DNS spoofing
is "Java Security: From HotJava to Netscape and Beyond," by Drew Dean,
Edward W. Felten, and Dan S. Wallach. The paper discusses a technique where a Java
applet makes repeated calls to the attacker's machine, which is in effect a cracked
DNS server. In this way, it is ultimately possible to redirect DNS lookups from the
default name server to a remote untrusted one. From there, the attacker might conceivably
compromise the client machine or network.
Cross Reference: "Java Security:
From HotJava to Netscape and Beyond" is located online at http://www.cs.princeton.edu/sip/pub/oakland-paper-96.pdf.
DNS spoofing is fairly easy to detect, however. If you suspect one of the DNS
servers, poll the other authoritative DNS servers on the network. Unless the originally
affected server has been compromised for some time, evidence will immediately surface
that it has been cracked. Other authoritative servers will report results that vary
from those given by the cracked DNS server.
Polling may not be sufficient if the originally cracked server has been compromised
for an extended period. Bogus address-hostname tables may have been passed to other
DNS servers on the network. If you are noticing abnormalities in name resolution,
you may want to employ a script utility called DOC (domain obscenity control).
As articulated in the utility's documentation:
- DOC (domain obscenity control) is a program which diagnoses misbehaving domains
by sending queries off to the appropriate domain name servers and performing a series
of analyses on the output of these queries.
Cross Reference: DOC is available online
at ftp://coast.cs.purdue.edu/pub/tools/unix/doc.2.0.tar.Z.
Other techniques to defeat DNS spoofing attacks include the use of reverse DNS schemes.
Under these schemes, sometimes referred to as tests of your forwards, the service
attempts to reconcile the forward lookup with the reverse. This technique may have
limited value, though. With all likelihood, the cracker has altered both the forward
and reverse tables.
Summary
Spoofing is popular now. What remains is for the technique to become standardized.
Eventually, this will happen. You can expect point-and-click spoofing programs to
hit the circuit within a year or so.
If you now have or are planning to establish a permanent connection to the Internet,
discuss methods of preventing purportedly internal addresses from entering your network
from the void with your router provider (or your chief network engineer). I say this
for one reason: Spoofing attacks will become the rage very soon.
© Copyright, Macmillan Computer Publishing. All
rights reserved.
|
