Online Documentation Server
Net technology
Web technology
Data bases
Other docs



Вся предоставленная на этом сервере информация собрана нами из разных источников. Если Вам кажется, что публикация каких-то документов нарушает чьи-либо авторские права, сообщите нам об этом.

Maximum Security:

A Hacker's Guide to Protecting Your Internet Site and Network

Previous chapter Next chapter Contents


Telnet-Based Attacks

This chapter examines attacks developed over the years using the Telnet service. That examination begins with a bit of history. The Telnet protocol was first comprehensively defined by Postel in 1980. In RFC 764, Postel wrote:

The purpose of the Telnet protocol is to provide a fairly general, bi-directional, eight-bit byte oriented communications facility. Its primary goal is to allow a standard method of interfacing terminal devices and terminal-oriented processes to each other. It is envisioned that the protocol may also be used for terminal-terminal communication ("linking") and process-process communication (distributed computation).

Cross Reference: RFC 764 can be found on the Web at


As I mentioned in Chapter 6, "A Brief Primer on TCP/IP," Telnet is unique in its design with the notable exception of rlogin. Telnet is designed to allow a user to log in to a foreign machine and execute commands there. Telnet (like rlogin) works as though you are at the console of the remote machine, as if you physically approached the remote machine, turned it on, and began working.

NOTE: PC users can get a feel for this by thinking in terms of PCAnywhere or CloseUp. These programs allow you to remotely log in to another PC and execute commands at the remote machine's C: prompt (or even execute commands in Windows, providing you have a very high-speed connection to transmit those graphics over the wire).

Virtual Terminal

The magic behind Telnet is that it imitates an ASCII terminal connection between two machines located great distances from each other. This is accomplished through the use of a virtual terminal, as described by Postel in this excerpt from RFC 854:

When a Telnet connection is first established, each end is assumed to originate and terminate at a "Network Virtual Terminal," or NVT. An NVT is an imaginary device which provides a standard, network-wide, intermediate representation of a canonical terminal...The Network Virtual Terminal (NVT) is a bi-directional character device. The NVT has a printer and a keyboard. The printer responds to incoming data and the keyboard produces outgoing data which is sent over the Telnet connection and, if "echoes" are desired, to the NVT's printer as well. "Echoes" will not be expected to traverse the network (although options exist to enable a "remote" echoing mode of operation, no host is required to implement this option). The code set is seven-bit USASCII in an eight-bit field, except as modified herein. Any code conversion and timing considerations are local problems and do not affect the NVT.

Cross Reference: Read RFC 854 in its entirety at

A virtual terminal is the equivalent (at least in appearance) of a hard-wired serial connection between the two machines. For example, you can simulate something very similar to a Telnet session by uncommenting the respawn instructions in the inittab file on a Linux box (and most other UNIX boxes) or by disconnecting both the monitor and keyboard on a SPARC and plugging a VT200 terminal into serial A or B. In the first instance, a login: prompt is issued. In the second, all boot process messages are echoed to the connected terminal and eventually, a boot prompt is issued (or perhaps, if the right SCSI disk drive is specified as the boot device in the PROM, the machine will boot and issue a login: prompt).

Therefore, Telnet-based connections are what are called bare bones connections. You will notice that if you use a VT220 terminal as a head for your SPARC that, when the boot occurs, the cool Sun logo is not printed in color, nor do the cool graphics associated with it appear. Telnet and terminal sessions are completely text based. In addition, Telnet connections do not have facilities to interpret display-oriented languages such as HTML without the assistance of a text-based browser such as Lynx. Therefore, retrieving a Web page through Telnet will reveal no pictures or nicely formatted text; it will reveal only the source of the document (unless, of course, you have logged in via Telnet and are now using Lynx).

NOTE: Lynx is a completely terminal-based HTML browser for use with shell-account or even DOS-based TCP/IP connections. It is a no-frills way to access the World Wide Web.

Telnet Security History

Telnet has cropped up in security advisories many times. Telnet security problems vary considerably, with a large number of vulnerabilities surfacing due to programming errors. However, programming errors are not the only reasons Telnet has appeared on advisories. In August of 1989, for example, the problem was a trojan, as the CERT advisory "Telnet Break-in Warning" explains:

