home *** CD-ROM | disk | FTP | other *** search
/ Hacker 2 / HACKER2.mdf / virus / virusl2 / virusl2.229 < prev    next >
Text File  |  1995-01-03  |  14KB  |  345 lines
  1. VIRUS-L Digest   Wednesday,  1 Nov 1989    Volume 2 : Issue 229
  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. re: Virus scanning on PCs?
  17. Re: Protection in Operating Systems
  18. re: Where are the Sophisticated Viruses?
  19. re: Self-checking programs (PC)
  20. Re: Virus source available in Toronto
  21. Re: Self-checking programs (PC)
  22. Supplemental Security Info on DECnet Worm (VAX/DECnet)
  23. Re: Checksum programs
  24. Re: Imbedded virus detection
  25. Re: Checksum programs
  26.  
  27. ---------------------------------------------------------------------------
  28.  
  29. Date:    31 Oct 89 00:00:00 +0000
  30. From:    "David.M..Chess" <CHESS@YKTVMV.BITNET>
  31. Subject: re: Virus scanning on PCs?
  32.  
  33. > Do scanning programs (in particular scanv45) check video memory
  34. > for a virus?
  35.  
  36. Once again, it's important to remember that a virus has to get
  37. itself -executed- somehow.   That means altering some object
  38. that gets executed (typically EXE and COM files and boot
  39. sectors so far).   Nothing that I know of will execute code
  40. found in video memory.   So a virus, even if it did hide most
  41. of itself in the video memory, would have to change some
  42. executable object (COM or EXE file, boot record, etc) in order
  43. to get executed.   So, if you can check your executable
  44. objects thoroughly enough, it's not necessary to check
  45. video memory as well.   All the known viruses hide in
  46. EXE or COM files, or boot records, so those are the only
  47. things any scanner for known viruses has to check.  (This is
  48. about the same answer I gave last week to the question about
  49. viruses "hiding" in sectors marked as bad.)                    DC
  50.  
  51. ------------------------------
  52.  
  53. Date:    31 Oct 89 00:00:00 +0000
  54. From:    "David.M..Chess" <CHESS@YKTVMV.BITNET>
  55. Subject: Re: Protection in Operating Systems
  56.  
  57. Bill Davidsen's point that DOS allows all sorts of things that
  58. UNIX(tm) doesn't is quite true.   Remember, though, that viruses
  59. don't *have* to do any of those things (write over the o/s
  60. in memory, write directly to the hardware, etc) in order to
  61. spread.   See Cohen's "Computer Viruses - Theory and Experiments"
  62. paper for some quite convincing numbers about viruses and
  63. UNIX.   *Any* operating system that allows users to write
  64. programs and share information will be vulnerable to viruses.   DC
  65.  
  66. ------------------------------
  67.  
  68. Date:    31 Oct 89 00:00:00 +0000
  69. From:    "David.M..Chess" <CHESS@YKTVMV.BITNET>
  70. Subject: re: Where are the Sophisticated Viruses?
  71.  
  72. You're forgetting one important kind of virus detector: a
  73. general modification-detector that does a check-code of some
  74. kind (CRC, MDC, or whatever), and alerts the user when
  75. a file's *contents* (not the date) change.   There are
  76. enough people using such things (at least in the PC world;
  77. I don't know much about that Mac world) that I think even
  78. a virus that talked straight to the hardware to avoid
  79. "suspicious activity" detectors wouldn't get far before
  80. it was detected.                        DC
  81.  
  82. ------------------------------
  83.  
  84. Date:    31 Oct 89 00:00:00 +0000
  85. From:    "David.M..Chess" <CHESS@YKTVMV.BITNET>
  86. Subject: re: Self-checking programs (PC anti-virus protection)
  87.  
  88. > The basic idea is OK, but you need to use a "one-way" hash function,
  89. > rather than something readily invertible like a linear CRC.
  90.  
  91. John Sangster is basically correct, but I'd like to suggest that
  92. it's possible to get the advantages of a CRC (faster and more
  93. exportable than the DES), and still avoid invertibility.  The
  94. key (hehe) is that a CRC is easily invertible only if you know
  95. the polynomial used.   If a modification-detector were to use
  96. a different CRC polynomial for each user (based, for instance,
  97. on a key phrase elicited from the user at each run), and the
  98. database of CRCs were kept from the virus (to avoid the virus
  99. being able to calculate the polynomial from file-CRC pairs),
  100. the theoretical invertibility of the CRC wouldn't matter,
  101. because a virus would not have all the information needed
  102. to make an undetected change.
  103.  
  104. DC
  105.  
  106. ------------------------------
  107.  
  108. Date:    31 Oct 89 00:00:00 +0000
  109. From:    "David.M..Chess" <CHESS@YKTVMV.BITNET>
  110. Subject: Re: Virus source available in Toronto
  111.  
  112. >        however "Viruses , A high Tech disease" published only
  113. > overwriting viruses!!
  114.  
  115. Hm, maybe there are two versions of the book?   The one I have
  116. contains an almost-complete disassembly of the 648 (aka Vienna,
  117. DOS-62, etc) virus on pages 156-164.   This virus is a standard
  118. (very small) non-overwriting virus, that spreads between COM files,
  119. and leaves the function of the infected program intact.
  120.  
  121. DC
  122.  
  123. ------------------------------
  124.  
  125. Date:    31 Oct 89 12:54:19 +0000
  126. From:    leif@ambra.dk (Leif Andrew Rump)
  127. Subject: Re: Self-checking programs (PC anti-virus protection)
  128.  
  129. JHSangster@DOCKMASTER.ARPA writes:
  130. >               ... this product includes an "INSTALL" utility which
  131. >"vaccinates" the boot track and all executables on the disk.
  132. >"Vaccination" consists of appending a cryptographic "seal" checking
  133. >module (smaller than a typical virus!)  and patching the load module
  134.                                              ^^^^^^^^
  135. >header so that this module executes first, then passes control to the
  136. >original application program if the program is "clean", otherwise
  137. >halting and issuing a warning message.
  138.  
  139. If a virus killer can patch a program so can a virus! Exactly as virus
  140. detectors is able to find a virus by looking at the code so is the
  141. virus able to detect the virus killer and disable it! That's life!!
  142.  
  143.   Leif Andrew Rump, AmbraSoft A/S, Roejelskaer 15, DK-2840 Holte, Denmark
  144.  UUCP: leif@ambra.dk, phone: +45 42424 111, touch phone: +45 42422 817+313
  145.  
  146.    > > > Why are tall Irish girls with red hair so wonderful ? ? ? < < <
  147.  
  148.  
  149.  
  150. ------------------------------
  151.  
  152. Date:    Tue, 31 Oct 89 16:38:58 -0500
  153. From:    TENCATI@NSSDCA.GSFC.NASA.GOV (SPAN SECURITY MGR. (301)286-5223)
  154. Subject: Supplemental Security Info on DECnet Worm (VAX/DECnet)
  155.  
  156.  
  157. NETWORK SECURITY SUPPLEMENTAL INFORMATION - PROTECTING THE DECNET ACCOUNT
  158.  
  159. The most important thing that needs to be done to protect a system
  160. against the current WORM attacks is to modify accounts where
  161. USERNAME=PASSWORD.  This is the default configuration for the DECNET
  162. account.  This can be changed easily, but there appears to be some
  163. confusion about the effect that this has on a network. Changing the
  164. DECnet default password DOES NOT IMPACT the normal operation of DECnet
  165. in any way.
  166.                             --------
  167.  
  168. The following section provides some background material to illustrate
  169. this point:
  170.  
  171. On your system, issue the following commands from a priviliged
  172. (CMKRNL,BYPASS,SYSPRV) account:
  173.  
  174.         $MCR NCP (or $RUN SYS$SYSTEM:NCP)
  175.         NCP> show executor characteristics
  176.  
  177. This will produce a list that resembles the following:
  178.  
  179.  
  180.         Node Volatile Characteristics as of 31-OCT-1989 11:02:23
  181.  
  182.         Executor node = 6.133 (NSSDCA)
  183.  
  184.         Identification           = DECnet-VAX V4.7,  VMS V4.7
  185.         .
  186.         .
  187.         .
  188.         Nonprivileged user id    = DECNET
  189.         Nonprivileged password   = DECNET
  190.         .
  191.         .
  192.         .
  193.  
  194. This is your DECnet executor database.  The information listed is the
  195. default configuration for your node.  The information contained in this
  196. list includes "Nonprivileged user id" and "Nonpriviliged Password".
  197.  
  198. This information is what DECnet uses for userid/password when the
  199. connecting process a)does not have a proxy, b)does not specify a
  200. username/password as part of the access string, and c)does not
  201. have a different userid/password defined for the network object
  202. being invoked.
  203.  
  204. The access information contained in the executor database is used for
  205. reference only. The candidate userid and password (in this case DECNET
  206. and DECNET respectively) are then passed to LOGINOUT to validate them
  207. against the *REAL* information contained in SYSUAF.DAT.  If the
  208. information matches, the access is allowed. If the information does not
  209. match, the connecting user gets the following error messages:
  210.  
  211.          Unable to connect to listner
  212.          Login Information Invalid at Remote Node
  213.  
  214.                           --------
  215.  
  216. In order to correctly change your default network password so that your
  217. system cannot be easily exploited by the current DECnet WORM, the
  218. following 2 steps must be followed:
  219.  
  220. 1)  Change the password for user DECNET in SYSUAF.DAT:
  221.  
  222.         UAF> modify DECNET/Password=NEW_DECNET_PASSWORD
  223.  
  224.                                *NOTE*
  225.            It is advisable at this time to check that
  226.            certain other attributes of the DECNET user
  227.            are properly set:
  228.  
  229.            The ONLY access method for this account should
  230.            be NETWORK. The BATCH, REMOTE, INTERACTIVE,
  231.            and DIALUP fields should all read "--no access--"
  232.  
  233.            The value of PRCLM should be set to ZERO. This is
  234.            the number of (SPAWNed) sub-processes allowed.
  235.  
  236.            The flag LOCKPWD should be set. This prevents
  237.            anyone but a priviliged user from changing the
  238.            password. The following command can be used:
  239.  
  240.       UAF> MOD DECNET/FLAGS=LOCKPWD/PRCLM=0/NOBATCH/NODIAL/NOINTER/NOREM/NETW
  241.  
  242.  
  243. 2) Change the password for DECNET in your network executor database:
  244.  
  245.         NCP> set exec nonpriviliged password NEW_DECNET_PASSWORD
  246.         NCP> define exec nonpriviliged password NEW_DECNET_PASSWORD
  247.  
  248. The important thing to remember is that the password must be changed in
  249. BOTH places, otherwise your network WILL break.  The worm is breaking
  250. nodes by penetrating the DECNET account, and changing only the UAF
  251. password with the $SET PASSWORD command.  By not changing the NCP
  252. password, the network no longer accepts INBOUND connections.
  253.  
  254. For more information, consult the VAX/VMS manuals:
  255.  
  256.    VMS V4.X - Volume 6 "Networking Manual"
  257.    VMS V5.x - Volume 5A&5B "Guide to DECnet-VAX Networking"
  258. - ---------------------------------------------------------------------------
  259. Ron Tencati                           |   NCF::TENCATI /6277::TENCATI
  260. SPAN Security Manager                 |   Tencati@Nssdca.gsfc.nasa.gov
  261. NASA/Goddard Space Flight Center      |   (301)286-5223
  262. Greenbelt, MD. USA                    |
  263. - ---------------------------------------------------------------------------
  264.  
  265. ------------------------------
  266.  
  267. Date:    31 Oct 89 20:54:37 +0000
  268. From:    kerchen@iris.ucdavis.edu (Paul Kerchen)
  269. Subject: Re: Checksum programs
  270.  
  271.  
  272. RADAI1@HBUNOS.BITNET (Y. Radai) writes:
  273.  
  274. >  In my opinion, the most important requirements on a checksum program
  275. >are:
  276. >(5) It must be convenient to specify and update the list of files to
  277. >    be checksummed.
  278.  
  279. This point brings up a problem which is common to most checksumming
  280. solutions: where does one store these checksums and their keys?  If
  281. they are stored on disk, they are vulnerable to attack just like
  282. programs.  That is, a virus could infect the program and then update
  283. its checksum, since the key must be somewhere on disk as well (unless
  284. the user enters it every time they compute a checksum--yecch!) and one
  285. must assume that the checksum algorithm is known.  Or,
  286. more simply, a virus could simply wipe out all the checksums,
  287. leaving the user to decide which files were infected.  Storing the
  288. 'sums off line would insure security, but at what cost?  Checking
  289. and updating the 'sums with any frequency would become tedious at best.
  290. I don't mean to rain on this parade, but this issue is one which must
  291. be considered by anyone writing a checksum-based anti-viral program.
  292.  
  293. Paul Kerchen                            | kerchen@iris.ucdavis.edu
  294.  
  295. ------------------------------
  296.  
  297. Date:    Wed, 01 Nov 89 09:32:37 -0500
  298. From:    ZLCBEOWEN@csvax.qut.oz
  299. Subject: Re: Imbedded virus detection
  300.  
  301. Bob McCabe writes:
  302. >  While working out the algorithm for this check it struck me
  303. >that it should be possible to work out a scheme by which any
  304. >program could check itself at load time for infection.
  305.  
  306. Have a look at PC Magazine Aug. 1989, 8(14), p411.  There is
  307. some code there which does exactly this.
  308. - --
  309. Chris Owen                            | zlcbeowen@csvax.qut.edu.au
  310. Library                               | phone:  +61 7 223 2406
  311. Queensland University of Technology   | fax:    +61 7 229 0874
  312. Brisbane, AUSTRALIA                   |
  313.  
  314. ------------------------------
  315.  
  316. Date: 1 Nov 89 13:47:43 GMT
  317. From: comcon!roy@uunet.UU.NET (Roy M. Silvernail)
  318. Subject: Re: Checksum programs
  319.  
  320. RADAI1@HBUNOS.BITNET (Y. Radai) writes:
  321.  
  322. >   In my opinion, the most important requirements on a checksum program
  323. > are:
  324. > (2) Even if the checksum algorithm and checksum length are known,
  325. >     without knowledge of the key (the generating polynomial in the
  326. >     case of a CRC algorithm), it should be impossible to modify a file
  327. >     in such a way that the checksum remains unchanged.
  328.  
  329. What about doing both an 8-bit and a 16-bit CRC on the file, along with
  330. a record of the file length? It seems to me that an altered file might
  331. be able to duplicate one of the checksum, but not both, and certainly
  332. not both sums *and* the length record. (This might also reduce the need
  333. for each machine generating a unique checksum... something I have no
  334. clue about. How would this be done?)
  335.  
  336. Roy M. Silvernail | UUCP: uunet!comcon!roy  |  "No, I don't live in an igloo!"
  337. [ah, but it's my account... of course I opine!]           -Sourdough's riposte
  338. SnailMail: P.O. Box 210856, Anchorage, Alaska, 99521-0856, U.S.A., Earth, etc.
  339.  
  340. ------------------------------
  341.  
  342. End of VIRUS-L Digest
  343. *********************
  344. Downloaded From P-80 International Information Systems 304-744-2253
  345.