VIRUS-L Digest Wednesday, 16 Aug 1989 Volume 2 : Issue 176 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. 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 Today's Topics: Swapping Virus (PC) Response to query from A.Berman, Yale,8-14-89 (PC) CERT Internet Security Advisory --------------------------------------------------------------------------- Date: Tue, 15 Aug 89 20:36:50 +0300 From: "Yuval Tal (972)-8-474592" Subject: Swapping Virus (PC) +------------------------------------------------------+ | The "Swapping" virus | +------------------------------------------------------+ | | | Disassembled on: August, 1989 | | | | Disassembled by: Yuval Tal | | | | Disassembled using: ASMGEN and DEBUG | | | +------------------------------------------------------+ Important note: If you find *ANYTHING* that you think I wrote incorrectly or is-understood something, please let me know ASAP. You can reach me: Bitnet: NYYUVAL@WEIZMANN InterNet: NYYUVAL%WEIZMANN.BITNET@CUNYVM.CUNY.EDU This text is divided into theree parts: 1) A report about the Swap Virus. 2) A disassembly of the Swap Virus. 3) How to install this virus? - ------------------------------------------------------------------------------ - R E P O R T - ------------------------------------------------------------------------------ - Virus Name..............: The Swap Virus Attacks.................: Floppy-disks only Virus Detection when....: June, 1989 at......: Israel Length of virus.........: 1. The virus itself is 740 bytes. 2. 2048 bytes in RAM. Operating system(s).....: PC/MS DOS version 2.0 or later Identifications.........: A) Boot-sector: 1) Bytes from $16A in the boot sector are: 31 C0 CD 13 B8 02 02 B9 06 27 BA 00 01 CD 13 9A 00 01 00 20 E9 XX XX 2) The first three bytes in the boot sector are: JMP 0196 (This is, if the boot sector was loaded to CS:0). B) FAT: Track 39 sectors 6-7 are marked as bad. C) The message: "The Swapping-Virus. (C) June, by the CIA" is located in bytes 02B5-02E4 on track 39, sector 7. Type of infection.......: Stays in RAM, hooks int $8 and int $13. A diskette is infected when it is inserted into the drive and ANY command that reads or writes from/to the diskette is executed. Hard disks are NOT infected ! Infection trigger.......: The virus starts to work after 10 minutes. Interrupt hooked........: $8 (Timer-Tick - Responsible for the letter dropping) $13 (Disk Drive - Infects!) Damage..................: Track 39 sectors 6-7 will be marked as bad in the FAT. Damage trigger..........: The damage is done whenever a diskette is infected. Particularities.........: A diskette will be infected only if track 39 sectors 6-7 are empty. +-----------------------------------------------------------------------+ | BitNet: NYYUVL@WEIZMANN CSNet: NYYUVAL@WEIZMANN.BITNET | | InterNet: NYYUVAL%WEIZMANN.BITNET@CUNYVM.CUNY.EDU | | | | Yuval Tal | | The Weizmann Institute Of Science "To be of not to be" -- Hamlet | | Rehovot, Israel "Oo-bee-oo-bee-oo" -- Sinatra | +-----------------------------------------------------------------------+ ------------------------------ Date: Tue, 15 Aug 89 16:51:00 -0500 From: LUCKSMITH%ALISUVAX.BITNET@IBM1.CC.Lehigh.Edu Subject: Response to query from A.Berman, Yale,8-14-89 (PC) The unknown virus that Andrew Berman referred to in his submission of 14 Aug 89 sounds very much like one encountered here within the last 90 days. Various names exist for it, including Friday the 13th, Israeli, Jerusalem, Black Box and others. The virus is a TSR type that infects .COM and .EXE files replicating itself into the files (once only for .COM and repeatedly for .EXE). (It will infect and replicate itself in ANY executible, no matter the extension..check especially .OVL and .SYS) The virus under certain circumstances will delete files from the disk on Friday the 13th. Norton Utilities is capable of identifying the infected files by searching for the hexadecimal string E9 92 00 73 55 4D 73 44. Those eight bytes invariably occurred in the virus found here. A system can only be certified clean of the virus if the system is cold-booted from a clean system and the source files to be used are checked and found to be clean before they are used. This virus is very contagious...during the cleanup and check phase we infected FluShot+ more than once. There is an article by Yisrael Radai, Hebrew Univ. of Jerusalem, on the "original" Israeli PC virus in April 1989 issue of Computers and Security (UK publication, Elsevier Science Pub., Ltd. Vol.8, No. 2) and a paper by Jim Goodwin on Israeli viruses, available from the moderator of this forum. Based on our recent experience, good luck, and happy cleaning. David Rehbein, Thompson@alisuvax.bitnet Marsha Luckett-Smithson, LuckSmith@alisuvax.bitnet Ames Laboratory USDOE, Iowa State University ------------------------------ Date: Wed, 16 Aug 89 11:46:06 -0400 From: "Computer Emergency Response Team" Subject: CERT Internet Security Advisory Many computers connected to the Internet have recently experienced unauthorized system activity. Investigation shows that the activity has occurred for several months and is spreading. Several UNIX computers have had their "telnet" programs illicitly replaced with versions of "telnet" which log outgoing login sessions (including usernames and passwords to remote systems). It appears that access has been gained to many of the machines which have appeared in some of these session logs. (As a first step, frequent telnet users should change their passwords immediately.) While there is no cause for panic, there are a number of things that system administrators can do to detect whether the security on their machines has been compromised using this approach and to tighten security on their systems where necessary. At a minimum, all UNIX site administrators should do the following: o Test telnet for unauthorized changes by using the UNIX "strings" command to search for path/filenames of possible log files. Affected sites have noticed that their telnet programs were logging information in user accounts under directory names such as "..." and ".mail". In general, we suggest that site administrators be attentive to configuration management issues. These include the following: o Test authenticity of critical programs - Any program with access to the network (e.g., the TCP/IP suite) or with access to usernames and passwords should be periodically tested for unauthorized changes. Such a test can be done by comparing checksums of on-line copies of these programs to checksums of original copies. (Checksums can be calculated with the UNIX "sum" command.) Alternatively, these programs can be periodically reloaded from original tapes. o Privileged programs - Programs that grant privileges to users (e.g., setuid root programs/shells in UNIX) can be exploited to gain unrestricted access to systems. System administrators should watch for such programs being placed in places such as /tmp and /usr/tmp (on UNIX systems). A common malicious practice is to place a setuid shell (sh or csh) in the /tmp directory, thus creating a "back door" whereby any user can gain privileged system access. o Monitor system logs - System access logs should be periodically scanned (e.g., via UNIX "last" command) for suspicious or unlikely system activity. o Terminal servers - Terminal servers with unrestricted network access (that is, terminal servers which allow users to connect to and from any system on the Internet) are frequently used to camouflage network connections, making it difficult to track unauthorized activity. Most popular terminal servers can be configured to restrict network access to and from local hosts. o Passwords - Guest accounts and accounts with trivial passwords (e.g., username=password, password=none) are common targets. System administrators should make sure that all accounts are password protected and encourage users to use acceptable passwords as well as to change their passwords periodically, as a general practice. For more information on passwords, see Federal Information Processing Standard Publication (FIPS PUB) 112, available from the National Technical Information Service, U.S. Department of Commerce, Springfield, VA 22161. o Anonymous file transfer - Unrestricted file transfer access to a system can be exploited to obtain sensitive files such as the UNIX /etc/passwd file. If used, TFTP (Trivial File Transfer Protocol - which requires no username/password authentication) should always be configured to run as a non-privileged user and "chroot" to a file structure where the remote user cannot transfer the system /etc/passwd file. Anonymous FTP, too, should not allow the remote user to access this file, or any other critical system file. Configuring these facilities to "chroot" limits file access to a localized directory structure. o Apply fixes - Many of the old "holes" in UNIX have been closed. Check with your vendor and install all of the latest fixes. If system administrators do discover any unauthorized system activity, they are urged to contact the Computer Emergency Response Team (CERT). Kenneth R. van Wyk Computer Emergency Response Team cert@SEI.CMU.EDU (412) 268-7090 (24 hour hotline) ------------------------------ End of VIRUS-L Digest ********************* Downloaded From P-80 International Information Systems 304-744-2253