Phrack Inc. Volume Three, Issue 29, File #1 of 12 Phrack Inc. Newsletter Issue XXIX Index

Master Index Current Directory Index Go to SkepticTank Go to Human Rights activist Keith Henson Go to Scientology cult

Skeptic Tank!

==Phrack Inc.== Volume Three, Issue 29, File #1 of 12 Phrack Inc. Newsletter Issue XXIX Index ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ November 17, 1989 Greetings and welcome to Issue 29 of Phrack Inc. For those of you who have been with us from the beginning, the date on this issue may hold some historical significance: Happy Fourth Anniversary Phrack Inc.! This issue we feature two files dealing with electronic fund transfer written by a member of the Legion of Doom who wishes to remain anonymous. The second article tells a story detailing how an actual electronic fund transfer might take place -- Is it true or is it fiction? We decided to let you, the reader, decide that for yourself. The Future Transcendent Saga continues as usual in this issue with part two of "Introduction to the Internet Protocols." We also present to you the second edition of Network Miscellany which focuses largely on Public Access Unix systems around the country. Last, but not least, concerning the wide area networks, we have Covert Paths -- a file about hacking on the Internet and how to make sure you cannot be tracked down. On a lighter note, it appears that Teleconnect Magazine liked The Mentor's "Hacker's Manifesto" so much that they decided to print a portion of it in their November 1989 issue. If you receive this magazine you will find it on page 55, but only the last 4 paragraphs (they apparently did not like the beginning of the file). The interesting thing is that Teleconnect claims that they were given the article by MCI Security who recently discovered it on a bulletin board. If you are a long time reader of Phrack Inc., you might remember that this article was dated for January 8, 1986 and originally appeared in Phrack Inc. Newsletter Issue VII (file 3 of 10) and again in issue XXIV (file 3 of 9). As always, we ask that anyone with network access drop us a line to either our Bitnet or Internet addresses... Taran King Knight Lightning C488869@UMCVMB.BITNET C483307@UMCVMB.BITNET C488869@UMCVMB.MISSOURI.EDU C483307@UMCVMB.MISSOURI.EDU And we can also be reached via our new mail forwarding addresses (for those that cannot mail to our Bitnet or Internet addresses): ...!netsys!phrack or phrack@netsys.COM _______________________________________________________________________________ Table of Contents: 1. Phrack Inc. XXIX Index by Taran King and Knight Lightning 2. Phrack Pro-Phile XXIX on Emmanuel Goldstein 3. Introduction to the Internet Protocols II: Chapter Nine of the FTS by KL 4. Network Miscellany II by Taran King 5. Covert Paths by Cyber Neuron Limited and Synthecide 6. Bank Information compiled by Legion of Doom! 7. How We Got Rich Through Electronic Fund Transfer by Legion of Doom! 8. The Myth and Reality About Eavesdropping by Phone Phanatic 9. Blocking of Long-Distance Calls... Revisited by Jim Schmickley 10-12 Phrack World News XXIX/Parts 1-3 by Knight Lightning _______________________________________________________________________________ >--------=====END=====--------< ==Phrack Inc.== Volume Three, Issue 29, File #2 of 12 ==Phrack Pro-Phile XXIX== Created and Presented by Taran King Done on November 12, 1989 Welcome to Phrack Pro-Phile XXIX. Phrack Pro-Phile was created to bring information to you, the community, about retired or highly important/ controversial people. This edition of the Phrack Pro-Phile starts a different format as I'm sure you will notice. The skeleton of the Pro-Phile is a form in which the people fill in the blanks. Starting now, using their words (and a little editing), the Pro-Phile will be presented in first person format. This month, we present to you the editor of one of the most prominent printed phreak/hack newsletters of all times... Emmanuel Goldstein ~~~~~~~~~~~~~~~~~~ Handle: Emmanuel Goldstein Call Him: Call me anything. Just look me in the eye. Past Handles: Howard Tripod, Sidney Schreiber, Bob Hardy, Gary Wilson, Clint Eastwood, 110. There are others that I keep quiet about. Handle Origin: I prefer using regular names rather than descriptive boastful titles (i.e., "The Hacker King," who, incidentally, I don't wish to offend if he/she even exists; this is just an example). The names I use are either people I've "become" or names that bestow a certain image. Emmanuel Goldstein, for instance, led the resistance in "1984." But then, there was talk that he never really existed and was just created by the government in order to capture the real subversives. I don't think that's the case with me. Computers: I use PC compatibles for the most part. I also play around with Macs but they're not REAL computers to me. My favorite machine of all time is the Zenith Z-100, a dual-processor computer that can emulate an old fashioned H8 or an IBM PC. It runs lots of operating systems and has a great keyboard. Too bad it was discontinued four years ago.... Sysop/Co-Sysop Of: The old Plovernet on Long Island (1984), Private Sector in New Jersey (1985, 1986), and the present and future 2600 boards. Origins in Phreak/Hack World ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I've been playing with phones all of my life and I started playing with computers the first time I saw one. I always seemed to get in trouble for doing things I wasn't supposed to... crashing the PDP-10 in high school... flashing the switchhook on my phone 95 times and getting an angry switchman who wouldn't release the line, claiming I broke it (I was 10). As computers and phones started to become integrated, I realized what hacking really was -- just asking a lot of questions and being really persistent. A lot of people don't like that, whether it's computers or real life, but how else are you going to learn what's REALLY happening and not just what others WANT you to know? Origins in Phreak/Hack BBSes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I don't really have a BBS reputation to speak of. They tend to disappear rather quickly and that tends to dampen my enthusiasm towards them quite a bit, but I do want to see more and more of them come up and begin to reach out and be creative. They also have to challenge the system some more. 2600 has a very strong opinion on BBS privacy, namely that the same rights afforded to any publication should be extended to a bulletin board, but every BBS owner should know the importance of this and should be willing to fight for it. If you didn't believe in preserving the First Amendment, you probably wouldn't go out and buy a newspaper, would you? A BBS is the same thing and anyone who runs a system should see this connection. Hackers tend to bring this issue to the forefront a bit more, but this is something that applies to all bulletin boards. Encounters With Phreakers and Hackers ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Meeting Captain Crunch in Amsterdam this past summer was a real trip. Finding out who Cable Pair really was certainly resulted in some highlights. I've met a lot of "famous" phreaks and hackers and now I know a lot of foreign ones, but I'm always amazed at the number of people I meet (mostly in New York) who say they've been hacking since the sixties. There's an awful lot of people out there who are into this kind of stuff, which is something I never knew before I started being open about these particular interests. Experience Gained In The Following Ways ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Social engineering, of course. I like hacking computers when I'm not feeling social because you don't have to adjust your attitude to get a reply, but people hacking is so much more satisfying. No matter how many security codes and precautions are taken, as long as one person without knowledge is able to talk to another with knowledge, it will always be possible to get things out of them. Most of the really important bits of information I've been able to get are through people, not computers. Knowledge Attributed To... ~~~~~~~~~~~~~~~~~~~~~~~~~~ Ignorance. I built up my knowledge by wandering around in places others thought unimportant. Hacking can be like trashing. It looks like garbage or a waste of time to most, but if you keep your mind open, you can learn a lot. If more people felt this way, hackers would stand out less because everyone would be a bit more adventurous, but ignorance prevails and we learn what nobody else cares about...that is until it affects them. Work/Schooling ~~~~~~~~~~~~~~ I got an English degree at Stony Brook (it's currently gathering dust in a closet). I should note that I've never taken a computer course, nor do I intend to. I've worked as a limo driver, a Good Humor man, and a typesetter, and more recently, as a freelance writer, a reporter for Pacifica Radio, and a radio engineer/producer and talk show host. Busted For... ~~~~~~~~~~~~~ I used to make free phone calls all the time. Now, obviously, I can't do that, since I'm in the public eye, but that's not a drawback to me because I can still experiment all I want. Nothing can change that. For the most part I was careful while I was doing these things, but there was one time when my luck ran out. I had been using Telemail to communicate with some other people and they, unknown to us, had been looking for hackers on their system. They found us, the members of PHALSE (Phreakers, Hackers, and Laundromat Service Employees [I'm told the feds spent a lot of time investigating the laundry connection, even though we only used it to spell out the word PHALSE!]). I believe four people got indicted in that adventure. I was one of them. Bill Landreth was another. They thought I was the ringleader so they gave me a 10 count indictment, more than twice what anyone else got. Without hiring an expensive lawyer, I talked to a roomful of feds about the system and what was wrong with it. I made it clear that I wasn't turning anybody in -- even if I wanted to I still didn't know who or where they were. I think I was dealt with fairly. I told them what I did and paid for the time I used. Nothing more. That was in 1984 when 2600 was just getting off the ground. A couple of years ago, one of the feds who had questioned me tried to get me to work for them. Not to entrap hackers, but Soviet spies. And so it goes. Interests ~~~~~~~~~ I guess I'm an explorer because everything I like doing involves exploration of some sort. Obviously, hacking contains a good amount of that. I like traveling quite a bit, particularly when I'm free to do whatever the hell I want. Traveling with people is fun but it can also be a drag because something you want to do puts them off and then you either wind up not doing it or doing it and pissing them off. I like to ride subways to weird places and walk through bad neighborhoods. It's all a part of exploring and seeing the world through different eyes. A couple of years ago I went to Baffin Island and hung out for a week with Eskimos. Everyone thought I was crazy but I had a great time. I'm also into astronomy, but not the classroom kind. I took a course in astronomy once and it was the biggest mistake of my life. All we did was talk about equations. I like to look at the sky and read about what's being discovered up there. When the space telescope goes up next year, interest in space will rise again. Then there's free-lance writing, which I have to devote more time to. I'm working on a couple of plays, some short stories, a screenplay for a movie, and a screenplay for TV. I'll probably focus on the plays only because there's so much bullshit involved in TV and movies. And finally, there's radio. I've been in radio for just over 10 years, doing whatever comes to mind on WUSB-FM in Stony Brook, NY, a small, noncommercial radio station at the State University. Now I also work at WBAI-FM, a much larger station in New York City with the same kind of free-form attitude. There's so much you can do with radio, but so few stations want to take a chance any more. That's why they all sound the same. Unfortunately, when you sell commercials, you also sell your freedom. I've seen it enough times to know it's true and that's the reason I've stayed out of commercial radio. Right now I do a weekly talk show on WUSB called "Brain Damage" where I take calls, play with the phones, and air tapes from Radio Moscow. On WBAI I'm doing two shows: "News of the World" which is a compilation of foreign news reports and "Off The Hook," a program about, you guessed it, phone phreaks. Favorite Things ~~~~~~~~~~~~~~~ I like hanging out with fun people who are open-minded, non-judgmental, and preferably insane to a degree. I enjoy talking on the phone with friends and strangers alike. Strangers are different because you can be whoever you want to be with them. They tend to believe almost anything you say. Music is really important. Right now I like rappers and toasters the most, with soca and hardcore close behind. Ska's real good too, but there's not much coming out. The record I put on when I wake up sets my mood for the day. I like music with lyrics that mean something. There's a time and a place for mindless droning but there's too much of it around. Music should have meaning. In Jamaica, people don't buy newspapers. They buy records and that's how they learn what's going on and what the latest catch phrases are. Some of my favorite rock bands include The Clash, Big Audio Dynamite, Dead Kennedys, Donner Party, Public Enemy, Camper Van Beethoven, Pink Floyd, Fun Boy Three, De La Soul, and Anti-Nowhere League. Some of my favorite solo artists are Tracy Chapman, John Lennon, Elvis Costello, and Patsy Cline. I realize I'm very lucky because I work in an environment (noncommercial radio station) that gets over 100 new albums a week. I don't know how I would have ever found some of the stuff I like if I didn't have that kind of access. Inside Jokes ~~~~~~~~~~~~ "OK, if we can't have a tour, can we at least have a look around?" "I'm not allowed to talk to you any more." "This is the Sprint operator. I have a collect call from AT&T." "There aren't any more supervisors, sir. You've spoken to all of them." "Iran, will you hang up! Sir, do you speak what he speaks?" "I said, DON'T hit return!" "But we didn't know it was the foreign minister!" "Repair serv-- damn! There it goes again. What the hell's wrong with these phones?" "Just tell me how much money you lost and I'll arrange for a trial date." Serious Section ~~~~~~~~~~~~~~~ Being a part of the hack/phreak community, you get to experience unique little adventures that the "average" person has no conception of. We talk to people over the phone and have no idea what they look like, often no idea what they even sound like (BBSes). We play with technology and are thought of as geniuses merely because the rest of the world doesn't understand what we're doing. I think that goes to our heads sometimes, which is bad for everyone. We should apply our knowledge and skills not only to help ourselves by getting a high-paying job somewhere but to help others as well. Look what happened in China. Using FAX machines, modems, and redial functions, people forced information into the country and tied up the government's snitch lines which probably saved a few lives. The "average" person would never think of applying technology in this way, but we do and we know how to do it efficiently, quickly, and without spending money. It's because of that last one that we've got freedom. Most people don't do things because of the cost. Without having to worry about that, you can be a lot more imaginative. Of course, that also makes it illegal, which is enough to stifle some of us. What we do and how we do it is a decision we each have to make, but we should stop wasting time boasting and get on with the exploring and the learning and the new applications. Another thing that really gets me is the person who says, "hacking and phreaking isn't what it used to be." First off, if nothing changes, life gets pretty dull. Second, that statement is usually a precursor to something like, "what kids do today isn't real hacking. What I did 5, 10, 20 years ago was REAL hacking." Generalizations like that are worthless. It's just like yuppies going on about the Beatles, calling that real music, and saying the sounds of today are crap (by the way, I like the Beatles a lot). At the same time, too many hackers are just starting out and thinking they know it all, dismissing everything that happened before they were around. The spirit of today's hacker is often the same as that of a phone phreak of the sixties. And there were people like us around 100 years ago but we're even more far removed from what they could have possibly been doing. The point is that there's a bond that ties a lot of us together -- it cuts through time and backgrounds. Like anything else, there's too much hypocrisy and judging going on in the hack/phreak world. I think it's a real waste of time. Are Phreaks/Hackers You've Met Generally Computer Geeks? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Not in the least. Those people that I've come to know have turned out to be just about everything you can imagine. White/Black, Jew/Gentile, straight/gay, male/female, opened/closed, you name it. Everyone's got different sides to them, stuff they don't always want others to know. Sometimes we try to squash those other sides of us, but they still exist. I've met hackers who have geekish qualities but once you get to know them, you realize there's more to them. Of course, there are lots of hackers I would never want to know in a million years; that's just the way I am with a lot of people. I think it was Linus Van Pelt who said, "I love mankind. It's people I can't stand." >--------=====END=====--------< ==Phrack Inc.== Volume Three, Issue 29, File #3 of 12 <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> <> <> <> Introduction to the Internet Protocols <> <> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ <> <> Chapter Nine Of The Future Transcendent Saga <> <> <> <> Part Two of Two Files <> <> <> <> Presented by Knight Lightning <> <> September 27, 1989 <> <> <> <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> Prologue - Part Two ~~~~~~~~ A great deal of the material in this file comes from "Introduction to the Internet Protocols" by Charles L. Hedrick of Rutgers University. That material is copyrighted and is used in this file by permission. Time differention and changes in the wide area networks have made it neccessary for some details of the file to updated and in some cases reworded for better understanding by our readers. Also, Unix is a trademark of AT&T Technologies, Inc. -- Again, just thought I'd let you know. Table of Contents - Part Two ~~~~~~~~~~~~~~~~~ * Introduction - Part Two * Well Known Sockets And The Applications Layer * Protocols Other Than TCP: UDP and ICMP * Keeping Track Of Names And Information: The Domain System * Routing * Details About The Internet Addresses: Subnets And Broadcasting * Datagram Fragmentation And Reassembly * Ethernet Encapsulation: ARP * Getting More Information Introduction - Part Two ~~~~~~~~~~~~ This article is a brief introduction to TCP/IP, followed by suggestions on what to read for more information. This is not intended to be a complete description, but it can give you a reasonable idea of the capabilities of the protocols. However, if you need to know any details of the technology, you will want to read the standards yourself. Throughout this file, you will find references to the standards, in the form of "RFC" (Request For Comments) or "IEN" (Internet Engineering Notes) numbers -- these are document numbers. The final section (Getting More Information) explains how you can get copies of those standards. Well-Known Sockets And The Applications Layer ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In part one of this series, I described how a stream of data is broken up into datagrams, sent to another computer, and put back together. However something more is needed in order to accomplish anything useful. There has to be a way for you to open a connection to a specified computer, log into it, tell it what file you want, and control the transmission of the file. (If you have a different application in mind, e.g. computer mail, some analogous protocol is needed.) This is done by "application protocols." The application protocols run "on top" of TCP/IP. That is, when they want to send a message, they give the message to TCP. TCP makes sure it gets delivered to the other end. Because TCP and IP take care of all the networking details, the applications protocols can treat a network connection as if it were a simple byte stream, like a terminal or phone line. Before going into more details about applications programs, we have to describe how you find an application. Suppose you want to send a file to a computer whose Internet address is To start the process, you need more than just the Internet address. You have to connect to the FTP server at the other end. In general, network programs are specialized for a specific set of tasks. Most systems have separate programs to handle file transfers, remote terminal logins, mail, etc. When you connect to, you have to specify that you want to talk to the FTP server. This is done by having "well-known sockets" for each server. Recall that TCP uses port numbers to keep track of individual conversations. User programs normally use more or less random port numbers. However specific port numbers are assigned to the programs that sit waiting for requests. For example, if you want to send a file, you will start a program called "ftp." It will open a connection using some random number, say 1234, for the port number on its end. However it will specify port number 21 for the other end. This is the official port number for the FTP server. Note that there are two different programs involved. You run ftp on your side. This is a program designed to accept commands from your terminal and pass them on to the other end. The program that you talk to on the other machine is the FTP server. It is designed to accept commands from the network connection, rather than an interactive terminal. There is no need for your program to use a well-known socket number for itself. Nobody is trying to find it. However the servers have to have well-known numbers, so that people can open connections to them and start sending them commands. The official port numbers for each program are given in "Assigned Numbers." Note that a connection is actually described by a set of 4 numbers: The Internet address at each end, and the TCP port number at each end. Every datagram has all four of those numbers in it. (The Internet addresses are in the IP header, and the TCP port numbers are in the TCP header.) In order to keep things straight, no two connections can have the same set of numbers. However it is enough for any one number to be different. For example, it is perfectly possible for two different users on a machine to be sending files to the same other machine. This could result in connections with the following parameters: Internet addresses TCP ports connection 1, 1234, 21 connection 2, 1235, 21 Since the same machines are involved, the Internet addresses are the same. Since they are both doing file transfers, one end of the connection involves the well-known port number for FTP. The only thing that differs is the port number for the program that the users are running. That's enough of a difference. Generally, at least one end of the connection asks the network software to assign it a port number that is guaranteed to be unique. Normally, it's the user's end, since the server has to use a well-known number. Now that we know how to open connections, let's get back to the applications programs. As mentioned earlier, once TCP has opened a connection, we have something that might as well be a simple wire. All the hard parts are handled by TCP and IP. However we still need some agreement as to what we send over this connection. In effect this is simply an agreement on what set of commands the application will understand, and the format in which they are to be sent. Generally, what is sent is a combination of commands and data. They use context to differentiate. For example, the mail protocol works like this: Your mail program opens a connection to the mail server at the other end. Your program gives it your machine's name, the sender of the message, and the recipients you want it sent to. It then sends a command saying that it is starting the message. At that point, the other end stops treating what it sees as commands, and starts accepting the message. Your end then starts sending the text of the message. At the end of the message, a special mark is sent (a dot in the first column). After that, both ends understand that your program is again sending commands. This is the simplest way to do things, and the one that most applications use. File transfer is somewhat more complex. The file transfer protocol involves two different connections. It starts out just like mail. The user's program sends commands like "log me in as this user," "here is my password," "send me the file with this name." However once the command to send data is sent, a second connection is opened for the data itself. It would certainly be possible to send the data on the same connection, as mail does. However file transfers often take a long time. The designers of the file transfer protocol wanted to allow the user to continue issuing commands while the transfer is going on. For example, the user might make an inquiry, or he might abort the transfer. Thus the designers felt it was best to use a separate connection for the data and leave the original command connection for commands. (It is also possible to open command connections to two different computers, and tell them to send a file from one to the other. In that case, the data couldn't go over the command connection.) Remote terminal connections use another mechanism still. For remote logins, there is just one connection. It normally sends data. When it is necessary to send a command (e.g. to set the terminal type or to change some mode), a special character is used to indicate that the next character is a command. If the user happens to type that special character as data, two of them are sent. I am not going to describe the application protocols in detail in this file. It is better to read the RFCs yourself. However there are a couple of common conventions used by applications that will be described here. First, the common network representation: TCP/IP is intended to be usable on any computer. Unfortunately, not all computers agree on how data is represented. There are differences in character codes (ASCII vs. EBCDIC), in end of line conventions (carriage return, line feed, or a representation using counts), and in whether terminals expect characters to be sent individually or a line at a time. In order to allow computers of different kinds to communicate, each applications protocol defines a standard representation. Note that TCP and IP do not care about the representation. TCP simply sends octets. However the programs at both ends have to agree on how the octets are to be interpreted. The RFC for each application specifies the standard representation for that application. Normally it is "net ASCII." This uses ASCII characters, with end of line denoted by a carriage return followed by a line feed. For remote login, there is also a definition of a "standard terminal," which turns out to be a half-duplex terminal with echoing happening on the local machine. Most applications also make provisions for the two computers to agree on other representations that they may find more convenient. For example, PDP-10's have 36-bit words. There is a way that two PDP-10's can agree to send a 36-bit binary file. Similarly, two systems that prefer full-duplex terminal conversations can agree on that. However each application has a standard representation, which every machine must support. So that you might get a better idea of what is involved in the application protocols, here is an imaginary example of SMTP (the simple mail transfer protocol.) Assume that a computer called FTS.PHRACK.EDU wants to send the following message. Date: Fri, 17 Nov 89 15:42:06 EDT From: To: Subject: Anniversary Four years is quite a long time to be around. Happy Anniversary! Note that the format of the message itself is described by an Internet standard (RFC 822). The standard specifies the fact that the message must be transmitted as net ASCII (i.e. it must be ASCII, with carriage return/linefeed to delimit lines). It also describes the general structure, as a group of header lines, then a blank line, and then the body of the message. Finally, it describes the syntax of the header lines in detail. Generally they consist of a keyword and then a value. Note that the addressee is indicated as TARAN@MSP.PHRACK.EDU. Initially, addresses were simply "person at machine." Today's standards are much more flexible. There are now provisions for systems to handle other systems' mail. This can allow automatic forwarding on behalf of computers not connected to the Internet. It can be used to direct mail for a number of systems to one central mail server. Indeed there is no requirement that an actual computer by the name of FTS.PHRACK.EDU even exist (and it doesn't). The name servers could be set up so that you mail to department names, and each department's mail is routed automatically to an appropriate computer. It is also possible that the part before the @ is something other than a user name. It is possible for programs to be set up to process mail. There are also provisions to handle mailing lists, and generic names such as "postmaster" or "operator." The way the message is to be sent to another system is described by RFCs 821 and 974. The program that is going to be doing the sending asks the name server several queries to determine where to route the message. The first query is to find out which machines handle mail for the name FTS.PHRACK.EDU. In this case, the server replies that FTS.PHRACK.EDU handles its own mail. The program then asks for the address of FTS.PHRACK.EDU, which for the sake of this example is is 269.517.724.5. Then the the mail program opens a TCP connection to port 25 on 269.517.724.5. Port 25 is the well-known socket used for receiving mail. Once this connection is established, the mail program starts sending commands. Here is a typical conversation. Each line is labelled as to whether it is from FTS or MSP. Note that FTS initiated the connection: MSP 220 MSP.PHRACK.EDU SMTP Service at 17 Nov 89 09:35:24 EDT FTS HELO MSP 250 MSP.PHRACK.EDU - Hello, FTS.PHRACK.EDU FTS MAIL From: MSP 250 MAIL accepted FTS RCPT To: MSP 250 Recipient accepted FTS DATA MSP 354 Start mail input; end with . FTS Date: Fri, 17 Nov 89 15:42:06 EDT FTS From: FTS To: FTS Subject: Anniversary FTS FTS Four years is quite a long time to be around. Happy Anniversary! FTS . MSP 250 OK FTS QUIT MSP 221 MSP.PHRACK.EDU Service closing transmission channel The commands all use normal text. This is typical of the Internet standards. Many of the protocols use standard ASCII commands. This makes it easy to watch what is going on and to diagnose problems. The mail program keeps a log of each conversation so if something goes wrong, the log file can simply be mailed to the postmaster. Since it is normal text, he can see what was going on. It also allows a human to interact directly with the mail server, for testing. The responses all begin with numbers. This is also typical of Internet protocols. The allowable responses are defined in the protocol. The numbers allow the user program to respond unambiguously. The rest of the response is text, which is normally for use by any human who may be watching or looking at a log. It has no effect on the operation of the programs. The commands themselves simply allow the mail program on one end to tell the mail server the information it needs to know in order to deliver the message. In this case, the mail server could get the information by looking at the message itself. Every session must begin with a HELO, which gives the name of the system that initiated the connection. Then the sender and recipients are specified. There can be more than one RCPT command, if there are several recipients. Finally the data itself is sent. Note that the text of the message is terminated by a line containing just a period, but if such a line appears in the message, the period is doubled. After the message is accepted, the sender can send another message, or terminate the session as in the example above. Generally, there is a pattern to the response numbers. The protocol defines the specific set of responses that can be sent as answers to any given command. However programs that don't want to analyze them in detail can just look at the first digit. In general, responses that begin with a 2 indicate success. Those that begin with 3 indicate that some further action is needed, as shown above. 4 and 5 indicate errors. 4 is a "temporary" error, such as a disk filling. The message should be saved, and tried again later. 5 is a permanent error, such as a non-existent recipient. The message should be returned to the sender with an error message. For more details about the protocols mentioned in this section, see RFCs 821/822 for mail, RFC 959 for file transfer, and RFCs 854/855 for remote logins. For the well-known port numbers, see the current edition of Assigned Numbers, and possibly RFC 814. Protocols Other Than TCP: UDP and ICMP ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Thus far only connections that use TCP have been described. Remember that TCP is responsible for breaking up messages into datagrams, and reassembling them properly. However in many applications, there are messages that will always fit in a single datagram. An example is name lookup. When a user attempts to make a connection to another system, he will generally specify the system by name, rather than Internet address. His system has to translate that name to an address before it can do anything. Generally, only a few systems have the database used to translate names to addresses. So the user's system will want to send a query to one of the systems that has the database. This query is going to be very short. It will certainly fit in one datagram. So will the answer. Thus it seems silly to use TCP. Of course TCP does more than just break things up into datagrams. It also makes sure that the data arrives, resending datagrams where necessary. But for a question that fits in a single datagram, all of the complexity of TCP is not needed. If there is not an answer after a few seconds, you can just ask again. For applications like this, there are alternatives to TCP. The most common alternative is UDP ("user datagram protocol"). UDP is designed for applications where you don't need to put sequences of datagrams together. It fits into the system much like TCP. There is a UDP header. The network software puts the UDP header on the front of your data, just as it would put a TCP header on the front of your data. Then UDP sends the data to IP, which adds the IP header, putting UDP's protocol number in the protocol field instead of TCP's protocol number. UDP doesn't do as much as TCP does. It does not split data into multiple datagrams and it does not keep track of what it has sent so it can resend if necessary. About all that UDP provides is port numbers so that several programs can use UDP at once. UDP port numbers are used just like TCP port numbers. There are well-known port numbers for servers that use UDP. The UDP header is shorter than a TCP header. It still has source and destination port numbers, and a checksum, but that's about it. UDP is used by the protocols that handle name lookups (see IEN 116, RFC 882, and RFC 883) and a number of similar protocols. Another alternative protocol is ICMP ("Internet control message protocol"). ICMP is used for error messages, and other messages intended for the TCP/IP software itself, rather than any particular user program. For example, if you attempt to connect to a host, your system may get back an ICMP message saying "host unreachable." ICMP can also be used to find out some information about the network. See RFC 792 for details of ICMP. ICMP is similar to UDP, in that it handles messages that fit in one datagram. However it is even simpler than UDP. It does not even have port numbers in its header. Since all ICMP messages are interpreted by the network software itself, no port numbers are needed to say where an ICMP message is supposed to go. Keeping Track Of Names And Information: The Domain System ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ As we indicated earlier, the network software generally needs a 32-bit Internet address in order to open a connection or send a datagram. However users prefer to deal with computer names rather than numbers. Thus there is a database that allows the software to look up a name and find the corresponding number. When the Internet was small, this was easy. Each system would have a file that listed all of the other systems, giving both their name and number. There are now too many computers for this approach to be practical. Thus these files have been replaced by a set of name servers that keep track of host names and the corresponding Internet addresses. (In fact these servers are somewhat more general than that. This is just one kind of information stored in the domain system.) A set of interlocking servers are used rather than a single central one. There are now so many different institutions connected to the Internet that it would be impractical for them to notify a central authority whenever they installed or moved a computer. Thus naming authority is delegated to individual institutions. The name servers form a tree, corresponding to institutional structure. The names themselves follow a similar structure. A typical example is the name BORAX.LCS.MIT.EDU. This is a computer at the Laboratory for Computer Science (LCS) at MIT. In order to find its Internet address, you might potentially have to consult 4 different servers. First, you would ask a central server (called the root) where the EDU server is. EDU is a server that keeps track of educational institutions. The root server would give you the names and Internet addresses of several servers for EDU. You would then ask EDU where the server for MIT is. It would give you names and Internet addresses of several servers for MIT. Then you would ask MIT where the server for LCS is, and finally you would ask one of the LCS servers about BORAX. The final result would be the Internet address for BORAX.LCS.MIT.EDU. Each of these levels is referred to as a "domain." The entire name, BORAX.LCS.MIT.EDU, is called a "domain name." (So are the names of the higher-level domains, such as LCS.MIT.EDU, MIT.EDU, and EDU.) Fortunately, you don't really have to go through all of this most of the time. First of all, the root name servers also happen to be the name servers for the top-level domains such as EDU. Thus a single query to a root server will get you to MIT. Second, software generally remembers answers that it got before. So once we look up a name at LCS.MIT.EDU, our software remembers where to find servers for LCS.MIT.EDU, MIT.EDU, and EDU. It also remembers the translation of BORAX.LCS.MIT.EDU. Each of these pieces of information has a "time to live" associated with it. Typically this is a few days. After that, the information expires and has to be looked up again. This allows institutions to change things. The domain system is not limited to finding out Internet addresses. Each domain name is a node in a database. The node can have records that define a number of different properties. Examples are Internet address, computer type, and a list of services provided by a computer. A program can ask for a specific piece of information, or all information about a given name. It is possible for a node in the database to be marked as an "alias" (or nickname) for another node. It is also possible to use the domain system to store information about users, mailing lists, or other objects. There is an Internet standard defining the operation of these databases as well as the protocols used to make queries of them. Every network utility has to be able to make such queries since this is now the official way to evaluate host names. Generally utilities will talk to a server on their own system. This server will take care of contacting the other servers for them. This keeps down the amount of code that has to be in each application program. The domain system is particularly important for handling computer mail. There are entry types to define what computer handles mail for a given name to specify where an individual is to receive mail and to define mailing lists. See RFCs 882, 883, and 973 for specifications of the domain system. RFC 974 defines the use of the domain system in sending mail. Routing ~~~~~~~ The task of finding how to get a datagram to its destination is referred to as "routing." Many of the details depend upon the particular implementation. However some general things can be said. It is necessary to understand the model on which IP is based. IP assumes that a system is attached to some local network. It is assumed that the system can send datagrams to any other system on its own network. (In the case of Ethernet, it simply finds the Ethernet address of the destination system, and puts the datagram out on the Ethernet.) The problem comes when a system is asked to send a datagram to a system on a different network. This problem is handled by gateways. A gateway is a system that connects a network with one or more other networks. Gateways are often normal computers that happen to have more than one network interface. The software on a machine must be set up so that it will forward datagrams from one network to the other. That is, if a machine on network 128.6.4 sends a datagram to the gateway, and the datagram is addressed to a machine on network 128.6.3, the gateway will forward the datagram to the destination. Major communications centers often have gateways that connect a number of different networks. Routing in IP is based entirely upon the network number of the destination address. Each computer has a table of network numbers. For each network number, a gateway is listed. This is the gateway to be used to get to that network. The gateway does not have to connect directly to the network, it just has to be the best place to go to get there. When a computer wants to send a datagram, it first checks to see if the destination address is on the system's own local network. If so, the datagram can be sent directly. Otherwise, the system expects to find an entry for the network that the destination address is on. The datagram is sent to the gateway listed in that entry. This table can get quite big. For example, the Internet now includes several hundred individual networks. Thus various strategies have been developed to reduce the size of the routing table. One strategy is to depend upon "default routes." There is often only one gateway out of a network. This gateway might connect a local Ethernet to a campus-wide backbone network. In that case, it is not neccessary to have a separate entry for every network in the world. That gateway is simply defined as a "default." When no specific route is found for a datagram, the datagram is sent to the default gateway. A default gateway can even be used when there are several gateways on a network. There are provisions for gateways to send a message saying "I'm not the best gateway -- use this one instead." (The message is sent via ICMP. See RFC 792.) Most network software is designed to use these messages to add entries to their routing tables. Suppose network 128.6.4 has two gateways, and leads to several other internal Rutgers networks. leads indirectly to the NSFnet. Suppose is set as a default gateway, and there are no other routing table entries. Now what happens when you need to send a datagram to MIT? MIT is network 18. Since there is no entry for network 18, the datagram will be sent to the default, This gateway is the wrong one. So it will forward the datagram to It will also send back an error saying in effect: "to get to network 18, use" The software will then add an entry to the routing table. Any future datagrams to MIT will then go directly to (The error message is sent using the ICMP protocol. The message type is called "ICMP redirect.") Most IP experts recommend that individual computers should not try to keep track of the entire network. Instead, they should start with default gateways and let the gateways tell them the routes as just described. However this doesn't say how the gateways should find out about the routes. The gateways can't depend upon this strategy. They have to have fairly complete routing tables. For this, some sort of routing protocol is needed. A routing protocol is simply a technique for the gateways to find each other and keep up to date about the best way to get to every network. RFC 1009 contains a review of gateway design and routing. Details About Internet Addresses: Subnets And Broadcasting ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Internet addresses are 32-bit numbers, normally written as 4 octets (in decimal), e.g. There are actually 3 different types of address. The problem is that the address has to indicate both the network and the host within the network. It was felt that eventually there would be lots of networks. Many of them would be small, but probably 24 bits would be needed to represent all the IP networks. It was also felt that some very big networks might need 24 bits to represent all of their hosts. This would seem to lead to 48 bit addresses. But the designers really wanted to use 32 bit addresses. So they adopted a kludge. The assumption is that most of the networks will be small. So they set up three different ranges of address. Addresses beginning with 1 to 126 use only the first octet for the network number. The other three octets are available for the host number. Thus 24 bits are available for hosts. These numbers are used for large networks, but there can only be 126 of these. The ARPAnet is one and there are a few large commercial networks. But few normal organizations get one of these "class A" addresses. For normal large organizations, "class B" addresses are used. Class B addresses use the first two octets for the network number. Thus network numbers are 128.1 through 191.254. (0 and 255 are avoided for reasons to be explained below. Addresses beginning with 127 are also avoided because they are used by some systems for special purposes.) The last two octets are available for host addesses, giving 16 bits of host address. This allows for 64516 computers, which should be enough for most organizations. Finally, class C addresses use three octets in the range 192.1.1 to 223.254.254. These allow only 254 hosts on each network, but there can be lots of these networks. Addresses above 223 are reserved for future use as class D and E (which are currently not defined). 0 and 255 have special meanings. 0 is reserved for machines that do not know their address. In certain circumstances it is possible for a machine not to know the number of the network it is on, or even its own host address. For example, would be a machine that knew it was host number 23, but didn't know on what network. 255 is used for "broadcast." A broadcast is a message that you want every system on the network to see. Broadcasts are used in some situations where you don't know who to talk to. For example, suppose you need to look up a host name and get its Internet address. Sometimes you don't know the address of the nearest name server. In that case, you might send the request as a broadcast. There are also cases where a number of systems are interested in information. It is then less expensive to send a single broadcast than to send datagrams individually to each host that is interested in the information. In order to send a broadcast, you use an address that is made by using your network address, with all ones in the part of the address where the host number goes. For example, if you are on network 128.6.4, you would use for broadcasts. How this is actually implemented depends upon the medium. It is not possible to send broadcasts on the ARPAnet, or on point to point lines, but it is possible on an Ethernet. If you use an Ethernet address with all its bits on (all ones), every machine on the Ethernet is supposed to look at that datagram. Because 0 and 255 are used for unknown and broadcast addresses, normal hosts should never be given addresses containing 0 or 255. Addresses should never begin with 0, 127, or any number above 223. Datagram Fragmentation And Reassembly ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ TCP/IP is designed for use with many different kinds of networks. Unfortunately, network designers do not agree about how big packets can be. Ethernet packets can be 1500 octets long. ARPAnet packets have a maximum of around 1000 octets. Some very fast networks have much larger packet sizes. You might think that IP should simply settle on the smallest possible size, but this would cause serious performance problems. When transferring large files, big packets are far more efficient than small ones. So it is best to be able to use the largest packet size possible, but it is also necessary to be able to handle networks with small limits. There are two provisions for this. TCP has the ability to "negotiate" about datagram size. When a TCP connection first opens, both ends can send the maximum datagram size they can handle. The smaller of these numbers is used for the rest of the connection. This allows two implementations that can handle big datagrams to use them, but also lets them talk to implementations that cannot handle them. This does not completely solve the problem. The most serious problem is that the two ends do not necessarily know about all of the steps in between. For this reason, there are provisions to split datagrams up into pieces. This is referred to as "fragmentation." The IP header contains fields indicating that a datagram has been split and enough information to let the pieces be put back together. If a gateway connects an Ethernet to the Arpanet, it must be prepared to take 1500-octet Ethernet packets and split them into pieces that will fit on the Arpanet. Furthermore, every host implementation of TCP/IP must be prepared to accept pieces and put them back together. This is referred to as "reassembly." TCP/IP implementations differ in the approach they take to deciding on datagram size. It is fairly common for implementations to use 576-byte datagrams whenever they can't verify that the entire path is able to handle larger packets. This rather conservative strategy is used because of the number of implementations with bugs in the code to reassemble fragments. Implementors often try to avoid ever having fragmentation occur. Different implementors take different approaches to deciding when it is safe to use large datagrams. Some use them only for the local network. Others will use them for any network on the same campus. 576 bytes is a "safe" size which every implementation must support. Ethernet Encapsulation: ARP ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In Part One of Introduction to the Internet Protocols (Phrack Inc., Volume Three, Issue 28, File #3 of 12) there was a brief description about what IP datagrams look like on an Ethernet. The discription showed the Ethernet header and checksum, but it left one hole: It did not say how to figure out what Ethernet address to use when you want to talk to a given Internet address. There is a separate protocol for this called ARP ("address resolution protocol") and it is not an IP protocal as ARP datagrams do not have IP headers. Suppose you are on system and you want to connect to system Your system will first verify that is on the same network, so it can talk directly via Ethernet. Then it will look up in its ARP table to see if it already knows the Ethernet address. If so, it will stick on an Ethernet header and send the packet. Now suppose this system is not in the ARP table. There is no way to send the packet because you need the Ethernet address. So it uses the ARP protocol to send an ARP request. Essentially an ARP request says "I need the Ethernet address for". Every system listens to ARP requests. When a system sees an ARP request for itself, it is required to respond. So will see the request and will respond with an ARP reply saying in effect " is 8:0:20:1:56:34". Your system will save this information in its ARP table so future packets will go directly. ARP requests must be sent as "broadcasts." There is no way that an ARP request can be sent directly to the right system because the whole reason for sending an ARP request is that you do not know the Ethernet address. So an Ethernet address of all ones is used, i.e. ff:ff:ff:ff:ff:ff. By convention, every machine on the Ethernet is required to pay attention to packets with this as an address. So every system sees every ARP requests. They all look to see whether the request is for their own address. If so, they respond. If not, they could just ignore it, although some hosts will use ARP requests to update their knowledge about other hosts on the network, even if the request is not for them. Packets whose IP address indicates broadcast (e.g. or are also sent with an Ethernet address that is all ones. Getting More Information ~~~~~~~~~~~~~~~~~~~~~~~~ This directory contains documents describing the major protocols. There are hundreds of documents, so I have chosen the ones that seem most important. Internet standards are called RFCs (Request for Comments). A proposed standard is initially issued as a proposal, and given an RFC number. When it is finally accepted, it is added to Official Internet Protocols, but it is still referred to by the RFC number. I have also included two IENs (Internet Engineering Notes). IENs used to be a separate classification for more informal documents, but this classification no longer exists and RFCs are now used for all official Internet documents with a mailing list being used for more informal reports. The convention is that whenever an RFC is revised, the revised version gets a new number. This is fine for most purposes, but it causes problems with two documents: Assigned Numbers and Official Internet Protocols. These documents are being revised all the time and the RFC number keeps changing. You will have to look in rfc-index.txt to find the number of the latest edition. Anyone who is seriously interested in TCP/IP should read the RFC describing IP (791). RFC 1009 is also useful as it is a specification for gateways to be used by NSFnet and it contains an overview of a lot of the TCP/IP technology. Here is a list of the documents you might want: rfc-index List of all RFCs rfc1012 Somewhat fuller list of all RFCs rfc1011 Official Protocols. It's useful to scan this to see what tasks protocols have been built for. This defines which RFCs are actual standards, as opposed to requests for comments. rfc1010 Assigned Numbers. If you are working with TCP/IP, you will probably want a hardcopy of this as a reference. It lists all the offically defined well-known ports and lots of other things. rfc1009 NSFnet gateway specifications. A good overview of IP routing and gateway technology. rfc1001/2 NetBIOS: Networking for PCs rfc973 Update on domains rfc959 FTP (file transfer) rfc950 Subnets rfc937 POP2: Protocol for reading mail on PCs rfc894 How IP is to be put on Ethernet, see also rfc825 rfc882/3 Domains (the database used to go from host names to Internet address and back -- also used to handle UUCP these days). See also rfc973 rfc854/5 Telnet - Protocol for remote logins rfc826 ARP - Protocol for finding out Ethernet addresses rfc821/2 Mail rfc814 Names and ports - General concepts behind well-known ports rfc793 TCP rfc792 ICMP rfc791 IP rfc768 UDP rip.doc Details of the most commonly-used routing protocol ien-116 Old name server (still needed by several kinds of systems) ien-48 The Catenet model, general description of the philosophy behind TCP/IP The following documents are somewhat more specialized. rfc813 Window and acknowledgement strategies in TCP rfc815 Datagram reassembly techniques rfc816 Fault isolation and resolution techniques rfc817 Modularity and efficiency in implementation rfc879 The maximum segment size option in TCP rfc896 Congestion control rfc827,888,904,975,985 EGP and related issues The most important RFCs have been collected into a three-volume set, the DDN Protocol Handbook. It is available from the DDN Network Information Center at SRI International. You should be able to get them via anonymous FTP from SRI-NIC.ARPA. The file names are: RFCs: rfc:rfc-index.txt rfc:rfcxxx.txt IENs: ien:ien-index.txt ien:ien-xxx.txt Sites with access to UUCP, but not FTP may be able to retreive them via UUCP from UUCP host rutgers. The file names would be RFCs: /topaz/pub/pub/tcp-ip-docs/rfc-index.txt /topaz/pub/pub/tcp-ip-docs/rfcxxx.txt IENs: /topaz/pub/pub/tcp-ip-docs/ien-index.txt /topaz/pub/pub/tcp-ip-docs/ien-xxx.txt >--------=====END=====--------< ==Phrack Inc.== Volume Three, Issue 29, File #4 of 12 Network Miscellany II ~~~~~~~~~~~~~~~~~~~~~ by Taran King November 17, 1989 BROADCASTING NETWORKS ~~~~~~~~~~~~~~~~~~~~~ Although these articles discuss things about communicating through computer networks, there are ways to contact broadcasting networks via the nets. The Public Broadcasting Service (PBS) has their own UUCP node: Public Broadcasting Service (PBS) UUCP Node name: pbs Node contact: pbs!postmaster (Senton R. Droppers) Telephone number: (703) 739-5089 There are also a number of radio stations that can be contacted via Fidonet: KFCF Fresno, CA Contact: KKSF San Fransisco, CA Contact: KKDA Dallas, TX Contact: ECNCDC (BITNET) ~~~~~~~~~~~~~~~ Western Illinois University, Eastern Illinois University as well as the University of Northeastern Illinois, Chicago State University and Governors State University are part of the Educational Computing Network. The Educational Computing Network is a service of the Board of Governors of State Colleges and Universities operating as a cooperative to supply mainframe academic computing resources to each of its members (ECN is strictly for academic use and does no administrative computing). The cooperative effort of the members of the Educational Computing Network allows for more academic computing resources to be made available to the members than they could supply on their own. Each member institution of the Educational Computing Network has a unique letter for the first letter in all their user names. The letters are: Chicago State University - B Eastern Illinois University - C Governors State University - G Western Illinois University - M University of Northeastern Illinois - U Each member of ECN also has a person which is the interface between ECN and the university called their User Coordinator. The User Coordinator's username consists of their school letter followed by UCM000 (the User Coordinator for WIU is MUCM000). For more information about the Educational Computing Network, contact XJJGUDE@ECNCDC.BITNET MCI MAIL ~~~~~~~~ If you read the first Network Miscellany article which appeared in Phrack 28, you may remember my mentioning CMR, the Commercial Mail Relay. Unfortunately, due to its restrictions about who can use it (supposedly), it has potential to become a sticky situation if the user you are sending to no longer has his MCI Mail account or if you accidentally mistype the MCI Mail address. But to save us from this potential problem, MCI Mail now has their own domain on the Internet, MCIMAIL.COM so mailing to userid@MCIMAIL.COM should work just as well as CMR without the risks of being yelled at (and possibly billed). PUBLIC ACCESS UNIXES ~~~~~~~~~~~~~~~~~~~~ Part of the problem with the whole idea of using the Wide Area Networks is access. For those who are not enrolled in a university or cannot pull strings at their local business or college, the concept of communicating through the networks is useless besides thinking that it would be neat. Thanks to Phil Eschallier, phil@lgnp1.UUCP or phil@LS.COM, you should now be able to get access to the Wide Area Networks via UUCP. The following is a list of Public Access Unix systems taken from the Usenet Newsgroup pub.nixpub which Phil keeps up and there are two versions, both of which contain the same basic information but each has important information which the other does not necessarily have. I urge you to attempt to get on one of these systems and drop us a line over the networks. nixpub long listing Open Access UNIX (*NIX) Sites [Fee / No Fee] for mapped sites only [ November 12, 1989 ] Systems listed (73): [ agora, alphacm, althea, amazing, anet, attctc, bigtex, bucket, chariot ] [ chinet, cinnet, conexch, cpro, cruzio, dasys1, ddsw1, dhw68k, disk ] [ eklektik, esfenn, gensis, grebyn, i-core, igloo, jdyx, jolnet, lgnp1 ] [ lilink, loft386, lunapark, m-net, madnix, magpie, marob, ncoast, netcom ] [ nstar, nuchat, nucleus, oncoast, ozdaltx, pallas, pnet01, pnet02 ] [ pnet51, point, polari, portal, raider, rpp386, rtmvax, sactoh0, sharks ] [ sir-alan, sixhub, stanton, stb, sugar, telly, tmsoft, tnl, turnkey ] [ ubbs-nh, usource, uuwest, vpnet, well, wet, wolves, world, wybbs ] [ xroads, ziebmef ] Last Contact Date Telephone # Sys-name Location Baud Hours ----- ------------ -------- ----------- ------- ----- 08/89 201-846-2460^ althea New Brunswick NJ 3/12/24 24 AT&T 3B2/310 - Unix SVR3.1, no fee. USENET, email, C development, games. Single line. Contact: rjd@althea.UUCP (Robert Diamond) 10/89 206-328-4944 polari Seatle WA 3/12 24 Equip ???; 8-lines, Trailblazer on 206-328-1468; $30/year (flat rate); Multi-user games, chat, full USENET. Contact: uunet!microsoft!happym!polari!bruceki 10/89 212-420-0527 magpie NYC NY 3/12/24/96 24 ? - UNIX SYSV - 2, Magpie BBS, no fee, Authors: Magpie/UNIX,/MSDOS two lines plus anonymous uucp: 212-677-9487 (9600 bps Telebit modem) NOTE: 9487 reserved for registered Magpie sysops & anon uucp Contact: Steve Manes, {rutgers|cmcl2|uunet}!hombre!magpie!manes 10/89 212-675-7059 marob NYC NY 3/12/24 24 386 SCO-XENIX 2.2, XBBS, magpie bbs, no fee, limit 60 min Telebit Trailblazer (9600 PEP) only 212-675-8438 Contact: {philabs|rutgers|cmcl2}!{phri|hombre}!marob!clifford 05/89 212-879-9031^ dasys1 NYC NY 12/24 24 Unistride - SYS V, multiple lines, fee $5/mo AKA Big Electric Cat USENET, games, multi-user chat, email, login: new, passwd: new Contact: ...!rutgers!cmcl2!rsweeney or rsweeney@dasys1.UUCP 09/89 213-376-5714^ pnet02 Redondo Bch CA 3/12/24 24 XENIX (also 213-374-7404) no fee, 90 min limit, login: pnet id: new some USENET, net-work e-mail, multi-threaded conferencing 09/89 213-397-3137^ stb Santa Monica CA 3/12/24 24 AT&T 3b1; BBS and shell access; uucp-anon: ogin: uucp NO PASSWD 3 line on rotory -3137 2400 baud. 03/88 213-459-5891 amazing Pacific Palisades CA 3/12/24 24 AMT 286 - Microport David's Amazing BBS Fee $7.50/month;$35/6;$60/year 5 lines on rotary; Unique original software with conferencing, electronic bar, matchmaking, no file up/downloading 07/88 214-247-2367 ozdaltx Dallas TX 3/12/24 24 INTEC/SCO XENIX 2.2.1, OZ BBS, Membership only adult BBS, fee $40 year. Multiple lines. Closed system, carries limited USENET newsgroups. Login: guest (no PW). Voice verification on all new users. 07/89 214-824-7881 attctc Dallas TX 3/12/24 24 3b2/522 - UNIX, no fee, various time limits, 8 lines 2.8 GB online uucp-anon --> 214-741-2130 ogin: uupdsrc word: Public uucp-anon info in: /bbsys4/README (Formerly node name killer) 11/89 215-348-9727 lgnp1 Doylestown PA 3/12/24/96 24 SCO-XENIX -- Telebit access. Shell accounts by appointment only; Fee; Services include E-mail, USENET News; --Home of the Nixpub lists-- Contact: anon-uucp: nuucp NO PWD (download /usr/spool/uucppublic/nixpub or /usr/spool/uucppublic/nixpub.short) 09/89 216-582-2441 ncoast Cleveland OH 12/24/96 24 80386 Mylex, SCO Xenix; 600 meg. storage; XBBS and Shell; USENET (newsfeeds available), E-Mail; donations requested; login as "bbs" for BBS and "makeuser" for new users. Telebit used on 216-237-5486. 08/88 217-529-3223 pallas Springfield IL 3/12/24 24 Convrgnt Minifrme, multiple lines, 200 meg Minnie bbs $25 donation 10/89 219-289-0286 nstar South Bend IN 3/12/24/96 24 Equip ???, UNIX 3.2; 300 Meg On-line; 4 lines at 9600 baud -- (listed) - Hayes V-Series, (287-9020) - HST, (289-3745) - PEP; Full USENET, AKCS Software; Contact ..!iuvax!ndcheg!ndmath!nstar!larry 08/88 312-283-0559^ chinet Chicago IL 3/12/24 24 3b2/300 - SYS V 3.1, multiple lines, Picospan BBS, system & BBS free Extra phone lines and usenet, $50/yr. 10/89 312-338-0632^ point Chicago IL 3/12/24/96 24 North Shore / Rogers Park area of Chicago. 386 - ISC 2.01 (SysV3.2), multiple lines, Telebit PEP on 338-3261, USRobotics HST on 338-1036, AKCS bbs, some usenet conferences available. 200+ MB online storage. Downloads, full usenet & shell access in the works. 04/89 313-623-6309 nucleus Clarkston MI 12/24 24 286 - Unix System V, no fee. Shell access, full usenet access, online games, AKCS conferencing system, some public domain sources online, extensive tape library of public domain source code 02/88 313-994-6333 m-net Ann Arbor MI 3/12 24 Altos 68020 - SYS III, limits unstated, fee for extended service Picospan conference system, multiple lines, 160 meg, packet radio 08/89 313-996-4644^ anet Ann Arbor MI 3/12 24 Altos 68000 - Sys III, no limits, 1st month free, fees range up to $20/ month (negotiable), accepts equipment/software in lieu of fees, Picospan conferencing, 120M, non-profit, user-supported, community-based, ideal autodidact educational system. Tax-deductible donations okay. 08/89 314-474-4581 gensis Columbia MO 3/12/24/48/96 24 Gateway 386 system w/ SCO Xenix V/386, DataFlex, Oracle, CHARM, & VP/ix. No fee. Online gaming, game design, and (oddly enough) data base design are the main focus. Modem is Microcom MNP 6. 10/89 404-321-5020^ jdyx Atlanta GA 12/24/96 24 386/ix 2.0.2. XBBS. Usenet (alt, gnu, most comp and a few others) and shell access. Second line (2400 below) (404) 325-1719. 200+ meg current Usenet and GNU sources. Specializing in graphics and ray-tracing under 386/ix (with/with out X11). Yearly fee for shell and/or downloads. Telebit access. Contact: ...gatech!emory!jdyx!tpf (Tom Friedel) 05/88 407-380-6228 rtmvax Orlando FL 3/12/24 24 mVAX-I - Ultrix-32 V1.2 USENET & UUCP Email Gateway. XBBS front end for new user subscribing. No Fees. Primary function is Technical exchange. Contact: { cbosgd!codas, hoptoad!peora }!rtmvax!rob 09/89 408-245-7726^ uuwest Sunnyvale CA 3/12/24 24 SCO-XENIX, Waffle. No fee, USENET news (news.*, music, comics, telecom, etc) The Dark Side of the Moon BBS. This system has been in operation since 1985. Login: new Contact: (UUCP) ames!uuwest!request (Domain) 04/88 408-247-4810 sharks Santa Clara CA 3/12 24 Altos 886/80/80 - XENIX 3.2f AKA: Shark's Head BBS, BBCS Network Multiple lines,no fee for non-members,members $25 year Restricted sh access and UUCP/Usenet access for advanced members 11/89 408-423-9995 cruzio Santa Cruz CA 12/24 24 Tandy 4000, Xenix 2.3.*, Caucus 3.*; focus on Santa Cruz activity (ie directory of community and goverment organizations, events, ...); Multiple lines; no shell; fee: $18/quarter. Contact: ...!uunet!cruzio!chris 10/89 408-725-0561^ portal Cupertino CA 3/12/24 24 Networked Suns (SunOS), multiple lines, Telenet access, no shell access fees: $10/month + Telenet charges (if used) @ various rates/times conferencing, multi user chats, usenet 02/89 408-997-9119^ netcom San Jose CA 3/12/24/96 24 Unix System V -- Shell Access [Bourne, Korn, C-Shell], BBS, USENET, Languages: C, Lisp, Prolog, Clips, (Ada soon), $10 / month, login as 'guest' no password. Contact netcom!bobr. 10/89 412-431-8649 eklektik Pittsburgh PA 3/12/24 24 UNIX PC- SYSV - UNaXcess BBS, new system - donation requested for shell, login: bbs for BBS, uucp-mail, limited Usenet news feeds. Gaming SIGS. Contact: ...!gatech!emoryu1!eklektik!anthony 11/89 415-332-6106^ well Sausalito CA 12/24 24 6-processor Sequent Balance (32032); UUCP and USENET access; multiple lines; access via CPN; PICOSPAN BBS; $3/hour. Contact (415) 332-4335 06/88 415-582-7691 cpro Hayward CA 12/24 24 Microport SYSV 2, UNaXcess bbs, no fee, 60 min limit, shell access 07/89 415-753-5265^ wet San Francisco CA 3/12/24 24 386 SYS V.3. Wetware Diversions. $15 registration, $0.01/minute. Public Access UNIX System: uucp, PicoSpan bbs, full Usenet News, multiple lines, shell access. Newusers get initial credit! contact:{ucsfcca|claris|hoptoad}!wet!cc (Christopher Cilley) 05/89 415-783-2543 esfenn Hayward CA 3/12/24 24 System ????; USENET news; E-mail; No charges; Contact esfenn!william. 01/89 416-452-0926 telly Brampton ON 12/24/96 24 286 Xenix; proprietary menu-based BBS includes Usenet site searching. News (all groups, incl biz, pubnet, gnu), mail (including to/from Internet), some archives. Feeds available. Fee: $75(Cdn)/year. Contact: Evan Leibovitch,, {uunet!attcan,utzoo}!telly!evan 12/88 416-461-2608 tmsoft Toronto ON 3/12/24/96 24 NS32016, Sys5r2, shell; news+mail $30/mo, general-timesharing $60/mo All newsgroups. Willing to setup mail/news connections. Archives:comp.sources.{unix,games,x,misc} Contact: Dave Mason / Login: newuser 07/89 416-654-8854 ziebmef Toronto ON 3/12/24/96 24 AT&T 3B1, Sys V, shell, news, mail, no fee (donations accepted) Carries most newsgroups (willing to add extra ones on request) Telebit access, willing to give mail feeds Contact: Chris Siebenmann, {utzoo!telly,ncrcan}!ziebmef!cks 08/89 502-968-5401 disk Louisville KY 3/12 24 386 clone, Microport System V, 600 meg. 6 lines 5401 thru 5406. rarrying most USENET groups, Shell access, games, downloads, multi-user chat, and more. Rate info available via a free trial account. 12/88 503-254-0458 bucket Portland OR 3/12/24 24 Tektronix 6130, UTek 2.3(4.2BSD-derived). Bit Bucket BBS publically available; login as 'bbs'. BBS is message only. Users intereseted in access to Unix should contact SYSOP via the BBS or send EMail to ..tektronix!tessi!bucket!rickb. Unix services include USENET News, EMail, and all tools/games/utility access. Alternate dial-in lines available for Unix users. 05/89 503-640-4262^ agora PDX OR 3/12/24 24 Intel Xenix-286, $2/mo or $20/yr, news, mail, games, programming two lines with trunk-hunt, 4380 supports MNP level 3. Contact: Alan Batie, tektronix!tessi!agora!batie 10/89 512-346-2339 bigtex Austin TX 96 24 Equip unknown, no shell, no fee, anonymous uucp ONLY, Telebit 9600/PEP mail & newsfeeds (limited) available. Carries GNU software. anon login: nuucp NO PASSWD, file list /usr3/index Contact: ...!uunet!utastro!bigtex!james 07/89 512-832-8835 rpp386 Austin TX 12/24 24 386 SYSV, no shell, no bbs, anonymous uucp file transfer site only, no fee uucp and kermit server available, login uucp or kermit NO PASSWD 10/89 513-779-8209 cinnet Cincinnati OH 12/24/96 24 80386, ISC 386/ix 2.02, Telebit access, 1 line; $7.50/Month; shell access, Usenet access; news feeds available; login: newact password: new user to register for shell access 05/89 516-872-2137 lilink Long Island NY 12/24 24 80386/20 Mhz. , three lines, News/Mail/Shell access. Online games, conferencing, full program development system, full text processing. We carry ALL Usenet groups. Dues are $10/month (unlimited access). Accounts are filled by application/phone verification. Login: new Alternate numbers: 516-872-2138 & 516-872-2349 07/89 517-487-3356 lunapark E. Lansing MI 12/24 24 Compaq 386/20 SCO-XENIX 2.3.1, lunabbs bulletin board & conferencing system, no fee, login: bbs no password. Primarily UNIX software with focus on TeX and Postscript, also some ATARI-ST and IBM-PC stuff 2400/1200 --> 8 N 1 Contact: ...!uunet!frith!lunapark!larry 12/88 518-346-8033 sixhub upstate NY 3/12/24 24 PC Designs GV386. hub machine of the upstate NY UNIX users group (*IX) two line reserved for incoming, bbs no fee, news & email fee $15/year Smorgasboard of BBS systems, UNaXcess and XBBS online, Citadel BBS now in production. Contact: davidsen@sixhub.uucp. 09/88 602-941-2005 xroads Phoenix AZ 12/24 24 Motorola VME1121, UNIX 5.2, Crossroads BBS, Fee $30/yr + $.50/.25 (call) prime (evenings)/non-prime, USENET news, multi-chat, online games, movie reviews, adventure games, dos unix/xenix files for dload, multi lines 08/89 603-880-8120 ubbs-nh Nashua NH 3/12/24/96 24 New England Unix Archive Site. Multiple lines. Services include E-Mail, full or partial news feeds. XBBS access $25/year, User Accounts or News Feeds available $60/year (1 hour/day) or $120/year (2 hours/day). Contact: noel@ubbs-nh or {decvax}!ubbs-nh!noel or leave message on the bbs. Voice: 603 595-2947 08/89 605-348-2738 loft386 Rapid City SD 3/12/24/96 24 80386 SYS V/386 Rel 3.2, Usenet mail/news via UUNET, UUNET archive access. NO BBS! News feeds avaliable. 400 meg hd. Fees: $10/month or $25/quarter. Call (605) 343-8760 and talk to Doug Ingraham to arrange an account or email uunet!loft386!dpi 08/88 608-273-2657 madnix Madison WI 3/12/24 24 286 SCO-XENIX, shell, no fee, USENET news, mail, login: newuser Contact: ray@madnix 08/89 612-473-2295 pnet51 Minneapolis MN 3/12/24 24 Equip ?, Xenix, multi-line, no fee, some Usenet news, email, multi-threaded conferencing, login: pnet id: new, PC Pursuitable UUCP: {rosevax, crash}!orbit!pnet51!admin 08/89 615-896-8716 raider Murfreesboro TN 12/24 24 Tandy 4000 XENIX, XBBS, shell accounts, news and mail, newsfeeds available. Two line system; second dialup is 615-896-7905. Contact: root@raider.MFEE.TN.US (Bob Reineri); NO CHARGE. 07/89 616-457-1964 wybbs Jenison MI 3/12/24 24 286 - SCO-XENIX 2.2.1, no fees, two lines, shell access, usenet news, 150 meg storage, XBBS, interests: ham radio, xenix AKA: Consultants Connection Contact: danielw@wybbs.UUCP Alternate phone #: 616-457-9909 (max 1200 baud) 11/89 617-739-9753 world Brookline MA 3/12/24/96 24 Sun 4/280, SunOS 4.03; Shell, USENET, E-Mail, UUCP and home of the Open Book Initiative (text project); fees: 8a-6p $8/hr, 6p-12a $5/hr, 12a-8a $2.50/hr; Multiple lines: 2400 MNP used on listed number, Telebits used on others; login as "new"; Contact: 07/88 619-444-7006^ pnet01 El Cajon CA 3/12/24 24 BSD Unix, 3 lines, login: pnet id: new, some USENET, email, conferencing Home of P-Net software, mail to crash!bblue or pnet01!bblue for info. Contributions requested Unix accounts available for regulars, PC Pursuit access 2/88. 10/88 703-281-7997^ grebyn Vienna VA 3/12/24/96 24 Vax/Ultrix. $25/month. GNU EMACS, USENET, PC/BLUE archives, Telebit on 7998 and 7999, archives, Ada repository, comp.sources.(misc,unix,games) archives, net.sources archives, 3 C compilers, Ada compiler, 500MB disk, multiple lines 11/89 708-272-5912^ igloo Northbrook IL 12/24/96 24 3B2-300; accounts by invitation only, no limit/no fee; full usenet; 132megs HD; 2 lines rotary, 9600 telebit on 272-5917 Contact: igloo!postmaster 11/89 708-301-2100^ jolnet Joliet IL 3/12/24 24 3b2/400 - Unix, public access and contributions, No fee for postnews. 5 lines AKCS bbs. Free Newsfeeds available. >450 MB online storage. Free Shell and Usenet access. Telebit Trailblazer access (2104). Telenet access. 11/89 708-566-8911^ ddsw1 Mundelein IL 3/12/24/96 24 Televideo 386 -SCO XENIX 386, guest usr 1 hr daily, fee extends use AKCS bbs, fee $30/6 months $50/year, Authors of AKCS bbs multiple lines, 9600 bps available, anonymous uucp, >/README for info Contact: Karl Denninger (...!ddsw1!karl) Voice: (312) 566-8910 11/89 708-833-8126^ vpnet Villa Park IL 12/24/96 24 386 Clone - Interactive 386/ix R2.0 (3.2), no fee. Akcs linked bbs including several Usenet conf's. No charge for shells. Trailblazer. Mail lisbon@vpnet.UUCP 07/89 713-438-5018 sugar Houston TX 3/12/24/96 24 386/AT (2) networked - Bell Technologies V/386, usenet, news, downloads Homegrown BBS software, Trailblazer+ access, currently no charges 10/89 713-668-7176^ nuchat Houston TX 3/12/24/96 24 i386; USENET, Mail, Shell Access; 300M On-line; Trailbazer Used; No fee. 12/88 714-635-2863 dhw68k Anaheim CA 12/24 24 Unistride 2.1, no fee, also 714-385-1915, Trailblazer on both lines, USENET News, /bin/sh or /bin/csh available 05/89 714-662-7450 turnkey Inglewood CA 12/24 24 286 - Xenix SYSV, XBBS 11/89 714-821-9671 alphacm Cypress CA 12/24/96 24 386 - SCO-XENIX, no fee, Home of XBBS, 90 minute per login, 4 lines, 9600 baud via MicroComm/Hayes (v.29) uucp-anon: ogin: nuucp NO PASSWD 05/89 714-842-5851 conexch Santa Ana CA 3/12/24 24 386 - SCO Xenix - Free Unix guest login and PC-DOS bbs login, one hour inital time limit, USENET news, shell access granted on request & $25/quarter donation. Anon uucp: ogin: nuucp NO PASSWD. List of available Unix files resides in /usr3/public/FILES. 08/88 714-894-2246 stanton Irvine CA 3/12/24 24 286 - SCO Xenix - donation requested, limit 240 min, XBBS, USENET news UNIX access granted on request through BBS, 20$/year, access includes C development system (XENIX/MSDOS), PROCALC 1-2-3 clone, FOXBASE+ anon uucp: ogin: nuucp, no word, 2400/1200/300 MNP supported 05/88 719-632-4111 chariot Colo Sprgs CO 3/12 24 Convrgnt Minifrme - SYS V, multiple lines, fee $12/mo Picospan 08/89 801-943-7947^ i-core Salt Lake City UT 3/12/24/96 24 286 SYS V, Unidel BBS, a.k.a. Bitsko's Bar & Grill, no limit, no fee, UseNet and Citadel feeds available, home of Unidel BBS, Telebit 19200 used Contact: ken@i-core.UUCP or uunet!iconsys!caeco!i-core!ken 12/88 802-865-3614 tnl Burlington VT 3/12/24 24 80386 w/ SCO XENIX. No Fee. 2 hr session limit. XBBS/USENET, shell. Login as 'new' for a shell account, no validation. AKA: Northern Lights. 08/88 813-952-1981 usource Sarasota FL 12/24 -24 386 - SCO-XENIX, fee depends on services provided, no fee for bbs. New users subscribe by logging in as 'help' or 'newuser' (no password). Primary purpose is technical forum. 6pm-8am M-Th, 24 hrs weeekends (6pm Fri-8am Mon) uucp-anon: 1200/2400 bps --> ogin: auucp word: gateway uucp-anon directory: /usr/spool/uucppublic; contact: frank@usource.UUCP 08/88 814-333-6728 sir-alan Meadville PA 3/12/24 24 Tandy XENIX/68000 03.01.02, Allegheny College, UNaXcess BBS uucp-anon: ogin: pdsrc NO PASSWD uucp-anon directory: /usr/spool/pdsrc/all.subjects Telebit TB+ available at 814 337 0894, now operating. Contact: sir-alan!mikes 05/88 814-337-3159 oncoast Meadville PA 3/12/24/96 24 Tandy 12/6000, no fee, no bbs, archive site, USR HST 9600, cycle 24/96/12 vols 1 - 13 of mod.sources/comp.sources.unix, comp.sources.misc New stuff on sir-alan, older on oncoast. 2 uucp logins "uucp" and "pdsrc" files list = /usr/spool/uucppublic/ or /usr/spool/pdsrc/ all.subjects.Z 09/89 916-649-0161 sactoh0 Sacramento CA 12/24/96 24 3B2/310 SYSV.2, SAC_UNIX; $2/month, limit 90 min, 2 lines, TB on line, 2400/1200 baud on 916-722-6519; USENET, E-Mail, Games; login: new Contact: ..pacbell!sactoh0!sysop 089 919-493-7111^ wolves Durham NC 3/12/24 24 AMS 386/25 - UNIX SysVr3.2, XBBS, no fee for bbs. Rates for UNIX access and USENET are being determined. Developing yet another UNIX bbs (ideas welcome!) Single line, telebit coming soon. Contact: wolves!ggw or wolves!sysop [...duke!dukcds!wolves!...] ------------------------------------------------------------------------------- NOTE: ^ means the site is reachable using PC Pursuit. =============================================================================== This list is maintained by Phil Eschallier on lgnp1. Any additions, deletions, or corrections should be sent to one of the addresses below. The nixpub listings are kept as current as possible. However, you use this data at your own risk and cost -- all standard disclaimers apply!!! ------ Lists available from lgnp1 via anonomous uucp. +1 215 348 9727 [Telebit access] login: nuucp NO PWD [no rmail permitted] this list: /usr/spool/uucppublic/nixpub short list: /usr/spool/uucppublic/nixpub.short or from news groups pubnet.nixpub, comp.misc or alt.bbs. ------ E-MAIL ... uucp: ..!uunet!lgnp1!$ phil | nixpub $ or: $ phil | nixpub $@LS.COM CIS: 71076,1576 =============================================================================== COMPAQ, IBM, PC Pursuit, [SCO] XENIX, UNIX, etc. are trademarks of the respective companies. =============================================================================== nixpub short listing Open Access UNIX (*NIX) Sites [Fee / No Fee] for mapped sites only [ November 12, 1989 ] Systems listed (73) Legend: fee/contribution ($), no fee (-$), hours (24), not (-24) shell (S), USENET news (N), email (M), multiple lines (T) Telebit 9600 bps on main number (+P), Telebit on other line[s] (P) Courier 9600 bps on main number (+H), Courier on other line[s] (H) anonymous uucp (A), archive site ONLY - see long form list (@) @> = anonymous uucp archive site listed in ANONIX (mike@cpmain) Dialable thru PC Pursuit (^) Last Contact Date Telephone # Sys-name Location Baud Legend ----- ------------ -------- ----------- ------- --------- 08/89 201-846-2460^ althea New Brunswic NJ 3/12/24 24 -$ M N S 10/89 206-328-4944 polari Seatle WA 3/12 24 $ M N P S T 10/89 212-420-0527 magpie NYC NY 3/12/24/96 24 -$ T P 10/89 212-675-7059 marob NYC NY 12/24 24 -$ A 05/89 212-879-9031^ dasys1 NYC NY 12/24 24 $ S N M T 09/89 213-376-5714^ pnet02 Redondo Bch CA 3/12/24 24 -$ M N T 09/89 213-397-3137^ stb Santa Monica CA 3/12/24 24 -$ S A 11/88 213-459-5891 amazing Pac Palisade CA 3/12/24 24 $ T 07/88 214-247-2367 ozdaltx Dallas TX 3/12/24 24 $ N T 07/89 214-741-2130 attctc Dallas TX 3/12/24 24 -$ N M S T A 11/89 215-348-9727 lgnp1 Doylestown PA 3/12/24/96 24 $ A M N +P S 09/89 216-582-2441 ncoast Cleveland OH 12/24/96 24 $ S N M P T 08/88 217-529-3223 pallas Springfield IL 3/12/24 24 $ T 10/89 219-289-0286 nstar South Bend IN 3/12/24/96 24 -$ H M N P S T 08/88 312-283-0559^ chinet Chicago IL 3/12/24 24 $ N T 10/89 312-338-0632^ point Chicago IL 3/12/24/96 24 -$ N P S T 04/89 313-623-6309 nucleus Clarkston MI 12/24 24 $ S N M 11/88 313-994-6333 m-net Ann Arbor MI 3/12 24 $ T 08/89 313-996-4644^ anet Ann Arbor MI 3/12 24 $ T 08/89 314-474-4581 gensis Columbia MO 3/12/24/96 24 -$ M S 10/89 404-321-5020^ jdyx Atlanta GA 12/24 24 $ M N +P S T 05/88 407-380-6228 rtmvax Orlando FL 3/12/24 24 -$ N M 09/89 408-245-7726^ uuwest Sunnyvale CA 3/12/24 24 -$ N 04/88 408-247-4810 sharks Santa Clara CA 3/12 24 $ S N M T 11/89 408-423-9995 cruzio Santa Cruz CA 12/24 24 $ M T 10/89 408-725-0561^ portal Cupertino CA 3/12/24 24 $ -S N M T 02/89 408-997-9119^ netcom San Jose CA 3/12/24/96 24 $ M N S 10/89 412-431-8649 eklektik Pittsburgh PA 3/12/24 24 $ S N M 11/89 415-332-6106^ well Sausalito CA 12/24 24 $ M N S T 06/88 415-582-7691 cpro Hayward CA 12/24 24 -$ S 07/89 415-753-5265^ wet San Francisc CA 3/12/24 24 $ M N S T 05/89 415-783-2543 esfenn Hayward CA 3/12/24 24 -$ M N S 01/89 416-452-0926 telly Brampton ON 12/24/96 +P 24 $ M N 12/88 416-461-2608 tmsoft Toronto ON 3/12/24/96 24 $ S M N 07/89 416-654-8854 ziebmef Toronto ON 3/12/24/96 24 +P M N S T 08/89 502-968-5401 disk Louisville KY 3/12 24 $ M N S T 12/88 503-254-0458 bucket Portland OR 3/12/24 24 -$ N M T 05/89 503-640-4262^ agora PDX OR 3/12/24 24 $ M N S T 10/88 512-346-2339 bigtex Austin TX 96 +P 24 -S -$ A @> 07/89 512-832-8835 rpp386 Austin TX 12/24 24 @ -$ -S A T 10/89 513-779-8209 cinnet Cincinnati OH 12/24/96 24 $ M N +P S 05/89 516-872-2137 lilink Long Island NY 12/24 24 $ M N S T 07/89 517-487-3356 lunapark E. Lansing MI 12/24 24 -$ 12/88 518-346-8033 sixhub upstate NY 3/12/24 24 $ S N M T 09/88 602-941-2005 xroads Phoenix AZ 3/12/24 24 $ N T 08/89 603-880-8120 ubbs-nh Nashua NH 3/12/24/96 24 -$ M N +P S T 08/89 605-348-2738 loft386 Rapid City SD 3/12/24/96 24 $ M N +P S 08/88 608-273-2657 madnix Madison WI 3/12/24 24 -$ S N M 08/89 612-473-2295 pnet51 Minneapolis MN 3/12/24 24 -$ N M T 08/89 615-896-8716 raider Murfreesboro TN 12/24 24 -$ S N M T 07/89 616-457-1964 wybbs Jenison MI 3/12/24 24 -$ S N T 11/89 617-739-9753 world Brookline MA 3/12/24/96 24 $ M N P S T 07/88 619-444-7006^ pnet01 El Cajon CA 3/12/24 24 $ N M S T 10/88 703-281-7997^ grebyn Vienna VA 3/12/24/96 24 $ N M T P 11/89 708-272-5912^ igloo Northbrook IL 12/24/96 24 -$ S N T P 11/89 708-301-2100^ jolnet Joliet IL 3/12/24 24 -$ +P M N S T 08/88 312-566-8911^ ddsw1 Mundelein IL 3/12/24/96 24 $ S N M T A P 11/89 708-833-8126^ vpnet Villa Park IL 12/24/96 24 -$ +P M N S 07/89 713-438-5018 sugar Houston TX 3/12/24/96 24 -$ N +P 10/89 713-668-7176^ nuchat Houston TX 3/12/24/96 24 -$ M N +P S 12/88 714-635-2863 dhw68k Anaheim CA 12/24 24 -$ T 05/89 714-662-7450 turnkey Inglewood CA 12/24 24 -$ 11/89 714-821-9671 alphacm Cypress CA 12/24/96 24 -$ T H A 05/89 714-842-5851 conexch Santa Ana CA 3/12/24 24 $ A M N S 08/88 714-894-2246 stanton Irvine CA 3/12/24 24 $ S N 05/88 719-632-4111 chariot Colo Sprgs CO 3/12 24 $ T 08/89 801-943-7947^ i-core Salt Lake Ci UT 3/12/24/96 +P 24 -$ A N 06/88 802-865-3614 tnl Burlington VT 3/12/24 24 -$ S N M 08/88 813-952-1981 usource Sarasota FL 12/24 -24 -$ A 08/88 814-333-6728 sir-alan Meadville PA 3/12/24 24 -$ A P 05/88 814-337-3159 oncoast Meadville PA 3/12/24/96 +H 24 @ -$ -S A 09/89 916-649-0161 sactoh0 Sacramento CA 12/24/96 24 $ M N +P S T 08/89 919-493-7111^ wolves Durham NC 3/12/24 24 $ M N S ------------------------------------------------------------------------------- NOTE: ^ means the site is reachable using PC Pursuit. =============================================================================== This list is maintained by Phil Eschallier on lgnp1. Any additions, deletions, or corrections should be sent to one of the addresses below. The nixpub listings are kept as current as possible. However, you use this data at your own risk and cost -- all standard disclaimers apply!!! ------ Lists available from lgnp1 via anonomous uucp. +1 215 348 9727 [Telebit access] login: nuucp NO PWD [no rmail permitted] this list: /usr/spool/uucppublic/nixpub.short long list: /usr/spool/uucppublic/nixpub or from news groups pubnet.nixpub, comp.misc or alt.bbs ------ E-MAIL ... uucp: ..!uunet!lgnp1!{ phil | nixpub } or: { phil | nixpub }@LS.COM =============================================================================== COMPAQ, IBM, PC Pursuit, [SCO] XENIX, UNIX, etc. are trademarks of the respective companies. >--------=====END=====--------< ==Phrack Inc.== Volume Three, Issue 29, File #5 of 12 [-][-] [-][-] [-][-] [-][-] [-][-] [-][-] [-][-] [-] [-] [-] Covert Paths [-] [-] [-] [-] by [-] [-] [-] [-] Cyber Neuron Limited and Synthecide [-] [-] [-] [-] November 1, 1989 [-] [-] [-] [-][-] [-][-] [-][-] [-][-] [-][-] [-][-] [-][-] When cracking a system, it is important for you to use a path to the system that will not lead the authorities to your door step. There are several methods for doing this and all of them will depend on your destination, available time, goal and the phase of the moon. This article deals mostly with cover attacks via a connected network. If attacking via a phone link: o Tap in to your local payphone line and red box or "sprint" the call. o Using a long haul service (like Sprint or MCI) to dial into systems in remote cities. [This should hinder a track by a good order of magnitude.] o Use a midnight packet switching network (eg: PC-Pursuit, Tymnet, et. al.) o All the above. If attacking from a network (eg: the Internet) there are ways of spoofing the packet headers, but this requires superuser privileges on the system you are attacking from and a fair amount of 'C' programming expertise. Therefore, this will not be discussed here in any more detail. Another obvious trick is to use network routers and gateways along with guest accounts to "route" your data path. This will cause the person tracking you to have to go though more red tape and hassle to track you. This gives you more time to cover your tracks. Some useful paths I know of are: host: host: account: nobody account: netgate net address: net address: host: host account: terminal account: telnet net address: net address: host: host: port: 8033 account: guest net address: net address: The accounts nobody, netgate, and terminal at Berkeley are accounts that were installed so that people can use the system to rlogin or telnet to an account elsewhere without a local login (or so I am told by the local hackers [Hi Audrey...]). The lightning path/method can be accessed by the command: "telnet 8033". I am interested in hearing about other Internet access accounts that are available out there. If you know of any please send them in. Tymnet is also a useful method of gaining access to systems. From Tymnet, you can hook up to just about any computer and use the other methods to go one step further. It's not until you are traced back to the computer you linked to from Tymnet that they can even begin to follow you back. My understanding is that for a systen to find your Tymnet node, they must contact Tymnet personally and ask them to put a trap on their connection. For more infomation concerning Tymnet see the article "Hacking & Tymnet" by Synthecide in Phrack Inc. Newsletter Issue XXX. ********************************** >--------=====END=====--------< ==Phrack Inc.== Volume Three, Issue 29, File #6 of 12 + BANK INFORMATION + \ / \ / ___Compiled By___ / \ Legion Of Doom! EFT Division ------------ In order to exact any type of bank associated transaction by computer, one must have a working knowledge of the various routing codes involved in the banking processes. The following is an informational guide to the coding used in American banking transactions. ABA (American Bankers Association) Transit Numbers Numbers 1 to 49 inclusive are Prefixes for Cities Numbers 50 to 99 inclusive are Prefixes for States Prefix Numbers 50 to 58 are Eastern States Prefix Number 59 is for Alaska, Hawaii, and US Territories Prefix Numbers 60 to 69 are Southeastern States Prefix Numbers 70 to 79 are Central States Prefix Numbers 80 to 88 are Southwestern States Prefix Numbers 90 to 99 are Western States 1 New York, NY 2 Chicago, IL 3 Philadelphia, PA 4 St. Louis, MO 5 Boston, MA 6 Cleveland, OH 7 Baltimore, MD 8 Pittsburgh, PA 9 Detroit, MI 10 Buffalo, NY 11 San Francisco, CA 12 Milwaukee, WI 13 Cincinnati, OH 14 New Orleans, LA 15 Washington D.C. 16 Los Angeles, CA 18 Kansas City, MO 19 Seattle, WA 20 Indianapolis, IN 21 Louisville, KY 22 St. Paul, MN 23 Denver, CO 24 Portland, OR 25 Columbus, OH 26 Memphis, TN 27 Omaha, NE 28 Spokane, WA 29 Albany, NY 30 San Antonio, TX 31 Salt Lake City, UT 32 Dallas, TX 33 Des Moines, IA 34 Tacoma, WA 35 Houston, TX 36 St. Joseph, MO 37 Fort Worth, TX 38 Savannah, GA 39 Oklahoma City, OK 40 Wichita, KS 41 Sioux City, IA 42 Pueblo, CO 43 Lincoln, NE 44 Topeka, KS 45 Dubuque, IA 46 Galveston, TX 47 Cedar Rapids, IA 48 Waco, TX 49 Muskogee, OK 50 New York 51 Connecticut 52 Maine 53 Massachusetts 54 New Hampshire 55 New Jersey 56 Ohio 57 Rhode Island 58 Vermont 59 Alaska, American Samoa, Guam, Hawaii, Puerto Rico, Virgin Islands 60 Pennsylvania 61 Alabama 62 Delaware 63 Florida 64 Georgia 65 Maryland 66 North Carolina 67 South Carolina 68 Virginia 69 West Virginia 70 Illinois 71 Indiana 72 Iowa 73 Kentucky 74 Michigan 75 Minnesota 76 Nebraska 77 North Dakota 78 South Dakota 79 Wisconsin 80 Missouri 81 Arkansas 83 Kansas 84 Louisiana 85 Mississippi 86 Oklahoma 87 Tennessee 88 Texas 90 California 91 Arizona 92 Idaho 93 Montana 94 Nevada 95 New Mexico 96 Oregon 97 Utah 98 Washington 99 Wyoming Federal Reserve Routing Symbols * All banks in an area served by a FR bank or branch bank carry the routing symbol of the FR bank or branch 1 Federal Reserve Bank of Boston Head 5-1 Office 110 2 Federal Reserve Bank of New York Head 1-120 Office 210 Buffalo Branch 10-26 220 3 Federal Reserve Bank of Philadelphia 3-4 Head Office 310 4 Federal Reserve Bank of Cleveland Head 0-1 Office 410 Cincinnati Branch 13-43 420 Pittsburgh Branch 8-30 430 5 Federal Reserve Bank of Richmond Head 68-3 Office 510 Baltimore Branch 7-27 520 Charlotte Branch 66-20 530 6 Federal Reserve Bank of Atlanta Head 64-14 Office 610 Birmingham Branch 61-19 620 Jacksonville Branch 63-19 630 Nashville Branch 87-10 640 New Orleans Branch 14-21 650 7 Federal Reserve Bank of Chicago Head 2-30 Office 710 Detroit Branch 9-29 720 8 Federal Reserve Bank of St. Louis Head 4-4 Office 810 Little Rock Branch 81-13 110 Louisville Branch 21-59 830 Memphis Branch 26-3 840 9 Federal Reserve Bank of Minneapolis 17-8 Head Office 910 Helena Branch 92-26 920 10 Federal Reserve Bank of Kansas City 18-4 Head Office 1010 Denver Branch 23-19 1020 Oklahoma City Branch 39-24 1030 Omaha Branch 27-12 1040 11 Federal Reserve Bank of Dallas Head 32-3 Office 1110 El Paso Branch 88-1 1120 Houston Branch 35-4 1130 San Antonio Branch 30-72 1140 12 Federal Reserve Bank of San Francisco 11-37 Head Office 1210 Los Angeles Branch 16-16 1220 Portland Branch 24-1 1230 Salt Lake City Branch 31-31 1240 Seattle Branch 19-1 1250 BANK IDENTIFICATION CODES XX-YYY WHERE: XX = City or State ZZZZ YYY = Bank of Origin ZZZZ = Federal Reserve Routing Code If three digits: The first digit identifies the Federal Reserve District The second digit, if 1, stands for the Head Office of the Federal Reserve District; 2-5 stand for the Branch Office of the Federal Reserve District The third digit signifies: 0-available for immediate credit; others have deferred credit and the digits mean the following: 1-5 designates the state in which the drawee bank is located; 6-9 special collection arrangements. If four digits: The first two digits stand for the Federal Reserve District 10-12. The following digits are as above EXAMPLE: 68-424 68-State of Virginia 514 424-Arlington Trust Co., Arlington, VA 5-Fifth Federal Reserve District 1-Head Office in Richmond, Virginia 4-Deferred credit and the state of Virginia *NOTE -- For further your familiarity with the coding process, on checks, these numbers appear at the bottom of the check according to the MICR Check Coding System. The check number, the account number, and the ABA Transit Number will all be encoded in magnetic ink. The ABA Number will be enclosed in symbols like: |: ABANUMBER |: The grouping of the ABA and Federal Reserve Codes will also usually appear at the upper right-hand corner of the check. Keep in mind that there are a great many checks involved in any banking procedure, and almost any transaction evoked improperly will draw attention. Furthermore, the documents generated in a legitimate wire-transfer situation are quite extensive. Should a transaction be noticed, and these documents are not available for scrutiny, again attention will be drawn to the situation. * BANK DOCUMENTS * * WIRE TRANSFER * INTERNAL CUSTOMER RECORD Teller Tape & Proof Sheets Copy of Wire Transfer Ticket Wire Transfer Ticket Cancelled Check (if used to Microfilm copy of check purchase) used to purchase wire Bank Statement (if funds came transfer out of the account) Microfilm copies of account records (if fund came out of existing account) Cash In/Out Ticket Vault Book Entry Bank Security Film Copy of CTR Bank transactions must be swift and precise. Amounts should be kept under the $10,000 range in order not to immediately arouse suspicion. Attacks must executed correctly the first time, as there will be no possibilities for a second chance. Monies must be gathered rapidly and dispersed into various outlets to avoid additional attention. Transfers to banking systems whose countries keep strict right to privacy laws, such as Panama, Switzerland, are not recommended as the transactions are much more involved and there exists a greater potential for error in international wire-transfers. The preferred method of transfer of funds would involve one or more false identities, complete with state approved identification or passport and social security cards. Bank Security Film is kept on file, so it would be preferred that some semblance of disguise be implemented, ranging from hair bleaching, sun-tanning, makeup, false accents, facial hair, etc. Various accounts in the assumed name would be opened in several cities with the minimum initial balance. Within approximately two weeks, funds of no more than $7500 would be diverted to each account. The funds would then be withdrawn in cash with no more than $5000 from each account, the balance being left in the account. Once the funds have been made cash, they would then be distributed to foreign banks, or invested in foreign markets to avoid detection by the Internal Revenue Service. Conviction for Illegal Transference of Funds is not recommended. >--------=====END=====--------< ==Phrack Inc.== Volume Three, Issue 29, File #7 of 12 The Legion of Doom! EFT Division Presents HOW WE GOT RICH THROUGH ELECTRONIC FUND TRANSFERS (OR: GEE! NO, GTE!) A certain number of financial institutions that reside within the packet-switched confines of the various X.25 networks use their connections to transfer funds from one account to another, one mutual fund to another, one stock to another, one bank to another, etc... It is conceivable that if one could intercept these transactions and divert them into another account, they would be transferred (and could be withdrawn) before the computer error was noticed. Thus, with greed in our hearts, an associate and I set forth to test this theory and conquer the international banking world. We chose CitiCorp as our victim. This multinational had two address prefixes of its own on Telenet (223 & 224). Starting with those two prefixes, my associate and I began to sequentially try every possible address. We continued through 1000 in increments of one, then A-Z, then 1000-10000 by 10's, and finally 10000-99999 by 100's. Needless to say, many addresses were probably skipped over in our haste to find valid ones, but many we passed over were most likely duplicate terminals that we had already encountered. For the next few days my associate and I went over the addresses we had found, comparing and exchanging information, and going back to the addresses that had shown 'NOT OPERATING,' 'REMOTE PROCEDURE ERROR,' and 'REJECTING.' We had discovered many of the same types of systems, mostly VAX/VMS's and Primes. We managed to get into eight of the VAXen and then went forth on the CitiCorp DECNET, discovering many more. We entered several GS1 gateways and Decservers and found that there were also links leading to systems belonging to other financial institutions such as Dai-Ichi Kangyo Bank New York and Chase Manhattan. We also found hundreds of addresses to TWX machines and many in-house bank terminals (most of which were 'BUSY' during banking hours, and 'NOT OPERATING' during off hours). In fact, the only way we knew that these were bank terminals was that an operator happened to be idle just as I connected with her terminal (almost like the Whoopie Goldberg movie, "Jumpin' Jack Flash," not quite as glamorous ...yet.) Many of the computers we eventually did penetrate kept alluding to the electronic fund transfer in scripts, files, and personal mail. One of the TOPS-20 machines we found even had an account EFTMKTG.EFT, (password EFTEFT)! All the traces pointed to a terminal (or series of terminals) that did nothing but transfer funds. We decided that this was the case and decided to concentrate our efforts on addresses that allowed us to CONNECT periodically but did not respond. After another week of concentrated effort, we managed to sort through these. Many were just terminals that had been down or malfunctioning, but there were five left that we still had no idea of their function. My associate said that we might be able to monitor data transmissions on the addresses if we could get into the debug port. With this idea in mind, we set out trying sub-addresses from .00 to .99 on the mystery addresses. Four of the five had their debug ports at the default location (.99). The fifth was located 23 away from the default. That intrigued us, so we put the others aside and concentrated on the fifth. Although its location was moved, a default password was still intact, and we entered surreptitiously. The system was menu driven with several options available. One option, Administrative Functions, put us into a UNIX shell with root privilege. After an hour or so of nosing around, we found a directory that held the Telenet Debug Tools package (which I had previously thought existed solely for Prime computers). Using TDT, we were able to divert all data (incoming and outgoing) into a file so we could later read and analyze it. We named the file ".trans" and placed it in a directory named ".. ", (dot, dot, space, space) so it would remain hidden. This was accomplished fairly late on a Sunday night. After logging off, we opened a case of Coors Light and spent the rest of the night (and part of the morning!) theorizing about what we might see tomorrow night (and getting rather drunk). At approximately 9:00 p.m. the following evening, we met again and logged onto the system to view the capture file, hoping to find something useful. We didn't have to look very far! The first transmission was just what we had been dreaming about all along. The computer we were monitoring initiated by connecting with a similar computer at another institution, waited for a particular control sequence to be sent, and then transferred a long sequence of numbers and letters. We captured about 170 different transactions on the first day and several hundred more in the following week. After one business week, we removed the file and directory, killed the TDT routine, and went through the system removing all traces that we had been there. We felt that we had enough to start piecing together what it all meant, so we uploaded our findings to the LOD HP-3000 (ARMA) in Turkey. This way we could both have access to the data, but keep it off our home systems. We didn't bother to tell any of the other LOD members about our doings, as most had retired, been busted, or were suspected of turning information over to the Secret Service. Using this as a base, we analyzed the findings, sorted them, looked for strings being sent, etc. We came to the conclusion that the transmissions were being sent in the following way: XXXXXXXXXXXXTCxxxxxxxxxxxx/NNNNNNNNNNNNCnnnnnnnnnnnnAMzzzzzzz.zzOP# X=Originating Bank ID T=Transfer (Also could be R(ecieve), I(nquire)) C=Type of account (Checking--Also S(avings) I(RA) M(oney Market) T(rust) W(Other wire transfer ie. Credit Transfer, etc.)) x=Originating Account Number /=Slash to divide string N=Destination Bank ID C=Type of account (See above) n=Destination Account Number AMzzzzzzz.zz=Amount followed by dollar and cents amount OP#=operator number supervising transaction After this string of information was sent, the destination bank would then echo back the transaction and, in ten seconds, unless a CONTROL-X was sent, would send "TRANSACTION COMPLETED" followed by the Destination Bank ID. We now needed to check out our theory about the Bank ID's, which I figured were the Federal Reserve number for the Bank. Every bank in America that deals with the Federal Reserve System has such a number assigned to it (as do several European Banks). I called up CitiBank and inquired about their Federal Reserve Number. It was the number being sent by the computer. With this information, we were ready to start. I consulted an accountant friend of mine for information on Swiss or Bahamanian bank accounts. He laughed and said that a $50,000 initial deposit was required to get a numbered account at most major Swiss banks. I told him to obtain the forms necessary to start the ball rolling and I'd wire the money over to the bank as soon as I was told my account number. This shook him up considerably, but he knew me well enough not to ask for details. He did, however, remind me of his $1000 consulting fee. A few days later he showed up at my townhouse with an account number, several transaction slips and paperwork. Knowing that I was up to something shady, he had used one of his own false identities to set up the account. He also raised his "fee" to $6500 (which was, amazingly enough, the amount he owed on his wife's BMW). My associate and I then flew to Oklahoma City to visit the hall of records to get new birth certificates. With these, we obtained new State ID's and Social Security Numbers. The next step was to set up bank accounts of our own. My associate took off to Houston and I went to Dallas. We each opened new commercial accounts at three different banks as LOD Inc. with $1000 cash. Early the next day, armed with one Swiss and six American accounts, we began our attack. We rigged the CitiCorp computer to direct all of its data flow to a local Telenet node, high up in the hunt series. Amazingly, it still allowed for connections from non-909/910 nodes. We took turns sitting on the node, collecting the transmissions and returning the correct acknowledgments. By 12:30 we had $184,300 in electronic funds in "Limbo." Next we turned off the data "forwarding" on the CitiCorp computer and took control of the host computer itself through the debug port to distribute the funds. Using its data lines, we sent all the transactions, altering the intended bank destinations, to our Swiss account. After I got the confirmation from the Swiss bank I immediately filled out six withdrawal forms and faxed them to the New York branch of the Swiss bank along with instructions on where the funds should be distributed. I told the bank to send $7333 to each of our six accounts (this amount being small enough not to set off Federal alarms). I did this for three consecutive days, leaving our Swiss account with $52,000. I signed a final withdrawal slip and gave it to my accountant friend. Over the next week we withdrew the $22,000 from each of our Dallas and Houston banks in lots of $5000 per day, leaving $1000 in each account when we were through. We were now $66,000 apiece richer. It will be interesting to see how the CitiCorp Internal Fraud Auditors and the Treasury Department sort this out. There are no traces of the diversion, it just seems to have happened. CitiBank has printed proof that the funds were sent to the correct banks, and the correct banks acknowledgment on the same printout. The correct destination banks, however, have no record of the transaction. There is record of CitiBank sending funds to our Swiss account, but only the Swiss have those records. Since we were controlling the host when the transactions were sent, there were no printouts on the sending side. Since we were not actually at a terminal connected to one of their line printers, no one should figure out to start contacting Swiss banks, and since CitiBank does this sort of thing daily with large European banks, they will be all twisted and confused by the time they find ours. Should they even get to our bank, they will then have to start the long and tedious process of extracting information from the Swiss. Then if they get the Swiss to cooperate, they will have a dead-end with the account, since it was set up under the guise of a non-entity. The accounts in Dallas and Houston were also in fake names with fake Social Security Numbers; we even changed our appearances and handwriting styles at each bank. I'm glad I'm not the one who will have the job of tracking me down, or even trying to muster up proof of what happened. Now we won't have to worry about disposable income for awhile. I can finish college without working and still live in relative luxury. It's kind of weird having over six-hundred $100 bills in a drawer, though. Too bad we can't earn any interest on it! ** Since the events described transpired, CitiBank has made their Banking Transaction Ports all refuse collect connections. Even by connecting with an NUI they now respond "<>". C'est La Vie. >--------=====END=====--------< ==Phrack Inc.== Volume Three, Issue 29, File #8 of 12 ........................................... ||||||!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!|||||| |||!!! !!!||| ||| The Myth and Reality About ||| ||| Eavesdropping ||| ||| ||| ||| by Phone Phanatic ||| ||| ||| |||... October 8, 1989 ...||| ||||||...............................|||||| !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Most Central Office (CO) eavesdropping intercepts in a Bell Operating Company (BOC) CO are today performed using a modified Metallic Facility Termination (MFT) circuit pack which places about a 100,000 ohm isolated bridging impedance across the subscriber line. Supervisory signaling is detected on the subscriber loop using a high-impedance electronic circuit, and the signaling is repeated in an isolated fashion using the A and B leads of the repeating coil in the MFT to "reconstruct" a CO line for the benefit of monitoring apparatus. The entire purpose of the above effort is to prevent any trouble or noise on the intercept line or monitoring apparatus from causing any trouble, noise or transmission impairment on the subject line. Some BOCs may elect to use service observing apparatus to provide the necessary isolation and repeated loop supervisory signaling. Less common are locally engineered variations which merely use an isolation amplifier from an MFT or other 4-wire repeater, and which provide no repeated supervisory signaling (which is not all that necessary, since voice-activated recorders and DTMF signaling detectors can be used, and since dial pulses can be counted by playing a tape at slow speed). Today, the use of a "bridge lifter" retardation coil for the purpose of connecting an eavesdropping intercept line is virtually non-existent since they do not provide sufficient isolation and since they provide a fair amount of insertion loss without loop current on the "observing" side. Bridge lifter coils are primarily intended for answering service intercept lines, and consist of a dual-winding inductor which passes 20 Hz ringing and whose windings easily saturate when DC current flows. Bridge lifter coils are used to minimize the loading effect (and consequent transmission impairment) of two subscriber loops on one CO line. Bridge lifter coils provide a significant insertion loss at voice frequencies toward the idle loop; i.e., the loop in use will have DC current flow, saturating the inductor, and reducing its insertion loss to 1.0 dB or less. Despite gadget advertised in magazines like The Sharper Image, the simple truth of the matter is that there is NO WAY for any person using ANY type of apparatus at the telephone set location to ascertain whether there is a properly installed eavesdropping device connected across their line in the CO. The only way such a determination can be made is through the cooperation of the telephone company. For that matter, there is virtually no way for any person using any type of apparatus in their premises to ascertain if there is ANY type of eavesdropping apparatus installed ANYWHERE on their telephone line outside their premises, unless the eavesdropping apparatus was designed or installed in an exceptionally crude manner (not likely today). Some types of eavesdropping apparatus may be located, but only with the full cooperation of the telephone company. The sole capability of these nonsense gadgets is to ascertain if an extension telephone is picked up during a telephone call, which is hardly a likely scenario for serious eavesdropping! These screw-in-the-handset gadgets work by sensing the voltage across the carbon transmitter circuit, and using a control to null this voltage using a comparator circuit. When a person makes a telephone call, the control is adjusted until the light just goes out. If an extension telephone at the user's end is picked up during the call, the increased current drain of a second telephone set will decrease the voltage across the carbon transmitter circuit, unbalancing the voltage comparator circuit, and thereby causing the LED to light. These voltage comparator "tap detectors" cannot even be left with their setpoint control in the same position, because the effective voltage across a subscriber loop will vary depending upon the nature of the call (except in the case of an all digital CO), and upon other conditions in the CO. Electromechanical and analog ESS CO's may present different characteristics to the telephone line, depending upon whether it is used at the time of: An originated intraoffice call (calling side of intraoffice trunk), an answered intraoffice call (called side of intraoffice trunk), an originated tandem call (interoffice tandem trunk), an originated toll call (toll trunk), or an answered tandem/toll call (incoming tandem or toll trunk). There is usually enough variation in battery feed resistance due to design and component tolerance changes on these different trunks to cause a variation of up to several volts measured at the subscriber end for a given loop and given telephone instrument. Even more significant are variations in CO battery voltage, which can vary (within "normal limits") from 48 volts to slightly over 52 volts, depending upon CO load conditions. 50 to 51 volts in most CO's is a typical daily variation. If anyone is curious, connect an isolated voltage recorder or data logger to a CO loop and watch the on-hook voltage variations; in many CO's the resultant voltage vs 24-hour time curve will look just like the inverse of a busy-hour graph from a telephone traffic engineering text! In some all-digital CO apparatus, the subscriber loop signaling is performed by a solid-state circuit which functions as a constant-current (or current-limiting) device. With such a solid-state circuit controlling loop current, there is no longer ANY meaningful reference to CO battery voltage; i.e., one cannot even use short-circuit loop current at the subscriber location to even estimate outside cable plant resistance. To explode this myth even further, let's do a little Ohm's Law: 1. Assume a CO loop with battery fed from a dual-winding A-relay (or line relay, ESS ferrod line scanner element, or whatever) having 200 ohms to CO battery and 200 ohms to ground. 2. Assume a CO loop of 500 ohms (a pretty typical loop). 3. Assume an eavesdropping device with a DC resistance of 100,000 ohms (this is still pretty crude, but I'm being generous with my example). 4. Using some simple Ohm's law, the presence or absence of this hypothetical eavesdropping device at the SUBSCRIBER PREMISES will result in a voltage change of less than 0.5 volt when measured in the on-hook state. This voltage change is much less than normal variations of CO battery voltage. 5. Using some simple Ohm's law, the presence or absence of this hypothetical eavesdropping device at the CENTRAL OFFICE LOCATION will result in a voltage change of less than 0.2 volt when measured in the on-hook state. This voltage change is an order of magnitude less than the expected normal variation of CO battery voltage! Measuring voltage variations on a subscriber loop in an effort to detect a state-of-the-art eavesdropping device is meaningless, regardless of resolution of a voltage measuring device, since the "signal" is in effect buried in the "noise". Moving on to the subject of subscriber line impedance... There is simply no way for any device located on the subscriber's premises to obtain any MEANINGFUL information concerning the impedance characteristics of the subscriber loop and whether or not anything "unusual" is connected at the CO (or for that matter, anywhere else on the subscriber loop). There are a number of reasons why this is the case, which include but are not limited to: 1. The impedance of a typical telephone cable pair results from distributed impedance elements, and not lumped elements. Non-loaded exchange area cable (22 to 26 AWG @ 0.083 uF/mile capacitance) is generally considered to have a characteristic impedance of 600 ohms (it actually varies, but this is a good compromise figure). Loaded exchange area cable, such as H88 loading which are 88 mH coils spaced at 6 kft intervals, is generally considered to have a a characteristic impedance of 900 ohms (it actually varies between 800 and 1,200 ohms, but 900 ohms is generally regarded as a good compromise figure for the voice frequency range of 300 to 3,000 Hz). What this means is that a bridged impedance of 100,000 ohms located in the CO on a typical subscriber loop will result in an impedance change measured at the SUBSCRIBER LOCATION of 0.1% or less. That's IF you could measure the impedance change at the subscriber location. 2. As a general rule of thumb, the impedance of an exchange area telephone cable pair changes ONE PERCENT for every TEN DEGREES Fahrenheit temperature change. Actual impedance changes are a function of the frequency at which the impedance is measured, but the above rule is pretty close for the purposes of this discussion. 3. Moisture in the telephone cable causes dramatic changes in its impedance characteristics. While this may appear obvious in the case of pulp (i.e., paper) insulated conductors, it is also characteristic of polyethylene (PIC) insulated conductors. Only gel-filled cable (icky-PIC), which still represents only a small percentage of installed cable plant, is relatively immune from the effects of moisture. 4. From a practical standpoint, it is extremely difficult to measure impedance in the presence of the DC potential which is ALWAYS found on a telephone line. The subscriber has no means to remove the telephone pair from the switching apparatus in the CO to eliminate this potential. Therefore, any attempt at impedance measurement will be subject to DC current saturation error of any inductive elements found in an impedance bridge. The telephone company can, of course, isolate the subscriber cable pair from the switching apparatus for the purpose of taking a measurement -- but the subscriber cannot. In addition to the DC current problem, there is also the problem of impulse and other types of noise pickup on a connected loop which will impress errors in the impedance bridge detector circuit. Such noise primarily results from the on-hook battery feed, and is present even in ESS offices, with ferrod scanner pulses being a good source of such noise. While one could possibly dial a telephone company "balance termination" test line to get a quieter battery feed, this still leaves something to be desired for any actual impedance measurements. 5. Devices which connect to a telephone pair and use a 2-wire/4-wire hybrid with either a white noise source or a swept oscillator on one side and a frequency-selective voltmeter on the other side to make a frequency vs return loss plot provide impressive, but meaningless data. Such a plot may be alleged to show "changes" in telephone line impedance characteristics. There is actual test equipment used by telephone companies which functions in this manner to measure 2-wire Echo Return Loss (ERL), but the ERL measurement is meaningless for localization of eavesdropping devices. 6. It is not uncommon for the routing of a subscriber line cable pair to change one or more times during its lifetime due to construction and modification of outside cable plant. Outside cable plant bridge taps (not of the eavesdropping variety) can come and go, along with back taps in the CO to provide uninterrupted service during new cable plant additions. Not only can the "active" length of an existing cable pair change by several percent due to construction, but lumped elements of impedance can come and go due to temporary or permanent bridge taps. The bottom line of the above is that one cannot accurately measure the impedance of a telephone pair while it is connected to the CO switching apparatus, and even if one could, the impedance changes caused by the installation of an eavesdropping device will be dwarfed by changes in cable pair impedance caused by temperature, moisture, and cable plant construction unknown to the subscriber. About a year ago on a bulletin board I remember some discussions in which there was mention of the use of a time domain reflectometer (TDR) for localization of bridge taps and other anomalies. While a TDR will provide a rather detailed "signature" of a cable pair, it has serious limitations which include, but are not limited to: 1. A TDR, in general, cannot be operated on a cable pair upon which there is a foreign potential; i.e., a TDR cannot be used on a subscriber cable pair which is connected to the CO switching apparatus. 2. A TDR contains some rather sensitive circuitry used to detect the reflected pulse energy, and such circuitry is extremely susceptible to noise found in twisted pair telephone cable. A TDR is works well with coaxial cable and waveguide, which are in effect shielded transmission lines. The use of a TDR with a twisted cable pair is a reasonable compromise provided it is a _single_ cable pair within one shield. The use of a TDR with a twisted cable pair sharing a common shield with working cable pairs is an invitation to interference by virtue of inductive and capacitive coupling of noise from the working pairs. 3. Noise susceptibility issues notwithstanding, most TDR's cannot be used beyond the first loading coil on a subscriber loop since the loading coil inductance presents far too much reactance to the short pulses transmitted by the TDR. There are one or two TDR's on the market which claim to function to beyond ONE loading coil, but their sensitivity is poor. There is simply no device available to a telephone subscriber that without the cooperation of the telephone company which can confirm or deny the presence of any eavesdropping device at any point beyond the immediate premises of the subscriber. I say "immediate premises of the subscriber" because one presumes that the subscriber has the ability to isolate the premises wiring from the outside cable plant, and therefore has complete inspection control over the premises wiring. I have used the phrase "without the cooperation of the telephone company" several times in this article. No voltage, impedance or TDR data is meaningful without knowing the actual circuit layout of the subscriber loop in question. Circuit layout information includes such data as exact length and guages of loop sections, detailed description of loading (if present), presence and location of multiples and bridge taps, calculated and measured resistance of the loop, loop transmission loss, etc. There is NO way that a telephone company is going to furnish that information to a subscriber! Sometimes it's even difficult for a government agency to get this information without judicial intervention. Despite what I have stated in this article, you will see claims made by third parties as to the existence of devices which will detect the presence of telephone line eavesdropping beyond the subscriber's immediate premises. With the exception of the trivial cases of serious DC current draw by an extension telephone or the detection of RF energy emitted by a transmitter, this just ain't so. Companies like Communication Control Corporation (which advertises in various "executive" business publications) get rich by selling devices which claim to measure minute voltage and impedance changes on a telephone line -- but consider those claims in view of the voltage changes due to CO battery variations and due to temperature changes in outside cable plant -- and you should get the true picture. >--------=====END=====--------< ==Phrack Inc.== Volume Three, Issue 29, File #9 of 12 \`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\ \`\ \`\ \`\ BLOCKING OF LONG-DISTANCE CALLS... REVISITED \`\ \`\ by Jim Schmickley \`\ \`\ \`\ \`\ Hawkeye PC, Cedar Rapids, Iowa \`\ \`\ \`\ \`\ Previosly Seen in Pirate Magazine \`\ \`\ \`\ \`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\ This file is a continuation of "Block Of Long-Distance Calls" that was seen in Phrack Inc. Issue 21, file 8. Although the material has already been released (perhaps on a limited basis) in Pirate Magazine, we felt the information was important enough to re-present (on a larger scale), especially considering it was an issue that we had previously detailed. -- Phrack Inc. Staff The following article begins where the previous article left off: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - November 17, 1988 Customer Service Teleconnect P.O. Box 3013 Cedar Rapids, IA 52406-9101 Dear Persons: I am writing in response to my October Teleconnect bill, due November 13, for $120.76. As you can see, it has not yet been paid, and I would hope to delay payment until we can come to some equitable table resolution of what appears to be a dispute. The records should show that I have paid previous bills responsibly. Hence, this is neither an attempt to delay nor avoid payment. My account number is: 01-xxxx-xxxxxx. My user phone is: 815-xxx-xxxx. The phone of record (under which the account is registered) is: 815-xxx-xxxx. If possible, you might "flag" my bill so I will not begin receiving dunning notices until we resolve the problem. I have several complaints. One is the bill itself, the other is the service. I feel my bill has been inflated because of the poor quality of the service you provide to certain areas of the country. These lines are computer lines, and those over which the dispute occurs are 2400 baud lines. Dropping down to 1200 baud does not help much. As you can see from my bill, there are numerous repeat calls made to the same location within a short period of time. The primary problems occured to the following locations: 1. Highland, CA 714-864-4592 2. Montgomery, AL 205-279-6549 3. Fairbanks, AK 907-479-7215 4. Lubbock, TX 806-794-4362 5. Perrine, FL 305-235-1645 6. Jacksonville, FL 904-721-1166 7. San Marcos, TX 512-754-8182 8. Birmingham, AL 205-979-8409 9. N. Phoenix, AZ 602-789-9269 <-- (The Dark Side BBS by The Dictator) The problem is simply that, to these destinations, Teleconnect can simply not hold a line. AT&T can. Although some of these destinations were held for a few minutes, generally, I cannot depend on TC service, and have more recently begun using AT&T instead. Even though it may appear from the records that I maintained some contact for several minutes, this time was useless, because I cold not complete my business, and the time was wasted. An equitable resolution would be to strike these charges from my bill. I would also hope that the calls I place through AT&T to these destinations will be discounted, rather than pay the full cost. I have enclosed my latest AT&T bill, which includes calls that I made through them because of either blocking or lack of quality service. If I read it correctly, no discount was taken off. Is this correct? As you can see from the above list of numbers, there is a pattern in the poor quality service: The problem seems to lie in Western states and in the deep south. I have no problem with the midwest or with numbers in the east. I have been told that I should call a service representative when I have problems. This, however, is not an answer for several reasons. First, I have no time to continue to call for service in the middle of a project. The calls tend to be late at night, and time is precious. Second, on those times I have called, I either could not get through, or was put on hold for an indeterminable time. Fourth, judging from comments I have received in several calls to Teleconnect's service representatives, these seem to be problems for which there is no immediate solution, thus making repeated calls simply a waste of time. Finally, the number of calls on which I would be required to seek assistance would be excessive. The inability to hold a line does not seem to be an occasional anomaly, but a systematic pattern that suggests that the service to these areas is, indeed, inadequate. A second problem concerns the Teleconnect policy of blocking certain numbers. Blocking is unacceptable. When calling a blocked number, all one receives is a recorded message that "this is a local call." Although I have complained about this once I learned of the intentional blocking, the message remained the same. I was told that one number (301-843-5052) would be unblocked, and for several hours it was. Then the blocking resumed. A public utility simply does not have the right to determine who its customers may or may not call. This constitutes a form of censorship. You should candidly tell your customers that you must approve of their calls or you will not place them. You also have the obligation to provide your customers with a list of those numbers you will not service so that they will not waste their time attempting to call. You might also change the message that indicates a blocked call by saying something "we don't approve of who you're calling, and won't let you call." I appreciate the need to protect your customers. However, blocking numbers is not appropriate. It is not clear how blocking aids your investigation, or how blocking will eliminate whatever problems impelled the action. I request the following: 1. Unblock the numbers currently blocked. 2. Provide me with a complete list of the numbers you are blocking. 3. End the policy of blocking. I feel Teleconnect has been less than honest with its customers, and is a bit precipitous in trampling on rights, even in a worthy attempt to protect them from abuses of telephone cheats. However, the poor quality of line service, combined with the apparrent violation of Constitutional rights, cannot be tolerated. Those with whom I have spoken about this matter are polite, but the bottom line is that they do not respond to the problem. I would prefer to pay my bill only after we resolve this. Cheerfully, (Name removed by request) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - /*/ ST*ZMAG SPECIAL REPORT - by Jerry Cross /*/ (reprinted from Vol. #28, 7 July, 1989) =============================================== TELECONNECT CALL BLOCKING UPDATE Ctsy (Genesee Atari Group) Background ~~~~~~~~~~ At the beginning of last year one of my bbs users uploaded a file he found on another bbs that he thought I would be interested in. It detailed the story of an Iowa bbs operator who discovered that Teleconnect, a long distance carrier, was blocking incoming calls to his bbs without his or the callers knowledge. As an employee of Michigan Bell I was very interested. I could not understand how a company could interfere with the transmissions of telephone calls, something that was completely unheard of with either AT&T or Michigan Bell in the past. The calls were being blocked, according to Teleconnect public relations officials, because large amounts of fraudulent calls were being placed through their system. Rather than attempting to discover who was placing these calls, Teleconnect decided to take the easy (and cheap) way out by simply block access to the number they were calling. But the main point was that a long distance company was intercepting phone calls. I was very concerned. I did some investigating around the Michigan area to see what the long distance carriers were doing, and if they, too, were intercepting or blocking phone calls. I also discovered that Teleconnect was just in the process of setting up shop to serve Michigan. Remember, too, that many of the former AT&T customers who did not specify which long distance carrier they wanted at the time of the AT&T breakup were placed into a pool, and divided up by the competing long distance companies. There are a number of Michigan users who are using certain long distance carriers not of their choice. My investigation discovered that Michigan Bell and AT&T have a solid, computer backed security system that makes it unnecessary for them to block calls. MCI, Sprint, and a few other companies would not comment or kept passing me around to other departments, or refused to comment about security measures. I also discussed this with Michigan Bell Security and was informed that any long distance company that needed help investigating call fraud would not only receive help, but MBT would actually prepare the case and appear in court for prosecution! My calls to Teleconnect were simply ignored. Letters to the public service commission, FCC, and other government departments were also ignored. I did, however, get some cooperation from our U.S. Representative Dale Kildee, who filed a complaint in my name to the FCC and the Interstate Commerce Commission. What follows is their summary of an FCC investigation to Mr. Kildee's office. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dear Congressman Kildee: This is in further response to your October 18, 1988 memorandum enclosing correspondence from Mr. Gerald R. Cross, President of the Genesee Atari Group in Flint, Michigan concerning a reported incidence of blocking calls from access to Curt Kyhl's Stock Exchange Bulletin Board System in Waterloo, Iowa by Teleconnect, a long distance carrier. Mr. Cross, who also operates a bulletin board system (bbs), attaches information indicating that Teleconnect blocked callers from access via its network to Mr. Kyhl's BBS number in an effort to prevent unauthorized use of its customers' long distance calling authorization codes by computer "hackers." Mr. Cross is concerned that this type of blocking may be occurring in Michigan and that such practice could easily spread nationwide, thereby preventing access to BBSs by legitimate computer users. On November 7, 1988, the Informal Complaints Branch of the Common Carrier Bureau directed Teleconnect to investigate Mr. Cross' concerns and report the results of its investigation to this Commission. Enclosed, for your information, is a copy of Teleconnect's December 7, 1988 report and its response to a similar complaint filed with this Commission by Mr. James Schmickley. In accordance with the commission's rules, the carrier should have forwarded a copy of its December 7, 1988 report to Mr. Cross at the same time this report was filed with the Commission. I apologize for the delay in reporting the results of our investigation to your office. Teleconnect's report states that it is subject to fraudulent use of its network by individuals who use BBSs in order to unlawfully obtain personal authorization codes of consumers. Teleconnect also states that computer "hackers" employ a series of calling patterns to access a carrier's network in order to steal long distance services. The report further states that Teleconnect monitors calling patterns on a 24 hour basis in an effort to control, and eliminate when possible, code abuse. As a result of this monitoring, Teleconnect advises that its internal security staff detected repeated attempts to access the BBS numbers in question using multiple seven-digit access codes of legitimate Teleconnect customers. These calling patterns, according to Teleconnect, clearly indicated that theft of telecommunications services was occurring. The report states that Teleconnect makes a decision to block calls when the estimated loss of revenue reaches at least $500. Teleconnect notes that blocking is only initiated when signs of "hacking" and other unauthorized usage are present, when local calls are attempted over its long distance network or when a customer or other carrier has requested blocking of a certain number. Teleconnect maintains that blocking is in compliance with the provisions of Section A.20.a.04 of Teleconnect's Tariff FCC No. #3 which provides that service may be refused or disconnected without prior notice by Teleconnect for fraudulent unauthorized use. The report also states that Teleconnect customers whose authorizations codes have been fraudulently used are immediately notified of such unauthorized use and are issued new access codes. Teleconnect further states that while an investigation is pending, customers are given instructions on how to utilize an alternative carrier's network by using "10XXX" carrier codes to access interstate or intrastate communications until blocking can be safely lifted. Teleconnect maintains that although its tariff does not require prior notice to the number targeted to be blocked, it does, in the case of a BBS, attempt to identify and contact the Systems Operator (SysOp), since the SysOp will often be able to assist in the apprehension of an unauthorized user. The report states that with regard to Mr. Kyle's Iowa BBS, Teleconnect was unable to identify Mr. Kyle as the owner of the targeted number because the number was unlisted and Mr. Kyhl's local carrier was not authorized to and did not release any information to Teleconnect by which identification could be made. The report also states that Teleconnect attempted to directly access the BBS to determine the identity of the owner but was unable to do so because its software was incompatible with the BBS. Teleconnect states that its actions are not discriminatory to BBSs and states that it currently provides access to literally hundreds of BBSs around the country. The report also states that Teleconnect's policy to block when unauthorized use is detected is employed whether or not such use involves a BBS. Teleconnect advises that when an investigation is concluded or when a complaint is received concerning the blocking, the blocking will be lifted, as in the case of the Iowa BBS. However, Teleconnect notes that blocking will be reinstated if illegal "hacking" recurs. Teleconnect advises that it currently has no ongoing investigations within the State of Michigan and therefore, is not presently blocking any BBSs in Michigan. However, Teleconnect states that it is honoring the request of other carriers and customers to block access to certain numbers. The Branch has reviewed the file on this case. In accordance with the Commission's rules for informal complaints it appears that the carrier's report is responsive to our Notice. Therefore, the Branch, on its own motion, is not prepared to recommend that the Commission take further action regarding this matter. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - This letter leaves me with a ton of questions. First, let's be fair to Teleconnect. Long distance carriers are being robbed of hundreds of thousands of dollars annually by "hackers" and must do something to prevent it. However, call blocking is NOT going to stop it. The "hacker" still has access to the carrier network and will simply start calling other numbers until that number, too, is blocked, then go on to the next. The answer is to identify the "hacker" and put him out of business. Teleconnect is taking a cheap, quick fix approach that does nothing to solve the problem, and hurts the phone users as a whole. They claim that their customers are able to use other networks to complete their calls if the number is being blocked. What if other networks decide to use Teleconnect's approach? You would be forced to not only keep an index of those numbers you call, but also the long distance carrier that will let you call it! Maybe everyone will block that number, then what will you do? What if AT&T decided to block calls? Do they have this right too? And how do you find out if the number is being blocked? In the case of Mr. Kyhl's BBS, callers were given a recording that stated the number was not in service. It made NO mention that the call was blocked, and the caller would assume the service was disconnect. While trying to investigate why his calls were not going through, Mr. James Schmickley placed several calls to Teleconnect before they finally admitted the calls were being blocked! Only after repeated calls to Teleconnect was the blocking lifted. It should also be noted that Mr. Kyhl's bbs is not a pirate bbs, and has been listed in a major computer magazine as one of the best bbs's in the country. As mentioned before, MBT will work with the long distance carriers to find these "hackers." I assume that the other local carriers would do the same. I do not understand why Teleconnect could not get help in obtaining Mr. Kyhl's address. It is true the phone company will not give out this information, but WILL contact the customer to inform him that someone needs to contact him about possible fraud involving his phone line. If this policy is not being used, maybe the FCC should look into it. Call blocking is not restricted to BBSs, according to Teleconnect. They will block any number that reaches a $500 fraud loss. Let's say you ran a computer mail order business and didn't want to invest in a WATS line. Why should an honest businessman be penalized because someone else is breaking the law? It could cost him far more the $500 from loss of sales because of Teleconnect's blocking policy. Teleconnect also claims that "they are honoring the request of other carriers and customers to block access to certain numbers." Again, MBT also has these rules. But they pertain to blocking numbers to "certain numbers" such as dial-a-porn services, and many 900-numbers. What customer would ever request that Teleconnect block incoming calls to his phone? And it is an insult to my intelligence for Teleconnect to claim they could not log on to Mr. Kyhl's BBS. Do they mean to say that with hundreds of thousands of dollars in computer equipment, well trained technicians, and easy access to phone lines, that they can't log on to a simple IBM bbs? Meanwhile, here I sit with a $50 Atari 800xl and $30 Atari modem and I have no problem at all accessing Mr. Kyhl's bbs! What's worse, the FCC (the agency in charge of regulating data transmission equipment), bought this line too! Incredible!!! And finally, I must admit I don't have the faintest idea what Section A.20.a.04 of Teleconnect's Tariff FCC No. 3 states, walk into your local library and ask for this information and you get a blank look from the librarian. I know, I tried! However, MBT also has similar rules in their tariffs. Teleconnect claims that the FCC tariff claims that "service may be refused or disconnected without prior notice by Teleconnect for fraudulent, unauthorized use". This rule, as applied to MBT, pertains ONLY to the subscriber. If an MBT customer were caught illegally using their phone system then MBT has the right to disconnect their service. If a Teleconnect user wishes to call a blocked number, and does so legally, how can Teleconnect refuse use to give them service? This appears to violate the very same tarriff they claim gives them the right to block calls! I have a few simple answers to these questions. I plan, once again, to send out letters to the appropriate agencies and government representatives, but I doubt they will go anywhere without a mass letter writing campaign from all of you. First, order that long distance companies may not block calls without the consent of the customer being blocked. Every chance should be given to him to assist in identifying the "hacker," and he should not be penalized for other people's crimes. There should also be an agency designated to handle appeals if call blocking is set up on their line. Currently, there is no agency, public service commission, or government office (except the FCC) that you can complain to, and from my experience trying to get information on call blocking I seriously doubt that they will assist the customer. Next, order the local phone carriers to fully assist and give information to the long distance companies that will help identify illegal users of their systems. Finally, order the Secret Service to investigate illegal use of long distance access codes in the same manner that they investigate credit card theft. These two crimes go hand in hand. Stiff fines and penalties should be made mandatory for those caught stealing long distance services. If you would like further information, or just want to discuss this, I am available on Genie (G.Cross) and CompuServe (75046,267). Also, you can reach me on my bbs (FACTS, 313-736-4544). Only with your help can we put a stop to call blocking before it gets too far out of hand. >--------=====END=====--------< >--------=====END=====--------< ==Phrack Inc.== Volume Three, Issue 29, File #10 of 12 PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN P h r a c k W o r l d N e w s PWN PWN ~~~~~~~~~~~ ~~~~~~~~~ ~~~~~~~ PWN PWN Issue XXIX/Part 1 PWN PWN PWN PWN November 17, 1989 PWN PWN PWN PWN Created, Written, and Edited PWN PWN by Knight Lightning PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN Welcome to Issue XXIX of Phrack World News! Although Phrack Inc. is officially four years old, Phrack World News is not. PWN originally in its first issue (which was in Phrack Inc. II... its a long story) was known as "Phreak World News," but quickly changed and starting with Phrack Inc. Issue III became Phrack World News as you see it today. This issue of Phrack World News contains stories and articles detailing events and other information concerning AT&T, Clifford Stoll, Kent O'Brien, Kevin David Mitnick, Datacrime, DEC, FAX, FCC, Galactic Hackers Party, IBM, Lawrence Livermore National Laboratory, Leonard Mitchell DiCicco, MCI, NASA, Robert Morris, Shockwave Rider, SummerCon '89, The "NEW" TAP Magazine, 2600 Magazine, Viruses, Worms Against Nuclear Killers, and much more so keep reading and enjoy. :Knight Lightning "The Real Future Is Behind You... And It's Only The Beginning!" _______________________________________________________________________________ Judge Proposes Community Service For Hacker's Accomplice October 13, 1989 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ by Kathy McDonald (New York Times) LOS ANGELES -- A federal judge says she is inclined to sentence a man who pleaded guilty to helping computer hacker Kevin Mitnick steal a computer security program to community service and asked him to submit a proposal on such a sentence. U.S. District Judge Mariana R. Pfaelzer said Leonard Mitchell DiCicco, of unincorporated suburban Calabasas, had been helpful in the case, in which he reported Mitnick to officers at Digital Equipment Corporation in Massachusetts. Mitnick has admitted he stole a DEC computer security program and electronically brought it to California. Pfaelzer gave DiCicco, age 23, until November 1 to come up with a detailed proposal for his community service. "I favor the handicapped, older people, something which is out in the community," Pfaelzer said. DiCicco pleaded guilty in July to one count of aiding and abetting the interstate transportation of stolen property. He admitted that in 1987 he let Mitnick, age 25, of suburban Panorama City, use his office computer at Voluntary Plan Administrators in Calabasas to break into the DEC system. Mitnick pleaded guilty and was sentenced in July to one year in prison and six months in a community treatment program aimed at breaking his "addiction" to computer hacking. Under a plea agreement with the government, DiCicco pleaded guilty in exchange for a promise that he would not be prosecuted for any of the other instances of computer hacking he and Mitnick carried out. He said after Thursday's (October 12) court appearance that he would like to put his computer talents to use to help others. Assistant U.S. Attorney James Asperger did not object to giving DiCicco community service rather than a prison term, saying: "I think Mr. DiCicco's cooperation in this case was essential to the prosecution of both Mr. Mitnick and himself. He is certainly lower in culpability than Mr. Mitnick." - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If you are looking for other articles related to Leonard Mitchell DiCicco and the famous Kevin David Mitnick please refer to; "Pacific Bell Means Business" (10/06/88) PWN XXI....Part 1 "Dangerous Hacker Is Captured" (No Date ) PWN XXII...Part 1 "Ex-Computer Whiz Kid Held On New Fraud Counts" (12/16/88) PWN XXII...Part 1 "Dangerous Keyboard Artist" (12/20/88) PWN XXII...Part 1 "Armed With A Keyboard And Considered Dangerous" (12/28/88) PWN XXIII..Part 1 "Dark Side Hacker Seen As Electronic Terrorist" (01/08/89) PWN XXIII..Part 1 "Mitnick Plea Bargains" (03/16/89) PWN XXV....Part 1 "Mitnick Plea Bargain Rejected As Too Lenient" (04/25/89) PWN XXVII..Part 1 "Computer Hacker Working On Another Plea Bargain" (05/06/89) PWN XXVII..Part 1 "Mitnick Update" (05/10/89) PWN XXVII..Part 1 "Kenneth Siani Speaks Out About Kevin Mitnick" (05/23/89) PWN XXVII..Part 1 "Judge Suggests Computer Hacker Undergo Counseling"(07/17/89) PWN XXVIII.Part 1 "Authorities Backed Away From Original Allegations"(07/23/89) PWN XXVIII.Part 1 _______________________________________________________________________________ How Hacker Jammed 911 Police Lines October 4, 1989 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ by Benny Evangelista He is a brilliant, but lonely teenage computer hacker with too much time on his hands. And the police said the 16-year-old San Gabriel boy used that time to put a sophisticated high-tech spin on age-old teenage telephone pranks by tying up police emergency lines from Hayward, California to Cedar Rapids, Iowa, and harassing other people, all from what he thought was the safety of his home Commodore 64 computer. The calls that jammed Hayward police and Alameda County sheriff's lines were potentially dangerous, but officials said that no emergency was neglected because of them. This is the way he got his kicks, but he had most of us just absolutely crazed," said Connie Bullock, security director for one of the long-distance companies that suffered thousands of dollars of losses. The boy, who police would not identify because of his age, is scheduled to be arraigned October 16th in Los Angeles County Juvenile Court for making telephone bomb threats, fraudulently obtaining long-distance telephone service, interfering with a police officer and making harassing phone calls. "Our goal is to get him on probation so we can doctor him for the next couple of years," said Sgt. Bernie Kammer, of the Los Angeles County sheriff's computer crime detail. "Hopefully, he may be one of the guys who sends the next space capsule up," Kammer said. The hacker, who has used handles like "Kent O'Brien," surfaced sometime last October, said Bullock, director of network security for ComSystems Incorporated, a Van Nuys-based long distance company. Bullock learned that someone had tapped into the electronic phone mail system of a Cedar Rapids-based long-distance company using ComSystems lines. A security officer for the Iowa company began receiving harassing and threatening calls, some at home in the middle of the night, she said. The hacker became good at cracking home answering-machine codes in the Southern California area and possibly elsewhere, and changed several outgoing messages, she said. He also broke into the phone mail system at Sears administrative office in Hayward, California and called workers there, she said. He even commandeered one phone mail box and had other people leave messages. He would also make anonymous calls or just let the phone ring in the middle of the night and hang up. He phoned in bomb threats to his old high school and a fast-food restaurant, Kammer said. In all cases, he used a computer synthesizer to disguise his voice, Kammer said. And he routed the calls in ways to make tracing impossible. Then he started calling Cedar Rapids police emergency 911 lines, bombarding dispatchers in the middle of the night with a series of computer-assisted calls that would tie up the lines for hours. He would make small talk and ask about the weather, said Cedar Rapids Detective Stan McCurg. The boy could call up five or six other people, hold their lines captive and route the calls to police, McCurg said. "The scary thing is he had the capability to screw you over and you couldn't do anything about it," McCurg said. Police say the boy pulled the same trick on the Alameda County Sheriff's office, San Francisco police and the Los Angeles County sheriff's office in Crescrenta Valley. The calls did not cause any safety problems, but there was always that potential, Kammer said. The big break came after the boy started calling Hayward police dispatchers in late February. At first, the dispatchers played along, trying to find out who and where the boy was while the boy gave false clues to throw them off. "It was like, 'Catch me if you can,'" said Hayward Detective Dennis Kutsuris. On March 2, dispatchers kept him talking from 8:10 a.m. to 1:20 p.m., long enough to trace the call to his San Gabriel home. That night, police served a search warrant and found the boy in bed talking on the phone using his synthesizer. The hacker was a lonely boy who dropped out of high school because it didn't challenge him, but had passed his general education equivalency exam and was taking courses from a community college, according to Kammer and Bullock. Police seized the computer equipment, but formal charges were not filed until last month because of the complex followup investigation, Kammer said. Bullock said her company lost about $71,000 worth of calls, plus four angered customers. Kammer said although police believe the loss could be "hundreds of thousands" of dollars, they can only prove the loss of $2000 in court. In the meantime, Hayward police received another call September 6th from a computer-synthesized voice that they feel came from the boy. Kammer said a relative had given the boy another computer, but they have no proof that he was back to his old tricks. Still, that incident, along with Cedar Rapids police reports will be used for a probation report, Kammer said. Bullock said the case was intriguing at first, but became frustrating as her file grew to 2 feet thick. "He had me by the guts," she said. "I was obsessed with finding him. He's a typical 16-year old, but a little more menacing. He is pretty smart, but he had absolutely nothing to do, but sit in his room with his computer equipment and all he had to do was talk on the phone." _______________________________________________________________________________ Just The FAX, Please November 6, 1989 ~~~~~~~~~~~~~~~~~~~~ by Noam Cohen (New York Times) Teachers in rural Minnesota are ready to hear the most up-to-date version of the oldest excuse in the book: "Honest, teach, the fax ate my homework." Yes, the facsimile machine has gone to school in Sibley County, an agricultural area 60 miles southwest of Minneapolis-St. Paul. It is the last component to be installed in a four-year-old interactive television system, or ITV, that brings advanced classroom instruction to small, isolated areas through closed-circuit cable television. In an education system where students adjust the contrast knobs to get a better look at their calculus teacher, it is hardly surprising that these students are the first in the country to use the fax to receive or hand in homework. David Czech, the telecommunications director for the school district who is responsible for its cable system education program, said that now, televised teachers can even give surprise quizzes. "The fax makes the classroom truly self-contained," said Kelly Smith, an assistant principal at Gibbon-Fairfax-Winthrop High School, in Sibley County, who taught mathematics for the ITV program before fax machines were introduced. He said that when he taught he "had to rely on transportation in the district and assignments always stacked up." The fax machines, part of a special line made by Ricoh Corporation, transmit on the same wiring that carries the television image to students. By using cable instead of telephones, the district saves money on telephone costs and receives quicker, cleaner copies. The machines have a built-in copier, allowing one student to retrieve the assignment and hand copies to classmates (usually no more than eight). Students then use the machine to hand back work. The Sibley County school district purchased and installed the fax machines with the remaining $22,000 of a $150,000 state grant for ITV, according to Czech. The machines, which school officials and a Ricoh spokeswoman say are the first to be used in high school education, have generated interest elsewhere. Czech says he has received calls from education officials in Hawaii, Wisconsin, Ohio and other parts of Minnesota. _______________________________________________________________________________ MCI Sues AT&T -- Charges Deceptive Advertising October 12, 1989 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "We Welcome The Opportunity To Discuss Who Is Misleading Whom..." AT&T is using false and malicious advertising to protect its long-distance business, MCI Communications Corporation charges in a lawsuit filed Tuesday, October 10. MCI, whose 10 percent market share makes it a distant number two to AT&T's 75 percent, says its giant rival is resorting to false claims in the hope of stemming the loss of 100,000 customers to MCI each week. AT&T, however, says it will defend itself with a countersuit. According to AT&T spokesman Herb Linnen: "We welcome the opportunity to discuss who is misleading whom... we have been quite concerned for some time now about MCI's misleading print and broadcast advertising. We have taken our complaints directly to MCI without success." He added, "AT&T stands behind its advertising." This latest litigation is simply the latest chapter in MCI's long and very bitter battle with AT&T, which began in the 1970's when MCI successfully broke AT&T's long-distance monopoly by offering "Execunet," the first long-distance service bypassing AT&T offered to the public. The two companies have battled each other at the Federal Communications Commission, which authorizes the rates for each, ever since. This is the first time since AT&T's divestiture that the arguments have been taken into a courtroom. In an interview, MCI Chairman William McGowan said that "AT&T ads are sleazy," and he noted that the nine month old campaign grew increasingly negative, forcing MCI into the courts. AT&T responded saying that MCI is resorting to the courts since "...they just can't hack it in the marketplace..." McGowan responded that he believes a lawsuit is the only way to fight a company which is spending two million dollars a day on advertising. He said, "Our budget is big -- $51 million -- but how do you compete with someone who is nine or ten times your size in advertising?" MCI is still studying the impact of the latest round of AT&T ads, but McGowan said he is sure MCI should have gained "a lot more" than 100,000 customers per week if not for the advertising. The advertising has not affected professional telecommunications managers, but does have an impact on individual and small business customers, he said. The MCI suit, filed in U.S. District Court in Washington, DC, alleges that AT&T's advertising campaign "maliciously attacked MCI's honesty and the value of MCI's products and service by falsely and deceptively representing that it is superior to its competitors in general, and MCI in particular, in terms of trustworthiness, quality and price. MCI's suit cites AT&T ads that assert MCI's rates are cheaper than AT&T's only when calls are made over 900 miles away and after 7 p.m. MCI's suit also takes umbrage at AT&T's advertisement which states that MCI customers "might have better luck calling Mars than trying to reach MCI representatives for an explanation of their bills." The ads, the suit charges, also claim non-AT&T companies provide slow telephone connections; that other companies do not operate worldwide like AT&T; and that competing 800, facsimile and WATS services are inferior. The suit says AT&T "has wrongfully profited and MCI has been damaged by being wrongfully thwarted from maximizing its sales potential." The suit asks the court to order AT&T to discontinue advertising its services for a period of one year and that advertisements after that time be approved by the court and carry a notice to that effect in the advertisement itself. Additionally, it asks for profits "wrongfully amassed" by AT&T on the sale of its products and services during the past year, plus interest and legal fees. McGowan was particularly irked by a claim that MCI's fax service has 57 percent more problems than AT&T faxes. He said that number was arrived at by figuring the difference between AT&T service -- with 4.9 percent errors -- and MCI, with 7.7 percent errors. Rather than reporting the 2.8 percent difference, the ad claims a 57 percent higher rate -- the percentage increase between 4.9 percent and 7.7 percent. "Talk about misleading," McGowan said. "Yes, talk about misleading," said Herb Linnen. "They've survived this long in part based on the deceptions they've used on a public not well educated on the technical aspects of telephony... we'll clear this up once and for all in court with a countersuit." - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Unleashing Ma Bell October 24, 1989 ~~~~~~~~~~~~~~~~~~ by Peter Passell (New York Times) Could AT&T's rivals in long-distance phone service survive no-holds-barred competition? Since the breakup of the telephone monopoly in 1984, the Federal Communications Commission has kept AT&T on a short leash to prevent the giant company from chewing up the "small fry." But now two of those small fry have grown into profitable multibillion-dollar corporations, and AT&T is asking the regulators for the freedom to fight for market share. If the FCC agrees -- a crucial decision could come as early as Thursday -- high-volume telephone users are likely to reap a bonanza from lower prices. When the Bell System was dismembered, analysts generally agreed that rivals would need a lot of help from Washington to gain a secure foothold in the long-distance market dominated by the ultimate name-brand company. The analysts were right: After AT&T's competitors lost their discounts on regulated charges for hookups to local telephone exchanges, all of them took a financial bath and some went broke. But in the ensuing consolidation, a few companies emerged with both the technical capacity to match AT&T's service and the marketing savvy to sell themselves to once-skeptical consumers. MCI Communications now has 12 percent of the long-distance market and in the last year has grown four times as fast as AT&T. US Sprint Communications, with its much-ballyhooed all-fiber-optic system, has an 8 percent share and is the principal carrier for 117 of America's 800 largest companies. Joel Gross, a communications analyst at Donaldson, Lufkin & Jenrette, believes a fourth network, assembled from a half-dozen smaller companies, will soon emerge. One reason AT&T's rivals have managed to do so well in the last few years is continuing regulatory discrimination. Last summer, the FCC switched AT&T from traditional fair-rate-of-return regulation to a more flexible "price-cap" system that gives the company discretion to adjust individual rates within a narrow price band. But neither the old price regulations nor the new ones apply to MCI, US Sprint and other smaller long-distance companies. And they have taken advantage of AT&T's inability to cut prices, offering volume discounts where AT&T is most vulnerable to customer defections. AT&T has fought back, convincing the FCC to allow it fast-track approval for rate concessions needed to hang onto its biggest customers. And it is now asking the commission for broad discretion to cut rates by more than the 5 percent permitted under the price-cap rule. If the FCC agrees, it is a sure bet that AT&T will price aggressively, accepting sharp reductions in its fat profit margins to check its loss of market share. It is obvious why MCI and US Sprint are unhappy at the prospect of an AT&T unleashed. But it is not so easy to see how the public would lose from the ensuing donnybrook. One worry is that AT&T would slash prices by enough to drive rivals out of business, and then be free to price-gouge. But as Peter Pitsch, a former FCC staff member who now consults for AT&T points out, such "predatory" pricing is only a plausible option if the predator can hope to make up the inevitable short-term losses with long-term monopoly gains. And two considerations make such a calculation unlikely. Once the cables have been laid and the switches installed, it costs very little to operate a long-distance phone system. Thus even if AT&T were able to drive MCI and US Sprint into bankruptcy, their creditors would find it advantageous to continue to sell long-distance services. And if AT&T somehow did manage to shut down its rivals, the FCC would hardly be likely to reward it with permission to charge monopoly prices. Another concern is that price-cutting would make long-distance service unprofitable for all, discouraging further investment. That, however, might not be such a bad thing. Losses are capitalism's way of telling businesses to slow down: There is enormous overcapacity in long-distance communications and more investment anytime soon is unlikely to be productive. Does all this mean the commission will hang tough and permit AT&T to flex its competitive muscles? A year ago, when the FCC was dominated by Reagan-appointed free marketers, the answer would have been easy. Today, with a Bush-appointed majority led by a chairman, Alfred Sikes, of less certain ideological bent, it is hard to say. MCI and US Sprint have managed to squeeze a lot of regulatory mileage out of their underdog status, and certainly will not give up the privileges that go along without a fight. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - AT&T Strikes Back: Countersues MCI October 27, 1989 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ AT&T struck back on Thursday, October 27 at advertising claims made by MCI Communications Corporation and received two rulings from the Federal Communications Commission affecting regulation of its long distance services. AT&T said in a countersuit against MCI filed in Washington, DC that MCI was misleading consumers through false and deceptive advertising in its business and residential long distance service. AT&T's filing denied similar allegations made by MCI in a suit filed October 10. Victor Pelson, AT&T group executive, said MCI unfairly compared its discount service with AT&T's regular long distance service rather than its discount service. Pelson also denied claims that the quality of MCI voice service was superior to AT&T's, or that its facsimile service featured fewer garbled transmissions than AT&T's. "We intend to clarify any misconceptions in the market," said Merrill Tutton, AT&T Vice President for consumer marketing. MCI spokeswoman Kathleen Keegan Thursday responded that, "our ad claims are accurate... We will soon be filing a motion for a preliminary injunction to cause AT&T to cease its advertising campaign." Also on Thursday, the Federal Communications Commission upheld a decision giving AT&T greater freedom to compete for big corporate customers but rejected another pricing plan by AT&T. The FCC voted unanimously to uphold a pricing plan known as Tariff 12, which lets AT&T offer corporate customers a package of communications services. AT&T contends it is at a disadvantage because MCI does not have to submit detailed filings to the FCC before they can serve customers. MCI had challenged Tariff 12, asking the FCC to overrule it and prohibit AT&T from offering full service communications packages to its customers. In the second item, the FCC declared unlawful a pricing plan known as Tariff 15, that AT&T had applied solely to a single customer, the Holiday Corporation, owner of the largest hotel chain in the United States. The FCC said AT&T could no longer justify the special rates to a single customer to meet competition when MCI was making the same service available to customers generally. >--------=====END=====--------< ==Phrack Inc.== Volume Three, Issue 29, File #11 of 12 PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN P h r a c k W o r l d N e w s PWN PWN ~~~~~~~~~~~ ~~~~~~~~~ ~~~~~~~ PWN PWN Issue XXIX/Part 2 PWN PWN PWN PWN November 17, 1989 PWN PWN PWN PWN Created, Written, and Edited PWN PWN by Knight Lightning PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN Offensive Message Flashes At Busy City Corner October 25, 1989 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ by Linda Wheeler (Washington Post) An offensive message that mystified the owners of an electronic information board was flashed Monday, October 23 at Connecticut Avenue and L Street NW, one of the city's (Washington DC) busiest intersections. A Georgetown University law student, Craig Dean, said he saw the message; "HELP STAMP OUT A.I.D.S. NOW: KILL ALL QUEERS AND JUNKIES" It flashed five times in 25 minutes. Minutes after seeing the message, he called the city Human Rights Office and the Washington Blade, a gay community newspaper. Doug Hinckle, a staff photographer for the Blade, saw the message flash once and photographed it. Judith Miller, president of Miller Companies, which own the building at 1101 Connecticut Avenue NW and the message board, said she did not know how the statement got onto the board. She refused to believe it had appeared until she was shown of the photographs. Her company has complete control of the board and does not accept any paid messages or advertisements, Miller said. "I would never do anything like that," she said. "There is no way I would allow such a statement to appear." Yesterday, Keller, a five-year employee of the Miller Companies, said he did not write the statement and does now know how it became part of the normal flow of headline news. Miller said she believes her computer system may have a "virus" and will have experts search to find where the unauthorized statement originated. "How absolutely awful," she said of the message. _______________________________________________________________________________ "WANK" Worm On SPAN Network October 17, 1989 ~~~~~~~~~~~~~~~~~~~~~~~~~~~ >From The Computer Emergency Response Team On October 16, the CERT received word from SPAN network control that a worm was attacking SPAN VAX/VMS systems. This worm affects only DEC VMS systems and is propagated via DECnet protocols, not TCP/IP protocols. If a VMS system had other network connections, the worm was not programmed to take advantage of those connections. The worm is very similar to last year's HI.COM (or Father Christmas) worm. This is NOT A PRANK. Serious security holes are left open by this worm. The worm takes advantage of poor password management, modifies .com files, creates a new account, and spreads to other systems via DECnet. It is also important to understand that someone in the future could launch this worm on any DECnet based network. Many copies of the virus have been mailed around. Anyone running a DECnet network should be warned. R. Kevin Oberman from Lawrence Livermore National Labs reports: "This is a mean bug to kill and could have done a lot of damage. Since it notifies (by mail) someone of each successful penetration and leaves a trapdoor (the FIELD account), just killing the bug is not adequate. You must go in an make sure all accounts have passwords and that the passwords are not the same as the account name." The CERT/CC also suggests checking every .com file on the system. The worm appends code to .com files which will reopen a security hole everytime the program is executed. An analysis of the worm appears below and is provided by R. Kevin Oberman of Lawrence Livermore National Laboratory. Included with the analysis is a DCL program that will block the current version of the worm. At least two versions of this worm exist and more may be created. This program should give you enough time to close up obvious security holes. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Report on the W.COM worm. R. Kevin Oberman Engineering Department Lawrence Livermore National Laboratory October 16, 1989 The following describes the action of the W.COM worm (currently based on the examination of the first two incarnations). The replication technique causes the code to be modified slightly which indicates the source of the attack and learned information. All analysis was done with more haste than I care for, but I believe I have all of the basic facts correct. Here is a description of the program: 1. The program assures that it is working in a directory to which the owner (itself) has full access (Read, Write,Execute, and Delete). 2. The program checks to see if another copy is still running. It looks for a process with the first 5 characters of "NETW_". If such is found, it deletes itself (the file) and stops its process. Note: A quick check for infection is to look for a process name starting with "NETW_". This may be done with a SHOW PROCESS command. 3. The program then changes the default DECNET account password to a random string of at least 12 characters. 4. Information on the password used to access the system is mailed to the user GEMPAK on SPAN node 6.59. Some versions may have a different address. 5. The process changes its name to "NETW_" followed by a random number. 6. It then checks to see if it has SYSNAM priv. If so, it defines the system announcement message to be the banner in the program: W O R M S A G A I N S T N U C L E A R K I L L E R S _______________________________________________________________ \__ ____________ _____ ________ ____ ____ __ _____/ \ \ \ /\ / / / /\ \ | \ \ | | | | / / / \ \ \ / \ / / / /__\ \ | |\ \ | | | |/ / / \ \ \/ /\ \/ / / ______ \ | | \ \| | | |\ \ / \_\ /__\ /____/ /______\ \____| |__\ | |____| |_\ \_/ \___________________________________________________/ \ / \ Your System Has Been Officically WANKed / \_____________________________________________/ You talk of times of peace for all, and then prepare for war. 7. If it has SYSPRV, it disables mail to the SYSTEM account. 8. If it has SYSPRV, it modifies the system login command procedure to APPEAR to delete all of a user's file. (It really does nothing.) 9. The program then scans the accounts logical name table for command procedures and tries to modify the FIELD account to a known password with login form any source and all privs. This is a primitive virus, but very effective IF it should get into a privileged account. 10. It proceeds to attempt to access other systems by picking node numbers at random. It then used PHONE to get a list of active users on the remote system. It proceeds to irritate them by using PHONE to ring them. 11. The program then tries to access the RIGHTSLIST file and attempts to access some remote system using the users found and a list of "standard" users included with the worm. It looks for passwords which are the same as that of the account or are blank. It records all such accounts. 12. It looks for an account that has access to SYSUAF.DAT. 13. If a priv. account is found, the program is copied to that account and started. If no priv account was found, it is copied to other accounts found on the random system. 14. As soon as it finishes with a system, it picks another random system and repeats (forever). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Computer Network At NASA Attacked By Rogue Program October 18, 1989 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ by John Markoff (New York Times) A rogue computer program attacked a worldwide network of the National Aeronautics and Space Administration on Monday, October 16, inflicting no damage but forcing officials to disconnect the network from sensitive military and space systems. Security experts speculated that the program was written by someone who opposed Tuesday's (October 17) scheduled launching of the space shuttle Atlantis, which was to carry a nuclear-powered satellite into orbit. The launching was postponed because of bad weather. NASA officials said the rogue program attacked an academic and research network, the Space Physics Analysis Network, which is not used for space shuttle mission control. But a NASA official said the agency felt compelled to disconnect several links between the network and an operational space shuttle network as a precaution. Computer security experts at several national laboratories said the Department of Defense had also severed the connection between commercial and research networks and nonclassified network that connects United States military installations and contractors around the world. The program was designed to copy itself secretly and send unwanted, sometimes vulgar messages to users of the NASA network. It also tricks users into thinking that data have been destroyed, although no data are damaged. Like similar programs that have been sent into computer networks by pranksters and saboteurs, it exploited a flaw in the security system designed to protect the computers on the network. Computer security experts said Tuesday that they knew of about 60 computers that had been affected by the program. A NASA spokesman said the program was still spreading. While the network is widely available to academic researchers with personal computers, the rogue program was designed to attack only 6,000 computers manufactured by the Digital Equipment Corporation. The flaw in the security of the Digital Equipment computers had been widely publicized over a year ago even before a similar rogue program jammed a group of interconnected international networks known as the Internet. NASA officials said the program was only able to attack computers in which the necessary steps had not been taken to correct the flaw. Among the messages the program displayed on all infected computers was one that read: "Worms Against Nuclear Killers. You talk of times of peace for all, and then prepare for war." Computer scientists call this kind of program a worm, a reference to a program first described in the novel "Shockwave Rider" by a science fiction writer, John Brunner. _______________________________________________________________________________ Virus Controversies Again October 6, 1989 ~~~~~~~~~~~~~~~~~~~~~~~~~ by John Markoff (New York Times) "The issue has also sparked interest among computer scientists." Harold Highland, editor of Computers & Security, a professional journal, said he had received two research papers describing how to create such anti-virus programs. He has not decided whether to publish them. "No one has raised the obvious ethical questions," he added. "I would hate to see a virus released to fight viruses. Until it's tested you don't know whether it's going to do more damage than the program it is designed to fight." A number of these programs have already been written, computer researchers said. The one that destroyed the data on business and governmental personal computers in the United States was reportedly designed by a Venezuelan programmer. How many computers were affected and where they were is unclear. That program is called Den Zuk, or Search. It was intended to attack a destructive program known as the Brain Virus that was distributed in 1986 by two brothers who owned a small computer store in Pakistan. Errors in the design of the program illustrate the potential danger of such viruses, critics say. Fridrik Skulason, a microcomputer specialist at the University of Iceland in Reykjavik, who has disassembled the program, said the author of Den Zuk had failed to take into account the different capacities of disks available for IBM and IBM-compatible machines. Because of that simple error, when the program infects a higher-capacity disk it destroys data. "They probably wrote with good intention," he said. "The only problem is that the programmers were not able to do their job correctly." At least two other anti-viral viruses have already been devised, said Russell Brand, a computer security researcher at Lawrence Livermore. He said programmers at one company, which he would not identify, had written the programs to combat the Scores virus, a program that infected Macintosh computers last year. He added that even though the programs were designed so they could not go beyond the company's own computers, there had been a heated debate over whether to deploy the programs. He said he did not know how it was decided. Brand said a group of computer researchers he works with at Lawrence Livermore had written several self-replicating programs after the appearance of the rogue program that Morris of Cornell is accused of writing. But he added that the group had never given permission to release the programs. The debate over vigilante viruses is part of a broader discussion now taking place among some computer researchers and programmers over what is being termed "forbidden knowledge." "There are ethical questions any time you send something out there that may find itself invited on to somebody else's computer," said Pamela Kane, author of a book on computer virus protection. In California this month a group of computer hackers plans to hold a forum on "forbidden knowledge in a technological society." While the role of the computer hacker has been viewed as mischievous in a negative way, hackers have consistently played a role as innovators, said Lee Felsenstein, a Berkeley, California, computer expert who designed several early personal computers. "Computer hacking was originally a response to the perception of a priesthood's control over immensely powerful technological resources," he said. "Informed individuals were able to break the power of this priesthood through gaining and spreading the body of forbidden knowledge." - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dreaded Personal Computer Virus May Be Only A Cold October 6, 1989 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ by Don Clark (New York Times) It won't be much of a plague. But the hysteria anticipating it has been world-class. Those observations come from computer-security experts as they await Datacrime, a virus program set to attack IBM-compatible personal computers starting Thursday, October 12, 1989. Analyses of the program, also called the Columbus Day Virus, show that it is indeed destructive. It just hasn't spread very far. "It's going to be the week of the non-event," predicted John McAfee, a Santa Clara, California, consultant who serves as chairman of the Computer Virus Industry Association. "You have more chance of being hit by a meteor than getting this virus." McAfee Associates, which acts as a clearinghouse for virus information, has received just seven confirmed reports of Datacrime in six months -- compared with three to 50 reports per day about another virus that originated in Israel in 1987. He thinks only 50 copies of Datacrime exist, and 40 of those are in the hands of researchers. "It's gotten more publicity than it deserves," agreed Russell Brand, another virus expert, who advises Lawrence Livermore National Laboratory. Brand expects to find just 20 copies among the 75,000 computers he monitors at 1,000 sites. Such projections are disputed by some. They are based on how often Datacrime has been detected by computer users using special software that scans their systems for the virus. The virus could have infected many users who have not bothered to scan their systems, McAfee concedes. Fears have been whipped up by the news media and computer managers at companies and government agencies. Companies promoting products to eradicate viruses also have played a role -- understandably. Staid IBM Corporation this week took the unusual step of offering a program that checks systems for viruses. The company hasn't detected the virus in its own operations, but concedes that many customers are worried. "They are asking us how we protect our software-development operations from viruses," said Bill Vance, who was appointed a year ago as IBM's director of secure systems. Bank of America, a huge IBM customer with 15,000 PCs, recently put out a company-wide notice advising users to make backup copies of their computer data by Wednesday, the day before the virus is programmed to strike. Three different government agencies have panicked and sent out multiple versions of incorrect advice," Brand said. Worried calls have deluged McAfee's office, which has just three lines for computer communications and three for voice. "We put the phone down and it's 30 seconds before it rings again," he said. Computer sleuths detected Datacrime -- and have detected other viruses -- by looking for changes in the size of data files and in the way programs operate. The underlying code used to write the program, once disassembled by experts, indicates when the program will activate itself. The identity of Datacrime's author isn't known, although some reports have linked the virus to an anonymous hacker in Austria. It first began showing up in March, McAfee said, and gained notoriety after it was discussed at the midsummer Galactic Hackers Conference in Amsterdam. It appears to be relatively prevalent in the Netherlands and other European countries. Dutch computer users have reportedly bought hundreds of programs that are said to detect and destroy the program. Like other viruses, Datacrime rides along with innocuous programs when they are exchanged over a computer network or computer bulletin board or through exchange of infected disks. Unlike many viruses, it has been designed to later insert itself in data files that users don't often examine. If one of the programs is executed after the target date, Datacrime proceeds with its dirty work -- destroying the directory used to keep track of files on a computer's hard disk. The crime is analogous to destroying a card file in the library. "By destroying this one table you can't find where any of your data is," said Brand. But no one should really be in a fix if he makes backup copies of data, experts say. The data, once safely stored on another disk drive or on magnetic tape, can be restored by computer professionals even if the virus has infected the backup files. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - "Vaccines" To Hunt Down Rogue Programs October 6, 1989 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ by John Markoff (New York Times) Ever since a rogue program created by a graduate student jammed a nationwide computer network last year, the rapid spread of such disruptive software, often known as viruses, has caused growing alarm among computer users. Now, to fight fire with fire, some companies, individuals and even a government research laboratory are crafting a new breed of what have been called anti-viruses to hunt down intruders. The trouble is, some computer security experts say, the problem of viruses may be exaggerated -- and the new crime fighter may do even more damage than the criminal. Much like an infection, a well-intended but badly designed program to stop viruses can run amok, knocking out thousands of computers or destroying vast amounts of data. Indeed, one of the anti-virus programs intended to defeat a known virus has already destroyed data on business and governmental personal computers in the United States. The issue has touched off a heated debate over whether the creation of these high-technology vigilantes is a responsible action. "The risks are just enormous," said Peter Neumann, a computer security expert at SRI International, a technology research center in Menlo Park, California. "It's an unbelievably unsafe thing to do." But Chris Traynor, a programmer at Divine Axis, a software development company in Yonkers, New York, argues that anti-virus programs can be contained so that they do not spread out of control, reaching and possibly damaging data in other computers. His company is now trying to design such a program. Computer researchers at the Lawrence Livermore Laboratory, a federal weapons center in Livermore, California, have designed similar programs that patrol computer networks in search of breaches through which viruses could enter the system. Viruses, which got their name because they mimic in the computer world the behavior of biological viruses, are programs, or sets of instructions, that can secretly be spread among computers. Viruses can travel either over a computer network or on an infected disk passed by hand between computer users. Once the infection has spread, the virus might do something as benign as displaying a simple message on a computer screen or as destructive as erasing the data on an entire disk. Computer security experts have been concerned for several years by the emergence of vandals and mischief makers who deliberately plant the destructive programs. But in recent weeks international alarm has reached new heights as rumors have spread that a virus program will destroy data on thousands of computers this month, on Friday the 13th. Computer security researchers said the virus, known as Datacrime, was one of at least three clandestine programs with internal clocks set to destroy data on that date. As is usually the case, no one knows who wrote the program, but U.S. military officials have mentioned as possible suspects a European group linked to West German terrorists and a Norwegian group displeased with the fame of Christopher Columbus, who is honored next week. Largely in response to customer concerns, IBM said on Monday that it was offering programs for its personal computers that would scan for viruses. But several computer security experts say public fears are largely exaggerated. They note that there have been fewer than a dozen reported appearances of the Datacrime virus in the United States, and contend that the whole issue is overblown. Still, in the personal computer world, where many users have little knowledge of the technical workings of their machines, concern over computer viruses has become widespread. The issue got the most attention last November, when, it is charged, Robert Morris, a graduate student at Cornell, unleashed a rogue program that because of a small programming error, ran wildly out of control, copying itself hundreds of times on thousands of computers, overloading a national network, As a result of the mounting concern, a new industry has blossomed offering users protective programs known as vaccines, or anti-viral software. These programs either alert users that a virus is attempting to tamper with their computer or scan a computer disk and erase any rogue program that is detected. These conventional programs do not automatically migrate from computer to computer, but now some experts are exploring fashioning programs that graft the powers of the vaccines onto viruses in order to pursue and stop them wherever they go. Designing and spreading such programs was proposed in August by several people attending an international gathering of computer hobbyists, or "hackers," in Amsterdam. They suggested that it was a good way for members of the computer underground to make a positive contribution. But many researchers believe the idea is dangerously flawed because of the possibility of accidentally doing great damage. Some computer security researchers worry that writing an infectious program to stop viruses may be taken as an intellectual challenge by hackers who are well meaning but do not grasp what problems they could create. "One of the questions that the hacker community is now addressing is what you do about young hackers," said Stewart Brand, a writer in Sausalito, California, who is working on a book on outlaw cultures and high technology. "They don't have a sense of responsibility; they have a sense of curiosity. These are deliciously debatable issues, and I don't see them going away." >--------=====END=====--------< ==Phrack Inc.== Volume Three, Issue 29, File #12 of 12 PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN P h r a c k W o r l d N e w s PWN PWN ~~~~~~~~~~~ ~~~~~~~~~ ~~~~~~~ PWN PWN Issue XXIX/Part 3 PWN PWN PWN PWN November 17, 1989 PWN PWN PWN PWN Created, Written, and Edited PWN PWN by Knight Lightning PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN The Cuckoo's Egg October 18, 1989 ~~~~~~~~~~~~~~~~ by By Christopher Lehmann-Haupt (New York Times) "Tracking a Spy Through the Maze of Computer Espionage" It all begins with a 75-cent discrepancy in the computer complex's accounting system. Clifford Stoll, the new man in the office, is assigned to reconcile the shortfall. Although an astronomer by training, Stoll has recently seen his grant money run dry and so has been transferred from the Keck Observatory at the Lawrence Berkeley Lab down to the computer center in the basement of the same building. No wizard at computers, he thinks he can pick things up fast enough to get by. So he sets out to look for the 75 cents. He quickly discovers that no glitch in the accounting programs has occurred. No, what seems to have happened is that an unfamiliar user named Hunter briefly logged on to the system, burning up 75-cents worth of time. Since there is no account record for Hunter, Stoll erases him from the system. The problem is solved, or so it seems. But almost immediately, an operator from Maryland on the same network that the Lawrence Berkeley Lab uses complains that someone from Stoll's lab is trying to break into his computer. When Stoll checks the time of the attempt, he discovers that the account of someone named Joe Sventek, who is known to be in England for the year, has been used. So he guesses that the user calling himself Hunter has somehow activated Sventek's account. But who is this hacker (as Stoll begins to refer to him), where is he operating from and how is he getting into the system? Next Stoll sets up systems to alert him every time the hacker comes on line and monitor his activities without his being aware of it. He watches as the hacker tries to lay cuckoo's eggs in the system's nest, by which of course he means programs for other users to feed -- for instance, a program that could decoy other users into giving the hacker their secret passwords. He watches as the hacker invades other computer systems on the networks the Lawrence Berkeley Lab employs, some of them belonging to military installations and contractors. The mystery grows. Telephone traces gradually establish that the hacker is not a local operator, is not on the West Coast and may not even be in North America. But of the various three-letter organizations that Stoll appeals to for help -- among them the FBI, the CIA and even the National Security Agency -- none will investigate, at least in an official capacity. By now a reader is so wrapped up in Stoll's breezily written account of his true adventure in "The Cuckoo's Egg: Tracking a Spy Through the Maze of Computer Espionage" that he is happy to overlook certain drawbacks in the narrative -- most conspicuously the lack of consistently lucid technical talk and the author's dithering over whether appealing for help to the likes of the FBI and CIA is selling out to the enemy, a qualm left over from the 1960s mentality that still afflicts him and his friends. The only truly annoying aspect of the book is that an endpaper diagram gives away the location of the computer spy. Readers are advised not to look at the endpapers, which do little but spoil the suspense. Unfortunately, the narrative, too, eventually helps dissipate the story's tension. The officials who finally take over the hunt from Stoll are so reluctant to tell him what is happening that all the suspense he has created simply evaporates. Even Stoll seems to lose interest in the identity of his mysterious antagonist, judging by the limp and haphazard way he finally does give us the news. Instead of building his story, he allows himself to be distracted by a banal domestic drama centering on his decision to stop being afraid of emotional commitment and marry the woman he has been living with for seven years. And he continues limply to debate the need of the state to defend the security of communications networks against wanton vandalism, as if there were room for serious discussion of the question. Still, nothing can expunge the excitement of the first two-thirds of "The Cuckoo's Egg," particularly those moments when the author hears his portable beeper going off and bicycles to his lab to read the latest printout of the hacker's activities. Nothing can relieve our discouragement at the bureaucratic runaround that Stoll got. Had a million dollars worth of damage occurred? the FBI kept asking him. "Well, not exactly," he would reply. Then there was nothing the FBI could do. And so it dishearteningly went, although some points should be conceded. Certain individuals in government agencies were extremely helpful to Stoll. The entire issue of computer-network security was after all a new and unexplored field. And the agencies that the author was asking for help probably knew more about the security threat than they were willing to tell him. Finally, nothing can diminish the sense of the strange new world Stoll has evoked in "The Cuckoo's Egg" -- a world in which trust and open communication will determine the quality of the future. Whether such values will prevail will prove a drama of momentous significance. Even if this book finally dissipates that drama, its very presence makes these pages worth dipping into. _______________________________________________________________________________ Digital's Hip To The Standards Thing October 10, 1989 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NEW YORK -- During a creative session at a major public relations firm to formulate a new corporate message for Digital Equipment Corporation that reflects the company's new direction promoting and supporting computing industry standards, the shopworn phrase "Digital has it now" was replaced by a new tag line that is more contemporary and tied to DEC's adherence to standards. DECrap by Rapmaster Ken "Digital's Hip to the Standards Thing" I heard some news just the other day It sounded kinda strange and I said, "No way!" But I heard it again from another source It mighta made sense and I said, "Of course!" Now computer biz has a lotta confusion 'Cause operating systems abound in profusion. But there's a whole new wave in data processing Now that Digital's hip to the standards thing. (chorus) Digital's hip to the standards thing! Digital's hip to the standards thing! Way back when a long time ago IBM owned the whole show. But other dudes saw this proprietary mess And formed committees to find out what's best. Some went their own way and built their own software But users were perturbed, "It's just a different nightmare." So they got together to look over the picks Put down their money on good 'ol UNIX (chorus) Digital's hip to the standards thing! Digital's hip to the standards thing! Now Digital always kept their users in mind And pushed VMS as the best of the kind. A lotta folks agreed but kept askin' for UNIX support, "We gotta have more!" Soon DEC saw the light and decided to give UNIX to the masses, (sorta live and let live). So DEC's ridin' the wave ahead of the rest On a backplane boogie board on top of the crest. No doubt about it DEC's sprouted its wings 'Cause Digital's hip to the standards thing. (chorus) Digital's hip to the standards thing! Digital's hip to the standards thing! _______________________________________________________________________________ Hacker Publications November 12, 1989 ~~~~~~~~~~~~~~~~~~~ Here is a general overview of a pair of the more popular hardcopy hacker magazines. 2600 Magazine: The Hacker Quarterly Volume Six, Number Three Autumn, 1989 The cover on this issue features a scene from the Galactic Hackers Convention that took place in Amsterdam, Switzerland, last August. Although it is not explicitly stated or implied, it would appear that the comic illustration portrays the hacker "Shatter" being run over by a bus bearing the label "2600 XPRESS." The articles featured in this issue include: The Nynex Strike Grade "A" Hacking: What Is UAPC? by The Plague Galactic Hacker Party (GHP) British Telecom's Guilty Conscience The Death Of COSMOS? What's Going On - Technological Marvels o U.S. Sprint Billing Problems o U.S. Sprint Voicecards o Other Voiceprints o Surveillance - Hacker Spies (Chaos Computer Club, KGB Hackers discussed) - Nynex Bigotry (Gay And Lesbian Organizations) - Dial-It News (Pacific Bell 900 Services) - Payphone Choices (AT&T, Sprint, MCI, AOS) - Overseas Access (AT&T Calls To Vietnam) - News From The U.K. o Directory Assistance Operators o British Telecom To Buy Tymnet From McDonnel Douglas o Chat Lines Banned - One Less Choice (The Source and Compuserve) - Privacy? What's That? o Bulletin Board User Information o Illegal Aliens Database o Scotland Yard Database o Wiretapping o Bell of Pennsylvania (giving out confidential information) o Personal Smart Card - Hackers In Trouble o Kevin Mitnick o Robert Morris - Hacker Fun o Friday The 13th Virus o Speed Limit Alterations o Delray Beach Probation Office - Telco Literature (FON Line Newsletter) - Calling Card Tutorials - Another Telco Ripoff (C&P Telephone) - Technology Marches Back o French Computer Mixup o New York Telephone Repairman Sent On Wild Goose Chases - And Finally (Bejing Phone Calls) The Secrets of 4TEL Letters - Moblie Telephone Info - A Southern ANI - ROLM Horrors - A Nagging Question (by The Apple Worm) - A Request - Another Request (by THOR ) - The Call-Waiting Phone Tap (Alternative Inphormation) - Interesting Numbers (1-800-EAT-SHIT, 800, 900 numbers) - UNIX Hacking (Unix security, hacking, TCP/IP) - Intelligent Payphones - Retarded Payphones REMOBS by The Infidel Gee... GTE Telcos by Silent Switchman and Mr. Ed Voice Mail Hacking... by Aristotle Punching Pay Phones by Micro Surgeon/West Coast Phreaks Touch-Tone Frequencies 2600 Marketplace Carrier Access Codes Lair of the INTERNET Worm by Dark OverLord Timely Telephone Tips (from a Defense Department Phone Book) There were also plenty of other interesting small articles, pictures, and stories about hackers, telephones, computers and much more. All in all, this is the best issue of 2600 Magazine I have read in several issues (despite the fact that some of the material had appeared in Phrack Inc., LOD/H TJs, and/or Telecom Digest previously). Let's hope they continue to be as good. Are you interested in 2600 Magazine? 2600 (ISSN 0749-3851) is published quarterly by 2600 Enterprises Inc., 7 Strong's Lane, NY 11733. Second class postage permit paid at Setauket, New York. Copyright (c) 1989, 2600 Enterprises, Inc. Yearly subscriptions: U.S. and Canada -- $18 individual, $45 corporate. Overseas -- $30 individual, $65 corporate. Back issues available for 1984, 1985, 1986, 1987, 1988 at $25 per year, $30 per year overseas. Address all subscription correspondence to: 2600 Subscription Department P.O. Box 752 Middle Island, New York 11953-0752 2600 Office Line: 516-751-2600 2600 FAX Line: 516-751-2608 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - TAP Magazine Issue 94 1989 The new TAP Magazine is a smaller publication in comparison to 2600. The "outer" cover of this newsletter was a "warning" from The Predat0r concerning the nature of the material inside. The true or "inner" cover of the newsletter had the following: The Information You've Requested Of TAP Publishing Society A Unit Of The Technological Advancement Party Presents... "...a family of people dedicated to the advancement of home computer systems and electronic technology, the study and duplication of related communication networks and the subsequent utilization of one's own ingenuity in today's fast-paced world of creative logic." The articles in this issue of TAP included: TAP RAP: News From The TAP Staff by Aristotle Small Tags Protect Big Stores (continued from TAP 93) Ozone (concerning American Telephone & Telegraph's plans for 1994) Telephone Wires In New York In 1890 Mercury Fulminate by Dark OverLord How To Hack Stamps Hoffman Worked To Help All Of Mankind Police Raid 3 Jefferson Homes In Search For Computer Hackers by Calvin Miller SummerCon '89 by Aristotle (includes a copy of the official SummerCon '89 poster and button, although an error stating that the poster was shown at 1/2 size when in reality, the original was 8 1/2" by 14"). There were a few other interesting "tid bits" of information scattered throughout the four loose pages including the new TAP logo (that was made to resemble CompuTel) and other pictures. The staff at TAP also included a postcard that contained a reader's survey. It asked all sorts of questions about how the reader liked certain aspects of the publication... I found the idea to be potentially productive in improving the quality of the newsletter all around. The cost of TAP is rather cheap... it is free. For an issue send a self addressed stamped envelope to: T.A.P. P.O. Box 20264 Louisville, Kentucky 40220-0264 :Knight Lightning _______________________________________________________________________________ Phrack World News QuickNotes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. 911 Improvement Surcharge in Chicago (October 16, 1989) -- Monday morning, October 16, Chicago Mayor Richard M. Daley announced that he would submit to the city council a plan to increase city telephone taxes by 95 cents per line per month, earmarked for improvements to 911 service. Currently there is no such flat charge, simply a percentage tax rate on local telephone service. Daley's spokespeople commented that 911 service here has been a mess for years, and that many of the suburbs charge $1.00 per line per month, so 95 cents should not be unreasonable. There were no details about what is currently wrong or about what specific improvements Daley has in mind. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 2. Hacker Caught by Caller-ID (October 9, 1989) -- MIS Week reported the apprehension of a 15-year old hacker who used his Amiga personal computer to tap into two minicomputers at Grumman. The youngster was from Levittown, Long Island and stumbled into the computer by using a random dialing device attached to his computer. Grumman security was able to detect the intrusions, and the computer's recording of the boy's telephone number led police to his home. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 3. 14-Year-Old Cracks TRW Credit For Major Fraud (October 18, 1989) -- A 14-year-old Fresno, California boy obtained secret "access codes" to the files of TRW Credit from a bboard and used them to pose as a company or employer seeking a credit history on an individual whose name he picked randomly from the phone book. From the histories, he obtained credit card numbers which he then used to charge at least $11,000 in mail-order merchandise (shipped to a rented storeroom) and make false applications for additional cards. He also shared his findings on computer bulletin boards. Police began investigating when TRW noticed an unusual number of credit check requests coming from a single source, later found to be the youth's home telephone number. The high school freshman, whose name was not released, was arrested at his home last week and later released to his parents. His computer was confiscated and he faces felony charges that amount to theft through the fraudulent use of a computer. "Here is a 14-year-old boy with a $200 computer in his bedroom and now he has shared his data with countless other hackers all over the nation," said Fresno Detective Frank Clark, who investigated the case. "The potential (for abuse of the information) is incredible." Excerpts provided by Jennifer Warren (Los Angeles Times) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4. Computer Virus Countermeasures Article (October 25, 1989) -- Readers of Phrack Inc. might be interested in an interesting article in the October 1989 issue of DEFENSE ELECTRONICS, page 75, entitled "Computer Virus Countermeasures -- A New Type Of Electronic Warfare," by Dr. Myron L. Cramer and Stephen R. Pratt. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 5. Computer Viruses Attack China (November 6, 1989) -- The Ministry of Public Safety of People's Republic of China found this summer that one tenth of the computers in China had been contaminated by three types of computer virus: "Small Ball," "Marijuana," and "Shell." The most serious damage was found in the National Statistical System, in which "Small Ball" spread in 21 provinces. In Wuhan University, viruses were found in *ALL* personal computers. In China, three hundred thousand computers (including personal computers) are in operation. Due to a premature law system the reproduction of software is not regulated, so that computer viruses can easily be propagated. Ministry of Public Safety now provides "vaccines" against them. Fortunately, those viruses did not give fatal damage to data. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 6. More Phone-Card Fraud (October 31, 1989) -- Two men were convicted by Tokyo District Court on Monday, October 30, for tampering with Nippon Telephone and Telegraph calling cards to increase the number of calls they could make. The court ruled that they violated the Securities Transaction Law. One man, Kawai, was sentenced to 30 months in prison, and another, Sakaki, was given an 18-month suspended sentence. Two presiding judges ruled that using falsified telephone cards in pay phones is tantamount to using securities. However, another judge ruled in a separate case last September that tampering with a telephone card does not constitute use of a security, so legal observers say it will be up to the Supreme Court. According to this most recent s ruling, Kawai changed about 1,600 telephone cards, each good for 500-yen worth of telephone calls, into cards worth 20,000 yen. He sold the altered cards to acquaintances for as much as 3,500 yen. Sakaki also sold about 320 tampered cards for about 2 million yen. One of the presiding judges ruled that using tampered telephone cards on public telephones is the same as misleading Nippon Telegraph and Telephone Corporation into believing the cards -- false securities -- were genuine. Taken from The Japan Times - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7. Computer Virus Hits Japanese Quake Data (October 30, 1989) -- Tokyo; A computer virus has destroyed information at the University of Tokyo's seismological and ocean research institutes, a university official and local reports said yesterday. An official of the university's Ocean Reasearch Institute said the virus was detected earlier this month in five of the center's 100 computers, but was believed to have first infected the computers in September. The virus was found only in personal computers being used by researchers and not major computer systems, the official said, requesting anonymity. He said the damage was not serious. He declined to discuss further details, but a report by the Japan Broadcasting Corporation said a virus had also been found in the computers at the university's Earthquake Research Institute. Thanks to Associated Press news services. (Related article follows) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 8. First Virus Attack On Macintoshes In Japan (November 7, 1989) -- Six Macs in University of Tokyo, Japan, were found to have caught viruses. Since Since this September, Professor K. Tamaki, Ocean Research Institute, University of Tokyo, has noticed malfunctions on the screen. In October, he applied vaccines "Interferon" and "Virus Clinic" to find his four Macintoshes were contaminated by computer viruses, "N Virus" type A and type B. He then found ten softwares were also infected by viruses. A Macintosh of J. Kasahara, Earthquake Research Institute, University of Tokyo, was also found to be contaminated by N Virus and Score Virus. These are the first reports of real viruses in Japan. Later it was reported that four Macintoshes in Geological Survey of Japan, in Tsukuba, were infected by N Virus Type A. This virus was sent from United States together with an editor. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 9. Hackers Can Tap Into Free Trip (October 1989) -- Attention Hackers: Here is your chance to break into a computer system and walk away with a grand prize. The "hacker challenge" dares any hacker to retrieve a secret message stored in a KPMG Peat Marwick computer in Atlanta. This challenge is being sponsored by LeeMah DataCom Security Corporation, a Hayward, California, consulting firm that helps companies boost computer security. The winner gets an all-expense paid trip for two to either Tahiti or St. Moritz, Switzerland. Hackers with modems must dial 1-404-827-9584. Then they must type this password: 5336241. From there, the hacker is on his own to figure out the various access codes and commands needed to retrieve the secret message. The winner was announced October 24, 1989 at the Federal Computer Show in Washington. Taken from USA Today. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 10. Groaning Phone Network Survives Millions Of Calls (October 18, 1989) -- The nation's telecommunications network was flooded Tuesday (October 17) night by an estimated 20 million attempted telephone calls from people around the nation concerned about friends and family after the earthquake in the bay area. Except for brief failures, the system did not break down under the record load in the areas damaged by the earthquake. AT&T officials said that as many as 140 million long-distance phone calls were placed Wednesday (October 18), the highest number for a single day in history. Excerpts thanks to John Markoff (New York Times) >--------=====END=====--------<


E-Mail Fredric L. Rice / The Skeptic Tank