[comp.virus] IBM Virus

consp21@bingvaxu.cc.binghamton.edu (Ken Hoover) (09/22/89)

[Ed. This message was forwarded from the BITNET mailing list, EXPERT-L.]

Original-Date:         Mon, 18 Sep 89 17:38:00 EDT
Original-From:         Sanjay Hiranandani <GDO@CRNLVAX5.BITNET>

On Friday morning at 8:00 AM, I came into the Sibley facility, sat
down at IBM #18, and invoked Foxbase.  Instead of the familiar welcome
screen, the machine hung.  Other pieces of software throughout in the
facility had recently quit working for no apparent reason.  Gregg said
"I think there might be a virus here," (or words to that effect); from
that time to now, Gregg and I have spent most of our waking hours
trying to figure this out.  This comes at a specially bad time for
Gregg because he's in the middle of training new operators and so on.

    Here is a brief summary of what is now known about the virus:

    1.  Approximately seven of the Sibley facility's IBM PS/2's have
been found to be infected with a highly contagious IBM virus "time
bomb".  Gregg and I have developed a reliable test for the program and
will soon complete its eradication from the facility.  Some users'
personal applications and disks, however, are probably infected.

     2.  The DMPC program (disk manager) which is intended to restrict
users from copying or deleting our software, is effective in
protecting programs from being corrupted -- but only for those
programs for which DMPC has been properly configured to monitor.

     3.  The virus rewrites *.EXE and *.COM files with many changes
including the virus code itself.  In most cases, these changes are
tolerated by the program and it continues to work.  In the case of Word
Perfect (WP.EXE) and Foxbase (FOXPLUS.EXE), the changes make the program
completely nonfunctional.  In other programs, small difference are
noticed: small rectangles of the screen display may get misplaced, for
example.

     4.  An infected *.EXE file can be recognized by the hex string
10078419C5, a five byte string which apparently takes over the 21st
through 25th bytes near the beginning of the file.  This is not the
only change, but it is a consistent one.  Infected copies of WP.EXE,
FOXPLUS.EXE, APL.EXE, ED.EXE, NU.EXE, etc., etc., all had this same
string in the exact same location.  No uninfected software had this
string anywhere.  Uninfected IBM's had no sign of this string anywhere
on their hard disks.

     5.  This same string also occurs in what appears to be the virus
code itself, which is written to the "slack area" of *.EXE files
between the end-of-file and the end of the file's actual allocated
disk space.  Often, maybe always, the end-of-file marker is
overwritten.  Secondly, a certain fixed distance after the occurence
of 10078419C5 is the ascii text "COMMAND.COM", a further clue for
identifying this virus.

     6.  Files modified by the virus show NO SIGN AT ALL of any change
to the DOS directory command.  The number of bytes and the date and time
of last modification are unchanged, when in fact a file is infected.

     7.  When a file is fragmented on the disk, individual fragments may
become separately infected.

     8.  Setting a file's attributes to "read-only" or "hidden" does NOT
protect it.

     9.  Setting the write protect tab on a diskette appears to
protect diskettes in the 3.5" drives at Sibley.  Executing a program
from a locked 3.5" diskette on an infected machine generates a "Write
protect error writing drive A" message.  The program on the diskette
remains uninfected.

     10.  When an infected machine's internal clock-calendar is
changed to register a date of 10-13-89 (Friday the 13th), all *.EXE
and *.COM files will DELETE themselves when a user tries to execute
them (for example, if a user types WP, for WordPerfect, the WP.EXE
file would be deleted, and the message "Bad command or file name"
would be displayed on the screen).  This condition applies when the
system date is 10-13-89, but not 10-12-89 or 10-14-89 (we speculate
that it may apply to every Friday the 13th, but this has not been
tested).  Attempts to execute a program from an unlocked diskette will
cause the deletion of the program, regardless of whether it was
previously infected.  The virus deletes programs in a normal fashion,
and these files are probably recoverable.  Of course, all these
recoverable files are infected anyway, and not really worth recovering
(unless the virus begins to kill data files as well).

     11.  When the system date is 10-13-89, the virus attempts to
