Phoenix Rising BBS/phoenixrising.zip/phoenixrising/e-zines/cmsb.tj2

Text File | 1992-09-26 | 27KB | 717 lines

The LOD/H Technical Journal: File #9 of 10


                     Hacking IBM's VM/CMS Operating System
                                     PART B

Command Interpretation Chart: The following chart will compare the commands
used on VAX/VMS, UNIX, and VM/CMS to allow those who are familiar with the
other Operating Systems to quickly reference its CMS counterpart.


+-----------------+---------------+----------------------+--------------------+
! VAX/VMS         ! UNIX          ! VM/CMS               ! SHORT EXPLANATION
!

+-----------------+---------------+----------------------+--------------------+
! /NOCOMMAND      ! *****NONE**** ! NOIPL                ! aborts login pgm
!

+-----------------+---------------+----------------------+--------------------+
! SHOW USERS      ! WHO           ! QUERY NAMES          ! online userlisting
!

+-----------------+---------------+----------------------+--------------------+
! DIRECTORY       ! LS            ! LISTFILE or FILELIST ! show current dir.
!

+-----------------+---------------+----------------------+--------------------+
! TYPE filename   ! CAT filename  ! TYPE fname ftype fm  ! list or view files
!

+-----------------+---------------+----------------------+--------------------+
! EDIT            ! ED or VI or EX! XEDIT                ! system editor
!

+-----------------+---------------+----------------------+--------------------+
! DELETE filename ! REMOVE filenme! ERASE fname ftype fm ! deletes files
!

+-----------------+---------------+----------------------+--------------------+
! PHONE username  ! WRITE user    ! TELL userid          ! user communication
!

+-----------------+---------------+----------------------+--------------------+
! Control-Y       ! Ctrl-Backslash! Hard-break then HX   ! aborts process
!

+-----------------+---------------+----------------------+--------------------+

Corresponding files:


+-----------------+---------------+--------------+----------------------------+
! SYSUAF.DAT      ! /ETC/PASSWD   ! USER DIRECT  ! Userlist & user
information!
! MAIL.TXT        ! USR/MAIL/user ! USERID NOTE  ! Electronic mail files
!
! LOGIN.COM       ! .PROFILE      ! PROFILE EXEC ! User login command files
!

+---------------------------------+--------------+----------------------------+


Local Commands:
---------------

Local commands are commands written for an individual system. They are
customized commands that suit a facilities' needs. These commands are execs
which are either not available from IBM or are cheaper to write on their
own. I will mention a few which may be found on other systems, as these are
rather common.

WHOIS

This command gives a little information about the users that you specify
which
are on the system.

.WHOIS MAINT BACKUP MAILER BUBBA RELAY VMUTIL

Userid    Name
--------- ---------
MAINT     System Maintenance Account
BACKUP    VM System Backup and Recovery Machine
MAILER    BITNET Inter-Node Mail Processing Machine
BUBBA     Bubba B. Bonehead - Programmer/Analyst Extroadinaire
RELAY     BITNET Internet Chat Facility
VMUTIL    VM Utilization Statistics



SYSPASS
READPW
WRITEPW

In most cases, the only way to change a users' password is by having the
system
operator or someone with high privileges do it. This is one reason why many
passwords remain the same for long periods of time. These programs allow
users
to change their logon password, read access minidisk password and write
access
minidisk password respectively. Perhaps you will find these or similar
programs
on some systems.


Privileged Commands:
--------------------

As far as I know, there is no command to determine which privilege class the
userid you are abusing is. The only way is to check in the CP Directory for
it.
The following are some privileged commands and what privilege class is needed
to run them. Again, as far as I know, the system keeps no records of failed
attempts at running privileged commands. Use of these commands are most
likely
recorded, has a msg sent to the system console or both, especially when using
FORCE.


FORCE userid (Class A)

This command will forcibly log off the userid you specify. I really can see
no reason other than to be a total asshole for abusing this command.

