NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/compress/4606

Text File | 1993-01-12 | 17.4 KB | 352 lines

Newsgroups: comp.compression
Path: sparky!uunet!math.fu-berlin.de!Sirius.dfn.de!news.DKRZ-Hamburg.DE!rzsun2.informatik.uni-hamburg.de!fbihh!bontchev
From: [e-mail] (Vesselin Bontchev)
Subject: Re: pkzip204c--virus activity?
Message-ID: <bontchev.726871363@fbihh>
Sender: [e-mail] (Mr. News)
Reply-To: [e-mail]
Organization: Virus Test Center, University of Hamburg
References: <[e-mail]>
Date: 12 Jan 93 20:42:43 GMT
Lines: 339

[e-mail] (Mark Achtemeier) writes:

> The following is a report of an incident of virus-like activity which
> appeared recently on my system, possibly in connection with the use
> of the new version 2.04c of PKZIP.  I confess that I do not understand

My final conclusion (see below) is that even if the activity observed
by you is caused by a virus, it is NOT in connection with the use of
the new version 2.04c of PKZIP.

> how all the pieces of the puzzle fit together, but I am recording the
> events as accurately and completely as I possibly can so that others
> can be on the lookout for similar phenomena.

You did a pretty good job; I'll try to point out a few minor mistakes,
so that you could do even better the next time.

> I FTP'd the file 'pkz204c.exe' from the archive at garbo.uwasa.fi on
> the Internet at approx. 2:00pm est on Thursday, January 7.  The file

You should post a better identification of the file, so that we are
certain to talk about one and the same thing. However, Prof. Salmi
already posted both VALIDATE and CRC-32 checksums of the file there,
and I am convinced that it is exactly the same as the file I
inspected. Therefore, I guarantee you that the file on garbo is NOT
infected.

> was copied first to my storage area on the DEC terminals at Duke
> University, and from their FTP'd to an IBM compatible terminal on a
> public cluster in the Duke library.  The public terminal had been
> turned on when I began to use it, but its associated directories
> showed no files present.

Uhm, I am not familiar with DEC terminals... You are speaking about
directories - are some kind of PCs used as terminals? Or are you
speaking about the directories on the machine to which your terminal
provides you access?

If an IBM PC compatible machine is used as a terminal, if you have
found it turned on, and if you have used it to transfer the executable
on diskette, then if this machine was infected with a certain type of
virus (a fast infector), they your downloaded executable would be
infected. This has nothing to do with garbo or PKWare - the file gets
infected due to bad computer hygiene...

In general, it is always dangerous to use an unknown PC to transfer
executable code, because the PC might be infected and this will cause
infection of the transfered executable code. On the other side, it is
also a bad practice to use self-extracting archives, because they can
get infected.

> On the public terminal, I ran pkz204c.exe to extract the various
> program and documentation files, consulted these and ran some tests
> comparing the performance of the new version against PKZIP 1.1 (I was

So, the "terminal" is some kind of PC. Note that if it is infected,
all your executables might be infected by now...

> Since I had read the discussion about the "maltese amoeba" alarms
> associated with this program, I ran the 'scan.exe' program in McAfee
> Associates' SCAN 8.6V93 package on both the original and the extracted
> archive files.  The program reported no viruses found.

A few remarks:

1) The latest version of SCAN is 99 - yours is a bit out-of-date.

2) A scanner is able to detect only known viruses. If that terminal PC
was infected by a new virus (unknown to SCAN), then nothing would be
detected.

3) If the virus is using an advanced technology to hide, known as
"stealth", the scanner will not be able to find the virus in the
infected files, if that virus is active in memory. In general, the
scanner should be able to detect the virus in memory and refuse to
run, but don't rely on that. That's why, when you suspect a virus, the
first thing you must do is to ensure that the virus is not in memory.
The ONLY secure way to achieve this is to cold-boot from an uninfected
write-protected system diskette. Such diskette must contain the
operating system (the same your hard disk is formatted with), any
drivers needed to access the disk (such as Stacker, etc.), and the
virus scanning software. In case it does not fit on a single diskette,
you can keep the scanning software on a separate diskette - but again
it must be write protected and not infected. Have you done all this
before running SCAN in your case? If not, the scanner could have
spread the virus (if there is a virus) on every executable it has
scanned.

> On my own system, I copied the original archive file to a temporary

Are you absolutely certain that your own system was not infected at
that point?

> directory.  Before extracting it, I executed my standard batch file
> (hereafter called the "standard scan") for running the McAfee scan
> program--I had used the /AF option some months earlier to create a
> file (called scanval.val, located on the c: drive) of validation codes
> for my program, *.sys and *.ovl files.  My standard scan batch file

That's a good idea. Actually, checksumming programs (usually called
"integrity checkers") are a much stronger weapon against viruses than
the known-virus scanners. Unfortunately, the integrity checking
provided in SCAN is not good enough, but this is irrelevant for the
moment.

