========================================================================= Date: Mon, 18 Jul 88 10:53:29 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: AL148859@TECMTYVM Subject: Virus on the PC. Hello, Can anybody sendme a technical explanation of the "Brain" virus? I'll apreciate the help.. If you know another virus for the IBM-PC send to me an explanation too. Thank's! Juan Gabriel Ruiz Pinto AL148859@TECMTYVM Ing. Sistemas Electronicos I.T.E.S.M. ========================================================================= Date: Mon, 18 Jul 88 10:40:14 PLT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Andrew Vaught <29284843@WSUVM1> Subject: Virus Discussion The list has sure been quiet for a while. Have we said all there is to say about viruses? Andy ========================================================================= Date: Mon, 18 Jul 88 12:54:19 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Len Levine Subject: Re: Virus Discussion In-Reply-To: Message from "Andrew Vaught" of Jul 18, 88 at 10:40 am > >The list has sure been quiet for a while. Have we said all there is to say >about viruses? > > > Andy > I had noted that too. Seemed like my wire had been cut. :-) + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Leonard P. Levine e-mail len@evax.milw.wisc.edu | | Professor, Computer Science Office (414) 229-5170 | | University of Wisconsin-Milwaukee Home (414) 962-4719 | | Milwaukee, WI 53201 U. S. A. Modem (414) 962-6228 | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + ========================================================================= Date: Mon, 18 Jul 88 14:45:15 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Joe McMahon Subject: Re: Virus Discussion In-Reply-To: Message of Mon, 18 Jul 88 10:40:14 PLT from <29284843@WSUVM1> >The list has sure been quiet for a while. Have we said all there is to say >about viruses? No, but I DO think we have (along with others) made it plain that "hangin' 's too good for them varmints." Either we've scared a lot of people away from viruses by our immediate and agressive response (could be), or they've been working on their new viruses (alas - even more likely to be). --- Joe M. ========================================================================= Date: Mon, 18 Jul 88 16:29:24 CST Reply-To: Virus Discussion List Sender: Virus Discussion List From: Claudia Lynch Subject: Re: Virus on the PC. In-Reply-To: Message of Mon, 18 Jul 88 10:53:29 EDT from There are some articles in the CCNEWS archives. You can get these by issuing the command GET filename filetype to LISTSERV@BITNIC. These articles are: BRAIN McPART_T , VIRUS CERNY_J and VIRUS SHEEHA_M. I hope these were of some help. Claudia Lynch ========================================================================= Date: Mon, 18 Jul 88 19:04:37 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: 2662@DB0TUZ01 GET DIRTY DOZEN ========================================================================= Date: Tue, 19 Jul 88 12:52:53 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: Forwarded virus hype editorial, and some random comments Greetings, First of all, I've noticed that VIRUS-L has gained many subscribers in the past week or so since it was announced in the NETMONTH newsletter here on BITNET; welcome all! Around the end of this month, I'll be sending out my monthly info sheet which should clear up some questions which you may have, such as, "how do I get files from this LISTSERV?". Secondly, a number of people have noted that VIRUS-L traffic has subsided quite a bit. I'd imagine that this is partly due to the fact that many university students have gone home for the summer, but perhaps not. I don't think that the subject has been exhausted by any means. We'll see... Let's see some participation out there! Finally, this next item is a editorial comment from an anti-software vendor. The editorial was distributed via Compuserve, and forwarded to me verbatim. Note that it is not an endorsement, merely an opinion from the vendor. Ken van Wyk -------- begin editorial --------- CompuServe IBMSW IBM Software Forum Forum Menu #: 197283 S9/Hot Topic (S) 09-Jul-88 16:53:51 Sb: #Virus Hype Fm: rg software 70701,2561 To: ALL VIRUS HYPE Since I'm a new participant in this forum group, I'd like to introduce myself: Raymond M. Glath President RG Software Systems, Inc. 2300 Computer Ave. Willow Grove, PA 19090 (215) 659-5300 We are a 4 year old developer/publisher. Our products are "DISK WATCHER" which includes anti-virus logic among its many features, and the "PC TRACKER" systems for managing pc resources. Between various articles in INFOWORLD and discussions in CIS forums, Steve Gibson has heartily promoted: The C-4 product from Interpath (according to Steve, "the only product to beat all viruses known to the NBBS"); The "not-for-profit" "National Bulletin Board Society" with its Virus Simulator, VIRSIM; and in a recent message to Thomas Thornbury of Software Directions, the "industry-wide coalition of independent anti-viral software publishers", information on which may be obtained from the individual Steve referenced at the NBBS. Some interesting facts that we've discovered: 1. The 1st time we ever saw the NBBS referenced in print was in an editorial column in PC WEEK approximately 1 month after Interpath announced their anti-virus product. This editorial stated that the NBBS was selling a virus simulator product for $79.95. 2. Interpath and the NBBS co-incidentally share the exact same address, however published reports never seem to link these two? groups in any way other than Steve Gibson's report that C-4 is the only product that defeats ALL the viruses on the NBBS. 3. One of our customers had contacted the NBBS and received a disk from them which contained: the virus simulator... VIRSIM; an actual working virus that attacks COM files; and two dis-assembled/commented virus programs... The BRAIN and the ISRAELI viruses. #: 197284 S9/Hot Topic (S) 09-Jul-88 16:56:49 Sb: #Virus Hype Fm: rg software 70701,2561 To: ALL (Continuation from 197283) 4. Upon request from our customer, we analyzed the VIRSIM simulator product and discovered that VIRSIM makes a number of erroneous assumptions when performing its "virus attacks". To wit: a. It considers the mere OPENing of a COM, EXE, or SYS file to be a virus attack. The fact that a file is OPENed doesn't change the file in any way. You must WRITE TO THE FILE TO CHANGE IT. WRITING to one of these files would indicate a valid virus attack condition. OPENing, without ever WRITING is not a virus attack condition, but rather a "false alarm". b. During several VIRSIM "attacks", VIRSIM does not check the error return conditions properly after the "attack", and therefore erroneously reports successful attacks that have, in reality, failed. 5. Steve also told Thomas Thornbury to contact an individual at the NBBS for information on the newly formed "industry-wide coalition of independent anti-viral software publishers". In fact, the president of INTERPATH phoned our company stating that HE was forming this group and solicited our membership. Due to the conditions outlined above, we have chosen to NOT AFFILIATE with this "coalition", and must question whether or not its formation is just another form of hype to keep the virus fuel burning in the pressrooms. Viruses are real. The threat is there. The extent of the threat is totally unknown at this time. It may get serious and it may not. We need more substance and less hype in the press. If the world must have a virus simulator to evaluate anti-virus products, then lets have one developed by someone totally isolated from anti-virus publishers; lets have it certified by a professional software evaluation company; and lets insure that it is neither able to be easily turned into a real virus, nor documented to a level that it becomes a "how to" guide for virus writers. Comments welcome... Ray Glath ========================================================================= Date: Tue, 19 Jul 88 13:21:00 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: GILL@QUCDNAST Subject: RE: VMS ZOO John Lundin writes >A version of ZOO for VAX/VMS arrived over the net yesterday on Info-VAX.. an >executable image, UUENCODEd. ZOO is an archiver program. Considering the >number of bad PKARC versions that are out there, can anyone vouch for this? >Anyone have source? >A quick check shows that it was probably written in C, and has many plausible- >sounding error messages near the beginning. Our system guru downloaded this file yesterday and found out that it did not work - the resulting file had the wrong format for our uVAX to recognize. He theorizes that this may have something to do with the fact that we have no C or C libraries on our machine, but isn't positive. It is not a virus as far we know - it just doesn't work. If anyone gets a ZOO for the VAX up and running, e-mail me. We will be interested. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Arnold Gill | If you don't complain to those who | Queen's University at Kingston | implemented the problem, you have | gill @ qucdnast.bitnet | no right to complain at all ! | -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ========================================================================= Date: Tue, 19 Jul 88 10:38:44 PLT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Andrew Vaught <29284843@WSUVM1> Subject: VIRSIM I think that the idea of keeping a "Virus Simulator" around is a pretty useless idea since having your virus-detector program `discover' VIRSIM's `attacks' only give a false sense of security. A genuine virus would probably much trickier. This makes me wonder-- have we seen any viruses yet that are designed to fools any of the popular packages around? It would seem to me that a virus has to be small enough to hide somewhere, and this would prevent esoteric anti-detection detection countermeasures. As for VIRSIM, shelve it. It is useless. Andy ========================================================================= Date: Wed, 20 Jul 88 02:44:41 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: me! Jefferson Ogata Subject: simulators > As for VIRSIM, shelve it; it is useless. Virus simulators are viable ways to test virus protection software. If I were testing it, one thing I wouldn't do is use REAL viruses. The majority of virus problems presently are caused by known viruses, such as the BRAIN virus, and mutations therefrom. An appropriate way to test software designed to protect against such attacks is to simulate the attacks with an easily controlled substitute. Protecting against new and innovative viruses would be virtually impossible; nevertheless, we needn't discard the notion of virus simulation for known strains. Virus simulation is really quite close in principle to vaccination. Vaccines are designed to stimulate immune system response to a disease without incurring any real danger to the patient. Virus simulators are a good test for virus-protection software, as they also incur no real danger to the patient (hopefully). Should we stop manufacturing influ- enza vaccines just because the flu changes every year? I am certainly not endorsing this particular simulator, VIRSIM, as good evidence has been presented that it may be a corporate marketing ruse. There are other simulators out there. I'd say use them in good health. - Jeff ========================================================================= Date: Wed, 20 Jul 88 12:57:17 SET Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Christian J. Reichetzeder" Subject: Re: VM/CMS viruses In-Reply-To: Message of Fri, 24 Jun 88 10:07:00 URZ from I don't know if the following scenario has already been addressed. *-* Use of PCs both as PC and Terminal is wildly increasing at our site. More and more products are available to connect to hosts (ECF, FBSS, Kermit, ...). Future plans for our site include LAN, bridges to EtherNet and who knows what else. There will (must) also be some "public" PCs for software-demo, assitance, utilities (e.g. copying diskettes to different format), students, ... REMARK: most of the PCs are "outside" our institution, i.e. other Institutes/ Clinics connecting to the mainframe own those PCs. *-* I fear that there is a "good" chance that (almost) all PCs get infested from the public ones - not necessary by deliberate action. It could come from a user who caught a virus by accident and uses the public PC to copy some diskettes. What if a Trojan connection program (e.g. 3270 emulation) spreads around? It could steal *host* passwords and make use of the LAN to send them to the hacker. It could also be used to infest the host (CMS in our case). *-* Any comments, suggestions, experiences, war stories, ...??? Some specific questions: * is it better if the "public" PCs have *NO harddisk* ? * should we offer host access in "public" PCs or not ? * anyone ever heard of installing a "controlled" PC as a "bait" ? Christian ========================================================================= Date: Wed, 20 Jul 88 07:38:10 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: Re: VM/CMS viruses In-Reply-To: Message of Wed, 20 Jul 88 12:57:17 SET from >What if a Trojan connection program (e.g. 3270 emulation) spreads around? > * is it better if the "public" PCs have *NO harddisk* ? > * should we offer host access in "public" PCs or not ? > * anyone ever heard of installing a "controlled" PC as a "bait" ? This sort of thing is certainly a very real problem, primarily at universities which have publically accessible micros. It turns out that these public micros are probably about the best incubating environment that you could imagine for a virus or trojan terminal emulator, etc. Here at Lehigh, we've done the following to try to reduce this risk: 1) All public micros are dual floppy machines; most of which are connected to LANs (Novell on 3COM boards). 2) All boot disks (with Novell software on) are notchless disks, and they contain nothing other than the operating system boot files and the Novell software. 3) All Novell hard disks (on the file servers) are read only, with the exception of a scratch area where users can place temporary files. 4) The scratch areas get cleaned (i.e., erased) periodically by our student employees. 5) Users logging into the LAN are not automatically placed in the scratch directory. (Recall that, in MS-DOS, the current working directory is always searched for executables before the PATH is...) The above methods are probably not infallible (sp?), but what is? Yes, I do think that it is worthwhile to have public micros, but you *HAVE* to take some basic precautions. Offering host access from your public micros should be a must; at least, depending upon how your computing facility is set up. We have very few data terminals any more; almost all mainframe access is via PCs connected to our digital voice/data PBX. As far as setting up a controlled PC as bait; it sounds rather expensive, but what form of bait did you have in mind? Ken Kenneth R. van Wyk From the Devil's Dictionary: User Services Senior Consultant Barometer - an ingenious device Lehigh University Computing Center designed to inform the user what Internet: the weather is. BITNET: ========================================================================= Date: Tue, 19 Jul 88 19:27:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: WHMurray@DOCKMASTER.ARPA Subject: Re: Forwarded virus hype editorial, and some random comments In-Reply-To: Message of 19 Jul 88 12:52 EDT from "Kenneth R. van Wyk" >Since I'm a new participant in this forum group, I'd like to introduce >myself: > > Raymond M. Glath > President > RG Software Systems, Inc. > 2300 Computer Ave. > Willow Grove, PA 19090 Nice; courteous; however, we have already met. > a. It considers the mere OPENing of a COM, EXE, or SYS file to be a > virus attack. The fact that a file is OPENed doesn't change the > file in any way. > You must WRITE TO THE FILE TO CHANGE IT. True. However, a simulator need not do everything that the real thing must do. Flight Simulator does not fly either, but it does simulate the externals. A virus simulator need not necessarily infect. If it would present the same results to a virus protection program that a virus would, then it has probably met the requirement for such a program. >Due to the conditions outlined above, we have chosen to NOT AFFILIATE >with this "coalition", and must question whether or not its formation is just >another form of hype to keep the virus fuel burning in the pressrooms. More basic, it seems to me, is whether or not there is any requirement for such an organization. Even if "caveat emptor" did not apply here, there does not appear to be much evidence that people are being ripped off. It seems a little early to declare the market full and all of the invention done. >If the world must have a virus simulator to evaluate anti-virus >products, then lets have one developed by someone totally isolated from >anti-virus publishers; lets have it certified by a professional software >evaluation company; and lets insure that it is neither able to be easily >turned into a real virus, nor documented to a level that it becomes a >"how to" guide for virus writers. Certainly, we should avoid conflict of interest. It is useful to have a forum such as this to publicize any potential ones that we identify. That having been said, we can likely afford what we have seen to date. Still, there does seem to be some unseemly haste here somewhere. Regards, Bill William Hugh Murray, Fellow, Information System Security, Ernst & Whinney 2000 National City Center Cleveland, Ohio 44114 21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840 ========================================================================= Date: Wed, 20 Jul 88 12:00:09 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: Lois Buwalda Subject: How to warn inexperienced users about viruses Hi! I'm in the process of writing a BITNET help guide for beginning computer users. Since I have to explain to these users how to send and receive files, I would also like to include a section on viruses. Thus, I was wondering what you guys think beginning users should be told about them (i.e., what can be done to minimize the spread of them, etc.). Please keep in mind that these people know very little about computers, so telling them to carefully read through all programs before running them wouldn't help a whole lot. Anything else I can tell them besides the obvious "don't receive any files from people that you don't know"? If you want to reply directly to me, I will summarize the responses over the list later. Thanks! Lois ========================================================================= Date: Wed, 20 Jul 88 15:26:51 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Steve Subject: Re: VM/CMS viruses In-Reply-To: Message of Wed, 20 Jul 88 12:57:17 SET from >What if a Trojan connection program (e.g. 3270 emulation) spreads around? It >could steal *host* passwords and make use of the LAN to send them to the >hacker. It could also be used to infest the host (CMS in our case). I'm new to this list. I wanted to point out that in regard to corrupted terminal emulators that steal passwords and send them to a "hacker", this probably is not the way it would happen. Such an emulator would have to have the "address" of the "hacker" in order to forward passwords to him, right? That leaves the "hacker" vulnerable to discovery and identification, and most intelligent "hackers" would not take such a risk. On the other hand, the program could store userids and passwords, hidden on disk somewhere, and the "hacker" could later come along and extract this information. Or maybe such an emulator could be set up to respond remotely to the queries of the person who planted it. Steve ========================================================================= Date: Wed, 20 Jul 88 20:03:40 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: David.Slonosky@QUEENSU.CA Subject: Write protect hardware Is there any way to design code so that a disk write to a write-protected disk will NOT generate a write error message? ========================================================================= Date: Wed, 20 Jul 88 20:05:17 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: David.Slonosky@QUEENSU.CA Subject: Getting a handle on size I just thought of a purely hypothetical question which may or may not be of value to this discussion. Supposing you were the ideal computer user and initialised your system by checksumming all your files initially followed by regular repeats, and using programs like CHK4BOMB, BOMBSQAD, and/or FSP regularly. You also believe in the value of a well-placed write protect tab and have the latest software protection for your hard drive. You have also made your important files read-only using some attribute changing utility. Along comes virus writer X who wants to destroy your system for perverted kicks. What type of virus could this person design to circumvent all these measures, what is the minimum size it could possibly be, and how much would it slow down processing time (to the detectable level? not at all?)? Obviously almost no one has write protect tabs on their disks all the time. ========================================================================= Date: Wed, 20 Jul 88 16:54:47 MEX Reply-To: Virus Discussion List Sender: Virus Discussion List From: SISTEMAS@VMTECMEX Hi there: I'm new to the list but I think it's real good. I would like to get a virus simulator to evaluate a protection developed here.I'd like it better if it's an "independent" simulator ( not VIRSIM ). Any suggestions? ( please be specific about it ). Thanks in advance for your valuable help. Arturo Torres. Soft.Eng.Dep. ITESM Mexico City. Mexico. ========================================================================= Date: Thu, 21 Jul 88 03:11:21 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Amanda B Rosen Subject: Re: Write Protect Hardware David Slonosky asks: >Is there any way to design code so that a disk write to a write-protected >disk will NOT generate a write error message? This could be interpreted two ways. 1) If you mean, can I fool the virus into thinking it has successfully altered my disk, the answer is yes. Whether the disk is protected by software or hardware (write lines cut or whatever), it should be very easy to replace the disk-writing trap (or interrupt in MS-DOS) so that writes simply do nothing. However, this is useless against sophisticated viruses which can easily see if the trap or interrupt has been replaced. Also, it is easy for a virus to read-after-write to tell for sure. I am not aware of any such viruses, but some such probably do exist. Of course, if your disk is hardware write-protected, the only benefit to fooling the virus is that it may subsequently reveal itself. However, if you're going to the trouble of hooking the write calls, you might as well add some user alert to the code while you're at it. Thus, I don't think that fooling the virus this way is significantly helpful, except against very simple ones. 2) If you mean, can I prevent MY programs from crapping out when they try it, the answer is the same. Do the same thing. In this case, there can be some benefit (your application doesn't die, unless it depends in some critical way on the data it just wrote...) /a ========================================================================= Date: Thu, 21 Jul 88 02:37:00 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Back off man, I'm a scientist..." Subject: P.S. P.S. About snatch.com, we never actually used this program against the world at large. We did test it on our girlfriends, though. Frank ========================================================================= Date: Wed, 20 Jul 88 22:39:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Brian Holmes Subject: Re: Write protect hardware In-Reply-To: Your message of Wed 20 Jul 88 20:03:40 EDT It is very easy to tell if a disk is write protected through specific calls to the operating system, so yes you can design code to not issue a write protect error, if a disk has been write protected. ******************************************************************* * Brian Holmes \ / ___ * * Wayne State University \/\/su | | * * Detroit Michigan ____| |____ * * | | | | * * BITNET : BHOLMES@WAYNEST1 | | | | * * INTERNET : Brian_Holmes%WU@UM.CC.UMICH.EDU | | | | * * UUCP : {UMIX|ITIVAX}!WAYNE-MTS!BRIAN_HOLMES ============= * ******************************************************************* ========================================================================= Date: Wed, 20 Jul 88 22:25:36 CST Reply-To: Virus Discussion List Sender: Virus Discussion List From: James Ford Subject: HDSENTRY I downloaded HDSENTRY from a bbs here in town and decided to give it a try. (HDSENTRY is suppose to be a h-drive "write-protect" tab...) It came with a DOC, COM and ASM file............. Well, I backed up a directory and then ran the program. I then proceded to DEL *.* and sat back. I got the message WARNING! TRYING TO DELETE ...etc. and said to my self, "Hey, this might do the job." I then did a directory and found no files at ALL. However, after re-booting, the files re-appeared. My question: Why does HDSENTRY do this? Are some stack pointers off or what? I have a copy of the ASM file, but don't know enough about assembly to check on it. Any takers? I'm using an IBM PS/2 M30 w/20M. James Ford JFORD1@UA1VM.BITNET ========================================================================= Date: Thu, 21 Jul 88 02:34:00 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Back off man, I'm a scientist..." Subject: Password Snatchers. The problem of password stealing isn't limited to hacked software that links PC's to mainframes. This problem can occur from dumb-terminals hard-wired directly to the mainframe. Last semester, a few of us wondered if it would be possible to snatch peoples Usernames and Passwords. After arguing the matter for about 10 minutes, we decided that the only way to determine if it were possible or not, was to try to write one for ourselves... The basic idea behind our snatcher.com was to have a terminal appear to be unused and let the Victim "log in" there. We simulated the system password request mechanism and When the person typed in his/her username and password we intercepted it and wrote them out to a file. The whole program took only an hour to write, and looked and felt almost exactly like the real thing. It did, however, have two faults. The first was that after you got finished typing in your password, snatch.com would write out "user authorization failure." It would, then ask for your username and password 2 more times. After the 3rd "Failure", snatch.com would cut it's own process enabling you to log in for real. -- After a while, people should start to catch on to what was happening. (We could, of course, have set hosted the victim, but that would be asking for trouble.) The other problem, was that if at the Username prompt, you hit a bunch of returns quickly, there was a slightly noticable delay (1/8 second) until the next username prompt came up. We figure that this program could fool all non-frequent users, a good deal of the frequent users, a couple consultants, and the System Programmers on one of their bad days. If we had actually planned to use snatch.com, we would have eliminated the possibility of being caught by running snatch.com from some obscure user's account. At Loyola, that's pretty easy to do since passwords are set to the owner's school id number, and most people don't ever bother to change their passwords... We would have snatch.com write to some innocent sounding file in that user's account. As far as protection goes for this sort of program, I can think of three ways to guard against this. First, have the System Manager run a batch job that will stop any interactive process that has been laying dorminant for a given period of time. The next are specific to my program. Watch out for unusual responses (cursor jumps or time lags). Finally, if you get a user authorization failure, make sure that when you finally do get logged in, you get the proper number of login failure messages since your last login, otherwise, changing your password would be in order... Frank Gauthier Academic Computing. ========================================================================= Date: Thu, 21 Jul 88 09:58:32 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: SHERK@UMDD Subject: Write protect hardware In-Reply-To: Message received on Wed, 20 Jul 88 20:12:09 EDT ========================================================================= >Is there any way to design code so that a disk write to a writeprotected >disk will NOT generate a write error message? Yes. It is trivial in fact. The error message one sees is a DOS function and not a bios function. ========================================================================= Date: Thu, 21 Jul 88 18:09:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: WHMurray@DOCKMASTER.ARPA Subject: Re: Password Snatchers. In-Reply-To: Message of 21 Jul 88 03:34 EDT from "Back off man, I'm a scientist..." >The basic idea behind our snatcher.com was to have a terminal appear >to be unused and let the Victim "log in" there. We simulated the system >password request mechanism and When the person typed in his/her username and >password weintercepted it and wrote them out to a file. This attack belongs to the class called spoofs. It is well known and documented. Along with eavesdropping, it is one of the reasons that re-useable passwords should be limited to systems in which the terminal and link are dedicated to the application and in which there is no user programming (yes, Virginia, there really are such systems.) In other systems serious consideration should be given to the use of one-time passwords. (While there are other defenses against such attacks, they all rely upon knowledgeable and diligent users. These are known to be expensive.) William Hugh Murray, Fellow, Information System Security, Ernst & Whinney 2000 National City Center Cleveland, Ohio 44114 21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840 ========================================================================= Date: Thu, 21 Jul 88 21:08:00 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Back off man, I'm a scientist..." Subject: Forwarded submission. Passwords & Thug From: Jnet%"KERRY@TUFTS" 21-JUL-1988 20:38 To: JNET%"Frank@LOYVAX",KERRY Subj: Passwords & THUG Received: From TUFTS(KERRY) by LOYVAX with Jnet id 5372 for FRANK@LOYVAX; Thu, 21 Jul 88 20:37 EST Date: Thu, 21 Jul 88 20:35 EST From: Subject: Passwords & THUG To: Frank@LOYVAX Original_To: JNET%"Frank@LOYVAX",KERRY Couldn't help smiling at your suggestion that the System Manager run some job which logs out inactive jobs. We've put exactly that into place here at Tufts. It's called THUG (and I even forget why, although one of my staff wrote it!), and does just that sort of logging out. It even provides for two classes of exceptions. Is anyone there interested? Kerry Dugan Systems Programming Tufts University Medford, MA Kerry@Tufts.BITNET X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X Another file downloaded from: The NIRVANAnet(tm) Seven & the Temple of the Screaming Electron Taipan Enigma 510/935-5845 Burn This Flag Zardoz 408/363-9766 realitycheck Poindexter Fortran 510/527-1662 Lies Unlimited Mick Freen 801/278-2699 The New Dork Sublime Biffnix 415/864-DORK The Shrine Rif Raf 206/794-6674 Planet Mirth Simon Jester 510/786-6560 "Raw Data for Raw Nerves" X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X