ch23.htm

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

be they client or server. Big vendors are likewise careful because applications that
offer remote access form the very binding thread of the Internet. If these applications
could not be trusted, the Internet would come to a grinding halt. Lastly, because
so much focus has been on remote applications (particularly by crackers who do often
crack across borders or even continents), it is rare to find a remote hole that can
result in root or even privileged access.</P>
<P>In contrast, internal applications may often be flawed. It's not that programmers
who work on internal applications are less careful than their counterparts who code
remote applications; rather, programmers who work on internal applications have a
more difficult task. For example, client/server applications are generally limited
in their scope. True, these applications may call others, but their scope is typically
limited to a handful of operations that occur outside the client/server relationship.</P>
<P>In contrast, local internal applications may be required to interface with dozens
of system utilities or processes. As I mentioned at the beginning of the book, many
don't expect these utilities or processes to have security implications. Finally,
internal applications could be coded by anybody. Third-party vendors abound for local
internal applications. Conversely, there are only so many vendors that design fully
fledged server packages for a given platform. In the UNIX community, this is especially
so. How many HTTP servers are there for UNIX? Compare this to the number of text
editors, CD-ROM utilities, and printing tools. The latter exceed the former by a
huge margin.</P>
<P>This is less so in the IBM-compatible and Macintosh communities. However, these
communities have still other problems. For example, in Windows 95, a malicious cracker
could easily attack the underlying database system by removing just a few key files.
So there is no comfortable trade-off.
<H2><FONT COLOR="#000077"><B>Gathering Information</B></FONT></H2>
<P>The internal cracker need not concern himself with complex techniques, such as
scanning, and tools. He simply needs to know the system and its holes. This is not
a complicated matter.</P>
<P>Much depends upon the type of network he is attempting to crack. However, one
thing remains universal, regardless of the platform with which he is working: known
holes. To obtain known holes, the cracker may have to do either a little research
or a lot (probably a little less now that this book exists).</P>
<P>For information about internal (and remote) holes, BUGTRAQ is a great source.
The technical level of the information available there is generally very high. Moreover,
there are often detailed analyses of tools and techniques for a wide variety of platforms.
A perfect example is a September 1996 posting by a software engineer from Indiana.
He begins his posting as follows:

<DL>
	<DD>I have successfully implemented this attack against a 3.12 server, the exploit
	is available on my web page in the Novell section. A brief explanation of the attack
	follows... The NetWare login protocol consists of three packet exchanges between
	the server and the client. First the client sends a request for a login key, the
	server generates a random eight byte value and sends it to the client. Then the client
	sends a request for the user ID of the user logging in, the server looks up the user
	ID in the bindery and sends it to the client...
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>The previous paragraph
	is excerpted from &quot;An Attack Against the NetWare Login Protocol,&quot; by G.
	Miller. It can be found online at <A HREF="http://geek-girl.com/bugtraq/1996_3/0530.html"><TT>http://geek-girl.com/bugtraq/1996_3/0530.html</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>The posting continues for about three typewritten pages, complete with diagrams
showing the methods through which keys are exchanged on a Novell NetWare login. At
the conclusion of the posting, the author leaves his WWW page address, where one
can find other tools to test (or circumvent) network security.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>Some (though not all) of Mr. Miller's
	tools are on the CD-ROM that accompanies this book. Two such tools are Miller's spoofing
	utility and his C source for attacking the Novell login procedure. 
<HR>


</BLOCKQUOTE>

<P>What is even more extraordinary about BUGTRAQ is that readers post to it with
detailed information about this or that hole. When a posting like the one referenced
previously appears, it is immediately followed by commentary from other members of
the list. Much of the time, other members take code, policy, or theory and test it
out in their own environment. This yields even further information about the discussed
attack.</P>
<P>The fact is, the majority of information posted to BUGTRAQ refers to secondary
holes that can only be exploited by local users. Tracking a few such advisories can
be instructive. Suppose we take HP-UX as an example; a search through BUGTRAQ looking
for pure security advisories or holes produces some very interesting information.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>A <I>pure</I> advisory or hole is
	any top-level posting (a posting that is the first in a series). It is quite literally
	the first mention of that particular hole. Subsequent threads can also be significant,
	but here I am simply demonstrating the nature of the data, not the value of it. 
