VIRUS-L Digest Friday, 20 Sep 1991 Volume 4 : Issue 168 Today's Topics: Re: Boot sectors (PC) Re: Mutant viruses (PC) Re: Scanning LZEXE and PKLITE files (PC) Re: FAT Infection and sundry flames/comments (PC) bogus scan?? (PC) New virus? (PC) Re: FAT Infection (PC) Norton Anti-Virus 1.5 (PC) re: Students and viruses Re: Boot sectors (PC) Re: FAT Infection (PC) Boot sequence part 2 (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. Please sign submissions with your real name. Send contributions to VIRUS-L@IBM1.CC.LEHIGH.EDU (that's equivalent to VIRUS-L at LEHIIBM1 for you BITNET folks). Information on accessing anti-virus, documentation, and back-issue archives is distributed periodically on the list. Administrative mail (comments, suggestions, and so forth) should be sent to me at: krvw@CERT.SEI.CMU.EDU. Ken van Wyk ---------------------------------------------------------------------- Date: 20 Sep 91 09:00:05 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Boot sectors (PC) grdo@botik.yaroslavl.su (Gryaznov Dmitry O.) writes: > Tracing has its own drawbacks - there are several nice methods to avoid > tracing. For instance? Are they as safe? > >2) It is possible (in theory) to design a virus which particularly > >attacks this protection scheme - i.e., tries to find the file where > >the original contents of the boot sector is, intercepts the program at > >the point where the user is notified, prevents the system to be > >rebooted, etc. All this could be made difficult enough but requires a > >good amount of programming. > Let this file be named by user or use just a random name during > installation. Of course, I assumed this by default. I had in mind the following attacks: 1) Search all files on the disk that contain something like a boot sector or other characteristic parts, if the format of the datafile is known. Could be stopped by encrypting the file with a user-selctable password. 2) Wait until the message is displayed (by watching INT 10h or directly the video RAM) and kill the current process. Could be stopped by disableing all interrupts when displaying the message and writing the message directly in the video RAM. 3) Similarly to 2), but wait until the program asks the user for confirmation and supply it with wrong input. Can be stopped if the original keyboard interrupt is also traced & saved or if the keyboard is polled directly, or if the user is given no choice but to reboot. 4) Etc.... :-) As I said, all these could be stopped, or at least made so difficult to implement, that the average virus writer probably won't try to; it just requires a good amount of programming. It is possible however, that's why I don't consider the boot sector infectors as a major threat. > But I wrote: > >> ... restore the contents of interrupt vectors area > >> just before booting DOS - virus will lost control. Agreed, that's a point to install the program in the boot sector, instead of having it as a standalone program. But I don't like to mess with the boot sector - it's too dirty. :-) > Yes. This person was A.Sessa from Dniepropetrovsk, Ukraine. He > suggested this idea last November at All-Union Anti-Virus Conference > in Kiev. You were there. Me too. Nice to meet you again, then... :-) > >1) Is the Bulgarian virus Dir II already spread there? (It is a virus > >that cross-links all COM and EXE files to the last disk cluster.) I > >received a report that it is already spread in Poland, so I'm just > >wondering... (To all the others: I'll publish soon a detailed > >description of this virus.) > Yes, it is. I didn't know this virus came from Bulgaria. Don't you > know the author? Damn! :-( Yes, I know its authorS personally. Two kids - pupils at the Mathematical Highschool in Varna. They are also the authors of Shake, MG, and the first Dir viruses. They continue to write viruses and to release them "for fun". :-(( > This August a lot of PCs were infected at WDNH in Moscow (main Soviet > exhibition) with this virus. So it is spread all over the USSR now. Damn and damn... :-(((( > There are already several Soviet disinfectors available. > Once again: is it meaningfull to PUBLISH a DETAILED description of > a virus? Will it not encourage new virus-writers? Maybe it is worth Since the virus is already widespread, any virus writer who needs a copy, will finish getting it... And it's better to warn the rest of the users to be prepared. > to organize a special E-mail anti-virus conference not so opened > as VIRUS-L/comp.virus for exchanging such an info and viruses among > anti-virus specialists. This is a good idea and preparations for such thing are under way (the CARO group & the CARO net), but there is a very difficult problem - how to determine whom to trust? > >2) Can you (or whoever from the SU reads this) provide us with contact > >with the Soviet anti-virus researcher Bezrukov, Nikolaj Nikolaevitch? > >He lives in Kiev and has published a book on computer viruses. I know > >his snail-mail address, but could anyone provide him with e-mail > >contact? > I have Bezrukov's E-mail address: bnn@softp.kiev.ua . I sent a So, SoftPanorama has got a computer and an Internet address? That's good. > message or two to him but got no response. Maybe something is > wrong with this address. That's shame... Have you tried to add .su at the end? Or is Ukraina a separate region in Netland too? Another hint - SoftPanorama was in that institute for avio-engineering. Maybe you have to insert its weird abbreviation somewhere in the address? Could you please try to phone Nikolay Nikolaevitch (his phone was 2681026 the last time I saw him; you should add the appropriate code for Kiev which I don't have handy right now) and ask him about what happens with his e-mail address? Please, ask him to try to e-mail to me. Thakns! Regards, Vesselin - -- Vesselin Vladimirov Bontchev Universitaet Hamburg, FB Informatik - AGN Bontchev@Informatik.Uni-Hamburg.de Schlueterstrasse 70, D-2000 Hamburg 13 New address after October 1, 1991: Vogt-Koelln-Strasse 30, D-2000, Hamburg 54 ------------------------------ Date: 20 Sep 91 09:32:14 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Mutant viruses (PC) grdo@botik.yaroslavl.su (Gryaznov Dmitry O.) writes: > >Which ones? Can you send examples (encrypted please) to the VTC > >Hamburg? We already got a Russian encrypted and mutating virus that is > >currently unknown to the public. It was sent to us by two Russian > >anti-virus researchers who claimed that they have created it in order > >to show that virus scanners are inefective... The so-called Washburn > >approach... :-(( > Can you name these researches? I'll send you personal e-mail about them. > One mutant virus is STARSHIP - it contains encrypted string > ">STARSHIP_1<". It is both MBR and file infector. Uses 4th text video > page - so it doesn't work on PCs with monochrome. When an infected > program is being executed the virus just infects BOOT and doesn't > remain resident. It stays resident when an infected disk is booted. > Infects .EXE and .COM files being copied to floppy. This one seems unknown... Could you provide an example to the VTC? It would be useful too to send a program that can identify most of the Soviet viruses, so we could recognize them when (and if) they spread. Is Lozinsky's program still the best one? > Another one is TEQUILA. Also MBR/file infector. Contains encrypted > strings "Welcome to T.TEQUILA's latest production", "Contact > T.TEQUILA/P.o.Box 543/6312 St'hausen/Switzerland", "Loving thoughts to > L.I.N.D.A.", "BEER and TEQUILA forever!", "Execute: mov ax, FE03 / int > 21. Key to go on!". Infects .COM and .EXE when executed. Oh, we know this one. It's really from Switzerland. It's mutating technique is rather silly; far from the sophisticated tricks used by V2P6... Is Tequla spread in the Soviet Union? > I meant POWERFUL ENOUGH regular expressions. For example, including > variant samples. Did you mean extended (i.e., egrep-style) regular expressions? Or just cloumsy enough regexps? :-) Regards, Vesselin - -- Vesselin Vladimirov Bontchev Universitaet Hamburg, FB Informatik - AGN Bontchev@Informatik.Uni-Hamburg.de Schlueterstrasse 70, D-2000 Hamburg 13 New address after October 1, 1991: Vogt-Koelln-Strasse 30, D-2000, Hamburg 54 ------------------------------ Date: 20 Sep 91 09:43:01 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Scanning LZEXE and PKLITE files (PC) pshuang@ATHENA.MIT.EDU writes: > If you PKLITE an arbitrary executable, *ANYONE* can decompress it with > their copy of PKLITE. Developers who wish to make it less easy for > anyone who may wish to be able to examine their code may register for > a customized copy of PKLITE whose output cannot be decompressed by > end-user PKLITE. This is bad in that even the largest commercial > developers have been known to be inadvertently infected and distribute > infected applications, and if they choose to get the special PKLITE, > we can no longer check the original code ourselves. However, it isn't > easy for malicious virus-writers to insert their virii into such files > at the source -- so I don't think this is much of a concern. Furthermore, it's stupid to claim that files compressed by the customized version of PKLite are unexpandable. They have to be expanded in memory when run, don't they? They're just not expandable to their -exact- (byte by byte) original source. But, of course, the code (which contains the instructions and where the virus hides) -can- be expanded exactly. Besides, Ross Greenberg's VirX scans in such "unexpandable" programs perfectly. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Universitaet Hamburg, FB Informatik - AGN Bontchev@Informatik.Uni-Hamburg.de Schlueterstrasse 70, D-2000 Hamburg 13 New address after October 1, 1991: Vogt-Koelln-Strasse 30, D-2000, Hamburg 54 ------------------------------ Date: Fri, 20 Sep 91 14:25:59 +0000 >From: mrs@netcom.com (Morgan Schweers) Subject: Re: FAT Infection and sundry flames/comments (PC) Some time ago bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) happily mumbled: >moore@iastate.edu (Brian J Moore) writes: > >> >If it overwrites only the first FAT copy, you won't lose anything... >> >and you probably won't even notice that something nasty has happened. > >> Running CHKDSK will tell you if the FATs don't match... > >It won't, if the virus modifies the DPB to indicate that there is only >one FAT copy... If the virus did that, then DOS would have trouble with the disk. I think that it should be pointed out that you cannot INFECT the FAT, but a virus might use it as storage space. The FATs are PURELY data areas. No executable code, therefore no possiblity of infection. On that score, you can relax. There are a *LOT* of delicate features that you can't muck around with too much under DOS, and most of them you don't discover until you've crashed your machine a *LOT*! There is a limited set of areas that can be infected by a virus. Essentially, the files, the MBR and the Boot Sector. The methods used in infecting these can vary *WIDELY*, however. There are some things that viruses have not been written to do yet, thankfully. There are some things that viruses CAN not be written to do, simply because it's impossible. (INFECTING the FAT is one of these.) As a side-slam against viral researchers who write viruses (slamming them is a favorite hobby of mine) they seem to think that the first category (viral methods which haven't been written yet) are a prime candidate for showing off their own technical prowess. Frankly, any viral researcher who writes a virus 'to demonstrate that it can be done' is doing the community a *GREAT* disservice. I am not a proponent of security through obscurity. I believe strongly in 'be prepared for the worst', however I do not believe that one should CREATE the worst, to prepare people for it. (As Mr. Bontchev suggested, that is the Washburn approach.) My colleagues and I commonly brainstorm and talk (privately) about possible new viral technology. We try to come up with ideas that will make each others programs ineffective. The other person (or both of us) come up with ideas on how we would have to handle that sort of problem. Neither one of us would WRITE the things we talk about. *shiver* It's the 'researchers' who don't just *TALK* about this, but *DO* it which worry me. I've been off comp.virus for a while, but I see there's still this thread about 'Virus Simulators' going on. I figure I'll drop in my two cents... I was aghast when I found out that our strings were in it. Just goes to show that the little disclaimers we post at the end of our messages really are true! *grin* Other side comments: Mr. Bontchev mentioned that to his awareness VirX was the only program which scanned inside of PKLite'd files as well as LZEXE'd files... That's not true. McAfee Associates places high import on the ability to scan inside of compressed executables. PKLITE and LZEXE detection have been standard inside our programs for some time now. It's my firm opinion that the virus problem will not go away until the operating system manufacturers move their OS into protected mode, and implement file protection checking in protected mode. This would also, of course, assist in implementing multiprocessing, etc. Now, viruses would still propagate under earlier versions of the OS and earlier processors than the 80386, but it would *STOP* the continual increase of viruses. (With the obvious exception of people who implemented their file protection poorly. But that's a system managment problem.) If Digital Research does it first, and advertises it properly, they could kick a serious hole in Microsoft. If Microsoft does it first, and advertises it properly, they could gain a *LOT* of goodwill in the computer field. Both of them have a lot to gain. The question is when they'll get off their lazy ---es and start WORKING! -- Morgan Schweers - -- mrs@netcom.com | Morgan Schweers | Happiness is the planet Earth in your ms@gnu.ai.mit.edu| These messages | rear view mirror. -- Jeff Glass Kilroy Balore | are not the +-------------------------------------- Freela | opinion of anyone.| I *AM* an AI. I'm not real... ------------------------------ Date: Fri, 20 Sep 91 10:35:00 -0400 >From: HAYES@urvax.urich.edu Subject: bogus scan?? (PC) Hi. I found the following messages this morning in the FIDO echonet virus conference: - ---- begin forwarded messages -- To: Olaf Greve Message #: 4877 3245 4878 >From: Martin Saintonge Submitted: 18 Sep 91 09:22:00 Subject: Number of viruses Status: Public Received: No Group: VIRUS (30) >Well you probably have NOT got it wrong but you probably DO have an >older version of SCAN for version 80 is able to detect some 700 >viruses, I've also read that version 82 (version 81 was probably a >trojan) will be released very soon. >Olaf I've got SCAN version 83 ! I don't think it's a fake, It works fine and all the documentation is authentic. I got it from a friend from Montreal and I verified it and performed a scan on it (with version 72) with no problem. - --- via Silver Xpress V2.27 [NR] * Origin: RAMBAB LE babillard du Haut-Richelieu 347-5983 (1:167/570) - ------ To: Volker Weber Message #: 4993 1204 5013 >From: Paul Ferguson Submitted: 18 Sep 91 20:43:00 Subject: New McAfee's ?? Status: Public Received: No Group: VIRUS (30) * In a message originally to All, Volker Weber said: VW> KH> CLEANBTA.ZIP McAffee Clean Version 8.2 VW> KH> WSCANBTA.ZIP McAffee Scan Version 8.2b / WINDOWS VW> VW>Can anybody verify this? Hmmm... Somethings definitely afoot... McAfee Associates just released their v82 a couple of days ago, but that was definitely not the filenames... Suggest you check with the McAfee rep in your area or contact someone )BBS) that you thoroughly trust... VW> A dog is the only thing on earth that loves you VW> more than he loves himself. VW> - Josh Billings - -- I remember the good old days when computers were mainframes, analysts were magicians, and programmers punched cards. - Paul Ferguson Cheers - --- * Origin: Sentry Net BBS, Centreville, VA 703-815-3244 (1:109/229) - ----- end forwarded messages -- Does anyone on this list know something about either a "windowScan" or a version 83? Best to all, Claude. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Claude Bersano-Hayes HAYES @ URVAX (Vanilla BITNET) University of Richmond hayes@urvax.urich.edu (Bitnet or Internet) Richmond, VA 23173 ------------------------------ Date: Thu, 19 Sep 91 15:52:00 -0500 >From: RONNIE@ECUAFUN.BITNET Subject: New virus? (PC) In reference of an earlier report from my self about a possible new kind of vir us, very faster and lethal, i have no way to isolate the virus because the mach ine that was shoot, was reformatted, i was trying to locate any virus signature within the backups that i have of the machine involved in the attack, but all the atempts were unsuccessful. I begining to suspect that we are dealing with a local-born virus, this may explain the fact that no anti-virus program has not ices about him, and probably is very specific for the SCAN program. I don't known if the virus attachs his code to a .EXE or .COM file or if he can "insert" his code within the file's code. ------------------------------ Date: 19 Sep 91 08:21:27 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: FAT Infection (PC) CCTR132@csc.canterbury.ac.nz (Nick FitzGerald) writes: > At this point there is much potential for confusion. Some BSI/PTI > viruses _affect_ (NOT infect) the FAT. This happens with Stoned and Yes, I know that of course, but I didn't mean that. I didn't neither say that the virus will DESTROY the FAT, nor that it will INFECT it. I said that it will use the first FAT copy (yeah, the first, NOT the second) to hide there the second part of its body (the first being in the boot/master boot sector. > For what Vesellin is hinting at to work, I think what would be needed > as part of the infection process would be a little "byte twiddling" in > the partition table entry for the affected partition and the addition/ > modification of some code in the MBR loader. Well, almost. The "byte twiddling" will be only in the Disk Parameter Table, which is contained in the DOS boot sector (NOT in the MBR). > Yes - but note my warning above. If this was prompted due to > corruption of the FAT by some (Stoned-like or other?) virus, you may > not be able to "repair" the FAT by copying the second copy back on top > of the first. Whether this succeeds or not depends upon many factors To repair the FAT if only one copy is damaged, you have to copy the CORRECT copy over the DAMAGED one (if there are at least two copies, which is the usual case). Particularly with Stoned, the damaged one is the first copy. Unfortunately, DOS sometimes copies the first copy of the FAT over the second one, without careing whether they are equal or not. This, of course, will damage the FATs beyond repair. > >Note however, that it won't help if a virus has been especially > >designed to hide in the first FAT copy - you'll need probably a > >specific disinfector. > Huh - what I'm thinking of would be easily reversible by copying FAT2 > back to FAT1 and fixing the PT entries. Yeah, but what if there is no second FAT copy any more? :-) > Yes of course, because it would have to use some good (as in "well- > implemented") stealth techniques (but wouldn't it then be slightly > simpler to implement using FAT2 as the hiding place instaed of FAT1?). Nope. Well, OK, I'll describe it. It is not a very dangerous idea - it just has not been implemented yet. Someday some hacker will discover it even without my hints. Well, Ken, if you feel that the idea IS dangerous, please delete the following description. In the boot sector of each disk/partition (the DOS boot sector, not the MBR), at offset 0Bh, the following structure (called Disk Parameter Block) can be found: Offset: Length: Comment: 0Bh 2 Number of bytes per sector 0Dh 1 Number of sectors per cluster 0Eh 2 Number of sectors before the first FAT 10h 1 Number of FAT copies 11h 2 Number of 32 byte dir entries in the root directory 13h 2 Total sectors on the disk 15h 1 Media descriptor byte 16h 2 Number of sectors per FAT copy In general, each DOS disk (or partition) consists of (1) reserved sectors (their number is at offset 0Eh), (2) n FAT copies (n can be found at offset 10h) of x sectors each (x can be found at offset 16h), (3) (r * 32 + 511) div 512 sectors for the root directory (r can be found at offset 11h) and (4) data space for files, which begins right after the directory entry. Now consider a boot sector virus, which overwrites the DOS boot sector and places its second part, together with the original contents of the disk over the first FAT copy. It the increases the number at offset 0Eh in the DPB (which indicates the number of reserved sectors before the first FAT copy), so that it includes all the sectors which were previously occupied by the first copy of the FAT (now part or all of them are occupied by the virus). Then, the virus decreases the number at offset 10h in the DPB, to indicate that there is ONE LESS FAT copy. On most systems this will indicate that there is now only one FAT copy (the one which was second before the infection). Everithing seems OK now and neither DOS, nor CHKDSK, nor anybody else will notice something unusuall, since the disk structure is OK, the disk space is not decreased; there is just one less copy of the FAT. Of course, the virus could aslo have stealth capabilities, in order to fool the user even further (e.g., it may report a disk error if the user tries to write on the "reserved" sector, or may indicate that the number of FAT copies is not changed and redirect all FAT accesses to the second copy, but all this is not nessacary (although it will help the virus to spread unnoticed). The above scheme has only a small drawback - DOS usually dosn't use that DPB structure when accessing floppy disks. For instance, the Stoned virus overwrites this structure on the infected diskettes, but they are strill perfectly readable, without the virus being stealth. However, this can also be circumvented. It is sufficient to modify the FAT media description byte (not the one that is in the DPB, since the whole structure is not used, but the media description byte that is contained at offset 0 in the FAT), to 0F8h, which will fool DOS that the diskette is in fact... a hard disk. In this case, DOS will always use the DPB structure. Well, that's all, now we have just to watch for such viruses too... :-(( Note: the idea is not mine, this method has been invented and described to me (although never implemented) by T.P. - the author of the Vacsina/Yankee Doodle viruses. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Universitaet Hamburg, FB Informatik - AGN Bontchev@Informatik.Uni-Hamburg.de Schlueterstrasse 70, D-2000 Hamburg 13 New address after October 1, 1991: Vogt-Koelln-Strasse 30, D-2000, Hamburg 54 ------------------------------ Date: Fri, 20 Sep 91 09:34:17 -0700 >From: bob morales <7340P@NAVPGS.BITNET> Subject: Norton Anti-Virus 1.5 (PC) Hello there! At the risk of sounding "virus illiterate" (of which I am trying to emerge from), I have a question regarding my copy of NAV 1.5. According to the programs Scan Options, I may set it to "Scan Executable Files Only" (or words to that effect) which tells me that virus programs can only be transferred via executable files only, i.e., files ending in .COM, .EXE, or .SYS. My questions are: (1) is this a safe bet? and (2) is my assumption correct? Help me get out of the dark ages. Show me the light! Thanks. Bob Morales 7340P@NAVPGS ------------------------------ Date: Fri, 20 Sep 91 12:52:00 -0400 >From: "Jon Womack (Ext. 2-2141)" Subject: re: Students and viruses LISSA@WHEATNMA.BITNET writes: >It has been my experience that, for as long as I have worked here, >that administrations of colleges try to keep the subject of viruses >low-key. They don't want to worry the students, and they don't want to >admit they have a problem. martin@cs.ualberta.ca (Tim Martin; FSO; Soil Sciences) writes: >Are there any Administrators reading this group, who can explain to me >the logic behind such administrative head-in-the-sandedness? I just wanted to comment on this subject. At the Citadel, approximately 1 week ago, we had a massive infection of the STONED virus. The Software Support people who run our computer labs, IMMEDIATELY tagged all infected computers. They were in the process of evaluating anti-virus packages and selected F-PROT to do the job. Our head of Information Resources, then sent E-Mail to all Faculty and Staff to inform them of the problem with this VIRUS (we have a faculty and staff distribution list). Since then, we have done everything we can to warn the users (faculty, staff and students) of the problem, and disinfecting is well on its way. Naturally, there are still alot of infected diskettes, but but they are identified when the students attempt to use them, and they are required to go to the software support people to disinfect them. Naturally, this has caused us to rethink our virus protection scheme (one bitten twice shy). ;-) We have found in general, that if we keep our users informed of the problems that we encounter and make every effort to learn from those problems, they are much more forgiving and willing to work with us. This head-in-the-sand approach simply won't work! I have been a regular reader of this digest, but this is the first time I have had a chance to comment. Thanks of all the great input and keep it coming! Jon ******************************************************************************** * | What are the three most dangerous things * * Jonathan W. Womack (Jon) | in the world? * * The Citadel | * * (The Military College of SC) | 1) A technician with a program patch. * * Bond Hall Rm. 403 | 2) A programmer with a screw driver. * * Charleston, SC 29409 | 3) A user with an idea. * * (803) 792-2141 | * * | A lack of planning on your part does NOT * * BITNET: WOMACKJ@CITADEL.BITNET | constitute an emergency on my part! * ******************************************************************************** ------------------------------ Date: Fri, 20 Sep 91 15:07:32 +0000 >From: bdh@gsbsun.uchicago.edu (Brian D. Howard) Subject: Re: Boot sectors (PC) grdo@botik.yaroslavl.su writes: >p1@arkham.wimsey.bc.ca (Rob Slade) writes: >> In addition to the psychological advantage, "BSI"s have some >> technical values as well. For one thing, they get the first >> chance at the system, before most "protection" has started. For >> another, a BSI, to be effective at all, must be memory resient. >> For a third, because hy make changes to system areas which are >> not normally seen, te changes are often undetected in normal >> operation. >In fact there is a way to overcome ANY boot sector infector on PC. To >do this it is enough to restore the contents of interrupt vectors area >just before booting DOS - virus will lost control. It is also desired >to set a correct amount of RAM into an appropriate BIOS variable (loc. >0:413H). It is possible to place a necessary program code into a DOS >BOOT sector (not MBR - such a code must be loaded AFTER all possible >Boot sector viruses). Being installed on a virus-free PC such a >program can "remember" the necessary info and then check it and, if >neccessary, restore each time PC is booted. Such an approach was >implemented at least in one program in USSR. >- -- That is the approach that we have been taking here at the U-C. I call it the DELTA approach (Don't Even Let Them Aboard). Of necessity it treats *any* tsr as a virus, but since we run public systems for any student to sit down at and use, its not a bad thing for us if all the machines look the same. - -- Dallas,TX "Where we shoot Presidents and shoot people who shoot Presidents." ------------------------------ Date: Fri, 20 Sep 91 18:10:53 +0300 >From: grdo@botik.yaroslavl.su (Gryaznov Dmitry O.) Subject: Re: FAT Infection (PC) bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes: >moore@iastate.edu (Brian J Moore) writes: > >> >If it overwrites only the first FAT copy, you won't lose anything... >> >and you probably won't even notice that something nasty has happened. > >> Running CHKDSK will tell you if the FATs don't match... > >It won't, if the virus modifies the DPB to indicate that there is only >one FAT copy... If a virus will modify the BPB in such a way, then a start of a root directory and data area will be calculated wrong - file system will be corrupted. Moreover, I experimented with formating a floppy with one FAT copy (using my own program). DOS (3.30) ignored BPB data saying "one FAT copy" and considered there were two of them - so it calculated the start sector of a root wrong and showed a nice picture both with DIR command and Norton Commander. Brian is wrong, of course. CHKDSK will not help because such a virus MUST be stealth - see my previous message on the same subject to the VIRUS-L. - -- Sincerely, Dmitry O. Gryaznov E-mail: grdo@botik.yaroslavl.su or grdo1@node.ias.msk.su Phones: office: (08535)-2-1731, (08535)-2-0715 home:(08535)-2-1465 ------------------------------ Date: Wed, 18 Sep 91 13:45:37 -0700 >From: p1@arkham.wimsey.bc.ca (Rob Slade) Subject: Boot sequence part 2 (PC) FUNBOT3.CVP 910918 Boot sequence - part 2 Obtaining the state of the environment immediately after the boot sector has been run is not as easy as it might sound at first. The computer, while functional, does not have all parts of the operating system installed at this point, and it is the "higher" levels of the operating system that users generally interact with. The last section of the boot sector program points to the files or areas on the disk in which to find the next step of the operating system. At this point the specific files and subsequent steps start to change from one operating system to another. However, it is fairly common for all operating systems to have "hidden" files along this route which may be subject to viral attack. Given that the files are not evident to the user, they are more subject, not to attack, but to an undetected change. When setting up antiviral defences, it is important to know the sequence of events in the boot process in order to know which programs will protect to which level. The MS-DOS sequence provides the clearest example, and those knowledgeable in other systems can use the examples it provides in order to analyze the specific details of their own systems. After the master boot record and boot sector proper have been run, MS-DOS normally runs two additional programs which set up input/output routines and the most basic operating system. (As these programs are called by the boot sector, it is possible to re-route this process to call specialized driver programs first, or with them. Some esoteric disk drives use such a process.) Traditionally, these files have "hidden" attributes and are not visible to the user on the disk. After they have run, the system has sufficient programming to interpret a text file which contains listings of various additional programming which the user wishes to have in order to run specialized hardware. This file, CONFIG.SYS, is the first point at which the intermediate user may normally affect the boot process, and is the first point at which antiviral software may be easily installed. As can be seen, however, there are a number of prior points at which viral programs may gain control of the computer. After the programs listed in CONFIG.SYS are run, the command interpreter is invoked. The standard MS-DOS interpreter is COMMAND.COM, but this may be changed by an entry in the CONFIG.SYS file. After COMMAND.COM is run, the AUTOEXEC.BAT batch file is run, if it exists. AUTOEXEC.BAT is the most commonly created and modified "boot file", and many users, and antiviral program authors, see this as the point at which to intervene. It should be clear by now, however, that many possible points of intervention are open before the AUTOEXEC.BAT is run. In spite of the greater number of entry points, viral programs which attack the programs of the boot sequence are rare, and not greatly successful. For one thing, while very disk has a boot sector, not every disk has a full boot sequence. For another, different versions of a given operating system may have different files in this sequence. (For example, the "hidden" files have different names in MS-DOS, PC-DOS and DR-DOS.) Finally, viral programs which can infect ordinary programs files may not work on boot sequence files, and vice versa. copyright Robert M. Slade, 1991 FUNBOT3.CVP 910918 ============= Vancouver p1@arkham.wimsey.bc.ca | "If you do buy a Institute for Robert_Slade@mtsg.sfu.ca | computer, don't Research into CyberStore | turn it on." User (Datapac 3020 8530 1030)| Richards' 2d Law Security Canada V7K 2G6 | of Data Security ------------------------------ End of VIRUS-L Digest [Volume 4 Issue 168] ****************************************** Downloaded From P-80 International Information Systems 304-744-2253