From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
Newsgroups: comp.virus
Subject: Re: network security
Date: 5 Oct 92 12:13:14 GMT

seborg@csrc.ncsl.nist.gov (Brian Seborg) writes:

> surprised that the virus was different.  As for 1963 having
> "nothing in common" with the Dark_Avenger virus, I will leave you
> to argue this out with Patricia since she seems to disagree with
> you here. 

I have myself disassembled 1963 completely. Simultaneously, in my
contacts with Patricia Hoffman I came into conclusion that she is not
able even to -read- the well-commented virus disassemblies sent to
her, let alone to disassemble a virus herself. Sorry, but I will even
not argue with her on this subject.

> my posting!?!  I am not sure why you wasted the band width to
> revisit this since it was obvious to any reader that no definitive
> answer was being provided.

Because I saw a claim which I knew was wrong, so I decided to post a
correction, in order to prevent the readers from getting false
knowledge about this particular virus. I definitively do not consider
this a "wasted bandwidth".

> While I must agree that VSUM does have its share of errors, and
> provides little in the way of "down and dirty" technical
> information, I still believe it is a good reference for ball-
> parking whether you have a particular virus or not.  I have to

No, this exactly what it does not provide. It might have been useful
when SCAN used to identify viruses better, since then VSUM contained
the name that SCAN gave to the particular virus. Nowadays SCAN is
completely useless for virus identification and the virus names in
VSUM do not have even this value.

There is nothing in VSUM that really helps you identify which virus
you have. No virus maps for exact identification. No cross-reference
between the names that the different products use. No correct
technical information. Even such basic information, as the virus
infective length is sometimes wrong. Several of the listed viruses do
not exist (I know, I have the files appropriate files from Patti's
collection). Several viruses are listed twice or more times, under
different names - and curiously - with different properties. For most
viruses it is said "It is not know what the virus does besides
replicate" - even for those viruses, for which the name suggests what
they are doing...

My (wild) guess is that the information in VSUM is a combination of
what Mrs. Hoffman has been told about the virus and what she has
observed when running the virus on a sacrificial system.

> admit that I prefer the descriptions put out by Brunnestein's
> students (including you) for accuracy, although the user-
> friendliness of the lists containing these descriptions leaves
> something to be desired.:-)

I know, I know... :-) We are working on the subject...

> >Astra viruses infect only device drivers. Some viruses (Tequila
> >and StarShip, I think) will not

> Wrong about Tequila, it infects just fine. 

Well, I wrote "I think", didn't I? I was not sure, because I didn't
have the disassembly of the virus in front of me.

> Remember, it is a multi-partite virus and it does go TSR.

So is StarShip, yet it works exactly in the way I described. And I
don't just "think" this time - I -know- it.

> >infect, if you don't have a hard disk - because they don't go
> >resident when you run an infected file, but only modify the MBR
> >and wait until the user reboot... There are some other pitfalls.
> > We have a huge amount of files here, about which we cannot easily
> >decide whether they are viruses, trojans, buggy programs, or just
> >innocent tools.  They all refuse to replicate on the systems we
> >have tested them, but this does not imply that they will not
> >replicate on some other 

> But this does imply that they are unlikely to represent a threat
> since there survival is unlikely.

Huh, as far as I remember, the question what exactly represents a
threat has not been mentioned neither in your message, nor in my
reply. You were just listing a few methods how to determine whether
what you have is really a virus or not, and I pointed out that in some
cases it doesn't work. That's all.

> >systems. The only way to solve the problem is to disassemble each
> >one of them and see what it does. And this is a LOT of work...

> No disagreement here.  Disassembly is obviously the best solution,
> however, many users are not assembly programmers, and are unlikely
> to be able to dis-assemble the virus.  Also, in cases where the

In this case I am not speaking about the users - they don't have to
bother with all those "unknown" files from our collection. I am
speaking about us, and we -are- both good assembly language
programmers and able to disassemble a virus. Gosh, we are doing this
all the time; we are even teaching the students how to do it... My
point was that it is a lot of work - for us - to disassemble all those
files. And this work is low-priority, because we have to deal with
lots of viruses every day that -do- replicate perfectly...

> user notices changes in files (like the one we are speaking of) my
> suggested technique works well.  I never said that it was "the only

Your suggested technique sounded (to me, at least) as a general
approach for dealing with viruses. It is indeed useful as such, it
just needs to be updated and refined, what I believed to do with my
message. Sorry for any misunderstanding.

> virus.  Also, continually bringing up viruses which have "new" and
> "different" techniques that have often never been seen "in the
> wild", or which are only the product of an active imagination may
> be a useful academic exercise, but let's put some statistics next
> to these viruses you have noted. 

I strongly disagree with you here. To constantly bring up new
"research" techniques here definitively has a beneficial effect. Here
is one example. The Dir_II virus is -extremely- spread in Bulgaria.
More than 90% of the requests for help to my Lab there are for this
virus - they have documented statistics about this. Yet, I made a lot
of fuss about this virus here, so now most of the popular scanners are
able to detect it (McAfee's CLEAN can even remove it), and we
succeeded to prevent the wide spread of this virus in the West.

Second example. I made a lot of fuss about the MtE, so not several
scanners are able to detect it. When I was in Bulgaria this summer, I
met a virus writer and asked him whether he intends to use the MtE.
The answer was "Why bother, even McAfee can detect it!". The truth is
that SCAN does not detect the MtE reliably, but so what... The
important thing is that we prevented a wave of MtE-based viruses.

> Have they infected any computers
> at all other than in the lab?  Let's be reasonable!?!  I act as the
> CERT for a network with over 350 servers, and 10,000 nodes.  In
> addition, we have over 3000 lap-tops.  If I were "fishing" for

My Lab in Bulgaria is basically the only official anti-virus
supporting team in Bulgaria and they have almost half a million of PCs
in that country. This, combined with the fact that several people
consider writing and/or releasing a virus there to be some kind of
entertainment, leads to some unexpected results...

For instance, I have seen myself Anti-Pascal.605 in the wild -
combined with Cascade. If you have ever disassembled this extremely
stupid virus, you'll understand my surprise.

Also, can you believe that I spent almost a week hunting for Kamikaze
- - a silly overwriting virus that should never spread at all? (I
finally nailed it using an integrity checker, but this is another
story, which I could tell you if you are interested.)

> a virus.  I think it's time we started being realistic about the
> actual threat from these viruses.

No disagreement here, although we probably interpret the above
sentence differently...

Regards,
Vesselin
- -- 
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
< PGP 2.0 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany