ch19.htm

来自「Maximum Security (First Edition) 网络安全 英文」· HTM 代码 · 共 931 行 · 第 1/3 页

	<LI><I>Mode.</I> This is an interesting feature. You can specify the mode in which
	a user can connect and interact with the system. Therefore, you can restrict remote
	network logins to certain times or eliminate them completely. Because this can be
	done incisively by user, this feature makes remote security much stronger than on
	many other platforms. You can hardly begin to crack if you are restricted from even
	logging in. (Next, we'll discuss some utilities that also force callback verification
	on remote dial-up users.)<BR>
	<BR>
	
	<LI><I>Resources.</I> You can control the resources available to the user at login.
	This is useful for setting directories beyond which the user may not be able to travel.
</UL>

<P>This is really just scratching the surface of the access control available in
VMS. In fact, there are multiple levels of privileges, and these can be applied to
groups. Groups can be restricted to certain resources, and so on. In other words,
access control is a complex issue with VMS. There are many, many options. It is for
this reason that crackers have a halfway decent chance of finding a hole. Sometimes,
complexity can be a security risk in itself. Crackers are well aware of this:

<DL>
	<DD>The greatest advantage of VMS is its flexibility. The system manager can choose
	to implement or ignore a wide range of security features, fortunately for the [cracker],
	they all seem to ignore the important ones. It is possible to protect all, any or
	none of the files created. It is also possible to provide general or restricted passwords,
	or no passwords at all. Access codes can be global or limited. The use log can be
	ignored, used only for record keeping, or be employed as a security control tool.
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>The previous paragraph
	is excerpted from Lex Luthor's &quot;Advanced Hacking VAX's VMS&quot; (<I>Legion
	of Doom</I>, June 1, 1985). It can be found online at <A HREF="http://www.mdc.net/~trent/hackvax.txt"><TT>http://www.mdc.net/~trent/hackvax.txt</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>This document is one of the definitive texts on cracking the VMS system. It was
authored by Lex Luthor (an alias, of course), who in 1984 established a bulletin
board called the Legion of Doom. From this (and through other means) Luthor gathered
together a loosely knit cracker group that went by the same name. Legion of Doom
(or LoD, as they are more commonly referred to) pulled off some of the most extraordinary
cracks ever done. LoD published many electronic journals on the Internet that simplified
the art of cracking, including the LoD Technical Journal. The federal government
waged a fleetingly successful war against members of the group. Today, former LoD
members are a little piece of Internet folklore.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>Perhaps one of the best
	documents available on the Internet for information on how to secure a VMS box was
	written by neither a cracker nor a hacker: Rob McMillan, &quot;A Practical Exercise
	in Securing an OpenVMS System,&quot; Prentice Centre, The University Of Queensland,
	<A HREF="http://nsi.org/Library/Compsec/openvms.txt"><TT>http://nsi.org/Library/Compsec/openvms.txt</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>Attacking a VAX (or any VMS-based system) is quite different from attacking a
UNIX system. First, the concept of the password file is different and so is its structure.
UNIX systems maintain <TT>/etc/passwd</TT>, which defines the username, password,
login shell, and group. In contrast, the VMS system uses a file that defines many
other variables, not simply these values:

<DL>
	<DD>Every DEC running VMS holds the user profiles in a file called SYSUAF (System
	User Authorization File). For every user on the system, including the System Manager,
	there is a record which tells the computer when and how a user can log onto the system.
	It also gives details of password aging, password lengths and all the facilities
	that a user has when they are logged on.
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>The previous paragraph
	is excerpted from &quot;The Five Minute Guide to VMS Security: Product Review PC-DEC-AUDIT&quot;
	(<I>AudIT Magazine</I>, 1994). It can be found online at <A HREF="http://www.trillion.demon.co.uk/magrev.htm"><TT>http://www.trillion.demon.co.uk/magrev.htm</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>Note that this &quot;comprehensive&quot; approach to the password file has its
pitfalls. One is this: If a cracker gains access to the file and cracks it (using
the utilities described later in this chapter), the whole system is subject to breach,
then and there. However, the likelihood of that happening is poor.</P>
<P>The user, by the way, is identified through the use of a user identification code
(UIC). This is very similar in ways to the GID in UNIX. It identifies the user and
what groups that user may belong to. As you might have guessed, the UIC comes from
the centralized database:

<DL>
	<DD>When you log in to a system, the operating system copies your UIC from your user
	authorization (UAF) record in the system user authorization file (SYSUAF.DAT) and
	assigns it to your process. It serves as an identification for the life of the process.
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>The previous paragraph
	is excerpted from &quot;OpenVMS Guide to System Security: Contents of a User's Security
	Profile. 4.1.1.3 How Your Process Acquires a UIC,&quot; which can be found online
	at <A HREF="http://wawona.ethz.ch/OpenVMS_docu/ssb71/6346/6346p004.htm#heading_4.1.1"><TT>http://wawona.ethz.ch/OpenVMS_docu/ssb71/6346/6346p004.htm#heading_4.1.1</TT></A>.
	
<HR>


</BLOCKQUOTE>

<H2><FONT COLOR="#000077"><B>Some Old Holes</B></FONT></H2>
<P>Following is a discussion of some common holes.
<H3><FONT COLOR="#000077"><B>The Mountd Hole</B></FONT></H3>
<P>If two successive <TT>mount -d -s</TT> commands are sent within seconds of one
another (and before another host has issued such a request), the request will be
honored. This was originally reported by CERT in March 1994 and applies to VAX machines
running any variant of Digital UNIX.
<H3><FONT COLOR="#000077"><B>The Monitor Utility Hole</B></FONT></H3>
<P>In VMS there is a utility called Monitor. The purpose of the program is to monitor
classes of systemwide performance data (either from a process already running or
from a previously compiled monitor file). The hole was not a critical one, but did
bear some concern:

<DL>
	<DD>Unauthorized privileges may be expanded to authorized users of a system under
	certain conditions, via the Monitor utility. Should a system be compromised through
	unauthorized access, there is a risk of potential damage to a system environment.
	This problem will not permit unauthorized access entry, as individuals attempting
	to gain unauthorized access will continue to be denied through the standard VMS security
	mechanisms.
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>The previous paragraph
	is excerpted from a CERT advisory titled &quot;VMS Monitor Vulnerability.&quot; It
	can be found online at <A HREF="http://www.arc.com/database/Security_Bulletins/CERT/CA-92:16.VMS.Monitor.vulnerability"><TT>http://www.arc.com/database/Security_Bulletins/CERT/CA-92:16.VMS.Monitor.vulnerability</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>This was a local problem and not a particularly critical one. For specific information
on that hole (and the fix), obtain the Defense Data Network Advisory concerning it.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>The Defense Data Network
	Advisory concerning this hole is located at DDN Security Bulletin 9223, <A HREF="ftp://nic.mil/scc/sec-9223.txt"><TT>ftp://nic.mil/scc/sec-9223.txt</TT></A>.
	
<HR>


</BLOCKQUOTE>

<H3><FONT COLOR="#000077"><B>Historical Problems: The Wank Worm Incident</B></FONT></H3>
<P>Sometime in September or October 1989, a worm was released that compromised machines
on DecNet. On infected machines, the program would print to the terminal a message
relating that the machine had been &quot;Wanked.&quot; The message purported to come
from Worms Against Nuclear Killers, or WANK. It was reported in the CERT advisory
about the Wank Worm:

