VIRUS-L Digest Wednesday, 31 Jul 1991 Volume 4 : Issue 133 Today's Topics: Brunnstein (CARO) virus catalog files Re: Exchanging floppies Re: Philosophy, comments & Re: long and technical (PC) Re: Virus Scan V57 and V77. (PC) Dark Avenger (PC) Tequila virus and partition table (PC) Re: High Memory (PC) Multi-compress virues in io.sys (PC) Re: Self-scanning executables (PC) Observation on F-DRIVER.SYS & Windows 3 (PC) CARO and EICAR Re: Philosophy, comments & Re: long and technical (PC) Re: Self-scanning executables (PC) Related Terms 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: Mon, 29 Jul 91 16:32:27 -0400 >From: Kenneth R. van Wyk Subject: Brunnstein (CARO) virus catalog files The files which Dr. Brunnstein announced on 24 July 1991, along with the rest of the virus information files from CARO, are now available on cert.sei.cmu.edu (IP number 192.88.209.5) in the pub/virus-l/docs/brunnstein directory. Please use this archive rather than ftp.informatik.uni-hamburg.de in order to limit the network load to that site. My thanks to the folks at CARO for making this excellent work freely available. Ken Kenneth R. van Wyk Moderator VIRUS-L/comp.virus Technical Coordinator, Computer Emergency Response Team Software Engineering Institute Carnegie Mellon University krvw@CERT.SEI.CMU.EDU (work) ken@OLDALE.PGH.PA.US (home) (412) 268-7090 (CERT 24 hour hotline) ------------------------------ Date: Mon, 29 Jul 91 17:37:42 -0400 >From: Peter Jones Subject: Re: Exchanging floppies On Thu, 11 Jul 91 11:24:58 -0400 you said: >I work in a library in which we have been accepting disks from patrons >in exchange for a formatted disk. They then use those in our CD-ROM >workstations to download. We re-format the disks we receive to use in >the exchange process. To date, we have not had any infections >(acording to virscan and f-prot). My question is this: would we be >better off zapping the disks in the demagnitizer, then formatting? Or I think formatting is enough. However, zapping is a great way to let people know the data are going to be zapped forever. Also, you avoid the problem of a disk slipping past the formatting station without really being re-formatted (if someone is in a hurry and doesn't want to wait for re-formatting). Note that there are high-speed programs for copying/formatting a large number of disks. De-gaussing is also necessary if a DD disk has been accidentally as HD, and you need to format at 2D on an HD drive. Peter Jones (514)-987-3542 Internet:Peter Jones UUCP: ...psuvax1!uqam.bitnet!maint N.B. "Our customers will forgive a one-time error far more quickly than they will forgive our inability to correct that error." - Karen Ward (wardk@cse.ogi.edu) ------------------------------ Date: 29 Jul 91 19:28:20 +0000 >From: davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) Subject: Re: Philosophy, comments & Re: long and technical (PC) msb-ce@cup.portal.com writes: | One problem that may occur is that of BIOS-shadowing. We can no longer | assume that the BIOS is in ROM at the time that it is executed. Many | machines now copy it to faster RAM. It is possible that a virus might | intercept the BIOS call inside the BIOS itself rather than in the | interrupt table. Which braindead machines do that? I know about BIOS shadowing, but I don't think I've ever found one which didn't set write protect so memory maps would think it was ROM. - -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) GE Corp R&D Center, Information Systems Operation, tech support group Moderator comp.binaries.ibm.pc and 386-users digest. ------------------------------ Date: 29 Jul 91 16:15:46 +0000 >From: motcid!dyer@uunet.uu.net (Bill Dyer) Subject: Re: Virus Scan V57 and V77. (PC) BRENNAAA@DUVM.OCS.DREXEL.EDU (Andrew Brennan) writes: > Stoned in the memory _and_ doesn't find it on the disk. I will > be retrieving a copy of V80 ASAP, but I don't know exactly what > to think in this situation ... > > Andrew. (brennaaa@duvm) Drexel Univ. College of Info Studies. My version of SCAN (V77) found Stoned on my hard disk, no problem. It was in the partition table. I would check your version of SCAN to make sure it is clean. There was talk of a trojan version of SCAN, but this was supposedly SCAN V78. If you have a program that will let you look at the disk (PCTOOLS or Norton), look at your partition table or boot sector. If you have Stoned, you should see the string "You have been Stoned" or something like that. At least I did when I was infected. While I am here, a question about Stoned. From what I can tell, Stoned is a memory resident program that resides in the partition table on hard disks and the boot sector on floppies. My question is what triggers the thing to infect a floppy from the hard disk? In other words, what interupt is it stealing? Second question, can Stoned infect other places besides the partition table? We have a PC board plugged into one of our suns here at work, and I think the thing is infected with Stoned. However, the thing does not have a standard hard drive, I think it uses NFS and a partition on the Sun's hard drive. The disk does not seem to have a partition table or a boot sector that I can find? Does anyone know how these PC boards in a Sun work, and if it would be possible for Stoned to infect one of them. Thanks for any help. - -Bill Dyer - -- _____________________________________________________________________________ | I wish I could sit on soft pillows, |Bill Dyer (708) 632-7081 | | and eat molten lava. | dyer@motcid.rtsg.mot.com | | -King Missle | or uunet!motcid!dyer | ------------------------------ Date: 30 Jul 91 02:11:54 +0000 >From: stefan@zurich.ai.mit.edu (Stefan Kozlowski) Subject: Dark Avenger (PC) Folks, A friend of mine just called me and asked for help with removing the Dark Avenger virus from his PC. I know nothing about the virus and little about PC's. Any information would be greatly appreciated. Thanks in advance. - --Stefan Kozlowski MIT AI Lab stefan@zurich.ai.mit.edu ------------------------------ Date: 30 Jul 91 05:03:40 +0000 >From: Lachlan Brown Subject: Tequila virus and partition table (PC) A friend of mine who works in a computer shop has recently had a number of people coming to him with the Tequila virus on their systems. In case I have a nasty encounter with it I'd like to know a little more. If I understand correctly, the virus writes it's self in to the partition table (as well as exe files and some other area of the hard disk) Where exactly is the partition table? and is it changed or over written in the a normal day on the computer, or can you back it up using debug or whatevero in case some nasty groobly gets into it ? Thanks in advance Lachlan Brown The University of Queensland Electrical Engineering ------------------------------ Date: 30 Jul 91 10:44:00 -0500 >From: "William Walker C60223 x4570" Subject: Re: High Memory (PC) >From: padgett%tccslr.dnet@mmc.com (A. Padgett Peterson) > The key is that at BIOS load time (before DOS), all Intel iapx80X86 > processors are running in real mode (i.e. brain-dead as a 8086). Yep. > There should be no "high" or "extended" or "expanded" RAM available > as yet and all interrupts "should" be located in the segment range > C000h-F000h. This is easily authenticated with a fast pass through > the interrupt table since the segment prefix is in each vector. (the > video buffer A000h-BFFFh) is a data storage area and should not have > interrupts pointing there). You cannot look only at the segment prefix to determine where the vector points; you must calculate the actual address. For example, if you found the segment 9800h, you might assume that the vector pointed into the top of the 640K RAM area. But if the offset was 8000h, making the entire address 9800:8000h, it would point to absolute address 0A0000h, or the beginning of the video buffer. True, there should be no vectors pointing into any RAM, video or otherwise, before DOS is loaded. However, there is a more subtle example. There is a portion of extended memory on a '286 or '386, which Microsoft calls the High Memory Area (HMA), which is accessible from real mode. A good explanation of how it works is given in the article "Power Programming" by Ray Duncan, in the June 27, 1989 issue of PC Magazine, part of which I've quoted below: > "Recall the method by which physical addresses are generated in real > mode. The contents of a segment register are shifted left 4 bits > and added to a 16-bit offset. On an 8086/88 machine, if the result > overflows the 20-bit addresses supported by the CPU, the address > simply wraps--that is, the upper bits are discarded. 80286- and > 80386-based PCs can support larger physical addresses (24 bits and > 32 bits, respectively), but this capability is ordinarily not > apparent when DOS is running. That's because these machines have > special hardware to disable the most-significant address lines in > real mode, making the machine behave more like an 8088. > "Consider what happens, however, on an 80286 when you enable the A20 > line and place the value FFFFh in one of the segment registers. > Enabling the A20 line allows the generation of 21-bit physical > addresses. And when FFFFh is shifted left 4 bits and added to a > 16-bit offset, the result will fall in the address range FFFF0h- > 10FFEFh. In other words, enabling the A20 line allows the first > 65,520 bytes of extended memory to be addressed WITHOUT LEAVING REAL > MODE." [my emphasis - WWW] > - Duncan, Ray. Power programming. PC Magazine, V8 I12 (June 27, > 1989), p. 321. Copyright Ziff-Davis Publishing Co. 1989 Knowing this, suppose a virus has somehow infected a machine with a pre-DOS validator, relocating it as though it was a normal boot sector or MBR. Also suppose that it has enabled the A20 line and stored part or all of itself in the HMA, with vectors pointing up there. These vectors would by necessity have a segment prefix greater than 0F000h. Now, when the validator gets control, it would mistakenly believe that those vectors pointed into ROM below the 1M line if it only examined the segment prefix. But if it calculated the full absolute addresses, it would easily see that the vectors pointed into the HMA, not ROM. Such a virus, though possible, would not be very viable, since running HIMEM.SYS or anything which used memory in protected mode would wipe out the virus code in the HMA. And, if the virus somehow protected itself, these programs would bomb out, giving the user a clue that something was wrong. One other item: there is a device I mentioned in a previous posting called the HIcard from RYBS Electronics. I'm not completely familiar with this device, but I believe it adds 64K to conventional memory, making a total of 704K. I believe it also puts that memory in an unused block between 0A000h and 0F000h. At first, it seems like a device few people would use, but it is mandatory on 8086/88/286 systems to run dBASE IV 1.0 with most networks, so there could be quite a few in use. And there's nothing to prevent a virus from using it at any time, even before DOS loads...... Disclaimer: The quoted material from A. Padgett Peterson belongs to him. The quoted material from PC Magazine belongs to Ziff-Davis Publishing. The rest belongs to me. None of it belongs to my employer. Bill Walker ( WALKER@AEDC-VAX.AF.MIL ) | OAO Corporation | "... but as we say on Earth, Arnold Engineering Development Center | c'est la vie." M.S. 120 | - James T. Kirk Arnold Air Force Base, TN 37389-9998 | ------------------------------ Date: Tue, 30 Jul 91 10:19:00 -0700 >From: Eric_Florack.Wbst311@xerox.com Subject: Multi-compress Dmitri Schoeman in VIRUS-L #129: > If the "compressed" code is larger than the original code it will > erase the temp file, and I am sure we are all aware of the > non-permancy of the erase command,..... Ah, so /that's/ it. Good going, Dmitri... this is a point that had eluded me since I generaly do my compressions in a RAM disk for speed. Perhaps we can prevail upon the makers of such to do a WIPE olike routine on the old files to prevent this kind of thing? > Can anyone verify if the code is sufficiently changed by the above > method? In the method you describe, the code being changed isn;t the problem, here; it's that the checkers such as SCAN won't look inside a nested file. It would look at the first level, without de-compressing the file inside, and therefore wouldn;t see a virus inside the nested file. Again, seems the only way to prevent this is to tamper proof the PKLITE and LZEXE code.... Again, perhaps if we yelled loud enough... I'm quite sure Phil Katz would at least be interested in such a proposal. And another good idea is Padgett's..>>>.The answer, of course, is for scanners to use a recursive technique for unravelling files and it would be relatively easy to check. Eternal Vigilance and all that. << Perhaps both ideas are worth pursuing? ------------------------------ Date: 30 Jul 91 14:09:15 +0000 >From: grueber@olymp.informatik.uni-bonn.de (Willi Grueber) Subject: virues in io.sys (PC) Ares there any viruses infecting io.sys and thus installing themselves before DOS is started ? Which virus-scanners check for infected io.sys files ? Thanks Hermann hermann@holmium.informatik.uni-bonn.de ------------------------------ Date: Tue, 30 Jul 91 17:56:16 +0000 >From: johnf@apollo.hp.com (John Francis) Subject: Re: Self-scanning executables (PC) Somewhere on CompuServe, Kevin Dean writes: > Cracking the algorithm is not a trivial task: a virus has one chance > in four billion (2^32) of successfully infecting a program or, if it > decides to fool the algorithm by changing the stored CRC, would lock > up a 386 for hours bordering on days to find and change it. Unfortunately this is nothing more than "Ignorance Protection". There has to be some way of calculating the initial CRC when the program is built - they don't appear in the executable by magic! This must be by some method that is faster than exhaustive search, or else nobody will use CRC protection. The same algorithms are available to virus writers. It won't take long to find the encryption code in an executable - the techniques to do that can be found in all the current virus scanners, and we must assume that most virus writers are conversant with these methods, and could use them themselves to find the right spot. ------------------------------ Date: Tue, 30 Jul 91 15:47:37 -0600 >From: rtravsky@CORRAL.UWYO.EDU (Richard W Travsky) Subject: Observation on F-DRIVER.SYS & Windows 3 (PC) I was recently given a Zenith 386 to use here at work. These come pre-installed with Windows 3.0 and DOS 4.01. I had troubles getting Windows to come up in enhanced mode. It would default to standard and on startup would complain about not finding an application (when it should not have even been looking for one in the first place). The program manager window was small (not minimized, more like a window onto a maximized window - hopefully you get the picture). And there was a couple of other minor annoyances I've already forgotten about. Any, I played the windows game, fiddling with my config.sys. What worked was moving F-DRIVER.SYS towards the end of the device calls. Anyone have any other Windows/fprot experiences? After the recent posts about F-DRIVER.SYS and DOS 5.0 I thought it interesting enough to pass on. Richard Travsky Division of Information Technology RTRAVSKY @ CORRAL.UWYO.EDU University of Wyoming (307) 766 - 3663 / 3668 ------------------------------ Date: Tue, 30 Jul 91 09:42:15 -0700 >From: p1@arkham.wimsey.bc.ca (Rob Slade) Subject: CARO and EICAR frog@DGIHRZ01.BITNET writes: > I never read something about CARO and EICAR on this list. Does anyone > have some information about this two organizations or other > international efforts to fight computer viruses? CARO is connected with Klaus Brunnstein, the primary contact for the Computer Virus Catalogue project, and a fairly regular contributor. ============= Vancouver p1@arkham.wimsey.bc.ca | "If you do buy a Institute for Robert_Slade@mtsg.sfu.ca | computer, don't Research into (SUZY) INtegrity | turn it on." User Canada V7K 2G6 | Richards' 2nd Law Security | of Data Security ------------------------------ Date: Fri, 26 Jul 91 17:08:44 +0000 >From: nykerk@McRCIM.McGill.EDU (Martijn Nykerk) Subject: Re: Philosophy, comments & Re: long and technical (PC) Maybe a Followup WILL make it out of here. Anyways johnf@apollo.hp.com (John Francis) opposing padgett%tccslr.dnet@mmc.com (A. Padgett Peterson) on authenticatable peripheral paths writes: > I do not, however, accept your belief that you can get clean and > authenticatable periperal paths" on a PC. > On 386 or better systems, I can write a "Virtual Machine" emulator > that can fool you into believing you are running on the raw hardware. > This means I can write the ultimate stealth system - undetectable by any > means whatsoever (not quite true, but I don't want to give everything away). I don't want to give everything away? (are you working on one? :) ;) :) ) Forgive me if I am wrong but wouldn't the check to see if you're at ROM BIOS (if that's where you want to be) be just a memory write and a check to see if your byte survived in the big world? Ofcourse shadowing would sort of f*ck this check up I guess. Martijn. ------------------------------ Date: Mon, 29 Jul 91 13:05:00 -0400 >From: Jeff Boyd Subject: Re: Self-scanning executables (PC) Fridrik Skulason wrote: > Well, this is of just as much use as a simple checksumming algorithm - You either overlook or underestimate the value of it. When I write PC software for sale or otherwise, I build this routine in and the program has an INDEPENDENT self-check CRC calculation. My program will not run if altered, and hence will NEVER aid in the spread of a virus (provided the user takes appropriate cleansing action when the program finds any changes - the virus could certainly move in the single run required to expose its presence). ------------------------------ Date: Fri, 26 Jul 91 14:13:25 -0700 >From: p1@arkham.wimsey.bc.ca (Rob Slade) Subject: Related Terms DEFGEN4.CVP 910721 Related (non-viral) terms Two other groups of security breaking programs are very often confused with viri. The first is the "trojan horse", the second the "logic bomb." The confusion is understandable, as viral type programs, trojan horses and logic bombs make up the three largest distinct groups of security breaking software, and often one may "contain" the code of one another. A trojan horse is a program which pretends to do one thing, while performing another, unwanted action. The extent of the "pretence" may vary greatly. Many of the early PC trojans relied merely on the filename and a description on a bulletin board. "Login" trojans, popular among university student mainframe users, will mimic the screen display and prompts of the normal login program, and may, in fact, pass the username and password along to the valid login program, as well as stealing it. Some trojans may contain actual code which does what it is supposed to be doing, while performing additional nasty acts that it does not tell you about. (I make the distinction that trojans are always malicious, as opposed to "joke" or "prank" programs.) (A recent example of a trojan is the "AIDS Information Disk", often incorrectly indentified in both the general and computer trade press as a virus. Not to be confused with the, fairly rare, AIDS I and II viri, this program appears to have been part of a well organized extortion attempt. The "evaluation disks" were shipped to medical organizations in England and Europe, with covers, documentation and license agreements just like any real commercial product. When installed and run, it did give information and an evaluation of the subject's risk of getting AIDS, but it also modified the boot sequence so that after 90 reboots of the computer all files on the disk were encrypted. The user was informed that, in order to get the decryption key, a "license fee" had to be paid.) Trojan horse programs are sometimes referred to as an "Arf, arf" or "Gotcha" program from the screen messages of one of the first examples. A trojan horse may be used to plant a virus simply by infecting any existing program. A logic bomb is a malicious program which is triggered by a certain event or situation. Logic bomb code may be part of a regular program, or set of programs, and not activate when first run, thus having some of the features of a trojan. The trigger can be any event that can be detected by software, such as a date, username, CPU id, account name, or the presence or absence of a certain file. Viral programs and trojans may contain logic bombs. copyright Robert M. Slade, 1991 DEFGEN4.CVP 910721 ============= Vancouver p1@arkham.wimsey.bc.ca | "If you do buy a Institute for Robert_Slade@mtsg.sfu.ca | computer, don't Research into (SUZY) INtegrity | turn it on." User Canada V7K 2G6 | Richards' 2nd Law Security | of Data Security ------------------------------ End of VIRUS-L Digest [Volume 4 Issue 133] ****************************************** Downloaded From P-80 International Information Systems 304-744-2253