ch28.htm

Maximum Security (First Edition) 网络安全 英文版

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.)</P>
<P>Machines within a network segment that are aware of the addresses of their pals
are referred to as machines that <I>trust</I> 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.</P>
<P>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.
<H3><FONT COLOR="#000077"><B>Anatomy of an IP Spoofing Attack</B></FONT></H3>
<P>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 <I>Nexus</I>, is shown in Figure 28.1.</P>
<P><A NAME="01"></A><A HREF="01.htm"><B>FIGURE 28.1.</B></A> <I><BR>
Overview of Nexus segment.</I></P>
<P>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:

<UL>
	<LI>He can spoof either Nexus 1 or Nexus 3, claiming to be Nexus 2<BR>
	<BR>
	
	<LI>He can spoof Nexus 2, claiming to be either Nexus 1 or Nexus 3
</UL>

<P>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.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>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. 
<HR>


</BLOCKQUOTE>

<H4><FONT COLOR="#000077"><B>Step One: Putting Nexus 3 to Sleep</B></FONT></H4>
<P>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).</P>
<P>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.</P>
<P>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<I> syn_flooding</I>.</P>
<P>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 <I>down</I>,
or unreachable; it will not respond to requests sent by Nexus 2.
<H4><FONT COLOR="#000077"><B>Step Two: Discovering Nexus 2's Sequence Number</B></FONT></H4>
<P>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.</P>
<P>Nexus 2 generates a series of <I>sequence numbers</I>. Chapter 6, &quot;A Brief
Primer on TCP/IP,&quot; mentioned that sequence numbers are used in TCP/IP to mark
and measure the status of a session. An articled titled &quot;Sequence Number Attacks&quot;
by Rik Farrow articulates the construct of the sequence number system. Farrow explains:

<DL>
	<DD>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...
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>Find &quot;Sequence Number
	Attacks&quot; by Rik Farrow online at <A HREF="http://www.wcmh.com/uworld/archives/95/security/001.txt.html"><TT>http://www.wcmh.com/uworld/archives/95/security/001.txt.html</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>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 &quot;A Weakness in the 4.2BSD UNIX TCP/IP Software&quot;:

<DL>
	<DD>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 <TT>ESTABLISHED</TT>
	state.
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>Find Morris's article
	online at <A HREF="ftp://ftp.research.att.com/dist/internet_security/117.ps.Z"><TT>ftp://ftp.research.att.com/dist/internet_security/117.ps.Z</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>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.
<H4><FONT COLOR="#000077"><B>Driving Blind</B></FONT></H4>
<P>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.</P>
<P>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 <TT>ESTABLISHED</TT>
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.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>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. 
<HR>


</BLOCKQUOTE>

<P>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.
<H4><FONT COLOR="#000077"><B>Opening a More Suitable Hole</B></FONT></H4>
<P>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 <TT>.rhosts</TT> file so
that Nexus 2 will accept connections from any source without requiring additional
authentication.</P>
<P>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.
<H3><FONT COLOR="#000077"><B>How Common Are Spoofing Attacks?</B></FONT></H3>
<P>Spoofing attacks are rare, but they do occur. Consider this Defense Data Network
advisory from July, 1995:

<DL>
	<DD>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.
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>To view the DDN bulletin
	online, visit <A HREF="ftp://nic.ddn.mil/scc/sec-9532.txt"><TT>ftp://nic.ddn.mil/scc/sec-9532.txt</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>The attack documented by John Markoff in <I>The New York Times</I> 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.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>One of these individuals
	posted to a well-known security list with the subject line &quot;Introducing in the
	Left Corner: Some Spoofing Code.&quot; 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 <A HREF="http://main.succeed.net/~coder/spoofit/spoofit.html"><TT>http://main.succeed.net/~coder/spoofit/spoofit.html</TT></A>.<BR>
	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. 
<HR>


</BLOCKQUOTE>

<P>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.</P>
<P>Spoofing is sometimes purposely performed by system administrators. This type
of spoofing, however, varies considerably from typical IP spoofing. It is referred
to as <I>LAN spoofing</I> or <I>WAN spoofing</I>. These techniques are used primarily
to hold together disparate strings of a WAN (see Figure 28.2).</P>
<P><A NAME="02"></A><A HREF="02.htm"><B>FIGURE 28.2.</B></A> <I><BR>
LAN and WAN spoofing in action.</I></P>
<P>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).</P>
<P>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.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>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
	&quot;Network Spoofing: Is Your WAN on the Wane? LAN Spoofing May Help Solve Some
	of Your Woes,&quot; can be viewed online at <A HREF="http://www.byte.com/art/9412/sec13/art4.htm"><TT>http://www.byte.com/art/9412/sec13/art4.htm</TT></A>.
	Fritz also wrote the book <I>Sensible ISDN Data Applications</I>, published by West
	Virginia University Press. This book is a must read for ISDN users. 
<HR>


</BLOCKQUOTE>

<P>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: