From: Kenneth R. van Wyk (The Moderator) Errors-To: krvw@CERT.SEI.CMU.EDU To: VIRUS-L@IBM1.CC.LEHIGH.EDU Path: cert.sei.cmu.edu!krvw Subject: VIRUS-L Digest V3 #131 Reply-To: VIRUS-L@IBM1.CC.LEHIGH.EDU -------- VIRUS-L Digest Thursday, 26 Jul 1990 Volume 3 : Issue 131 Today's Topics: 639k, 4096, detection, etc (PC & General) Update on previous posting Diskettes w/o DOS Executable Files (PC) Re: Problems running Disinfectant 2.0! (Mac) Re: LaserWriter virus? Re: We have been hit!!! (Help) (4096) (PC) Dangerous removal programs Re: 4K virus (PC) Stoned Virus Clear (PC) Re: Outsmarting checksums Preliminary analysis of a PC Today diskette (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 LEHIIBM1.BITNET for 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: Tue, 24 Jul 90 23:16:59 -0400 From: padgett%tccslr.dnet@uvs1.orl.mmc.com (A. Padgett Peterson) Subject: 639k, 4096, detection, etc (PC & General) Have been absent for a while as a result of vacation followed by acute bronchitis (still recovering so possibly a bit incoherant - sorry) but do have a few comments to make. 639K: I saw this first in early 1989 on a Compaq 386/20. Turned out that in the "as shipped" condition the manufacturer allocated 1k at TOM to a "mouse buffer" & was essentially null-filled (also changing a jumper on the mother board would restore it to the user). Since then several other uses for that last k of memory have surfaced, few of which are adeqately documented. Though of course it is feasible, I have not yet seen a virus that just uses 1k. For example, the BRAIN reduces memory by 7K (a 640k machine drops the TOM from 280h segments to 279h or 633k. Differences in reporting memory: Essentially there are two ways of reporting memory. The original is to use either Int 12h or locations 0:413h & 414h to report total DOS RAM available in segments (280h for 640k). The other common method is to use Int 21h Fn 48 (Allocate memory) with FFFFh in Bx to return available memory. Not all programs prorperly handle the results, particularly when innovative means of avoiding RAM-CRAM are in use. 4096/Stealth Virus: One of the first things I was taught in doctoral work was to "Review the Literature", another was to seek multiple citations. While there has been some confusion concerning multiple names for the same virus (e.g. 1813 vs Jerusalem) the essential charactoristics are what determine a listing. A description of the 4096 appeared in Patricia Hoffman"s VSUM listing in January, 1990. Consequentially, any later quibbling concerning discovery would indicate a lack of research. Further, there has been some mindless denegration of some sources. In my opinion, ANY source may provide some insight, if only in how misconceptions propagate. At the same time, it must be recognized that it takes 10-20 hours per week of reading just to stay current in the field. Virus-L provides a valuable forum for discussion, but I would strongly suggest that participants try to review at least the last six months of discussion before casting stones (but always welcome new ideas). On the authentication vs checksum question, we beat on this fairly heavily a few months ago but two points still stand out: Ultimately viral signature analysis routines are doomed through latency and sheer mass, and simple checksum analysis of existing programs is adequate so long as the algorithm used is unknown. The wide number of anti-virus routines available simply indicates that the "good enough" solution has not yet been found. Personally, I like the approach being used by Enigma-Logic's Virus-Safe that takes a "snapshot" of the system and its files using a machine-unique algorithm to encrypt the signatures. It is the first system I have seen that can be installed & maintained by a non-expert and does not require an administrator. Padgett Peterson, 10 miles North of DisneyWorld. ------------------------------ Date: Tue, 24 Jul 90 23:30:35 -0400 From: padgett%tccslr.dnet@uvs1.orl.mmc.com (A. Padgett Peterson) Subject: Update on previous posting Having just seen the 25 July posting, I see that the 4096 was adequately described on Virus-L in October of last year (I really need to collect my back listings which are scattered on three PCs and a VAX). It just goes to show how quickly this field is changing: a situation which was made possible only by the proliferation of powerful computers and which is trackable only through the use of the same devices globally. (and the Army is investigating viral insertion with radio waves. sheeesh.) Padgett - 10 miles North of DisneyWorld. ------------------------------ Date: 25 Jul 90 16:14:22 -0400 From: Steve Albrecht <70033.1271@CompuServe.COM> Subject: Diskettes w/o DOS Executable Files (PC) Concerning the spread of viruses from diskettes which contain no DOS executable files, e.g., *.EXE, *.COM, *.SYS, and *.BAT files, I understand that the only ways that a virus can spread from this diskette is if (1) a boot track, or partition table virus, is present, and the computer is booted from this diskette, (2) executable virus code is contained under the guise of a data or text file, and is renamed to a *.EXE, *.COM, or other such executable file and subsequently executed, (3) executable virus code is hidden in a WordPerfect, 123, or other macro. Am I correct in my understanding? Thanks in advance for any assistance. Steve Albrecht MIS Field Services PLAN International 70033,1271@compuserve.com ------------------------------ Date: 25 Jul 90 22:10:32 +0000 From: t1f4387@venus.tamu.edu (Farlow, T. Michael) Subject: Re: Problems running Disinfectant 2.0! (Mac) GREVE@wharton.upenn.edu (Michael Greve) writes... > First off I want to thank the people who responded to my plea for > help with the 4096 virus. Things are under control now. I have another > problem though. I've downloaded Disinfectant 2.0 and cannot use the > help function on my machine. I have an SE/30 with 4mb of memory. The > program will scan and disinfect fine but when you try to call up help > the machine freezes and I have to re-boot. I have many INIT's, CDEV's > and DA's in my system folder. Could these be causing this? I also CV: mmmmm...could be the problem... > have a startup screen and various other things in my system folder. > > Does anybody know of anything that could cause this. It works fine > on other machines so I know it has to be my computer. I have so much > going on in the system folder I don't know (or have time) to remove > things one by one to test them. Any help will be appreciated. If it's controlling your inits/cdevs that you want, let me tell you about the Init CDEV 3.0 written by Jon Rotenstein. when starting up, hold down the space bar and you will be presented with a dialog box containing a scrolling field with most of your inits and cdevs. The ones that are hi-lited are the ones that will load into your system heap. You can even specify if this is to be temporary or a permanent change. Init CDEV is avialble in the sumex-aim.stanford.edu archives. -=-Captain Video \`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\ ` '` '` This intonation of wonderful '` TTTTTTTTTTTTTT '` DISCLAIMER: Just the same thoughts was brought to you '` T TT T '` as DATclaier and DEM- by: '` TT '` claimmers over there. '` A TT M M '` Michael Farlow `88 '` A A TT MM MM '` (Basically, Only I am Texas A&M University '` AAAAA TT M M M '` responsible for what was t1f4387@venus.tamu.edu '` A A TT M M '` said, not my employer) '` '` `\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\ I may be full of sh*t, but at least I am consistently full of the *SAME* sh*t. --Michael Freeman ------------------------------ Date: 26 Jul 90 04:52:18 +0000 From: woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) Subject: Re: LaserWriter virus? swsh@midway.uchicago.edu (Janet M. Swisher) writes: > I have heard in several places that this LaserWriter nasty is a Trojan > horse. If so, that would seem to restrict it to being a Mac problem. > However, nothing that I have seen mentions the name that this Trojan > goes under, so I don't know what to look out for. Could someone with > actual experience with the problem confirm/deny/specify? Well, since Postscript printers are intellegent, (they understand a very complex and rich general purpose programming language,) and every thing sent to them is in actuality a program, the problem knows no boundries. Now, for the problem, (luckily it isn't very widespread, if at all. The original discussion centered on the POSSIBLITY of a Postscript nasty.) The Adobe postscript printers are interpreter driven. Part of the interpreter is called the "server loop". It is written in Postscript (using built in primatives). When you send a job to the printer, it reads the input stream, parses it into tokens and dispatches each token to cause it to execute. It also "wraps" each job with a save/restore context. That is to say, it saves the current state of the VM, executes the job and then restores it. This allow s programs to run without interfering with each other. This also means that each program is discarded when it is through running. In order to downloadl something permantly (until power-off) into the machine, such as a header or preamble, you have to escape the save/restore context. The mechanism to do this, is the keyword exitserver. exitserver takes as one parameter, a password. This password is compared with a password stored int the eeprom, and if they match, the exit takes place, and whatever comes down the line until a ^D (EOF), will be stored in memory "under the server, outside of the save and restore". The server is then restarted and the code that was loaded sets there regardless of the save/restore wrapping by the server. The default password is 0. Many applications will attempt to download a preamble, or perhaps a font or 2 and put them "under the server". If the password is not what the application expects, it will fail to work (the preamble will get thrown away). Generaly, people don't mess with the password. Adobe provides a mechanism to set the password, IF you know the old one. It imposes a 1 second delay for each attempt at changing the password. On a network, people typicaly will set the password for each printer to some other one than the default. Then modify the application to issue the correct password. This prevents an unwanted application from downloading preambles. Since almost all of the postscript operators can be redifined, preambles give you a way to drasticaly alter the operation of the printer. For example, you can change the definition of showpage (the command that causes the page to be emmited) to do most anything, including printing things on the page, etc etc. For this reason, generaly on networks the password gets changed. Now, suppose someone comes along with a routine called writeeprom that writes an arbitryary byte to a location in theeeprom. They can now write to the locations that control the password, regardless of what it is and change it. If you forget the password, Apple at least, will reset it for $600.00!!!!! You have to send your board in. Needless to say, you can cost a place a pile of money real fast, not to mention lost time by messing the passwords up. ANY postscript program can change the password using the built in operator, and ANY postscript program can change the password using writeeprom. writeeprom is what My resetter uses to do it's work, and that is why I have restricted acess to it. Well, sorry for the longwinded post. Hope that this helps. If your applications suddenly quit working, check the password out. It may have changed. The suppliment for your printer will detail how it is dne. Cheers Woody Baker Rt.1 Box I Manor, Tx. 78653 ------------------------------ Date: Thu, 26 Jul 90 09:13:19 +0700 From: David de Leeuw Subject: Re: We have been hit!!! (Help) (4096) (PC) Michael Greve writes: >Subject: We've been hit!!! Help! (4096 VIRUS) (PC) > > This afternoon we discovered that two of the machines in our lab have > the 4096 virus on them. One of the people in our office was installing > new software on the hardrives of the lab machines. The machines are > protected with disk manager. The install was going fine until she > reached one certain machine. When she tried booting off her disk > manager disk, it started the booting process then wouldn't read the > disk. When she tried booting without the bootdisk it came back with > "Insert system disk into drive and press any key to continue". The > machine will no longer work. This happened with two machines. When > she tried to check the her disk on a machine in the consulting office > it ruined that one. At that point I ran SCANV62 on the disks she > had been using that day and sure enough every executable file has > 4096 on it. We think that since the disk she was using was just created > on a clean machine (we assume) that she picked it up on a lab machine. > Either way we now have three machines that no longer boot up. > > I've created a fresh, clean boot disk and tried booting up with it. > All three get to the A prompt but only one will recognize the C: drive. > On that one, every .exe or .com file was infected. > Does anybody have any info on what we can do? How can we get these > machines working again and how can we get rid of this virus? What's > the best way to handle this. Can anybody give me any info on this > virus? Does it normally cause the machine to no longer boot? Any > help would be greatly appreciated. How come diskmanager didn't > stop this virus? I don't know disk manager that well! > Thank you for any assistance. >Michael Greve >University of Pa. >The Wharton School >greve@wharton.upenn.edu Dear Michael, Here are answers based on my struggles with 4096. 1. Disk Manager will do nothing to protect against viruses. DM is a disk initializer, partitioner etc but is not a watch dog for any attacks. 2. The boot-sector does get attacked by 4096. (John McAfee's Virlist says it does not.) 3. All executables and coms get infected, my suspision is that a file checker which is infected spreads the virus to all files, even those not run. 4. Backuping after you noticed the virus to reformat the disk is useless because the restore brings the virus back. 5. We used two antiviruses. Ran them a number of times. TNTVIRUS got stuck on one of the computers because of a weird hidden directory and could not get to the subdirectories. Unvirus ran alright. TNTVIRUS is a very smart program. Both protect against a wide range of viruses including this 4096 (1000 Years, Frodo, IDF etc.) TNTVIRUS : (For U.S.A.) PepCo New Yersey phone 201-9455751 fax 201-9459029 [yesterdays newspaper here states that the City of New York decided to use this program for its 1400 pcs after testing 14 anti-virus checkers] UNVIRUS 10 PF1 114 Derech P.Tikva Tel Aviv Israel phone 972-3-5617175 972-3-5622930 (Unvirus 9 was freeware, not completely effective against 4096..) These antiviruses cleaned up the files from antiviruses without causing any damage to executables. 6. Restoring the boot sector: Prepare a DOS diskette from an absolutely clean computer and copy SYS.COM to it. WRITE-PROTECT it! (take care that the DOS version is compatible with the DOS on the hard disk) Boot from A: and run SYS C: Now immediately run antiviruses from diskette again on the hard disk. Also copy COMMAND.COM from the diskette to C: to make sure. The SYS program did not work at first in a few cases. Running SYS and antiviruses a few times we got it to work. 7. It is very likely the disk will be reinfested a number of times. Likely most diskettes around will be infected too so bring back the virus. Another source might be the ZIP, ARC, LZH etc compressed files with executables in them. Most antiviruses won't see those programs. Apparently some can be run from SHEZ to check archives as well. [On the other hand: storing infrequently used executables in an archive will protect them against future attacks!] 8. Protecting against attack. We installed the BOOTCHEK program. (Shareware in the US, Freeware abroad) available from SIMTEL20 and TRICKLE. This will prevent any changes in the boot at startup of the computer. It also checks itself and as the first program run (after COMMAND.COM) will warn you immediately if the virus struck again. BOOTCHEK is not a resident program, does not take memory and does the job very well. 9. Be very careful not to spread the virus further. Check all the diskettes with UNVIRUS and/or TNTVIRUS (or other antiviruses) Our computers which are fairly public (a number of users) got attacked repeatedly. My homecomputer stayed clean all the way. Success, David de Leeuw Ben Gurion University of the Negev Beer Sheva Israel [and lots of disclaimers apply ...] ------------------------------ Date: Thu, 26 Jul 90 11:03:41 +0600 From: mweiner@bene.at (Michael Weiner) Subject: Dangerous removal programs Fridrik Skulason (frisk@rhi.hi.is) wrote: > Well, how are we then supposed to disinfect files ? > Just replacing infected > programs with originals may be preferable, and even > necessary in three or > four cases, where the virus destroys the original > program, but the originals > are not always available. We can use a two-stage approach: 1 Use a signature to determine whether the (known) virus CAN be in an individual file. 2 If the signature is found, verify the presence of the virus by using a range-checksum calulation. Range/Checksum information consists of two parts: Entries that define the location of static code in an infected program and checksumming information that indicates which values have to result from the calculation over the defined range if it is a virus. Granted: It looks complicated - but in my opinion it's the only way to play it safe. As an example, let's assume a 'primitive' post-attach COM-file infector: J|CCCCCCCCCCCCCCCC|VVVVVVVVVVVVVVVVVV I I I I Infection host Virus code I JMP to beginning of virus code Step 1: Signature detection *** J|CCCCCCCCCCCCCCCC|VVVVVVVVVVVVVVVVVV *** Signature found Step 2: Verification using checksum calculations ****************** J|CCCCCCCCCCCCCCCC|VVVVVVVVVVVVVVVVVV ****************** Checksumming range Individual bytes of byte fields can be excepted from the calculation range (for counters, storage areas, DTAs and other non-static portions). E.g.Checksum = 1234ABCDh -->> matches virus entry -->> infection can be assumed -->> no risk when removing Checksum = 61A2DAE1h -->> does not match entry -->> Either: - Imitation - Virus scanner - New derivate = NO AUTOMATIC REMOVAL > Suppose that a virus just overwrites > the first 3 bytes of a .COM > file with a JMP to the virus code > and restores the original code with > the following sequence of instructions. > > MOV BX,100H ; beginning of program > MOV AX,[SI+357] ; location of original data > MOV [BX],AX ; restore first two bytes > MOV AL,[SI+359] ; get third byte > MOV [BX+2],AL ; and restore it > > A disinfection program may check if this code fragment > is indeed present at > a specific location, and if so, the original 3 bytes > can savely be written > back to the beginning of the file. I disagree, because I am convinced we will see viruses that carry routines such as the above as UNUSED DATA in their 'body' to fool detection programs and to cause even more damage. PPS: What about XOR [SI+357],AX twice somewhere else in a yet unknown derivate of the virus :-( > >Perfect agreement with that - but it could even get worse: Imagine > >virus derivates deliberately placing JMPs to killer code within their > >body at the location where a recovery program expects the original > >start of the program. > > As soon as this happened, the virus would probably be > sent to the author of > the anti-virus program, who could then update his > program to deal with the > new virus. After all, new versions of anti-virus > programs get distributed a > lot faster than new virus variants. I hope you are right, but I am not as optimistic as you are. Removal programs have to provide a reasonable amount of safety to their user. Hoping "that SCAN (or whatever) knows anyway" is not enough (at least for my part). This is a loophole we can and should shut. > Anti-virus programs are always changing, and as long > as we have several > popular programs, it is impractical to attack them all > in this way. If a virus-writer reverse-engineered CLEAN... :-( > This is becoming more and more difficult, as the > number of self-modifying, > encrypting viruses increases. It seems this group now > includes four viruses, > Stealth (1260), V-101, Suomi (1008) and Flip. I was > not even able to produce a > 16-byte identification string for the Virus bulletin > in those cases, without > using "don't care" characters. Granted. I think we all agree that algorithmic methods have to be used to identify self-modifying and encrypting viruses. Let's hope for a virus-free future... Waiting for criticism, Michael [sorry for the lenth of this messages...] +------------------------------------------------------------+ I UUCP: mweiner@bene.at I I Internet: mweiner@f23.z2.FIDONET.ORG Voice ++43 1 8232400 I I Michael Weiner -- Ghelengasse 4 -- A-1130 Wien -- Austria I +------------------------------------------------------------+ ------------------------------ Date: Thu, 26 Jul 90 13:05:49 +0300 From: Y. Radai Subject: Re: 4K virus (PC) Hank Nussbacher writes, concerning the 4K virus: >I would be interested in more details as to why it is called the IDF virus. >I have never heard about it here in Israel. Well, as I wrote in Issue 120, > (Judging from the fact that >one of its many nicknames is "IDF", it was presumably first discovered >in the Israel Defense Forces.) It sounds to me like that answered your question. The only thing I can add is that that name was given to it by the Iris Co. in Tel Aviv. If you've never heard of it in Israel, either you don't have it in your particular area (in which case you're lucky), or you *do* have it and don't *know* you've got it! I suggest you get a copy of UnVirus or similar program as soon as possible in order to find out which of these is correct. Y. Radai Hebrew Univ. of Jerusalem, Israel RADAI1@HBUNOS.BITNET RADAI@HUJIVMS.BITNET ------------------------------ Date: 26 Jul 90 16:31:55 From: Yavuz Selim KOMUR Subject: Stoned Virus Clear (PC) Hello Virus networker. We have Stoned virus in PC. How I clear virus it from partion table I tried to format hard disk two times, but I couldn't successfull . Thank for your comments. Yavuz. ------------------------------ Date: 26 Jul 90 16:02:17 +0000 From: ewiles@netxcom.DHL.COM (Edwin Wiles) Subject: Re: Outsmarting checksums T530083@UNIVSCVM.CSD.SCAROLINA.EDU (Dmitri Schoeman) writes: >If the anti virus programs would first perform a checksum, then >couldn't a virus "outsmart" that program by just changing one (non >executiong) byte in it's source? > >- -----Dmitri Schoeman The problem with this is that most viri must be fairly small in size to have a reasonable chance of going undetected. A virus capable of regenerating the checksum would have to A) know where the checksum was being stored, B) know how the checksum was calculated, C) have the same checksum calculating code within itself, and D) have a sufficient number of "non-executing" bytes imbedded within itself to make whatever adjustment was necessary to the checksum (I'm not sure one is sufficient). Using something like "snefru" (a checksum calculator that apparently generates a very large and reliable checksum) would make this virtually impossible. The virus would be almost the same size as the "snefru" program itself! The "snefru" program that I have here is over 27K. Don't ask me for SNEFRU, it was posted in either comp.sources.misc or comp.sources.unix within this year. Go check either those groups or your local archiving site(s). I WILL IGNORE ANY SNEFRU REQUESTS! - -- Edwin Wiles. ------------------------------ Date: 26 Jul 90 11:48:58 -0400 From: "David.M.Chess" Subject: Preliminary analysis of a PC Today diskette (PC) Summary - ------- The net result of our analysis of a copy of the PC Today diskette is that it does -not- contain a working copy of the Disk Killer virus. Provisos - -------- The following is based on analysis of a 5.25" diskette that was sent to us (electronically, as a diskette image) from the UK. The originally diskette was received with a copy of the August issue of PC Today magazine, published by Database Publications Ltd. in the UK. It contains a program called PCSTORY.EXE (PC TODAY DISK LIBRARY, VOLUME 3, AUGUST '90) which runs a ShareWare program called PowerMenu. (The diskette doesn't seem to have been designed to be booted from, so it's unlikely that too many people will be affected, *whatever* booting from it turns out to actually do.) We have done a bit of long-distance testing over the telephone which indicates that the diskette from which the image was made has the same properties as the diskette that we created from the image. When we receive one of the original diskettes, we will confirm this. We will also be checking that all of the diskettes we receive are the same. 3.5" diskettes were also distributed to some subscribers of the magazine. At least one of these has been scanned with the IBM Virus Scanning Program and does not appear to be infected. We will verify this when we receive one of the original 3.5" diskettes. Analysis - -------- The boot record part of the virus is there, in the boot record, but the rest of the virus (which, on floppies, is normally stored in three clusters marked "bad" in the FAT) is not there. The diskette does contain three "bad" clusters (containing five "bad" sectors), but those clusters don't seem to contain anything at all (they are full of hex "F6" bytes, which is what the FORMAT command writes when it initializes a disk). The pointer in the boot record part of the virus, which is supposed to point to the three bad clusters, in fact points somewhere else entirely (to a point on the disk that contains part of a file). The effect of this is that when the disk is booted from, it reads in essentially random junk, and passes control to it. A machine booted from the disk will generally hang, go into Cassette BASIC, or otherwise malfunction. We searched the diskette (using the Norton Utilities(tm)), and the string "iller", which occurs in the non-boot-sector part of the virus, does not occur anywhere on the disk. We also tried booting from the diskette several times, and it never booted successfully, nor did the hard disk in the machine become infected. Since the boot sector is in fact the boot sector from the virus, most virus scanning programs (all that we know of) that detect the Disk Killer on diskettes will report that the diskette is infected (since they all examine only the boot sector). In particular, the IBM Virus Scanning Program will report that it is infected. Nonetheless, the full virus is not present on the diskette and it will not spread. Dave Chess, Bill Arnold, Steve White High Integrity Computing Laboratory IBM Thomas J. Watson Research Center ------------------------------ End of VIRUS-L Digest [Volume 3 Issue 131] ******************************************