home *** CD-ROM | disk | FTP | other *** search
/ Hacker 2 / HACKER2.mdf / virus / virusl2 / virusl2.94 < prev    next >
Text File  |  1995-01-03  |  6KB  |  140 lines
  1. VIRUS-L Digest             Thursday, 20 Apr 1989        Volume 2 : Issue 94
  2.  
  3. Today's Topics:
  4. Viruses, Networks, and NFS: Questions
  5. AppleShare volumes (Mac)
  6. Forwarded: DenZuk Virus (PC)
  7. Hiding Viruses by Intercepting Output
  8.  
  9. ---------------------------------------------------------------------------
  10.  
  11. Date:    Thu, 20 Apr 89 07:58:06 PLT
  12. From:    Joshua Yeidel <YEIDEL@WSUVM1.BITNET>
  13. Subject: Viruses, Networks, and NFS: Questions
  14.  
  15. Joe Sieczkowski's recent remarks about the possibility of NFS-borne
  16. viruses lead me to the following questions:
  17.  
  18. I understand that EXECUTING an infected program stored on an NFS
  19. server could infect the client system.  I'm wondering if NFS has
  20. loopholes such that a client can be infected by a server WITHOUT the
  21. client requesting execution of a server-based program (for example,
  22. via a worm process, a bogus remote procedure call, or ???)  Anyone who
  23. knows NFS well is hereby invited to speculate.
  24.  
  25. We are a few weeks away from getting our first NFS machines, so I'm
  26. not very familiar with the ins and outs (I don't have documentation
  27. yet, either).  This is not a burning issue, just a question which our
  28. security task force is bound to ask sooner or later.
  29.  
  30. ------------------------------
  31.  
  32. Date:    Thu, 20 Apr 89 11:14 EST
  33. From:    Roberta Russell <PRUSSELL@OBERLIN.BITNET>
  34. Subject: AppleShare volumes (Mac)
  35.  
  36. I have a question about virus infections on an AppleShare file server.
  37.  
  38. If I partition the server into two "volumes", and if one of these
  39. volumes becomes infected, will that infection spread to the other
  40. volume?  I'm not talking here about users infecting the other volume,
  41. but about the infection spreading across the server from one volume to
  42. another (users would have access to only one volume).  Since both
  43. volumes share the same operating system, I'm assuming this would be
  44. true, but would appreciate more informed opinions.  Thanks,
  45.  
  46. Robin Russell
  47. Oberlin College Computing Center
  48. prussell@oberlin (bitnet)
  49. prussell@ocvaxa.oberlin.edu (internet)
  50.  
  51. ------------------------------
  52.  
  53. Date:    Thu, 20 Apr 89 09:44:35 PDT
  54. From:    rogers@marlin.nosc.mil (Rollo D. Rogers)
  55. Subject: Forwarded: DenZuk Virus (PC)
  56.  
  57. Here are more details as a follow-up to the message i forwarded to you
  58. yesterday on this suspected new virus. This person is seeking
  59. assistance to find a way to eradicate the infection and perhaps
  60. disassemble a copy of it too..
  61.  -------
  62. Forwarded mail follows:
  63. Original-Date: Thu, 20 Apr 89 10:12:40 EST
  64. Original-From: iuvax!bsu-cs.bsu.edu!atariman@ucsd.edu (Jeff Scott)
  65.  
  66. Here is some general information about the 'DENZUK' virus.  No
  67. specific information is available as to it's origin, what it actually
  68. does, or how long it takes to do it.
  69.  
  70. The 'DENZUK' virus.
  71.  
  72.     The DENZUK virus first started showing up here at Ball State
  73. University, Muncie, Indiana around the 16th of April.  It was first
  74. noticed because everytime that the computer is re-booted, a graphic
  75. display will show up and the letters DEN ZUK * will slide in from the
  76. sides of the screen. (The * is a graphics symbol resembling the AT+T
  77. logo) then the system will roboot.  The display only lasts for about 3
  78. seconds and will only be seen on a graphics screen (CGA is the only
  79. one that has been checked).  If the disk is not write protected, the
  80. virus (I call it that, but techincally it might be a worm, we really
  81. don't know) will write a counter to the disk.  After about 5 times of
  82. rebooting, the disk will become useless.  The information is still
  83. there, but the disk is un-usable.  (It might overwrite the directory
  84. blocks or something simular).
  85.  
  86.     The 'DENZUK' virus can be transfered to either other bootable
  87. disks or DATA DISKS (unbootable disks).  It was thought for a while
  88. that the virus could possibly be transfered to disks with a write
  89. protect tab in (as it is possible to do that on IBM PC's), but this
  90. can only be done in certain instances.  This instance would be if the
  91. write-protect tab was squeezed or torn a bit.  The virus is transfered
  92. to another disk whenever another disk is accessed (either read or
  93. write) and that disk will then have the virus.
  94.  
  95.     The only way known of checking for that virus is to reboot the
  96. computer with the disk you want to check in the A: drive.  This will
  97. work with system or data disks to check for the virus.  This is not to
  98. say that this is a sure- fire way of checking for DENZUK.  It may well
  99. keep a counter to count up the number of times re-booted and not start
  100. showing the display until a certain number.  That would give it time
  101. to propagate even more.
  102.  
  103.     It has also been found out that the virus writes to the first
  104. track.  This may be where the actual program is, or it could be where
  105. the counters are kept, or both...
  106.  
  107.     At this point, we do not know what, if anything, this virus will
  108. do to a hard drive.
  109.  
  110.     That is all that we know right now, if we learn any more I will
  111. try to keep you informed.
  112.  
  113. Jeff Scott
  114. Computer Competency
  115. Ball State University
  116.  
  117. ------------------------------
  118.  
  119. Date:    Thu, 20 Apr 89 16:06 EST
  120. From:    <JWW7917@RITVAX.BITNET>
  121. Subject: Hiding Viruses by Intercepting Output
  122.  
  123.         Some time ago, a person brought up the idea of a virus that
  124. would intercept the sector reads.  If the sector that was read was the
  125. one in which the virus lived, then the virus would return bogus data.
  126. Someone else responded with a reason why this would not be an easy
  127. task to do.  Could anyone tell me how this method of hiding a virus
  128. would fail?  Consider the virus using this technique to be a boot
  129. sector virus.
  130.  
  131.                                           John Wagner
  132.                                           RITRC
  133.                                           jww7917@ritvaxa
  134.  
  135. ------------------------------
  136.  
  137. End of VIRUS-L Digest
  138. *********************
  139. Downloaded From P-80 International Information Systems 304-744-2253
  140.