Many computers connected to the Internet have recently experienced unauthorized system activity. Investigation shows that the activity has occurred for several months and is spreading. Several UNIX computers have had their "Telnet" programs illicitly replaced with versions of "Telnet" which log outgoing login sessions (including user names and passwords to remote systems). It appears that access has been gained to many of the machines which have appeared in some of these session logs.

Cross Reference: To view this CERT advisory in its entirety, visit

That attack occurred just prior to the establishment of the DDN Security Coordination Center (September 1989), so there is little documentation about whether it affected government computers. Also, although the efforts of CERT are appreciated and vital to Internet security, DDN advisories sometimes contain a more technical analysis of the problem at hand.

In March, 1991, the telnetd daemon on certain Sun distributions was found to be flawed. As the CERT advisory "SunOS in.telnetd Vulnerability" notes:

The Computer Emergency Response Team/Coordination Center (CERT/CC) has obtained information from Sun Microsystems, Inc. regarding a vulnerability affecting SunOS 4.1 and 4.1.1 versions of in.telnetd on all Sun 3 and Sun 4 architectures. This vulnerability also affects SunOS 4.0.3 versions of both in.telnetd and in.rlogind on all Sun3 and Sun 4 architectures. To our knowledge, a vulnerability does not exist in the SunOS 4.1 and 4.1.1 versions of in.rlogind. The vulnerability has been fixed by Sun Microsystems, Inc.

Cross Reference: To view this CERT advisory in its entirety, visit

TIP: If you buy an old Sun 3/60 over the Net, you will want to get the patches, which are included in the previous advisory.

Months later, it was determined that a specialized LAT/Telnet application developed by Digital Corporation was flawed. As the CERT advisory "ULTRIX LAT/Telnet Gateway Vulnerability" explains:

A vulnerability exists such that ULTRIX 4.1 and 4.2 systems running the LAT/Telnet gateway software can allow unauthorized privileged access...Anyone who can access a terminal or modem connected to the LAT server running the LAT/Telnet service can gain unauthorized root privileges.

Cross Reference: To view this CERT advisory in its entirety, visit

The first Telnet problem that rocked the average man on the street was related to a distribution of the NCSA Telnet client for PC and Macintosh machines. So that there is no misunderstanding here, this was a client Telnet application that included an FTP server within it. The hole was fostered primarily from users' poor understanding of how the application worked. As articulated by the folks at DDN:

The default configuration of NCSA Telnet for both the Macintosh and the PC has a serious vulnerability in its implementation of an FTP server...Any Internet user can connect via FTP to a PC or Macintosh running the default configuration of NCSA Telnet and gain unauthorized read and write access to any of its files, including system files.

The problem was related to a configuration option file in which one could enable or disable the FTP server. Most users assumed that if the statement enabling the server was not present, the server would not work. This was erroneous. By omitting the line (or adding the line option ftp=yes), one allowed unauthorized individuals read and write access to the files on your hard drive.

I hope this will settle the argument regarding whether a PC user could be attacked from the outside. So many discussions on Usenet become heated over this issue. The NCSA Telnet mishap was only one of many situations in which a PC or Mac user could be attacked from the void. So depending on the circumstances, the average user at home on his or her PC can be the victim of an attack from the outside. People may be able to read your files, delete them, and so forth.

What is more interesting is that even today, those using the NCSA Telnet application are at some risk, even if they only allow access to the FTP server by so-called authorized individuals. If a cracker manages to obtain from the target a valid username and password (and the cracker is therefore an authorized user), the cracker may then obtain the file FTPPASS. This is an authentication file where the usernames and passwords of users are stored. The encrypted passwords in this file are easily cracked.

The username in this file is not stored in encrypted form (in reality, few programs encrypt usernames). The password is encrypted, but the encryption scheme is very poorly implemented. For example, if the password is fewer than six characters, it will take only seconds to crack. In fact, it is so trivial to crack such passwords that one can do so with a 14-line BASIC program.

Cross Reference: The BASIC program that cracks passwords can be found at

If you are a Mac or PC user currently using NCSA Telnet (with the FTP server), disallow all FTP access to anyone you do not trust. If you fail to heed this warning, you may get cracked. Imagine a scenario where a single individual on a network was using NCSA Telnet. Even if the rest of the network was reasonably secure, this would blow its security to pieces. Moreover, the application does not perform logging (in the normal sense) and therefore, no trail is left behind. Any network running this application can be attacked, disabled, or destroyed, and no one will be able to identify the intruder.

