The Hacker's Encyclopedia 1998

home *** CD-ROM | disk | FTP | other *** search

/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / zines / a_m / lodhtj02.009 < prev next >

Wrap

Text File | 2003-06-11 | 26.0 KB | 606 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 SD 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