Stumbling Into Control on a VMS

by The Mole

Once a hacker has gained access to a VMS system, his goal should be to try to
get a hold of the most powerful privileges he can. Here are some tips on taking
over a VMS system.

There are two routes to take either through programming or by modifying the
User Authorization File. The first method generally requires the CMKRNL
privilege. This privilege allows one to modify the data structures used by the
operating system. By writing the correct code a hacker can change his, or
anyone else's, privileges and quotas. This method requires very detailed
knowledge of the operating system and should be left only to the very
experienced. If you do not know what you are doing, it's very likely that you
will crash the system and if you do there will be an accurate and detailed
record of what you did. (You should never take down a system because doing so
leaves a trail that the system manager can use to track you down.)

The easier way to gain control of a system is through the User Authorization
File or UAF. If you modify the UAF you must log out and then log back on to get
any privileges you added to your account. With programming you can make them
take effect immediately. The cost you pay is complexity.

First, here are some tips for breaking onto a VAX:

Every VAX that is serviced by DEC has a Site Management Guide. This is a brown
loose-leaf binder that the DEC field service personnel use to keep a
maintenance log. Field service people like to write the FIELD password down in
this book. If you can get a quick browse at it you may be able to come up with
several passwords. If you find the FIELD password, you are all set to take
control of the system.

The VT200 series terminals have an answerback feature that allows the terminal
to save a character string that can be recalled by pressing CTRL/BREAK. Users
often make this character string "username(CR)password(CR)." This allows them
to log in by pressing two keys. It also allows you to do the same. The way you
can get in is by bringing up the username prompt and by pressing CTRL/BREAK.
You won't be able to see the password, though. To get the password, enter
"$CREATE PASSWORD.DAT CTRL/BREAK CTRL/Z" then "$TYPE PASSWORD.DAT." This method
is more likely to work with a terminal that is in someone's office as opposed
to a terminal that is in a common area.

Of course, the simplest way to get in is through a terminal that is left logged
on. If you have access to a user area, you probably can find a terminal that
has not been logged off.

A list of usernames on a system is often helpful. In my experience, around 50
percent of all passwords are usernames or slight variations on the username.
This is especially true of such usernames as GAMES, DEMO, and USER.

Once you are logged on to a system, the very first thing you should do is enter
the command "$DELETE/SYMBOL/ALL/GLOBAL." Digital-related trade magazines are
filled with articles on how to catch hackers and prevent them from doing things
by defining global symbols. If you execute that command you have removed all of
those silly little traps.

Now for taking over that VAX. First, the easy way. Once you are logged in use
the "$SHOW PROCESS/PRIV" command to see if you have any of the following
privileges:

 BYPASS
 SYSPRV
 SETPRV
 CMKRNL

If you do have one of these, you already have the system in your hands. If you
have BYPASS or SYSPRV you can modify the UAF directly. Just enter the command
"$SET DEFAULT SYS$SYSTEM" and then the command "$RUN AUTHORIZE." Then follow Lex
Luthor's instructions in the VMS series, the last of which appeared in the
March 1986 issue of 2600. If you have SETPRV you have all privileges available.
Just enter the command '$SET PROCESS/PRIV=ALL" and then follow the instruction
above. If you have CMKRNL enter the command "$SET UIC [1,4]" and then follow
the instructions above.

Also, use the "$SHOW PROCESS" command and see if the first number of your UIC
code is 10 (octal) or less. UICs look like [100,4]. If you do, you have SYSPRV
automatically even if it is not listed when you SHOW PROCESS/PRIV.

An easy way for a system manager to help keep you off of his system is by not
creating any privileged accounts. Fortunately for the hacker, system managers
do not follow this rule (often not by personal choice). The only privileged
accounts that are needed to run a VMS system are the FIELD and SYSTEM accounts
(the FIELD account is not absolutely required). In spite of this, very often
executives in computer departments (as well as system managers) keep privileged
accounts for themselves (presumably for ego purposes) even though they have
nothing to do with maintaining the system. Also, support people often have
system privileges when they could get by with group privileges. At colleges,
often many of the professors have privileged accounts. The excuse is that they
need to read their students' files. The more there are the more targets there
are for the hacker. It's harder to get in if five people know the SYSTEM
password than if all five people have privileged accounts.

Here's a little story for you. When I was in college the "systems people"
created a command called ORACLE so that users could send them mail messages.
For some reason they also created an account called ORACLE to read the
messages. Guess what the password for the account was? ORACLE, that's right.
How did you know? Would you believe that this account had full privilege also?
The whole school knew the password to the account.

A smart system manager is also going to use the SYSTEM account only to manage
the system and use a personal, non-privileged account to program with and to
write memos. Luckily for you, most system managers are lazy. They use their
CHKRNL privilege to change their UIC code so that the SYSTEM account
temporarily becomes their personal account (but with privileges, of course).
The more the SYSTEM account is in use, the more likely it is to be left logged
on. In my experience, this is the absolute easiest way to get to take over a
system. The SYSTEM account should only be used from a secure area.

When I was in college, I had a reputation for breaking into the computer. Now I
am going to reveal The Mole's break-in secret to the world. Every time I got in
it was because someone in the computer department had left a terminal logged on
to a privileged account. That was the only method I ever used personally
(although I did teach other people more sophisticated means). So I never broke
in. I just walked right through the front door. As a direct result of my
"hacking" (if you can really call it that), the school created all sorts of
rules governing computer use when all they really needed was some common sense
from their "systems people."

Once you re on a VMS system you should try to get a copy of the program
SYS$SYSTEM: AUTHORIZE.EXE. Once you get a copy of this program, bring it back
to your microcomputer and save it. The AUTHORIZE program should be protected
but often it is not. Once you get it from one system, it is good anywhere.

Now what do you do once you get your own AUTHORIZE program? Create a new UAF,
of course. Enter "$RUN AUTHORIZE." That will generate an error saying that
there is no UAF and a prompt asking if you want to create one. Of course you
do, so you answer yes. Next, enter "UAF) MODIFY SYSTEM/PASS=MANAGER." Now in
your own UAF MANAGER is the system password. So what good is having your own
UAF when the system is not going to use it? Well, why not make the system use
it? At this point you need a privilege called SYSNAM. Many programs, especially
scientific ones, require that the user have it so it is not too difficult to
find an account with this privilege. When you are logged onto the system, enter
"$SET PROCESS/PRIV=ALL"  and then "$SHO PROC/PRIV." If you see SYSNAM listed you
are in luck. Enter "$SHOW DEFAULT" to get your directory name. Then enter
"$DEFINE/ SYSTEM/EXEC SYSUAF dev:[directory]SYSUAF.DAT," where dev and directory
are the names you get from the SHOW DEFAULT command. Now log out and log back
on to the SYSTEM account using the password you just created.

SYSNAM privilege is also nice if you want to just screw up a system. By
redefining such logical names as SYS$SYSROOT, SYS$SYSTEM, SYS$SYSDEVICE you can
bring the system to a halt.

If you have not guessed by now, I am a VMS system manager. I am assuming that
many of the people who are reading this are other system managers who, like
myself, are trying to keep hackers off of their systems. I think the benefit
from system managers reading this in a hacker publication is greater than the
harm that could come from hackers reading it.