|
|
ARCHIVE: Zardoz 'Security Digest' - Archives (1989 - 1991)
DOCUMENT: Zardoz 'Security Digest' V1 #39 1989-11-03 (1 file, 6237 bytes)
SOURCE: http://securitydigest.org/exec/display?f=zardoz/archive/139.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
Date: Fri, 3 Nov 89 18:10:00 PST
Subject: Security Digest V1 #39
Security Digest Volume 1 Issue 39
subject(s):
SECURITY GUIDELINES TO BE FOLLOWED IN LATEST WORM ATTACK
More on the WANK worm (WORM VACCINE PLEASE DISTRIBUTE)
request for security packages
Net Hacker ...
Hacker detail ctd.
Suspect ID
Re: Advisory by CERT about Sun 4.X systems
[markw@gvl.unisys.com : NTT Challenges Hacker]
------------------------------------------------------------------------
Date: Tue, 31 Oct 89 01:02:34 EST
From: Gene Spafford <uunet!cs.purdue.edu!spaf>
Subject: SECURITY GUIDELINES TO BE FOLLOWED IN LATEST WORM ATTACK
An update on the NASA worm situation. Please pass along as you see
fit.
--From: TENCATI@NSSDCA.GSFC.NASA.GOV (SPAN SECURITY MGR. (301)286-5223)
The following message is being circulated within SPAN. It has been
submit to the routing center managers for distribution. I thought you
might like a copy for your records. Please pass this on to as many people
as you feel it appropriate.
It is applicable to all DECnet nodes world-wide.
============================================================================
INTER-NETWORK MEMORANDUM SPAN MANAGEMENT OFFICE
=============================================================================
30-OCT-1989
TO: ALL SPAN SYSTEM MANAGERS
FROM: SPAN MANAGEMENT OFFICE
GODDARD SPACE FLIGHT CENTER CODE 630.2
GREENBELT, MD. 20771
(301)286-7251
SUBJ: SECURITY GUIDELINES TO BE FOLLOWED IN LATEST WORM ATTACK
----------
A variant of the 16-Oct worm has been restarted on the DECnet internet.
This worm is a slightly modified copy of the original worm that infected
the networks last week. The method of attack is identical to the last
except that this version calls itself OILZ_nnnn instead of NETW_nnnn.
This variant of the worm changes the password of the account it
penetrates unlike its predecessor which only changed passwords if it
penetrated a privileged account.
The effect of this modification is that if the DECNET account is breached
(Userid DECNET, Password DECNET), changing of the password will disable
further *INBOUND* network connections to the node, effectively removing it
from the network. THIS IS THE PRIMARY WAY IN WHICH THE CURRENT WORM IS
ACHIEVING SUCCESS.
The previous precautions and guidelines issued by this office are still
applicable and valid. The following 5 procedures should be implemented on
all DECnet nodes to ensure that the worm cannot gain access to your node.
----------
1) The current worm has been modified to attack the default DECNET account
first. It attempts to enter the default DECNET account with user=DECNET
and password=DECNET. This is the default set up. IT MUST BE CHANGED.
To change it, two things have to be done:
$MCR AUTHORIZE
UAF> mod DECNET /pass=<something> !anything BUT "DECNET"
UAF> mod DECNET /flag=lockpwd/nobatch/prclm=0
UAF> exit
Then, to match default access control information in the executor (so
MAIL and NML will still work):
$MCR NCP
NCP> set executor nonpriv pass <something> !NOTE this MUST match what
you set in AUTHORIZE!
The above changes will not effect operation of your system, but will
prevent the worm from entering via your default DECNET account.
2) DISABLE THE TASK OBJECT
The TASK Object MUST be removed from your DECnet database.
There are two methods by which you can accomplish this:
1. In SYSTARTUP.COM/SYSTARTUP_V5.COM, after the call to
@SYS$MANAGER:STARTNET, insert the following line:
$ MCR NCP CLEAR OBJECT TASK ALL
THIS COMMAND MUST BE EXECUTED *EACH TIME* THE NETWORK
IS STARTED OR RESTARTED. DOING IT AT BOOT-TIME ALONE
IS NOT SUFFICIENT.
2. Instead of option 1, the following commands can be issued
ONCE from a privileged account to permanently change the
information in the DECnet database for the TASK object:
$ MCR NCP SET OBJECT TASK PASSWORD <type an INCORRECT password>
$ MCR NCP DEF OBJECT TASK PASSWORD <type an INCORRECT password>
If for some reason you MUST have a TASK object, please call the
SPAN network office at (301)286-7251.
3a) Protect SYS$SYSTEM:RIGHTSLIST.DAT so that it is has no protection bits
set for the WORLD category of users. This is how the attacking worm
determines who your valid users are. There is some discussion about
this approach, it apparently works on 4.7 thru 5.1-1 systems, reports
from systems testing this approach say it breaks under V5.2. So there
are 2 other approaches, set an ACL on RIGHTSLIST.DAT disabling NETWORK
access, or using a logical name to point to RIGHTSLIST.
**NOTE**
THE ACL APPROACH MAY REQUIRE A REBOOT TO PURGE THE OLD RIGHTSLIST.DAT
ON V4.7 SYSTEMS.
b) Place an ACL on RIGHTSLIST.DAT to prevent network access of your user names
------------------------------------------------------------------------
Date: Fri, 03 Nov 89 13:40:18 EST
From: Gene Spafford <uunet!cs.purdue.edu!spaf>
Subject: More on the WANK worm (WORM VACCINE PLEASE DISTRIBUTE)
I don't use VMS, so I can't comment on this. However, here it
is for you to see & use as appropriate.
------- Forwarded Message
--Date: Fri, 03 Nov 89 13:10:39 -0500
--From: TBUTLER@NSSDCA.GSFC.NASA.GOV
*********** WANK WORM VACCINE **************
A vaccine to combat the WANK worm has been developed by Bernard Perrot
of the Institut de Physique Nucleaire, Orsay, France.
The vaccine consists of creating a bogus file which you put in
SYS$SYSTEM:RIGHTSLIST.DAT. When the worm tries to use the information in this
file, the worm-code generates errors and blows up causing the attacking worm to
die. The vaccine does NOT affect the remote system - it only kills the worm.
This vaccine will stop attacks from any attacking nodes, it should therefore
greatly reduce the "annoyance level" of attacks by reducing the volume of audit
trails.
******************* IMPORTANT IMPORTANT IMPORTANT ***********************
PLEASE READ!!!
THIS VACCINE WILL ONLY WORK AGAINST **CURRENT** STRAINS OF THE WORM. WE
BELIEVE HOWEVER THAT TO ELIMINATE THIS WORM FROM THE NETWORK, THIS TECHNIQUE
WILL HAVE TO BE USED ON AS MANY SYSTEMS AS POSSIBLE. IT IS THE ONLY WAY TO
ATTACK THE WORM AT IT'S SOURCE (short of system management action on the
infected node...and a lot of system managers are either asleep, ignorant, lazy
or??? and therefore the worm has been running on some systems for days).
*******************************************************************************
This method has been tested on VMS 4.7 thru VMS 5.2 systems. In order to
correctly implement this fix, the following steps must be performed:
1) If you have previously implemented any of our suggestions regarding
file protection or ACL's on RIGHTSLIST.DAT, it is necessary to undo them
restoring SYS$SYSTEM:RIGHTSLIST.DAT to its original configuration.
2) RENAME the file SYS$SYSTEM:RIGHTSLIST.DAT to some other name of
your choosing.
3) To make VMS operate correctly with the rightslist file in a new
location, issue the following command, and also add it to your
system startup procedure:
$DEFINE/SYSTEM/EXEC RIGHTSLIST <ddcu:[dir]new-file-name>
The worm won't find the file because it can't translate the
logical symbol.
4) Take the 4-line file listed below, protect it W:R and do not
put an ACL on it. Name it SYS$SYSTEM:RIGHTSLIST.DAT. You *WANT*
the worm to access this file! Users on your system will translate the
system logical RIGHTSLIST and things will work correctly.
When an infected system attacks your node, the first thing it does is
copy your sys$system:rightslist.dat file and tries to get your local
usernames. This dummy file will cause the attacking worm to abort with
a fatal error when it tries to use the information it finds in the
bogus file.
If you have followed each of the above steps, VMS will run normally, and
you will not be vulnerable to the CURRENT strains of the worm which are
running aroung the network.
The following file should be copied into SYS$SYSTEM:RIGHTSLIST.DAT exactly
as it appears below:
- -------------------------- CUT HERE - RIGHTSLIST.DAT -----------------
DUMMY MAINTENANCE RECORD
0123456789012345"'F$PID(ON)
0123456789012345'F$PID(ON)
0123456789012345BATCH
- --------------------------- CUT HERE ----------------------------------
John McMahon of NASA/GSFC Advanced Data Flow Technology Office has created a
command procedure that will have the same end-result as the above instructions.
It is available by copying WANK_SHOT.COM from NSSDCA::WANK_SHOT.COM or
6277::WANK_SHOT.COM. This command procedure uses a modification of the above
procedure using a SET FILE/ENTER command to set up an alias for RIGHTSLIST.DAT
rather than the RENAME command above. Knowledgable system managers may want to
decide for themselves which version they prefer.
------------------------------------------------------------------------
Date: Tue, 31 Oct 89 09:49:39 MST
From: uunet!stcvax!rlr (Roger Rose)
Subject: request for security packages
Our corporate security group is attempting to compile a list of
recommended security software for various systems, and it has fallen
upon me to evaluate packages for UNIX-based systems.
The environment consists of a wide variety of systems, running various
flavors of UNIX. Not all systems have source code. The systems are
connected via ethernet. NFS and DECNET support is not unusual. Some
systems support modems and uucp links.
What the corporate MIS-types are fantasizing is a single package that
will run on any UNIX system and make it secure. (pretty funny... huh?)
What *I'm* looking for falls into two categories:
1. Audit software that checks for holes in normal UNIX system
administration.
2. Embedded/extended software that adds additional features.
(eg. audit trails, access lists, password aging)
It would be nice if the software ran on various flavors of UNIX and
various hardware platforms (such as Lachman's stuff), but this is not
necessarily essential. It would also be nice if source code were
available, so we can make local extensions and program around
vendor-specific problems.
To summarize, I'm interested any information, good or bad, about any
generally available security package running on any UNIX-based system.
------------------------------------------------------------------------
Date: Tue, 31 Oct 89 18:24:15 EST
From: uunet!aplcen.apl.jhu.edu!johnj
Subject: Net Hacker ...
[ This and the next two messages came in from the sun-managers mail list.
Thought they might be of interest - neil ]
We (at welch.jhu.edu, not apl) had a hacker attack. It came in on the
ftp account (bug? looking) and was on for 16 min total, we watched for
a bit.
In case any of you have an attack, one thing I wish I had done was to
follow the guy out. He came in via terminal servers at Rice and PSU.
I shut off our router when convinced it may be hostile/harmful, I
think it may have been better to follow him out ... I got terminal
server addresses ;he/she/it used & could have followed it out
using some server commands lik who or help or ? to keep me going.
Any advice? I called CERT to inform them. Some info follows:
in my next mail ...
------------------------------------------------------------------------
Date: Tue, 31 Oct 89 18:39:21 EST
From: uunet!aplcen.apl.jhu.edu!johnj
Subject: Hacker detail ctd.
Sorry, had to dial in to remember some names.
I have a 4/280 running OSv 4.0
The first break was on ftp account, anonymous was enabled. The proces
seems to have then ls -R /users directory captured a copy of my
passwd file & looked for no passwd * pwds same as uid. The next
break was then under an account with no passwd. A login with
group 0 (sorry I will mail again with this id) appeared in
my etc/passwd file.
The /usr/tmp/foo* files had:
foo121212 an ls -R of /users (user accounts)
foo456456 directory listings of files with string passwd in them
foo654654 a list of .rhosts files
Nothing else seems to be harmed. The addresses of the terminal servers
used is:
128.241.0.81
128.118.25.2
128.118.25.2
The first I think is rice, the next two are psu ( I called).
I will mail with the strange userid passwd entry.
------------------------------------------------------------------------
Date: Tue, 31 Oct 89 18:49:13 EST
From: uunet!aplcen.apl.jhu.edu!johnj
Subject: Suspect ID
Last for now folks, the userid that appeared in /etc/passwd was
schevon uid 1871 (not the highest) with a 0 group id.
------------------------------------------------------------------------
Date: Thu, 2 Nov 89 10:21:45 PST
From: uunet!gumby.dsd.TRW.COM!mdm (Mike Marcinkevicz)
Subject: Re: Advisory by CERT about Sun 4.X systems
Just a note that system administrators need to also remake the yellow pages
passwd file if Yellow Pages is running, otherwise the change is not guaranteed
to take effect.
------------------------------------------------------------------------
Date: Thu, 2 Nov 1989 20:12:38 CST
From: Werner Uhrig <uunet!rascal.ics.UTEXAS.EDU!werner>
Subject: [markw@gvl.unisys.com : NTT Challenges Hacker]
I had caught a part of this story on the car-radio some weeks
back and had meant to bring this to your attention. I am not
in favor of such "dares", and consider NTT's action irresponsible.
--From: markw@gvl.unisys.com
--Newsgroups: comp.dcom.telecom
--Subject: NTT Challenges Hackers
[A copy of the following article appeared on one of our bulletin boards here
at work. I have no idea when or where it was originally published - MHW]
NTT: Calling All Hackers
Tokyo - Nippon Telegraph and Telephone Corp. has issued a provocative
challenge: the Japanese communications giant will give 1 million yen
($6803) to any computer hacker anywhere in the world who can break its
FEAL-8 data communications security code by August 1991. Why the
unusual move? The company wants to debunk a rumor circulationg in
Europe that its security code has been cracked. The FEAL-8 code,
developed by NTT in 1986, is widely used in Japan and overseas to
protect datacom systems and integrated circuit cards from illegal
access.
------------------------------------------------------------------------
End of Security Digest Volume 1 Issue 39
**********************
END OF DOCUMENT
| ISSN 1742-948X 01 (Online) | 2005/03/01 | Copyright 2002-2008 securitydigest.org. All rights reserved. |