|
|
In this chapter we are going to take a stroll down memory lane. In order to make the trip pleasurable for all readers, I thought I would make this a truly historical treatment. Therefore, we will start with the rise of Digital Equipment Corporation (DEC), the company that manufactured the once-popular product the VAX.
In one way or another, DEC has always been there at critical moments in computer history. (You may recall that Ken Thompson was first hacking UNIX on a DEC PDP-10.)
Cross Reference: To appreciate just how long DEC has been delivering computer products to the industry, take a moment to catch this link: http://www.cs.orst.edu/~crowl/history/.
This link will take you to Lawrence Crowl's wonderful computer history page, which shows photographs of machines that mark milestones in our computer culture (starting with the very first computer ever constructed by Charles Babbage, circa 1823). The first DEC PDP-1 appears on that page.
Cross Reference: To get a full-screen view of that machine, catch this link: http://www.cs.orst.edu/~crowl/history/dec_pdp1_2.full.jpg.
The machine looked, quite frankly, like a prop in some terrible B movie from the 1950s--something you would expect to see in the laboratory of a mad scientist. Incredibly, there was a time when such "technology" was the state of the art. Well, DEC moved on pretty quickly, to produce a wide range of products, including the very first minicomputer, the DEC PDP-8.
Cross Reference: You can see this machine on Crowl's page as well, located full size at http://www.cs.orst.edu/~crowl/history/dec_pdp8.full.jpg.
In 1978, DEC created the first VAX (virtual address extension), the Digital VAX 11/780. This machine offered 32-bit architecture and 1MIPS performance. By standards of the day, the 11/780 was powerful and fast. (It was also backward compatible with the PDP line that preceded it.) The pricetag? A mere $200,000.
NOTE: MIPS refers to million instructions per second.
Curiously, the 11/780 became so popular that it would establish itself as the benchmark for the MIPS index. In other words, it became the yardstick by which to measure performance of all workstations that later followed. (This occurred despite the fact that the IBM 370/158 was reportedly comparable in terms of speed and processing power. For reasons unknown to me, the IBM 370/158 never reached the popularity status of the 11/870.)
So, to reiterate, the 11/870 was a $200,000 machine that could do roughly 1 million instructions per second. Fantastic. Today, if you were to advertise this machine for sale on the Internet, you would have to pay the buyer to haul it away. It is considered by today's standards either junk or, perhaps more charitably, a collector's item. However, one thing made the 11/870 a special innovation and still singles it out from other machines in computer history: The 11/870 could support two operating systems. One was a system--UNIX--that was known reasonably well at the time. The other system was something a little different. It was called VMS. We will be examining VMS in just a moment. First, however, I want to give you an idea of what the VAX was all about.
The VAX was a multiuser system. Many readers may not be old enough to remember the VAXstations, so I'll offer a little description. The MicroVAX stands nearly 3 feet tall. On the right side of the machine is a panel that, when opened, reveals the cards. These cards are quite large, although not nearly as large as the panels of, say, a SPARCstation 4/330 VME deskside computer. (But certainly larger than most modern motherboards for personal computers.)
The Terminal is a VT220, with a viewing screen of approximately 81/2 inches. At the back of the terminal are various connectors. These include a data lead connection, a printer connection, and a serial port. The serial port could be set to an amazing 19200 baud and terminal emulations available included VT220 and VT100. If you connect a modem to the terminal, you have to set modem commands by hand. (In other words, you would have to send raw modem commands from a blank screen that sports a blinking cursor. Typically, you would dial by issuing the command ATDT5551212, for example.)
Contained within the terminal is firmware. This is software hard-coded into the board itself. (PC users should think of firmware in exactly the same way as the CMOS. It is a small software module that performs a limited number of tasks, including setting the machine's parameters.) Unfortunately, there is no facility by which to capture a figure of the screen, so I must describe it. When the terminal boots, you are presented with a copyright screen and then a blank screen with a blinking cursor. The terminal is then ready to accept commands. To manipulate the settings in the firmware, you choose the F3 (function 3, or Setup) key. This brings up a menu at the bottom of the screen, where you can review and change various settings. These include not only the way that communications are conducted, but also how the screen is laid out and behaves. For example, you have a choice of either an amber background and black foreground or the reverse. You can specify a typewriter keyboard or Data mode, which is more commonly used when interfacing directly with the VAX. You can also manipulate the number of characters per line and lines per screen. (Additionally, the firmware has short help messages embedded within it. These generally appear at the bottom of the screen, in the status area, as do the setting values for each facet of your environment. These may indicate which printer you are using, whether you want local echo, whether you want type-ahead mode, and so forth.) No mouse, hard disk drive, floppy drive, or other components are either present or required.
You have a wide range of choices regarding communication. For example, you can change the bits (typically 7 or 8) and also the parity of these (none, odd, even). This makes the VT220 terminal valuable not only to interface with VAXen (slang for VAX machines), but also a wide variety of UNIX machines. For example, you can use a VT220 terminal as a "head" for a workstation that otherwise has no monitor. This can generally be done by plugging the terminal into the first serial port of the workstation. (For most versions of UNIX, you generally need to strip the eighth bit.)
TIP: For Linux hackers: You can also "add" an Internet node to your box using such a terminal. To do so, you plug the terminal into either COM1 or COM2. You then edit inittab to respawn another instance of getty on that port. For this to work, you need to ensure that the cable used is a null modem cable. You also should set the emulation to VT100. When the Linux box reboots, a login prompt will appear on the VT220. From there, log in as any valid user, and you are ready. This is significantly valuable, especially if you are trying to train someone in programming or navigation of the Net via a CLI (command-line interface). It is important to note that if you are using the same COM port that normally supports your mouse, you need to kill gpm (general purpose mouse support).
These terminals, while intended for use with the VAX, can also be used as the most inexpensive method ever of accessing the Internet. Naturally, you need an old-style dial-up connection to do so (perhaps via Delphi), but there is no comparison in the price. Such terminals can now be purchased for $20. Add to this the price of a 19200 baud modem, and you are done. They are also great for connecting to local BBSs.
TIP: An interesting point here: Such a terminal does not have environment variables per se and therefore reports none. All the environment variables are obtained from whatever shell you happen to acquire on the remote machine.
These terminals are used to connect to the VAX. (Note, too, that I have described only very early implementations of VT terminals. Much later models supported various types of colors and graphics not available to the early VT100 and VT220 terminals. These newer models are extremely functional but can run as high as several hundred dollars. Good examples are the VT330 and VT340.)
Finally, you can connect to a VAX without such a terminal. Typically, this is done using PC software that supports VT100 terminal emulation. (Kermit is another popular and compatible emulation.)
The VMS (Virtual Memory System) operating system is unique, but bears similarities to several others. Logging in works much as it does on a UNIX system. You are presented with a login prompt (Username:) and a password prompt. If you enter the correct information, you are dropped to a prompt represented by a dollar ($) sign. You are also given a series of values when you log in, including your username, your process ID, and so forth.
Some common VMS commands are listed in Table 19.1.
| Command | Purpose |
| HELP [args] | If issued alone (without arguments), this command will bring up the prompt Topic?. The HELP command is generally followed by whatever command you want to learn about. |
| COPY [arg1 arg2] | Will copy an existing file or files to another file or directory. |
| DIRECTORY | Works very much like the DOS command dir, giving the contents of a directory and the attributes associated with the files therein. |
| Invokes the e-mail program interface for VAX. This works (roughly) like standard mail in UNIX. When preparing to compose a message, you are prompted for recipient and subject. | |
| LOOK | The VAX equivalent to the UNIX command ps, LOOK shows you your current processes. |
TIP: There is a nice table of command translations from VAX to UNIX. The table has been around for a while and basically offers UNIX users and others a brief reference. It is located at http://egret.ma.iup.edu/~whmf/vms_to_unix.html. You might want to examine that table now, because I will refer to a few of those commands throughout this chapter.
VMS has many of the amenities of other operating systems. The commands may be just slightly different. For example, the C shell in UNIX has a facility that will recall commands previously typed at the prompt. This facility is called history. (DOS has a similar command module, usually loaded at boot time, called DOSkey.) In VMS, you can recall commands recently typed by holding down the Ctrl key and the letter B. There are other key combinations that will stop a process, list all processes, resume a process, report current user statistics, and edit the current command line.
There are still many VAX servers on the Internet, and VMS is still very much alive. The newest version is called OpenVMS. OpenVMS is available for both VAX and Alpha machines. Alphas are extremely fast workstations (now at speeds exceeding 400Mhz) that can run Windows NT, OpenVMS, or Digital UNIX.
TIP: There is a complete online manual on OpenVMS. It is almost 1MB, but offers comprehensive coverage of OpenVMS and its capabilities. That document is available at http://www.ethz.ch/ETH/ID/KS.html.docs/SW_Distr/OpenVMS_AXP_Distr/9506-OpenVMS_AXP_new_features.html.
The majority of VAX servers on the Net are older. Many are machines located at university libraries. These provide users with facilities for searching electronic card catalogs. In all likelihood, most older VAX machines are at least as secure as their UNIX workstation counterparts. This is because much is known about the VAX/VMS system and its security. If there is a hole, it is because the system administrator missed it.
Security in VMS is well supported. For example, there is a strong model for access control. (Whether that access control is properly implemented by the system administrator is another matter.) Access control on VMS is at least as comprehensive as that on the Novell NetWare platform. Here are some of the values that can be controlled:
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:
Cross Reference: The previous paragraph is excerpted from Lex Luthor's "Advanced Hacking VAX's VMS" (Legion of Doom, June 1, 1985). It can be found online at http://www.mdc.net/~trent/hackvax.txt.
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.
Cross Reference: 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, "A Practical Exercise in Securing an OpenVMS System," Prentice Centre, The University Of Queensland, http://nsi.org/Library/Compsec/openvms.txt.
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 /etc/passwd, 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:
Cross Reference: The previous paragraph is excerpted from "The Five Minute Guide to VMS Security: Product Review PC-DEC-AUDIT" (AudIT Magazine, 1994). It can be found online at http://www.trillion.demon.co.uk/magrev.htm.
Note that this "comprehensive" 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.
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:
Cross Reference: The previous paragraph is excerpted from "OpenVMS Guide to System Security: Contents of a User's Security Profile. 4.1.1.3 How Your Process Acquires a UIC," which can be found online at http://wawona.ethz.ch/OpenVMS_docu/ssb71/6346/6346p004.htm#heading_4.1.1.
Following is a discussion of some common holes.
If two successive mount -d -s 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.
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:
Cross Reference: The previous paragraph is excerpted from a CERT advisory titled "VMS Monitor Vulnerability." It can be found online at http://www.arc.com/database/Security_Bulletins/CERT/CA-92:16.VMS.Monitor.vulnerability.
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.
Cross Reference: The Defense Data Network Advisory concerning this hole is located at DDN Security Bulletin 9223, ftp://nic.mil/scc/sec-9223.txt.
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 "Wanked." The message purported to come from Worms Against Nuclear Killers, or WANK. It was reported in the CERT advisory about the Wank Worm:
Cross Reference: The previous paragraph is excerpted from a CERT advisory titled "`WANK' Worm On SPAN Network." It can be found online at http://www.arc.com/database/Security_Bulletins/CERT/CA-89:04.decnet.wank.worm.
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:
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.
Cross Reference: The main advisory, issued by CERT is located at http://www.arc.com/database/Security_Bulletins/CERT/CA-89:04.decnet.wank.worm.
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.
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.
An interesting treatment of the event can be found in "Approaching Zero: The Extraordinary Underworld of Hackers, Phreakers, Virus Writers, and Keyboard Criminals":
Cross Reference: The previous excerpt is from an article by Paul Mungo and Bryan Glough titled "Approaching Zero: The Extraordinary Underworld of Hackers, Phreakers, Virus Writers, and Keyboard Criminals." It can be found online at http://www.feist.com/~tqdb/h/aprozero.txt.
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.
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.
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.
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.
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.
watchdog.com was written by a hacker with the handle Bagpuss. The purpose of watchdog.com is simple: It keeps tabs on users logging in and out of the machine. It is an early warning system that can alert you to when the system operator (or other similarly privileged user) logs on.
Cross Reference: The source code and full explanation of watchdog.com are located at http://www.wordserf.co.uk/mh/vaxhackpro.html.
Stealth was also written by Bagpuss. The purpose of this utility is to evade detection in the event that someone (the system operator, perhaps) issues the SHOW USER command. This command is much like combining the W, WHO, and PS commands in UNIX. It identifies the users currently logged to the machine and their status. Stealth prevents the user from being visible on such a query.
Cross Reference: The source code for Stealth is at http://www.wordserf.co.uk/mh/vaxhackpro.html.
GUESS_PASSWORD is designed to crack the password file of the VMS system. The program works quite well, but you have to wonder about its actual value. These days, it is unlikely that a system administrator would unprotect the SYSUAF.DAT file (where the passwords are actually located). However, if a cracker could find such an unprotected password file, this utility would assist in cracking it.
Cross Reference: GUESS_PASSWORD (with source) is available at http://www.uniud.it/ftp/vms/uaf.zip.
WATCHER is a snooping utility, most commonly used by system administrators. Its purpose is to watch terminal sessions. From a security point of view, WATCHER is a good resource. It will monitor how long a terminal has been idle. The system administrator (or the user) can set the time period after which idle sessions can be automatically killed. (Idle terminal sessions are in themselves a security risk. Crackers watch accounts that remain idle for long periods of time. These accounts are deemed good targets.)
Cross Reference: WATCHER is available at ftp://ftp.wku.edu/madgoat/WATCHER.zip.
Checkpass is a tool that examines the relative strength or weakness of a given password in the SYSUAF.DAT file. It's good for versions 5.4 and onward.
Cross Reference: Checkpass is available at ftp://www.decus.org/pub/lib/vs0127/checkpass/check.zip.
As you might guess, Crypt is a DES encryption module for the VMS operating system. Interestingly, it also provides support for UNIX and DOS. It was developed (along with the previous utility) by M. Edward Nieland, who wrote these tools primarily in C and FORTRAN.
Cross Reference: The CRYPT utility is located at ftp://www.decus.org/pub/lib/vs0127/crypt/crypt.zip.
A secure dialback module, DIAL is designed to prevent unauthorized remote users from gaining access to your system. As explained in the DIAL user's guide:
The system works through the maintenance of a file that lists all valid users and their telephone numbers. (Read: This could be one method of circumventing this security. Reach that file and you reach DIAL.) It was written in C by Roger Talkov at Emulex.
Cross Reference: DIAL is available at ftp://www.decus.org/pub/lib/v00149/dial.zip.
Written by Robert Eden of Texas Utilities, CALLBACK.EXE performs essentially the same functions as DIAL. It was written in FORTRAN.
Cross Reference: CALLBACK.EXE is available at http://www.openvms.digital.com/cd/CALLBACK/CALLBACK.EXE.
TCPFILTER is a utility that restricts outgoing connects. As described in the documentation, the utility does the following:
Cross Reference: The previous paragraph is excerpted from a file titled TCPFILTER.DOC ENGLISH by G. Gerard. It can be found online at http://www.openvms.digital.com/cd/TCPFILTER/.
I should point out that the term calls means outgoing TCP/IP connect requests. That is, you can restrict connect requests to specific IP addresses, based on user information in the Access Control List. A pretty nifty utility. For example, you could restrict any access to outside hacker or cracker boards. Hmm.
Cross Reference: TCPFILTER is located at http://www.openvms.digital.com/cd/TCPFILTER/TCP.COM.
The VAX/VMS combination was once a very popular one. And, as I have already related, OpenVMS is alive and well. However, changes in the computer industry and in public demand have altered the Internet's climate with regard to VMS. When coupled with Digital's commitment to Microsoft to provide a suitable architecture on which to run Windows NT, these changes contributed to a decrease in the use of VMS. This is curious because today the source code is available. As I have explained elsewhere in this book, whenever the source of an operating system is available, the security community has an opportunity to fine-tune it.
Because Digital Alpha stations now run both Microsoft Windows NT and Digital UNIX, VMS is likely to take a backseat. This is especially so with regard to Digital UNIX because it is a 64-bit system. Imagine for a moment a 64-bit system running at 400MHz. In my opinion, this configuration is the most powerful currently available to the average user. Such a machine (loaded with at least 64MB of RAM) is vastly superior in my opinion to either the Pentium or the MMX. So the days of the old VAX/VMS are probably over.
Today's cracker probably knows little about these systems. More concentration has been allotted to UNIX and as of late, Windows NT. If I were going to contract someone to crack a VAX, I would look for someone in his mid-30s or older. Certainly, the advent of the PC has contributed to the lack of VMS security knowledge. Young people today work mostly with PC- or Mac-based machines. It is therefore rare to come in contact with a VAX anymore, except as library servers or other database machines.
A close friend of mine has a MicroVAX II in his garage. Each time I visit his home, we talk about the prospect of cranking up that old machine. One day soon, we'll probably do just that.
At day's end, VMS is an interesting, durable, and relatively secure platform. Moreover, DEC was always exceptionally close-mouthed about the security weaknesses of VAX/VMS. If you retrieve all the known advisories on VAX/VMS, you will see that DEC routinely declined to include information that could potentially be used by crackers. (Most often, DEC would advise that VAX users contact their local DEC representative.) This was a smart move and one that has made it traditionally difficult to crack VAX servers. If the system administrator of a VAX has been on his toes, after a cracker has tried all the default passwords, there is nothing left to do but turn to social engineering.
The VAX/VMS system is an antiquated one at this stage of the game. However, it is not out of the race yet. OpenVMS has much to offer. If you are considering a career in Internet security, you should at least take some brief courses in VMS. Or, if you are like me and prefer the more direct approach, buy a used VAX and set yourself to the task of cracking it. These can be acquired for practically nothing today in misc.forsale.computers.workstation. Many sellers even have the original installation media.
In closing, it is my opinion that the security of the VAX is advanced and even somewhat elegant. Moreover, in many parts of the world, the VAX is still popular. Time studying VAX security is probably time well spent.
VAX Security: Protecting the System and the Data. Sandler and Badgett. John Wiley & Sons. ISBN 0-471-51507-8.
A Retrospective on the VAX VMM Security Kernel. Paul A. Karger, Mary E. Zurko, Douglas W. Bonin, Andrew H. Mason, and Clifford E. Kahn. IEEE Transactions on Software Engineering, 17(11):1147-1163, November 1991.
Database Security. S. Castano, M. G. Fugini, G. Martella, and P. Samarati. Addison-Wesley Publishing Company. 1995. (Good chapter on VAX/VMS.)
Security Guidance for VAX/VMS Systems. Debra L. Banning. Sparta, Inc. 14th National Computer Security Conference, Washington, DC, October, 1991.
A Practical Exercise in Securing an OpenVMS System. Rob McMillan, Prentice Centre, The University Of Queensland.
How VMS Keeps Out Intruders. Tanya Candia. Computers & Security, 9(6):499-502, October 1990.
ESNET/DECNET Security Policy Procedures and Guidelines. D. T. Caruso and C. E. Bemis, Jr., ESnet/DecNet Security Revised Draft, December 1989.
C.O.T.S. (Certified OpenVMS Technical Specialist) Examination.
Approaching Zero: The Extraordinary Underworld of Hackers, Phreakers, Virus Writers, and Keyboard Criminals. Paul Mungo and Bryan Glough.
VMS Monitor Vulnerability. CERT advisory. CA-92:16. September 22, 1992.
© Copyright, Macmillan Computer Publishing. All rights reserved.