The most interesting Telnet hole ever discovered, though, was related to the environment variable passing option. The DDN bulletin on it was posted on November 20, 1995:

A vulnerability exists in some versions of the Telnet daemon that support RFC 1408 or 1572, both titled the "Telnet Environment Option," running on systems that also support shared object libraries...Local and remote users with and without local accounts can obtain root access on the targeted system.

Many sites suffer from this vulnerability. To understand the problem, you must understand the term environment. In UNIX vernacular, this generally refers to the environment of the shell (that is, what shell you might use as a default, what terminal emulation you are using, and so forth).

NOTE: DOS/Windows users can most easily understand this by thinking about some of the statements in their AUTOEXEC.BAT and CONFIG.SYS files. For example, variables are established using the SET command, as in SET PATH=C:\;C:\WINDOWS; (the PATH environment variable is one of several that can be specified in the DOS environment). These statements define what your programming environment will be like when you boot into command mode. Some common environment variables that can be set this way are the shell you are using, the path, the time zone, and so forth.

Changing the Environment

In UNIX, you can view or change the environment by using either the setenv or printenv command. Here is an example of what one might see on such an instruction:

> setenv

LS_OPTIONS=--8bit --color=tty -F -T 0

This listing is a very extensive output of the command on a machine on which a virtual domain has been established. A more manageable (and more easily explained) version can be taken from a bare shell machine. Here is the output:

samshacker% /usr/ucb/printenv

This output is from a SPARCstation 10 on which I set up a mock shell account (the first output was from a Linux box). This is a very stripped-down environment. The PATH statement (line 6) points only to /usr/bin. In practice, this is impractical because there are many more binaries on a UNIX system than those located in /usr/bin. For example, there are binaries located in /usr/sbin, /usr/bin/X11, and so forth. You can see, for example, that even the command given (setenv) was done by issuing the absolute path statement (/usr/ucb/setenv). In practice, I would have (within a day or so) set a much longer path, pointing to man pages, binaries, and perhaps even include directories.

NOTE: The PATH statement in UNIX works almost exactly as it does in DOS. Directories that you intend to be in the path must be articulated on the PATH statement line and separated by colons (instead of semicolons). By articulating these on the PATH line, you give the user access to commands within these directories (no matter which directory the user is currently located in).

Terminal Emulation

Other variables set in the preceding statements include HOME, MAIL, SHELL, and TERM. TERM, one of the most important variables, expresses the type of terminal emulation that you will be using. Because not all readers know what terminal emulation is, I want to quickly explain it.