> runs SCAN with the /CF option, checking these validation codes against
> the appropriate files on the disk.  This first run of the standard
> scan produced one alarm: for a file entitled DESKTOP.OVL associated
> with my PCTOOLS 5.0 package.  While it concerned me at the time, I
> have since discovered that this file is written to every time the
> PCTOOLS DESKTOP program is run in resident mode.  Since I had in fact
> done this after creating the file of validation codes, I have no
> reason to believe this file was infected at that time.

Your conclusion seems reasonable.

> My next step was to execute the pkz014c.exe program in my c:\temp
> directory in order to extract the program files from the archive.  All
> of the files produced -AV validation codes.  Again I ran a standard
> scan, which continued to produce a single alarm for DESKTOP.OVL.

This means that at this point either PKZ204C.EXE was not infected, or
it was infected by a stealth virus. In the latter case, it has been
infected on the terminal PC.

> Satisfied that the program was virus-free, I proceeded to rename the

Note that just because SCAN did not report anything does not
necessarily mean that the program was virus-free. It means that it is
either infected by a new virus, or it is infected by a stealth virus
(probably - a new one), which is already resident in memory (due to
the execution of the program PKZ204C.EXE).

> Wanting to be on the safe side, I then decided to do a final run of
> the standard scan.  This scan was done immediately after the PKZIP
> batch job, with no other programs run in the interim. This time, to my
> horror, the program produced alarms for my MSDOS.SYS file, along with
> every file on my disk containing and extension of '.OVL'.  No other
> files were affected.  The overlay files, approximately twelve in all,

Are you absolutely certain that the name of your OS file is MSDOS.SYS
and not IBMDOS.COM, for instance? This is important, because very few
viruses attack SYS files.

Next, were there other files on your disk with extension SYS? It is
possible that if it is a virus, it applies its stealth abilities to
hide its precense only in COM and/or EXE files, but not in SYS and OVR
files.

> resided in three separate directories on my c: drive.  The alarms
> simply said: "File has been modified, a virus infection may have
> occurred".  No indication of the identity of the virus was given, nor

Yes, that's the main drawback of integrity checking... It doesn't
tell you whether it is a virus and which virus it is. The user is
usually just notified that the file has been modified... However,
-good- integrity checkers try to tell you -how- the file is modified.
Did its size increase or decrease? Maybe just its file date and time
of last modification or file attributes have changed (e.g., if you
have used PKZIP as a backup program and have told it to turn the
Archive bit off). Knowing -how- the file is changed sometimes helps
you to determine whether the change has been caused by a virus.

> That evening I spent some time plotting strategy for ridding my system
> of what I assumed was an infection.  I determined that I would prepare
> a write-protected, bootable floppy disk on my home system, containing
> uninfected copies of the overlay and MSDOS.SYS files, which I would
> use to replace the damaged files.

A very good idea. The only problem might be that if it is an infection
by a stealth virus, the executable files might be infected too... The
only way to determine that is to boot from a clean diskette (see
above) and run a clean version of the integrity checker, using a
trusted copy of the database of checksums - usually on a
write-protected diskette.

> The next morning, I executed a boot from power-off of the write-
> protected floppy disk.  I had set up the floppy to install a new
> versions of the PCTOOLS SHELL utility to a temporary directory on the
> c: drive.  I then used this utility to delete the MSDOS.SYS and IO.SYS
> files (which I replace using the DOS 'sys' command) and also to
> overwrite all of the .OVL files with the clean versions.

Correct.

> Having finished this procedure, I powered off the system and did a
> reboot from the c: drive.  I immediately ran the standard scan, and
> was puzzled to find that while the number of alarms had decreased, a
> number were still reported.  The MSDOS.SYS file still registered as
> corrupt, along with three or four of the .OVL files.  After puzzling

Hmm... Two possibilities:

1) The .OVL files have had different parameters (date&time,
attributes, etc.) when the checksum has been computed. Regardless
whether they have been infected or not, you have replaced them with
clean copies, but if those copies have different parameters, the
integrity checker will still report a change.

2) You have replaced the (infected) .OVL files, but the virus was a
stealth one and was still present in the COM and EXE files. As soon as
you have run the "standard scan", you have executed the infected scan
program, which has spread the virus to a few .OVL files again.
Probably due to a bug, the virus does not stealth its presence in such
files, so the integrity checker detects the modification. The correct
move would be to run not the "standard scan", but instead run a known
clean copy of the integrity checker, using a known clean copy of the
databases of checksums.

> over this awhile, I tried repeating the procedure of powering down the
> system, booting from the floppy, deleting the old files and replacing
> them with with the uninfected versions.  A subsequent run of the
> standard scan continued to produce alarms.

At this point it looks pretty much like a virus. It has probably been
transfered from the terminal PC.

> {On two occasions during all this--I am fuzzy on just when they were--
> I also noted that an attempt to run a program contained on my utility
> floppy produced an error message of "Write protect error: unable to
> write to floppy disk" or something to that effect.  This struck me as
> highly unusual, since nothing in the command or program involved
> should have called for a write to the diskette.}

