To: VIRUS-L@LEHIGH.EDU Subject: VIRUS-L Digest V6 #7 -------- VIRUS-L Digest Wednesday, 13 Jan 1993 Volume 6 : Issue 7 Today's Topics: WARNING - Virus found in file ypcbr101.zip on simtel archive. (PC) Re: Export restrictions of anti-virus software? Yes, but is it a virus? Math Models of Polymorphic Viruses How to measure polymorphi Infection question (was: Viral Based Distribution System) Re: How to measure polymorphism Measuring polymorphism OS2SCAN99 checked (OS/2) MtE info. (PC) Romanian Vampirus (PC) Monkey [Mon] and Multi-2 [M12] viruses (PC) Possible new PC viruses ? (PC) Re: Vshield vs Virstop (PC) Re: False positive in the new PKZIP (PC) Re: Known virus that tweaks PC date function? (PC) Problems with Filler and Isrealie boot virus in Windows (PC) Re: False positive in the new PKZIP (PC) Invalid Boot Sectors (PC) How do MtE utilizing viruses detect themselves? (PC) Internet Worm Functions - part 2 (CVP) 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@LEHIGH.EDU. Information on accessing anti-virus, documentation, and back-issue archives is distributed periodically on the list. A FAQ (Frequently Asked Questions) document and all of the back-issues are available by anonymous FTP on cert.org (192.88.209.5). Administrative mail (comments, suggestions, and so forth) should be sent to me at: . Ken van Wyk ---------------------------------------------------------------------------------------------------- Date: Mon, 11 Jan 93 00:32:42 +0000 From: johnm@bowen.cc.utas.edu.au (John Miezitis) Subject: WARNING - Virus found in file ypcbr101.zip on simtel archive. (PC) [Moderator's note: I sent this out on VALERT-L earlier this week along with a note saying that the infected file was removed from the archive (thanks Keith!). Everyone that downloaded the infected file should closely examine their systems.] The zip archive ypcbr101.zip was downloaded from Simtel-20 and the oak mirror on archie.au and both files were found to contain the 1800 variant of Dark Avenger in the executable yapcbr.exe. The file was unzipped and then tested using F-PROT206a which was able to remove the virus. Adminstrators at both these sites will be informed as will the author of the program. - -- _______________________________________________________________________________ John B Miezitis, University of Tasmania, Computing Centre. Ph +61 02 202811 email: John.Miezitis@cc.utas.edu.au | Belgium man Belgium!!! - Z. Beeblebrox _______________________________________________________________________________ ------------------------------ Date: Fri, 08 Jan 93 18:29:07 +0000 From: aryeh@mcafee.com (McAfee Associates) Subject: Re: Export restrictions of anti-virus software? Good morning Vesselin, You write: [From Robert Heuman of Canada's posting on export controls on AV software, of which I've deleted quite a bit for brevity. AG] >Source: A Guide to Canada's Export Controls, January 1, 1992 [...deleted...] >Page 25, item 1154. Software > >1154.a.c.3. "Software" designed or modified to protect against >malicious computer damage, e.g., viruses. > > >Page 1, General "Software: Note > >This List does not embargo "software" which is either: >1. Generally available to the public by being: > a. sold from stock at retail selling points, without restriction, > by means of: > 1. Over the counter transactions > 2. Mail order transactions > 3. Telephone call transactions _AND_ > b. Designed for installation by the user without further > substantial support by the supplier, _OR_ >2. "In the public domain". > >A check with Ottawa resulted in the statement that F-PROT was export >restricted (controlled) as shareware did not meet the criteria of this >general "software" note... Therefore SCAN by McAfee also would not >meet the requirements. At first, it would appear that VIRUSCAN would be export-controlled since it is a shareware program. However, as I'm sure our half-dozen (or so) Canadian agents (not to mention our own accounting department) would point out, the programs are generally available by mail order and telephone call transactions. Now, I am not lawyer, but this would seem to invalidate any export controls on the software. Question: Does "In the public domain" mean a program that is not copyrighted, e.g., "free" as in the context of "public domain" software, or does it just mean a program is widely available to the public, and thus not subject to export controls--even if it is shareware, e.g, publicly-available but copyrighted? Regards, Aryeh Goretsky McAfee Associates Technical Support - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - McAfee Associates, Inc. | Voice (408) 988-3832 | INTERNET: aryeh@mcafee.COM 3350 Scott Blvd, Bldg 14 | FAX (408) 970-9727 | IP# 192.187.128.1 Santa Clara, California | BBS (408) 988-4004 | CompuServe ID: 76702,1714 ------------------------------ Date: 09 Jan 93 23:07:10 +0000 From: ygoland@edison.SEAS.UCLA.EDU (The Jester) Subject: Yes, but is it a virus? First, Dr. Cohen and later Vesselin Bontchev are correct in their assertion that language makes for horrible definitions. Further the use of a math based model is obviously the best solution to the question of 'what is a virus' and so Dr. Cohen certainly took the correct course of action. Now doesn't everyone feel better that I'v given these concepts my personal stamp of approval? =) With the above in mind let us now address the question of:What Is a Virus? To answer the question I think it needs to be restated "What is a virus and to whom are we speaking to it about?". If Dr. Cohen is speaking of viruses to other experts in the field then his comments regarding Beneficial Viruses and such are appropriate and will be understood. I doubt anyone who understands his comments would disagree with his assertions. But theres the rub, how many people really understand his assertions? If I go to the average person and say "VIRUS" they are not going to define it as Dr. Cohen has defined it. It is futile to argue who is 'correct' in their definition, reality is perspective. To the average semi-literate computer user what Dr. Cohen defines as a Virus is either a worm or not a virus at all. As such to term the products a 'Beneficial Virus' is misleading, I would even go so far as to call it false advertising. So, in summary, I have yet to see anyone on this group who understood exactly what Dr. Cohen was refering to disagree with his assertions. What is being argued here is definitions and personally I think its a bit ungentlemanly for Dr. Cohen to make his various statements without cleary explaining that he is using the term virus in a form which the average individual of some computer knowledge would not be familiar with. 'nuff said, Yaron (The Jester) Goland - -- RSA proved you could patent math, whats next? Fire? "Sorry, you can't rub those two stones together! First is a Patented Process" -The Jester ------------------------------ Date: 10 Jan 93 08:38:04 +0000 From: ygoland@edison.SEAS.UCLA.EDU (The Jester) Subject: Math Models of Polymorphic Viruses I was discussing this with Vesselin and I thought that perhaps the people on this group might find the problem interesting: I define a function V() which takes two inputs, the function itself and a random key K. The result is that V(V,K) will produce another function V2. The process is continuous, V2(V2,K2) will produce V3 and so on and so forth. The picture of this process is a tree graph where each node is a mutation of the root with a theoretically unlimited number of children (You can just increase K to some arbitrary size when you wish to increase the number of mutations) each of which is itself a node with children and so on and so forth. Further more the graph does NOT have to be directed. It is possible for a child to produce its parent given the appropriate key. IMPORTANT NOTE ON RESTRICTIONS OF THIS PROBLEM: It may be that allowing the graph to be non-directed might over simplify the problem. If this is the case, then the restrictions that the child can NOT produce some arbitrary level of ancestor can be introduced. (I.e. the child can not produce the father, grand father, and great grand father but may have a cyclic period that would allow the great great grandfather to be produced) While the above should make the problem more difficult, causing the graph to become directed, there will still be many functionally bidirectional links (i.e. a connection from some node A to some node B and some node B to some node A). The problem can be further complicated by holding to the above assumption of infinite mutations and thus precluding any realistic use of the cyclic period as an identifier. For those who are not familiar with the term:Cyclic period is the minimum number of mutations a function must go through before the original function is produced. I.e. V(V,K)->V2(V2,K2)->V3(V3,K3)->...->VN(), where VN() = V(). The question is:Given functions VX() and VY(), can I determine if they are both members of the same tree? Further, if this problem should turn out to be NP-complete, can I use probability analysis to determine within a certain margin of error, if the two functions are from the same tree? The application of this problem is obviously to polymorphic viruses. V() is the polymorphic virus function and K is whatever the virus is using to determine its next mutation. So if I have some known virus VX() and I scan the system, I can compare code against VX() and determine membership. If the above problem is solvable in real time then this means there is a good shot at dealing with heavily polymorphic viruses. Even if the process isn't fast enough to be run regularly (such as at bootup) it will at least provide for an identification and containment mechanism when your integrity checker goes wild. Your friendly neighborhood Jester, Yaron (The Jester) Goland p.s. I am very interested in this problem, if anyone here should also find the problem interesting I will be more than happy to discuss it via e-mail should the virus-L group decide they aren't interested in the problem. - -- Proof Windows is a Virus:It is very widespread, It eats up your disk space, It slows down your computer, It takes control over your computer, It performs disk access at random times, It displays silly messages on your screen, It randomly crashes the computer-Vesselin ------------------------------ Date: 08 Jan 93 23:32:00 +0000 From: bill.lambdin%acc1bbs@ssr.com (Bill Lambdin) Subject: How to measure polymorphi Quoting from Vesselin Bontchev to All About How to measure polymorphi on 01-08-93 VB> Unfortunately, this does not work. First, for some viruses it is VB> almost impossible (well, at least too difficult) to count the total VB> number of appearances. Nobody has succeeded yet to determine the exac VB> number of different decryptors that MtE can generate. How about releasing a polymorphic virus on a test machine with several thousand bait files that are identical. 2-5 thousand bait files should be enough. infect these bait files, then use a program that would generate CRC's of all of the infected files then delete the duplicates. If the MtE generates fewer dupes than the others, call it the most polymorphic Bill - --- * WinQwk 2.0 a#383 * 1704 (Format) activates Sep 1 - dec 31 ------------------------------ Date: Sun, 10 Jan 93 12:54:46 -0500 From: celustka@sun.felk.cvut.cs (Celustkova-k336-doktorand(Richta)) Subject: Infection question (was: Viral Based Distribution System) Hi all, Nice day for fishing in calm water. Here is the fish (just a small one): bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) says: >Another misunderstanding comes from the fact that most people distinguish >between a "virus" (i.e., something that modifies executable files) and a >"worm" (i.e., something that copies itself as a whole). While it is useful >to make such a distinguishment for practical reasons, there is no real >theoretical difference (e.g., what "files" do the boot sector viruses >infect? How about the companion viruses? They do not modify anything...). Cite from your paper "Possible Virus Attacks Against Integrity Programs and How To Prevent Them", EICAR Conference,Munich,December 1992 (stresses are mine): "...Therefore to avoid detection, the viruses [companion viruses] could not to modify the files themselves, they -change- their execution path instead... ...Such viruses [regular companion viruses] are not usually considered particulary dangerous. The reason is that they tend -to spread- only inside a particular computer system... ...A PATH companion virus could -infect all executable files- in all directories - regardless how well they are protected. It is sufficient that at least one writable directory exists -e.g. the user's home directory. The virus could insert the name of the writable directory at the beginning of the PATH variable and create copies of its body in it with names, designed to spoof the executable files in the protected directories...etc..." Cite from Virus-L FAQ : "B8) What is a companion virus? A COMPANION virus is one which, instead of modifying an existing file, creates a new program which (unknown to the user) gets executed by the com- mand-line interpreter instead of the intended program. (On exit, the new program executes the original program so that things will appear normal.) The only way this has been done so far is by creating an infected .COM file with the same name as an existing .EXE file..." Conclusion: Companion viruses don't modify files but information about them and create new files which is executed instead of the intended, i.e. they modify the previous state of the system. In that way they could cause inner infection (inside the system - PC or LAN) and possibly outer infection (between systems). One can ask here: Can the infection by companion virus be called infection when it doesn't change original file? The answer is : Yes, because changing of appropriate data enables its spreading. Also BOOT viruses change BOOT sector and doing this can cause outer infection (i.e.between PC-s). Maybe the right question here is not "What is the virus?" but "What is the infection?" I'm waiting for answer. A note to remember: Don't be in contradiction with yourself. Have a lot of fun ! _____________________ Cheers, | | | That's all folk! | Suzana /|_____________________| /~~~~~~\ / ~\( * * )/~ ( \___/ ) \______/ @/ \@ - --------------------------------------------------------------------------- Address: Suzana Stojakovic-Celustka e-mail addresses: Department of Computers celustka@sun.felk.cvut.cs Faculty of Electrical Engineering celustkova@cs.felk.cvut.cs Karlovo namesti 13 12135 Prague 2 phone : (+42 2) 293485 Czech Republic fax : (+42 2) 290159 ------------------------------ Date: Thu, 07 Jan 93 20:51:22 -0500 From: Declan Malone Subject: Re: How to measure polymorphism In the last VIRUS-L, Vesselin Bontchev wrote: > Subject: How to measure polymorphism? > > Hello, everybody! > > There are already two polymorphic engines available (MtE and TPE) and > we are going to see more and more polymorphic viruses in the future. > An interesting question arises - how to determine how polymorphic a > virus is? How to determine which of two viruses is "more polymorphic"? > In other words - how to measure polymorphism in an objective way? [Much deleted] I smile to think that the whole issue of computer viruses keeps returning to a central theme. That is randomness and undecideablitity. Let me explain. What polymorphism is, essentially, is a term describing randomness, true? Now how do you measure randomness in an objective way? You can't really, and the irony of it is that the more you try, and the more objective/detailed your description becomes, the more you are taking away from the central essence of the word `random' or sending your definition in the wrong direction. It seems to be the same with creating an a-priori scanning program - the more you close in on the definition, the more room virus authors have to exploit it, and the more the reality shifts away from the definition. > This article is not meant to provide a solution of the problem. I am > trying just to explain the problem and am asking for solutions. Any > ideas are welcome - we really need an objective way to measure the > level of polymorphism... You say that there is a real need for an objective way of measuring the level of polymorphism, but why is that so? If a user has a new virus running loose on his system, it is of little interest to him whether it is more or less random than another virus. Even to scanner manufacturers, I think, the point is largely irrellevant - so long as they can produce a scanner to detect the virus, its level of polymorphism is purely academic. Even so, taking it that there can be no a-priori measure of polymorphism, for specific purposes, measures can be defined that, while not measuring randomness, give something that is useful in the context. The progression of measures seemed reasonable, but what about giving each virus a "difficulty" rating to detect using various scanners. A function could be made to order which would combine various attributes of the virus in question. I think that for most purposes, a grading would ask the following questions about the code: 1 Is every byte of every sample constant? (a simple CRC will identify it) 2 Is there a fixed (no wildcards) signature that will identify it? 3 Is there a simple wildcard signature (constant length) to identify it? 4 Is there a complex wildcard signature to identify it? ( signature matches variable length strings) 5 etc This is just my own intuitive way of looking at the problem, at least in terms of scanning. Still, it's really only of use at low levels of polymorphism - after that things would start to get really hairy . . . I'm as bereft of answers as Vesselin, but I must say that this is fascinating stuff. One metric that I think might be interesting would extract the total number of useful signatures from a program (or as a ratio of the total possible signatures for that file) - not only would you get some idea of polymorphism, but you'd also get some idea of how well a signature picked at random for the virus would withstand random modifications to the virus. This could give stats for how likely a signature would be of detecting various new variants with increasing modifications. Because it's signature-based, the effect of moving sections of code around from original to variant is much less over bigger files. Of course, just knowing how likely you are to detect changes ignores the probablity of the changes themselves - which cannot be predicted. > Regards, > Vesselin Regards, Declan Malone - --- I'm filling in the negative space with positively everything. PS I love the signatures, Suzana! They're inspired. ------------------------------ Date: Sun, 10 Jan 93 23:19:49 -0500 From: barnold@watson.ibm.com Subject: Measuring polymorphism A couple of other metrics that you may not have considered: - - Difficulty of analysis. By this metric, the TPE is simpler than the Whale, and the Whale is simpler than the MtE. - - How prone to false positives will detectors for this virus be? If the degarbler (AKA decryptor) semantics are sufficiently variable, a verifier will be difficult to produce. (By verifier I mean a program or piece of code that exactly identifies the virus; we can safely not worry about the many-to-one mappings of virus code regions to checksums, if the checksums are large enough and the checksum algorithms are strong enough.) I've heard comments that TPE detectors may be more prone to false positives than MtE detectors. This remains to be seen. (This metric is probably mainly useful for product marketing.) - - My favorite metric is the one alluded to in your last paragraph; how much new code will have to be written to reliably detect instances of the virus? For example, for many detectors, any virus detectable by a small set of search strings (with multiple length wildcard characters allowed), such as the Maltese Amoeba (AKA Grain of Sand, Irish) requires no new code. The MtE might require 200 lines of code as one ordinarily counts lines of C code, the V2P6 might require 40 lines of code, etc. Some detectors might have a more expressive detection language embedded; in such cases an MtE detector might be possible in fewer lines of code. A similar less-vendor-centered measure might be complexity of the detector. We could conceivably get a couple of vendors to plug their detectors for a few such viruses into a better complexity metric than lines of code, and average the results. These would be an upper bound, assuming the detectors were reliable, but it might still be useful. Bill Arnold barnold@waton.ibm.com ------------------------------ Date: Fri, 08 Jan 93 07:01:05 -0500 From: KARGRA@GBA930.ZAMG.AC.AT Subject: OS2SCAN99 checked (OS/2) Hi all! Note: All programs tested (except OS2VAL) were release 9.0 V 99. OS2VAL is version 0.5. The last tests I made were the betas of V97. - ----------------------------------------------------------------------------- OS2VAL: Seems to run perfectly, but should not complain, that it can't find file "/?" or "/h". A thing I found in all programs: (OS2VAL, OS2SCAN, OS2NSCAN and OS2CLEAN): The copyrightmessage says, that it is protected since 1989. I assume this means, that parts of the software are exactly the same as in the DOS-version. OS2CLEAN: at least I found no problems, when I tried to clean my system from [JERU]. More testing could not be done, as I don't have any virus and I don't want any. Maybe some day I'll go and get me some uncritical samples. OS2SCAN: It seems to run quite well. Finally the Help-pages were updated and the problem with "more help?" is fixed too. Is there a reason, why you still don't scan *.DLL? You added new extentions, of which I never thought, they would contain executable code (*.PIF). So I learned some new things. If neither windows nor OS2 *.DLL contains executable code, then please tell me, as I don't want to remain on error. Obviously some kind of integrity-checking has been added with the /AF and /CF switches, where the info is stored in a separate file. Still there are two options to add integrity-info of various sizes to files. I wonder, how the experts will comment on /AG/CG/RG and AV/CV/RV which add 10 or 52 bytes to each file ... As there is the wonderful AF/CF option, there is no need to add bytes to every executable. BTW: Is /RF really necessary, or will just deleting the file created by /AF do the same ? Currently I'm fighting with /DATE and /SHOWDATE. Somehow I can't get it to do what it should. I even don't find this 0-byte file. All I get now is a message, that OS2SCAN may be outdated. I understand, that this is due to the missing file. The DOCs say, that there should be created a SCANVAL.VAL file in the logged directory. Not even a global search on both drives finds it :( You should save the date in your INI file. How about that ?? :) Somehow I also managed to have problems with the /CF switch. After I success- fully created a file "scanned" with "/AD /AF scanned" I tried to run it with "/AD /CF scanned", but it complained about a corrupted file "scanned".:( If I read the DOCs correct, there should be also a file SCANVAL.VAL in the rootdirectory of (in my case) drive C: and D:. But there is none :( OS2NSCAN: Though I did not expect it would do anything with a not networked PC, OS2NSCAN C: D: did exactly the same thing as OS2SCAN, though the DOCs re- commend using OS2SCAN. Maybe for trade-reasons ... NETSCAN for DOS: It can't run within a DOS-session, as it makes a selfcheck. Therefore it needs to open itself and creates a share-violation, as it is already in use by "another" process which is itself. .... I just had a system-lockup which needed a cold-reset! A thing I should try to avoid. Probably this is due to NETSCAN leaving some never terminating garbagecode somewhere, as I had to shut it down by force. So don't use it in OS2. I recommend using ONLY the OS2-specific versions! Page 1 of OSCAN99.DOC contains a small error. It says: "it creates a SCAN.INI file". In fact "it creates a OS2SCAN.INI" would be correct. It is correct on page 12. Sometimes I DO read manuals ...:) On page 8 the manual says: "Please note the /AF and /AG switches modify executable files." ^^^ On page 4 the manual says: "Files which are self-checking (e.g., Lotus 1-2-3) should not be validated with the /AV (Add Validation) or /AG (Add Generic) switches which modify files. Instead, use the /AF (Add File) switch." Obviously a mistake again ... ^^^ So please, Mr. Goretsky, check your manuals once again, or even better, have them read by somebody else. 4 eyes are better than 2. ;) Finally I have to say, that they seem to behave very well. If the problems I have are bugs or my inability to use this program I can't tell. Could someone else try these programs on his OS2-HPFS-drives? Somehow I feel that programs only usually run on 2 different machines with the same OS. That's all for today. The rest of checking the virusdetection is up to someone else, but as the scanning engine seems to be much the same, there will be probably not much need for it. (??) Today I found the only 100% reliable hardware-virusprotection for my PC: (not even Padgett will complain) A blown 10A fuse in the mains..... :) Alfred ############################################################################### # Alfred Jilka # Geologic Survey, Austria # Shall I raise the white towel or throw the flag ??? KARGRA@GBA930.ZAMG.AC.AT # ############################################################################### # ------------------------------ Date: Fri, 08 Jan 93 18:10:35 +0000 From: ksmall%hydra.unm.edu@lynx.unm.edu (Kim Small) Subject: MtE info. (PC) I'd like to do a paper on the MtE virus engine/virus. Where can I find information on this recent phenom. Kim [Moderator's note: You might start by reading Vesselin Bontchev's MtE Detection Tests, available by anonymous FTP from cert.org (192.88.209.5) in /pub/virus-l/docs/mtetests.zip] ------------------------------ Date: Fri, 08 Jan 93 14:17:13 -0500 From: tajti@viking.ttt.bme.hu Subject: Romanian Vampirus (PC) A new virus was found in Hungary (ROMANIAN VAMPIRUS). The length of the virus is 1499 bytes. If you find the following sequent, it may be the virus: 817600????4581FD????72F4BD????C3 If anybody has this virus, please send an e-mail to tajti@ttt.bme.hu (I have the killer) ------------------------------ Date: Fri, 08 Jan 93 18:46:08 -0500 From: Libbie Counselman Subject: Monkey [Mon] and Multi-2 [M12] viruses (PC) We have been using and supporting F-Prot 2.06a on campus, but have discovered 2 viruses that are not detected and not disinfected by F-Prot. The first one discovered was the Monkey [Mon] virus. It affects the File Allocation Table. SCAN discovers it, but does not disinfect, but Norton Disk Doctor will recover the clean FAT. The second is known as Multi-2 [M12]. It has a predecessor called Multi [M-123], also not recognized by F-Prot. This one infects .COM files, .EXE files, overlays and becomes memory resident. CLEAN apparently disinfects it. Does anyone know any non-commercial packages (i.e. shareware or freeware) that can combat these viruses? - -Libbie Counselman libbie@pucc.princeton.edu ------------------------------ Date: Sat, 09 Jan 93 20:18:00 -0600 From: VXC15931@VAX1.Mankato.MSUS.EDU Subject: Possible new PC viruses ? (PC) I just came across possibly two new viruses which F-Prot 2.06a cannot remove. They are WONDER and URUGUAY. The damage is not critical since F-Prot simply renames the files. I replaced them from an uninfected(I hope) archive disk. Can Frisk advise me on this? I checked the archive itself with F-Prot 206a and got an all-clear. I also managed to copy the infected files to a blank disk for later inspection. Thanks. ===================== Jose' R.C. Cruz Graduate Assistant Department of Physics, Engineering and Technology Mankato State University Mankato, MN ==================== "Quantum Mechanics is the closest thing Science will ever get to becoming a religion. And I happened to be an atheist." -- me ------------------------------ Date: 08 Jan 93 20:44:00 +0000 From: bill.lambdin%acc1bbs@ssr.com (Bill Lambdin) Subject: Re: Vshield vs Virstop (PC) Quoting from Mcafee Associates to All About Re: Vshield vs Virstop (P on 01-08-93 MA> VSHIELD (or SCAN) will detect the change in a CRC made by a stealth MA> virus provided the stealth virus is not resident in memory to MA> interfere with checking. Right. I can go along with that. But if the Stealth virus were active in memory, the CRC would not detect the change because the virus would remove the infection temporarily while the CRC comparions was going on. Bill - --- * WinQwk 2.0 a#383 * Viruses replicate and spread, Trojans do not. ------------------------------ Date: Sun, 10 Jan 93 11:46:49 -0500 From: Jimmy Kuo Subject: Re: False positive in the new PKZIP (PC) It was reported in VIRUS-L #5 that the new PKZIP was being false-id'ed by an old NAV as having the Malta or Maltese Amoeba virus. If you are a user of NAV 2.0 and have not updated your definitions, you may either enter in the following under "Definitions" "Add": Name: Maltese Amoeba Size: 346 CRC: 631E Definition: 0R0G0L0J0GFH0H0HBM0GDYAQ9Z0K0G0MAQ6GAZ0G0NCUAX3Y0G0M5U0MAQFR0K0G0MEW0G0M 6Y8Q3Y4W4M5U2JEW0G0M0JCN0G2N0J9L0G2H0G2KCR2Q0N0Q3U6MDY7M7N7WEZ1H9M9U1W1X 1Y1Z0G2NBGEZ0G0M0G2NAR6M0G2NAG7N0G2NAG3U0G0M0G2N0R7M0G2N0R1H0MBLCM0J8SCL CQCK0G0HCMFK5SCGCSCNFK0J5Y5ZCHCSCMFKCMCJBS0M0GCV1G0H0G0G0LAY0G0G0JCN0G2N 0J9L0G2H0G2KCR2Q0N0Q3U6MDY7M7N7WEZ1H9M9U1W1X1Y1Z0G2NBG7Z0G0M0G2NAR6L0G2N AG7N0G2N0W3U0G0M0G2N0R7M0G2N0L1H0JCJ0G0K0G2KCR2Q0N0Q3U6MDY7M7N7WEZ1H9M9U 1W1X1Y1Z0G2NBGEZ0G0M0G2NAR6M0G2NAG7N0G2NAG3U0G0M0G2N0R7M0G2N0R1H0MBWCUCM FK5SCGCSCNFK0J5Y5ZCHCSCMFKCMCJBS0M0GCW1L0H1N0HCQ0GCM0G0G0GBHAN0GBXAG0GBH 0Y0GBXAG0G0W0JCJ0G0K0G2KCR2Q0N0Q3U6MDY7M7N7WEZ1H9M9U1W1X1Y1Z0G2NBG7Z0G0M 0G2NAR6L0G2NAG7N0G2N0W3U0G0M0G2N0R7M0G2N0L1H But who wants to type all that in? So, you can also send me email and I will send you a uuencoded ZIP file containing the last definitions update for NAV 2.0. NAV 2.1 users do not have this problem. And if you are still a NAV 2.0 user, we recommend you upgrade to NAV 2.1. Jimmy Kuo cjkuo@ccmail.norton.com Norton AntiVirus Research ------------------------------ Date: Thu, 07 Jan 93 20:17:10 -0500 From: Anthony Naggs Subject: Re: Known virus that tweaks PC date function? (PC) student, asks: > In the office where I work, we recently purchased a 286 clone.. Over > the past few weeks, the computer's internal clock has been losing > days. [...] > > Has anyone heard of a virus that would produce these symptoms? If > not, does anyone have any other ideas about how to fix the problem? I don't remember any viruses like that, the only time I've seen anything similar was on a 'true blue' IBM AT which needed a new battery for the clock. If you bought this new then contact your supplier saying you have a clock problem, if it's previously been used then just replace the battery. Hope this helps, Anthony Naggs Software/Electronics Engineer P O Box 1080, Peacehaven (and virus researcher) East Sussex BN10 8PZ Phone: +44 273 589701 Great Britain Email: (c/o Univ of Brighton) amn@vms.brighton.ac.uk or xa329@city.ac.uk ------------------------------ Date: Fri, 08 Jan 93 06:58:38 +0000 From: Scott.Bailey@lambada.oit.unc.edu (Scott Bailey) Subject: Problems with Filler and Isrealie boot virus in Windows (PC) Greetings, I recently ran into an interesting problem with my sister's Gateway 2000 386/33. When I tried to use the computer I found that the FAT had been moderatly damaged to the point where chkdsk reported that the hard drive was a probable non-boot disk and sever cross-linked files existed. Naturally my first thought was to power down and run some virus checking programs. At the time I had tried scanv93 and it reported that there were no viruses present on the drive. I repaired the drive with PCtools and then ran scan again and found no viruses, however this time I also tried scan for windows and it reported that the Isrealie [Iboot] boot virus was active in memory. Again, I powered down to clear memory and ran clean93 and it said the virus had been removed and I powered down as recommended. When I ran scan for windows this time it told me that the Filler virus was active. After I removed it, I when and retrieved the latest versions of clean, scan, and scan for windows from Wuarchive. This is what I find happening now: After booting scan99 reports no viruses in active memory nor any infected files, scan for windows agreed, but I find now that Filler or Iboot will launch itslef into memory after any windows application is used. It seams as if there is a link virus attached to windows which is causing the viruses to become active but I cannot find any discrepency in the file sizes. I've since told my sister to reinstall windows to see if that will correct the problem. I was wondering if anyone else has had a similar experience in this area, if so could you please mail me with your solution to it and then I will post a summary of the solutions here. Please send replies to bailey@vader.eng.uri.edu Thanks /-----------------------------------------------------------------------------\ | Scott A. Bailey | #include "std_disclaimer.h" | | ECL Operator |------------------------------------------------| | Computer Engineering | I'm just a knight who chases the moon... | | University of Rhode Island | Haven't caught it yet,but I haven't let that | | bailey@vader.eng.uri.edu | keep me from still trying each day and night | | bailey@ecl1.uri.edu | --(---------- ----------)-- | \-----------------------------------------------------------------------------/ - -- The opinions expressed are not necessarily those of the University of North Carolina at Chapel Hill, the Campus Office for Information Technology, or the Experimental Bulletin Board Service. internet: laUNChpad.unc.edu or 152.2.22.80 ------------------------------ Date: Fri, 08 Jan 93 08:25:57 +0000 From: estephen@netcom.com (E. Stephen Mack) Subject: Re: False positive in the new PKZIP (PC) Vesselin Bontchev writes: | [...] What is interesting is that somebody used an out-of-date version of | Symantec's Norton Anti-Virus to scan the new archiver. It seems that | this version causes a false positive - the program is flagged as | infected by Maltese Amoeba. [...] | [...] Even a recent version of NAV (2.1 with signature updates of | December) does not report the false positive any more. PKWare has | confirmed that this is a "real" version. [...] I can verify part of Vesselin's report: The NAV TSR will flag the PKZ204C.EXE which I ftp'd from ftp.csie.nctu.edu.tw. Yeng-Chee Su placed it there after downloading it from the PKWARE BBS (414-354-8670). Can you tell me how to get the new version of NAV? Mine came with Norton Desktop for Windows 2.0 (I'm sure many other Windows users have this version as well) and is dated 03-22-92. Does Symantec require a payment to receive updates? Is there a location to anonmyously ftp the update, or must we call the Symantec BBS? My one experience with the Symantec BBS was not very positive. I'm sure many users would be interested in this information. I will summarize any answers. [estephen] E. Stephen Mack estephen@netcom.com ------------------------------ Date: Sun, 10 Jan 93 23:50:11 -0500 From: "Roger Riordan" Subject: Invalid Boot Sectors (PC) frisk@complex.is (Fridrik Skulason) writes > riordan@tmxmelb.mhs.oz.au (Roger Riordan) writes: >>It appears the original message got lost, but the gist was that, >>IN THEORY, it is possible to write a BS virus which is invisible >>on an infected PC, but impossible to detect on an uninfected PC >>with any existing scanner because DOS will crash if any attempt is >>made to access an infected disk. > well, only if the scanner uses int 21H/25H/26H to access the disk. > If it uses int 13H to access the disk the disk can be read no > matter what data is in the boot sector. Fully agreed. Only ALL the well known scanners I have tested crash if byte at offset 0Dh (sectors/cluster) in floppy boot sector is set to zero. This is not just a theoretical argument; Quox overwrites the disk parameters, with the result that neither F-Prot nor Scan can detect it on 3.5" HD disks. Further to the above padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) writes >I am glad that the above said "IN THEORY" since an undetectable, >invisible virus that can make a system completely unbootable except >from the hard disk just cannot exist. ... In stating such a virus was possible I assumed DOS treated invalid DOS boot sectors on floppies & hard disks in the same way, so assumed it would crash if sects/cluster were set to zero in HD DOS boot sector. For obvious reasons I didn't verify it. Of course I should have known DOS would not behave so rationally. Decided I'd better check before I said any more, so on XT, running MSDOS 3.3, set sects/clust to zero in DOS BS. PC wouldn't boot from HD, but booted normally from floppy, & could then access HD normally. Set sects/track, then heads, then MDB & sects/FAT successively to zero with same result. The XT has no CMOS, & the Partition Table does not contain this info in an obvious form, so don't know where DOS finds it. So Padgett is right in saying that such a virus would be readily detectable on hard disk after booting from clean floppy. However, if a stealth BS virus set sects/clust to zero on floppies, existing scanners would crash when they tried to check infected disks on clean PCs, so this part of what I wrote is true. Reason I said IN THEORY is that you would not have many friends if your disks crashed everyone elses PCs, so the chances of such a virus remaining undiscovered are not high. Of course a few recipients would reset with disk still in drive A, so it would propagate occasionally. Padgett also writes >In other words, every infection I have seen is recoverable with the >right tools (usually DEBUG, FDISK, & SYS). ... I doubt if one user in 100 can use DEBUG at all, and it will not load some infected boot sectors (eg Quox on 3.5"HD). I can think of no circumstances in which I would use it to remove a virus, though it is handy for infecting test disks. SYS will only fix DOS BS infectors and is extremely cranky on early versions of DOS, and FDISK will only work on DOS 5, will not fix all viruses, and will destroy nonstandard MBRs which appear on some PCs. (See recent note from tck@bend.ucsd.edu (Kevin Marcus) re FDISK/MBR & Linux). Each of these tools takes time & expert knowledge to use, and each has traps which can cause serious problems in some circumstances. Padgett may enjoy doing things from first principles, but the average user will do far better to buy a good specialist A/V program. This will stop almost all viruses getting in, and if the user is careless, it will remove 99.9% of all infections in a few seconds with far less risk of losing all their data. Roger Riordan Author of the VET Anti-Viral Software. riordan@tmxmelb.mhs.oz.au CYBEC Pty Ltd. Tel: +613 521 0655 PO Box 205, Hampton Vic 3188 AUSTRALIA Fax: +613 521 0727 ------------------------------ Date: Fri, 08 Jan 93 11:22:00 +0000 From: Malte_Eppert@f535.n240.z2.fidonet.bad.se (Malte Eppert) Subject: How do MtE utilizing viruses detect themselves? (PC) Hello ALL! Can anybody tell me how MtE utilizing viruses detect themselves in an infected file? Or do they reinfect the file each time they attack it, like old Jerusalem? Can't an algorithmic scanner use the method used by MtE itself to detect it? cu! eppi - --- Via SCANTOSS V 1.37 * Origin: Another Virus Help Node - The EpiCentre! (2:240/535) ------------------------------ Date: Thu, 07 Jan 93 16:51:07 -0800 From: rslade@sfu.ca Subject: Internet Worm Functions - part 2 (CVP) HISVIRQ.CVP 921215 The Internet Worm - Functions (continued from last week) "sendmail" is the "engine" of most mail oriented processes on UNIX systems on the Internet. In most cases it only allows data received from another system to be passed to a user address. However, there is a "debug" mode, which allows commands to be passed to the system. Some versions of UNIX shipped with the debug mode enabled, some with it off. The greatest weakness, however, seems to have been that regardless of the default, debug mode was often enabled during installation of sendmail for testing, and then never turned off. However the Worm managed to get into a system, it then was supplied with the main program from the "previous" site. Two programs were used, one for each CPU that could be infected. If neither of the two would work, the Worm would erase itself and stop. If the new host was suitable, the Worm looked for further hosts and connections to try out. The program also tried to break into user accounts on the infected machine. Given the information in the account and password file, it first tried simple variations on the name of the account and the user. It also carried a dictionary of passwords that it would try, and would also look for a dictionary on the new machine and attempt to use words from that as well. If an account was "cracked", the Worm would look for accounts that this user had on other computers. Since the accounts and requests thus found were valid, it was easier to start new processes, and thus the new infection had a greater chance of success. The Worm did have a means of checking to see whether there were multiple copies running on a given computer. However, the mechanism delayed the termination of a program for a significant time. Also, the Worm regularly produced copies which would not respond to the request for termination. The copies of the Worm would, regularly, destroy themselves -- having first made a new copy. In this way the identifying process id number would continually change. Note that there is nothing in the Worm that is specifically or intentionally destructive. However, as with the CHRISTMA EXEC, the mere existence of the entity had implications for the infected systems, and those associated with them. The multiple copies of the program that ran on the host machines meant that processing was significantly affected. In addition, communications links and processes were being used for propagating the Worm rather than the work they were intended to support. copyright Robert M. Slade, 1992 HISVIRQ.CVP 921215 ============== Vancouver ROBERTS@decus.ca | "If you do buy a Institute for Robert_Slade@sfu.ca | computer, don't Research into rslade@cue.bc.ca | turn it on." User p1@CyberStore.ca | Richards' 2nd Law Security Canada V7K 2G6 | of Data Security ------------------------------ End of VIRUS-L Digest [Volume 6 Issue 7] ****************************************