Table of Contents

This is a compilation of Texts by Dysphunxion.. Most of it was actually typed by me.. like the intro.. the boxes explained.. and the VMB Hacking.. the rest are just plans for boxes.. Some may be on the older side but most still work!!! Now on with the show... Xx-x-x-x-x-x-x-x-x-x-x-xX I Table of Contents I Xx-x-x-x-x-x-x-x-x-x-x-xX Introduction to hacking. . . . . . . . . . . . . . . . . . . . 1 Phone Phreaking. . . . . . . . . . . . . . . . . . . . . . . . 2 Basic Boxes Technically Explained . . . . . . . . . . . . 3 (BLUE,3); (BLACK,4); (CHEESE,5) Voice mail box hacking. . . . . . . . . . . . . . . . . . 6 Blue Box Tones. . . . . . . . . . . . . . . . . . . . . . 9 Scarlet box . . . . . . . . . . . . . . . . . . . . . . . 10 Green Box . . . . . . . . . . . . . . . . . . . . . . . . 11 Blotto Box. . . . . . . . . . . . . . . . . . . . . . . . 12 Potpourri Lunch Box . . . . . . . . . . . . . . . . . . . . . . . . 13 INTRODUCTION TO HACKING Most people who have never hacked or are beginners think that hackers are a small community of very knowledgeable computer "geniuses" that randomly break into systems for fun and then create havoc or steal information. I will speak of my own views on hacking which shouldn't reflect the feelings of the entire hacking community but I would guess a large amount. First of all hacking is getting more and more risky everyday. Because of this, hacking for fun isn't as safe as it used to be (although most of my hacking is for fun). The reason people (people I know) hack is because we believe in free information exchange. This means that I should be able to freely access any information that is available over the modem that I want. There are obvious reasons why this can't be achieved, but if people have information that is that sensitive then it should not be put out over the modem. Now the second and biggest misconception about hacking is how the hacker actually "hacks". Most people think that hacking is just basically getting lucky and guessing a password that lets you into a system. This is *very* untrue. Let us take an example that you have just broken into the CIA's computer system. So suddenly you get a -> prompt. Now what do you do?!? This is the difference between the hacker and some kid that is good at guessing. The kid may be able to guess a password, but if he doesn't know what to do once he's in then he might as well have not even hacked the password at all. So, the main objective of the hacker is to concentrate on learning how to use a system. After he has done that then he can figure out ways to get around certain kinds of security and get to the stuff he wants. So what you should do is read all the manual's and text files that you can get your hands on. Because before you can defeat a system, you must know how it works (this works for life in general). Ok, now you understand what hacking is and how you should go about learning it. Phone Hacking Basic Boxes Technically Explained BLUE The "Blue Box" was so named because of the color of the first one found. The design and hardware used in the Blue Box is fairly sophisticated, and its size varies from a large piece of equipment to the size of a pack of cigarettes. The Blue Box contains 12 or 13 buttons or switches that emit multi-frequency tones characteristic of the tones used in the normal operation of the telephone toll (long distance) switching network. The Blue Box enables the user to place free long distance calls by circumventing toll billing equipment. The Blue Box may be directly connected to a phone line, or it may be acoustically coupled to a telephone handset by placing the Blue Box's speaker next to the transmitter or the telephone handset. To understand the nature of a fraudulent Blue Box call, it is necessary to understand the basic operation of the Direct Distance Dialing (DDD) telephone network. When a DDD call is properly originated, the calling number is identified as an integral part of establishing the connection. This may be done either automatically or, in some cases, by an operator asking the calling party for his telephone number. This information is entered on a tape in the Automatic Message Accounting (AMA) office. This tape also contains the number assigned to the trunk line over which the call is to be sent. The information relating to the call contained on the tape includes: called number identification, time of origination of call, and info that the called number answered the call and time of disconnect at the end of the call. Although the tape contains info with respect to many different calls, the various data entries with respect to a single call are eventually correlated to provide billing info for use by your Bell's accounting department. The typical Blue Box user usually dials a number that will route the call into the telephone network without charge. For example, the user will very often call a well-known INWATS (toll-free) customer's number. The Blue Box user, after gaining this access to the network and, in effect, "seizing" control and complete dominion over the line, operates a key on the Blue Box which emits a 2600 Hertz (cycles per second) tone. This tone causes the switching equipment to release the connection to the INWATS customer's line. The 2600Hz tone is a signal that the calling party has hung up. The Blue Box simulates this condition. However, in fact the local trunk on the calling party's end is still connected to the toll network. The Blue Box user now operates the "KP" (Key Pulse) key on the Blue Box to notify the toll switching equipment that switching signals are about to be emitted. The user then pushes the "number" buttons on the Blue Box corresponding to the telephone # being called. After doing so he/she uses the "ST" (Start) key to tell the switching equipment that signalling is complete. If the call is completed, only the portion of the original call prior to the 'blast' of 2600Hz tone is recorded on the AMA tape. The tones emitted by the Blue Box are not recorded on the AMA tape. Therefore, because the original call to the INWATS # is toll- free, no billing is rendered in connection with the call. Although the above is a description of a typical Blue Box call using a common way of getting into the network, the operation of a Blue Box may vary in any one or all of the following respects: The Blue Box may include a rotary dial to apply the 2600Hz tone and the switching signals. This type of Blue Box is called a "dial pulser" or "rotary SF" Blue box. Getting into the DDD toll network may be done by calling any other toll-free # such as Universal Directory ASSistance (555-1212) or any number in the INWATS network, either inter-state or intra-state, working or non-working. Entrance into the DDD toll network may also be in the form of "short haul" calling. A "short haul" call is a call to any # which will result in a lesser amount of toll charges than the charges for the call to be completed by the Blue Box. For example, a call to Birmingham from Atlanta may cost $.80 for the first 3 minutes while a call from Atlanta to Los Angeles is $1.85 for 3 minutes. Thus, a short haul, 3-minute call to Birmingham from Atlanta, switched by use of a Blue Box to Los Angeles, would result in a net fraud of $1.05 for a 3 minute call. A Blue Box may be wired into the telephone line or acoustically coupled by placing the speaker of the Blue Box near the transmitter of the phone handset. The Blue Box may even be built inside a regular Touch-Tone phone, using the phone's push- buttons for the Blue Box's signalling tones. A magnetic tape recording may be used to record the Blue Box tones for certain phone numbers. This way, it's less conspicuous to use since you just make it look like a walkman or whatever, instead of a box. All Blue Boxes, except "dial pulse" or "Rotary SF" Blue Boxes, must have the following 4 common operating capabilities: It must have signalling capability in the form of a 2600Hz tone. This tone is used by the toll network to indicate, either by its presence or its absence, an "on hook" (idle) or "off hook" (busy) condition of the trunk. The Blue Box must have a "KP" tones that unlocks or readies the multi-frequency receiver at the called end to receive the tones corresponding to the called phone #. The typical Blue Box must be able to emit M tones which are used to transmit phone #'s over the toll network. Each digit of a phone # is represented by a combination of 2 tones. For example, the digit 2 is transmitted by a combination of 700Hz and 1100Hz. The Blue Box must have an "ST" key which consists of a combination of 2 tones that tell the equipment at the called end that all digits have been sent and that the equipment should start switching the call to the called number. BLACK This Box was named because of the color of the first one found. It varies in size and usually has one or two switches or buttons. Attached to the telephone line of a called party, the Black Box provides toll-free calling *to* that party's line. A Black Box user tells other people beforehand that they will not be charged for any call placed to him. The user then operates the device causing a "non-charge" condition ("no answer" or "disconnect") to be recorded on the telephone company's billing equipment. A Black Box is relatively simple to construct and is much less sophisticated than a Blue Box. NOTE: This will not work on any type of Electronic Switching Systems, (ESS, DMS100 etc.) CHEESE This Box was named after the container in which the first one was found. Its design may be crude or very sophisticated. Its size varies; one was found the size of a half-dollar. A Cheese Box was used most often by bookmakers or betters to place wagers without detection from a remote location. The device inter-connects 2 phone lines, each having different #'s but each terminating at the same location. In effect, there are 2 phones at the same location which are linked together through a Cheese Box. It is usually found in an unoccupied apartment connected to a phone jack or connecting block. The bookmaker, at some remote location, dials one of the numbers and stays on the line. Various bettors dial the other number but are automatically connected with the book maker by means of the Cheese Box interconnection. If, in addition to a cheese box, a Black Box is included in the arrangement, the combined equipment would permit toll-free calling on either line to the other line. If a police raid were conducted at the terminating point of the conversations -the location of the Cheese Box- there would be no evidence of gambling activity. This device is sometimes difficult to identify. Law enforcement officials have been advised that when unusual devices are found associated with telephone connections the phone company security representatives should be contacted to assist in identification. (This probably would be good for a BBS, especially with the Black Box set up. and if you ever decided to take the board down, you wouldn't have to change your phone #. It also makes it so you yourself cannot be traced. I am not sure about calling out from one though.) VOICE MAIL BOX HACKING Hello again, and welcome to another œegions “f œucifer text file! This text file has to do with hacking and scanning VMBs. The reason I am writing this file is because I am very good at it, and have had years of experience. In fact I have been called by MCI for screwing them over by attacking and taking over a whole damn system with a few friends of mine. Anyway, hacking VMBs is very simple and basically safe, and not only that but they are cool to have around. You can give them to friends, you can trade them for access on bulletin boards, or you can use it for yourself. As for this 'Tutorial on Hacking VMBs', we will be talking about what systems to hack, how you go about hacking them, default passwords, hints on better scanning, and having your very own box. VMB, in case you don't know, stands for 'Voice Mail Box'. Now a VMB is like an answering machine. You can use it for all sorts of things. Most VMB systems are dialed though 800 numbers. People call up the VMB system that you have a box on, and dial in your box number and then leave you a message. Whenever you want to check your box, you just call up, enter your password and read your messages. Inside a VMB you can do whatever, you can leave messages to others on the system, you can change your 'Out Going' message, you can have guest boxes (Explained later), you can have the box call your house when you get an Urgent message, you can do a lot of things. In fact, on some systems you can even CALL OUT through them, so they can be used as a code of sorts! They are cool to have. You should scan/hack out Virgin Systems, this is another way of calling a system that hasn't been hack out yet. Also, CINDI Systems and ASPEN Systems have the best boxes and the most options that VMB Systems can offer. I will be talking about ASPEN System today since I know most about those. Okay once you've found your Virgin VMB System, you start to scan. Just incase you don't know what scanning is, that means you search for boxes that are hackable (Explained later on). Now you dial up the system and when it picks up and the bitch starts to talk, press the "#" key. It will then ask you for your box number... now there are two different way the ASPEN System can be configured: 1) a "3 Digit Box Number System" or 2) a "4 Digital Box Number System". Now lets just say this system is a 3 Digit System. Okay, when it asks for your Box Number, enter in 999, now it will say one of three things: [These are known as 'Greeting Names'] 1. John Doe [Box owners name] 2. "Box Number 999 Is Not a Valid Box Number" 3. "Box Number 999" Now, if it either says 1 or 2, go to box number 998...997...996...995..etc, but if it says 3, then you are lucky, now it will ask you for your password, now you are probably saying 'Oh no this is where it gets difficult'... well you are WRONG! This part is easy. Here is a list of ASPEN Default Passwords: * We will use box number 666 as an example box # [ BN = Box Number ] List of Default Password: Combination Result 1-BN 1666 BN+1 667 0-BN 0666 BN-0 6660 Most Common Äį BN 666 Now enter in a those defaults, try JUST the Box Number first, ASPENs usually use that most. Now, if you try all those Defaults and still can not get into that Voice Mail Box, then that means that the box has been already taken, but the owner hasn't changed his 'Generic Message', if you don't get in, you will just have to search until you get in. Okay, once you get your first box, *DO NOT* change anything!! That will come later. Your first box is, as what is known as a 'Scanning Box'! What you do with your Scanning Box is this: You enter "3" from the main commands menu, and it will ask you for the box number. Now that command is the "Check for Receipt" command, what it does it check Box #xxx for mail from you. This command is very convenient for us VMB Hackers. To use that command to your advantage, you enter in box a box number and it will say 1 of the three 'Greeting Names', like before, if it say #3, then you write down that Box Number and hack it later. But if it says 1 or 2, then just keep scanning! All boxes with the number 3 Greeting Name is known as a 'Hackable Box'. Now you keep scanning until you have gone all the way down to Box number 000 or whatever is the lowest box it supports. Now, once you have your list this is when all the fun starts! Now you are ready to hack! Hacking Out Your New Found 'Hackable' Boxes: Okay this is the easy part. After you spent most of your time by scanning the system you should be used to the system and how it works, that should make hacking the ASPEN all the easier. Now, if you had a 'Scanning Box', you should know what the default password was for your Scanning Box. Well if the password for your Scanning Box was just the Box Number, then *EVERY* other hackable box should have the SAME default password. VMB Systems have only one default password, If one box has the BN for a Default PW, the all the others will too. Okay, you call up the VMB System will the list of 'Hackable' boxes by your side, and when the bitch is talking, press the "#" key. When it asks you for your box number, enter in the first box number on your list. When it asks for your password, enter in the Default Password Sequence. Now if you don't get into that box, it's not a problem, just keep going down your list. You should get into a few. But remember, just because a box is marked 'Hackable', it doesn't mean you will definitely get into it. Okay, now you have a few dozen boxes. You can now use you Scanning Box to do whatever you please. ASPEN Guest Boxes: Once you have a box of your own, you can give out 'Guest Boxes'. Guest Boxes are like Sub Boxes in your box. In ASPEN you have 4 of them. If you give out Guest Box #1 to John Doe, Mr. Doe can call in, enter in the password YOU set for him, and leave you messages, but not only that, you can leave messages to HIM! Which means, if his is in New York, and you are in California, and neither of you have codes to call each other, then you can leave messages thru your 800 VMB. Here is a list and explanation of all 4 of the Guest Boxes: 0. Main Box - Your Voice Mail Box! 1. Guest Box #1 - Can Leave & Receive Messages 2. Guest Box #2 - Can Leave & Receive Messages 3. Home Box - Can Leave & Receive Messages 4. Secretary Box - Can Check How Many Messages You Have & Receive Messages Hints On Better Scanning: A lot of people say hacking and scanning for VMBs is too damn hard... well that's because they are going at it all wrong, they probably read some lame piece of text file on Hacking VMBs that was about 500 bytes long. Well, here is a small list of hints on better scanning and hacking: 1. Do not use a Voice Mail Box hacking/scanning program (i.e.: VMB v1.0, ASPEN v1.0, VMBHACK v2.3, etc..) 2. Do not hack in random order (i.e.: B#999, 345, 810, etc) Always hack in order: 999, 998, 997, 996, 995...000. 3. Try to find out if it's virgin. The newer the System, the better. 4. If you have a phone with memory dial, change one entry to the number of the VMB System. 5. Don't hack the System Managers box unless you really want to. Ideas of Things To Do With Your Extra Boxes: Well since you can have up to 500 extra Voice Mail Boxes, you might not know what to do with them, here are a few ideas that can help you out: 1. Give them to friends 2. Sell them to friends 3. Offer them to sysops for better access 4. Trade them for HSTs or whatever 5. Use them as a Voice Verifying line (So you don't have to give out your real voice number to BBSs when you apply!) Blue Box Tones In this short section I will attempt to list some tones that Ma Bell uses and what they are. Well here goes: Blue box frequencies: 2600 hz - used to get on/off trunk tone matrix to use after 2600 hz. 700: 1 : 2 : 4 : 7 : 11 : 900: + : 3 : 5 : 8 : 12 : 1100: + : + : 6 : 9 : KP : 1300: + : + : + : 10 : KP2 : 1500: + : + : + : + : ST : 900 :1100 :1300 :1500 : 1700 : Use KP to start a call and ST (1500+1700) to stop. Use 2600 HZ to disconnect. Red box freqs: 1700 hz and 2200 hz mixed together. A nickel is 66 ms on (1 beep). A dime is 66ms on, 66ms off, 66ms on (2 beeps) a quarter is 33ms on, 33ms off repeated 5 times. (Ms = millisecond). For those of you who don't know, a red box simulates money being put into a pay phone. You must put in some money first though (the operator can tell if money was put in but as to how much she lets the computer answer that. (Yeah for the computer) TASI locking freq: TASI (time assignment speech interpolation) is used on satellite trunks, and basically allows more than one person to use a trunk by putting them on while the other person isn't talking. Of course, you'd never hear the other person talking on your trunk. When you start to talk, however, the TASI controller has to find an open trunk for you. Because of this, some of your speech is lost (because of the delay in finding a trunk) this is called clipping. Well, if you were transmitting data over a trunk, clipping would really mess up the data. So there is something called a TASI locking frequency which keeps the TASI from putting anyone else on your trunk or you on anyone else's trunk. In any case the freq. is 1850 hz. (Sent before the transmission). Have fun!!! :%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%: :% %: :% THE GREEN BOX %: :% %: :%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%: The Green Box generates useful tonessuch as COIN COLLECT, COIN RETURN, and RINGBACK. These are the tones that ACTS or the TSPS operator would send to the CO when appropriate. Unfortunately, the green box cannot be used at a fortress station, but must be used by the CALLED party. The tones (hz) are: COIN COLLECT 700 + 1100 COIN RETURN 1100 + 1700 RINGBACK 700 + 1700 Before the called party sends any of these tones, an operator released signal should be sent to alert the MF detectors at the CO. This can be done by sending 900 + 1500 Hz or a single 2600 Hz wink (90 ms) followed by a 60 ms gap and then the appropriate signal for at least 900 ms. Also, do not forget that the initial rate is collected shortly before the 3 minute period is up. :-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-::-:-:-:-:-:-:-:-:-:-: -:-:-:-:-:-:-:-: :%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%: :% %: :% THE BLOTO BOX %: :% %: :%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%: HOW TO BUILD A BLOTO BOX Finally, it is here! What was first conceived as a joke to fool the inncoent phreakers around America has finally been concieved by the one phreak who is the expert on lines and voltage: The Traveler. Other boxes by the Traveler include the White Gold Box, the Aqua Box, The Diverti Box, and the Cold Box. All of those plans will soon be available in a BBS/AE near you! Well, for you people who are unenlightened about the Blotto Box, here is a brief summery of a legend. --*-=> The Blotto Box <=-*-- For years now every pirate has dreamed of the Blotto Box. It was at first made as a joke to mock more ignorant people into thinking that the function of it actually was possible. Well, if you are The Voltage Master, it is possible. Originally conceived by King Blotto of much fame, the Blotto Box is finally available to the public. NOTE: The Traveler can not be responcable for the information disclosed in the file! This file is strictly for informational purposes and should not be actually built and used! Usage of this electronical impulse machine could have the severe results listed below and could result in high federal prosecution! Again, The Traveler TAKES NO RESPONCABILITY! All right, now that that is cleared up, here is the basis of the box and it's function. The Blotto Box is every phreaks dream... you could hold AT&T down on it's knee's with this device. Because, quite simply, it can turn off the phone lines everywhere. Nothing. Blotto. No calls will be allowed out of an area code, and no calls will be allowed in. No calls can be made inside it for that matter. As long as the switchhing system stays the same, this box will not stop at a mere area code. It will stop at nothing. The electrical impulses that emit from this box will open every line. Every line will ring and ring and ring... the voltage will never be cut off until the box/ generator is stopped. This is no 200 volt job, here. We are talking GENERATOR. Every phone line will continue to ring, and people close to the box may be electricuted if they pick up the phone. But, the Blotto Box can be stopped by merely cutting of the line or generator. If they are cut off then nothing will emit any longer. It will take a while for the box to calm back down again, but that is merely a superficial aftereffect. Once again: Construction and use of this box is not advised! The Blotto Box will continue as long as there is electricity to continue with. OK, that is what it does, now, here are some interesting things for you to do with it... --*-=> The Blotto Box Functions and Installation <=-*-- Once you have installed your Blotto, there is no turning back. The following are the instructions for construction and use of this box. Please read and heed all warnings in the above section before you attempt to construct this box. Materials: - A Honda portable generator or a main power outlet like in a stadium or some such place. - A radio shack cord set for 400 volts that splices a female plug into a phone line jack. - A meter of voltage to attach to the box itself. - A green base (i.e. one of the nice boxes about 3' by 4' that you see around in your neighborhood. They are the main switch boards and would be a more effective line to start with. or: A regular phone jack (not your own, and not in your area code! - A soudering iron and much souder. - A remote control or long wooden pole. Now. You must have guessed the construction from that. If not, here goes, I will explain in detail. Take the Honda Portable Generator and all of the other listed equiptment and go out and hunt for a green base. Make sure it is one on the ground or hanging at head level from a pole, not the huge ones at the top of telephone poles. Open it up with anything convienent, if you are two feeble that fuck don't try this. Take a look inside... you are hunting for color-coordinating lines of green and red. Now, take out your radio shack cord and rip the meter thing off. Replace it with the voltage meter about. A good level to set the voltage to is about 1000 volts. Now, attach the voltage meter to the cord and set the limit for one thousand. Plug the other end of the cord into the generator. Take the phone jack and splice the jack part off. Open it up and match the red and green wires with the other red and green wires. NOTE: If you just had the generator on and have done this in the correct order, you will be a crispy critter. Keep the generator off until you plan to start it up. Now, sauder those lines together carefully. Wrap duck tape or insultation tape around all of the wires. Now, place the remote control right on to the startup of the generator. If you have the long pole, make sure it is very long and stand back as far away as you can get and reach the pole over. NOTICE: If you are going right along with this without reading the file first, you sill realize now tHat your area code is about to become null! Then, getting back, twitch the pole/remote control and run for your damn life. Anywhere, just get away from it. It will be generating so much electricity that if you stand to close you will kill yourself. The generator will smoke, etc. but will not stop. You are now killing your area code, because all of that energy is spreading through all of the phone lines around you in every direction. Have a nice day! <%>^<%>^<%>^<%>^<%>^<%>^<%>^<%>^<%>^<%>^<%>^<%>^<%>^<%>^<%>^<%>^<%>^<%>^<%> <%> <%> <%> Making the <%> <%> <%> <%> Lunch Box <%> <%> ===== === <%> <%> <%> <%> Written, Typed and Created by: Dr. D-Code <%> <%> <%> <%>^<%>^<%>^<%>^<%>^<%>^<%>^<%>^<%>^<%>^<%>^<%>^<%>^<%>^<%>^<%>^<%>^<%>^<%> Introduction ============ The Lunch Box is a VERY simple transmitter which can be handy for all sorts of things. It is quite small and can easily be put in a number of places. I have successfully used it for tapping fones, getting inside info, blackmail and other such things. The possibilities are endless. I will also include the plans for an equally small receiver for your newly made toy. Use it for just about anything. You can also make the transmitter and receiver together in one box and use it as a walkie talkie. Materials you will need ======================= (1) 9 volt battery with battery clip (1) 25-mfd, 15 volt electrolytic capacitor (2) .0047 mfd capacitors (1) .022 mfd capacitor (1) 51 pf capacitor (1) 365 pf variable capacitor (1) Transistor antenna coil (1) 2N366 transistor (1) 2N464 transistor (1) 100k resistor (1) 5.6k resistor (1) 10k resistor (1) 2meg potentiometer with SPST switch Some good wire, solder, soldering iron, board to put it on, box (optional) Schematic for The Lunch Box =========================== This may get a tad confusing but just print it out and pay attention.  ! 51 pf ! ---+---- ------------base collector ! )( 2N366 +----+------/\/\/----GND 365 pf () emitter ! ! )( ! ! +-------- ---+---- ! ! ! ! ! ! ! GND / .022mfd ! ! 10k\ ! ! ! / GND +------------------------emitter ! ! ! 2N464 / .0047 ! base collector 2meg \----+ ! ! +--------+ ! / ! GND ! ! ! GND ! ! ! +-------------+.0047+--------------------+ ! ! ! +--25mfd-----+ -----------------------------------------+ ! ! microphone +--/\/\/-----+ ---------------------------------------------+ 100k ! ! GND---->/<---------------------!+!+!+---------------+ switch Battery from 2meg pot. Notes about the schematic ========================= 1. GND means ground 2. The GND near the switch and the GND by the 2meg potentiometer should be connected. 3. Where you see: )( () )( it is the transistor antenna coil with 15 turns of regular hook-up wire around it. 4. The middle of the loop on the left side (the left of "()") you should run a wire down to the "+" which has nothing attached to it. There is a .0047 capacitor on the correct piece of wire. 5. For the microphone use a magnetic earphone (1k to 2k). 6. Where you see "[!]" is the antenna. Use about 8 feet of wire to broadcast approx 300ft. Part 15 of the FCC rules and regulation says you can't broadcast over 300 feet without a license. (Hahaha). Use more wire for an antenna for longer distances. (Attach it to the black wire on the fone line for about a 250 foot antenna!) Operation of the Lunch Box ========================== This transmitter will send the signals over the AM radio band. You use the variable capacitor to adjust what freq. you want to use. Find a good unused freq. down at the lower end of the scale and you're set. Use the 2 meg pot. to the 2meg is for turning the Lunch Box on and off. When everything is adjusted, turn on an AM radio adjust it to where you think the signal is. Have a friend say some shit thru the Box and tune in to it. That's all there is to it. The plans for a simple receiver are shown below: The Lunch Box receiver ====================== (1) 9 volt battery with battery clip (1) 365 pf variable capacitor (1) 51 pf capacitor (1) 1N38B diode (1) Transistor antenna coil (1) 2N366 transistor (1) SPST toggle switch (1) 1k to 2k magnetic earphone Schematic for receiver ====================== [!] ! 51 pf ! +----+----+ ! ! ) 365 pf (----+ ! ) ! ! +---------+---GND ! +---*>!----base collector----- diode 2N366 earphone emitter +----- ! ! GND ! - + - battery + GND------>/<------------+ switch Closing statement ================= This two devices can be built for under a total of $10.00. Not too bad. Using these devices in illegal ways is your option. If you get caught, I accept NO responsibility for your actions. This can be a lot of fun if used correctly. Hook it up to the red wire (I think) on the fone line and it will send the conversation over the air waves. If you have any problems or are confused, leave me mail on:Hi-Times=702/832/7469 Warez House=702/827/9273 ______________________________________________________________________________ Sysops of other systems may use the file as long as none of it is altered. ______________________________________________________________________________ This has been a High Mountain Hackers Production- (c) 1985 by HMH Industries ______________________________________________________________________________