<HR>


</BLOCKQUOTE>

<P>Have a look at a few listings:

<UL>
	<LI>December 1996: A CERT advisory is posted, reporting that the passwd utility in
	HP-UX is flawed and contains a buffer overflow weakness. The same advisory reports
	that two more programs (fpkg2swpkg and newgrp, respectively) contain similar flaws.
	The bottom line? &quot;Vulnerabilities may allow local users to gain root privileges.&quot;<BR>
	<BR>
	
	<LI>November 1996: CIAC Bulletin H-03 reports that several programs in HP-UX are
	run suid root. &quot;Using these vulnerabilities, any normal user can compromise
	security and get root access to a system or can destroy system owned files.&quot;<BR>
	<BR>
	
	<LI>October 1996: An individual posts the names of 119 programs that also run suid
	root under HP-UX, suggesting that most of them are security risks (for example, if
	any of them have buffer overflows, they offer a local cracker root access). This
	posting can be found online at <A HREF="http://geek-girl.com/bugtraq/1996_4/0004.html"><TT>http://geek-girl.com/bugtraq/1996_4/0004.html</TT></A>.<BR>
	<BR>
	
	<LI>October 1996: CIAC Bulletin G-45 reveals a weakness in HP-VUE, a windowing system
	in use on HP-UX. The result? &quot;By exploiting these vulnerabilities, a local user
	can obtain root access.&quot; This bulletin can be found online at <A HREF="http://geek-girl.com/bugtraq/1996_3/0506.html"><TT>http://geek-girl.com/bugtraq/1996_3/0506.html</TT></A>.
</UL>

<P>These types of advisories are posted each day. Many of them contain explicit instructions
for testing your state of vulnerability. These instructions generally include source
or shell code. A local cracker need not be a genius to exploit this information.
In fact, if a cracker is a subscriber of BUGTRAQ (and perhaps a dozen other public
security mailing lists), he doesn't even need to search for the information. As soon
as a vulnerability hits the wire, it is automatically mailed out to all members of
the list. If the cracker is such a member, he gets this news hot off the press. So
the information is there. This situation, therefore, breaks the local crack into
two categories or classifications:

<UL>
	<LI>The crack of opportunity<BR>
	<BR>
	
	<LI>The average crack
</UL>

