VIRUS-L Digest Monday, 8 Apr 1991 Volume 4 : Issue 55 Today's Topics: HC viruses vs. Trojans (Mac) Unix viruses and damaging programs (UNIX) re: April Fool's Day virus (PC) Mutation of Stoned/Implications for self check boot sectors(PC) Virus Detectors for Suns running UNIX (UNIX) 1813 Virus on a PC (PC) MDC questions Joshi Virus in part. table (PC) re: Unix viruses and damaging programs (UNIX) Re: Zenith OEM MS-DOS (PC) Questions re. UNIX viruses (UNIX) How to kill Stoned in partition table (PC) Re: More reviews on archives Call for Papers - DPMA Virus Conference Systems Security Certification information 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. Please sign submissions with your real name. Send contributions to VIRUS-L@IBM1.CC.LEHIGH.EDU (that's equivalent to VIRUS-L at LEHIIBM1 for you BITNET folks). Information on accessing anti-virus, documentation, and back-issue archives is distributed periodically on the list. Administrative mail (comments, suggestions, and so forth) should be sent to me at: krvw@CERT.SEI.CMU.EDU. Ken van Wyk --------------------------------------------------------------------------- Date: Fri, 05 Apr 91 10:28:15 -0500 >From: Joe McMahon Subject: HC viruses vs. Trojans (Mac) I'd argue that Dukakis was/is a virus. Why? The program created copies of itself by infecting the Home stack script and them infecting the stack scripts of other stacks. From my point of view, this fulfills the qualifications of a virus - a self-reproducing program which uses other programs as hosts. A Trojan, on the other hand, is a program purporting to do one thing and actually doing another. The Dukakis virus actually stated within its source that it was a virus. I can't think of anything less like a Trojan - the program did act exactly as it claimed it would. I don't personally feel there's a "level of simplicity" below which a piece of code is too simple to be a virus. Just because the programming language used to write the virus is HyperTalk and not C or assembly language doesn't mean it can't act like a virus. It's just easier to detect and stop. --- Joe M. ------------------------------ Date: 05 Apr 91 10:39:41 -0500 >From: "David.M.Chess" Subject: Unix viruses and damaging programs (UNIX) vancleef@iastate.edu (Van Cleef Henry H): > I have been asked to consider the possibility of virus, trojan horse, > etc. attacks on a distributed Unix fileserver system... > > My study begins with some assumptions, which I should state here... > > b. That all "security" to read and write as a superuser has already > been breached and that this breach has gone undetected. > > c. That one workstation with a bootable hard disk is accessible to the > individual planning to damage the system... Those are fine assumptions if you only want to worry about traditional sorts of attacks (Bad Guy breaking into your system and doing Bad Things by typing at his terminal/workstation). But if you also want to worry about the new sorts of risks that come with viruses, you should make assumptions that are more like: < b'. That, although the technical security of the system may be intact < and unbreached, there may be program-sharing patterns that would < allow a spreading virus to get from an "exposed" user to one with < superuser authority, through innocent actions of authorized users. < < c'. That, rather than a single individual actively attempting to do < damage on your system, there may be viruses in the outside world < that could inadvertantly be brought into the organization through < the innocent actions of authorized users importing programs. The new dangers that viruses add are that they can cause an "attacker's" code to run with privileges on your system even if your system's security is unbreached, no passwords have been guessed, everyone with access to your system is well-intentioned, and the attacker has in fact never touched a workstation attached to your system (he may never even have *heard* of your system). DC ------------------------------ Date: 05 Apr 91 10:58:43 -0500 >From: "David.M.Chess" Subject: re: April Fool's Day virus (PC) viki@crash.cts.com (Victoria Harkey): > There was a posting on April 2 regarding a trojan horse that had activated > on April 1, and was now a full force virus. Has this virus been identified? > Has anyone been able to get rid of it? There was? I don't recall/find any such posting. Perhaps it was a forged posting, local to your site, and someone's playing an elaborate joke on you? If not, and you're actually seeing symptoms of something, perhaps you could post more details? DC ------------------------------ Date: Fri, 05 Apr 91 11:42:14 -0500 >From: padgett%tccslr.dnet@uvs1.orl.mmc.com (A. Padgett Peterson) Subject: Mutation of Stoned/Implications for self check boot sectors(PC) >From: frisk@rhi.hi.is (Fridrik Skulason) >I think somebody may be confusing this with the practice of Zenith DOS >(or at least some versions of it) to write to the DOS boot record - Our experience with Zenith XT class machines (model 158 & 159) was that they did write occasionally to the boot record (not the MBR) as Frisk says. This action seemed to occur with Zenith DOS 3.0 through 3.2 and the location written to varied with the O/S but was inside the "reserved" area of the boot record. As with Frisk's software, this surfaced when we began installing integrity checking mechanisms in our PCs last year and started getting changes flagged on each boot, before we had the checking software "fixed" to recognize that it was dealing with a Zenith (ATs & 386s did not exhibit this). Since then, I have been told that early HP Vectras are likely to exhibit this same condition. For more detailed discussion, I posted a number of items to Virus-L last year concerning this. Possibly, the confusion seems to come from the number of different names applied to the "Master Boot Record" (cyl 0 hd 0 setor 1) which contains both executable code and the partition table. The DOS Boot Record (first sector of any DOS partition - only the record of the partition marked "active" is executed) is something else entirely. The DOS Boot Record can be accessed with a "load" (L) command from DEBUG. The MBR cannot. Padgett ------------------------------ Date: Fri, 5 Apr 91 11:42:14 -0500 >From: Padgett Peterson Subject: Virus Detectors for Suns running UNIX (UNIX) >From: ejd@slate.mitre.org (eRic Donaldson) >From: vancleef@iastate.edu (Van Cleef Henry H) >My study begins with some assumptions, which I should state here. >a. That MS-Dos viruses (is this an all-encompassing term for things >that tamper with and destroy the OS and programs?) have conceptual >parallels in the Unix o/s. i.e. the kernel is equivalent to >COMMAND.COM, the file system superblock is equivalent to the FAT, etc. Kind of: COMMAND.COM is more of an analogue of the shell, the kernel is closer to the BIOS while IO.SYS & MSDOS.SYS are more like a "run-time library" - imperfect conceptulization but you get the idea. One reason MS-DOS viruses flourish is that the O/S has zero integrity checking while most multi-user systems have some means of defending one user from the "errors" of another, what we usually term "robustness". >b. That all "security" to read and write as a superuser has already >been breached and that this breach has gone undetected. Given this, an intruder can do anything the system is capable of. Period. However, a worm or spoof is much more likely than a virus simply because it is easier to write (UNIX performs some integrity checking of a file against its header and directory information - MS-DOS does not). Similarly, users of Sun OSes will be reasured to know that the diversity of Sun platforms (based on Intel, Mororola, and SPARC architectures) makes it difficult for an outsider to plant a virus unless it is in the form of source code that the intruder can compile and execute at your location. Executable code that will run on a Sun386i is gibberish to the Sun-3 family. On the other hand, an insider or professional targetting a specific organization can tailor the attack. Given B, anything is possible. The only protection in this case is to make B impossible (or difficult, or, at least detectable). You have to decide the risk/response for yourself. >From your comments, it sounds like you have a specific workstation and individual in mind. My minimum suggestion would be to monitor at the network level (any number of devices can do this) every communication from this station. ------------------------------ Date: Fri, 5 Apr 91 11:42:14 -0500 >From: Padgett Peterson Subject: 1813 Virus on a PC (PC) >From: jogle@floyd.att.com (Joseph M Geigel) 1813 is IBM's apolitical way of referring to the JERUSALEM (must be using VIRUSCAN). ------------------------------ Date: Fri, 5 Apr 91 11:42:14 -0500 >From: Padgett Peterson Subject: MDC questions >From: jimkirk@CORRAL.UWyo.Edu (James Kirkpatrick) > Questions: does anybody have a better feel for the probable security > of the multi-pass SNEFRU... For discussion: a lifetime ago (when ASR-33 traffic was encrypted using the tube-driven KY-26), I was involved with definition of such algorithms. The impression was that for any single key multipass system, if transposition was not used, a single-pass decryption was still possible. If transposition was used, the same number of passes may be required to decrypt (if the encryption is recursive, then the number is something between one and the recursion frequency). ANY continuous encryption method can be broken given enough horsepower (the Intel i860 family makes it easier), the real fist question must be, "How much is someone else willing to spend to break my system ?" and tailor your response accordingly. ps discontinuous cyphers are another subject but DES is continuous. ------------------------------ Date: Fri, 5 Apr 91 11:42:14 -0500 >From: Padgett Peterson Subject: Joshi Virus in part. table (PC) >From: awl@extro.ucc.su.oz.au (Tony Locke) >We have a machine with Joshi on it and can't find something to kill >it. Anyone have any ideas (have tried SCAN 74B) As I recall, the Joshi stores the real MBR (partition table) code in cyl 0 head 0 sector 9 (should be able to tell by looking). To recover, just cold boot from a known clean write-protected floppy and use DEBUG to copy the real MBR back to sector 1. The rest of the virus code will still be on (hopefully) unused sectors on cyl 0 but will be cut off from execution & harmless. Warmly, Padgett ------------------------------ Date: Fri, 05 Apr 91 12:03:16 -0500 >From: Valdis Kletnieks Subject: re: Unix viruses and damaging programs (UNIX) >Date: Wed, 03 Apr 91 21:10:57 +0000 >From: vancleef@iastate.edu (Van Cleef Henry H) >... >b. That all "security" to read and write as a superuser has already >been breached and that this breach has gone undetected. If the first part of this is true, *all* bets are off. See Ken Thompson' Turing Award lecture "On Trusting Trust" for an example. If you are permitting the intruder super-user access and source access, about the *only* way to recover is to scrub the disks and re-install the system from known good tapes from the locked vault. You will have to first format the disks, then convince yourself that the distribution tapes are in fact clean - don't trust your backup tapes, they might be bad. Then re-install the operating system. Then restore user files, checking each one for any and all possible trojans that might still be left in them. Under Unix, if you don't trust your kernel, you can't trust ANYTHING. Your only hope is if you can find a "trick" that the intruder didn't trap against in his kernel hacking. However, Dijkstra once said: "Testing can show the presence of bugs, but not their absence." So if you DONT find anything, that does NOT prove your system is clean, it only means that it's *either* clean *or* the intruder is a step ahead of you. The second part - the assertion that the breach is undetected - is also quite suspect. Remember - we've only caught the second best computer criminal. The best is so good that we'll never catch him. If your system check (whatever its form) actually *finds* anything, then it won't be an undetected breach anymore. If you are planning a *serious* research effort on Unix, you should be addressing the issues of access right compartmentalization - i.e. work on closing the *holes* so that the guy can't *GET* to superuser status... Valdis Kletnieks Computer Systems Engineer Virginia Polytechnic Institute ------------------------------ Date: Fri, 05 Apr 91 15:02:00 -0400 >From: "Paul R. Coen" Subject: Re: Zenith OEM MS-DOS (PC) The Zenith versions of MS-DOS are a little different than the "standard" MS- and PC-DOS. On earlier versions (3.2 and 3.21 -- I haven't used any earlier ones), the current time and date was occasionally saved to the boot sector. That's how the disks "remembered" the approximate time of last use on boot-up (assuming no real-time-clock). This caused the boot sector checksum to change. Frequently. It really freaked me out the first time I noticed it :-). Zenith DOS 3.3+ (equivalent to Compaq 3.31) does away with this. I guess they assume that everyone has real-time clocks in their pc's these days. All of the new Zeniths are shipped with them, anyway. By the way, different releases of 3.3+ leave very different amounts of free memory (some use up to 20K of RAM more than others). I'd assume Zenith 4.01 acts the same way as 3.3+. I have this aversion to to DOS 4.01, so I haven't tested it extensivly. ------------ Brought to you from Drew University, land of the 2,000+ Zeniths. Paul Coen -- Drew University Academic Computer Center pcoen@drunivac.bitnet pcoen@drunivac.drew.edu ------------------------------ Date: Fri, 05 Apr 91 11:33:11 -0800 >From: p1@arkham.wimsey.bc.ca (Rob Slade) Subject: Questions re. UNIX viruses (UNIX) micor!esleng!esleng.ocunix.on.ca!dag@uunet.UU.NET (Dave Gilmour) writes: > 3) What steps should I take in order to "reduce the risk" |-) Others will likely give you better technical information, but the biggest single "whole" that has been shown by the Morris/Internet/UNIX worm, the WANK/VMS worm and Clifford Stoll's experience ("The Cuckoo's Egg") is the failure to rename and reassign security files and system passwords. The best (simple) protection you can give yourself is to change all standard system defaults relating to system access. (UNIX gurus, no flames please. you *know* I am not refering to "terminal type".) ============= Vancouver p1@arkham.wimsey.bc.ca | "Is it plugged in?" Institute for Robert_Slade@mtsg.sfu.ca | "I can't see." Research into (SUZY) INtegrity | "Why not?" User Canada V7K 2G6 | "The power's off Security | here." ------------------------------ Date: Fri, 05 Apr 91 11:41:36 -0800 >From: p1@arkham.wimsey.bc.ca (Rob Slade) Subject: How to kill Stoned in partition table (PC) westk@cgrb.orst.edu (Ken West - Entomology) writes: > How does one kill the stoned virus when it resides in the partition > table of a hard drive. Does McAfee's clean kill it? I've had no > trouble killing in boot sectors with f-disinf but it won't get it in > the PT. Thanks in advance! Which version of FPROT are you using? I have had no trouble with F-DISINF from version 1.11 on, although a recent posting did point out a potential problem with OEM MS-DOS which has been fixed in 1.14. ============= Vancouver p1@arkham.wimsey.bc.ca | "Is it plugged in?" Institute for Robert_Slade@mtsg.sfu.ca | "I can't see." Research into (SUZY) INtegrity | "Why not?" User Canada V7K 2G6 | "The power's off Security | here." ------------------------------ Date: Fri, 05 Apr 91 09:38:49 +0000 >From: plains!umn-cs!LOCAL!aslakson@uunet.UU.NET (Brian Aslakson) Subject: Re: More reviews on archives krvw@cert.sei.cmu.edu (Kenneth R. van Wyk) writes: >Chris McDonald, , has graciously given >us a series of product reviews which he has written on various >anti-virus products for both the PC and the Mac. The reviews are all >available by anonymous FTP on cert.sei.cmu.edu in >pub/virus-l/docs/reviews. The following files are currently >available: >mcdonald.disinfectant - Disinfectant, version 1.5 (Mac) Nice, but Disinfectant has been at version 2.4 for a long time. Version 2 was a big upgrade. Of course some things are the same. It's still free. This review would be all but useless. My one line review of Disinfectant 2.4: Available from various ftp sites, free, you're wrong if you don't use it.* __________________ Mac users that is... [Ed. My mistake - I re-checked Chris's review after reading this message and he indeed did update his review upon receiving Disinfectant 2.4. My apologies for any inconvenience.] - -- Brian Aslakson brian@cs.umn.edu (mail) aslakson@cs.umn.edu (talk) mac-admin@cs.umn.edu (Me!!) ------------------------------ Date: Mon, 08 Apr 91 08:56:47 -0400 >From: Kenneth R. van Wyk Subject: Call for Papers - DPMA Virus Conference CALL FOR FIFTH ANNUAL COMPUTER PAPERS VIRUS & SECURITY CONFERENCE Thursday-Friday, March 12-13, 1992 World Trade Center, New York City Sponsored by DPMA Financial Ind. Ch. in cooperation with ACM SIGSAC, IEEE-CS [pdg], Communications Mgrs. Assn.; ICCP, etc., credits Your Audience: Past attendees have represented industry, military, government, forensic and academic - creators and users of related software and hardware. They travel from U.S. and many international locations, and have titles such as MIS Director, Security Analyst, Operations Manager, Investigator, Programming Leader Topics of Interest Include: o Prevention, Detection, and Recovery from Viruses and other Unauthorized Usage o Case studies of mainframe, pc &/or network security o Access control, accountability, audit, data recovery o Surveys or demonstrations of products & techniques o Particulars of LAN, UNIX, cryptography, military use o Computer crime, law, data liability, related contexts o US/international sharing of research & techniques Paper Submission: A submission may take the format of either a long abstract (3-5 double spaced pages) or a draft final paper. Final papers will usually be 6-20 pages in length. Four copies of the submission should be received regular mail by the Program Chair no later than Tuesday, December 24, 1991. It's best to include a small photo and introductory bio not exceeding 50 words. Successful submitters or co-authors are expected to present in person. Presenters receive Proceedings. Paper Format: Typed double spaced, with last name/page# below bottom line (may be hand-written), brief (to 200 words) abstract following four centered heading lines: TITLE (caps); Name; Position Affiliation; Telephone, City/State/Zip, Electronic Address (optl). Notification: Written and (where practicable) telephoned con-firmation will be initiated by Monday, January 29, 1992, to facilitate low cost travel. Those needing earlier notification should submit papers sooner and attach a note to this effect. You may be asked to perform specific revisions to be accepted. Nobody can guarantee you a place without an acceptable paper. At the Conference: There are five tracks. Time your presentation to last 40 minutes and have clear relation to your paper. A Committee member will preside over your assigned room and adhere to schedule. Don't hesitate to submit a presentation you've given elsewhere to a more specialized audience: Most attendees will find it new - and necessary. On-site Schedule is duplicated early on first day. If you may have a work emergency you can reschedule or substitute your co-author. COMMITTEE: GENERAL CHAIRPERSON: Judy S. Brand Nationwide Computing (800) 835-2246, x190 PROGRAM CHAIRPERSON: Richard G. Lefkon NYU, DPMA Fin. Ind. Ch. 609 West 114th Street New York, NY 10025 (212) 663-2315 H. Carol Bernstein IBM, Vassar Klaus Brunnstein U. of Hamburg Tom Duff AT&T Bell Laboratories Frederick B. Cohen ASP Harold J. Highland Computers & Security Jack Holleran NCSC William H. Murray Deloitte & Touche Donn B. Parker SRI International A. Padgett Peterson Martin-Marietta Fridrick Skulason U. of Iceland Dennis D. Steinauer NIST Gail M. Thackeray Maricopa County, AZ Kenneth R. van Wyk CERT, Carnegie-Mellon ------------------------------ Date: Fri, 05 Apr 91 11:58:58 -0500 >From: Kenneth R. van Wyk Subject: Systems Security Certification information International Information Systems Security Certification Consortium, Inc. Announces Invitation for Test Question Writers and Waiver of Formal Examination (ISC)2, the International Information Systems Security Certification Consortium, Inc., is pleaseed to announce the opportunity for qualified individuals to volunteer as Item Writers, i.e., test question writers, for the Certified Information Systems Security Professional (CISSP) examination. Individuals with significant expertise in one or more of the seventeen topical areas in the Common Body of Knowledge, are invited to apply for acceptance as an Item Writer. The seventeen topical areas in which expertise is sought, are as follows: o Business Continuity Planning o System Program Security o Data Classification o Access Control o Security Awareness o Operations Security o Computer and System Security o Physical Security o Telecommunications Security o Information Ethics o Organizational Structure o Cryptography o Legal/Regulatory Requirements o Risk Management o Application Program Security o Policy Development o Investigation Item Writer Applications will be reviewed as soon after receipt as proactical, as test question writing must commence shortly. (ISC)2 will provide the necessary training for those selected, however, Item Writers are expected to pay their own travel expenses to attend a training session. Those selected who successfully complete their duties as an Item Writer, will be publically recognized following the completion of test development activities. In addition, (ISC)2 also formally announces the opportunity for qualified candidates to apply for Waiver of Formal Examination (WFE) for the Certified Information Systems Security Professional (CISSP) designation. The basic requirements for candidates to qualify is that they must have a total of eight years of information security related experience during the past ten years, with at least five of those years working directly in information systems security. This must include a minimum of one year in at least four different areas of experience related to the topical areas in the Common Body of Knowledge. Full information regarding this and other requirements to qualify for Waiver of Formal Examination and/or acceptance as an Item Writer is contained in the instructions and Application Forms that are available as described below. The Waiver of Formal Examination application period will be open for only six months. WFE Applications are now being accepted, and must be postmarked before midnight August 31, 1991 to be considered. The fee for waiver of Formal Examination is $200, plus a non-refundable $50 application fee ($250 total). There is no fee for those who simply wish to apply as an Item Writer. It should be noted that acceptance as an Item Writer does not imply acceptance for WFE, as the years of experience criteria must still be met. Application Forms and instructions can be quickly obtained by sending a self-addressed 9"x12" envelope, stamped with postage for 2 ounces ($.52 for domestic U.S., $.63 for Canada, $.55 for Mexico, $1.34 for International Airmail), to: (ISC)2, Inc., P.O. Box 98, Spencer, MA 01562, U.S.A. Please do NOT send fees with your request. ABOUT (ISC)2: The International Information Systems Security Certification Consortium, or (ISC)2, was established as a non-profit U.S. corporation specifically chartered to develop a certification program for information systems security professionals. (ISC)2 was founded by representatives of the following groups who are presently serving as volunteer officers or members of the Board of Directors (listed alphabetically): Canadian Information Processing Society (CIPS); Computer Security Institute (CSI); Data Processing Management Association (DPMA); Special Interest Group for Certified Professionals & Special Interest Group for Computer Security; Information Systems Security Association (ISSA); and, International Federation for Information Processing (IFIP). Other interested membership organizations are encouraged to contact (ISC)2 regarding cooperative and mutually beneficial efforts. ------------------------------ End of VIRUS-L Digest [Volume 4 Issue 55] ***************************************** Downloaded From P-80 International Information Systems 304-744-2253