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

  1. VIRUS-L Digest              Monday, 24 Apr 1989         Volume 2 : Issue 97
  2.  
  3. Today's Topics:
  4. Worms and Trojan Horse talk at NETCON.
  5. Request for guest speakers.
  6. Re: McAfee's SENTRY a-v software (PC)
  7. Congress catches the computer virus bug...
  8. Using Checkfunctions For Virus Detection (General Interest)
  9. BALL VIRUS (PC)
  10.  
  11. ---------------------------------------------------------------------------
  12.  
  13. Date:    Fri, 21 Apr 89 18:52 EDT
  14. From:    John McMahon - NASA GSFC ADFTO - <FASTEDDY@DFTBIT.BITNET>
  15. Subject: Worms and Trojan Horse talk at NETCON.
  16.  
  17. Conference Announcement:
  18.  
  19.         NETCON 1989 - A meeting of BITNET users in Baltimore, Maryland
  20.         during Memorial Day weekend will feature the following speakers
  21.         during the Saturday technical sessions:
  22.  
  23.                 David Bolen - Speaking on the XYZZY utility
  24.  
  25.                 Valdis Kletnieks - Speaking on RELAY Version 2
  26.  
  27.                 John McMahon - Speaking on Worms, Trojan Horses and
  28.                                Computer Networking.
  29.  
  30.         For further information contact Reba Taylor at REBAT@VTVM1.BITNET
  31.         and Joe Ogulin at P12I1798@JHUVM.BITNET
  32.  
  33.  
  34. I figured that was a good way to plug my upcoming talk at NETCON 1989.
  35.  
  36. For those of you who are curious, "Worms, Trojan Horses and Computer
  37. Networking" will be an hour (or so) long talk where I will be doing a
  38. novice level review of three networking "events".
  39.  
  40.         The CHRISTMAS EXEC Trojan Horse (and similar) on BITNET,
  41.         The Father Christmas Worm on SPAN/HEPNET,
  42.         and (of course) the Morris Internet Worm.
  43.  
  44. I plan to point out during my talk that BITNET is beginning to coexist
  45. with other networks (e.g. JNET over SPAN & HEPNET, BITNET2 over
  46. NSFnet) and that an "attack" on another network can affect BITNET.
  47.  
  48. Similarly, I am going to talk a bit about "the costs" that a worm
  49. attack can incur.  Costs in wasted time, personnel, network resources
  50. and the legal costs.  Obviously I want to discourage this kind of
  51. foolishness (worms), my machine is on several networks!
  52.  
  53. If you are interested in attending, or wish to learn more about
  54. NETCON, please contact Reba Taylor at REBAT@VTVM1 and/or Joe Ogulin at
  55. P12I1798@JHUVM.BITNET
  56.  
  57. Any questions/suggestions/comments about my talk can be directed to me...
  58. +------------------------------------+-----------------------------------+
  59. |John "Fast Eddie" McMahon           |Span: SDCDCL::FASTEDDY (Node 6.9)  |
  60. |Advanced Data Flow Technology Office|Arpa: FASTEDDY@DFTNIC.GSFC.NASA.GOV|
  61. |Code 630.4 - Building 28/W255       |Bitnet: FASTEDDY@DFTBIT            |
  62. |NASA Goddard Space Flight Center    |GSFCmail: JMCMAHON                 |
  63. |Greenbelt, Maryland 20771           |Phone: x6-2045                     |
  64. +------------------------------------+-----------------------------------+
  65.  
  66. ------------------------------
  67.  
  68. Date:    Sat, 22 Apr 89 16:12 EST
  69. From:    Space, the final frontier.... <KUMMER@XAVIER.BITNET>
  70. Subject: Request for guest speakers.
  71.  
  72.      I've been recently elected secretary of the Xavier University
  73. chapter of the ACM and I'm sending out a request for guest speakers on
  74. the subject of viruses/worms/trojan horses for the fall semester of
  75. this year.  If anyone is interested or knows of someone that would be
  76. interested, please contact me.  My address is KUMMER@XAVIER.BITNET.
  77.  
  78. Thanks in advance,
  79.  
  80. Tom Kummer
  81.  
  82. ------------------------------
  83.  
  84. Date:    Sat, 22-Apr-89 13:20:56 PDT
  85. From:    portal!cup.portal.com!Gary_F_Tom@Sun.COM
  86. Subject: Re: McAfee's SENTRY a-v software (PC)
  87.  
  88. In VIRUS-L #2.96, David Bader writes about John McAfee's SENTRY
  89. anti-viral program, and concludes that "frankly --it is worthless."  I
  90. tried SENTRY myself before forwarding it to the VIRUS-L moderator, and
  91. I'd like to try to address David's concerns.
  92.  
  93. David states:
  94. > I followed the instructions on installation, and it automatically
  95. > places itself in autoexec.bat and reboots (maybe John, you could have
  96. > told me that you were going to modify my file, or that you would do a
  97. > cold boot - for me, it matters.)
  98.  
  99. The SENTRY.DOC installation instructions state:
  100.  
  101.     "The SENTRY installation will re-boot your system and then begin
  102.   its logging function.  It will create a log file called SENTRY.LOG
  103.   and store it at the root of your boot disk.  It will then install
  104.   the SENTRY check routine at the root of your boot disk and include
  105.   it as the first program in your autoexec.bat routine.  SENTRY.COM
  106.   MUST REMAIN THE FIRST INSTRUCTION IN YOUR AUTOEXEC IN ORDER TO
  107.   OPERATE CORRECTLY."
  108.  
  109. In addition, the SENTRY installation program prints a message that it
  110. is "Ready to re-boot this system," warns the hard-disk user to remove
  111. any floppy disks, and prompts for a key-press before automatically
  112. re-booting.  I thought the instructions and the program messages were
  113. clear enough about what would happen during installation. I was only
  114. surprised that installation took much less time than I thought it
  115. would, knowing that the program had to scan the entire disk directory
  116. and examine every executable file.
  117.  
  118. > Anyway, After Sentry did a check of filesize and a random checksum
  119. > at the beginning, middle, and end of every file on my harddisk, it
  120. > told me nothing.
  121.  
  122. After its initial installation, there is nothing to tell.  David might
  123. have misunderstood the purpose of SENTRY.  It assumes that you start
  124. with a virus-free system environment, and attempts to detect viral
  125. infections by warning you of changes in that environment.  The
  126. installation process does not look for pre-existing viruses, so no
  127. messages about them are printed.
  128.  
  129. > Ok, so I run Sentry a second time just to see what happens and I get
  130. > told my interrupt vectors have changed and I should contact someone
  131. > because that could mean a virus.  Have you ever heard about
  132. > FASTOPEN, or FluShot Plus, or one million other programs that I give
  133. > permission to to take over my interrupt vectors?
  134.  
  135. As emphasized in the installation instructions, SENTRY must be run as
  136. the first program in AUTOEXEC.BAT (that is, immediately after booting
  137. and loading CONFIG.SYS drivers) in order to work correctly.  The
  138. interrupt vectors and programs are checked against the log at that
  139. time.  If they match, then after that it doesn't matter which of those
  140. programs you load or what interrupt vectors they use -- they should
  141. all be free of viruses.
  142.  
  143. > ... And then, after taking a minute to scan all my files, I would
  144. > appreciate "XXXXX file changed since last use" - NOT "3 files were
  145. > modified".  Useless, John, absolutely useless.
  146.  
  147. This comment baffles me.  My experience has been that whenever SENTRY
  148. finds a changed file, it stops, displays the filename and a message
  149. about what has changed, and then waits for the user to press a key.
  150. For example:
  151.  
  152.    WARNING - The file C:\UTIL\LIST.COM has different time.
  153.    A VIRUS INFECTION MAY HAVE OCCURRED
  154.    PLEASE SEE THE SENTRY USER MANUAL FOR INSTRUCTIONS
  155.  
  156.    PRESS ANY KEY TO CONTINUE
  157.  
  158. Only at the end of its checking does it print a summary line:
  159.  
  160.    250 files checked.  1 changes detected.
  161.  
  162. Perhaps David is using an older version of SENTRY, not the one that I
  163. sent to Ken.  In any case, I hope that David's unhappy experience does
  164. not dissuade interested parties from trying the program out for
  165. themselves.
  166.  
  167. For me, SENTRY offers a good combination of safety (provided by early
  168. detection of possible infections), convenience (automatic checking
  169. whenever the machine is booted), compatibility (no interrupt vector or
  170. memory buffer conflicts), and performance (checking is fast,
  171. re-installation is fast, and since it is non-resident, it does not
  172. take cpu cycles or memory away from other programs).  It's true that
  173. SENTRY does not prevent viral infections from occurring, nor does it
  174. remove viral infections once they have occurred.  As a tool for
  175. quickly detecting new viral infections, however, I find it to be far
  176. from "useless."
  177.  
  178. Gary Tom
  179. garyt@cup.portal.com
  180. sun!portal!cup.portal.com!garyt
  181.  
  182. ------------------------------
  183.  
  184. Date:    Sun, 23 Apr 89 14:45:08 EST
  185. From:    dmg@mwunix.mitre.org
  186. Subject: Congress catches the computer virus bug...
  187.  
  188. I received the following message from the internal security conference
  189. at MITRE.  I thought others here might have some observations on
  190. this...
  191.  
  192. David Gursky
  193. Member of the Technical Staff, W-143
  194. Special Projects Department
  195. The MITRE Corporation
  196.  
  197.  ------- Forwarded Message
  198.  
  199. Forum-Transaction:  [0753] in the >site>forum_dir>bb meeting
  200. Transaction-Entered-By:  LGMartin.SAISS@DOCKMASTER.ARPA
  201. Transaction-Entered-Date:  24 Feb 89 16:42 EDT
  202.  
  203. The Senate Judiciary Committee is holding a public hearing on viruses on
  204. Tuesday, 28 February 1989, in Room 226 of the Dirksen Senate Office
  205. Building from 1000 to 1300. I have not heard who is going to testify,
  206. but I assume it is preliminary to any vote on the Virus Eradication Act
  207. of 1989.  Larry.
  208.  
  209. [Ed. Meeting delays deleted...]
  210.  
  211. ======================================================
  212. Forum-Transaction:  [0755] in the >site>forum_dir>bb meeting
  213. Transaction-Entered-By:  JWilliams.Grapevine@DOCKMASTER.ARPA
  214. Transaction-Entered-Date:  28 Feb 89 10:36 EDT
  215.  
  216. I have commented on the draft of HR 55 as of 1/27/89, and it is
  217. essentially similar in wording to Al's citation, except that I believe
  218. it now invokes a maximum penalty of 20 years.
  219.  
  220. Be that as it may, I believe much work is needed on the wording: for
  221. instance, it appears that to me that the Internet Worm would not have
  222. been illegal if it had functioned as intended: a one-time surreptitions
  223. invasion, and low-level reproduction.
  224. =======================================================
  225. Forum-Transaction:  [0756] in the >site>forum_dir>bb meeting
  226. Transaction-Entered-By:  AArsenault.Standards@DOCKMASTER.ARPA
  227. Transaction-Entered-Date:  1 Mar 89 08:30 EDT
  228.  
  229. Thanks, Mike, for the update.  Of particular concern to me in the bill
  230. is that it doesn't seem to do a good job of defining precisely what is
  231. illegal.  Based on the '88 text, it seems clear that if I give you a
  232. program that I know has a bug in it, and don't tell you, I'm guilty
  233. under this bill.  (Granted, I should not have given you a program with a
  234. known bug without telling you, but I really don't think that that was
  235. what the bill's authors had in mind.)  What's worse, I'm not sure I'm
  236. safe from prosecution if I give you a text editor/word processing
  237. package that works properly!
  238.  
  239. (Why do I say that?  Because every text editor/word processor I know of
  240. has commands that can cause "damage" - by deleting things!  Thus, the
  241. case comes down to a question of whether or not I "told" you about the
  242. damage that can be done by using the delete commands.  I've seen a lot
  243. of documentation that did NOT have big red warning signs all over the
  244. place, warning people about what can happen.  And then, of course, since
  245. DOS has a command that will let me format my hard disk, and that's not
  246. well documented at all, maybe we can start going after people big time.
  247. A felony for shoddy documentation!)
  248.  
  249. (Of course, one can defend against prosecution by claiming that the text
  250. editor /word processor/operating system did in fact contain
  251. documentation describin
  252.  what could happen if the user wasn't careful.  But then, so could the
  253. writer of a "real virus".  After all, if one ran the executable file
  254. through a debugger before execution, one would see the ASCII strings
  255. identifying the file as a virus, and warning that executing it would be
  256. hazardous to one's health.)
  257.  
  258.                                         Al
  259.  
  260. NOTE:  THE ABOVE OPINIONS ARE MINE.  MINE AND NOBODY ELSE'S.  UNDER NO
  261. CIRCUMSTANCES SHOULD THEY BE INTERPRETED AS REPRESENTING ANYBODY ELSE -
  262. OR ANY ORGANIZATION, WHETHER I WORK FOR IT OR NOT!!  ON TOP OF THAT, I
  263. AIN'T NO LIARYER, JUST A PLAIN AND HUMBLE LAYMAN WHAT SPEAKS UP OUT OF
  264. TURN ON OCCASION.
  265.  
  266. [Ed. More meeting delays...]
  267.  ------- End of Forwarded Message
  268.  
  269. ------------------------------
  270.  
  271. Date:    Sun, 23 Apr 89 16:53:37 EST
  272. From:    dmg@mwunix.mitre.org
  273. Subject: Using Checkfunctions For Virus Detection (General Interest)
  274.  
  275. I've been going through the Virus-L archives doing some background for
  276. my work on viruses here at MITRE.  I'm up to late June of last year,
  277. when there was a strong debate about the merits of using a
  278. checkfunction to detect the presence of viruses in applications.  To
  279. remind everyone, the consensus at that time was that using a
  280. checkfunction in such a manner would only be effective against the
  281. simplest of viruses, that an advanced virus would be resiliant against
  282. detection in such a manner.
  283.  
  284. I believe it is possible to use a checkfunction in a constructive
  285. manner to detect even the most advanced computer viruses, and it
  286. involves a technique called a "cryptographic checkfunction".
  287.  
  288. In a normal checkfunction, your have an arbitrarily long string x
  289. (which is really an application) that you apply to function [f(x)]
  290. that results in the value for your checkfunction value.  A
  291. cryptographic checkfunction adds an addition function [lets call it
  292. q(x)] that encrypts an arbitraily long string.  Instead of making the
  293. result of f(x) being the checkfunction value, the result of f(q(x)) is
  294. the checkfunction value.  Any foreign data (z) inserted into x would
  295. not only have to take into account how the checkfunction [f(x)]
  296. operates, but how the encryption algorithm [q(x)] operates.  This task
  297. can be made even more difficult by choosing a key for q(x) that is
  298. dependent upon x itself.
  299.  
  300. [In other words, suppose your have the string X1 X2 X3 X4.  You apply
  301. this string to q(x) and the result is Y1 Y2 Y3 Y4.  Now suppose you
  302. have a virus string Z1 Z2 that inserts itself into X1... so you now
  303. have (for instance) X1 X2 X3 Z1 Z2 X4.  The result of applying this to
  304. q(x) would be something like Y1 Y2 Y3 A1 A2 A3, instead of Y1 Y2 Y3 A1
  305. A2 Y4.]
  306.  
  307. A problem with this is key-dependent encryption algorithms are not
  308. exactly speed demons, but the new generation of microprocessors may
  309. have the horse- power for them to be used effectively.  Comments
  310. anyone?
  311.  
  312. David Gursky
  313. Member of the Technical Staff, W-143
  314. Special Projects Department
  315. The MITRE Corporation
  316.  
  317. ------------------------------
  318.  
  319. Date:    Mon, 24 Apr 89  14:23:12 TST
  320. From:    Koyun@TRBOUN
  321. Subject: BALL VIRUS (PC)
  322.  
  323.     HI!
  324.     I HAVE AN IBM PC-XT COMPATIBLE.  LAST DAY WHEN I LOOKED FOR A
  325. PROGRAM I SEE THAT ONE OF MY PROGRAM WAS DESTROYED.THERE WAS A BAD
  326. CULSTER ON IT.  WHEN I TRY TO VERIFY HARDDISK SUDDENLY A BALL OCCURED
  327. AND BEGAN TO HIT BORDERS AND LETTERS,AND WHEN I TRY TO VERIFY IT
  328. OCCURS AGAIN.
  329.     IF SOMEBODY KNOW ANYTHING ABOUT THIS VIRUS OR HAVE AN INJECT,PLEASE
  330. SEND ME .
  331.     MY ADRESS IS  KOYUN@TRBOUN.BITNET
  332.     THANKS.....
  333.                       TAN KOYUNOGLU
  334.                       BOSPHORUS UNIVERSITY
  335.  
  336. ------------------------------
  337.  
  338. End of VIRUS-L Digest
  339. Downloaded From P-80 International Information Systems 304-744-2253
  340.