home *** CD-ROM | disk | FTP | other *** search
/ Hacker 2 / HACKER2.mdf / virus / virusl2 / virusl2.176 < prev    next >
Text File  |  1995-01-03  |  11KB  |  233 lines
  1. VIRUS-L Digest   Wednesday, 16 Aug 1989    Volume 2 : Issue 176
  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.  Information on
  8. accessing anti-virus, document, and back-issue archives is distributed
  9. periodically on the list.  Administrative mail (comments, suggestions,
  10. and so forth) should be sent to me at: krvw@SEI.CMU.EDU.
  11.  - Ken van Wyk
  12.  
  13. Today's Topics:
  14.  
  15. Swapping Virus (PC)
  16. Response to query from A.Berman, Yale,8-14-89 (PC)
  17. CERT Internet Security Advisory
  18.  
  19. ---------------------------------------------------------------------------
  20.  
  21. Date:    Tue, 15 Aug 89 20:36:50 +0300
  22. From:    "Yuval Tal (972)-8-474592" <NYYUVAL@WEIZMANN.BITNET>
  23. Subject: Swapping Virus (PC)
  24.  
  25.  
  26.         +------------------------------------------------------+
  27.         |                The "Swapping" virus                  |
  28.         +------------------------------------------------------+
  29.         |                                                      |
  30.         | Disassembled on: August, 1989                        |
  31.         |                                                      |
  32.         | Disassembled by: Yuval Tal                           |
  33.         |                                                      |
  34.         | Disassembled using: ASMGEN and DEBUG                 |
  35.         |                                                      |
  36.         +------------------------------------------------------+
  37.  
  38. Important note: If you find *ANYTHING* that you think I wrote
  39. incorrectly or is-understood something, please let me know ASAP.
  40. You can reach me:
  41.  
  42.  Bitnet:   NYYUVAL@WEIZMANN
  43.  InterNet: NYYUVAL%WEIZMANN.BITNET@CUNYVM.CUNY.EDU
  44.  
  45.  
  46. This text is divided into theree parts:
  47.  
  48.     1) A report about the Swap Virus.
  49.     2) A disassembly of the Swap Virus.
  50.     3) How to install this virus?
  51.  
  52. - ------------------------------------------------------------------------------
  53.  
  54. -
  55.                             R  E  P  O  R  T
  56. - ------------------------------------------------------------------------------
  57.  
  58. -
  59.  
  60. Virus Name..............: The Swap Virus
  61. Attacks.................: Floppy-disks only
  62. Virus Detection when....: June, 1989
  63.                 at......: Israel
  64. Length of virus.........: 1. The virus itself is 740 bytes.
  65.                           2. 2048 bytes in RAM.
  66. Operating system(s).....: PC/MS DOS version 2.0 or later
  67. Identifications.........: A) Boot-sector:
  68.                              1) Bytes from $16A in the boot sector are:
  69.                                    31 C0 CD 13 B8 02 02 B9 06 27 BA 00 01 CD 13
  70.                                    9A 00 01 00 20 E9 XX XX
  71.                              2) The first three bytes in the boot sector are:
  72.                                 JMP 0196 (This is, if the boot sector was
  73.                                           loaded to CS:0).
  74.                           B) FAT: Track 39 sectors 6-7 are marked as bad.
  75.                           C) The message:
  76.                                 "The Swapping-Virus. (C) June, by the CIA"
  77.                              is located in bytes 02B5-02E4 on track 39,
  78.                              sector 7.
  79. Type of infection.......: Stays in RAM, hooks int $8 and int $13.
  80.                           A diskette is infected when it is inserted into the
  81.                           drive and ANY command that reads or writes from/to
  82.                           the diskette is executed. Hard disks are NOT infected
  83. !
  84. Infection trigger.......: The virus starts to work after 10 minutes.
  85. Interrupt hooked........: $8 (Timer-Tick - Responsible for the letter dropping)
  86.                           $13 (Disk Drive - Infects!)
  87. Damage..................: Track 39 sectors 6-7 will be marked as bad in the
  88.                           FAT.
  89. Damage trigger..........: The damage is done whenever a diskette is infected.
  90. Particularities.........: A diskette will be infected only if track 39 sectors
  91.                           6-7 are empty.
  92.  
  93. +-----------------------------------------------------------------------+
  94. | BitNet:   NYYUVL@WEIZMANN              CSNet: NYYUVAL@WEIZMANN.BITNET |
  95. | InterNet: NYYUVAL%WEIZMANN.BITNET@CUNYVM.CUNY.EDU                     |
  96. |                                                                       |
  97. | Yuval Tal                                                             |
  98. | The Weizmann Institute Of Science     "To be of not to be" -- Hamlet  |
  99. | Rehovot, Israel                       "Oo-bee-oo-bee-oo" -- Sinatra   |
  100. +-----------------------------------------------------------------------+
  101.  
  102. ------------------------------
  103.  
  104. Date:    Tue, 15 Aug 89 16:51:00 -0500
  105. From:    LUCKSMITH%ALISUVAX.BITNET@IBM1.CC.Lehigh.Edu
  106. Subject: Response to query from A.Berman, Yale,8-14-89 (PC)
  107.  
  108.       The unknown virus that Andrew Berman referred to in his
  109. submission of 14 Aug 89 sounds very much like one encountered here
  110. within the last 90 days. Various names exist for it,
  111. including Friday the 13th, Israeli, Jerusalem, Black Box and others.
  112. The virus is a TSR type that infects .COM and .EXE files replicating
  113. itself into the files (once only for .COM and repeatedly for .EXE).
  114. (It will infect and replicate itself in ANY executible, no matter
  115. the extension..check especially .OVL and .SYS)
  116. The virus under certain circumstances will delete files from the disk
  117. on Friday the 13th. Norton Utilities is capable of identifying the
  118. infected files by searching for the hexadecimal string E9 92 00 73 55
  119. 4D 73 44. Those eight bytes invariably occurred in the virus found
  120. here. A system can only be certified clean of the virus if the
  121. system is cold-booted from a clean system and the source files to be
  122. used are checked and found to be clean before they are used.
  123. This virus is very contagious...during the cleanup and check phase we
  124. infected FluShot+ more than once.
  125. There is an article by Yisrael Radai, Hebrew Univ. of Jerusalem, on the
  126. "original" Israeli PC virus in April 1989 issue of Computers and Security
  127. (UK publication, Elsevier Science Pub., Ltd. Vol.8, No. 2) and a paper
  128. by Jim Goodwin on Israeli viruses, available from the moderator of this
  129. forum.
  130. Based on our recent experience, good luck, and happy cleaning.
  131.  
  132. David Rehbein, Thompson@alisuvax.bitnet
  133. Marsha Luckett-Smithson, LuckSmith@alisuvax.bitnet
  134. Ames Laboratory USDOE, Iowa State University
  135.  
  136.  
  137. ------------------------------
  138.  
  139. Date:    Wed, 16 Aug 89 11:46:06 -0400
  140. From:    "Computer Emergency Response Team" <cert@SEI.CMU.EDU>
  141. Subject: CERT Internet Security Advisory
  142.  
  143. Many computers connected to the Internet have recently experienced
  144. unauthorized system activity.  Investigation shows that the activity
  145. has occurred for several months and is spreading.  Several UNIX
  146. computers have had their "telnet" programs illicitly replaced with
  147. versions of "telnet" which log outgoing login sessions (including
  148. usernames and passwords to remote systems).  It appears that access
  149. has been gained to many of the machines which have appeared in some of
  150. these session logs.  (As a first step, frequent telnet users should
  151. change their passwords immediately.)  While there is no cause for
  152. panic, there are a number of things that system administrators can do
  153. to detect whether the security on their machines has been compromised
  154. using this approach and to tighten security on their systems where
  155. necessary.  At a minimum, all UNIX site administrators should do the
  156. following:
  157.  
  158. o Test telnet for unauthorized changes by using the UNIX "strings"
  159.   command to search for path/filenames of possible log files.  Affected
  160.   sites have noticed that their telnet programs were logging information
  161.   in user accounts under directory names such as "..." and ".mail".
  162.  
  163. In general, we suggest that site administrators be attentive to
  164. configuration management issues.  These include the following:
  165.  
  166.  
  167. o Test authenticity of critical programs - Any program with access to
  168.   the network (e.g., the TCP/IP suite) or with access to usernames and
  169.   passwords should be periodically tested for unauthorized changes.
  170.   Such a test can be done by comparing checksums of on-line copies of
  171.   these programs to checksums of original copies.  (Checksums can be
  172.   calculated with the UNIX "sum" command.)  Alternatively, these
  173.   programs can be periodically reloaded from original tapes.
  174.  
  175. o Privileged programs - Programs that grant privileges to users (e.g.,
  176.   setuid root programs/shells in UNIX) can be exploited to gain
  177.   unrestricted access to systems.  System administrators should watch
  178.   for such programs being placed in places such as /tmp and /usr/tmp (on
  179.   UNIX systems).  A common malicious practice is to place a setuid shell
  180.   (sh or csh) in the /tmp directory, thus creating a "back door" whereby
  181.   any user can gain privileged system access.
  182.  
  183. o Monitor system logs - System access logs should be periodically
  184.   scanned (e.g., via UNIX "last" command) for suspicious or unlikely
  185.   system activity.
  186.  
  187. o Terminal servers - Terminal servers with unrestricted network access
  188.   (that is, terminal servers which allow users to connect to and from
  189.   any system on the Internet) are frequently used to camouflage network
  190.   connections, making it difficult to track unauthorized activity.
  191.   Most popular terminal servers can be configured to restrict network
  192.   access to and from local hosts.
  193.  
  194. o Passwords - Guest accounts and accounts with trivial passwords
  195.   (e.g., username=password, password=none) are common targets.  System
  196.   administrators should make sure that all accounts are password
  197.   protected and encourage users to use acceptable passwords as well as
  198.   to change their passwords periodically, as a general practice.  For
  199.   more information on passwords, see Federal Information Processing
  200.   Standard Publication (FIPS PUB) 112, available from the National
  201.   Technical Information Service, U.S. Department of Commerce,
  202.   Springfield, VA 22161.
  203.  
  204. o Anonymous file transfer - Unrestricted file transfer access to a
  205.   system can be exploited to obtain sensitive files such as the UNIX
  206.   /etc/passwd file.  If used, TFTP (Trivial File Transfer Protocol -
  207.   which requires no username/password authentication) should always be
  208.   configured to run as a non-privileged user and "chroot" to a file
  209.   structure where the remote user cannot transfer the system /etc/passwd
  210.   file.  Anonymous FTP, too, should not allow the remote user to access
  211.   this file, or any other critical system file.  Configuring these
  212.   facilities to "chroot" limits file access to a localized directory
  213.   structure.
  214.  
  215. o Apply fixes - Many of the old "holes" in UNIX have been closed.
  216.   Check with your vendor and install all of the latest fixes.
  217.  
  218.  
  219. If system administrators do discover any unauthorized system activity,
  220. they are urged to contact the Computer Emergency Response Team (CERT).
  221.  
  222.  
  223. Kenneth R. van Wyk
  224. Computer Emergency Response Team
  225. cert@SEI.CMU.EDU
  226. (412) 268-7090  (24 hour hotline)
  227.  
  228. ------------------------------
  229.  
  230. End of VIRUS-L Digest
  231. *********************
  232. Downloaded From P-80 International Information Systems 304-744-2253
  233.