ch29.htm

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

<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B><TT>libc</TT> is the standard C
	library. A full distribution of <TT>libc</TT> commonly contains header and include
	files for use in C programming. All UNIX flavors have (or should have) this library
	installed. It is a requisite for compiling programs written in the C programming
	language. 
<HR>


</BLOCKQUOTE>

<P>As Sam Hartman of MIT notes in his article &quot;Telnet Vulnerability: Shared
Libraries&quot;:

<DL>
	<DD>The problem is that telnetd will allow the client to pass LD_LIBRARY_PATH, LD_PRELOAD,
	and other run-time linker options into the process environment of the process that
	runs login.
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>Find Hartman's article
	on the Web at <A HREF="http://geek-girl.com/bugtraq/1995_4/0032.html"><TT>http://geek-girl.com/bugtraq/1995_4/0032.html</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>By passing the <TT>LD_LIBRARY_PATH</TT> environment option to the server, the
cracker can add to this search path a custom directory (and therefore a custom library).
This can alter the dynamic linking process, greatly increasing the chances of a root
compromise.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>Hartman noted that if the target
	was using a Kerberos-aware telnetd, only users with a valid account on the remote
	box could actually implement the attack. My guess, however, is that the larger majority
	of machines out there are not using such a means of secure Telnet. 
<HR>


</BLOCKQUOTE>

<P>One interesting note about this hole: It was determined that one could identify
Telnet sessions in which the environment variables had been passed by executing a
<TT>ps</TT> instruction. However, one individual (Larry Doolittle) determined that
on certain flavors of UNIX (Linux, specifically), one has to be root to ID those
processes. In response to the Hartman report, Doolittle advised:

