home *** CD-ROM | disk | FTP | other *** search
/ Hacker 2 / HACKER2.mdf / virus / virusl2 / virusl2.156 < prev    next >
Text File  |  1995-01-03  |  12KB  |  288 lines

  1. VIRUS-L Digest   Friday, 21 Jul 1989    Volume 2 : Issue 156
  2.  
  3. Today's Topics:
  4.  
  5. New PC virus (and really bad news)
  6. Re: CMS viruses (IBM CMS)
  7. Re: Request for info on viruses (PC)
  8. VIRUSCAN tested (PC)
  9. On Brain (PC)
  10. Re: Corporate culture shift resulting from virus mis(?)information
  11.  
  12. ---------------------------------------------------------------------------
  13.  
  14. Date:    Thu, 20 Jul 89 13:54:51 +0000
  15. From:    Fridrik Skulason <frisk@RHI.HI.IS>
  16. Subject: New PC virus (and really bad news)
  17.  
  18. Subject: A virus that can bypass anti-viral programs.
  19.  
  20. I got a letter yesterday. Translated to English, it reads:
  21.  
  22. Dear Fridrik,
  23.  
  24.         Thanks for the publicity you have given to our virus. To show our
  25.         gratitude, we have placed you on our distribution list. You will
  26.         from now on receive FREE copies of all our viruses.
  27.  
  28.         Enclosed is an update of our first virus, that will bypass every
  29.         virus protection programs.
  30.  
  31.         Expect our program for "improving" SYS-files Real Soon Now.
  32.  
  33.                                      (signed)   4418 and 5F19
  34.  
  35. The signature is the same as the last two words in the Icelandic virus.
  36.  
  37. By "publicity" they are probably referring to the fact that I have alerted
  38. every computer dealer in Reykjavik (all 12 of them that is) to the existence
  39. of an Icelandic virus.
  40.  
  41. I guess the last sentence in the letter is the first vaporware announcement
  42. by virus authors.
  43.  
  44. The bad news is that the virus will indeed bypass some anti-virus
  45. programs. Not all of them - programs that check for file length changes
  46. will find infected programs.
  47.  
  48. But - the virus will infect programs, even if programs like Flushoot+
  49. (or my own programs) are installed. It probably will also bypass
  50. all programs that just monitor interrupts.
  51.  
  52. I have not finished disassembling it, but I will send a copy of the listing
  53. to those who received the disassembly of the first version of the Icelandic
  54. virus.
  55.  
  56.  
  57. ------------------------------
  58.  
  59. Date:    Thu, 20 Jul 89 11:06:24 -0400
  60. From:    Valdis Kletnieks <VALDIS@vtvm1.cc.vt.edu>
  61. Subject: Re: CMS viruses (IBM CMS)
  62.  
  63. >2. neither MVS nor VM could be infected by 16 bytes of code in an none
  64. >obtrusive manner... an overwriting virus possibly...!! however these
  65. >are both large expensive mainframe SCP(system control programs) note I
  66. >didnt include cms in this he is a user interface!! but they most
  67. >defintely can be infected!!!!!!
  68.  
  69. First of all, I beleive it was 16 *lines* not 16 *bytes*.  Even in
  70. assembler, 16 lines will give you 64 bytes of code (assuming average
  71. 4/bytes instruction), and more if you allow macro use.
  72.  
  73. I'm unclear what you're saying - are you saying that VM and MVS are
  74. systems that "can't be infected non-obtrusively" or that they "can be
  75. infected"?
  76.  
  77. I have seen 5-line programs that broke VM.  Once you do that, all the rest
  78. is just pretty-printing.  And the 5-line program was SO unobtrusive that
  79. the author literally didn't KNOW for a while that he had done it.
  80. It turned out to be a bug in HIS program accidentally exploiting a bug
  81. in the SYSTEM.
  82.  
  83. IBM very recently (as an SPE apar to SP/4) fixed a BIG hole in the reader
  84. file support, where a sequence of 5 user commands would break a userid.
  85.  
  86. The bottom line is that (a) you can break it (b) if you're good, nobody
  87. will notice and (c) sometimes you don't even have to be very good...
  88.  
  89. >3. given the richness of the 2 above environments and both of them
  90. >predate any other System control programs currently used now... no
  91. >human intervention is necessary for an infection mechanism to
  92. >accomplish its designed task!!!!
  93.  
  94. Well, MVS/ESA can trace itself back to 1963 and the OS/360 project.
  95. However, CP/67 (the ancestor of VM/SP and VM/XA) dates to almost literally
  96. the same month in 1967 as the first attempts to bring Unix up.  And both
  97. Unix and VM are newer than the venerable Multics (which is still used at a
  98. fairly large number of sites).
  99.  
  100. And admittedly MVS and VM *can* both be broken.  Otherwise IBM would not
  101. have needed to issue 'Statements of Integrity' for them.
  102.  
  103. However, if anything, you got the point here backwards.  It is mostly the
  104. *newer*, *less mature* systems that are easily attacked and penetrated
  105. without human intervention.  Remember that MVS has literally 25 years
  106. of people breaking into it, while the Macintosh OS has a lot less
  107. experience in defending itself.
  108.  
  109. Yes, the older operating systems ARE generally more full-featured.
  110. But the features are generally a LOT more robust.
  111.  
  112. >4. to acheive point 3 above... one must be what is knwown in IBM
  113. >Parlance as a SYSPROG not just a technical support specialist... in
  114. >other words it most likely is not going to be the local 14 year old
  115. >sunnyvale hacker!!!(that would implement this code)
  116.  
  117. Ah yes - to break into VM without human intervention DOES require a fair
  118. amount of true wizardry.  However, you can trust that enough users will
  119. run anything that shows up that a trojan horse like the Christmas Card
  120. exec is effectively a virus.  Yes, technically the Christmas Exec was
  121. a trojan horse.  However,  that didn't stop it from taking out the
  122. BitNet academic network and the VNET IBM internal net just as effectively
  123. as the Morris worm did to the Internet.
  124.  
  125.                                    Valdis Kletnieks
  126.                                    Computer Systems Engineer
  127.                                    Virginia Tech
  128.  
  129. ------------------------------
  130.  
  131. Date:    Thu, 20 Jul 89 12:45:51 -0700
  132. From:    voder!nsc!berlioz.nsc.com!gwang@apple.com (George Wang)
  133. Subject: Re: Request for info on viruses (PC)
  134.  
  135. In article <0003.y8907031857.AA11952@ge.sei.cmu.edu> you write:
  136. >    We have had the same (c) Brain running around UB for some time now,
  137. >but have managed to kill it off. We Have the source code (written in C) for
  138. >NOBRAIN, which will remove the bad sectors, and volume. We had picked up
  139. >the cure from another University, and put it in all of our micro sites.
  140.  
  141. Can you email me the source code to NOBRAIN? I would like to
  142. install it on the school's University computers... We've
  143. been having trouble with the Brain Virus and would like
  144. to stop it.... Thanks
  145.  
  146. George
  147.  
  148. George Wang
  149. VLSI Software Engineer
  150. National Semiconductor
  151. Gwang@berlioz.nsc.com
  152. (408) 721-4365 Voice
  153.  
  154. ------------------------------
  155.  
  156. Date:    Thu, 20 Jul 89 13:09:08 -0700
  157. From:    huangcm@iris.ucdavis.edu (Christina M. Huang)
  158. Subject: VIRUSCAN tested (PC)
  159.  
  160. I ran VIRUSCAN Version 0.3V27 on some virus infected programs.  The
  161. following are the ones that it positively identified:
  162.  
  163. Italian (Ping Pong)
  164. Den Zuk
  165. Jerusalem
  166. Pakistani Brain
  167. 1701/1704 (Cascade)
  168. Alameda
  169. Lehigh
  170. Vienna (DOS62)
  171. April First
  172. Icelandic
  173. Fu Manchu
  174. Traceback
  175. Datacrime (1280/116B)
  176.  
  177. - -CH
  178.  
  179. ------------------------------
  180.  
  181. Date:    Fri, 21 Jul 89 09:18:29 -0000
  182. From:    A.SIGFUSSON@ABERDEEN.AC.UK
  183. Subject: On Brain (PC)
  184.  
  185. I got a copy of PC VIRUS LISTING by Jim Goodwin of a virus archive and
  186. I found that the copy of the BRAIN virus I have is different from what
  187. he describes.  The version I have is the SHOE_VIRUS which has the message
  188. "...VIRUS_SHOE RECORD, v9.0.  Dedicated to the....." and is said to be a
  189. modified version of the Brain-B virus which can infect hard disks.  I tried
  190. recently to infect a hard disk with it when I was experimenting with the
  191. F-PROT protection software but failed to infect the disk.  I booted the
  192. computer up on an infected floppy, several times, and the virus planted
  193. itself in the memory and infected every floppy I inserted after that exept
  194. those protected with F-INOC.  According to J. Goodwin this version of
  195. Brain should infect hard disks but SHOE_VIRUS v9.1 should not.  I was
  196. wondering if it was the other way around and if anyone has experience
  197. of Brain infecting hard disks.
  198.  
  199.                Thanks
  200.  
  201.              Arnor Sigfusson (A.SIGFUSSON@UK.AC.ABERDEEN)
  202.  
  203.  
  204.  
  205. ------------------------------
  206.  
  207. Date:    20 Jul 89 19:23:42 +0000
  208. From:    chinet!ignatz@att.att.com
  209. Subject: Re: Corporate culture shift resulting from virus mis(?)information
  210.  
  211.  
  212. In article <0004.y8907171856.AA19378@ge.sei.cmu.edu> DCD@CUNYVMS1.BITNET writes
  213. :
  214. >....   I am intrigued by what can only be called the return of MIS:
  215. >we all know the corporate Kulturkampf that took place not so many years
  216. >ago when microcomputers became readily available--the MIS people (in large
  217. >corporations) kicked and screamed, but eventually their power was diluted.
  218. >Now, I am seeing reports that their day has returned.  Relatively techno-
  219. >illiterate upper management sees reports on viruses in Time, etc., and puts
  220. >a call in that all decisions on software must be blessed from a newly power-
  221. >ful management structure.
  222. >
  223.         [A few examples elided]
  224. >
  225. >I have no doubt that such corporate shenanigans are taking place all
  226. >the time, and would be interested in any comments.
  227. >
  228. >Thanks for your time in reading this,
  229. >
  230. >        Robert Braham
  231. >E-mail: DCD@CUNYVMS1.BITNET
  232. >Home:   1315 Third Ave., 4D
  233. >        New York, NY  10021
  234. >        (212) 879-1026
  235.  
  236. I trust Robert reads this group; otherwise, well, he won't see this.
  237. I'm a consultant in the Chicago area, and have been for almost 11
  238. years now.  This means I get to encounter the MIS and computer
  239. policies of a number of different firms, both Fortune 500 and small
  240. ones.  Most definitely, the MIS departments are attempting to
  241. re-assert their control over computing resources, and use of the
  242. current panic concerning possible viruses, worms, and other
  243. infestations by crackers is one of the prime tools.  Unfortunately,
  244. these organizations often have little or no knowledge of the needs of
  245. the long-alienated users who now must clear requests through them;
  246. many are traditional IBM mainframe managers, who now must deal with
  247. the bewildering plethora of packages and utilities available to the
  248. micro- and mini-computer user.  The (unfortunate) result is that
  249. often, only a very few programs and packages are considered
  250. 'authorized', and restrictive (and usually unnecessary) controls are
  251. placed on procurement and use.
  252.  
  253. Even worse are some organizations who have installed usually
  254. unqualified personnel in the newly-created office of "Computer
  255. Security."  In one unnamed company, this person was a lawyer whose
  256. qualifications were that he knew how to use Lotus 1-2-3.  Period.  In
  257. these cases, it's particularly difficult to express the difference
  258. between accepting a source copy of a public domain program, and a
  259. binary copy--this person passed down a directive that *all* PD
  260. software was to be scrubbed ASAP on all corporate machines.  It took a
  261. **long** training session to explain the difference in verification
  262. capabilities, and why we really could safely review and use PD
  263. sources.
  264.  
  265. I'm in the position to argue with, and (often) successfully educate
  266. such organizations; but this is difficult for "real" employees, since
  267. such directives often come from individuals who are high enough in the
  268. hierarchy to make disagreement a somewhat risky proposition.  Also,
  269. the decision makers at this level may well not be computer literate
  270. themselves, and have neither the time nor the desire to do so--they
  271. want clear, concise advice from their experts, who are often those
  272. disenfranchised MIS people.  (Who are often not qualified
  273. themselves...see above.)
  274.  
  275. This is not a happy-making situation, and I don't have a blanket
  276. answer.  I think what, perhaps, will give us all the best ammunition
  277. to counter the rising hysteria is a clear, well-written text that is
  278. targeted at the intelligent layman, describing exactly what the attack
  279. vectors are, and what approaches can reasonably protect a distributed
  280. computing environment without unnecessary stifling of creative use or
  281. access to valuable programs.
  282.  
  283. ------------------------------
  284.  
  285. End of VIRUS-L Digest
  286. *********************
  287. Downloaded From P-80 International Information Systems 304-744-2253
  288.