Return-Path: XPUM04@prime-a.central-services.umist.ac.uk Received: from G.SEI.CMU.EDU by ubu.cert.sei.cmu.edu (5.61/2.3) id AA21832; Thu, 7 Jun 90 18:42:52 -0400 Received: from SEI.CMU.EDU by g.sei.cmu.edu (5.61/2.5) id AA16665; Thu, 7 Jun 90 18:42:52 -0400 Received: from nsfnet-relay.ac.uk by sei.cmu.edu (5.61/2.3) id AA15292; Thu, 7 Jun 90 18:42:43 -0400 Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa29014; 7 Jun 90 20:36 BST From: Anthony Appleyard To: DAVIDF@cs.heriot-watt.ac.uk Date: Thu, 07 Jun 90 15:35:24 BST Message-Id: <$TGVGDBVHFKVV at UMPA> Subject: Virus-L vol 0 issue #0721 Virus-L Digest Thu, 21 Jul 88, Volume 0 : Issue #0721 Today's Topics Re: Write Protect Hardware P.S. Password Snatchers. Write protect hardware Re: Password Snatchers. Forwarded submission. Passwords & Thug ------------------------------ 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: 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 -------------------- *** end of Virus-L issue *** Return-Path: XPUM04@prime-a.central-services.umist.ac.uk Received: from G.SEI.CMU.EDU by ubu.cert.sei.cmu.edu (5.61/2.3) id AA25851; Tue, 12 Jun 90 06:39:06 -0400 Received: from SEI.CMU.EDU by g.sei.cmu.edu (5.61/2.5) id AA12952; Tue, 12 Jun 90 06:39:02 -0400 Received: from nsfnet-relay.ac.uk by sei.cmu.edu (5.61/2.3) id AA04204; Tue, 12 Jun 90 06:38:43 -0400 Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa09491; 12 Jun 90 11:08 BST From: Anthony Appleyard To: KRVW <@NSFnet-Relay.AC.UK:KRVW@sei.cmu.edu> Date: Tue, 12 Jun 90 11:03:32 BST Message-Id: <$TGVTCZHTCBQH at UMPA> Subject: Virus-L vol 0 issue #0721 Virus-L Digest Thu, 21 Jul 88, Volume 0 : Issue #0721 Today's Topics Re: Write Protect Hardware P.S. Password Snatchers. Write protect hardware Re: Password Snatchers. Forwarded submission. Passwords & Thug ------------------------------ 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: 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 -------------------- *** end of Virus-L issue ***