<DL>
	<DD>Recent Linux kernels do not allow access to environment strings via ps, except
	for the user him/herself. That is, /proc/*/environ is protected 400. This could confuse
	people reading your instructions, since they would see environments for their own
	process but not root's. To verify environment strings of login, you need to run ps
	as root.
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>Find Larry Doolittle's
	article on the Web at <A HREF="http://geek-girl.com/bugtraq/1995_4/0042.html"><TT>http://geek-girl.com/bugtraq/1995_4/0042.html</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>Here are patches for various distributions of telnetd:

<UL>
	<LI>DEC. (OSF/1):
</UL>


<DL>
	<DD><A HREF="ftp://ftp.service.digital.com/public/osf/v3.2c/ssrt0367_c032"><TT>ftp://ftp.service.digital.com/public/osf/v3.2c/ssrt0367_c032</TT></A>
</DL>


<UL>
	<LI>A compressed version is available at
</UL>


<DL>
	<DD><A HREF="ftp://ftp.ox.ac.uk/pub/comp/security/software/patches/telnetd/"><TT>ftp://ftp.ox.ac.uk/pub/comp/security/software/patches/telnetd/</TT></A>
</DL>


<UL>
	<LI>Linux:
</UL>


<DL>
	<DD><A HREF="ftp://ftp.ox.ac.uk/pub/comp/security/software/patches/telnetd/linux/telnetd"><TT>ftp://ftp.ox.ac.uk/pub/comp/security/software/patches/telnetd/linux/telnetd</TT></A>
</DL>


<UL>
	<LI>Red Hat:
</UL>


<DL>
	<DD><TT>h</TT><A HREF="ttp://www.io.com/~ftp/mirror/linux/redhat/redhat/updates/i386/NetKit-B-0.09-1.1.i386.rpm"><TT>ttp://www.io.com/~ftp/mirror/linux/redhat/redhat/updates/i386/NetKit-B-0.09-1.1.i386.rpm</TT></A>
</DL>


<UL>
	<LI>SGI (IRIX):
</UL>


<DL>
	<DD><A HREF="ftp://sgigate.sgi.com/security/"><TT>ftp://sgigate.sgi.com/security/</TT></A>
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>Although patches have been issued
	for this problem, some other Telnet-related modules and programs may still be affected.
	As late as February, 1997, <TT>in.telnetsnoopd</TT> was reported as vulnerable to
	the <TT>LD_PRELOAD</TT> passing on some platforms, including Linux. There is reportedly
	a patch for this problem, and it has been uploaded to <TT>ftp://sunsite.unc.edu</TT>.
	
<HR>


</BLOCKQUOTE>

<P>Garden-variety Telnet is not a particularly secure protocol. One can easily eavesdrop
on Telnet sessions. In fact, there is a utility, called ttysnoop, designed for this
purpose. As describe by its author, Carl Declerck:

<DL>
	<DD>[ttynsoop] allows you to snoop on login tty's through another tty-device or pseudo-tty.
	The snoop-tty becomes a &quot;clone&quot; of the original tty, redirecting both input
	and output from/to it.
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>Declerck's <TT>README</TT>
	for ttysnoop 0.12 (alpha) can be found on the Web at <A HREF="http://ion.apana.org.au/pub/linux/sources/admin/ttysnoop-0.12.README"><TT>http://ion.apana.org.au/pub/linux/sources/admin/ttysnoop-0.12.README</TT></A><BR>
	
<HR>
</P>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>ttysnoop is not simply a Telnet-specific
	snooper; it snoops on the tty, not the Telnet protocol. A network sniffer like sniffit
	can also be used (and is probably more suitable) to sniff the Telnet protocol. 
<HR>


</BLOCKQUOTE>

<P>Telnet sessions are also especially sensitive. One reason for this is that these
sessions are often conducted in an island-hopping pattern. That is, the user may
Telnet to one network to tidy his or her Web page; from there, the user may Telnet
to another machine, and another machine, and so on. If a cracker can snoop on such
a session, he or she can obtain login IDs and passwords to other systems.
<H3><FONT COLOR="#000077"><B>Aren't These Attacks No Longer Effective?</B></FONT></H3>
<P>No; this is due primarily to a lack of education. The environment option attack
described previously is quite effective on many systems in the void. This is so even
though advisories about the attack are readily available on the Internet.
<H3><FONT COLOR="#000077"><B>Telnet as a Weapon</B></FONT></H3>
<P>Telnet is an interesting protocol. As explained earlier, one can learn many things
using Telnet. For example, you can cull what version of the operating system is being
run. Most distributions of UNIX will report this information on connection. It is
reported by at least one authoritative source that various scanners use the issue
information at connect to identify the type of system (SATAN being one such scanner).
The operating system can generally be determined by attacking any of these ports:

<UL>
	<LI>Port 21: FTP
	<LI>Port 23: Telnet (Default)
	<LI>Port 25: Mail
	<LI>Port 70: Gopher
	<LI>Port 80: HTTP
</UL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE: </B></FONT>Although I have only listed five ports,
	one can connect to the majority of TCP/IP ports by initiating a Telnet session. Some
	of these ports will remain in an entirely passive state while the connection is active,
	and the user will see nothing happen in particular. This is so with port 80 (HTTP),
	for example. However, you can issue perfectly valid requests to port 80 using Telnet
	and if those requests are valid, port 80 will respond. (The request needn't necessarily
	be valid. Issuing an erroneous <TT>GET</TT> instruction will elicit a lively response
	from the Web server if the request is sufficiently malformed.) 
<HR>


</BLOCKQUOTE>

<P>In their now-famous paper, &quot;Improving the Security of Your Site by Breaking
Into It,&quot; Dan Farmer and Wietse Venema point out ports that can be attacked.
Specifically, they address the issue of port 6000:

<DL>
	<DD>X windows is usually on port 6000...If not protected properly (via the magic
	cookie or xhost mechanisms), window displays can be captured or watched, user keystrokes
	may be stolen, programs executed remotely, etc. Also, if the target is running X
	and accepts a Telnet to port 6000, that can be used for a denial of service attack,
	as the target's windowing system will often &quot;freeze up&quot; for a short period
	of time.
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>&quot;Improving the Security
	of Your Site by Breaking Into It&quot; can be found on the Web at <A 
HREF="http://stos-www.cit.cornell.edu/Mark_html/Satan_html/docs/admin_guide_to_cracking.html"><TT>http://stos-www.cit.cornell.edu/Mark_html/Satan_html/docs/admin_guide_to_cracking.html</TT></A>
	
<HR>


</BLOCKQUOTE>

<P>In the paper by Farmer and Venema are many attacks implemented with Telnet alone
or in conjunction with other programs. One such attack involves an X terminal:

<DL>
	<DD>X Terminals are generally diskless clients. These are machines that have the
	bare minimum of hardware and software to connect to an X server. These are most commonly
	used in universities and consist of a 17&quot; or 19&quot; screen, a base, a keyboard
	and a mouse. The terminal usually supports a minimum of 4 megabyte of RAM but some
	will hold as much as 128 megabytes. X terminals also have client software that allows
	them to connect to the server. Typically, the connection is via fast Ethernet, hardwired
	to the back of the terminal. X Terminals provide high-speed connectivity to X servers,
	coupled with high-powered graphics. These machines are sold on the Internet and make
	great &quot;additional&quot; terminals for use at home. (They are especially good
	for training.)
</DL>

<P>The Farmer-Venema X terminal technique uses a combination of rsh and Telnet to
produce a coordinated attack. The technique involves stacking several commands. The
cracker uses rsh to connect to the X terminal and calls the X terminal's Telnet client
program. Finally, the output is redirected to the cracker's local terminal via the
specification of the <TT>DISPLAY</TT> option or variable.</P>
<P>Another interesting thing that Telnet can be used for is to instantly determine
whether the target is a <I>real</I> or <I>virtual</I> domain (this can be done through
other methods, but none perform this function quite as quickly). This can assist
a cracker in determining exactly which machine he or she must crack to reach your
resources or, more precisely, exactly which machine he or she is engaged in cracking.</P>
<P>Under normal circumstances, a <I>real domain</I> is a domain that has been registered
with InterNIC and also has its own dedicated server. Somewhere in the void is a box
with a permanent IP address, and that box is attached permanently to the Internet
via 28.8Kbps modem, ISDN, 56Kbps modem, frame relay, T1, T3, ATM, or perhaps, if
the owner spares no expense, SONET. As such, when you Telnet to such a real site,
you are reaching that machine and no other.</P>
<P><I>Virtual domains</I>, however, are simply directories on a real server, aliased
to a particular domain name. That is, you pay some ISP to register your domain name
and create a directory on its disk where your virtual domain exists. This technique