home *** CD-ROM | disk | FTP | other *** search
/ Hacker 2 / HACKER2.mdf / virus / virusl2 / virusl2.240 < prev    next >
Text File  |  1995-01-03  |  22KB  |  559 lines
  1. VIRUS-L Digest   Thursday, 16 Nov 1989    Volume 2 : Issue 240
  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: Sophisticated viruses
  17. Ohio vs. Den Zuk (PC)
  18. VACSINA infects more than EXE and COM files (PC)
  19. Re: Pull plug before cleaning
  20. Macintosh Virus List
  21. Need software to detect PC virus (PC)
  22. Another Virus? (PC)
  23. Undecidability of virus detection
  24. Virus removal programs for use on MAC 128K
  25. Another virus... Marijuana virus (PC)
  26. Virus eliminators above reproach.
  27. Sunday virus (PC)
  28. Lisbon virus (PC)
  29. Ralf Burger's book
  30.  
  31. ---------------------------------------------------------------------------
  32.  
  33. Date:    Mon, 13 Nov 89 12:12:46 +0000
  34. From:    frisk@rhi.hi.is (Fridrik Skulason)
  35. Subject: Re: Sophisticated viruses
  36.  
  37. jim frost writes:
  38. > Fridrik Skulason writes:
  39. > >jim frost writes:
  40. > >>Given the limited resources of PC environments, it's
  41. > >>unlikely that you'll get a very sophisticated virus.
  42. >
  43. > >I must disagree.
  44. >
  45. > No, it's harder.
  46.  
  47. The disagreement results from our different understanding of the words
  48. "very sophisticated virus." I understood them in a relative sense,
  49. meaning that a "very sophisticated virus" in the PC environment does
  50. not have to be nearly as complicated or large as a "very sophisticated
  51. virus" in the UNIX environment, and therefore much easier to write.
  52. So, we really do not disagree regarding the fact that
  53.  
  54. > MS-DOS systems are so trivial that it's difficult to build a good virus
  55. > detector and there are no inherent security systems.  Viruses don't need to
  56. > be sophisticated.
  57.  
  58. > >"Bypass protection programs and jump directly to the hardware, DOS or
  59. > >BIOS routines."
  60. >
  61. > I didn't add that because that's not usually one of the "survival"
  62. > traits, but rather is used in propagation and/or infection.
  63.  
  64. No, because a part of the "survival" is to avoid detection. Many
  65. protection program simply hook interrupts, and any virus that bypasses
  66. the interrupt table has a good chance of avoiding them altogether.
  67.  
  68. - -frisk
  69.  
  70. ------------------------------
  71.  
  72. Date:    Mon, 13 Nov 89 11:54:52 +0000
  73. From:    frisk@rhi.hi.is (Fridrik Skulason)
  74. Subject: Ohio vs. Den Zuk (PC)
  75.  
  76. It is obvious that the "Den Zuk" and "Ohio" viruses are somehow related,
  77. but the nature of their relationship has not been determined yet. "Ohio"
  78. was reported later, but there is a possibility that it is older than
  79. "Den Zuk".
  80.  
  81. I said in an earlier note that a diskette infected with Ohio would be
  82. immune to infections by Brain and Den Zuk. This is not entirely
  83. correct. The diskette will be immune to infections by Brain, but when
  84. Den Zuk finds a "Ohio"-infected diskette, it will remove the virus and
  85. put a copy of itself there instead.
  86.  
  87. As I have mentioned before, the "Ohio" virus contains the signature of
  88. the "Den Zuk", but it also contains some interesting text strings:
  89.  
  90.                       V  I  R  U  S
  91.                            b y
  92.                        The Hackers
  93.                        Y C 1 E R P
  94.                       D E N Z U K O
  95.                       Bandung 40254
  96.                         Indonesia
  97.  
  98.                 (C) 1988, The Hackers Team....
  99.  
  100. Remember that Den Zuk puts the volume label Y.C.1.E.R.P on
  101. Brain-infected diskettes, when it removes the infection.
  102.  
  103. (And yes, by the way, both viruses only infect diskettes, not hard
  104. disks).
  105.  
  106. The "Den Zuk" virus contains the following text strings:
  107.  
  108.                         Welcome to the
  109.                            C l u b
  110.                         --The HackerS--
  111.                             Hackin'
  112.                          All The Time
  113.  
  114.                          The HackerS
  115.  
  116. On a more technical level, the viruses are very close. Both store the main
  117. part of the virus on track 40, starting at sector 33. (Remember that normal
  118. 360K diskettes have only tracks numbered 0..39 and sectors 1..9) They also
  119. hook INT 9, take action when Ctrl-Alt-Del is pressed and in both cases
  120. a true reboot can be produced by pressing Ctrl-Alt-F5.
  121.  
  122. And of course - the "Ohio" virus has the same "bug" as "Den Zuk" - it can
  123. not infect other types of diskettes than 360K properly.
  124.  
  125. A part of the "Den Zuk" virus may explain the relationship. The following
  126. code fragment is used to determine if a diskette should be infected or not.
  127.  
  128.     CMP    [SIGN1],537CH        ; Is current diskette infected
  129.                     ; with this version of Den Zuk ?
  130.     JE    BP0300            ; Yes, do not infect.
  131.     CMP    [SIGN2],0FAFAH        ; No, but is it infected with
  132.                     ; (probably) an older version ?
  133.     JE    BP0280            ; Yes, update the virus.
  134.     CMP    [SIGN3],1234H        ; No, but is it infected with Brain ?
  135.     JNE    BP0290            ; Yes, remove it.
  136.                     ; No, just infect.
  137.  
  138. "Ohio" contains the signature FAFA in the specified location.
  139.  
  140. My theory is that the "Ohio" virus is the missing "older version" of
  141. "Den Zuk", that it was written by the same authors as "Den Zuk", but
  142. earlier. The authors of Ohio released it to fight the Brain virus, but
  143. since it contained a number of bugs, the "Den Zuk" virus was later
  144. released to track it down.
  145.  
  146. One final question. I understand that a variant of Dutch is spoken in
  147. some parts of Indonesia - do the words "Den Zuk" mean anything over
  148. there ?
  149.  
  150. - -frisk
  151.  
  152. ------------------------------
  153.  
  154. Date:    Mon, 13 Nov 89 13:41:09 -0500
  155. From:    Christoph Fischer <RY15%DKAUNI11.BITNET@IBM1.CC.Lehigh.Edu>
  156. Subject: VACSINA infects more than EXE and COM files (PC)
  157.  
  158. Hi,
  159. VACSINA infects any file that is loaded and executed via the INT 21H(4BH)
  160. function. So additionally to COM and EXE files other files like OVL or
  161. APP are infected as long as they start with E9H (jump) or 'MZ' (EXE header).
  162. We have written a program that detects VACSINA and removes it from those
  163. files. Also we have an immuniser that prevents VACSINA from installing its
  164. memory resident copy.
  165.  
  166. Christoph and Torsten
  167.  
  168. *****************************************************************
  169. * Torsten Boerstler and Christoph Fischer and Rainer Stober     *
  170. * Micro-BIT Virus Team / University of Karlsruhe / West-Germany *
  171. * D-7500 Karlsruhe 1, Zirkel 2, Tel.: (0)721-608-4041 or 2067   *
  172. * E-Mail: RY15 at DKAUNI11.BITNET or RY12 at DKAUNI11.BITNET    *
  173. *****************************************************************
  174.  
  175. ------------------------------
  176.  
  177. Date:    13 Nov 89 00:00:00 +0000
  178. From:    "David.M..Chess" <CHESS@YKTVMV.BITNET>
  179. Subject: Re: future viruses on a PC; Pull plug before cleaning
  180.  
  181. > Sorry again turning off power will stop the current execution of the
  182. > virus...  but... unless you are perfect in your safe computing habits
  183. > and your tools are up to snuff and you give your harddisk an
  184. > engineering prep as you power up and ALL your software is clean.. you
  185. > can still be hit upon power up...
  186.  
  187. The usual idea is that you boot from a known-safe *diskette* when
  188. you want to get the system into a clean state for checking.  With
  189. enough effort, it's possible to get a diskette whose possibility
  190. of being infected is as small as you like; if you boot from that,
  191. you can check your hard disk without having to assume that it's
  192. clean already (when a machine boots from a properly-prepared
  193. diskette, as you know, no code from the hard disk is executed).
  194. That was, I think, what was being suggested in the item
  195. you're replying to...              DC
  196.  
  197. ------------------------------
  198.  
  199. Date:    Mon, 13 Nov 89 11:35:30 -0500
  200. From:    "Gregory E. Gilbert" <C0195%UNIVSCVM.BITNET@VMA.CC.CMU.EDU>
  201. Subject: Macintosh Virus List
  202.  
  203. After much scrutinization I ahave ammended the earlier Macintosh virus list
  204. and came up with the following.  Hope this helps.
  205.  
  206. Macintosh Viruses
  207. - -----------------
  208.  
  209. There are about six Macintosh viruses known at present (a list
  210. of viruses and the years in which they first appeared can be seen
  211. in the following table).
  212. - -----------------------------------------------------------------
  213. Virus                         Strains       Clones
  214. - ------                        --------      --------
  215. MacMag(December 1987)**
  216. Dukakis(Early 1988?)****
  217. nVir(Early 1988)
  218.                               nVir A(?)
  219.                               nVir B(?)
  220.                                             Hpat(Late 1988)
  221.                                             AIDS(Late 1988)
  222.                                             MEV#(March 1989)
  223.                                             nFLU(August 1989)
  224. Scores(Spring 1988)***
  225. INIT 29(Late 1988)*
  226. ANTI(Early 1989)
  227. - -----------------------------------------------------------------
  228.    * - also known as the Drew Virus, Brandow Virus, and the
  229.        Peace Virus
  230.   ** - also known as the NASA virus
  231.  *** - also known as the San Jose Flu
  232. **** - can only infect HYPERCARD Stacks!
  233.  
  234. Gregory E. Gilbert
  235. Computer Services Division
  236. University of South Carolina
  237. Columbia, South Carolina   USA   29208
  238. (803) 777-6015
  239. Acknowledge-To: <C0195@UNIVSCVM>
  240.  
  241. ------------------------------
  242.  
  243. Date:    Mon, 13 Nov 89 18:11:00 -0500
  244. From:    DOUG%HUGIN%NORWICH.BITNET@VMA.CC.CMU.EDU
  245. Subject: Need software to detect PC virus (PC)
  246.  
  247. I need to find software to detect and purge viruses from DOS-PC
  248. software.  I have seen vaccine software in magazines and catalogs
  249. but no description of how it functions (whether it automatically
  250. destroys the virus and the software attached, or if it can be a
  251. bit selective).  Can any one elaborate a bit on the value of the
  252. following vaccines or suggest software with which they are familiar.
  253.  
  254. Compugard Anti-Virus
  255. Flu-Shot+
  256. Flushot(1225)
  257. Mace Vaccine
  258. Virus Killer
  259.  
  260. Any Discussion would be helpful.  Send replies to:
  261.  
  262. DOUG@NORWICH.BITNET
  263. Doug Johnson
  264. Computer Users Services
  265. Norwich University
  266. Northfield, VT 05663
  267.  
  268. ------------------------------
  269.  
  270. Date:    Mon, 13 Nov 89 18:45:00 -0500
  271. From:    IA96000 <IA96%PACE.BITNET@VMA.CC.CMU.EDU>
  272. Subject: Another Virus? (PC)
  273.  
  274. Over the weekend a file named EAGLE.EXE was uploaded to my BBS.
  275. My system run extensive tests on ALL new files before they are
  276. released for general use and downloading. I checked the log and
  277. NO reports of anything you may consider improper were found after
  278. checking the uploads.
  279.  
  280. EAGLE.EXE is said to produce a VGA animation of an EAGLE flying
  281. in the sky. For those interested in VGA animations it would appear
  282. to be of interest.
  283.  
  284. I ran EAGLE.EXE and all that happened is the program produced the
  285. following line on the screen:
  286.  
  287. Kiss an Eagle Today!
  288.  
  289. Being of suspicious nature, I immediately started to check the file
  290. using SCANV48 and other utilities. No indication of a virus was
  291. detected or reported.
  292.  
  293. HOWEVER,running certain files after running EAGLE.EXE caused them to
  294. grow in size. Okay, cold booted and ran SCAN and other utilities again.
  295. Same result, no report of infection. But as soon as you run EAGLE.EXE
  296. again, files start to get larger.
  297.  
  298. There has been NO apparent FAT TABLE damage, and no files have
  299. suddenly disappeared. Other than files growing in size, there appears
  300. to be nothing else happening yet!
  301.  
  302. The file EAGLE.EXE probably has been or will be uploaded to Homebase
  303. by the time you read this message. If not, it will transfered tonight
  304. as soon as we can get through.
  305.  
  306. NOTE:    SOURCER  reveals code similar to other viruses in existance,
  307. but I will defer to experts and let them decide what exactly is
  308. contained in the EAGLE.EXE file. In all likelihood this IS NOT a
  309. new virus, just a modification on an old one, however again I will
  310. defer to the experts!
  311.  
  312. SUSPECT FILE NAME: EAGLE.EXE
  313.      DESCRIPTION : Supposedly a VGA animation of an EAGLE.
  314.  
  315.  
  316. DISCLAIMER:
  317.  
  318.     This virus (or whatever you want to call it) HAS NOT affected
  319. any computers or files at this University. It was discovered on a BBS
  320. run by a student who attends this University.
  321.  
  322. ------------------------------
  323.  
  324. Date:    Sat, 11 Nov 89 12:25:00 -0500
  325. From:    crocker@TIS.COM
  326. Subject: Undecidability of virus detection
  327.  
  328. In VIRUS-L Digest   Thursday,  9 Nov 1989    Volume 2 : Issue 237,
  329. Peter Day writes
  330.  
  331.     `A note to the virus-l digest of 6-Nov-89 said that "the virus
  332.     problem (at least detection anyway) is undecidable."  Does
  333.     anyone know if there are any papers where this result is
  334.     proved? Or where the problem is shown to not be NP complete?
  335.     Or even where the problem is stated precisely?'
  336.  
  337. There are two parts to this question.  First, precisely what is a
  338. virus and second, how hard is it computationally to determine whether
  339. a candidate program contains a virus.  Precise specification of
  340. viruses is an open-ended discussion, but almost any reasonable
  341. definition will lead to the same conclusion.  For the sake of this
  342. discussion, let's agree that a virus modifies something it shouldn't.
  343. (A program which makes undesired modifications does not necessarily
  344. contain a virus, but all viruses make undesired modifications.)
  345.  
  346. Determining whether a program makes undesired modifications is
  347. equivalent to determining whether it ever computes a particular
  348. result, which is equivalent to the halting problem.  Hence
  349. determination of the presence of a virus is undecidable.  This is not
  350. a formal proof, of course, but a student in a first course in formal
  351. systems ought to be able to supply the necessary framework and details.
  352.  
  353.  
  354. Undecidability is unfortunate, but not the end of the world.
  355. Approximate virus detectors are entirely feasible.  The undecidability
  356. result simply guarantees that any detector must err sometimes.  It may
  357. err by failing to find some viruses, or it may err by falsely finding
  358. viruses where they aren't.  (Or it can hang up in a loop and never
  359. terminate.)  Most virus-finding programs in use today err on the side
  360. of missing some viruses.  Maria Pozzo and I are conducting research
  361. along the alternate line.  (See our paper in the 1989 IEEE Symposium
  362. on Security and Privacy, Oakland, CA, if you want further details.)
  363.  
  364. Steve Crocker
  365.  
  366. ------------------------------
  367.  
  368. Date:    14 Nov 89 07:03:23 +0000
  369. From:    kulp@cs.nps.navy.mil (jeff kulp x2174)
  370. Subject: Virus removal programs for use on MAC 128K
  371.  
  372.  
  373.    I have a friend with a MAC 128K that got a bad case of nVIR A
  374. from another MAC.  His MAC is running system 4.1 and has a 20MEG harddisk.
  375. Are there any Virus removal programs that will run on this machine.  The
  376. programs that I have found (Disinfectant, VirusRx, Interferon, etc) all
  377. require at least 220K of RAM.  Any help would be appreciated.
  378.  
  379.  
  380.  
  381. ------------------------------
  382.  
  383. Date: 14 Nov 89 17:07:04 GMT
  384. From: Bill.Weston@f12.n376.z1.FIDONET.ORG (Bill Weston)
  385. Subject: Another virus... Marijuana virus (PC)
  386.  
  387.  A program called XTREE.EXE is suspect in spreading a very annoying
  388. virus.  A friend used this program and was consequently infected.  The
  389. first time he ran the program the computer simply locked up.  He then
  390. re-booted and got the following message - YOUR PC IS STONED !
  391. LEGALIZE MARIJUANA!
  392.  
  393.  I have not been able to examine the infected disks personally so the
  394. information that I have is just what I have been told.  The Virus
  395. causes many READ/WRITE errors and does spread to floppies.  It has
  396. apparently infected COMMAND.COM and the BOOT area of the disk,
  397.  
  398.  The real nasty part is that the chap who has been hit is pretty new
  399. to MS-DOS machines.  In fact he barely has the system set up at all.
  400.  
  401.  If anyone has had experience with this VIRUS I would thank you for any
  402. advise.
  403.  
  404. Bill Weston == ...!usceast!uscacm!12!Bill.Weston
  405.  
  406. ------------------------------
  407.  
  408. Date:    Tue, 14 Nov 89 15:06:28 -0600
  409. From:    MITCH COTTRELL <C2852@UMRVMB.UMR.EDU>
  410. Subject: Virus eliminators above reproach.
  411.  
  412. I AGREE....  All virus elimination programs MUST be seen and BE above
  413. reproach this includes software from public sources.  I have already
  414. see a "elimination" program for Juruselem that says all is fine, But
  415. the scan program still says t hat it is infected.  Which is right.
  416. Both came from the same source.  (McAffee Associates)
  417.  
  418. I am not perfect in my software, But two programs that test for the
  419. same thing would be assumed to give the same result.  If they don't,
  420. one is not working ri ght.  Can you afford to gamble and GUESS which
  421. one is wrong??? It may cost more than you think........
  422. Acknowledge-To: <C2852@UMRVMB>
  423.  
  424. ------------------------------
  425.  
  426. Date:    Tue, 14 Nov 89 22:44:50 +0000
  427. From:    frisk@rhi.hi.is (Fridrik Skulason)
  428. Subject: Sunday virus (PC)
  429.  
  430. The "Sunday" virus reported here recently seems to be little more than a
  431. variant of the Israeli/Jerusalem virus.
  432.  
  433. There are some differences - the length of Israeli/Jerusalem is 1808 bytes,
  434. but "Sunday" is only 1631 bytes long. Jerusalem defines INT 21 subfunction
  435. E0 to check if it is installed, but Sunday uses subfunction FF.
  436.  
  437. It is, however, so similar to the original virus, that the only modification
  438. I had to make to my virus removal program to cover "Sunday" was to change
  439. one line in the "remove_israeli_or_fu_manchu" procedure:
  440.  
  441.         if (virlen == 1808)
  442. to
  443.         if (virlen == 1808 || virlen == 1631)
  444.  
  445. No other changes needed, not even new signature strings.
  446.  
  447. This means that we only have 39 different viruses to worry about, not 40. :-)
  448.  
  449. Anyhow - it is always getting harder and harder to determine what is a new
  450. virus and what is just a variant. Viruses Like "Ghost" and "Mix1" that
  451. combine parts of two viruses are not making that job easier...!
  452.  
  453. - -frisk
  454.  
  455. ------------------------------
  456.  
  457. Date:    Tue, 14 Nov 89 23:55:44 +0000
  458. From:    frisk@rhi.hi.is (Fridrik Skulason)
  459. Subject: Lisbon virus (PC)
  460.  
  461. The "Lisbon" virus reported recently is nothing but a variant of the
  462. Vienna virus. The major difference is that the virus seems to have been
  463. created from the disassembly in Ralf Burger's book "Computer Viruses..."
  464. and assembled using a different assembler than the one used to create the
  465. original virus.
  466.  
  467. The "Lisbon" virus contains the patches added in the book to make the
  468. virus a little less harmful than the original, just like the "Ghost"
  469. virus I reported recently.
  470.  
  471. The reason I say that the virus has been created using a different assembler
  472. is that in many cases different forms of the same instructions are used.
  473. It is a rather little known fact that many x86 instructions have two
  474. different forms, in particular the XOR instructions. For example, the
  475. "XOR AX,AX" instruction can both be represented as
  476.  
  477.         31 C0   or   33 C0
  478.  
  479. The Microsoft assembler will generate one of the forms, but DEBUG the
  480. other one. I don't know about TASM and other assemblers, I use MASM
  481. and DEBUG for everything :-)
  482.  
  483. Since Lisbon contains the form not used by the original virus, it was
  484. obviously not created by patching of Vienna. Still, this small difference
  485. was enough to confuse both the scanning programs from IBM and McAfee,
  486. but not my own....... :-)
  487.  
  488. There are a few differences in the code, but they are trivial.
  489.  
  490. - -frisk
  491.  
  492. ------------------------------
  493.  
  494. Date:    Wed, 15 Nov 89 01:02:11 +0000
  495. From:    frisk@rhi.hi.is (Fridrik Skulason)
  496. Subject: Ralf Burger's book
  497.  
  498. I spent a part of last evening reading the book "Computer Viruses, a
  499. high-tech disease".  This book has been mentioned here several times
  500. before, in most cases because it contains a (slightly crippled)
  501. disassembly of the Vienna virus.
  502.  
  503. This disassembly, and other that have been (and will be) made
  504. generally available will become a major source of problems in the
  505. future. The reason is quite simple. It takes a GOOD assembly language
  506. programmer at least a couple of days to write and debug an original
  507. virus. Given a disassembly to start from, he can complete the job in a
  508. few hours instead. A novice may spend a bit longer time creating a new
  509. virus built on a disassembly, but it will be MUCH harder for him to
  510. write a new virus from scratch. It takes no genius to write a virus,
  511. only an experienced assembly language programmer, but since the
  512. novices outnumber the experienced ones, the availability of a virus
  513. disassembly will result in a far greater number of people being able
  514. to write viruses with less effort.
  515.  
  516. My opinion of the book is very simple.
  517.  
  518. I can not recommend it. This is not due to the fact that it contains
  519. listings of "real" viruses, but rather that the information in the
  520. book is inaccurate and out of date.
  521.  
  522. Consider for example the different virus types described. They are:
  523.  
  524.         Overwriting viruses.
  525.     Non-overwriting viruses.
  526.     Memory-resident viruses.
  527.     Calling viruses.
  528.     Hardware viruses.
  529.     Buffered viruses.
  530.     "Live and Die" viruses.
  531.     "Hide and Seek" viruses.
  532.  
  533. Boot sector viruses are not mentioned in this list, or anywhere else
  534. in the book. This is of course because they only appeared in 1988, but
  535. the book was written in 1987. Some of the virus types mentioned are
  536. unknown and VERY unlikely to appear at all.
  537.  
  538. Some time is spent on the subject of "Randomly occurring viruses"...
  539.  
  540.     "who can say that his software cannot be turned into a virus by
  541.      changing a single bit ?".
  542.  
  543. ... and that sort of stuff.
  544.  
  545. Still, this book is l lot better than the two other books I saw here
  546. at the university bookstore. I guess we will never get a "good" book
  547. on viruses, since they will probably have become obsolete by the time
  548. they appear.
  549.  
  550. But who needs a book when we have VIRUS-L and comp/virus ?  :-)
  551.  
  552. - -frisk
  553.  
  554. ------------------------------
  555.  
  556. End of VIRUS-L Digest
  557. *********************
  558. Downloaded From P-80 International Information Systems 304-744-2253
  559.