Hacker 2/HACKER2.mdf/virus/virusl2/virusl2.18

Text File | 1995-01-03 | 15KB | 299 lines

VIRUS-L Digest            Wednesday, 18 Jan 1989        Volume 2 : Issue 18

Today's Topics:
Re: The Ping-Pong virus (PC)
Re: Boot sequence (PC); Discretion
Init 29 virus (Mac)
Macintosh INIT 29 virus - brief description (Mac)
suspicious file
Worm paper in nroff (Internet)

---------------------------------------------------------------------------

Date:        Tue,  17 Jan 89 15:06:39 +0200
From:        Y. Radai <[e-mail]>
Subject:     Re: The Ping-Pong virus (PC)

  Eldad Salzmann asked about the Ping-Pong virus.  It is a virus
which first appeared in Israel about three months ago, and which got
its name because of a bouncing point which appears on the screen.
Like the Brain virus, it resides in the boot sector of disks, in bad
sectors, and in high RAM.  (Since I haven't heard of any reports of
its appearence anywhere else, I presume that it originated in Israel,
probably in the Tel Aviv area.)
  Among the points in which it differs from the Brain virus: (1) It
infects hard disks, not only 5 1/4-inch floppies.  (2) It marks only
two sectors as bad.  (3) It grabs only 2K of high RAM.  (4) To the
best of my knowledge, it does not cause any damage to files or to the
FAT.  In particular, the bad sectors seem to always be chosen from
unused clusters.
  As to Eldad's question about the possibility of a connection between
the Ping-Pong virus and his WordPerfect problem, I strongly doubt that
there is any.
  No, there is no panacea against viruses.  However, the same program
UNVIRUS which was originally written to eradicate the "sUMsDos"
(Friday-the-13th) Israeli virus, and was later extended to three other
Israeli viruses, has also been extended to eradicate the Ping-Pong
virus, both from the disk and from RAM.  (The author of all versions
of UNVIRUS is Yuval Rakavy.)

  I said above that points (1)-(4) were supposed to be in contrast to
the Brain virus, but actually I'm not at all sure what the latter does
with respect to point (4).  I have read (A) that it isn't at all des-
tructive; (B) that it "has been hacked ... into a very malignant form
which can infect hard disks and which destroys FAT entries, deletes
files, and performs other malicious activities" (quoted from the
InterPath document); (C) that is is destructive only to the extent
that it may copy its code to sectors which may belong to existing
files.  Obviously, each of these descriptions may be correct for a
different strain of the virus, although sometimes the reports contra-
dict themselves even when talking about the *same* variant (e.g. with
respect to that which hit the Univ. of Miami).  In any case, can any-
one verify from *actual first-hand experience* that there is a version
of Brain which is destructive in sense (B)?

                                           Y. Radai
                                           Hebrew Univ. of Jerusalem

------------------------------

Date:        Tue,  17 Jan 89 17:10:21 +0200
From:        Y. Radai <[e-mail]>
Subject:     Re: Boot sequence (PC); Discretion

Concerning the boot process on the PC, Dimitri Vulis writes (V2#10):
>                                  Certainly, one can mess around with
>a disk and create one that won't boot, because IBMBIO.SYS is not at
>the beginnig. This would require some (a little) conscious effort and
>cannot easily be done with just FORMAT/S or SYS. I was describing a
>successful boot, in which the file is read into memory.
  (1) I wasn't assuming a disk which wouldn't boot, since IBMBIO.SYS
does not have to be at the beginning of the disk in order for it to
boot.  If another program has been placed there (e.g. by a virus), it
would be executed first, but it could terminate with a transfer of
control to IBMBIO (which has been relocated elsewhere) in order for a
successful boot to take place.  (2) Even if Dimitri intended to des-
cribe only normal boots, it is more accurate to say that the boot rou-
tine loads certain sectors than that it loads certain files, and my
correction was intended to convert his description from one which is
correct only in the case of normal disks into one which would be accu-
rate also for altered disks (assuming, of course, that the boot rou-
tine itself has not been altered).  (3) Although my correction may
seem trivial to some readers, I have reasons for considering it to be
quite significant for certain purposes.

  Another (not very important) point:
>     if the disk has IBMBIO.COM and IBMDOS.COM as the first files in
>the directory, (and finding that takes room too) and if they are
>hidden/system, then the code assumes that the disk is OK ....
  I once removed the hidden and system attributes from IBMBIO.COM and
IBMDOS.COM on one of my diskettes, yet I was still able to boot from
it.

  In his reply concerning the false-sense-of-security issue which I
raised, Dimitri has clarified what he meant by discretion.  Among
other things he writes:
> I don't download software from BBS's anymore (too bad) ....
  Yes, it certainly is too bad.  I continue to download software
(mainly from the SIMTEL20 archives).  One reason that I feel relative-
ly safe doing so is that I try out all new software on a separate com-
puter (I realize, of course, that this facility is not available to
everyone), and I don't transfer the new software to the hard disk of
my ordinary computer until several weeks (sometimes even months) have
elapsed, during which time I check for suspicious activity by means of
the programs I mentioned earlier: FSP, PROTECT, and (most important)
the checksum program in order to see if anything on the disk is get-
ting altered which shouldn't.  (I use the same programs on my ordinary
computer too, of course.)  Also, I simulate dates in the future just
in case the software contains a time bomb with a long delay.  (Yes, I
know, even then I can't be *completely* sure, but I don't mind taking
the risk.)
  Secondly, Dimitri has mentioned ads which claim 100% protection from