<H3><FONT COLOR="#000077"><B>The Crack of Opportunity</B></FONT></H3>
<P>An opportunity crack is one that suddenly emerges. This is where the cracker has
been monitoring or at least receiving security advisories on a regular basis. He
cranks up his browser one morning and a new vulnerability is available. This situation
is very common.
<H3><FONT COLOR="#000077"><B>The Average Crack</B></FONT></H3>
<P>If an <I>average crack</I> occurs on your network, it is your fault and not the
cracker's. That is because the average crack involves exploitation of known vulnerabilities.
This brings us to an issue of some concern: Just what is a &quot;known vulnerability,&quot;
and what is the time period after which your security personnel or system administrator
should be aware of it?</P>
<P>A known vulnerability is any vulnerability that has been <I>papered</I>. Technically,
a vulnerability should not be deemed known until some authoritative source has acknowledged
it. Examples of an authoritative source would be CERT, CIAC, or the vendor. However,
you should not cast this in stone. Sometimes, vendors hide from the inevitable. They
may know the hole exists, but may stall the publication of it until a fix has been
found. Even though such a hole has not been papered, it is an existing, known vulnerability.
If it has been circulated within the cracker community, it makes little difference
whether the vendor is hiding or not. If crackers have started using the hole to exploit
systems, and if the first case of this activity has been reported to a security group,
the hole is real and known.</P>
<P>Situations like this <I>do</I> arise, and you <I>can</I> identify them. They usually
surface as follows: An individual system administrator whose site has been successfully
attacked via the hole independently posts to a security list or newsgroup. That post
is vague about the particulars but explains that the vendor was contacted. The post
indicates that the vendor said it was working on a fix and an advisory. The individual
system administrator then requests information, such as whether anyone has had similar
experiences.</P>
<P>In general, your system administrator or security personnel should know about
a papered hole within one week of its discovery. That is what they are paid to do:
Discover holes and the fixes for them. If your network gets cracked because of an
age-old hole that has been papered for more than a year, you have a problem.
<H3><FONT COLOR="#000077"><B>Extremely Local Users: Hardware Considerations</B></FONT></H3>
<P>Many companies do not pay enough attention to hardware considerations. If you
have machines that are located in such a manner that local users can tamper with
them, expect trouble. Suppose you use a (fictional) operating system called the BOG
operating system. (I hope no such operating system exists. If it does, I apologize.
I have not heard of the BOG system, in any case.) Figure 23.1 shows the construction
of this fictional operating system.</P>
<P><A NAME="01"></A><A HREF="01.htm"><B>FIGURE 23.1.</B></A> <BR>
<I>The fictional BOG system network.</I></P>
<P>This figure shows a three-station network consisting of a server and two workstations.
Suppose the BOG operating system has strong access control; the access control is
so strong that the user on Workstation 2 (who has high access privileges) has files
located on the drive of Workstation 1. These files can be accessed only by Workstation
2 or root. In other words, a portion of Workstation 1's drive is owned by Workstation
2 and root.</P>
<P>Say Workstation 1 operates on a SCSI drive that is attached to an adapter (or
even on board, if you like). The system administrator has installed software that
prevents any user from booting from a floppy disk. The SCSI disk is attached to the
desk via a locking device (these are common. I see a lot of them on Mac networks).
The BOG operating system boots directly to a login prompt, and the local single user
password has been disabled. It's a pretty tight setup.</P>
<P>Now suppose Workstation 1 is located in a room on its own. Well, that's it then;
all the security measures are for naught. The user can tamper with the equipment
without fear of being discovered. As long as a user can chain an additional disk
to the SCSI adapter, he can circumvent this security. He may not be able to do it
using a disk loaded with the BOG operating system, though; he may have to use another.
To demonstrate, assume Workstation 1 is running Windows NT. Assume the user brings
in a SCSI disk loaded with Linux and changes the SCSI ID numbers so the adapter catches
the Linux disk first. No further effort need be made. The Linux disk will boot to
a login prompt, and the user logs in as root. At the time of boot, Linux will catch
the other partition. The user need only mount the NT partition in the local (Linux)
directory of his choice. The Linux user is root, after all. He can do anything. A
True Story: The system administrator for a Windows for Workgroups network with third-party
access control installed was baffled by changes in the file system. He had a logging
utility, but the logs showed very little activity that could be deemed suspicious.
After a few weeks, the system administrator placed a bogus database file in a directory
and waited for someone to take the bait. The database file had a password to another
portion of the network, where a few old, tired NetWare legacy machines were located.
On the Novell box in question, the system administrator logged heavily. Evidence
surfaced that someone had indeed logged in using the bait ID, but for whatever reason,
the system administrator could not determine the identity of the user.</P>
<P>Here comes the good part: I get called in on a Sunday morning to take a look.
After hours of trying to determine the problem, I discovered a hidden directory on
one machine. In that directory were several files, including <TT>gzip.exe</TT> and
<TT>rawrite</TT>, and a hidden batch file. In the batch file were commands to load
a Linux file system. After seeing this, I rebooted the machine and went into CMOS.
Then, I proceeded to kick myself several times. CMOS reported a second disk. I rebooted