=============================================================================== RUSH2112 Presents A HALE Production H ackers A gainst L aw E nforcement Call HALE Hq. (619)660-67xx Active HALE members are: Ripper, Trashman, Rush2112. The Underground Newsletter: Vol I. Issue I, Part I =============================================================================== Note: Feel free to distribute the file provided none of its contents or credits are changed. Topic: A Guide to Unix Systems, Part I. Date: September 1, 1989. Foreword: This file is compiled from my experiences on both BSD and Sys V Unix on VAX 750/780 mainframes, AT&T 3B20 and Pyramid Technology's mainframes. In today's world, as a hacker, you are nothing unless you learn some of the more popular operating systems around used on minis, mainframes, super- computers and the like. In this file I will attempt (to the best of my ability) to introduce you to one of those operating systems - namely - the world of Unix. It is hoped that by reading this file you can pick up perhaps enough of a working knowledge so that if by chance in your hacking exploits you come across a Unix system (and you will) you'll know what to do. There is NO WAY to cover everything about Unix in a file so this will be the first of many that I hope to release in the future. If I find there are stuff I have not mentioned I will write more files as needed. In Part II, I plan to give you a tutorial on what to do while you're on-line in regards to hacking and using essential system utilities. Have fun. Usually (unless modifified by the system administrator or one with such privileges), you can tell if you've connected to a Unix system of some type by the login prompt which looks like this: login: Pretty simple huh? Anyway, that is the standard login prompt, it may or may not be preceded by a message telling you what type of Unix or system you have connected to. If you try to login with an illegal login name and/or an illegal password the system will respond as such and as you to try again: login:hacker password: login incorrect login: (Note the password is not echoed in any form) In Part I of this Unix tutorial I'd like to start with an overview of the Unix system before I get into some of the more interesting stuff (so bear with me all you Unix experts). Then I will go through the login process and the /etc/passwd file and how it is structured. This will not be an in-depth look at all, merely an overview. Some day I will write an in-depth study to accompany this file and the files that follow for the more advance user/hacker. There are basically 2 types of Unix systems that you will most likely come across. They are: I. BSD Unix - from UC Berkeley's (B)erkeley (S)oftware (D)istributors II. System V UNIX - from AT&T (how nice - I know all you phreakers are smiling!) (Other spinoff's of the above 2 will not be discussed - such as Ultrix, Minix, Xenix, etc...) They are alike in many respects but both have their differences, hence their are advantages and disadvantages to both of the systems, BSD and Sys V. Perhaps the main difference between the two are the default shell that each uses as the user interface to the system utilities. BSD Unix defaults to the csh (C-Shell) while AT&T's Sys V uses the sh (Bourne shell). But on both of these systems both shell types are available to the user. A third optional shell which is also pretty popular is the ksh (Korn shell). The way to recognize the default shells when you see them is by their default prompt. The csh uses the % symbol as the prompt while the sh uses the $ symbol as the prompt. Now let's talk about files, shall we? The MOST important file of all on ANY UNIX system is the password file. This file holds information about all the accounts on the system, passwords, and other information. Without this file no one can log in and use the system. You can find this file on any system in the /etc directory. It is called simply 'passwd'. The full pathname is /etc/passwd (of course). The /etc/passwd file is stuctured as such: Each user has an entry in the passwd file that holds his account information. Among the information included on each user entry line is his login name, his password (encrypted), his user id, his group id, his home directory, his name, and his startup program if any. Basically it looks something like this: ------------------------ Sample /etc/passwd file -------------------------- General format of each entry: login:password:user-ID:group-ID:info:home directory:startup program root:Arllz76Dnq:0:0:The & of All Evil:/:/bin/csh jsmith:Yi83amq9:102:100:John Smith:/usr/jsmith:/bin/sh who::99:500:Who's on:/usr/ucb:/bin/who daemon:r6Eeu:1:1:The DEVIL himself:/etc:/bin/csh bin:mb033yt:3:3:The Keeper of the Flame:/etc:/bin/csh info::508:501:Library user group:/usr2/info:/usr2/bin/rsh ..... ..... [ and so on ] ..... ---------------------------------------------------------------------------- Now we'll examine each entry. Remember that each field is separated by the colon. So in the first entry in /etc/passwd given above, we can tell the following about the entry. login name is: root Password (encrypted): Arllz76Dnq User ID: 0 Group ID: 1 Info (usually owner): root Home Directory: / Startup Program: /bin/sh The second entry in /etc/passwd looks like this: login name is: jsmith Password (encrypted): Yi83amq9 User ID: 102 Group ID: 100 Info (usually owner): John Smith Home Directory: /usr/jsmith Startup Program: /bin/sh But now you get the general format...so let's discuss some things about the field. I. The login field This is the login name that you use to login at the prompt of the Unix system. During the login process, after you enter the login and the password the system will then call routines to search the 1st field of each entry in /etc/passwd to see if any login names match up with the one you have given it. If none exists it will report the "login incorrect" message and start prompting for a new login name and new password. II. The Password field If the login name is valid, Unix then takes your password entry and encrypts it then compares it against the encrypted password in the 2nd field of the login name entry (see I. The login field). If the two passwords match up, the login process will continue, otherwise the "login incorrect" message will be displayed. I'll explain later what goes on when comparisons of the encrypted passwords take place. If the Password Field contains null :: then no password is needed and the system logs you into the home directory and executes the startup program. If the Password Field contains :,.: then upon login the system will run the passwd utility and assign that account a password. (This is nice if you're a system administrator, you create an account for your friend then put the ",." in the password field and he'll set his own password upon login. III. The UID (UserID) field If everything is correct (login name and password) then the system proceeds to put your in your home directory. You are then given a UID from your entry in the /etc/passwd file. All UID's fall in the range 0-65535 with 0 as the superuser UID (see /etc/passwd example). The system reserves UID 0-99 for special accounts. UID's are used by the system and its utilities to control both access levels and file ownership (as determined by the ls utility - more on that later). IV. The GID (GroupID) field The Group ID is used to associate the user with a certain group, used by Unix primarily for access levels as determined by file protections. (i.e. a member who is not in a group can not get group privileges on files for that group, even though file protections for the file say all privileges to group users.) GID's fall in the range 0-655535 with GID 1 being the default. All GID's between 0-99 are reserved. V. The Information field This field usually holds the account owner's name though it can be used for anything actually. I have seen it used to describe the account function (see the sample /etc/passwd file on the entry for login name "who"), and also to hold people's phone extension, etc.. VI. The Home Directory Field This field should have the full pathname to your home directory. On many UNIX systems it is usually in the format of /usr/{loginname} (See the entry for login name "jsmith"). Not necessarily your PERMANENT home directory, one can change it by reassigning an alternate path to the system variable $HOME (on Sys V). VII. The Program Field Usually this field holds the startup program to execute once the login procedure has been completed. If left blank then the default startup program will be the shell assigned to the Unix system. In the our example /etc/passwd file, the entry for login name who, will execute the who command in /bin/who once you log in. However, after the command finishes executing, it will exit the system as there is no password on the account, there is no way to stay logged in. On the info account however, you will remain login until you type exit or logout or CTRL-D as the program running there is a shell. Though not a full Bourne shell or C-shell, the restricted shell (rsh) does allow to you play around a little. Well, that about does it for what I want to cover in Part I. Look for Part II coming out real soon. I will be going into details what to do once online with an account and how to go about getting an account. This file is for informational purposes only. ------------------------------------------------------------------------------ Brought to you by: The Apple Bandit 10-89 =============================================================================== RUSH2112 Presents A HALE Production H ackers A gainst L aw E nforcement Call HALE Central. (619)472-0xxx Active HALE members are: Ripper, Trashman, Rush2112. The Underground Newsletter: Vol I. Issue I, Part II =============================================================================== Note: Feel free to distribute the file provided none of its contents or credits are changed. Date: September 3, 1989. Topic: A Guide to Unix Systems, Part II. In Part I of TUN, I explained the very basic fundamentals of the Unix operating system. In Part II, which I'm sure a lot of you will be more interested in, I will show you a sample run of how and what a hacker would do (for example - what I would do) if I were on some unknown Unix account. I. Access to a Unix account. First off, you need to find yourself an account. Briefly, here are some of the most popular methods I use some of which are hard and some of which are easy. 1. You can try to hack one out at the login: prompt. Of course this is the old traditional method of trial and error and some standard login accounts. (It is suggested but as a last resort - though it has worked for me in the past I opt for other routes to getting an account.) Well, the first thing of course when you hit a Unix system is to try the standard accounts. This would include: uucp, nuucp, daemon, ftp Some systems include public accounts that you may also want to try as many of them give you shell access. You might want to try: guest, info, bbs, games Sooner or later, you'll find a system that has a vulnerability like non-passworded accounts or simple passwords for a login. Some of the things you should try are the login names as a password. Even the magazine UNIX Review claims it was surprised how entries in /etc/passwd on systems they checked used login names as the actual passwords. My own experiences shows this is true. 2. You can get one if you know someone who already has a Unix account. (I find this works very well, by working from the inside you're guaranteed to get an account if you know what you're doing.) Of course the hack attack from the login: prompt could be fruitless and you may never get an account this way so the best way to get into a Unix system is from the inside. This means of course you know someone on that system with an account, who could help you find an account either by searching the /etc/passwd for non-passworded account with shell access. Or hunting the entire file system for files with "other" and/or "group" privileges in hopes of finding a password or some account names or other neat info to get you started on Unix. 3. You can try a trojan horse program to gain someone's login and password. Some popular trojan horses are password capturing programs and emulators that emulator the login screen. This method by-far is the EASIEST way to do it but it requires you have an account to run the trojan horse from. This can be done easily if your friend lets you use his account. You won't even have to tell him what you're using it for. I'll have more about this at a later date. Maybe an issue on trojan horses and emulators, etc.. is in order? II. Working with an account. Once you have access some important points to remember and do are: 1. Set history to 0 if on BSD or erase .history on Sys V before logoff 2. Turn off your messages. 3. Get a buffer of the /etc/passwd. 4. Get a buffer of the login process. 5. Get a buffer of the ENTIRE file system online. Assuming that you have gotten into someone else's account, the first thing to do when you log in is shut your messages off with "mesg n" (messages no). This will turn off write permission to your tty in /dev/ttyXX (where XX is your tty number). It will prevent people from writing to you while you're online buffering system information. It will also stop people from redirecting output to your tty. Plus, you'll be busy so you want no disturbances of any type. If you're on an account running csh you should set the history to 0. You can do that with the command 'set history=0'. History is just that... it keeps a history of everything that you do, all the commands you pass to the csh is stored. Typing 'history' by itself will show you a list of previous commands entered by the user. By setting it to 0, it will not record your commands from the shell. On Sys V under Bourne shell, history is stored sometimes in the "hidden file" .history in your home directory ($HOME/.history) You should delete the file before logging off. Now you should get a copy of the password file. This is easily accomplished with 'cat /etc/passwd'. Make sure you buffer the contents, you'll need this for later. You may also wish to get the /etc/group file, this file has information on all the groups on the system along with members of each group. (I'll talk about groups in another file.) Just type 'cat /etc/group' and buffer its contents. Now comes the interesting part. You'll want to get a listing of every single file on the system and buffer it. Here's what you would do: $cd / (at this point open your buffer) $find . -type f -exec ls -al {} \; (when this is finish, close your buffer) This will take quite a while if the system you're on has a lot of files. Basically, you are going to the root directory ('cd /') which is the top of the directory tree hierarchy. From there you will execute the 'find' command which is a file find utility. We are asking it to print out all the filenames of type 'f' (which is normal file) from the current directory (which is root) and all directories below it (which is the rest of the directory tree) and search all files recursively and pass its findings via -exec to the "ls" utility which will list its file information (-al including file attributes).. but anyway, if this is too complicated to follow, don't worry. Try typing 'man find' for perhaps a better explanation. Suffice it to say you should now have buffered a listing of all files in the directory tree. Next take a look at your hidden files like .profile on Sys V or .login and .cshrc on BSD Unix. They contain login information such as commands to automatically execute and perhaps some aliases definitions. If there is anything interesting you should buffer it. Find out who the hell is on at the time with the "who" command. Then find out what everyone is doing with the "ps" command. For example on Sys V Unix you might do something like this: who -HTu (see "man who" for what the full explanation of all switches) - basically this shows all users on currently and gives other information on their tty status like "mesg y" or "mesg n" (A + means messages are on, a - means messages are off.) It will also report tty IDLE time, nice to know if someone is working or not. After you see who's on, you'll want to know what they're doing. This can be done with the "ps" (Process Status) command: ps -fu username (read the on-line manual for full options) - where username is the login name of whoever it is that you wanted to check up on. ps -fa | more - shows ALL processes on the system. Piping through more will pause tty output every screenful. Using the "ps" utility is handy in getting some interesting paths to programs run by users on the system as it shows the path to the entire process. I have found many neat programs and utilities by watching what other people do on the system with the "ps" command. At this point you are interested in getting your own account if possible. You have several options now. You could install a trojan horse program in hopes of getting an account or you may want to play around with the account you have. Installing a trojan horse. I'll be going into more details about trojan horses in a future issue of TUN as there are many ways to do this. You should check first to see that your Unix system has a C compiler on it. (yes, you'll unfortunately have to know a little bit of programming so go get those books on C and start reading!). If it doesn't have a C compiler you'll be out of luck, but not completely helpless, you could start writing shell scripts (again probably another issue of TUN to cover shell scripts). If you want to play around on the system, here are a few things to do. One of the most basic tricks of Unix is called i/o redirection. This is a process whereby you "redirect" standard input/output to some other device. An example would be if I were to send a file to my screen to look at it, I would redirect the output to another file, or screen, or printer, or any other device on the system. Let's go with redirection to a file for a simple first step. Suppose I had a text file called "textfile001". To view to the screen I would type: $cat textfile001 What happens when you type the 'cat' command is it views the file and send its output to your tty or terminal screen. Now if I were to do this: $cat textfile001 > newfile You can see that nothing happens to the screen and it will come back to the main prompt. However you will now have a new file called "newfile" whose contents are those of textfile001. The redirection symbol > told it to cat the file textfile001 but redirect standard output to the file called "newfile". Using this principal, you can try to redirect things to people's tty's or terminal screen. (Note - redirection to tty's will not work on BSD Unix ver 4.3 due to a bug fix.) The way to do that is like this: $cat textfile001 > /dev/ttyXX Where XX is the tty number you wish the standard output to go to. So for example if I were to do a 'who' command and I find that there is a user name 'steve' on the system on 'tty12' I could send the text file to his tty with: $cat textfile001 > /dev/tty12 Now the standard output of 'cat' will go to tty12 which belongs to user steve. Another trick to to redirect stty outputs to people's tty's. The stty command handles certains setups for your tty, including how to process erase keys, interrupt keys, baud rate, hangups, etc... For a list type 'man stty' to get the on-line manual entry for stty. Anyways, the command stty 0 will automatically terminate phone connection to the system (i.e. hang you up). So if you were to type: $stty 0 You would gracefully exit the system with a &[1 NO CARRIER or some equivalent. Now using redirection you can send your stty commands to other tty's. So using the above example of stty 0: $stty 0 > /dev/tty12 will hang up user steve. Unfortunately, due to the way Sys V handles stty processing, this will not work on System V or later versions of BSD Unix (4.3 to be exact.) Other nasty things to do is to cat binary files to people's tty. Due to the big file sizes of certain binary executables you should do redirection in the background..that is with the & symbol at the end of the command line. For example to send the "ls" binary file to user steve we would type: $cat /bin/ls > /dev/tty12 & Once typed in, you will get a Process ID (PID) or job number (on BSD) for the background job. You will also get your prompt back so you can proceed as normal while Unix is sending the ls binary to user steve. To kill the process you could type: $kill -9 PID where PID is the number returned to you from the background command. On BSD: $kill %jobnumber for example if the job number returned was 1 then $kill %1 will do the job. This is handy to remember since doing a ps -fu username on your username will reveal you are sending him a binary file in the background. You could easily be dubbed the culprit messing with people's tty's. Well, at this point I would like to wrap up Part II. If there are typos my apologies.. it's late. Part III will be a bit more technical but hopefully you'll get something out of it. I will be going over trojan horses and emulators, and perhaps a discussion of file protections is in order and of course how to get other people's files and give yourself more permission. This file is for informational purposes only. Brought to you by: --------H.ackers--------A.gainst-----------L.aw---------E.nforcement-----------