viruses, and he has discussed the exploitation by crooks and gonefs of
"dumb ignorant people", "complete idiots" and "very stupid and igno-
rant individuals".  However, I don't find that he has given a direct
answer to my main question: Why can't we use *both* anti-viral soft-
ware *and* discretion?
                                           Y. Radai
                                           Hebrew Univ. of Jerusalem

------------------------------

Date: Wed, 18 Jan 89 11:39:10
Resent-From: [e-mail]
From: Confusion's Drummer <[e-mail]>
Subject: Init 29 virus (Mac)

Here's an extract describing the Mac INIT 29 virus from Laura Lemay
at Carnegie-Mellon University.

 --- Joe M.


1.  To answer your question on Virus-L...init 29 is NOT hpat.  Hpat is
a near-clone of nVIR B (the 422-byte, code 256 version that says
"don't panic"), except the code is 255 instead of 256, and I think the
byte-size has changed.  Rumors are still flying. {Several new repair
programs are available, but have not yet been put out on the SCFVM
server. They will be announced and sent to the Simtel-20 and Info-Mac
archives when they are installed.}

Init 29 is an entirely NEW virus.  It is tiny (1/2 k!)), and the only
sign it exists is an INIT (29, wonder of wonders) that starts popping
up in everything.  SO far, the only side effects I've heard of is that
it gives "disk needs minor repairs" errors while trying to mount TOPS
volumes.

The really evil thing about INIT 29 is that it doesn't need a program
to be run in order to spread.  It starts infecting the moment a disk
is inserted in a drive!  In this way, an idle hard disk can be
infected completely in a short amount of time.

Oops - I just found another note about INIT 29....it adds CODE
resources to applications, and INITs to everything else.  Both are 712
bytes.  I don't know what number the code is -- they didn't mention it
in the note.  Protected code 0's foil the virus (as they do in nVIR
and scores).

VirusDetective (tm) and RWatcher can be modified to look for it
(search on INIT 29 and code size 712). New versions of Vaccine,
Interferon, and Virus RX either have appeared or will appear soon.
{New Vaccine is out; haven't seen a new Interferon yet; new Virus RX
is out and available at SCFVM.}

I hope I haven't sounded too confused -- there are still a lot of
rumors flying around.  All my info comes from a friend at apple who
pulled it off of mac link.

If you want to post this info on virus-L, please do.  For some reason,
I don't have access to the group or to the moderator.  Sigh. {Any
ideas, Ken?}

Laura Lemay
[e-mail]
Carnegie-Mellon University

[Ed. She does now...welcome to VIRUS-L, Laura.]

------------------------------

Date: Wed, 18 Jan 89 14:05:52 -0500
From: Joel B Levin <[e-mail]>
Subject: Macintosh INIT 29 virus - brief description (Mac)

Here is a brief overview of the recently seen INIT 29 virus.  I have
disassembled it and this represents a summary of what I have discovered.

* PLEASE NOTE: Where I describe what this virus does or does not do, keep in
* mind the phrase "AS FAR AS I KNOW."  I have looked at all the code in the
* virus, but I'll not guarantee that I have seen everything that there is to
* see in it.

