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

Text File | 1995-01-03 | 17KB | 349 lines

VIRUS-L Digest              Friday, 6 Jan 1989           Volume 2 : Issue 5

Today's Topics:
Right to Purge Mail
Re: Disks Drive protection -gimme a break
re: copy protected disketts
Getting Mac Anti-viral Files
Clarificaton/More on the Father Christmas Worm (VAX/VMS)
Brain and the boot sequence (PC)
Re: creating government standards for software

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

Date:  Thu, 5 Jan 89 08:42 EST
From:  [e-mail]
Subject:  Right to Purge Mail

S. H. asks:

"Which takes priority,  the rights of the individuals receiving these
virus files or the responsibility of systems managers for securing their
systems against anwanted [sic] viri [sic]?"

I think that the question, as stated, is loaded.  Try "Is the
responsibility of the system manager to ensure that the majority of the
population receives the majority of its mail superior to his
responsibility to see that an individual receives a particular mailing?"

William Hugh Murray, Fellow, Information System Security, Ernst & Whinney
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840

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

Date:         Thu, 5 Jan 1989 08:55:01 EDT
From:         "W. K. (Bill) Gorman" <[e-mail]>
Subject:      Re: Disks Drive protection -gimme a break

>From:     <[e-mail]>
>I would like to suggest the formation of another list...
>...  Readers: What do you think?

Not much. Personally, I *much* prefer having information available
quickly from a centralized location, not spread over
Gxx-knows-how-many separate lists.

>- -David Richardson

*******************************************************************************
* A CONFIDENTIAL COMMUNICATION FROM THE VIRTUAL DESK OF:                      *
*******************************************************************************
...............................................................................
|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:         Thu, 05 Jan 89 12:32:40 CST
From:         DON STRUBE <[e-mail]>
Subject:      re: copy protected disketts

I joined this list last week and have tried to come up-to-speed on the
conversations on this list by reading old digests.  I agree that the
copy protection thing has been beat to death and there still seems to
be a difference of opinion among the 'experts' writting to this list.
Since everything changes so fast in the world of computing I am sure
the correct response today will be incorrect next week anyway so lets
drop it and move forward.

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

Date:         Thu, 05 Jan 89 17:02:04 EST
From:         Joe McMahon <[e-mail]>
Subject:      Getting Mac Anti-viral Files

Would the person who sent me mail asking about the anti-virals here at
SCFVM please send me another message? Your message was misaddressed,
and forwarded to me by the postmaster without a reply-to field.
Thanks.  To all who are not concerned, sorry.

- --- Joe M.

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

Date:    5-JAN-1989 19:38:09.58
From:   <[e-mail]>
Subject: Clarificaton/More on the Father Christmas Worm (VAX/VMS)
Comments: BSMTP envelope created by ENVELOPE.COM version T1.0

Greetings,

What I found disturbing about the recent outbreak of "Father
Christmas" worm (a.k.a. HI.COM) was that some of the techniques used
in the "Internet worm" were duplicated in HI.COM.

One point where HI.COM looked like the "Internet worm" was causing the
source program to "disappear". This was accomplished by copying the
entire program into a DCL symbol array and then deleting the disk copy
of the program.  The program continued to execute since it had been
loaded and running already, and when it wanted to propagate to another
node it just dumped the symbol array.  The result was that you could
not observe (by using SHOW DEVICE/FILES) what the command procedure
was even though it was executing.  This made getting a copy of the
procedure and deciphering it difficult.

A second "lookalike" feature is that it moved through the network very
rapidly, and thus attracted attention quickly.  Infection attempts
were hitting my machine on the order of 3 or 4 tries every 5 minutes.
We run a homebrew network alarm package called NETINFO which told us
the type of attempt, and where it was coming from.  After the 8th file
transfer attempt in as many minutes I got curious and started looking.
If the program hadn't been so voracious, it might not have had
attracted so much attention on the beginning of a holiday weekend.

Anyhow, I am a new subscriber to VIRUS-L and I saw a few bits and
pieces in the digest (8901A) that ought to be "fleshed out".

Networks affected by the worm: Any DECnet network directly connected
to SPAN (The NASA Space Physics Analysis Network) or HEPnet (DOE -
High Energy Physics Network) was subject to infection. I have not
heard of any infections in THEnet, CCnet or Easynet at this time.  The
method of transmission was by DECnet on VMS systems only.

The process name used by the worm was "MAIL_178DC".  This was intended
to disguise the worm as a DECnet mail delivery process.  However, the
worm did not connect to another DECnet mail delivery process on a
remote node. Instead it connected to FAL, which is the file transfer
process.  This information is available from the command MCR NCP SHOW
KNOWN LINKS and is one way to distinguish the worm from a real MAIL
transfer process.

The short term fix that was proposed here at NASA/GSFC was to disable
the DECnet object that runs command procedures on remote nodes.  This
object is known as TASK or Object number 0.

