VIRUS-L Digest Monday, 12 Feb 1990 Volume 3 : Issue 38 Today's Topics: copyrighted virus code? Virus-laden Census Disks The Aids Virus Author Caught (PC) Re: Disinfectant 1.6 (Mac) Re: WDEF A (Mac) Re: Universal virus detector RE: Copyrights on virus code Re: Viruses 4096 and 1260 on BBS (PC) Re: Idea for WDEF Innoculation (Mac) Re: JERUSALEM B again (PC) The AIDS "Trojan" is a Copy Protection System Re: WDEF in Toronto (MAC) Re: Idea for WDEF Innoculation (Mac) Twelve Tricks Trojan (PC) WDEF at Wollongong VIRUS-L is a moderated, digested mail forum for discussing computer virus issues; comp.virus is a non-digested Usenet counterpart. Discussions are not limited to any one hardware/software platform - diversity is welcomed. Contributions should be relevant, concise, polite, etc., and sent to VIRUS-L@IBM1.CC.LEHIGH.EDU (that's LEHIIBM1.BITNET for BITNET folks). Information on accessing anti-virus, document, and back-issue archives is distributed periodically on the list. Administrative mail (comments, suggestions, and so forth) should be sent to me at: krvw@SEI.CMU.EDU. - Ken van Wyk --------------------------------------------------------------------------- Date: Sat, 10 Feb 00 19:90:31 +0000 From: greg@agora.hf.intel.com (Greg Broiles) Subject: copyrighted virus code? In VIRUS-L V3-36, Olivier Crepin-Leblond writes: > In VIRUS-L V3-34 Steven C Woronick writes: > > >Even if you could copyright viral code, it's > >not likely to discourage the kind of people who write viruses (aren't > >those the ones you are really after?) from copying it. Also, what > >happens if some virus-loving person copyrights it before you do and > >then grants universal privilege to copy? Just wondering... [text deleted] > I can hardly imagine some individual copyrighting virus source code. > Anyone doing that will probably be in for a lot of trouble... Well, if it's written in the United States, it's copyrighted automatically as soon as it's written to disk. Anything "recorded in a fixed medium of expression" is automatically copyrighted, with the rights going to the author, unless she gives them up voluntarily. No registration is necessary (unlike patents), though it's helpful in the case of a disputed claim of ownership. Work done for an empoyer belongs to the employer, not the employee. I'm not a lawyer (I may end up as one someday) and I can't immediately put my hands on a copy of the results of research I did on copyrights a few years ago. The above is correct, but might be incomplete. At any rate, I'm certain that, if Sam Sociopath locks himself up in a Las Vegas hotel room and writes a virus, the copyright belongs to him. (Unless he makes it public domain, transfers the rights, or is being paid by another to write the virus.) The United States has behaved strangely in the past in terms of agreeing to and adherence to international treaties about copyrights. Things may very well be different for viruses developed elsewhere, though I doubt they could be copyrighted here. ------------------------------ Date: Fri, 09 Feb 00 19:90:03 +0000 From: email!lgdelta!mshamel@tachost.af.mil (SMSgt Michael L. Shamel) Subject: Virus-laden Census Disks The following article is from the February 5, 1990 addition of COMPUTERWORLD. I though the group might be interested. U.S. RECALLS VIRUS-LADEN CENSUS DISKS. The Government Printing Office narrowly averted triggering a nationwide computer virus epidemic late last month after picking up an infection from the U.S. Census Bureau. On Jan. 25, the GPO was in the process of mailing packages containing two floppy disks and a compact disc/read-only memory disc holding census data to 772 depository libraries scattered across the country when it learned from the Census Bureau that one of the two disks had been infected by the Jerusalem virus, said Jan Erickson, manager of information technologies at the GPO. The floppy disks contained programs that enabled users to retrieve data from a CD-ROM disc published by the Census Bureau containing the County and City Data Book. The Jerusalem Virus, also known as the Israeli, Hebrew University and Friday the 13th virus attacks both .COM and .EXE files on personal computers running under MS-DOS, according to John McAfee, president of the Computer Virus Industry Association in Santa Clara, Calif. The virus repeatedly infects executable files, increasing them about 1.8K bytes, until the computer's memory is clogged, McAfee said. In addition to slowing an infected systems, some versions can destroy data, although that does not appear to have happened this instance. "The GPO's [distribution] system allows libraries to choose the material that they want, and of the 1,400 libraries, 772 chose this disk," Erickson said. "We caught most of the disks before they went out." The few libraries that received the disks have not reported an problems with data being destroyed, she added. The virus was initially discovered on four stand-alone computers in the Suitland, Md., office of the Data Users Service Division of the Census Bureau on Jan. 22 and was eradicated within 24 hours, said Jim Gorman, a Census Bureau spokesman. It is still unclear how the four computers were infected, he said. Two days later, on Jan. 25, the bureau discovered that disks slated to be distributed by the GPO had been infected with the same virus, Gorman said. The disks, however, were not produced by the Census Bureau but by an outside disk duplication service, Gorman said. Furthermore, it is not known if the virus was transmitted by the Census Bureau to its disk supplier. Gorman said that he did not know the name of the disk duplicator or what action, if any, the Bureau intended to take against the firm. In an alert sent out to its depository librarians, the GPO said that it and the Census Bureau planned to take "appropriate measures ... to ensure that it does not happen again." Gorman said that he did not know what those measures would be. The virus had no impact on the Census Bureau's preparations for the 1990 census, Gorman said. The computer Virus Industry Association has put out an alert about the virus to its members, warning them that the disk should be destroyed immediately, McAfee said. The virus is easily transmitted and can destroy programs, he warned. ------------------------------ Date: Sat, 10 Feb 00 19:90:34 +0000 From: email!lgdelta!mshamel@tachost.af.mil (SMSgt Michael L. Shamel) Subject: The Aids Virus Author Caught (PC) The following article is from the February 5, 1990 addition of COMPUTERWORLD. The FBI apparently caught the guy who spread the Aids Virus Disk in England. Although this is more of a Trojan Horse than a Virus story, I thought the group might be interested. SUSPECT ARRESTED IN AIDS DISK FRAUD CASE Acting on a warrant issued by a London magistrate, agents of the Federal Bureau of Investigation arrested Dr. Joseph Lewis Popp last Thursday for his alleged role in a scheme to bilk computer users who used a program that he created. Popp, an U.S. citizen, is alleged to be the author of an "AIDS Information Introductory Diskette" that was mailed unsolicited to thousands of MS-DOS computer users in Europe, Africa and Australia last December. Concealed within the program, which was designed to evaluate a person's likelihood of contraction the Acquired Immune Deficiency Syndrome (AIDS) virus, was a Trojan horse that moved some files stored on hard disks into hidden directories and encrypted others. "The effect for the nontechnical user is devastating because it appears as though everything is gone," said Jim Bates, a computer consultant in Leicester, England, who has dissected the program. A license agreement packaged with the AIDS disk warned users that the program would adversely affect programs on their personal computer's hard disk drives unless they agreed to lease the program with 365 uses for $189, or for the "lifetime of your hard disk" for $398. Users were directed to send a check to an address in Panama City, Panama. It has been estimated that between 23,000 and 27,000 disks were mailed to unsuspecting users, according to Bates. There have been no reports of the programs's arrival in the U.S. English law enforcement authorities issued a warrant for Popp's arrest on Jan. 15 for allegedly violating a 1968 blackmail and extortion statute, said assistant U.S. Attorney Gary Arbeznik in Cleveland. Popp, 39, is being held without bail following a bond hearing last Friday. It is not known whether he will fight extradition (hearings are expected to be concluded within the next 60 days). Popp, who has a PH.D. in anthropology, is believed to have once worked for the World Health Organization (WHO), whose members were among those who received the AIDS disk. A WHO spokesman in Washington, D.C. said that Popp is not currently employed by the organization. ------------------------------ Date: Sat, 10 Feb 90 13:41:16 -0800 From: dplatt@coherent.com Subject: Re: Disinfectant 1.6 (Mac) > I have recently read something about Disinfectant 1.6 from this > newsgroup. Its author said that there was no Disinfectant 1.6 and it > maigt cause potential porblems on virus detection. Someone in our lab > downloaded it and has been using it without any obvious trouble. I > would appreciate any further comments on this application. So, again, > is there any upgraded version of Disinfectant after version 1.5 ? If > not, is there any more information about this "fake" Disinfectant ? A month or so ago, there was a report of a Disinfectant 1.6 at a time when the latest officially-released version of Disinfectant was 1.5. It turns out that this report was in error... a fileserver somewhere had a copy of 1.5, and had mistakenly catalogged it as being version 1.6. More recently (about 10 days ago), John Norstad released an official 1.6 version of Disinfectant. This version includes nVIR-clone detection... it will identify and remove simple clones of the nVIR virus family even if these clones are newly-created and have not been seen before. Check the version history in the About... box in the copy of Disinfectant 1.6 which you have downloaded. If it's consistent with this description, you probably have a valid copy of the new version, and can use it without difficulty or dismay. - -- Dave Platt VOICE: (415) 493-8805 UUCP: ...!{ames,apple,uunet}!coherent!dplatt DOMAIN: dplatt@coherent.com INTERNET: coherent!dplatt@ames.arpa, ...@uunet.uu.net USNAIL: Coherent Thought Inc. 3350 West Bayshore #205 Palo Alto CA 94303 ------------------------------ Date: Sat, 10 Feb 90 13:47:41 -0800 From: dplatt@coherent.com Subject: Re: WDEF A (Mac) + Today, while I was disinfecting a Macintosh IIx with Disinfectant 1.6 + I got a report saying that the desktop was infected at 3:36 p.m. on + 2/6. + + Now, it just happened that it WAS 3:36 p.m. while I was doing the + disinfecting... + + Since the locked disk was clean, it couldn't have infected the HD, + right? The person involved swears that no other disks had been in his + drives today. The time-of-infection which Disinfectant reports is the "last modification time" for the infected file. This information is often useful when you try to track down a virus which infects applications, since most applications do not modify themselves when they are run... and hence the "last modification time" of the application will often be the time at which the virus infected the program. However, the Desktop file is modified _very_ frequently by the Finder... it may be modified any time you launch a new application, or drag an application from one disk/folder to another, or change any file's Get Info... comments. For this reason, the "last modification time" on the Desktop file is _not_ a reliable indicator of when your system was first infected. BTW, there's no reason (as far as I know) to install Gatekeeper Aid on the locked Disinfectant disk... as long as you keep the disk locked, no virus will be able to infect it. - -- Dave Platt VOICE: (415) 493-8805 UUCP: ...!{ames,apple,uunet}!coherent!dplatt DOMAIN: dplatt@coherent.com INTERNET: coherent!dplatt@ames.arpa, ...@uunet.uu.net USNAIL: Coherent Thought Inc. 3350 West Bayshore #205 Palo Alto CA 94303 ------------------------------ Date: Sat, 10 Feb 90 17:59:43 -0500 From: crocker@TIS.COM Subject: Re: Universal virus detector Robert Eachus explained quite lucidly why there is no possibility of building a universal virus checker WHICH PERFECTLY DISTINGUSIHES BETWEEN VIRUSES AND NON-VIRUSES [emphasis mine]. As with most theoretically intractable problems, a slight change in the question leads to remarkably different results. For example, it's entirely feasible to build a virus checker which errs on the safe side and throws out some good programs as well as all bad programs. Whether this is useful depends on how many good programs it throws out. At the extreme, you can postulate it throwing out ALL programs. This is, of course, the easiest filter to build, but also the least useful, i.e. completely useless. A more interesting challenge is whether you can build a checker that permits a usefully large set of good programs to be executed while excluding all bad programs. A related question is whether it's possible to define programming standards whic facilitate the checking process. If such standards existed, the burden of proving that a program is virus-free would fall back on the writer of the program. Programs not meeting the criteria would be treated the same as virus-laden programs and prohibited from execution. Maria Pozzo is working in this area, and she and I published a paper at the IEEE Symposium on Privacy and Security last year. I also posted a description of the basic ideas some time ago. (Perhaps the editor would be kind enough to supply the volume and number?) ------------------------------ Date: Sat, 10 Feb 90 17:12:00 -0800 From: jmolini@nasamail.nasa.gov (JAMES E. MOLINI) Subject: RE: Copyrights on virus code I have recently seen quite a bit of rhetoric about the possibility of copyrighting virus code and thereby reducing the chance that some innocent dolt would play with it and start an epidemic. Although I can easily believe the scenario, I can't accept the recommended deterrent. In particular, Olivier M.J. Crepin-Leblond appears to think that just having the code is inherently dangerous and therefore should be tightly controlled. While I agree that there is not much to be done with virus writers (aside from removing body parts), I cannot believe that legislating virus code will provide any real benefit for the rest of us. Let's examine a similar situation. How many of you reading this bulletin think that you know how to stick up a liquor store? If you don't know how, you will after watching a couple episodes from "Cagney & Lacey" or some other appropriate American Police show. So as long as you know how, what prevents you from trying it the next time you are a little short on cash? If you live in Europe you might say that "It's just not done." We here in the U.S., however, are probably just as afraid that we will end up spending a couple of years in a cell with a bisexual, 300 lb. (136 kg.) dope pusher. This is precisely the reason why Mike Royko (an American humorist) felt that Robert Morris Jr. needed to do some jail time. Prison is not nearly as much a deterrent for the hardened criminal as it is for the college freshman and high school senior. That is why I doubt that we will ever see it illegal to possess virus code here in the U.S. I would rather see us vigorously prosecute the use of these things. Which leads me to my last point. The best way to start fighting this beast is to start reporting people who engage in obviously illegal activity. If you overheard hackers sharing virus code at one of these gatherings, I would advise you to report it to the sponsor of the event and have them thrown out. A conversation overheard at a public event is a perfectly legal tip for the police too. As long as these punks believe that their activities will be tolerated, we will continue to be infected and damaged by these things. Jim Molini ------------------------------ Date: Fri, 09 Feb 90 16:25:05 +0000 From: ddb@ns.network.com (David Dyer-Bennet) Subject: Re: Viruses 4096 and 1260 on BBS (PC) USERGSVE@LNCC.BITNET (GEORGE SVETLICHNY) writes: :What David forgets to mention is that the BBS is the safest source of :virus-free files *as long as the BBS is infected* with these viruses. :Will Sysops now start deliberately infecting their boards with these :viruses so as to assure the users clean files? Is your BBS infected, :Dave? ;-) Not as of last weekend, the last time I ran scanv57. Actually, I've never *seen* a virus, nor have any other local sysops so far as I'm aware (it hasn't been mentioned in the fidonet sysops echo, anyway). Getting serious for half a second, the other problem is that most software on a bbs is in archived form; if the files are infected inside the archive wrapper, the virus won't disinfect itself when reading them even if the bbs *IS* infected. Oh well :-) - -- David Dyer-Bennet, ddb@terrabit.fidonet.org or ddb@network.com or Fidonet 1:282/341.0, (612) 721-8967 9600hst/2400/1200/300 or terrabit!ddb@Lynx.MN.Org, ...{amdahl,hpda}!bungia!viper!terrabit!ddb ------------------------------ Date: Sun, 11 Feb 90 20:35:44 -0500 From: Christopher Tate Subject: Re: Idea for WDEF Innoculation (Mac) jg3o+@andrew.cmu.edu (Jason Ari Goldstein) says: >I don't know much about Macs (Being a PC person) but if I understand >correctly every time the disk is inserted the they Virus is sread to >the disk. Well, why doesn't someone write an innoculation directly >based on the virus itself. Everytime a disk is inserted in the drive >it would be checked for infection if so it would remove WDEF if not it >would then 'innoculate the disk' with itself. Eventually, WDEF would >be wiped out the same way it was spread initially. > >The only problem with this is that it is a virus also, but with the >proper prompts (allowing the user the choice of being innoculated) I >don't think this would be a problem. I know I would mind not ever >being infected by a virus that kills other viruses. > >In the mean time, about 75% of the time I in a cluster I remove WDEF A >or B from either a hard disk or someone elses floppies. The big problem with this is that since the WDEF-removal code is itself a virus, it stands a big chance of causing the same problems as any other virus -- crashes due to poorly written code. There have been no viruses written to date for the Macintosh which deliberately cause damage to the system (*). All of the problems caused by existing viruses are in fact the result of bugs in the viruses, which causes interference with other programs under certain circumstances. Since the above-mentioned inoculation program would be a virus itself, it might well cause problems itself. (*) Mosaic and Font Finder are not viruses (they do not replicate), but are instead "trojan horses" -- destructive code hidden within an innocuous-seeming program. - ------- Christopher Tate | cxt105@psuvm.bitnet | nobody, not even the rain, cxt105@psuvm.psu.edu | has such small hands. ..!psuvax1!psuvm.bitnet!cxt105 | ------------------------------ Date: Sun, 11 Feb 00 19:90:24 +0000 From: mcdphx!hrc!microm!brad@asuvax.eas.asu.edu Subject: Re: JERUSALEM B again (PC) Definitely sound advice! This virus will try to attach itself to any exe,com,app,or ovl file you run once it is in memory ... and as such has the tendency to propagate quite quickly. The latest SCANxx can usually be found quickest on a local DOS based BBS (it is sharware ) and has CLEANUP which will eradicate the virus. There is also alot of interesting documentation that comes with it. The only problem is that this paticular flavor of virus can not always be removed without some damage to the original file ... but a least it can be removed! I would be interested in knowing what the commercial package was ... we have seen a few minor breakouts here in Phoenix lately. I'm just a wanna be UNIX guru (IJWBUG) | Micro Maintenance, Inc. | 2465 W. 12th St. #6 -== Brad Fisher ==- | Tempe, Arizona 85281 ...!asuvax!mcdphx!hrc!microm | 602/894-5526 ------------------------------ Date: Mon, 12 Feb 90 10:45:03 -0500 From: munnari!mqccsunc.mqcc.mq.oz.au!ifarqhar@uunet.UU.NET (Ian Farquhar) Subject: The AIDS "Trojan" is a Copy Protection System For several weeks we have been monitoring the discussion in comp.virus and elsewhere concerning the AIDS "trojan". There has been much discussion about the motives of the author in publishing this virus, and the general surprise that the accompanying program was quite sophisticated. We have recently received a copy of the AIDS trojan with the accompanying license agreement, and upon reading this agreement I am drawn to make several points. Needless to say, this copy was not installed. Let me quote some of the relevant passages from the license agreement: "Read this license agreement carefully. If you do not agree with the terms and conditions stated below, do not use the software, and do not break the seal (if any) on the software diskette..." "...you may not decompile, disassemble, or reverse-engineer these programs or modify them in any way without consent from PC Cyborg Corporation. These programs are provided for your use as described above on a leased basis to you; they are not sold. You may choose one of the following types of lease (a) a lease for 365 user applications or (b) a lease for the lifetime of your hard disk drive or 60 years, whichever is the lesser. PC Cyborg Corporation may include mechanisms in the programs to limit or inhibit copying and to ensure that you abide by the terms of the license agreement and to the terms of the lease duration. There is a mandatory leasing fee for the use of these programs; they are not provided to you free of charge. The prices for "lease a" and "lease b" mentioned above are US$189 and US$378, respectively (subject to change without notice). If you install these programs on a microcomputer (by the install program or any other means), then under the terms of this license you are thereby agree to pay PC Cyborg Corporation in full for the cost of leasing these programs. In the case of breach of this license agreement, PC Cyborg Corporation reserves the right to take any legal action necessary to recover any outstanding debts payable to PC Cyborg Corporation and to use program mechanisms to ensure termination of your use of the program. These program mechanisms will adversely affect other program applications on microcomputers. You are hereby advised of the most serious consequences of your failure to abide by the terms of this license agreement: your conscience may haunt you for the rest of your life; you will owe compensation and possible damages to PC Cyborg Corporation; and your microcomputer will stop functioning normally. Warning: Do not use these programs unless you are prepared to pay for them..." End quote. This is not a trojan: it is a COPY PROTECTION SYSTEM. The consequences of using the program without paying are quite adequately laid out in the license, which apparently has not been read. It warns quite clearly that: a) You should not install this program unless you are going to pay for it. b) The program contains mechanisms that will ensure that the terms of this license agreement will be followed. c) That these mechanisms will affect other programs on the hard disk. I am led to make the following conclusions: 1. That all of the users who were adversely affected by this supposed trojan either (a) did not read the license agreement for the program which they were installing, or (b) they read it and ignored it. Either way, they must accept the consequences. The installation instructions first step tells you to read the agreement on the reverse of the sheet. 2. That the people who have been harping on at length about this trojan did not bother to read the license agreement either. I am left wondering if the "excitement" of this horrible "trojan" prevented them using some elementary logic to ask if the program may be something else. 3. PC Cyborg laid out the consequences quite plainly in the license agreement. It is a debatable point whether PC Cyborg would have sent the "defusing" program for the time bomb that this program installs, though the US invasion would have defeated any attempt to do this (the invasion was doubtless more illegal than this program). 4. That the people hurriedly disassembling the program actually committed a breach of the license agreement, and are liable for legal action from PC Cyborg. Equally, copying of this program is as illegal and is as much piracy as copying any commercial program. I am stunned at the sheer volume of pointless garbage that this program has generated, and it makes me seriously doubt any other information received from these "experts". I would also point out that self-destructing programs are not new, but one has never caused such an outcry before. If the author of this program is convicted, it will be the first conviction ever for the hidious crime of writing a copy protection system, and will be one of the biggest farces of justice ever witnessed. Disclaimer: These are my own opinions, and do not necessarily represent the opinions of my employers. "AI is also an acronym for Artificial Ignorance" Ian Farquhar Phone : (612) 805-7420 Office of Computing Services Fax : (612) 805-7433 Macquarie University NSW 2109 Also : (612) 805-7205 Australia Telex : AA122377 ACSNet ifarqhar@macuni.mqcc.mq.oz.au ifarqhar@suna.mqcc.mq.oz.au ------------------------------ Date: 09 Feb 90 02:29:05 +0000 From: woody@rpp386.cactus.org (Woodrow Baker) Subject: Re: WDEF in Toronto (MAC) ADAMS@HUMBER.BITNET (Kevin Adams) writes: > > >From the reports I've read NVIR and WDEF both have no malicious > intent, and that any damage they cause are 'side effects'. Is this > accurate? > > It seems very strange to me that Virus writers would launch > their missiles with no payload... Not really, Perhaps they are 1. General test cases to see how effective an attack method is 2. A somewhat responsible virus writer, who likes the chllenge but would not want to cause damage. 3. Someone who stood a chance f getting discovered, and figured that if it was a benign virus, the legal troubles would be less. All of the above would be valid reasons not to make it lethal... Cheers Woody ------------------------------ Date: 09 Feb 90 02:33:21 +0000 From: woody@rpp386.cactus.org (Woodrow Baker) Subject: Re: Idea for WDEF Innoculation (Mac) jg3o+@andrew.cmu.edu (Jason Ari Goldstein) writes: > Just like everywhere else the WDEF is thriving here at Carnegie-Mellon > Univ. I recently removed WDEF A & B off of 15 disks of a friend of > mine. When I commented to somone here about the virus they said there > was nothing they could do to stop it, except remove it once a machine > got infected. > > I don't know much about Macs (Being a PC person) but if I understand > correctly every time the disk is inserted the they Virus is sread to > the disk. Well, why doesn't someone write an innoculation directly > based on the virus itself. Everytime a disk is inserted in the drive > it would be checked for infection if so it would remove WDEF if not it > would then 'innoculate the disk' with itself. Eventually, WDEF would > be wiped out the same way it was spread initially. This is the first *really* sane Idea that I have seen, about combatting viri. The checkers and clearers are fine, but this type of 'virus' would be a good thing. Provided it is safegarded so that IT can't be infected..... Cheers Woody ------------------------------ Date: Mon, 12 Feb 90 10:45:43 +0000 From: Alan Solomon Subject: Twelve Tricks Trojan (PC) The "Twelve Tricks" trojan - alert and description We have recently received and analysed a trojan that we believe warrants an urgent alert. We are calling it the Twelve Tricks trojan, and it is very interesting, very nasty, and quite complex. This message is not meant to be a complete description of the trojan - we feel that it is important to get a warning out quickly, rather than aim for completeness. It is not a virus. The trojan consists of a program (more about this aspect later) which you run; running the program, as well as the obvious things that the program is expected to do, also replaces the partition record (also called the Master Boot Record, or MBR) on your hard disk with its own version. This can easily be recognised by inspecting the hard disk at cylinder zero, head zero, sector one, which can be done with a disk sector editor such as Peeka. If the partition has this trojan in place, it will contain the following text near the beginning: SOFTLoK+ V3.0 SOFTGUARD SYSTEMS INC 2840 St. Thomas Expwy,suite 201 Santa Clara,CA 95051 (408)970-9420 At this point, let us state that we believe that the company mentioned above has nothing whatsoever to do with the trojan; perhaps the trojan author has a grudge against them. The trojan uses a far call to the hard disk Bios code in order to plant this partition. To do this, it must know the location in memory of the entry point; it tries five different ones, one of which is the one documented in the IBM PC-XT Technical reference manual, and the other four are presumably fairly common alternatives. The purpose of planting the trojan with a far call is, we believe, to escape detection by Active Monitor programs that protect a computer by monitoring the interrupt table, and preventing unauthorised writes to system areas on the hard disk. Since Twelve Tricks doesn't use an interrupt to plant the MBR, such programs won't be able to prevent it. We tested this using Flushot+, probably the most successful of the Active Monitors, and Twelve Tricks went straight through it - the same would be true, we think, of any other Active Monitor. The Replacement MBR When the MBR is run, which is every time you boot from the hard disk, Twelve Tricks copies 205 (d7h) bytes of itself onto locations 0:300h to 0:3d6h. This overwrites part of the interrupt vector table, but it is a part that doesn't get used very much. This means that these d7h bytes are memory resident without having to use any of the TSR calls of Dos, and without having to reserve part of high memory. Reserving part of high memory is the usual ploy used by Boot Sector Viruses, but the drawback of that route is that you might notice that a few kb from your 640 kb has disappeared (CHKDSK would reveal this). The method used by Twelve Tricks would not show up as a loss from your 640 kb. When the computer is started up, a random number generator determines which of the Twelve Tricks will be installed. It does the installation by replacing one of the interrupt vectors with a vector that points to the Twelve Tricks own code, and then chains on to the original code. The twelve tricks are: 1. Insert a random delay loop in the timer tick, so that 18.2 times per second, the computer executes a loop that is randomly between 1 and 65536 long (different each time it is executed). This slows the machine down, and makes it work rather jerkily. 2. Insert an End-Of-Interrupt in the timer tick. This interferes with the servicing of hardware interrupts, so for example, the clock is stopped, TSRs that depend on the timer tick don't work, and the floppy motor is permanently on. 3. Every time a key is pressed or released, the timer tick count is incremented by a random number between 0 and 65535. This has a variety of effects; programs sometimes won't run, when you type "TIME" you get "Current time is divide overflow", and copying files sometimes doesn't work. 4. Every time interrupt 0dh is executed, only do the routine three times out of four. Interrupt 0dh is used on PCs and XTs for the fixed disk, on ATs for the parallel port. 5. Every time interrupt 0eh is executed, only do the routine three times out of four. Interrupt 0eh is used for the floppy disk. 6. Every time interrupt 10h is called (this is the video routine), insert a delay loop that is randomly between 1 and 65536 long (different each time it is executed). This slows the video down, and makes it work rather jerkily and/or slowly. 7. Every time the video routine to scroll up is called, instead of the requested number of lines being scrolled, the entire scrolling window is blanked. 8. Every time a request is made to the diskette handler, it is converted into a write request. This means that the first time you try to read or write to a diskette, whatever happens to be in the buffer will be written to the diskette, and will probably overwrite the boot sector, FAT or directory, as these must be read before anything else can be done. If you try to read a write protected diskette, you get "Write protect error reading drive A". If you do a DIR of a write enabled diskette, you get "General Failure ...", and if you inspect the diskette using a sector editor, you'll find that the boot and FAT have been zeroed or over-written. 9. Every time interrupt 16h is called (read the keyboard) the keyboard flags (Caps lock, Num lock, shift states etc) are set randomly before the keystroke is returned. This means that at the Dos prompt, the keyboard will only work occasionally. Programs that poll interrupt 16h will be unusable. Holding down the Del key will trigger a Ctrl-Alt-Del. 10. Everything that goes to the printer is garbled by xoring it with a byte from the timer tick count. 11. Every letter that is sent to the printer has its case reversed by xoring it with 20h. Also, non-alpha characters are xored, so a space becomes a null, and line feeds don't feed lines. 12. Whenever the Time-Of-Day interrupt (1ah) is executed, do an End-Of-Interrupt instead. This means that you can't set the system clock, and the time is set permanently to one value. These are the twelve tricks. In addition there are two more things that the trojan does. It uses a random number generator; one time out of 4096, it does a low level format of the track that contains the active boot sector; this will also destroy part of the first copy of the FAT. You can recover from this by creating a new boot sector, and copying the second copy of the FAT back over the first copy. After it does the format, it will display the message "SOFTLoK+ " etc as above, and hang the computer. If it doesn't do the format, it makes a random change to a random word in one of the first 16 sectors of the FAT, which will make a slight and increasing corruption in the file system. This is perhaps the worst of the things that it does, as it will cause an increasing corruption of the files on the disk. The Dropper program The program that drops the trojan was, in the specimen that we analysed, a hacked version of CORETEST, a program to benchmark hard disk performance. The file is CORETEST.COM, it is version 2.6, (dated 1986 in the copyright message) had a length of 32469 bytes, and it was timestamped 6-6-86, 9:44. When we looked in more detail at this program, we found some interesting things. It looks as if the original CORETEST program was an EXE file, and the trojan author prepended his code to it. This code consists of some relocation stuff, then a decryptor, to decrypt the following 246h bytes. The decryption is a double xor with a changing byte. Those 246h bytes, when run, examine the memory to try to find one of five sets of hard disk handler code (presumably corresponding to five Bioses). When it finds one of them, (we have identified the first one as being the IBM XT Bios) it plants the trojan MBR in place, using a far call to the Bios code. The trojan MBR is 200h of the 246h bytes. The trojan is patched so that it also does disk accesses using a far call to the same location. Finally, the prepended trojan passes control to the original program. We call the combination of the prepended code, plus the original program, the Dropper. The main purpose of the encryption, we would guess, is to evade detection by programs that check code for bombs and trojans. There are no suspicious strings or interrupt calls in the code until it is decrypted at run time. As far as we can tell, it is not a virus, but a trojan. However, it is unlikely that all the patching to the original program was done by hand - it is far more likely that the trojan author wrote a prepender program (we would call this the Prepender), to automatically attach his code to the target executable. If this is the case, then there are two consequences. The first is that he might have trojanised other programs besides the one that we have examined. In other words, there might be other Droppers around besides the one we have examined. The second is that if that is the case, we cannot rely on the encryption having the same seed each time, as the Prepender might change the seed each time it operates. So it would be unsafe to search files for the encrypted MBR. Instead, we propose a search string based on the decryptor. Indeed, a further possibility exists. The Prepender program might have been placed into circulation, and people running it would unwittingly be creating additional Droppers. There is absolutely no evidence to suggest that that is actually the case, but we would ask anyone who detects this Dropper in one of their files, to also examine all the others. Detection Here's a variety of ways to detect the trojan. The hexadecimal string e4 61 8a e0 0c 80 e6 61 is to be found in the MBR. This string will also be found in memory if you have booted from a trojanised MBR, at location 0:38b. You can use Debug to search in memory. A useful search string to detect the Dropper is be 64 02 31 94 42 01 d1 c2 4e 79 f7 Getting rid of it It's easy to get rid of Droppers; just delete them and replace them with a clean copy. If you find the string above in the MBR or in memory at 0:38b, you need to boot from a clean Dos diskette and replace the partition record. DO NOT use Fdisk to do this unless you are prepared for Fdisk to zero your FAT and directory; you will lose all your data that way. One way would be to do a file-by-file backup, low-level format to get rid of the trojan MBR, then Fdisk Format and restoer your backup. We would recommend doing two backups using as different methods as possible if you use this route, in case one of them fails to restore. The other way to replace the partition is to run a program that drops a clean partition record onto the MBR, but doesn't change the partitioning data. We are currently preparing one of these - please ask if you need it. Damage done The whole of the MBR is used for the code. Most normal MBRs don't use more than half the space, and a number of other programs have started using this space. For example Disk Manager, and the Western Digital WDXT-Gen controllers (but the Dropper doesn't work on the WDXT-Gen). This means that the Dropper might cause an immediate problem in some circumstances. The main damage done, however, will be in the impression that this trojan creates that your hardware is suffering from a variety of faults, which usually go away when you reboot (only to be replaced by other faults). Also, the FAT gets progressively corrupted. Occurrences So far, this has only been reported in Surrey, England. It was noticed because it made a disk using Speedstor to control it, non-bootable. Disks that are controlled in the normal way, remain bootable. We would be grateful if any sightings could be reported to us, especially if the Dropper program is different from the one we have examined; we would also like a specimen of it, Please report instances to the addresses below: Dr Alan Solomon Day voice: +44 494 791900 S&S Anti Virus Group Eve voice: +44 494 724201 Water Meadow Fax: +44 494 791602 Germain Street, BBS: +44 494 724946 Chesham, Fido node: 254/29 Bucks, HP5 1LP Usenet: drsolly@ibmpcug.co.uk England Gold: 83:JNL246 CIX, CONNECT drsolly or Mr Christoph Fischer Day voice: +49 721 6084041 Micro-BIT Virus Centre Eve voice: +49 721 861540 University of Karlsruhe Fax: +49 721 621479 Zirkel 2 BITNET: RY15@DKAUNI11 D-7500 Karlsruhe 1 West-Germany ------------------------------ Date: 12 Feb 90 18:14:22 +0000 From: "David N. Schlesinger" Subject: WDEF at Wollongong For those who are keeping scores, the WDEF virus has been found on at least two Macs at the Wollongong group. It was found and destroyed using Virex 2.3. Best, Lefty =========================================================================== David N. Schlesinger || "There's a word for it: words don't The Wollongong Group || mean a thing. There's a name for it; Internet: Lefty@twg.com || names make all the difference in the POTS: 415/962-7219 || world..." -- David Byrne =========================================================================== ------------------------------ End of VIRUS-L Digest ********************* Downloaded From P-80 International Information Systems 304-744-2253