DISABLE raddr (or) all  (Class A or B)

This is used to prevent specific terminals or all terminals from logging onto
the system. Again, there is no real reason to use this or most other
privileged
commands for that matter unless you want to be kicked off of the machine. If
you do DISABLE a terminal, simply use ENABLE to repair the damage.

DETACH realaddr (FROM) whatever (Class B)

This is used to detach real devices from the system. These can be terminals,
printers, disk packs, tape drives, etc. You must know the real address of the
device, and 'whatever' can be the system, or a userid.

WARNING userid (or) operator or all (Class A or B)

Warning will send a priority message to a user, operator or all users on the
system. It will interrupt anything they happen to be doing. Obviously sending
a msg to all users stating they are BONEHEADS is not recommended.


MINIDISKS:
----------

A minidisk is a subdivision of consecutive cylinders on a real DASD volume.
The
real DASD device, is the actual disk the information is stored on. This can
be
compared to a hard drive for an IBM PC. Before the drive can be used, it must
be formatted. Once formatted, it is divided up into directories which are
minidisks. Each minidisk is a number of cylinders which is the standard
memory
storage unit. There can be many minidisks on a DASD.  Associated with each
CMS
disk, is a file directory, which contains an entry for every CMS file on the
disk.  A minidisk can be defined for R/W or R/O access. It can also be used
for
temporary or permanant storage of files. Each minidisk has a virtual address.
Virtual addresses can be from 001-5FF (hexidecimal) in basic control mode,
and
001-FFF in ECMODE (Extended Control Mode).

CMS minidisks can be accessed according to a letter of the alphabet (A-Z).
In
order to better explain this, lets assume we are logged onto a VM/CMS system
under the userid of JOE and we want to see what minidisks we have access to.
We use the QUERY SEARCH command to determine which disks we are ATTACHed to.

.Q SEARCH

JOE001  191  A    R/W
JOE002  192  D    R/O
CMS190  190  S    R/O
CMS19E  19E  Y/S  R/O


As can be seen each minidisk has a volume name, virtual address, filemode,
and access mode. The A disk is the default. Most accounts you gain access
with
will have an A disk with a virtual address of 191. The S disk is the System
disk. This contains the files and programs for running the system. The same
goes for the Y disk. The D disk is another disk used by JOE.

You can view what each of these directories contains by issueing the LISTFILE
command.

.LISTF

BUBBA    NOTE     A1
MISC     WHATEVER A1
PROFILE  EXEC     A0


This is a list of files on the A disk. The first column is the Filename the
second is the Filetype and the third is the filemode. Filenames can be
anything
you specify. Filetypes can also be anything you specify, but commonly follow
a
pattern which tells what type of file it is. Filemodes are comprised of a
filemode letter (A-Z) and a filemode number (0-6).

Filenames can contain the following characters: A-Z  0-9  $  #  +  -  :  `  U

Here is an explanation of common filetypes:

Filetype ! Description
---------+-------------
DATA     ! Data for programs or simply TYPE-able text.
EXEC     ! User written programs or IBM procedures written in REXX.
HELP     ! System HELP files.
HELPCMS  ! System HELP files.
LANGUAGE ! One of the langauges that the system supports, such as ASSEMBLE,
         ! COBOL, FORTRAN, JCL, REXX, PL1, SNOBALL, BINARY, ETC.
LISTING  ! Program source code listings
LOADLIB  ! Loading Library
MACLIB   ! Macro Library
MODULE   ! System commands
NETLOG   ! Contains a list of all files which have been SENT to other users.
NOTE     ! Similar to E-MAIL on other systems, a note sent from another user.
SOURCE   ! SOURCE code for various programs.
TEXT     ! Text file. Probably used for programs and when TYPEd yields
little.
TXTLIB   ! Text Library
WHATEVER ! A nonstandard filetype which will probably be somewhat descriptive
         ! of its contents.
XEDIT    ! A file which was created using the XEDIT utility.