A Novice's Guide to Hacking- 1989 edition

+++++++++++++++++++++++++++++++++++++++++++++++++ | The LOD/H Presents | ++++++++++++++++ ++++++++++++++++ \ A Novice's Guide to Hacking- 1989 edition / \ ========================================= / \ by / \ The Mentor / \ Legion of Doom/Legion of Hackers / \ / \ December, 1988 / \ Merry Christmas Everyone! / \+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++/ ********************************************************************** | The author hereby grants permission to reproduce, redistribute, | | or include this file in your g-file section, electronic or print | | newletter, or any other form of transmission that you choose, as | | long as it is kept intact and whole, with no ommissions, delet- | | ions, or changes. (C) The Mentor- Phoenix Project Productions | | 1988,1989 XXX/XXX-XXXX | ********************************************************************** Introduction: The State of the Hack ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ After surveying a rather large g-file collection, my attention was drawn to the fact that there hasn't been a good introductory file written for absolute beginners since back when Mark Tabas was cranking them out (and almost *everyone* was a beginner!) The Arts of Hacking and Phreaking have changed radically since that time, and as the 90's approach, the hack/phreak community has recovered from the Summer '87 busts (just like it recovered from the Fall '85 busts, and like it will always recover from attempts to shut it down), and the progressive media (from Reality Hackers magazine to William Gibson and Bruce Sterling's cyberpunk fables of hackerdom) is starting to take notice of us for the first time in recent years in a positive light. Unfortunately, it has also gotten more dangerous since the early 80's. Phone cops have more resources, more awareness, and more intelligence that they exhibited in the past. It is becoming more and more difficult to survive as a hacker long enough to become skilled in the art. To this end this file is dedicated . If it can help someone get started, and help them survive to discover new systems and new information, it will have served it's purpose, and served as a partial repayment to all the people who helped me out when I was a beginner. Contents ~~~~~~~~ This file will be divided into four parts: Part 1: What is Hacking, A Hacker's Code of Ethics, Basic Hacking Safety Part 2: Packet Switching Networks: Telenet- How it Works, How to Use it, Outdials, Network Servers, Private PADs Part 3: Identifying a Computer, How to Hack In, Operating System Defaults Part 4: Conclusion- Final Thoughts, Books to Read, Boards to Call, Acknowledgements Part One: The Basics ~~~~~~~~~~~~~~~~~~~~ As long as there have been computers, there have been hackers. In the 50's at the Massachusets Institute of Technology (MIT), students devoted much time and energy to ingenious exploration of the computers. Rules and the law were disregarded in their pursuit for the 'hack'. Just as they were enthralled with their pursuit of information, so are we. The thrill of the hack is not in breaking the law, it's in the pursuit and capture of knowledge. To this end, let me contribute my suggestions for guidelines to follow to ensure that not only you stay out of trouble, but you pursue your craft without damaging the computers you hack into or the companies who own them. I. Do not intentionally damage *any* system. II. Do not alter any system files other than ones needed to ensure your escape from detection and your future access (Trojan Horses, Altering Logs, and the like are all necessary to your survival for as long as possible.) III. Do not leave your (or anyone else's) real name, real handle, or real phone number on any system that you access illegally. They *can* and will track you down from your handle! IV. Be careful who you share information with. Feds are getting trickier. Generally, if you don't know their voice phone number, name, and occupation or haven't spoken with them voice on non-info trading conversations, be wary. V. Do not leave your real phone number to anyone you don't know. This includes logging on boards, no matter how k-rad they seem. If you don't know the sysop, leave a note telling some trustworthy people that will validate you. VI. Do not hack government computers. Yes, there are government systems that are safe to hack, but they are few and far between. And the government has inifitely more time and resources to track you down than a company who has to make a profit and justify expenses. VII. Don't use codes unless there is *NO* way around it (you don't have a local telenet or tymnet outdial and can't connect to anything 800...) You use codes long enough, you will get caught. Period. VIII. Don't be afraid to be paranoid. Remember, you *are* breaking the law. It doesn't hurt to store everything encrypted on your hard disk, or keep your notes buried in the backyard or in the trunk of your car. You may feel a little funny, but you'll feel a lot funnier when you when you meet Bruno, your transvestite cellmate who axed his family to death. IX. Watch what you post on boards. Most of the really great hackers in the country post *nothing* about the system they're currently working except in the broadest sense (I'm working on a UNIX, or a COSMOS, or something generic. Not "I'm hacking into General Electric's Voice Mail System" or something inane and revealing like that.) X. Don't be afraid to ask questions. That's what more experienced hackers are for. Don't expect *everything* you ask to be answered, though. There are some things (LMOS, for instance) that a begining hacker shouldn't mess with. You'll either get caught, or screw it up for others, or both. XI. Finally, you have to actually hack. You can hang out on boards all you want, and you can read all the text files in the world, but until you actually start doing it, you'll never know what it's all about. There's no thrill quite the same as getting into your first system (well, ok, I can think of a couple of bigger thrills, but you get the picture.) One of the safest places to start your hacking career is on a computer system belonging to a college. University computers have notoriously lax security, and are more used to hackers, as every college computer depart- ment has one or two, so are less likely to press charges if you should be detected. But the odds of them detecting you and having the personel to committ to tracking you down are slim as long as you aren't destructive. If you are already a college student, this is ideal, as you can legally explore your computer system to your heart's desire, then go out and look for similar systems that you can penetrate with confidence, as you're already familar with them. So if you just want to get your feet wet, call your local college. Many of them will provide accounts for local residents at a nominal (under $20) charge. Finally, if you get caught, stay quiet until you get a lawyer. Don't vol- unteer any information, no matter what kind of 'deals' they offer you. Nothing is binding unless you make the deal through your lawyer, so you might as well shut up and wait. Part Two: Networks ~~~~~~~~~~~~~~~~~~ The best place to begin hacking (other than a college) is on one of the bigger networks such as Telenet. Why? First, there is a wide variety of computers to choose from, from small Micro-Vaxen to huge Crays. Second, the networks are fairly well documented. It's easier to find someone who can help you with a problem off of Telenet than it is to find assistance concerning your local college computer or high school machine. Third, the networks are safer. Because of the enormous number of calls that are fielded every day by the big networks, it is not financially practical to keep track of where every call and connection are made from. It is also very easy to disguise your location using the network, which makes your hobby much more secure. Telenet has more computers hooked to it than any other system in the world once you consider that from Telenet you have access to Tymnet, ItaPAC, JANET, DATAPAC, SBDN, PandaNet, THEnet, and a whole host of other networks, all of which you can connect to from your terminal. The first step that you need to take is to identify your local dialup port. This is done by dialing 1-800-424-9494 (1200 7E1) and connecting. It will spout some garbage at you and then you'll get a prompt saying 'TERMINAL='. This is your terminal type. If you have vt100 emulation, type it in now. Or just hit return and it will default to dumb terminal mode. You'll now get a prompt that looks like a @. From here, type @c mail and then it will ask for a Username. Enter 'phones' for the username. When it asks for a password, enter 'phones' again. From this point, it is menu driven. Use this to locate your local dialup, and call it back locally. If you don't have a local dialup, then use whatever means you wish to connect to one long distance (more on this later.) When you call your local dialup, you will once again go through the TERMINAL= stuff, and once again you'll be presented with a @. This prompt lets you know you are connected to a Telenet PAD. PAD stands for either Packet Assembler/Disassembler (if you talk to an engineer), or Public Access Device (if you talk to Telenet's marketing people.) The first description is more correct. Telenet works by taking the data you enter in on the PAD you dialed into, bundling it into a 128 byte chunk (normally... this can be changed), and then transmitting it at speeds ranging from 9600 to 19,200 baud to another PAD, who then takes the data and hands it down to whatever computer or system it's connected to. Basically, the PAD allows two computers that have different baud rates or communication protocols to communicate with each other over a long distance. Sometimes you'll notice a time lag in the remote machines response. This is called PAD Delay, and is to be expected when you're sending data through several different links. What do you do with this PAD? You use it to connect to remote computer systems by typing 'C' for connect and then the Network User Address (NUA) of the system you want to go to. An NUA takes the form of 031103130002520 \___/\___/\___/ | | | | | |____ network address | |_________ area prefix |______________ DNIC This is a summary of DNIC's (taken from Blade Runner's file on ItaPAC) according to their country and network name. DNIC Network Name Country DNIC Network Name Country _______________________________________________________________________________ | 02041 Datanet 1 Netherlands | 03110 Telenet USA 02062 DCS Belgium | 03340 Telepac Mexico 02080 Transpac France | 03400 UDTS-Curacau Curacau 02284 Telepac Switzerland | 04251 Isranet Israel 02322 Datex-P Austria | 04401 DDX-P Japan 02329 Radaus Austria | 04408 Venus-P Japan 02342 PSS UK | 04501 Dacom-Net South Korea 02382 Datapak Denmark | 04542 Intelpak Singapore 02402 Datapak Sweden | 05052 Austpac Australia 02405 Telepak Sweden | 05053 Midas Australia 02442 Finpak Finland | 05252 Telepac Hong Kong 02624 Datex-P West Germany | 05301 Pacnet New Zealand 02704 Luxpac Luxembourg | 06550 Saponet South Africa 02724 Eirpak Ireland | 07240 Interdata Brazil 03020 Datapac Canada | 07241 Renpac Brazil 03028 Infogram Canada | 09000 Dialnet USA 03103 ITT/UDTS USA | 07421 Dompac French Guiana 03106 Tymnet USA | There are two ways to find interesting addresses to connect to. The first and easiest way is to obtain a copy of the LOD/H Telenet Directory from the LOD/H Technical Journal #4 or 2600 Magazine. Jester Sluggo also put out a good list of non-US addresses in Phrack Inc. Newsletter Issue 21. These files will tell you the NUA, whether it will accept collect calls or not, what type of computer system it is (if known) and who it belongs to (also if known.) The second method of locating interesting addresses is to scan for them manually. On Telenet, you do not have to enter the 03110 DNIC to connect to a Telenet host. So if you saw that 031104120006140 had a VAX on it you wanted to look at, you could type @c 412 614 (0's can be ignored most of the time.) If this node allows collect billed connections, it will say 412 614 CONNECTED and then you'll possibly get an identifying header or just a Username: prompt. If it doesn't allow collect connections, it will give you a message such as 412 614 REFUSED COLLECT CONNECTION with some error codes out to the right, and return you to the @ prompt. There are two primary ways to get around the REFUSED COLLECT message. The first is to use a Network User Id (NUI) to connect. An NUI is a username/pw combination that acts like a charge account on Telenet. To collect to node 412 614 with NUI junk4248, password 525332, I'd type the following: @c 412 614,junk4248,525332 <---- the 525332 will *not* be echoed to the screen. The problem with NUI's is that they're hard to come by unless you're a good social engineer with a thorough knowledge of Telenet (in which case you probably aren't reading this section), or you have someone who can provide you with them. The second way to connect is to use a private PAD, either through an X.25 PAD or through something like Netlink off of a Prime computer (more on these two below.) The prefix in a Telenet NUA oftentimes (not always) refers to the phone Area Code that the computer is located in (i.e. 713 xxx would be a computer in Houston, Texas.) If there's a particular area you're interested in, (say, New York City 914), you could begin by typing @c 914 001 . If it connects, you make a note of it and go on to 914 002. You do this until you've found some interesting systems to play with. Not all systems are on a simple xxx yyy address. Some go out to four or five digits (914 2354), and some have decimal or numeric extensions (422 121A = 422 121.01). You have to play with them, and you never know what you're going to find. To fully scan out a prefix would take ten million attempts per prefix. For example, if I want to scan 512 completely, I'd have to start with 512 00000.00 and go through 512 00000.99, then increment the address by 1 and try 512 00001.00 through 512 00001.99. A lot of scanning. There are plenty of neat computers to play with in a 3-digit scan, however, so don't go berserk with the extensions. Sometimes you'll attempt to connect and it will just be sitting there after one or two minutes. In this case, you want to abort the connect attempt by sending a hard break (this varies with different term programs, on Procomm, it's ALT-B), and then when you get the @ prompt back, type 'D' for disconnect. If you connect to a computer and wish to disconnect, you can type @ and you it should say TELENET and then give you the @ prompt. From there, type D to disconnect or CONT to re-connect and continue your session uninterrupted. Outdials, Network Servers, and PADs ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In addition to computers, an NUA may connect you to several other things. One of the most useful is the outdial. An outdial is nothing more than a modem you can get to over telenet- similar to the PC Pursuit concept, except that these don't have passwords on them most of the time. When you connect, you will get a message like 'Hayes 1200 baud outdial, Detroit, MI', or 'VEN-TEL 212 Modem', or possibly 'Session 1234 established on Modem 5588'. The best way to figure out the commands on these is to type ? or H or HELP- this will get you all the information that you need to use one. Safety tip here- when you are hacking *any* system through a phone dialup, always use an outdial or a diverter, especially if it is a local phone number to you. More people get popped hacking on local computers than you can imagine, Intra-LATA calls are the easiest things in the world to trace inexp- ensively. Another nice trick you can do with an outdial is use the redial or macro function that many of them have. First thing you do when you connect is to invoke the 'Redial Last Number' facility. This will dial the last number used, which will be the one the person using it before you typed. Write down the number, as no one would be calling a number without a computer on it. This is a good way to find new systems to hack. Also, on a VENTEL modem, type 'D' for Display and it will display the five numbers stored as macros in the modem's memory. There are also different types of servers for remote Local Area Networks (LAN) that have many machine all over the office or the nation connected to them. I'll discuss identifying these later in the computer ID section. And finally, you may connect to something that says 'X.25 Communication PAD' and then some more stuff, followed by a new @ prompt. This is a PAD just like the one you are on, except that all attempted connections are billed to the PAD, allowing you to connect to those nodes who earlier refused collect connections. This also has the added bonus of confusing where you are connecting from. When a packet is transmitted from PAD to PAD, it contains a header that has the location you're calling from. For instance, when you first connected to Telenet, it might have said 212 44A CONNECTED if you called from the 212 area code. This means you were calling PAD number 44A in the 212 area. That 21244A will be sent out in the header of all packets leaving the PAD. Once you connect to a private PAD, however, all the packets going out from *it* will have it's address on them, not yours. This can be a valuable buffer between yourself and detection. Phone Scanning ~~~~~~~~~~~~~~ Finally, there's the time-honored method of computer hunting that was made famous among the non-hacker crowd by that Oh-So-Technically-Accurate movie Wargames. You pick a three digit phone prefix in your area and dial every number from 0000 --> 9999 in that prefix, making a note of all the carriers you find. There is software available to do this for nearly every computer in the world, so you don't have to do it by hand. Part Three: I've Found a Computer, Now What? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This next section is applicable universally. It doesn't matter how you found this computer, it could be through a network, or it could be from carrier scanning your High School's phone prefix, you've got this prompt this prompt, what the hell is it? I'm *NOT* going to attempt to tell you what to do once you're inside of any of these operating systems. Each one is worth several G-files in its own right. I'm going to tell you how to identify and recognize certain OpSystems, how to approach hacking into them, and how to deal with something that you've never seen before and have know idea what it is. VMS- The VAX computer is made by Digital Equipment Corporation (DEC), and runs the VMS (Virtual Memory System) operating system. VMS is characterized by the 'Username:' prompt. It will not tell you if you've entered a valid username or not, and will disconnect you after three bad login attempts. It also keeps track of all failed login attempts and informs the owner of the account next time s/he logs in how many bad login attempts were made on the account. It is one of the most secure operating systems around from the outside, but once you're in there are many things that you can do to circumvent system security. The VAX also has the best set of help files in the world. Just type HELP and read to your heart's content. Common Accounts/Defaults: [username: password [[,password]] ] SYSTEM: OPERATOR or MANAGER or SYSTEM or SYSLIB OPERATOR: OPERATOR SYSTEST: UETP SYSMAINT: SYSMAINT or SERVICE or DIGITAL FIELD: FIELD or SERVICE GUEST: GUEST or unpassworded DEMO: DEMO or unpassworded DECNET: DECNET DEC-10- An earlier line of DEC computer equipment, running the TOPS-10 operating system. These machines are recognized by their '.' prompt. The DEC-10/20 series are remarkably hacker-friendly, allowing you to enter several important commands without ever logging into the system. Accounts are in the format [xxx,yyy] where xxx and yyy are integers. You can get a listing of the accounts and the process names of everyone on the system before logging in with the command .systat (for SYstem STATus). If you seen an account that reads [234,1001] BOB JONES, it might be wise to try BOB or JONES or both for a password on this account. To login, you type .login xxx,yyy and then type the password when prompted for it. The system will allow you unlimited tries at an account, and does not keep records of bad login attempts. It will also inform you if the UIC you're trying (UIC = User Identification Code, 1,2 for example) is bad. Common Accounts/Defaults: 1,2: SYSLIB or OPERATOR or MANAGER 2,7: MAINTAIN 5,30: GAMES UNIX- There are dozens of different machines out there that run UNIX. While some might argue it isn't the best operating system in the world, it is certainly the most widely used. A UNIX system will usually have a prompt like 'login:' in lower case. UNIX also will give you unlimited shots at logging in (in most cases), and there is usually no log kept of bad attempts. Common Accounts/Defaults: (note that some systems are case sensitive, so use lower case as a general rule. Also, many times the accounts will be unpassworded, you'll just drop right in!) root: root admin: admin sysadmin: sysadmin or admin unix: unix uucp: uucp rje: rje guest: guest demo: demo daemon: daemon sysbin: sysbin Prime- Prime computer company's mainframe running the Primos operating system. The are easy to spot, as the greet you with 'Primecon 18.23.05' or the like, depending on the version of the operating system you run into. There will usually be no prompt offered, it will just look like it's sitting there. At this point, type 'login '. If it is a pre-18.00.00 version of Primos, you can hit a bunch of ^C's for the password and you'll drop in. Unfortunately, most people are running versions 19+. Primos also comes with a good set of help files. One of the most useful features of a Prime on Telenet is a facility called NETLINK. Once you're inside, type NETLINK and follow the help files. This allows you to connect to NUA's all over the world using the 'nc' command. For example, to connect to NUA 026245890040004, you would type @nc :26245890040004 at the netlink prompt. Common Accounts/Defaults: PRIME PRIME or PRIMOS PRIMOS_CS PRIME or PRIMOS PRIMENET PRIMENET SYSTEM SYSTEM or PRIME NETLINK NETLINK TEST TEST GUEST GUEST GUEST1 GUEST HP-x000- This system is made by Hewlett-Packard. It is characterized by the ':' prompt. The HP has one of the more complicated login sequences around- you type 'HELLO SESSION NAME,USERNAME,ACCOUNTNAME,GROUP'. Fortunately, some of these fields can be left blank in many cases. Since any and all of these fields can be passworded, this is not the easiest system to get into, except for the fact that there are usually some unpassworded accounts around. In general, if the defaults don't work, you'll have to brute force it using the common password list (see below.) The HP-x000 runs the MPE operat- ing system, the prompt for it will be a ':', just like the logon prompt. Common Accounts/Defaults: MGR.TELESUP,PUB User: MGR Acct: HPONLY Grp: PUB MGR.HPOFFICE,PUB unpassworded MANAGER.ITF3000,PUB unpassworded FIELD.SUPPORT,PUB user: FLD, others unpassworded MAIL.TELESUP,PUB user: MAIL, others unpassworded MGR.RJE unpassworded FIELD.HPPl89 ,HPPl87,HPPl89,HPPl96 unpassworded MGR.TELESUP,PUB,HPONLY,HP3 unpassworded IRIS- IRIS stands for Interactive Real Time Information System. It orig- inally ran on PDP-11's, but now runs on many other minis. You can spot an IRIS by the 'Welcome to "IRIS" R9.1.4 Timesharing' banner, and the ACCOUNT ID? prompt. IRIS allows unlimited tries at hacking in, and keeps no logs of bad attempts. I don't know any default passwords, so just try the common ones from the password database below. Common Accounts: MANAGER BOSS SOFTWARE DEMO PDP8 PDP11 ACCOUNTING VM/CMS- The VM/CMS operating system runs in International Business Machines (IBM) mainframes. When you connect to one of these, you will get message similar to 'VM/370 ONLINE', and then give you a '.' prompt, just like TOPS-10 does. To login, you type 'LOGON '. Common Accounts/Defaults are: AUTOLOG1: AUTOLOG or AUTOLOG1 CMS: CMS CMSBATCH: CMS or CMSBATCH EREP: EREP MAINT: MAINT or MAINTAIN OPERATNS: OPERATNS or OPERATOR OPERATOR: OPERATOR RSCS: RSCS SMART: SMART SNA: SNA VMTEST: VMTEST VMUTIL: VMUTIL VTAM: VTAM NOS- NOS stands for Networking Operating System, and runs on the Cyber computer made by Control Data Corporation. NOS identifies itself quite readily, with a banner of 'WELCOME TO THE NOS SOFTWARE SYSTEM. COPYRIGHT CONTROL DATA 1978,1987'. The first prompt you will get will be FAMILY:. Just hit return here. Then you'll get a USER NAME: prompt. Usernames are typically 7 alpha-numerics characters long, and are *extremely* site dependent. Operator accounts begin with a digit, such as 7ETPDOC. Common Accounts/Defaults: $SYSTEM unknown SYSTEMV unknown Decserver- This is not truly a computer system, but is a network server that has many different machines available from it. A Decserver will say 'Enter Username>' when you first connect. This can be anything, it doesn't matter, it's just an identifier. Type 'c', as this is the least conspicuous thing to enter. It will then present you with a 'Local>' prompt. From here, you type 'c ' to connect to a system. To get a list of system names, type 'sh services' or 'sh nodes'. If you have any problems, online help is available with the 'help' command. Be sure and look for services named 'MODEM' or 'DIAL' or something similar, these are often outdial modems and can be useful! GS/1- Another type of network server. Unlike a Decserver, you can't predict what prompt a GS/1 gateway is going to give you. The default prompt it 'GS/1>', but this is redifinable by the system administrator. To test for a GS/1, do a 'sh d'. If that prints out a large list of defaults (terminal speed, prompt, parity, etc...), you are on a GS/1. You connect in the same manner as a Decserver, typing 'c '. To find out what systems are available, do a 'sh n' or a 'sh c'. Another trick is to do a 'sh m', which will sometimes show you a list of macros for logging onto a system. If there is a macro named VAX, for instance, type 'do VAX'. The above are the main system types in use today. There are hundreds of minor variants on the above, but this should be enough to get you started. Unresponsive Systems ~~~~~~~~~~~~~~~~~~~~ Occasionally you will connect to a system that will do nothing but sit there. This is a frustrating feeling, but a methodical approach to the system will yield a response if you take your time. The following list will usually make *something* happen. 1) Change your parity, data length, and stop bits. A system that won't re- spond at 8N1 may react at 7E1 or 8E2 or 7S2. If you don't have a term program that will let you set parity to EVEN, ODD, SPACE, MARK, and NONE, with data length of 7 or 8, and 1 or 2 stop bits, go out and buy one. While having a good term program isn't absolutely necessary, it sure is helpful. 2) Change baud rates. Again, if your term program will let you choose odd baud rates such as 600 or 1100, you will occasionally be able to penetrate some very interesting systems, as most systems that depend on a strange baud rate seem to think that this is all the security they need... 3) Send a series of 's. 4) Send a hard break followed by a . 5) Type a series of .'s (periods). The Canadian network Datapac responds to this. 6) If you're getting garbage, hit an 'i'. Tymnet responds to this, as does a MultiLink II. 7) Begin sending control characters, starting with ^A --> ^Z. 8) Change terminal emulations. What your vt100 emulation thinks is garbage may all of a sudden become crystal clear using ADM-5 emulation. This also relates to how good your term program is. 9) Type LOGIN, HELLO, LOG, ATTACH, CONNECT, START, RUN, BEGIN, LOGON, GO, JOIN, HELP, and anything else you can think of. 10) If it's a dialin, call the numbers around it and see if a company answers. If they do, try some social engineering. Brute Force Hacking ~~~~~~~~~~~~~~~~~~~ There will also be many occasions when the default passwords will not work on an account. At this point, you can either go onto the next system on your list, or you can try to 'brute-force' your way in by trying a large database of passwords on that one account. Be careful, though! This works fine on systems that don't keep track of invalid logins, but on a system like a VMS, someone is going to have a heart attack if they come back and see '600 Bad Login Attempts Since Last Session' on their account. There are also some operating systems that disconnect after 'x' number of invalid login attempts and refuse to allow any more attempts for one hour, or ten minutes, or some- times until the next day. The following list is taken from my own password database plus the data- base of passwords that was used in the Internet UNIX Worm that was running around in November of 1988. For a shorter group, try first names, computer terms, and obvious things like 'secret', 'password', 'open', and the name of the account. Also try the name of the company that owns the computer system (if known), the company initials, and things relating to the products the company makes or deals with. Password List ============= aaa daniel jester rascal academia danny johnny really ada dave joseph rebecca adrian deb joshua remote aerobics debbie judith rick airplane deborah juggle reagan albany december julia robot albatross desperate kathleen robotics albert develop kermit rolex alex diet kernel ronald alexander digital knight rosebud algebra discovery lambda rosemary alias disney larry roses alpha dog lazarus ruben alphabet drought lee rules ama duncan leroy ruth amy easy lewis sal analog eatme light saxon anchor edges lisa scheme andy edwin louis scott andrea egghead lynne scotty animal eileen mac secret answer einstein macintosh sensor anything elephant mack serenity arrow elizabeth maggot sex arthur ellen magic shark asshole emerald malcolm sharon athena engine mark shit atmosphere engineer markus shiva bacchus enterprise marty shuttle badass enzyme marvin simon bailey euclid master simple banana evelyn maurice singer bandit extension merlin single banks fairway mets smile bass felicia michael smiles batman fender michelle smooch beauty fermat mike smother beaver finite minimum snatch beethoven flower minsky snoopy beloved foolproof mogul soap benz football moose socrates beowulf format mozart spit berkeley forsythe nancy spring berlin fourier napoleon subway beta fred network success beverly friend newton summer bob frighten next super brenda fun olivia support brian gabriel oracle surfer bridget garfield orca suzanne broadway gauss orwell tangerine bumbling george osiris tape cardinal gertrude outlaw target carmen gibson oxford taylor carolina ginger pacific telephone caroline gnu painless temptation castle golf pam tiger cat golfer paper toggle celtics gorgeous password tomato change graham pat toyota charles gryphon patricia trivial charming guest penguin unhappy charon guitar pete unicorn chester hacker peter unknown cigar harmony philip urchin classic harold phoenix utility coffee harvey pierre vicky coke heinlein pizza virginia collins hello plover warren comrade help polynomial water computer herbert praise weenie condo honey prelude whatnot condom horse prince whitney cookie imperial protect will cooper include pumpkin william create ingres puppet willie creation innocuous rabbit winston creator irishman rachmaninoff wizard cretin isis rainbow wombat daemon japan raindrop yosemite dancer jessica random zap Part Four: Wrapping it up! ~~~~~~~~~~~~~~~~~~~~~~~~~~ I hope this file has been of some help in getting started. If you're asking yourself the question 'Why hack?', then you've probably wasted a lot of time reading this, as you'll never understand. For those of you who have read this and found it useful, please send a tax-deductible donation of $5.00 (or more!) in the name of the Legion of Doom to: The American Cancer Society 90 Park Avenue New York, NY 10016 ****************************************************************************** References: 1) Introduction to ItaPAC by Blade Runner Telecom Security Bulletin #1 2) The IBM VM/CMS Operating System by Lex Luthor The LOD/H Technical Journal #2 3) Hacking the IRIS Operating System by The Leftist The LOD/H Technical Journal #3 4) Hacking CDC's Cyber by Phrozen Ghost Phrack Inc. Newsletter #18 5) USENET comp.risks digest (various authors, various issues) 6) USENET unix.wizards forum (various authors) 7) USENET info-vax forum (various authors) Recommended Reading: 1) Hackers by Steven Levy 2) Out of the Inner Circle by Bill Landreth 3) Turing's Man by J. David Bolter 4) Soul of a New Machine by Tracy Kidder 5) Neuromancer, Count Zero, Mona Lisa Overdrive, and Burning Chrome, all by William Gibson 6) Reality Hackers Magazine c/o High Frontiers, P.O. Box 40271, Berkeley, California, 94704, 415-995-2606 7) Any of the Phrack Inc. Newsletters & LOD/H Technical Journals you can find. Acknowledgements: Thanks to my wife for putting up with me. Thanks to Lone Wolf for the RSTS & TOPS assistance. Thanks to Android Pope for proofreading, suggestions, and beer. Thanks to The Urvile/Necron 99 for proofreading & Cyber info. Thanks to Eric Bloodaxe for wading through all the trash. Thanks to the users of Phoenix Project for their contributions. Thanks to Altos Computer Systems, Munich, for the chat system. Thanks to the various security personel who were willing to talk to me about how they operate.

