ch25.htm

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

party. That this would happen, however, is quite unlikely, especially if the cracker
staggers his gateways. In other words, if the cracker intends to do any of this type
of work "by hand," he should really do each finger query from a different
gateway. Because there are 3,000+ finger gateways currently on the Web, this is not
an unreasonable burden. Furthermore, if I were doing the queries, I would set them
apart by several minutes (or ideally, several hours).


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>One technique involves the redirection
	of a finger request. This is where the cracker issues a raw finger request to one
	finger server, requesting information from another. This is referred to as <I>forwarding</I>
	a finger request. The syntax of such a command is <I><TT>finger</TT></I><TT> <I>user</I>@real_target.com@someother_host.com</TT>.
	For example, if you wanted to finger a user at <I>primenet.com</I>, you might use<I>
	</I><TT>deltanet.com</TT>'s finger service to forward the request. However, in today's
	climate, most system administrators have finger forwarding turned off. 
<HR>


</BLOCKQUOTE>

<H2><FONT COLOR="#000077"><B>The Operating System</B></FONT></H2>
<P>You may have to go through various methods (including but not limited to those
described in the preceding section) to identify the operating system and version
being used on the target network. In earlier years, one could be pretty certain that
the majority of machines on a target network ran similar software on similar hardware.
Today, it is another ball game entirely. Today, networks may harbor dozens of different
machines with disparate operating systems and architecture. One would think that
for the cracker, this would be a hostile and difficult-to-manage environment. Not
so.</P>
<P>The more diverse your network nodes are (in terms of operating system and architecture),
the more likely it is that a security hole exists. There are reasons for this, and
while I do not intend to explain them thoroughly, I will relate at least this: Each
operating system has its own set of bugs. Some of these bugs are known, and some
may be discovered over time. In a relatively large network, where there may be many
different types of machines and software, you have a better chance of finding a hole.
The system administrator is, at day's end, only a human being. He cannot be constantly
reviewing security advisories for each platform in turn. There is a strong chance
that his security knowledge of this or that system is weak.</P>
<P>In any event, once having identified the various operating systems and architectures
available at the target, the next step is study. A checklist should be made that
lists each operating system and machine type. This checklist will assist you tremendously
as you go to the next step, which is to identify all known holes on that platform
and understand each one.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>Some analysts might make the argument
	that tools like ISS and SATAN will identify all such holes automatically and, therefore,
	research need not be done. This is erroneous, for several reasons. First, such tools
	may not be complete in their assessment. Here is why: Although both of the tools
	mentioned are quite comprehensive, they are not perfect. For example, holes emerge
	each day for a wide range of platforms. True, both tools are extensible, and one
	can therefore add new scan modules, but the scanning tools that you have are limited
	to the programmer's knowledge of the holes that existed at the time of the coding
	of the application.</P>
	<P>Therefore, to make a new scanning module to be added to these extensible and malleable
	applications, you must first know that such new holes exist. Second, and perhaps
	more importantly, simply knowing that a hole exists does not necessarily mean that
	you can exploit it--you must first understand it. (Unless, of course, the hole is
	an obvious and self-explanatory one, such as the <TT>-froot</TT> rlogin problem on
	some versions of the AIX operating system. By initiating an rlogin session with the
	<TT>-froot</TT> flags, you can gain instant privileged access on many older AIX-based
	machines.) For these reasons, hauling off and running a massive scan is a premature
	move. 
<HR>


</BLOCKQUOTE>

<P>To gather this information, you will need to visit a few key sites. The first
such site you need to visit is the firewalls mailing list archive page.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>The firewalls mailing
	list archive page can be found online at <A HREF="http://www.netsys.com/firewalls/ascii-index.html"><TT>http://www.netsys.com/firewalls/ascii-index.html</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>You may initially wonder why this list would be of value, because the subject
discussed is firewall-related. (Remember, we began this chapter with the presumption
that the target was not running a firewall.) The firewalls list archive is valuable
because it is often used--over the objections of many list members--to discuss other
security-related issues. Another invaluable source of such data is BUGTRAQ, which
is a searchable archive of known vulnerabilities on various operating systems (though
largely UNIX.)


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>BUGTRAQ is located online
	at <A HREF="http://www.geek-girl.com/bugtraq/search.html"><TT>http://www.geek-girl.com/bugtraq/search.html</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>These searchable databases are of paramount importance. A practical example will
help tremendously at this point. Suppose that your target is a machine running AIX.
First, you would go to the ARC Searchable WAIS Gateway for DDN and CERT advisories.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>The ARC Searchable WAIS
	Gateway for DDN and CERT advisories can be found online at <A HREF="http://info.arc.com/sec_bull/sec_bullsearch.html"><TT>http://info.arc.com/sec_bull/sec_bullsearch.html</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>Figure 25.2 shows how the WAIS gateway at this site is configured.</P>