Both filenames and filetypes must not exceed 8 characters in length.


Filemodes:

Filemode numbers are classified as follows:

Filemode 0   There is little file security on VM/CMS.  This may be due to the
             fact that directory security is very good.  A file with a mode
of
             zero makes that file invisible to other users unless they have
             Read/Write access to that disk.  When you LINK to someones' disk
             in Read/Only mode and get a directory listing, files with a mode
             of 0 will not be listed.

Filemode 1   This is the default filemode.  When reading or writing files,
you
             do not have to specify a filemode letter of 1 (unless you want
             to) since it will default to it.

Filemode 2   This is basically the same as a filemode of 1.  It is mainly
             assigned to files which are shared by users who link to a common
             disk, like the system disk.

Filemode 3   Be careful when you see these!  These are erased after they have
             been read.  If a file with a mode of 3 is printed or read it
will
             be erased.  Blindly reading files without paying attention to
             the filemode numbers can shorten your stay on the system.  The
             main reason for this filemode is for the files or programs which
             are unimportant or have one time use can be automatically
deleted
             to keep disk space and maintenance to a minimum.

Filemode 4   This is used for files that are to simulate OS data sets. They
are
             created by OS macros in programs running in CMS.  I have not
found
             any files with this filemode, so for the time being, you should
             not be concerned about it.

Filemode 5   This is basically the same as filemode 1.  It is different in
that
             its used for groups of files or programs.  It makes it easier
for
             deleting files a user wants to keep for a certain period of
time.
             You could just enter:

             ERASE * * A5

             Now all files on the A disk with a filemode of 5 will be
deleted.

Filemode 6   Files with this mode are re-written back to disk in the same
place
             which is called "update-in-place".  I have no idea why this
would
             be specified, and have not found any files with a filemode of 6.


Filemode 7-9 These are reserved for IBM use.



Look back to our Q Search listing. If you want to see what is on the D disk:

.LISTF * * D

NOTMUCH ONHERE D1

In this case, the D disk only contains 1 file called NOTMUCH with a filetype
of
ONHERE. But do not forget the fact that you only have Read/Only access to the
D minidisk! So there may or maynot be merely 1 file on the D disk. Remember
all
filemodes of 0 (which in this case would be D0) are invisible to anyone who
does not posses Read/Write access.

You can access any disk that you are ATTACHed to by replacing the D in the
above example with the filemode letter (A-Z) you want to access. As was shown
previously, the QUERY SEARCH command will give you a list of minidisks that
your userid is attached to upon logging in. These command statements are
usually found in your PROFILE EXEC.


So you can access a few minidisks. There may be hundreds on the system.
Unlike
UNIX and VMS, and most other Operating Systems for that matter you cannot
issue
a command and some wildcard characters to view the contents of every users'
directory. In order to access another users' directory (minidisk) you must
have
the following:

1) The USERID of the person whose disk you wish to access.

2) The virtual address(es) (CUU) that the USERID owns.

3) The Read, Write, or Multi disk access password, depending on which
   access mode you wish to use.

This would be accomplished by the following:


.LINK TO BUBBA 191 AS 555 RR

Enter READ link password:
 *************************
 HHHHHHHHHHHHHHHHHHHHHHHHH
 SSSSSSSSSSSSSSSSSSSSSSSSS
.RBUBBA

R; T=0.01/0.01 21:58:48
.ACCESS 555 B

R; T=0.01/0.01 21:59:03
.Q SEARCH

JOE001  191  A    R/W
BUB001  555  B    R/O
JOE002  192  D    R/O
CMS190  190  S    R/O
CMS19E  19E  Y/S  R/O

.LISTF * * B

MISCFILE DATA     B1
PROFILE  EXEC     B1

.REL 555

R; T=0.01/0.01 22:02:01

Now an explanation for the events which have just occured.

The LINK command is used to access other users' minidisks. The format is:

.LINK (TO) USERID VADDR1 (AS) VADDR2 (MODE) ((PASS=)PASSWORD)

