=============================================================================== 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-----------