<DL>
	<DD>This worm affects only DEC VMS systems and is propagated via DecNet protocols,
	not TCP/IP protocols. If a VMS system had other network connections, the worm was
	not programmed to take advantage of those connections. The worm is very similar to
	last year's HI.COM (or Father Christmas) worm.
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>The previous paragraph
	is excerpted from a CERT advisory titled &quot;`WANK' Worm On SPAN Network.&quot;
	It can be found online at <A HREF="http://www.arc.com/database/Security_Bulletins/CERT/CA-89:04.decnet.wank.worm"><TT>http://www.arc.com/database/Security_Bulletins/CERT/CA-89:04.decnet.wank.worm</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>In that advisory, an analysis of the worm was provided by R. Kevin Oberman of
the Engineering Department of Lawrence Livermore National Laboratory. Oberman's report
was apparently generated on-the-fly and in haste, but it was quite complete notwithstanding.
He reported that the worm was not incredibly complex but could be dangerous if it
compromised a privileged account. The worm would enter a system, check to see if
it was already infected, and if not, perform some or all of these procedures:

<UL>
	<LI>Disable mail to certain accounts<BR>
	<BR>
	
	<LI>Change system passwords, using a random-number generator, and in doing so, lock
	out the system operator<BR>
	<BR>
	
	<LI>Use the instant system as a launching pad to attack new ones
</UL>

<P>Oberman included within his analysis a quickly hacked program that would halt
the march of the Wank Worm. The source of that program can still be examined online
in the original advisories.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>The main advisory, issued
	by CERT is located at <A HREF="http://www.arc.com/database/Security_Bulletins/CERT/CA-89:04.decnet.wank.worm"><TT>http://www.arc.com/database/Security_Bulletins/CERT/CA-89:04.decnet.wank.worm</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>What's really interesting is the degree of seriousness in the tone of the advisory.
Think about it for a moment. It was just less than one year before that the Morris
Worm incident sent a ripple through the Net. The mere mention of a worm during those
months could cause a panic. Oddly, though, because of the curious name of this particular
worm, some administrators initially took the warnings for a joke.</P>
<P>Also, the Wank Worm was irrelevant to a large portion of the Internet. Since the
worm only affected those running DEC protocols (and not TCP/IP), only a limited number
of potential victims existed. However, while that number was relatively small in
proportion to the entire Internet, there were a great many sites using DecNet.</P>
<P>An interesting treatment of the event can be found in &quot;Approaching Zero:
The Extraordinary Underworld of Hackers, Phreakers, Virus Writers, and Keyboard Criminals&quot;:

<DL>
	<DD>The arrival of the worm coincided with reports of protesters in Florida attempting
	to disrupt the launch of a nuclear-powered shuttle payload. It is assumed that the
	worm was also a protest against the launch. The WANK Worm spread itself at a more
	leisurely rate than the Internet Worm, sending out fewer alarms and creating less
	hysteria....A method for combating the worm was developed by Bernard Perrot of the
	Institut de Physique Nucleaire at Orsay, France. Perrot's scheme was to create a
	booby-trapped file of the type that the worm could be expected to attack. If the
	worm tried to use information from the file, it would itself come under attack and
	be blown up and killed.
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>The previous excerpt
	is from an article by Paul Mungo and Bryan Glough titled &quot;Approaching Zero:
	The Extraordinary Underworld of Hackers, Phreakers, Virus Writers, and Keyboard Criminals.&quot;
	It can be found online at <A HREF="http://www.feist.com/~tqdb/h/aprozero.txt"><TT>http://www.feist.com/~tqdb/h/aprozero.txt</TT></A>.
	
<HR>


</BLOCKQUOTE>

<H2><FONT COLOR="#000077"><B>Audits and Monitoring</B></FONT></H2>
<P>Auditing capabilities in the VMS environment are advanced. There are different
ways to implement auditing and this is basically a matter of the system operator's
taste. However, by default, VMS will log all logins, failures to log in, changes
in system privileges, and so forth. The default configuration provides a minimum
of logging.</P>
<P>That minimum, however, can be quickly surpassed if need be. The system operator
can apply special access controls on individual files and directories, a user account,
or processes. When undesirable or suspicious activity occurs in relation to these
access control policies, an alarm is generated. The system operator defines what
form the alarm will take. (For example, it is common for system operators to redirect
alarm information to a specific console so that such messages visibly appear and
can be quickly perused at any time.) Of course, severe paranoia in this type of environment
can add up to sacrificing a fair amount of disk space. For example, a system operator
can even have the system generate alarms on a mere attempt to access a file for which
the user has no privileges.</P>
<P>An example would be where a user attempted to view (or list) a file for which
he had no privileges. It would be the equivalent of issuing an alarm for each time
a shell user on a UNIX system tried accessing a root-owned file or directory. One
interesting thing about this is that the alarm can be generated in response to a
violation of policies set against the user, as opposed to global restrictions placed
on the file. I am not sure which model is actually more secure, but I would guess
it would be the VMS model.</P>
<P>The logging capabilities of VMS are quite granular. You can monitor almost anything
from users accessing a file to them starting a protocol-based process. (You can even
log users attempting to change the time.) In addition to this native monitoring,
there are several utilities (some of which I mention later in the chapter) that can
trap terminal sessions and monitor them for inactivity and perhaps other undesirable
behavior.</P>
<P>Various utilities make it easier to crack the VMS platform or, having cracked
it, to avoid detection. As with any other system, these utilities are sometimes of
significant advantage to both the root operator and the cracker.
<H3><FONT COLOR="#000077"><B>watchdog.com</B></FONT></H3>