to some crackers, and certainly leads to both the addiction and self-perpetuation of cracking. As to the "How" of the question, this is again a very sketchy area. In universities, it is extremely common for computer account to be passed back and forth between undergraduates: "Mary gives her account password to her boyfriend Bert at another site, who has a friend Joe who "plays around on the networks". Joe finds other crackable accounts at Marys site, and passes them around amongst his friends..." pretty soon, a whole society of crackers is playing around on the machines that Mary uses. This sort of thing happens all the time, and not just in universities. One solution is in education. Do not let your users develop attitudes like this one: "It doesn't matter what password I use on _MY_ account, after all, I only use it for laserprinting..." - an Aberystwyth Law student, 1991 Teach them that use of the computer is a group responsibility. Make sure that they understand that a chain is only as strong as it's weak link. Finally, when you're certain that they understand your problems as a systems manager and that they totally sympathise with you, configure your system in such a way that they can't possibly get it wrong. Believe in user education, but don't trust to it alone. ------------------------------------------------------------------ Q.9 Who can I contact if I get broken into? If you're connected to the Internet, you should certainly get in touch with CERT, the Computer Emergency Response Team. To quote the official blurb: >From: Ed DeHart > The Computer Emergency Response Team (CERT) was formed by the Defense > Advanced Research Projects Agency (DARPA) in 1988 to serve as a focal > point for the computer security concerns of Internet users. The > Coordination Center for the CERT is located at the Software Engineering > Institute, Carnegie Mellon University, Pittsburgh, PA. > Internet E-mail: cert@cert.org > Telephone: 412-268-7090 24-hour hotline: > CERT/CC personnel answer 7:30a.m. to 6:00p.m. EST(GMT-5)/EDT(GMT-4), > and are on call for emergencies during other hours. ...and also, the umbrella group "FIRST", which mediates between the incident handling teams themselves... >From: John Wack >[...] FIRST is actually a very viable and growing >organization, of which CERT is a member. It's not actually true that, >if you're connected to the Internet, you should call CERT only - that >doesn't do justice to the many other response teams out there and in the >process of forming. >NIST is currently the FIRST secretariat; we maintain an anonymous ftp >server with a directory of FIRST information (csrc.ncsl.nist.gov: >~/pub/first). This directory contains a contact file that lists the >current members and their constituencies and contact information >(filename "first-contacts"). >While CERT is a great organization, other response teams who do handle >incidents on their parts of the Internet merit some mention as well - >perhaps mentioning the existence of this file would help to do that in a >limited space. The file mentioned is a comprehensive listing of contact points per network for security incidents. It is too large to reproduce here, I suggest that the reader obtains a copy for his/her self by the means given. ------------------------------------------------------------------ Q.10 What is a firewall? A (Internet) firewall is a machine which is attached (usually) between your site and a wide area network. It provides controllable filtering of network traffic, allowing restricted access to certain internet port numbers (ie: services that your machine would otherwise provide to the network as a whole) and blocks access to pretty well everything else. Similar machines are available for other network types, too. Firewalls are an effective "all-or-nothing" approach to dealing with external access security, and they are becoming very popular, with the rise in Internet connectivity. For more information on these sort of topics, see the Gateway paper by [Cheswick], below. ------------------------------------------------------------------ Q.11 Why shouldn't I use setuid shell scripts? You shouldn't use them for a variety of reasons, mostly involving bugs in the Unix kernel. Here are a few of the more well known problems, some of which are fixed on more recent operating systems. 1) If the script begins "#!/bin/sh" and a link (symbolic or otherwise) can be made to it with the name "-i", a setuid shell can be immediately obtained because the script will be invoked: "#!/bin/sh -i", ie: an interactive shell. 2) Many kernels suffer from a race condition which can allow you to exchange the shellscript for another executable of your choice between the times that the newly exec()ed process goes setuid, and when the command interpreter gets started up. If you are persistent enough, in theory you could get the kernel to run any program you want. 3) The IFS bug: the IFS shell variable contains a list of characters to be treated like whitespace by a shell when parsing command names. By changing the IFS variable to contain the "/" character, the command "/bin/true" becomes "bin true". All you need do is export the modified IFS variable, install a command called "bin" in your path, and run a setuid script which calls "/bin/true". Then "bin" will be executed whilst setuid. If you really must write scripts to be setuid, either a) Put a setuid wrapper in "C" around the script, being very careful to reset IFS and PATH to something sensible before exec()ing the script. If your system has runtime linked libraries, consider the values of the LD_LIBRARY_PATH also. b) Use a scripting language like Perl which has a safe setuid facility, and is proactively rabid about security. - but really, it's safest not to use setuid scripts at all. ------------------------------------------------------------------ Q.12 Why shouldn't I leave "root" permanently logged on the console? Using a 'smart' terminal as console and leaving "/dev/console" world writable whilst "root" is logged in is a potential hole. The terminal may be vulnerable to remote control via escape sequences, and can be used to 'type' things into the root shell. The terminal type can usually be obtained via the "ps" command. Various solutions to this can be devised, usually by giving the console owner and group-write access only , and then using the setgid mechanism on any program which has need to output to the console (eg: "write"). ------------------------------------------------------------------ Q.13 Why shouldn't I create Unix accounts with null passwords? Creating an unpassworded account to serve any purpose is potentially dangerous, not for any direct reason, but because it can give a cracker a toehold. For example, on many systems you will find a unpassworded user "sync", which allows the sysman to sync the disks without being logged in. This appears to be both safe and innocuous. The problem with this arises if your system is one of the many which doesn't do checks on a user before authorising them for (say) FTP. A cracker might be able to connect to your machine for one of a variety of FTP methods, pretending to be user "sync" with no password, and then copy your password file off for remote cracking. Although there are mechanisms to prevent this sort of thing happening in most modern vesions of Unix, to be totally secure requires an in-depth knowledge of every package on your system, and how it deals with the verification of users. If you can't be sure, it's probably better not to leave holes like this around. Another hole that having null-password accounts opens up is the possibility (on systems with runtime linked libraries) of spoofing system software into running your programs as the "sync" user, by changing the LD_LIBRARY_PATH variable to a library of your own devising, and running "login -p" or "su" to turn into that user. >From: chowes@sfu.ca > >Don't forget LD_LIBRARY_PRELOAD! You can point it to a library that >contains routines to override LD_LIBRARY_PATH routines. Main advantage >is that the library is a lot smaller by virtue of only having the >doctored routines, not *every* routine; and also that some people >forget to protect both. [Just how many more of these LD_* variables ARE there ? - Alec] >From: barnett@alydar.crd.ge.com (Bruce Barnett) > >One more thing you may want to mention is that each network service must >be checked to see if there is any security problem. Not all services >use the shell entry in a passwd file. Therefore having a null password >make allow other services to break into the account. > >For instance, some systems that provide remote file access uses the >username and password to verify access. The shell entry is not used. > >Therefore it is possible for someone to use the "sync" account to >"mount" a Unix file system, getting access to the account without using >the shell. > >To be precise, I used Sun's TOPS service on a Macintosh to mount a Unix >file system thru the sync account as it didn't have any password. I has >user ID "1" when I did this. Don't know if this needs to be added to >the FAQ... I did notify Sun a while ago about this bug.... ------------------------------------------------------------------ Q.14 What security holes are associated with X-windows (and other WMs)? Lots, some which affect use of X only, and some which impact the security of the entire host system. I would prefer not to go into too much detail here, and would refer any reader reader looking for detailed information to the other FAQ's in relevant newsgroups. (comp.windows.*) One point I will make is that X is one of those packages which often generates "Incompatible Usage" security problems, for instance the ability for crackers to run xsessions on hosts under accounts with no password (eg: sync), if it is improperly set up. Read the question about unpassworded accounts in this FAQ. ------------------------------------------------------------------ Q.15 What security holes are associated with NFS? Lots, mostly to do with who you export your disks to, and how. The security of NFS relies heavily upon who is allowed to mount the files that a server exports, and whether they are exported read only or not. The exact format for specifying which hosts can mount an exported directory varies between Unix implementations, but generally the information is contained within the file "/etc/exports". This file contains a list of directories and for each one, it has a series of either specific "hosts" or "netgroups" which are allowed to NFS mount that directory. This list is called the "access list". The "hosts" are individual machines, whilst "netgroups" are combinations of hosts and usernames specified in "/etc/netgroup". These are meant to provide a method of finetuning access. Read the relevant manual page for more information about netgroups. The exports file also contains information about whether the directory is to be exported as read-only, read-write, and whether super-user access is to be allowed from clients which mount that directory. The important point to remember is that if the access list for a particular directory in /etc/exports contains: 1) Your directory can be mounted by anyone, anywhere. 2) Your directory can be mounted by anyone permitted to run the mount command at hostname. This might not be a trustworthy person; for instance, if the machine is a PC running NFS, it could be anyone. 3) If the netgroup: a) is empty, anyone can mount your directory, from anywhere. b) contains "(,,)", anyone can mount your directory, from anywhere. c) contains the name of a netgroup which is empty or contains "(,,)", anyone can mount your directory, from anywhere. d) contains "(hostname,,)", anyone on the named host who is permissioned to mount files can mount your directory. e) contains "(,username,)", the named user can mount your directory, from anywhere. 4) If you meant to export the directory to the host "athena" but actually type "ahtena", the word "ahtena" is taken as a netgroup name, is found to be an empty netgroup, and thus the directory can be mounted by anyone, anywhere. So, if you aren't careful about what you put into /etc/exports and /etc/netgroup you could find that a user with a PC could a) mount your mainframe filestore as a network disk b) edit your /etc/passwd or .rhosts or /etc/hosts.equiv ... c) log into your mainframe as another user, possibly "root" Disclaimer: The above information may not be true for all platforms which provide an NFS serving capability, but is true for all of the ones in my experience (Alec). It should be noted that the SAFE way to create an "empty" netgroup entry is: ngname (-,-,-) Which is a netgroup which matches no-one on no-host on no-NIS-domain. >From: Mark Crispin > >NFS is far more insecure than the FAQ implies. It does not require >any carelessness in export files, since the only thing the export file >does is be helpful in disclosing the key that an NFS client needs to >unlock your system. Means exist to guess these keys. It is prudent, >to say the least, to configure your routers to forbid NFS traffic from >outside your organization. [...this is true; I just haven't had time to document it yet...] ------------------------------------------------------------------ Q.16 How can I generate safe passwords? You can't. The key word here is GENERATE. Once an algorithm for creating passwords is specified using upon some systematic method, it merely becomes a matter of analysing your algorithm in order to find every password on your system. Unless the algorithm is very subtle, it will probably suffer from a very low period (ie: it will soon start to repeat itself) so that either: a) a cracker can try out every possible output of the password generator on every user of the system, or b) the cracker can analyse the output of the password program, determine the algorithm being used, and apply the algorithm to other users to determine their passwords. A beautiful example of this (where it was disastrously assumed that a random number generator could generate an infinite number of random passwords) is detailed in [Morris & Thompson]. The only way to get a reasonable amount of variety in your passwords (I'm afraid) is to make them up. Work out some flexible method of your own which is NOT based upon: 1) modifying any part of your name or name+initials 2) modifying a dictionary word 3) acronyms 4) any systematic, well-adhered-to algorithm whatsoever For instance, NEVER use passwords like: alec7 - it's based on the users name (& it's too short anyway) tteffum - based on the users name again gillian - girlfiends name (in a dictionary) naillig - ditto, backwards PORSCHE911 - it's in a dictionary 12345678 - it's in a dictionary (& people can watch you type it easily) qwertyui - ...ditto... abcxyz - ...ditto... 0ooooooo - ...ditto... Computer - just because it's capitalised doesn't make it safe wombat6 - ditto for appending some random character 6wombat - ditto for prepending some random character merde3 - even for french words... mr.spock - it's in a sci-fi dictionary zeolite - it's in a geological dictionary ze0lite - corrupted version of a word in a geological dictionary ze0l1te - ...ditto... Z30L1T3 - ...ditto... I hope that these examples emphasise that ANY password derived from ANY dictionary word (or personal information), modified in ANY way, constitutes a potentially guessable password. For more detailed information in the same vein, you should read the APPENDIX files which accompany Crack [Muffett]. ------------------------------------------------------------------ Q.17 Why are passwords so important? Because they are the first line of defence against interactive attacks on your system. It can be stated simply: if a cracker cannot interact with your system(s), and he has no access to read or write the information contained in the password file, then he has almost no avenues of attack left open to break your system. This is also why, if a cracker can at least read your password file (and if you are on a vanilla modern Unix, you should assume this) it is so important that he is not able to break any of the passwords contained therein. If he can, then it is also fair to assume that he can (a) log on to your system and can then (b) break into "root" via an operating system hole. ------------------------------------------------------------------ Q.18 How many possible passwords are there? Most people ask this at one time or another, worried that programs like Crack will eventually grow in power until they can do a completely exhaustive search of all possible passwords, to break into a specific users' account - usually root. If (to simplify the maths) we make the assumptions that: 1) Valid passwords are created from a set of 62 chars [A-Za-z0-9] 2) Valid passwords are to be between 5 and 8 chars long Then the size of the set of all valid passwords is: (in base 62) 100000b62 + 1000000b62 + 10000000b62 + 100000000b62 = --------- 111100000b62 ~= 222000000000000 (decimal) A figure which is far too large to usefully undertake an exhaustive search with current technologies. Don't forget, however, that passwords CAN be made up with even more characters then this; you can use , all the punctuation characters, and symbols (~<>|\#$%^&*) too. If you can use some of all the 95 non-control characters in passwords, this increases the search space for a cracker to cover even further. However, it's still MUCH more efficient for a cracker to get a copy of "Crack", break into ANY account on the system (you only need one), log onto the machine, and spoof his way up to root priviledges via operating systems holes. Take comfort from these figures. If you can slam the door in the face of a potential crackers with a robust password file, you have sealed most of the major avenues of attack immediately. ------------------------------------------------------------------ Q.19 Where can I get more information? Books: [Kochan & Wood] Unix System Security A little dated for modern matters, but still a very good book on the basics of Unix security. [Spafford & Garfinkel] Practical Unix Security This wonderful book is a worthy successor to the above, and covers a wide variety of the topics which the Unix (and some non Unix) system manager of the 90's will come across. >From: Gene Spafford >Mention appendix E in "Practical Unix Security." Okay: Appendix E contains an extensive bibliography with even more pointers to security books than this FAQ contains. [Stoll] The Cuckoo's Egg A real life 1980's thriller detailing the tracing of a cracker from Berkeley across the USA and over the Atlantic to Germany. An excellent view from all points: a good read, informative about security, funny, and a good illustration of the cracker psyche. Contains an excellent recipie for chocolate chip cookies. A videotape of the "NOVA" (PBS's Science Program on TV) episode that explained/reenacted this story is available from PBS Home Video. They have a toll-free 800 number within North America. I believe that this program was aired on the BBC's "HORIZON" program, and thus will be available from BBC Enterprises, but I haven't checked this out yet - Alec THE TECHNICAL PAPER containing details of the "Cuckoo's Egg" breakin is called "Stalking the wily hacker" in an issue of CACM which I will dig out and get the proper reference for, in my copious free time - Alec [Raymond] (Ed.) The New Hackers Dictionary/Online Jargon File A mish-mash of history and dictionary definitions which explains why it is so wonderful to be a hacker, and why those crackers who aren't hackers want to be called "hackers". The Jargon File version is available online - check an archie database for retails. Latest revision: 3.00. [Gasser] Building a Secure Computer System. By Morrie Gasser, and van Nostrand Reinhold; explains what is required to build a secure computer system. [Rainbow Series] (Especially the "Orange Book") >From: epstein@trwacs.fp.trw.com (Jeremy Epstein) >The "Rainbow Series" consists of about 25 volumes. Some of the >more interesting ones are: > > The "Orange Book", or Trusted Computer Systems Evaluation > Criteria, which describes functional and assurance > requirements for computer systems > > Trusted Database Interpretation, which talks both about > trusted databases and building systems out of trusted > components > > Trusted Network Interpretation, which (obviously) talks > about networked systems > >A (possibly) complete list is: > -- Department of Defense Trusted Computer System Evaluation Criteria > (TCSEC), aka the "Orange Book" > -- Computer Security Subsystem Interpretation of the TCSEC > -- Trusted Data Base Management System Interpretation of the TCSEC > -- Trusted Network Interpretation of the TCSEC > -- Trusted Network Interpretation Environments Guideline -- Guidance > for Applying the Trusted Network Interpretation > -- Trusted Unix Working Group (TRUSIX) Rationale for Selecting > Access Control List Features for the Unix System > -- Trusted Product Evaulations -- A Guide for Vendors > -- Computer Security Requirements -- Guidance for Applying the DoD > TCSEC in Specific Environments > -- Technical Rationale Behind CSC-STD-003-85: Computer Security > Requirements > -- Trusted Product Evaluation Questionnaire > -- Rating Maintenance Phase -- Program Document > -- Guidelines for Formal Verification Systems > -- A Guide to Understanding Audit in Trusted Systems > -- A Guide to Understanding Trusted Facility Management > -- A Guide to Understanding Discretionary Access Control in Trusted > Systems > -- A Guide to Understanding Configuration Management in Trusted Systems > -- A Guide to Understanding Design Documentation in Trusted Systems > -- A Guide to Understanding Trusted Distribution in Trusted Systems > -- A Guide to Understanding Data Remanence in Automated Information > Systems > -- Department of Defense Password Management Guideline > -- Glossary of Computer Security Terms > -- Integrity in Automated Information Systems > >You can get your own copy (free) of any or all of the books by >writing or calling: > > INFOSEC Awareness Office > National Computer Security Centre > 9800 Savage Road > Fort George G. Meade, MD 20755-6000 > >If you ask to be put on the mailing list, you'll get a copy of each new >book as it comes out (typically a couple a year). ------------------------------------------------------------------ >From: kleine@fzi.de (Karl Kleine) >I was told that this offer is only valid for US citizens ("We only send >this stuff to a US postal address"). Non-US people have to PAY to get >hold of these documents. They can be ordered from NTIS, the National >Technical Information Service: > NTIS, > 5285 Port Royal Rd, > Springfield VA 22151, > USA ------------------------------------------------------------------ >From: Ulf Kieber >just today I got my set of the Rainbow Series. > >There are three new books: > -- A Guide to Understanding Trusted Recovery in Trusted Systems > -- A Guide to Understanding Identification and Authentication in Trusted > Systems > -- A Guide to Writing the Security Features User's Guide for Trusted Systems > >They also shipped > -- Advisory Memorandum on Office Automation Security Guideline >issued by NTISS. Most of the books (except three or four) can also be >purchased from > > U.S. Government Printing Office > Superintendent of Documents > Washington, DC 20402 phone: (202) 783-3238 > >>-- Integrity in Automated Information Systems >THIS book was NOT shipped to me--I'm not sure if it is still in >the distribution. ------------------------------------------------------------------ >From: epstein@trwacs.fp.trw.com (Jeremy Epstein) >... >The ITSEC (Information Technology Security Evaluation Criteria) is a >harmonized document developed by the British, German, French, and >Netherlands governments. It separates functional and assurance >requirements, and has many other differences from the TCSEC. > >You can get your copy (again, free/gratis) by writing: > > Commission of the European Communities > Directorate XIII/F > SOG-IS Secretariat > Rue de la Loi 200 > B-1049 BRUSSELS > Belgium ------------------------------------------------------------------ >From: Nick Barron > >...The ITSEC and associated DTI security publications (the "Green >Books") are available for *free* (makes a change) from the DTI >Commercial Computer Security Centre. The contact is Fiona Williams on >081 977 3222 or as fjw@dsg.npl.co.uk. Hope that this is of interest. >The ITSEC is currently being "harmonised" with the Orange Book... Also note that NCSC periodically publish an "Evaluated Products List" which is the definitive statement of which products have been approved at what TCSEC level under which TCSEC interpretations. This is useful for separating the output of marketdroids from the truth. Papers: [Morris & Thompson] Password Security, A Case History A wonderful paper, first published in CACM in 1974, which is now often to found in the Unix Programmer Docs supplied with many systems. ------------------------------------------------------------------ [Curry] Improving the Security of your Unix System. A marvellous paper detailing the basic security considerations every Unix systems manager should know. Available as "security-doc.tar.Z" from FTP sites (check an Archie database for your nearest site.) ------------------------------------------------------------------ [Klein] Foiling the Cracker: A Survey of, and Improvements to, Password Security. A thorough and reasoned analysis of password cracking trends, and the reasoning behind techniques of password cracking. Your nearest copy should be easily found via Archie, searching for the keyword "Foiling". ------------------------------------------------------------------ [Cheswick] The Design of a Secure Internet Gateway. Great stuff. Host: research.att.com Location: dist/internet_security FILE rw-rw-r-- 33836 Jul 24 1992 gateway.dvi FILE rw-rw-r-- 42373 Aug 19 1991 gateway.ps FILE rw-rw-r-- 674169 Jun 28 12:23 gateway_slides.ps ------------------------------------------------------------------ [Cheswick] An Evening With Berferd: in which a Cracker is Lured, Endured & Studied. Funny and very readable, somewhat in the style of [Stoll] but more condensed. Host: research.att.com Location: dist/internet_security FILE rw-rw-r-- 41612 Jul 24 1992 berferd.dvi FILE rw-rw-r-- 81747 Jul 24 1992 berferd.ps ------------------------------------------------------------------ [Bellovin89] Security Problems in the TCP/TP Protocol Suite. A description of security problems in many of the protocols widely used in the Internet. Not all of the discussed protocols are official Internet Protocols (i.e. blessed by the IAB), but all are widely used. The paper originally appeared in ACM Computer Communications Review, Vol 19, No 2, April 1989. Host: research.att.com Location: dist/internet_security FILE rw-rw-r-- 48703 Aug 22 1991 ipext.ps.Z ------------------------------------------------------------------ [Bellovin91] Limitations of the Kerberos Authentication System A discussion of the limitations and weaknesses of the Kerberos Authentication System. Specific problems and solutions are presented. Very worthwhile reading. Available on research.att.com via anonymous ftp, originally appeared in ACM Computer Communications Review but the revised version (identical to the online version, I think) appeared in the Winter 1991 USENIX Conference Proceedings. ------------------------------------------------------------------ [Muffett] Crack documentation. The information which accompanies Crack contains a whimsical explanation of password cracking techniques and the optimisation thereof, as well as an incredibly long and silly diatribe on how to not choose a crackable password. A good read for anyone who needs convincing that password cracking is _really easy_. ------------------------------------------------------------------ [Farmer] COPS Read the documentation provided with COPS. Lots of hints and philosophy. The where, why and how behind the piece of security software that started it all. ------------------------------------------------------------------ [CERT] maillists/advisories/clippings CERT maintains archives of useful bits of information that it gets from USENET and other sources. Also archives of all the security "advisories" that it has posted (ie: little messages warning people that there is a hole in their operating system, and where to get a fix) ------------------------------------------------------------------ [OpenSystemsSecurity] A notorious (but apparently quite good) document, which has been dogged by being in a weird postscript format. >From: amesml@monu1.cc.monash.edu.au (Mark L. Ames) >I've received many replies to my posting about Arlo Karila's paper, >including the news (that I and many others have missed) that a >manageable postscript file and text file are available via anonymous ftp >from ajk.tele.fi (131.177.5.20) in the directory PublicDocuments. These are all available for FTP browsing from "cert.org". ------------------------------------------------------------------ [RFC-1244] Site Security Handbook RFC-1244 : JP Holbrook & JK Reynolds (Eds.) "The Site Security Handbook" covering incident handling and prevention. July 1991; 101 pages (Format: TXT=259129 bytes), also called "FYI 8" ------------------------------------------------------------------ [USENET] comp.virus: for discussions of virii and other nasties, with a PC bent. comp.unix.admin: for general administration issues comp.unix.: for the hardware/software that YOU use. comp.protocols.tcp-ip: good for problems with NFS, etc. ------------------------------------------------------------------ Q.20 How silly can people get? This section (which I hope to expand) is a forum for learning by example; if people have a chance to read about real life (preferably silly) security incidents, it will hopefully instill in readers some of the zen of computer security without the pain of experiencing it. If you have an experience that you wish to share, please send it to the editors. It'll boost your karma no end. ------------------------------------------------------------------ From: aem@aber.ac.uk The best story I have is of a student friend of mine (call him Bob) who spent his industrial year at a major computer manufacturing company. In his holidays, Bob would come back to college and play AberMUD on my system. Part of Bob's job at the company involved systems management, and the company was very hot on security, so all the passwords were random strings of letters, with no sensible order. It was imperative that the passwords were secure (this involved writing the random passwords down and locking them in big, heavy duty safes). One day, on a whim, I fed the MUD persona file passwords into Crack as a dictionary (the passwords were stored plaintext) and then ran Crack on our systems password file. A few student accounts came up, but nothing special. I told the students concerned to change their passwords - that was the end of it. Being the lazy guy I am, I forgot to remove the passwords from the Crack dictionary, and when I posted the next version to USENET, the words went too. It went to the comp.sources.misc moderator, came back over USENET, and eventually wound up at Bob's company. Round trip: ~10,000 miles. Being a cool kinda student sysadmin dude, Bob ran the new version of Crack when it arrived. When it immediately churned out the root password on his machine, he damn near fainted... The moral of this story is: never use the same password in two different places, and especially on untrusted systems (like MUDs). ------------------------------------------------------------------ From: zerkle@cs.ucdavis.edu (Dan Zerkle) I've got a good one. Our department has a room of workstations for graduate students who have not started on a research project. If you don't have an account, you can still use these workstations as terminals. There is a special, null-password account called "terminal". This account runs a short program which accepts a machine name, a user name and a password, then runs rlogin to connect you to the machine of your choice. Awhile back, I used this system, but accidentally hit RETURN before I typed my user name. Since there was no way to back out, I also hit RETURN for the password. As it happened, the machine to which I was connecting had an entry in the password file like this: ::0:1::: (this is a YP/NIS password entry, missing a "+" symbol) You can imagine how startled I was when the terminal program connected me and logged me in as root! I sent mail to the system administrator (as root, just to irk him), and got the hole patched within a day. Ordinarily, the entry in the password file was not a problem. Normal methods of logging in require you to supply a user name. However, the "terminal" login accepted the null string as a user name and passed it on (via rlogin) to the host computer. Thus, purely by accident, I managed to break root on that machine. -Dan -------------------------------------------------------------------- From: BENNETT@dstos3.dsto.gov.au (John Bennett) Hi Alec, You asked for contributions for "How silly can people get ?" Here is a simple but true and possibly oft repeated story... My son bought a new car, so we went down to the local office of the Royal Automobile Association to insure it. A Charming Young Lady was very helpful and efficient as we sorted out the details of the policy. Once the paperwork was written, the CYL went across the office to a computer terminal, sat down, and called to another CYL "Is the password still (censored, name of computer company) ?". Regards, John Bennett bennett@dstos3.dsto.gov.au ------------------------------------------------------------------- From: Alec.Muffett@UK.Sun.COM - A cautionary tale, about a friend of mine who will probably wish to remain anonymous, for his sins. (Hi, Ian!) At a British university with a particularly paranoid (not to say rabid) security policy, the systems administrators had changed the permissions on the "su" command, removing world execute permission, and making it group-execute only to members of the computing services staff. ...however, the staff were not informed enough to remove world-write permission from /dev/console. My friend, Ian, attended this university, and on one occasion became particularly annoyed at a fellow student-user (let's call him foobar1). Foobar1 was apparently nosing round the terminals of everyone in the room, peering over the shoulders of his fellow students, and not obeying the rules of etiquette. So, in order to "get him back", Ian did this: Ian wrote a script which, every so often, would print: BAD SU: foobar1 on tty0a at 12:34:56 - to the machine's console. Given that "only members of staff can use 'su' to get to root on this system", this must have worried the operators mightily. After a few iterations of this cat-and-mouse game, Ian did: SU: foobar1 on tty0a at 12:45:03 - thirty seconds later, the machine crashed. The operations team, rather than let this horrible hacker run amok on the system, chose to pull the plug. They then arrived in the terminal room, hauled "foobar1" out backwards, took him away and shouted at him for an hour or so, until they believed that it wasn't him. I believe that Ian apologised to foobar1 eventually, but the systems people never *did* sort it out. The moral of this tale? During an incident: 1) don't panic - you might do something stupid 2) don't trust any audit trail which is open to compromise ------------------------------------------------------------------ Alec Muffett (alec.muffett@sun.co.uk) Sun Microsystems IR, Bagshot, Surrey, UK #include