VIRUS-L Digest Monday, 25 Nov 1991 Volume 4 : Issue 226
Today's Topics:
re: Warning! SCAN 82 trojanized! (PC)
Re: Hard disk problem (PC)
Re: System 7 vs. viruses (Mac)
PCVirus publication? (PC)
re: NIST Naming Proposal
Re: NIST Naming Proposal
Re: Dir-II removal (PC)
Virus Verification and Removal
Radai re: Frisk, re: Washburn
Taxonomy tool?
Empire Virus Update (long) (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
[email protected] (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:
[email protected].
Ken van Wyk
----------------------------------------------------------------------
Date: Fri, 22 Nov 91 14:56:16 -0500
>From:
[email protected]
Subject: re: Warning! SCAN 82 trojanized! (PC)
> I have received reports from several places that breaking PKZIP's
> authentification code is relatively easy.
Does anyone know if PAK 2.0's security envelope feature has also been
compromised? There doesn't seem to be the need to come up with any
sophisticated procedure or program from scratch if one already exists.
Adopting one of the schemes whereby the file is CRC'd by two seperate
algorithms should also be foolproof, right?
- ---
Above text where applicable is (c) Copyleft 1991, all rights deserved by:
UNIX:/etc/ping instantiated (Ping Huang) [INTERNET:
[email protected]]
------------------------------
Date: Fri, 22 Nov 91 23:53:46 +0000
>From:
[email protected] (Brian D. Howard (CS))
Subject: Re: Hard disk problem (PC)
[email protected] (Glen Braden) writes:
>Greetings,
> I have a question, concerning my brother's PC. I installed a new
>(40m) hard disk into his 286 PC UNLIMITED(?) after his original hard
>disk got trashed...
Make sure that he sets the DOS partition as 'active' using FDISK.
- --
_______________________________________________________________________________
This space intentionally left what would otherwise be blank were this not here.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
------------------------------
Date: Fri, 22 Nov 91 23:01:49 +0000
>From:
[email protected] (Brian Excarnate)
Subject: Re: System 7 vs. viruses (Mac)
[email protected] (Albert Lunde) writes:
> 1 - Desktop file viruses do not spread easily under system 7, because
> the Finder is more careful about how it opens the Desktop file.
> (This may be related to the use of the Desktop database except on
> floppies or to the Finder rewrite in C++, I don't know. This
> *could* be Apple getting smart.)
Desktop file viruses do not spread under System 7 because System 7
does not use the Desktop file. If you have one left over from an
older System, you can delete it if you like.
The best way of scanning is to boot from a floppy with Disinfectant
on it. That way nothing is busy on the harddrive.
If you want further details, e-mail me or ask on comp.sys.mac.system.
Brian
------------------------------
Date: Sat, 23 Nov 91 02:16:19 -0800
>From:
[email protected] (Great GooglyMoogly!)
Subject: PCVirus publication? (PC)
I've noticed several times in the digest that a publication
named PCVirus has been mentioned. I have never seen this
magazine. Could someone please send me some information
about this publication. I think that I'd like to subscribe.
Thanks in advance.
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: John Price, FB7-53, Intel, Rio Rancho, New Mexico 87124 ::
:: eMail:
[email protected] ::
:: standard disclaimer applies ::
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
"Your brain may no longer be the boss."
Firesign Theatre
------------------------------
Date: Sat, 23 Nov 91 11:24:37 +0000
>From: Fridrik Skulason <
[email protected]>
Subject: re: NIST Naming Proposal
>Does anyone know of, or use, a radically different naming convention
>(other than the ones mentioned and decided against in the NIST
>documents)?
None of the current major products...all the "radically different methods",
such as the old East-German method of just numbering the viruses (virus-1,
virus-2 ....etc) have been abandoned - or at least I don't think one needs
to worry about them.....
However - many products refer to variants of the some family only under a
separate name - for example "Fu Manchu", but not "Jerusalem-Fu Manchu" or
"Israeli-Fu Manchu".
- -frisk
------------------------------
Date: Sat, 23 Nov 91 14:09:02 +0700
>From:
[email protected]
Subject: Re: NIST Naming Proposal
In VIRUS-L 4/224 "David.M.Chess" <
[email protected]> ask:
>Does anyone know of, or use, a radically different naming convention
>(other than the ones mentioned and decided against in the NIST
>documents)?
I know that the soviet researches are using radically different naming
convention. It is based on classification method proposed by Nikolay
Bezrukov from Kiev Institute of Civil Aviation Engineers. I am sure that
Vesselin Bontchev has english description of soviet convention (he
posted it in the FIDONET about one year ago). If you have in your sample
collection any file with name like RCE-1834 then it is from Soviet Union
archives. I do believe Vesselin will be able to provide better english
description what I am talking about.
Andrzej Kadlof
Department of Mathematics, University of Warsaw
Editor-in-chief of PCvirus Bulletin
------------------------------
Date: Sat, 23 Nov 91 14:09:01 +0700
>From:
[email protected]
Subject: Re: Dir-II removal (PC)
In VIRUS-L 4/224
[email protected] (Vesselin
Bontchev) writes:
> The only three
>methods for removing this virus which are currently availble, are
>CLEAN 84, my program DIR2CLR, and using the REN method, described by
>Andrzej Kadlof (similar to your backup method, but much easier and
>faster).
In Poland there is known the fourth method and as far as I known the
best one. This is DIR2CURE.COM - program written by Marek Sell. This
program hes been published in PCvirus 5(6)91.
The problem with the first three method is that they work only when
wirus is present in the system. Not necessary active (first two methods)
but present. About two week ago I have had to clean Compaq Portable III
with Compaq version of DOS 3.31. The problem is that Dir-II is able to
install itself in memory of that system but is not able to write itself
to disk. (I do not know why.) So my problem was to restore disk to its
original state without live virus in the system. CLEAN v84 simply
reported that there is no virus in the system. That was true. Vesselin's
DIR2CLR was better as it reported new variant of Dir-II (due to the
garbage in the last two sectors of HD). Method with renaming files is
not applicable without Dir-II active in memory.
Marek program is the only one I known, which can restore disk without
detecting virus on the disk. I understand, that today, when we have two
new variants of Dir-II (which I do not know yet), such a program may be
as dangerous as CHKDSK is. (Restoring is possible only if the user
decide to take the risk.) But it falls into general question how to
restore disk encrypted in some way by virus, which deleted itself after
final attack and there is no way to exactly decided which particular
variant is responsible for all the mess.
Andrzej Kadlof
Department of Mathematics, University of Warsaw
Editor-in-chief of PCvirus Bulletin
------------------------------
Date: Sat, 23 Nov 91 14:09:03 +0700
>From:
[email protected]
Subject: Virus Verification and Removal
In VIRUS-L 4/224 "David.M.Chess" <
[email protected]> writes:
>The November 1991 issue of Virus Bulletin has a paper by me on the
>above subject. It talks in general about verifying the identity of a
>virus (why and how), and attempting to remove viruses from infected
>objects (why, why not, and how); and it talks about the prototype
>program that we have to do these things. The program is basically a
>little interpreter for a high-level language that describes viruses
>for verification and removal purposes. I know various other folks
>have done similar things, and we hope that this paper will stimulate
>discussion (and/or bragging!) on the subject.
I am very happy that this subject is at last raised. I have never been
able to understand how people can discuss about viruses (even about
very specific technical details) without certainty that they are
talking about the same. I think that the question of unique virus
recognition is very important and should be solved as soon as
possible.
Some job in this direction has been done in Poland. One year ago we
have started to publish PCvirus bulletin. One of the main idea of
PCvirus is to give people so exact virus description, that they could
be able to write safe cure. The major problem is of course unique
virus identification. We use so called Virus Identyfication Card,
which contains many general information and the most important, Virus
Map.
Virus Map is the main tool for virus identification. It consist of a
series of numbers and is build in the following way:
After the detailed analyze of virus, its body is divided into disjoint
blocks. Each block is classified into one of the four categories: V -
virus code, W - working area, C - constants and G - garbage. Working
blocks we are ignoring. For blocks of type V, C and G we publish they
offsets in virus body and set of control sums. Additionally, if given
block is longer than 256 bytes, we divide it into smaller parts (of at
most 256 bytes each). We olso sometimes publish dumps of blocks of
type C or G if they can help during visual inspection of the
suspicious file. For example the map of the virus Stoned is:
offset block type length control sums
- ------------------------------------------------------------------------
0000 ( 0) virus code 8 AE0C
0008 ( 8) working area 13
0015 ( 21) virus code 373 907F 82ED
018A ( 394) constants 46 E34B
dump: 59 6F 75 72 20 50 43 20 69 73 20 6E 6F 77 20 53 Your PC is now S
74 6F 6E 65 64 21 07 0D 0A 0A 00 4C 45 47 41 4C toned!.....LEGAL
49 53 45 20 4D 41 52 49 4A 55 41 4E 41 21 ISE MARIJUANA!
- -------------------------------------------------- 0001C178:0002A4C3 ---
Control sums are computed with the algorithm used by the Polish
Section of Virus Information Bank.
Of course the algorithm for computing control sums is published. I
know that above method is not perfect. It is possible to write virus
for which such a map could not be constructed. I call such a virus
'second generation virus'. However, after one year of experience, all
viruses found in Poland in wild (about 100) falls into the class
'first generation virus'. Even selfencrypted viruse like Tequilla or
1260 (this one is not reported in Poland yet) has its map. Map for
such a virus is build after decryption of its code.
I know that similar concept has been developed by Vesselin Bontchev.
Any comments are kindly welcome.
Andrzej Kadlof
Department of Mathematics, University of Warsaw
Editor-in-chief of PCvirus Bulletin
------------------------------
Date: Sat, 23 Nov 91 10:29:00 -0500
>From:
[email protected]
Subject: Radai re: Frisk, re: Washburn
Y. Radai:
> I suppose, however, that you meant people who have released viruses
>publicly, not just for test purposes.
Well, perhaps. However, the important word is "released."
>True, Washburn released a virus
>publicly, but many of us distinguish between writers of deliberately
>destructive viruses and those of non-destructive ones.
I believe that you do but that such a distinction is not as significant
as you believe.
>And Mark's viruses are not destructive.
Patently false.
>True, someone else used his virus to create
>a destructive one, and mainly because of the possibility that this
>would happen, Washburn's decision was a mistake.
It was indeed a mistake, but not only for the reason that you cite.
>But perhaps he has realized his mistake?
Perhaps. However, we must, in our own collective interest, punish the
behavior, without regard to its perpetrator, his intent, or subsequentot his me
aning. I believe that he
intended exactly what he said. We should ignore, indeed we should
ostracise, any and all who intentionally or knowingly release a virus.
The only thing about the intent of such an author is the intent to
release. That is at least reprehensible. I think that Mr. Skulason
would agree with me that it should be punishable, at least within the
cognoscenti, if not under the law.
Between getting Mr. Washburn's virus on my computer and getting one of
its progeny, I would prefer Mr. Washburn's. But that is not the issue.
The author of this posting clearly believes that the intent of the author
is important; it is not.
Between having Mr. Washburn's program, it's progeny, or any other virus
in the population, there is little to choose. ALL VIRUSES ARE
DESTRUCTIVE OF TRUST.
The persistent belief that there is something significant to choose
among viruses, based upon their behavior in the execution environment,
as opposed to their behavior in the population, is used by the ignorant,
the reckless, or the irresponsible as justification for releasing
viruses which they believe or assert to be benign in their intent.
We have known for a long time that achieving the intent of the author of
a program in a known execution environment is extremely difficult.
Achieving that intent when the environment is not known is rare. It is,
at best, accidental. That is, it is independent of his intent.
While the author of a virus can be expected to know a little bit about
the machine in which some copies of his creation will execute, he cannot
know about all of them. While he may may be able to predict how it will
behave in a particular machine, he can only speculate as to how it will
behave in a population, all the salient characteristics of which he
cannot possibly know.
To assert otherwise is hubris. We would do well to remember how the
god's punished Pandora.
I responded to this posting without noting its source. Only when I was
through did I check on its source. Imagine my chagrin to when I noted
the name of its author.
William Hugh Murray, Executive Consultant, Information System Security
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840
203 966 4769, WHMurray at DOCKMASTER.NCSC.MIL
------------------------------
Date: Fri, 22 Nov 91 13:39:37 +0000
>From: Technician <
[email protected]>
Subject: Taxonomy tool?
After look at the posting relating to taxonomy, I've a suggestion
using the same approach that is used by some genetisists to analyes
DNA relationship. The method is simply based on the op codes, and
gives a visual comparison of two virus code sections.
The method is dot matrix analysis, and works as show below.
Each op code (see foot note) of Virus A is compared against all the op
codes in Virus B, and a dot is placed where a match is found. This
gives a visual representation of how well the two code segments
compare. It will also show re-arrangment of the code ie moving a
routine within code, insertion ie extra code and deletion ( it will
also show data being reversed - text perhaps to fool scanners?).
eg:
A B D E F K L W L T Y P W S C H F S Q E T S Y U Y U S < - Virus A
A *
B *
D *
E * *
F * *
H *
J
Y * * *
U * *
S * * * *
W * *
G
I
O
P *
W * *
S * * *
C *
F *
S * * * *
^
\ Virus B
As you can see, the two stings of letters have areas of similarity,
denoted by the lines of *'s going down left to right, on a real DNA
string, the lines are much more pronounced, and the background has the
look of a star field, but for the purposes of a simple ASCII
representation, I hope you can see what I mean (I don't have any virus
strains to test this out on - and no I don't want any, just an
observer, not a virlogist).
Please note, I suggest this as a visual method of getting a good idea
of how related viruses are, producing a true taxonomy is something
else, in which this method might help, but exactly how or if, I'll
leave upto the real experts.
Jim Cottrell - Software Technician and former biologist,
Computer Science, University of Durham
[Foot Note - you can compare more than one opcode at a time, ie put a
dot only if two adject op-codes match, or 4 out of a window of 5, them
move on one.....]
------------------------------
Date: Sat, 23 Nov 91 12:39:53 -0700
>From:
[email protected] (Tim Martin; FSO; Soil Sciences)
Subject: Empire Virus Update (long) (PC)
I came across another variant of "Empire" yesterday, and realized I
haven't been keeping the news groups up to date on what we know about
this virus "family". (Yesterday's variant isn't new, chronologically,
it is simply the first time we have captured this particular variant.)
Empire Virus Update
- -------------------
The "Empire" viruses are boot sector viruses, derived from "Stoned".
Evidence suggests that the virus writer started modifying Stoned in
the fall of 1990, at the University of Alberta. At least the U of A
computer labs were where the virus was released to the world. The
last known variant was released on July 10, 1991. A total of 18
variants have been identified to date. These 18 variants are variants
only in the strict sense: they have differences in the code --
sometimes only one or two bytes -- which virus scanner writers should
know about, and which indicate separate programming efforts on the
part of the virus writer. The rest of us can think of them all as one
"species". Fred Waller, you can think whatever you wish, of course!
:)
All of these variants (but the one I found yesterday) are already in the
collections of MacAfee, Frisk, Dave Chess, and other virus protection
software writers. If you are using their latest scanners, you should be
ok, though only FPROT seems to recognize all the variants.
Some of the Empire family are really only very slightly different from
the Stoned virus. These are probably from last fall. The only variants
that we are sure were written since April 1991 are what I call Empire C
and Empire D. These variants are designed as responses to virus detection
schemes we put into place in response to the earlier variants.
Empire C gets around the simple "chkdsk" test for boot sector viruses.
Since most boot sector viruses have to reduce the number of "Total bytes
of memory" of a computer, to hide at the top of memory, the virus can be
detected by seeing whether "chkdsk" returns 1k or 2k less than it
is supposed to return. Empire C simply didn't bother telling DOS that
the virus was present in memory, when it installed itself. It put itself
at 9000:0000 or 8000:0000 and functioned until something else used that
memory location, then the system crashed. This virus shouldn't get far
beyond U of A, but it has some virus-illiterate PC technicians in
Edmonton scratching their heads.
Empire D was a response to our installation of "Disk Secure" (from Padgett
Peterson) in our computer labs. Empire D recognizes the presense of
Disk Secure on a computer and removes it before infecting the computer.
Of course we told Padgett about this within minutes of our discovering it,
and he reached back into his collection of backup Disk Secure variants,
developed and held in reserve just for such a contingency. Does Padgett
ever miss anything?
Seems at this point the virus writer gave up. :)
Unfortunately the Empire virus variants are now the most common viruses
at U of A and in the Edmonton area. The difficult challenge now is
to teach the campus community how to recognize the virus, how to stop
it, how to remove it. From Nick Fitzgerald's experience with the
original Stoned, in New Zealand, I'm not too hopeful.
Some characteristics of Empire variants:
1. Three have an algorithm for "data diddling", and thus are
"intentionally" malicious.
2. Almost all will cause 3.5" disks to be confused about their
format, thus APPARENTLY causing data loss. In fact the data
can be recovered, by copying a proper 3.5" boot sector
from the same format back into place, so the system can figure
out what kind of diskette it is reading.
3. On hard disks, the virus infects the first sector (where the main boot
record should be), and copies the MBR to sector 3, 6, or 7, depending
on the variant.
4. On a floppy disk, the proper boot sector is moved into the directory.
Most variants move it to side 1, sector 2 or sector 3. On a 360k
diskette this is near or at the bottom of the root directory, so it
rarely causes data loss. But on higher densities, it is near or at
the beginning of the directory, and is much more likely to wipe out
directory entries. Of course the FAT, and the files themselves, are
not altered: "chkdsk /f" should permit recovery of the files.
Unfortunately current virus detection software cannot always remove
the Empire virus from floppy disks. The best method I have found is
to do the job manually using Norton Utilities -- I still use version
4.5, I'm not sure why. I simply find the boot sector manually and
copy it back into place, thereby clobbering the virus. Or else I copy
the boot sector from a "like" floppy. To finish the job, the sector
where the boot sector was hidden (somewhere in the directory) should
be zeroed out, so the system doesn't get confused when reading the
directory.
5. The name "Empire" is appropriate only for the first recognized variant,
the one with the "Evil empire" message. The common textual theme
throughout the others, usually contained in non-displayed, sometimes
encoded strings, is "PC loves AT". ("Love" is often represented
by a 03h, the heart character in IBM ascii.) Several variants have
references to U of A as well; one has the encoded string "Canadian".
Only a few of the variants ever display messages to the screen,
some only when the hard disk first becomes infected.
6. Most variants are 1 sector long. A few take up part of sector 2
on a hard disk, to make room for the partition table data, but use
only the one sector on a floppy, where the table isn't required.
The "Empire A" variant needs a second sector for its encoded message.
7. Most variants begin with the command string EA 9F 01 C0 07. Other
initial jump command strings are EA A1 00 C0 07 and EA A7 01 C0 07.
8. Most use self-encoding, so that only these first 5 bytes, and the
decoding algorithm jumped to (about 24 bytes) stay recognizable.
Actually this makes it possible for scanners like F-PROT to find
variants that haven't yet been isolated: most of the Empire variants
are identical in their non-encrypted bytes.
9. Most of the Empire variants use stealth. They simply reroute all
INT 13 "reads" from hard disk side 0 cylinder 0 sector 1 to sector
3, 6, or 7, where the real MBR was put. They cancel any INT 13
request to write to 0,0,1. This technique is simple, but relatively
effective. If I think an Empire virus might currently be in memory,
controlling the computer, I find the easiest test is to use debug to
look at the memory locations 9FC0:0, 9F80:0, 9000:0 and 8000:0. For
example, this helps ensure that a "clean reboot" really was clean.
A second way to help insure that the diskette you rebooted from
really is clean is to use debug to look at the boot sector of that
diskette: the Empire stealth applies only to the hard disk partition
table.
10. Currently my naming scheme for Empire variants is not very logical.
I hope the people working on naming conventions will simply come up
with a numbering scheme for variants, that we will then standardize
on. They may decide that at least three of the Empire variants
should simply be called variants of Stoned: only the later ones
really deviate significantly from their stoned roots.
11. An interesting task I haven't had time to get at is to try to figure
out the chronological sequence of the earlier variants, from the code.
Some of them are obvious, others are not. Vesselin, Fred: A new field
of Science: Computer-Virological Archeology! :)
Here's hoping this ends the saga of the Empire Virus.
A Thank You Note:
If anyone deserves credit for stopping the Empire viruses in the U of A
labs, it is Padgett Peterson. A public, formal thank you, Padgett.
While I am at it, Frisk should be thanked for his prompt response and his
excellent software: we swear by FPROT here: it is the only thing I have
that recognizes ALL the Empire variants. (Protection writers note:
complementary test software can be sent to the address below! :)
Tim.
-------------------------------------------------------------
Tim Martin *
Soil Science * These opinions are my own:
University of Alberta * My employer has none!
[email protected] *
-------------------------------------------------------------
------------------------------
End of VIRUS-L Digest [Volume 4 Issue 226]
******************************************
Downloaded From P-80 International Information Systems 304-744-2253
