CIAC Documents FY 1990
Series A
ciacfy90.txt All public FY90 bulletins
a-01.txt ciac-unix-attacks
a-02.txt ciac-vms-worm-w_com
a-03.txt ciac-wank-worm
a-04.txt ciac-new-wank-worm
a-05.txt ciac-sun-rpc
a-06.txt ciac-norton-utilities-trojan-horse
a-07.txt ciac-unicos
a-08.txt ciac-unicos
a-09.txt ciac-wdef-virus
a-10.txt ciac-cyborg-trojan-horse
a-11.txt ciac-ti-d3-rsx
a-12.txt ciac-decnet-attacks
a-13.txt ciac-unix-decode
a-14.txt ciac-unix-decode
a-15.txt ciac-apple-mac
a-16.txt ciac-sun-sendmail
a-17.txt ciac-wdef-virus
a-18.txt ciac-smarterm-240
a-19.txt ciac-unix-attacks
a-20.txt ciac-twelve-tricks-trojan-horse
a-21.txt ciac-unix-attacks
a-22.txt ciac-login-screen
a-24.txt ciac-unisys-passwd
a-25.txt ciac-mdef-virus
a-26.txt ciac-steroid-trojan-horse
a-27.txt ciac-orge-virus
a-28.txt ciac-stoned-virus
a-29.txt ciac-stealth-virus
a-30.txt ciac-apollo-domain-os
a-32.txt ciac-sunview-suntools
a-33.txt ciac-jerusalem-virus
a-34.txt ciac-fy90-update
________________________________________________________________
CIAC
Computer Incident Advisory Capability
Information Bulletin
________________________________________________________________
October 9, 1989
Notice A-1
CIAC (the Computer Incident Advisory Capability) has learned
of a series of attacks on a set of UNIX computers attached to the
Internet. This series of attacks targets anonymous ftp to gain access
to the password file, then uses accounts from that file that use
easily guessed passwords to gain access to the machine. Once access
is gained to the machine, a trojan horse is installed in the Telnet
program (as described in a previous CIAC bulletin) to record further
user accounts and passwords. The TFTP facility has also been utilized
in this sequence of breakins. This bulletin describes the nature of
the threat, and suggests a procedure to protect your computers.
This is a limited distribution information bulletin to warn
your site of a series of hacker/cracker attacks on the Internet. This
bulletin is being sent to you because our records indicate that your
site is connected to the Internet. Please inform CIAC if this is not
true. Also, if you are not the CPPM or CSSM for your site, will you
please promptly forward this bulletin to that person or persons?
There has been a series of breakins into UNIX machines
connected to the Internet. These breakins at first were largely into
systems in North and South Carolina, but they have spread rapidly.
They appear to be the work of a group of hackers with fairly
identifiable patterns of attack. You should be aware of these attack
patterns, and should take measures described below to prevent breakins
at your site.
The attackers are using anonymous ftp (the ability to use ftp
as a guest) to obtain copies of an encrypted password file for a
machine. They then decrypt passwords, and use them to log into an
account on that machine. They become a root user, then install the
trojan horse version of Telnet, about which CIAC alerted you nearly
two months ago. This trojan horse collects passwords of Telnet users,
which the hackers then use to break into other machines. The hackers
are also using .rhost and host.equiv to gain entry into other systems
once they have broken into a new machine. The TFTP facility is also
used to gain access to a machine.
The attackers have not been destroying files or damaging
systems. To avoid being detected and/or monitored, however, they have
many times waited for several weeks or even longer after obtaining
passwords to break in to a system. This threat seems to center around
systems that have not installed the distributed patches to already
known vulnerabilities in the UNIX operating system.
CIAC recommends that you take three courses of action:
1) Look for connections between machines in your network and
host machines that would not normally be connected to your site. If
many of these connections exist, there is a strong possibility that
they may not be legitimate.
Currently many of these unauthorized connections and attacks
have been using:
- universities in North and South Carolina
- universities in Boston
- universities and computer companies in the California
Berkeley/Palo Alto area
Any unusual and unexplained activity from these locations are worth
special attention, as they are likely to be attacks.
2) Look for the Telnet trojan horse, using the command:
strings `which telnet` | grep \@\(\#\) | grep on/off
Any lines that are printed from this command indicate that you have
been affected by the trojan horse. If you discover that you have been
affected by the trojan horse program, please contact CIAC for recovery
procedures.
3) If the host.equiv file contains a "+" unauthorized users
can gain entry into a system. You should therefore inform system
managers that they should remove "+" from any host.equiv files.
Please refer questions to:
CIAC, Thomas Longstaff
Lawrence Livermore National Laboratory
P.O. Box 808
L-540
Livermore, CA 94550
(415) 423-4416 or (FTS) 543-4416
longstaf@frostedflakes.llnl.gov
_____________________________________________________________________________
T H E C O M P U T E R I N C I D E N T A D V I S O R Y C A P A B I L I T Y
C I A C
A D V I S O R Y N O T I C E
_____________________________________________________________________________
The W.COM Worm affecting VAX VMS Systems
October 16, 1989 18:37 PST Number A-2
Summary
A worm is attacking NASA's SPAN network via Vax/VMS systems connected
to DECnet. It is unclear if the spread of the worm has been checked.
It may spread to other systems such as DoE's HEPNET within a few days.
VMS system managers should prepare now. The worm targets VMS machines,
and can only be propagated via DECnet. The worm exploits two features
of DECnet/VMS in order to propagate itself. The first is the default
DECnet account, which is a facility for users who don't have a specific
login ID for a machine to have some degree of anonymous access. It uses
the default DECnet account to copy itself to a machine, and then uses
the "TASK 0" feature of DECnet to invoke the remote copy. It has
several other features including a brute force attack on passwords. An
analysis of the worm is provided below. Included with the analysis is
a DCL program that will block the current version of the worm. This
should give your system administrator enough time to close obvious
security holes. This worm exploits poor security practices, so you
must take action now to assure that the worm will not propagate to your
system(s).
If your site may be affected, please contact us for further
information. Information on how to contact CIAC appears at the end
of this notice.
________________________________________________________________________
This is a mean bug to kill and could have done a lot of damage.
Since it notifies (by mail) someone of each successful penetration
and leaves a trapdoor (the FIELD account), just killing the bug is
not adequate. You must go in an make sure all accounts have
passwords and that the passwords are not the same as the account
name.
R. Kevin Oberman
________________________________________________________________________
Advisory Notice
A worm is attacking NASA's SPAN network via
Vax/VMS systems connected to DECnet. It is unclear if the spread of the
worm has been checked. It may spread to other systems such as DOE's
HEPNET within a few days. VMS system managers should prepare now. The
worm targets VMS machines, and can only be propagated via DECnet. The
worm exploits two features of DECnet/VMS in order to propagate itself.
The first is the default DECnet account, which is a facility for users
who don't have a specific login ID for a machine to have some degree of
anonymous access. It uses the default DECnet account to copy itself to a
machine, and then uses the "TASK 0" feature of DECnet to invoke the
remote copy. It has several other features including a brute force
attack.
Once the worm has successfully penetrated your system it will infect
.COM files and create new security vulnerabilities. It then seems to
broadcast these vulnerabilities to the outside world. It may also
damage files as well, either unintentionally or otherwise.
An analysis of the worm appears below and is provided by R. Kevin Oberman of
Lawrence Livermore National Laboratory. Included with the analysis is a
DCL program that will block the current version of the worm. At least
two versions of this worm exist and more may be created. This program
should give you enough time to close up obvious security holes. A
more thorough DCL program is being written.
If your site could be affected please call CIAC for more details...
Report on the W.COM worm.
R. Kevin Oberman
Engineering Department
Lawrence Livermore National Laboratory
October 16, 1989
The following describes the action of the W.COM worm (currently based on the
examination of the first two incarnations). The replication technique causes
the code to be modified slightly which indicates the source of the attack and
learned information.
All analyis was done with more haste than I care for, but I believe I have all
of the basic facts correct.
First a description of the program:
1. The progam assures that it is working in a directory to which the owner
(itself) has full access (Read, Write,Execute, and Delete).
2. The program checks to see if another copy is still running. It looks for a
process with the first 5 characters of "NETW_". If such is found, it deletes
itself (the file) and stops its process.
NOTE
A quick check for infection is to look for a process name starting with
"NETW_". This may be done with a SHOW PROCESS command.
3. The program then changes the default DECNET account password to a random
string of at least 12 characters.
4. Information on the password used to access the system is mailed to the user
GEMTOP on SPAN node 6.59. Some versions may have a different address.
5. The process changes its name to "NETW_" followed by a random number.
6. It then checks to see if it has SYSNAM priv. If so, it defines the system
announcement message to be the banner in the program:
W O R M S A G A I N S T N U C L E A R K I L L E R S
_______________________________________________________________
\__ ____________ _____ ________ ____ ____ __ _____/
\ \ \ /\ / / / /\ \ | \ \ | | | | / / /
\ \ \ / \ / / / /__\ \ | |\ \ | | | |/ / /
\ \ \/ /\ \/ / / ______ \ | | \ \| | | |\ \ /
\_\ /__\ /____/ /______\ \____| |__\ | |____| |_\ \_/
\___________________________________________________/
\ /
\ Your System Has Been Officically WANKed /
\_____________________________________________/
You talk of times of peace for all, and then prepare for war.
7. If it has SYSPRV, it disables mail to the SYSTEM account.
8. If it has SYSPRV, it modifies the system login command procedure to
APPEAR to delete all of a user's file. (It really does nothing.)
9. The program then scans the account's logical name table for command
procedures and tries to modify the FIELD account to a known password
with login form any source and all privs. This is a primitive virus,
but very effective IF it should get into a privileged account.
10. It proceeds to attempt to access other systems by picking node numbers at
random. It then used PHONE to get a list of active users on the remote system.
It proceeds to irritate them by using PHONE to ring them.
11. The program then tries to access the RIGHTSLIST file and attempts
to access some remote system using the users found and a list of
"standard" users included withing the worm. It looks for passwords
which are the same as that of the account or are blank. It records all
such accounts.
12. It looks for an account that has access to SYSUAF.DAT.
13. If a priv. account is found, the program is copied to that account and
started. If no priv account was found, it is copied to other accounts found on
the random system.
14. As soon as it finishes with a system, it picks another random system and
repeats (forever).
Response:
1. The following program will block the worm. Extract the following code
and execute it. It will use minimal resources. It create a process named
NETW_BLOCK which will prevent the worm from running.
-------
Editors note: This fix will work only with this version of the worm.
Mutated worms will require modification of this code; however, this
program should prevent the worm from running long enough to secure
your system from the worms attacks.
-------
==============================================================================
$ Set Default SYS$MANAGER
$ Create BLOCK_WORM.COM
$ DECK/DOLLAR=END_BLOCK
$LOOP:
$ Set Process/Name=NETW_BLOCK
$ Wait 12:0
$ GoTo loop
END_BLOCK
$ Run/Input=SYS$MANAGER:BLOCK_WORM.COM/Error=NL:/Output=NL:/UIC=[1,4] -
SYS$SYSTEM:LOGINOUT
==============================================================================
2. Enable security auditing. The following command turns on the MINIMUM
alarms. The log is very useful in detecting the effects of the virus left by
the worm. It will catch the viruses modification of the UAF.
$ Set Audit/Alarm/Enable=(ACL,Authorization,Breakin=All,Logfailure=All)
3. Check for any account with NETWORK access available for blank passwords or
passwords that are the same as the username. Change them!
4. If you are running VMS V5.x, get a copy of SYS$UPDATE:NETCONFIG_UPDATE.COM
from any V5.2 system and run it. If you are running V4.x, change the username
and password for the network object "FAL".
5. If you have been infected, it will be VERY obvious. Start checking the
system for modifications to the FIELD account. Also, start scanning the system
for the virus. Any file modified will contain the following line:
$ oldsyso=f$trnlnm("SYS$OUTPUT")
It may be in LOTS of command procedures. Until all copies of the virus are
eleiminated, the FIELD account may be changed again.
6. Once you are sure all of the holes are plugged, you might kill off
NETW_BLOCK. (And then again, maybe not.)
Conclusion:
This is a mean bug to kill and could have done a lot of damage. Since it
notifies (by mail) someone of each successful penetration and leaves a trap
door (the FIELD account), just killing the bug is not adequate. You must go in
an make sure all accounts have passwords and that the passwords are not the
same as the account name.
R. Kevin Oberman
Lawrence Livermore National Laboratory
Internet: oberman@icdc.llnl.gov
(415) 422-6955
________________________________________________________________________
If you have any questions please contact either of the following CIAC team
members:
Dave Brown, (415) 423-9878 or FTS 543-9878
or
Gene Schultz, (415) 422-8193 or FTS 532-8193
or send electronic mail to:
ciac@tiger.llnl.gov
CIAC FAX: (415) 423-0913 FTS 543-0913
For Official Department of Energy Use Only
_______________________________________________________________________
THE COMPUTER INCIDENT ADVISORY CAPABILITY (CIAC) ADVISORY NOTICE
_______________________________________________________________________
Tools available to check the spread of the "WANK" Worm
October 20, 1989 1130 PST Number A-3
Summary
This is a follow-up bulletin to the CIAC advisory notice A-2 dated
October 16, 1989, stating that the "WANK" worm is attacking HEPnet and
the NASA SPAN network on VAX/VMS systems connected via DECnet. Our
latest information is that approximately 60 to 70 systems, mostly at
non-DOE sites, have been infected. The rate at which this worm is
spreading seems to be slowing, although more detailed information about
the spread of this worm is not currently available.
CIAC now has additional information about the "WANK" computer worm
outbreak. The worm targets VMS machines, and can only be propagated
via DECnet. The worm exploits well known security holes within the
DECnet/VMS system in order to propagate itself. However, most DOE
sites have not yet been affected. In order to help prevent your site
>from becoming infected, we recommend that you follow procedures
described in this bulletin , and use a tool to check your VAX/VMS
systems for the same weaknesses the worm exploits. We also are
providing you with a list of the worm symptoms, as well as a tool to
kill the worm if your systems become infected.
If your site is infected, or if you have any questions, please contact
CIAC. CIAC phone numbers and addresses appear at the end of this
notice.
Advisory Notice
A computer worm written in DCL for DEC-VMS has been attacking the
HEPnet and the NASA SPAN networks. This worm can only be propagated
via DECnet. The primary methods of attack include a brute force attack
on passwords as well as exploiting well known security vulnerabilities
of DECnet/VMS. One vulnerability is the default DECnet account, which
is a facility for users who do not have a specific login ID for a
machine and want some degree of anonymous access. It uses the default
DECnet account to copy itself to a machine, and then uses the "TASK 0"
and Submit/Remote features of DECnet to invoke the remote copy. Once
the worm has successfully penetrated a system, it will infect .COM
files and create new security vulnerabilities. It then broadcasts
these vulnerabilities to another machine. It may also damage files or
crash systems.
In our last memo we published an analysis of the worm by Kevin
Oberman. That analysis contained a error that we would like to
correct. In that notice we printed the quote:
4. Information on the password used to access the system is mailed to
the user GEMTOP on SPAN node 6.59. Some versions may have a different
address.
The actual user is "GEMPAK" not "GEMTOP".
Visible Symptoms
The following information is an extract from a report by John McMahon
on detecting the symptoms of the WANK worm. This information was
compiled after a thorough analysis of copies of various versions of
the WANK worm retrieved from different infected sites. There are
indications that these copies were derived from three different
"starter" versions of the worm. The worm is self-modifying, and may
also have been manually modified by others. There may also be other
currently undetected versions of the worm with additional
capabilities.
Specifically, some or all of the following symptoms have been noted on
infected systems:
1) Account passwords have been changed without the knowledge of the
user, or the system manager.
2) Processes are running on your system with the process name NETW_nnnn
(where nnnn is a random number). Check this with the SHOW SYSTEM
command.
3) Command procedures/data file names starting with one or two letters
and up to a five digit number appear in the SYS$LOGIN: directory of an
account. Examples: C12345.COM, A7007.DAT.
Note: Earlier reports that the file W.COM is created by the worm
appear to be in error. Any "anti-worm" procedure involving the
creation of a blank W.COM;32767 will NOT stop the worm.
4) The SYS$ANNOUNCE message, prior to the USERNAME: login prompt, has
been
redefined to the following WANK logo.
W O R M S A G A I N S T N U C L E A R K I L L E R S
_______________________________________________________________
\__ ____________ _____ ________ ____ ____ __ _____/
\ \ \ /\ / / / /\ \ | \ \ | | | | / / /
\ \ \ / \ / / / /__\ \ | |\ \ | | | |/ / /
\ \ \/ /\ \/ / / ______ \ | | \ \| | | |\ \ /
\_\ /__\ /____/ /______\ \____| |__\ | |____| |_\ \_/
\___________________________________________________/
\ /
\ Your System Has Been Officically WANKed /
\_____________________________________________/
You talk of times of peace for all, and then prepare for war.
5) The SYSTEM account can no longer receive mail. The DISMAIL flag has
been set in SYSTEM's UAF record.
6) Users log into the system and report that all of their files have
been deleted while logging in. The user observes many %DELETE-I-FILDEL
messages ,and DIRECTORY reports that no files are found. The system
manager follows up on this report and finds the files are still there,
and that the system login procedure (SYLOGIN, SYS$SYLOGIN) has been
modified.
Note: Earlier reports that the worm performs mass deletion of files
appears to be in error.
7) Command procedures have been modified with code to reactivate the
FIELD account if the person running the procedure has SYSPRV.
8) A remote DECnet site contacts you about odd VAXPhone call messages
coming from your node. The VAXPhone ring messages do not contain a
userid, but a strange "fortune cookie" saying.
Note: the node id can be found in the NETSERVER.LOG files in your
DECnet default account. [CIAC note]: Please note the node number of
the system that sent you the message and pass that information to your
respective network security manager, or CIAC so that the infected node
can be informed.
9) Top-level directories have had their OWNER protection field changed
to O:RWED.
10) A remote DECnet site contacts you about logfails (on several
accounts) on the remote site which were traced back to an account on
your machine. Similarly, a remote site contacts you because a local
account tried to read the SYSUAF/RIGHTSLIST files on the remote node.
Regardless of whether or not you think you have been infected,
download the ANTIWANK.COM command procedure and start it running on
your node immediately. This program will kill copies of the worm that
are running on your node.
You may see the whole list of symptoms and recommended fixes by
obtaining the file WORM-INFO.COM. See details below.
Procedures to stop the spread of this worm
CIAC recommends that you use the following procedures, quoted from a
message by Ron Tencati (SPAN Security Manager), to stop the spread of
the WANK worm:
1) It is IMPERATIVE that all systems protect or remove the DECnet TASK
0 object to prevent reoccurrence of this worm, OR MORE SERIOUS ATTACKS
OF THIS KIND IN THE FUTURE!
The TASK object can be secured by either of the following methods:
Method 1)
Issue the command:
NCP> CLEAR OBJECT TASK ALL
after the network is started up. This command can also be
inserted into the procedure SYSTARTUP>COM (SYSTARTUP_V5.COM on
V5.x systems) after the call to STARTNET.COM. In addition
which the system is running, this command must be executed EACH
TIME the network is restarted.
Method 2:
Issue the following commands ONCE:
NCP> SET OBJECT TASK USER DECNET PASSWORD
NCP> DEFINE OBJECT TASK USER DECNET PASSWORD
This causes a login failure to be generated whenever the TASK
object is accessed. Once done, this change will be permanent.
NOTE We have received one report that TASK 0 is
required for DECwindows. Read your documentation!
2) Under NO circumstances it is acceptable for an account to have a
password the same as the username. Passwords (passPHRASES) should be
created so that they are difficult to guess, multi- word phrases are
preferable. As a precaution, we recommend that all passwords be
changed. Additionally, system managers may choose to revalidate ALL
accounts.
If a system had the DECNET TASK 0 protected as above, the DECNET
account protected against SUBMIT/REMOTE (described below) and no user
had their userid as their password, it was immune to this WORM. As a
result, the number of nodes actually INFECTED by this attack is
relatively small. The number ATTACKED however, is large.
3. NETWORK ATTACKS
To protect against the SUBMIT/REMOTE attack, run AUTHORIZE and make
sure that all network account flags are set to NOBATCH, NODIALUP,
NOLOCAL, and NOREMOTE.
4. FIELD ACCOUNT
Make sure the FIELD ACCOUNT does not have the password FIELD. DISUSER
the account. You must SEARCH all .COM files for a
"field/remote/dialup." If the search shows it is in .COM files, They
have a trojan horse appended to the files. When the .COM file is
executed, This Trojan horse will try to reset account FIELD to
/NODISUSER and password to FIELD. You should either delete the
corrupted .COM file and obtain a good one elsewhere, or examine the
file and remove the affected lines of the command procedure.
5. WORM FILES
The WORM source files are W.COM or a single alphabetic character (C or
D) followed by 4 or 5 numeric characters. (Cnnnnn.COM), ("nnnn"
represents a random number). The WORM will start a process or
processes running. These processes are named in format NETW_nnnn, and
should be deleted. PHONE_nnnn may also be running as the WORM utilizes
the PHONE object in an attempt to send a message to a user on another
randomly selected node.
6. ALARMS
Some alarms generated by the WORM are related to PHONE.EXE and
FAL.EXE. The majority of the alarms are login failures as the WORM
attempts to log into specific accounts.
We recommend that alarms be set immediately for logins, logouts,
breakin attempts, modifications to the system and net UAF's, and to
changes to user and system passwords.
Tools available
A series of tools are available to control the WANK worm. These may be
obtained by anonymous FTP access from node ROGUE.LLNL.GOV
(128.115.2.99). They may also be obtained from SPAN and ESnet. Contact
CIAC for more information.
[.SECURITY]CHECK_SYSTEM.COM, written by Kevin Oberman, will check your
entire system for the security holes used by the WANK worm. It then
reports back all system problems so that they can be corrected.
DEC has provided a fix for the well known problem with the default
DECnet account hole called SYS$UPDATE:NETCONFIG_UPDATE.COM for VMS
V5.2. It is available from the VMS V5.2 distribution tape. If you
have this, CIAC recommends that you run it now. If you donUt have
access or are running an earlier system such as V4., you may obtain
>from ROGUE.LLNL.GOV a program called: FIX-FAL.COM which fixes the
default DECnet account.
The program by John McMahon can be obtained by downloading
ANTIWANK.COM. This program kills the worm processes. You can also run
it as a vaccine even if your systems have not been infected.
WORM-INFO.TXT contains an important report by John McMahon . It
contains a list of symptoms, recommended proceduresand the code for
ANTIWANK.COM.
If your site has been infected, or if you have any questions, please
contact either of the following CIAC team members:
David Brown, (415) 423-9878 or FTS 543-9878
Gene Schultz, (415) 422-8193 or FTS 532-8193
or send electronic mail to:ciac@tiger.llnl.gov
CIAC FAX: (415) 422-4294 FTS 532-4294
________________________________________________________________
THE COMPUTER INCIDENT ADVISORY CAPABILITY
CIAC
ADVISORY NOTICE
________________________________________________________________
Information about a new version of the "WANK" worm
October 30, 1989, 1615 PST
Number A-4
This is a follow-up bulletin to CIAC advisory notices A-2 dated
October 16, 1989 and notice A-3 dated October 20, 1989. These
notices informed you about the "WANK" worm attacking HEPnet and
the NASA SPAN network. The previous notices contained
information on obtaining tools to combat this worm. The purpose
of this notice is to inform you about a new version of this worm
which has already attacked over 60 sites.
The "WANK" worm is still attacking VAX/VMS systems connected
via DECnet. The worm, however, has been modified somewhat. The
method of attack is the same, except that this version calls its
process OILZ_nnnn (where nnnn equals a random number string),
instead of NETW_nnnn. Preliminary information indicates that
this modified version of the worm changes passwords of any
account into which it successfully enters, regardless of whether
those accounts are privileged accounts.
The tools described in CIAC advisory notice A-3 are effective
against both the original "WANK" version and the new "OILZ"
version of the worm. These tools may still be obtained by
anonymous FTP access from node ROGUE.LLNL.GOV (128.115.2.99), or
from SPAN and ESnet. In addition, CIAC again recommends sound
password management to counter this new threat.
If your site has been infected, if you observe unusual activity,
or if you have any questions, please contact either of the
following CIAC team members:
David Brown, (415) 423-9878 or FTS 543-9878
or
Gene Schultz, (415) 422-8193 or FTS 532-8193
or send electronic mail to:ciac@tiger.llnl.gov
CIAC FAX: (415) 422-4294 FTS 532-4294
This notice has been sent to the following persons
Alexander, D. (LANL)
Allender, C. (Stone & Webster)
Baker, A. (LANL CCS)
Baker, D. (Richland Operations)
Banda, M. (UC Medical Center)
Barcysk, J. (Pinellas Area Office)
Barnes, D. (Princeton Plasma Physics)
Beck, C. (Argonne West)
Berg, T. (SAN)
Best, M.D. (Holmes & Narver)
Breault, L. (DP-34)
Brooks, S. (Boeing Petroleum)
Brown, R. (EG&G Idaho)
Bryan, F. (Naval Petroleum Reserve)
Burkmar, W. (Computer Data Systems)
Byrd, C. (Kansas City Area Office)
Clouse, B. (Chicago Operations)
Cole, C. (LLNL)
Combs, T. (Allied-Signal)
Cox, T. (Stanford Synchrotron)
Craig, J. (Morgantown Energy)
Cyganowski, W. (SAN)
D'Andrea, R. (Grand Junction)
Delmastro, A. (Pittsburgh Energy)
Diel, J. (Inhalation Toxology Research)
Dolven, L. (Rockwell INEL)
Downing, D. (SLAC)
Duncan, R. (Computer Data Systems)
Eckerson, F. (Nevada Operations)
Edmundson, C. (KMS Fusion)
Elder, R. (Bettis)
Endler, R. (Savannah River Operations)
Faux-Burhans, D. (DP-34)
Favaron, P. (Neutron Devices)
Ference, J. (West Valley Nuclear Services)
Ferguson, C. (Alaska Power Admin.)
Fish, J. (Hanford Env't Health)
Fluckinger, J.D. (PNL)
Folkendt, S. (Sandia-Livermore)
Fraser, G. (Rocky Flats)
Fulton, J. (Westinghouse Ohio)
Furner, K. (Kaiser Hanford)
Gault, J. E. (Reynolds Electric)
Glock, T. (Pittsburgh Naval Reactors)
Gurth, R. (Westinghouse Hanford)
Haldy, J. (Pittsburgh Naval Reactors)
Hann, H. (Idaho Operations)
Hardwick, R. (SAIC)
Hercamp, A. (Bonneville Power)
Herhold, J. (EG&G Nevada)
Hileman, M. (EG&G Nevada)
Hodder, N. (GA Technologies)
Johnston, B. (PNL)
Jones, D. C. (Sandia-Albuquerque)
Jones, L. (Bonneville Power)
Kauffman, S. (Naval Reactors)
Kessler, H. R. (Albuquerque Operations)
Kilcrease, L. (MSE)
Klafke, J. (Albuquerque Operations)
Kramer, J. (Chicago Operations)
Kramer, K. (Chicago Operations)
Madden, T. (Savannah River Operations)
Marsden, L. (Westinghouse Idaho)
McGrath, J. (KMS Fusion)
Meadows, B. (SRP)
Munyon, W. (Energy Technology Eng.)
Neal, B. (Southeastern Power)
Nicolayeff, N. (Idaho Operations)
Niziol, E. (Oak Ridge Operations)
O'Doherty, R. (Solar Energy Research)
Oldis. P. (CSC)
Orton, J. (Westinghouse Hanford)
Parish, S. (Wackenhut)
Penny, S. K. (ORNL)
Pfister, J. (Fermi)
Phillips, R. E. (Albuquerque Operations)
Pielich, G. (Nuclear Fuel Services)
Pohlig, P. (BNL)
Provencher, D. (Schenectady)
Przysucha, J. (MA-24)
Purnell, R. (Southwestern Power)
Richards, J. (Computer Data Systems)
Rosenbloom, H. (LANL CCS)
Runge, L. (BNL)
Sanchez, A. (Stretegic Petroleum Reserves)
Scharping, R. (Argonne)
Schumann, M. (Rocky Flats Area Office)
Shepherd, J. (DP-34)
Shoop, D. (MSE)
Sibert, P. (MA-24)
Simms, G. S. (Pantex)
Smith, B. (Boeing Petroleum)
Sohnholz, R. (WAPA)
Sorter, B. (EG&G Idaho)
Stahl, T. (Computer Data Systems)
Stevens, D. (LBL)
Stollings, C. (Martin Marietta)
Strazisar, A. (Pittsburgh Energy)
Surface, R. (Albuquerque Operations)
Terrell, R. (OSTI)
Teska, R. G. (Kansas City Area Office)
Tilton, L. (Dayton Area Office)
Troyer, J. (Argonne)
Warmoth, E. (EG&G Mound)
Watson, B. (Oak Ridge Operations)
Whyte, J. (Wackenhut)
Wilson, W. (Sandia-Livermore)
Zeilman, T. (Holmes & Narver)
Zuyus, P. (Naval Petroleum Reserves)
________________________________________________________________
THE COMPUTER INCIDENT ADVISORY CAPABILITY
CIAC
ADVISORY NOTICE
________________________________________________________________
Information about a new vulnerability in the SUN rcp utility
November 1, 1989, 1615 PST
Number A-5
CIAC has learned of a new vulnerability in the SunOS 4.0.x rcp
utility (Sun Bug Report number 1017314). This is a different
vulnerability from the rcp vulnerability described in the CIAC
bulletin of August 21, 1989.
This new vulnerability can be exploited by any other trusted host
listed in /etc/hosts.equiv or /.rhosts. This hole can be ex-
ploited by anyone running NFS (Network File System), and in par-
ticular by someone who is using a PC to run PC/NFS. This new rcp
hole affects only SunOS 4.0.x systems; 3.5 systems are not
affected.
Sun Microsystems will distrubute a patch for this vulnerability
when version SunOS 4.1 is released. In the meantime, CIAC recom-
mends that you use the following workaround:
Change the 'nobody'/etc/passwd file entry from
nobody:*:-2:-2::/:
to
nobody:*:65534:65534:Mismatched NFS ID's:/:
If you have already used another workaround for this vulnerability,
please be advised that other workarounds may cause unexpected sys-
tem behavior. Several incorrect workarounds have already been dis-
tributed by organizations outside of DOE.
If you need further information about this problem, please contact:
Ana Maria De Alvare', (415) 422-7007 or FTS 532-7007
or
(415) 422-8193 or FTS 532-8193
or send electronic mail to: ciac@tiger.llnl.gov
CIAC FAX: (415) 422-4294 or FTS 532-4294
P.S.--CIAC also advises that if you run SunOS 4.0.3, you should re-
move the + in the /etc/hosts.equiv file unless you are running YP.
(This information is not related to any rcp vulnerability.)
This notice has been sent to the following persons:
Alexander, D. (LANL)
Allender, C. (Stone & Webster)
Baker, A. (LANL CCS)
Baker, D. (Richland Operations)
Banda, M. (UC Medical Center)
Barcysk, J. (Pinellas Area Office)
Barnes, D. (Princeton Plasma Physics)
Beck, C. (Argonne West)
Berg, T. (SAN)
Best, M.D. (Holmes & Narver)
Breault, L. (DP-34)
Brooks, S. (Boeing Petroleum)
Brown, R. (EG&G Idaho)
Bryan, F. (Naval Petroleum Reserve)
Burkmar, W. (Computer Data Systems)
Byrd, C. (Kansas City Area Office)
Clouse, B. (Chicago Operations)
Cole, C. (LLNL)
Combs, T. (Allied-Signal)
Cox, T. (Stanford Synchrotron)
Craig, J. (Morgantown Energy)
Cyganowski, W. (SAN)
D'Andrea, R. (Grand Junction)
Delmastro, A. (Pittsburgh Energy)
Diel, J. (Inhalation Toxology Research)
Dolven, L. (Rockwell INEL)
Downing, D. (SLAC)
Duncan, R. (Computer Data Systems)
Eckerson, F. (Nevada Operations)
Edmundson, C. (KMS Fusion)
Elder, R. (Bettis)
Endler, R. (Savannah River Operations)
Faux-Burhans, D. (DP-34)
Favaron, P. (Neutron Devices)
Ference, J. (West Valley Nuclear Services)
Ferguson, C. (Alaska Power Admin.)
Fish, J. (Hanford Env't Health)
Fluckinger, J.D. (PNL)
Folkendt, S. (Sandia-Livermore)
Fraser, G. (Rocky Flats)
Furner, K. (Kaiser Hanford)
Gault, J. E. (Reynolds Electric)
Gibson, J. (Westinghouse Ohio)
Glock, T. (Pittsburgh Naval Reactors)
Gurth, R. (Westinghouse Hanford)
Haldy, J. (Pittsburgh Naval Reactors)
Hann, H. (Idaho Operations)
Hardwick, R. (SAIC)
Hercamp, A. (Bonneville Power)
Herhold, J. (EG&G Nevada)
Hileman, M. (EG&G Nevada)
Hodder, N. (GA Technologies)
Johnston, B. (PNL)
Jones, D. C. (Sandia-Albuquerque)
Jones, L. (Bonneville Power)
Kauffman, S. (Naval Reactors)
Kessler, H. R. (Albuquerque Operations)
Kilcrease, L. (MSE)
Klafke, J. (Albuquerque Operations)
Kramer, J. (Chicago Operations)
Kramer, K. (Chicago Operations)
Madden, T. (Savannah River Operations)
Marsden, L. (Westinghouse Idaho)
McGrath, J. (KMS Fusion)
Meadows, B. (SRP)
Munyon, W. (Energy Technology Eng.)
Neal, B. (Southeastern Power)
Nicolayeff, N. (Idaho Operations)
Niziol, E. (Oak Ridge Operations)
O'Doherty, R. (Solar Energy Research)
Oldis. P. (CSC)
Orton, J. (Westinghouse Hanford)
Parish, S. (Wackenhut)
Penny, S. K. (ORNL)
Pfister, J. (Fermi)
Phillips, R. E. (Albuquerque Operations)
Pielich, G. (Nuclear Fuel Services)
Pohlig, P. (BNL)
Provencher, D. (Schenectady)
Przysucha, J. (MA-24)
Purnell, R. (Southwestern Power)
Richards, J. (Computer Data Systems)
Rosenbloom, H. (LANL CCS)
Runge, L. (BNL)
Sanchez, A. (Stretegic Petroleum Reserves)
Scharping, R. (Argonne)
Schumann, M. (Rocky Flats Area Office)
Shepherd, J. (DP-34)
Shoop, D. (MSE)
Sibert, P. (MA-24)
Simms, G. S. (Pantex)
Smith, B. (Boeing Petroleum)
Sohnholz, R. (WAPA)
Sorter, B. (EG&G Idaho)
Stahl, T. (Computer Data Systems)
Stevens, D. (LBL)
Stollings, C. (Martin Marietta)
Strazisar, A. (Pittsburgh Energy)
Surface, R. (Albuquerque Operations)
Terrell, R. (OSTI)
Teska, R. G. (Kansas City Area Office)
Tilton, L. (Dayton Area Office)
Troyer, J. (Argonne)
Warmoth, E. (EG&G Mound)
Watson, B. (Oak Ridge Operations)
Whyte, J. (Wackenhut)
Wilson, W. (Sandia-Livermore)
Zeilman, T. (Holmes & Narver)
Zuyus, P. (Naval Petroleum Reserves)
________________________________________________________________________
THE COMPUTER INCIDENT ADVISORY CAPABILITY
CIAC
INFORMATION BULLETIN
________________________________________________________________________
Information about a trojan horse in Norton Utilities for IBM
PCs and clones
November 7, 1989, 1730 PST Number A-6
CIAC has been informed that a trojan horse has been found in a number
of IBM PCs and PC clones which run Norton Computing utilities. This
trojan horse appears superficially to be a legitimate file within
Norton Utilities named either NORTSTOP.ZIP or NORTSHOT.ZIP. (The file
contents are the same, regardless of the name used.) The trojan horse
program must be run (i.e., the EXE file for the program must be
executed) for any damage to occur to your system. If run, the program
lists the directory and displays a message that one's machine is free
of viruses. Damage resulting from running this program occurs only if
the trojan horse program is executed between December 24 and December
31 inclusive. In this case, the program will erase files with
selected file extensions.
Detection
You can detect this trojan horse by using Norton Utilities to examine
the .EXE file for either of the.ZIP files listed above. The EXE file
will contain the following message:
The Norton Public Domain Virus Utility, PD Edition 5.50, (C) 1989
Peter Norton
Your System has been infected with a Christmas virus! Selected
files were just eliminated! Without these files, you might as well
use your computer as a damn, boat anchor! If you do NOT own a
boat, you may want to replace the files which were just erased.
Try to determine which files they were. HARDY HA! HA! HA! HOW
DO YOU FEEL NOW; YOU IDIOT? MERRY CHRISTMAS AND HAPPY NEW YEAR!
If your system has the trojan horse, you will obtain a report similar
to the following when using PKUNZIP (a utility which separates and
decompresses files):
1065 Implode 650 39% 10-04-89 12:26 9778978d --w READ-ME.NOW
38907 Implode 30156 23% 10-02-89 11:57 c333dec0 --w NORTSHOT.EXE
----- ------ ----- ---------------
39972 30806 23% 2
Eradication
If you should discover this trojan horse, do not execute the file
NORTSHOT.EXE. Please make a copy of the bogus .EXE and .ZIP files on
a diskette before you do anything else. Eradicating the NORTSTOP.ZIP
and NORTSHOT.ZIP trojan horse is straightforward; simply use your disk
operating system to delete all files named NORTSHOT.EXE and the .ZIP
file that created it. Please then send the diskette to CIAC at the
address below as soon as possible.
Note
According to information provided to CIAC, this trojan horse is not
found in the version of Norton Utilities sold in commercial software
outlets. It is only found in versions of Norton Utilities available
from public sources (e.g., bulletin boards).
NORTSTOP.ZIP and NORTSHOT.ZIP are not viruses. They will not
replicate themselves and spread from machine to machine. Once you have
removed this trojan horse, it can only be reintroduced by copying the
files once again from public sources.
To send copies of the trojan horse, or to obtain further information
about this problem, please contact:
Tom Longstaff, CIAC
Lawrence Livermore National Laboratory
P.O. Box 808, L-540
Livermore, CA 94550
(415) 423-4416 or FTS 543-4416
Send electronic mail to: ciac@tiger.llnl.gov
CIAC FAX: (415) 422-4294 FTS 532-4294
NOTE: CIAC Bulletin A-7 is classified. CIAC Bulletin A-8 is a
sanitized version of A-7. A-8 is included here for
completeness.
================================================================================
________________________________________________________________________
THE COMPUTER INCIDENT ADVISORY CAPABILITY
CIAC
INFORMATION BULLETIN
________________________________________________________________________
Information about a UNICOS Problem
November 29, 1989, 1630 PST Number A-8
CIAC has been informed of a system bug in the UNICOS operating system which
runs on CRAY computers. This bug involves the possibility of losing control
over the separation of users and need-to-know. For further information,
please contact your Computer Security Operations Manager (CSOM). A notice
describing this problem in greater detail was sent to your CSOM on
November 28, 1989.
Ana Maria De Alvare', CIAC
Lawrence Livermore National Laboratory
P.O. Box 808, L-619
Livermore, CA 94550
(415) 422-7007 or FTS 532-7007
Send electronic mail to: ciac@tiger.llnl.gov
CIAC FAX: (415) 423-0913 FTS 543-0913
DISTRIBUTION
Alexander, D. (LANL) Kessler, H.R. (Albuquerque Operations)
Anderson, A. (SAN) Kramer, K. (Chicago Operations)
Baker, A. (LANL CCS) Madden, T. (SRO)
Baker, D. (Richland Operations) Marcum, R. (ORNL)
Berg, T. (SAN) Marsden, L. (Westinghouse Idaho)
Breault, L. (DP-34) Meadows, B. (SRP)
Brown, R. (EG&G Idaho) Miles, D. (EG&G Idaho)
Clouse, B. (Chicago Operations) Nicolayeff, N. (Idaho Operations)
Cole, C. (LLNL) Niziol, E. (Oak Ridge Operations)
Cyganowski, W. (SAN) Orton, J. (Westinghouse Hanford)
Dolven, L. (Rockwell INEL) Phillips, R.E. (Albuquerque Operations)
Elder, R. (Bettis) Provencher, D. (Schenectady)
Endler, R. (SRO) Przysucha, J. (MA-24)
Faux-Berhans (DP-34) Rosenbloom, H. (LANL CCS)
Fish, J. (Hanford Env't Health) Scharping, R. (Argonne)
Fluckinger, J.D. (PNL) Shepherd, J. (DP-34)
Folkendt, S. (Sandia-Livermore) Sibert, P. (MA-204)
Glock, T. (Pittsburgh Naval Reactors) Sorter, B. (EG&G Idaho)
Gurth, R. (Westinghouse Hanford) Staley, J. (MA-205.5)
Haldy, J. (Pittsburgh Naval Reactors) Surface, R. (Albuquerque Operations)
Hann, H. (Idaho Operations) Troyer, J. (Argonne)
Johnston, B. (PNL) Watson, W. (Oak Ridge Operations)
Jones, D.C. (Sandia-Albuquerque) Wilson, W. (Sandia-Livermore)
CIAC BULLETINS ISSUED
SUN 386i authentication bypass vulnerability
nVIR virus alert
/dev/mem vulnerability
tftp/rwalld vulnerability
"Little Black Box" (Jerusalem) virus alert
restore/dump vulnerability
rcp/rdist vulnerability
Internet trojan horse alert
Columbus Day (DataCrime) virus alert
Columbus Day (DataCrime) virus alert (follow-up notice)
Internet hacker alert (notice A-1)
HEPnet/SPAN network worm alert (notice A-2)
HEPnet/SPAN network worm alert (notice A-3)
HEPnet/SPAN network worm alert (notice A-4)
rcp vulnerability (second vulnerability, notice A-5)
Trojan horse in Norton utilities (notice A-6)
UNICOS vulnerability (classified, notice A-7)
UNICOS problem (notice A-8)
________________________________________________________________________
THE COMPUTER INCIDENT ADVISORY CAPABILITY
CIAC
INFORMATION BULLETIN
________________________________________________________________________
Information about a UNICOS Problem
November 29, 1989, 1630 PST Number A-8
CIAC has been informed of a system bug in the UNICOS operating system which
runs on CRAY computers. This bug involves the possibility of losing control
over the separation of users and need-to-know. For further information,
please contact your Computer Security Operations Manager (CSOM). A notice
describing this problem in greater detail was sent to your CSOM on
November 28, 1989.
Ana Maria De Alvare', CIAC
Lawrence Livermore National Laboratory
P.O. Box 808, L-619
Livermore, CA 94550
(415) 422-7007 or FTS 532-7007
Send electronic mail to: ciac@tiger.llnl.gov
CIAC FAX: (415) 423-0913 FTS 543-0913
DISTRIBUTION
Alexander, D. (LANL) Kessler, H.R. (Albuquerque Operations)
Anderson, A. (SAN) Kramer, K. (Chicago Operations)
Baker, A. (LANL CCS) Madden, T. (SRO)
Baker, D. (Richland Operations) Marcum, R. (ORNL)
Berg, T. (SAN) Marsden, L. (Westinghouse Idaho)
Breault, L. (DP-34) Meadows, B. (SRP)
Brown, R. (EG&G Idaho) Miles, D. (EG&G Idaho)
Clouse, B. (Chicago Operations) Nicolayeff, N. (Idaho Operations)
Cole, C. (LLNL) Niziol, E. (Oak Ridge Operations)
Cyganowski, W. (SAN) Orton, J. (Westinghouse Hanford)
Dolven, L. (Rockwell INEL) Phillips, R.E. (Albuquerque Operations)
Elder, R. (Bettis) Provencher, D. (Schenectady)
Endler, R. (SRO) Przysucha, J. (MA-24)
Faux-Berhans (DP-34) Rosenbloom, H. (LANL CCS)
Fish, J. (Hanford Env't Health) Scharping, R. (Argonne)
Fluckinger, J.D. (PNL) Shepherd, J. (DP-34)
Folkendt, S. (Sandia-Livermore) Sibert, P. (MA-204)
Glock, T. (Pittsburgh Naval Reactors) Sorter, B. (EG&G Idaho)
Gurth, R. (Westinghouse Hanford) Staley, J. (MA-205.5)
Haldy, J. (Pittsburgh Naval Reactors) Surface, R. (Albuquerque Operations)
Hann, H. (Idaho Operations) Troyer, J. (Argonne)
Johnston, B. (PNL) Watson, W. (Oak Ridge Operations)
Jones, D.C. (Sandia-Albuquerque) Wilson, W. (Sandia-Livermore)
CIAC BULLETINS ISSUED
SUN 386i authentication bypass vulnerability
nVIR virus alert
/dev/mem vulnerability
tftp/rwalld vulnerability
"Little Black Box" (Jerusalem) virus alert
restore/dump vulnerability
rcp/rdist vulnerability
Internet trojan horse alert
Columbus Day (DataCrime) virus alert
Columbus Day (DataCrime) virus alert (follow-up notice)
Internet hacker alert (notice A-1)
HEPnet/SPAN network worm alert (notice A-2)
HEPnet/SPAN network worm alert (notice A-3)
HEPnet/SPAN network worm alert (notice A-4)
rcp vulnerability (second vulnerability, notice A-5)
Trojan horse in Norton utilities (notice A-6)
UNICOS vulnerability (classified, notice A-7)
UNICOS problem (notice A-8)
________________________________________________________________________
THE COMPUTER INCIDENT ADVISORY CAPABILITY
CIAC
INFORMATION BULLETIN
________________________________________________________________________
Information about the WDEF virus
December 18, 1989, 1400 PST Number A-9
Summary
A new Macintosh virus called WDEF is spreading rapidly. It is not
necessary to run a program for the virus to spread. The WDEF virus is
not programmed to damage a system, but due to software errors in this
virus, it can cause serious problems such as system crashes, poor
performance, and damage to disks. Disinfectant 1.5, VirusDetective and
GateKeeper Aid V1.0 can be used to detect and eradicate this virus.
Critical WDEF Facts
Name: WDEF
Types: WDEF A, WDEF B
Platform: Apple Macintosh
Damage: No intentional damage, see symptoms.
Symptoms: The virus can cause:
- both the Macintosh IIci and the portable to crash.
- severe performance problems on AppleTalk networks
with AppleShare servers.
- frequent crashes when users try to save files in
applications under MultiFinder.
- problems with the proper display of font styles (the
outline style in particular).
- damage to disks.
- Macintoshes with 8 megabytes of memory to crash.
- Erratic system behavior due to incompatibility with
the "Virtual" INIT from Connectix.
Detection/Eradication: GateKeeper Aid, Disinfectant 1.5;
others should be available in the next few weeks.
Introduction
A new form of computer virus called WDEF has been released into the
Macintosh world. WDEF only infects the invisible "Desktop" files used
by the Macintosh operating system's "Finder." WDEF does not infect
applications, document files, or other system files. Unlike the other
viruses, it does not at this time appear to spread through the sharing
of applications, but rather through the sharing of diskettes. WDEF
spreads from disk to disk very rapidly. It is not necessary to run a
program for the virus to spread. WDEF has been in existence since mid-
October of this year and has been found at many locations throughout the
United States.
At this time their appears to be two strains of WDEF, WDEF A and WDEF B.
These strains are similar except WDEF B beeps every time it infects a
new Desktop file.
Symptoms
The WDEF virus is not programmed to damage a system. However, due to
errors in the virus code itself, it can cause serious problems. Below
is a list of known symptoms:
The virus causes both the Mac IIci and the portable to crash.
Under some circumstances the virus can cause severe performance
problems on AppleTalk networks with AppleShare servers.
Many people have reported frequent crashes when trying to save
files in applications under MultiFinder.
The virus causes problems with the proper display of font styles
(the outline style in particular).
The virus can damage disks.
The virus causes Macintoshes with 8 megabytes of memory to crash.
The virus may be incompatible with the "Virtual" INIT from
Connectix.
Prevention
With AppleShare servers you do not need a Desktop. If you are
comfortable using a software developers' package called ResEdit, you
should remove the Desktop. You should also not allow the "make changes"
privilege to the root directory on the server. This should eliminate
any possibility that this virus from spreading to an AppleShare server.
Detection
Packages which claim to detect WDEF are Disinfectant 1.5 and GateKeeper
Aid V1.0 (to be used in conjunction with GateKeeper 1.11). Virus
Detective 3.1 can also be used to find the WDEF virus. You will,
however, have to add the search string:
Creator=ERIK & Resource WDEF & Any
Disinfectant 1.3 , Vaccine 1.0.1, GateKeeper 1.1.1, Symantec's SAM
Intercept 1.10, and HJC's Virex INIT 1.12 do not detect WDEF, although
new versions of many of these products which claim to be able to detect
WDEF are rapidly being developed. Please also note that Disinfectant
1.4 detects only one strain of the WDEF virus.
Eradication
Disinfectant 1.5 should be used to eradicate WDEF. When using
Disinfectant to repair WDEF infections, you must use Finder instead of
MultiFinder. Otherwise Disinfectant cannot write to the normally 'Busy'
Desktop file. If you do not prefer use Disinfectant 1.5, CIAC can
advise you of alternate eradication procedures using ResEdit.
For further information, or for a copy of Disinfectant 1.5, please
contact CIAC:
David S. Brown
(415) 423-9878 or (FTS) 543-9878
FAX: (415) 294-5054
or send e-mail to: ciac@tiger.llnl.gov
_____________________________________________________________
THE COMPUTER INCIDENT ADVISORY CAPABILITY
CIAC
INFORMATION BULLETIN
_____________________________________________________________
Information about the PC CYBORG (AIDS) trojan horse
December 19, 1989, 1600 PST Number A-10
There recently has been considerable attention in the news
media about a new trojan horse which advertises that it
provides information on the AIDS virus to users of IBM PC
computers and PC clones. Once it enters a system, the trojan
horse replaces AUTOEXEC.BAT, and may count the number of
times the infected system has booted until a criterion number
(90) is reached. At this point PC CYBORG hides directories,
and scrambles (encrypts) the names of all files on drive C:
There exists more than one version of this trojan horse, and
at least one version does not wait to damage drive C:, but
will hide directories and scramble file names upon the first
boot after the trojan horse is installed.
At first PC CYBORG was distributed only in Europe, although
several PC CYBORG infections have recently been reported in
the U.S. No DOE site has been affected yet, and the
probability of a widespread infection of this trojan horse
throughout DOE is extremely small. This trojan horse is
introduced into systems through a disk called the AIDS
Information Introductory Diskette, which has been mailed to a
mailing list which the author(s) of this trojan horse
obtained. PC CYBORG is a trojan horse, not a virus, and
thus is limited in ability to spread. This information
bulletin is being distributed in response to questions raised
because of the considerable media attention the trojan horse
has received, more than because of a genuine threat to
systems.
If you receive a disk in the mail which purports to provide
information on AIDS, do not load the disk into your computer.
Please save the disk, and contact CIAC immediately. If you
have already run this disk, please also call CIAC as soon as
possible. It is important to leave your PC on if it is
currently on, or leave it off if it is currently off.
Failure to do so may result in loss of your data, or make
recovery more difficult. CIAC has developed recovery
procedures, which are too lengthy to publish in this
bulletin.
For further information, including information about recovery
procedures, please contact CIAC:
Tom Longstaff
(415) 423-4416 or (FTS) 543-4416
FAX: (415) 294-5054
or send e-mail to: ciac@tiger.llnl.gov
________________________________________________________________________
THE COMPUTER INCIDENT ADVISORY CAPABILITY
CIAC
INFORMATION BULLETIN
________________________________________________________________________
Problem in the Texas Instruments D3 Process Control System
January 4, 1990, 1430 PST Number A-11
CIAC has recently learned of a computer security problem in the Texas
Instruments D3 Process Control System running on the RSX operating
system (all versions). If your site has this system and you wish to
learn more about this problem, please contact CIAC.
Eugene Schultz (415) 422-8193 or (FTS) 532-8193
FAX: (415) 423-0913 or (FTS) 543-0913
CIAC's 24-hour emergency hot-line number is (415) 971-9384
or send e-mail to: ciac@tiger.llnl.gov
Neither the United States Government nor the University of California
nor any of their employees, makes any warranty, express or implied, or
assumes any legal liability or responsibility for the accuracy,
completeness, or usefulness of any information, product, or process
disclosed, or represents that its use would not infringe privately
owned rights. Reference herein to any specific commercial products,
process, or service by trade name, trademark manufacturer, or
otherwise, does not necessarily constitute or imply its endorsement,
recommendation, or favoring by the United States Government or the
University of California. The views and opinions of authors expressed
herein do not necessarily state or reflect those of the United States
Government nor the University of California, and shall not be used for
advertising or product endorsement purposes.
DRAFT
________________________________________________________________________
THE COMPUTER INCIDENT ADVISORY CAPABILITY
CIAC
INFORMATION BULLETIN
________________________________________________________________________
DECNET Hacker Attack Alert
January 18, 1990, 1430 PST Number A-12
CIAC has recently been advised of a series of hacker attacks on DECnet
systems. Hackers are using a variety of techniques to break into systems,
including entering through system accounts (e.g., SYSTEM) or through
user accounts in which the account name and password are identical. Other
hackers are using more sophisticated techniques.
Once the hackers have broken into a system, they may cause a variety of
problems. They may become privileged users, and then leave executable
images. CIAC has also been advised that VMSMAIL_PROFILE.DATA may be
altered to cause mail sent to the system manager and other accounts to
be intercepted. (Since mail delivery may be compromised, it may not be
advisable for VMS system managers to alert users of these threats using
electronic mail.) In addition, they may modify RIGHTSLIST.DAT, causing
problems with Access Control Lists.
CIAC recommends that DECnet administrators increase monitoring activity.
It is important to check for default account passwords and user accounts
in which the user name is the same as the password. However, the more
sophisticated penetration methods may be difficult to detect. At a
minimum, you may want to ensure that all your privileged accounts are
authorized.
If you have questions, please contact CIAC:
Eugene Schultz (415) 422-8193 or (FTS) 532-8193
FAX: (415) 423-0913 or (FTS) 543-0913
CIAC's 24-hour emergency hot-line number is (415) 971-9384
or send e-mail to: ciac@tiger.llnl.gov
Neither the United States Government nor the University of California
nor any of their employees, makes any warranty, expressed or implied, or
assumes any legal liability or responsibility for the accuracy,
completeness, or usefulness of any information, product, or process
disclosed, or represents that its use would not infringe privately
owned rights. Reference herein to any specific commercial products,
process, or service by trade name, trademark manufacturer, or
otherwise, does not necessarily constitute or imply its endorsement,
recommendation, or favoring by the United States Government or the
University of California. The views and opinions of authors expressed
herein do not necessarily state or reflect those of the United States
Government nor the University of California, and shall not be used for
advertising or product endorsement purposes.
________________________________________________________________________
THE COMPUTER INCIDENT ADVISORY CAPABILITY
CIAC
INFORMATION BULLETIN
________________________________________________________________________
Vulnerability in DECODE alias
January 19, 1990, 1600 PST Number A-13
CIAC has learned of a UNIX vulnerability in the DECODE alias. There is
a strong possibility that this vulnerability is currently being exploited.
One workaround is to disable the DECODE alias by commenting out the line
beginning with DECODE in either /etc/aliases or /usr/aliases. If you
do not wish to disable the DECODE alias, you can redirect DECODE to
postmaster.
If you have questions, please contact CIAC:
Eugene Schultz (415) 422-8193 or (FTS) 532-8193
FAX: (415) 423-0913 or (FTS) 543-0913
CIAC's 24-hour emergency hot-line number is (415) 971-9384
or send e-mail to: ciac@tiger.llnl.gov
Neither the United States Government nor the University of California
nor any of their employees, makes any warranty, expressed or implied, or
assumes any legal liability or responsibility for the accuracy,
completeness, or usefulness of any information, product, or process
disclosed, or represents that its use would not infringe privately
owned rights. Reference herein to any specific commercial products,
process, or service by trade name, trademark manufacturer, or
otherwise, does not necessarily constitute or imply its endorsement,
recommendation, or favoring by the United States Government or the
University of California. The views and opinions of authors expressed
herein do not necessarily state or reflect those of the United States
Government nor the University of California, and shall not be used for
advertising or product endorsement purposes.
________________________________________________________________________
THE COMPUTER INCIDENT ADVISORY CAPABILITY
CIAC
INFORMATION BULLETIN
________________________________________________________________________
Additional information on the vulnerability in the UNIX DECODE alias
January 23, 1990, 1130 PST Number A-14
CIAC information bulletin A-13 described preliminary information about
a vulnerability in some versions of the UNIX operating system. This
bulletin gives additional information and a procedure for patching
this vulnerability.
The UNIX operating system maintains a global mail aliases data base
used by the "sendmail" program to re-route electronic mail. This
database file is contained in /usr/lib/aliases for most UNIX systems
(with exceptions noted below). One standard alias delivered with some
versions of UNIX is "decode." When mail is sent to "decode" at a UNIX
host, the message is re-routed to the program "uudecode", which will
translate a file that has been encoded with "uuencode". There is a
vulnerability associated with this default alias, and CIAC maintains
that there is a strong possibility that this vulnerability has been or
is currently being exploited.
To determine if your UNIX system has this vulnerability, CIAC
recommends the following procedure:
1. Find the global aliases file for your UNIX system.
Traditionally this file is kept in /usr/lib/aliases, but for some
systems such as SUN OS 4.X and ULTRIX 3.X systems it may be in
/etc/aliases. If you do not have either of these files, it is
possible that you are not running the SENDMAIL program, and thus do
not have this vulnerability. The global aliases file will be referred
to as in the following steps.
2. Determine if the decode alias is present in your global
aliases file. To do this execute the command "grep decode "
If this command results in nothing being displayed, your system does
not have a decode alias, and probably does not have this
vulnerability. If you see a line such as
'decode: "|/usr/bin/uudecode" ' or a similar line, proceed to step 3.
3. Become a super-user for your system if you are not already
running as root. Create a backup copy of the aliases file found in
step 1, and edit this file. Insert a "#" at the beginning of the line
containing the decode alias. The line should now read:
'#decode: "|/usr/bin/uudecode" ' Save the file and exit.
4. Assure that the ownership and permissions of this aliases file
are still set properly, by executing the command "ls -l " The
line should begin with "-rw--r--r--" If this is not the case, run the
command "chmod 644 "
5. Once the aliases file has been altered, run the command
"newaliases" so that the changed aliases file will take effect. The
vulnerability has now been closed.
If you do not wish to disable the DECODE alias, you can redirect
DECODE to postmaster. In step 3 above, change the decode alias to
"decode: postmaster" Now mail to decode will be forwarded to
postmaster, allowing the designated postmaster to manually uudecode
the file if desired. If neither of these solutions is appropriate for
your system, you may call CIAC for additional alternatives.
If you have questions, please contact CIAC.
Tom Longstaff
(415) 423-4416 or (FTS) 543-4416
FAX: (FTS) 543-0913 or (415) 294-5054
CIAC's business hours phone number is (415) 422-8193 or (FTS) 532-8193.
CIAC's 24-hour emergency hot-line number is (415) 971-9384
or send e-mail to: ciac@tiger.llnl.gov
Neither the United States Government nor the University of California
nor any of their employees, makes any warranty, express or implied, or
assumes any legal liability or responsibility for the accuracy,
completeness, or usefulness of any information, product, or process
disclosed, or represents that its use would not infringe privately
owned rights. Reference herein to any specific commercial products,
process, or service by trade name, trademark manufacturer, or
otherwise, does not necessarily constitute or imply its endorsement,
recommendation, or favoring by the United States Government or the
University of California. The views and opinions of authors expressed
herein do not necessarily state or reflect those of the United States
Government nor the University of California, and shall not be used for
advertising or product endorsement purposes.
________________________________________________________________________
THE COMPUTER INCIDENT ADVISORY CAPABILITY
CIAC
INFORMATION BULLETIN
________________________________________________________________________
Number A-15
CIAC information bulletin A-15 describs vulnerabilities within Apple MACs.
Please contact CIAC for further information.
Tom Longstaff
(415) 423-4416 or (FTS) 543-4416
During working hours, call CIAC at (415) 422-8193 or (FTS)
532-8193. For non-working hour emergencies , call (415)
422-7222 or (FTS) 532-7222 and ask for CIAC (this is a new
emergency number).
send e-mail to ciac@cheetah.llnl.gov (this is a new Internet
address)
send FAX messages to: (415) 423-0913 or (FTS) 543-0913
________________________________________________________________________
THE COMPUTER INCIDENT ADVISORY CAPABILITY
CIAC
INFORMATION BULLETIN
________________________________________________________________________
Vulnerability in SUN sendmail program
January 29, 1990, 0900 PST Number A-16
CIAC has been advised of a new vulnerability in the SUN sendmail
program. This vulnerability (SUN bug #1028173) exists in all versions
of SUN OS (version 4.1, 4.0.3 on SUN 3, SUN 4, as well as SUN 386i
systems, for which version 4.0.2 is the most current version). This
vulnerability has been exploited in several recent Internet breakins.
You may obtain a patch directly from SUN by calling (800) USA-4SUN, or
may obtain SUN 3 and 4 sendmail binaries using anonymous FTP from
uunet.uu.net in the /sun-fixes directory. CIAC can also provide you
with a patch for this vulnerability.
Recent versions of UNIX systems other than SUN OS systems contain a
sendmail fix. CIAC encourages you to consult with your vendor about
upgrading to a recent release if the version you are running does not
have this fix.
If you have questions, please contact CIAC.
Tom Longstaff
(415) 423-4416 or (FTS) 543-4416
FAX: (FTS) 543-0913 or (415) 294-5054
CIAC's business hours phone number is (415) 422-8193 or (FTS)
532-8193. CIAC's 24-hour emergency hot-line number is (415) 971-9384.
If you call the emergency number and there is no answer, please leave
a voice mail message. Someone will return your call promptly. You may
also send e-mail to:
ciac@tiger.llnl.gov
This bulletin is based on information supplied by the Computer
Emergency Response Team Coordination Center. Neither the United
States Government nor the University of California nor any of their
employees, makes any warranty, expressed or implied, or assumes any
legal liability or responsibility for the accuracy, completeness, or
usefulness of any information, product, or process disclosed, or
represents that its use would not infringe privately owned rights.
Reference herein to any specific commercial products, process, or
service by trade name, trademark manufacturer, or otherwise, does not
necessarily constitute or imply its endorsement, recommendation, or
favoring by the United States Government or the University of
California. The views and opinions of authors expressed herein do not
necessarily state or reflect those of the United States Government nor
the University of California, and shall not be used for advertising or
product endorsement purposes.
________________________________________________________________________
THE COMPUTER INCIDENT ADVISORY CAPABILITY
CIAC
INFORMATION BULLETIN
________________________________________________________________________
Eradicating WDEF using Disinfectant 1.5 or 1.6
February 2, 1990, 1400 PST Number A-17
CIAC Information Bulletin A-9 reported the existence of the WDEF virus on
Macintosh computers. The purpose of this bulletin is to provide additional
information about eradicating this virus.
Disinfectant 1.5 and the most recent version, Disinfectant 1.6, are capable
of detecting and eradicating WDEF, but are not designed to prevent the
spread of WDEF during its execution. If an infected disk is inserted into
the Macintosh while Disinfectant is running (for the purposes of eradicating
WDEF), WDEF will infect ANY OTHER UNLOCKED MOUNTED VOLUMES. If Disinfectant
is to be used to eradicate a WDEF infection, CIAC recommends the following
procedure:
1. Prepare a system disk using LOCKED originals. Use the
instructions provided with the Macintosh documentation if you require
assistance in preparing this system disk. If possible, you should not use
your hard disk to prepare this system disk. Copy Disinfectant version 1.5
or version 1.6 to this disk. Lock the disk and shut down the system.
2. Reboot the Macintosh using the prepared system disk. Launch
Disinfectant off the floppy and use the SCAN function to check your hard disk
for the WDEF virus. If found, use the DISINFECT function to remove WDEF from
your hard disk. Quit Disinfectant.
3. Reboot the Macintosh using this prepared system disk. You should
drag any hard disks that automatically appear on the desktop to trash to
unmount them. Launch the copy of Disinfectant on the system disk. Use the
SCAN facility of Disinfectant to verify that WDEF has not infected the system
disk. If it has, you will have to eject the system disk, unlock it, and
insert it again. Use the DISINFECT function of Disinfectant to eradicate
WDEF. Next, you should eject the system disk and lock it again. Reinsert
the system disk.
4. Use Disinfectant to scan ALL of your floppy disks. WDEF will
infect both system and non-system disks; to completely eradicate WDEF you
will have to disinfect all of your disks (including backup disks). DO NOT
USE YOUR HARD DRIVE DURING THIS PROCEDURE.
5. Once all of your floppy disks are disinfected, reboot your system
using the locked system disk. Now run Disinfectant and disinfect your hard
disk. Once WDEF has been eradicated from all floppies and your hard disk, the
eradication procedure is complete.
The most recent versions of other tools such as SAM, VIREX, GATEKEEPER, and
GATEKEEPER AID may also be used to eradicate or prevent the spread of the
WDEF virus. If you have questions concerning these tools, contact CIAC for
assistance.
For further information, or for a copy of Disinfectant 1.6, please contact
CIAC:
Tom Longstaff
(415) 423-4416 or (FTS) 543-4416
FAX: (FTS) 543-0913 or (415) 294-5054
CIAC's business hours phone number is (415) 422-8193 or (FTS) 532-8193.
Send e-mail to:
ciac@tiger.llnl.gov
Neither the United States Government nor the University of California
nor any of their employees, makes any warranty, expressed or implied,
or assumes any legal liability or responsibility for the accuracy,
completeness, or usefulness of any information, product, or process
disclosed, or represents that its use would not infringe privately
owned rights. Reference herein to any specific commercial products,
process, or service by trade name, trademark manufacturer, or
otherwise, does not necessarily constitute or imply its endorsement,
recommendation, or favoring by the United States Government or the
University of California. The views and opinions of authors expressed
herein do not necessarily state or reflect those of the United States
Government nor the University of California, and shall not be used for
advertising or product endorsement purposes.
_______________________________________________________________________
THE COMPUTER INCIDENT ADVISORY CAPABILITY
CIAC
INFORMATION BULLETIN
_______________________________________________________________________
Notice of Availability of Patch for SmarTerm 240
February 13, 1990, 1200 PST Number A-18
SmarTerm 240 is a PC terminal emulation package used to connect PCs to host
computers. CIAC has been advised of an exploitable feature in this package that
can result in execution of unauthorized programs on the host computers accessed
via this package.
Persoft, Inc., the manufacturer of SmarTerm 240, has provided a workaround
(validated by CIAC) that will disable the exploitable feature. For versions
3.0A or 3.0B, the procedure for disabling this feature is as follows:
1A. If you have SmarTerm version 3.0A, you will need to get
an updated version of the FILEMOD2 program. This program is included
with SmarTerm 240 on the utilities disk which comes with SmarTerm 240.
The updated version is available from CIAC or from Persoft, Inc., phone
(608) 273-6000.
1B. If you have SmarTerm 240 version 3.0B, you already have
the version of FILEMOD2.EXE that you need. It is on the utility disk
which comes with SmarTerm 240.
2. Load the utility disk containing FILEMOD2.EXE (From the
original SmarTerm 240 distribution disks) into drive A:. Change to the
A: prompt by typing
A:
3. Enter the following command from the DOS prompt.
filemod2 (path)\st240.exe 0 1 x7503e9a6fe 0 1 xe9b3009090 1473
where (path) is the drive designator and the directory containing
st240.exe
For example, you can enter:
filemod2 C:\st240\st240.exe 0 1 x7503e9a6fe 0 1 xe9b3009090 1473
where C is the hard drive and st240 is the directory containing SmarTerm.
The procedure is now complete. If you are using a version of SmartTerm 240
other than versions mentioned above, please contact CIAC for assistance in
closing this vulnerability:
David S. Brown
(415) 423-9878 or (FTS) 543-9878
FAX: (415) 423-0913 or (415) 294-5054
CIAC's business hours phone number is (415) 422-8193 or (FTS) 532-8193. You
may also send e-mail to:
ciac@tiger.llnl.gov
Neither the United States Government nor the University of California nor any of
their employees, makes any warranty, expressed or implied, or assumes any legal
liability or responsibility for the accuracy, completeness, or usefulness of any
information, product, or process disclosed, or represents that its use would not
infringe privately owned rights. Reference herein to any specific commercial
products, process, or service by trade name, trademark manufacturer, or
otherwise, does not necessarily constitute or imply its endorsement, recom-
mendation, or favoring by the United States Government or the University of
California. The views and opinions of authors expressed herein do not
necessarily state or reflect those of the United States Government nor the
University of California, and shall not be used for advertising or product
endorsement purposes.
________________________________________________________________________
THE COMPUTER INCIDENT ADVISORY CAPABILITY
CIAC
ADVISORY NOTICE
________________________________________________________________________
UNIX Internet Attack Advisory
February 23, 1990, 1500 PST Number A-19
CIAC has learned of a large number of attacks on UNIX machines connected to the
Internet. There are several groups of attackers using a variety of different
methods to break into systems. One method is to use tftp to steal the password
file. Another is to use sendmail to append additional entries onto .rhost
files. Still another is to login to unpassworded system accounts and "Joe"
accounts (in which the username and password are identical). Many of the
attackers then exploit unpatched vulnerabilities to obtain root privileges.
Using the root account, some have installed a modified version of /bin/login.
Modifications to /etc/utmp, /etc/wtmp, and /usr/adm/lastlog have also been made
to mask the intrusion. The motivation for intrusion largely appears to be use
of machine time rather than destruction of files or damage to systems.
However, cases of malicious activity have also been observed. This intrusion
activity is widespread, and is usually difficult to detect.
CIAC recommends that you take the following actions:
1. Ensure that you have installed any applicable patches (e.g., for tftp,
restore/ dump, etc.--see previous CIAC bulletins) in your UNIX system. (CIAC is
currently preparing a checklist to help you verify that you have installed all
the applicable patches.)
2. Regularly perform an integrity check on /bin/login
3. Check for unpassworded accounts and "Joe" accounts--CIAC can supply DOE sites
with a copy of the Security Profile Inspector, a UNIX password checking tool
4. Look for suspicious connections from the University of Texas and Dartmouth
University
5. Look for strange files in /tmp
For additional information or assistance, please contact CIAC:
David S. Brown
(415) 423-9878 or (FTS) 543-9878
FAX: (415) 423-0913 or (415) 294-5054
CIAC's business hours phone number is (415) 422-8193 or (FTS) 532-8193. You may
also send e-mail to:
ciac@tiger.llnl.gov
Neither the United States Government nor the University of California nor any of
their employees, makes any warranty, expressed or implied, or assumes any legal
liability or responsibility for the accuracy, completeness, or usefulness of any
information, product, or process disclosed, or represents that its use would not
infringe privately owned rights. Reference herein to any specific commercial
products, process, or service by trade name, trademark manufacturer, or
otherwise, does not necessarily constitute or imply its endorsement,
recommendation, or favoring by the United States Government or the University of
California. The views and opinions of authors expressed herein do not
necessarily state or reflect those of the United States Government nor the
University of California, and shall not be used for advertising or product
endorsement purposes.
________________________________________________________________________
THE COMPUTER INCIDENT ADVISORY CAPABILITY
CIAC
INFORMATION BULLETIN
________________________________________________________________________
The Twelve Tricks Trojan Horse
March 8, 1990, 1300 PST Number A-20
Summary
CIAC has been informed of a possible new trojan horse called the Twelve Tricks
Trojan Horse. The intention of this bulletin is to rapidly inform the DOE
community about this possible threat and to help eliminate confusion and false
rumors. However, CIAC has been able neither to obtain a copy of this trojan
horse, nor to confirm the information received to date. This trojan horse
affects computers running the MS DOS operating system or common variants (IBM
PC-DOS etc.). It can produce a variety of disruptions and/or damage as
described below.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Critical Facts about Twelve Tricks Trojan Horse
Name: Twelve Tricks Trojan
Types: Only one known variant: CORETEST.COM VERSION 2.6, 32469 bytes, timestamp
6-6-86 9:44
Platform: IBM PC and PC clones running MS DOS or IBM-PC DOS
Damage: Varies from slow program execution to low level formatting of disk
Symptoms: A variety of disruptions and/or damage, based on a random number
between one and twelve. Affects system performance, writing to screen, clock,
printer and/or keyboard malfunctions, random disk writes, garbled printer
output, boot sector, File Allocation Table (FAT) or directory overwrites, and a
low level format of select tracks on the hard disk. Other symptoms include the
floppy disk motor continuously running, FAT, directory and/or boot sector
damaged diskettes.
Detection: Examine the Master Boot Record (MBR) for the message:
SOFTLOK+ V3.0 SOFTGUARD SYSTEMS INC
2840 St. Thomas Expwy, Suite 201
Santa Clara, CA 95051
(see important note below)
or search the MBR and memory for the following hex string:
e4 61 8a e0 0c 80 e6 61.
If you suspect a program, you can use the search string:
64 02 31 94 42 01 d1 c2 4e 79 f7
Caution: These search strings are based on the trojan program examined by the
discoverer. If there are modifications to this program, the above search
strings may not work.
Eradication: Remove trojan program by deleting. To recover from a corrupt MBR,
back-up current data files and programs, perform a low level format and restore
data files and programs from a recent backup.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
CIAC has been alerted that there may be a new trojan horse called the Twelve
Tricks Trojan Horse. CIAC has not been able to obtain a copy of this program,
and cannot at this time confirm the information contained in this bulletin.
This trojan program affects computers running the MS DOS operating system or
common variants (IBM PC-DOS etc.). It can produce a variety of disruptions
and/or damage, including a slowdown of system performance, blanking or jerky
motion in the scrolling window, clock, printer and/or keyboard malfunctions,
random disk writes, garbled printer output, boot sector, File Allocation Table
(FAT) or directory overwrites, and a low level format of select tracks on the
hard disk. Other symptoms include the floppy disk motor continuously running,
FAT, directory and/or boot sector damaged diskettes. The particular damage which
occurs depends on a random number between 1 and 12 that the trojan program
generates.
DETECTION
Detecting this trojan horse is straightforward. Using Debug or a similar
utility, inspect your machine's hard disk at cylinder zero, head zero, sector
one. If this trojan horse has infected your machine, the following will be
displayed near the start of the master boot record:
SOFTLOK+ V3.0 SOFTGUARD SYSTEMS INC
2840 St. Thomas Expwy, Suite 201
Santa Clara, CA 95051
IMPORTANT NOTE: There is absolutely no evidence to link the origin of this
trojan horse to any company or organization, such as the one mentioned above.
The motivation of the author of this trojan horse to mention the company listed
above is currently unknown.
There are several additional ways to detect the trojan. The following
hexadecimal string can be found in the MBR of infected machines:
e4 61 e0 0c 80 e6 61
The above string can also be found at location 0:38b in memory if you have
booted from a corrupted MBR. You can use Debug as a search tool.
A useful search string to detect the source program (containing the trojan
horse) is
be 64 02 31 94 42 01 d1 c2 4e 79 f7
ERADICATION
Trojan programs can be removed by simply deleting them. To recover from a
corrupt MBR, back-up current data files and programs, perform a low level format
and restore data files and programs. Note: FDISK will erase other directory
information as well as replace the MBR. Thus, we recommend that you do not use
FDISK alone to eradicate the trojan unless you are prepared to lose directory
information from other partitions. Because the file system may be corrupted,
CIAC recommends a full backup, low level format, and recovery.
Trojan programs can be removed by simply deleting them. 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 restore your data
files and programs from your backup.
ADDITIONAL INFORMATION
There is currently no evidence that anything similar to the Tweleve Tricks
Trojan has affected any machines in the United States. It is possible, however
that there will be attempts to introduce this malicious code in the United
States. (This trojan horse is not self-replicating, and cannot spread the way
viruses do.) In particular CIAC urges you to carefully check any software
distributed through trade shows, U.S. mail, or electronic bulletin boards, and
to use only licensed copies of software. Please contact CIAC if you become
aware of any machines infected by this malicious code.
For additional information or assistance, please contact CIAC:
David S. Brown
(415) 423-9878 or (FTS) 543-9878
FAX: (415) 423-0913 or (415) 294-5054
CIAC's business hours phone number is (415) 422-8193 or (FTS) 532-8193.
You may also send e-mail to:
ciac@tiger.llnl.gov
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Appended message--excerpt from a message from Dr. Alan Solomon posted to
virus-l)
We have recently received and analyzed 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 recognized
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 unauthorized writes to system areas on the hard
disk. Since the 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:3000h 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 (CHKSK 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-Interupt 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, shirt 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 (lah) 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 analyzed, 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 description 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 attack his code to the target executable.
If this is the case, then there are two consequences. The first is that he
might have trojanized 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 is operates. So it would be unsafe to assume we can use 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 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 trojanized 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 restore 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.
(End of appended message)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Neither the United States Government nor the University of California nor any of
their employees, makes any warranty, expressed or implied, or assumes any legal
liability or responsibility for the accuracy, completeness, or usefulness of any
information, product, or process disclosed, or represents that its use would not
infringe privately owned rights. Reference herein to any specific commercial
products, process, or service by trade name, trademark manufacturer, or
otherwise, does not necessarily constitute or imply its endorsement,
recommendation, or favoring by the United States Government or the University of
California. The views and opinions of authors expressed herein do not
necessarily state or reflect those of the United States Government nor the
University of California, and shall not be used for advertising or product
endorsement purposes.
________________________________________________________________________
THE COMPUTER INCIDENT ADVISORY CAPABILITY
CIAC
ADVISORY NOTICE
________________________________________________________________________
Additional Information on Current UNIX Internet Attacks
March 16, 1990, 1145 PST Number A-21
This bulletin follows up CIAC Information Bulletin A-19, UNIX Internet Attack
Advisory (notice A-19). Attacks on UNIX machines connecting to the Internet
persist, and are a very widespread and serious threat. This bulletin provides
additional information about detecting these attacks and procedures to follow to
decreasing the likelihood of attack. This information specifically concerns
SUN, ULTRIX, and BSD UNIX systems, but may be useful to system managers of other
UNIX platforms. Even if you think systems are your site are not being attacked,
it is important to recheck for evidences of intrusions and to adopt additional
precautionary measures.
1. Intruders are using tftp to obtain password files. If possible use
tftbootd in place of tftp.
2. The sendmail function has several problems which intruders can exploit.
CIAC has been informed that sendmail is secure in the latest version of
Ultrix and BSD (versions 3.1 and 5.61 respectively), but that older
versions as well as the recent versions of SunOS (up to version 4.0.3)
have exploitable features in sendmail. In general, it is advantageous
run the most recent version of an operating system. Patches for most
versions and flavors of UNIX are available (call your vendor or
CIAC), and should be installed on every system to close this avenue
of attack! (Refer to CIAC bulletin A-16)
3. There is also a well-known problem with finger in less recent versions
of UNIX. Attackers continue to exploit this vulnerability. Obtain and
install the patch for this bug! (Call your vendor or CIAC for the
availability of a patched version.)
4. Attackers are using ftp to steal system files, especially when a system
is running ftp with an anonymous login. Running the most recent version
of ftp and configuring ftp properly will take care of this problem.
SunOS 4.0.3 and the most recent versions of ULTRIX and BSD UNIX contain
the correct patches. However, it is important to follow the
instructions provided with the operating system to properly configure
the files available through anonymous ftp (e.g., file permissions,
ownership, group, etc.). Note especially that you should not use
your regular password file for the one ftp will use.
5. Programs such as telnet, su and login are being replaced by trojan horse
programs. We recommend that you compare files currently available on
your machines with those obtained from original distribution tapes of
the operating system.
6. Intruders have been leaving files and directories with both usual and
unusual names such as ".mail", ".. "(dot dot space space), "...", "h"
and "k." These files may be found in the home directories of
compromised accounts or in /tmp or /usr/tmp. Also assure that any
".rhost" files in user accounts are authorized and have not been
planted by the attacker.
7. Some intruders continue to remove entries from /etc/utmp, etc/wtmp and
usr/admin/lastlog to mask their presence. You may notice a corrupted or
invalid system log file, or notice that a logfile has been reduced in
size for an unexplained reason. Should you find this activity, please
call CIAC immediately.
8. Once an intruder has compromised your system, a backdoor may be
introduced through the introduction of scripts that set the user id
to root (setuid scripts). You should use the "find" command to
verify that all such scripts are authorized.
9. The intruder may attempt to leave an additional account on the system
to be used at a later time. Check your password file to assure that all
accounts are authorized and properly passworded. Look especially for
any unauthorized root accounts (where the user id is 0). If you have a
password checking program, check the passwords on your system to assure
that there are no easily guessed passwords or unpassworded accounts.
For information on how to obtain such a checker, please contact CIAC.
10. If you use terminal servers on your network (such as ANNEX terminal
servers), these may be used by the intruder to access other hosts on
your network. Follow the instructions for the terminal server to
provide any available auditing capability, and assure that access to the
server is controlled with passwords. Access to a terminal server is
equivalent to access to your network.
Final note: since a primary result of a successful attack is the theft of the
password file, all account passwords on a successfully attacked machine should
be immediately changed.
For additional information or assistance, please contact CIAC:
Tom Longstaff
(415) 423-4416 or (FTS) 543-4416
FAX: (415) 423-0913 or (415) 422-4294
CIAC's phone number is (415) 422-8193. You may also send e-mail to:
ciac@tiger.llnl.gov
This bulletin is partially based on information supplied by the Computer
Emergency Response Team Coordination Center. Neither the United States
Government nor the University of California nor any of their employees, makes
any warranty, expressed or implied, or assumes any legal liability or
responsibility for the accuracy, completeness, or usefulness of any information,
product, or process disclosed, or represents that its use would not infringe
privately owned rights. Reference herein to any specific commercial products,
process, or service by trade name, trademark manufacturer, or otherwise, does
not necessarily constitute or imply its endorsement, recommendation, or favoring
by the United States Government or the University of California. The views and
opinions of authors expressed herein do not necessarily state or reflect those
of the United States Government nor the University of California, and shall not
be used for advertising or product endorsement purposes.
________________________________________________________________________
THE COMPUTER INCIDENT ADVISORY CAPABILITY
CIAC
INFORMATION BULLETIN
________________________________________________________________________
Logon Messages and Hacker/Cracker Attacks
March 16, 1990, 1200 PST Number A-22
CIAC has published several recent information bulletins and advisory notices
about hacker/cracker attacks on computers connected to the Internet. This
bulletin suggests a strategy for your site that is important for legal reasons.
In addition, this strategy may help deter some hacking activity.
In many systems a logon screen is displayed during or before the time the user
is asked to enter a user name and password. Sometimes this screen contains a
message which welcomes the potential user to the system. Court cases involving
unauthorized use of computing systems may be thrown out because a welcoming
message was initially displayed. We strongly recommend, therefore, that (when
feasible to implement) every machine at your site should display a warning
message before or during the logon sequence, and that all phrases suggesting
that users are welcome to use the system be removed. An example of a warning
message is the following:
WARNING: Unauthorized access to this computer system is prohibited, and
is subject to criminal and civil penalties.
This type of warning message may also discourage casual hackers from intruding
into a system.
If feasible to implement, it is also important to display to users any failed
logon attempts on their account, and to inform users who they should contact if
their account was probed or accessed by someone else. Finally, we recommend
that the logon screen should advise users to logout when they are through with a
session or when they leave their terminal.
For additional information or assistance, please contact CIAC:
Eugene Schultz
(415) 422-8193 or (FTS) 532-8193
FAX: (415) 423-0913 or (415) 422-4294
You may also send e-mail to:
ciac@tiger.llnl.gov
Neither the United States Government nor the University of California nor any of
their employees, makes any warranty, expressed or implied, or assumes any legal
liability or responsibility for the accuracy, completeness, or usefulness of any
information, product, or process disclosed, or represents that its use would not
infringe privately owned rights. Reference herein to any specific commercial
products, process, or service by trade name, trademark manufacturer, or
otherwise, does not necessarily constitute or imply its endorsement,
recommendation, or favoring by the United States Government or the University of
California. The views and opinions of authors expressed herein do not
necessarily state or reflect those of the United States Government nor the
University of California, and shall not be used for advertising or product
endorsement purposes.
________________________________________________________________________
THE COMPUTER INCIDENT ADVISORY CAPABILITY
CIAC
ADVISORY NOTICE
________________________________________________________________________
Password Problems with Unisys U5000 /etc/passwd
May 8, 1990, 1500 PST Number A-24
The following advisory was issued by the Computer Emergency Response Team (CERT)
and has been relayed via the Defense Communications Agency's Security
Coordination Center and the various Emergency Response Teams in the Department
of Defense. This unedited notice is reproduced below.
CERT Advisory
May 7, 1990
Unisys U5000 /etc/passwd problem
The CERT/CC has recently verified several reports of unauthorized access
to Internet connected Unisys systems. The intruder(s) gained access to
these systems by logging into vendor supplied default accounts; accounts
that had not been given passwords by the systems' owners.
Gary Garb, Corporate Computer Security Officer for Unisys Corporation,
states:
"The Unisys U5000 series UNIX systems are delivered with a number of
system logins. The logins are NOT password protected when the
customer receives the system. Unless the customer secures these logins,
the system is vulnerable to unauthorized access."
"A complete list of these logins can be found in the /etc/passwd file.
Each login is described by one record in /etc/passwd which contains a
number of fields separated by colons. The second field normally would
contain the encrypted password. The system logins will initially have
a null second field (indicated by two adjacent colons) in their descriptive
records in /etc/passwd."
"The U5000/80/85/90/95 System V Administration Guide, Volume 1 (UP13679)
begins with a chapter on "System Identification and Security". On page 1-2
it states, "All logins should have passwords ... Logins that are not needed
should be either removed (by deleting from /etc/passwd) or blocked (by
locking the login as described in the section "Locking Unused Logins" on
page 1-8). The Guide contains complete instructions on controlling logins
and passwords."
"It is the user's (system administrator's) responsibility to thoroughly
read the Guide and to ensure the security of the system. *Securing the
login entries should be of the highest priority and should be accomplished
before anyone else has access to the system.*"
The CERT/CC urges administrators of Unisys systems, as well as administrators
of systems provided by other vendors, to check their systems and insure all
accounts are protected by passwords; passwords that are different from the
default passwords provided by the vendor.
Questions regarding the security aspects of Unisys systems should be directed
to:
Gary Garb, Corporate Security Officer
Unisys Corporation
(215) 986-4038
For additional information or assistance, please contact CIAC:
David S. Brown
(415) 423-9878 or (FTS) 543-9878
FAX: (415) 294-5054, (415) 423-0913 or (415) 422-4294
CIAC's 24-hour emergency hot-line number is (415) 971-9384.
FELIX, CIAC's bulletin board service (BBS) can be accessed at 1200 or 2400 baud
at (415) 423-4753 or (FTS) 543-4753. (9600 baud access can be obtained from
Lawrence Berkeley and Lawrence Livermore Laboratories at 423-9885.)
Neither the United States Government nor the University of California nor any of
their employees, makes any warranty, expressed or implied, or assumes any legal
liability or responsibility for the accuracy, completeness, or usefulness of any
information, product, or process disclosed, or represents that its use would not
infringe privately owned rights. Reference herein to any specific commercial
products, process, or service by trade name, trademark manufacturer, or
otherwise, does not necessarily constitute or imply its endorsement,
recommendation, or favoring by the United States Government or the University of
California. The views and opinions of authors expressed herein do not
necessarily state or reflect those of the United States Government nor the
University of California, and shall not be used for advertising or product
endorsement purposes.
________________________________________________________________________
THE COMPUTER INCIDENT ADVISORY CAPABILITY
CIAC
INFORMATION BULLETIN
________________________________________________________________________
The MDEF or Garfield Virus on Macintosh Computers
May 23, 1990, 1000 PST Number A-25
Summary
A new Macintosh virus called MDEF or the Garfield virus is spreading
rapidly. This virus is not a variant of the WDEF virus, and should not
be confused with WDEF. The MDEF virus spreads through system and
application files, and may cause serious damage to the menu system.
Disinfectant 1.8, GateKeeper, Virus Detective DA are effective against
this virus, but Vaccine can cause undesirable side effects.
_______________________________________________________________________________
Name: MDEF
Types: Only one known variant
Platform: Apple Macintosh models 128K and 512K, 512KE, Mac Plus, SE, SE/30, II,
IIx, IIcx, IIci and IIfx.
Damage: Possible removal of system menus.
Symptoms: The virus can cause:
% both the Macintosh 128K and 512K to crash.
% system menus to be removed
Detection/Eradication: Disinfectant 1.8, GateKeeper, Virus Detective DA; others
should be available shortly.
Critical MDEF Facts
_______________________________________________________________________________
Introduction
CIAC has learned of a new Macintosh virus called the MDEF or Garfield
virus. Although its name is similar to WDEF, MDEF is an entirely
different virus. Currently, the MDEF virus is known to infect the
Macintosh 128K and 512K, 512KE, Mac Plus, SE, SE/30, II, IIx, IIcx,
IIci and IIfx. This virus will not spread from 128K or 512K
Macintoshes, but will cause these models to crash.
MDEF actually refers to one of the resources on Macintosh computers.
The MDEF virus is so named because this virus infects the MDEF
resources. If you attempt to detect the MDEF virus using ResEdit or a
similar tool and discover the MDEF resources, this does not indicate
that your computer is infected by the MDEF virus.
Symptoms
Preliminary indications are that after performing a currently
unspecified set of actions, the virus will remove itself from the
system along with the code to control the menu system. This will
result in the loss of all menus generated by the system. Regardless of
the particular model of Macintosh computer subject to infections by the
MDEF virus, this virus infects the system file and applications.
Typically, the finder and DA handler also become infected. However,
neither the desktop nor the document files become infected. The MDEF
virus infects the system file when an infected application is run, and
infects other applications when they are executed on an infected
system. On the Macintosh IIci and IIfx, the MDEF virus spreads from
infected applications to uninfected system files, but does not
propagate from infected systems to uninfected applications.
Detection and Eradication
Disinfectant 1.8 has recently been released to detect and eradicate the
MDEF virus. GateKeeper also prevents the MDEF virus from infecting
the system file. To use the Virus Detective DA, add the following
search strings:
Resource MDEF & Name "Garfield"
Resource MDEF & ID = 5378
CAUTION: CIAC has been advised that the use of Vaccine may have an
undesirable side effect. Vaccine will inform the user that the system
file has been infected, but is only partially effective in preventing
this virus from infecting the system file! The system file will be
damaged as a result of running Vaccine when an application containing
the MDEF virus is executed.
For additional information or assistance, or to obtain a copy of
Disinfectant 1.8, please contact CIAC:
Eugene Schultz
(415) 422-8193 or (FTS) 532-8193
FAX: (415) 294-5054, (415) 423-0913 or (415) 422-4294
You may also send e-mail to:
ciac@tiger.llnl.gov
Neither the United States Government nor the University of California
nor any of their employees, makes any warranty, expressed or implied,
or assumes any legal liability or responsibility for the accuracy,
completeness, or usefulness of any information, product, or process
disclosed, or represents that its use would not infringe privately
owned rights. Reference herein to any specific commercial products,
process, or service by trade name, trademark manufacturer, or
otherwise, does not necessarily constitute or imply its endorsement,
recommendation, or favoring by the United States Government or the
University of California. The views and opinions of authors expressed
herein do not necessarily state or reflect those of the United States
Government nor the University of California, and shall not be used for
advertising or product endorsement purposes.
________________________________________________________________________
THE COMPUTER INCIDENT ADVISORY CAPABILITY
CIAC
INFORMATION BULLETIN
________________________________________________________________________
A New Macintosh Trojan Horse Threat--STEROID
June 7, 1990, 1100 PST Number A-26
_______________________________________________________________________
Name: Steroid trojan horse
Types: Only one known variant
Platform: Apple Macintosh computers
Damage: Erases all mounted disks
Symptoms: Can be identified by:
TYPE: INIT
CREATOR: QDAC
Code Size: 1080
Data Size: 267
ID: 148
Name: QuickDraw Accelerator
File Name: " Steroid" (First 2 characters are ASCII 1)
Detection/Eradication: Examine system folder; if Steroid is there,
save a copy and then drag the icon to the trash folder and empty trash.
______________________________________________________________________
Critical Steroid Facts
A Macintosh trojan horse called "Steroid" has been discovered. The purported
purpose of Steroid is to make QuickDraw run faster on computers with 9 inch
screens. Steroid is actually an INIT that contains malicious code to check
for the system date and to erase all mounted disks if this date is July 1, 1990
or afterwards. (Note: earlier reports indicated that June 6, 1990 is the
trigger date, but the sources of these reports now claim that July 1 is the
trigger date.)
Steroid is a trojan horse, not a virus, and thus is limited in ability to
spread. This trojan horse is a genuine threat; however, because it is being
posted to electronic bulletin boards, and has already been downloaded by
unsuspecting users on the West Coast. If you use a bulletin board, make sure
that you do not download any software claiming to improve QuickDraw performance
or related in any way to "Steroid." Since "Steroid" is an INIT, you would have
had to put it in your system folder to have this trojan horse. If you are
unsure if you have installed "Steroid," look in your system folder for start-up
documents with the name "Steroid" or "Quickdraw Accelerator." Another detection
method is to use RESEDIT; look for documents in the system folder with the
Creator: "QDAC," Type "INIT," and a code size of 1080 and a data size of 267.
If your Macintosh computer contains this INIT, please make a copy on a floppy
before you do anything else and send that copy to CIAC at your earliest
convenience. Then drag the Steroid INIT to the trash icon and empty the trash.
If you unknowingly have used Steroid before July 1, 1990, no damage appears
possible at this time. It is important, however, to determine if you have
shared Steroid with anyone else, and, if so, to notify them of the information
in this bulletin. If you use Steroid on or after July 1, 1990, CIAC has been
advised that you can recover if you use the SUM II Disk Clinic tool to restore
erased files. Do not use the machine until you have recovered the files using
SUM. CIAC can provide more detailed procedures in this case.
The following is an excerpt from a bulletin board posting by Apple:
________________________________________________________________________
So far, we know that the code does the following:
OPERATIONS AT RESTART:
----------------------
DATE & TIME CHECK (Loop)
SYSENVIRONS CHECK
GETS VOLUME INFORMATION (probably checking for HFS)
GETS SOME ADRESSES (Toolbox traps)
DOES SOME HFS DISPATCH OPERATIONS
VOLUME IS REINITIALIZED to "Untitled"
INFORMATION:
------------
TYPE: INIT
CREATOR: qdac
CODE SIZE: 1080
DATA SIZE: 267
ID: 148
Name: QuickDraw Accelerator
File Name: " Steroid" (First 2 characters are ASCII 1)
WHAT TO DO:
-----------
If your disk becomes erased, you can use SUM II Disk Clinic to recover the
deleted files. We have tried this and it seems to work.
IF YOU HAVE STEROID ON YOUR SYSTEM, DISABLE IT IMMEDIATELY.
________________________________________________________________________
For additional information or assistance, please contact CIAC:
Eugene Schultz
(415) 422-8193 or (FTS) 532-8193
FAX: (415) 294-5054, (415) 423-0913 or (415) 422-4294
You may also send e-mail to:
ciac@tiger.llnl.gov
Neither the United States Government nor the University of California nor any of
their employees, makes any warranty, expressed or implied, or assumes any legal
liability or responsibility for the accuracy, completeness, or usefulness of any
information, product, or process disclosed, or represents that its use would not
infringe privately owned rights. Reference herein to any specific commercial
products, process, or service by trade name, trademark manufacturer, or
otherwise, does not necessarily constitute or imply its endorsement,
recommendation, or favoring by the United States Government or the University of
California. The views and opinions of authors expressed herein do not
necessarily state or reflect those of the United States Government nor the
University of California, and shall not be used for advertising or product
endorsement purposes.
________________________________________________________________________
THE COMPUTER INCIDENT ADVISORY CAPABILITY
CIAC
INFORMATION BULLETIN
________________________________________________________________________
The Disk Killer (Orge) Virus on MS DOS Computers
June 28, 1990, 1000 PST Number A-27
________________________________________________________________________
Name: Disk Killer virus (also known as the Ogre virus)
Types: Only one known variant
Platform: MS DOS computers
Damage: Overwrites mounted disks
Symptoms: Writes "COMPUTER OGRE 04/01/89" on screen and overwrites disk
Detection/Eradication: VIRALERT, VIRHUNT, RESSCAN, CodeSafe, CleanUp,
F-Prot, IBM Scan, Pro-Scan, and others (contact CIAC for information
about these products)
Critical Disk Killer Facts
________________________________________________________________________
The Disk Killer virus is a destructive virus affecting MS DOS
computers. This virus infects the boot sector, then hides itself by
marking unused blocks on floppy or hard disks as bad. After remaining
dormant for approximately 48 hours of operation (not calendar) time
after the initial infection, Disk Killer executes upon the first boot
or reboot after this period. Upon execution, this virus displays the
following message:
Disk Killer -- Version 1.00 by COMPUTER OGRE 04/01/89
Warning!!
Don't turn off the power or remove the diskette while Disk Killer
is Processing!
Next, the word "PROCESSING" will be displayed, followed by this message:
Now you can turn off the power. I wish you Luck!
Disk Killer overwrites the boot sector, then the file allocation table
(FAT), then the directory randomly with blocks of a single character.
The proper procedure depends upon when you detect Disk Killer:
1. If your machine is infected before it executes and you detect this
virus through a scan package (such as CodeSafe, RESSCAN, VIRHUNT, or
IBM Scan)---TURN YOUR MACHINE OFF. Then use a write-protected bootable
floppy disk to boot your system; otherwise, you will have disk Killer
in memory, causing re-infection. Remove Disk Killer by installing and
executing a PC virus eradication package such as VIRHUNT.
2. If the message shown above appears on your computer's screen, Disk
Killer has already executed---LEAVE YOUR MACHINE ON AND ALLOW THIS
VIRUS TO EXECUTE WITHOUT INTERRUPTION (i.e., until "Now you can turn
off the power..." is displayed). It is true that Disk Killer will
overwrite your disk, but don't worry---you can restore all data and
files from your disk (floppy or hard disk) using a recovery package
such as UNKILL. Reboot from a write-protected master floppy, and
remove the virus using virus eradication software.
Regardless of which particular procedure (1 or 2) you use, be sure to
scan any disks (in particular, bootable floppies) before resuming
normal activity with your computer.
Note: Because this virus modifies every byte in every sector on your
disk, Norton Utilities not a feasible means of recovering from the Disk
Killer virus. Note also that a considerable amount of incorrect
information about responding to Disk Killer has already been
distributed. If you follow this incorrect information, which advises
you to turn your machine off as soon as Disk Killer begins to execute,
it is extremely likely that you will not be able to fully recover from
this virus.
Additional Note: The CIAC team first became aware of this virus early
last Fall. At that time, however, we chose to briefly describe this
virus in the CIAC Bulletin Board (FELIX) and CIAC Bulletin A-15, rather
than to issue a separate bulletin; infections at that time appeared to
be limited to MS DOS computers equipped with hard disks made by a
particular manufacturer in Taiwan.
For additional information or assistance, please contact CIAC:
David S. Brown
(415) 423-9878 or (FTS) 543-9878
FAX: (415) 423-0913, (FTS) 543-0913 or (415) 422-4294
Send e-mail to:
ciac@tiger.llnl.gov
Neither the United States Government nor the University of California
nor any of their employees, makes any warranty, expressed or implied,
or assumes any legal liability or responsibility for the accuracy,
completeness, or usefulness of any information, product, or process
disclosed, or represents that its use would not infringe privately
owned rights. Reference herein to any specific commercial products,
process, or service by trade name, trademark manufacturer, or
otherwise, does not necessarily constitute or imply its endorsement,
recommendation, or favoring by the United States Government or the
University of California. The views and opinions of authors expressed
herein do not necessarily state or reflect those of the United States
Government nor the University of California, and shall not be used for
advertising or product endorsement purposes.
________________________________________________________________________
THE COMPUTER INCIDENT ADVISORY CAPABILITY
CIAC
INFORMATION BULLETIN
________________________________________________________________________
The Stoned (Marijuana or New Zealand) Virus on MS DOS Computers
July 12, 1990, 1200 PST Number A-28
________________________________________________________________________
Name: Stoned virus (also known as the Marijuana or New Zealand virus)
Types: At least four known variants
Platform: MS DOS computers
Damage: Not deliberately destructive--however, this virus overwrites
some of boot sector/master boot record on infected disks (see text)
Symptoms: May write "Your computer is now stoned. Legalize marijuana"
or similar message on screen (one variant has this message removed);
may create hard disk errors or the inability to boot
Detection: VIRALERT, VIRHUNT, RESSCAN, CodeSafe, F-PROT, IBM Scan
Eradication: VIRHUNT, RESSCAN, CodeSafe, CleanUp, F-PROT and others
(contact CIAC for information about these products)
Critical Stoned Virus Facts
_______________________________________________________________________
The Stoned (Marijuana or New Zealand) virus is now one of the most
common viruses among MS-DOS systems. The Stoned virus infects the boot
sector/master boot record of floppy and hard disks. Once resident in
memory, this virus may display a message similar to the following:
Your computer is now stoned. Legalize marijuana.
Although the Stoned virus apparently was not programmed to do damage,
this virus can nevertheless damage a system. The Stoned virus may
overwrite parts of infected disks that contain directory information or
portions of user data files, specifically the boot sector of floppy
disks along with Head 0, Track 0, Sector 3 on a diskette or the master
boot record and Head 0, Track 0, Sector 7 on hard disks. If hard disks
have last been partitioned under DOS 2, this virus overwrites portions
of the File Allocation Table (FAT) as well. The result is overwriting
of data files and indications of disk errors by CHKDSK. Variants of
the Stoned virus produce slightly different effects:
Stoned-B: infection of the hard disk's partition table,
Stoned-C: no displayed message
Stoned-D: infection of high density diskettes
You can detect the Stoned virus with a variety of scan packages such as
VIRALERT, VIRHUNT, RESSCAN, CodeSafe, F-PROT, IBM Scan. You can
eradicate this virus by using packages such as VIRHUNT, RESSCAN,
CodeSafe, CleanUp, F-PROT. If you cannot obtain a virus removal
utility, we suggest you back up your applications and data from your
hard disk, and then low-level format the disk to ensure that the master
boot record is removed. Boot from a clean, writeprotected operating
system disk, restore your system, and then restore the application and
data files.
After you have cleaned your system, either with an eradication product
or by formating the drive, scan again using a virus detection utility
to ensure that the virus is not present. To ensure that your system
does not immediately become re-infected, be sure to scan all of floppy
disks for the virus as well. To clean floppies you may use one of the
suggested products, or you may format new floppies on a clean system,
then use the "copy" command to copy files from the infected floppies to
the clean ones. Format the infected floppies to reuse them.
The Stoned virus typically spreads wherever floppy disks are shared.
Infections can be easily prevented by adopting sound protection
procedures. The Stoned virus infects hard disks when a PC is booted
from an infected floppy. This virus does not infect applications,
however. If you must boot from a floppy disk, ensure with a virus scan
package that this disk is not infected, and write-protect this disk.
This will prevent your boot disk from becoming infected. (Warning:
under some circumstances the Stoned-infected floppy disk can infect a
machine even if the computer does not have a bootable operating system
on it.)
Additional Note: Basic information about the Stoned virus has been
available through the CIAC Bulletin Board (FELIX) and CIAC Bulletin
A-15 since the beginning of this year.
For additional information or assistance, please contact CIAC:
David S. Brown
(415) 423-9878 or (FTS) 543-9878
FAX: (415) 423-0913, (FTS) 543-0913 or (415) 422-4294
Send e-mail to:
ciac@tiger.llnl.gov
The assistance of Ken Van Wyk and Dave Chess is gratefully
acknowledged. Neither the United States Government nor the University
of California nor any of their employees, makes any warranty,
expressed or implied, or assumes any legal liability or responsibility
for the accuracy, completeness, or usefulness of any information,
product, or process disclosed, or represents that its use would not
infringe privately owned rights. Reference herein to any specific
commercial products, process, or service by trade name, trademark
manufacturer, or otherwise, does not necessarily constitute or imply
its endorsement, recommendation, or favoring by the United States
Government or the University of California. The views and opinions of
authors expressed herein do not necessarily state or reflect those of
the United States Government nor the University of California, and
shall not be used for advertising or product endorsement purposes.
________________________________________________________________________
THE COMPUTER INCIDENT ADVISORY CAPABILITY
CIAC
INFORMATION BULLETIN
________________________________________________________________________
The 4096 (4k, Stealth, IDF, etc.) Virus on MS DOS Computers
July 18, 1990, 1200 PST Number A-29
________________________________________________________________________
Name: 4096 virus (also known as the 4k, Stealth, IDF--Israel Defense
Forces, 100 years, Century, and Frodo virus)
Types: Two known versions (also see note 1 about Fish virus)
Platform: MS-DOS computers running DOS 3.x or 4.x ; does not appear to
infect files in DOS 2.x
Damage: Can damage files by destructive cross-linking
Symptoms: May slow system performance somewhat; may cause the system to
crash/hang, or may create hard disk errors; may write "FRODO LIVES"
on screen on or after September 22, 1990 (one variant only)
Detection: VIRHUNT, RESSCAN, CodeSafe, Vi-Spy, IBM Scan, FPROT
Eradication: VIRHUNT, CodeSafe, FPROT, and others (contact CIAC for
information about these products)
_______________________________________________________________________
Critical 4096 Virus Facts
The 4096 (4k, Stealth, IDF--Israel Defense Forces, 100 years, Century,
or Frodo) virus is one of a new breed of viruses ("Phase II"
viruses--see note 2) that are so effective in masking their presence
that they are nearly invisible to the user. The 4096 virus infects
MS-DOS systems running DOS 3.x and 4.x. (Tests show that the 4096
virus is memory resident in DOS 2.x, but it will not infect files).
This virus infects programs when a user runs or closes an executable
file. The result is that the 4096 virus adds 4096 bytes to any .EXE or
.COM files that have been opened, as well as to COMMAND.COM.
(However, this virus disguises the size of infected files by causing
the original file length to be displayed.) After initial infection,
there are usually only subtle slowdowns in system performance. As more
files become infected by this virus, it can disrupt the File Allocation
Table (FAT), causing system crashes. The hard disk may also approach
its storage capacity, causing CHKDSK to indicate the following when an
infected executable file is run:
Allocation error - File size adjusted
There is a trigger date of September 22, 1990. On or after this date
the virus attempts to replace the original boot record with another
boot record. Other reports indicate that the 4096 virus is
unsuccessful in attempting to write the boot record. The result,
however, is that the system may crash. In one version of the 4096
virus the following message is also displayed on or after the trigger
date:
FRODO LIVES
The 4096 virus is very difficult to detect, even if it has infected
many files. There is logic to defeat detection on the basis of
increased file size, virus-initiated interrupts, and/or checksums.
The most current versions of virus detection packages such as VIRHUNT,
RESSCAN, CodeSafe, Vi-Spy, and IBM Scan are effective against the 4096
virus. If you find that your computer is infected by this virus, you
should turn your machine off, then boot from a clean floppy. Now run a
virus eradication program (e.g., VIRHUNT, CodeSafe, etc.) from a
non-infected, write-protected floppy disk. Alternately, you can use
DOS COPY to change the extension of an executable version of a virus
eradication program from .EXE to .DAT or some other similar extension.
This will assure that your renamed anti-virus program cannot become
infected. Virus Bulletin recommends an additional detection method for
DOS 3.x systems---set the time stamp ahead to January 1, 2044, create a
small file, then enter the DIR command. If the 4096 virus is present,
the file size will be 4K and the date will be January 1 of the year 100
(see note 3 below). In DOS 4.x systems the displayed date will be
January 1 of the year 99. Another detection method is to use Norton
Utilities or a similar disk management utility to show the actual size
of suspected files.
Note 1: The Fish virus is a modified, more sophisticated version of
the 4096 virus. It increases file sizes by either 8K or 4K.
Note 2: Other phase two viruses include the Alabama, Virus 101, 1260,
and Fish virus.
Note 3: The 4096 virus adds 100 to the year of file creation, but
since MS DOS normally displays only the last two digits of the
year, the virus is not normally detectable on the basis of year
of file creation. MS- DOS time stamps cannot exceed December
31, 2107. If the user sets the date to January 1, 2044, the
virus code increases the year by 100, causing an illegal date.
The number 100 is displayed instead.
Note 4: Basic information about the 4096 virus has been available
through the CIAC Bulletin Board (FELIX) and CIAC Bulletin
A-15 since the beginning of this year.
For additional information or assistance, please contact CIAC:
Eugene Schultz
(415) 422-8193 or (FTS) 532-8193
FAX: (415) 423-0913, (FTS) 543-0913 or (415) 422-4294
Send e-mail to:
ciac@tiger.llnl.gov
Ray Glath and Bill Kinney furnished a portion of the information in
this bulletin. Neither the United States Government nor the University
of California nor any of their employees, makes any warranty,
expressed or implied, or assumes any legal liability or responsibility
for the accuracy, completeness, or usefulness of any information,
product, or process disclosed, or represents that its use would not
infringe privately owned rights. Reference herein to any specific
commercial products, process, or service by trade name, trademark
manufacturer, or otherwise, does not necessarily constitute or imply
its endorsement, recommendation, or favoring by the United States
Government or the University of California. The views and opinions of
authors expressed herein do not necessarily state or reflect those of
the United States Government nor the University of California, and
shall not be used for advertising or product endorsement purposes.
----------------------------------------------------------------------------
THE COMPUTER INCIDENT ADVISORY CAPABILITY
CIAC
INFORMATION BULLETIN
----------------------------------------------------------------------------
Apollo Domain/OS suid_exec Problem
July 30, 1990, 1100 PST Number A-30
----------------------------------------------------------------------------
Critical suid_exec problem Facts
Name: suid_exec problem
Types: Apollo Domain/OS version SR10.2 and SR10.3 beta earlier than BL67
Platform: Hewlett Packard/Apollo systems
Damage: Can cause unauthorized privileged access to the system
Workaround: Backup and remove the file suid_exec from the directories
/etc on each node, and in each authorized area:
/install/ri.apollo.os.v.10.2/sys5.3/etc/suid_exec
/install/ri.apollo.os.v.10.2/bsd4.3/etc/suid_exec
/install/ri.apollo.os.v.10.2.p/sys5.3/etc/suid_exec
/install/ri.apollo.os.v.10.2.p/bsd4.3/etc/suid_exec
Patch: Hewlett Packard/Apollo will release an incremental software
release to this level of the Apollo Domain/OS system shortly. This
will be available from HP/Apollo as part number 018669-A00, SR10.2.
----------------------------------------------------------------------------
The CIAC team has received information about a bug in a recent release
of the Apollo Domain/OS system released by Hewlett Packard/Apollo.
This bug can allow an intruder unauthorized privileged access to a
system. There is a workaround for this flaw described below, and a
patch will be available directly from Hewlett Packard/Apollo in the
next incremental software release. The following announcement was
recently released by Hewlett Packard.
This message is to alert administrators of Domain/OS systems of a
serious security problem in all versions of Domain/OS Release sr10.2
and in Beta versions of sr10.3 earlier than bl67. This problem is
NOT present in sr10.1 or earlier versions of Domain/OS. This problem
can be referred to as APR number DE278, other APRs have been filed
against this problem.
There is a known flaw in the file /etc/suid_exec. This file should
be deleted IMMEDIATELY from the /etc directories on all HP/Apollo
nodes AND from all authorized areas on HP/Apollo networks from which
software can be installed.
The files that must be deleted are:
On each node:
///etc/suid_exec
In each Authorized Area:
/install/ri.apollo.os.v.10.2/sys5.3/etc/suid_exec
/install/ri.apollo.os.v.10.2/bsd4.3/etc/suid_exec
/install/ri.apollo.os.v.10.2.p/sys5.3/etc/suid_exec
/install/ri.apollo.os.v.10.2.p/bsd4.3/etc/suid_exec
You must be 'root' or 'locksmith' in order to delete these files.
The removal of these files will resolve the security vulnerability
immediately.
This procedure will require that the install tool should be run with the
-x option ( continue on error - see Installing Software with Apollo's
Release and Installation Tools, Apollo order number 008860-A00, chapter
4) for all subsequent installations until the replacement files have been
obtained. The absence of these files in the authorized areas will
generate an error message during the installation process, and, if the -x
option is not specified when invoking the installation tool, will
terminate the install.
This file is normally required by the Korn Shell to run set-id Korn Shell
scripts, but is a no-op on HP/Apollo systems since Domain/OS does NOT
support the execution of set-id shell scripts. Its purpose is to serve as
the 'agent' described in the manual page for the Korn Shell under
'Execution'. An error during compilation introduced the reported
vulnerability. The removal of this file will have no affect on the
functionality provided by HP/Apollo systems, but will affect the
installation procedure as mentioned in the previous paragraph.
HP/Apollo is creating an incremental software release that will replace
these files with the correctly compiled version of the suid_exec program.
This incremental release will be made available to software maintenance
customers shortly. Those users not on a HP/Apollo maintenance contract
should be able to order the replacement files as HP/Apollo part number
018669-A00, SR10.2 Incremental Software Release. Once installed, the
replacement files will permit normal installation of software. They will
NOT permit set-id shell scripts to be run on Domain/OS installations.
The repaired file will also be available as patch_m0170 on 68000-based
systems, and patch_p0136 on DN10000-based systems. These patches are
scheduled to be on the August patch tape. The problem has already been
addressed in the next release of Domain/OS.
For additional information or assistance, please contact CIAC:
Tom Longstaff
(415) 423-4416 or (FTS) 543-4416
FAX: (415) 423-0913, (FTS) 543-0913 or (415) 422-4294
CIAC's 24-hour emergency hot-line number is (415) 971-9384. If you
call the emergency number and there is no answer, please let the
number ring until voice mail comes on. Please leave a voice mail
message; someone will return your call promptly. You may also send
e-mail to:
ciac@tiger.llnl.gov
Thanks to John G. Griffith of Hewlett Packard and Paul Holbrook of the
CERT/CC team for this information.
Neither the United States Government nor the University of California
nor any of their employees, makes any warranty, expressed or implied,
or assumes any legal liability or responsibility for the accuracy,
completeness, or usefulness of any information, product, or process
disclosed, or represents that its use would not infringe privately
owned rights. Reference herein to any specific commercial products,
process, or service by trade name, trademark manufacturer, or
otherwise, does not necessarily constitute or imply its endorsement,
recommendation, or favoring by the United States Government or the
University of California. The views and opinions of authors expressed
herein do not necessarily state or reflect those of the United States
Government nor the University of California, and shall not be used for
advertising or product endorsement purposes.
CIAC BULLETINS ISSUED
SUN 386i authentication bypass vulnerability
nVIR virus alert
/dev/mem vulnerability
tftp/rwalld vulnerability
"Little Black Box" (Jerusalem) virus alert
restore/dump vulnerability
rcp/rdist vulnerability
Internet trojan horse alert
NCSA Telnet vulnerability
Columbus Day (DataCrime) virus alert
Columbus Day (DataCrime) virus alert (follow-up notice)
Internet hacker alert (notice A-1)
HEPnet/SPAN network worm alert (notice A-2)
HEPnet/SPAN network worm alert (follow-up, notice A-3)
HEPnet/SPAN network worm alert (follow-up, notice A-4)
rcp vulnerability (second vulnerability, notice A-5)
Trojan horse in Norton Utilities (notice A-6)
UNICOS vulnerability (limited distribution, notice A-7)
UNICOS problem (limited distribution, notice A-8)
WDEF virus alert (notice A-9)
PC CYBORG (AIDS) trojan horse alert (notice A-10)
Problem in the Texas Instruments D3 Process Control System (notice A-11)
DECnet hacker attack alert (notice A-12)
Vulnerability in DECODE alias (notice A-13)
Additional information on the vulnerability in the UNIX DECODE alias (notice A-14)
Virus information update (notice A-15)
Vulnerability in SUN sendmail program (notice A-16)
Eradicating WDEF using Disinfectant 1.5 or 1.6 (notice A-17)
Notice of availability of patch for SmarTerm 240 (notice A-18)
UNIX Internet Attack Advisory (notice A-19)
The Twelve Tricks Trojan Horse (notice A-20)
Additional information on Current UNIX Internet Attacks (notice A-21)
Logon Messages and Hacker/Cracker Attacks (notice A-22)
New Internet Attacks (notice A-23)
Password Problems with Unisys U5000 /etc/passwd (notice A24)
The MDEF or Garfield Virus on Macintosh Computers (notice A-25)
A New Macintosh Trojan Horse Threat--STEROID (notice A-26)
The Disk Killer (Ogre) Virus on MS DOS Computers (notice A-27)
The Stoned (Marijuana or New Zealand) Virus on MS DOS Computers (notice A-28)
The 4096 (4k, Stealth, IDF, etc.) Virus on MS DOS Computers (notice A-29)
Apollo Domain/OS suid_exec Problem (notice A-30)
________________________________________________________________________
THE COMPUTER INCIDENT ADVISORY CAPABILITY
CIAC
INFORMATION BULLETIN
________________________________________________________________________
SunView/SunTools selection_svc Vulnerability
August 23, 1990, 1600 PST Number A-32
CIAC has been advised that there is a vulnerability (Sun Bug ID
1039576) in systems running SunView under SunOS 4.x (or SunTools under
SunOS 3.x). The SunView/SunTools selection_svc facility may allow a
remote user unauthorized access to selected files from a computer
running SunView. The problem exists in Sun3 and Sun4 platforms
running SunOS 3.x, 4.0, 4.0.1, 4.0.3, and 4.1 as well as 386i platforms
running SunOS 4.0, 4.01, and 4.0.2. Because the selection_svc process
continues to run until terminated, this vulnerability can be exploited
even after a user changes to another window system after running
SunView/SunTools or logs off the system. (The problem is in
SunView/SunTools, however, and not with other window systems such as
X11.) CERT/CC provides additional details:
On Sun3 and Sun4 systems, a remote system can read any file that is
readable to the user running SunView. On the 386i, a remote system
can read any file on the workstation running SunView regardless of
protections. Note that if root runs Sunview, all files are
potentially accessible by a remote system. If the password file with
the encrypted passwords is world readable, an intruder can take the
password file and attempt to guess passwords.
A patch for this vulnerability is available for Sun 4.x systems. Call
your local Sun answer center, phone (800) USA-4SUN, anonymous ftp into
sun-fixes on uunet.uu.net, or send e-mail to:
security-features@sun.com
Sun Microsystems has recently established a customer warning system for
reporting new vulnerabilities and disseminating relevant information.
Send e-mail to:
security-alert@sun.com
or leave a message on the voice mail system at (415) 336-7205. Please
also advise CIAC of any new vulnerabilities you may discover.
For additional information or assistance, please contact CIAC:
David Brown
(415) 423-9878 or (FTS) 543-9878
FAX: (415) 423-0913, (FTS) 543-0913 or (415) 422-4294
CIAC's 24-hour emergency hot-line number is (415) 971-9384. If you
call the emergency number and there is no answer, please let the number
ring until voice mail comes on. Please leave a voice mail message;
someone will return your call promptly. You may send e-mail to:
ciac@tiger.llnl.gov
CERT/CC and Brad Powell of Sun Microsystems provided information
included in this bulletin. Neither the United States Government nor
the University of California nor any of their employees, makes any
warranty, expressed or implied, or assumes any legal liability or
responsibility for the accuracy, completeness, or usefulness of any
information, product, or process disclosed, or represents that its use
would not infringe privately owned rights. Reference herein to any
specific commercial products, process, or service by trade name,
trademark manufacturer, or otherwise, does not necessarily constitute
or imply its endorsement, recommendation, or favoring by the United
States Government or the University of California. The views and
opinions of authors expressed herein do not necessarily state or
reflect those of the United States Government nor the University of
California, and shall not be used for advertising or product
endorsement purposes.
_____________________________________________________
The Computer Incident Advisory Capability
___ __ __ _ ___
/ | / \ /
\___ __|__ /___\ \___
_____________________________________________________
Informational Bulletin
Virus Propagation in Novelle and Other Networks
September 21, 1990, 1000 PST Number A-33
Problem: Virus propagation on write-protected file systems
Types: Many known viruses, most frequently variants of the Jerusalem
(Israeli) virus
Platform: MS-DOS computers
Damage: Files that use software write-protection schemes cannot be
assumed safe from damage due to virus infection
Symptoms: Virus infection on write-protected files
Detection: VIRHUNT, RESSCAN, CodeSafe, Vi-Spy, IBM Scan, FPROT
Eradication: VIRHUNT, CodeSafe, FPROT, and others (see text in p. 2 of
this bulletin for recommended procedures)
Critical Virus Propagation Facts
This bulletin is to warn of a virus threat to networks for MS-DOS
systems. File servers (e.g., Novell file servers) use attribute bits
to perform write protection on files stored on server machines. Many
viruses will clear these attribute protection bits before they attempt
infection, thus circumventing the write protection scheme. Thus,
write-protecting a program does not guarantee that the file is not
infected with the virus.
The following is a common scenario reported to CIAC: a floppy infected
with the Jerusalem-B virus is inserted into a user's PC attached to a
Novell network. Once this virus is executed, it resides in the PC's
memory. When the user attempts to logon to the file server (running
the program login.exe), the virus infects this program, even though the
program is write-protected. Login.exe is a shared program that is
executed by each user as s/he connects to the Novell network. Thus,
each time a user logs in to the network, his/her machine immediately
becomes infected with the Jerusalem-B virus. The network allows the
Jerusalem-B virus to spread considerably more quickly than if it had
spread through exchange of floppy disks.
When someone disinfects a system of PCs or PC clones on a Novell or
similar file system, CIAC recommends the following procedures:
1) Detect the virus using one of the recommended packages for
detecting and identifying the virus. Determine exactly which virus has
infected the system, and that all virus types have been detected.
Contact CIAC if you need assistance.
2) Deactivate the network connecting the PCs/PC clones together.
This includes shutting down the file servers and unmounting the
partitions from the users' PCs/PC clones.
3) Disinfect the server machines using an anti-virus package known
to be effective against the detected virus. Alternately, reformat the
server disks and re-install the system from original diskettes, then
restore the data files from a recent backup. Do not attempt to restore
programs (i.e., executable files) from a backup, as this is likely to
reinfect your system.
4) Disinfect each user's PC/PC clone using the same procedure as
in step 2.
5) Verify that the virus does not reside on the file server or any
user's PC/PC clone.
6) Bring the network file system back up.
For additional information or assistance, please contact CIAC:
Tom Longstaff
(415) 423-4416 or (FTS) 543-4416
FAX: (415) 423-0913 or (FTS) 543-0913
Send e-mail to:
ciac@tiger.llnl.gov
Neither the United States Government nor the University of California
nor any of their employees, makes any warranty, expressed or implied,
or assumes any legal liability or responsibility for the accuracy,
completeness, or usefulness of any information, product, or process
disclosed, or represents that its use would not infringe privately
owned rights. Reference herein to any specific commercial products,
process, or service by trade name, trademark manufacturer, or
otherwise, does not necessarily constitute or imply its endorsement,
recommendation, or favoring by the United States Government or the
University of California. The views and opinions of authors expressed
herein do not necessarily state or reflect those of the United States
Government nor the University of California, and shall not be used for
advertising or product endorsement purposes.
_____________________________________________________
The Computer Incident Advisory Capability
___ __ __ _ ___
/ | / \ /
\___ __|__ /___\ \___
_____________________________________________________
Informational Bulletin
End of FY90 Update
September 30, 1990, 1300 PST Number A-34
During the twelve months of this fiscal year, CIAC team members have
engaged in a number of activities. One of the main activities has been
assisting sites in recovering from incidents. Our involvement has led
to a number of valuable lessons learned--things that can improve your
site's computer security as well as enhance the DOE community's
coordination and handling of incidents.
1. Password problems. The main contributor to network intrusions has
been poorly chosen passwords. There are still too many accounts in
which the username and password are identical--an easy target for
network attackers and worms. There is a great need for system managers
to perform regular checks on passwords using tools such as the Security
Profile Inspector (SPI) for UNIX and VMS systems. (Contact CIAC to
obtain a copy of SPI.) Accounts such as DEMO, GUEST, TEST, FIELD, and
others need to be closed--these accounts provide an easy way for
attackers to gain unauthorized access to systems. Prohibit passwords
that can be found in the English dictionary. CIAC strongly recommends
that your site as well as your system(s) have a written password
policy. This policy should be required reading for users before they
are given an account. Violations of this policy should result in a
lower level of privileges, i.e., lower usage priority (if practical to
implement), or in the case of repeated violations, termination of usage
altogether.
2. Vulnerabilities. A frequent contributor to network intrusions
is unpatched operating system vulnerabilities. In CIAC Bulletin A-23
we described the major exploited vulnerabilities in UNIX systems. In
particular, ensure that sendmail, finger, ftp, tftp, the DECODE alias,
and the host.equiv configuration do not allow attackers opportunity for
intrusion. In CIAC Bulletin A-31 steps to improve the security of VMS
systems are presented. It is important to secure DECNET, enhance
auditing, disuser (or protect in other ways) all old or infrequently
used accounts, and improve login security with LGI_xxx SYSGEN
parameters. If you are not sure how to patch vulnerabilities, which
particular vulnerabilities apply to your system, how to install a TAR
tape, etc. call CIAC for assistance! Again, having a site policy for
dealing with vulnerabilities is essential!
3. Viruses. The major viruses with which we have dealt in the
MS-DOS arena during the last 12 months are Jerusalem, Stoned, Cascade
(1701/1704), Ohio, Ping Pong, and Disk Killer. Of these viruses,
Jerusalem and Disk Killer are most likely to produce damage. In the
Macintosh arena, nVIR and WDEF are most prevalent, although neither is
likely to damage a system. For a summary of the major viruses, refer
to CIAC Bulletin A-15. In addition to frequently obtaining reports of
viruses spreading through exchange of removable media (disks), we are
also hearing about viruses spreading rapidly through Novelle and other
microcomputer networks (see CIAC Bulletin A-33). Vendor demonstrations
and shrink wrap software are increasingly becoming a source of virus
outbreaks. We have found that sites with implemented procedures for
detecting and eradicating viruses have significantly decreased the time
and effort involved in recovering from this type of incident. Users of
PCs, PC clones, and Macintoshes frequently do not know exactly whom to
call if there is a suspected virus infection--the number of a support
person should be posted on every small system! This is particularly
important with users of classified systems. Finally, Disinfectant 2.1
and FPROT (freeware detection/ eradication packages for Macintosh and
MS-DOS computers, respectively) are available from CIAC for the
asking.
4. User Accountability and Legal Considerations. We recommend
that every user should be required to sign a statement indicating
exactly what the user is and is not permitted to do before being
allowed to use a computing system. We also recommend that if possible
every system should display a login banner that prohibits unauthorized
use (see CIAC Bulletin A-22). Failure to take these steps may provide
a legal loophole during prosecution for computer misuse and/or damage.
5. Distribution of CIAC Bulletins. Many sites promptly distribute
CIAC and other bulletins widely throughout the site. Some users and
system managers, however, report that they are not receiving CIAC
bulletins, or, if they are, there is a substantial delay. CIAC
bulletins are sent to every site's security managers (e.g., Computer
Security Site Managers and Computer Protection Program Managers). It
is critical to ensure that these bulletins quickly get to those who
need them. It is also important to avoid distributing bulletins marked
FOR OFFICIAL DEPARTMENT OF ENERGY USE ONLY outside of the DOE community.
6. Reporting of Incidents. Sometimes a CIAC team member will
call a system manager and inform that the system manager's system has
been probed or penetrated by an attacker. Too often the system manager
will not report the incident to the site security manager(s). CIAC
does not report incidents; however, it is essential that site personnel
comply with DOE Orders 1360.2A and 5637.1 in reporting incidents.
7. Getting Information to CIAC. When you have an incident that
might affect others throughout DOE (e.g., a network intrusion, worm,
new vulnerability, widespread virus infection, etc.), call CIAC. A
large number of CIAC bulletins this fiscal year have been based on
information supplied to us by sites. Many thanks go to the "good
computer security citizens" who furnish this information to us--timely
warnings have spared many sites from incidents.
8. Training and Awareness. The CIAC team has already presented
the two-day workshop on incident handling at many sites . We
appreciate the comments and feedback that have enhanced this workshop
considerably. The aim of the workshop is to enable system managers,
managers, and users to respond to incidents more efficiently as well as
become more aware of sound computer security practices. For
additional information, or to bring this workshop to your site, call
CIAC.
As a parenthetical note, please be advised that the identification
number for CIAC bulletins issued on or after October 1, 1990 will begin
with "B." Thus, the first bulletin will be B-1, the second will be
B-2, etc.
For additional information or assistance, please contact CIAC:
Eugene Schultz
(415) 422-8193 or (FTS) 532-8193
FAX: (415) 423-0913 or (FTS) 543-0913
Send e-mail to:
ciac@tiger.llnl.gov
Neither the United States Government nor the University of California nor any of
their employees, makes any warranty, expressed or implied, or assumes any legal
liability or responsibility for the accuracy, completeness, or usefulness of any
information, product, or process disclosed, or represents that its use would not
infringe privately owned rights. Reference herein to any specific commercial
products, process, or service by trade name, trademark manufacturer, or
otherwise, does not necessarily constitute or imply its endorsement,
recommendation, or favoring by the United States Government or the University of
California. The views and opinions of authors expressed herein do not
necessarily state or reflect those of the United States Government nor the
University of California, and shall not be used for advertising or product
endorsement purposes.