Years ago, the majority of servers were mainframes. In those days, users did not have powerful PCs attached to the mainframe; they had terminals, which were (usually) boxes without hard drives. These were screens attached to keyboards. Behind terminals were a series of connectors, which might offer different methods of connection. One popular method was a bare-bones serial connection (we're talking primitive here: a straight serial-to-serial interface). Other terminals might sport hardwire options such as Ethernet connections.

In any event, these terminals had very little functionality (at least in comparison to the average PC). Contained on the main board of such a terminal was a small portion of memory and firmware (software hardwired into the board itself). This firmware would grant the user several options. For example, one could set the speed and type of connection, the need for local echo, and so forth. Sometimes, there were options to set the type of printer that might be used or even what port the data was to be sent from.

TIP: Such terminals are still sold on certain Usenet newsgroups. If you are a student with limited funds and you have been granted some form of Ethernet or even serial connection to your college's server, and if that server account is a shell account, get a terminal. For a mere $25-40, you can get high-speed access to the Internet. True, you cannot generally save materials to a disk, but you can print what is currently on the screen. You will not believe how quickly the screen will update. It is the absolutely ideal situation for Internet Relay Chat (IRC). These boxes are small, cheap, and fast.

The two best-known terminals were the Tektronix 4010 and the VT100 (also the IBM 3270, which is a bit different). Each had a set number of characters per line and lines per screen that could be displayed. In fact, most terminals usually had two settings. As terminals became more fancy, one could even set columns and, eventually, graphics (the Tektronix was graphics oriented).

Because these terminals became the standard method of connecting to mainframes, they also bled into the UNIX world. As such, all UNIX operating systems have keyboard and screen mappings for terminals. Mappings are descriptions of the screen and the keyboard settings (for example, how many lines and columns per screen or, more importantly, what Ctrl key sequences represent special characters). These are required because certain terminals use more keys than are offered on the standard PC or Mac keyboard. In addition to the regular typewriter keyboard and F function keys, there may be P keys that perform special actions, including the activation of menus and the navigation of the screen cursor in databases. To make up for this on PC, Mac, or even some UNIX keyboards, Esc or Ctrl sequences are defined. These are combinations of keystrokes that equal a P key. These key assignments are called key bindings, which are statements made within the program code that define what happens if this or that key combination is executed. Key bindings are a big part of programming, especially in C where you offer a semi-graphical interface (for example, where you use Borland's famous TurboVision libraries to create drop-down menus in a DOS application).

One can generally define key bindings in a program (at least, in a well written one). This gives the user application-level control over which keys do what. For example, perhaps the user can set the binding of the Ctrl key plus the letter F to perform a variety of functions. Some specialized applications actually ask the user to do so before launching the program for the first time. There is one such program--a freeware editor for UNIX, written in Germany--that allows you to completely remap the keyboard.

In UNIX, terminal mappings are generally stored in a file called termcap. The termcap library, reportedly introduced with Berkeley UNIX, is a very important addition to the system. Without it, many machines would not communicate well with each other. For example, if you perform a fresh install of a Linux operating system and do nothing to alter the TERM variable, it will be set to Linux. If you then Telnet to a SPARCstation (or other machine that also has its default TERM configuration), you will be unable to clear the screen with the well-known command clear. This is because the two terminal emulation settings are incompatible. Furthermore, if you try to execute a program such as PINE--which relies on compatible terminal types--the program will exit on error, reporting that the terminal is not supported. (SysV systems traditionally use terminfo as opposed to termcap.)

CAUTION: Many distributions of UNIX have complete termcap listings, which sometimes contain hundreds of terminal emulations. If you are new to UNIX and are toying with the idea of altering your termcap entries, be extremely careful. You may end up with bizarre results. In some cases, what once looked like nicely formatted text may appear as strange, disjointed, scattered blocks of words that are largely illegible. Study the man page before fiddling with your termcap file.

Many different environmental variables can be set. These variables can strongly influence how a remote machine will receive, process, and support your remote Telnet connection. Thus, the Telnet protocol was designed to allow the passing of certain environment variables at the time of the connection. As explained in RFC 1408:

Many operating systems have startup information and environment variables that contain information that should be propagated to remote machines when Telnet connections are established. Rather than create a new Telnet option each time someone comes up with some new information that they need propagated through a Telnet session, but that the Telnet session itself doesn't really need to know about, this generic information option can be used.

Cross Reference: To view RFC 1408 in its entirety, visit

The recent Telnet security hole was based on the capability of a Telnet server to receive, respond to, and authorize the passing of these environment variables. Because this option was so prominent in the UNIX system, an incredible number of platforms were vulnerable to this attack.

This vulnerability is more common than one would expect. In a rather engrossing report, one firm, Novatech, posted the results of an actual security audit of a network with 13 hosts. In it, the Telnet vulnerability appears, as do 138 other holes. The most extraordinary thing is that the site had already been assessed as having a clean bill of health, complete with a firewall. As Novatech's sample audit report notes:

This is a copy of a actual attack report with definitions and possible rectifications of actual problems found. The network had a state of the art firewall installed and had been checked by CERT. As you can see there were many small problems and a number of larger ones as well. This was not the fault of the systems administration but of a mix that systems change and need constant attention and the lack of knowledge of how intruders gain access (a specialist field). We are able to check your system for nearly 390 different forms of access vulnerability all of which are Internet only type access.

Cross Reference: For those who have a "let's wait and see" attitude about security, I suggest that you go immediately to this site and view the results. They are astonishing. See the results of the audit at

The line that reveals the Telnet environment option vulnerability reads as follows:

Dynamic Linker Telnet Vulnerability [High Risk]2

This line reports that a Telnet vulnerability in the high risk category was found (in the audit cited previously, this vulnerability was found on two hosts within the same subnet). [High Risk]2 refers to the level of risk the hole represents. This is an extremely high risk vulnerability. Remember, this was found on a host with a state-of-the-art firewall!

To understand the method, you must understand precisely what options can be passed from the client to the server. One of these involves the passing of a custom libc.

NOTE: libc is the standard C library. A full distribution of libc 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.

As Sam Hartman of MIT notes in his article "Telnet Vulnerability: Shared Libraries":

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.

Cross Reference: Find Hartman's article on the Web at

By passing the LD_LIBRARY_PATH 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.

NOTE: 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.

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

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.

Cross Reference: Find Larry Doolittle's article on the Web at

Here are patches for various distributions of telnetd:

  • DEC. (OSF/1):
  • A compressed version is available at
  • Linux:
  • Red Hat:
  • SGI (IRIX):

NOTE: Although patches have been issued for this problem, some other Telnet-related modules and programs may still be affected. As late as February, 1997, in.telnetsnoopd was reported as vulnerable to the LD_PRELOAD passing on some platforms, including Linux. There is reportedly a patch for this problem, and it has been uploaded to

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:

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

Cross Reference: Declerck's README for ttysnoop 0.12 (alpha) can be found on the Web at

NOTE: 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.

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.

Aren't These Attacks No Longer Effective?

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.

Telnet as a Weapon

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:

  • Port 21: FTP
  • Port 23: Telnet (Default)
  • Port 25: Mail
  • Port 70: Gopher
  • Port 80: HTTP

NOTE: 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 GET instruction will elicit a lively response from the Web server if the request is sufficiently malformed.)

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

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 "freeze up" for a short period of time.

Cross Reference: "Improving the Security of Your Site by Breaking Into It" can be found on the Web at admin_guide_to_cracking.html

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:

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" or 19" 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 "additional" terminals for use at home. (They are especially good for training.)

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 DISPLAY option or variable.

Another interesting thing that Telnet can be used for is to instantly determine whether the target is a real or virtual 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.

Under normal circumstances, a real domain 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.

Virtual domains, 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 allows to masquerade as a real server. Thus, when users point their browsers to, they are reaching the ISP's server. The ISP's server redirects the connection request to your directory on the server. This virtual domain scheme is popular for several reasons, including cost. It saves your company the trouble of establishing a real server and therefore eliminates some of these expenses:

  • Hardware
  • Software
  • 24-hour maintenance
  • Tech support

Basically, you pay a one-time fee (and monthly fees thereafter) and the ISP handles everything. To crackers, this might be important. For example, if crackers are about to crack your domain--without determining whether your machine is truly a server--they may get into trouble. They think they are cracking some little machine within your internal offices when in fact, they are about to attack a large, well-known network provider.

Telnet instantly reveals the state of your server. When a cracker initiates a Telnet connection to (and on connect, sees the name of the machine as a node on some other, large network), he or she immediately knows that your address is a virtual domain.

Moreover, Telnet can be used for other nefarious purposes. One is the ever-popular brute-force attack. I am not sure why brute-force attacks are so popular among young crackers; almost all servers do some form of logging these days. Nevertheless, the technique has survived into the 1990s. These attacks are most commonly initiated using Telnet clients that have their own scripting language built in. Tera Term is one such application.

Tera Term sports a language that allows you to automate Telnet sessions. This language can be used to construct scripts that can determine valid usernames on a system that refuses to cough up information on finger or sendmail-expn queries. Versions of Telnet reveal this information in a variety of ways. For example, if a bogus username is given, the connection will be cut. However, if a valid username is given, a new login: prompt is reissued.

Cross Reference: Tera Term can be found on the Web at

Moreover, Telnet is a great tool for quickly determining whether a particular port is open or whether a server is running a particular service. Telnet can also be used as a weapon in denial-of-service attacks. For example, sending garbage to certain ports on an NT Web server under IIS can cause the targeted processor to jump to 100 percent utilization. Initiating a Telnet session to other ports on an NT Web server can cause the machine to hang or crash. This is particularly so when issuing a Telnet connection request to port 135.

Cross Reference: A fix for this problem, issued by Microsoft, can be found at

One can also crash Microsoft's Internet Information Server by Telnetting to port 80 and issuing a GET.../... request. Reportedly, however, that problem was remedied with the Microsoft Windows NT Service Pack 2 for Windows NT 4.0. If you do not have that patch/service pack, get it. A good treatment of this and other problems can be found in the Denial of Service Info post, posted by Chris Klaus of Internet Security Systems. In it, Klaus writes:

The file sharing service if available and accessible by anyone can crash the NT machine and require it to be rebooted. This technique using the bug on a Windows 95 machine potentially allows anyone to gain access to the whole hard drive...Solution: This vulnerability is documented in Microsoft Knowledge Base article number Q140818 last revision dated March 15, 1996. Resolution is to install the latest service pack for Windows NT version 3.51. The latest service pack to have the patch is in service pack 4.

Cross Reference: Visit the Denial of Service Info post at

NOTE: This was only a vulnerability in the Internet Information Server 2.0 World Wide Web server (HTTP). Later versions of IIS are reportedly clean.

Finally, Telnet is often used to generate fakemail and fakenews. Spammers often use this option instead of using regular means of posting Usenet messages. There are certain options that can be set this way that permit spammers to avoid at least some of the screens created by spam-killing robots on the Usenet network.


Telnet is a very versatile protocol and, with some effort, it can be made secure. (I personally favor SSH as a substitute, for it prevents against snooped Telnet sessions.) Nevertheless, Telnet is not always secure out of the box. If you are using older software (pre 1997), check whether the appropriate patches have been installed.

Telnet can also be used in a variety of ways to attack or otherwise cull information from a remote host (some of those are discussed in this chapter). By the time this book is released, many more Telnet attack techniques will have surfaced. If you run a network and intend to supply your users with Telnet access, beware. This is especially so on new Telnet servers. These new servers may have bugs that have not yet been revealed. And, because Telnet is so interactive and offers the user so much power to execute commands on remote machines, any hole in a Telnet distribution is a critical one. It stands in the same category as FTP or HTTP in this respect (or is perhaps even worse).


Sendmail Bug Exploits List. Explains methods of attacking sendmail. Some of these techniques use Telnet as the base application.

Improving the Security of Your Site by Breaking Into It. Dan Farmer and Wietse Venema.

The Telnet Protocol Specification (RFC 854). J. Postel and J. Reynolds. May 1983.

The Telnet Environment Option (RFC 1408). D. Borman, Editor. Cray Research, Inc. January 1993.

Telnet Environment Option (RFC 1572). S. Alexander.

Telnet Authentication: SPX (RFC 1412). K. Alagappan.

Telnet Remote Flow Control Option. (RFC 1372). C. Hedrick and D. Borman.

Telnet Linemode Option (RFC 1184). D.A. Borman.

The Q Method of Implementing Telnet Option Negotiation (RFC 1143). D.J. Bernstein.

Telnet X Display Location Option (RFC 1096). G.A. Marcy.

Telnet Binary Transmission (RFC 856). J. Postel and J.K. Reynolds.

Remote User Telnet Service (RFC 818). J. Postel.

Discussion of Telnet Protocol (RFC 139). T.C. O'Sullivan. Unfortunately, this RFC is no longer available online.

First Cut at a Proposed Telnet Protocol (RFC 97). J.T. Melvin and R.W. Watson. Unfortunately, this RFC is no longer available online.

The Telnet Authentication Option. Internet Engineering Task Force Internet Draft. Telnet Working Group. D. Borman, Editor. Cray Research, Inc. February 1991.

Telnet Authentication: Kerberos Version 4 (RFC 1411). D. Borman, Editor. Cray Research, Inc. January 1993.

STEL: Secure Telnet. Encryption-enabled Telnet. David Vincenzetti, Stefano Taino, and Fabio Bolognesi.

Session-Layer Encryption. Matt Blaze and Steve Bellovin. Proceedings of the Usenix Security Workshop, June 1995.

Attaching Non-TCP-IP Devices with Telnet. Stefan C. Johnson. Sys Admin: The Journal for UNIX Systems Administrators. June 1996.

Secure RPC Authentication (SRA) for Telnet and FTP. David K. Hess, David R. Safford, and Douglas Lee Schales. Proceedings of the Fourth Usenix Security Symposium, Supercomputer Center, Texas A&M University, 1993.

Internetworking with TCP/IP Vol. 1: Principles, Protocols and Architecture. Douglas Comer. Prentice Hall. 1991.

Terminal Hopping. Karen Bannan. PC Magazine's InternetUser--CRT, Version 1.1.4 (01/30/97).

Telnet & Terminal Emulation. PC Magazine's InternetUser. January 30, 1997.

EFF's (Extended) Guide to the Internet--Telnet. Adam Gaffin. Mining the Net, Part I.

Previous chapter Next chapter Contents

© Copyright, Macmillan Computer Publishing. All rights reserved.

With any suggestions or questions please feel free to contact us