This is -very- suspect. Most of the viruses are smart enough to avoid
this message when trying to infect something on a write-protected
floppy, but some of them aren't. What puzzles me is the aparent
combination of clever (stealth technology) and dumb (not suppressing
the critical errors) properties of the virus...

> Thinking that perhaps the files from my home system were infected, I
> used the temporary version of PCTOOLS on the c: drive to run a
> comparison between the supposedly uninfected files on the floppy disk
> and the which were still producing alarms on the c: drive.  The
> comparison, to my bewilderment, showed that the MSDOS.SYS and overlay
> files in question were, in fact, different from their source files on
> the floppy which I had copied onto the c: drive a few moments earlier.

Yes, this is typical for a stealth virus. Your files on the C: drive
are infected, but the virus stealths its presence in EXE files and you
detect the difference only in the other files. It is not your home
system that is infected - it is the system at the office. Could you
tell me (1) how did you compare the files (DIR, COMP, PCTOOLS' file
compare) and (2) how they were different - larger, smaller, same size
but different contents, etc.

> In desperation I did a final run of the standard scan.  This time it
> produced *more* alarms--still not for all the overlay files on the
> disk, but for more than had been reported in the run immediately
> preceeding it.

Yes, because the virus is still in memory (you didn't reboot from the
clean diskette, did you?), the scanner is infected (you didn't run the
one from the write-protected diskette, did you?) and the virus
continues to infect. Do you see now why it is important that you
ensure a virus-free memory when checking for viruses?

> At this point I panicked and decided that drastic action was called
> for.  I used PCTOOLS to make copies of the infected MSDOS.SYS and
> *.OVL file on a clean floppy for future reference.  Alas, I did not
> think to examine them closely at the time.  I then did a power-off
> boot from my write-protected, utility floppy, and used FDISK to delete
> all of my drive partitions.  I proceeded to set up the disk from
> scratch, installing a new operating system (DRDOS 6) which I had been
> meaning to do for some time anyway, and restoring my program and data
> files from a set of backups which (fortunately) I had done only a few
> days before.  I did scans (with new validation files) throughout the
> process and have not encountered any virus alarms since.

At this point you felt a bit seized by panic, didn't you? This has
been your second important mistake (the first was that you have failed
to ensure virus-free memory) - you have destroyed the evidence and
possibly lost some data (unless you had a backup).

Other mistakes:

1) Just running FDISK and deleting the partitions is not always
sufficient. It will not remove a Master Boot Sector virus like Stoned
or Michelangelo. (This is probably irrelevant in your case, because
you have almost certainly had a file infector.) In order to remove a
MBR virus, you need to boot from a system MS-DOS 5.0 diskette (a lower
DOS version or DR-DOS won't do the job) and execute the command
FDISK/MBR. This will not display anything, but will remove the
eventually present MBR infector.

2) You had also to save copies of a few executable files (COM&EXE),
regardless that they did not show any suspicions for infection.

> A puzzling final note:  I have since had the opportunity to examine
> the copies of the infected files which I had copied to floppy disk.
> Compares run against uninfected versions of the same files on my home
> system reveals no difference between the files--this in spite of the
> fact that the differences were clearly evident when they resided on
> the c: drive.

Not certain what could cause this... Either your home system is
already infected by the same virus, or the virus has disinfected
itself when your have copied the files on floppies. There is not
enough evidence to support any of those suppositions... I just don't
know. I need a copy of an infected executable file, in order to decide
that. Unfortunately, I understand that all such files have been
destroyed.

> If this is a case of virus infestation, there are a lot of aspects of
> it I don't understand--like how a virus could turn up active in a
> system booted from a clean, write-protected floppy, for starters.  The

It turned up active when you have started the infected scan program
from the hard disk, in order to perform the "standard scan". During
the scan from the clean floppy, the scanner has not found anything,
because it is certainly a new virus - if it is a virus at all, of
course. And you didn't execute the integrity check from that clean
floppy, did you?

> account in order to make the emergent picture a clearer one.  I have
> decided, though, that everyone's best interest will be served by as
> complete and accurate an account as possible, and this is what I have
> struggled to provide.

I hope to have helped you make the picture a little bit more clear. If
you have any further questions, feel free to ask. Please note that the
proper newsgroup for virus discussions is comp.virus.

> I have available for the asking:  copies of the now mysteriously
> intact files which were copied from the infected c: drive onto floppy.
> Copies of the original pkz204c.exe file which started this whole
> incident (maybe!) to begin with.

One thing I am 100% certain - the file pkz204c.exe that you have
obtained from garbo is NOT infected. It is possible that the terminal
PC used for the download is infected - maybe it still is.

Regards,
Vesselin
--
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:[phone], Fax: [phone]      Fachbereich Informatik - AGN
< PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [e-mail]    D-2000 Hamburg 54, Germany