From: Kenneth R. van Wyk (The Moderator) Errors-To: krvw@CERT.SEI.CMU.EDU To: VIRUS-L@IBM1.CC.LEHIGH.EDU Path: cert.sei.cmu.edu!krvw Subject: VIRUS-L Digest V5 #78 Reply-To: VIRUS-L@IBM1.CC.LEHIGH.EDU -------- VIRUS-L Digest Tuesday, 31 Mar 1992 Volume 5 : Issue 78 Today's Topics: Filler warning with SCAN & CPAV (PC) Re: Measuring Michelangelo (PC) New Virus???? (PC) Stoned, No-Int, Michelangelo, & Scanners (PC) Re: Victor Charlie program (PC) Re: Wanted: Info about "Form" virus (PC) Re: Which Package is Best? (PC) Re: Which Package is Best? (PC) Re: Network Viruses (PC) Re: Measuring Michelangelo (PC) Re: Measuring Michelangelo (PC) Re: Networks and viruses (PC) (Novell) Re: Dir-II virus (PC) Re: Measuring Michelangelo (PC) Re: Vax Virus & Patricia Hoffman (VAX/VMS) Re: CRCs- How do they work? Re: Origins of viruses Virus-L FAQ available by E-Mail request FTP site for Virus Simulations! (PC) McAfee V89B anti-virals uploaded to SIMTEL20 VIRUS-L is a moderated, digested mail forum for discussing computer virus issues; comp.virus is a non-digested Usenet counterpart. Discussions are not limited to any one hardware/software platform - diversity is welcomed. Contributions should be relevant, concise, polite, etc. (The complete set of posting guidelines is available by FTP on cert.sei.cmu.edu or upon request.) Please sign submissions with your real name. Send contributions to VIRUS-L@IBM1.CC.LEHIGH.EDU (that's equivalent to VIRUS-L at LEHIIBM1 for you BITNET folks). Information on accessing anti-virus, documentation, and back-issue archives is distributed periodically on the list. Administrative mail (comments, suggestions, and so forth) should be sent to me at: krvw@CERT.SEI.CMU.EDU. Ken van Wyk ---------------------------------------------------------------------- Date: Thu, 26 Mar 92 17:08:10 +0000 From: kenm@maccs.dcss.mcmaster.ca (...Jose) Subject: Filler warning with SCAN & CPAV (PC) A colleague has the following, peculiar problem: He loads the CPAV TSR from his AUTOEXEC.BAT, and later tries to use McAfee's SCAN. SCAN will sometimes report that the FILLER virus is there, ubt often will not. Oddly, CPAV doesn't seem to know about FILLER, so he's a wee bit nervous. Has anyone else encountered this behavior? Can it simply be attributed to weird anti-virus software interactions? - ------------------------------------------------------------------------------ |Kenneth C. Moyle MOYLEK@SSCVAX.CIS.MCMASTER.CA| |Computing Services Coordinator (Sciences) MOYLEK@MCMASTER| |Computing and Information Services ...!uunet!mnetor!maccs!kenm| |McMaster University - Hamilton, Ontario (Canada) | - ------------------------------------------------------------------------------ ------------------------------ Date: Thu, 26 Mar 92 09:13:00 -0800 From: "a_rubin@dsg4.dse.beckman.com"@BIIVAX.DP.BECKMAN.COM Subject: Re: Measuring Michelangelo (PC) KDC@UOFMCC.BITNET (Ken De Cruyenaere 204-474-8340) writes: > In virus-l # 5073 > bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes: > (regarding the media crying wolf) >>The next time (March 6, 1993), they probably won't. Since the virus >>continues to spread, this will cause much more hard disks to be wiped >>out than this year. That's why March 6, 1994 will be a good "next >>time"... :-) >Do you really think so ? I would have thought that copies of >Michelangelo, aside from captive copies, would be few and far between >after March 6th. Either: > --- found and erradicated before March 6th (largely thanks to all > the media attention) > --- or self destructed when it activated on march 6th. > (If Michelangelo doesn't kill itself on March 6th, it certainly > draws attention to itself...) Remember, infected floppies remain infected if they weren't used on March 6th. - -- Arthur L. Rubin: a_rubin@dsg4.dse.beckman.com (work) Beckman Instruments/Brea 216-5888@mcimail.com 70707.453@compuserve.com arthur@pnet01.cts.com (personal) My opinions are my own, and do not represent those of my employer. Ich bin ein Virus. Mach' mit und kopiere mich in Deine .signature. ------------------------------ Date: Thu, 26 Mar 92 17:10:10 +0000 From: kpjone01@ulkyvx03.louisville.edu Subject: New Virus???? (PC) Recently I had someone call about a virus called 'Barry Mannilo' sp?? Supposedly this virus plays some tune and then blanks the screen. The person calling said that one of her co-workers saw something on the news last week about this virus. Does anyone have any idea of what this person is talking about? Scan 86b does not notice any viruses on her system. Any help is greatly appreciated. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Kevin Jones KPJONE01@ULKYVX.CT.LOUISVILLE.EDU Lab Supervisor KPJONE01@ULKYVX.LOUISVILLE.EDU Computing and Telecommunications PHONE: 502-588-6303 University of Louisville, KY FAX: 502-588-0150 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ------------------------------ Date: Thu, 26 Mar 92 12:29:45 -0500 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: Stoned, No-Int, Michelangelo, & Scanners (PC) From: "William Walker C60223 x4570" Subject: Stoned, No-Int, and SCANV86B (PC) >As for why VSHIELD won't recognize it in Mr. Hogan's case, I don't know. >Since the scan strings for SCAN and CLEAN are faulty, it's possible that >the strings for VSHIELD are faulty, too. It may also be possible that >the strings these programs use were accidentally matched to the "Stoned" >virus, and Mr. Hogan has the REAL "No-Int" virus. Aryeh, do you have an >idea on this? A reoccurring problem. The important thing is that it is very good at detecting that a virus is present (in the case of MBR infectors, if it is unsure, what you normally get is the [GenB] flag. Lately my problem has been different - VShield refusing to permit me to work on a virus 8*). More humerously, before the 6th I was demonstrating to a group of people the [Mich] and forgot SafeMBR was loaded. Naturaly, once infected, it refused to allow the boot to complete. Since I did not have a "dumb" MBR available and the machine was running DOS 3.3, things becane a touch difficult to demonstrate. >I have not observed the identification problem Mr. Hama reports, that >SCAN 86B mislabels "Michelangelo" as "No-Int." SCAN 86B identified >"Michelangelo" as "Michelangelo Virus [Mich]" for me, and CLEAN 86B >successfully cleaned it. Perhaps there is another strain of >"Michelangelo," or Mr. Hama's copy of "Michelangelo" was damaged in such >a way to cause the misidentification. I have seen a minor change to the Michelangelo code do this, it has to do with the signature string hierarchy used by SCAN. Since what is being checked is technically no longer a "known" virus, this is considerably better than no report at all. >"Michelangelo" is not a strain of "Stoned," because it is too different, >but it is close enough for analysts to say that it may be a poorly hacked >version of "Stoned." If it walks like a duck, etc. It even makes some of the same mistakes as STONED (plus some new ones of its own 8*). Warmly, Padgett ------------------------------ Date: 26 Mar 92 16:58:35 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Victor Charlie program (PC) cs4cb3ii@maccs.dcss.mcmaster.ca (Group I) writes: > If anyone out there has used the program Victor Charlie could > you please give me your experiences with it. It has been created by a > company called "Bankok Security Associates" and is based in Thailand. Yes, I have reviewed about a year ago a version of this program. At that time is was nice, but didn't offer as much protection as its authors claimed. One of the tricks they used was to try to infect some files and automatically extract a common scan signature from them. Of course, it didn't work with the polymorphic viruses... I haven't seen any recent version of the program, though. If you can reach the developpers, tell John Deheaven and Alan Dawson that I say 'Hi'. Also tell them that the three Catman viruses they sent me do not seem able to replicate. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Bontchev@Informatik.Uni-Hamburg.De Fachbereich Informatik - AGN, rm. 107 C Tel.:+49-40-54715-224, Fax: -226 Vogt-Koelln-Strasse 30, D-2000, Hamburg 54 ------------------------------ Date: 26 Mar 92 17:53:14 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Wanted: Info about "Form" virus (PC) magnus@thep.lu.se (Magnus Olsson) writes: > I've looked it up in the Virus Catalog at ftp.informatik.uni-hamburg.de, > and (fortunately) it seems to be a pretty benign virus, that only Remember, there ain't no such thing as a benign virus. For any given virus it is possible to select a combination of hardware and software, in which the virus will cause damage. This law has been first formulated by Prof. Harold Highland, I believe. > 1) Exactly what does this virus do? The Catalog says that on the 24th > of each month, it "makes keys click and delays key action slightly" - > is that really all? Well, yes. What else did you expect? Overwriting the hard disk on March 6? :-) > 2) What is the simplest method of disinfecting the HD? Will it be > enough to just do a SYS command from a floppy, and is there any risk > of damage if I do that? Yes, SYS C: will do the job. In the worst case, you'll have to use Norton Disk Doctor's "make a disk bootable" option. > 3) No files seem to have been damaged (yet). However, the virus list > enclosed with SCANV86 said something about Form damaging data files. > In what way does it damage files? Well, let's say that the file VIRLIST.TXT that comes with SCAN is not the most reliable source of information... I don't remember what exactly the virus does, but I think that it saves the original boot sector and the second part of its body in a bad cluster. I have to disassemble it very carefully in order to decide whether it will overwrite something on some conditions. > 4) Is there any risk whatsoever in using the executable files that are > on my HD right now after disinfection, or should I restore everything > from the distribution disks? If I've understood everything correctly, > Form doesn't infect executables, so there shouldn't be any risk, but > I'd like to have a second opinion... You are right, this is a boot sector infector (like Ping Pong) and the files should be OK. > 5) Lately, my computer has hung at boot time with irregular intervals. > The problem went away when I removed the disk cache from CONFIG.SYS. > Could this be caused by the Form infection? Probably not. > Thanks in advance for your help! You're welcome. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Bontchev@Informatik.Uni-Hamburg.De Fachbereich Informatik - AGN, rm. 107 C Tel.:+49-40-54715-224, Fax: -226 Vogt-Koelln-Strasse 30, D-2000, Hamburg 54 ------------------------------ Date: 26 Mar 92 18:29:57 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Which Package is Best? (PC) trent@rock.concert.net (C. Glenn Jordan -- Microcom) writes: > >Yes, you are right. The generic disinfection is a Very Bad Idea > >exactly because of that. I admit that the implementation of this bad > >idea in the UT is excellent (e.g., it will never corrupt a file when > >it tries to recover it, etc.), but the idea is still bad, especially > >if the users begin to rely on it. McAfee Associates are trying to > >implement it too (with their GenP and GenB virus removal algorithms), > >and doubtlessly others will try too, but it's still a bad idea. > What is new here ? VIREX for the PC has had its Inoculate database > since the 2.0 release last summer, with the ability to generically I didn't say that it is new, I said that it is bad... :-) I admit that I didn't know that Virex-PC does this, but I don't have a copy of it. > We have found that the feature is very rarely used. Tech support Probably it hasn't beed advertized well enough... :-) Seriously, maybe you should review the documentation and make sure that you properly explain the people what they can achieve if they are using this feature. > By the way, I don't think a CRC is superior to a proprietary > Checksum for this kind of application. Oops, I cannot let this pass. Sorry, but you are wrong. The problems is not whether it's better to use CRC or something else (but just as easy to break); the problems is to use a -different- checksum algorithm on each installation. Only this way you can ensure that the virus writer will not crack your particular algorithm. The CRC has this nice property that it is known how to generate good different algorithms. Yisrael Radai has submitted an excellent paper on this subject to the IFIP conference in Madrid. As soon as it gets published, I'll ask him to provide it in electronical form for anonymous ftp. It's a -must- for any wannabe developper of integrity checking software. Several developpers of anti-virus software produce internally flawed software just because they don't bother to listen what the scientists say about it... Fred Cohen has predicted the decline of the scanners about eight years ago. > Checksumming is faster and > though each individual checksumming method is sucessfully attackable, > no one's has yet been attacked that I'm aware of, and the method is > easy to alter between version updates. Whether it has been done or whether you are aware of it is not signifficant. What is signifficant is that the one method is intrinsically flawed, while the other one isn't. BTW, long time ago, somebody in Bulgaria has cracked the checksumming algorithm in FluShot+ 1.80 and has distributed a program which modifies COMMAND.COM in such a way that it displays "FluShot is STUPID! Press any key" when run - all this without the modification act being detected by FluShot's monitor (which is easy) and even by its checksummer (which is the tricky part). Unfortunately, I don't have copy of this program handy. Just remember - if it can be done, some perverted hacker out there will do it. > In the real world samples I've > examined, duplicate checksums for different whole files have no real > impact on the protection method. Let's not be shortsighted. What still works today (but is flawed) may not work tomorrow. I guess that when the first scanners appeared (especially the programmable scanners) people like you thought that it is a really great idea - there were a couple of dozens of viruses, and maintaining a scanner was so easy... Especially when the Icelandic viruses proved that the monitoring programs are a dead end. > In my opinion, CRC's are a marketing > gimmick pure and simple. Nice, particularly nice sounding, but not > worth slowing down for, yet. The difference in relative > "infallibilty" in the real world is not worth anything. Sorry, but you are wrong. The method that UT uses has a very stable scientific background. Please, get aquainted with the underlying theory before claiming that it's worthless. > Maybe later, who knows. Well, the theory and the people who have developped it -do- know, believe me. > As far as the quick look-up-table CRC calculations go, I'd rather have > use the same code/data space for virus detection. Maybe that's one > reason why "Untouchable" is missing such an alarming number of known > viruses with their scanner ? Nope, the reason is that the people who developped it tried to produce a good integrity checker (and they succeeded). When they tried to market it, they suddenly found out that everybody seems to think that anti-virus program = scanner. And every reviewer checks how many known viruses the package is able to scan for. Don't laugh, I observed this attitude even in a competent anti-virus researcher. That's why they patched a scanner in a hurry. Is it surprizing that the scanner part is so bad? I hope that they have learned the lesson and will improve the product. Disclaimer: I have neither developped the Untouchable, nor am trying to sell it. I'm even not using it. But I know the underlying theory... :-) Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Bontchev@Informatik.Uni-Hamburg.De Fachbereich Informatik - AGN, rm. 107 C Tel.:+49-40-54715-224, Fax: -226 Vogt-Koelln-Strasse 30, D-2000, Hamburg 54 ------------------------------ Date: 26 Mar 92 18:59:23 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Which Package is Best? (PC) RADAI@HUJIVMS.BITNET (Y. Radai) writes: > posted so late), I got a look at Fred Cohen's ASP integrity shell and > I was very favorably impressed by it. I don't yet have any hands-on > experience with it, so I can't really compare it with packages like UT > or IM, but it looks like a very serious contender, much better than > the version of ASP which I read about a couple of years ago. Well, the current version seems to be as secure as UT. It is slower, because it uses cryptographic checksums. It's access control can be bypassed by a knowledgeable attacker who has a bootable diskette and runs Norton Utilities in /Maintnance mode, as I showed to Dr. Cohen :-), and a virus can infect it in the same way as it can infect an UT-protected system. (BTW, I discussed this kind of attack with him and he agreed that an integrity checker is not able to stop it, but that such a virus will spread so slow, that it probably won't be a practical danger.) It also can be disabled by a virus which is speciafically oriented to the product, if the user does not always boot from a clean system. The same is true for UT. Maybe Cohen's product tends to be a bit more prone to that, since it does not strongly advise the user to regularly boot from a clean system and perform a full integrity check. Anyway, the two products belong to different classes (UT is an integrity checker, while the ASP Toolkit is an integrity shell), so a straightforward comparison is not very fair. > fair. However, when I answered Vesselin's question, my criterion in > comparing the two checkers for speed was to use the *fastest* mode > which each product provides. I understand, but I still claim that the check is unfair. There is nothing in IM, which provides the same level of security as UT's quick check, so you just cannot compare. IM's full check is more secure than UT's quick check (and slower), and IM's quick check is much less secure than UT's quick check (and faster). That's why you should compare what provides the same level of security. For those two programs this is only the full check mode. > Sorry, but I don't think this is a very practical scenario. At best > it would delay the detection of the virus by a tiny amount. That would > hardly be worth any virus writer's effort. This is probably not a practical scenario, but it is possible. Just like the CRC cracking - do you seriously expect that somebody's virus will try to crack the CRC checksums by collecting a large number of examples and trying to solve the appropriate system of linear equations in order to find the polynomial? C'mon, everybody who knows how to do that is more likely to do something else than creating viruses... Yet you have taken steps to confront this attack in UT. I'm just pointing you out another equally unprobable but possible scenario. I agree that the UT's quick check is secure enough for practical use, it is is not abused and the user runs the full check after booting from a clean diskette, say, once per month. > you're so *glad* about this. Anyway, it looks like generic disinfec- > tion is becoming more and more popular; I know of 4 products now which > do it, the most recent being McAfee's SCAN/AG and CLEAN/GENERIC start- > ing with Ver. 86, and I'm sure there'll be many more in the future. Yes, unfortunately, this will certainly happen. And the (ignorant) users will begin to rely entirely on such methods just like they are entirely relying on scanners... :-( The same goes for the heuristic analyse... Those are two very tempting ideas, especially now, when the producers of scanners have begun to realize that scanning is doomed... They desperately seek something to replace it with, so that they won't be faced with the problem of hundreds new viruses appearing each month, polymorphic viruses, constant updating which the user is uwilling to pay for and so on... Heuristic analyse and generic removal seems a "natural" way to solve the problems that the virus-specific software has... Unfortunately, it won't work either, just the users will have to pay for yet another bad move... Sorry, Yisrael, the above was not against UT in particular, it was targeted to those who intend to make their users rely entirely on these "new" approaches... A much better solution is to build a multi-level defense, with BIOS and DOS support, and with accent on integrity checkers and integrity shells. I'm not saying that the virus-specific scanners, the monitors, and the heuristic analyzers are just crap, I'm saying that they are just a small (needed, but not very important) level in this defense. > That's correct only if the size of the table remains *fixed* (or in- > creases more slowly than the number of viruses). Right, but if the memory requirements increases faster than the number of new viruses, the program won't be useful after a while... :-) > In general, the > probability of a collision depends on the number of entries divided > by the length of the hash table. ...and of the quality of the hash function, of course. > The size of UT's table is kept > *proportional to the number of viruses*, so the probability of a > collision remains constant, hence the time remains constant also. ...in practice. In you add only a reasonable amount of new viruses and have enough memory. BTW, can you tell us some numbers? Suppose a computer with 512 Kb RAM, running DOS 5.0. If the user boots from the safe diskette with only the OS and UT on it, how much memory will UT require and how many new signatures will be possible to add without running out of memory? > free, but of ensuring that *all files* on the disk are. I had given > measures for ensuring that the MBR and boot sector were clean (by > FDISK/MBR and SYS; it's not clear to me why one has to "prove" this), Because your statement implies that you trust those programs. What about a virus, shich seeks the copy of the boot sector in them and installs itself there? > hence I assumed you were talking of how to ensure that the files on > the user's disk were virus-free before the initial checksums are com- > puted. As you know, inter-machine file- and sender- authentication is > a way of greatly increasing the probability of that. Ah, yes, in theory. If we could only make any software supplier provide a way its software to be authenticated and if we could force all the users to bother to check the authentication... :-) > There is no such thing as a "long run" in this context, only a con- > stant escalation on both sides. The whole point of generic disinfec- > tion is that at any given moment there will be new viruses which KVSs > have not yet been taught to remove, yet the *great majority* of them > will be removable by a generic disinfector such as UT. As for the Yep, but a good virus-specific disinfector will be able to remove more viruses than a generic one, especially when the virus writers learn how to create viruses which are impossible to remove generically, regarless how clever your algorithm is (unless it's a full backup of the file). You know very well that such viruses are possible. > often as KVSs need to be). Besides, remember that I didn't say that a > known-virus scanner/remover wasn't necessary *at all* with UT, only > that it's much *less* necessary. Yes, and I fully agree with this. I just wanted to point out one more time that the users must not rely -entirely- on a generic remover, and that a virus-specific scanner is not -entirely- useless. All those are just levels in the multi-level defense. Not as important as the integrity checker, but necessary. > VB>I said "a Lehigh-type virus", not "the Lehigh virus". I meant a virus, > VB>which hides only in one place in the system... > How would such a virus spread?? The only types of viruses I can think > of which hide in only one place are those which hide in the MBR, the > DOS boot sector (or a hidden system file), or COMMAND.COM, and I have > covered these cases (by FDISK/MBR, SYS, and refreshing COMMAND.COM, Think a little bit more. How about the programs, executed from CONFIG.SYS and AUTOEXEC.BAT? There are already several device driver infectors, which parse CONFIG.SYS for a target to infect. > resp.). To spread successfully, a virus which is limited to a single > place would have to be in a program which is present on nearly all hard > disks and diskettes and which is frequently executed; how many pro- Yep. > grams other than the above do you know of which satisfy these condi- > tions? Enough, see above. > We both know that stealth viruses can be taken care of by booting from > a clean diskette. Of course. My point was that the virus writers devised an entirely new method of attack against the integrity checkers, which forced us to instruct the user to use a safe diskette, which is often inconvenient for him/her and therefore s/he will dumbly not use it, regarless how persistent you are... :-) > Do you have some other attack in mind? Yep. > VB>I think you'll agree that if a system is infected with a virus, which > VB>infects only one object in the system, and which infects other objects > VB>only if they are modified, will not be detected by a checksummer, if > VB>the checksummer is installed on an already infected system. > I think what you're trying to describe is what I referred to as an > "ambiguity" virus in my paper. Nope, I don't mean a virus which is there, but never spreads. I mean a virus, which spreads only on occasions when it will be undecidable for the integrity checker whether the change has been caused by a virus or not. Such virus -will- spread (although slowly), unlike the "ambiguity" virus. > It can't be detected by a checksummer > *alone*, but there are other measures which can be taken in this case, > and who says that the burden must be on a checksummer alone? Of course, if it is known, a virus-specific scanner will detect it. But what if it is a new virus? > VB> In fact, > VB>it is possible to design a virus, which will even prenentrate a > VB>checksum-protected system, even if the integrity checkers is installed > VB>before the virus. > Even if the system is booted from a clean diskette (and the checker is > UT)? Yep. It's not important how secure the integrity checker is. > Please explain. Privately. > >> I can only presume that [Hamilton] was not running Untouchable's > >> resident module, UTRes, at the time, because it *does* detect all the > >> common viruses in memory. > VB> > VB>The resident module - maybe, but the off-line scanner should detect > VB>them too, IMHO... > Yes, it should too. The reason I mentioned only UTRes is that it is > normally resident, whereas UTScan is not normally run, except during > installation. Well, so does UTScan detect the viruses in memory or not? If it does, why it didn't in the quoted case? > VB>As a conclusion - the UT is an excellent product and I recomend it to > VB>everybody. However, let's better educate the users how to do proper > VB>backups, instead of creating in them a false sense of safety (safety, > VB>not security, since I -know- that the UT is secure) by letting them > VB>believe in a magical generic removal method. > Concerning backups, I wrote something about them in my last posting > (to which you unfortunately have not reacted): > >>That's true in theory, but in practice most users do not keep backups, You have quoted my reaction. I said: "Educate the users how to do proper backups!" and "Don't rely entirely on generic virus removal!". Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Bontchev@Informatik.Uni-Hamburg.De Fachbereich Informatik - AGN, rm. 107 C Tel.:+49-40-54715-224, Fax: -226 Vogt-Koelln-Strasse 30, D-2000, Hamburg 54 ------------------------------ Date: 26 Mar 92 12:03:06 +0000 From: stephenm@project4.computer-science.manchester.ac.uk (M. B. Stephens) Subject: Re: Network Viruses (PC) suresh@iss.nus.sg (Suresh Thennarangam - Research Scholar) writes: >1> Is it possible to bypass the read-only file-locking mechanism > provided by Novell Netware and Banyan Vines ? >2> Is it possible to bypass the read-only file server option in 3COM ? >3> Technically, there ought to be a low-level hack way to achieve >both, but has anyone come across a virus that does this ? If you are running a dedicated fileserver and a malicious program is running on a station then you are talking about two different computers which have NOTHING in common at the low level. The program on the station cannot modify the disk on the fileserver by writing directly to the disk controller on the file server. This is similar to my inability to thump a guy talking to me on a telephone if he is in another room. To stretch this analogy (probably too far) the best I can do is ask him to thump himself. My knowledge of networks is limited to one running RM-NET, a derivative of MS-NET supplied by Research Machines Ltd. (a British company). This system has so far proved reliable in a difficult (university) environment. ------------------------------ Date: Thu, 26 Mar 92 21:42:16 +0000 From: rslade@sfu.ca (Robert Slade) Subject: Re: Measuring Michelangelo (PC) KDC@UOFMCC.BITNET (Ken De Cruyenaere 204-474-8340) writes: > I would have thought that copies of >Michelangelo, aside from captive copies, would be few and far between >after March 6th. Either: > > --- or self destructed when it activated on march 6th. > (If Michelangelo doesn't kill itself on March 6th, it certainly > draws attention to itself...) Unfortunately, we have every reason to believe that Vesselin is correct in his statement that each successive year the Michelangelo problem will be greater than before. We have, now, a reputable report of Michelangelo's existence prior to March of 1991, and therefore proof that the virus will survive. Actually, no proof is needed, as this is quite obvious from the operations of the virus. On March 6 most copies of Michelangelo on hard disks will self destruct. However, as it is a boot sector infector, and a member of the eminently "successful" Stoned family, we know that there is an infected floppy which was used to infect the hard disk in the first place. The majority of floppy disks used around the infected machine will also be infected, and thus "store" copies of the virus which allow it to survive. For those "in the know" it is difficult to understand why these copies will not be found and cleaned. However, the vast majority of the computer using population does not understand the situation. I have, on more than one occasion, been requested to clean up a BSI infection on a hard disk, and been refused access to the floppies used around that machine. (If successful at gaining access to the floppies, the tone usually changes radically when I find a 30 to 80% infection rate on the diskettes.) There is, in this case, an additional vector: that of older, non-turbo XT and PC level machines. Indeed, in one local case, a Michelangelo infection was detected on such a machine and tested (by setting the clock ahead to March 6). Since nothing happened, they figured the virus was a hoax ... ============== Vancouver | "A ship in a harbour Institute for Robert_Slade@sfu.ca | is safe, but that is Research into rslade@cue.bc.ca | not what ships are User CyberStore Dpac 85301030 | built for." Security Canada V7K 2G6 | John Parks ------------------------------ Date: 26 Mar 92 21:58:32 +0000 From: jgunders@copper.denver.colorado.edu (James P. Gunderson) Subject: Re: Measuring Michelangelo (PC) KDC@UOFMCC.BITNET (Ken De Cruyenaere 204-474-8340) writes: { in response to an anaysis of Michaelangelo's impact next year } >after March 6th. Either: > --- found and erradicated before March 6th (largely thanks to all > the media attention) > --- or self destructed when it activated on march 6th. > (If Michelangelo doesn't kill itself on March 6th, it certainly > draws attention to itself...) > Ken Except for all those floppy disks, that were the vector this time around. Do we really believe that everyone traced down the original infection diskette and cleaned it? And, of course there are all those silly people who still do nothing about checking their software. What if they got an infected diskette on Saturday the 7th? I think we will have to keep March the sixth on the calender for a while yet. Speaking of which, wasn't someone working on a viral "Hot Day" calander? No signature, just a name. JIM ------------------------------ Date: Thu, 26 Mar 92 15:42:38 -0700 From: kev@inel.gov (Kevin Hemsley) Subject: Re: Networks and viruses (PC) (Novell) Leonard Erickson <70524.2603@CompuServe.COM> writes: >Under Novell Netware (and I would assume under the other Network OSes) >the read-only attribute is *exactly* the same as that given under DOS. >Thus it is changeable by user software. >BUT... If a user doesn't have "Modify" rights in the directory (or to >the files under Netware 3.x) he cannot change the flag. I'm afraid this is not quite correct. A user only needs READ, WRITE and FILE SCAN Rights in order to change an ATTRIBUTE. There still seems to be some confustion about NetWare RIGHTS and ATTRIBUTES. ATTRIBUTES are an emulation and an extension of regular DOS file attributes. All DOS attributes (or NetWare ATTRIBUTES which exactly emulate DOS attributes) can be changed by viruses. Viruses can therefor bypass most NetWare attributes. There are only two NetWare ATTRIBUTES which may prohibit viral infection, they are EXECUTE ONLY and SYSTEM. The SYSTEM NetWare ATTRIBUTE does not perfectly emulate the DOS system attribute, and can prohibit viral infection. RIGHTS are NetWare's own security implementation and can provide much more protection against viruses than DOS can. Viruses cannot directly alter assigned effective RIGHTS. ^^^^^^^^^^^^^^^^^^^^^^^^^ *HOWEVER*, assigned Rights CAN be overridden through the use of the Supervisory Right or by using an account with Supervisor or Supervisor- equivilant rights. The SUPERVISORY right will supersede any restricions placed on subdirectories or files with an inherited rights mask. And a Supervisor or equilivant account can bypass all your work in properly setting up user accounts. Use of Supervisor accounts should be used sparingly and not as general work accounts by network administrators. - -- Kevin Hemsley | Information & Technical Security | The cute message that used to be Idaho National Engineering Laboratory | here was destroyed by a .sig (208) 526-9322 | virus on March 6th. kev@inel.gov | ------------------------------ Date: 26 Mar 92 22:40:04 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Dir-II virus (PC) MWHANLEY@SUVM.BITNET (Matthew W. Hanley) writes: > I have a user that came in with a hard drive infected by the > DIR-II virus. He claims that VSCAN does not detect it, but F-PROT > does, although F-PROT will not remove it. Since it is his home > machine I cannot verify this, so my question is: How should he go > about removing the virus? I'm hoping that there is a solution other > than reformatting the hard drive. Thanks. 1) Execute one of the infected programs. Yeah, right. 2) For each directory of the disk, execute the commands ren *.com *.coz ren *.exe *.exz 3) Reboot from a non-infected write-protected system diskette. 4) For each directory of the disk, execute the commands ren *.coz *.com ren *.exz *.exe 5) Run CHKDSK /F (optional). That's all, the disk should be cleaned. Just make sure that you don't run CHKDSK or any other disk repairing utility -before- step 5. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Bontchev@Informatik.Uni-Hamburg.De Fachbereich Informatik - AGN, rm. 107 C Tel.:+49-40-54715-224, Fax: -226 Vogt-Koelln-Strasse 30, D-2000, Hamburg 54 ------------------------------ Date: 26 Mar 92 22:50:02 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Measuring Michelangelo (PC) KDC@UOFMCC.BITNET (Ken De Cruyenaere 204-474-8340) writes: > Do you really think so ? I would have thought that copies of > Michelangelo, aside from captive copies, would be few and far between > after March 6th. Either: > --- found and erradicated before March 6th (largely thanks to all > the media attention) > --- or self destructed when it activated on march 6th. > (If Michelangelo doesn't kill itself on March 6th, it certainly > draws attention to itself...) You forget that meanwhile it has infected thousands of diskettes which are a potential vector for re-infection. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Bontchev@Informatik.Uni-Hamburg.De Fachbereich Informatik - AGN, rm. 107 C Tel.:+49-40-54715-224, Fax: -226 Vogt-Koelln-Strasse 30, D-2000, Hamburg 54 ------------------------------ Date: Thu, 26 Mar 92 22:00:37 +0000 From: rslade@sfu.ca (Robert Slade) Subject: Re: Vax Virus & Patricia Hoffman (VAX/VMS) ROY@mvax1.me.liverpool.ac.uk (Roy Coates) writes: > >1. Has anyone ever come across a virus targetted at VAX/VMS ?? There were two (rather similar) VMS viral type programs in 1989, seemingly modelled after the Morris/Internet/UNIX worm of 1988. [Moderator's note: The two versions of the DCL-based WANK ("Worms Against Nuclear Killers") worm were found on DECNET networks during October 1989. See CERT Advisory CA-89:04, titled "WANK Worm on SPAN Network", for more details. The advisory is available by anonymous FTP on cert.sei.cmu.edu (192.88.209.5) in the pub/cert_advisories directory.] >2. Where can I contact Patricia Hoffman ?? Voice or fax 408-246-3915, BBS 408-244-0813. =================== Vancouver | "Power users think Institute for Robert_Slade@sfu.ca | 'Your PC is now Research into rslade@cue.bc.ca | Stoned' is part of User CyberStore Dpac 85301030 | the DOS copyright Security Canada V7K 2G6 | line." R. Murnane ------------------------------ Date: 26 Mar 92 22:34:15 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: CRCs- How do they work? rmg53668@uxa.cso.uiuc.edu (Ryan M. Grant) writes: > In my understanding CRCs add up the bytes of a file with certain > significance added to each byte (very fuzzy here). The question is, In fact, the CRC algorithm is very well defined. (Arrgh, Yisrael, your paper is -really- needed to be read by a lot of people...) > if a CRC can guarantee unique files with one whatever-byte number, why Of course, it can't. > cant the file just be stored as its CRC? If not, I suspect that it > WOULD be possible to get two files with the same CRC...and if this is > the case, how can anyone be sure when they restore a damaged file > through the use of a CRC? I'm sure that if PART of the file were They cannot be -absolutely- sure. They can only be DAMN MUCH sure. If you have 2^16 files of the same size but with different contents, at least two of them will have the same CRC-16. If you have 2^32 such files, at least two of them will have the same CRC-32. This is secure enough for practical purposes. > file with the same CRC would probably be radically different. Where > am I right and where am I completely lost in this post? Completely lost, sorry. The only way to store -all- the information of the file is to store a (possible archived) copy of itself. Unfortunately, this is space-expensive. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Bontchev@Informatik.Uni-Hamburg.De Fachbereich Informatik - AGN, rm. 107 C Tel.:+49-40-54715-224, Fax: -226 Vogt-Koelln-Strasse 30, D-2000, Hamburg 54 ------------------------------ Date: 26 Mar 92 22:55:19 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Origins of viruses U58288%uicvm.uic.edu@OHSTVMA.ACS.OHIO-STATE.EDU writes: > >Wrong. The first Bulgarian virus (Old Yankee) was written in November > >1988 (I personally know the person who wrote it). > Please, tell us who these people are. Sigh... Unfortunately I can't - for privacy reasons... Besides, there is no way that I can prove my claims. I just happen to know the guy (and some others), but if they say "nope, it wasn't me", I cannot prove anything... I suggest that you read my paper about the Bulgarian virus factory, available for anonymous ftp from ftp.informatik.uni-hamburg.de (IP=134.100.4.42), directory pub/virus/texts/viruses, file factory.zip. > I'm sure many virus authors are known. Yes, at least I know several of the Bulgarian virus authors. > Let's expose them, and treat them to the scorn and derision We can't do that, unfortunately... :-( > they deserve. And, where appropriate, let the victims band together > and sue the originators for the damage they have caused. As long as The people I know are in Bulgaria. To release a virus there is not a crime. How are you going to sue them? > the perpetrators go unpunished, or worse, are treated as folk heros, > there will be no end to these problems. I agree with you, but what we can do? Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Bontchev@Informatik.Uni-Hamburg.De Fachbereich Informatik - AGN, rm. 107 C Tel.:+49-40-54715-224, Fax: -226 Vogt-Koelln-Strasse 30, D-2000, Hamburg 54 ------------------------------ Date: Thu, 26 Mar 92 17:43:39 -0500 From: Jon Freivald Subject: Virus-L FAQ available by E-Mail request I'm in the process of setting up a mail-server. So far it is working fine (I think!) with plain text files, so the Virus-L FAQ is available by E-Mail request. Send a message as follows: To: file-request@jaflrn.uucp Subj: doesn't matter get dos/virus/virus-l.faq If you have any problems, please E-mail me so I can look into it pronto. Jon ============================================================================= Jon Freivald ( jaf@jaflrn.uucp ) Nothing is impossible for the man who doesn't have to do it. ============================================================================= ------------------------------ Date: Thu, 26 Mar 92 18:23:44 -0500 From: I'M NOT JUST A NUMBER! Subject: FTP site for Virus Simulations! (PC) I came across an interesting file the other day. And I thought some of you would enjoy these too! FTP Site: risc.ua.edu Directory : pub/ibm-antivirus File Name: virsimul.zip This file contains simulations of: 1. Cascade 2. Den Zuk 3. Italian Pest 4. Jerusalem 5. Fu Manchu None of these files are infectious, and are not detected by any anti-virus software. This was my first oportunity to experience any of these viruses, and what more could you ask for..they're not infectious. (It's like sex w/o protection) Anyway, Cascade is pretty impressive and the others are interesting too! Maybe these programs could help you with a practical joke on April 1st? __ooOO None of my friends are safe!! OO Good Luck and Good Fun. ------------------------------ Date: Sun, 29 Mar 92 01:43:02 -0500 From: mcafee@netcom.com (McAfee Associates) Subject: McAfee V89B anti-virals uploaded to SIMTEL20 I have uploaded to WSMR-SIMTEL20.Army.Mil: pd1: SCANV89B.ZIP VIRUSCAN Version 89-B virus scanner for PC's CLEAN89B.ZIP CLEAN-UP Version 89-B virus remover for PC's, LAN's VSHLD89B.ZIP VSHIELD Version 89-B infection prevention TSR NETSC89B.ZIP NETSCAN Version 89-B virus scanner for LAN's WHAT'S NEW IN VERSION 89-B Version 89-B of the VIRUSCAN series fixes false alarms on the Hafen virus in MONITOR.EXE, a utility manufactured by Adaptec Corp. for SCSI controller cards, and on the Generic File virus in BLOCKCUR.COM, a utility that comes with Toshiba laptops. VERSION 89 Versions 87 and 88 of VIRUSCAN were skipped due to Trojan Horse versions which appeared on BBS'es in the US and Europe, respectively. Fifty-three viruses were added in this release, bringing the total number of viruses to 534, or counting variants 1,263. Version 89 now also detects all viruses that have been encrypted by the new Dark Avenger Mutation Engine. The Pogue virus was the first of these polymorphic viruses and has been reported Austalia, Norway, and the United States. In the past month two additional mutated viruses have appeared--the Fear virus and the Dedicated virus. It seems certain that many more such viruses will appear in the near future, since the object code for the mutating engine has now appeared on many virus-exchange BBS'es around the world. Also added in this release is capability to detect nonspecific (new or unknown) file-infecting viruses. When a file is detecting containing an unknown virus, SCAN will report the presence of a Generic File Virus [GenF]. Files containing a Generic File Virus can be removed by running SCAN with the /D option, however, please contact McAfee Associates to send a specimen in for analysis. SCAN Version 89 of SCAN now includes a "save option" feature that allows systems administrators to pre-configure SCAN to default to scanning specific drives, checking or not-checking memory, creating a specific report, or any other command line setting for their end users. The /SAVE option will save all of the other options that are specified on the command line, or will reset to the original SCAN defaults if no other options are specified on the command line. The saved options will be added to the SCAN.EXE file. This option should be set up by the systems administrator prior to distribution to the end-users and installation on the end-users' machines. A new VALIDATE.COM has been included in this release. It must be used instead of the old version if the /SAVE option is used. Otherwise, the validation results before and after /SAVE will not match. CLEAN Version 89 of CLEAN-UP adds eight new removers for the 855, 1241, 1554, Holocausto, M128, Mardi Bro.'s, Mosquito, and Traceback/3066 viruses. VSHIELD Version 89 of VSHIELD adds the /SAVE option (see SCAN for details), plus two other new features: The /RECONNECT option allows VSHIELD to regain control of the system interrupts after they have been trapped by another program. This allows VSHIELD to be loaded before network drivers. Then, after the network drivers have loaded, VSHIELD can be reconnected without having to be first unloaded from memory. The /NOCONT option prevents a user from being able to proceed with the execution of programs that have not been certified when VSHIELD is run with the /CERTIFY option. NETSCAN NETSCAN adds detection of all new viruses added in this release. VALIDATE Version 0.4 of VALIDATE has been released. This version is able to validate the software after the /SAVE switch has been used to store options in SCAN and VSHIELD. (VALIDATE.COM is included in the .ZIP files for all programs.) VALIDATION DATA CLEAN-UP V89B (CLEAN.EXE) S:92,579 D:03-26-92 M1: CD93 M2: 0769 NETSCAN V89B (NETSCAN.EXE) S:71,624 D:03-26-92 M1: 9ABA M2: 10A3 VIRUSCAN SCANV89B (SCAN.EXE) S:73,542 D:03-25-92 M1: 64FC M2: 0448 VSHIELD VSHLD89B (VSHIELD.EXE) S:40,359 D:03-25-92 M1: 39E5 M2: 132D VALIDATE V04 (VALIDATE.COM) S:12,197 D:03-24-92 M1: D5BB M2: 166F Aryeh Goretsky McAfee Associates Technical Support - - - - McAfee Associates | Voice (408) 988-3832 | mcafee@netcom.com (business) 1900 Wyatt Drive, Suite 8| FAX (408) 970-9727 | "Log... from Blammo" Santa Clara, California | BBS (408) 988-4004 | 95054-1229 USA | v32bis(408) 988-5190 | CompuServe ID: 76702,1714 ViruScan/CleanUp/VShield | HST (408) 988-5138 | or GO VIRUSFORUM ------------------------------ End of VIRUS-L Digest [Volume 5 Issue 78] *****************************************