home *** CD-ROM | disk | FTP | other *** search
/ Hacker 2 / HACKER2.mdf / virus / virusl2 / virusl2.101 < prev    next >
Text File  |  1995-01-03  |  10KB  |  217 lines
  1. VIRUS-L Digest             Thursday, 27 Apr 1989       Volume 2 : Issue 101
  2.  
  3. Today's Topics:
  4. Forwarded Message From Jim Goodwin re: various VIRUS-L comments
  5. BRAIN infection (PC)
  6. More Using Checkfunctions For Virus Detection (General Interest)
  7. re: Yale and 1701/1704 virus, and Sentry (PC)
  8. re: Checkfunctions For Virus Detection (General Interest)
  9.  
  10. ---------------------------------------------------------------------------
  11.  
  12. Date:    Thu 27 Apr 1989 06:00 CDT
  13. From:    GREENY <MISS026@ECNCDC.BITNET>
  14. Subject: Forwarded Message From Jim Goodwin re: various VIRUS-L comments
  15.  
  16. The following is a message that I am forwarding for Jim Goodwin on the
  17. HomeBase Virus BBS.
  18.  
  19. Bye for now but not for long
  20. Greeny
  21.  
  22. BITNET: MISS026@ECNCDC
  23. Internet: MISS026%ECNCDC.BITNET@CUNYVM.CUNY.EDU
  24.  
  25.  ------------------------- Message Test to Follow -------------------------
  26. 04/25/89 08:26:59 (Read 18 Times)
  27. From: JIM GOODWIN
  28.  
  29. Last weeks Virus-L messages brought up a number of good points and questions.
  30. I hope the following clarifies some of the issues:
  31.  
  32. To David Chess: Mr. McAfee is correct when he states the POP CS
  33. instruction will not work on 286 machines - in real or protected mode.
  34. As Naama Zahavi-Ely of the Yale computer center verified, the Yale
  35. (Alameda) virus does not run on ATs or other 286 machines.  In fact,
  36. the the only way this virus is discovered (usually) is when someone
  37. attempts to boot a 286 machine from an infected disk.  There is,
  38. however, another version of the Yale (Version -C), that replaces the
  39. POP CS with another series of instructions used to relocate the virus
  40. in memory.  This version will run on the 286.  Perhaps this is the
  41. version that you mean.
  42.  
  43. To Tom Sheriff: The virus you described is the Australian virus (or
  44. stoned virus).  It is a boot sector infector and causes no damage.
  45. The message you described is on the boot sector but it is never
  46. displayed.  If you like, you can obtain a disassembly of the virus
  47. from HomeBase.  Leave me a message.  BTW, to remove the virus, perform
  48. a SYS command on the affected disks.
  49.  
  50. To David Bader: You are incorrect about Sentry.  It does not modify
  51. any existing files, the documentation warns of the re-boot and it does
  52. display the names of all infected files.  As to the interrupt vector
  53. modifications, Sentry installs first in the autoexec, so no other
  54. programs will have been loaded that modify the interrupt vectors.  We
  55. have yet to find a virus that Sentry will not detect.
  56.  
  57. To Jeff Scott: The virus that you describe is the Venezuelan virus.
  58. It is a boot sector infector and is a damaging virus.  There is also a
  59. non-virus Trojan floating around that looks identical from a user
  60. standpoint.  To determine whether you have the trojan or the virus,
  61. boot a system diskette on an infected machine and check the boot
  62. sector using Norton to see if it has been modified.  If it has, then
  63. you have the viral version.
  64.  
  65. To David Chess: You mentioned a bug in the 1704 virus that prevents it
  66. from recognizing true IBM machines.  What you are describing is the
  67. 1701 virus.  The 1701 is identical to 1704 with the exception that
  68. 1701 cannot recognize the IBM/Clone difference.  IBM in Denmark was
  69. the first company to get hit by the 1701, and there is a joke going
  70. around that the 1701 went into IBM, and the 1704 came out.  By the
  71. way, both the 1701 and the 1704 can recognize pre-existing infections,
  72. but they WILL re-infect each other.
  73.  
  74. Just a note of interest.  I have finished the disassembly of the
  75. Russian Black Hole virus, and find that it is merely the New Jerusalem
  76. with some non-referenced text additions.  Anyone wishing to see the
  77. disassembly please contact me on Homebase.  408 988 4004.
  78.  
  79. Jim Goodwin.
  80.  
  81. ------------------------------
  82.  
  83. Date:    Thu, 27 Apr 1989 01:02 IST
  84. From:    Ilan Lamdan <KBULI@HUJIVM1.BITNET>
  85. Subject: BRAIN infection (PC)
  86.  
  87. It seems like I have a visitor...
  88. A (c) brain virus infected few of my diskets.
  89. I wonder if anybody can tell me :
  90.       A. any harm done by this virus... (what to expect ?)
  91.       B. any cure ?
  92.       C. if so, how can I get it (no ftp, pure BITNET).
  93.          I searched the <msdos.trojan-pro> on SIMTEL20
  94.          but found nothing.
  95.  
  96.                                        thanks in advance
  97.                                                 Ilan
  98.  
  99. ------------------------------
  100.  
  101. Date:    Thu, 27 Apr 89 08:38:52 EST
  102. From:    dmg@mwunix.mitre.org
  103. Subject: More Using Checkfunctions For Virus Detection (General Interest)
  104.  
  105. In Virus-L V2 #100, Joe Sieczkowski <joes@scarecrow.csee.Lehigh.EDU>
  106. passed on the following comment regarding my suggestion of encrypting
  107. the input to a checkfunction algorithm in order to prevent a virus
  108. from masking itself by having no effect on the checkfunction:
  109.  
  110. >His checksum might be harder to fake, but it is not necessary to be able
  111. >to reverse the encryption to fake a checksum.  Only the algorithm for
  112. >the forward encryption is needed, and that can be pulled from the
  113. >program that does the checking.  If f is the checksum and g is the
  114. >encryption, all he has done is create a new function s(x) = f(g(x))
  115. >which is just another signature function.  If f was more than just
  116. >a CRC polynomial, g might not really make any difference, and if
  117. >f is a CRC, then some choices of g could make the combination easier
  118. >to break.
  119. >                                WB
  120.  
  121. Before I go on, let me note that I understand "WB"'s comment about
  122. faking the checksum to mean that the virus is somehow able to
  123. recalculate the checksum for the application after infection.  My
  124. solution was meant to address the case of a virus that, once added to
  125. an application, would not affect the checkfunction value.
  126.  
  127. To address WB's comments (does this person have a name?  I dislike
  128. using initials for someone I've never met), you need more then just
  129. the encryption algorithm, you need the encryption key as well.  While
  130. I did say the key should be dependent on the data to be encrypted,
  131. that does not preclude the use of an independent seed key left up to
  132. the user.  This seed is then modified by the input data.  Even if the
  133. virus has the clear input data, and the encryption algorithm, it would
  134. need to query the user to get original seed key to success- fully
  135. infect the application.
  136.  
  137. David Gursky
  138. Member of the Technical Staff, W-143
  139. Special Projects Department
  140. The MITRE Corporation
  141.  
  142. ------------------------------
  143.  
  144. Date:    27 April 1989, 10:28:07 EDT
  145. From:    David M. Chess  <CHESS@YKTVMV.BITNET>
  146. Subject: re: Yale and 1701/1704 virus, and Sentry (PC)
  147.  
  148. I stand corrected on "POP CS"; that's what I get for reading (and
  149. misinterpreting!) the manual, rather than trying it myself.  "POP CS"
  150. is invalid on a '286, even in real (DOS) mode, and the version of the
  151. virus with POP CS in it shouldn't be able to function on '286
  152. machines.  My mistake!
  153.  
  154. On the "vanilla IBM machine" issue, though, I stick to my guns.  I
  155. have samples of both the 1701 and the 1704.  The 1701 has *two* bugs
  156. in that section: he forgot the "ES" overrides, and the last compare is
  157. a word compare rather than a byte compare.  He fixed the override bug
  158. in the 1704, but he still has the word-compare bug.
  159.  
  160. Perhaps I'm missing something subtle here.  It seems to me that the
  161. instructions
  162.  
  163. .     CMP   WORD PTR ES:[DI+8],4DH
  164. .     JZ    KILLVIRUS
  165.  
  166. Are testing for the value "004D" at that place in BIOS.  Interpreted
  167. as bytes, that's an "M" followed by a byte of zeros.  In all the
  168. vanilla IBM machines I've looked at, the "M" is in fact followed by a
  169. blank (020 hex).  So the compare will fail, and the jump to KILLVIRUS
  170. will not be taken.
  171.  
  172. Have I made a mistake there somewhere?   I have tested the 1704 on
  173. a number of vanilla IBM machines, and it happily infects on all of
  174. them.   Perhaps there are some clones on which the "M" in "IBM"
  175. is actually followed by 00?   Doesn't seem too likely...
  176.  
  177. In any case, unless you can point out some mistake in the above,
  178. I think we have to conclude that the virus author still has a
  179. bug, and that the 1704 does spread just as well on vanilla IBM
  180. machines as on anything else.
  181.  
  182. DC
  183.  
  184. ------------------------------
  185.  
  186. Date:    27 April 1989, 10:39:06 EDT
  187. From:    David M. Chess  <CHESS@YKTVMV.BITNET>
  188. Subject: re: Checkfunctions For Virus Detection (General Interest)
  189.  
  190. I don't think the conclusion was that check functions are too easy to
  191. defeat!  A simple-minded fixed CRC has definite problems, but there
  192. are at least two alternatives to that (I thought they both came up in
  193. the discussion, but they may not have):
  194.  
  195.   - Use a more complex algorithm, based on an encryption (as you
  196.     suggest).   CRCs were designed to detect accidental changes,
  197.     and no one was worried about the computational complexity of
  198.     inverting them.   Now that we *are* worried about that, it
  199.     makes sense to use what's been learned in the crypto area.
  200.     As you say, that can be slow.  If hardware-assists for crypto
  201.     become common, that would help!
  202.  
  203.   - Use a CRC in which the polynomial is kept secret.   If the
  204.     CRC is long enough (30 bits seems a good lower bound), and the
  205.     polynomial is actually kept secret, it becomes very very hard
  206.     to invert the CRC.   I don't think anyone shot down that idea
  207.     in the previous discussions, except to note that keeping the
  208.     polynomial away from the virus reliably requires care.
  209.  
  210. DC
  211.  
  212. ------------------------------
  213.  
  214. End of VIRUS-L Digest
  215. *********************
  216. Downloaded From P-80 International Information Systems 304-744-2253
  217.