delete DMPC-protected software (the warning bleep sounds), but fails.
Such programs continue to work even on machines heavily infected with
non-DMPC protected software.

     12.  After working all day Friday fighting this virus, I spoke
with my girlfriend, who had heard something on National Public Radio
about a virus which becomes active on October 13.  In the meantime,
Gregg heard a rumor about an October 12th virus.  From a friend in
Michigan, I heard about an October 12th virus which supposedly would
attach itself to *.COM files and disable the hard disk by overwriting
track 0.  I don't know whether these other reports are of the same
exact virus (with a few wrong facts), or whether there is some
national "collective action" to write lots of different viruses which
all spring into view on the same day or so.  (I incline toward the
first view, Gregg toward the second).

     Please let me know if I can be of any further assistance in
getting rid of this thing.

                     Larry Kestenbaum, Sibley PTOP
                     Gregg Cirielli, SIbley FTOP

David.M..Chess.CHESS@YKTVMV (09/26/89)

Sounds basically like the Jerusalem Virus; in particular, the
little signature string given occurs in the JV.   Not sure
why they aren't seeing files change in size when they're
infected.   Perhaps the fact that a file gets infected when
it executes (rather than when the original infected file executes)
is causing confusion.  The multiple infections that they're
seeing (and attributing to disk fragmentation) are also
characteristic of the JV.  Or, of course, it could be some
Brand New nasty...                    DC

CJH@CORNELLA.cit.cornell.edu (Chris Haller) (09/27/89)

>From:    Ken Hoover <consp21@bingvaxu.cc.binghamton.edu>
>Subject: IBM Virus (from EXPERT-L list) (PC)
>
>Original-Date:         Mon, 18 Sep 89 17:38:00 EDT
>Original-From:         Sanjay Hiranandani <GDO@CRNLVAX5.BITNET>
>
 [text omitted]

Oh well, I was considering writing to VIRUS-L about this anyway, and
this posting precipitates a response.  Here is the current situation
about the virus that showed up at Sibley Hall at Cornell University.

John McAfee's VIRUSCAN v36 identified this virus as Jerusalem B, and
its appearance and behavior correspond with this identification, AS
FAR AS I KNOW.  (Would some kind soul please send me a type
description of "Jerusalem B" so I can verify the identification more
completely?  I think this is the version of the Israeli that attacks
both .COM and .EXE files on both floppy and hard disks, that was
modified (probably in the U.S.) to be less obtrusive, and that
WordPerfect and FoxBase catch in the act because they detect its
alteration of their file.) We are using UNVIRUS, which we retrieved
from the archive at Kansas State, to clean up.

Incidentally, we find VIRUSCAN and SCANRES very useful and intend to
ask Mr. McAfee about site licensing arrangements for Cornell
University.  (That's why we haven't sent in our shareware fees yet!
Most of us on the staff here won't use software without paying for it,
except preliminarily.)  However, do not let this kind of endorsement
of one person's (or group's) efforts deter those of you who are
writing other protective software.  No single program, indeed no
single way of addressing the problem, will be sufficient to protect a
diverse computing community like this from the threat of viruses.
This semester we may recommend SCANRES, but we are counting on there
still being a lot of people using FLU_SHOT+ here, and next semester we
may recommend something else, or a newer version of FLU_SHOT, or a
program that checks CRC polynomials to detect altered files or disk
sectors.  The idea is that in a large and diverse community like a
major university, a virus may get started locally but it won't get
very far before it sets off an alarm on someone's system.  If everyone
using PC's were using the same kind of protection, a virus written to
evade that particular protection would spread farther.  This is not a
new idea, it's one I learned from reading this list!  Thank you all.

- -Chris Haller, Research and Analysis Systems, Cornell University
BITNET: <CJH@CORNELLA>  Internet: <CJH@CornellA.CIT.Cornell.edu>
Acknowledge-To: <CJH@CORNELLA>