<A NAME="02"></A><P><B><A HREF="02.htm">FIGURE 25.2.</A></B> <I><BR>
The WAIS gateway at </I><TT>ARC.COM</TT><I> for searching security advisories.</I></P>
<P>At the bottom of that page is an input field. Into it, I entered the search term
<TT>AIX</TT>. The results of that search produced a laundry list of AIX vulnerabilities.
(See Figure 25.3.)</P>
<A NAME="03"></A>
<P><B><A HREF="03.htm">FIGURE 25.3.</a></B> <I><BR>
A laundry list of AIX vulnerabilities from the WAIS gateway.</I></P>
<P>At this stage, you can begin to do some research. After reading the initial advisory,
if there is no more information than a simple description of the vulnerability, do
not despair. You just have to go to the next level. The next phase is a little bit
more complex. After identifying the most recent weakness (and having read the advisory),
you must extract from that advisory (and all that follow it) the commonly used, often
abbreviated, or &quot;jargon,&quot; name for the hole. For example, after a hole
is discovered, it is often referred to by security folks with a name that may not
reflect the entire problem. (An example would be &quot;the Linux telnetd problem&quot;
or &quot;AIX's froot hole&quot; or some other, brief term by which the hole becomes
universally identified.) The extraction process is quickly done by taking the ID
number of the advisory and running it through one of the abovementioned archives
like BUGTRAQ or Firewalls. Here is why:</P>
<P>Typically, when a security professional posts either an exploit script, a tester
script (tests to see if the hole exists) or a commentary, they will almost always
include complete references to the original advisory. Thus, you will see something
similar to this in their message: <TT>Here's a script to test if you are vulnerable
to the talkd problem talked about in CA-97.04.</TT>.</P>
<P>This message is referring to CERT Advisory number 97.04, which was first issued
on January 27, 1997. By using this number as a search expression, you will turn up
all references to it. After reading 10 or 12 results from such a search, you will
know what the security crowd is calling that hole. After you have that, you can conduct
an all-out search in all legitimate and underground database sources to get every
shred of information about the hole. You are not looking for initial postings in
particular, but subsequent, trailing ones. (Some archives have an option where you
can specify a display by thread; these are preferred. This allows you to see the
initial posting and all subsequent postings about that original message; that is,
all the &quot;re:&quot; follow-ups.) However, some search engines do not provide
for an output in threaded form; therefore, you will simply have to rake through them
by hand.</P>
<P>The reason that you want these follow-ups is because they usually contain exploit
or test scripts (programs that automatically test or simulate the hole). They also
generally contain other technical information related to the hole. For example, one
security officer might have found a new way to implement the vulnerability, or might
have found that an associated program (or include file or other dependency) may be
the real problem or even a great contributor to the hole. The thoughts and reflections
of these individuals are pure gold, particularly if the hole is a new one. These
individuals are actually doing all the work for you: analyzing and testing the hole,
refining attacks against it, and so forth.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>TIP:</B></FONT><B> </B>Many exploit and test scripts are
	posted in standard shell or C language and are therefore a breeze to either reconfigure
	for your own system or compile for your architecture. In most instances, only minimal
	work has to be done to make them work on your platform. 
<HR>


</BLOCKQUOTE>

<P>So, to this point, you have defined a portion (or perhaps all) of the following
chief points:

<UL>
	<LI>Who the administrator is<BR>
	<BR>
	
	<LI>The machines on the network, and perhaps their functions and domain servers<BR>
	<BR>
	
	<LI>Their operating systems<BR>
	<BR>
	
	<LI>Their probable holes<BR>
	<BR>
	
	<LI>Any discussion by the administrator about the topology, management, policies,
	construction, or administration of the network
</UL>

<P>Now you can proceed to the next step.</P>
<P>One point of interest: It is extremely valuable if you can also identify machines
that may be co-located. This is, of course, strictly in cases where the target is
an Internet service provider (ISP). ISPs often offer deals for customers to co-locate
a machine on their wire. There are certain advantages to this for the customer. One
of them is cost. If the provider offers to co-locate a box on its T3 for, say, $600
a month, this is infinitely less expensive than running a machine from your own office
that hooks into a T1. A T1 runs about $900-$1,200 monthly. You can see why co-location
is popular: You get speeds far faster for much less money and headache. For the ISP,
it is nothing more than plugging a box into its Ethernet system. Therefore, even
setup and administration costs are lower. And, perhaps most importantly of all, it
takes the local telephone company out of the loop. Thus, you cut even more cost,
and you can establish a server immediately instead of waiting six weeks.</P>
<P>These co-located boxes may or may be not be administrated by the ISP. If they
are not, there is an excellent chance that these boxes may either have (or later
develop) holes. This is especially likely if the owner of the box employs a significant
amount of CGI or other self-designed program modules that the ISP has little or no
control over. By compromising that box, you have an excellent chance of bringing
the entire network under attack, unless the ISP has purposefully strung the machine
directly to its own router, a hub (or instituted some other procedure of segmenting
the co-located boxes from the rest of the network.)


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>This can be determined to some degree
	using traceroute or whois services. In the case of traceroute, you can identify the
	position of the machine on the wire by examining the path of the traced route. In
	a whois query, you can readily see whether the box has its own domain server or whether
	it is using someone else's (an ISP's). 
<HR>