BUBBA is the USERID whose disk we wish to access.

VADDR1 is a virtual address which belongs to the BUBBA userid. If BUBBA was
to
access our minidisk whose userid is JOE, he could access either our 191
address
or our 192 address. The 190 and 19E addresses are usually automatically
accessed by nearly all the users of the system since it contains system
commands. We are assuming that BUBBA indeed has a minidisk with the virtual
address of 191. Some userid's may not have any or they may have addresses
which
are somewhat obscure, say of 13A or 503. The only way we would be able to
access those assuming BUBBA did not give them to us would be to guess them.
This would be rather difficult, timeconsuming, and dangerous as we will soon
see.

VADDR2 is any address which is not currently in our control, (ie. in our Q
Search which would be 190, 191, 192, 19E) and is in the range of 001 to 5FF
in
Basic Control or FFF in Extended Control. In this example, we chose to use
555.
We could have easily used 104, 33F, 5FA, etc.

MODE is the access mode which consists of up to 2 letters. The first letter
specifies the Primary access mode. The second letter is optional and
designates
the alternate access mode. If the primary mode is not available, the
alternate
is used.

The access mode we used was RR. Valid access modes are:

R   Primary Read/Only access. This is the default. You can opt to not specify
    an access mode when linking to a users' disk, and this is the mode which
is
    used. It will only work if no other links are in effect.

RR  This allows read access no matter what links are in effect to that users'
    disk.

W   Primary Write access. This is only good if no other links are in effect.

WR  If Write is available then the link will be made, if not it will goto
Read.

M   Primary Multiple access.

MR  Resorts to Read if Multi is unavailabe.

MW  This garauntees write access no matter what.


If another user has write access to one of your disks when you log on, your
access will be forced to Read/Only. For this reason, you should have read
access to others disks instead of write. If you wish to see what files have a
filemode of zero, then link with write access, view or access those files,
then
RELEASE the disk and re-access it via read to avoid suspicion by that user of
unauthorized individuals gaining write access to his files.

If a user has write access to a disk, you cannot gain write access unless you
use a mode of MW. It is not recommended to have write access to anothers'
disk
if they themselves have write access. CMS cannot guarantee the integrity of
the data on a disk which has more than one person linked to it with write
access. Now if you see that the user is in a disconneced (DSC) state through
the Q NAMES command, then it shouldn't be a problem if you have write access
also since the person is not active. If that person re-connects however, then
it is advisable to RELEASE that disk as soon as possible to avoid any chance
of
data being destoyed.

PASS=PASSWORD  like the logon password, it can be a 1-8 character string that
MUST match the access mode password for the VADDR1 of the userid which you
are
attempting to gain access to. Up to three access mode passwords can exist for
each minidisk, R, W, and M.

If the installation uses the Password Suppression Facility, an INVALID FORMAT
message will be issued when you attempt to enter the password for a disk on
the
same line as the LINK command was entered on. Obviously this is to prevent
people from 'spoofing' the password off the screen or from printouts found in
the trash. If this occurs, just hit return after entering the access mode,
and
wait for the enter password response.

Every disk password along with every users password and other information is
contained in the CP Directory. If the password is "ALL" then a password is
not
required for any user so you will not be asked for one. You will then recieve
a ready message indicating that the transaction has just been completed.

If you receive the message: "BUBBA 191 NOT LINKED; NO READ PASSWORD" then
within the CP Directory, there is no read password at all. This means that
the
only way you can gain access to BUBBA's directory would be by getting his
logon
password. One note, I believe that a users logon password cannot be any of
his
access mode passwords. The reasons for this are obvious. If BUBBA wants JOE
to
access a disk, then he can give JOE the corresponding disk password. If this
was identical to his logon password then JOE could logon as BUBBA and access
all BUBBA's disks with no problem, and at the same time posses all the privs
that BUBBA has. Within the CP directory, if there is no password entry for
read
access then there are no entries for write nor multi. If there is no entry
for
write then there may or may not be an entry for read, but definitly not one
for
multi. And finally if there is no entry for multi then there may or may not
be
entries for read and write.

