VIRUS-L Digest Thursday, 28 Mar 1991 Volume 4 : Issue 49 Today's Topics: Re: Virus naming Re:Mutation of Stoned/Implications for self check boot sectors(PC) STONED Problems (PC) Re: Unknown virus help! (PC) Re: Integrity Checking, programs & system Re: FPROT vs SCAN (PC) WANTED: Best way to protect laboratory PC/XT & PC/AT clones? (PC) WHALE virus (PC) Azusa (PC) VPCScan Demo Version (PC) Stoned (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: Wed, 27 Mar 91 09:52:00 +1200 >From: "Mark Aitchison, U of Canty; Physics" Subject: Re: Virus naming CHESS@YKTVMV.BITNET (David.M.Chess) writes: > The trouble with hash codes, or dates, or anything else semi-automatic > is that, when there get to be enough of them, the names start to > become useless. At IBM, we tried to use number-names whenever > possible early on, but the disadvantages became apparent after not too > long. If there's a 453 and a 435 virus, for instance, it's Real Hard > to remember which is which! I agree, but there are two reasons for a virus name: (1) To indicate in "human-friendly" terms roughly what it is, and (2) To positively identify which virus it is. In the first case, you usually aren't concerned if it is a slight modification of a well known virus (so long as it does the same things), and it is nice if there are just a few, easily pronounced names to remember. To start with, that is what we had. Now, the system is breaking down because there are so many, often minor modifications, and a lack of communication or standardisation by anti-virus workers. Having a lot of easy-to-remember but incorrectly applied virus names is worse than useless. Hence my suggestion for a change. Ideally, there should be a method of identification, given nothing but the virus itself. So if people over the other side of the world also find the same virus, you can definately say "yes, this is the same virus" without having to send a copy of the whole thing. It would be nice if such a method for positive identification also helped with an easily remembered name as well. Well, that is possible (e.g. with my CHECKOUT program), and it partly involves the "family plus number" method you mentioned. This is how it works... You create a hashcode that consists of two parts (see my BOOTID program), one part has bit-flags that identify certain good and bad things the boot code is doing. Similar viruses get similar codes here. If you can't be bothered working out what this part of the code means, the CHECKOUT program has an option that explains it all in English. The other part of the code is a seemingly-random code derived from the bytes in the boot sector. Two viruses that are similar but slightly different will get totally different codes, so this part is of little use to us humans. But the total code can be used to look up a list of known good and bad boot sectors. This would have a "popular name", that hopefully is assigned carefully, perhaps by one person or organisation. So, if it is a known virus, you get two things, the hashcode plus a sensible name. If it isn't in the list of known viruses, you just get a hashcode, the last 3 characters of which I, at least, find easy to identify the basic type of virus from at first glance. Now, this hasn't been extended to other types of virus yet, but I have a plan in mind, which puts more emphasis on what the virus does, and less on the code it uses to get there, but it is still determined only from the contents of the virus, rather than some obscure historical fact that gave it a name. As I have said, there is still a place for "family" or "generic" names for viruses, *but* it should be a lot more organised than at present, otherwise there will be more and more cases of confusion - which can be dangerous since some variations of some viruses have to be handled very differently. By the way, BOOTID and CHECKOUT are both free from cantva.canterbury.ac.nz, 132.181.30.3, in the pc subdirectory. There will be a new version released within the next week, with better analysis facilities in the CHECKOUT program, and a slight change to hashcodes produced by both programs, to allow for some types of good (e.g. "virus-immune") disks that gave "worrying" results. Keep sending suggestions, though! Mark Aitchison, Physics, University of Canterbury, New Zealand. ------------------------------ Date: Wed, 27 Mar 91 13:14:00 +1200 >From: "Nick FitzGerald" Subject: Re:Mutation of Stoned/Implications for self check boot sectors(PC) In VIRUS-L Digest V4 #47: "David.M.Chess" wrote: >Pat Ralston writes: > >>Table" "Your PC is now Stoned! LEGALISE". Please note that Legalise >>is NOT spelled with a Z as in other versions and is in all uppercase >Now I'm taking an unusual (for me) risk here, as I'm at home with the >tail end of a nasty cold, and can't verify it, but I'm Pretty Sure >that the standard normal everyday Stoned virus spells the word with an >"S" ("LEGALISE"). Yep - originating from New Zealand, where we speak proper English ( 8-) ) the author of Stoned, like most New Zealanders (and probably Aussies and the English themselves), spelled "legalise" with an "s". Pity none of them read the Oxford English Dictionary, or any of the standard references on "correct" English usage (this is a cryptic comment, whose significance will be uncovered by the truly inquisitive - - enjoy). > . . . There are also many cases in which the word >"MARIJUANA" has been overwritten (probably, I am told, by hard disk >controllers that keep some data in an "unused" part of the master boot >record, and overwrite that word in the process). I have seen several copies of Stoned from various machines exhibitting the munged legalise message, and often wondered what may be causing it. I've also seen copies with apparently random bytes in the "free" space between the end of the message and the bootable disk signature bytes. If David is right, however, there are serious implications for the "self- checking boot sector" type schemes that have been discussed here recently. If some HD controllers cavalierly write to what they assume is unused space in the MBR, change-checking boot sectors are going to have a hell of a time. David - are you thinking about the (I think) Zenith machines that write the boot time and date in the MBR each boot up, or do you mean something different? - --------------------------------------------------------------------------- Nick FitzGerald, PC Applications Consultant, CSC, Uni of Canterbury, N.Z. Internet: n.fitzgerald@csc.canterbury.ac.nz Phone: (64)(3) 642-337 ------------------------------ Date: Wed, 27 Mar 91 13:25:00 +1200 >From: "Nick FitzGerald" Subject: STONED Problems (PC) In VIRUS-L Digest V4 #47: Padgett Peterson wrote: > Recently a number of people have mentioned STONED infections >trashing hard disks & think that the following is why. > > Today, nearly every partitioning software aligns the partitions on >even track boundarys for simplicity. Since the Partition Table resides >on track (cyl) 0 head 0 sector 1, the balance of this track is usually >left alone and the first partion starts on the next track. However, >this is just convension and not a requirement. In fact FDISK 1.00 >which came with DOS 2.x began the first partition on track 0 head 0 >sector 2 and has no "hidden" sectors. > > Since DOS version 3.0 came out in 1984, the later convension has >been followed and Norton's DI usually reports 17 "hidden" sectors (all >of track 0 head 0). Whilst Padgett's postings are usually very valuable, the above is a little misleading. Some OEM versions of DOS (some of them still labelled MS DOS) with version numbers 3.0 and above have versions of FDISK that still begin the first partition at 0,0,2 - from memory, I think Falcon DOS 3.1 is one such. This may give a tiny bit more usable disk space, but causes grief after a Stoned strike. > STONED does not bother to check and just copies the original >partition table code to track 0 head 0 sector 7. No problem if this is >a "hidden" sector but disastrous (to DOS) if not. THIS IS REPAIRABLE. > > DOS keep two copies of the FAT (which STONED just overwrote) and >several utilities exist (Norton Disk Doctor is one) that will copy #2 >onto #1 if some utility (like CHKDSK/F) hasn't corrupted the second >copy. It can also be fixed manually by someone with a bit of >experience. Unfortunately, this implies that recovering from Stoned on such a disk is much simpler than it really (usually) is. FAT#2 is not "used" by DOS, in that all DOS file allocation work is done on the basis of FAT#1, but FAT#2 is maintained and updated by DOS. Not knowing exactly how this is done, I just shelled back to DOS and did a bit of FAT editing and file creation/ updating work and discovered that with 3.3 and a 20 Meg HD not all of the FAT is held in memory by DOS (not surprising given that it is about 50 sectors - with floppies I think all of FAT#1 is held in RAM). Any alterations to the file structure are saved to both copies of the FAT, but only the modified sectors are written out to disk. That last point is important - when the FAT is updated not all of FAT#1 is copied to FAT#2, only the changed sectors are copied. What this means for a Stoned HD is that if there has been *NO* file creation, deletion, or updating that affects the area of the disk *near* (sorry, can't be specific) the part of the disk that is mapped by the 6th sector of FAT#1, you can recover from Stoned by copying the sector at 0,0,7 (the original MBR) back to 0,0,1 and then copy the sector in FAT#2 that corresponds to FAT#1's 6th sector back to 0,0,7 (exactly which sector will depend on disk size, and possibly on whether the disk has 12 or 16 bit FAT's). So Padgett's recovery scheme only works if you happen to discover your HD is infected between the actual infection (booting from an infected floppy) and the first attempt to create or update a file, which results in the 6th sector of FAT#1 being updated (at which point the Stoned code is copied to FAT#2). PLEASE NOTE: Whilst the FAT handling is the same, the above advice about disinfecting a Stoned HD *ONLY* applies to disks which were FDISK'ed with an "old" version of DOS - i.e. where FAT#1 starts at the sector after the MBR. On other HD's it is usually just a matter of copying the sector at 0,0,7 back to 0,0,1. > Consequently, I suspect that those experiencing FAT-type problems >had the misfortune to have a drive that was partitioned using "old" >software and then became infected with STONED. Yes, but note my rider above, about what is an "old" version of FDISK. If your HD is defragged then recovery from Stoned on a system prepared with "old" versions of FDISK is simple and relatively straightforward, even if both FAT's do get corrupted. - --------------------------------------------------------------------------- Nick FitzGerald, PC Applications Consultant, CSC, Uni of Canterbury, N.Z. Internet: n.fitzgerald@csc.canterbury.ac.nz Phone: (64)(3) 642-337 ------------------------------ Date: 27 Mar 91 09:50:06 +0000 >From: frisk@rhi.hi.is (Fridrik Skulason) Subject: Re: Unknown virus help! (PC) csg020@cck.coventry.ac.uk (***CURTIS***) writes: >Hello all. > > I have a little problem with my 386 PC. A few days ago I had >the Jeruselem B virus on my machine (it's going ripe round here). II >got rid of it but somehow it kept coming back.... (I know about the >memory resident thingies etc etc) In the end I got rid of it. Hm...maybe I should have replied directly by mail, but there are a few points which might be of interest to other readers of the newsgroup, so... You do not say which scanner you used, but at least I know it is not my own, as it will display a different message when infected. :-) The reason iy "kept coming back.." might be that some program with an extension other than .COM or .EXE was infected, and the scanner only scanned "normal" executable files, not overlay files, for example. Another possibility is that you have an infected file which has been compressed (PKLITE or LZEXE) after being infected, as most scanners will not be able to detect viruses in compressed files. When something like this happens, it is generally advisable to scan all files, just to make sure. >Yesterday, I ran my virus checker from hard disk. It came up with the >warning "Virus checker Infected. Do not use" Three possibilities here - A: The file had been infected and disinfected, but the disinfection might leave 1-15 extra bytes at the end. B: The virus had damaaged the file when infecting it - which happens in <5% of Jerusalem infections - Disinfectin may not be able to detect the damage in all cases. C: The file is just normally infected. >So I ran the write-protected version I had on floppy, No virus's found. This might indicate a hidden virus (overlay, or packed as I mentioned), and just a damaged scanner. >Next I copied the virus checker from floppy to HD and ran it. This clearly indicates you have an active virus in memory at that point - and an infected scanner. As the scanner did not detect any virus, there are two possibilities: A: A new virus - or a lousy scanner :-) B: A "stealth" virus, which the scanner will not find in the files, unless you boot from a "clean" system diskette before scanning. However - it is very unlikely this is a "stealth" virus, as the virus scanner would then probably not have been able to detect any changes to itself. >It, again, said it had been infected. On further investigation I found >that whatever I had was appending itself onto the end of the file, around >10-15K worth. However, the virus only appends to a file once. If you see the file increase happen, you don't have a "stealth" virus, but this is a bit strange as 10-15K in one chunk does not indicate a Jerusalem is involved - actually there are very few viruses in that range, and I suspect a new one - the 40th this month :-( I would strongly suggest sending a sample to the anti-virus people active on comp.virus. >Has anyone out there got a good virus killer (shareware of course!) >that they could arc and mail me?? Well, I have one - I wrote it :-) but I am not sure what is causing your problems - if it is a new virus, my scanner will not be of much help, until I have updated it. If your scanner is just unable to detect the virus, you might try a different scanner, but "10-15K" might indicate a new virus. - -frisk Fridrik Skulason University of Iceland | Technical Editor of the Virus Bulletin (UK) | Reserved for future expansion E-Mail: frisk@rhi.hi.is Fax: 354-1-28801 | ------------------------------ Date: 27 Mar 91 10:21:27 +0000 >From: frisk@rhi.hi.is (Fridrik Skulason) Subject: Re: Integrity Checking, programs & system padgett%tccslr.dnet@uvs1.orl.mmc.com (Padgett Peterson) writes: >> SCAN does have an "internal" self check, but if a "stealth" virus is >>active in memory, it will defeat any kind of integrity check. > >NO ! It will not defeat "any kind of integrity check" though "stealth" >will defeat SCAN's if the /nomem switch is in use (wish we had italics) While >the "stealth" seen so far will defeat a program integrity check, it will NOT >defeat a system integrity check (the six bytes). I don't mean to be insulting, but I have said it before, and I will say it again: The six-byte check is no sustitute for a full system integrity check! Athough it will detect most wiruses, it will NOT detect them all, in particular it will miss some "stealth" viruses, like the "Number of the Beast". The method will also miss viruses like Saddam, Do-Nothing, Micro-128 and all non-resident viruses. Worse, it will "detect" all TRS programs, even programs like PRINT.COM However, my main point is this - it is possible to make a program integrity check which will detect infection by all "stealth" viruses known today, and (I hope) tomorrow's viruses as well. I cannot go into details, but I do have a working program which is able to do this - more details next month. - -frisk ------------------------------ Date: 27 Mar 91 10:38:25 +0000 >From: adlacy%unix2.tcd.ie@BITNET.CC.CMU.EDU Subject: Re: FPROT vs SCAN (PC) I use both F-PROT and the McAfee suite. I used John McAfee's virus s/w for a while before F-PROT. Up till then I had found nothing to beat it. Fridrik Skulason's F-PROT is fantastic. But it has some problems. I use F-DRIVER.SYS as I find it quicker on my XT than VSHIELD (although VSHIELD has the added protection of refusing to warm boot off an infected floppy). However SCAN is better than F-FCHK, as it is much faster. [Note I do NOT know which scans for more viruses] I use F-DISINF to disinfect Boot Sector Viruses...it's faster than clean generally...but I use CLEAN to cleanup file viruses. I also use F-LOCK and F-POPUP to protect against unknown viruses and trojans [as they look out for funny stuff like direct writes to disk, and deleting locked com/exe files..etc.]. I have found a small problem with these unde DESQVIEW v2.3 in that when you tell it shut off for the duration of the running program, they sometimes do just that...or they sometimes shut off for as long as I keep the DOS window open under DV. As I say...a small problem, as if I did suspect something I wouldn't test it Desqview in the first place...and I usually do test EVERYTHING I d/l v. thoroughly before running. cheers, Andy! ------------------------------ Date: 27 Mar 91 11:19:31 +0000 >From: annala@neuro.usc.edu (A J Annala) Subject: WANTED: Best way to protect laboratory PC/XT & PC/AT clones? (PC) We have about 30 IBM PC's (some stand alone two floppy systems, some stand alone hard disk systems, and some connected via DE-100 and 3C501 cards to thick wire ETHERNET) in our laboratory. One investigator found a virus -- yet to be identified on his home computer -- we are now somewhat panic'd & very curious about how best to protect our laboratory computers. We have obatined a copy of McAfee Associated VIRUSCAN Version 6.9V75 from computer center. Is this product adequate protection -- or should we invest in one of the regular commercially distributed products (e.g. Norton stuff)? My background as an old time computer center manager doesn't really help much here. Perhaps someone would be kind enough to offer some general advice. Thanks, AJ Annala ------------------------------ Date: Tue, 26 Mar 91 22:15:55 -0500 >From: stevet@ihlpm.att.com (Stephen E Turpin) Subject: WHALE virus (PC) Does anyone have information or a cure for the WHALE virus? Apparently, it writes a large file to your disk until the disk is unusable. Thanks. Steve Turpin ------------------------------ Date: Wed, 27 Mar 91 11:31:48 -0500 >From: Padgett Peterson Subject: Azusa (PC) It seems that quite a few folks are getting hit by the AZUSA virus. Removing it, while not very difficult, is complicated by the fact that the virus has completely overwritten the master boot record code so that the original cannot be simply retrieved from another location as with most such viruses (STONED, JOSHI, etc). Since the virus has also overwritten the ASCII warning messages, simple patching of the virus code to remove the infection is not a good solution. The virus does contain the essential partition table information from the uninfected code in the proper offset (BE - FD) so removal of the virus requires the following steps: 1) Obtain a "good" master boot record from the same DOS version or higher. 2) Cold boot the infected machine from a write protected floppy 3) Extract the partition table information from the virus 4) Graft the partition table into the uninfected MBR code 5) Overwrite the virus with the composite MBR code. The following assembly language fragment can be used to perform this function. It assumes that a "good" MBR has been loaded into offset 200h-3FFh and that the infected PC has been cold-booted clean. (DEBUG format). MOV AX,0201 ;read a sector MOV BX,0400 ;into offset 400h-5FFh MOV CX,0001 ;MBR MOV DX,0080 ;fixed disk INT 13 CMP WORD PTR [03FE],AA55 ;make sure it was read JZ 0118 JMP 013C ;exit with ERRORLEVEL if not PUSH CS ;align segment registers (0118) POP DS PUSH DS POP ES MOV SI,05BE ;point si & di at table areas MOV DI,03BE MOV CX,0020 ;40 bytes = 20 words REPZ MOVSW ;put table into clean MBR MOV AX,0301 ;write one sector (0127) MOV BX,0200 ;from the "good" area MOV CX,0001 ;to MBR MOV DX,0080 ;of infected disk INT 13 ;we could read it before so JB 0127 ;try again on failure MOV AX,4C00 ;exit ERRORLEVEL zero (pass) INT 21 MOV AX,4C01 ;exit ERRORLEVEL one (fail) (013C) INT 21 Padgett ps - fiddling at this level is not for the inexperienced, caveat y'all. ------------------------------ Date: Wed, 27 Mar 91 11:49:57 -0700 >From: Chris McDonald Subject: VPCScan Demo Version (PC) As a registered user of Ross Greenberg's program Flu-Shot+, I received a demonstration version of VPCScan of the commercial program Virex-PC bundled within version 1.8 of Flu-Shot+. I used the demonstration for several days, and then purchased the full commercial product. Since I routinely evaluate security-related software products for my agency, I had occasion to run the demonstration version on Tuesday, 26 March since I wanted to compare its feature against the actual commercial product. I received the following message prior to the execution of the demo: "This demonstration expires in 6 days." This morning I ran the demo again, and the counter was down to "5 days". I am waiting with anticipation to see what happens on April 1st. I must note that the read.me file contained within Flu-Shot+ which described the demo at no time indicated a shelf life. In fact, the file states: "This demo may be distributed freely, but may not be sold without the express written permission of Microcom, Inc. and Ross M. Greenberg." I have no objection to someone offering a demo, or in encouraging that someone "freely" distribute it under the vendor's instructions. I would think that it sure would have been nice to have included some type of statement in the read.me file alerting REGISTERED, fee paying customers of Flu-Shot+ of the demo's expiration date--particularly when it appears April 1st is the drop-dead date. Since I know Ross has access to this forum, I would simply like to ask if this was a designed feature on his and Microcom's part, or whether I perhaps have a "hacked" version of Flu-Shot+. Chris Mc Donald cmcdonald@wsmr-simtel20.army.mil ------------------------------ Date: Wed, 27 Mar 91 15:17:47 -0500 >From: Padgett Peterson Subject: Stoned (PC) >From: Pat Ralston >Subject: Mutation (or not) of Stoned (PC) >Stoned can be found on floppy disks but not the hard disk. There appear to be two cases in which the STONED will not infect a hard disk: one has to do with an internal variable in the virus (offset 8). The second is if the first four bytes of the master boot record (absolute sector one) match those of the virus (EA 05 00 C0). In this case, the virus "thinks" that the disk is already infected. I have heard of several "vaccines" that perform this function. The dangerous part is that the virus still goes resident in such a machine and while it will not infect the fixed disk, it will infect floppies presented to it. (some variants only 360k, some anything). At least the STONED is easy to detect/get rid of. Padgett (we also walk dogs) ------------------------------ End of VIRUS-L Digest [Volume 4 Issue 49] ***************************************** Downloaded From P-80 International Information Systems 304-744-2253