zmudzinskit@imo-uvax.dca.mil (zmudzinski, thomas) (08/08/90)
>From Virus-L V3 #138 > "Stealth" virus > > I have seen the name "Stealth" used for 4 different viruses, 4096 > (Frodo, IDF) and 1260, as well as two of the Bulgarian viruses. This is > too confusing, so what I propose (and what I will do in version 1.13 of > F-PROT) is to use "Stealth" to refer to a class of viruses - the viruses > that attempt to hide from detection, using a variety of methods. > Comments, anybody ? Agree that "Stealth" has become a class of virus. However, I suggest limiting it to those viruses that use the technique of disinfecting their prey (either on disk or in memory). Reason: Clarity. A virus that "hides" by counter-attacking the virus detection software (making it lie about infections) is not of the same class as a disinfector. Theoretically, it should always be possible to use the "stealth" code to recover the infected programs. I propose the following definition: Stealth - (adj) Any malicious code that "hides" from detection by erasing itself from its carrier. /s/ Tom Zmudzinski ZmudzinskiT@imo-uvax.dca.mil
frisk@rhi.hi.is (Fridrik Skulason) (08/14/90)
> (zmudzinski, thomas) writes: >Agree that "Stealth" has become a class of virus. However, I suggest >limiting it to those viruses that use the technique of disinfecting >their prey (either on disk or in memory). > >Reason: Clarity. A virus that "hides" by counter-attacking the virus >detection software (making it lie about infections) is not of the same >class as a disinfector. I never proposed this - what I said was simply "viruses that attempt to hide from detection, using a variety of methods". The methods may include: Disinfecting the file when it is read (4096 method) Redirecting INT 13H and/or INT 21H, so the file will appear to be unchanged when read. Redirecting INT 13, so the boot sector appears unchanged, while the virus is active in memory (Brain) and possibly the method used by TPVIR and AIDS II, where the original program does not change, and the user is unaware that he is, in fact, executing the virus instead of the program he intends to execute. >Stealth - (adj) Any malicious code that "hides" from detection by >erasing itself from its carrier. "erasing itself" is not 100% clear, I think. What about: Stealth: Any malicious code that vanishes or appears to vanish from the infected media, while it is active in memory. - -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 |
mweiner@bene.at (Michael Weiner) (08/15/90)
frisk wrote: > I never proposed this - what I said was simply "viruses that > attempt to hide > from detection, using a variety of methods". The methods may > include: > > Disinfecting the file when it is read (4096 method) > > Redirecting INT 13H and/or INT 21H, so the file will > appear to be > unchanged when read. > > Redirecting INT 13, so the boot sector appears > unchanged, while the > virus is active in memory (Brain) INT 40h should definitely be included, it might also become necessary to check INT 0Dh and INT 0Eh at some point in the future. > Stealth: Any malicious code that vanishes or appears to vanish > from the infected media, while it is active in memory. I would like to add: [...] under certain trigger conditions. Something else: Does anyone know of a virus scanner that examines high memory (as used by 386max and similar utilities) for "stealth-type" viruses ? Michael Weiner +-----------------+-----------------------------------------------------+ I mweiner@bene.at I Michael Weiner, Ghelengasse 4, A-1130 Wien, Austria I +-----------------+-----------------------------------------------------+
woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) (08/17/90)
mweiner@bene.at (Michael Weiner) writes: > frisk wrote: > > INT 40h should definitely be included, it might also become necessary > to check INT 0Dh and INT 0Eh at some point in the future. One should not forget ram shadowing of the bios. It is a simple matter to determine whether this is in effect attempt to alter a byt in the bios area, and see if it took. If so, then overlay one of the known entry points (most bioses attempt to be IBM compatabile, right down to the entry points in the rom), and patch part of the bios. Now you are below DOS, below the BIOS interface, below the IRQ's etc. > Something else: Does anyone know of a virus scanner that examines high > memory (as used by 386max and similar utilities) for "stealth-type" > viruses ? Good point. This is a fertile breeding ground, imagine a large virus, that stuffs it'self up there, and then pages back and forth by changing the LIM memory driver, so that interrupts to it pass control to the virus. Since LIM drivers are easy to access, live in ram, it would be no big deal to patch the actual code, and not touch the interrupt vectors. The same goes double for device drivers. Suppose a device driver that does some nice thing, like fix the @#$%@$#% daily rollover bug in dos. The driver perhaps unpacks a bit of nasty that goes to work at midnight... Cheers Woody
mweiner@bene.at (Michael Weiner) (08/18/90)
woody@chinacat.Unicom.COM (Woody Baker wrote) : > MW> Something else: Does anyone know of a virus scanner that examines high > MW> memory (as used by 386max and similar utilities) for "stealth-type" > MW> viruses ? > > Good point. This is a fertile breeding ground, imagine a large > virus, that stuffs it'self up there, and then pages back and forth by > changing the LIM memory driver, so that interrupts to it pass > control to the virus. Since LIM drivers are easy to access, live in > ram, it would be no big deal to patch the actual code, and not touch the > interrupt vectors. The same goes double for device drivers. > Suppose a device driver that does some nice thing, like fix the @#$%@$#% > daily rollover bug in dos. The driver perhaps unpacks a bit of nasty > that goes to work at midnight... There is an additional problem: Many of these 386/486 memory managers allow you to define "high DOS memory" over the 640k barrier. 386max for example allows you to load device drivers and TSRs into this memory region (In my case, it is 96kB at C800 - E000). If a file infected with a "stealthy" virus into this memory region, I doubt many scanners will detect it when they look for virus signatures in memory. To my knowledge, most only scan the "low" 640k. A friend told me that this has already occured in a number of cases he knows about. cheers, mike +----------------------+-----------------------+ I Michael Weiner I uucp: mweiner@bene.at I I Ghelengasse 4 +-----------------------+ I A-1130 Wien Austria I tel: ++43 1 8232400 I +----------------------+-----------------------+
mweiner@bene.at (Michael Weiner) (08/20/90)
woody@chinacat.Unicom.COM (Woody Baker) wrote: [on the possibility for viruses to alter ROM BIOS code shadowed into RAM on 386 machines] > One should not forget ram shadowing of the bios. It is a simple > matter to determine whether this is in effect attempt to alter a > byte in the bios area, and see if it took. In many cases ROM shadow is write protected (on my machine for example) and on the machines of all people I asked. The only way to check whether it is shadowed or not is timing ROM access and comparing the timing to RAM timing. Still, this write protection is software-based only. As I understand it, these memory managers work by placing the machine in protected mode and running the PC in Virtual-86 mode. If a virus was able to switch into protected mode using some backdoor, it becomes feasible to alter shadowed ROM which would be truly frigthening. Let's hope it won't happen because we'll have a hard time protecting ourselves against this type of attack. +----------------------+-----------------------+ I Michael Weiner I uucp: mweiner@bene.at I I Ghelengasse 4 +-----------------------+ I A-1130 Wien Austria I tel: ++43 1 8232400 I +----------------------+-----------------------+
frisk@rhi.hi.is (Fridrik Skulason) (08/25/90)
mweiner@bene.at (Michael Weiner) writes: >There is an additional problem: Many of these 386/486 memory managers >allow you to define "high DOS memory" over the 640k barrier. 386max >for example allows you to load device drivers and TSRs into this >memory region (In my case, it is 96kB at C800 - E000). I just wanted to mention that we already have one virus which is able to load itself above the 640K barrier. The E.D.V. boot sector virus starts to look for free ram at E800:0000 and moves downward in 64K jumps - skipping the area 9800-B000 As an extra twist, the virus will attempt to crash any program scanning high memory - in intercepts the "timer-tick" interrupt, and if it finds that ES or DS point to the region where it is hiding, it will halt the computer. This of course makes scanning for this virus a bit complicated. - -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 |
prs@EDDIE.MIT.EDU (Paul Schmidt) (08/28/90)
mweiner@bene.at (Michael Weiner) writes: > [on the possibility for viruses to alter ROM BIOS code shadowed > into RAM on 386 machines] > >Still, this write protection is software-based only. As I understand >it, these memory managers work by placing the machine in protected >mode and running the PC in Virtual-86 mode. That's not true for all machines. Nearly all, if not all of the more recent support chip sets for PCs (both 286 and 386) allow BIOS shadowing (and Video BIOS shadowing, as well) in _hardware_, regardless of what mode the CPU is running in. Some of these chip sets can be manipulated to allow write access to the 0xF0000 area (after all, the boot-up code needs write access to copy the code over). Some others, however, have various interlocks that disallow write access after the initial copy, or from any executing code outside the BIOS.
HLIN@NAS.BITNET (Herbert Lin) (11/16/90)
In a recent msg, someone said that a "stealth" virus could evade checksum and CRC checks. Can anyone tell me how this is done? Wouldn't the author of the virus have to know the checksum/CRC technique being used in detail? Without specific knowledge of the polynomial being used, what could the virus author do? I can imagine that certain values wouldn't contribute to the checksum, but if you make the original size of the file part of the check, then adding those special values will change the file size, and render it detectable. In short, it seems that if I am willing to give up the detection of virus propagation in real-time, I should be able to detect viruses ALL THE TIME (of course, if and only if I have a confirmed clean system to begin with). what am I missing? herb
vail@tegra.com (Johnathan Vail) (11/21/90)
HLIN@NAS.BITNET (Herbert Lin) writes: In a recent msg, someone said that a "stealth" virus could evade checksum and CRC checks. Can anyone tell me how this is done? Wouldn't the author of the virus have to know the checksum/CRC technique being used in detail? Without specific knowledge of the polynomial being used, what could the virus author do? Checksums are easy to beat. CRCs are more difficult. The combination of both is unbeatable except by "stealth" techniques. As I understand it, the stealth type programs take over DOS or BIOS and if the infected files or sectors or directory info about these is read then a "fixed" version is actually returned. The fixed version makes it appear that the program or disk is uninfected. I can imagine that certain values wouldn't contribute to the checksum, but if you make the original size of the file part of the check, then adding those special values will change the file size, and render it detectable. Yes, the way to add code without changing the checksum or without calculating it from the entire file is to make the checksum of the additions be zero. Any addition would add to the file size. In short, it seems that if I am willing to give up the detection of virus propagation in real-time, I should be able to detect viruses ALL THE TIME (of course, if and only if I have a confirmed clean system to begin with). what am I missing? The stealth concept. That is why it is called stealth... Your detector would have to do all its disk I/O by itself, or somehow guarantee that the BIOS and DOS routines have not been compromised. And direct hardware I/O may not be completely safe on a 386 without checking the MMU, which again may not be guaranteed safe. "Like a clock, they sent, through, a washing machine: come around, make it soon, so alone." -- Syd Barrett _____ | | Johnathan Vail | n1dxg@tegra.com |Tegra| (508) 663-7435 | N1DXG@448.625-(WorldNet) ----- jv@n1dxg.ampr.org {...sun!sunne ..uunet}!tegra!vail
frisk@rhi.hi.is (Fridrik Skulason) (05/13/91)
I am working on an article on "stealth" viruses, and was wondering if I had missed any of them - here is my list: Boot sector stealth viruses: Azusa, Brain, EDV, Evil Empire, Joshi and Spanish Telecom (boot) Program stealth viruses: Fish6, Frodo, INT13, Number of the Beast, Whale ZeroHunt (Minnow) Note that I do not consider any of the following program viruses to belong to the "stealth" category, as they only fulfill one of the two necessary conditions (hiding increase in length), but make no attempt to hide the virus code, when an infected file is read. 3445, Diamond, Dir, Eddie-2000, Eddie-2100, Eddie-2, MG, PcVrsDs, Spanish Telecom (file), SVC 4.0 and Zero Bug. Did I overlook something ? - -frisk Fridrik Skulason Technical Editor of the Virus Bulletin (UK) (author of F-PROT) E-Mail: frisk@rhi.hi.is Fax: 354-1-28801
c-rossgr@uunet.uu.net (05/15/91)
>From: frisk@rhi.hi.is (Fridrik Skulason) > >I am working on an article on "stealth" viruses, and was wondering if I had >missed any of them - here is my list: >Did I overlook something ? Perhaps the Tequila virus? Seems to be gaining in "popularity". Ross