From: SDS::"virus-l@Lehigh.EDU" 11-SEP-1992 16:17:24.24 To: 3338$SPAN::HENDEE CC: Subj: VIRUS-L Digest V5 #151 Received: from CS2.CC.Lehigh.EDU by Sdsc.Edu (sds.sdsc.edu STMG) via INTERNET; Fri, 11 Sep 92 20:14:06 GMT Received: from (localhost) by CS2.CC.Lehigh.EDU with SMTP id AA30040 (5.65c/IDA-1.4.4 for ); Fri, 11 Sep 1992 15:45:31 -0400 Date: Fri, 11 Sep 1992 15:45:31 -0400 Message-Id: <9209111901.AA28207@barnabas.cert.org> Comment: Virus Discussion List Originator: virus-l@lehigh.edu Errors-To: krvw@cert.org Reply-To: Sender: virus-l@lehigh.edu Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas From: Kenneth R. van Wyk To: Multiple recipients of list Subject: VIRUS-L Digest V5 #151 VIRUS-L Digest Friday, 11 Sep 1992 Volume 5 : Issue 151 Today's Topics: Re: Tan An Door virus?!?! (PC) Re: NetWare and viruses - some new results (PC) Re: Tan an Door virus?!?! (PC) Netware Rights again (PC) F-PROT 2.05 - minor problem detected. (PC) Re: F-prot false alarm? (PC) Re: New files on eugene and beach (PC) Problem with Vshield 5.1B95 (PC) Netware (PC) NAVSCAN (PC) Re: NetWare and viruses - some new results (PC) Re: VACSINA Information Wanted (PC) Re: F-Prot & SuperStor (PC) Re: F-PROT reports Bugsres 3 Jokes program? (PC) Now I know I have something. (PC) Re: A new virus????? HELP! (PC) Re: Auto-detecting Virus (PC) Re: Looking for references (UNIX) Virus scan for AIX 3.2? (UNIX) Re: self-checking programs Self-modifying programs Re: Comp Virus Conferences ... THE BEST CONFERENCE THIS YEAR! 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: Wed, 09 Sep 92 22:32:33 -0400 From: Anthony Naggs Subject: Re: Tan An Door virus?!?! (PC) Paul Bradshaw, , asked for information about a virus described in his local virus conference: > Title: Tan An Door Virus > > Recently in China I cought the > 64 VIRUS > which apparently was related to the incident of June 4 atthe Square of > Tan An Door in Peijiang (Bejing ?). 64 => June 4 This is presumably the massacre of students in Tiannamen Square (sorry not sure about the spelling), in Bejing/Peking. There is a boot virus, loosely based on Stoned, which includes the message "Bloody! Jun.4, 1989". The usual names I have seen are "Bloody" and "June 4". > I found there a "Kill" progr, and apparentlyI have cleaned my stuff off. > However bere transferring material form my travelling kit to my computer > in Guelph I would like to know if any of you know anything about this > virus and if it could be lingering still somewhere: > a. I was using a palmtop (Sharp 3100) with built in software: could the > virus have entered such software ? > .. As a boot sector virus it is unlikely to have been transferred to a palmtop, unless user has disk image files (eg using Teledisk). I would expect all a-v software to detect "Bloody"/"June 4", as F-PROT is one of the more comprehensive scanners you could use it for reassurance. 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: Wed, 09 Sep 92 23:55:39 -0400 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: Re: NetWare and viruses - some new results (PC) >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) > >By "exhaustive test" he means exhaustive test. He has generated 256 >directories will all possible combinations of access rights and has >tried to infect the files in them. In fact, I have found that only a very small number of the 256 possible combinations prevent possible infection (believe it is 24 but CREATE is confusing the issue. If you have CREATE you can infect a directory unless you also have READ in which case you must also have WRITE unless you are a MacIntosh...). Please note that I include those cases that a virus *could* be written to exploit (such as MODIFY and where a file is known to be in a directory that cannot be searched). >> 4. A virus which has Read, Write and File Scan rights, can infect >> target files. Therfore careful consideration should be given to use >> of the Write right. Unfortunately, many users (and some applications) become very unhappy if they do not have WRITE right in their own directories. This was the problem I had with one LAN last year, the custom MAIL facility demanded WRITE right to itself. JERUSALEM spread like mad. >And, if the user is given the right to modify the rights, the virus >could do so as well and to set the Write right, even if it is not >initially set. A more exact configuration that prevents virus >infection can be found in Dr. Cohen's paper. Specifically, you must have NOT SUPERVISOR AND NOT WRITE AND NOT MODIFY AND (NOT CREATE OR READ). (Boolean math in ASCII is difficult). >Correct. What Dr. Cohen has actually observed is that the "default" >configurations and even those configurations that are usually >considered "secure" do not actually prevent a virus attack. It -IS- >possible to set the right in a way that will stop viruses, it is just >not easy to figure out how exactly. Not really difficult once the rules of RIGHTS and INHERITANCE are understood, see above. >I encourage you to read Dr. Cohen's paper. Unfortunately, he refused >to make it available in electronical form, so you should refer to the >proceedings of the 2nd Virus Bulletin Conference. Unfortunately typical. I actually held his book in my hand for nearly 15 seconds before it was snatched away. >His basic theory is that it is very difficult to figure out how to >manage the NetWare rights in a way that will stop virus attacks. Not difficult at all, just what is required is unlikely to be palatable to users. One of the difficulties is that unlike UNIX or a Mainframe where a process may take on rights denied to the user as a function of the owner (see ROOT), under PC Netware, a user must have all rights required by a process. Hence to pass mail, EVERYONE *must* have CREATE right to all MAIL subdirectories (see boolean above). >P.S. I don't have the paper handy right now. We (the VTC-Hamburg) are >planning to repeat the tests, in order to verify the results. >Unfortunately, we can repeat only the Novell Netware tests (since we >don't have a Unix-based DOS server) and only for version 2.15. :-( Our testing has been done so far on version 3.11 (386 server) - there is a Sun server but the owner is not stupid enough to let me play with it - yet. I hope in the near future to convert my den closet to Novell so that some nastier testing can be done. Incidently, we have also been testing both Intel's LANPROTECT and McAfee's NETSHIELD and I would consider both to be a good version 1.0 but IMHO some cleaning up needs to be done (example: client FROG is infected with SUNDAY. On logging into server SUNDAY tries to infect LOGIN.EXE but lacks WRITE right {I love that}. No alarm is raised at the failed attempt (default). On reaching his home directory SUNDAY infects MAPMEM on request. Both products then notify FROG that MAPMEM is infected and deny access. Neither warns FROG that *he* may be the source. FROG then calls SUPERVISOR over to report that there is an infected file on the server and...) Again IMHO, what is really required is a layered defense (where have we heard that before ?) 1) Integrity TSR active on CLIENT to ensure cleanliness 2) Check of CLIENT on login to verify cleanliness 3) Monitor for attempted illegal activity by CLIENT 4) Scanner for legal file transfers and on exceptions reported by 1-3. NETSHIELD and LANPROTECT accomplish item 4 only. Of course it could be said that other products exist for the other three items e.g. McAfee's VSHIELD for item 1 and Intel's LPSCAN for item 2 but I like one-stop approachs. Of course IMHO both products are good enough that they are worth a little prodding to make them great. Warmly, Padgett BTW thanks to all of those who responded, I have enough LAN adapter cards now. ------------------------------ Date: Thu, 10 Sep 92 04:26:25 -0400 From: A.APPLEYARD@fs1.mt.umist.ac.uk Subject: Re: Tan an Door virus?!?! (PC) The square in Beijing (formerly known as Peking) in China where the massacre occured, is correctly called 'Tien An Men Square', because it is by the 'Tien An Men' = "Heaven(ly) Peace Gate". (Do not confuse it with the Indian cookery word 'tandoori'.) Your informant seems to have part-translated the name. Is this virus the virus usually known as 'Beijing' or 'Bloody'?, which contains matter referring to that event. > Date: Tue, 08 Sep 92 11:08:48 -0400 > From: Paul Bradshaw > Subject: Tan An Door virus?!?! (PC) > The following recently appeared on our local virus conference here at the > University of Guelph. I've never heard of the tan an door virus, or the 64 > virus as the gentleman refers to it and would like to hear from any of you > who have. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Title: Tan An Door Virus > Recently in China I cought the 64 VIRUS which apparently was related to the > incident of June 4 atthe Square of Tan An Door in Peijiang (Bejing ?). I > found there a "Kill" progr, and apparentlyI have cleaned my stuff off. > However bere transferring material form my travelling kit to my computer in > Guelph I would like to know if any of you know anything about this virus > and if it could be lingering still somewhere: a. I was using a palmtop > (Sharp 3100) with built in software: could the virus have entered such > software ? .. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > I would like to help the poor guy out, but I haven't the faintest idea what > this virus's commonly accepted name would be. Thanks all, Paul Bradshaw > acdpaul@vm.uoguelph.ca ------------------------------ Date: Thu, 10 Sep 92 05:14:18 -0400 From: G J Scobie Subject: Netware Rights again (PC) I have been reading with interest the discussions concerning Netware Rights and thought I would throw my own observations into the ring :-) Certainly on page 227 on the Concepts manual for netware 3.11 it states: "Attribute security overrides rights granted with trustee assignments and can prevent tasks that effective rights would allow". So what does this mean in reality? Let us suppose I have all rights in a directory and to the files contained there. If I flag a file as read-only, netware 3.11 automatically adds the delete-inhibit and the rename-inhibit attribute to this file. Now although I have the erase permission any attempt to delete this file will give me an access denied message. Now futher down page 227 of the concepts manual it states that: "If users have the Modify right for the directory or the file, they can change the attributes and complete any task allowed with their effective rights." Fair enough. I have the modify right, so what happens if I just remove the delete-inhibit attribute? Although the file is still flagged as read-only, I have erase permission so I can delete it. This is explained again on pages 230-231. This situation holds for supervisors as well. By default the system files are installed with the delete-inhibit attribute set, in order to prevent supervisors from accidentally deleting files. So where does this leave us? Certainly attribute security in this instance, overrides rights granted with trustee assignments, and is explained quite clearly in the manuals. Perhaps confusion has arisen regarding the read-only attribute in netware and that under DOS. As for viruses, I feel that we should all assume that if a user has certain rights then a virus will have those rights as well. Infection of files on a server is an issue notably in users home directories, and anyother area that they have more than read/filescan permission. Supervisors - if they are at all worried - should cold-boot from a known clean source before commencing work with supervisor status. It worries me that perhaps too much has been made of the "default configuration" of netware servers. I can't think of any system which comes pre-set for maximum security. It is not a specifically novell problem. To conclude, I work on the basis that the security as far as viruses are concerned are only as good as the rights users have to their areas of the servers disks. If a virus can infect my applications volume where everyone has only read and filescan permission set as a trustee assignment then I would appreciate being told about it as soon as possible. Thanks for all the great work on this board. Its appreciated more than I can say. Cheers Garry Scobie Senior Computing Officer EUCS Edinburgh University ------------------------------ Date: Thu, 10 Sep 92 06:50:58 -0400 From: J|rgen Olsen Subject: F-PROT 2.05 - minor problem detected. (PC) Having brought home my personal copy of version 2.05 (collected from Fredric i Edinburgh, I used the SAVE feature after doing a scan with the heuristics option (lots of 'semi-false' positives but correctly identified as being so). The result : Funny things happened - system hang (5) - funny Characters on screen (1) - garbled report (misc.characters replaced with others) (2). The above numbers refers to 8 test on 3 machines. I seems that saving of larger files results in a) no save - with or without hang. b) no save - with an entry of length ZERO (0). By the was if yopu only write a program name when prompted the file (if it is a small one) will be placed in the root of the last logical disk on your system. In these days with a lot of cheap RAM around this will often be a RAMDISK on many (non-networked) machines. Maybe an other saving strategy should be considered! The whole thing is a minor nuissance - when you know of it! But distributing version 2.05 to 1600 users might give us a feedback we should like to be without. As no one has reported the problem - few people seems to use the SAVE feature! J Olsen DOU, Odense DK ------------------------------ Date: 10 Sep 92 10:47:37 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: F-prot false alarm? (PC) andy@exp.uvs.edu.sr writes: > Just obtained F-prot 2.05 from simtel. Unpacked it and did a secure > scan. To my surprise backup.exe (from dos 5.0) was reported as being > infected with the Stanco virus. The file was packed with pklite. I Hmm, it's a nasty false positive... For the reasons, see below. I suggest that you send a private message to Frisk about that, since he's now on holidays and may miss your article... I didn't know that BACKUP.EXE from DOS 5.0 is PKLite'd... (I am using DR-DOS 6.0.) DR-DOS -does- have most of its utilities in a PKLite'd form, but I thought that Microsoft/IBM don't do that... > Looked the virus up in the info table of f-prot and it says the virus > replicates only in compressed form??! Also Virstop didn't stop > backup.exe from running. I think this is a false alarm (or I hope it > is). > Does anyone has more information regarding the Stanco virus? It is a virus written in Turbo Pascal and compressed with PKLite. Was first detected in Genoa, Italy. The size is about 7500 bytes. It is** PGP publi c key available on request. ** Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: 10 Sep 92 08:55:06 -0500 From: JFORD@seebeck.ua.edu Subject: Re: New files on eugene and beach (PC) >From: John Perry > >Hello Everyone! > >Better late than never I always say! I've finally had a chance to sit >down and update the anti-viral archives on eugene and beach. Please >make note of the following additions. If there is a problem or >question, please feel free to contact me at perry@eugene.utmb.edu. > >eugene.utmb.edu >vsig9207.zip vsig9208.zip is on risc.ua.edu and oak.oakland.edu. - ---------- James Ford - Consultant II, Seebeck Computer Center jford@seebeck.ua.edu, jford@risc.ua.edu The University of Alabama (in Tuscaloosa, Alabama) ------------------------------ Date: Thu, 10 Sep 92 11:16:31 -0400 From: "Chip Seymour, Information Resources" Subject: Problem with Vshield 5.1B95 (PC) I believe I am having a problem with VSHIELD. It loads ok, but when I do a MEM/C, it produces "blem wit" as the program name. Anybody else come across this? (v5.1B95) ============================================================================= Conventional Memory : Name Size in Decimal Size in Hex - ------------- --------------------- ------------- MSDOS 19472 ( 19.0K) 4C10 SETVER 544 ( 0.5K) 220 ANSI 4192 ( 4.1K) 1060 HIMEM 1184 ( 1.2K) 4A0 SMARTDRV 18592 ( 18.2K) 48A0 RAMDRIVE 1184 ( 1.2K) 4A0 ATDOSXL 9520 ( 9.3K) 2530 MOUSE 14816 ( 14.5K) 39E0 ETHDEV 30400 ( 29.7K) 76C0 TCPIP 16480 ( 16.1K) 4060 COMMAND 4416 ( 4.3K) 1140 3C503 3936 ( 3.8K) F60 DOSKEY 4128 ( 4.0K) 1020 IPX 16960 ( 16.6K) 4240 NET5 42112 ( 41.1K) A480 blem wit 38832 ( 37.9K) 97B0 <--------- FREE 64 ( 0.1K) 40 FREE 144 ( 0.1K) 90 FREE 426944 (416.9K) 683C0 Total FREE : 427152 (417.1K) Total bytes available to programs : 427152 (417.1K) Largest executable program size : 426688 (416.7K) 5242880 bytes total contiguous extended memory 0 bytes available contiguous extended memory 2293760 bytes available XMS memory MS-DOS resident in High Memory Area ============================================================================= Chip Seymour ComputerVision chip.s@bdso.Prime.COM Bedford, MA ============================================================================= ------------------------------ Date: Thu, 10 Sep 92 12:47:41 -0400 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: Netware (PC) In my last posting, I accidently referred to the MODIFY right when the reference should have been to the ACCESS right in the boolean equation. MODIFY is only of importance if certain non-default attributes (e.g.are set. ReadOnly are set. Padgett ------------------------------ Date: 10 Sep 92 17:45:57 +0000 From: al163193@academ01.mty.itesm.mx (Jesus Miguel Garcia Rodriguez) Subject: NAVSCAN (PC) Where can i get NAVSCAN? or When its gonna be out? Thanx. /\/\otley. ------------------------------ Date: Thu, 10 Sep 92 20:01:45 -0400 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: Re: NetWare and viruses - some new results (PC) >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Note: my comments refer to Netware 3.11 which Fred is using also but is different from what Vessilin has at the VTC in Hamburg. >kev@inel.gov (Kevin Hemsley) writes: >> can access and what the user is allowed to do with them. Rights >> Security supersedes attribute security, in that a user must first be >> given access to a directory, subdirectory or file before attributes >> can be defined for each. Vesselin repondeth: >Correct. It is indeed so. Unfortunately, the manual says exactly the >opposite. I agree with the conclusion that the structure can be confusing *however* IMHO the manual (Concepts page 8) is correct. Attributes do supersede Rights (more correctly *complement*). If the ReadOnly bit is set an attribute must be changed before a file can be altered, deleted, or renamed irreguardless of what rights a user has (including Supervisor). If you are considering action based on what must be granted to gain access, then the rights must *precede* any test of the attributes but do not *supersede* the attributes. Rights (Supervisor, Modify) can be used to change attributes but not to bypass them. One of the things I feel to have been fortunate in my education was exposure to such things as Set Theory, Boolean Algebra, and Linear Programming at a tender age, courses that I fear are rarely taught to CS majors nowadays. The concepts of rights and attributes are best expressed as Boolean relationships as is attempted to be rendered into ASCII below: Possibly the best way to look at the difference is that RIGHTS state what the user is permitted to do to a file or a directory. ATTRIBUTES state what is *not* permitted to be done to a file or directory: RIGHTS allow, ATTRIBUTES disallow. RIGHTS refer to the user, ATTRIBUTES refer to the object (oops 8*). In Boolean terms you must be allowed and *not* disallowed. Thus for a particular file (say MAPMEM.COM), the user rights NOT SUPERVISOR AND NOT ACCESS AND NOT MODIFY ANDed with the file attribute READONLY *should* protect MAPMEM.COM from direct infection (says nothing about companion or path viruses, just that this particular copy of MAPMEM.COM is protected). In contrast, while contextually NOT SUPERVISOR AND NOT ACCESS AND NOT WRITE has the same protection for MAPMEM.COM, the protection is extended to all files in the directory. In short attributes protect a file or directory from everybody while a lack of rights protects the file or directory from the user. Generally though, rights have more power than attribute since either the SUPERVISOR or MODIFY right can be used to change any attribute *except* one: once the EXECUTEONLY attribute is set, it cannot be changed, the file can only be deleted and restored from a fresh copy. This is obviously an attempt by Novell to protect an executable even from an infected client with SUPERVISOR right. However, despite such powerful macros as FLAG RO *.* /S, attributes are falling out of use for two reasons: 1) Unlike RIGHTS which are enforced at the server level, attributes are enforced by the client shell (hence the PC - MacIntosh difference) and may be overridden by directed client software (some viruses do already - I have some testing planned). 2) As noted by Dr. Cohen, the logic can be puzzling particularly if all that one has to go on is the CONCEPTS volume and conventional (even UNIX 8*) data protection experience. Ignorance is curable. Given all of the above, once the proper logical understanding is made of rights and attributes, I see no difficulty in understanding their implications, not do I find any problem with the documentation other than it is more of an encyclopedia than a tutorial. In other words, if you already know the answer, it is useful. If not, hire a CNE. (or CNA now). More importantly to the non-technical manager who has been receiving these contradictory reports via Virus-L (have had a few calls already), a *properly* set-up Novell LAN not IMHO a flawed system that is an open invitation to viruses. In fact it is less likely to experience an uncontrolled virus infection than a stand-alone PC even though the Netware security is not directed at protection from malicious software. Again IMHO LANs that are at risk (that is *all* that are not single-user like mine 8*) need a properly layered mix of Novell, third party NLMs, exception reporting, and TSRs to achieve a high degree of confidence but it *can* be done. Further, being in a nasty mood, I'll reiterate that IMNSHO *only* client- server systems supporing login scripting such as Netware can be properly protected from infected clients. Peer-peer systems that do not are virus havens. Warmly, Padgett ps don't forget that the above comments refer to the current product, Netware 3.11 & may not apply to older/other versions ------------------------------ Date: Thu, 10 Sep 92 21:01:23 -0400 From: Anthony Naggs Subject: Re: VACSINA Information Wanted (PC) Remembering that a well known story teller, :-), gave me this advice: > Rule 0. Read before arguing. :-) I believe I have read, so here goes... Vesselin Bontchev, , wrote: > AMN@vms.brighton.ac.uk (Anthony Naggs) writes: > > > > Is it important that one utility recognised CHKDSK while the other did > not? > > > Yes, 'EXE' files modified in this way may be corrupted and either fail to *** Reading test; do you see the word 'may' in my previous answer? In the particular incident discussed there is no problem, as CHKDSK functions normally in this state. However I was answering the question of whether scanners should detect such files. > > work or work incorrectly. This includes a number of programs that > > use overlays or include configuration information in the executable file. > > True in general, but this particular virus (Vacsina.05) does not > infect files with internal overlays or trailing configuration info. > So, in this particular case there is no danger. No. No. No. Even with the care that Vacsina takes there can still be problems. For instance programs, as discussed here recently, that check themselves will notice such a change and refuse to run. If the detection utility misses this file in the list of those affected, then the user will suspect that s/he is also suffering from a new virus. This is likely to cause some anxiety! I hope this is clear, and I shall save my ration for other topics. 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: 07 Sep 92 19:39:57 +0000 From: duck@nuustak.csir.co.za (Paul Ducklin) Subject: Re: F-Prot & SuperStor (PC) Thus spake Andrew_Clark.sdb-e@rx.xerox.com: >Second: IBM PC question. >Can anyone advise me whether there is a virus that modifies the >seconds field in a files time value to 62. I seem to recall that there >is a virus which does this. Plenty of viruses use this trick. Vienna was probably the first -- and the source went and got itself published in a book \end{flame}, with the result that it became a popular technique. Or, of course, you might have a program that's been "innoculated" against various viruses, including those which avoid infection if they see a second stamp of 62. [Incidentally, M*crosoft allocated 5 bits for "seconds", so a DOS filestamp has a 2-second granularity; 62 seconds are actually 31 M*crosoft-double-seconds]. Try as decent virus scanner [after a clean boot, of course] if you want to identify what it is. - -- - --<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>-- Paul Ducklin duck@nuustak.csir.co.za CSIR Computer Virus Research Lab * Box 395 * Pretoria * 0001 S Africa ------------------------------ Date: 07 Sep 92 19:32:05 +0000 From: duck@nuustak.csir.co.za (Paul Ducklin) Subject: Re: F-PROT reports Bugsres 3 Jokes program? (PC) Thus spake dana%are.Berkeley.EDU@ucbvax.Berkeley.EDU (Dana E. Keil): >I just obtained F-PROT. Running a scan with it reports that a file >named bugres.com is infected with a virus named "bugsres 3 jokes >program". I can find no mention of this virus anywhere in F-PROT >documentation (nor elsewhere). Can anyone enlighten me about it? The bugsres program I've seen is a non-viral TSR which waits for a hotkey and then starts up a bunch of text-mode "insects" which run around, chomping up the screen. A "joke", and not a virus. Of course, the problem with "jokes" is that jokers tend to encapsulate them in replicative engines and to let them go... Why keep software around if you don't know its function, anyway? Seems to be a waste of disc space to me - and a recipe for disaster. - -- - --<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>-- Paul Ducklin duck@nuustak.csir.co.za CSIR Computer Virus Research Lab * Box 395 * Pretoria * 0001 S Africa ------------------------------ Date: Fri, 11 Sep 92 07:24:17 +0000 From: mcampbel@nyx.cs.du.edu (Matthew Campbell 'The Fire Fox') Subject: Now I know I have something. (PC) VIRSTOP was installed as a device driver in Config.Sys right after Himem.Sys Later I tried installing VIRSTOP from the command line and it said: >VIRSTOP cannot be installed >This may be caused by an active virus or an incompatible DOS > >C:\VIRUS> f-prot.exe >Program infected with the [= ] Virus. >File access terminated. (A couple weird characters)(Control-Z) and a > halted system. I had just unzipped fp-205.zip from a clean, write-protected floppy disk; however, I didn't happen to boot with one. Has this ever happened to anyone else before? After killing the power for about a minute, I rebooted with a clean, write-protected floppy disk and scaned the drive with a different disk on which the scanner files were already expanded, (Not Zipped). I also scanned the other disks that came in contact, but no viruses were detected. I got my F-PROT from wuarchive. Is F-PROT supposed to have -AV with the files when unzipped? Mine doesn't. SCANNING RESULTS: Scanner used: F-PROT v205 Infected: 0 Suspicious: 12 (Mostly .ini and .cnf files) Disinfected: 0 Scanning: Hard Disks Method: Heuristics Scanning: All files Message: This is either a corrupted program or one which contains instructions wich do not exist on all 80x86 processors. It will crash on some machines. 0F0+were noted as suspicious such as NEW.205, SCAN.DOC, LANGUAGE.DOC, CONFIG.SYS, AUTOEXEC.BAT, and all scan.crc files. (scan.crc files are files made with McAfee's scanv95b.zip scanner.) (/af scan.crc) Scanner used: SCAN 8.7B95 McAfee Options: C: /a /m /chkhi Infected: 0 Suspicious: 0 A disk editor revealed extra garbage added to the ends of the suspicious files as named by F-PROT v205. The extra stuff held two sectors or less. The file names EMM386.EXE and SMARTDRV.EXE were added to the end of LANGUAGE.DOC which were two files that the computer uses in the boot up. You should see the end of the Config.Sys.... What a mess. Some hex codes include: 89 97 88 89 99 A8 89 FF CF 89 9D E8 89 9F 08 8A A1 28 8A A3 48 8A A5 68 8A A7 88 8A A9 A8 8A AB C8 8A AD E8 8A AF 08 8B B1 28 8B B3 48 8B B5 68 8B B7 88 8B B9 A8 8B BB C8 8B BD E8 8B BF 08 8C C1 28 8C C3 48 8C C5 68 8C C7 88 8C C9 A8 8C CB C8 8C CD E8 8C FF FF FF D1 28 8D D3 48 8D D5 68 8D D7 88 8D D9 A8 8D DB C8 8D DD E8 8D DF 08 8E E1 28 8E E3 48 8E E5 68 8E E7 88 8E E9 F8 FF EB F8 FF ED E8 8E EF 08 8F F1 28 8F F3 48 8F F5 68 8F F7 88 8F F9 A8 8F FB C8 8F FD E8 8F FF 08 90 01 29 90 03 49 90 05 69 90 FF 0F For the next two sectors it had something that looked like a data file containing names of viruses like: Violator, Stoned, Vienna, Hydra, and had names of the current scanners, characteristics of viruses, the months of the year, and some names of some countries. What should I do? - -- Matthew Campbell 'The Fire Fox' Internet: MatthewCal@Ids.Net MCampbel@Nyx.Cs.Du.Edu Ugcsmc0084%Mtvms2.Dnet@Terra.Oscs.Montana.Edu A thought to remember: "The only way to God is through his son Jesus Christ." ------------------------------ Date: 11 Sep 92 08:34:04 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: A new virus????? HELP! (PC) scholl@gaul.csd.uwo.ca (Cam Scholl) writes: > Anyways, here's what is happening. Every once in a while, my system > will try to access a file, only to find out that somehow, it has been > damaged! This has happened to Windows 3.1 program manager groups, Could be done by a virus, of course, but it doesn't sound like a virus problem to me... Most people seem to think that destruction of information is the most indicative symptom of a virus infected. In fact, the most important property of the viruses is their ability to spread. Only some of them intentionally cause a noticeable corruption of data. Remember, the main goal of the virus is to spread. And, if it destroys data in a noticeable way, you are likely to notice it and to remove it, therefore it will not be able to spread further... > Shortly thereafter, I ran into the same problem... After much > investigation, I have found that the virus seems to only attack files > with their archive bit set, meaning they've been changed since the This is quite indicative. Most viruses are clever enough not to modify any file attributes. What you are actually observing should be interpreted in the opposite way - not that something is modifying your files with archive bit set, but that something is modifying your files in a standard way (via the documented MS-DOS functions), which sets the archive bit. My guess is that you don't have a virus. Probably some kind of faulty application. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN ** PGP public key available on request. ** Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: 11 Sep 92 08:42:52 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Auto-detecting Virus (PC) Alexander_Ofek@p8.f101.n9721.z9.virnet.bad.se (Alexander Ofek) writes: > Your approach will fail to detect a stealth virus like 1963 or dir2. > To be on the safe side you will have to read the directory using absolute rea d > (int 13h) and follow the FAT chains yourself. Which will fail to detect advance stealth viruses like Int13, which are stealthy at sector access level. Using INT 13h to read the file will not detect Dir_II either, since this virus subverts the block device driver requests... > Of course it might be useful to > check whether the interrupt vectot of int 13h still points to the BIOS area. Unfortunately, since DOS 3.20 the interrupt vector for INT 13h never points to the BIOS area (except at boot time), since DOS intercepts it itself... There are other possible anti-stealth techniques that could be used, like scanning the ROM space for the hard disk controller program and calling it directly, but neither of these tricks is reliable and/or compatible with all kinds of systems... Just as an example, consider a disk, compressed with Stacker... How are you going to access the files on it "at a low level"? The -only- secure technique against the stealth viruses is to use the "magic object" - to cold boot from a write-protected non-infected system diskette. Unfortunately, this method of operation is considered too inconvenient by most users. Furthermore, it can be used only for off-line integrity checkers, and what the original poster proposed was an integrity module, contained in the executable file. In this case, there's no way to stop the stealth viruses from fooling the integrity module. > Use any CRC check with an UNUSUAL (i.e. rarely used) polinomial. More exactly, use a CRC with a -different- polynomial on each particular installation (be it a computer or a program). Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN ** PGP public key available on request. ** Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: Wed, 09 Sep 92 21:53:11 -0500 From: Gene Spafford Subject: Re: Looking for references (UNIX) See the postscript files on ftp.cs.purdue.edu in pub/spaf/security In particular, see IWorm and IWorm2 Also, here's some info on Robert Morris that many people ask for: Robert T. Morris, the author of the Internet Worm program, was convicted of a Federal felony in the case. The law involved was 18 USC 1030, the Computer Crime and Abuse Actof 1986. He was found guilty in February of 1990 in US District Court in Syracuse, NY. In May of 1990, he was sentenced -- outside of Federal guidelines -- to 3 years of probation, 400 hours of community service, and $10,000 in fines plus probation costs. His lawyers appealed the conviction to the Circuit Court of Appeals, and the conviction was upheld. His lawyers then appealed to the Supreme Court, but the Court declined to hear the case -- leaving the conviction intact. ------------------------------ Date: Thu, 10 Sep 92 15:37:47 +0000 From: jin@spdcc.com (Jerry Natowitz) Subject: Virus scan for AIX 3.2? (UNIX) I have never heard of a Unix based virus scanner, but I have been asked to investigate virus scanning of software built on, and running on, an RS6000 running AIX 3.2. Any leads, freeware or commercialware, would be appreciated. - -- Jerry Natowitz Guest user on: ARPA jin@ursa-major.spdcc.com UUCP {ima,harvard,rayssd,linus,m2c}!spdcc!jin ------------------------------ Date: Thu, 10 Sep 92 02:54:38 -0400 From: Christian Burger Subject: Re: self-checking programs In response to the posting of D. Beauregard on self-checking programs and to several comments thereon: You should have a look at the ``Stealth Bomber'' package by Kevin Dean. It implements a crc self-check plus additional anti-virus features for borland turbo c or pascal programs. The package uses a very sophisticated way to circumvent the problem that the crc itself is part of the stream to calculate the crc from, patching the executable after compilation. This package will probably not protect against all stealth viruses but it will certainly provide a good protection against the most common viruses. The stealth bomber package is freely available via anonymous ftp from any simtel archive mirror as /msdos/trojan-pro/stealth.zip. I would be interested in comments of the virus gurus on this package. Christian Burger, burger@dmrhrz11.bitnet ------------------------------ Date: Fri, 11 Sep 92 03:47:13 -0400 From: A.APPLEYARD@fs1.mt.umist.ac.uk Subject: Self-modifying programs Re self-modifying programs confusing virus scanners: before PC's were around, my university had a mainframe that had an Algol60 compiler that compiled (subroutines that had parametric subroutines) thus, e.g.:- real procedure integrate(fn,q,w,e,r,t); real procedure fn; real q,w,e,r,t; begin; .... x[2]=fn(q+w); ...... z=fn(t); ..... x[4]=fn(e+r); ..... end; The compiled version of procedure 'integrate' started with code which wrote a copy of the (entry address of whatever 'fn' was in that call) into the code of 'integrate' wherever it calls 'fn'. I don't know if there are any compilers around nowadays that do that sort of thing. ------------------------------ Date: Wed, 09 Sep 92 22:32:29 -0400 From: Anthony Naggs Subject: Re: Comp Virus Conferences ... THE BEST CONFERENCE THIS YEAR! Francesco Dalla Libera, , asked: > Yes, maybe I'm too lazy or I do not remember very well, but there is a > list of the most important Computer Virus Scientific Conferences for > the next year [1993, off course] ? A couple I know of next year: 6th International Computer Virus & Security Conference March 11th-12th 1993, New York City, NY USA Dick Lefkon posted a call for papers here a little while back. 3rd Virus Bulletin Conference probably in September again However the best one to attend, -subtle hint-, this year is still to come: The 3rd annual EICAR Conference (EICAR - European Institute for Computer Anti-Virus Research) December 7th-9th, Munich Germany Quick outline: Monday 7th is an introductory day. Tuesday 8th has an opening talk, and splits into technical and management tracks. Wednesday 9th continues with technical and management tracks, which join in the afternoon for a panel discussion. Tuesday and Wednesday will have papers in English and German with translation provided. If you have not sent your draft papers to Christoph, the deadline is Friday September 11! Final arrangements and full details of the programme will be posted here soon. Email for info to: Christoph Fischer ry15@rz.uni-karlsruhe.de or (UK) Anthony Naggs amn@vms.brighton.ac.uk 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 ------------------------------ End of VIRUS-L Digest [Volume 5 Issue 151] ******************************************