home *** CD-ROM | disk | FTP | other *** search
/ Hacker 2 / HACKER2.mdf / virus / virusl2 / virusl2.231 < prev    next >
Text File  |  1995-01-03  |  14KB  |  330 lines
  1. VIRUS-L Digest   Friday,  3 Nov 1989    Volume 2 : Issue 231
  2.  
  3. VIRUS-L is a moderated, digested mail forum for discussing computer
  4. virus issues; comp.virus is a non-digested Usenet counterpart.
  5. Discussions are not limited to any one hardware/software platform -
  6. diversity is welcomed.  Contributions should be relevant, concise,
  7. polite, etc., and sent to VIRUS-L@IBM1.CC.LEHIGH.EDU (that's
  8. LEHIIBM1.BITNET for BITNET folks).  Information on accessing
  9. anti-virus, document, and back-issue archives is distributed
  10. periodically on the list.  Administrative mail (comments, suggestions,
  11. and so forth) should be sent to me at: krvw@SEI.CMU.EDU.
  12.  - Ken van Wyk
  13.  
  14. Today's Topics:
  15.  
  16. Brain Virus info needed (PC)
  17. Jerusalem Virus (PC)
  18. Re: Checksum programs
  19. WANK Antidote (VAX/VMS/DECnet)
  20. Virus Invasion of Hardware?
  21. Macintosh Virus List (Mac)
  22. Identify Ashar Virus
  23. re: VGA2CGA infected with virus? (PC)
  24.  
  25. ---------------------------------------------------------------------------
  26.  
  27. Date:    Fri, 03 Nov 89 10:01:04 -0600
  28. From:    Mitch Cottrell <C2852%UMRVMB.BITNET@VMA.CC.CMU.EDU>
  29. Subject: Brain Virus info needed (PC)
  30.  
  31. Help Help Help
  32.  
  33. We have been infected with two virus strains...  Jeruslum-B and
  34. Pakastani Brain...  I have gotten some information on Jeruslium...
  35. but have not been able to get any info on brain other than how it
  36. replicates itself..  I still dont know what system damage it can do
  37. other than eat up a couple sectors of disk space.  Please let me know
  38. if you have any info on this virus or a source for info.  ps.  I have
  39. already tried McAfee Associates BBS.
  40.  
  41. Thanks...
  42. Acknowledge-To: <C2852@UMRVMB>
  43.  
  44. ------------------------------
  45.  
  46. Date:    Fri, 03 Nov 89 24:41:00 -0500
  47. From:    "Chris_C.Conner" <13501CCC%MSU.BITNET@IBM1.CC.Lehigh.Edu>
  48. Subject: Jerusalem Virus (PC)
  49.  
  50. The computers(PC) in many of the labs on campus(MSU) have been struck
  51. by the Jerusalem Virus.  I used SCAN.EXE (I don't know what version)
  52. and identified it as the Jerusalem Virus.  Irealize there have been
  53. quite a few articles about it in the recent digests, but thinking I
  54. was not susceptible, I didn't bother reading any of them.  Could
  55. someone please send me any information on what the virus does, what I
  56. can do to get rid of it, and any other shareware that could help out.
  57.  
  58.                                        CCC
  59.  
  60. ------------------------------
  61.  
  62. Date:    03 Nov 89 17:44:32 +0000
  63. From:    kerchen@iris.ucdavis.edu (Paul Kerchen)
  64. Subject: Re: Checksum programs
  65.  
  66. In article <0002.8911031455.AA13850@ge.sei.cmu.edu> len@csd4.csd.uwm.edu (Leona
  67. rd P Levine) writes:
  68.  
  69. >The checksum program and the checksum should be stored in a place that is
  70. >different on each machine.  Furthermore, there is no special "best"
  71. >crc or testing algorithm, many will do with varying polynomials.
  72.  
  73. True, but the checksum program must have some way of knowing what
  74. these algorithms are and where the checksums are stored.  If the `sum
  75. program can find these things, so can a virus.  If the `sum program
  76. must be told where these things are then there is no problem; the
  77. virus cannot find the info it needs because it isn't on the system.
  78. However, that could become tedious for administrators who oversee
  79. tens or hundreds of machines, detracting them from their real work.
  80.  
  81. >A satisfactory system is one in which each user can use a polynomial
  82. >of his/her choice and where the list of files and their crc's
  83. >(for example) is stored in some arbitrary location.  No virus writer
  84. >will be looking for YOU, rather just a collection of systems that
  85. >are alike enough to infect.
  86.  
  87. Again, where are these polynomials stored?  One must keep this fact
  88. in mind: a virus can do anything a legitimate program can do.  A "good"
  89. virus will be able to adapt to minor changes in systems and find out
  90. where these things are hidden.
  91.  
  92. I don't mean to play the devil's advocate here, but I think it's
  93. important to realize that no solution will be a 100% solution.  There
  94. are a lot of people who read this newsgroup, some of whom may not
  95. realize this point, and it always pains me to hear about someone who
  96. invested all of their trust into some vaccine, only to get burned by
  97. the next virus to come down the pike; they didn't realize the
  98. complexity of the problem and jumped right on to someone's bandwagon.
  99. Folks have to realize that all of the vaccines, filters, shields,
  100. latest & greatest methods, etc.,  will only slow viruses down; they
  101. won't stop them.  Of course, if the resposible computing community can
  102. make it so difficult for the degenerate virus writers to make a
  103. living, perhaps those degenerates will find something else to occupy
  104. their time, like making crank calls or torturing small woodland
  105. animals.
  106.  
  107. Paul Kerchen                            | kerchen@iris.ucdavis.edu
  108.  
  109. ------------------------------
  110.  
  111. Date:    Fri, 03 Nov 89 13:10:39 -0500
  112. From:    TBUTLER@NSSDCA.GSFC.NASA.GOV
  113. Subject: WANK Antidote (VAX/VMS/DECnet)
  114.  
  115.  
  116.               *********** WANK WORM VACCINE  **************
  117.  
  118. A vaccine to combat the WANK worm has been developed by Bernard Perrot
  119. of the Institut de Physique Nucleaire, Orsay, France.
  120.  
  121. The vaccine consists of creating a bogus file which you put in
  122. SYS$SYSTEM:RIGHTSLIST.DAT.  When the worm tries to use the information
  123. in this file, the worm-code generates errors and blows up causing the
  124. attacking worm to die. The vaccine does NOT affect the remote system -
  125. it only kills the worm.
  126.  
  127. This vaccine will stop attacks from any attacking nodes, it should
  128. therefore greatly reduce the "annoyance level" of attacks by reducing
  129. the volume of audit trails.
  130.  
  131.   ******************* IMPORTANT IMPORTANT IMPORTANT ***********************
  132.                                 PLEASE READ!!!
  133.  
  134. THIS VACCINE WILL ONLY WORK AGAINST **CURRENT** STRAINS OF THE WORM.
  135. WE BELIEVE HOWEVER THAT TO ELIMINATE THIS WORM FROM THE NETWORK, THIS
  136. TECHNIQUE WILL HAVE TO BE USED ON AS MANY SYSTEMS AS POSSIBLE.  IT IS
  137. THE ONLY WAY TO ATTACK THE WORM AT IT'S SOURCE (short of system
  138. management action on the infected node...and a lot of system managers
  139. are either asleep, ignorant, lazy or??? and therefore the worm has
  140. been running on some systems for days).
  141.  
  142. ******************************************************************************
  143.  
  144. This method has been tested on VMS 4.7 thru VMS 5.2 systems. In order to
  145. correctly implement this fix, the following steps must be performed:
  146.  
  147. 1)  If you have previously implemented any of our suggestions regarding
  148.     file protection or ACL's on RIGHTSLIST.DAT, it is necessary to undo them
  149.     restoring SYS$SYSTEM:RIGHTSLIST.DAT to its original configuration.
  150.  
  151. 2)  RENAME the file SYS$SYSTEM:RIGHTSLIST.DAT to some other name of
  152.     your choosing.
  153.  
  154. 3)  To make VMS operate correctly with the rightslist file in a new
  155.     location, issue the following command, and also add it to your
  156.     system startup procedure:
  157.  
  158.        $DEFINE/SYSTEM/EXEC RIGHTSLIST <ddcu:[dir]new-file-name>
  159.  
  160.     The worm won't find the file because it can't translate the
  161.     logical symbol.
  162.  
  163. 4)  Take the 4-line file listed below, protect it W:R and do not
  164.     put an ACL on it.  Name it SYS$SYSTEM:RIGHTSLIST.DAT.  You *WANT*
  165.     the worm to access this file!  Users on your system will translate the
  166.     system logical RIGHTSLIST and things will work correctly.
  167.  
  168. When an infected system attacks your node, the first thing it does is
  169. copy your sys$system:rightslist.dat file and tries to get your local
  170. usernames.  This dummy file will cause the attacking worm to abort with
  171. a fatal error when it tries to use the information it finds in the
  172. bogus file.
  173.  
  174. If you have followed each of the above steps, VMS will run normally, and
  175. you will not be vulnerable to the CURRENT strains of the worm which are
  176. running aroung the network.
  177.  
  178. The following file should be copied into SYS$SYSTEM:RIGHTSLIST.DAT exactly
  179. as it appears below:
  180.  
  181. - -------------------------- CUT HERE - RIGHTSLIST.DAT -----------------
  182. DUMMY MAINTENANCE RECORD
  183. 0123456789012345"'F$PID(ON)
  184. 0123456789012345'F$PID(ON)
  185. 0123456789012345BATCH
  186. - --------------------------- CUT HERE ----------------------------------
  187.  
  188. John McMahon of NASA/GSFC Advanced Data Flow Technology Office has
  189. created a command procedure that will have the same end-result as the
  190. above instructions.  It is available by copying WANK_SHOT.COM from
  191. NSSDCA::WANK_SHOT.COM or 6277::WANK_SHOT.COM.  This command procedure
  192. uses a modification of the above procedure using a SET FILE/ENTER
  193. command to set up an alias for RIGHTSLIST.DAT rather than the RENAME
  194. command above. Knowledgable system managers may want to decide for
  195. themselves which version they prefer.
  196.  
  197. Todd Butler                                Ron Tencati
  198. SPAN/GSFC Routing Center Manager           SPAN Security Manager
  199. (301)286-7251                              (301)286-5223
  200. 6277::Tbutler or NSSDCA::tbutler           6277::Tencati or NSSDCA::Tencati
  201.  
  202. ------------------------------
  203.  
  204. Date:    Fri, 03 Nov 89 13:38:54 -0500
  205. From:    "Gregory E. Gilbert" <C0195%UNIVSCVM.BITNET@VMA.CC.CMU.EDU>
  206. Subject: Virus Invasion of Hardware?
  207.  
  208. Is it possible to write a virus that will invade hardware?  Has it
  209. been done?  Just curious.
  210.  
  211. Gregory E. Gilbert
  212. Computer Services Division
  213. University of South Carolina
  214. Columbia, South Carolina   USA   29208
  215. (803) 777-6015
  216. Acknowledge-To: <C0195@UNIVSCVM>
  217.  
  218. ------------------------------
  219.  
  220. Date:    Fri, 03 Nov 89 13:50:53 -0500
  221. From:    "Gregory E. Gilbert" <C0195%UNIVSCVM.BITNET@VMA.CC.CMU.EDU>
  222. Subject: Macintosh Virus List (Mac)
  223.  
  224. Recently I have been writing an article on Macintosh infections.  In
  225. writing the article I tried to compile an exhaustive list of Macintosh
  226. viruses. Below is the list.  If anyone has anything to add to the list
  227. I would appreciate them notifying me so I can update the list.  Thanks
  228. much!
  229.  
  230. =================================  CUT HERE  ==================================
  231.  
  232. Macintosh Infections
  233. - ----------------------
  234. There are about eight Macintosh infections that are known at present
  235. (a list of infections and the years in which they first appeared
  236. can be seen in the following table).
  237.  
  238. - ------------------------------------------------------------
  239.  
  240. Infection                  Strains           Clones
  241. - ----------                 -------           ------
  242. Scores(Spring 1988)*
  243. nVir(Early 1988)
  244.                            nVir A(?)
  245.                            nVir B(?)
  246.                                              Hpat(Late 1988)
  247.                                              AIDS(Late 1988)
  248.                                              MEV#(March 1989))
  249.                                              nFLU(August 1989)
  250. INIT 29(Late 1988)
  251. ANTI(Early 1989)
  252. MacMag(December 1987)**
  253. Dukakis(Early 1988?)
  254. SNEAK(?)
  255. San Jose Flu(?)
  256.  
  257. - ------------------------------------------------------------
  258.  
  259. *  - also known as the NASA virus
  260. ** - also known as the Drew Virus, Brandow Virus, and the Peace
  261.       Virus
  262.  
  263. ==================================  AND HERE  =================================
  264.  
  265. Gregory E. Gilbert
  266. Computer Services Division
  267. University of South Carolina
  268. Columbia, South Carolina   USA   29208
  269. (803) 777-6015
  270. Acknowledge-To: <C0195@UNIVSCVM>
  271.  
  272. ------------------------------
  273.  
  274. Date:    Fri, 03 Nov 89 14:41:00 -0500
  275. From:    SHERIFF@steffi.acc.uncg.edu
  276. Subject: Identify Ashar Virus
  277.  
  278. We encountered a boot sector virus yesterday that we have not seen,
  279. can anyone help with identification and explanation?  The virus has
  280. only been identified on disks that also contain the Pakistani Brain
  281. Virus.  Further, we have only seen it on three diskettes, thus far.
  282.  
  283. When we run Viruscan 0.7V42 on an infected disk, here is what we see:
  284.  
  285. " Found Pakistani Brain Virus in boot sector.
  286.   Found Ashar Virus in boot sector.
  287.  
  288. Disk B: contains 1 directories and 5 files.
  289.  ld viruses found.  "
  290.  
  291. Please also observe that the number of viruses found is oddly noted.
  292. I have only noticed that phenomenon when the Ashar virus has been
  293. identified.
  294.  
  295. Light shed by anyone concerning this virus would be greatly appreciated.
  296.  
  297. Tom Sheriff
  298. Microcompuer Support Manager
  299. UNC Greensboro - Greensboro, NC
  300. SHERIFF@UNCG.BITNET
  301. SHERIFF@STEFFI.ACC.UNCG.EDU
  302.  
  303. ------------------------------
  304.  
  305. Date:    01 Nov 89 15:16:07 -0500
  306. From:    "David Chess" <CHESS@ibm.com>
  307. Subject: re: VGA2CGA infected with virus? (PC)
  308.  
  309. I have a sample of this thing (or what I assume is the same thing) now;
  310. it seems to be a rather silly overwriting-virus (that is, rather than
  311. arranging to execute more or less silently before the victim, it
  312. simply arranges to execute *instead of* the victim; the victim code,
  313. at least much of it, no longer exists).   It also seems to be written
  314. in a Borland language, perhaps Turbo Pascal.   It's very possible that
  315. it's based on the Turbo Pascal overwriting-virus "Number One", source
  316. for which was published in the Burger book "Computer Viruses, a
  317. high-tech disease".   I haven't taken it apart enough to know,
  318. for instance, what damage if any it does, or when it prints its
  319. message; it's hard to reverse-compile compiler output, and this
  320. virus isn't likely to spread very far (since an infected file
  321. is obviously infected, in that it doesn't do what it used to...).
  322.  
  323. DC
  324.  
  325. ------------------------------
  326.  
  327. End of VIRUS-L Digest
  328. *********************
  329. Downloaded From P-80 International Information Systems 304-744-2253
  330.