First, the good news: it appears to have almost no harmful side
effects (files destroyed, beeping, and the like).  If it can't do
something it generally does nothing.  All its code is devoted to the
task of propagating itself.

So the bad news: it is very good at propagating; I would agree with
those who term INIT 29 virulent.

INIT 29 is a single 712 byte resource which installs itself into
non-applications as (you guessed it) INIT 29, and into applications as
a CODE resource.  There are no ancillary resources such as those used
by nVIR (and Hpat), so it is somewhat less noticeable using ResEdit,
say.

The INIT works by patching a trap, OpenResFile.  (If it detects that
another copy of itself has already patched OpenResFile, it does
nothing.)

The patch to OpenResFile is a tail patch; i.e., it calls the routine
at the address previously dispatched to by OpenResFile, then does its
dirty work on the resource file just opened.  This, basically, is to
copy itself into that resource file if it was not previously infected.
If the file has no CODE resources, it copies itself in as INIT 29.  If
the file does have CODE resources, it writes itself into the file as a
new CODE resource with the previously lowest unused resource number.
It patches the jump table in CODE 0 so that it is called before the
application proper is started.

When an infected application runs, it examines the system file for
INIT 29.  If the system is infected, it just starts the application
proper; if not, it first adds itself as INIT 29 to the system file.

The only overtly destructive thing this virus does is to remove and replace
any legitimate INIT 29 which may have been present in the file before the
infection attempt.

Because it patches the trap that it does, any resource file which is
opened once this INIT has run at boot time will become infected: your
Desktop file will have a copy of the INIT; all your INIT files may
have it; your EDIT text files will have it.  Just examining a resource
fork with ResEdit is sufficient to add it, either as the INIT, or
patching in the new CODE.

The VirusDetective DA can detect it; Apple's Virus Rx 1.4a1 appears to
flag it (though it doesn't say why it thinks a file is bad).  Other
virus programs may or may not catch it, and I don't know if any can
repair it.  Removing the INIT 29 resource should be safe; however, DO
NOT try to repair applications by removing the offending CODE
resource, as there will still be a patched jump table entry pointing
to that resource.  I do not know at this time if Vaccine, RWatcher, or
any of the other infection attempt detectors will catch this.

------------------------------

Date:         Mon, 16 Jan 89 11:27:42 EDT
From:         "W. K. (Bill) Gorman" <[e-mail]>
Subject:      suspicious file

I have a user who has a suspicious file on the disk. It has a filename
consisting of what looks like random alphanumeric characters, no
extension, and shows a size of zero in the directory. Further, it
shows up on a normal DIR listing, but cannot be deleted by either DOS,
NORTON or a couple of other things. NORTON thinks, judging from the
first character in the fileneme, that it is a deleted file... but it
still shows up on the normal DOS "DIR" listing. The user says there
were a bunch of files out there like this one, but they were all
deleted except this one.

I am wondering if this might be a viral footprint?

.............................................................................
|W. K. "Bill" Gorman                 "Do             Foust Hall # 5         |
|PROFS System Administrator        SOMETHING,        Computer Services      |
|Central Michigan University      even if it's       Mt. Pleasant, MI 48858 |
|[e-mail]                wrong!"         [phone]         |
|_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_|
|Disclaimer: These opinions are guaranteed against defects in materials and |
|workmanship for a period not to exceed transmission time.                  |
|...........................................................................|

------------------------------

Date: 18 January 89, 14:12:44 EST
From: Jeffery K. Bacon     <[e-mail]>
Subject: Worm paper in nroff (Internet)

Quick note on the "Tour of the Worm" file for Otto (and others):

In the nroff source, there IS a copyright note. However, considering the
thing was put up for anon ftp...

I'm sending Otto a reformatted version of the file...

- -JB

[Ed. Thanks Jeff.  Having never really looked at the nroff source (I
only printed the .CRT file), I never noticed the copyright notice.  I
just looked at it now, however, and it does say "Copyright 1988 by
Donn Seeley, all rights reserved".  Anyone who wishes to use this
report (a very informative one, by the way) should get permission from
Mr. Seeley.]

------------------------------

End of VIRUS-L Digest
*********************
Downloaded From P-80 International Information Systems 304-744-2253