The methods for obtaining disk access passwords are the same as anything
else.
Common sense and "Password Psychology" come into account along with the
element
of luck.

Assume the userid is VMTEST and you are hacking the READ password. Passwords
may be: RVMTEST, RVM, RTEST, RTESTVM. Others may be READ, READVM, VMREAD,
READTEST, TESTREAD and even VMTEST. Of course it could be something like:
J2*Z5
Many times the same password will be used for R, W, and M access instead of
three separate passwords.

CP keeps track of unsuccessful LINK attempts due to invalid passwords. When
you
exceed the maximum number of incorrect password attempts, which usually
defaults to 10, the link command will be disabled for the remainder of your
stay on the system. All you have to do is re-logon and you will have full use
of LINK again.

If the LOGON/AUTOLOG/LINK journaling facility is activated, unsuccessful link
attempts due to the above are recorded. When the threshold is reached the
userid whose password you are trying to hack is sent a message. Therefore,
keep
track of the number of attempts you make and keep just short of the system
threshold.

After successfully linking to a users' disk, you must issue the ACCESS
command
in order to get a directory listing or access any files on that disk. This is
accomplished by:

.ACCESS VADDR2 B

VADDR2 is the address after 'AS' in your link command line, and 'B' is the
filemode letter which you wish to access the disk as. This can be anything
but
the letters which you have already assigned up to a total of 26 (A-Z).

After accessing the disk to your hearts content, you can then RELEASE it.
When
you logoff the disk is automatically released. Releasing the disk is not
necessary unless you already are attached to 26 minidisks, and you want to
access more. You would then release whatever disks you wish and link then
access others. After releasing disks, and you want to re-access that disk,
you
do not have to issue another link command but merely the ACCess command and
what filemode you wish it to be.

The QUERY DASD command will list the minidisks that most everyone on the
system
has access to. All of these may or maynot be automatically accessed upon
logon.
For this reason, you should issue it, then all you have to do is ACCess the
virtual address and define the filemode.

.Q DASD

DASD  190  3380  SYSRES  R/O   32 CYL
DASD  191  3380  SYSRES  R/W    1 CYL
DASD  192  3380  SYSRES  R/O    2 CYL
DASD  193  3380  SYSRES  R/O   19 CYL
DASD  194  3380  SYSRES  R/O   21 CYL
DASD  19E  3380  SYSRES  R/O   27 CYL

In our Q SEARCH list, we have access to 190 as the system disk, 191 as our A
disk, 192 as our D disk, 19E as the systems' Y disk. Both 193 and 194 are
accessable but have not been accessed by us. Thus:

.ACC 193 B
B (193) R/O
.

Now the 193 disk is our B disk and accessable by us. You can perform the same
procedure for the 194 disk.


DIRMAINT:
---------

The Directory Maintenance utility can be found on some systems. If it is
running, DIRMAINT should be a valid userid. The DIRMAINT userid is
automatically initialized when the system is started up. It remains in
Disconnected mode awaiting transactions which contain directory maintenance
commands.


If you come across a system with DIRMAINT, it will provide you with all the
information you need to know about it. A few commands are important, at least
to the hacker:

MDPW  This displays access passwords for one or all of that userid's
minidisks.

.DIRM MDPW
DVHDIR005R ENTER CURRENT CP PASSWORD TO VALIDATE COMMAND OR A NULL TO EXIT:
R; T=0.12/0.15 19:33:34
 DVHMDF301I MINIDISK 191: RBUBBA     WBUBBA    MBUBBA
 DVHMDF301I MINIDISK 192: RBUBPW     BONEHEAD  MULTIBUB

The reason you must enter the users logon password is obvious. If someone
walks
up to a users terminal and wants to know what the guys disk passwords are all
he would have to do is enter this command and would get them, except for the
fact that it does ask for the users logon password, thus, protecting the disk
passwords.