Almost Everything You Ever Wanted To Know About Security

Almost Everything You Ever Wanted To Know About Security* *(but were afraid to ask!) This document is meant to answer some of the questions which regularly appear in the Usenet newsgroups "comp.security.misc" and "alt.security", and is meant to provide some background to the subject for newcomers to that newsgroup. This FAQ is maintained by Alec Muffett (aem@aber.ac.uk, uknet!aber!aem), with contributions from numerous others [perhaps]. The views expressed in the document are the personal views of the author(s), and it should not be inferred that they are necessarily shared by anyone with whom the author(s) are now, or ever may be, associated. Many thanks go to (in no particular order): Steve Bellovin, Matt Bishop, Mark Brader, Ed DeHart, Dave Hayes, Jeffrey Hutzelman, William LeFebvre, Wes Morgan, Rob Quinn, Chip Rosenthal, Wietse Venema, Gene Spafford, John Wack and Randall Atkinson. Disclaimer: Every attempt is made to ensure that the information contained in this FAQ is up to date and accurate, but no responsibility will be accepted for actions resulting from information gained herein. Questions which this document addresses: Q.1 What are alt.security and comp.security.misc for? Q.2 Whats the difference between a hacker and a cracker? Q.3 What is "security through obscurity" Q.4 What makes a system insecure? Q.5 What tools are there to aid security? Q.6 Isn't it dangerous to give cracking tools to everyone? Q.7 Where can I get these tools? Q.8 Why and how do systems get broken into? Q.9 Who can I contact if I get broken into? Q.10 What is a firewall? Q.11 Why shouldn't I use setuid shell scripts? Q.12 Why shouldn't I leave "root" permanently logged on the console? Q.13 Why shouldn't I create Unix accounts with null passwords? Q.14 What security holes are associated with X-windows (and other WMs)? Q.15 What security holes are associated with NFS? Q.16 How can I generate safe passwords? Q.17 Why are passwords so important? Q.18 How many possible passwords are there? Q.19 Where can I get more information? Q.20 How silly can people get? --------------------------------------------------------------------------- Q.1 What are alt.security and comp.security.misc for? Comp.security.misc is a forum for the discussion of computer security, especially those relating to Unix (and Unix like) operating systems. Alt.security used to be the main newsgroup covering this topic, as well as other issues such as car locks and alarm systems, but with the creation of comp.security.misc, this may change. This FAQ will concentrate wholly upon computer related security issues. The discussions posted range from the likes of "What's such-and-such system like?" and "What is the best software I can use to do so-and-so" to "How shall we fix this particular bug?", although there is often a low signal to noise ratio in the newsgroup (a problem which this FAQ hopes to address). The most common flamewars start when an apparent security novice posts a message saying "Can someone explain how the such-and-such security hole works?" and s/he is immediately leapt upon by a group of self appointed people who crucify the person for asking such an "unsound" question in a public place, and flame him/her for "obviously" being a cr/hacker. Please remember that grilling someone over a high flame on the grounds that they are "a possible cr/hacker" does nothing more than generate a lot of bad feeling. If computer security issues are to be dealt with in an effective manner, the campaigns must be brought (to a large extent) into the open. Implementing computer security can turn ordinary people into rampaging paranoiacs, unable to act reasonably when faced with a new situation. Such people take an adversarial attitude to the rest of the human race, and if someone like this is in charge of a system, users will rapidly find their machine becoming more restrictive and less friendly (fun?) to use. This can lead to embarrasing situations, eg: (in one university) banning a head of department from the college mainframe for using a network utility that he wasn't expected to. This apparently required a lot of explaining to an unsympathetic committee to get sorted out. A more sensible approach is to secure a system according to its needs, and if its needs are great enough, isolate it completely. Please, don't lose your sanity to the cause of computer security; it's not worth it. Q.2 What's the difference between a hacker and a cracker? Lets get this question out of the way right now: On USENET, calling someone a "cracker" is an unambiguous statement that some person persistently gets his/her kicks from breaking from into other peoples computer systems, for a variety of reasons. S/He may pose some weak justification for doing this, usually along the lines of "because it's possible", but most probably does it for the "buzz" of doing something which is illicit/illegal, and to gain status amongst a peer group. Particularly antisocial crackers have a vandalistic streak, and delete filestores, crash machines, and trash running processes in pursuit of their "kicks". The term is also widely used to describe a person who breaks copy protection software in microcomputer applications software in order to keep or distribute free copies. On USENET, calling someone a "hacker" is usually a statement that said person holds a great deal of knowledge and expertise in the field of computing, and is someone who is capable of exercising this expertise with great finesse. For a more detailed definition, readers are referred to the Jargon File [Raymond]. In the "real world", various media people have taken the word "hacker" and coerced it into meaning the same as "cracker" - this usage occasionally appears on USENET, with disastrous and confusing results. Posters to the security newsgroups should note that they currently risk a great deal of flamage if they use the word "hacker" in place of "cracker" in their articles. NB: nowhere in the above do I say that crackers cannot be true hackers. It's just that I don't say that they are... Q.3 What is "security through obscurity" Security Through Obscurity (STO) is the belief that a system of any sort can be secure so long as nobody outside of its implementation group is allowed to find out anything about its internal mechanisms. Hiding account passwords in binary files or scripts with the presumption that "nobody will ever find it" is a prime case of STO. STO is a philosophy favoured by many bureaucratic agencies (military, governmental, and industrial), and it used to be a major method of providing "pseudosecurity" in computing systems. Its usefulness has declined in the computing world with the rise of open systems, networking, greater understanding of programming techniques, as well as the increase in computing power available to the average person. The basis of STO has always been to run your system on a "need to know" basis. If a person doesn't know how to do something which could impact system security, then s/he isn't dangerous. Admittedly, this is sound in theory, but it can tie you into trusting a small group of people for as long as they live. If your employees get an offer of better pay from somewhere else, the knowledge goes with them, whether the knowledge is replaceable or not. Once the secret gets out, that is the end of your security. Nowadays there is also a greater need for the ordinary user to know details of how your system works than ever before, and STO falls down a as a result. Many users today have advanced knowledge of how their operating system works, and because of their experience will be able to guess at the bits of knowledge that they didn't "need to know". This bypasses the whole basis of STO, and makes your security useless. Hence there is now a need is to to create systems which attempt to be algorithmically secure (Kerberos, Secure RPC), rather than just philosophically secure. So long as your starting criteria can be met, your system is LOGICALLY secure. "Shadow Passwords" (below) are sometimes dismissed as STO, but this is incorrect, since (strictly) STO depends on restricting access to an algorithm or technique, whereas shadow passwords provide security by restricting access to vital data. Q.4 What makes a system insecure? Switching it on. The adage usually quoted runs along these lines: "The only system which is truly secure is one which is switched off and unplugged, locked in a titanium lined safe, buried in a concrete bunker, and is surrounded by nerve gas and very highly paid armed guards. Even then, I wouldn't stake my life on it." (the original version of this is attributed to Gene Spafford) A system is only as secure as the people who can get at it. It can be "totally" secure without any protection at all, so long as its continued good operation is important to everyone who can get at it, assuming all those people are responsible, and regular backups are made in case of hardware problems. Many laboratory PC's quite merrily tick away the hours like this. The problems arise when a need (such as confidentiality) has to be fulfilled. Once you start putting the locks on a system, it is fairly likely that you will never stop. Security holes manifest themselves in (broadly) four ways: 1) Physical Security Holes. - Where the potential problem is caused by giving unauthorised persons physical access to the machine, where this might allow them to perform things that they shouldn't be able to do. A good example of this would be a public workstation room where it would be trivial for a user to reboot a machine into single-user mode and muck around with the workstation filestore, if precautions are not taken. Another example of this is the need to restrict access to confidential backup tapes, which may (otherwise) be read by any user with access to the tapes and a tape drive, whether they are meant to have permission or not. 2) Software Security Holes - Where the problem is caused by badly written items of "privledged" software (daemons, cronjobs) which can be compromised into doing things which they shouldn't oughta. The most famous example of this is the "sendmail debug" hole (see bibliography) which would enable a cracker to bootstrap a "root" shell. This could be used to delete your filestore, create a new account, copy your password file, anything. (Contrary to popular opinion, crack attacks via sendmail were not just restricted to the infamous "Internet Worm" - any cracker could do this by using "telnet" to port 25 on the target machine. The story behind a similar hole (this time in EMACS) is described in [Stoll].) New holes like this appear all the time, and your best hopes are to: a: try to structure your system so that as little software as possible runs with root/daemon/bin privileges, and that which does is known to be robust. b: subscribe to a mailing list which can get details of problems and/or fixes out to you as quickly as possible, and then ACT when you receive information. 3) Incompatible Usage Security Holes - Where, through lack of experience, or no fault of his/her own, the System Manager assembles a combination of hardware and software which when used as a system is seriously flawed from a security point of view. It is the incompatibility of trying to do two unconnected but useful things which creates the security hole. Problems like this are a pain to find once a system is set up and running, so it is better to build your system with them in mind. It's never too late to have a rethink, though. Some examples are detailed below; let's not go into them here, it would only spoil the surprise. 4) Choosing a suitable security philosophy and maintaining it. >From: Gene Spafford >The fourth kind of security problem is one of perception and >understanding. Perfect software, protected hardware, and compatible >components don't work unless you have selected an appropriate security >policy and turned on the parts of your system that enforce it. Having >the best password mechanism in the world is worthless if your users >think that their login name backwards is a good password! Security is >relative to a policy (or set of policies) and the operation of a system >in conformance with that policy. Q.5 What tools are there to aid security? 1) "COPS" Managed by Dan Farmer, this is a long established suite of shell scripts which forms an extensive security testing system; There is a rudimentary password cracker, and routines to check the filestore for suspicious changes in setuid programs, others to check permissions of essential system and user files, and still more to see whether any system software behaves in a way which could cause problems. The software comes in two versions - one written in Perl and one (largely equivalent) written in shell scripts. The latest version is very up-to-date on Unix Security holes. 2) "Crack" (+ "UFC"). Written by Alec Muffett, this is a program written with one purpose in mind: to break insecure passwords. It is probably the most efficent and friendly password cracker that is publically available, with the ability to let the user to specify precisely how to form the words to use as guesses at users passwords. It also has an inbuilt networking capability, allowing the load of cracking to be spread over as many machines as are available on a network, and it is supplied with an optimised version of the Unix crypt() algorithm. An even faster version of the crypt() algorithm, "UFC" by Michael Glad, is freely available on the network, and the latest versions of UFC and Crack are compatible and can be easily hooked together. 3) NPasswd (Clyde Hoover) & Passwd+ (Matt Bishop) These programs are written to redress the balance in the password cracking war. They provide replacements for the standard "passwd" command, but prevent a user from selecting passwords which are easily compromised by programs like Crack. Several versions of these programs are available on the network, hacked about to varying degrees in order to provide compatibility for System V based systems, NIS/YP, shadow password schemes, etc. The usual term for this type of program is a 'fascist' password program. 4) "Shadow" - a Shadow Password Suite This program suite (by John F Haugh II) is a set of program and function replacements (compatible with most Unixes) which implements shadow passwords, ie: a system where the plaintext of the password file is hidden from all users except root, hopefully stopping all password cracking attempts at source. In combination with a fascist passwd frontend, it should provide a good degree of password file robustness. >From: jfh@rpp386.lonestar.org (John F. Haugh II) >Shadow does much more than hide passwords. It also provides for >terminal access control, user and group administration, and a few >other things which I've forgotten. There are a dozen or more >commands in the suite, plus a whole slew of library functions. 5) TCP Wrappers (Wietse Venema) These are programs which provide a front-end filter to many of the network services which Unix provides by default. If installed, they can curb otherwise unrestricted access to potential dangers like incoming FTP/TFTP, Telnet, etc, and can provide extra logging information, which may be of use if it appears that someone is trying to break in. 6) SecureLib >From: phil@pex.eecs.nwu.edu (William LeFebvre) >You may want to add a mention of securelib, a security enhancer >available for SunOS version 4.1 and higher. >Securelib contains replacement routines for three kernel calls: >accept(), recvfrom(), recvmsg(). These replacements are compatible with >the originals, with the additional functionality that they check the >Internet address of the machine initiating the connection to make sure >that it is "allowed" to connect. A configuration file defines what >hosts are allowed for a given program. Once these replacement routines >are compiled, they can be used when building a new shared libc library. >The resulting libc.so can then be put in a special place. Any program >that should be protected can then be started with an alternate >LD_LIBRARY_PATH. 7) SPI >From: Gene Spafford >Sites connected with the Department of Energy and some military >organizations may also have access to the SPI package. Interested (and >qualified) users should contact the CIAC at LLNL for details. >SPI is a screen-based administrator's tool that checks configuration >options, includes a file-change (integrity) checker to monitor for >backdoors and viruses, and various other security checks. Future >versions will probably integrate COPS into the package. It is not >available to the general public, but it is available to US Dept of >Energy contractors and sites and to some US military sites. A version >does or will exist for VMS, too. Further information on availabilty can >be had from the folks at the DoE CIAC. Q.6 Isn't it dangerous to give cracking tools to everyone? That depends on your point of view. Some people have complained that giving unrestricted public access to programs like COPS and Crack is irresponsible because the "baddies" can get at them easily. Alternatively, you may believe that the really bad "baddies" have had programs like this for years, and that it's really a stupendously good idea to give these programs to the good guys too, so that they may check the integrity of their system before the baddies get to them. So, who wins more from having these programs freely available? The good guys or the bad ? You decide, but remember that less honest tools than COPS and Crack tools were already out there, and most of the good guys didn't have anything to help. Q.7 Where can I get these tools? COPS: V1.04, available for FTP from cert.sei.cmu.edu in pub/cops and archive.cis.ohio-state.edu in pub/cops. Crack/UFC: Crack v4.1f and UFC Patchlevel 1. Available from any major USENET archive (eg: ftp.uu.net) in volume 28 of comp.sources.misc. NPasswd: Currently suffering from being hacked about by many different people. Version 2.0 is in the offing, but many versions exist in many different configurations. Will chase this up with authors - AEM Passwd+: "alpha version, update 3" - beta version due soon. Available from dartmouth.edu as pub/passwd+.tar.Z Shadow: This is available from the comp.sources.misc directory at any major USENET archive (see entry for Crack) TCP Wrappers: Available for anonymous FTP: cert.sei.cmu.edu: pub/network_tools/tcp_wrapper.shar ftp.win.tue.nl: pub/security/log_tcp.shar.Z Securelib: The latest version of securelib is available via anonymous FTP from the host "eecs.nwu.edu". It is stored in the file "pub/securelib.tar". Q.8 Why and how do systems get broken into? This is hard to answer definitively. Many systems which crackers break into are only used as a means of entry into yet more systems; by hopping between many machines before breaking into a new one, the cracker hopes to confuse any possible pursuers and put them off the scent. There is an advantage to be gained in breaking into as many different sites as possible, in order to "launder" your connections. Another reason may be psychological: some people love to play with computers and stretch them to the limits of their capabilities. Some crackers might think that it's "really neat" to hop over 6 Internet machines, 2 gateways and an X.25 network just to knock on the doors of some really famous company or institution (eg: NASA, CERN, AT+T, UCB). Think of it as inter-network sightseeing. This view is certainly appealing 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.sei.cmu.edu > 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. 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 (AEM). 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. [ I am STILL working on PC NFS packages / ethics at the moment - AEM ] 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) 100000 + 1000000 + 10000000 + 100000000 = --------- 111100000 (base 62) 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 - AEM [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: 2.99. [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 > Tel +1 301 766-8729 > >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 > order dept phone: +1-703-487-4650, fax +1-703-321-8547 >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 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. It's research.att.com:/dist/Secure_Internet_Gateway.ps [Cheswick] An Evening With Berferd: in which a Cracker is Lured, Endured and Studied. Funny and very readable, somewhat in the style of [Stoll] but more condensed. research.att.com:/dist/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. research.att.com:/dist/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.sei.cmu.edu". [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. --------------------------------------------------------------------------- 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). -- aem@aber.ac.uk aem@uk.ac.aber aem%aber@ukacrl.bitnet mcsun!uknet!aber!aem - send (cryptographic) comp.sources.misc material to: aem@aber.ac.uk -