Hacker 2/HACKER2.mdf/virus/virusl3/virusl3.71

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

VIRUS-L Digest   Friday,  6 Apr 1990    Volume 3 : Issue 71

Today's Topics:

HACKER.THESIS, HACKTHES.ZIP (text)
Brunnstein's lists
Re: Virus in Text Files
Validating Virus Software
ftp of disinfectant problem (Mac)
Universal Virus Detector
Re: Virus cure (PC)
The ZUC virus and SAM 2.0 (Mac)

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 [e-mail] (that's equivalent to
LEHIIBM1.BITNET for 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: [e-mail].

   Ken van Wyk

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

Date:    Thu, 05 Apr 90 09:14:51 -0500
From:    James Ford <[e-mail]>
Subject: HACKER.THESIS, HACKTHES.ZIP (text)

A bad copy of these files were loaded onto MIBSRV....approximately
half the thesis was missing.  This has been corrected now.

HACKER.THESIS is 152596 bytes (instead of 62504 bytes)
HACKTHES.ZIP  is  47137 bytes (instead of 19483 bytes)

Thanks to Jim Weinhold for pointing this out.....sorry for any inconvience.
- ----------
    James Ford - [e-mail], [e-mail]
Acknowledge-To: <JFORD1@UA1VM>

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

Date:    05 Apr 90 16:35:14 +0000
From:    [e-mail] (Dave Weissman)
Subject: Brunnstein's lists

Does K. Brunnstein put out a list of MAC viruses similar to the DOS
virus list (i.e. *VIR.A89).  If so, where would I find it (preferably
by anonymous FTP).

Dave Weissman
GSFCMail/X.400 Systems
Goddard Space Flight Center
NASA

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

Date:    05 Apr 90 18:29:00 +0000
From:    [e-mail] (Leonard P Levine)
Subject: Re: Virus in Text Files

[e-mail] (Dr. Ruth Mazo Karras) writes:
> I have heard of a concern that text files (consisting of plain ASCII text)
> may contain viruses.  I had thought that only executable files such as
> *.com or *.exe files were subject to viruses.  Which view is right?  Is there
> risk in moving a text file from a mainframe to a PC?

There is NO evidence that anything other than an .exe, .com, .ovl, or
.sys file can infect.  There has been talk about .pgm files (for
dBase) and lotus spreadsheets being carriers but I have no evidence of
any known.

The following file:

XPHPD[0GG0G,0G51G31GB'(G+(G:u'0g?(G>(GE1G@arwIV_F*=US@<1|_,5wXNg-7muTu(4
1m2?352t0osr2e3K1q2s0s3e0W1_F0:sss1@2G0t1k0s3p0@3T1m3>52f3>1k0t3<2C0@3T2
K1g2?0@3T1Fm3U51g3<1q0s3:0@3T1g3r1l0ts1>0I@3T1m3i52e0O2;h0L1_Eg352s0m3S2
j0W1g3of0<1;2?0r1m0s3:1>0m@3T2e0R1FH2E1m0s3:1>0B3^0=2g3=1g3s0@3T2e0@3^1t
2e0<1>0m1m0s361>0e1l0s371g3r1:0P@3T1:0P2e1hDk0s3q0V1F2M1_3_c2o3Z1=0Y1=0c
2s0o2Ag3H0CSCS1:0=F[1:0=2s0]352k0t1]2s0U390^3<1KL2D1Dc0sf1]2L0UE^1T2HfTZ
X3mS2@F5C6G3S2Y\_X3a25BB3W2HacTV^\aZ3S2gb3S2Y\_X3mSW28eebe3S2Whe\aZ3S2Y\
_X3S2<3b2B3W2Abg3S2XabhZ[3S2`X`bel3W4

is a text file that unpacks a kermit .boo format.  This is an ASCII
string that WHEN NAMED AS A .COM FILE executes.  Gives one pause doesn't
it?

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Leonard P. Levine                       e-mail [e-mail] |
| Professor, Computer Science             Office [phone] |
| University of Wisconsin-Milwaukee       Home   [phone] |
| Milwaukee, WI 53201 U.S.A.              FAX    [phone] |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +


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

Date:    Wed, 04 Apr 90 23:14:00 -0400
From:    David Ward -- Computer Support/Special Needs <[e-mail]>
Subject: Validating Virus Software

Periodically we hear concerns about the validity of SCANVxx and other
antiviral programs.  I think these concerns are valid since a
virmentor creating a virus would likely take great joy in attaching
the virus software to a product designed to fight viruses.

I do not have complete confidence in our local sources of SCANVxx -- the
distribution path of the software I use is as follows:
 - a local bulletin board downloads the SCANVxx software directly from
   homebase
 - our college microlab person downloads to his PC
 - he repacks it
 - he uploads to our VAX
 - I download it from VAX to my PC
 - I copy to disks to distribute it in my department.
There is potential for infection along the way.

It would seem logical that the most reliable source for SCANVxx is the
homebase bulletin board operated by McAfee himself.  However, it is a
long distance call and when a new version is released, the line is
quite busy.

The VALIDATE program is designed to allow us to determine whether or
not these programs are intact.  But what if someone modified SCANVxx,
revalidated the program, updated the check sums in the docs, and then
repacked the programs?  We would not be able to detect the changes
since the check sums would appear to be correct. Clearly, the
validation check sums must come from a source that is different from
the source of the program.  That is, if we get SCANVxx from a local
bulletin board, then to validate it, we must compare the validation
strings we generate to those published by McAfee on his bulletin
board.

A simple solution to this problem is that when new versions of scan
are announced on this digest, the announcement should include the
validation strings given by McAfee.  Then we can download from any
local source and compare the strings published in Virus-L to
those we generate with the validate program.

- -------------------------------------------------------------------
David Ward                          Phone:  [phone]
Special Needs Dept
Seneca College                      Netnorth/Bitnet: WARD@SENECA
Toronto
- -------------------------------------------------------------------

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

Date:    Thu, 05 Apr 90 09:31:06 -1100
From:    Michael Perrone <[e-mail]>
Subject: ftp of disinfectant problem (Mac)

I am having trouble getting disinfectant to my Mac via
ftp/kermit-white knight.  I can get the .sit file over to my IBM 4381
account, and to a unix account okay but I can't get white knight to
kermit or zmodem the file properly.  When I kermit from the ibm, White
Knight recognizes it as Macbinary but the file type and creator don't
come up as SIT!, and then it bombs id 4 (divide by 0 error!) and I
have to reboot.  WK kermit has worked for me before with macbinary to
and from the IBM with .sit files.  On my unix accounts, I can't get WK
to even recognize as Macbinary.  Yes, when I ftp I am first setting it
to binary.  Does anyone else have similar problems or a solution?

       Michael Perrone, Portland State University (Oregon) Macintosh support
       [e-mail]

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

Date:    Thu, 05 Apr 90 14:17:00 -0700
From:    [e-mail] (JAMES E. MOLINI)
Subject: Universal Virus Detector

I am working with a colleague on defining a robust virus detection
utility.  The following is an extended abstract of a paper which
discusses an approach we are investigating.  The work was undertaken as
part of a research project sponsored by the National Aeronautics &
Space Administration at the Johnson Space Center.  Please look it over
and tell us (or Virus-L) what you think.

If you have questions, or see a flaw in the process, please let us
know.  We are building a virus detector, which could be placed into the
public domain, that uses the techniques below to detect virus
infections.  Our initial tests have shown encouraging results.


                   A Universal Virus Detection Model
                      **** EXTENDED ABSTRACT ****

                     by Chris Ruhl and James Molini
                        Computer Sciences Corp.
                  Email: [e-mail]

[Ed. Thanks for the paper!  Those interested in reading the remainder
of this paper can get it by anonymous FTP from cert.sei.cmu.edu in
file:

pub/virus-l/docs/universal.detector.molini

In addition, I'm sending a copy of the paper to the U.K. comp.virus
archive site.]

This paper attempts to define an abstract model which will support the
construction of a Universal Virus Detector.

DEFINITIONS

VIRUS - A self-replicating program that must attach itself in some way
to an existing executable on the target computer system in order to
propagate.  In doing so, no overt user action is required to further
the replication process.

TROJAN HORSE - A non-replicating malicious program that misleads the
user in order to cause him/her to execute it's malicious code.
This type of program does not necessarily modify any existing
executable files on the system.

MASKING - The act of preventing discovery by intervening at some point
in the scanning process.  Typically this effects an indication of a
clean system, when, in fact, the environment under review has been
modified.

                       A Virus Propagation Model

In order to develop this model the following assumptions are made:

     a.) The user will begin the detection process (we have proposed a
         CRC type routine) prior to infection.  By doing so, the user
         has provided an uninfected baseline from which to judge future
         states.

     b.) The user will avoid the introduction of self modifying code
         into the system.  By doing so, he/she ensures that the target
         system maintains a given state of integrity.

Given the assumptions above, we may now define the circumstances
necessary to support a virus infection.  Without the adherence to the
following rules, it is impossible to define a circumstance in which a
virus can propagate.

Rule #1:    A Virus infection, or propagation occurs when an
            executable file is altered.

Rule #2:    Assuming that the detection mechanism is sufficiently
            robust, the only possible way to avoid detection is to mask
            the infection prior to having the detection results
            presented to the user.

UVD CONSTRUCTION.

>From the above discussion, we can begin defining a UVD with some degree
of assurance that it will do the job.  If a virus must modify the
original state of the system in order to be successful, we can define a
process that can detect that modification.  (Insert your favorite
Checksum/CRC/Cryptographic routine here.)  Any program which
circumvents the modification of existing code is not a virus.

Then, to defeat the detection process, the virus must mask the
infection in some way so that this verifiable change detection
mechanism cannot present accurate results to the user.

Any program which circumvents the detection mechanism must do so by
modifying the data delivery process into, or out of the detector.  Once
again we are talking about code modification.

So to put our theoretical UVD into practice, on, for example, an IBM
PC, we would do the following:

a.  Begin by validating the integrity of the detector code.  This has
    been discussed above. [not included in abstract]

b.  Validate the integrity of the read process by checking the
    interrupt table and low memory for changes.

c.  Validate the correctness of the output process by checking screen
    write interrupt vectors and device paths.  It could be done also by
    generating a direct write procedure to hardware addresses during
    the installation process.

d.  Validate the Boot sector of the disk and hidden R/O system files
    via direct sector reads.  Knowing that the read process is
    unchanged, we can also be sure that the data coming into the CRC
    routine is correct.

e.  Once both ends of the pipe and the pipe itself are validated, we
    can begin checking all executables on the system for modifications.

f.  In order to prevent a virus from attacking the CRC table, we will
    add a set of dynamic "State Vectors" for the machine, which define
    the run time environment for the detector.  This creates an
    unforgeable "fingerprint" of the detector as it exists in memory
    and can be prepended to each file prior to computing the CRC.

By doing this we have checked the entire data path and found it to be
correct.  We have also checked the correctness of the change detection
procedure.  This assumes that no other process has taken over the CPU
during the scan, but this is no problem as long as we mask all external
interrupts.  Then only an actual hardware interrupt can cause the
program to pause.

User involvement in the procedure can be coached by the detector.
[Not included in abstract.]

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

Date: 5 Apr 90 23:15:40 GMT
From: <[e-mail]>
Subject: Re: Virus cure (PC)

[e-mail] writes:
> One IBM PC at my office gets infected by virus.  I used Virscan(tm)
> from IBM and it detected some executable files *.EXE and *.COM are
> infected by 1813 or Jerusalem virus.  Anybody knows any kind of
> software which can fix the don't have to reformat hard drive.  Any
> public domain or commercial software can do the job?  Any information
> is highly appreciated.

I have run into Jerusalem virus myself.And as far as I can tell, there
is one program that I think will help you out. The program is called
m-jruslm. I tried it quite a few times and it seemed to work fine
except on a few occasion. There is another program called "clean",
which doesn't seem to disinfect the Jerusalem virus when I tried them.
I think you can find them in SIMTEL, and best of all they are
shareware.  You can try for a couple of days before purchasing them.
Hope this helps.

Roslan MdZaki.

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

Date:    Thu, 05 Apr 90 20:09:47 -0300
From:    Peter J Gergely <[e-mail]>
Subject: The ZUC virus and SAM 2.0 (Mac)

>From comp.sys.mac:

Date: 3 Apr 90 14:37:37-GMT
From: Joel B Levin <[e-mail]>
Subject: The ZUC virus and SAM 2.0
Sender: [e-mail]
Reply-To: [e-mail] (Joel B Levin)
Organization: BBN Communications Corporation

SAM Intercept can also prevent infection by the ZUC virus (at least
version 2.0 with "standard" or higher protection turned on).  The
information below was provided by the author of SAM to the Virus-L
list and comp.virus.
- - - - - -
For SAM 2.0 users:

A new virus has recently been discovered (now named ZUC). If you
happen to run across the ZUC with SAM 2.0, you can expect to see the
following.

1) If you are running in standard, advanced, or custom levels, SAM
will alert you to ZUC's attempt to change CODE resources within
applications when ZUC is trying to spread itself. Denying this attempt
with SAM keeps the infection from spreading.

2) If you have previously inoculated your applications with Virus
Clinic 2.0, then if ZUC has infected any files since inoculation (if,
for instance, you had SAM Intercept turned off or set to basic level),
then SAM will alert you to an inoculation discrepancy when you try to
launch the infected file.

3) SAM Virus Clinic will also alert you to a checksum change to any
infected files if you have turned on checksumming in the Virus Clinic
scans.

4) You can configure SAM (both Virus Clinic and Intercept) to find ZUC
during scans and application launches with the new virus definition
feature. Using the Add Virus Definition option in Virus Clinic, create
a new one with these fields:

     Virus Name:   ZUC
  Resource Type:   CODE
    Resource ID:   1
  Resource Size:   Any
  Search String:   4E56FF74A03641FA04D25290    (hexadecimal)
  String Offset:   Any

You can then add this definition to both Virus Clinic and SAM
Intercept.

One other note: SAM 2.0 also repairs files infected with multiple
viruses.

Paul Cozza
SAM Author
- - - - - - -
Nets: [e-mail]  |  "There were sweetheart roses on Yancey Wilmerding's
 or {...}!bbn!levin  |  bureau that morning.  Wide-eyed and distraught, she
POTS: [phone]  |  stood with all her faculties rooted to the floor."


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

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