Help   Get more info on DIRM commands.
PW     This changes a users logon password
PW?    Find out how long it was since the user changed his logon password.
MDISK  Change access mode, change, add, or delete passwords.
LINK   Cause an automatic link, at logon, to another users minidisk.
FOR    Enter a DIRMaint command for another user if authorized.


THINGS YOU WANT:
----------------

Things you want are: More valid userid's to try passwords on, actual logon
passwords, and disk access passwords. Obtaining userid's can be accomplished
by
using the Q NAMES command every time you logon. Obtaining logon passwords
isn't
as simple. There are a couple of places which you will want to explore.

The AUTOLOG1 or AUTOOP virtual machines (userid's) usually auto-logon other
userid's. Now, in order to do this they must have those users' passwords.
These
are contained within various EXECs within their user directory. If you can
obtain a valid disk access password for whichever one of these is running on
your particular system, you can get more passwords and possibly some disk
access passwords for about 10 other userid's. This should allow you to get
more
disk access passwords and hopefully more logon passwords. Nevertheless,
having
obtained a few more passwords, and not using them until the original one you
hacked dies, will greatly extend your stay on the system.

EXEC files from any user may contain more disk access passwords for other
users
and those users directories may contain EXECs which have more passwords, and
so on. Of course many other types of files may contain this type of
information.

The CP directory, this is similar to a big bullseye on a target. This
directory, as previously explained contains users' passwords, various system
information and minidisk passwords. The directory usually goes under the
filename/filetype of USER DIRECT. It can be anywhere on the system, and can
have a different name which in my view would add to system security. It is
usually found in either or both of two users' directorys which I leave to you
to find (sorry). This is a very big weakness in CMS due to the fact that if
you
can find what userid the directory is in, and it's disk access password,
you've
got the system by the balls. The file may also have a filetype of INDEX which
is a compilation or sorting of pertinent information used for speeding up
various procedures the system carries out constantly. A typical entry in the
USER DIRECT file would look like:

USER BUBBA BUBAPASS 1M 3M BG

VMU01000
 ACCOUNT 101 SYSPROG

VMU01010
 IPL CMS

VMU01020
 CONSOLE 00D 3215

VMU01030
 SPOOL 00C 2540 READER *

VMU01040
 SPOOL 00D 2540 PUNCH *

VMU01050
 SPOOL 00E 1403 A

VMU01060
 LINK MAINT 190 190 RR

VMU01070
 LINK MAINT 19D 19D RR

VMU01080
 LINK MAINT 19E 19E RR

VMU01090
 MDISK 191 3350 152 003 VMPK01 MR RBUBBA WBUBBA   MBUBBA
 MDISK 192 3350 152 003 VMPK01 MR RBUBPW BONEHEAD MULTIBUB

VMU01100
*


The first line gives the userid of BUBBA, password BUBAPASS, 1 and 3 Megs of
virtual memory, and Privilege Classes B and G. The next line gives the
account
number and department or owner of the account. The next few lines define
miscellaneous system information. Next, three lines of what disks should be
automatically linked to upon logon. And finally the minidisk (MDISK) virtual
addresses and corresponding passwords.


CONCLUSION:
-----------

As usual, there is always more I could add to an article like this one. I did
not want to keep writing part after part so I wrote a 'complete' article on
Hacking VM/CMS. I apologize for its length of over 50K but I wanted to
mention
everything you needed to become familiar with the Operating System and its
Security/Insecurity. I intentionally 'forgot' to mention various information
which would put sensitive and destructive information in the hands of anyone
who reads this article. The information within this article can and will be
different from system to system so don't take anything too literally. This
article is comprised: 80% information from actual system use, 10% CMS help
files, and 10% from various CMS documentation. I may write a followup article
of shorter length as more people become familiar with CMS.

Lex Luthor




Downloaded From P-80 International Information Systems 304-744-2253 12yrs+