Currently, it appears that the best long term fix without seriously
limiting DECnet functionality is to use a separate FAL (File transfer)
account.  A model FAL account can be found in the VAX/VMS Guide To
System Security.  Another proposed improvement would be to stop using
the default account/password of DECNET/DECNET for network
default-access accounts.  Finally, the worm needed to run AUTHORIZE,
which is system utility that users (both local and remote) should be
prevented from using.

Brian Lev who provided some of the information in the messages from
Steve Goldstein ([e-mail]) works for the Advanced Data
Flow Technology Office (Not CSDR) at NASA/Goddard Space Flight Center.
He can be contacted at [e-mail] or [e-mail].
His counterpart at CSDR who snagged the copy of the worm posted to
VIRUS-L was me (John McMahon), I can be contacted at
[e-mail] or [e-mail].

Since I will be giving a talk on the "Father Christmas" worm on Friday
the 13th (ominous, isn't it), I would be interested in any information
on it that hasn't already been shipped through VIRUS-L.  I am
especially interested in any proposed fixes that haven't been
mentioned, and also details on how widespread the worm was.  Thank you
very much, and Happy New Year!

John "Fast-Eddie" McMahon
ST Systems Corporation
Advanced Data Flow Technology Office - Code 630.4
Formerly COBE Science Data Room - Code 401.1
NASA Goddard Space Flight Center, Greenbelt, Maryland 20771

Bitnet:         FASTEDDY@DFTBIT  (old: FASTEDDY@IAFBIT)
Arpa:           [e-mail]
Span:           SDCDCL::FASTEDDY (Node 6.9)

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

Date:     Thu,  5 Jan 89 22:43 EST
From:     Dimitri Vulis <[e-mail]>
Subject:  Brain and the boot sequence (PC)

There seems to be some confusion concerning which part of boot logic
lives in ROM BIOS and which in the boot record (aka IPL record).
Indeed, the boot sequence (aka IPL sequence) is non-trivial on a PC.
Here's the story (valid for most IBM compatible BIOSes):

When the machine is reset (turned on, ctl-alt-del pressed, reset pin
tweaked, etc), the control passes to certain model-dependent ROM BIOS
routine that tests and resets various attachments (serial ports,
parallel ports, video card, etc); resets all interrupt vectors to ROM
routines; and also scans memory space for other valid ROMs, and if
they are found, calls an initialization procedure in each such ROM
(following a convention). Finally, it invokes INT 19.

(Note that INT 19 can only be invoked safely if you are certain that
all interrupts point to ROM. Don't issue it after you load some OS
code that redirects _any_ vector. This interrupt is for BIOS use
only.)

Now, if your machine has ROM on a hard disk controller, or a network
adapter, then it would intercept INT 19, and I'll deal with this
shortly. Similarly, if you have an EGA adapter, its ROM intercepts INT
10 (video), etc.

Suppose now, you are booting a plain vanilla PC, with no hard disk or
network card, from a floppy; this is the configuration most
susceptible to a boot sector virus. (On an IBM PC, the code for such
vanilla INT 19 routine is on page 5-49.) _All_the_code_does_is issue
INT 13 to read in a single sector from the A-disk (sector 1, track 0,
side 0) into memory location 0:7C00 and jump there. If it fails after
a few re-tries (e.g. no disk in drive A:) it goes into cassette BASIC.
Compatibles with no BASIC in ROM behave differently; some try ad
infinitum, some halt. NOTE: the message `Non-system disk' does not
originate here yet! I'll refer to the code just read as the `OS boot
record'.

If you have a separate hard disk ROM (this is slightly different on
`newer' machines, where hard disk BIOS is part of the `regular' BIOS),
it intercepts INT 19 (as well as INT 13 to interpret hard disk calls),
and when it's finally issued, it first tries to read from the floppy
(just like vanilla) and if that fails, it tries to read a `BIOS boot
record' from the hard disk (sector 1, track 0, head 0). If that too
fails (and it should not) it halts, or goes to BASIC, as above; if it
succeeds, it jumps to the BIOS boot record. The latter contains the
so-called `partition table', useful if you want to share the disk
between DOS and Unix, say, as well as some executable code to
interpret the table, find the `active' partition, read the OS boot
record from the first sector of that partition into 0:7c00 and jump
there. (This sector, by the way, is an ideal place for a worm, and
I've seen bad ones there.)

If you have a network adopter, then INT 19 does a `remote boot' and
the OS boot sector is read from a different machine on the network. We
will ignore this case, since the remote device is hopefully read-only
and no virus can spread that way.

So, we've reached the stage when the OS boot sector is in memory at
0:7C00 and we start executing it. _If_ the boot record is the vanilla
MS/PC-DOS boot record, then the code does the following (trivially
speaking): it read in the beginning of the directory and checks that
the first 2 files are IBMBIO.COM and IBMDOS.COM (for PC-DOS) or IO.SYS
and MSDOS.SYS (for generic MS-DOS). If they are not, it displays (via
INT 10) the message: `Non-system disk or disk error, replace, strike
any key when ready', waits for a keystroke and does INT 19 again. Of
course, it's trivial to replace this message by anything you like,
including a German one, and ROM BIOS has nothing to do with this.

If these files are there, it reads (using INT 13) the first one (DOS
low-level routines, _not_ BIOS---BIOS is in ROM!) into memory, usually
at 70:0, and jumps there. IBMBIO.COM then loads the rest of DOS. The
reason for all the arithmetic is that the boot record is the same on
different devices, so some logic is needed to compute the position of
IBMBIO.COM and the directory using the BPB table, also contained in
the boot record, that gives the number of sectors per track, etc. (INT
13 is pretty low-level, that's why this logic is needed.)

There are two ways the OS boot record normally gets (over)written: by
FORMAT command, and by SYS command. That's why many (commercial)
distribution (floppy) disks come with a boot record that does not even
check for IBMDOS.COM, but says immediately something like `This is XYZ
software, if you want to make this disk bootable, use the SYS command,
now insert your DOS disk and strike any key.'  This is a valid thing
to do, because if you SYS'd, the original boot record would be
replaced by the DOS one.

Suppose now that you are booting from a Brain-infected disk (not
necessarily having IBMBIO.COM and IBMDOS.COM!). (The following
description is approximate and may vary with version.) The very first
thing the `shoe record' does is read in the additional sectors, masked
as `bad sectors' (since all this logic would not fit in a single
sector) into high memory. and jumps there. It then decrements the word
in low memory that's set by the BIOS diagnostics routine to the amount
of RAM available to DOS, so DOS won't attempt to touch that memory.

It intercepts INT 13 (disk access) and replaces it by a code that
infects floppies whenever they are accessed via INT 13. (`Infecting'
involves marking sectors as bad in FAT, and writing a copy of the
virus code from high memory to those sectors, as well as to the boot
sector.) _But_ this only works with the (most common) 5.25" DS/DD
disks, not enough logic is there to handle other formats. Only after
that it passes the control to the original boot sector code.

The latter attempts to find IBMBIO.COM and if it fails, it displays a
message and waits for a keystroke, as above. But INT 13 is intercepted
now! So, if you insert a bare (sans tab) DOS disk into A: and press
_any_ key, INT 19 will not change any interrupts, and will attempt to
read the boot sector via INT 13, infecting the new disk in the
process. (Here INT 19 does not halt the machine because DOS does not
know about the piece of RAM where the virus code is, so it does not
overwrite it.) If, however, you press ctl-alt-del, then the BIOS will
go through the whole diagnostics again and reset the vectors,
disabling the virus. (Virus code still sits in high RAM, but it never
gains control, and is overwritten by DOS shortly.)

To summarise, a failed boot from a non-bootable Brain-infected disk
will load the virus into memory and the machine will infect other
disks until the machine is properly reset.

- -----------------------------------------------------------------------------
Also: after I've delivered the final kick to the write-protect issue,
I got a long, rude, obnoxious, illiterate flame from one person whose
postings I quoted. Most of that trash is not worth quoting, but he
makes one valid point:
>(Hence the confusion, since I happen to beleive in the authanticity of
>messeges posted in the disgest).
Fascinating. An ignorant (not necessarily stupid) person makes a
statement that makes no sense. A stupid and ignorant person (quoted
above) picks it up, takes it seriously, and bothers his systems
people. This digest is highly authoritative; with this authority comes
responsibility. (I've said this before, so I should stop here.)

- -Dimitri

[Ed. I agree with your comments about the digest and all.  One
problem, though, who should be the one(s) to verify the authenticity
of messages sent to the digest?  Should I?  That would become a
full-time job in itself, and I already have a full-time job which
takes up more than enough of my time.  Do we have any volunteers?  I
feel that the best solution is to ask people submitting messages to
try to verify their own messages within reason, and for readers to be
able to reply to messages that they feel are incorrect.  After all,
isn't that one of the reasons for having a _discussion_ forum?
Comments and/or suggestions anyone?  I'm *very* open to suggestions
here.]

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

Date:  Thu, 5 Jan 89 21:58 EST
From:  "Joseph M. Beckman" <[e-mail]>
Subject:  Re: creating government standards for software

I must second WHM's comments on the inadvisability of creating
government standards for software.  If anyone believes this is a good
thing, please forward me the consensus view of the community of what
those standards should be.  Anyway, I think the more traditional way
the "government" may play in these matters is thru judicial actions
against the manufacturers.  Personally, I am all for private citizen's
using their ability to influence the market thru their actions
(refusing to buy manufacturer "x"'s software) to promote such
"standards."

Joseph

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

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