From lehigh.edu!virus-l Wed Apr 21 13:40:10 1993 remote from vhc Received: by vhc.se (1.65/waf) via UUCP; Thu, 22 Apr 93 00:49:39 GMT for mikael Received: from fidoii.CC.Lehigh.EDU by mail.swip.net (5.65c8-/1.2) id AA01091; Thu, 22 Apr 1993 00:45:13 +0200 Received: from (localhost) by Fidoii.CC.Lehigh.EDU with SMTP id AA36918 (5.67a/IDA-1.5 for ); Wed, 21 Apr 1993 17:40:10 -0400 Date: Wed, 21 Apr 1993 17:40:10 -0400 Message-Id: <9304212014.AA21187@first.org> Comment: Virus Discussion List Originator: virus-l@lehigh.edu Errors-To: krvw@first.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 V6 #68 VIRUS-L Digest Wednesday, 21 Apr 1993 Volume 6 : Issue 68 Today's Topics: Source of Virus Information Re: Viruses and Canada Re: Scanners getting bigger and slower Re: Should viral tricks be publicized? (was: Integrity checking) V-Sign? (PC) Re: Can a virus infect NOVELL? (PC) Re: Integrity Checking (PC) Re: Censorship/40-Hex (PC) Re: FORM-18 Virus and 1.44Mb diskettes (PC) Re: Port Writes (PC) Re: Unknown little virus? (PC) Re: VSUM (PC) Re: DOS 6.0 and Scan (McAfee) Interaction (PC) On the merits of VSUM (PC) Surviving warm boots (PC) Re: Can a virus infect NOVELL? (PC) Re: Proffesional Group Virusized ! (PC) Re: ANSI viruses and things that go bump in the night (mostly PC) BeBe Virus (PC) "DIR" infection, or "Can internal commands infect" (PC) "DIR" infection, or "Can internal commands infect" (PC) "DIR" infection, or "Can internal commands infect" (PC) Re: Single state machines and warm reboots (PC) Re: DOS 6.0 and Scan (McAfee) Interaction (PC) New files on risc (PC) 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.org 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, krvw@first.org ---------------------------------------------------------------------- Date: Tue, 20 Apr 93 08:29:29 -0400 From: Garry J Scobie Ext 3360 Subject: Source of Virus Information There has been a number of postings concering obtaining accurrate information about PC viruses. Although not available by ftp (yes you will have to put your hand in your pocket :-) I've found the following to be most helpful. Solomon, A. 1991 "PC Viruses. Detection, Analysis and Cure". Springer-Verlag. London. This book deals with around a hundred or so of the most common PC viruses and has a number of interesting technical observations. Well worth a read. Solomon, A. 1992 "Dr Solomon's Virus Encyclopaedia". S & S International Ltd. 2nd edition. The Encyclopaedia comes with the Anti-Virus Toolkit. I do not know if it can be purchased separately. It covers a large number of viruses including many obscure ones. The opening pages also include an excelent description on Stealth techniques. Cheers Garry Scobie LAN Support Officer Edinburgh University Computing Services e-mail g.j.scobie@ed.ac.uk ------------------------------ Date: Tue, 20 Apr 93 15:34:08 +0000 From: aparker@mach1.wlu.ca (alan parker S) Subject: Re: Viruses and Canada I'll try an clear up a few queries, arising from responses to the previous posting. At this point in time, we as a university have experienced Stoned, Noint, Manitoba and something which F-Prot 207 suggests is a Stoned variant, and Scanv102 calls stoned. On scanning numerous student/faculty floppy disks we have noticed that the disks which had system files on them, have the files no longer hidden. On getting information on the disk, via in this case Virus Busters Doctor program, the disk label(always garbage), O.E.M IBM 3.3, followed by the id is displayed. The 'stoned variant' which I refer to above, is called Manitoba by Virus Buster 3.95, but with 3.94 this was not the case. The main differences(for us) between these two releases was that the program could now remove 'Manitoba' from floppy disks. I've received comment from one of the writers of Untouchable, and have forwarded additional testing information, however I'm still re-assessing the untouchable software; however the original testing resulted in the previous posting. To summarise, Untouchable 1.13 allowed us to restore from the safe diskette after boot infection, on being infected with an unknown boot infection the res part of the packages(UT and S&D) flagged a different in available memory, 2K, since in the defining of the system original 640K was listed, now 638 is available. However no virus was detected, but suggestions were made of a possible infection. As far as the form infection which was mentioned, the diskette in question had been shipped from Germany, and the student was complaining of 'errors' on the disk. On using f-prot the disk had Manitoba and form was revealed as well. On examining the disk attempting to restore the users 'critical' information, less and less of the disks contents were becoming available to us, with each attempt. However perchance the disk has a great deal of physical damage, originally all but a few files were accessible to the student via ordinary dos means.. such as type or indeed by using a wordprocessor. However again on repeated calls of the same file(s) more data errors were flagged ending in general failures which resulted in the disk being checked with Norton. On the untouchable theme, the copy we were supplied with for evaluation, came as three seperate items, each of which we installed fully. Untouchable 1.13, Search and Destroy, Untouchable NLM. I hope this goes some way to making the original post clearer. Alan ------------------------------ Date: Tue, 20 Apr 93 16:37:59 -0500 From: Jim Huguelet Subject: Re: Scanners getting bigger and slower In response to: > Article 8697 of comp.virus: > From: Inbar_Raz@f210.n9721.z9.virnet.bad.se (Inbar Raz) > Subject: Scanners getting bigger and slower > Message-ID: <0001.9304151053.AA13078@first.org> > Date: 8 Apr 93 23:20:13 GMT [stuff deleted] > Data Security. More than once I had a meeting with Bank representatives, and > even a Hospital representative, which wanted to know more information. All of > them came to a point where they said - "But what good is a SmartCard, if > people can lose it just as well as they can lose/give away their password?" > > There is no reply to that. The human factor will always exist, and this is [stuff deleted] There is a reply, of sorts, because there is a not insignificant difference between a password (or other "what you know" authentication schemes) and a smart-card (and "what you have" authentication.) Only one person can be in possession of a smart-card at a given moment - many people can be in possession of a password simultaneously. Users cannot tell if their password has been compromised, but they can determine whether or not they're still in possession of their token. =============================================================================== Jim Huguelet t90jwh8@mp.cs.niu.edu Department of Computer Science Psych-Math Building, Room 461 Voice: (815) 753-6937 Northern Illinois University DeKalb, IL 60115 Opinions expressed are my own ------------------------------ Date: Fri, 09 Apr 93 04:39:00 +0100 From: Sara_Gordon@f0.n462.z9.virnet.bad.se (Sara Gordon) Subject: Re: Should viral tricks be publicized? (was: Integrity checking) bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes: >My experience shows me that the bad guys are less knowledgeable but >better organized and learning faster than the good guys... And I am >not excluding even us, when I am speaking about "better organized". as someone who does study this, i am sorry to have to agree with you. the organization of the 'bad guys' is really extraordinary considering the usual problems of such organizational efforts... >Yes. I am getting virus collections from all over the world. Do you >know how many of them bear the signature of being downloaded from >Todor Todorov's BBS? but wait!! this does not necessarily mean they came from that bbs, of course. i have viruses sent to me from all over the world that have the names of anti-virus companies, anti-virus researchers, even my OWN name...this does not mean they originated here. why, i even have seen them from the VTC at Hamburg...i.e., when they are unzipped, they say 'Virus Test Center, University of Hamburg' in the A-V marking! of course, viruses did come from that bbs in sofia. its fortunate that bbs is no longer in operation; and unfortunate that many more have taken its place, mainly in the USA....and no one seems to care.... >Burger's and Ludwig's books are crap - they don't teach you anything, >even how to write good viruses. They don't contain useful information, i assume you meant to write viruses well, not to write good viruses :) - - -- # "talk to me about computer viruses............" # fax/voice: 219-277-8599 p.o. 11417 south bend, in 46624 # data 219-273-2431 SGordon@Dockmaster.ncsc.mil # fidomail 1:227/190 vfr@netcom.com - --- OD 0.0.1 * Origin: C.C.C. (9:462/121.0@VirNet) ====> OverDose Gateway Notice <==== Message is actually from sara@gator.rn.com Reply to 9:462/121.0 Internet Gateway with first line of message body beeing: TO: sara@gator.rn.com ------------------------------ Date: Tue, 20 Apr 93 10:50:25 -0400 From: Barbara Carlson Subject: V-Sign? (PC) A computer in a public cluster here turned up with what f-prot called "V-Sign". It said it infected the boot sectors of each of the drives (c,d,e,f) and listed garbage as the name for one of them. Has anyone heard of this virus? There is no mention of it in the listing that comes with f-prot. The version of f-prot was current -- 2/93. They had to do a hardware reformat of the disk - *three times* - could this thing have stuck around and diverted a format? Anything out there that could get rid of it?? - --Barb-- ------------------------------ Date: Tue, 20 Apr 93 16:44:21 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Can a virus infect NOVELL? (PC) sywu@csie.nctu.edu.tw (Xianyow ) writes: > I have a question, can a virus infect NOVELL system? Yes, of course. And it even happens relatively often. Mainly due to sloppy LAN security. > Since there are > many read-only files in NOVELL, how can it write into that file? Theoretically, it can't. However, what does exactly mean "read-only"? A file with the ReadOnly -attribute- set? A virus could easily remove this attribute, if the Modify -right- is granted to this file. Or do you mean a file that does not have the Read -right- granted? Granted to whom? If -you- do not have the right to write to this file, some other user might have it. And this user's workstation might be infected... Or even the supervisor's workstation might be infected - it happens... And the supervisor is able to write to any file... Similarly, it is possible to bypass the ExecuteOnly attribute by using a companion virus, as described in Dr. Cohen's paper in the proceedings of the 2nd Virus Bulletin conference. The paper describes in details his experiments on how protection works (and how it doesn't) on Novell NetWare and Unix file servers. Unfortunately, he has used NetWare 3.11 in his experiments. This is a version we don't have here, so we were unable to repeat the experiments. We did some similar experiments on NetWare 2.15c, but found nothing exceptional, except that if you establish a sloppy combination of rights and attributes, a virus will be able to infect the files. > If it can't > , how can it live when the power turned off? :-). It "lives" in the infected files. Whenever you execute one of them, the virus becomes active. If it is a memory resident one, this means that it installs itself in the memory of the workstation that has executed the infected file. > But I really heard some viruses can infect NOVELL. Can anyone answer me? Yes, many of the existing viruses do - if the protection settings allow (or do not forbid) them to do so and if the viruses are written well enough. There are also a few NetWare-aware viruses that steal passwords. 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 2.2 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: Tue, 20 Apr 93 16:55:37 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Integrity Checking (PC) ST29701@vm.cc.latech.edu writes: > I am looking for a program like Integrity Master that will store all the > data in one file. I dislike Integrity Master because it stores all the > info in each subdirectory. > At the same time I would like something as safe or safer than Integrity > Master. You didn't specify it to be shareware, did you? OK, there is a commercial product that does that - it is called Untouchable and is marketed in the USA by Fifth Generation Systems. Actually, there are many other products that use only a single database of checksums - NAV, SCAN, Sentry, Dr. Solomon's AVTK, etc., but since you also wanted it to be secure... 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 2.2 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: Tue, 20 Apr 93 13:02:37 -0400 From: AMN@UBIK.DEMON.CO.UK Subject: Re: Censorship/40-Hex (PC) David Hanson, , wrote: > And how does a "good guy" get 40-Hex? ... Chance. > ... Wouldn't receipt of 40-Hex from > *any* source be participation in the -distribution- of this magazine? > Not necessarily by dissemenating the info ("good guys" would NEVER do > that), but by creating demand. ... I don't solicit for such material. If it happens my way and tells me what is 'popular' with the virus writers, I am quite happy to take this as a hint to what I should be doing in response. > ... Even if you get it from another "good guy", > passing the magazine from one place or person to another is distribution. > This is something that is ok for YOU to participate in, but not ME (if I am > to be a "good guy")??? Viruses are going to remain a problem for the forseeable future. So the publicity and 'glamour' associated with producing will assure they continued production. Maintaining 'virus scanners' is expensive in time and labour, > Tell me, where do YOU get 40-Hex from? Generally other researchers say "the new issue of 40-hex includes a new virus/advocates method X of attacking a-v products" and pass me a copy. I can then revise my a-v tools to ensure that I can help my clients when these viruses are spread. > Why should it be ok for you to receive it, but not me? 40-hex is basically an incitement to write and distribute viruses, with hex dumps and disassemblies, and a few words of editorial encouragement. As such it is quite dangerous, a barely competent PC user could follow the published instructions to obtain an active virus. I wouldn't sell a gun/car/tank of acid to someone unless I am persauded they are competent to own/handle it. Similarly I will not pass something as damaging as a virus unless you persaude me that you are competent to handle, store and keep it safe. I should mention that I take a lot of persauding. > I do not wish to detract from the extremely valuable and "good" work that > you do as a virus researcher, just want to point out that "good"/"bad" > is not black/white, more like shades of gray. Case in point - your > participation in 40-Hex distribution. If you're going to fight the "bad" > guys, you've got to get your hands dirty. This is utterly wrong, there is no need to "get my hands dirty". If I obtain useful insight into virus writers current objectives it is curteous of me to alert other virus researchers. In the case of 40-hex it is simplest to forward the whole publication. > BOTTOM LINE: I really get peeved when access to information such as > 40-Hex is limited "for my own good". ... It is not for your good, but mine. It is unethical for me to pass such material to someone who might use it malicously, or is likely to have an 'accident' because they are not competent to take adequate safeguards. > ... In the short term, > censorship may seem like a good idea, but in the long term, It's not censorship, but trust. I work hard to earn the trust of my clients, and other researchers. I intend to keep that trust by behaving ethically, and being exceedingly cautious in providing viruses to other people. Regards, - -- Anthony Naggs Email: Paper mail: Software/Electronics Engineer amn@ubik.demon.co.uk P O Box 1080, Peacehaven & Computer Virus Researcher or amn@vms.bton.ac.uk East Sussex BN10 8PZ Phone: +44 273 589701 or xa329@city.ac.uk Great Britain ------------------------------ Date: Tue, 20 Apr 93 13:25:24 -0400 From: AMN@UBIK.DEMON.CO.UK Subject: Re: FORM-18 Virus and 1.44Mb diskettes (PC) Paul Ferguson, , wrote: > Recently. however, this particular variant surfaced again > yesterday. I made sure that I got a functional copy this time. > This variant activates on the 18th of the month, as described in the > dialog below from last fall. Hi Paul I don't remember looking at this one, probably sitting in my "in-tray" still, :-) > On a 1.44 Mb diskette, FORM relocates it's "jump" code to Cyl 7, > Side 0, Sector 16. It relocates the original DBR in the next sector, > sector 17, and marks both sectors bad. The text contained in sector > 16 is the same "The FORM Virus sends greetings..." message as with > the original FORM. > > Correct me if I'm wrong, but isn't this area used by DOS to store the > second copy of the FAT? If my understanding is correct, then the disk > allocation for a 1.44 Mb diskette is: > > Sectors Used for Used by > - ------- -------- -------- > 0 Boot Record DOS > 1-9 1st FAT DOS > 10-18 2nd FAT DOS > 19-32 Root Directory DOS > 33-2,879 Data Whatever I think you're suffering from a summer cold, you did say cylinder 7! If Cyl 7 Side 0 Sectors 16, 17 are the physical address, on a 1.44Mb floppy these translate to 'absolute' DOS sectors 267 & 268, (clusters 236 & 237). Quite a long way from the FAT. Hope you don't feel too foolish. Good luck with Legal Net Monthly, the first issue certainly looks promising. Regards, Anthony Naggs Email: Paper mail: Software/Electronics Engineer amn@ubik.demon.co.uk P O Box 1080, Peacehaven & Computer Virus Researcher or amn@vms.bton.ac.uk East Sussex BN10 8PZ Phone: +44 273 589701 or xa329@city.ac.uk Great Britain ------------------------------ Date: Tue, 20 Apr 93 16:59:00 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Port Writes (PC) Amir_Netiv@f120.n9721.z9.virnet.bad.se (Amir Netiv) writes: > What do you mean "non-natural way" who said that the "natural way to write to > a disk is only via INT-13, and how do you think INT-13 accesses the disk? Why > can't it be by port write? Does the DMA not use ports to perform some disk > transfers? I'd say that generally your suggested method is good due to the > lack of other methods (except hardware products that monitor the system-bus) > but I don't think it is suitable for implementation in a software product > because you'll have more False Alarms then you can handle (at probably the > worst times). By a natural way to write to the disk I mean - using the DOS file system. After all, all DOS manuals are telling you that this is the way to write to the disk. Internally DOS translates this to INT 13h requests. You could also use INT 26h (which is also translated to INT 13h requests by DOS, but DOS never uses INT 26h itself), or even INT 13h yourself, but this is already considered "dangerous" by any kind of resident interrupt monitoring program I have ever seen. The only programs that usually go that low are the programs from the Norton Utilities and the similar packages - disk organizers, directory sorters, disk editors. Oh, yes, and CHKDSK uses INT 26h too - when it needs to fix the FAT(s). Regarding the DMA, the abbreviation stands for Direct Memory Access and, as the name suggests, is used to access the memory in a fast way (bypassing the CPU) - not the disk. Of course, it is possible to do very fast disk transfer by controlling the disk via the ports and initializing DMA transfer to copy the read data to the appropriate location. At last, regarding what you think - whether the implementation will be suitable or not - I am not talking theories here. I have actually used such a product for months - and it never gave a false positive, and never allowed a virus to write to my hard disk. Maybe I was just lucky and didn't use some of the programs you claim to cause false positives if such a protection scheme is used. Could you name some particular products? Oh yes - why I am not using the product any more. Well, the Dark Avenger wrote the Number of the Beast viruses, and the Phoenix viruses, and the two guys from Varna wrote the MG viruses. All those viruses don't try to bypass INT 13h - instead they intercept it at two levels and fake a read when they want to do a write - so our nice protection program sees a read request, tells the "device ready" watching program "it's OK, buddy, let it pass", but here comes the virus again and turns the request back to write... If you are an anti-virus researcher worth your salt, you should be able to understand what I am talking about by looking at the viruses I mentioned... > Again, if you interfere in the wrong time, you might end up with a crashed > disk. But theoretically it is true. As I wrote about, I am not talking "theoretically" here. It is practical, it does work, I used a product that relied on this scheme (and did a lot of other things, like providing a Cyrillic keyboard driver, switching the character generators of the Bulgarian IBM PC clones, displaying a clock and the status of the *Lock keys on the 26th line of the screen on CGA controllers), and it NEVER crashed my disk. The only reason I stopped using it was because there appeared viruses that were able to circumvent it and I hate to be given a false sense of security. Well, yes, and I switched to EGA/VGA, but I also switched to a different clock program which is still able to display a clock on the 26th line... and the other bonuses too... :-) > > BTW, note that many hardware anti-virus products - will- > *MIGHT* instead of "- will -" ;-) > > be able to > > stop this kind of disk access, if they can be installed between the > > computer and the disk controller or between the disk controller and > > the bus... Please, don't quote me out-of-contest - I specified when some hardware anti-virus tools WILL and I mean will be able to stop this kind of disk access. I am not claiming that all of them do it - just that those of them that can do it WILL do it. > Usually the Hardware Anti-Virus products are installed ON the system-bus (in Some are, some are not. Here are some examples - ThunderByte -can- be installed between the controller and the hard disk. ExVira -is- installed between the controlled and the bus. Where are your examples? > one of the slots), if one does as you suggest (between disk and bus) I'd > expect "some" 8-) problems (to say the least). You'd expect? Then you'd expect wrong - as I said, ExVira is installed exactly in this way. In practice, you plug the card in a free slot, there is a flat cable that ends with something that resembles to a piece of paper, metalized from one of the sides only. You put it in the slot where the disk controller normally resides with the non-metalized side down. It is flexible and fits in the slot. You then insert the disk controller atop of it. The signals go to the controller, from it to the ExVira card. The card is a whole computer, with 68000 CPU, lots of RAM, ROM, and is attached not only to the hard disk controller, but also to the keyboard. 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 2.2 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: Tue, 20 Apr 93 17:27:37 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Unknown little virus? (PC) Malte_Eppert@f6051.n491.z9.virnet.bad.se (Malte Eppert) writes: > > There's no way to fit a memory-resident virus into 32 bytes... > What about a resident 'high DOS' or XMS swap routine, could it be that short? Well, dunno, what do you mean exactly by that? A big high-loaded TSR that has a small routine in conventional memory to call it? Dunno... maybe; have to check. Actually, I am no longer so sure about my initial statement. Padgett demonstrated me how it is possible to make the resident part of the virus occupy just 35 bytes. It is trivial to extend his idea into a program that consists of 31+4 bytes - that is, 31 consecutive bytes in one place and 4 consecutive bytes anywhere else - DOS is full of holes... 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 2.2 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: Tue, 20 Apr 93 17:32:53 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: VSUM (PC) sbonds@jarthur.Claremont.EDU (007) writes: > >What do you recommend as a better alternative, instead of VSUM then? > So far the best source of CORRECT information has been from Frisk's > F-prot. I have yet to find a case where his information has been incorrect. > Unfortunately, there isn't a whole lot of info included. Yes, that's the problem. All existing sources of such information are either incorrect, or incomplete, or both... :-( > The sort of info I'd like is on the order of: if resident, how? What > interrupts are hooked? Does it ask DOS to allocate memory, or does it > go around DOS? If it's buggy, why? Ah, yes, you are reminding me of something. We have such a project in CARO. Exactly what you would like a database of technical virus information (no scan strings, sorry) in a highly tokenized format - so that it permits easy searching and report generation. It's only the information skeleton - you can build a front end that uses the information to generate human language descriptions which could be as verbose as VSUM's entries, or just view it as database records with some mnemonic expansion of the values of the fields - if you are knowledgeable enough to understand them. The format is ready, we also have a few virus descriptions that illustrate how to use it. They are free for distribution or inclusion in any products (commercial or not). However, the copyright is retained by the University of Hamburg and you are not allowed to modify the entries without our permission. The people who write each entry have a copyright on it, but are granting it to the University (at least this is what I understood; I am by no means competent in these matters). What you are reminding me is that I have to make this information available by anonymous ftp. It will be accessible as ftp.informatik.uni-hamburg.de:/pub/virus/texts/carobase/carobase.zip Please, note that this is not a source of information about viruses - at least not yet. It is practically empty. The important stuff is the format of the database. The database itself is expected to be created later. > names of the analysts on the information. With so many people dissecting > viruses, if we all pooled our knowledge we could get an info sheet of enormou s > proportions! Yes, that was the intent - that the virus experts are filling the database in the designed format. > Oh, well. Enough dreaming. ;-> Why dreaming? Get the format and begin sending us entries!... :-) 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 2.2 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: Tue, 20 Apr 93 17:54:23 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: DOS 6.0 and Scan (McAfee) Interaction (PC) s926191@yallara.cs.rmit.OZ.AU (Donald Gingrich) writes: > 1. he booted the machine with the MS DOS 6.0 VSAFE in the autoexec (config?) > (I haven't seen DOS 6.0 yet) > 2. he ran McAfee scan with the /chkhi option twice (don't ask why) > 3. on the second pass it reported the "filler" virus > 4. he has scanned the hard disk with the /chkhi /a options after a cold boot > on a known clean floppy -- nothing found > seems like a false positive to me. Hmm, sorry I was unable to reproduce the problem. First, SCAN 102 does not scan the memory twice, even if you supply the /chkhi option twice. Second, it didn't find any viruses in memory, even with VSAFE loaded. 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 2.2 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: Tue, 20 Apr 93 18:00:08 -0400 From: Mikael Larsson Subject: On the merits of VSUM (PC) 007 writes: > Isn't there enough misinformation out there already? Of course VSUM will > be fine for the "common-people"-- they don't know any better! I find it > very upsetting that you would be willing to knowingly spread information > that is just plain WRONG. You are preying on the ignorance of these > common people. No, that is not correct, but since most of the common-users get infected by viruses like form, cascade etc.. and wants to read about THOSE viruses, then I think VSUM is good. > It is one thing to be wrong, admit you were wrong, and correct any mistakes > possible, and entirely another to be wrong, know you are wrong, and just > not care that many people will have just enough information to get into > trouble. Ignorance, at least, inspires caution. Sure, there are incorrect info in VSUM, but the users get the general idea of what the virus does/does not. The COMMON user aren't interested in all the technical stuff about that virus that they got infected by, they wanna see if it does any harm or not, how it spreads. Hope you get my point, MiL - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Virus Help Centre Phone: +46-26 275740 Email: mikael@vhc.se Box 7018 Fax: +46-26 275720 or : mikael@abacus.hgs.se S-811 07 Sandviken BBS #1: +46-26 275710 Fido : 2:205/204 & 2:205/234 Sweden BBS #2: +46-26 275715 Authorized McAfee Agent! ------------------------------ Date: Tue, 20 Apr 93 19:35:23 -0400 From: AMN@UBIK.DEMON.CO.UK Subject: Surviving warm boots (PC) A. Padgett Peterson, , wrote: > ... Accordingly the following code is presented as > an explicit way to generate a warm reboot that would be difficult > (but not impossible - this is software after all but a virus would have > to be looking for this specific sequence) to intercept (and there is a very > large number of ways to express the same thing). > > ... This is indeed a (fairly) reliable method of resetting a PC. A word of WARNING: This is flawed, in that it can potentially cause data damage to your PC. Expanded Memory Managers, Disk Caches and other software often need to be warned of a reset, in order to reset hardware and empty write buffers. I think the FAQ for comp.os.msdos.programmer has the appropriate information if you want to write a safe system reset program. (OTOH warning other software of the reset effectively defeats trying to reset without allowing resident viruses to interfer. Regards, Anthony Naggs Email: Paper mail: Software/Electronics Engineer amn@ubik.demon.co.uk P O Box 1080, Peacehaven & Computer Virus Researcher or amn@vms.bton.ac.uk East Sussex BN10 8PZ Phone: +44 273 589701 or xa329@city.ac.uk Great Britain ------------------------------ Date: Tue, 20 Apr 93 20:19:23 -0400 From: kam.bansal@symantec.com (Kam Bansal) Subject: Re: Can a virus infect NOVELL? (PC) > I have a question, can a virus infect NOVELL system? Since there are >many read-only files in NOVELL, how can it write into that file? If it can't >, how can it live when the power turned off? > But I really heard some viruses can infect NOVELL. Can anyone answer me? If the server is setup correctly (trustee rights etc), all should be well ( famousee last words!). Novell is really good at stopping anything from changing a file that is read-only or the user only has read only rights. I' ve tried along time to smash it, and lost! There is a command in netware 3.x that goes something like this "set executable files read only = on" Yes, I know the set command is wrong, but what it does is makes *every* executable file read only and will not allow *any* file to be writen too, so the only way to upgrade a file is to first delete it and then copy a new one! The real question is what if the following happens... A virus waits till a user has write rights to SYS:SYSTEM, and then attaches itself to a NLM! stream.nlm or clib would be a good start! They are the libraries for netware, then once the virus is active, on the server now, not the workstation, it can do ANYTHING! From a NLM, you can delete, trash anything even if it has read only rights! I believe that the new trend of viruses will be for netware (this is my opinion!) as NLM infectors! -Kam (^8* ------------------------------ Date: Wed, 14 Apr 93 19:24:00 +0100 From: Robert_Hoerner@f2170.n492.z9.virnet.bad.se (Robert Hoerner) Subject: Re: Proffesional Group Virusized ! (PC) Hello Vesselin, VB> Uh, wait a minute... Mich uses INT 1Ah to get the current date, so it VB> usually does not trigger on XTs... Or did yours have some kind of CMOS VB> clock? On XTs it is (has been) common practice to insert the commands "date" and " time" into the autoexec.bat. INT 1Ah will give the system-date as set by the user. No CMOS is needed (but highly preferred :-)) Ciao, und viele Gruesse, Robert - --- * Origin: Virus Help Service Karlsruhe, 49-721-821355 (9:492/2170) ------------------------------ Date: Wed, 14 Apr 93 13:25:00 +0100 From: Sten_Drescher@f0.n462.z9.virnet.bad.se (Sten Drescher) Subject: Re: ANSI viruses and things that go bump in the night (mostly PC) From: smd@hrt216.brooks.af.mil (Sten Drescher) On 6 Apr 93 19:50:08 GMT, padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) said: Padgett> a) If you have the stock ANSI.SYS loaded, have demonstrated Padgett> that it is possible to construct a mechanism that will cause Padgett> an infection to occur on execution of a DIR command on a Padgett> "prepared" floppy. Agreed. Padgett> b) There is no real need for anyone to have ANSI.SYS loaded. Well, yes, no need for the DOS ANSI.SYS. Padgett> IMHO while ANSI.SYS once had a real value for key redirection, Padgett> this is no longer true. Today the main reason is to set the Padgett> screen colors (a PROMPT string containing [37;44m will Padgett> produce a blue background with white letters). You can do the Padgett> same thing with a one byte change to COMMAND.COM (DOS 5.0 and Padgett> 6.0 COMMAND.COM contain on byte pair "B7 07". The second byte Padgett> defines the screen colors on a CLS (07 is low white on black). Padgett> Using DEBUG you can change this byte (found at DEBUG offset Padgett> 4A53 in DOS 6.0) to 17 for a blue background or 0F for bright Padgett> white on black - - nice on older laptops - Note: you will need Padgett> to reboot after the change & COMSPEC must point to the new Padgett> COMMAND.COM. Hmmmmmm. Now, tell me, how does this patch allow me to change screen colors in my PROMPT string? Answer: it doesn't. A better answer, rather than to tell people to make binary patches to their OS, is to use one of the multitude of ANSI drivers that don't support, or allow you to disable, key redirection. Just off the top of my head I can think of NANSI, NNANSI, ZANSI, ANSIPlus, and ANSI.COM (from PC Magazine). - - -- +---------------------------+--------------------------------------------+ | Sten Drescher | "Jill's fourth grade class raised $200 | | 2709 13th St #1248 | from a bake sale to reduce the federal | | Brooks AFB, TX 78235-5224 | deficit. If the deficit is $4 trillion, | |---------------------------+ how many bake sales will they need to pay | | smd@animal.brooks.af.mil | for a $30,000 jogging track?" R Limbaugh | +---------------------------+--------------------------------------------+ #include - --- OD 0.0.1 * Origin: C.C.C. (9:462/121.0@VirNet) ====> OverDose Gateway Notice <==== Message is actually from smd@hrt216.brooks.af.mil Reply to 9:462/121.0 Internet Gateway with first line of message body beeing: TO: smd@hrt216.brooks.af.mil ------------------------------ Date: Wed, 14 Apr 93 13:38:06 +0100 From: Inbar_Raz@f210.n9721.z9.virnet.bad.se (Inbar Raz) Subject: BeBe Virus (PC) Hello everyone. Before you read this letter, you should be aware of the fact that it was not written at one time. It was written during a research I was (and still) doing. It will be exported probable before the research is finished, so there might be more messages, although chances are small. To the point: A couple of days ago, I decided to go over the huge virus database I have, and make it smaller, by removing duplicates, and infecting smaller files whenever possible. While doing that, I found a few interesting things: 1. One of the viruses, which I can't remember its name at the moment, tries to find the original vector of Interrupt 13h by searching for CMP DL,80 in the BIOS segment (0F000h), and therefore it didn't work on my computer - when I ran it, I had to load it into the debugger, and actually feed it with a vector to Interrupt 13h :-). I later found another virus, Cemetery, which is actually a Murphy mutant, which also tries to imply this trick, thus I tend to believe that the first one was also a Murphy mutant. However, this technique also appears to be used by the Dark Avenger virus, as I later found out. 2. The BeBe virus, for some reason, did not execute well. It hung the computer. What's more weird is that if I load it to a debugger and STEP it, it works. Even more weird is that if I load and GO, it hangs as well. 3. I have a virus, aliased 'Brothers in Arm'. I was very suprised to find that only SCAN has managed to find this virus, but even that not completely fine. Scan claimed there were both Brothes [Bro] and 1530 [1530]. TBSCAN (by ThunderByte) found nothing, as well as PF1's UNVIRUS. When I ran the infected program, nothing else ran afterwards - I simply returned to the DOS prompt. Even DIR returned nothing. Any ideas as for the Bebe? The VSUM says that it won't replicate on 386's, but hang - exactly what happened, but it doesn't say why. I suspect it has to do with the virus's jmp instruction. The virus does a relocation-like operatin on a FAR JMP instruction within itself, to jump to the virus code. After that, I can run the program freely in DEBUG, and, like I said, it works. Inbar Raz - - -- Inbar Raz 5 Henegev, Yavne 70600 ISRAEL. Phone: +972-8-438660 Netmail: 2:401/100.1, 2:403/100.42, 9:9721/210 nyvirus@weizmann.weizmann.ac.il - --- FMail 0.94 * Origin: Inbar's Point - Home of the UnTinyProg. (9:9721/210) ------------------------------ Date: Sun, 18 Apr 93 11:55:00 +0100 From: Amir_Netiv@f120.n9721.z9.virnet.bad.se (Amir Netiv) Subject: "DIR" infection, or "Can internal commands infect" (PC) frisk@complex.is (Fridrik Skulason) writes on a reply to Amir_Netiv@f120.n9721.z9.virnet.bad.se (Amir Netiv) AN: >>unreported). There is a reason for all that: every program that needs more >>memory MAY overwrite the TRANSIENT part in memory (so more memory is >>available to programs). FS: > Small correction: Some TSRs may NOT overwrite that > part, if they may get called while COMMAND.COM is active. > This includes all programs that intercept INT 21, AH=4B, > some INT 2FH functions etc... True. Moreover: *Most* programs will not touch the TRANSIENT, but the large ones or the ones that allocates in the top of the memory on purpose. This design is a smart idea to allow more system flexibility, It doesn't mean that it will always happened. Regards * Amir Netiv. V-CARE Anti-Virus, head team * - --- * Origin: <<< NSE Software >>> Israel (9:9721/120) ------------------------------ Date: Sun, 18 Apr 93 11:40:00 +0100 From: Amir_Netiv@f120.n9721.z9.virnet.bad.se (Amir Netiv) Subject: "DIR" infection, or "Can internal commands infect" (PC) Hello Chris General comment: In my original article I tried to explain the mechanism of the "SHELL", meaning the way it's devided and the objectives of each part. I merely stated a possible mechanism of how a code might be loaded from a floppy with no intention. On a reply to Amir Netiv, Chris Franzen writes: > The transient part is never overwritten if you execute > an internal command. Thats true. You might overwrite it if you execute a program or allocate memory to a program. > No. I never saw this happen. You will be unable to force a re-read of > the transient part by executing an internal DOS command from the > DOS prompt...because the DOS prompt (the internal command processor) > is part of the transient part :-) True again. But consider the possibility that you use "DIR" from whithin a batch file (that also executes programs) the one prior to "DIR" might be the one that touched the TRANSIENT. Also what do you think about a program that " shells" to DOS (running "DIR" from whithin a program), in this case the TRANSIENT also might have been touched at program load time, and the "shell- to-DOS" frees the memory for the operation (you see many times the instruction "Insert diskette with COMMAND.COM..." when running programs that exit to DOS to do some DOS operations). > AN> In conclusion: If you use a floppy drive system (assuming you've booted > AN> from it) and you type "DIR" it is possible (but not likelly) > AN> that the TSR part of COMMAND.COM will try to load the TRANSIENT > AN> part from the infected floppy. However: to infect the TRANSIENT part > AN> alone in such a way that the CF: > No! I would like you to demonstrate this. You will be unable to > do that eh? As I said. It will not happened while typing "DIR" at the DOS prompt, but it might if you run DIR from a batch file or from a program. > AN> TSR will load exactly what you want is an un-easy task (however > AN> possible), but the *INFECTED* COMMAND.COM should be present at boot > AN> time since the TSR knows the file it is using to refresh the TRANSIENT > AN> by meens of a CHECKSUM generated at first loading. Thus: simply > AN> switching COMMAND.COM to > AN> an infected one (after the system is already booted) will not sufice. CF: > He! Here you say "it's unlikely because the reloaded > COMMAND.COM must be the one used when first bootet". Nop. I say that the command.com expects to find the right part in the file on the floppy by means of a checksum, but we know how "easy" it is to trick this way of checking, and BTW, I've seen things happened when you are working with a floppy based system (no hard disk) and switch floppies like mad, (you've forgotten what it's like probably). VB: >>> infected, you must execute some viral code. Therefore, the question is >>> equivalent to whether you can execute some code by executing the DIR >>> command on a floppy. > AN> I think I explained above how you *might* execute some code by "DIR". CF: > No. Demonstrate this! Demonstrate this! Nicely stated. (I can almost here you shout... Goog humor!) I'd live this to the virus writers to do, They might pick your challange. > You will not be able to force a COMMAND.COM- reload if you execute > DIR from a plain vanilly DOS prompt. As expressed before... > Hot for reply Come to Israel, we have 35 deg.cent. today... Regards * Amir Netiv. V-CARE Anti-Virus, head team * - --- * Origin: <<< NSE Software >>> Israel (9:9721/120) ------------------------------ Date: Sun, 18 Apr 93 12:20:00 +0100 From: Amir_Netiv@f120.n9721.z9.virnet.bad.se (Amir Netiv) Subject: "DIR" infection, or "Can internal commands infect" (PC) Vesselin Bontchev writes back to Amir Netiv: VB: > [excellent description deleted] Thanks. VB: > COMMAND.COM computes a checksum of the transient part and verifies > it each time it displays the prompt. That is, after each program > termination. EXTERNAL program. Any program can destroy the transient > part of the command interpreter, but it will be reloaded right after this > external program terminates. So far so good. > During the reload, the checksum will be re-computed and DOS will keep > insisting that you supply the real thing until the checksum matches. Right again, do you not see the possible hole here? > That's why you cannot use a different version of the command interpreter, > even if you change COMSPEC to point to it. (You CAN use a different > -copy- of the same command interpreter, located somewhere else, > if you change the COMSPEC variable.) When you've booted from a floppy derive, the COMSPEC is A:\COMMAND.COM, (did you forget the days few people had disks?) so you have to keep handy *THE* bootable floppy. > However, the DIR command is internal and its execution > does NOT destroy the transient part of COMMAND.COM, therefore > it NEVER causes its reloading. Absolutelly, and definitely TRUE. But what about "DIR" from whithin a program? The only question here is only: when can you replace the command.com to cause the reload of the TRANSIENT to load the infected one? AN: >> However: to infect the TRANSIENT part alone in such a way >> that the TSR will load exactly what you want is an un-easy task (however >> possible), but the *INFECTED* COMMAND.COM should be present at boot time >> since the TSR knows the file it is using to refresh the TRANSIENT by >> meens of a CHECKSUM generated at first loading. VB: > That's true, but we are talking about the DIR command > performing this. > It it IMPOSSIBLE. When you do a "DIR" from whithin a program (with "exec") you load another copy of command.com do to it, this might be the time when a "simple" does more then the user expects. AN: >> Thus: simply switching COMMAND.COM to an infected one (after the system is >> already booted) will not sufice. >> My conclusion is also that it is not possible (in normal conditions) to get >> infected just by typing "DIR". See..... VB: > It is not possible under any conditions (ANSI stupidities excluded). VB: > I challenge you to describe me a reproducible > situation in which executing the internal DIR command (on an > uninfected system and no ANSI keyboard programmability) will cause > reloading of the command interpreter from the diskette that is being > examined. I just did, and I leave the rest for virus writers who might pick your challange. Regards, * Amir Netiv. V-CARE Anti-Virus, head team * - --- * Origin: <<< NSE Software >>> Israel (9:9721/120) ------------------------------ Date: Tue, 20 Apr 93 08:46:58 -0400 From: Garry J Scobie Ext 3360 Subject: Re: Single state machines and warm reboots (PC) > From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) > > Several people have mentioned the ability of some viruses to survive > warm reboots and suggested that only cold (power off) reboots be used. > > In fact what is happening is that the virus has intercepted the keyboard > handler and is simulating a warm reboot rather than actually executing > one. I know of no virus (and am sure will be corrected if wrong 8*) that > can survive a *real* warm reboot. Was this thread ever followed up. In Volume 5 Issue 41 1992, Vesselin noted that no virus could survive the genuine or *real* Ctrl-Alt-Del or warm re-boot. However, in Issue 44 David Chess notes: >An interesting argument (we can take it offline if you like; I'd >claim that there are viruses that can do it in virtually any >configuration), BUT not of interest to end users. As far as the user >is concerned (and that includes even us expert-types when we're >actually using machines!) if there are -some- viruses that can - >sometimes- survive a three-key reboot, it's safest to assume that any >virus might, and to always do a poweroff reboot if it's important to >have the machine in a clean state. It's just too easy to make a >mistake otherwise! So, to present an alternative to your statement: > > In short, since some viruses ARE able to survive the Ctrl-Alt-Del > sometimes, Was this taken off-line and resolved? David, Vesselin? Cheers Garry Scobie LAN Support Officer Edinburgh University Computing Services e-mail: g.j.scobie@ed.ac.uk ------------------------------ Date: 20 Apr 93 14:26:09 +0000 From: frisk@complex.is (Fridrik Skulason) Subject: Re: DOS 6.0 and Scan (McAfee) Interaction (PC) s926191@yallara.cs.rmit.OZ.AU (Donald Gingrich) writes: >1. he booted the machine with the MS DOS 6.0 VSAFE in the autoexec (config?) > (I haven't seen DOS 6.0 yet) >2. he ran McAfee scan with the /chkhi option twice (don't ask why) >3. on the second pass it reported the "filler" virus : : >I believe that these false positives are a combination of both the OS and the >BIOS. Huh ? No...it is much more likely that this is just a signature left in memory by another anti-virus program...most of us producing anti-virus software try to be compatible, and not cause false alarms for each other - but there are a few companies that don't give a $#%%$# if their anti-virus program leave virus search strings in memory, which may cause other programs to produce false positives....this is starting to go on my nerves...I just hope they get at least as many support calls because of this as I do. Ah, well....back to work... :-) - -frisk - -- Fridrik Skulason Frisk Software International phone: +354-1-694749 Author of F-PROT E-mail: frisk@complex.is fax: +354-1-28801 ------------------------------ Date: Tue, 20 Apr 93 11:52:10 -0400 From: James Ford Subject: New files on risc (PC) The following files have been uploaded to risc.ua.edu (130.160.4.7) in the directory /pub/ibm-antivirus. tbav600.zip tbavx600.zip Description follows: - ----------------------------------------------------------- A new version of the ThunderByte antivirus utilities has appeared, some major modifications are involved, including the fact that it has its own virus signatures now. This to replace the old tbav5xx files (the vsig9303 file is still useful for htscan19, or for build-it-yourself things perhaps). Validate info on the new .zips follows; the "x" version has processor optimized executables for registered users only (I'm not sure you'd want that, but it's not that big); oh, and it needs the new pkunzip v2.04. _filename_ _size_ _date_ _v1_ _v2_ tbav600.zip 267,999 4-15-1993 832E 0C0D tbavx600.zip 75,811 4-15-1993 2E51 12B5 ------------------------------ End of VIRUS-L Digest [Volume 6 Issue 68] ***************************************** Downloaded From P-80 International Information Systems 304-744-2253