home *** CD-ROM | disk | FTP | other *** search
/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / virusl / vl04_106.txt < prev    next >
Encoding:
Internet Message Format  |  1996-09-04  |  21.1 KB

  1. From:       Kenneth R. van Wyk (The Moderator) <krvw@CERT.SEI.CMU.EDU>
  2. Errors-To: krvw@CERT.SEI.CMU.EDU
  3. To:       VIRUS-L@IBM1.CC.LEHIGH.EDU
  4. Path:      cert.sei.cmu.edu!krvw
  5. Subject:   VIRUS-L Digest V4 #106
  6. Reply-To:  VIRUS-L@IBM1.CC.LEHIGH.EDU
  7. --------
  8. VIRUS-L Digest   Thursday, 20 Jun 1991    Volume 4 : Issue 106
  9.  
  10. Today's Topics:
  11.  
  12. Re: Virus scanners (PC)
  13. Questons about "Disinfectant" are ANSWERED.. Thanks (Mac)
  14. virus detection by scanners ? (PC)
  15. re: FSP and sales figures (was: Into the 1990s)
  16. Int 24 virus info needed (PC)
  17. Re: Checksumming
  18. How viruses actually spread
  19. Review of Victor Charlie (addendum) (PC)
  20. Spanish Virus/Telefonica (PC)
  21. Re: Scanning infected files (PC)
  22. Re: joshi & vsum & f-prot & ll format (PC)
  23. Re: virus detection by scanners ? (PC)
  24. Requirements for Virus Checkers (PC)
  25. Re: Interesting interaction ( VIRx & SCAN ) (PC)
  26.  
  27. is a moderated, digested mail forum for discussing computer
  28. virus issues; comp.virus is a non-digested Usenet counterpart.
  29. Discussions are not limited to any one hardware/software platform -
  30. diversity is welcomed.  Contributions should be relevant, concise,
  31. polite, etc.  Please sign submissions with your real name.  Send
  32. contributions to VIRUS-L@IBM1.CC.LEHIGH.EDU (that's equivalent to
  33. VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
  34. anti-virus, documentation, and back-issue archives is distributed
  35. periodically on the list.  Administrative mail (comments, suggestions,
  36. and so forth) should be sent to me at: krvw@CERT.SEI.CMU.EDU.
  37.  
  38.    Ken van Wyk
  39.  
  40. --------------------------------------------------------------------------------
  41.  
  42. Date:    18 Jun 91 11:53:35 -0400
  43. From:    "David.M.Chess" <CHESS@YKTVMV.BITNET>
  44. Subject: Re: Virus scanners (PC)
  45.  
  46. >Date:    Mon, 17 Jun 91 13:05:00 -0400
  47. >From:    Al Woodhull <AWOODHULL@hamp.hampshire.edu>
  48.  
  49. >The new files contain all of the infected code and so are
  50. >good test targets, but since there is no way to execute the infected
  51. >code it is essentially just a block of data.
  52.  
  53. They aren't necessarily good test targets.  "Bulk" scanners (like
  54. IBM's), that look through every byte of every file for patterns, will
  55. identify them as infected, but scanners that look at, for instance,
  56. specific areas based on the file's entrypoint will not see them as
  57. infected, even if they work fine on actually-infected files.  I
  58. believe Alan Solomon's Anti-Virus Toolkit (I may have the name wrong)
  59. is of the latter kind, for instance.  So if a scanner doesn't see
  60. those files as infected, it doesn't necessarily mean that it wouldn't
  61. see a normally-infected file as such...
  62.  
  63. DC
  64.  
  65. ------------------------------
  66.  
  67. Date:    Tue, 18 Jun 91 11:11:11 -0600
  68. From:    James Firmiss <firmiss@cae.wisc.edu>
  69. Subject: Questons about "Disinfectant" are ANSWERED.. Thanks (Mac)
  70.  
  71. Thanks for all the info...  
  72.  
  73.  "Vaccine (TM) 1.0.1", "KillVirus", and "Kill WDEF - virus INIT" have
  74. been cast into our pit of obsolete & useless programs (with "Ferret"
  75. and "Kill Scores").
  76.   Disinfectant 2.4 and it's init are on all our MACs.
  77.   Sam Intercept is on all of them too.  I hear it requres some sort
  78. of password to remove it.  I've never tried to but I don't think anyone
  79. here remembers what the password is.  I'll have to RTFM (if I can FIND TFM).
  80.  
  81.  
  82.  + -  - +   |... P_lasma         --- James Firmiss     (Foxx Fox) ---
  83.   - + +  -  |... S_ource         --- firmiss@cae.wisc.edu         ---
  84.  +  +  - =====>+ I_on            --- Univ. of Wisc. Madison       ---
  85.   -  +  -   |... I_mplantation   --- Materials Science Program    ---
  86.  - + - + -  |..._______________________________________________________
  87.          "Beep.  Beep Beep.  Beep Beep."  -  vi editor
  88.  
  89. ------------------------------
  90.  
  91. Date:    18 Jun 91 13:05:32 -0400
  92. From:    "David.M.Chess" <CHESS@YKTVMV.BITNET>
  93. Subject: virus detection by scanners ? (PC)
  94.  
  95. >From:    hermann@uran.informatik.uni-bonn.de (Hermann Stamm)
  96. >Date:    07 Jun 91 14:33:23 +0000
  97.  
  98. >I have a few questions concerning detection of virii in general and
  99. >1701 in special.
  100.  
  101. The main thing you've discovered here is that scanners only reliably
  102. detect the viruses that they know about.  If you create a new virus
  103. (from scratch, or by modifying an old one), it's very likely that some
  104. scanners will no longer detect it.  No big surprises there!
  105.  
  106. >First of all, I hope that only good guys are on this list, because the
  107. >remarks made here would otherwise result in hundreds of newly virii.
  108.  
  109. Almost certainly a false hope; there's no reason to think that no
  110. virus writers are reading this.  On the other hand, I think they
  111. already understand the principle!  One could have wished you'd been a
  112. little less explicitly helpful to them, but I don't it'll hurt, at
  113. least in the long run.
  114.  
  115. > - what other scanner should I try for these versions ?
  116.  
  117. Some scanners may be "lucky", and see your home-grown variants as
  118. infected.  IBM's Virus Scanning Product, for instance, will recognize
  119. the first of your monsters as a variant of the 1701.
  120.  
  121. > - is it true, that any scanner must try to look at the
  122. >   semantics of such decoders, and not at the shape ?
  123. >   (undecidable problem ?)
  124.  
  125. Yep, deciding whether or not a given program is a virus is definitely
  126. undecidable.  Fred Cohen proved that awhile back.  So if you take some
  127. existing virus, and make some changes to it, the question of whether
  128. or not the result is still a virus is not one that *any* program is
  129. going to get right all the time.  Scanners reliably detect only
  130. *exactly* the viruses they know about, not variants that you (probably
  131. unwisely) choose to create.
  132.  
  133. > - which systems are good by looking at the length of
  134. >   files and reporting differences ?
  135.  
  136. Any good modification-detection program will look at the *contents* of
  137. files (not just the length), and tell you what's changed.  Of course,
  138. if you want to be able to trust the result, you have to get the
  139. machine into a known state first (cold-boot from a trusted floppy,
  140. don't run anything from the suspect hard disk).
  141.  
  142. > - Is the following behaviour possible for a virus:
  143. >
  144. >   After getting resident, it forces to do a warm-start
  145. >   with ctrl-alt-del, and then it copies itself to all
  146. >   .com-files encountered during rebooting
  147. >   (like command.com, ...).
  148. >
  149. >   I think, that this is the way most of my .com-files
  150. >   were infected.
  151.  
  152. A virus could certainly do that, but the 1701 doesn't.  Most likely it
  153. infected something in the autoexec, so that the next time you booted,
  154. it got control early, and then infected everything else executed
  155. thereafter (that's how the 1701 works; it infects every com executed
  156. after you run the first infected one).
  157.  
  158. DC
  159.  
  160. P.S. Assume that anything you post in public will be read by
  161.      large number of virus authors.   Please *don't* post
  162.      live virus code, or suggestions for improvements to
  163.      existing viruses!   *8)
  164.  
  165. ------------------------------
  166.  
  167. Date:    Tue, 18 Jun 91 13:24:44
  168. From:    microsoft!c-rossgr@uunet.uu.net
  169. Subject: re: FSP and sales figures (was: Into the 1990s)
  170.  
  171. >From:    padgett%tccslr.dnet@mmc.com (A. Padgett Peterson)
  172.  
  173. (Sorry for the delay...off line for a while)
  174.  
  175. >Ross: we seem to be cross communicating. In our shop we do not use "pre-
  176.       >installed" copies, no two machines are alike anyway & we are running
  177.       >everything from DOS 2.0 up. On installation, the package we use takes
  178.       >3-5 minutes to take a "snapshot" of the PC and record every executable
  179.       >on it during installation.
  180.  
  181. So, then, you have to install the program on each machine.  Taking
  182. that "snapshot" is a good idea, but still has problems if you use a)a
  183. new seed on each machine and b) store that seed someplace where it can
  184. be seen by "the bad guy".
  185.  
  186. If someone is going to subvert the code, they're gonna subvert the code
  187. and there's nothing we can do about it.  It's not as if DOS were a real
  188. operating system -- it provides no real protection and simply putting
  189. more and more layers of "feel-good-and-warm-and-fuzzy" dressing on DOS
  190. simply makes a person *feel* better, but provides them with nothing.
  191.  
  192. If somebody wanted to mcreate a virus that gets around my stuff and the
  193. code of everybody else out there, they probably could.  Targetting my
  194. code is sorta silly: it's too easy to simply go right out to the disk
  195. controller if you really needed to.
  196.  
  197. >Only if the "bad guy" knows where it is stored and if the offsets are
  198. >the same on every machine - one of the drawbacks to
  199. >"pre-installation". If you cannot ensure the physical integrity of the
  200. >machine all bets are off. It would take a complex and specifically
  201. >targetted piece of software to be able to determin that you were there
  202. >(and not some other routine) and bypass it - not for an amateur.
  203.  
  204. Right.  So, if they're targetting my code, no protection will suffice,
  205. if they are not targetting my code, why bother making things more
  206. complex.  Your mileage may, of course, vary.
  207.  
  208. > One
  209. >of the problems is that at present there is a single criteria for
  210. >judging PC protection programs: the number of viruses it detects.  In
  211. >actuality, this is one of the lesser threats that a full package
  212. >should take care of.
  213.  
  214. Well, the efficiency of a package in stopping viral infections has yet
  215. to have any scale to measure it by.  When such a scale exists, all the
  216. vendors will be climbing to the top of that heap, too.
  217.  
  218. Ross
  219.  
  220. (My views, not Microsoft's)
  221.  
  222. ------------------------------
  223.  
  224. Date:    Tue, 18 Jun 91 14:26:47 -0400
  225. From:    Alex Nemeth <AN5@CORNELLC.BITNET>
  226. Subject: Int 24 virus info needed (PC)
  227.  
  228. I remember something about an INT 24 virus that was discussed several
  229. months ago. could someone pleas send me some info on it, or tell me
  230. which back issue of Virus-L where i might find more.
  231.  
  232. Thanks
  233.  
  234. Alex Nemeth
  235. AN5@cornellc.cit.cornell.edu
  236. AN5@CORNELLC.BITNET
  237.  
  238. ------------------------------
  239.  
  240. Date:    Tue, 18 Jun 91 15:17:36 -0400
  241. From:    padgett%tccslr.dnet@mmc.com (A. Padgett Peterson)
  242. Subject: Re: Checksumming
  243.  
  244. >From:    Y. Radai <RADAI@HUJIVMS.BITNET>
  245.  
  246. >  Mike Lawrie writes:
  247. >>                         ... sooner or later this scenario [infecting
  248. >>files by performing SCAN while a virus like Plastique is in RAM] will
  249. >>re-occur, as you will get hit with a similar type of virus that McAfee
  250. >>has not yet catered for, even if you have their very latest version.
  251. >Right;
  252.  
  253. First, organizations have been woefully lacking in training of
  254. personnel expected to deal with malicious software (a management
  255. problem). Our technicians get two days of targetted training before
  256. being certified to respond to suspected viruses.
  257.  
  258. That said, since employees are instructed to power down and quarentine
  259. any PC suspected of having a virus, the first action after questioning
  260. the employee for symptoms is to cold boot from a write-protected
  261. floppy and check the system out in that manner including a "scan" of
  262. the disk and examination of the MBR and DOS Boot Record
  263.  
  264. Only if that comes up negative is the PC allowed to boot itself. At
  265. this point the system integrity is repeatedly validated using
  266. MEM/DEBUG and CHKDSK to determine if something is trying to go
  267. resident.
  268.  
  269. At this point, McAfee's SCAN is often used in a different way: the
  270. command "SCAN NUL /M" results in only memory (no files) being checked
  271. for all viruses it knows about. If this fails then file comparisons
  272. are done and the audit trails are checked (all PCs including employees
  273. home machines are authorized to use a site-licensed checksumming
  274. program).
  275.  
  276. Again a layered approach by trained personnel is necessary to protect
  277. against the sort of global disaster mentioned (incidently, during my
  278. training session at the CSI Conference in Denver, I thoroughly
  279. infected the demo PC with the 4096 only to discover that there was no
  280. 5 1/4 boot floppy to use for recovery - Had several 3 1/2s for the
  281. laptop, but no 5 1/4s.  Entertaining.)
  282.  
  283. BTW the McAfee product .DOCs do mention in several places the
  284. advisability of booting from a known clean, write-protected floppy
  285. first.
  286.  
  287. >>A checksummer gives you no
  288. >>security whatsoever, because it does not prevent a viral infection.
  289.  
  290. >True, a checksummer does not prevent infection, but at least it can
  291. >*detect* infections, and that's a lot better than no security at all!!
  292.  
  293. Depends on the checksummer - the one we use performs the checksum
  294. routine on any program presented for execution. If the program is not
  295. known to the audit trail, a screen warns the user that the program is
  296. unknown.  Depending on the setting, the user may or may not be
  297. permitted to execute the program. I suppose that this really comes
  298. under the heading of access control but should be part of any
  299. integrity management solution.
  300.  
  301. >... a program which prevents infections through floppy boots (to
  302. >be mentioned soon)...
  303.  
  304. I believe that VSHIELD protects from hot-boots now - do not believe
  305. that prevention from cold boots can be done without hardware or
  306. special BIOS.  My next project now that DISKSECURE is essentially
  307. complete will be a small addition to warn the user on boot if a floppy
  308. is in the drive - should not be difficult or require much code (trap
  309. cntrl-alt-del, check for floppy, write warning message, loop for
  310. response), several viruses make use of this technique already so it
  311. cannot be too difficult (famous last words).
  312.  
  313.                     Cooly (a/c working again)
  314.  
  315.                             Padgett
  316.  
  317. ------------------------------
  318.  
  319. Date:    Wed, 19 Jun 91 00:50:00 +0000
  320. From:    William Hugh Murray <0003158580@mcimail.com>
  321. Subject: How viruses actually spread
  322.  
  323. >Of course I don't do much with shareware or BBS downloading which is
  324. >where I imagine most of the problems are.
  325.  
  326. Along with many others, you imagine an untruth.  Both PC and Mac
  327. viruses spread by sharing of machines and diskettes.  They might have
  328. been spread by BBSs but they have not been.  They might have been
  329. spread by shareware, but they have not been.
  330.  
  331. Regular readers of this forum are aware of this, but it bears
  332. re-stating, particularly in the face of specualtion to the contrary.
  333.  
  334. The most successful viruses infect boot sectors of diskettes,
  335. partition tables or boot sectors of hard drives, and go resident,
  336. i.e., they are TSRs.  They spread when users permit strange diskettes
  337. to be inserted in their machines, or when they put their diskettes in
  338. machines that they did not themselves boot from a known source.  While
  339. they can and do spread marginally in other ways, this high-risk
  340. behavior accounts for their current success.
  341.  
  342. ------------------------------
  343.  
  344. Date:    Tue, 18 Jun 91 18:23:54 -0700
  345. From:    p1@arkham.wimsey.bc.ca (Rob Slade)
  346. Subject: Review of Victor Charlie (addendum) (PC)
  347.  
  348. For those who want to "try before you buy", Victor Charlie version 3.2 is 
  349. a "freeware" demo version.  The file VC3-2.ZIP should be available on 
  350. BBS's, and is posted on SUZY.
  351.  
  352. =============
  353. Vancouver          p1@arkham.wimsey.bc.ca   | "If you do buy a
  354. Institute for      Robert_Slade@mtsg.sfu.ca |  computer, don't
  355. Research into      (SUZY) INtegrity         |  turn it on."
  356. User               Canada V7K 2G6           | Richards' 2nd Law
  357. Security                                    | of Data Security
  358.  
  359. ------------------------------
  360.  
  361. Date:    Wed, 19 Jun 91 04:14:00 +0000
  362. From:    Ben Zajac <0004193926@mcimail.com>
  363. Subject: Spanish Virus/Telefonica (PC)
  364.  
  365. Recently, a virus was discovered at Oxford University, Oxford
  366. (England) and the City Univerity at London (England).  It has been
  367. named, "Spanish Telecom," and also, "Telefonica."
  368.  
  369. According to information that I have received from the UK, the
  370. virus does not kick in until after the system has been booted up
  371. 400 times.
  372.  
  373. The code reportedly contains the following message:
  374.  
  375.              "Menos tarifes y mas servivios"
  376.  
  377.     Which means: "Lower tariffs, more service"
  378.  
  379. Damage -- When triggered, destroys (overwrites) hard disks.
  380.  
  381. Detection:
  382.  
  383.      The virus is in *.COM files and boot sector.
  384.  
  385.      Pattern:
  386.  
  387.      Header 1 - 881D 8200 83FB 0074 188F 5500 B2; OFFSET 034H
  388.  
  389.      Header 2 - 83ED 09BE 2001 03F5 FC86; OFFSET 024H
  390.  
  391.      Boot Sector -
  392.  
  393.                 8A0E EC00 8E700 0003 F18A 4C02 8A74 03C3;OFFSET 083H
  394.  
  395. I have not personally examined this virus, however the I have no
  396. reason to doubt the source.
  397.  
  398.            Bernard P. Zajac, Jr.
  399.            MCI MAIL - 4193926@MCIMAIL.COM
  400.  
  401. ------------------------------
  402.  
  403. Date:    19 Jun 91 08:26:44 +0000
  404. From:    frisk@rhi.hi.is (Fridrik Skulason)
  405. Subject: Re: Scanning infected files (PC)
  406.  
  407. >Good question, but: wouldn't it be possible for the stealthy virus to
  408. >trap the sector I/O and "fix" it to also hide its tracks?
  409.  
  410. Not only possible - it has already been done.  At least one virus,
  411. simply known as INT13 does just this.
  412.  
  413. - -frisk
  414.  
  415. ------------------------------
  416.  
  417. Date:    19 Jun 91 08:30:32 +0000
  418. From:    frisk@rhi.hi.is (Fridrik Skulason)
  419. Subject: Re: joshi & vsum & f-prot & ll format (PC)
  420.  
  421. treeves@magnus.acs.ohio-state.edu (Terry N Reeves) writes:
  422. >    f-prot must be intended to work - "cured" - so can the author
  423. >speak to this?
  424.  
  425. As far as I knew, F-DISINF should have been able to remove the Joshi virus.
  426. I'll look into this right away and check what the problem is.
  427.  
  428. - -frisk
  429.  
  430. ------------------------------
  431.  
  432. Date:    19 Jun 91 08:22:54 +0000
  433. From:    frisk@rhi.hi.is (Fridrik Skulason)
  434. Subject: Re: virus detection by scanners ? (PC)
  435.  
  436. hermann@uran.informatik.uni-bonn.de (Hermann Stamm) writes:
  437. >  - what other scanner should I try for these versions ?
  438.  
  439. It does not matter - you will get practically the same results.  My
  440. scanner may detect some of those SCAN missed or vice versa, but that
  441. is not important.
  442.  
  443. What is important is that you cannot expect a scanner to detect a
  444. modified virus. It may work, or it may not, but there is absolutely no
  445. guarantee.  A scanner is designed to detect existing viruses, not new
  446. ones or new variants of older viruses, although some scanners may
  447. detect some new variants of some viruses.
  448.  
  449. >  - is it true, that any scanner must try to look at the
  450. >    semantics of such decoders, and not at the shape ?
  451.  
  452. Well, if it looked at something else, it would not be a scanner.... :-)
  453.  
  454. Don't misunderstand me - there are programs which may look at the 1701
  455. virus, or some of your modified variants, and report something like:
  456.  
  457.     This program seems to cotain additional code at the end,
  458.     which starts by performing decryption of itself. This is
  459.     typical of a virus.
  460.  
  461. But, a program like this is not a scanner - it is a generic analysis
  462. tool, unable to identify viruses - it just reports anything
  463. "suspicious".
  464.  
  465. >  - which systems are good by looking at the length of
  466. >    files and reporting differences ?
  467.  
  468. Differences between what ?
  469.  
  470. >  - Is the following behaviour possible for a virus:
  471. >
  472. >    After getting resident, it forces to do a warm-start
  473. >    with ctrl-alt-del, and then it copies itself to all
  474. >    .com-files encountered during rebooting
  475. >    (like command.com, ...).
  476.  
  477. No - it is not possible. 
  478.  
  479. ------------------------------
  480.  
  481. Date:    Tue, 18 Jun 91 23:11:30
  482. From:    microsoft!c-rossgr@uunet.uu.net
  483. Subject: Requirements for Virus Checkers (PC)
  484.  
  485. >From:    Robert McClenon <76476.337@CompuServe.COM>
  486.  
  487. (Sorry for the delay...offline for a while)
  488.  
  489. >Excuse me, but I use Virex-PC, which is Ross's product.  I do
  490. >occasionally need to remove it, not to troubleshoot IT, but because
  491. >something is incompatible with it.  One commercial game requires 540K
  492. >of FREE memory, not counting MOUSE.SYS, which it uses, and can't fit
  493. >if Virex-PC is installed.
  494.  
  495. The next version of the code runs the resident virus checker in 608
  496. bytes, Robert.  I think I can shave about 150 more off of that....
  497.  
  498. >  A third-party fax board program has TSR
  499. >conflicts with Virex-PC.  I don't know what it is doing, but it tries
  500. >to take over the same interrupts as Virex-PC and the results are
  501. >unpredictable.  (Sometimes it refuses to run.  Sometimes it crashes.)
  502.  
  503. Have you called tech support @ Microcom (919-490-1277) and told them
  504. about it?  We might have a fix someplace around, or can attempt to
  505. figure out what's wrong and fix it in the next release.
  506.  
  507. EVERYBODY: Never accept a problem with a piece of code: the vendor
  508. can't fix it if they don't know there is a problem.
  509.  
  510. Ross
  511.  
  512. ------------------------------
  513.  
  514. Date:    Wed, 19 Jun 91 16:30:21 +0000
  515. From:    kforward@kean.ucs.mun.ca (Ken Forward)
  516. Subject: Re: Interesting interaction ( VIRx & SCAN ) (PC)
  517.  
  518. p1@arkham.wimsey.bc.ca (Rob Slade) writes:
  519. > Noted an interesting interaction between two antivirals the other day,
  520. > and finally tracked it down.  If VIRx 1.4 is run before SCAN 77, SCAN
  521. > will "detect" the presence of the 3445 and Doom 2 viri in memory and
  522. > refuse to run.
  523.  
  524. Tried this out for myself; no 3445 or Doom 2, but Taiwan3 [T3] was
  525. "found" in memory.  Has anyone experienced any other false positives
  526. with this combination ?
  527.  
  528. Cheers,
  529. - ---------------------------------------------------------------------------
  530.      Kenneth Forward             |    "...don't plant your bad days,
  531.      MUN Dept of Physics         |        they grow into weeks..."
  532.      kforward@kean.ucs.mun.ca    |                    -Tom Waits- 
  533. - ---------------------------------------------------------------------------
  534.  
  535. ------------------------------
  536.  
  537. End of VIRUS-L Digest [Volume 4 Issue 106]
  538. ******************************************
  539.